Amazon Elasticsearch Service ドメインを設定するベストプラクティス

Amazon Elasticsearch Service (Amazon ES) は、AWS クラウドで Elasticsearch クラスターのデプロイ、保護、スケール、監視を簡単に行うことができる完全マネージド型サービスです。Elasticsearch は分散型データベースソリューションであり、計画や実行が困難な場合があります。この記事では、Amazon ES ドメインをデプロイするためのベストプラクティスについていくつか説明します。

最も重要なプラクティスは、繰り返し調整を行うことです。これらのベストプラクティスに従えば、基本レベルの Amazon ES のデプロイを計画できます。Elasticsearch はワークロードごとに異なる動作をします。レイテンシーとスループットは、主にリクエストの組み合わせ、リクエスト自体、実行するデータまたはクエリによって大部分が決定されます。ワークロードがどのように動作するかを 100％予測できる確定的なルールはありません。デプロイの調整と改善、ドメインの動作の監視を行い、状況に応じて調整するための時間を計画に入れてください。

Amazon ES のデプロイ

AWS マネジメントコンソール、AWS CloudFormation、Amazon ES API のいずれにデプロイする場合でも、ドメインのハードウェア、高可用性、セキュリティ機能に合わせた設定をするための豊富なオプションがあります。この記事では、データノードと専用マスターノードの構成を選択するためのベストプラクティスについて説明します。

Amazon ES ドメインを設定する際は、インスタンスタイプとデータおよび専用マスターノードの数を選択します。Elasticsearch は、インスタンスまたはノードのクラスターで実行される分散型データベースです。これらのノードタイプは異なる機能を備えているため、別々のサイズ設定が必要です。データノードはインデックスにデータを格納し、インデックス作成とクエリのリクエストを処理します。専用マスターノードはこれらのリクエストを処理しません。クラスターの状態維持と調整を行います。この記事はインスタンスタイプに焦点を当てています。データノードインスタンスのサイジングの詳細については、「Amazon Elasticsearch Service の使用を開始する: T シャツサイズのドメイン」を参照してください。専用マスターノードインスタンスのサイジングの詳細については、「Amazon Elasticsearch Service の使用を開始する: Use Dedicated Master Instances to Improve Cluster Stability」を参照してください。

Amazon ES は、M、R、I、C、T の 5 つのインスタンスクラスをサポートしています。ベストプラクティスとしては、各インスタンスクラスの最新世代のインスタンスタイプを使用します。この記事の執筆時点では、M5、R5、I3、C5、T2 がそれに該当します。

データノードのインスタンスタイプを選択する

データノードのインスタンスタイプを選択するときは、これらのノードがインデックス (ストレージ) 内のすべてのデータを保持し、リクエスト (CPU) の全処理を実行するよう留意してください。ベストプラクティスとしては、負荷のかかる本番ワークロードの場合、R5 か I3 インスタンスタイプを選択してください。主としてパフォーマンスを重視する場合は通常 R5 を選択します。ログ分析ワークロードや、よくあるケースでは検索ワークロードで最高のパフォーマンスを提供します。他の有力な候補としては I3 インスタンスがあります。こちらがワークロードにより適している可能性もあるため、両方をテストする必要があります。コストを重視する場合、I3 インスタンスは、特にリザーブドインスタンスを購入した際のコスト効率が大幅に改善されます。

エントリーレベルのインスタンスまたはより小さなワークロードの場合は、M5 を選択します。C5 は、ディスクやネットワークよりも CPU の作業が多量に必要とされる、クエリの多いユースケースに適した特化型インスタンスです。T2 インスタンスは開発または QA ワークロードに使用しますが、本番環境では使用しません。選択するインスタンス数と、データ処理フットプリントのより詳しい分析については、「Amazon Elasticsearch Service の使用を開始する: T シャツサイズのドメイン」を参照してください。

専用マスターノードのインスタンスタイプを選択する

専用マスターノードのインスタンスタイプを選択する際は、これらのノードは主に CPU バウンドで、RAM とネットワークも必要となることに留意してください。C5 インスタンスは、最大で約 75 個のデータノードクラスターの専用マスターとして最適に動作します。そのノード数より多い場合は、R5 を選択する必要があります。

アベイラビリティーゾーンの選択

Amazon ES を利用すると、ゾーン認識機能を使用して、クラスターの可用性を簡単に向上させることができます。データとマスターノードのデプロイ先は、1 つ、2 つ、または 3 つのアベイラビリティーゾーンを選択できます。ベストプラクティスとしては、本番環境のデプロイには 3 つのアベイラビリティーゾーンを選択してください。

複数のアベイラビリティーゾーンを選択すると、Amazon ES はゾーン全体にデータノードを均等にデプロイし、レプリカが確実に異なるゾーンに入るようにします。さらに、複数のアベイラビリティーゾーンを選択すると、Amazon ES は常に 3 つのゾーンに専用マスターノードをデプロイします (リージョンが 3 つのゾーンをサポートしている場合)。複数のアベイラビリティーゾーンにデプロイすれば、ドメインの安定性を高め、可用性を向上させることができます。

