PHPカンファレンス2010 1日目(ビジネスデイ) に参加してきたのでレポート！

PHPカンファレンス2010が開催されました！早速ビジネスデイに参加してきたのでレポートを投下！
gihyo.jpさんの記事のほうがよっぽど出来ている気がしてたまりませんが・・・気にせず！

なお、途中で聞き取れなかったところはリアル感を出すため、そのまま（聞き取れず）等で記載しています。

2日目の参加レポートはこちらから！

PHPカンファレンス2010 2日目(テックデイ)にも参加してきたのでレポート！

Contents(目次)

参加したセッション一覧

GREE Platformの現状と今後の取組について
CakePHPで作るニフティWebサービスのレシピ
ユニットホスティングを使った効率的なPHPプラットホームのご紹介
新しいPHPアプリケーションのテスト手法
Scaling the Worlds Largest Social Gaming Network

GREE Platformの現状と今後の取組について

講演者：グリー株式会社取締役執行役員CFO 事業開発本部長青柳直樹さん

・2010年7月現在国内No.1のソーシャルプラットフォームに（2125万人）
　→目標3000万人（ニンテンドウDSとほぼ同じ）
　　→プラットホームのオープン化をもってコンテンツ量を増大させて目指す

・2010年6月からオープン化開始
　→それ以降毎月トップページを含む各ページの大幅リニューアルを継続
　　→結果的にUU増加
　　　→アプリ利用者数が約４倍、課金状況は約１０倍（1アプリ単位5倍程度）増加

・GREEプラットホームとしてのスタンス
　→オープン：パートナーの過度な追い込みは行わない
　→サービス改善：集客・利用・収益化のそこ上げをする貯め、サイトの改善を繰り返す
　→コンサルティング：パートナー様向けのデータ提供を充実させ、ベストプラクティスを開示・共有
　→プロモ支援：マーケティングサポートを行う

CakePHPで作るニフティWebサービスのレシピ

・講演者：ニフティ株式会社ネットマーケティング本部コンシューマメディア部小田祐史さん
　（ココログ担当＋Webサービスの設計・開発担当）

■PHPとニフティ
・シュフモ（http://shuf.jp）
　→一部PHPで開発
・@niftyストア（http://ec.nifty.jp）
　→PHPで開発
・トピックイット（http://topic.nifty.com）
　→CakePHPで開発
・コネタマ（http://blog-neta.cocolog-nifty.com）
　→CakePHPで開発

■CakePHP
・RoRを基本としたフレームワーク
・規約重視（CoC）
・PEARなどの外部ライブラリ依存をしない
・PHPのバージョンに依存しない
・ActiveRecordに近いO/Rマッパー（SQL文を書かなくてもいける）
・RoRに構成が近い

・構成はMVC。
　・Controller
　　→URLに基づきアクションを実行する
　　→アクションにて、Modelを利用して実装を行う

　・Component
　　→Controllerの共通部品
　　→SessionやCookieなどを扱うものを標準で用意

　・Model
　　→ビヘイビア
　　→(うまく聞き取れず)

　・View
　　→出力
　　→ヘッダーやサイドバーなどを共通化する仕組み
　　→標準はPHPを用いたテンプレートだが、他のテンプレートエンジンも利用可能

　・Helper
　　→(うまく聞き取れず)

　。Shell
　　→Controllerと同じ
　　→Viewに遷移しない

　・注意事項
　→ActiveRecordの機能は便利だが、速度の問題は？
　　→確かに便利だが、速度の部分は問題あり。（余計なテーブルまで参照しようとする）bindをもちいて回避している。

■冗長化とCakePHP

【コネタマ】
・冗長化されたWeb,DB,memcachedで構成
・NAS上にアプリケーションの配置を行った
　→極端にレスポンス悪化
　　→ConrollerやModelを利用する際に動的にディレクトリ操作するため、I/O増加したから
　　→ローカルティスクへの配置をすることで解決

・セッション
　→CakePHPの標準はファイルベースのセッション管理
　　→一定の確率でレスポンスが帰ってこなくなる
　　→NASの多くはファイルロックが適切に行えない（SQLiteも同様の現象がありうる）
　　　→セッション情報はDBへ格納

