OpenSearch Service ドメインの使用コストを削減するにはどうすればよいですか?

所要時間1分
0

ドメインの可用性に影響を与えずに Amazon OpenSearch Service ドメインを使用するコストを削減したいと考えています。

解決方法

リザーブドインスタンスを使用する

コストを削減しながらベストプラクティスに従うには、OpenSearch Service ドメイン用のリザーブドインスタンスを購入してください。リザーブドインスタンスを購入すると、同じインスタンスタイプを使用する OpenSearch Service ドメインは、ドメインを変更することなく請求割引を受けることができます。

詳細については、AWS 料金計算ツールAmazon OpenSearch Service に関するよくある質問と回答を参照してください。

最新世代のインスタンスタイプと gp3 Amazon EBS ボリュームを使用する

OpenSearch Service には最新の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスタイプが採用されており、より低コストで優れたパフォーマンスを実現します。負荷には最新世代のインスタンスタイプを使用するのがベストプラクティスです。大きいインスタンスタイプを使用している場合は、小さいインスタンスタイプにスケールダウンしてください。負荷テストを実行し、使用状況とパフォーマンスの要件に基づいてインスタンスタイプを選択します。詳細については、「オンデマンドインスタンスの料金」を参照してください。

**注:**インスタンスタイプを変更すると、OpenSearch Service はブルー/グリーンデプロイメントを使用します。詳細については、「Amazon OpenSearch Service の設定変更」を参照してください。

OpenSearch Service のデータノードでは、高速なインデックス作成とクエリを実現するために、低レイテンシーかつ高スループットのストレージが必要です。Amazon Elastic Block Store (Amazon EBS) の gp3 ボリュームを使用すると、gp2 ボリュームタイプよりも低コストで高いベースラインパフォーマンスを得ることができます。gp3 ボリュームタイプは、バーストクレジットを使用しないため、より安定しています。gp3 ボリュームを使用すると、ボリュームサイズに関係なく追加の IPOS とスループットをプロビジョニングできます。また、gp3 ボリュームタイプでは、gp2 ボリュームタイプのデータノードあたりのボリュームサイズ制限が 2 倍になります。このようにボリュームが大きくなると、データノードあたりのストレージ量が増え、パッシブデータのコストが削減されます。

ウルトラウォームストレージとコールドストレージを使用する

OpenSearch Service をログ分析に使用する場合は、データを UltraWarm またはコールドストレージに移動してストレージコストを削減してください。インデックスステート管理 (ISM) を使用して、ストレージ階層間でデータを移行し、データ保持を管理します。

UltraWarm はストレージに Amazon Simple Storage Service (Amazon S3) を使用するためデータは不変であり、保存する必要があるのは1つのコピーだけです。お支払いいただくのは、インデックス内のプライマリシャードのサイズに相当するストレージに対してのみです。OpenSearch Service で UltraWarm を使用する方法の詳細については、「Amazon OpenSearch Service 用のUltraWarm ストレージ」を参照してください。

コールドストレージは Amazon S3 でもバックアップされます。コールドデータをクエリする必要がある場合は、既存のUltraWarm ノードにアタッチできます。コールドデータには UltraWarm と同じ管理ストレージコストがかかりますが、コールドストレージ内のオブジェクトは UltraWarm ノードリソースを消費しません。コールドストレージは、UltraWarm ノードのサイズや数に影響を与えることなく、大量のストレージ容量を提供します。

UltraWarmは、ホットストレージに約 2.5 TiB のデータがある場合に費用対効果が高くなります。フィルレートを監視し、そのデータ量に達する前にインデックスを UltraWarm に移行してください。

**注:**OpenSearch サービスは UltraWarm ストレージノードのリザーブドインスタンスをサポートしていません。

可用性についてのベストプラクティスに従う

サイジング、専用プライマリインスタンス、マルチ AZ 配置のベストプラクティスを確認して実装してください。

レプリカの削減

**重要:**以下のセクションのベストプラクティスに従うと、データ損失やクラスターが使用できなくなるリスクにさらされる可能性があります。

インデックス内のすべてのレプリカは、プライマリシャードのストレージと同じストレージを追加します。たとえば、インデックスのプライマリシャードに 1 TB のデータが保存されている場合、最初のレプリカはストレージを 2 TB に倍増します。2 つ目のレプリカでは、3 倍の 3 TB になります。レプリカの数を 1 つに減らすことで、データノードとストレージの最小要件が減り、ストレージコストも削減されます。詳細については、「小規模な Amazon Elasticsearch Service ドメインのコスト削減」と「レプリカの削減」セクションを参照してください。

アベイラビリティゾーンの削減

3 つのデータノードと 2 つのレプリカを持つ 3 ゾーンのデプロイを使用している場合があります。この設定により、1 つまたは 2 つのアベイラビリティーゾーン (AZ) が使用できなくなった場合でもデータが保護されます。デプロイを 2 つのアベイラビリティーゾーンに減らすと、最小データノード数を 2 つに、レプリカを 1 つに減らすことができます。ただし、複数のアベイラビリティーゾーンが使用できなくなると、データが失われる危険があります。これは、ノード数を 3 つ未満に減らすことができる小規模なドメインに当てはまります。大規模なワークロードの詳細とベストプラクティスについては、「小規模な Amazon Elasticsearch Service ドメインのコスト削減」と「アベイラビリティゾーンの削減」セクションを参照してください。

専用プライマリノードを削除

専用プライマリノードは、OpenSearch Service ドメインの安定性と可用性を提供します。クラスターの状態を保持し、その状態をクラスター内のすべてのノードにブロードキャストします。それ自体でリクエストを処理することはありません。

データノードが適格なプライマリノードになるように、専用のプライマリノードを使用しないことを選択できます。ベストプラクティスの設定の詳細については、「小規模な Amazon Elasticsearch Service ドメインのコスト削減」と「専用プライマリノードの削除」セクションを参照してください。

関連情報

Amazon OpenSearch Service クラスターの設定を変更するとどうなりますか?

AWS公式
AWS公式更新しました 10ヶ月前