http://cydn.cybozu.co.jp/

1. サイボウズの
MySQL に対する取り組み
サイボウズ株式会社 開発本部
サイボウズ株式会社 開発本部
プロダクト開発部
プロダクト開発部
ガルーン開発グループ
ガルーン開発グループ
丹羽 純平
丹羽 純平
米川 健一
米川 健一

2. 目次
ガルーン ２ とは？
MySQLを使い倒したグループウェア
特徴と問題点
解決策 → 次期ガルーン
全文検索を求めて
Senna の取り込み
スケーラビリティを求めて
ガルーン 2 のスケールアウトについて
ＤＢ／テーブル分割、クエリチューニング、キャッシュ
2

3. ガルーン2とは？
サイボウズのWebグループウェア
http://garoon.cybozu.co.jp/
３００人以上の中規模でもＯＫ
つなガル、ひろガル、おてガル
管理者もユーザもみんなが使いやすいグループウェア
弊社のグループウェアは ７回連続顧客満足度1位
ＭｙＳＱＬを使い倒したグループウェア
3

4. ガルーン ２ の中身
4

5. ポータル画面
各アプリケーションをアイコンで分かりやすく説明。
ワンクリックで目的の情報の場所に移動できます。
全社・所属部署・個人と目的や組織別
に自由にポータルを作成できます。
当日、今週のスケジュールや
天気がひと目でわかります。
グラフポートレットを使って
簡単にグラフ化。数字を
視覚的に表示できます。
≪企業ポータル画面≫
自分に関係があるすべての情報の新着や更新がトップペー
≪個人ポータル画面≫ ジに集ります。好みにあわせて、情報の表示位置を変え、仕
事のしやすい環境を作れます。
5

6. スケジュール機能
見たい予定の期間を選択できます。 予定はクリック操作だけ
で時間、メンバー、会議
室まですべて登録できま
す。
所属部署のメンバや他部署
の社員の予定、会議室や備
品の予約まで一覧で把握で
予約登録時にメンバーや
きます。
会議室の空き時間を確認
して、予定を調整できます。
6

7. ガルーン2を支える技術
ＣｙDE２ーフレームワーク
ＭｙＳＱＬ４＋ＰＨＰ４＋Ｓｍａｒｔｙ
7

8. 現行ガルーン２が抱える障壁
スケーラビリティの壁
現行バージョンでは分間アクセス 1,500を上限
更なるスケールアップ
検索機能の壁
現バージョンでは検索は LIKE のみ
アクセス権の評価をするため、複雑なSQL処理が必要
SELECT * FROM bulletin
WHERE article LIKE ’%hoge%’ AND (アクセス権);
遅い・・・
8

9. 次期ガルーン
検索機能を求めて
スケーラビリティを求めて
・DB分割 ・Sennaの取り込み
・ユーザ単位でテーブル分割 ・ＭｙＳＱＬ+Senna
→ Tritonnを利用
・キャッシュを活用（memcached）
9

10. 全文検索
全文検索

11. 全文検索エンジン
FAST
インターネット
Google Search Appliance
イントラネット
Hit！
Lucene, HyperEstraier, Senna
アプリケーション
オープンソース多数
11

12. Ｓｅｎｎａ
組み込み用の高速全文検索エンジン
MySQLやPostgreSQL、Ruby等に対応
アプリ側から見たら、普通にMySQLを使用
(有)未来検索ブラジルにおいて開発
http://qwik.jp/senna/
LGPL
12

13. Tritonn （MySQL + Senna）
MySQLのソースにパッチ
MySQLの上位層がSennaを隠蔽
Ｍｙ ＳＱＬ FULLTEXTのINDEX
の処理時にSennaが
SQL文解析 → 最適化 → データ検索/格納 使用される
patch
MEMORY Inno DB MyISAM
Senna
(HEAP)
.MYD .MYI
ibdata1
RAM .sen.i
引用元 : http://qwik.jp/tritonn/about.html
13

14. ガルーンの全文検索
検索機能
「横串検索」
ガルーン内の複数のアプリケーションを横断して検索
「全文検索」
ガルーン内に保存されたファイルの中身も検索
（例：WordやExcelやPowerpointやpdfファイル）
テキスト抽出フィルター
ＴＦライブラリ（データ変換研究所）を使用
http://www.dehenken.co.jp/products/products-01/products-tf01.html
高速なアクセス権評価が必須
データとACL（アクセス制御リスト）のクローリング
14

15. 全文検索の構成
データ収集エンジン 検索エンジン
・クローラ →データとACL ・認証
・インデクサ→テキスト抽出フィルタ
・ＳＱＬ実行
→クロールしたデータの追加
データの変更/削除
×
設定画面
15

16. データ収集エンジンの概観
Crawler
Data
Indexer
filter
… filter
API
Queue
ACL
MySQL
acl_id,
filter +
GRN uid list
Senna
…
Data filter Use bulk transfer
acl_id,
uid list Crawler
クロール間隔やスレッド数は
ACL
設定ファイルで変更可能
16

17. 検索エンジンの概観
Servlet
画面作成
API
…
GRN
DB
・リモートサービス対応のため検索エンジンには直接アクセスできない。
・ガルーンを通じて検索サーバにアクセス
17

