翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# サイジング
サイジングは、ターゲット環境に適したインスタンスタイプ、データノードの数、ストレージ要件を決定するのに役立ちます。最初にストレージのサイズを指定し、次に CPU のサイズを指定することをお勧めします。Elasticsearch または OpenSearch を既に使用している場合、通常はサイズを変更しません。ただし、現在の環境と同等のインスタンスタイプを特定する必要があります。適切なサイズを決定するには、次のガイドラインを使用することをお勧めします。
## Storage
クラスターのサイズ指定は、ストレージ要件の定義から始まります。クラスターに必要な raw ストレージを特定します。これは、ソースシステムによって生成されたデータ (ログを生成するサーバー、製品カタログの 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 により、データの GiB あたりのコストが大幅に削減されます。UltraWarm の詳細については、[AWS ドキュメント](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ultrawarm.html)を参照してください。
OpenSearch Service ドメインを作成してホットストレージを使用する場合は、EBS ボリュームサイズの定義が必要なことがあります。これはデータノードにどのインスタンスタイプを選択したかによって異なります。同じストレージ要件の式を使用して、Amazon EBS backed インスタンスのボリュームサイズを決定できます。最新世代の T3、R5、R6G、M5、M5g、C5、および C6g インスタンスファミリーには、gp3 ボリュームを使用することをお勧めします。Amazon EBS gp3 ボリュームを使用すると、ストレージ容量に関係なくパフォーマンスをプロビジョニングできます。Amazon EBS gp3 ボリュームではベースラインパフォーマンスも向上し、OpenSearch Service の既存の gp2 ボリュームよりも GB あたりのコストが 9.6% 低くなります。gp3 を使用すると、R5、R6g、M5、M6g インスタンスファミリーでより高密度なストレージも得られるため、コストをさらに最適化できます。EBS ボリュームはサポートされているクォータまで作成できます。クォータの詳細については、「[Amazon OpenSearch Service クォータ](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-limits.html)」を参照してください。
i3 インスタンスや r6gd インスタンスなどの NVM Express (NVMe) ドライブを持つデータノードの場合、ボリュームサイズは固定されているため、EBS ボリュームは選択できません。
## ノードの数とインスタンスタイプ
ノードの数は、ワークロードの運用に必要な CPU の数に基づきます。CPU の数はシャード数に基づきます。OpenSearch のインデックスは複数のシャードで構成されます。インデックスを作成するときに、インデックスのシャード数を指定します。そのため、以下のことを行う必要があります。
1. ドメインに保存するシャードの合計数を計算します。
1. CPU を決定します。
1. 最もコスト効率の高いノードのタイプと数を見つけたら、必要な CPU の数とストレージがわかります。
通常はこれが出発点となります。テストを実行して、見積もったサイズが機能要件と非機能要件を満たしていることを確認します。
## インデックス作成戦略とシャード数の決定
ストレージ要件がわかったら、必要なインデックスの数を決定し、それぞれのシャード数を特定できます。一般的に、検索ユースケースには 1 つまたはいくつかのインデックスがあり、それぞれが検索可能なエンティティまたはカタログを表します。ログ分析のユースケースでは、1 つのインデックスが毎日または毎週のログファイルを表す場合があります。インデックスの数を決定したら、次のスケールガイダンスを参考に、適切なシャード数を決定します。
+ 検索ユースケース – 10～30 GB/シャード
+ ログ分析ユースケース – 50 GB/シャード
1 つのインデックスのデータの総量を、ユースケースで目指すシャードサイズで割ることができます。これにより、インデックスのシャード数がわかります。シャードの合計数を特定すると、ワークロードに適したインスタンスタイプを見つけるのに役立ちます。シャードが大きすぎたり多すぎたりしないようにしてください。シャードが大きいと、OpenSearch の障害復旧が困難になる可能性があります。一方、各シャードはある程度の CPU とメモリを使用するため、小規模なシャードが多数ある場合には、パフォーマンスの問題やメモリ不足のエラーが発生する可能性があります。さらに、データノードへのシャード割り当てが不均衡だと、歪みが生じる可能性があります。複数のシャードを持つインデックスがある場合は、シャードがデータノード数の偶数倍になるように試みます。これは、シャードがデータノード全体に均等に分散されるようにするのに役立ち、ノードがホットになるのを防ぎます。例えば、プライマリシャードが 12 個ある場合、データノード数は 2、3、4、6、または 12 になります。ただし、シャード数よりもシャードサイズの方が重要です。5 GiB のデータがある場合、1 個のシャードを使用するべきです。レプリカシャードの数をアベイラビリティーゾーン間で均等に分散させると、耐障害性も向上します。
## CPU 使用率
次のステップでは、ワークロードに必要な CPU の数を特定します。CPU の数はアクティブなシャードの 1.5 倍から開始することをお勧めします。アクティブなシャードとは、大量の書き込みを受けているインデックスの任意のシャードです。プライマリシャード数を使用して、大量の読み取りまたは書き込みリクエストを受信しているインデックスのアクティブなシャードを決定します。ログ分析では、通常は現在のインデックスのみがアクティブです。検索ユースケースでは、すべてのプライマリシャードがアクティブなシャードと見なされます。アクティブなシャードあたり 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 以降の世代をお勧めします。前世代のインスタンスと比較して、パフォーマンスが向上し、コストが低くなるように構築されているためです。
ログ分析および検索ユースケースに関しては、それぞれに実行された各種テストに基づいて、以下をお勧めします。
+ ログ分析ユースケースの場合、一般的なガイドラインとして、データノードには R ファミリーの [Graviton](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/supported-instance-types.html) インスタンスから始めます。テストを実行し、要件のベンチマークを確立し、ワークロードに適したインスタンスサイズを特定することをお勧めします。
+ 検索ユースケースでは、ログ分析ユースケースよりも多くの CPU が必要になるため、データノードに R および C ファミリーの Graviton インスタンスを使用することをお勧めします。小規模なワークロードでは、検索とログの両方に M ファミリーの Graviton インスタンスを使用できます。I ファミリーインスタンスは NVMe ドライブを提供し、高速インデックス作成と低レイテンシーの検索を要件とするお客様が使用します。
クラスターは、データノードとクラスターマネージャーノードで構成されます。専用マスターノードでは検索およびクエリリクエストを処理しませんが、そのサイズは、管理可能なインスタンスサイズや、インスタンス数、インデックス数、シャード数と大きな相関があります。[AWS ドキュメントに記載されているマトリックス](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/managedomains-dedicatedmasternodes.html#dedicatedmasternodes-instance)で、推奨される最小限の専用クラスターマネージャーインスタンスのタイプがわかります。
AWS は、[AWS Graviton2 ](https://aws.amazon.com/ec2/graviton/)プロセッサを搭載した Amazon OpenSearch Service バージョン 7.9 以降向けに、汎用 (M6g)、コンピューティング最適化 (C6g)、メモリ最適化 (R6g および R6gd) を提供しています。これらのインスタンスは、Amazon によって設計されたカスタムシリコンを使用して構築されます。これらは、Amazon が設計したハードウェアおよびソフトウェアのイノベーションであり、分離されたマルチテナンシー、プライベートネットワーク、高速ローカルストレージを使用して、効率的で柔軟な、安全性の高いクラウドサービスを提供できます。
Graviton2 インスタンスファミリーは、OpenSearch Service (M5、C5、R5) で利用可能な前世代の Intel ベースのインスタンスと比較して、インデックス作成のレイテンシーを最大 50 % 削減し、クエリパフォーマンスを最大 30% 向上させます。