小規模な Amazon Elasticsearch Service ドメインのコストを削減する

Amazon Elasticsearch Service (Amazon ES) ドメインをデプロイして本番環境のワークロードをサポートする場合、使用するデータインスタンスのタイプと数、アベイラビリティーゾーンの数、専用マスターインスタンスを使用するかどうかを選択する必要があります。ベストプラクティスのための推奨事項をすべて実行するには、次のように設定する必要があります。

3 つの専用マスターインスタンス M5.large
3 つの M5.large データノードを備えた 3 ゾーンレプリケーション
プライマリに 2 つのレプリカの使用
必要に応じたストレージ、最大 512 GB、データノード用の GP2 Amazon Elastic Block Store (EBS) ボリューム

この設定の場合、最大 400 GB のソースデータと 1 秒あたり数十万のリクエストを、1 か月あたり最大 800 USD (米国東部、バージニア北部の料金) のオンデマンドコストでサポートします。実行可能なデプロイを最小限に抑えることで、このコストを削減できます。本番ワークロードで実行可能な最小のデプロイは、次のとおりです。

専用マスターインスタンスなし
M5.large ノードを備えた 2 ゾーンレプリケーション
プイマリに 1 つのレプリカの使用
必要に応じたストレージ、最大 512 GB、データノード用の GP2 EBS ボリューム

このデプロイでは、同じ 400 GB のソースデータと 1 秒あたり同じ数十万のリクエストを、月額 350 USD というはるかに低いオンデマンドコストでサポートします。すなわち、コストが 81％削減します。最大よりも小さな 512 GB EBS ボリュームをデプロイする場合、それに比例して Amazon EBS のコスト要素を月額 207 USD 削減できます。

AWS では、Amazon ES の本番ワークロードに T2 インスタンスを推奨していません。

この投稿では、ROI について、そしてドメインの可用性低下の可能性を軽減する方法に関するベストプラクティスについて説明します。

リザーブドインスタンス

コストを削減するには、すべてのベストプラクティスに従いながら、Amazon ES ドメインのリザーブドインスタンスを購入するのが最も良い方法です。前払いのない 1 年契約だと、ベストプラクティスでかかるドメインのコストを月額 630 USD に削減し、コストを 21％削減できます。3年間前払い契約では、10,746 USD の前払いと月額 207 USD で、月額 505 USD 分の料金または 37％のコスト削減になります。

料金のシナリオの詳細については、AWS 料金見積もりツールをご確認ください。

ベストプラクティスと可用性

以下は、サイジング、専用マスターインスタンス、マルチ AZ 配置に関するベストプラクティスです。

プライマリシャードがログ分析ワークロードの場合は 50 GB 未満、検索ワークロードの場合は 30 GB 未満になるようにシャード数を設定します (常にテストして、最大スループットと最小エラーに実際に最適なシャードサイズを決定してください)。
vCPU = 1.5 *アクティブシャードとなるよう、インスタンスタイプを選択する
3 つのアベイラビリティーゾーンにデプロイする
インデックスに 2 つのレプリカを使用する
3 つ以上のデータノードを使用し、3 つの専用マスターノードを使用する

これらのベストプラクティスで、最も可用性の高いデプロイを実行できます。詳細については、「Get started with Amazon Elasticsearch Service: T-shirt-size your domain」、「Get Started with Amazon Elasticsearch Service: Use Dedicated Master Instances to Improve Cluster Stability」、「Increase availability for Amazon Elasticsearch Service by deploying in three Availability Zones」をご参照ください。

次のセクションの推奨事項を実行することで、データの損失やクラスターの利用不能という潜在的なリスクにさらされることになります。そのため、ROI とダウンタイムおよびリカバリのコストを比較検討する必要があります。

レプリカの削減

インデックスの各レプリカは、プライマリシャードのストレージと同じものを追加します。インデックスのプライマリシャードが 1 TB のデータを保持している場合、最初のレプリカではストレージ容量が 2 TB に倍増します。2 つ目のレプリカは 3 TB、つまり 3 倍になります。レプリカの数を 1 つに減らして、データノードとストレージの最小要件を削除すると、ストレージにかかるコストが 33％削減します。

レプリカを 1 つに減らし、単一のデータノードが使用できなくなった場合、クラスターにデータのコピーが保持され、Elasticsearch をリカバリできます。Elasticsearch はプライマリーとは異なるデータノードに、レプリカのシャードをデプロイします。データノードが利用できなくなった場合、レプリカはデータがクラスターから失われていないことを確認します。レプリカを 1 つに減らすと、必要な最小データノードも 2 つ (1 つはプライマリ用、もう 1 つはレプリカ用) に削減されます。

レプリカを 1 つに減らし、クラスター内の複数のデータノードが使用できなくなると、それらのインスタンスにデプロイするシャードのプライマリコピーとレプリカコピーの両方が失われるリスクがあります。これが起こった場合、クラスターの状態が赤で表示されます。インデックスをリカバリするには、そのデータをリロードする必要があります。

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

3 ゾーンのデプロイ、3 つのデータノード、2 つのレプリカで、1 つまたは 2 つのアベイラビリティーゾーンが利用できなくなった場合、データを保護します。デプロイを 2 つのアベイラビリティーゾーンに減らすと、最小データノード数を 2 つに、レプリカを 1 つに減らすことができます。この設定で、複数のアベイラビリティーゾーンが利用できなくなると、データを失うリスクがあります。

