【初公開】チャットワーク検索機能を支える技術
- 1. 【初公開】チャットワーク 検索機能を支える技術 - AWS SummitTokyo 2014 - 2014/7/18 藤原吉規
- 2. -自己紹介 - ChatWork株式会社 サーバーエンジニア 藤原吉規 ビジネスチャットツール「チャットワーク」を展開中 東京：16人 大阪：20人 USA：6人 (New!) ルクセンブルクに子会社を設立
- 3.
- 4. 導入数 ４万６千社、４１万ユーザー突破！ 導入企業例： （2014年6月現在） 0 125000 250000 375000 500000 2011 69 12 2012 6 9 12 2013 6 9 12 2014 6 ユーザー数：
- 5. アジェンダ • チャットワーク検索システムの変遷 • CloudSearchを採用した理由 •CloudSearchを利用した検索アーキテクチャ • CloudSearchの課題
- 6.
- 7. チャットワーク 検索システムの変遷 • Mroonga単体構成：2011/9∼ • Mroonga分割構成：2013/5∼ •elasticsearch検討：2013/6∼ • CloudSearch検討：2014/4∼ 0 75,000,000 150,000,000 225,000,000 300,000,000 2013/6 2014/1 2014/6
- 8.
- 9. Mroonga 3.xの課題 • IOロックの発生 •1千万件程度のメッセー ジ規模では、順調に稼働 • 数千万件レベルになると、 mysqldがダウンするよ うに。。。 Thread pointer: 0x2f19350 Attempting backtrace.You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 7f5da7047e68 thread_stack 0x40000 /usr/local/mysql/bin/mysqld(my_print_stacktrace+0x29)[0x750bd9] /usr/local/mysql/bin/mysqld(handle_fatal_signal+0x35c)[0x654fcc] /lib64/libpthread.so.0(+0xf500)[0x7f61c05e5500] /usr/lib64/libgroonga.so.0(grn_ii_cursor_next_pos+0x237)[0x7f61bc9028f7] /usr/lib64/libgroonga.so.0(grn_ii_select+0x8aa)[0x7f61bc90aa0a] /usr/lib64/libgroonga.so.0(grn_ii_sel+0xec)[0x7f61bc90be9c] /usr/lib64/libgroonga.so.0(grn_obj_search+0x2b5)[0x7f61bc871135] /usr/lib64/libgroonga.so.0(grn_table_select+0x7ee)[0x7f61bc87c4de]
- 10. Mroonga 3.xの課題 • IOロック回避のために •Mroonga+Spiderストレージエンジンを検討 • 数億のメッセージ規模で安定稼働させるには、最初 から多数のMroongaノードを用意する必要あり
- 11. elasticsearch 0.9の検証 • 構成する要素が複雑 •クラスタ・ノード・インデックス・シャード、、 • サイジングが必要 • インデックス作成時にシャード数を決める • シャード数はあとから変更することができない
- 12. elasticsearch 0.9の検証 • ダミーメッセージ投入テストを行いながら、サイジン グを行うTryand Errorを実施 • 検証中に発生したこと • シャード分割数が少なすぎ、初期投入で大量データ を投入すると、書込速度が徐々に低下 • シャード分割数を増やして、データ再投入
- 13. elasticsearch 0.9の検証 • サイジング対策 •インデックスを範囲で区切って、細かく分割、シャー ドも細かく • クラスタ構成もはじめから大きなもので • i2.xlarge x 6 の構成を予定
- 14. elasticsearch 0.9の検証 • 課題 •バックアップ→☓ • Multi-AZ対応→☓ • アクセス制御→☓
- 15.
- 16.
- 17.
- 18. CloudSearchの検証と採用 • フルマネージドなため、サイジングが（ほぼ）不要 • 初期投入が十分速い •検索速度も速い • Multi-AZ運用も可能 • Index Fileldごとにアクセス制御可能
- 19.
- 20.
- 21.
- 22. 機能要件 • 複数言語対応 • 17言語の検索に対応 •閲覧権限を持つ全てのグループチャットの検索が可能 • 初期投入対象は約3.2億件 • 差分投入で追加・編集・削除を順次行う ja en zh_cn zh_tw ko fr de it es pt ar ru in tr hu fi vi
- 23. Domain設計 • Scaling Options •Desired Instance Type: search.m2.2xlarge • Desired Partition Count: 4 • SIMPLE MONTHLY CALCULATORで試算 • http://calculator.s3.amazonaws.com/index.html
- 24. Domain設計 • Indexing Optionsその１ • Multiple Languages • 特定の言語に依存しない • Index Fieldをひとつだけ用意
- 25. Domain設計 • Indexing Optionsその２ • 言語ごとにIndex Fieldを作成、言語判定ライブラリ は別途用意 • 言語判定が必要なため、今回はこちらを採用 • https://code.google.com/p/language-detection/
- 26. 3.2億件の初期投入結果 • SQSで分割、documents/batch requestを利用 •投入用Worker: c3.8xlarge x 1 • 30並列で実行 • 処理時間は約12時間
- 27. 差分投入構成 • チャットメッセージ送信・編集・削除ごとにSQS作成 • チャットメッセージ履歴Tableを作成、更新範囲をSQS でキューイング、まとめて投入 •投入用Worker: c3.large • この構成で、大きな遅延なくIndexできている
- 28.
- 29. 検索 • 記号の検索に現状対応していない • 例：C#,C++などの記号部分 •アプリケーション側で工夫が必要
- 30. CloudWatchの メトリクスがない • 代替手段 • SearchInstanceCount、SearchPartitionCount、 SearchableDocumentsの取得 • SQSの残キュー数の取得
- 31. 認証 • search,document request発行側をScaleOutするた めには、現状Proxyが必須 •Access PoliciesはグローバルIPのみ指定可能 • 即時反映されるわけではない • 実測約40分程度かかる
- 32.
- 33.
- 34. CloudSearch を採用してよかったこと • 保守運用が大幅に楽になった! • 差分投入の安定化、初期投入速度の大幅な改善 •検索速度の改善と安定化 • アプリケーション構成がシンプルに • AWSサポートから、日本語でサポートを受けられる
- 35.