Tair (Redis OSS-compatible) は、さまざまなシナリオで大量の重要データを保存するために使用できる、パフォーマンス専有型のキーと値のデータベースサービスです。このトピックでは、Tair (Redis OSS-compatible) が提供するディザスタリカバリソリューションについて説明します。
ディザスタリカバリソリューションの進化
インスタンスは、データセンターのデバイスや電源の障害などの理由で故障する可能性があります。この場合、ディザスタリカバリによってデータの整合性とサービスの可用性を確保できます。
図 1. ディザスタリカバリソリューションの進化
ディザスタリカバリソリューション | 保護レベル | 説明 |
★★★☆☆ | マスターノードとレプリカノードは、同じゾーン内の異なるマシンにデプロイされます。マスターノードに障害が発生した場合、高可用性 (HA) システムはフェールオーバーを実行して、単一障害点 (SPOF) によるサービスの中断を防ぎます。 | |
★★★★☆ | マスターノードとレプリカノードは、同じリージョン内の 2 つの異なるゾーンにデプロイされます。マスターノードが存在するゾーンが電源障害やネットワーク障害などの要因で切断された場合、HA システムはフェールオーバーを実行して、インスタンス全体の継続的な可用性を確保します。 | |
★★★★★ | Redis グローバル分散キャッシュのアーキテクチャでは、分散インスタンスは複数のサブインスタンスで構成され、同期チャネルを使用してリアルタイムでデータを同期します。チャネルマネージャーは、サブインスタンスのヘルスステータスをモニターし、マスターノードとレプリカノード間のスイッチオーバーなど、サブインスタンスで発生する例外を処理します。Redis グローバル分散キャッシュは、ジオディザスタリカバリ、アクティブ地理的冗長性、近接アプリケーションアクセス、ロードバランシングなどのシナリオに適しています。 |
シングルゾーン HA ソリューション
すべてのインスタンス は、シングルゾーン HA アーキテクチャをサポートしています。HA システムは、マスターノードとレプリカノードのヘルスステータスをモニターし、フェールオーバーを実行して SPOF によるサービス中断を防ぎます。
デプロイメントアーキテクチャ | 説明 |
図 2. 標準マスターレプリカインスタンスの HA アーキテクチャ 標準マスターレプリカインスタンスは、マスターレプリカアーキテクチャで実行されます。HA システムがマスターノードの障害を検出すると、システムはワークロードをマスターノードからレプリカノードに切り替え、レプリカノードがマスターノードのロールを偽装します。回復後、元のマスターノードはレプリカノードとして機能します。 | |
図 3. 複数レプリカクラスターインスタンスの HA アーキテクチャ 複数レプリカクラスターインスタンスでは、データはデータシャードに保存されます。各データシャードは、マスターノードと複数のレプリカノードで構成されます。マスターノードとレプリカノードは、HA アーキテクチャ内の異なるマシンにデプロイされます。マスターノードに障害が発生した場合、HA システムはマスターレプリカスイッチオーバーを実行して、高いサービス可用性を確保します。 | |
図 4. 読み書き分離インスタンスの HA アーキテクチャ
|
ゾーンディザスタリカバリ (マルチゾーン) ソリューション
Tair (Redis OSS-compatible) は、複数のゾーンを含むゾーンディザスタリカバリソリューションを提供します。ワークロードが単一リージョンにデプロイされていて、ディザスタリカバリに対する要件が高い場合は、インスタンスを作成するときにゾーンディザスタリカバリをサポートするマルチゾーンデプロイメントモードを選択できます。詳細については、「手順 1: インスタンスの作成」をご参照ください。
図 5. ゾーンディザスタリカバリインスタンスの作成 
ゾーンディザスタリカバリインスタンスを作成すると、マスターノードと同じ仕様のレプリカノードがマスターノードとは異なるゾーンにデプロイされます。マスターノードは、専用チャネルを介してレプリカノードにデータを同期します。
マスターノードで電源障害やネットワークエラーが発生した場合、レプリカノードがマスターノードのロールを偽装します。システムは設定サーバで API 操作を呼び出して、プロキシノードのルーティング情報を更新します。さらに、Tair (Redis OSS-compatible) は、最適化された Redis 同期メカニズムを提供します。MySQL のグローバルトランザクション ID (GTID) と同様に、Tair (Redis OSS-compatible) はグローバル操作 ID (OpID) を使用して同期オフセットを示し、バックグラウンドでロックフリーのスレッドを実行して OpID を検索します。システムは、AOF バイナリログ (binlog) をマスターノードからレプリカノードに非同期で同期します。同期をスロットルして、Redis のパフォーマンスを確保できます。
クロスリージョンディザスタリカバリソリューション
ビジネスが複数のリージョンに拡大するにつれて、クロスリージョンおよび長距離アクセスは高いレイテンシを引き起こし、ユーザーエクスペリエンスを低下させる可能性があります。Tair 用 Redis グローバル分散キャッシュは、クロスリージョンアクセスによって引き起こされる高いレイテンシを削減するのに役立ちます。Redis グローバル分散キャッシュには、次の利点があります:
アプリケーションに冗長性を組み込む必要なく、サブインスタンスを直接作成したり、同期が必要なサブインスタンスを指定したりできます。これにより、アプリケーション設計の複雑さが大幅に軽減され、アプリケーション開発に集中できます。
クロスリージョンレプリケーション機能を提供して、ジオディザスタリカバリまたはアクティブ地理的冗長性を実装します。
この機能は、マルチメディア、ゲーム、e コマースなどの業界におけるクロスリージョンデータ同期シナリオやグローバルなビジネスデプロイメントに適しています。詳細については、「Redis グローバル分散キャッシュ」をご参照ください。
図 7. Tair 用 Redis グローバル分散キャッシュのアーキテクチャ
障害への対応方法
デバイスの誤動作、データセンターの停電、自然災害などの障害は、マスターノードの障害またはゾーンレベルの障害として分類できます。このような障害が発生する確率は低いですが、インスタンスが一時的にデータを書き込めなくなったり、一時的な切断が発生したり、完全なダウンタイムやデータ損失に直面したりする可能性があります。インスタンスの信頼性は、そのアーキテクチャと密接に関連しています。ほとんどの場合、クラスターアーキテクチャはより高い信頼性を提供します。障害の影響を最小限に抑えるために、複数のレプリカを持つマルチゾーンインスタンスは、障害発生時に自動的にフェールオーバーを実行し、ダウンタイムを最小限に抑えます。次のセクションでは、さまざまなディザスタリカバリソリューションを使用するインスタンスが障害にどのように対応するかについて説明します。
ノード障害への対応
マスターノードに障害が発生した場合の処理メカニズムは、インスタンスのデプロイメント構成によって異なります:
インスタンスが単一ゾーンに複数のレプリカノードを持つ場合、マスターノードに障害が発生すると、システムは自動的にフェールオーバーを実行します。システムは、レプリケーションのレイテンシが最も低いレプリカノードを新しいマスターノードとして選択し、ルーティング関係を更新します。
インスタンスが複数のゾーンにまたがってデプロイされている場合、マスターノードに障害が発生すると、システムは自動的にフェールオーバーを実行します。システムは別のゾーンのレプリカノードを新しいマスターノードとして選択し、ルーティング関係を更新します。ただし、これにより、インスタンスと他のサービスとの間でクロスゾーンアクセスが発生する可能性があります。
説明マルチゾーンクラスターアーキテクチャでのクロスゾーンアクセスを防ぐために、プライマリゾーンとセカンダリゾーンにレプリカノードが存在する場合、ワークロードは優先的にプライマリゾーンのレプリカノードに切り替えられます。
ゾーンレベルの障害への対応
停電や火災などのゾーンレベルの障害が発生すると、データセンター全体が利用できなくなります。処理メカニズムは、インスタンスのデプロイメント構成によって異なります:
インスタンスが単一ゾーンにデプロイされている場合、インスタンスは利用できなくなります。ゾーンが回復するのを待つ必要があります。この場合、過去のバックアップデータに基づいて別のゾーンにインスタンスを作成できます。
インスタンスが複数のゾーンにまたがってデプロイされている場合、自動スイッチオーバーがトリガーされます。
セキュリティの観点から、複数のゾーンを選択し、各ゾーンに複数のレプリカノードを作成してダウンタイムを最小限に抑えることができます。ただし、障害の確率、ビジネスデータの重要性、およびコストの間で選択する必要があります。
前述の原則は、Redis グローバル分散キャッシュのサブインスタンスにも適用されます。ただし、単一のサブインスタンスに障害が発生しても、他のサブインスタンスの可用性には影響しません。単一のサブインスタンスの障害によるデータ書き込みの失敗を防ぐために、Redis グローバル分散キャッシュのサブインスタンスを複数のゾーンにまたがってデプロイすることをお勧めします。