Amazon ES ドメインのサイジング - Amazon Elasticsearch Service

「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」

Amazon ES ドメインのサイジング

Amazon ES ドメインを確実にサイジングする方法として絶対的なものはありませんが、ストレージ要件やサービス、Elasticsearch の内容を理解することで、ハードウェアに対するニーズを正しい知識に基づいて予測できます。ドメインのサイジングに取りかかる際の最も重要な検討材料として、そうした予測結果を代表的なワークロードを使用したテストに活用し、パフォーマンスを監視します。

ストレージ要件の計算

ほとんどの Elasticsearch ワークロードは、次の 2 つのカテゴリに大別できます。

  • 長期存続インデックス: データを 1 つまたは複数の Elasticsearch インデックスとして処理し、ソースデータの変更に伴ってそれらのインデックスを定期的に更新するコードを記述した場合。一般的な例としては、ウェブサイト、ドキュメント、e コマースの検索などがあります。

  • ローリングインデックス: データは継続的に一時的なインデックスに受け渡され、インデックス作成時間や保持期間が指定されます。たとえば、日次のインデックスは 2 週間保持されます。代表的な例は、ログ分析、時系列処理、クリックストリーム分析などです。

長期存続インデックスのワークロードの場合、使用されるストレージ容量はディスク上のソースデータを調べることで簡単に判断できます。データのソースが複数ある場合は、すべてのソースを単純に合計します。

ローリングインデックスについては、一般的な期間内に生成されるデータ量に保持期間を掛けます。たとえば、1 時間あたり 200 MiB 個のログデータを生成する場合、1 日GiBで 4.7 個になります。保持期間が 2 週間であれば、いずれかの時点でデータの GiB 66 個になります。

ただし、ソースデータのサイズはストレージ要件の 1 つの要素に過ぎません。次の点についても考慮する必要があります。

  1. レプリカの数: レプリカとはインデックス全体をコピーしたものであり、同量のディスク容量を必要とします。デフォルトでは、各 Elasticsearch インデックスに対してレプリカが 1 つ作成されます。データ損失を防ぐため、少なくとも 1 つは作成することをお勧めします。レプリカによって、検索パフォーマンスを改善することもできます。読み込みが多いワークロードが発生する場合は、より多くのレプリカがあるとよいでしょう。

  2. Elasticsearch インデックス作成オーバーヘッド: ディスク上のインデックスのサイズは一定ではありませんが、多くの場合でソースデータよりも 10% 大きくなります。データのインデックスを作成したら、_cat/indices?v API と pri.store.size の値を使用して正確なオーバーヘッドを計算します。_cat/allocation?v また、 は有用な概要も提供します。

  3. オペレーティングシステムの予約スペース: デフォルトでは、Linux は、重要なプロセス、システム復元、そしてディスクの断片化問題に対する保護目的で、root ユーザー用にファイルシステムの 5% を予約します。

  4. Amazon ES オーバーヘッド: は、セグメントマージ、ログ、およびその他の内部オペレーション用に、各インスタンスのストレージ容量の 20% (最大 20 個Amazon ES) GiB を予約します。

    このGiB最大数が 20 個であるため、予約容量の合計はドメイン内のインスタンスの数によって大きく異なります。たとえば、ドメインに 3 つの m4.xlarge.elasticsearch インスタンスがあり、各インスタンスGiBのストレージ容量が 500 であるとすると、合計は 1.46 になりますTiB。 この場合、予約容量の合計は 60 のみですGiB。 別のドメインには、10 個のm3.medium.elasticsearchインスタンスがあり、各GiBストレージ容量が 100 個であるとします。合計で 0.98 になりますTiB。 ここでは、最初のドメインが 50% 大きいですがGiB、予約容量の合計は 200 です。

    次の式では、ノードの障害やアベイラビリティーゾーンの停止による影響を最小限に抑えるために、追加の空き領域を含むオーバーヘッドの「ワーストケース」の見積もりを適用します。

つまり、任意の時点で 66 GiB 個のデータが存在し、レプリカを 1 つ必要とする場合、最小ストレージ要件は 66 * 2 * 1.1/0.95/0.8 = 191 になりますGiB。 この計算は次のように一般化できます。

