Amazon OpenSearch Service の内部構造 : OpenSearch Optimized Instances (OR1)

このブログは 2024 年 4 月 17 日に Bukhtawar Khan によって執筆された内容を翻訳したものです。原文はこちらを参照して下さい。

Amazon OpenSearch Service は最近、OpenSearch Optimized インスタンスファミリー (OR1) を導入しました。これは、内部ベンチマークで既存のメモリ最適化インスタンスと比較して最大 30% のコストパフォーマンスの向上を実現し、Amazon Simple Storage Service (Amazon S3) を使用して 99.9999999% (イレブンナイン) の耐久性を提供します。この新しいインスタンスファミリーにより、OpenSearch Service は OpenSearch のイノベーションと AWS のテクノロジーを使用して、クラウドでのデータのインデックス作成と保存方法を再考します。

今日、お客様は大量のデータを取り込みながら、豊富でインタラクティブな分析を提供する機能により、運用分析に OpenSearch Service を広く使用しています。これらの利点を実現するために、OpenSearch は、データのインデックス作成とリクエストの処理を行う複数の独立したインスタンスを持つ大規模な分散システムとして設計されています。運用分析データが生成される速度と量が増加するにつれ、ボトルネックが発生する可能性があります。高いインデックス作成ボリュームを持続的にサポートし、耐久性を提供するために、OR1 インスタンスファミリーが構築されました。

この投稿では、OR1 インスタンスの新しいデータフローがどのように機能するか、新しい物理レプリケーションプロトコルによって高いインデクシングスループットと耐久性をどのように実現しているのかについて説明します。また、正確性とデータの整合性を維持するために解決したいくつかの課題についても詳しく説明します。

高スループットとイレブンナインの耐久性のための設計

OpenSearch Service は数万の OpenSearch クラスターを管理しており、高スループットと耐久性の目標を達成するために、お客様が使用する典型的なクラスター構成についての洞察を得ています。より高いスループットを達成するために、お客様はレプリカコピーを削除することでレプリケーションのレイテンシーを節約することがよくありますが、この構成では可用性と耐久性が犠牲になります。他のお客様は高い耐久性を必要とするため、複数のレプリカコピーを維持する必要があり、その結果、運用コストが高くなります。

OpenSearch Optimized インスタンスファミリーは、Amazon S3 にデータのコピーを保存することで、コストを低く抑えながら更なる耐久性を提供します。OR1 インスタンスでは、インデックス作成のスループットを維持しながら、高い読み取り可用性のために複数のレプリカコピーを構成しながら、インデックス作成のスループットを維持できます。

次の図は、OR1 でのメタデータ更新を含むインデックス作成フローを示しています

インデクシングでは、個々のドキュメントは Lucene にインデックス付けされ、translog と呼ばれる先行書き込みログも追加されます。クライアントに確認応答を送り返す前に、すべての translog 操作は Amazon S3 でバックアップされたリモートデータストアに永続化されます。レプリカコピーが構成されている場合、プライマリコピーは正確性を保つためにすべてのレプリカコピーで複数のライターの可能性を検出するためのチェック (制御フロー) を実行します。

次の図は、OR1 インスタンスでのセグメント生成とレプリケーションのフローを示しています

新しいセグメントファイルが作成されるたびに、OR1 はそれらのセグメントを Amazon S3 にコピーします。転送が完了すると、プライマリは新しいセグメントがダウンロード可能になったことをすべてのレプリカコピーに通知する新しいチェックポイントを公開します。その後、レプリカコピーは新しいセグメントをダウンロードし、検索可能にします。このモデルは、Amazon S3 を使用して行われるデータフローと、ノード間トランスポート通信を介して行われる制御フロー (チェックポイントの公開と用語の検証) を分離します。

次の図は、OR1 インスタンスでのリカバリーフローを示しています

OR1 インスタンスは、データだけでなく、インデックスマッピング、テンプレート、設定などのクラスターメタデータも Amazon S3 に永続化します。これにより、非専用のクラスターマネージャーセットアップでは一般的な障害モードであるクラスターマネージャークォーラムの損失が発生した場合でも、OpenSearch が最後に確認されたメタデータを確実に回復できるようになります。

