AWS Summit Tokyo 2014 2014/7/18

1. 【初公開】チャットワーク
検索機能を支える技術
- AWS Summit Tokyo 2014 -
2014/7/18
藤原吉規

2. -自己紹介 -
ChatWork株式会社
サーバーエンジニア 藤原 吉規
ビジネスチャットツール「チャットワーク」を展開中
東京：16人
大阪：20人
USA：6人
(New!) ルクセンブルクに子会社を設立

3. チャットワークのご紹介
クラウド型ビジネスチャットツール
チャットの効率性・シンプルさをビジネスへ
+
ビデオ通話
in the cloud
チャット タスク管理

4. 導入数 ４万６千社、４１万ユーザー突破！
導入企業例：
（2014年6月現在）
0
125000
250000
375000
500000
2011 6 9 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. CloudSearch
を採用した理由

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の検証
• ダミーメッセージ投入テストを行いながら、サイジン
グを行うTry and Errorを実施
• 検証中に発生したこと
• シャード分割数が少なすぎ、初期投入で大量データ
を投入すると、書込速度が徐々に低下
• シャード分割数を増やして、データ再投入

13. elasticsearch 0.9の検証
• サイジング対策
• インデックスを範囲で区切って、細かく分割、シャー
ドも細かく
• クラスタ構成もはじめから大きなもので
• i2.xlarge x 6 の構成を予定

14. elasticsearch 0.9の検証
• 課題
• バックアップ→☓
• Multi-AZ対応→☓
• アクセス制御→☓

15. それでも、
他に選択肢がない。。

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

17. 2014年3月25日に転機が

18. CloudSearchの検証と採用
• フルマネージドなため、サイジングが（ほぼ）不要
• 初期投入が十分速い
• 検索速度も速い
• Multi-AZ運用も可能
• Index Fileldごとにアクセス制御可能

19. CloudSearchを利用した
検索アーキテクチャ

20. Mroonga

21. CloudSearch

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. CloudSearchの課題

29. 検索
• 記号の検索に現状対応していない
• 例：C#,C++などの記号部分
• アプリケーション側で工夫が必要

30. CloudWatchの
メトリクスがない
• 代替手段
• SearchInstanceCount、SearchPartitionCount、
Searchable Documentsの取得
• SQSの残キュー数の取得

31. 認証
• search,document request発行側をScaleOutするた
めには、現状Proxyが必須
• Access PoliciesはグローバルIPのみ指定可能
• 即時反映されるわけではない
• 実測約40分程度かかる

32. コスト
• 実質的な運用コストはMroonga分割運用時と比較して、
約２倍になった
• RIが今のところ存在しない

33. さいごに

34. CloudSearch
を採用してよかったこと
• 保守運用が大幅に楽になった!
• 差分投入の安定化、初期投入速度の大幅な改善
• 検索速度の改善と安定化
• アプリケーション構成がシンプルに
• AWSサポートから、日本語でサポートを受けられる

35. ありがとうございました！