Amazon Elasticsearch Service でペタバイト規模のクラスタを実行する

ログデータに Amazon Elasticsearch Service (Amazon ES) を使用するのは、あたかも強力な消火ホースから水を飲むようなもので、システムそのものの潜在力は絶大です。Elasticsearch と Kibana の知識が深まるにつれ、より説得力のあるデータの使い方が見つかるでしょう。カスタマーベースが拡大し、それに対処するためにインフラストラクチャも拡張するのに伴い、さらに多くのログデータが生まれます。

膨らむ一方のログデータを格納および分析するためには、いくつかのデザインパスを辿ることができます。たとえば、複数の Amazon ES ドメインを展開し、ワークロードをそれらに分散することもできます。しかし、このデザイン戦略では、単独の Kibana ダッシュボードによる分析がサポートされません。また、ログストリームの一部を「共同所有」することで、ハイブリッドアプローチを取るか、オールインワンドメインアプローチを取るかを選ぶことができます。

最終的に、単独のワークロードドメインを使用したとしても、1 PB に達する、あるいはそれを上回るストレージに拡大できます。

Amazon ES では最近、大規模クラスタのサポート制限を倍増させました。今日現在では、ドメイン制限を増やすことで、デフォルトで 20 個のデータインスタンスを、クラスタあたり最大 200 件のデータインスタンスまでサポートします。データインスタンスに I3.16xlarge.elasticsearch インスタンスを選択した場合、クラスタに最大で 3 PB のストレージを持たせることができます。このような XL 規模のワークロードの運用を成功させるベストプラクティスは何でしょう?

Elasticsearch の最新バージョンを実行する

Elasticsearch はバージョンが上がるたびに、安定性とパフォーマンスの面で大きく改善されています。この記事の執筆時点で、Amazon Elasticsearch Service では Elasticsearch バージョン 6.4 がサポートされています。大規模なクラスタでは、Elasticsearch の最新のサポートバージョンへデプロイするか、アップグレードする (インプレースアップグレードを使用することで) ことをお勧めします。

I3 インスタンスを使用する

ペタバイト規模へ拡張するには、I3s を使用する必要があります。I3 インスタンスには NVMe SSD エフェメラルストアがあります。大規模な環境では、I3.16xlarge.elasticsearch インスタンスはノードあたり 15.2 TB のストレージを有します。すなわち、200 個のノードドメインであれば、合計で 3.04 PB に達します。EBS ベースのインスタンスタイプのいずれかを選択した場合、Amazon ES ではデータインスタンスあたり最大 1.5 TB の EBS ボリュームをデプロイできるようになり、これで 300 TB の最大クラスタサイズがもたらされます。私たちは常に新しいインスタンスタイプの評価と追加、そしてサービスの制限の検証と変更を行っている点にご注意ください。将来的なサービスの改善により、この記事で推奨している内容が変動する可能性があります。

インデックスのライフサイクル管理に _rollover API を使用する

ログの分析に Amazon Elasticsearch Service を使用する場合、データを区分し、クラスタ内でのライフサイクルを管理するためにインデックスを作成します。一定の期間、ログを蓄積し、次の期間にはそれらを新しいインデックスへ移動します。保持期間の終わりには、最も古いインデックスを削除します。

インデックスはどの頻度で変更するべきでしょうか? 決まったルールがあるわけではありませんが、インデックスの管理には次に示すように 2 つのパターンがあります。

• 一定の間隔で入れ替える (通常毎日、ただし、ワークロードの大きさによっては、1 日 1 回より頻繁に入れ替える必要が生じる可能性もあり)。この変更はクラスタの外、つまり、宛先インデックスを判別する取り込みパイプラインで行われます。
• インデックスのサイズをベースに入れ替える。この変更はクラスタ内で行われます。インデックスへのデータの送信にエイリアスを使用し、条件を指定して _rollover API をコールします。Elasticsearch は条件が一致すると、エイリアスの背後に新しいインデックスを作成します。インデックスのサイズをベースにした入れ替えは、Elasticsearch のバージョン 6.4 以降でのみ利用できる点に注意してください。

インデックスのサイズによる入れ替えをサポートしない Elasticsearch の旧バージョンでは、トリガーとしてドキュメント数を使用し、_rollover API をコールすることで同様の結果が得られる手法をお勧めします。これは、この代わりの手法で「ファイルの古さ」を基準にすると、シャードサイズが大きく変動するためです。

_rollover API を使用し、インデックスのサイズ、またはドキュメントの件数で入れ替えを行う手法には、シャードがすべてほぼ同じサイズになるという利点があります。サイズがほぼ同じであれば、ストレージを平均して分散させることが可能になり、その結果、クラスタ内のインスタンス間でコンピューティング性能を平均的に分散させることにつながります。

インスタンス数でシャード数が割り切れるように設定する

Amazon Elasticsearch Service ドメインでクラスタが不安定になる主な理由は、シャードの使用時に起こるスキューで、スキューが生じることによりホットノードが発生するためです。Elasticsearch では個数を基準にインスタンスへシャードをマップし、各インスタンスはシャードの個数とほぼ同じ数のインスタンスを受け取ります。インスタンスの数でシャードが割りきれるように設定するときは、クラスタの全ノードに同じ数のシャードが割り振られるようにします。

