リモートバックドストレージの一般提供開始をお知らせします。この新機能により、Amazon Simple Storage Service (Amazon S3)、Oracle Cloud Infrastructure Object Storage、Azure Blob Storage、Google Cloud Storage などのリモートストレージオプションを使用したリクエストレベルの耐久性が実現できます。この機能は OpenSearch 2.3 で実験的機能として導入され、OpenSearch 2.10 で一般提供となりました。この機能により、ユーザーはリカバリポイント目標 (RPO) をゼロにし、設定したリモートストアと同じ耐久性特性を活用できます。本記事では、アーキテクチャ、メリット、トレードオフ、および今後の機能強化について詳しく説明します。
概要
現在、OpenSearch クラスターにインデックスされたデータはローカルディスクに保存されます。データの耐久性、つまりインフラストラクチャ障害が発生した場合にインデックス操作が失われないようにするために、ユーザーはデータを保持して再取り込みするための複雑なメカニズムを構築しています。あるいは、リクエストレベルの耐久性を提供しないスナップショットに依存したり、追加のコンピューティングリソースを必要とするレプリカを追加したりしています。リモートバックドストレージは、ネイティブソリューションを提供することでこれらの課題に対処します。
アーキテクチャ
コアコンセプト
- Translog: トランザクションログ (translog) には、正常にインデックスされたがまだコミットされていないデータが含まれます。インデックス操作が成功するたびに translog にエントリが作成されます。これは先行書き込みトランザクションログです。
- セグメント: Lucene セグメントは、OpenSearch プロセスによって定期的にインデックス操作から作成されます。
リモートバックドストレージでは、ローカルディスクへのデータ保存に加えて、取り込まれたすべてのデータが設定されたリモートストアに保存されます。OpenSearch はコミット済みデータをセグメントとして保持し、未コミットデータは translog に追加されます。一貫性を確保するために、リモートストアへのデータ保存時にも同じセマンティクスが使用されます。ローカル translog のデータは、各インデックス操作でリモート translog ストアにバックアップされます。リフレッシュ/フラッシュ/マージの一部として新しいセグメントが作成されるたびに、新しいセグメントがリモートセグメントストアにアップロードされます。
設計上の考慮事項
- リポジトリプラグイン: 設定されたリモートストアとの対話には、既存のリポジトリインターフェースが使用されます。これにより、既存のリポジトリプラグイン実装 (Amazon S3、Azure Blob Storage、HDFS、Google Cloud Storage) をそのまま使用できます。
- セグメントレプリケーション: リモートバックドストレージはセグメントレプリケーションタイプのみをサポートしています。ドキュメントベースのレプリケーションでは、プライマリノードとレプリカノードでセグメントの物理的なビューが異なる場合があります。これにより、プライマリが変更されるたびにリモートストアを新しいプライマリノードのセグメントで更新する必要があるため、リモートストア統合のサポートが複雑になります。セグメントレプリケーションでは、プライマリとレプリカが同じ物理セグメントのセットを持つため、この問題は解決されます。
リモートストア統合の改善
- レプリケーションとリカバリの強化: リモートストアは、あるノードから別のノードへデータをコピーする他の OpenSearch フローでも使用できます。例えば、レプリカはレプリケーションとリカバリフロー中に設定されたリモートストアからセグメントをダウンロードします。これにより、プライマリノードがデータコピー操作から解放されます。
- 軽量スナップショット: リモートストアとスナップショットでのデータ重複を避けるために、軽量スナップショットのサポートを追加しました。有効にすると、軽量スナップショットはリモートストアに既にアップロードされているデータに対してチェックポイントを作成します。これにより、スナップショット操作に必要なリソース消費と時間が大幅に削減されます。
考慮事項
- レプリケーションラグ: 前述のとおり、リモートバックドストレージはセグメントレプリケーションのみをサポートしています。セグメントレプリケーションの使用に伴うほとんどのトレードオフは、リモートストレージとの統合によって解決されます。ただし、レプリケーションラグに敏感なワークロードは、リモートストレージを使用する前にユースケースのコンテキストで評価する必要がある場合があります。
- リモートストアの選択: データの耐久性は、設定されたリモートストアの耐久性特性に依存します。より高い耐久性を実現するには、データノードよりも高い耐久性を提供するストレージを選択する必要があります。
今後の予定
すべてのインデックスデータとクラスター状態がリモートストアに保存されることで、バックアップ目的以上のことが実現できます。今後の OpenSearch バージョンでは、以下の機能が追加される予定です。
- 検索可能なリモートインデックス: 検索可能なリモートインデックスは、データをローカルディスクに完全にコピーすることなく、リモートストア内のデータから検索クエリを処理します。詳細については、こちらの RFC を参照してください: https://github.com/opensearch-project/OpenSearch/issues/6528
- 書き込み可能なリモートインデックス: リモートインデックスを完全に機能させるには、検索のみのサポートでは不十分です。次のステップは、リモートインデックスへの書き込みをサポートすることです。詳細については、こちらの RFC を参照してください: https://github.com/opensearch-project/OpenSearch/issues/7804
- ポイントインタイムリストア: 現在、リモートバックドストレージ機能は、データの最新状態のリストアをサポートしています。ポイントインタイムリストア機能は、スナップショット相互運用性機能に依存しています。ただし、スナップショットは手動であるため、リストアの粒度はスナップショットの期間と同じになります。リモートストアにデータチェックポイントを追加することで、確定的で秒/分レベルの粒度を提供できます。
参考資料
OpenSearch Project(OSS) の Publicationです。 OpenSearch Tokyo User Group : meetup.com/opensearch-project-tokyo/
Discussion