OpenSearchクラスタ・パフォーマンス・サイズによる検索

OpenSearchクラスタの容量のサイズ設定と決定のプロセスには、コストとパフォーマンスのバランスが必要です。パフォーマンスとサイズ決定の両方に影響を与える要因がいくつかあるため、容量計画プロセスを微調整するために、これらの側面に関するデータを収集することが不可欠です。

これらの要因は、ユースケース固有、データ関連、およびリソース関連の考慮事項のカテゴリにグループ化できます。

• ユースケース固有: これらの要素は、OpenSearchデプロイメントの目的です。たとえば、クラスタはログ分析または可観測性に使用されていますか。これには通常、読取りと比較して大量の書込みが伴いますか。または、データが一度書き込まれて何度も読み取られるアプリケーション検索に使用されていますか。または、クラスタはリソース集約型の機械学習ワークロードをサポートすることを意図していますか。ユース・ケースを理解すると、必要な読取りおよび書込みレイテンシとスループット、問合せパターン、および最適化が必要な問合せのタイプ(フィルタ、集計、基本検索など)を判断するのに役立ちます。
• データ関連: このファクタには、格納するデータの量、データ型(構造化または非構造化)、ドキュメント・サイズ、カーディナリティ、フィールド・タイプ、およびフィールド・マッピングが定義されているかどうかが含まれます。また、使用中の圧縮コーデック、および索引、シャードおよびレプリカのサイズと数はすべて、クラスタ全体のサイズとパフォーマンスに寄与します。
• リソース関連: これらの要因には、クラスタ・マネージャ・ノード、データ・ノード、ダッシュボード・ノードなど、クラスタ内のノードの構成および数が含まれます。これらのリソースは、定義されたワークロードを処理し、最高のパフォーマンスを確保するクラスタの能力に直接影響します。

キャパシティ・プランニングは最初は圧倒的なように思えますが、実験して問題に段階的に対処すると、管理しやすくなります。重要なのは、確立されたベスト・プラクティスに基づいて最初の見積りから開始し、キー・パフォーマンス・インジケータ(KPI)が満たされているかどうかを継続的に評価し、コストとパフォーマンスの理想的なバランスがとれるまで繰り返すことです。次のステップでは、キャパシティ・プランニング・プロセスの概要を示します。

1. 必要な記憶域サイズの見積り。
2. シャーディング戦略を定義します。
3. データ・ノード構成の見積り。
4. クラスタ・マネージャ・ノード構成の見積り。
5. ダッシュボード・ノード構成の見積り。
6. クラスタをテストして反復します。

この項では、現実的なクラスタ・サイズ設定の演習で説明した原則を適用できます。OpenSearchクラスタ内の複数の索引にまたがるデータを1日当たり10 GBのレートで取り込むログ分析のユースケースがあるとします。目標は、データを最大90日間保持し、その後安全に破棄できるようにすることです。

データ取込みは、ユース・ケースに応じて、バッチまたは連続のいずれかになります。多くのアプリケーション検索およびビジネス・インテリジェンス・シナリオでは、バッチ・プロセス中にデータが一括でロードされ、フィルタリング、集計、検索などの様々な操作について問い合せられます。これらのタイプの索引は存続期間が長いとみなされ、通常、ソース・データを分析することによってストレージ要件を推定できます。これは、頻繁に変更されない傾向があります。

ログ分析、時系列分析、実際のユーザー監視など、その他のユース・ケースでは、データは継続的にクラスタに取り込まれ、特定のサイズまたは時間しきい値に達した後にインデックスがロールオーバーされます。このようなタイプの索引では、特定の期間に収集されたデータの量を計算し、必要な保存期間を掛けてストレージ要件を見積もることが不可欠です。

収集されるデータの合計ボリュームに加え、その他のいくつかの要因が、必要なストレージの量に影響します。

• 保存期間(r): クラスタにデータが保持される期間によって、特定の時点で格納されるデータの最大量が決まります。この図は、最大量のデータが存在する最悪のシナリオを処理するためのクラスタの容量を見積もるのに役立ち、ピーク・ストレージ条件下でも理想的なパフォーマンスを実現します。
• レプリカ数(rc): 各レプリカはプライマリ・シャードの正確なコピーであり、信頼性とパフォーマンスの両方の目的に役立ちます。データ損失を防ぐため、すべての索引のデフォルト設定であるレプリカを少なくとも1つ使用することをお薦めします。ユースケースに大量の読取りボリュームが含まれている場合は、複数のレプリカを構成すると効果的です。これにより、複数のレプリカ・シャードで同時検索問合せを処理できるため、負荷が分散され、問合せのパフォーマンスが向上します。
• 圧縮率(cr): ディスクに格納されたデータは、収集されるRAWデータ・ボリュームと同一ではありません。かわりに、索引付けプロセス中に圧縮が適用されたため、通常は小さくなります。OpenSearchは、様々な圧縮コーデックをサポートしており、それぞれが圧縮率とパフォーマンスとの間で異なるトレードオフを提供します。索引の作成時に、ユース・ケースに最も適したコーデックを選択できます。

  達成される圧縮率は、データのタイプ(構造化および非構造化)、繰返しまたは空のフィールド値の数、データ・カーディナリティ、データ全体のサイズなど、いくつかの要因によって異なります。通常、圧縮の妥当な開始仮定は25%から40%の間です。たとえば、10 GBのRAWデータは、ディスク上の6 GB(cr=1.67)から7.5 GB(cr=1.33)の間を占めます。ただし、この仮定を、特定のユース・ケースの実際のテストで検証することは重要です。