この推奨事項は、ノード数を 3 つ未満に減らすことができる小さなドメインに適用できます。より大きなワークロードの場合、1 つのレプリカで 3 つのゾーンを実行する方が合理的です。最小インスタンス数がすでに 3 つで、合計シャード数が 3 つより大きい場合にはメリットがあります。Amazon ES は、3 つのゾーンにノードとシャードを分散します。各ゾーンには、1/3 のノードと 1/3 のシャードがあります。

極端に低い数では、単一のアベイラビリティーゾーン、単一のデータノードは使用できますが、レプリカは使用できません。ただし、そのアベイラビリティーゾーンが利用できなくなった場合、ドメイン全体が失われるリスクがあります。これでは、本番で利用する意味がありません。

専用マスターノードの削除

専用マスターノードは、Amazon ES ドメインに安定性と可用性を備えます。これらでクラスターの状態を保持し、その状態をクラスター内のすべてのノードにブロードキャストします。専用マスターノードは、リクエスト自体を処理しません。

専用マスターはシングルスレッドです。適格なインスタンスから 1 つのインスタンスが単一のクラスターマスターとして選ばれます。マスターの選択を行うには、クラスターにクォーラム、つまり適格なインスタンスの半分 (切り捨て、プラス 1) が必要です。クラスターに適格なインスタンスが 3 つある場合、クォーラムは 2 つです。クラスターに適格なインスタンスが 2 つある場合、クォーラムも 2 つです。

専用マスターノードを使用しない場合、データノードが適格なマスターノードです。2 つのデータノードのクラスターから 1 つのノードが失われると、マスターを選択するクォーラム (2 つ) がないため、そのクラスターは書き込みの許可を停止します。専用マスターノードが 2 つ以上ある場合、ノードの損失に耐えられる可能性が高くなります。

データノードの読み込みは通常、インデックス作成と検索のリクエストを処理するためのものであり、そのためマスターノードとしては最適ではありません。それらの可用性は、ワークロードの要求に大きく左右されます。専用マスターノードを使用しない場合、クラスターに書き込みできない、またはクラスターの機能が低下するリスクが高まります。

Elasticsearch 6x と 7x での専用マスターの損失

Elasticsearch マスターノードは、Elasticsearch バージョン 7 とそれ以降で動作が異なります。Elasticsearch バージョン 6 およびそれ以前でクラスターの機能を継続させるには、クォーラムが必要です。Elasticsearch バージョン 6 およびそれ以前で単一の専用マスターノードを失うと、クラスターは 100％の時間で書き込みブロックされます。バージョン 7 では、選択したクラスターマスターがクォーラムを続行する必要はありませんが、新しいマスターを選択するにはクォーラムが必要です。バージョン 7 以降では 2 つの専用マスターノードがあるため、クラスターマスターを失うとクラスターは書き込みブロックされます。他のマスターを失っても、これは起こりません。この場合、50％の確率で使用できなくなります。

リスクの軽減

コストの削減で、データの損失やクラスターの利用不能といったリスクが高まります。こうしたリスクを慎重に検討し、可能な場合はリカバリ時間を最小限に抑えるための手順を実行する必要があります。

これらの対策を講じる前に、クラスターが利用できない場合にどうなるかを評価してください。1 時間以上 Amazon ES にクエリできない状態を避けたい場合、これらのコスト削減に関する推奨事項は採用しないでください。

取り込み側で、できるだけ早く新しいクラスターを全く最初から再作成することを検討してください。このユースケースでは、より小さなデータセットとクラスターを扱っているため、ソースデータをかなり迅速にリロードすることが可能です。ただし、ソースデータをリロードするには、Amazon ES 以外の場所にソースデータを保存する必要があります。Amazon S3 バケット内のすべてのソースデータを、Elasticsearch _bulk リクエストとして管理できます。リロードするには、スクリプトを準備して、そのバケットをウォークしデータに取り込みます。

Amazon S3 のようなプライマリストアがない場合、_snapshot APIで取得した自己管理スナップショットを利用できます。詳細については、「Use Amazon S3 to Store a Single Amazon Elasticsearch Service Index」をご参照ください。スナップショットの欠点は、最後の実行可能なスナップショットの後に取り込んだデータを失うことです。その期間中のデータを失いたくない場合は、ドメインを再作成する間、更新を保存または保持する方法を考える必要があります。取り込みインフラストラクチャが Amazon S3 にバッチを送信している場合、それらを再度取り込めます。取り込みインフラストラクチャに Amazon Kinesis Data Streams または Amazon Managed Streaming for Kafka が含まれている場合、更新をもう一度読み込み、リロードできます。

自動でのサービス管理スナップショットは、同じドメインにしか取り込めないため、適していません。ドメインが利用できない場合は、自動スナップショットを使用できます。

まとめ

シャード数とインスタンス数を減らし、専用マスターインスタンスを削除することで、Amazon ES の小規模なデプロイにかかるコストを削減できます。しかし各手順では、ドメインを使用できないリスクが増大します。この投稿では、トレードオフと、コストを最大 81％削減できるリスク軽減戦略のいくつかを取り上げました。

著者について

Jon Handler (@_searchgeek) は、カリフォルニア州パロアルトに拠点を置くアマゾンウェブサービスのプリンシパルソリューションアーキテクトです。Jon は、CloudSearch および Elasticsearch のチームと緊密に連携し、AWS クラウドへの移行を希望する検索ワークロードを抱えている顧客を幅広く支援し、指導しています。AWS に入社する前、Jon はソフトウェア開発者として 4 年間、大規模な e コマース検索エンジンのコーディングに携わっていました。

Amazon Web Services ブログ