AWS Summit Tokyo 2014: Chatwork検索機能を支える技術

ChatworkがAWSで作られているのは周知の事実でしたが、これだけのものをどう構築しているのかはとても気になっていました。

ガンホーのセッションとどちらにいくかを迷いましたが、日頃お世話になっているChatworkのほうを聞きにきました。

オープンソースの検索ミドルウェアがいくつか選択肢があり、特別なノウハウが無くても検索システムを作ることは可能な時代になってきました。ただしその運用は簡単じゃなく、大量データの投入, 検索速度, バックアップなど課題が多いと思っています。

私も大規模なElasticSearchクラスタを運用していますが、このセッションでもあった通り、心が折れそうになる気持ちは分かります。その道のスペシャリストになれればよいのですが、それだけの仕事をしているわけではないので・・・中途半端に手を出すとやけどしますね。

そんななかでChatworkがあれだけの規模をなんとか動かし続けているのはCloudsearchのおかげな部分が大きいということです。やはり少人数で回すには、フルマネージドサービスさま様ですね。。。

Chatowkの規模：4万6千社、41万ユーザー

Chatwork検索システムの変遷

Mroonga 3.0の課題
- IOロックの発生
- 一千万件程度では順調
- 数千万件レベルになるとMySQLがダウンするように。。。
IOロックを回避するために Mroonga + Spiderストレージエンジンを検討数億のメッセージ規模で安定稼働させるには、最初から多数のMroongaノードを用意する必要あり
Elasticsearch 0.9の検証構成する要素が複雑: クラスター、ノード、インデックス、シャードサイジングが必要インデックス作成時にシャード数を決めるシャード数は後から変更できない
ダミーメッセージ投入テストを行いながらTry and Error
シャード分割数が少なすぎ、書き込み速度が徐々に低下、シャード分割数を増やしてデータ再投入
サイジング対策インデックスを範囲で区切って細かく分割, シャードも細かく、クラスタ構成も大きなもので
i2.xlarge x 6の構成を予定
課題
- バックアップｘ
- Multi-az x
- アクセス制御 x

もっとカジュアルに検索システムを開発・運用したい。

2014/3にCloudsearch大幅アップデートで検証開始
- 初期投入が十分早い
- 検索速度も早い
- Multi-AZ運用が可能
- Index Fieldごとにアクセス制御可能

キューを通してワーカーがDynamoDBに履歴を作って、それをまとめてCloudsearchに入れる構成

複数言語対応
閲覧権限を持つ全てのGroupChat
初期投入対象は3.2億件
差分投入で追加、編集、削除を順次行う
Domain設計
- Scaling Options:
  - search.m2.2xlarge
  - partition count: 4
- Index Option
  - (Multiple Language: 特定の言語に依存しない index fieldを一つ用意)
  - 言語ごとにIndex fieldを作成、言語判定ライブラリを用意
3.2億件の初期データ投入結果
- SQSで分割 documents/batch requestを利用
- c3.8xlargeをworker
- 30並列で実行
- 12時間
- データ投入自体にかかったコストは450ドルくらい
差分投入
- チャットメッセージ編集・追加・削除ごとにSQS作成
- 一定以上たまったらworkerがまとめて投入
- この構成で大きな遅延なくindexできている

検索
- 記号の検索に対応していない
- アプリケーション側で工夫が必要
Cloudwatchのメトリクスがない
- 代替手段として、describe
- SQSの残キュー数の取得
- muninを使用
認証
- Scaleoutするためには、現状Proxyが必要
- access policyはグローバルIPが指定可能だが、即時反映されない、実質４０分程度かかる
コスト
- 実質的な運用コストはMroonga分割運用時と比較して約２倍になった
- リザーブドインスタンスがない