• OpenSearch索引付けオーバーヘッド(o1): OpenSearchでは、RAWデータの索引付けに最大10%のストレージ・オーバーヘッドが発生します。索引付け後、/_cat/indices?v APIをpri.store.size値とともに使用して、実際の正確な値を計算できます。
• OpenSearchサービス・オーバーヘッド(o2): OpenSearchは、セグメントのマージ、ログおよびその他の内部操作のために、各インスタンスのストレージ領域の最大20%を20 GBまで予約します。
• オペレーティング・システム・オーバーヘッド(o3): デフォルトでは、Linuxはrootユーザーにファイル・システムの5%を予約して、ロギングや一時ファイル作成などの重要なシステム・プロセスがディスクがほぼいっぱいになったときに引き続き機能するようにします。この予約領域は、システム・リカバリにも役立ち、ディスクの断片化を防ぐため、操作の中断を回避します。
• エラー・マージン(b)に対応するバッファ: 索引の定義後にシャード数を変更できないため、ヒューマン・エラーとオプティミスティックな仮定を考慮して5から10%のバッファを追加することをお薦めします。このバッファは、後で実際の使用状況データを収集するときに調整または削除できます。
• 算式:

  Required Storage = Source Data * r * (1 + rc) * (1/cr) * (1 + o1) * (1/1-o2) * (1/1-o3) * (1+b)

  この式を例の演習に適用すると、次のようになります。

  • ソース・データ= 1日あたり10 GB
  • r = 90、90日の保存期間を考慮
  • rc = 1、1レプリカが必要であることを考慮
  • cr = 1.33、25%の圧縮率を達成することを考慮
  • o1 = 0.1 (索引付けのオーバーヘッドが10%)
  • o2 = 0.2 (20%のサービス・オーバーヘッド)
  • o3 = 0.05 (オペレーティング・システムのオーバーヘッドが5%)
  • b = 0.1 (10%エラーマージンバッファ)
  • 必要なストレージ= 10 * 90 * 2 * 0.75 * 1.1 * 1/0.8 * 1/0.95 * 1.1 = 2150 GB = 2.2 TB (丸め)

ストレージ要件を設定した後、次のステップはシャーディング戦略を定義することです。これには、シャードのサイズ、数および分布の決定が含まれます。OpenSearchシャードは、索引データの独立したパーティションであり、高いパフォーマンスとフォルト・トレランスを確保するためにクラスタ・ノード間でデータを分散するように設計されています。

シャードには、プライマリとレプリカの2つのタイプがあります。プライマリ・シャードは、データ・パーティションの認可コピーであり、読取り操作と書込み操作の両方を処理します。一方、レプリカ・シャードはプライマリ・シャードの正確なコピーであり、読取り操作にのみ使用されます。すべての書込みリクエストは、最初にプライマリ・シャードに送信され、その後、データがレプリカ・シャードにレプリケートされます。

OpenSearchは、プライマリ・シャードとレプリカ・シャードの両方をノードに自動的に割り当てて、プライマリ・シャードが可能なかぎり均等に分散され、プライマリ・シャードとレプリカ・シャードが同じノードに配置されないようにします。たとえば、プライマリ・シャードが3つ、レプリカ・シャードが1つある索引では、合計シャードが6つ(プライマリ・シャードが3つ、レプリカ・シャードが3つ)になります。この構成では、各書込みリクエストは2つのシャード(1つのプライマリ・レプリカと1つのレプリカ)によって処理され、読取りリクエストはプライマリ・シャードとレプリカ・シャードを任意に組み合せて処理できるため、冗長性とロード・バランシングが可能になります。

ストレージ要件を決定し、シャードのサイズと数を決定したら、ハードウェアの決定を開始できます。ハードウェアの要件はワークロードによって異なりますが、一般的な推奨事項をいくつか示します。

クラスタの安定性とパフォーマンスを向上させるには、専用のクラスタ・マネージャ・ノードを使用することをお薦めします。これらのノードは、重要な管理タスクをデータノードからオフロードするため、データストレージとクエリ処理のみに集中できます。クラスタ・マネージャ・ノードはデータを格納したり、データ・アップロード・リクエストを処理しません。かわりに、クラスタの全体的なヘルスおよび状態を管理します。クラスタ内のすべてのノードを追跡し、索引の数を監視し、各索引のシャード分散を監視します。

マネージャ・ノードは、ルーティング情報を保守し、変更中にクラスタ状態を更新し(索引の作成やノードの追加/削除など)、すべてのノード間で状態更新をレプリケートします。また、ハートビート信号を送信して、データノードの健全性と可用性を監視し、クラスタが動作していることを確認します。