ソースデータ x (1+ レプリカの数) x (1 + インデックス作成オーバーヘッド) ÷ (1 - Linux 予約スペース) ÷ (1 - Amazon ES のオーバーヘッド) = 最小ストレージ要件

あるいは、この簡素化されたバージョンを使用することもできます。

ソースデータ x (1+ レプリカの数) x 1.45 = 最小ストレージ要件

ストレージの容量不足は、クラスターが不安定になる最も一般的な原因の 1 つです。インスタンスタイプ、インスタンスの数、ストレージボリュームを選択.するときは、それらの数を照合して確認するようにしてください。

ストレージに関するその他の考慮事項は次のとおりです。

シャード数の選択

ストレージ要件を理解したら、インデックス作成の戦略を調査できます。各 Elasticsearch インデックスは、いくつかのシャードに分割されます。既存のインデックスのプライマリシャード数を簡単に変更することはできないため、最初のドキュメントのインデックスを作成する前にシャード数を決定する必要があります。

シャード数を選択する最終的なねらいは、クラスター内のすべてのデータノード間でインデックスを均等に分散させることです。ただし、これらのシャードは大きすぎたり多すぎたりしてはいけません。シャードのサイズは –1050 にすると良いようですGiB。 シャードが大きいと、 の障害Elasticsearch復旧が困難になる可能性がありますが、各シャードである程度の CPU とメモリが使用されるため、小規模なシャードが多すぎると、パフォーマンスの問題やメモリ不足エラーが発生する可能性があります。つまり、基盤となる Amazon ES インスタンスで問題なく処理できるようにシャードは小さくする必要がありますが、小さすぎるとハードウェアに不必要な負荷をかけてしまうということです。

たとえば、66 GiB 個のデータがあるとします。この数が時間の経過とともに増えることは予想されるものではなく、各シャードのサイズは約 30 個を維持する必要がありますGiB。この場合、シャード数は約 3 つとなります (66 * 1.1/30 = 3)。この計算は、次のように定型化できます。

(ソースデータ + 拡張の余地) * (1 + インデックス作成オーバーヘッド)/必要シャード数 = プライマリシャードの概数

この式は、時間の経過に伴う拡張にも対応できます。同じ GiB 67 個のデータが次の 1 年に 4 倍になると予想される場合、シャード数はおよそ (66 + 198) * 1.1/30 = 10 となります。ただし、これらの追加GiB分の 198 データはまだありません。将来に向けてのこのような準備として不必要な小さいシャードを作成し、現時点で CPU とメモリを大量に消費することがないようにしてください。この場合、シャードGiBあたり 66 * 1.1/10 シャード = 7.26 となります。これは余分なリソースを消費し、推奨サイズ範囲を下回ります。中間のアプローチとしてシャード数を 6 つにすると、シャードの数はGiB現時点で 12 個、将来的に 48 GiB 個になります。次に、シャードが 50 を超えた場合に、3 つのシャードから始めてデータのインデックスを再作成することもできますGiB。

かなりまれな問題の場合、ノードあたりのシャード数を制限する必要があります。シャードのサイズを適切に設定した場合、通常はこの制限に達するかなり前にディスク容量が不足します。たとえば、 m5.large.elasticsearch インスタンスの最大ディスクサイズは 512 ですGiB。 ディスク使用率が 80% 未満で、シャードのサイズを 20 にするとGiB、約 20 シャードに対応できます。 Elasticsearch 7.x 以降では、ノードあたり 1,000 シャードという制限があり、 cluster.max_shards_per_node 設定を使用して調整できます。

シャードのサイズを適切に設定すると、ほとんどの場合、この制限を下回ることができますが、各 GiB Java ヒープのシャード数を考慮することもできます。特定のノードでGiB、Java ヒープあたり 20 個以下のシャードがあります。たとえば、 m5.large.elasticsearch インスタンスには 4 つのGiBヒープがあるため、各ノードのシャード数は 80 個を超えないようにしてください。そのシャード数では、各シャードのサイズは約 5 GiB であり、推奨値をかなり下回っています。

インスタンスタイプとテストの選択

ストレージ要件を計算して必要なシャード数を選択したら、ハードウェアに関する決定ができるようになります。ハードウェア要件はワークロードによって大きく異なるものの、基本的な推奨事項は提供されています。

