• Like
  • Save
【初公開】チャットワーク検索機能を支える技術
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

【初公開】チャットワーク検索機能を支える技術

  • 15,045 views
Published

AWS Summit Tokyo 2014 …

AWS Summit Tokyo 2014
2014/7/18

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
15,045
On SlideShare
0
From Embeds
0
Number of Embeds
19

Actions

Shares
Downloads
0
Comments
0
Likes
52

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 【初公開】チャットワーク 検索機能を支える技術 - AWS Summit Tokyo 2014 - 2014/7/18 藤原吉規
  • 2. -自己紹介 - ChatWork株式会社 サーバーエンジニア 藤原 吉規 ビジネスチャットツール「チャットワーク」を展開中 東京:16人 大阪:20人 USA:6人 (New!) ルクセンブルクに子会社を設立
  • 3. チャットワークのご紹介 クラウド型ビジネスチャットツール チャットの効率性・シンプルさをビジネスへ + ビデオ通話 in the cloud チャット タスク管理
  • 4. 導入数 4万6千社、41万ユーザー突破! 導入企業例: (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 その1 • Multiple Languages • 特定の言語に依存しない • Index Fieldをひとつだけ用意
  • 25. Domain設計 • Indexing Options その2 • 言語ごとに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分割運用時と比較して、 約2倍になった • RIが今のところ存在しない
  • 33. さいごに
  • 34. CloudSearch を採用してよかったこと • 保守運用が大幅に楽になった! • 差分投入の安定化、初期投入速度の大幅な改善 • 検索速度の改善と安定化 • アプリケーション構成がシンプルに • AWSサポートから、日本語でサポートを受けられる
  • 35. ありがとうございました!