« AWS Black Belt Online Seminar「Amazon Lightsail」資料およびQA公開 | メイン | AWS Black Belt Online Seminar「AWS Storage Gateway」資料およびQA公開 »

【AWS Database Blog】Amazon Elasticsearch Service をはじめよう: インスタンス数の見積もり方法

こんにちは。ソリューションアーキテクトの篠原英治(@shinodogg)です。本日はAWS Database Blogに掲載されたGet Started with Amazon Elasticsearch Service: How Many Data Instances Do I Need?をご紹介します。


Jon Handler (@_searchgeek) は Amazon Web Services のプリンシパルソリューションアーキテクトです。

Elasticsearch および Amazon Elasticsearch Service のブログポストシリーズへようこそ。ここではAWS上でElasticsearchをはじめるにあたって必要な情報を提供していく予定です。

何台のインスタンスが必要?

Amazon Elasticsearch Serviceのドメインを作成する際の最初の質問です。

ElasticSearch

あなたのElasticsearchクラスタにいくつのデータノードをデプロイすべきか決定するには、検証やテストが必要になりますが、まずは、冗長性確保のために必要なミニマムな2インスタンスではじめていきます。

必要なストレージ = 元になるソースデータ x ソース:インデックス率 x (レプリカ + 1)

最初に元になるソースデータのサイズを把握しましょう。そして、ソースデータ→インデックスサイズにおけるインデックス率を求めましょう。最後にレプリカ数を掛け合わせて(レプリカのカウントはゼロベースなので + 1 します)、必要なストレージ容量を算出します。必要なストレージ容量が分かったら、1ノードにどれだけのインデックスを保存するかを考慮に入れて、データノードに対するストレージオプションを選択します。ノード数はトータルのデータ量をノード数で割り算して算出します。

必要なインスタンス数 = 全体ストレージ / ノード毎のストレージ

クラスタに対して、データの登録やクエリをを行っていく上で、継続的にクラスタのパフォーマンスを評価し、ノード数を調整していきます。もし、ストレージ容量が枯渇した場合、ノードを足すか、もしくは、Amazon Elastic Block Store (Amazon EBS)のボリュームサイズを増加させます。もし、コンピュートリソースが必要であれば、インスタンスタイプを変更するか、インスタンス数を増やします。Amazon Elasticsearch Serviceは、このような変更を動的にダウンタイムなく、行うことができます。

元になるソースデータ量の算出

インデックスのためにどの程度のストレージが必要か算出する際に、元になるソースデータがどの程度の量かを明らかにします。検索エンジンの世界では、ソースデータの集合のことを corpus (コーパス) と呼びます。大まかに分類すると、お客様のワークロードは以下の2つです。

  • シングル インデックス ワークロード: S3のような全てのコンテンツを一元化して保持する外部のデータリポジトリを使う。そしてコンテンツをシングルなインデックスにputする。一元化されたデータリポジトリに変更が行われると、インデックスも更新される用に実装する。この方法はウェブサイト, ドキュメント, eコマースサイトの全文検索などにおいては一般的。
  • ローリング インデックス ワークロード: データを継続的に受け取る。データはタイムスタンプとインデクシング期間(一般的には日ごと)によって分割された複数のインデックスに渡って登録される。通常これらのインデックスは更新されることはない。新しいインデックスは日ごとに作成され、最も古いインデックスはリテンション期間以降が削除される。これらは共通してログ解析、時系列プロセッシング、クリックストリーム解析などに使われる。

Index

もし、シングルインデックスなワークロードであるならば、あなたは既にどの程度のデータ量か知っています。一元化してデータを保存したストレージの容量をチェックし、それを利用します。もし複数のソース(例えば"ドキュメント"と"メタデータ")からデータを集めるのであれば、それを足し込んで総量を求めましょう。

もし、ローリングインデックスなワークロードであるならば、どの程度の量がストアされるのか計算する必要があるでしょう。シングル期間(例えば1日)とリテンションの期間を元に計算を行います。非常に一般的なケースとしては、"ログを24時間ごとに保存し、2週間保持する"というものです。もし、日ごとにどの程度の量のログが生成されるのか把握していなければ、大まかな見積もりをすることができます。それは256バイトをログ1行としてそれにログの行数を掛ける、というものです。リテンションの期間分掛け算を行えば、全体的な元データのサイズが算出されます。

IndexSpace