信頼性を最大限に高めるために、少なくとも3つのクラスタ・マネージャ・ノードを使用することをお薦めします。1つのマネージャ・ノードのみを持つと、そのノードに障害が発生した場合にクラスタが使用できなくなる可能性があるため、リスクがあります。また、偶数のマネージャ・ノードを使用することは、クラスタが障害発生時に新しいマネージャを選択するために必要な定足数を形成するのを防ぐため理想的ではありません。3つのマネージャ・ノードは、障害発生時に2つのバックアップ・ノードを提供し、新しいマネージャを選択するための定足数を確保します。

マネージャ・ノードの数を奇数増分(5、7など)で増やすと、フォルト・トレランスが向上するため、クラスタは稼働中にマネージャ・ノードの障害に耐えることができます。ただし、3つ以上のマネージャ・ノードの追加は過剰であり、徹底的な分析後の非常に大規模なクラスタまたは特別なユース・ケースにのみ考慮する必要があります。

専用のクラスタ・マネージャ・ノードは検索および問合せリクエストを処理しませんが、リソース要件は、管理する必要のあるデータ・ノード、索引およびシャードの数と密接に関連しています。次のガイドラインを開始点として使用できます。

• 4 vCPUおよび8 GBメモリー: 最大16
• 8 vCPUおよび16 GBメモリー: 17から32
• 8 vCPUおよび32 GBメモリー: 33から64
• 16 vCPUおよび64 GBメモリー: 65から128

この演習では、データ・ノードが5つあるため、3つのクラスタ・マネージャ・ノードをそれぞれ4つのvCPUと8 GBのメモリーで作成することから開始できます。

ダッシュボード・ノードは、データをローカルで直接索引付けまたは検索せず、記憶域要件が最小限であるため、最もサイズ設定しやすいノード・タイプです。これらのノードは、主にAPIサーバーとして機能し、クラスタへのリクエストを発行し、データI/Oを処理します。ダッシュボード・ノードに必要な主なリソースはCPUおよびメモリーで、これは同時ダッシュボード・リクエストの数によって異なります。

1つのダッシュボード・ノードを小規模または本番クラスタで使用することは一般的ですが、高可用性(HA) OpenSearchダッシュボード・アプリケーションでは、少なくとも2つのノードを使用することをお薦めします。HAのニーズに応じて、1つまたは2つのダッシュボード・ノードをデプロイすることをお薦めします。低スループットのシナリオでは、ノード当たり4 vCPUsおよび8 GBのメモリーを割り当て、高スループットのシナリオでは、ノード当たり8 vCPUsおよび16 GBのメモリーを割り当てます。デプロイメント後、CPU使用率およびJVM圧力を監視して、実際のパフォーマンスに基づいてリソースを微調整します。

ログ分析アプリケーションは主に、根本原因の分析、デバッグ、および時折のレビューとレポートのために限られた数の専門家によって使用されているため、8 vCPUsおよび16 GBのメモリーを備えた単一のダッシュボード・ノードから開始できます。その後、この初期構成の使用パターンおよびパフォーマンスに基づいて、リソースをスケール・アップまたはスケール・ダウンして調整できます。

次のテストを実行し、必要に応じて構成を調整します。

• 本番と同様のテスト・データの使用: テスト・データが、クラスタに収集される本番データを厳密にミラー化していることを確認します。これには、ドキュメント(フィールド、データ型など)の構造と、そのサイズと本番で使用されるものとの照合が含まれます。
• リアルワールド・ロードのシミュレート: 実際の条件でパフォーマンス・テストを実行します。最初に、予想される負荷をシミュレートする小さいクラスタを作成し、その結果を推定して、より大きなクラスタのパフォーマンスを見積ります。負荷を正確に反映するには、テスト・データの量がかなり(GB単位)である必要があります。
• 主要なメトリックの監視と分析: CPU使用率、JVM負荷、ディスク使用率、検索と索引付けのレイテンシ、検索と索引付けの速度、全体的な可用性などの重要なメトリックを継続的に監視します。必要なKPIを満たすように、必要に応じてクラスタ構成を調整します。
• 本番環境での継続的な監視: 本番クラスタを継続的に監視することが不可欠です。これらのKPIを定期的にチェックし、パフォーマンスが予想されるしきい値から逸脱した場合は是正措置を講じます。稼働開始前の1回限りのテストだけでは不十分です。継続的な検証は、最高のパフォーマンスを維持するために重要です。

OpenSearchクラスタのサイズ設定には、パフォーマンスとコストのバランスをとり、ユースケース、データ量、リソース割当てなどの要因を考慮する慎重なアプローチが必要です。このトピックでは、キャパシティ・プランニングの開始に役立つ主要なガイダンス、ベスト・プラクティスおよびサム・ルールについて説明します。構造化されたプロセスを追跡し、パフォーマンス・テストに基づいて反復することで、クラスタが効率性とスケーラビリティの両方に最適化されていることを確認できます。実際の負荷に応じた定期的な監視と変化は、ピーク・パフォーマンスを維持するために不可欠です。最適なクラスタ構成は、特定のワークロードおよび使用パターンからインサイトを収集するにつれて進化します。