・DBの冗長化
　→一方向レプリケーションされたDBの負荷分散
　→参照は問題ないが、更新はMasterとSlaveで接続先を変更する必要がある
　　→AppModelを拡張して動的に拡張をする必要がある

■効率的なデプロイ

・複数サーバへのアプリ配備の手間削減
・全サーバへの配置漏れ防止
・Apacheモジュール入れ替え、全部を再起動

【解決方法！】
・Webistrano
　→Capistranoを拡張
　　→複数のサーバーに同じ処理を実行できる
　　→SSH経由でアプリケーションの配備、再起動など
　　→Rubyで開発
　→サーバーに対する操作履歴
　→デプロイが終わるとメール通知
　→対象サーバをGUIにて追加・削除できる
　→Ruby/RoRの設置、デプロイサーバ、Subversion/gitなどのバージョン管理システム、デプロイ先サーバへのSSH接続が可能であること

　・よく使うタスク　
　　→deploy（SVNからデプロイ。デプロイするタグやブランチを指定することも可能。デプロイ時には前のバージョンを残しリンクを張り替え）
　　→deploy:restart（Apache再起動）
　　→deploy:rollback（直前にデプロイしたバージョンに戻す）
　　→deploy:cleanup（前にデプロイしたバージョンの5世代以上前を削除）

・注意事項
　→デプロイ専用サーバの準備が必要。
　　→ステージングを行うサーバと一緒にしてしまうと、デプロイ→リスタートをしたときにwebistrano自身も落としてしまうので、おかしくなる

■ニフティクラウドについて

・2010年8月末で400社以上の利用がされている。

・5分以内に準備可能
・従量課金（12円/h〜）か月額課金
・スペックアップダウン、台数追加削除がWebから可能
・@niftyのサービス約160がニフティクラウド上で稼働中

■質疑応答

・コネタマにおけるMemcachedは何処に適用？
　→サイドバー（管理画面）のサイドバー部分のキャッシュデータとして利用
　→参加人数数値？などのデータをキャッシュして利用
　

ユニットホスティングを使った効率的なPHPプラットホームのご紹介

講演者：株式会社ディノ高原芳浩さん

■ユニットホスティングとは

・メモリ・ディスク・CPUを独立して、時間単位に増減可能
・前払いポイント制
・無料共用回線
・多機能（API、クローン、ユーザースクリプト、コンソール）
・月額単位/時間単位（2円/h〜＋グローバルIP）
・256MB単位でスケール可能 1.5円/h
・CPU仮想コア 2円/h
・ディスク1GBあたり 0.1円/h
・クレジットカードによる前払いポイント制
・法人契約による後払い制

■運用事例

・とある大人気ECサイト
　→通常時は最小構成で運用
　→セール時だけ爆発的にユーザーが増えるので、ここでWeb,DBサーバの台数UP＋スペックUP
　→WebサーバにはCPUを増やし、DBサーバはメモリを増やすという詳細なスペックアップ方法が可能

■ユーザースクリプト

・ユーザースクリプトとは、サーバー構築時、任意のスクリプトを実行出来るようにする
・スクリプト自体はローカルでもgithub先でもOK

・1回出来上がったサーバーは2台目以降展開時にはクローン（複製）を行うことで、どんどん作れる

■APIを利用した、MapReduce環境の構築

・自分で開発したuhadoopを利用（github公開中）
　→APIを叩いてサーバを増やしたり、コマンド実行が可能

■コミュニティ機能
・VMテンプレート機能
　→自分のサーバを別の人が複製できる
　　→設定内容等の共有が可能
・VM共有機能
　→自分のサーバを別の人が管理できる機能

【目標】
ユーザー同士でサーバの販売、有償サポートの提供ができる可能性の模索
（オリジナル設定サーバの販売、またそのサポート提供）

新しいPHPアプリケーションのテスト手法

講演者：大垣靖男さん

■PHPとアプリのバージョンアップ

やらなければならない
　→セキュリティ
　　→フレームワークの活用
　　→セキュリティ規約の策定・順守
　　→設計レビュー・ベストプラクティス取り入れ
　　→ソースコード検索（ホワイトボックス検査）
　　→ブラックボックス検査

