サイジング

サイジングは、ターゲット環境に適したインスタンスタイプ、データノードの数、ストレージ要件を決定するのに役立ちます。最初にストレージのサイズを指定し、次に CPUsのサイズを指定することをお勧めします。Elasticsearch または OpenSearch を既に使用している場合、サイズは通常変更されません。ただし、現在の環境と同等のインスタンスタイプを特定する必要があります。適切なサイズを決定するために、次のガイドラインを使用することをお勧めします。

[Storage (ストレージ)]

クラスターのサイズ設定は、ストレージ要件の定義から始まります。クラスターに必要な raw ストレージを特定します。これは、ソースシステム (ログを生成するサーバー、製品カタログの raw サイズなど) によって生成されたデータを評価することによって決まります。未加工データの量を特定したら、次の式を使用してストレージ要件を計算します。その後、結果を PoC の開始点として使用できます。

storage needed = (daily source data in bytes × 1.45) (number_of_replicas + 1) × number of days retained

この式では、以下が考慮されます。

• インデックスのディスク上のサイズはさまざまですが、多くの場合、ソースデータよりも 10% 大きくなります。

• オペレーティングシステムのオーバーヘッド 5% は、システム復旧とディスクのデフラグの問題から保護するために Linux によって予約されています。

• OpenSearch は、セグメントマージ、ログ、その他の内部オペレーションのために、各インスタンスのストレージスペースの 20% を予約します。

• ノード障害やアベイラビリティーゾーンの停止の影響を最小限に抑えるために、10% の追加ストレージを維持することをお勧めします。

これらのオーバーヘッドと予約を組み合わせると、ソース内の実際の raw データに基づいて 45% の追加領域が必要になります。そのため、ソースデータに 1.45 を掛けます。次に、これをデータのコピー数 (1 つのプライマリと使用するレプリカの数など) で乗算します。レプリカの数は、耐障害性とスループットの要件によって異なります。平均的なユースケースでは、1 つのプライマリと 1 つのレプリカから始めます。最後に、ホットストレージ階層にデータを保持する日数を掛けます。

Amazon OpenSearch Service は、ホット、ウォーム、コールドストレージ階層を提供します。ウォームストレージ階層は UltraWarm ストレージを使用します。UltraWarm は、大量の読み取り専用データをコストパフォーマンスに優れた方法で Amazon OpenSearch Service に保存できます。標準データノードは、インスタンスストアまたは各ノードにアタッチされた Amazon Elastic Block Store (Amazon EBS) ボリュームの形式をとるホットストレージを使用します。ホットストレージは、新しいデータのインデックス作成と検索において、可能な限り高速なパフォーマンスを提供します。UltraWarm ノードは、Amazon Simple Storage Service (Amazon S3) をストレージとして使用し、パフォーマンスを向上させるための高度なキャッシュソリューションとして使用します。アクティブに書き込んでいないインデックスやクエリの頻度が低く、パフォーマンス要件が同じでない場合、UltraWarm はデータ 1 GiB あたりのコストを大幅に削減します。UltraWarm の詳細については、AWS ドキュメントを参照してください。

OpenSearch Service ドメインを作成してホットストレージを使用する場合は、EBS ボリュームサイズを定義する必要があります。データノードのインスタンスタイプの選択によって異なります。同じストレージ要件式を使用して、Amazon EBS ベースのインスタンスのボリュームサイズを決定できます。最新世代の T3, R5, R6G, M5, M5g, C5 gp3 ボリュームを使用することをお勧めします。 C6g Amazon EBS gp3 ボリュームを使用すると、ストレージ容量に関係なくパフォーマンスをプロビジョニングできます。Amazon EBS gp3 ボリュームはベースラインパフォーマンスも向上し、OpenSearch Service の既存の gp2 ボリュームよりも GB あたりのコストが 9.6% 低くなります。gp3 を使用すると、R5, R6g, M5M6g インスタンスファミリーでより高密度なストレージも取得できるため、コストをさらに最適化できます。サポートされているクォータまで EBS ボリュームを作成できます。クォータの詳細については、「Amazon OpenSearch Service クォータ」を参照してください。

i3 インスタンスや r6gd インスタンスなど、NVM Express (NVMe) ドライブを持つデータノードの場合、ボリュームサイズは固定されているため、EBS ボリュームはオプションではありません。

ノードとインスタンスタイプの数

ノードの数は、ワークロードの運用に必要な CPUs の数に基づいています。CPUs の数はシャード数に基づきます。OpenSearch のインデックスは複数のシャードで構成されます。インデックスを作成するときは、インデックスのシャード数を指定します。したがって、以下を実行する必要があります。

1. ドメインに保存するシャードの合計数を計算します。

2. CPU を決定します。

3. 必要な数の CPUsと数を見つけます。

これは通常、出発点です。テストを実行して、見積りサイズが機能要件と非機能要件を満たしていることを確認します。

インデックス作成戦略とシャード数の決定

ストレージ要件がわかったら、必要なインデックスの数を決定し、それぞれのシャード数を特定できます。一般的に、検索ユースケースには 1 つまたはいくつかのインデックスがあり、それぞれが検索可能なエンティティまたはカタログを表します。ログ分析のユースケースでは、インデックスは毎日または毎週のログファイルを表すことができます。インデックスの数を決定したら、次のスケールガイダンスから始めて、適切なシャード数を決定します。

