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

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

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

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

導入数４万６千社、４１万ユーザー突破！導入企業例：（2014年6月現在） 0 125000 250000 375000 500000 2011 6 9 12 2012 6 9 12 2013 6 9 12 2014 6 ユーザー数：

アジェンダ • チャットワーク検索システムの変遷 • CloudSearchを採用した理由 • CloudSearchを利用した検索アーキテクチャ • CloudSearchの課題

チャットワーク検索システムの変遷

チャットワーク検索システムの変遷 • 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

CloudSearch を採用した理由

Mroonga 3.xの課題 • IOロックの発生 • 1千万件程度のメッセージ規模では、順調に稼働 • 数千万件レベルになると、 mysqldがダウンするように。。。 Thread pointer: 0x2f19350 Attempting backtrace.You can use the following information to ﬁnd 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]

Mroonga 3.xの課題 • IOロック回避のために • Mroonga+Spiderストレージエンジンを検討 • 数億のメッセージ規模で安定稼働させるには、最初から多数のMroongaノードを用意する必要あり

elasticsearch 0.9の検証 • 構成する要素が複雑 • クラスタ・ノード・インデックス・シャード、、 • サイジングが必要 • インデックス作成時にシャード数を決める • シャード数はあとから変更することができない

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

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

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

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

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

2014年3月25日に転機が

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

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

Mroonga

CloudSearch

機能要件 • 複数言語対応 • 17言語の検索に対応 • 閲覧権限を持つ全てのグループチャットの検索が可能 • 初期投入対象は約3.2億件 • 差分投入で追加・編集・削除を順次行う ja en zh_cn zh_tw ko fr de it es pt ar ru in tr hu ﬁ vi

Domain設計 • Scaling Options • Desired Instance Type: search.m2.2xlarge • Desired Partition Count: 4 • SIMPLE MONTHLY CALCULATORで試算 • http://calculator.s3.amazonaws.com/index.html

Domain設計 • Indexing Options その１ • Multiple Languages • 特定の言語に依存しない • Index Fieldをひとつだけ用意

Domain設計 • Indexing Options その２ • 言語ごとにIndex Fieldを作成、言語判定ライブラリは別途用意 • 言語判定が必要なため、今回はこちらを採用 • https://code.google.com/p/language-detection/

3.2億件の初期投入結果 • SQSで分割、documents/batch requestを利用 • 投入用Worker: c3.8xlarge x 1 • 30並列で実行 • 処理時間は約12時間

差分投入構成 • チャットメッセージ送信・編集・削除ごとにSQS作成 • チャットメッセージ履歴Tableを作成、更新範囲をSQS でキューイング、まとめて投入 • 投入用Worker: c3.large • この構成で、大きな遅延なくIndexできている

CloudSearchの課題

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

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

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

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

さいごに

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

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

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

by Yoshinori Fujiwara, サーバーエンジニア at ChatWork 株式会社

on Jul 18, 2014

Statistics

Views

Actions

2 Embeds 0

Accessibility

Categories

Upload Details

Usage Rights

Report content

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