　→バグ
　　→テストコードの作成
　　→ユニットテスト
　　→バグフィックスの適用

　→単純にバージョンアップ
　　→PHP本体
　　→FWのバージョンアップ
　　→アプリケーションのバージョンアップ

常に、システムはバージョンアップしていく。
特にオープンソースシステムの場合、バージョンアップをしていくことでバグを直していく

いかに、最新のバーションで簡単にテストを行えるかが重要。

■バージョンアップとは
PCIDSS（カード会社のセキュリティ規約）では・・・
　→重要なセキュリティパッチはリリース後1ヶ月以内にリリースする。
　→優先順位の高いシステム及びデバイスは1ヶ月以内、通常デバイスは3ヶ月以内に対処。

■PHP本体のバージョンアップ

・本体自体もかなりユニットテストが行われている。
・PHP本体のテストはmake testでできる。
・PHP本体のテストファイルは約11200ファイルある

ただし、これが通っているからと言ってバージョンアップは容易にできない。

・PHP5.3.2とPHP5.3.3をdiffってみると・・・・166382箇所の更新箇所が存在。

→やっぱり本体バージョンアップは難しい
　→さらにWebアプリの動作確認はさらに難しい
　　→同一条件の再現、IPアドレスによる再現、HTTPヘッダ、クッキー、DB、キャッシュ、メールなど・・・
　　　→仮に同じ条件を揃えたとしても動やって確認を取るの？

最近のWebアプリシステム構成
　→ブラウザ（IE/FF/Chrome/ケータイ/iPhone/Android・・・）
　→Proxy
　→Web
　→DB

・マルチリンガルサイトのバージョンアップも大変
　→例えばDrupal。観光サイトで各言語動作。モジュールをバージョンアップした場合に正しく表示されるか確認をどうやって？

・ケータイサイトのバージョンアップ
　→FWの修正を行った。サポートするすべての機種で問題なく今まで通りに表示される？

■解決策！

「PROVE for PHP」
　→リグレッションテストツール

・アプリケーションレベルのテストスイート
・特にVerup時のテストに有効
・PHP4.3/5.1/5.2/5.3に対応予定

【アーキテクチャ】
・ZendEngineをラッピングしたもの

【特徴】
・実働アプリケーションに対してテスト

・TRACEモード
　→リクエスト
　→関数呼び出し
　→データベース
　→ファイル
　を記録
　　→1リクエスト1ファイル
　　→ログ形式はPHP配列形式

・VALIDATIONモード
　→TRACEモードで把握したものを正しく動作するかテスト

・Zend Engineモジュールとして動作
　→あらゆる関数呼び出しを監視
　→必要に応じてオーバーライド

・IPアドレスも何もかも再現
　→ファイルI/O、DBアクセスなど

・オーバーライド関数は指定可能

・十分な性能で動作するので実働アプリケーションからテストケースを作成可能
　→実際のユーザーさんのアクセスを元にテストケースを作成
　　→LB配下のWebサーバにPROVEサーバを追加することで、テストケースを取得

・LBはUltraMonkeyやnginxなどのオープンソース製品でOK
　→HAProxy,LXB,UltraMonkey-L7など

・クッキーバーシステンスをサポートしていると好都合

・関数オーバーライドとテストの信頼性
　→TRACEモードでは引数と戻り値を保存
　→VALIDATIONモードでは引数の検証と戻り値のオーバーライド
　　→単機能テストなので、ユニットテストの得意分野

【予定追加機能】
・バリデーションモードのWebベースGUI
・ソースガバレッジ分析
　→実際に、何処のソースコードを実行された/されていないのかが分かる
・オーバーライド関数の追加
・PROVE for ANY (powered by PHP)
　→プロキシ型PROVE（リバースプロキシ）
　　→APCなどのZendモジュールを利用した環境でも利用可能
　　→システムから完全独立が可能
・PROVE for PHP/SQL
　→SQLクエリトレーサー
　　→SQLクエリログを取る
　　→テスト用ではなく、セキュリティ対策用
　　→SQLクエリとPHP変数を一緒にdump

