読者です 読者をやめる 読者になる 読者になる

てくすた

ピクスタ株式会社のエンジニア・デザイナーがつづるよもやまテクニカルブログです

PIXTAにおけるCloudSearchのコスト削減

こんにちは、ピクスタ開発部の星直史です。

先日開催されたJAWS DAYS 2017でLT登壇してきたのですが、時間の制約上、めちゃくちゃ早口だったので、テキストベースでも解説します。

目次

  • 背景
  • CloudSearchの料金体系
  • コスト圧迫の原因と対策
  • コスト削減結果

背景

現在PIXTAでは2,200万点以上の素材を販売をしています。*1
素材は、クリエイターさんからアップロードする際にタグ付けを行い、そのデータをCloudSearchに格納し、検索に使用しています。
また、PIXTAでは、日本語の他に、英語繁体字簡体字タイ語と多言語対応しています。
そのため、CloudSearchに格納するタグ情報は各ロケールに合わせて、翻訳したタグ情報も格納しています。

2,200万点以上のデータが5言語分存在し、それぞれに、シノニム、表記揺れ、ステミング情報が格納されているので、コスト削減前は、CloudSearchのインスタンス数が膨れ上がってしまっていました。

f:id:watasihasitujidesu:20170313121428p:plain

今回は、その膨れ上がるインスタンス数をどのようにして抑えたかについての話です。

料金体系

CloudSearchの料金体系

まず、敵を知るべく、CloudSearchの料金体系を確認します。

料金表

課金項目は下記の通りです。 公式にもありますが、項目名とどんなときに課金されるのかのサマリです。*2

課金項目 内容
検索インスタンス インスタンスタイプによる1時間あたりの料金 * PartitionCount * ReplicationCount
ドキュメントバッチアップロード CLoudSearchにデータを格納する時に課金。
IndexDocumentsリクエスト スキーマなどを変更し、インデックス再構築をした際に課金発生。総データ容量に対して、1GBあたり0.98USD。
データ転送 データ転送のアウトについて課金。同一リージョン内は無料。

PIXTAにおける支払い内訳

上記の4つの課金項目を基に、どこにコストが多く発生しているかを特定します。

内訳のこの通りです。

f:id:watasihasitujidesu:20170313121447p:plain

一目でわかりますね。あいつです。PartitionCountがコスト圧迫の要因だとわかりました。

コスト圧迫の原因と対策

では、PartitionCountがなぜ、あんなに必要だったのかを深掘りしていきます。

インスタンス数は何によって決まるか

インスタンス数は、スケーリングによって決まります。内容は、ReplicationCountとPartitionCountによって決まります。

項目 内容
ReplicationCount トラフィックとレイテンシに影響を与える。Count数が多いと、多くのトラフィックを捌くことができ、レイテンシを低くさせる要因の一つになる。*3
PartitionCount ドメインに格納されるデータセットの総容量に依存。格納するデータが増えれば増えるほど、Partitionが必要になってくる。

したがって、今回PartitionCountが多いのは、データセットの総データ容量が大きいのが、原因だとわかります。

インスタンス数を減らすには

もう一段深掘りするために、データ容量が増える原因について見ていきます。 ここを知る & 解決することが、今回のメインとなります。

データ容量は下記3つに起因します。

  1. フィールド数が多い
  2. フィールド内のデータが大きい*4
  3. フィールドに設定している検索Optionが多い

また、これらの設定はマネジメントコンソールのサイドナビにあるIndexingOptionsから確認できます。

フィールド数が多い

f:id:watasihasitujidesu:20170313121505p:plain

当時、社内の検索機能のドメイン知識について、共有するものが足りなかったり、職人(!)による作業が多く、このフィールド消していいの?なにこれ怖い。みたいな状態になっていました。
そして、実際には使われていないフィールドが多く存在していました。

なので、まずは不要なフィールドの削除から始めました。

フィールドに設定している検索Optionが多い

f:id:watasihasitujidesu:20170313121517p:plain

次に疑うべきは検索Optionの最適化です。
検索オプションは、フィールドごとに、下記機能の使用可否を選択できます。

  • 検索対象とするか
  • ファセットを用意するか
  • 返却値としてしようするか
  • ソート対象とするか
  • ハイライトするか

詳細は公式ドキュメントが参考になります。

図を見るとわかるのですが、コスト削減前は、オプション全てにチェックが入っていました。
こちらは、検索オプションの意味や使用箇所も深く理解できていないまま、とりあえず全部チェックしてしまえ!状態だったので、一つずつ見直していくことにしました。

IndexingOptionsとIndexSizeについて補足

IndexingOptionsとインデックスサイズの関係については Amazon CloudSearch Deep Dive and Best Practices | AWS re:Invent 2014の25スライド目「Effect of options on index size」がとても参考になりました。

資料の例だと、6KBのドキュメントが2,500万件登録されていた場合に、
オプションを全くつけていない場合と、全てのオプションつけていた場合では、インデックスサイズが243%も増加していることの説明をしています。

コスト削減結果

f:id:watasihasitujidesu:20170313121529p:plain

ここまで説明した内容を実施した結果、Index再構築直後は上記のような結果になりました。 対応前は、使用率が70%台だったのに対し、対応後は30%台になりました。 コストが半分近くになったことがわかります。

まとめ

今回のコスト削減に関しては、テクニカルことは全く必要としませんでした。 それよりも

  • まずは、どんな課金体系なのか敵を知ること、
  • そして、何にいくらくらいかかっていることを知ること、
  • 最後に、何故、コストがかかっているかを知ること

これらを地道に調べることで、無駄なコストが省けたのだと思います。

ピクスタでは一緒に働くメンバーを募集しています!

*1:20107/03/13時点

*2:詳細は公式に譲ります

*3:レイテンシはネットワーク、クエリの複雑度など、多くの要素に左右されるので、ReplicationCountを増やしといって、爆速になるわけではない。

*4:今回ここについては、言及しません