Post on 12-Nov-2014
description
田中 裕一サイボウズ株式会社
開発本部開発部
ガルーン開発グループ
12-B-6
PHP/MySQL を用いた大規模向けパッケージソフトウェア開発
自己紹介
田中裕一
2007年４月入社
ガルーン開発グループ所属
これまで係わった製品
ガルーン2.5.0
ガルーン2.5.1
ガルーン2.5.2
現在：次世代ガルーン開発
目次
ガルーン２とは
サービスとパッケージの違い
パッケージ製品独自の開発ノウハウ
今後の課題
ガルーン2とは
Webグループウェアパッケージ
ターゲット
300～10000人規模の企業
コンセプト
おてがる
ひろがる
つながる
顧客満足度調査8年連続No.1
ポータル画面 各アプリケーションをアイコンで分かりやすく説明。ワンクリックで目的の情報の場所に移動できます。
自分に関係があるすべての情報の新着や更新がトップページに集ります。好みにあわせて、情報の表示位置を変え、仕事のしやすい環境を作れます。
アーキテクチャ
MySQLPHPSmarty
フレームワークCyDE2
ユーザー管理SSO
ポートレットアプリ管理など共通設定
スケジュール 掲示板 ファイル管理 …
ベースシステム
アプリケーション
ガルーン２とWebサービス
Webサービスと似ているところ
ブラウザから操作
PHP/MySQL
Webサービスと異なるところ
ユーザーがインストールする
ユーザーが管理する
ユーザーがリソース追加する
パッケージ製品は
管理者にも愛されなければ負け
トピック
導入時
システム構成
インストール
運用時
システム構成の変更
定期的な処理の実行
大容量データ対策
トピック
導入時
システム構成
インストール
運用時
システム構成の変更
定期的な処理の実行
大容量データ対策
柔軟なシステム構成
対応環境
Linux
Windows
サーバー構成
単体構成
Web多重構成
DB分割構成
単体構成
1台のサーバで
DB
Web
PHP
Linuxで1000ユーザーまで利用可能(※)
※ CPU :QuadCore Xeon 5460 3.16GHz × 2メモリ:4GBメールアプリケーションは未使用
Webサーバー
アプリケーションサーバー
DBサーバー
Web多重構成
Webサーバー × 複数
DBサーバー × 1
ロードバランサー
DBサーバー
Webサーバー
アプリケーションサーバー
Webサーバー
アプリケーションサーバー
ロードバランサー
DB分割構成
Webサーバー × 複数
DBサーバー × 複数
ロードバランサー
DBサーバー
Webサーバー
アプリケーションサーバー
Webサーバー
アプリケーションサーバー
ロードバランサー
DBサーバー
DB分割構成
アプリケーション単位でテーブルを分割
共通テーブルはレプリケーション
共通テーブルの更新はマスタDBへ
スケジュールDB
社内メールDB
マスタDB
ユーザーテーブル
組織テーブル
…
ユーザーテーブル
組織テーブル
スケジュールテーブル
…
ユーザーテーブル
組織テーブル
社内メールテーブル
…
レプリケーション
共通テーブルへの更新
DB分割構成
サイボウズの検証で1万人まで対応
Webサーバー × 15 CPU:Dual Core Xeon 5160 3GHz (L2キャッシュ4MB) × 2
メモリ：4GB
DBサーバー × 7 CPU:Dual Core Xeon 5160 3GHz (L2キャッシュ4MB) × 2
メモリ：4GB（2台は8GB）
どの構成を取ったらよいのか？
サイジング情報
検証データを元に作成
検証方法
LoadRunnerを使用
ユーザーアクセスをシミュレート
時間が経つにつれてアクセスユーザーを増やしていく
4秒ルール
4秒以内にページが表示されればOK
バリエーション
サーバー構成
ユーザー数
使用するアプリケーション
アクセスの種類
参照系 ：閲覧のみを行う
書込系 ：掲示板や予定の登録を行う
更新系 ：掲示板などにコメントを書き込む
他操作系：マイナーなアプリケーションの操作
検証結果グラフ
経過時間
レスポンスタイム
トピック
導入時
システム構成
インストール
運用時
システム構成の変更
定期的な処理の実行
大容量データ対策
インストール
設定不要
Webサーバー
DBサーバー
Webサーバーの設定が不要
cbgrn (インストールディレクトリ)
code (PHPスクリプト置き場)
grn.cgi (PHP処理系 + 独自パッチ)
cgi-bin
…
http://localhost/cgi-bin/cbgrn/grn.cgi/schedule/index
codeディレクトリ以下を見に行く(ように処理系にパッチ)
CGIとしてPHP処理系を直接実行
インストールディレクトリ内で完結
DBサーバーの設定も不要
my.ini(MySQLの設定ファイル)
検証により最適値を割り出し
サーバーのメモリ搭載量で値を切り替える
規定値 0GB –1GB
1GB –2GB
2GB –3GB
3GB –4GB
4GB-
sort_buffer_size 512K 512K 512K 512K 512K 1M
join_buffer_size 2M 2M 2M 3M 3M 3M
read_buffer_size 512K 512K 512K 512K 512K 1M
thread_cache_size 8 8 8 16 16 16
max_connections 30 30 30 50 50 50
innodb_buffer_pool_size 314M 314M 428M 856M 1150M 1500M
DB検証
DB単体の性能を測ってもあまり意味なし
実運用時の性能を測っているわけではないので
Webサーバーを多数立てて計測
DB以外の箇所がボトルネックにならないように
DBサーバー
Webサーバー
アプリケーションサーバー
Webサーバー
アプリケーションサーバー
ロードバランサー
・・・
トピック
導入時
システム構成
インストール
運用時
システム構成の変更
定期的な処理の実行
大容量データ対策
システム構成の変更
ユーザー数の増加
単体構成からDB分割構成へ構成を変更
構成の変更
DBサーバー
Webサーバー
アプリサーバー
Webサーバー
アプリサーバー
ロードバランサー
DBサーバー
Webサーバー
アプリケーションサーバー
DBサーバー
DB分配ツール
テーブルを複数のDBサーバーに分配するPHPスクリプト
設定ファイル
ホスト情報
どのアプリケーションをどのホストに割り振るか
コマンドラインから一発実行
トピック
導入時
システム構成
インストール
運用時
システム構成の変更
定期的な処理の実行
大容量データ対策
定期的な処理
メールの自動受信
受信時間を管理者が指定可能
不要となったデータの削除
ゴミ箱内の保存期間を過ぎたファイル
持ち主のいなくなったメモ
掲示期間の過ぎた掲示板
など
スケジューリングサービス
C++で実装
登録したPHPスクリプトを定期的に実行
Windowsでも動くcron
PHPから制御できるcron
つまりブラウザからイベントを登録できる
トピック
導入時
システム構成
インストール
運用時
システム構成の変更
定期的な処理の実行
大容量データ対策
大容量データ
これまで起こった問題
ポータル画面が遅い
ユーザーを削除できない
など
ポータル画面が遅い
ログイン直後の画面
原因
大量の通知
対策
対応前
通知画面を表示した時に通知
最新の通知のみを取得するため
対応後
データ更新時に通知を生成
ユーザーが削除できない
現象
ブラウザ上からユーザーを削除するとタイムアウト
原因
ユーザーに紐付いたデータをその場で削除・変更していた
サイボウズ社内(6年運用)の古株社員だと削除に１時間ほど メール 約一万件
通知 約千件
ワークフロー 約千件
参加している予定 数千件
対策
削除処理の非同期化
ブラウザから削除したときは削除フラグを立てるだけ
DB上からの削除はスケジューリングサービスで、空いている時間に実行
処理時間帯は管理者が指定可能
まとめ
一般ユーザーの使い勝手は重要
ただし、パッケージ製品では、
導入の容易さ
運用の容易さ
も超重要！！
大量データを扱う処理は非同期化
今後の検討課題
他の重い処理の非同期化
通知処理
データのアーカイブ化
より明確なサイジング情報
性能検証の効率化も