• 検索のユースケース – 10～30 GB/シャード

• ログ分析のユースケース – 50 GB/シャード

1 つのインデックスのデータの総量を、ユースケースで目指すシャードサイズで割ることができます。これにより、インデックスのシャード数がわかります。シャードの合計数を特定すると、ワークロードに適したインスタンスタイプを見つけるのに役立ちます。シャードは大きすぎたり、多すぎたりしないでください。シャードが大きいと、OpenSearch が障害から回復しにくくなりますが、各シャードがある程度の CPU とメモリを使用するため、シャードが小さすぎると、パフォーマンスの問題やout-of-memoryエラーが発生する可能性があります。さらに、データノードへのシャード割り当ての不均衡は、歪む可能性があります。複数のシャードを持つインデックスがある場合は、シャードがデータノード数の偶数倍になるように試みます。これは、シャードがデータノード全体に均等に分散されるようにするのに役立ち、ノードがホットになるのを防ぎます。例えば、プライマリシャードが 12 個ある場合、データノード数は 2、3、4、6、または 12 になります。ただし、シャード数よりもシャードサイズの方が重要です。5 GiB のデータがある場合、1 個のシャードを使用するべきです。レプリカシャードの数をアベイラビリティーゾーン間で均等に分散させると、耐障害性も向上します。

CPU 使用率

次のステップでは、ワークロードに必要な CPUsの数を特定します。アクティブなシャードの 1.5 倍の CPU 数から開始することをお勧めします。アクティブなシャードは、大量の書き込みを受信しているインデックスの任意のシャードです。プライマリシャード数を使用して、大量の読み取りまたは書き込みリクエストを受信しているインデックスのアクティブなシャードを決定します。ログ分析では、現在のインデックスのみが一般的にアクティブです。検索のユースケースでは、すべてのプライマリシャードがアクティブなシャードと見なされます。アクティブなシャードあたり 1.5 CPU をお勧めしますが、これはワークロードに大きく依存します。CPU 使用率をテストおよびモニタリングし、それに応じてスケーリングしてください。

CPU 使用率を維持するためのベストプラクティスは、OpenSearch サービスドメインにタスクを実行するのに十分なリソースがあることを確認することです。CPU 使用率が一貫して高いクラスターは、クラスターの安定性を低下させる可能性があります。クラスターが過負荷になると、OpenSearch Service は受信リクエストをブロックし、リクエストが拒否されます。これは、ドメインが失敗しないように保護するためです。CPU 使用率に関する一般的なガイドラインは、平均約 60%、最大 CPU 使用率 80% です。100% の時折の急増も許容され、スケーリングや再設定を必要としない場合があります。

インスタンスのタイプ

Amazon OpenSearch Service では、いくつかのインスタンスタイプを選択できます。ユースケースに最適なインスタンスタイプを選択できます。Amazon OpenSearch Service は、R、C、M、T、I インスタンスファミリーをサポートしています。インスタンスファミリーは、メモリ最適化、コンピューティング最適化、混合のワークロードに基づいて選択します。インスタンスファミリーを特定したら、最新世代のインスタンスタイプを選択します。一般的に、Graviton 以降の世代をお勧めします。前世代のインスタンスと比較して、パフォーマンスが向上し、コストが低くなるように構築されているためです。

ログ分析と検索のユースケースに対して実行されたさまざまなテストに基づいて、以下をお勧めします。

• ログ分析のユースケース の場合、一般的なガイドラインは、データノードの Graviton インスタンスの R ファミリーから始めることです。テストを実行し、要件のベンチマークを確立し、ワークロードに適したインスタンスサイズを特定することをお勧めします。

• 検索のユースケースでは、ログ分析のユースケースよりも多くの CPU が必要になるため、データノードに R および C ファミリーの Graviton インスタンスを使用することをお勧めします。小規模なワークロードでは、検索とログの両方に M ファミリーの Graviton インスタンスを使用できます。I ファミリーインスタンスは NVMe ドライブを提供し、高速インデックス作成と低レイテンシーの検索要件を持つお客様が使用します。

クラスターは、データノードとクラスターマネージャーノードで構成されます。専用マスターノードでは検索およびクエリリクエストを処理しませんが、そのサイズは、管理可能なインスタンスサイズや、インスタンス数、インデックス数、シャード数と大きな相関があります。AWS ドキュメントには、最小の専用クラスターマネージャーインスタンスタイプを推奨するマトリックスが用意されています。

AWS は、AWS Graviton2 プロセッサを搭載した Amazon OpenSearch Service バージョン 7.9 以降向けに、汎用 (M6g)、コンピューティング最適化 (C6g)、メモリ最適化 (R6g および R6gd) を提供しています。これらのインスタンスは、Amazon によって設計されたカスタムシリコンを使用して構築されます。これらは、Amazon が設計したハードウェアおよびソフトウェアのイノベーションであり、分離されたマルチテナンシー、プライベートネットワーク、高速ローカルストレージを使用して、効率的、柔軟、安全なクラウドサービスを提供できます。

Graviton2 インスタンスファミリーは、OpenSearch Service (M5、C5, R5クエリパフォーマンスを最大 30% 向上させます。