production.log

株式会社リブセンスでエンジニアをやっている星直史のブログです。

トップ > 技術 > Amazon CloudSearch における適切なスケーリングオプション(Scaling Options)を紹介します

Amazon CloudSearch における適切なスケーリングオプション(Scaling Options)を紹介します

技術

概要

Amazon CloudSearch における適切なスケーリングオプションの設定を紹介します。 設定できる項目は下記の通りです。

以下、公式ドキュメントより引用

ドメインのスケーリングオプションを設定するときは、コストとパフォーマンスのトレードオフが生じます。望ましいインスタンスタイプ、レプリケーション数、パーティション数を変更すると、ドメインを実行するコストに大きな影響があります。

また、各項目の変更はそれぞれ下記の通り影響があります。

設定項目 期待できる効果
インスタンスタイプ アップロードキャパシティの増加
パーティションカウント 検索リクエストの応答速度の向上
レプリケーションカウント 検索キャパシティの増加および耐障害性の改善

インスタンスタイプ

インスタンスタイプは格納するIndexサイズ(データ総容量)とドキュメント数の目安から決定しましょう。

インスタンスタイプ Indexサイズ ドキュメント数
m1.small 1GB未満 625,000
m3.medium 1GB ~ 8GB 1,250,000
m3.large 8GB ~ 16GB 2,500,000
m3.xlarge 16GB ~ 32GB 5,000,000
m3.2xlarge 32GB ~ 64GB 10,000,000

※Indexサイズが64GBを超える場合は、後述のパーティションカウントの設定変更を検討します。

Indexサイズ(データ総容量)について

容量はindexing optionsの設定により増加していきます。 indexing optionsで設定できる項目は下記の通りです。

  • Highlight
  • Return
  • Sort
  • Facet

これらはそれぞれ、次のようにIndexサイズを肥大化させます。

設定項目 増加するIndexサイズ(%)
全て指定しなかった場合 0%
全て指定した場合 243%
Highlight 220.8%
Return 153.2%
Sort 12.7%
Facet 0.3%

不要なindexing optionsの設定をしないことで、コスト削減と応答速度向上が見込めるため、 indexingする際には注意する必要があります。

パーティションカウント

インスタンスタイプが2xlargeの場合、パーティション数を指定できます。
また、インスタンスタイプを決定する際に、格納するIndexサイズ(データ総容量)を確認したと思いますが、
この容量が64GBを超える場合はパーティションカウントの上限を上げることを検討をします。
具体的なパーティション数は
(Indexサイズ / インスタンスタイプの容量上限) + 1
が望ましいパーティション数です。

例) Indexサイズが150GBの場合
インスタンスタイプ: m3.2xlarge
パーティションカウント: (150GB / 64) + 1 = 3

レプリケーションカウント

レプリケーションカウントはリクエストするクエリの複雑度と、トラフィックに応じてレプリケーションカウントを調整します。
現状CloudSearchでは応答速度のメトリクスは取れませんので、
NewRelicのWeb externalを確認し、調整するしかないようです。

または、下記の表を目安にしても良いでしょう。

インスタンスタイプ JMeterの設定 スループット
m3.medium 2 hosts 10threads 48.3 qps / 206 ms
m3.large 4 hosts 20threads 291.5 qps / 68 ms
m3.xlarge 8 hosts 40threads 665.9 qps / 59 ms
m3.2xlarge 16 hosts 80threads 985.3 qps / 80ms

その他スケーリングについてのtips

  1. スケーリングオプションではレプリケーションカウントの変更はIndex再構築が必要ない(変更自体は無料で変更できる)ですが、
    インスタンスタイプとパーティションカウントの変更にはIndex再構築費用がかかるため、十分に検討する必要があります。
    Index再構築費用は下記の通り
    Indexサイズ 1GB あたり 0.98 USD

  2. 上記より、Webサイトのピークタイムがわかる場合は、AWS CLIより自動で設定します。
    例) 10 ~ 18時のピークタイムに合わせてレプリケーションカウントを2 => 3に変更する場合

0 10 * * * /usr/bin/aws --region ap-northeast-1 cloudsearch update-scaling-parameters --domain-name hogehoge-production --scaling-parameters DesiredReplicationCount=3,DesiredInstanceType=search.m3.2xlarge,DesiredPartitionCount=4
0 18 * * * /usr/bin/aws --region ap-northeast-1 cloudsearch update-scaling-parameters --domain-name hogehoge-production --scaling-parameters DesiredReplicationCount=2,DesiredInstanceType=search.m3.2xlarge,DesiredPartitionCount=4

まとめ

CloudSearchはフルマネージドと謳いつつも、AutoScalingの検知やスケールが遅かったり、
メトリクスが貧弱なため、トライ＆エラーで知見を得ていくしかありません。
また、障害が発生した場合の問題を自分達で調べることができない上、サポートに問い合わせをしても腑に落ちない回答になる場合が多いです。
(レプリケーションカウントとパーティションカウントを増やして対応してくださいで終わる、など…)

ただ、経験が溜まっていくと、オンプレでSolrやElasticSearchを運用するよりは楽だと感じています。