18. 検索 ＳＱＬ 実行
データテーブル ＡＣＬ評価テーブル
title data acl_id … acl_id uid
検索
＋
スコア／日付で
JOIN
マージ
掲示板
select * from tab_grn_bulletin
where (MATCH (title, data) AGAINST (‘hoge’) ）
……
title data …
acl_id acl_id uid
検索
＋
JOIN
社内メール
select * from tab_grn_message
where (MATCH (title, data) AGAINST (‘hoge’) ）
18

19. ACL評価
ＰＩＭ系
•UIDの比較
•データテーブルをユーザ毎に用意
共有系
・ACL評価テーブルにUIDが含まれているか？
・object単位でACLの評価を行うと高コスト
→カテゴリ単位、フォルダ単位
・クロールされるデータには、ACL評価テーブルのIDが含まれる
・ＧＲＡＮＴモデルでもREVOKEモデルでもOK
19

20. プロトタイプ
検索画面
検索結果
20

21. まとめ
高性能全文検索機能
Tritonn（＝ＭｙＳＱＬ＋Ｓｅｎｎａ）
お手軽、高速
プロトタイプ完成
Sennaの進化
マルチセクション機能
NGRAMの文字種分割の制御
21

22. ガルーン ２ のスケールアウトについて
ガルーン ２ のスケールアウトについて

23. 現行ガルーン ２ スケーラビリティの壁
Webサーバーは複数台構成ができるが
DBサーバーはできない
分間1500アクセスを上限
23

24. 現行ガルーン ２ の構成
ロードバランサ
WEBサーバ WEBサーバ WEBサーバ
DBサーバ
DBサーバーに負荷が集中
24

25. 壁を越えるために
機能単位のDB分散
クエリチューニング
Memcachedの導入
ユーザー単位のテーブル分割
テーブル分割 + DB分散
25

26. スケールアウト後の構成
ロードバランサ
WEBサーバ WEBサーバ WEBサーバ
Memcached Memcached Memcached
DBサーバ DBサーバ DBサーバ
26

27. スケールアウト効果
5,000 アクセス/分の利用頻度でも快適に動作
→弊社ではWeb15台 / DB7台の構成で検証
サーバーを増やせば更に伸ばすことも可能
→機能ごとの分割なので限界はある
27

28. レスポンスタイム(現行ガルーン 2)
レ
ス
ポ
ン
ス
タ 以降エラーしか返さない
イ
ム
経過時間
28

29. スケールアウト後
レ
ス
ポ
ン
ス
タ
イ
ム
経過時間
29

30. スループット
スケールアウト後
ガルーン 2.1.2
処
理
量
経過時間
30

31. 機能単位のDB分散
負荷の高い機能のテーブルを別のDBに分散する
ユーザー情報などの共通テーブルはマスタDBに配置してレプリ
ケーションする
共通テーブルの更新は常にマスタへ
分散するアプリはインストール時に設定する
→ 運用中の変更は考慮しない
31

32. マスタDB
共通テーブルへの更新
ユーザーテーブル
組織テーブル
…
レプリケーション
各アプリケーションへの
更新
スケジュールDB 社内メールDB
ユーザーテーブル
ユーザーテーブル
組織テーブル
組織テーブル
社内メールテーブル
スケジュールテーブル
… …
32

33. クエリチューニング
スロークエリログに出現した遅いクエリを排除して
レスポンスを上げる
純粋なパフォーマンスチューニング
- インデックスを追加 / 張り直す
- 正しいインデックスを使うようにする
- 非正規化
33

34. Memcachedの導入
更新の少ないデータをキャッシュしてクエリの数を
減らす
複数のMemcachedサーバーを登録して負荷を分
散できる
ダウンしているMemcachedへのアクセスは自動で
フェイルオーバーさせることができる
34

35. ユーザー単位のテーブル分割
ユーザー毎のデータをテーブル分割
- アプリケーションの通知, メール, etc…
1テーブルに格納されるレコード数を減らす
個人データの書き込み処理を分散
35

36. tab_grn_notification_notify
_id col_user ….
1 100 ….
2 200 ….
tab_grn_notification_notfy___100 tab_grn_notification_notfy___200
_id …. _id ….
1 …. 1 ….
36

37. 大量テーブルと参照性制約による弊害
col_userはユーザーテーブルに参照性制約を
設定している
テーブルに対してクエリを実行すると
子テーブルと子テーブルに参照性制約を
設定しているテーブルを全て開こうとする
MySQL起動後のそのテーブルに対する
最初のクエリのみこの現象が起きる
37

38. ユーザーテーブル分割＋DB分散
分割したユーザー毎テーブルを更に別のDBへ
分散する
どのDBにどのユーザーのテーブルを
配置するかは、ユーザーIDで範囲指定して設定する
38

39. 例) ユーザーID1～1000のユーザーをhost1に
ユーザーID1001～2000のユーザーをhost2に
tab_grn_notification_notify
_id col_user ….
1 100 ….
2 200
3 1500 ….
host2
host1
tab_grn_notification_notfy___100 tab_grn_notification_notfy___1500
tab_grn_notification_notfy___200
39

40. その他のチューニング
mod_phpに対応
APCによるPHPスクリプトキャッシュ
ログテーブルのエンジンをMyISAMに変更
40

41. まとめ
アプリケーション単位でDBを分散して負荷を減らす
クエリチューニングで重いクエリを排除する
Memcachedを導入してクエリの数を減らす
ユーザーごとのデータを分割して共通テーブルの
負荷も分散する
41

42. 今後の課題 / 展望
複数ユーザーの個人データに対する更新処理の
パフォーマンス
分割により大量に作られるテーブルへの対策
ユーザーごとの分割ではなく、1サーバーに1テーブルでよいかもしれない
MySQL5.1のパーティショニング
行ベースレプリケーション
InnoDB 以外のストレージエンジンの検討
42

43. ご清聴ありがとうございました。
http://cydn.cybozu.co.jp/
43