Elasticsearch インデックスとシャード設計

Amazon ES を使用する場合は、クラスターのインデックスにデータを送信します。インデックスは、リレーショナルデータベースのテーブルに似ています。検索ドキュメントは行、JSON フィールドは列と同様に考えられます。

Amazon ES は、デフォルトでランダムハッシュを使用して、データをシャードにパーティション分割します。シャード数を設定するため、このセクションのベストプラクティスを使用する必要があります。

インデックスパターン

ログ分析のユースケースでは、クラスター内のデータのライフサイクルを制御する必要があります。これはローリングインデックスパターンで実行できます。毎日新しいインデックスを作成してから、クラスター内の最も古いインデックスをアーカイブして削除します。分析のニーズに応じて、ドメインに何日分のデータを (いくつのインデックスを) 保持するかを制御する保持期間を定義します。詳細については、「Index State Management」を参照してください。

シャード数を設定する

シャードには、プライマリとレプリカの 2 種類があります。プライマリシャード数は、Elasticsearch が作成するデータのパーティション数を定義します。レプリカ数は、作成するプライマリシャードの追加のコピー数を指定します。プライマリシャード数はインデックス作成時に設定します。変更はできません (方法はありますが、負荷の大きいクラスターに _shrink または _split API を使用することは推奨しません)。レプリカ数はインデックス作成時に設定できますが、その場で変更することもできます。それに応じて Elasticsearch がレプリカを作成または削除して調整します。

「POST」コマンドを使用して手動でインデックスを作成する場合は、プライマリとレプリカのシャード数を設定できます。ログ分析の方法として優れているのは、インデックスのテンプレートを設定することです。次のコードを参照してください。

PUT _template/<template_name>
{
    "index_patterns": ["logs-*"],
    "settings": {
        "number_of_shards": 10,
        "number_of_replicas": 1
    },
    "mappings": {
        …
    }
}

テンプレートをこのように設定すると、index_pattern に一致するすべてのインデックスに、そのインデックスに対応した設定とマッピング (指定した場合) が適用されます。ローリングインデックスのシャード戦略を管理するにはこの方法が便利です。テンプレートを変更すると、次のインデックス作成サイクルで新しいシャード数を取得できます。

ソースデータのサイズに基づき number_of_shards を設定する必要があります。プライマリシャード数 = (1 日のソースデータのバイト数 * 1.25) / 50 GB が目安です。

ローリングインデックスを使用しない検索のユースケースでは、30 GB のシャードをターゲットにするため、除数を 30 GB とします。ただし、これは目安に過ぎません。常にご自身のデータ、インデックス、クエリを使用してテストし、最適なシャードサイズを見つけてください。

シャードがノード間で均等に分配されるように、シャードとインスタンスの数を調整してみてください。割り切れる数で均等になるよう、シャード数またはデータノード数を調整します。たとえば、Elasticsearch バージョン 6 およびそれ以前のデフォルト設定は、プライマリシャード 5 つとレプリカ 1 つとなっています (合計 10 シャード)。2 個、5 個、または 10 個のデータノードを選択すると、均等に分配することができます。ワークロードをデータノードに均等に分配することは重要ですが、すべてのインデックスをいつも均等にデプロイできるわけではありません。シャードサイズをシャード数の最初の目安として使用し、微調整 (<20％) を行います。一般的には、均等に分配することを基本として、インスタンス数を増やすか、シャード数を減らすことが望ましいとされています。

ストレージサイズの決定

ここまでは、必要なストレージに基づいてシャード数をマッピングしてきました。次に、リクエストを処理するための十分なストレージと CPU リソースがあることを確認する必要があります。まず、全体的に必要なストレージ容量を確認します。必要なストレージ = (1 日のソースデータのバイト数 * 1.25) * (number_of_replicas + 1) * 保持日数で計算します。

レプリケートされていないインデックスのサイズにレプリカ数と保持日数を掛けて、必要なストレージ容量の合計を決定します。各レプリカは、プライマリストレージのサイズと等しい容量のストレージを必要量として追加します。クラスターにデータを保持する日は、毎回これを再度追加します。検索のユースケースでは、保持の日数を 1 に設定します。

ストレージに必要な総容量により、インスタンスが提供する最大ストレージに基づいて、インスタンスタイプとインスタンスでの最小容量が決まります。M5 や R5 などの EBS ベースのインスタンスを使用している場合は、サポートされている上限まで EBS ボリュームをデプロイできます。詳細については、「Amazon Elasticsearch Service の制限」を参照してください。

エフェメラルストアのあるインスタンスの場合、ストレージはインスタンスタイプによって制限されます (たとえば、I3.8xlarge.elasticsearch には 7.8 TB のストレージがアタッチされています)。EBS を選択する場合は、汎用の GP2 ボリュームタイプを使用する必要があります。このサービスは io1 ボリュームタイプとプロビジョンド IOPS をサポートしていますが、一般的には不要です。プロビジョンド IOPS は、メトリクスがサポートする特別な状況でのみ使用してください。

