[翻訳] 検索とインデックス作成のワークロードを分離して OpenSearch クラスターのパフォーマンスを向上させる
本記事は OpenSearch Project Blog "Improve OpenSearch cluster performance by separating search and indexing workloads" の日本語訳です。
すべての OpenSearch インデックスはシャードで構成されており、インデックス内の各ドキュメントはシャードに格納されています。
従来、OpenSearch ではプライマリシャードとレプリカシャードの 2 種類のシャードが定義されています。プライマリシャードはインデックス作成と検索の両方の操作を処理し、レプリカシャードはプライマリシャードのデータのコピーを維持して冗長性を提供し、検索クエリに対応します。シャードの数はインデックス作成時に設定され、後から変更するにはリインデックスが必要です。
OpenSearch にセグメントレプリケーションとリモートストレージが導入されたことで、このモデルは進化しました。セグメントレプリケーションでは、プライマリシャードノードのみがインデックス作成操作を実行し、セグメントファイルをリモートオブジェクトストア（Amazon Simple Storage Service (Amazon S3)、Google Cloud Storage、Azure Blob Storage など）に書き込みます。レプリカシャードはオブジェクトストアからセグメントファイルを並行してダウンロードするため、各レプリカでインデックス作成操作を再実行する必要がなくなります。
新機能
インデックス作成と検索のワークロードを分離するために、新しいシャードロールを導入しました。
- 書き込みレプリカ：プライマリシャードの冗長コピー。プライマリシャードに障害が発生した場合、書き込みレプリカをプライマリに昇格させて書き込み可用性を維持できます。
- 検索レプリカ：検索クエリのみを処理し、プライマリに昇格することはできません。
インデックス作成と検索のワークロードをハードウェアレベルで分離するために、新しい検索ノードロールを導入しました。プライマリシャードと書き込みレプリカはデータロールを持つノードに割り当てることができますが、検索レプリカは検索ロールを持つノードにのみ割り当てられます。検索ロールを持つノードは、専用の検索処理ノードとして機能します。
以下の図は、2 つのコーディネーターノード、2 つのデータノード、2 つの検索ノードを持つ OpenSearch クラスターを示しており、インデックス作成フリートと検索フリートを形成しています。インデックスには 1 つのプライマリシャード、1 つの書き込みレプリカ、2 つの検索レプリカが含まれています。プライマリシャードと書き込みレプリカはデータノードに割り当てられ、検索レプリカは検索ノードに割り当てられています。各コンポーネントは以下のように構成されています。
- リモートストアはセグメントファイルとトランザクションログを保存します。書き込みレプリカと検索レプリカを含むすべてのレプリカは、リモートストアからセグメントをダウンロードします。
- プライマリシャードはセグメントとトランザクションログの両方をリモートストアに書き込みます。
- 書き込みレプリカは、プライマリが書き込みを完了した後にセグメントをダウンロードします。
- 検索レプリカは、新しいセグメントを継続的にリモートストアからポーリングします。
メリット
インデックス作成と検索のワークロードを分離することで、以下のメリットが得られます。
- 並列かつ分離された処理：インデックス作成と検索を分離することで、スループットと予測可能性が向上します。
- 独立したスケーラビリティ：データノードまたは検索ノードを追加することで、インデックス作成と検索を個別にスケールできます。
- 障害耐性：インデックス作成と検索の障害が分離され、可用性が向上します。
- コスト効率とパフォーマンス：インデックス作成にはコンピュート最適化、検索にはメモリ最適化など、特殊なハードウェアを使用できます。
- チューニングの柔軟性：バッファやキャッシュなどのパフォーマンス設定をインデックス作成と検索で個別に最適化できます。
- 障害の分離：インデックス作成と検索の問題が分離されるため、障害のトラブルシューティングが容易になります。
- スケーラブルな設計：インデックス作成と検索を互いに独立してスケールできます。
インデックス作成と検索の分離を有効にする
詳細な手順については、インデックスと検索のワークロードを分離するをご覧ください。
書き込みと読み取りの分離によるゼロスケールの達成：検索専用モード
書き込み一回・読み取り多数のシナリオ（ログ分析や凍結された時系列データなど）では、インデックス作成が完了した後にリソース使用量を削減できます。OpenSearch は現在、_scale API を通じて検索専用モードをサポートしており、プライマリシャードと書き込みレプリカを無効にして検索レプリカのみをアクティブにすることができます。
これにより、完全な検索機能を維持しながらストレージとコンピュートのコストを大幅に削減できます。以下のメリットがあります
- 書き込みが不要になった場合にインデックス作成キャパシティをスケールダウンできます。
- 不要な書き込みパスを削除することでディスクとメモリの容量を解放できます。
- _open/_close 操作によるインデックスライフサイクル制御とスムーズに連携します。
- 検索レプリカのみをアクティブにしてリソース使用量を削減できます。
- アクティブな検索パスでクラスターの正常性を GREEN に維持します。
- 手動介入なしで検索レプリカを自動復旧します。
- いつでもスケールアップしてインデックス作成を再開できます。
- 検索専用モード中に検索トラフィックに基づいて検索レプリカをスケールできます。
検索専用モードがアクティブな場合、プライマリと書き込みレプリカが無効になっていても、OpenSearch はクラスターの正常性を GREEN として維持します。これは、検索レプリカのみが割り当てられることが期待され、それらがすべて正常に割り当てられているためです。これにより、運用の安定性と完全な検索可用性が確保されます。
仕組み
_scale API が { "search_only": true } で呼び出されると、OpenSearch は以下の操作を実行します：
- インデックスに内部的な検索専用ブロックを追加します
- すべてのプライマリと書き込みレプリカをスケールダウンします
- 検索レプリカのみをアクティブに保ちます
インデックス作成を再開するには、{ "search_only": false } で _scale 操作を実行します。OpenSearch は元のインデックス状態を復元します。検索専用モードでも、期待されるすべての検索レプリカが割り当てられているため、クラスターの正常性は GREEN のままです。
ベンチマーク比較
OpenSearch Benchmark の http_logs ワークロードを使用して、3 つのクラスター構成でインデックス作成スループットとクエリレイテンシーをベンチマークしました。テストでは、最初にインデックス作成の 50% を実行し、その後インデックス作成と高負荷なマルチターム集計クエリを同時に実行しました。
クラスター構成
opensearch-cluster-cdk を使用して、AWS 上に 3 つの異なるクラスターをセットアップしました。以下の表は、使用された Amazon EC2 インスタンスタイプに基づくノードロールと関連コストを示しています。インスタンス価格は Amazon EC2 インスタンスタイプ から取得しています。
クラスター 1 (c1-r6g)：データノードにメモリ最適化インスタンスを使用した標準クラスター
| ノードロール | ノード数 | インスタンスタイプ | 時間あたりのコスト | 合計時間あたりのコスト |
|---|---|---|---|---|
| データ | 4 | r6g.xlarge | $0.20 | $0.81 |
| コーディネーター | 2 | r6g.xlarge | $0.20 | $0.40 |
| クラスターマネージャー | 3 | c6g.xlarge | $0.14 | $0.41 |
| $1.62 |
クラスター 2 (c2-c6g)：データノードにコンピュート最適化インスタンスを使用した標準クラスター
| ノードロール | ノード数 | インスタンスタイプ | 時間あたりのコスト | 合計時間あたりのコスト |
|---|---|---|---|---|
| データ | 4 | c6g.xlarge | $0.14 | $0.54 |
| コーディネーター | 2 | r6g.xlarge | $0.20 | $0.40 |
| クラスターマネージャー | 3 | c6g.xlarge | $0.14 | $0.41 |
| $1.36 |
クラスター 3 (c3-indexing-search)：データノードと検索ノードにコンピュート最適化とメモリ最適化インスタンスを使用したインデックス作成と検索を分離したクラスター
| ノードロール | ノード数 | インスタンスタイプ | 時間あたりのコスト | 合計時間あたりのコスト |
|---|---|---|---|---|
| データ | 2 | c6g.xlarge | $0.14 | $0.27 |
| 検索 | 2 | r6g.xlarge | $0.20 | $0.40 |
| コーディネーター | 2 | r6g.xlarge | $0.20 | $0.40 |
| クラスターマネージャー | 3 | c6g.xlarge | $0.14 | $0.41 |
| $1.49 |
結果の可視化
3 つのクラスター構成間のインデックス作成スループットとクエリレイテンシーの違いを示します。
以下のチャートは、3 つのクラスター構成間のインデックス作成スループットを比較しています。
以下のチャートは、ワークロードを分離することでクエリレイテンシーがどのように改善されるかを示しています。
結果は、クラスター 3 が同時インデックス作成と検索において他のクラスターをわずかに上回り、クエリレイテンシーを大幅に削減しながらコストを低減していることを示しています。
結果の指標と比較
以下の表は、各クラスターのベンチマーク結果の比較を提供しています。
クラスター 1 とクラスター 3 の比較
| クラスター 1 (5P, 3R) | クラスター 3 (5P, 1R, 1S) | 差異 | |
|---|---|---|---|
| インデックススループット 中央値 | 58523.95095 | 59818.80119 | 2.16462 |
| 最大 | 58777.10938 | 60240.02344 | 2.42848 |
| クエリレイテンシー p50 | 6725.72925 | 5358.19263 | -25.52235 |
| p90 | 7218.57544 | 5875.875 | -22.85107 |
| p99 | 8073.80762 | 6180.44385 | -30.63475 |
| p100 | 8575.49512 | 6312.8374 | -35.84217 |
| コスト/時間 | 1.62 | 1.49 | -8.72483 |
クラスター 2 とクラスター 3 の比較
| クラスター 2 (5P, 3R) | クラスター 3 (5P, 1R, 1S) | 差異 | |
|---|---|---|---|
| インデックススループット 中央値 | 58520.82413 | 59818.80119 | 2.16985 |
| 最大 | 59169.29297 | 60240.02344 | 1.77744 |
| クエリレイテンシー p50 | 6842.04297 | 5358.19263 | -27.69311 |
| p90 | 7708.91797 | 5875.875 | -31.19609 |
| p99 | 8328.41211 | 6180.44385 | -34.75427 |
| p100 | 8438.39258 | 6312.8374 | -33.67036 |
| コスト/時間 | 1.36 | 1.49 | 8.72483 |
結果のまとめ
これらの比較から、クラスター 3 は同時インデックス作成と検索ワークロードにおいてわずかに優れ（約 2% の改善）、クエリレイテンシーが大幅に低い（約 34% の改善）ことがわかります。これはクラスター 1 と比較して時間あたり約 8% 低いコストで達成されています。
結論
OpenSearch でインデックス作成と検索のワークロードを分離することで、クラスターのスケーリング、チューニング、最適化をより細かく制御できます。スループットを優先するか、レイテンシーを削減するか、コストを管理するかにかかわらず、このアプローチは現代のアプリケーションのニーズを満たすのに役立ちます。
今後の展望
現在、コーディネーターノードは検索とインデックス作成の両方のリクエストを処理しています。完全な分離のためには、インデックス作成と検索のトラフィックを異なるコーディネーターノードグループにルーティングすることを検討してください。
Discussion