Amazon CloudSearch 値下げ！ 2014年11月

どうも！Amazon CloudSearch が値下げされたようなので、内容をまとめてみました。なお、内容の正誤については一切こちらでは保証しませんので、きちんとご自分でご確認くださいますようお願いします。

http://aws.amazon.com/jp/blogs/aws/cloudsearch-price-reduction-plus-features/

追記：アマゾンのソリューションアーキテクトの篠原さんにコメント頂いたので、追記しました！

使用料の値下げ幅が大きいですねー。５０％オフは大きい。。。おそらく、EC2 の値下げに追随した形なんだと思います。もう一つ気になったのは、限定的ですが、パーティション数の指定が可能になったこと。インデックスの高速化が期待できそうですが、使いドコロと価格には注意ですね。

それではどうぞ。

インスタンスの時間あたりの使用料を値下げ

インスタンスの時間あたりの使用料を最大５０％まで値引きします！値引きは１１月１日以降の利用分から反映されます。１月動かしっぱなしで、search.m1.small で 95.16ドル → 42.48 ドル、search.m2.2xlarge で 1039.44 ドル → 441.36 ドルになります。いずれも us-east-1 です。*1

AWS | Amazon CloudSearch | 料金表

ヘブライ語のサポート

ヘブライ語 (Hebrew) がサポートされました。これで、トータル 34 言語になります。他言語化対応をする必要がある、検索の場合、構築がかなり楽ちんかと思います。

ちなみに、日本語についてもトークナイゼーション辞書を追加して、形態素解析の動作をカスタムできると、書いてありますが、ブログにもあるとおりで、１０月半のアップデートで追加された機能になります。こちらは、検証を軽くやってみたので、気になる方は以下のエントリを参照ください。

パーティション数の指定が可能に (ただし m2.x2large のみ)

検索ドメインの作成時に、パーティション数を指定できるようになりました。ただし、m2.x2large のみです。パーティションを指定することで、ドキュメントの更新パフォーマンスの向上や、１パーティション当たりのドキュメントが減ることによる検索パフォーマンスの向上が期待できます。

おそらく、内部的には Solr 使用されているとのことですので、シャード数として扱われる形になるかと思われますので、インデックスを分けて持つことでパフォーマンスの向上を実現する、という機能になるかと思います。このため、あまりドキュメント数が多くない状態で、パーティションを分けてもパフォーマンスの向上には、役に立たないどころか、検索時は結果のマージ処理によるオーバーヘッドが発生するので、分けない場合と比較して遅くなる場合もあります。

もう１点、ブログなどには明示されていないのですが、パーティション数を増やした場合の料金への影響です。通常、Solr でシャードを切る場合、別々のマシンにシャードを配置します。このため、インデックスの更新処理や検索処理を分散することで、高速化を図るわけです。このとおりであれば、CloudSearch も内部的にインスタンスをパーティション数に合わせて増やす必要があるので、パーティション数を増やすと料金が高くなると思われます。さらに、レプリカ数の指定と合わせると、例えばレプリカ２、パーティション２で指定すると４インスタンスが常に起動する構成になるので、注意が必要かと思います。

いずれにせよ推測なので、具体的なプライシングがどうなっているか Amazon さんに聞いてみたいところです。

追記：アマゾンのソリューションアーキテクトの篠原さんにコメント頂きました！

まとめるとこんな感じ。

インスタンス数は、レプリケーション数☓パーティション数で決まります。なお、負荷に応じて自動的にスケールアウト、スケールインするので固定ではありません。明示的に指定すると、その数を下回ることは無いので、２☓２を指定すると最低でも４インスタンスは常に稼働している計算になります。
レプリカ、パーティション共にあとで減らすことが出来ます！なので、想定よりもアクセスやドキュメント数が少なかったら、後で減らして、コストを抑えるなんてことも可能です。ただし、一時的に一貫性が失われることがあるそうで、ヒットしないドキュメントが出てきたりするので、タイミングには注意。
パーティションは、特にインデックスの更新パフォーマンスに効きます。初回のインデキシング時など大量にインデックス処理が発生するタイミングなどに使うといいんじゃないでしょうか。

@yoshi0309 ブログ執筆ありがとうございます〜！CloudSearchはEC2やRDSと同様に起動しているインスタンスの1時間毎の課金になります〜。例えばパーティションが3でレプリカが2の場合は3x2=6インスタンスという感じです。パーティションは初期移行時に(続く)
— eiji shinohara (@shinodogg) 2014, 11月 20

@yoshi0309 ガバっとマルチプロセスでやる場合に有利だったりします、レプリカは予め沢山の検索リクエストを受け付ける事が分かっている場合にやっていただくとよろしい感じです。どうしてもCloudSearchデフォルトの自動でのレプリケーションは数分のタイムラグがありますので〜
— eiji shinohara (@shinodogg) 2014, 11月 20

@yoshi0309 この辺のメカニズムは、先週WashingtonDCで行われたLucene/Solr Revolution(http://t.co/MEJmyEeTki)で開発者のA9のTomasが詳細に話してくれて、資料も近いうちに公開されますので、是非ご覧いただければと！
— eiji shinohara (@shinodogg) 2014, 11月 20

@shinodogg 早速のレスありがとうございました！大体、予想通りでした！ちなみに、ベンチマーク的な資料って公開されていたりしますか？
— よしだ (@yoshi0309) 2014, 11月 20

@yoshi0309 検索ってクエリ条件等によってイロイロ変わってきてしまうので、我々が公式に出しているベンチマークってあまりないのですが何億ドキュメントの初期投入と検索〜といった観点ではChatWorkさんの資料とかがナイスかなと〜 http://t.co/fjqfwZNBgD
— eiji shinohara (@shinodogg) 2014, 11月 20

@shinodogg もう一点だけよろしいですか？ドキュメントを見るかぎりでは、パーティション数を、後から減らすことができるみたいですが、あってますか？ http://t.co/4GWuWBsdto
— よしだ (@yoshi0309) 2014, 11月 20

@yoshi0309 はい、ご認識の通りです〜。例えばデータがガッポリ減ったりすればパーティションの数はそれに合わせて減っていきます。CloudSearchのそういった自動制御とは別に、用途に応じて(初期データ投入時など)、Desiredというオプションが用意されている感じです〜
— eiji shinohara (@shinodogg) 2014, 11月 20

@yoshi0309 ただ、どうしてもノードが増えたり減ったりしている間はEventual Consistencyなアレで、クエリでデータが取得出来たり出来なかったりするので、その辺は考慮が必要になります〜。この辺また勉強会等でシェアしていきますね :)
— eiji shinohara (@shinodogg) 2014, 11月 20