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

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    1 Favorite & 1 Event

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

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

    + yuichielectricyuichielectric, 10 months ago

    custom

    1720 views, 1 favs, 0 embeds more stats

    デブサミ2009 12_B_6の発表資料

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 1720
      • 1720 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 1
    • Downloads 106
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories

    Tags

    Groups / Events