[レポート]【ランチセッション】Amazon CloudSearch Deep Dive #AWSSummit

AWS Summit Tokyo 2015

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS Summit Tokyo 2015TA-01: Tech Deep Dive by Amazon:「【ランチセッション】Amazon CloudSearch Deep Dive」のレポートです。

スピーカーはAmazon Data Services Japanの篠原英治氏です。

IMG_1883

レポート

Amazon CloudSearchとは

 SnapDishでCloudSearchが使われている。
 SnapDishでウインナーで検索→CloudSearchで検索。
  CloudSearchを使うことでサーバー運用の負担から解放された。
 フルマネージドなクラウド型検索エンジン。簡単に導入できる。
 多言語対応。34の言語。ヘブライ語なども対応している。
 ヒットしたらハイライトしたり、サジェストしたり、便利な機能がたくさん。

 CloudSearchの背景
  Amazonの最下部の検索→サーチエンジン=A9と記載されている。
  CloudSearchはA9がパロアルトで作っている。
   スタンフォード大学が近い。

 CloudSearchの使い方。例えば南北線の駅を検索する場合。
  検索ドメインの作成
  検索用のデータファイル(駅コード、駅名、路線)の作成
  データファイルのアップロード
  データを自動認識してスキーマ定義を作成
   日本語でのトークナイズの指定可能
   Dynamic FIeld機能も使える
  マネージメントコンソール上ですぐに検索できる
   or検索ももちろん可能

 Japanese Text Processing
  形態素解析→日本語はスペースで区切られていないので解析の必要がある
  名詞の辞書のメンテナンスが必要
   →CloudSearchでは辞書のカスタマイズが可能
   →APIから辞書登録もできる
  シノニム、類義語
   ベニス、ベネチア、ヴェネチア、等
   Aliasの設定ができる
   Group化も出来る
  Bi-gramでのIndexing
   Muttiple LanguagesでBi-gramでIndexingされる
    2文字ずつ区切ってしまうので検索ノイズが発生
     (例:東京都が京都でヒット)
    ノイズは発生するけど取りこぼしが少なくなる
  形態素解析とBi-gramを組み合わせて使う
   CloudSearchではSourceFieldという機能がある
    元フィールドからデータをコピーしてトークナイズする
    形態素解析のフィールドからBi-gramのフィールドを作る
   →^(カレット)を使ってソート順を調整
    形態素解析の結果を上に、Bi-gramのフィールドを下に表示したり、など
  スコア=tf-idf
   あるドキュメントによく出てきて、他のドキュメントにでてこない
    →このドキュメントでは重要性が高いと判断
  Expressions
   検索結果のチューニングに様々な手法が使える
   A/Bテスト
    マネージメントコンソール上でチューニング結果を比較しながら確認出来る

 Field Typeのカスタマイズ
  dateやint、textなど、データによってTypeを変えられる
  nanapiのCloudSearch利用法→nanapi tech blogに記述がある
 Suggestions
  ひらがなやカタカナで検索→候補を表示
 高可用性の強化→Multi-AZ対応
 IAMによるアクセス制御可能
  ユーザーやリソースによってきめ細やかな制御が可能

Inside Amazon CloudSearch

 フルマネージド
  Auto Scaling + Auto Partitioning

 Indexing
  データを保持している全てのノードにELB経由で均等にアップロード
  データを受け取ったノード→ファイルをS3に保存、メタ情報をDynamoDBに保存
  ノードではアップデート処理とは非同期でUpdaterが動作
   自Partition担当のIndexingデータがあればローカルのSolrに配置
  S3とDynamoDBの組み合わせでフルマネージドの高い信頼性が確保できている

 Query
  indexingと同様にELB経由で均等に割り振り
  リクエストを受け取ったノードがそれぞれのノードから検索(分散処理)

 Auto Scaling
  検索リクエストが大量に発生したらAuto Scalingするシンプルな仕組み

 Auto Partitioning
  最初はスケールアップしていく
   スケールアップするのでダウンタイムはない
    →切り替わり中はIndexing結果がすぐに反映されない場合がある
  最大までスケールアップしたら、次はスケールアウト
   パーティションの分割処理はHadoop(EMR)で行っている
   ダウンタイムは無いが結果整合性モデルになる→一時的に取れない場合がある
  検索ドメインの設定変更
   →変更に伴う処理はEMRで行っている
    こちらもダウンタイム無し、結果整合性モデル
  大量に初期データを投入する場合
   →あらかじめ大きなインスタンスを多数並べることで、
    短時間でIndexingを実行可能
  インスタンスタイプとデータ量の目安は?
   扱うデータによって圧縮率が異なるので、保持量に差がある。一概には言えない。
   やろうとするデータで試してみるのが一番簡単。
  大量の検索リクエストに事前に備える(予測されるバーストトラフィック)
   事前にレプリケーションカウントを上げておくことで準備可能
   インスタンスタイプとスループットの目安
    →これも扱うデータによってスループットが変わってくる

 2015年2月からm3インスタンスが利用可能に
  →安く安定して動作するようになった

Amazon CloudSearch事例

 爆速で導入→schoo
  リリースするまでに1週間程度だった
 フルマネージドの良さを活用→nanapi
  デフォルトのままでいい感じで使える
  簡単に構築できちゃう、とにかく楽
 大規模利用→Chatwork
  5億件オーバー
  導入時は大変だったがリリース後はほぼメンテナンスフリー
  データ量が増えても検索のレスポンスは落ちない
 Lancers、ごちクル、Smart/InSight、パソナキャリア、e.t.c.

さいごに

CloudSearchのバッググラウンドが聴けて非常に面白かったです!