[12_B_6] PHP/MySQL を用いた大規模向けパッケージソフトウェア開発

田中裕一サイボウズ株式会社

開発本部開発部

ガルーン開発グループ

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上からの削除はスケジューリングサービスで、空いている時間に実行

処理時間帯は管理者が指定可能

まとめ

一般ユーザーの使い勝手は重要

ただし、パッケージ製品では、

導入の容易さ

運用の容易さ

も超重要！！

大量データを扱う処理は非同期化

今後の検討課題

他の重い処理の非同期化

通知処理

データのアーカイブ化

より明確なサイジング情報

性能検証の効率化も

[12_B_6] PHP/MySQL を用いた大規模向けパッケージソフトウェア開発

Technology

Transcript of [12_B_6] PHP/MySQL を用いた大規模向けパッケージソフトウェア開発