アクティブ-アクティブレプリケーションが高可用性を確保する仕組み
アクティブ/アクティブ レプリケーションにより、障害発生時でもダウンタイムなしでシステムが稼働し続けます。. 複数のサーバーが同時にトラフィックを処理することで、継続的なサービスが確保され、復旧時間がゼロになり、パフォーマンスが向上します。知っておくべきポイントは以下のとおりです。
- 概要: すべてのサーバーは稼働しており、ワークロードを共有し、同期を維持しています。.
- なぜ重要なのか: ダウンタイムは企業にとってコストと信頼を損なうものです。アクティブ/アクティブシステムはほぼ完璧な稼働率（99.999%）を維持し、年間のダウンタイムはわずか5.26分です。.
- 仕組み: 負荷分散、リアルタイムのデータ同期、自動フェイルオーバーを組み合わせて、中断のない運用を実現します。.
- 主な利点: ダウンタイムの短縮、グローバルなスケーラビリティ、中断のないメンテナンス。.
- 課題: データの一貫性、運用の複雑さ、およびコストの増加を管理します。.
このアーキテクチャは、eコマース、金融、ヘルスケアなど、稼働時間の1秒1秒が重要となる業界に最適です。綿密な計画とリソースが必要ですが、その見返りとして、中断のないサービスと顧客満足度を実現できます。.
マルチデータセンターレプリケーション：アクティブ/パッシブとアクティブ/アクティブアーキテクチャの説明
sbb-itb-59e1987
アクティブ-アクティブレプリケーションの仕組み
アクティブ-アクティブレプリケーションの仕組み: 3つのコアメカニズム
アクティブ・アクティブ・レプリケーションは、次のものを組み合わせることで高可用性を確保することを目的としています。 負荷分散, リアルタイム同期、 そして 自動フェイルオーバー. これらのメカニズムを組み合わせることで、予期せぬ問題が発生した場合でもスムーズに動作し続けるシステムが構築されます。.
トラフィック分散のための負荷分散
トラフィック管理の中核となるのはロードバランサです。ロードバランサは、受信したリクエストをすべてのアクティブノードに分散します。一般的には、以下の方法が用いられます。
- ラウンドロビン: リクエストをノードに順番に割り当てます。シンプルですが、各サーバーの実際のワークロードは考慮されません。.
- 加重分布: より多くのトラフィックを 仮想プライベートサーバー 容量が大きいため、さまざまなハードウェア仕様のシステムに最適です。.
- 最小接続数: 最も少ないアクティブセッションを処理するサーバーにトラフィックを送信し、不均一なワークロードによる過負荷を防ぎます。.
- 最短応答時間: リクエストを最速のサーバーにルーティングします。これは、低レイテンシが重要となるアプリケーションにとって非常に重要です。.
複数の地域にまたがるシステムの場合、, エニーキャストルーティング は画期的なソリューションです。異なる場所にあるサーバーで単一のIPアドレスを共有できるため、トラフィックは最も近い正常なノードに自動的にルーティングされます。地域のデータセンターがオフラインになった場合でも、トラフィックは中断することなくシームレスに他の場所に移行します。.
負荷分散が完了したら、次のステップはすべてのノードが同期された状態を維持することを確認することです。.
リアルタイムデータ同期
ノード間でデータの一貫性を維持することは不可欠であり、これは継続的なレプリケーションによって実現されます。この課題には、システムごとに独自の方法で対処しています。
- コンセンサスベースのシステム: CockroachDB のようなツールは、一貫性を確保するために Raft などのアルゴリズムを使用します。書き込みは、過半数（多くの場合 3 ノード中 2 ノード）が承認した場合にのみ確定されます。このアプローチにより、競合を回避し、ネットワーク分割から 20 秒以内に回復できます。.
- CRDT ベースのシステム: Redisは、衝突のない複製データ型（CRDT）を採用し、複数リージョンへの同時書き込みを処理します。ローカルデータは一時的に異なる可能性がありますが、最終的には単一の一貫性のある状態に収束します。専用の同期プロセスが変更を管理し、定期的な更新には部分同期、失われたレプリカの回復には完全同期を使用します。.
"「アクティブ/アクティブデータベースは、競合のない複製データ型（CRDT）のみを使用します。これらのデータ型は予測可能な競合解決を提供し、アプリケーション側またはクライアント側での追加作業を必要としません。」 – Redis Software
CRDTを活用したシステムは、1ミリ秒未満という驚異的な読み取り/書き込みレイテンシを実現できます。ただし、このレベルのパフォーマンスを実現するには、メタデータと同期のバックログを処理するために、標準的なレプリケーションの最大2倍のメモリが必要です。ノードクロックの同期を維持し、クラスター全体のスムーズな通信を確保するには、NTPやChronyなどのツールが不可欠です。.
この同期により、複雑な分散設定でもデータの一貫性と信頼性が確保されます。.
ノード障害時の自動フェイルオーバー
ノードに障害が発生した場合、アクティブ-アクティブレプリケーションが介入し、システムの稼働を継続します。負荷分散と同期データにより、システムは瞬時に適応できます。仕組みは以下のとおりです。
- リアルタイム検出: ロードバランサーとグローバルトラフィックマネージャー（GTM）は、ハートビート信号と遅延を考慮した可用性チェックを通じてノードの健全性を監視します。ノードがダウンした場合、トラフィックは直ちに正常なノードにリダイレクトされます。.
- Redis レプリカ HA: Redis のようなセットアップでは、レプリカ シャードは他のノードに自動的に再割り当てされ、単一障害点によって操作が中断されることがなくなります。.
- コンセンサスベースのシステム: これらのシステムは、1 つのノードが使用できなくなった場合でもデータの整合性を維持するために、複数のレプリカ (少なくとも 3 つ) にレプリケーション要求を送信します。.
リージョンをまたぐ設定では、Global Traffic Manager がユーザーを最も近い運用リージョンにルーティングします。遅延を考慮したヘルスチェックにより、フェイルオーバー時のデータの古さを回避できます。また、Redis 実装では、Pub/Sub メカニズムを使用して、単純なデータセットの読み取りよりも効果的にレプリケーション ストリームを監視できます。.
アクティブ-アクティブレプリケーションの利点
アクティブ/アクティブ・レプリケーションは、ダウンタイムの最小化、システムの効率的な拡張、そして中断のないメンテナンスの実現において、画期的なソリューションです。負荷分散、リアルタイム同期、自動フェイルオーバーを組み合わせることで、他に類を見ない高可用性を実現します。. Serverion‘のインフラストラクチャはこれらの機能を最大限に活用して、システムをスムーズかつ効率的に実行します。.
ダウンタイムの短縮
アクティブ/アクティブ・レプリケーションの際立った利点の一つは、ダウンタイムをほぼゼロにまで削減できることです。すべてのノードがアクティブで同時にリクエストを処理するため、1つのノードに障害が発生しても、バックアップシステムの起動を待つ必要はありません。ワークロードは残りのノードに瞬時に分散されるため、目立った中断は一切発生しません。.
"「サーバーが『高可用性』とみなされるためには、99.999%のネットワーク稼働率を達成する必要があります。」 – Microsoftネットワーク開発者用用語集
「ファイブ・ナイン」の稼働率（99.999%）を達成するということは、年間のダウンタイムがわずか5.26分であることを意味します。アクティブ/アクティブアーキテクチャは単一障害点を排除し、ハードウェアの問題、ソフトウェアのクラッシュ、ネットワークの問題によってシステムがダウンすることを防ぎます。.
しかし、ダウンタイムの短縮はほんの始まりに過ぎません。アクティブ/アクティブ・レプリケーションは、グローバルな拡張性においても真価を発揮します。.
スケーラビリティとマルチリージョンサポート
アクティブ/アクティブ環境はスケーリングをシンプルにします。新しいノードを追加すると、すべてのノードが読み取りと書き込みの両方を処理できるため、システムのスループットが即座に向上します。この水平スケーリングにより、追加ノードごとにパフォーマンスが直線的に向上します。.
地理的分散は、さらに一歩先を行きます。ノードを複数の地域に分散させることで（例えば、バージニア州に1つ、カリフォルニア州に1つ、アイルランドに1つなど）、ユーザーは最も近いノードに接続されます。この構成により、データの読み取りと書き込みの両方で、多くの場合1ミリ秒未満という超高速の応答時間を実現します。さらに、データセンターが停電や災害でオフラインになった場合でも、トラフィックはサービスが中断されることなく、自動的に他のノードにリダイレクトされます。.
サービス中断なしのメンテナンス
定期メンテナンスに伴うダウンタイムや顧客への事前警告は不要になりました。ノード障害に対応するリアルタイム同期機能は、シームレスなメンテナンスもサポートします。ノードのアップデート、セキュリティパッチの適用、ハードウェアの交換などが必要になった場合、そのノードをオフラインにすることができます。その間も、他のノードは引き続きすべての受信トラフィックを管理します。.
"「Oracle GoldenGateは、高可用性とゼロダウンタイムのアップグレードおよび移行プロジェクトの両方にアクティブ/アクティブソリューションを提供します。」 – Oracle
メンテナンスが完了すると、オフラインノードは未適用の更新情報と自動的に再同期します。このアプローチにより、ユーザーや業務に支障をきたすことなく、システムのセキュリティと最新状態が維持されます。.
アクティブ/アクティブ展開における課題
アクティブ/アクティブレプリケーションには紛れもない利点がありますが、組織にとって一連の技術的課題も伴います。この構成を成功させるには、分散システムにおける調整、一貫性、そしてコストを慎重に管理する必要があります。.
データの一貫性の管理
リアルタイム同期はアクティブ/アクティブ環境における信頼性の基盤ですが、同時に大きな課題も伴います。最も困難な問題の一つは、異なるノード間での同時データ書き込みの処理です。例えば、2人のユーザーが別々のサーバーで同時に同じレコードを更新した場合、システムはどちらの変更を保持するかを決定する必要があります。こうした競合を解決するための一般的な戦略としては、「最終書き込み優先」、特定のノードへの優先順位の割り当て、カスタムマージロジックの採用などが挙げられます。.
"マルチマスターは競合を排除するわけではなく、単に移動させるだけです。このような状況では、遅延やその他の理由により競合が発生します。解決ロジックが重要になります。"
- Jan Wieremjewicz、Percona シニアプロダクトマネージャー
ノード間の地理的な距離は、複雑さをさらに増します。例えば、米国とオーストラリア間のネットワーク遅延は、150～200ミリ秒の往復遅延を引き起こす可能性があり、ノードが一時的に古いデータを提供したり、フェイルオーバー時に最新の更新情報を取得できなかったりする可能性があります。この問題はクロック同期の問題によってさらに悪化します。サーバーのクロックがずれると、タイムスタンプベースの競合解決が信頼できなくなり、一貫性がさらに複雑になります。.
運用の複雑さ
アクティブ/アクティブシステムの運用は決して容易ではありません。これらの環境では、専門知識と継続的な監視が求められます。スキーマの更新やデプロイメントといった日常的なタスクは、レプリケーションを中断させるリスクが高く、ダウンタイムを回避するために綿密な計画が必要です。.
"「アクティブ/アクティブは、よく思われるほど近道ではありません。単なる『高可用性（HA）をさらに向上させたもの』ではありません。これは、エンジニアリング、運用、製品管理のすべてにおいて、多大な継続的なコストを伴う、根本的なシステム設計の変更を意味します。」‘
- Jan Wieremjewicz、Percona シニアプロダクトマネージャー
アクティブ/アクティブ構成では、運用監視の要件が大幅に厳しくなります。チームは、複数の書き込み可能なノード間でのレプリケーション遅延、ノードの健全性、整合性チェック、トランザクションのトレースを綿密に監視する必要があります。さらに、これらのシステムでは、メタデータと同期のバックログを管理するために、より多くのメモリ（標準的なレプリケーション構成の2倍になる場合もあります）が必要になることがよくあります。場合によっては、メモリ使用量が80%に達したときに、クラスタ間のスムーズな伝播を確保するために、エビクションポリシーが有効化されることもあります。.
コストへの影響
アクティブ/アクティブ導入には高額な費用がかかります。より多くのハードウェアリソース、より広いネットワーク帯域幅、そしてシステム管理のための高度なスキルを持つ人員が必要になります。さらに、エンタープライズグレードのアクティブ/アクティブソリューションは、標準構成と比較してライセンスコストが高額になる場合が多くあります。このようなアーキテクチャを採用する前に、組織は、リージョンリードレプリカ、シャーディング、アクティブ/パッシブ構成といったよりシンプルなオプションが、より低コストでニーズを満たすことができるかどうかを慎重に検討する必要があります。これらの課題は重大ですが、アクティブ/アクティブアーキテクチャが目指す高可用性を実現するためには、これらの課題への対処が不可欠です。.
一般的なアクティブ/アクティブ展開パターン
組織は、アクティブ/アクティブ・レプリケーションを実装するために、いくつかの確立されたパターンを採用しています。それぞれは特定の運用ニーズに合わせてカスタマイズされています。これらのアプローチは、アクティブ/アクティブ・システムのコアメカニズムを基盤とし、様々な導入シナリオに適用されています。適切なパターンの選択は、システムの要件と制約によって異なります。.
マルチリージョンデータベースクラスター
最も一般的なパターンの一つは、データベースクラスタを複数の地理的地域に分散させることです。この設定では、米国東海岸、ヨーロッパ、アジアなどの地域に独立したデータベースクラスタを配置し、各クラスタがローカルの読み取りおよび書き込み操作を管理します。ユーザーは最も近いクラスタに接続することで、 1ミリ秒未満の遅延 ローカルリクエストの場合。ただし、リージョン間でデータを同期すると、物理的な距離により遅延が発生します。.
例えば、ニューヨークのユーザーがプロフィールを更新した場合、その変更がヨーロッパやアジアに反映されるまでには時間がかかる可能性があります。CockroachDBのようなシステムでは、コンセンサスベースのレプリケーションを使用することでこの問題に対処しています。コンセンサスベースのレプリケーションでは、書き込みがコミットされる前に、レプリカの過半数（通常は3つ）による確認が必要となります。これにより、すべてのノード間で強力な一貫性が確保されます。.
"「マルチアクティブ可用性は、従来の高可用性の概念と同様の利点を提供しますが、クラスタ内のすべてのノードから競合を発生させることなく読み取りと書き込みを行うことができます。」 – CockroachDB
このパターンは、データレジデンシー法への準拠が求められるグローバルアプリケーションや、eコマースプラットフォームや金融サービスなどの高トラフィックシステムに適しています。ただし、複雑なトランザクションロジックを持ち、結果整合性を処理できないアプリケーションには最適な選択肢ではない可能性があります。.
一部の導入では、回復力を高めるためにレプリケーション ロジックをアプリケーション層に直接組み込むことで、これをさらに進めています。.
アプリケーションレベルのレプリケーション
このパターンでは、フェイルオーバーロジックはデータベースのみに依存するのではなく、アプリケーションに直接組み込まれています。アプリケーションはデータベースレプリカの健全性を積極的に監視し、障害を検知すると接続を切り替えます。例えば、ローカルのRedisレプリカがオフラインになった場合、アプリケーションはすぐに別のリージョンにあるリモートレプリカに再ルーティングできます。.
パブリッシュ/サブスクライブ機構は、レプリカの健全性を追跡することで信頼性を高めるためによく使用されます。このアプローチは、開発者が一貫性のトレードオフをより細かく制御できる一方で、課題も伴います。フェイルオーバー中の非同期レプリケーションでは、書き込み操作が失われる可能性があります。.
"「アクティブ-アクティブ接続フェイルオーバーはデータの可用性を向上させますが、データの一貫性に悪影響を与える可能性があります。別のレプリカにフェイルオーバーするアプリケーションは、書き込み操作を逃す可能性があります。」 – Redis
この方法は柔軟性を提供しますが、可用性と一貫性のバランスをとるために慎重な設計が必要です。.
仮想マシンとサーバーのレプリケーション
もう一つのアプローチは、仮想マシン（VM）とサーバーを異なるサイトに複製することです。この方法では、多くの場合「ストレッチクラスタ」が用いられます。ストレッチクラスタとは、2つの物理的な場所にあるホストが同じ仮想化環境内で動作するクラスタです。この構成では、両サイトからアクセスおよび書き込み可能な同期的に複製されたストレージと、低レイテンシのレイヤー2ネットワーク接続が不可欠です。.
このパターンは、災害復旧と事業継続性に最適です。通常運用時は、ワークロードを2つのサイト間で分散できます。障害発生時には、すべてのワークロードが正常なサイトへ自動的に移行されます。ただし、これを実装するには、共有ネットワークや同期ストレージなどの大規模なインフラストラクチャが必要となり、コストと複雑さが増大する可能性があります。.
結論
アクティブ-アクティブレプリケーションは、一瞬たりともダウンタイムが許されないビジネスにおいて重要な役割を果たします。すべてのノードをオンライン状態に保ち、トラフィックをアクティブに処理することで、この構成は 目標復旧時間（RTO）ゼロ – すべてのサーバーがすでに稼働しているため、バックアップ サーバーが起動するまで待つ必要はありません。.
前述の通り、このアーキテクチャは稼働時間とパフォーマンスの向上など、明確な運用上のメリットをもたらします。リソースをアイドル状態にするアクティブ/パッシブシステムとは異なり、アクティブ/アクティブ構成ではハードウェアを最大限に活用できます。フェイルオーバーは数秒で完了し、最新の設計によりローカルリクエストのレイテンシが最小限に抑えられます。株式取引プラットフォームや通信サービスなど、1ミリ秒単位の遅延が重要な業界にとって、このレベルのパフォーマンスは画期的な成果をもたらす可能性があります。.
"「ほとんどの業界では、データ損失に対する許容度はゼロに近づいています。かつては数分単位のダウンタイムが許容されていましたが、今日では許容されるダウンタイムのレベルも1桁、あるいは数秒単位へと移行しています。」 – Preciselyホワイトペーパー
しかし、この信頼性には複雑さが伴います。複数のアクティブノード間でデータの一貫性を確保するには、高度な競合解決メカニズム、同期されたクロック、そしてレプリケーション遅延の継続的な監視が必要です。さらに、メタデータとレプリケーションのバックログを処理するために、メモリ需要が倍増する可能性もあります。しかし、稼働時間が収益と顧客の信頼に直接影響する組織にとって、これらの課題は避けられないトレードオフです。.
マルチリージョンのデータベースクラスターを管理する場合でも、アプリケーションレベルのレプリケーションを使用する場合でも、データセンター全体にストレッチクラスターを展開する場合でも、アクティブ/アクティブ・レプリケーションは高可用性を現実的なものにします。これは単なる設計上の選択ではなく、中断を許容できない企業にとって戦略的な必需品です。Serverionの高度なアクティブ/アクティブ・レプリケーション・ソリューションにより、障害の有無にかかわらず、サービスへのアクセスを維持できます。.
よくある質問
アクティブ/パッシブよりもアクティブ/アクティブを選択すべきなのはどのような場合ですか?
アプリケーションで要求される 常に利用可能, 最高のパフォーマンス 交通量の増加時, スケーラビリティ、 そして 地理的な冗長性, アクティブ/アクティブ構成が最適な選択肢です。インフラストラクチャ費用が増加し、複雑さも増しますが、ダウンタイムを許容できないシステムにおいて、高い信頼性と可用性を実現します。.
アクティブ/アクティブシステムはどのようにして書き込みの競合を防ぐのでしょうか?
アクティブ・アクティブシステムは、書き込み競合に対処するために、 競合のない複製データ型（CRDT）. これらは、 最終的な一貫性 複数のレプリカ間で読み取りおよび書き込み操作を自動的に同期します。CRDTは競合を自動的に解決するため、手動での修正は不要です。この方法により、分散システムにおける高可用性を維持しながら、データの一貫性を維持できます。.
リージョン間でアクティブ/アクティブを実行するには何が必要ですか?
リージョン間でアクティブ-アクティブレプリケーションを実行するには、 グローバル交通管理ソリューション リクエストルーティングを効率的に処理するためには、DNSベースのトラフィックマネージャやロードバランサなどのツールを利用する必要があります。また、この設定には、以下の機能を備えたインフラストラクチャも必要です。 データ複製の同期 一貫性を維持しながら、多くの場合、次のようなアプローチを通じて 最終的な一貫性.
安全で信頼性の高いシステムを確保するには、 TLS暗号化 ネットワークセキュリティのために。さらに、以下のような要素を考慮することが重要です。 レイテンシー, 運用コスト、そして 管理の複雑さ. これらの考慮事項は、高可用性と堅牢な災害復旧機能を維持するために不可欠です。.