インフラストラクチャの障害が発生した場合、OpenSearch ドメインは 1 つ以上のノードを失う可能性があります。このような場合、新しいインスタンスファミリーは、最後に確認された操作までのクラスターメタデータとインデックスデータの両方の回復を保証します。交換される新しいノードがクラスターに参加すると、内部クラスターリカバリーメカニズムは新しいノードのセットをブートストラップし、リモートクラスターメタデータストアから最新のクラスターメタデータを回復します。クラスターメタデータが回復された後、リカバリーメカニズムは、Amazon S3 から不足しているセグメントデータと translog を復元し始めます。次に、最後に確認された操作までのすべての未コミットの translog 操作が再生され、失われたコピーが復元されます。

OR1 の新しい設計では、検索の仕組みは変更されません。クエリは、インデックス内の各シャードのプライマリまたはレプリカシャードのいずれかによって通常どおり処理されます。データのレプリケーションに Amazon S3 を使用しているため、特定の時点ですべてのコピーが一貫性を保つまでに長い遅延 (10 秒程度) が発生する可能性があります。
このアーキテクチャの主な利点は、リーダーとライターの分離、コンピューティングレイヤーとストレージレイヤーの分離など、将来のイノベーションの基礎となるビルディングブロックとして機能することです。

レプリケーション戦略を再定義することでインデックス作成のスループットが向上する仕組み

OpenSearch は、論理 (ドキュメント) レプリケーションと物理 (セグメント) レプリケーションの 2 つのレプリケーション戦略をサポートしています。論理レプリケーションの場合、データはすべてのコピーで個別にインデックス付けされるため、クラスターで冗長な計算が行われます。OR1 インスタンスは、データがプライマリコピーでのみインデックス付けされ、プライマリからデータをコピーすることで追加のコピーが作成される新しい物理レプリケーションモデルを使用します。レプリカコピーの数が多い場合、プライマリコピーをホストするノードは、セグメントをすべてのコピーにレプリケートするために大量のネットワーク帯域幅を必要とします。新しい OR1 インスタンスは、リモートストレージオプションとして構成されている Amazon S3 にセグメントを永続的に保存することで、この問題を解決します。また、プライマリでのボトルネックなしにレプリカのスケーリングにも役立ちます。

セグメントが Amazon S3 にアップロードされた後、プライマリは新しいセグメントをダウンロードするようにすべてのレプリカに通知するチェックポイントリクエストを送信します。その後、レプリカコピーは増分セグメントをダウンロードする必要があります。このプロセスにより、データを冗長にインデックス付けするために必要なレプリカのコンピューティングリソースと、プライマリでデータをレプリケートするために発生するネットワークオーバーヘッドが解放されるため、クラスターはより多くのスループットを処理できます。レプリカが過負荷や遅いネットワークパスなどにより新しく作成されたセグメントを処理できない場合、レプリカは古い結果を返さないように一定のポイントを超えて失敗としてマークされます。

高い耐久性が良い理由と、それを適切に行うのが難しい理由

コミットされたすべてのセグメントは、作成されるたびに Amazon S3 に永続的に保存されますが、高い耐久性を達成する上での主な課題の 1 つは、スループットを犠牲にすることなく、クライアントへ確認応答を返す前にすべての未コミットの操作を Amazon S3 の translog に同期的に書き込むことです。新しいセマンティクスでは、個々のリクエストに追加のネットワークレイテンシーが発生しますが、他のスレッドがインデックスのリクエストを続けながら、指定された間隔まで単一のスレッドでリクエストをバッチ処理してドレインすることで、スループットへの影響がないようにしました。その結果、バルクペイロードを最適にバッチ処理することで、より多くの同時クライアント接続でより高いスループットを実現できます。

高い耐久性のあるシステムを設計する上での他の課題には、常にデータの整合性と正確性を強制することが含まれます。ネットワークパーティションなどの一部のイベントはまれですが、システムの正確性を損なう可能性があるため、システムはこれらの障害に対処する準備ができている必要があります。したがって、新しいセグメントレプリケーションプロトコルに切り替える際に、各レプリカで複数のライターを検出するなど、いくつかの他のプロトコルの変更も導入しました。このプロトコルは、クラスターマネージャークォーラムに基づいて新しく昇格されたプライマリが同時に新しい書き込みを受け入れている間に、分離されたライターが書き込みリクエストに応答できないようにします。

