サイボウズのMySQL に対する取り組みサイボウズのMySQL に対する取り組み

サイボウズ株式会社 開発本部プロダクト開発部

ガルーン開発グループ

丹羽 純平

米川 健一

サイボウズ株式会社 開発本部プロダクト開発部

ガルーン開発グループ

丹羽 純平

米川 健一

2

目次

ガルーン ２ とは？

MySQLを使い倒したグループウェア

特徴と問題点

解決策 → 次期ガルーン

全文検索を求めて

Senna の取り込み

スケーラビリティを求めて

ガルーン 2 のスケールアウトについて

ＤＢ／テーブル分割、クエリチューニング、キャッシュ

3

ガルーン2とは？

サイボウズのWebグループウェア

http://garoon.cybozu.co.jp/

３００人以上の中規模でもＯＫ

つなガル、ひろガル、おてガル

管理者もユーザもみんなが使いやすいグループウェア

弊社のグループウェアは ７回連続顧客満足度1位

ＭｙＳＱＬを使い倒したグループウェア

4

ガルーン ２ の中身

5

ポータル画面

各アプリケーションをアイコンで分かりやすく説明。ワンクリックで目的の情報の場所に移動できます。

当日、今週のスケジュールや天気がひと目でわかります。

自分に関係があるすべての情報の新着や更新がトップページに集ります。好みにあわせて、情報の表示位置を変え、仕事のしやすい環境を作れます。

全社・所属部署・個人と目的や組織別に自由にポータルを作成できます。

グラフポートレットを使って簡単にグラフ化。数字を視覚的に表示できます。

≪個人ポータル画面≫

≪企業ポータル画面≫

6

スケジュール機能

見たい予定の期間を選択できます。

所属部署のメンバや他部署の社員の予定、会議室や備品の予約まで一覧で把握できます。

予定はクリック操作だけで時間、メンバー、会議室まですべて登録できます。

予約登録時にメンバーや会議室の空き時間を確認して、予定を調整できます。

7

ガルーン2を支える技術

ＣｙDE２ーフレームワーク

ＭｙＳＱＬ４＋ＰＨＰ４＋Ｓｍａｒｔｙ

8

現行ガルーン２が抱える障壁

スケーラビリティの壁

現行バージョンでは分間アクセス 1,500を上限

更なるスケールアップ

遅い・・・

検索機能の壁

現バージョンでは検索は LIKE のみ

アクセス権の評価をするため、複雑なSQL処理が必要

SELECT * FROM bulletin WHERE article LIKE ’%hoge%’ AND (アクセス権);

9

次期ガルーン

スケーラビリティを求めて 検索機能を求めて

・Sennaの取り込み

・ＭｙＳＱＬ+Senna → Tritonnを利用

・DB分割

・ユーザ単位でテーブル分割

・キャッシュを活用（memcached）

全文検索全文検索

11

全文検索エンジン

FAST

インターネット

Google Search Appliance

イントラネット

Lucene, HyperEstraier, Senna

アプリケーション

オープンソース多数

Hit！

12

Ｓｅｎｎａ

組み込み用の高速全文検索エンジン

MySQLやPostgreSQL、Ruby等に対応

アプリ側から見たら、普通にMySQLを使用

(有)未来検索ブラジルにおいて開発

http://qwik.jp/senna/

LGPL

13

Tritonn （MySQL + Senna）

MySQLのソースにパッチ

MySQLの上位層がSennaを隠蔽

FULLTEXTのINDEXの処理時にSennaが使用される

Ｍｙ ＳＱＬ

MEMORY Inno DB MyISAM

SQL文解析 → 最適化 → データ検索/格納

patch

Senna

RAM .sen.iibdata1 .MYD .MYI

(HEAP)

引用元 : http://qwik.jp/tritonn/about.html

14

ガルーンの全文検索

検索機能

「横串検索」

ガルーン内の複数のアプリケーションを横断して検索

「全文検索」

ガルーン内に保存されたファイルの中身も検索

（例：WordやExcelやPowerpointやpdfファイル）

テキスト抽出フィルター

ＴＦライブラリ（データ変換研究所）を使用

http://www.dehenken.co.jp/products/products-01/products-tf01.html

高速なアクセス権評価が必須

データとACL（アクセス制御リスト）のクローリング

15

全文検索の構成

データ収集エンジン

・クローラ →データとACL

・インデクサ→テキスト抽出フィルタ

→クロールしたデータの追加

データの変更/削除

検索エンジン

・認証

・ＳＱＬ実行

×

設定画面

16

Crawler

Queue

Indexer

MySQL+

Senna

filter

filter

filter

filter…

クロール間隔やスレッド数は設定ファイルで変更可能

…

acl_id,uid list

Crawler

Data

ACL

Use bulk transfer

APIACL

Data

データ収集エンジンの概観

acl_id,uid list

GRN

17

検索エンジンの概観

Servlet

画面作成API

・リモートサービス対応のため検索エンジンには直接アクセスできない。

・ガルーンを通じて検索サーバにアクセス

GRN…

DB

18

検索 ＳＱＬ 実行

掲示板

title data …検索

社内メール

title data …

……

スコア／日付でマージ