一般的に、各インスタンスタイプのストレージ制限Amazon Elasticsearch Service の制限は、軽いワークロードに必要な CPU とメモリの量にマッピングされます。たとえば、 m4.large.elasticsearch インスタンスの最大 EBS ボリュームサイズは GiB512、2 vCPU コア、8 GiB のメモリです。クラスターには多数のシャードがあり、高負荷の集計処理、頻繁なドキュメント更新、または大量のクエリ処理が発生している場合、それらのリソースではニーズを満たせない可能性があります。クラスターがこれらのカテゴリのいずれかに分類される場合はGiB、ストレージ要件 100 ごとに vCPU コア 2 個とGiBメモリ 8 個に近い構成から開始してみてください。

ヒント

各インスタンスタイプに割り当てられるハードウェアリソースの概要については、「Amazon Elasticsearch Service 料金表.」を参照してください。

ただし、上記に記載されたリソースでも不十分になる場合があります。一部の Elasticsearch ユーザーからは、要件を満たすためにこれらのリソースが重ねて必要になるという報告を受けています。ワークロードに最適なハードウェアを特定するには、知識に基づく初期予測、代表的なワークロードを使用したテスト、調整、そして再テストが必要になります。

  1. まず、スプレッドブレインなどの潜在的な Elasticsearch の問題を防ぐため、ノード数は 3 つ以上を選択することをお勧めします。専用マスターノードが 3 つある場合は、レプリケーション用に最低 2 つのデータノードをお勧めします。

  2. ストレージ要件が 184 GiB で、推奨最小数が 3 つのノードである場合は、式 184/3 = 61 GiB を使用して、各ノードに必要なストレージの量を確認します。この例では、3 つのm5.large.elasticsearchインスタンスを選択し、それぞれで 90 GiB 個の EBS ストレージボリュームを使用することで、安全策として時間の経過に伴う拡張にも備えることができます。この設定では 6 つの vCPU コアと 24 GiB 個のメモリが提供されるため、より軽量のワークロードに適しています。

    より大規模な例として、ストレージ要件が 14 TiB (14,336 GiB) で高いワークロードがあるとします。この場合、2 * 144 = 288 の vCPU コアおよび 8 * 144 = 1152 GiB のメモリでテストを開始することができます。これらの数値は、約 18 i3.4xlarge.elasticsearch インスタンスを使用する結果となります。高速なローカルストレージが必要ない場合は、それぞれが 1 r5.4xlarge.elasticsearch つの EBS ストレージボリュームを使用する 18 個のTiBインスタンスをテストすることもできます。

    クラスターに数百テラバイトのデータが含まれる場合は、「」を参照してください。Amazon Elasticsearch Service におけるペタバイト規模.

  3. クラスターを設定したら、先ほど計算したシャードの数を使用してインデックスAmazon Elasticsearch Service でのデータのインデックス作成を追加し、実践的なデータセットを使用して代表的なクライアントテストを実行した後、 メトリクスCloudWatchを監視してクラスターがワークロードを処理する方法を確認できます。

  4. パフォーマンスがニーズを満たすものであれば、テストは成功し、CloudWatch メトリックスは正常であり、クラスターは使用する準備ができたことになります。リソースの異常な使用状況を検出するための アラームCloudWatchを必ず設定してください。

    パフォーマンスが許容できないものであれば、テストが失敗したか、または CPUUtilizationJVMMemoryPressure が高いことになります。別のインスタンスタイプを選択 (またはインスタンスを追加) して、テストを続行する必要があるかもしれません。インスタンスを追加すると、Elasticsearch はクラスター全体にわたってシャードを自動的に再分散します。

    過負荷クラスターの過剰容量は、負荷の低いクラスターの不足よりも簡単に測定できるため、必要以上に大きなクラスターから開始することをお勧めします。次に、追加のリソースを持つ効率的なクラスターにテストおよびスケールダウンして、アクティビティの増加期間中に安定した運用を確保します。

本番稼働用クラスター、または複雑な状態のクラスターは、専用マスターノードから利点を得られます。これにより、パフォーマンスとクラスターの信頼性が向上します。