PHP

大規模サイトの開発・運用ノウハウ　GREE編

データ
• 増え続けるデータとアクセスとの闘いの日々
– パフォーマンス
• どんだけ速くデータをとってこられるか
– スケーラビリティ
• データが無限に増え続けてもサーバリソースで問題を解決できるか？
– 似て非なる両者(やることはわりと一緒)
• 当たり前ですが、データは増え続ける一方です
• 増えるペースも増え続けてます
• やることってシンプル
– データベース分割
– インデックス張る
– キャッシュ
• データキャッシュ
• スマートキャッシュ(書きながら命名)

• まとめてみると
• TEXTフィールド分離
• テーブル分離
• テーブル分割
• JOINしない
• 正規化がんばりすぎない
• キャッシュも使いどころを考えてうまいこと…
– Memcacheって、なんか…だめ
• そもそもアプリケーションをなんとか…(SNSっていろいろ面倒)
– 「ともだちの~」とかACLとか
• 最近はネットワークトラフィックが馬鹿にならないです

大規模サイトの開発・運用ノウハウ　GREE編

bootstrapファイル
– ディレクトリが増えてきて、構造が複雑になってくると
– 「あれ？この定数ってここでつかっていいんだっけ？」
– 「あれ？このメソッドってここで呼んでいいんだっけ？」
– とかとか出てきます
• だったらrequice_onceしとけばいいじゃん
– 50,000 filesもあると、require_onceのコストも馬鹿になりません(もちろんeacceleratorと
か入れてますが - ちなみにコンパイルキャッシュを切ると相当遅いです)
– ということでbootstrapファイルとrequireのルール作り

src/Gree_Bootstrap.php
– 全サービス共通の定数
• define(‘PATH_ROOT’, dirname(dirname(__FILE__)));
– とかいうパス定義とか
– 絶対使うだろー、的なファイルのrequire
• require_once PATH_SRC_CLASS . ‘Gree/Util.php’;
– とか
• でもって
– 各frontend以下の値は、各frontend毎に勝手に(但しfrontend間の依存は原則禁止)
– 各service以下のクラス、定数等はgetService(‘service’)を通じて
– src以下のクラスライブラリはbootstrapでrequireされているもの以外は適宜require
• ってなルールです(書きながら決めた)

PHPカンファレンス2007

http://www.php.gr.jp/seminar/20070901/prog.php

http://labs.uechoco.com/blog/2007/09/gree.html

1. GREEの今と昔
* （オフレコ情報につき割愛）
2. ソースコードアーキテクチャ
* フレームワークに移行
* 激しくリファクタリング
* 複数サービスの連携
1. サービスがつくりたくなる
2. IDの共通化
3. 共通処理をたくさん作って楽する
* 定数をまとめたBootstrapを作る
* まとめ
1. require_onceのコストは考慮にいれるべき
2. 多言語へのブリッジもあってもいい
3. リファクタリングは避けられない
4. サービス連携を考慮して
3. データ
* データの扱い
o パフォーマンスやスケーラビリティを考える
o DB分割、インデックス、キャッシュ
* DB分割
o TEXTフィールド分割
* テーブル分割
o 別サーバーへ
o １つのテーブルを複数のテーブルに分割し、パーティションIDでアクセス（mixiでもやってる）
* インデックス張る
o MySQLのインデックスはどうも・・・
* キャッシュ
o memcache
o MySQL
* RDBMS
o JOINしない
o 正規化しすぎない
4. サーバー構築・運用
* 数百台規模になると、サーバー管理システムが欲しくなる
* サーバーのアップデートをパッケージ化
5. リリース
1. 初期
* CVS
* リリーススクリプト
* staging環境を構築
2. 中期
* /home/devNで開発者ごとに環境
* trunkに一本化
3. 偏在
* cvs2svnでSVN化
* 開発環境のパッケージ化
* rsync
6. 基幹システム
* LVS
* mod_proxy_balanser
* RDBMS：master_master
* Smarty遅い

http://www.phppro.jp/phptips/archives/vol11/2

ハッシュの使用は特にバッチ処理などで大量のデータを扱うときに有効です。また、テーブルにキーと文字列の情報が保存されている場合、テーブル結合をする SQL文を複数実行よりも、一度その内容を連想配列形式のハッシュで保存して使用すると、実行スピードが向上する場合もあります。