クラスター間レプリケーション (CCR) は、リーダー クラスターから 1 つ以上のフォロワー クラスターにインデックスデータをほぼリアルタイムでレプリケーションします。これにより、リモートディザスタリカバリ、読み書き分離、地理的に分散したアクセスが可能になります。このトピックでは、Elasticsearch の一般的なディザスタリカバリソリューションを比較し、CCR の仕組みを説明して、適切なソリューションを選択するのに役立てます。
ソリューションの比較
Elasticsearch (ES) は、次のリモートディザスタリカバリソリューションをサポートしています。
OSS スナップショット:インデックスデータを Alibaba Cloud Object Storage Service (OSS) にバックアップして永続ストレージに保存します。最初のスナップショットは完全バックアップで、後続のスナップショットは増分です。クラスター間 OSS リポジトリを使用して、スナップショットデータを送信先 ES インスタンスに復元できます。詳細については、「クラスター間 OSS リポジトリの設定」をご参照ください。
Logstash:パイプラインを設定して、ソース ES クラスターからデータを読み取り、処理して、送信先クラスターに書き込みます。このソリューションは、メジャーバージョン間のデータ移行や、データフィルタリングと変換が必要なシナリオに適しています。詳細については、「クイックスタート」をご参照ください。
Reindex:組み込みの Reindex API を使用して、すべてのデータまたは特定の条件を満たすデータをあるインデックスから別のインデックスにコピーします。このソリューションはクラスター間の操作をサポートしており、小規模なデータセットの 1 回限りの移行に適しています。詳細については、「Reindex API を使用したデータ移行」をご参照ください。
クラスター間レプリケーション (CCR):書き込み可能なインデックスをリーダー クラスターから 1 つ以上のフォロワー クラスターに非同期かつ増分的にレプリケーションします。このソリューションはほぼリアルタイムの同期をサポートしており、低い目標復旧時点 (RPO) と目標復旧時間 (RTO) が求められるディザスタリカバリのシナリオに最適です。
ソリューションの比較
ソリューション | 利用シーン | RPO | 復旧時間目標 | 主な制限事項 |
OSS スナップショット | 大規模データ (GB から PB) の定期的なバックアップと復元。 | 数時間から数日 (スナップショットの間隔に依存)。 | 数時間 (データ量とシャードの回復時間に依存)。 | 継続的な同期をサポートしていません。回復中にサービスの停止時間が必要になる場合があります。 |
Logstash | リアルタイム要件が低いデータ移行、データフィルタリングや変換が必要なシナリオ、メジャーバージョン間の移行。 | 数秒から数分 (同期の頻度に依存)。 | 数時間 (データ量とインスタンスのパフォーマンスに依存)。 | バッチ同期のみで、リアルタイムではありません。削除操作の同期はサポートしていません。 |
Reindex | 小規模なデータセットの 1 回限りのインデックス移行。 | 適用外 (1 回限りの操作)。 | 数分から数時間 (データ量に依存)。 | 継続的な同期をサポートしていません。大規模なデータ移行には非効率です。 |
CCR | リモートディザスタリカバリ、読み書き分離、地理的に分散したアクセス。 | ほぼゼロ (秒)。 | 数秒から数分。 | フォロワーインデックスは読み取り専用です。マッピングとシャード数が同一である必要があります。 |
低い RPO と低レイテンシが求められるリモートディザスタリカバリのシナリオでは、CCR が最良の選択です。
CCR は数秒でデータを同期するため、データ損失を最小限に抑えます。
リーダー クラスターに障害が発生した場合、スナップショットの復元を待たずに、トラフィックをフォロワー クラスターにリダイレクトしてサービスを復旧できます。
初期のデプロイコストは高くなりますが、CCR はデータ損失によるビジネス上の損失を防ぐことで、長期的にはより費用対効果が高くなります。
仕組み
アーキテクチャ
CCR はアクティブ/パッシブアーキテクチャを使用します。リーダー クラスターがすべての書き込み操作を受け取り、フォロワー クラスターは読み取り専用で、リーダー クラスターからデータをレプリケーションします。
リーダー クラスター:すべての書き込み操作を処理するソースクラスター。
フォロワー クラスター:読み取り専用で、CCR を使用してリーダー クラスターからデータを同期する送信先クラスター。
データレプリケーションのプロセス
CCR のデータレプリケーションプロセスは、2 つのフェーズで構成されます。
初期化
フォロワー クラスターは、リーダー クラスターに初期化リクエストを送信します。その後、リーダー クラスターは、スナップショットリストアの仕組みと同様に、リーダーインデックスからフォロワーインデックスにすべての Lucene セグメントファイルを転送します。
増分同期
フォロワーインデックスの各シャードは、定期的にリーダー クラスターにプルリクエストを送信し、最後の同期ポイント以降の最新の操作をフェッチします。デフォルトでは、これは 1 秒ごとに発生します。プロセスは次のとおりです。
プル開始点の特定:フォロワー クラスターは、ローカルで正常に適用された最新の操作を示すローカルの
remote_checkpointを維持します。このチェックポイントは、リーダー クラスターのトランザクションログ (translog) のglobal_checkpointに対応します。リーダーの translog から操作を読み取る:リーダー クラスターは、フォロワー クラスターから提供された
from_seq_noを使用して、自身の translog 内の開始位置を見つけます。その後、後続のすべての操作 (インデックス、更新、削除) を読み取り、リストとして返します。フォロワー クラスターで操作をリプレイする:フォロワー クラスターは、これらの操作をローカルで順番にリプレイし、自身の
remote_checkpointを更新します。バージョンの競合などが原因でリプレイが失敗した場合、同期は一時停止され、エラーがログに記録されます。継続的なポーリング:フォロワー クラスターは、固定の間隔で新しい操作を継続的にポーリングし、通常はサブ秒レベルのレイテンシを実現します。
translog の役割
トランザクションログ (translog) は、CCR における増分同期のデータソースです。Elasticsearch では、次の目的を果たします。
データ損失の防止:デフォルトでは、Elasticsearch は 1 秒ごとにリフレッシュを実行し、インメモリバッファから検索可能な新しい Lucene セグメントを作成します。ただし、このセグメントはまだディスクにフラッシュされていません。translog はすべての書き込み操作を記録します。ノードがクラッシュした場合、ログをリプレイすることでデータを回復できます。
レプリカの一貫性の確保:Elasticsearch は、まず操作を translog に書き込み、次にそれをレプリカシャードに転送します。プライマリシャードとレプリカシャードの両方が書き込みを確認した後にのみ、成功の応答を返します。
CCR での増分同期のサポート:CCR は、Elasticsearch の内部 API を使用して translog を読み取り、指定されたシーケンス番号以降のすべての変更をフェッチします。これにより、ほぼリアルタイムのデータレプリケーションが可能になります。
translog はシャードごとに個別に保存されます。各シャードには、indices/{index_uuid}/{shard_id}/translog/ に独自の translog ディレクトリがあります。Translog ファイル (.tlog) はバイナリ形式で保存され、世代管理の仕組みを使用して管理されます。Elasticsearch は、フラッシュが発生するたび、またはファイルがサイズ制限 (デフォルトでは 512 MB) に達するたびに、新しい世代ファイルを作成します。
Alibaba Cloud ES のための CCR ネットワーク
Alibaba Cloud Elasticsearch インスタンスは、お客様の VPC ではなく、専用の管理 VPC にデプロイされます。2 つのクラスターが同じリージョンにある場合や、それらの VPC が CEN を使用してリージョン間で接続されている場合でも、プライベートネットワークを介して直接通信することはできません。NLB と PrivateLink を使用して管理 VPC を接続する必要があります。
2 つのクラスターが同じリージョンにあるかどうかに基づいて、適切なドキュメントを選択してください。
シナリオ | 説明 | ドキュメント |
同じリージョン | リーダー クラスターとフォロワー クラスターが同じリージョンにあります。NLB と PrivateLink を使用して、それらの管理 VPC を接続します。 | |
リージョン間 | リーダー クラスターとフォロワー クラスターが異なるリージョンにあります。まず CEN を使用してお客様の VPC を接続し、次に NLB と PrivateLink を使用してそれらの管理 VPC を接続する必要があります。 |
制限事項
両方のクラスターの管理デプロイモードは、クラウドネイティブ新管理 (v3) である必要があります。クラスターが v1 または v2 アーキテクチャの場合、まずそのアーキテクチャをアップグレードする必要があります。詳細については、「インスタンスアーキテクチャのアップグレード」をご参照ください。
Elasticsearch クラスターのアーキテクチャバージョンを確認するには、Elasticsearch コンソールにログインします。インスタンスの 基本情報 ページで、デプロイコントロールモード を表示します。モードは クラウドネイティブの新しいコントロール (v3) または 基本コントロール (v2) のいずれかです。
両方のクラスターは Elasticsearch 7.10.0 以降を実行している必要があります。フォロワー クラスターのバージョンは、リーダー クラスターのバージョンと同じか、それ以降である必要があります。
フォロワーインデックスは読み取り専用であり、書き込み操作をサポートしていません。ターゲットインデックスを書き込み可能にするには、次の操作を実行します。
フォロータスクを一時停止する:
POST /<index>/_ccr/pause_followインデックスを閉じる:
POST /<index>/_closeインデックスのフォローを解除する:
POST /<index>/_ccr/unfollowインデックスを再度開いて読み書き可能にする:
POST /<index>/_open
リーダーインデックスとフォロワーインデックスは、マッピングとシャード数が同一である必要があります。フォロワーインデックスのシャード数を変更することはできません。