データは、ほとんどのビジネスにとって中心的な要素です。 データキャリアとして、データベースはビジネスにおいて決定的な役割を果たします。 ApsaraDB for Redis は、高性能な key-value データベースシステムです。 データベースには、企業にとって重要なデータが大量に保存されています。 このドキュメントでは、ApsaraDB for Redis に基づくディザスタリカバリのメカニズムについて説明します。

ApisaraDB for Redis に基づくディザスタリカバリアーキテクチャの進化

プログラムの実行中に、ソフトウェアのバグ、デバイスの障害、データセンターの停電などの問題が発生する場合があります。 このような場合に、優れたディザスタリカバリメカニズムにより、データの一貫性とサービスの可用性を確保できます。 ApsaraDB for Redis は、ディザスタリカバリ機能を改善してサービスの高可用性 (HA) を確保し、さまざまなシナリオで高可用性ソリューションを提供します。

次の図は、AdisaraDB for Redis に基づくディザスタリカバリアーキテクチャの進化を示しています。

図 1. ApisaraDB for Redis に基づくディザスタリカバリアーキテクチャの進化

これらのソリューションがすべて利用可能です。 必要に応じて選択できます。 以下のセクションでは、これらのソリューションについて詳しく説明します。

単一ゾーンの高可用性メカニズム

ApsaraDB for Redis インスタンスのすべてのタイプで、単一ゾーンの高可用性アーキテクチャをサポートしています。 HA 監視モジュールは、独立したプラットフォームアーキテクチャを使用し、ゾーン全体に高可用性メカニズムを提供します。 したがって、ApsaraDB for Redis は、オンプレミスの Redis システムよりも安定して機能します。

標準デュアルレプリカ版

標準デュアルレプリカインスタンスは、マスターレプリカアーキテクチャを使用します。 マスターノードで障害を検出すると、HA 監視モジュールは自動的にフェールオーバー操作を実行します。 レプリカノードはサービスを引き継ぎ、マスターノードになります。障害から回復すると、元のマスターノードは新しいレプリカノードとして機能します。 インスタンスはデフォルトでデータ永続性に対応し、自動データ複製を許可します。 複製ファイルを使用して、インスタンスをロールバックまたは複製できます。

図 2. マスターレプリカインスタンスの高可用性アーキテクチャ

マスターレプリカインスタンス

マスターレプリカインスタンス は、設定サーバー、複数のプロキシサーバー、および複数のシャードサーバーで構成されています。 これらのサーバーについて以下に説明します。

  • 設定サーバーは、グローバルルーティングおよび設定情報を提供するクラスター管理ツールです。 このサーバーは、Raft プロトコルに従うトリプルレプリカクラスターアーキテクチャを使用します。
  • プロキシサーバーは、単一ノードアーキテクチャを使用します。 Cluster Edition には、複数のプロキシサーバーが含まれています。 ApsaraDB for Redis は、すべてのプロキシサーバーに対して負荷分散とフェールオーバー操作を実行します。
  • シャードサーバーは、デュアルレプリカの高可用性アーキテクチャを使用します。 標準のデュアルレプリカインスタンスと同様に、シャードサーバーのマスターノードに障害が発生すると、HA モジュールは自動的にフェールオーバー操作を実行してサービスの高可用性を確保し、プロキシサーバーと設定サーバーの情報を更新します。
図 3. マスターレプリカクラスターの高可用性アーキテクチャ

ゾーンディザスタリカバリのメカニズム

Standard Edition と Cluster Edition では、2 つのデータセンター間のゾーンディザスタリカバリをサポートしています。 単一のリージョンにビジネスをデプロイでき、優れたディザスタリカバリが必要となります。 この場合、ApsaraDB for Redis インスタンスを作成する際に、ゾーンディザスタリカバリに対応しているゾーンを選択する必要があります。 たとえば、次の図に示すように シンガポールゾーン (B+C) を選択できます。