新しいインスタンスファミリーは、データの回復中にプライマリシャードの損失を自動的に検出し、Amazon S3 からデータを再ハイドレートしてクラスターを正常な状態に戻す前に、ネットワークの到達可能性に関する広範なチェックを実行します。

データの整合性のために、すべてのファイルは広範にチェックサムされ、ネットワークまたはファイルシステムの破損によってデータが読み取り不能になる可能性を検出して防止できるようにします。さらに、メタデータを含むすべてのファイルは不変になるように設計されており、破損に対する更なる安全性を提供し、偶発的な変更を防ぐためにバージョン管理されています。

データフローの再構想

OR1 インスタンスは、インフラストラクチャ障害時に失われたシャードのリカバリを実行するために、Amazon S3 から直接コピーを復元します。Amazon S3 を使用することで、プライマリノードのネットワーク帯域幅、ディスクスループット、およびコンピュートを解放でき、プライマリノードの調整を最小限に抑えてプロセス全体を調整することで、よりシームレスなインプレーススケーリングとブルー/グリーンデプロイメントエクスペリエンスを提供できます。

OpenSearch Service は、スナップショットと呼ばれる自動データバックアップを 1 時間間隔で提供します。これは、データが誤って変更された場合に、以前の時点の状態に戻るオプションがあることを意味します。しかし、新しい OpenSearch インスタンスファミリーでは、データがすでに Amazon S3 に永続的に保存されていることを説明しました。では、データがすでに Amazon S3 に存在する場合、スナップショットはどのように機能するのでしょうか？

新しいインスタンスファミリーでは、スナップショットはチェックポイントとして機能し、ある時点で存在するセグメントデータを参照します。これにより、追加のデータを再アップロードする必要がないため、スナップショットはより軽量で高速になります。代わりに、その時点でのセグメントのビューを取得するメタデータファイルをアップロードします。これをシャロースナップショットと呼びます。シャロースナップショットの利点は、作成、削除、複製など、すべての操作に及びます。他の管理操作用に、手動スナップショットで独立したコピーをスナップショットするオプションもあります。

まとめ

OpenSearch はオープンソースのコミュニティ主導のソフトウェアです。レプリケーションモデル、リモートバックドストレージ、リモートクラスターメタデータなどの基本的な変更のほとんどは、オープンソースに貢献されています。事実、私たちはオープンソースファーストの開発モデルに従っています。

スループットと信頼性を向上させる取り組みは、学習と改善を続ける限り終わりのないサイクルです。新しい OpenSearh の最適化されたインスタンスは、将来のイノベーションへの道を開くビルディングブロックの基礎として機能します。私たちは信頼性とパフォーマンスの向上に向けた取り組みを継続し、新規および既存のソリューションビルダーが OpenSearch Service を使用して何を作成するかを楽しみにしています。本ブログにより、新しい OpenSearch インスタンスファミリーについての理解が深まり、このオファリングがどのように高い耐久性とより良いスループットを実現し、ビジネスのニーズに基づいてクラスターを構成するのに役立つかを理解できることを願っています。

OpenSearch への貢献に興味があれば、GitHub issue を開いてあなたの考えを教えてください。また、OpenSearch Service で高いスループットと耐久性を実現した成功事例についてもぜひお聞かせください。

著者について

Bukhtawar Khan は Amazon OpenSearch Service のプリンシパルエンジニアです。分散型および自律型システムの構築に興味を持っています。OpenSearch のメンテナーであり、アクティブなコントリビューターです。

Gaurav Bafna は Amazon Web Services で OpenSearch のシニアソフトウェアエンジニアです。分散システムの問題解決に興味を持っています。OpenSearch のメンテナーであり、アクティブなコントリビューターです。

Sachin Kale は AWS で OpenSearch のシニアソフトウェア開発エンジニアです。

Rohin Bhargava は Amazon OpenSearch Service チームのシニアプロダクトマネージャーです。AWS での情熱は、顧客がビジネス目標を達成するために適切な AWS サービスの組み合わせを見つけるのを助けることです。

Ranjith Ramachandra は、Amazon OpenSearch Service のシニアエンジニアリングマネージャーです。ハイスケーラブルな分散システム、高性能でレジリエントなシステムに情熱を注いでいます。