select * from tab_grn_bulletinwhere (MATCH (title, data) AGAINST (‘hoge’) ）

select * from tab_grn_messagewhere (MATCH (title, data) AGAINST (‘hoge’) ）

検索

＋

＋

…acl_id

acl_id

acl_id uid

acl_id uid

JOIN

JOIN

データテーブル ＡＣＬ評価テーブル

19

•UIDの比較

•データテーブルをユーザ毎に用意

ACL評価

・ACL評価テーブルにUIDが含まれているか？

・object単位でACLの評価を行うと高コスト

→カテゴリ単位、フォルダ単位

・クロールされるデータには、ACL評価テーブルのIDが含まれる

・ＧＲＡＮＴモデルでもREVOKEモデルでもOK

共有系

ＰＩＭ系

20

プロトタイプ

検索画面

検索結果

21

まとめ

高性能全文検索機能

Tritonn（＝ＭｙＳＱＬ＋Ｓｅｎｎａ）

お手軽、高速

プロトタイプ完成

Sennaの進化

マルチセクション機能

NGRAMの文字種分割の制御

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

23

現行ガルーン ２ スケーラビリティの壁

Webサーバーは複数台構成ができるが

DBサーバーはできない

分間1500アクセスを上限

24

現行ガルーン ２ の構成

WEBサーバ WEBサーバ WEBサーバ

DBサーバ

DBサーバーに負荷が集中

ロードバランサ

25

壁を越えるために

機能単位のDB分散

クエリチューニング

Memcachedの導入

ユーザー単位のテーブル分割

テーブル分割 + DB分散

26

スケールアウト後の構成

DBサーバ DBサーバ DBサーバ

Memcached Memcached Memcached

ロードバランサ

WEBサーバ WEBサーバ WEBサーバ

27

スケールアウト効果

5,000 アクセス/分の利用頻度でも快適に動作

→弊社ではWeb15台 / DB7台の構成で検証

→機能ごとの分割なので限界はある

サーバーを増やせば更に伸ばすことも可能

28

レスポンスタイム(現行ガルーン 2)

以降エラーしか返さない

レスポンスタイム

経過時間

29

スケールアウト後

レスポンスタイム

経過時間

30

スループット

スケールアウト後

ガルーン 2.1.2

経過時間

処理量

31

機能単位のDB分散

負荷の高い機能のテーブルを別のDBに分散する

ユーザー情報などの共通テーブルはマスタDBに配置してレプリケーションする

共通テーブルの更新は常にマスタへ

分散するアプリはインストール時に設定する→ 運用中の変更は考慮しない

32

マスタDB

レプリケーション

ユーザーテーブル組織テーブル

…

共通テーブルへの更新

各アプリケーションへの更新

ユーザーテーブル組織テーブル

…

スケジュールテーブル

ユーザーテーブル組織テーブル

…社内メールテーブル

スケジュールDB 社内メールDB

33

クエリチューニング

スロークエリログに出現した遅いクエリを排除して

レスポンスを上げる

純粋なパフォーマンスチューニング- インデックスを追加 / 張り直す- 正しいインデックスを使うようにする- 非正規化

34

Memcachedの導入

更新の少ないデータをキャッシュしてクエリの数を減らす

複数のMemcachedサーバーを登録して負荷を分散できる

ダウンしているMemcachedへのアクセスは自動でフェイルオーバーさせることができる

35

ユーザー単位のテーブル分割

ユーザー毎のデータをテーブル分割- アプリケーションの通知, メール, etc…

1テーブルに格納されるレコード数を減らす

個人データの書き込み処理を分散

36

_id col_user ….

1 100 ….2 200 ….

_id ….

1 ….

tab_grn_notification_notfy___100 tab_grn_notification_notfy___200

tab_grn_notification_notify

_id ….

1 ….

37

大量テーブルと参照性制約による弊害

col_userはユーザーテーブルに参照性制約を

設定している

テーブルに対してクエリを実行すると子テーブルと子テーブルに参照性制約を設定しているテーブルを全て開こうとする

MySQL起動後のそのテーブルに対する最初のクエリのみこの現象が起きる

38

ユーザーテーブル分割＋DB分散

分割したユーザー毎テーブルを更に別のDBへ

分散する

どのDBにどのユーザーのテーブルを配置するかは、ユーザーIDで範囲指定して設定する

39

host1

_id col_user ….1 100 ….2 2003 1500 ….

tab_grn_notification_notify

tab_grn_notification_notfy___100

tab_grn_notification_notfy___200tab_grn_notification_notfy___1500

例) ユーザーID1～1000のユーザーをhost1にユーザーID1001～2000のユーザーをhost2に

host2

40

その他のチューニング

mod_phpに対応

APCによるPHPスクリプトキャッシュ

ログテーブルのエンジンをMyISAMに変更

41

まとめ

アプリケーション単位でDBを分散して負荷を減らす

クエリチューニングで重いクエリを排除する

Memcachedを導入してクエリの数を減らす

ユーザーごとのデータを分割して共通テーブルの負荷も分散する

42

今後の課題 / 展望

複数ユーザーの個人データに対する更新処理のパフォーマンス

分割により大量に作られるテーブルへの対策

ユーザーごとの分割ではなく、1サーバーに1テーブルでよいかもしれない

MySQL5.1のパーティショニング

行ベースレプリケーション

InnoDB 以外のストレージエンジンの検討

43

ご清聴ありがとうございました。

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

ご清聴ありがとうございました。

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