[レポート] UltraWarm for Amazon Elasticsearch Serviceの紹介 #ANT229 #reinvent

Introducing UltraWarm for Amazon Elasticsearch Service

本記事はre:Invent 2019のセッション「ANT229 - Introducing UltraWarm for Amazon Elasticsearch Service」のレポートです。

UltraWarmは発表されたばかりですので、その全容はまだまだ分からないところが多いです。いち早くキャッチアップするための情報としてご参照いただけると幸いです。

Speaker

• Ian Swanson [General Manager, Amazon Web Services]
• Eli Fisher [Product Manager, Amazon Web Services]
• Ramakrishna Kotla [Principal Software Engineer, Amazon Web Services]

ログを手に入れた。さあどうする？

システムやサービスには必ずログが存在するものです。期間が長ければ長いほど日に日にログは貯まり、膨大な数になります。言い換えると、たくさんのログデータとともにビジネスが成長していきます。

ログは、ビジネス上の価値を生み出します。

• クリティカルなインサイト
• アプリケーションパフォーマンス
• セキュリティ

Elasticsearchとは

Elasticsearchは、ログについてのパワフルな検索・アナリティクスのエンジンです。Elasticsearch, Logstash, Kibanaといった周辺ツールがまとまって、ログを最大化します。

Amazon Elasticsearch Serviceとは

AWSが提供するElasticsearchのフルマネージドサービスです。オープンソースであるElasticsearchのクラスタを簡単操作で構築できます。

次のようなベネフィットがあります。

• OSSのAPIツールのサポート
• 簡単に使える
• スケーラブル
• セキュア
• 高可用
• 他のAWSサービスとの簡単な連携

これまでに1万ものカスタマーが利用しています。

ログにおける課題

AWSは、カスタマーが共通の様々な課題を持っていることを学びました。

• データ格納が高額
• データ制限がある
• 貴重なインサイトを見逃す

このような課題を解決するためには、様々なツールを駆使することで解決に向かおうとします。しかしながら管理コストがかかってしまったり本質的ではありません。

UltraWarm

ここで登場するのが、Andy Jassy Keynoteで発表された新サービス UltraWarm です。

UltraWarmはAmazon Elasticsearch Serviceに新しいストレージ層を作ります。アーカイブ層を増やすことで、既存のAmazon Elasticsearch Serviceのアーキテクチャに比べ、最大約90%のコスト削減が可能になりました。

アーキテクチャ

UltraWarmを使った場合のアーキテクチャです。

大きく変わるところはUltraWarm層が新たに用意されるところです。アクセスのないデータはUltraWarm層に、頻繁にアクセスされるデータは "Hot" データノード層に格納されます。

UltraWarm層では、データはノードの内部ではなくS3にデータを格納します。S3に格納することで、S3が持つ様々な特長が活かされます。低コストに保存され、また優れた耐久性でデータが保証されます。ノードのストレージに拘束されることはありません。

Logging Example

より具体的なロギングのユースケースを元に、各層でどの程度のキャパシティが必要になるか見ていきましょう。

例えば1日1TBのログデータがホットデータとしてIndexされるとします。また、これらの新規データは7日後にリテインさることとします。さらには60日間の保持を要件とします。

この場合、データ量としては1日あたり2.6TBが使われることになります。7日間後にリテインされるので、Hot層としてはオーバープロビジョニングも考慮した上で、18.4TBが必要です（レプリカ + オーバーヘッド）。Node数は i3.4xlarge が5台あれば足りる計算となります（各Nodeで3.8TB）。

UltraWarmのキャパシティとしては、60日間必要ですので60TBが必要です。その場合、UltraWarm Largeを3台用意していることが必要になります。

UltraWarmを使用すると、すべてのストレージを100％利用でき、すべてのオーバーヘッドにプロビジョニングが組み込まれるため、インフラストラクチャでのプロビジョニングについて心配する必要はありません。

Demo

Amazon Elasticsearch ServiceにUltraWarmを設定するデモを披露いただきました。

写真が荒すぎて何も読めない…!!のであくまでイメージ画像として貼りました。UltraWarmを使う設定はElasticsearch ServiceのDomainを設定する画面に組み込まれる形になっています。

UltraWarmはプレビューで利用可能ですので、どのように設定するか知りたい場合はぜひ使ってみてください（一般公開されるまでに変更される可能性がありますのでご留意ください）。

ログデータをKibanaで分析する

UltraWarmを有効化すれば全てが解決するか、と言うとそう言うわけではありません。

実際のデータ量を分析し続けることも非常に大事なことです。

例えば平均的にクエリ毎にどのくらいのデータを参照しているか。あるいは、スパイクのあった日はないかどうかなどを調べます。Amazon Elasticsearch Serviceに標準で付いている「Kibana」を使うことでデータ量などをグラフ化できます。

例えば下図はクエリ毎にグループ化した際のデータ量のグラフです。

Amazon Elasticsearch Serviceに格納されているデータを様々な切り口で参照・グラフ化することで、UltraWarmの効果がどれほどあるか分析したり、今後のログ戦略に活かしたりします。

まとめ

UltraWarmについて解説された、初めてのセッションでした。

UltraWarmは非常に強力ですが、Amazon Elasticsearch Serviceのデータ量をしっかりと事前に分析した方がより効果的に活用できる と思いました。

現在運用しているElasticsearch Serviceは、どのくらいのデータ量で、どのくらいコストがかかっているのか。あるいはどのクエリがよく使われているのか。こういった情報をKibanaを使って分析しておくと良いでしょう。

そうした上で、UltraWarmを入れることでどのくらいコストが浮くか把握できるようになります。もしかすると、実はUltraWarmを使う前にそもそも使い方の改善でコスト削減できるポイントがあるかも知れません。

UltraWarmが登場したことをきっかけに、Amazon Elasticsearch Serviceの使い方を見直してみましょう！