必要なストレージの総容量を取得し、選択したインスタンスタイプのインスタンスごとの最大ストレージ容量で割り、最小インスタンス数を取得します。

インスタンスタイプと数を取得したら、リクエストを処理するのに十分な vCPU があることを確認してください。インスタンス数に、インスタンスが提供する vCPU を掛けます。これで、クラスター内の vCPU の総数がわかります。スケールについては、最初に vCPU 数がアクティブなシャード数の 1.5 倍であることを確認してください。アクティブなシャードとは、大量の書き込みを受け取っているインデックスのシャードです。プライマリシャード数を使用して、大量の書き込みを受信しているインデックスのアクティブなシャードを特定します。ログ分析では、現在のインデックスのみがアクティブです。読み取りの負荷が大きい検索のユースケースでは、プライマリシャード数を使用します。

1.5 をお勧めしますが、これはワークロードにかなり依存します。必ず CPU 使用率のテストとモニタリングを行い、それに応じてスケーリングしてください。

シャードとインスタンスの数を取り扱う際、Amazon ES を適切に機能させるには合計シャード数を最小限にすべきであることに留意してください。適切なソフトリミットは 10,000 未満です。また、各インスタンスは、インスタンス上の JVM ヒープの合計シャード数が GB あたり 25 を超えないようにする必要があります。たとえば、R5.xlarge の RAM の合計数は 32 GB です。サービスは RAM の半分 (16 GB) をヒープに割り当てます (インスタンスの最大ヒープサイズは 31.5 GB です)。そのクラスター内のノードに 16 * 25 = 400 を超えるシャードを配置することはできません。

ユースケース

7 日間保持される Apache Web ログ (500 GB / 日) と、syslog (500 GB / 日) をサポートするログ分析ワークロードがあるとします。この記事では、ログ分析の最適な選択肢として R5 インスタンスタイプに焦点を当てています。インデックスごとに 3 つのアベイラビリティーゾーンのデプロイメントを使用します。プライマリ 1 つとレプリカ 2 つです。3 ゾーンのデプロイでは、ノードを 3 の倍数でデプロイする必要があります。これにより、インスタンス数が増加し、シャード数もある程度増加します。

各インデックスのプライマリシャード数は (500 * 1.25) / 50 GB = 12.5 シャードで、これを丸めて 15 とします。15 のプライマリを使用すると、各シャードで追加スペースを拡大し、3 で割り切れる数にできます (アベイラビリティーゾーン数とそれによるインスタンス数は 3 の倍数です)。必要なストレージの総容量は、1,000 * 1.25 * 3 * 7 = 26.25 TB です。このストレージには、R5.xlarge.elasticsearch インスタンスを 18 個、R5.2xlarge.elasticsearch インスタンスを 9 個、R5.4xlarge.elasticsearch インスタンスを 6 個 (それぞれ EBS の制限を 1.5 TB、3 TB、6 TB とする) 提供できます。一般的な目安として、垂直スケーリングは水平スケーリングよりも通常パフォーマンスが高くなるとされているため、4xlarge インスタンスを選択する必要があります (この一般的なルールには例外も多いため、繰り返しの際は適切に判断を行ってください)。

最小限のデプロイがわかったら、CPU 数を検証する必要があります。各インデックスには 15 のプライマリシャードと 2 つのレプリカがあり、シャード数の合計は 45 個になります。最新のインデックスは大量の書き込みを受け取るため、それぞれに 45 のアクティブなシャードがあり、アクティブなシャード数の合計は 90 になります。他の 6 日間のインデックスはアクセス頻度が低いため、無視します。ログ分析の場合、読み取りは常に少量で、データが古くなるにつれて減少することが想定できます。各 R5.4xlarge.elasticsearch には 16 個の vCPU があり、クラスター内の合計数は 96 個になります。ベストプラクティスでは、目安として 90 * 1.5 = 135 個の vCPU が必要です。スケールの開始点として、144 個の vCPU を搭載した R5.4xlarge.elasticsearch を 9 倍まで増やす必要があります。さらに、テストによってプロビジョニングが過剰であると明らかになり、6 つまで減少可能とされるでしょう。最後に、データノードとシャードの数を考慮して、C5.large.elasticsearch 専用マスターノード 3 つをプロビジョニングします。

まとめ

この記事では、Amazon ES ドメインをデプロイするための主要なベストプラクティスをいくつか取り上げました。これらの目安では、データノードの数とタイプの合理的な見積もりを示しています。今後の記事では、安全なドメインのデプロイ、ドメインのパフォーマンスの監視、ドメインへのデータの取り込みに関するベストプラクティスについて紹介します。ご期待ください。

著者について

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

Amazon Web Services ブログ