どの程度のストレージスペースが必要かは、いくつかの要素に依存します。Elasticsearchにドキュメントを送信するにつき、それらのデータは検索可能な状態にするために処理されます。どの程度のディスクサイズが実際に使われるかは、データおよび設定したスキーマ情報によります。大体、インデックスサイズに対する元のソースデータのサイズの割合は 1:1.1 くらいのことが多いです。10%のオーバーヘッドを考慮にいれつつも、元のソースデータのサイズと同じサイズのストレージが必要、と大まかに言うことができるでしょう。

レプリカによるインデックスサイズの増加

Elasticsearchでは、インデックスに対するレプリカの数を設定(そして動的に変更)することができます。レプリカを使用する最も重要な理由はクラスタの冗長性の確保です。プロダクションのワークロードやデータロスを許容できない場合はレプリカを使用することをお進めします。また、クエリのプロセッシングのキャパシティによってレプリカの数を増やす必要があるかもしれません。この点の詳細に関しては今後のブログポストでも触れますが、ノードレベルの冗長性を確保するには少なくともノードを追加しなければならないということです。ただ1つのノードでは、レプリカを使用したとしても、高可用性の実現はできません。

それぞれのレプリカはシャードレベルでのインデックスの完全なコピーです。つまり、プライマリなインデックスと同じストレージをコピー用にも使用します。つまり、もし、レプリカを1つ使うのであればストレージ容量は2倍になります。

インスタンスごとのストレージ

Amazon Elasticsearch Serviceのドメインの設定を行う際に、ストレージオプションを選択します: インスタンス(エフェメラル)ストレージ or EBSストレージ。インスタンスストレージを選択するのであれば、データノードごとのストレージ量はインスタンスタイプによって決まります。EBSストレージを選択した場合、インスタンスごとのストレージ容量を設定することができます。Amazon Elasticsearch ServiceにおけるEBSストレージの制限はインスタンスタイプによって異なります。

例えば、もしm3.medium.elasticsearchを選択し、インスタンスストアを選んだ場合、それぞれのノードは4GBのSSDを保持します。EBSを選んだ場合はそれぞれのノードに100GBまでEBSストレージをアタッチすることができます。

但し、実際にインデックスを保存できる領域はトータルなストレージ容量よりも少ないです。サービスファイルとOSのファイルが約3%のm3.medium(大きいインスタンスであればその割合は低くなる)のストレージ容量を消費します。またAmazon ESはノードごとに約20%(最大で20GB)のディスクを確保します。これは、特に小さいインスタンスにおいては、ストレージ容量が最大の境界に近い場合は追加ノードをすべきであることを意味します。

2つの例をみてみましょう

以下2つの例は同じ会社の中の異なるワークロードです。

最初の例は、シングル インデックス ワークロードで、eコマースなウェブサイトの商品カタログを扱うものです。10万個の商品がありデータ容量は1GBです。これにより1GBのインデックスサイズが必要ということになりますが、レプリカを1つ持つようにするために合計2GBのストレージが必要です。彼らが選択したm3.medium.elasticsearchインスタンスには4GBのストレージが割り当てられており、レプリカも含めて1つのノードでやりくりできてしまうデータ量ですが、冗長性を確保するためにm3.medium.elasticsearchインスタンスを2台確保しました。

二つ目の例は、ローリング インデックス ワークロードで、Twitter firehoseからデータを収集し、ブランドのセンチメント分析を行い、上記の商品検索のランキング機能の向上に役立てます。毎日100GBのTwitterのデータをダウンロードし、それを7日間保持します。1日100GBのインデックスを毎日消費するとして、レプリカも1つ保持します。つまり200GBのデイリーのインデックスを7日間保持するということです。200GBを7倍すると1,400GBのストレージが必要になります。m3.large.elasticsearchインスタンスを選択し、512GBのGeneral Purpose SSD(gp2)のEBSボリュームをアタッチすることにしました。この場合3台のインスタンスが必要な計算になりますが、ここでは追加のストレージの確保の意味で(日によってデータ量は一定でない場合がある)、4台のm3.large.elasticsearchインスタンスを使うことにしました。

インスタンス数の見積もり

Amazon Elasticsearch Serviceを使ってElasticsearchをはじめることは簡単ですが、いくつか事前に選択をしなければなりません。1つはいくつのノードを使うかということですが、こちらはどの程度のデータ量を保存するかによって導き出すことができます。大抵の場合インデックスのサイズは元のソースデータと同じで、それをレプリカの数で掛け算します。これでインデックスの全体サイズは算出できます。更にそれをノードごとのストレージ量で割り算することで、必要なノード数、つまりインスタンス数が分かることになります。

 

コメント

Twitter, Facebook

このブログの最新情報はTwitterFacebookでもお知らせしています。お気軽にフォローください。

2018年4 月

1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30