ApsaraDB for Redisでは、読み取り負荷の高いワークロードを処理するための読み書き分離アーキテクチャが導入されています。 このアーキテクチャは、読み取り /書き込み分割サービスを提供する際に、高レベルの可用性、パフォーマンス、および柔軟性を提供します。 このアーキテクチャにより、多数のクライアントが読み取りレプリカからホットデータを同時に読み取ることができます。 さらに、読み書き分離インスタンスは、Alibaba Cloud Tairチームによって開発されたプロキシコンポーネントを使用して、データ配布やフェールオーバーなどのサービスを提供します。 これにより、O&Mコストが削減されます。
コンポーネント
読み書き分離インスタンスには、マスターノード、複数の読み取りレプリカ、複数のプロキシノード、および高可用性 (HA) システムが含まれます。
図 1. クラウドネイティブの読み書き分離アーキテクチャ 
図2. クラシック読み書き分離アーキテクチャ (廃止) 
コンポーネント | クラウドネイティブの読み書き分離アーキテクチャ (推奨) | 従来の読み書き分離アーキテクチャ |
マスターノード | マスターノードはすべての書き込み要求を処理します。 また、特定の読み取り要求を読み取りレプリカとともに処理します。 | |
レプリカの読み取り | 読み取りレプリカは読み取り要求を処理し、次の利点があります。
| 読み取りレプリカは読み取り要求を処理し、次の利点があります。
|
レプリカノード | レプリカノードは提供されません。 読み取りレプリカはレプリカノードとして使用されます。 マスターノードに障害が発生した場合、リクエストはランダム読み取りレプリカに切り替えられます。 クラウドネイティブの読み書き分離インスタンスは、レプリカノードがないため、同じ仕様の従来の読み書き分離インスタンスよりもコストが低くなります。 | レプリカノードは、データをバックアップするためのコールドスタンバイノードとして機能し、サービスを提供しません。 マスターノードに障害が発生した場合、リクエストはレプリカノードに切り替えられます。 |
プロキシノード | クライアントがプロキシノードに接続されると、プロキシノードは、クライアントによって開始された要求のタイプを自動的に識別し、次に、各データノードに割り当てられた所定の重みに基づいてトラフィックを分配する。 一般的な構成では、すべてのデータノードの重みは等しく、重みを変更することはできません。 たとえば、書き込み要求はマスターノードに転送され、読み取り要求はマスターノードと読み取りレプリカに転送されます。 説明
| |
HAシステム | HAシステムは, 各ノードの状態を監視します。 マスタノードに障害が発生した場合、HAシステムはマスタノードとレプリカノードの切り替えを実行します。 読み取りレプリカに障害が発生した場合、HAシステムは別の読み取りレプリカを作成して読み取り要求を処理します。 切り替え中に、HAシステムはルーティングと重みの情報を更新します。 | |
クラウドネイティブの読み書き分離アーキテクチャ (推奨) | 従来の読み書き分離アーキテクチャ |
プライマリゾーンとセカンダリゾーンの両方が、次の最小設定でサービスを提供します。
プライマリゾーンとセカンダリゾーンの両方で別々のエンドポイントを使用できます。 各エンドポイントは、読み取り操作と書き込み操作の両方をサポートします。 読み取り要求は、要求の発信元と同じゾーン内のプライマリノードまたは読み取りレプリカにルーティングされます。 これは、要求が地理的に最も近いノードによって処理されることを保証する。 書き込み要求は、常にプライマリゾーン内のプライマリノードにルーティングされます。 次の図はアーキテクチャを示しています。  説明 プライマリゾーンとセカンダリゾーンの両方に少なくとも2つのノードを設定することを推奨します。
| プライマリノードと読み取りレプリカの両方がプライマリゾーンにデプロイされます。 セカンダリゾーンにはレプリカノードのみがデプロイされます。 レプリカノードは、データをバックアップするためのコールドスタンバイノードとして機能し、サービスを提供しません。 マスターノードに障害が発生した場合、リクエストはレプリカノードに切り替えられます。 |
メリット
互換性
標準インスタンスを、プロキシノードを使用してリクエストを転送する読み書き分離インスタンスにアップグレードできます。 アップグレード後、アプリケーションを変更することなく、Redisクライアントからインスタンスに接続できます。 読み書き分離インスタンスは、Redisコマンドと完全に互換性があります。 読み書き分離インスタンスでサポートされるコマンドの制限については、「」「読み書き分離インスタンスでサポートされるコマンドの制限」をご参照ください。
HAシステム
Alibaba Cloudは、読み書き分離インスタンス用のHAシステムを開発しました。 HAシステムは、インスタンスのすべてのノードのステータスを監視して、HAを確保します。 マスターノードに障害が発生した場合、HAシステムはワークロードをマスターノードからレプリカノードに切り替え、インスタンストポロジを更新します。 リードレプリカに障害が発生した場合、HAシステムは別のリードレプリカを作成します。 HAシステムはデータを同期し、読み取り要求を新しい読み取りレプリカに転送し、障害のある読み取りレプリカを一時停止します。
プロキシノードは、各リードレプリカのステータスをリアルタイムで監視します。 例外のためにリードレプリカが使用できない場合、プロキシノードはこのリードレプリカの重みを減らします。 読み取りレプリカの接続が指定された回数失敗した場合、システムは読み取りレプリカを一時停止し、読み取り要求を使用可能な読み取りレプリカに転送します。 プロキシノードは、使用不可能なリードレプリカのステータスを引き続き監視します。 リードレプリカが回復した後、プロキシノードは使用可能なリードレプリカのリストに追加し、リクエストを転送します。
高パフォーマンス
読み書き分離アーキテクチャは、連鎖レプリケーションをサポートします。 これにより、読み取りレプリカをスケールアウトして読み取り容量を増やすことができます。 レプリケーションプロセスは、Redisソースコードに基づいて最適化され、レプリケーション中のワークロードの安定性を最大化し、各リードレプリカの物理リソースを最大限に活用します。
シナリオ
1秒あたりの高いクエリ数 (QPS)
ApsaraDB for Redisの標準アーキテクチャは、高QPSシナリオ用に設計されていません。 アプリケーションが読み取り負荷の高い場合は、読み書き分離インスタンスを選択し、複数の読み取りレプリカをデプロイして、単一ノード標準アーキテクチャによって引き起こされるパフォーマンスのボトルネックを解決できます。 読み書き分離インスタンスは、標準インスタンスの最大9倍のQPSを処理できます。
データがリードレプリカに同期されるときにレイテンシが存在します。 したがって、読み書き分離インスタンスは、特定の量のダーティデータを許容できるアプリケーションに適しています。 高いデータ一貫性が必要なシナリオでは、クラスターアーキテクチャを選択することを推奨します。
使用上の注意
リードレプリカが失敗した場合、リクエストは他の使用可能なリードレプリカに転送されます。 すべてのリードレプリカが使用できない場合、リクエストはマスターノードに転送されます。 レプリカの読み取りに失敗すると、マスターノードのワークロードが増加し、応答時間が長くなる可能性があります。 多数の読み取り要求を処理するには、複数の読み取りレプリカを使用することを推奨します。
リードレプリカでエラーが発生した場合、HAシステムはリードレプリカを一時停止し、別のリードレプリカを作成します。 このプロセスには、リソース割り当て、データ同期、およびサービスロードが含まれます。 切り替えに必要な時間は、システムのワークロードとデータ量によって異なります。 ApsaraDB for Redisは、リードレプリカを使用したデータ復元に必要な特定の時間を保証するものではありません。
リードレプリカ間の完全なデータ同期は、特定のシナリオでトリガーされます。 たとえば、マスターノードでスイッチオーバーが発生したときにトリガーできます。 完全データ同期中、リードレプリカは使用できません。 リクエストがリードレプリカに転送されると、次のエラーメッセージが返されます。
-LOADING Redis is loading the dataset in memory\r\n。ルーティング方法の詳細については、「」「プロキシノードの機能」をご参照ください。
購入方法
クラウドネイティブの標準インスタンスを作成した場合、そのインスタンスの読み書き分離機能を有効にできます。 詳細については、「読み書き分離の有効化」をご参照ください。