図 4. ゾーンディザスタリカバリインスタンスの作成

複数のゾーンで実行するインスタンスを作成する際、レプリカデータセンターのレプリカインスタンスは、マスターデータセンターのインスタンスと同じタイプになります。 マスターおよびレプリカデータセンターのインスタンスは、専用のレプリケーションチャネルを使用してデータを相互に同期します。

マスターデータセンターで停電またはネットワークの障害が発生すると、レプリカインスタンスがサービスを引き継ぎ、マスターインスタンスになります。 システムは、設定サーバーで操作を呼び出して、プロキシサーバーのルーティング情報を更新します。 システムは、ルーティングの精度に従って、ネットワーク層でフェールオーバー操作を実行します。 通常の状態では、システムは正確なクラスレスドメイン間ルーティング (CIDR) ブロックを使用して、マスターデータセンターのインスタンスにデータを直接送信します。 ただし、障害が発生した場合、マスターデータセンターは、ルーティングの詳細をバックボーンにアップロードしません。 バックボーンは、レプリカデータセンターの低精度 CIDR ブロックのみを提供します。 システムは、フェールオーバー中にレプリカデータセンターに要求をルーティングする必要があります。

ApsaraDB for Redis は、Redis 同期メカニズムを最適化します。 MySQL のグローバルトランザクション識別子 (GTID) と同様に、ApsaraDB for Redis はグローバル操作識別子 (OpID) を使用して同期のオフセットを示し、バックグラウンドロックフリースレッドを使用して OpID を検索します。 システムは、追加専用ファイル (AOF) バイナリログ (binlog) を非同期に同期します。 この同期を調整して、サービスのパフォーマンスを確保できます。

クロスリージョンディザスタリカバリ

ApisaraDB for Redis はRedis Global Replica ソリューションを提供しているため、複数のサイトが世界中のリージョンで同時にサービスを提供することができます。 これは、複数のリージョン間の同期に適用できます。 従来のディザスタリカバリソリューションとは異なり、このソリューションでは複数のサイトが同時にマスターノードとして機能します。 このアーキテクチャに基づいて、ビジネスを複数のリージョンで同時に実行できます。 これらのリージョンのグローバルレプリカインスタンスの子インスタンスは、リアルタイムでデータを相互に同期します。

Redis Global Replica は現在、Alibaba Cloud 中国サイトでトライアル中です。 現在、他の Alibaba Cloud サイトではサポートしていません。
ApsaraDB for Redis のグローバルレプリカインスタンスは、複数の子インスタンス、複数の同期チャネル、およびチャネルマネージャーで構成されています。
  • 子インスタンスは、グローバルレプリカインスタンスの基本サービス単位です。 すべての子インスタンスは、読み取りおよび書き込み可能です。
  • 同期チャネルは、子インスタンス間の双方向の同期をリアルタイムでサポートします。 ブレークポイントからの再開に基づいて、システムは数日間のサービスの中断に対応します。
  • チャネルマネージャーは、同期チャネルのライフサイクルを制御し、マスターインスタンスに障害が発生した後、マスターレプリカのフェールオーバーやレプリカインスタンスの再構築など、子インスタンスの操作を処理します。 このようにして、グローバルレプリカインスタンスは高可用性サービスを提供できます。
子インスタンスは、非同期レプリケーションを実行してデータを同期します。 これは、AdisaraDB for Redis のサービスパフォーマンスには影響しません。

ApisaraDB for Redis のグローバルレプリカインスタンスを使用する場合、アプリケーションのフェールオーバー条件を指定できます。 したがって、あるリージョンで障害が発生すると、ビジネスはサービスを別のリージョンの子インスタンスに切り替えて、サービスの可用性を確保します。

ApsaraDB for Redis では、インスタンスレベル、ゾーンレベル、およびリージョンレベルのディザスタリカバリを実行するための複数の高可用性アーキテクチャを提供します。 必要に応じて、対応するディザスタリカバリソリューションを選択できます。