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

PHPカンファレンス会場風景 php

PHPカンファレンス会場風景

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

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

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

参加したセッション一覧

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

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

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

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

・2010年6月からオープン化開始
 →それ以降毎月トップページを含む各ページの大幅リニューアルを継続
  →結果的にUU増加
   →アプリ利用者数が約4倍、課金状況は約10倍(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自体でオリジナルで開発していったものを流用しているので、わざわざオープンソースのを採択する必要はない。

講演関連資料

コメント