production.log

ピクスタ株式会社でエンジニアのマネージャーをやっている星直史のブログです。

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を運用するよりは楽だと感じています。