Scaling the Worlds Largest Social Gaming Network

講演者：Zinga inc.（Justin Waldron ,Don Mosite）

（全編英語なので、適当ヒアリングで書いてます）

■Zyngaについて

・Zyngaのミッション
　→世界中のゲーム同士でコネクトする（つながる）

・Facebookを中心としたソーシャルオンラインゲームを中心に事業展開

・ソーシャルゲームとは？
　→プレイが簡単で楽しい（いわゆるクリックゲーム思想の話？）
　→ソーシャル部分がゲームに介在する？
　　→（友達や知らない人同士の交流がある）

・Zynga
　→MonthlyUser：2億4800万

・グローバルに展開
　→パートナー企業が世界中に存在

・FarmVille（ゲーム名）
　→今まで受理されたギフト数は190億個

Facebookのトップゲームの上位7個がすべてZynga。（1位〜7位）

■テクノロジー面のスケール方法

・1週間1000代のサーバー追加
・1日のデータスループットが1PB！
・書き込み頻度が多い
・リリース後数日以内の大量負荷に対応できる環境が必要
　→クラウド上のオートスケールウェブサーバ
　→サーバアーキテクチャの全部分は水平方向にスケールする
　　→全てが非同期式、キャッシュされる

・PHPWebサーバを横展開
　→ユーザーデータの更新などはすべてMemcacheにPoolして、遅延書き込みさせる

・負荷次第でWebサーバーの追加をする
　・新規インスタンスをLB配下に入れる

■APIに関して
・APIレスポンスキャッシュ内蔵

■コードデプロイに関して
　→リリースをプッシュするための仕組みを構築（BitTorrent）
　→迅速なリリースとロールバックを可能に

■データ
　→MemcacheをKVSとして利用
　　→Membase：分散型KVS：持続型Memcached　を利用
　→MySQLは持続型データストアとしてのみ利用
　→MySQLへの書き込みは非同期書き込み

・Membase
　→KeyとValue
　→早い（高速アクセス＋信頼性がある分散型ハッシュテーブル形式データ）
　→柔軟性（データへのアクセスが途切れずにノードを追加）
　　→データアクセス時に一貫性を維持（MembaseはCAタイプのシステム）
　→オープンソース

・mcmux
　→Memcached用のコネクションマルチプレクサー

・pecl-memcached

・FontLavel
　→iPhoneの任意.ttfフォントを書くためのモジュール

■質疑応答

・Membaseに参加させることは簡単のようだが、障害時の復旧は？
　→データはDBに投げ込む。障害時はbounce？させるが、これは手動で行う。

・Zyngaのキャラはなんか日本の影響うけているような？
　→本社に聞かないとわからない・・・けど、様々なユーザーテスト、ユーザー反応を見て決めている

・日本やアジア向け特化したゲームやキャラを作る予定は？
　→もちろん考えてはいるが、全世界向けではなくアジアや日本限定のものを考えている。
　→既に既存ゲームの中国特化版など提供。

・日本オフィスはそういうローカライズをするために？
　→日本オフィスは単独で機能する場所なので、それだけの目的じゃないよ。もちろんやるとは思うけど。

・Zynga（本社）/日本オフィスなどで日本人/アジア人って仕事してる人いるの？
　→東京オフィス（ウノウ）は日本人60人程度、Zynga本社は人数多すぎて把握不能・・・でもいるよ。（10人〜20人）

・MySQLを使う決定的な理由は？
　→LAMPの構造が既に構造として信頼性が高いので、必然とMySQLを利用。
　→最初始めたときはLAMPで行っていた。

・MySQLの書き込み速度改善方法は？
　→そもそもLazy Write（非同期遅延書き込み）なので、そもそもあんまりやってない。
　→Memcachedを水平分割する技術のほうが発達しているので。

・ウノウはSymfony使ってるけど、Zynga本体は使ってる？
　→基本的にゲームごとにすべての仕様が違う。Zynga自体でオリジナルで開発していったものを流用しているので、わざわざオープンソースのを採択する必要はない。

講演関連資料

github – zinga (zingaが公開しているオープンソース関連）
Membase公式サイト