これはストレージスキューの管理で、_rollover API が威力を発揮するところです。あなたのシャードがすべて同じサイズであれば、ストレージはシャードの数をもとに、平均的にそれらを分散させます。ストレージが平均的に分散されていないと、ノードによっては他のノードより早くスペースを使い果たしてしまう可能性があります。このようなケースでは、Elasticsearch はこうしたノードにシャードを展開するのを停止し、シャード数もまたスキューとなり、インスタンスで不均一なロードが起こります。

インデックスの入れ替え後にインデックスを最適化する

分析用のワークロードでは、インデックスは 1 度だけ書き込むことができ、その後は読み取り専用になります。新しいインデックスに入れ替えたとき、_forcemerge API をコールして、このパターンのメリットを活かすことができます。_forcemerge はインデックス内のセグメントをマージすることで、Lucene セグメント数を減らします。これはクエリの処理時にその威力を発揮します。インデックスのシャード数を減らすために _shrink API を使用するのも良いアイデアで、シャード数を管理することで、クラスタ間に作業を平均的に分散できるようになります。

これらの API はいずれも、クラスタで大量のロードを生成する点に注意してください。_forcemerge または _shrink は頻繁にコールするべきではありません。これらのコールは一日で使用量の少ない時間帯に設定し、同時実行コールの件数を 1 件に制限します。

マスターノード

PB 規模のクラスタでは専用マスターインスタンスをデプロイする必要があります。専用のマスターインスタンスはノード数の多いクラスタに必要な安定性をもたらします。専用マスターインスタンスをこのように使う主な理由には、シャード数、ノード数、マッピングサイズ、マッピングの変更などが含まれます。以下の表ではさまざまな規模の専用マスターインスタンスに推奨されるインスタンスタイプについて、いくつかの要素の指標としてシャード数を使用しています。

どの Amazon ES クラスタでも、シャードの合計数は 30,000 個未満に抑えることをお勧めしています。しかし、すべてのシャードが同じリソースを使用するわけではありません。前回の記事 sizing your Amazon Elasticsearch Service Domain では、アクティブなシャードとアクティブでないシャードの差について解説しました。シャードがアクティブとは、シャードで読み取りと書き込みのトラフィックがあることを指します。ご使用のドメインがサポートできるアクティブなシャード数は、クラスタの CPU の数に左右されます (詳細については、sizing your Amazon Elasticsearch Service Domain を参照してください)。I3.16XLarge.elasticsearch クラスタの 200 個のノードでは、アクティブシャードの個数を 5,000 個未満にする必要があります (他のクラスタのタスクに余裕を持たせるため)。

前出の表では、インスタンスに格納されたデータ (バイト数) に対し、JVM のサイズ (バイト数) を 1:50 と仮定しています。また、シャードの最大サイズのベストプラクティスとして 50 GB を使用します。ワークロードによっては、100 GB までのより大きなシャードサイズが適している場合もあります。

シャードに 50 GB より大きなサイズを使用するときは、正常に機能するようクラスタのメトリクスを慎重に調べる必要があります。必ず、CloudWatch メトリクスにアラームを設定してください。シャードの個数が多いクラスタでは、マスターインスタンスの CPU と JVM の使用状況を監視することが特に重要になります。専用マスター CPU が平均して 80% 以上で稼働している、または専用マスターの JVM Memory Pressure が持続的に 80% を超えるようであれば、シャード数を減らしてください。

Limit _bulk リクエストのペイロード

ドメインを最初に展開するとき、ある程度の時間を割いて、_bulk リクエストのペイロードサイズを調整するようにしてください。Elasticsearch のスループットは書き込みリクエストと、それに続く処理時間、各リクエストの JVM のメモリ使用量に大きく左右されます。経験的に、この調整の開始点として適切なのは、およそ 5 MB と言えます。

PB 規模のクラスタでは、バルクペイロードの量を 20 MB 未満に維持するようおすすめします。これはバルクサイズをこの数値以上に設定したときにより良いスループットが得られるようであっても変わりません。バルクが大きくなればなるほど、処理すべき JVM のメモリも増えます。これは処理するバルクリクエストの量が多すぎた場合、JVM ヒープを使い果たしてしまう可能性があるためです。

まとめとご注意

膨大なログ分析ワークロードを処理するために、単独のドメインを使用するのであれ、複数のドメインに分散するのであれ、このブログ記事でまとめたベストプラクティスをご活用ください。しかし、この点には十分にご注意ください。Elasticsearch のワークロードは千差万別です。本記事での推奨内容はガイドラインに過ぎず、各自の使用量は異なります。 サイズ設定、シャード戦略、インデックスライフサイクルの管理を積極的にデプロイ、監視、調整する必要があります。

Jon Handler は、検索テクノロジーに特化した AWS ソリューションアーキテクトです。@_searchgeek で Jon Handler に連絡できます。