PHP カンファレンス 2010 ビジネスデイ私的不完全議事録【phpcon2010】

オープン: 信頼される、オープンなプラットフォームを志向。パートナーを苦しめる過度な囲い込みは行わない
サービス改善: 集客・利用・収益化の底上げを図るためにも、サイトの仕様・機能の追加・改善を繰り返していく
コンサルティング: パートナー様向けのデータ提供(他社アプリとの比較データなど)を充実させていく。コンサルティング専門のチームを立ち上げ、ベストプラクティスをタイムリーに共有していく
プロモーション支援: マーケティング面でのサポートを手厚くしていく

コンサルティングのフレームワーク(例)
パートナー様向けのプロモーション支援

テレビ CM──年末までに 30 タイトルの CM を実施予定
モバイル広告──パートナー様タイトルを用いたモバイル広告出稿を拡大
ソーシャルアプリに参入してください。グリーが全力でサポートします!

GREE のスマートフォン展開

スマートフォン対応を順次拡大。対応の詳細については 2010 年中にも順次公表予定

グローバル展開

アジア及び北米での事業展開を計画中

海外拠点を開設予定
外国籍の社員採用も積極化
ローカルプレイヤーとの業務・資本提携を検討中

[A-3] CakePHP で作るニフティ Web サービスのレシピ (小田祐史氏)

会社概要

1987 年の商用パソコン通信サービス「NIFTY-Serve」提供開始から 24 年
現在はさまざまな Web サービス・コミュニティサービスを提供
ニフティのサービス利用者は PC・モバイル合わせて 1015 万人

自己紹介

ココログ・関連サービス担当
CakePHP 1.3 まで開発

PHP とニフティ

PHP で開発されたサービス

シュフモ (一部を PHP で作成)
@niftyストア
トピックイット (CakePHP)
コネタマ (CakePHP、小田氏作成)

CakePHP

http://cakephp.org/
Ruby on Rails (RoR)の影響を強く受けた高速開発フレームワーク
1.3.4 が最新
特徴

Pear などの外部ライブラリ非依存
PHPバージョン非依存 (4 or 5)
RoR の AcriveRecord に近い O/R マッパー
RoR に構文が近く、Ruby とPHP の両方を書くエンジニアにはやさしい

構成

MVC
Controller
Component
Model
VIew
Helper
Shell

冗長化とCakePHP

コネタマの構成

冗長化された Web サーバー、DB サーバー、memcached サーバーで構成

アプリケーションの配置先

NAS 上へアプリケーションの配置を行った
レスポンスが急激に悪化

Controller や Model を利用する際に、動的にディレクトリを操作するため I/O が増加
ローカルディスクへの配置にて解決(3 秒→0.1 秒以下)
ソースはローカルディスクへ置くべき

セッション

CakePHP 標準のファイルベースのセッション管理

一定の確率でレスポンスが帰ってこなくなる
NAS の多くはファイルロックが適切に行えない (今回の話とは無関係だが、SQLite を利用する場合も同様の問題がある)
セッション情報は DB に格納するようにする

一方向レプリケーションされた DB の負荷分散

参照は問題ないが、更新はマスターとスレーブで接続先を変更する必要がある
AppModel を拡張して、接続先を動的に変更するようにした

効率的なデプロイ

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

Capistrano を Web 化したもの。RoR のデプロイでよく使われている

Capistrano

複数のサーバーに同じ処理を実行できるツール
SSH 経由でアプリケーションの配備、再起動など
Ruby で開発され、RoR で広く利用されている

Webistrano

サーバーに対する操作履歴
デプロイなどが終わるとメールで通知

Webistrano を利用するために必要なもの

Ruby および Ruby on Rails
デプロイ用サーバー
Subversion や git などのバージョン管理システム

独自のレシピを書けば NAS 上からコピーすることも可

デプロイ先サーバへ SSH で接続できること

よく使うタスク

deploy

Subversion などのバージョン管理システムからデプロイ。デプロイするタグやブランチを指定することも可能
デプロイ時には前のバージョンを残しリンクを張り替え

deploy:restart

Apache の再起動

deploy:rollback

直前にデプロイしたバージョンに戻る

deploy:cleanup

前にデプロイしたバージョンの 5 世代以上前を削除

ニフティ クラウドのご紹介

2010 年 8 月に開始。8 月末時点で 400 社以上に導入
http://cloud.nifty.com/
特徴

オンデマンド

5 分以内にサーバーを準備。ディスクの追加なども 5 分で完了

従量課金

月額課金も選択可

伸縮可能
@nifty で培った高い運用実績

約 160 の @nifty サービスがクラウド上で稼働中

オンデマンド性

コントロールパネルから 5 分以内にできること

サーバーの作成・削除・起動・停止・リブート
ディスク領域の作成・削除・接続・取り外し
サーバー能力の変更 (1CPU 512MB←→4CPU 16GB)
ロードバランサーの作成・削除
SSH キーの作成・削除など

ニフティ クラウドの今後について

ニフティクラウド API

8/10 β版リリース

SOAP 版提供中
10 月以降リリース予定機能

サーバコピー (作成・設定済みサーバのコピー)
オートスケール (負荷に応じたサーバー自動縮退
基本監視 (CPU・メモリ等)
稼働状況レポート (リソース状態のグラフ表示)

エンジニアの日々の作業をより簡単にできるよう頑張ります

質疑応答

デプロイツールで、実際に失敗することは?

→ステージング環境(本番サーバーに適用する前のサーバー)に対してデプロイを行った場合、サーバーの再起動を行うと、Webistrano が動いているサーバーも再起動してしまった。なので、デプロイ専用のサーバーを立てたほうがよいと思う
CakePHP の O/R マッパーのためにパフォーマンスが落ちていると思うが、内部のチューニングなどはしているか?

→バインドを動的に行って参照するようにしている
memcached でどんなものをキャッシュしているのか?

→ココログの管理画面のサイドにコネタマのネタ一覧を表示しているが、ココログ管理画面自体アクセスが多いので、その画面自体にキャッシングを行っている。コネタマ自体はPVがそこまで多くない。参加者数の表示などはキャッシングしている

[A-4] ユニットホスティングを使った効率的な PHP プラットフォームのご紹介 (高原芳浩氏)

ディノについて

1998年東工大発ベンチャー
社名は Digital Innovation から
本社: 東京都渋谷
PHP エンジニア 22 名
ウェブシステム開発 (PHP/Symfony)

ユニットホスティングのご紹介

メモリ・ディスク・CPU を独立して時間単位に増減可能
前払いポイント制
無料共用回線
多機能 (API、クローン、ユーザスクリプト、コンソール)

料金体系

月額単位・時間単位 2 円/時〜 (グローバル IP + 2 円/時)

256MB 単位でスケール可能、1.5 円/時
CPU 仮想 Core 2 円/時
ディスク 1GB あたり 0.1 円/時

支払い方法

クレジットカードによる前払いポイント制
法人契約による前払い制

これまで

2010/3 サービス開始
2010/4 API 仕様公開、サーバ複製などリリース
2010/6 クラッシュリカバリ機能、SSH キージェネレータなどリリース

運用事例──とある大人気 EC サイト

セール時は非常にアクセスが増える。その時だけ Web サーバ、DB サーバを増強する
Web サーバーと DB サーバーとではリソースの追加の仕方が若干違うと感じている。Web サーバは CPU を、DB サーバはメモリを増やすのが効率的
柔軟な拡張性──すぐに、必要なだけ。縮小もカンタン

必須条件

10 分以内にサーバーを立ち上げる
1 分以内に CPU やメモリを増やす
要らなくなったらすぐ捨てる

既存のレンタルサーバーではできなかった

ユニットホスティングの設計思想

短期で無精で無計画な人向け
全世界に提供できるサービス
利用者同士がコミュニケーションにより創造できる
「すぐに」「必要なだけ」「自動で」
「与信不要で」→前払いポイント制
コミュニケーション手段としての「ユーザスクリプト」(まだ不十分)

ユーザスクリプトを利用した OpenPNE の瞬間設置例 (デモ)

ユーザスクリプトとは……サーバ構築時に任意のスクリプト(シェルスクリプト)を実行
サーバ設定画面でユーザスクリプト URI を指定
2 台目からは複製(クローン)。1 台目のサーバーをコピー

API を利用した MapReduce 環境の構築 (デモ)

uhadoop を導入
name ノードと data ノードをあらかじめ用意
./bin/deploy tumf-sg-13 4 (4 は data ノード 1、data-cluster 3 の 4 台の意)
ジョブ実行 uhadoop tumf-sg-10 jar ジョブ.jar

今後の予定

ユーザスクリプトはコミュニケーションに役立っているか?

現状では利用者が少ない
コミュニティ機能の充実を計画
ユーザーを独立したものと考えていない

VM テンプレート機能

自分のサーバーを別の人が複製できる

VM 共有機能

自分のサーバーを別の人が管理できる機能
企業内ユーザーに利用が多い

将来的には、ユーザ同士でサーバを販売したり、有償サポートを提供したり……

[A-5] 大ヒットソーシャルアプリの裏側 (高田敦史氏、新田祐介氏)

会社紹介

2000 年 8 月設立、今年 10 周年を迎える
大規模/高負荷モバイルサイトの構築/運用にて、負荷対策のノウハウを蓄積
ソーシャルアプリ向けホスティングサービス「DSAS Hosting for Social」提供中
ソーシャルアプリを多数展開中

スピーカー紹介

新田祐介(@fushianako)

KLab 株式会社第 2 開発部グループマネージャー

高田敦史

K ラボラトリー第 2 開発部 PMO
最近作ったものは「Paintica」
PHP は主にソーシャルアプリの開発に使用

第 1 部: ソーシャルアプリの概要 (新田氏)

ソーシャルアプリとは?

SNS の機能を使うことができるアプリケーション
SNS の機能を使いたい時は、各プラットフォームが提供する JavaScript API や Web API を利用する

特徴

サービスを気軽に立ち上げられる

ビジネス的観点

ユーザの母体が SNS にあるが故の集客コストの削減
流行っているからという理由で納得する人が多い (半分冗談、半分本気)

技術的観点

OpenSocialAPI を使うことによる、開発コストの削減

気軽に立ち上げられる反面、同じようなテーマのアプリが多いため、差別化が重要

どうやって差別化していくか?

アプリのテーマの選定

誰も考えていないようなテーマを選定することが重要

独自機能の提供

数が多く、テーマがかぶることが多い
すでにかぶっている場合は、他のアプリを研究して他アプリにはない機能を作り込む

自分をアピールしなきゃダメ。劣化コピーでは振り向かれない

第 2 部: 激戦! ソーシャルアプリ開発日記 (新田氏)

私(新田)の苦労話をノンフィクションで

その 1 集中砲火

「恋してキャバ嬢」は見事に差別化に成功した
負荷に耐えきれなくなった
初日: 380PV/sec → 翌日: 580PV/sec → 最大: 2000PV/sec 以上 (500PV/sec は普通のウェブアプリでは考えられない)
というわけで地道に負荷対策を始めた

その 2 ハイブリッド化

キャバをテーマにしたアプリも出てきた
新規機能を開発して差別化を行わないと追い抜かれてしまう
他社アプリ対策で新機能作成→企画者から「作り直して」と手戻り発生
リリースが遅れると機会損失になる
企画者からの相談をすぐ作るのではなく、こちらから「こうしたほうが面白そうじゃない?」と提案をする。企画の意図がよく理解できたし、手戻りもかなり減った
スピードの流れが速いので、自分の担当にとらわれず、担当外の作業も積極的に行うことがヒットアプリを生み出す要因になる
エンジニアも企画のフィールドに少しでも首を突っ込むと楽になれる

第 3 部: ソーシャルアプリ負荷対策 (高田氏)

Web アプリ負荷対策の基本をおさえる
リソースの特性を意識する
参考:「LAMP で作るソーシャルアプリの負荷対策」

1. ソーシャルアプリの負荷特性

ユーザー固有のデータ

大量

ゲーム内ステータス
アイテム所持情報
課金・購入ログ

更新頻度高

ボタンを押すだけでステータス変化
大量のログ

高頻度 + 大量の HTTP リクエスト
マスター DB の負荷集中。マスター DB は分散困難
ソーシャルアプリで重要なリソース

データベース(特にマスター)。最大コネクションは数百程度

情報閲覧とダウンロード中心のモバイルサイトと比べて、モバイル向けソーシャルアプリは「ユーザーのアクション + ユーザー間アクション」があり、リクエストが多く、参照も更新も同様に多い

2. KLab のシステム構成

DSAS──高負荷・大規模サイト構築用インフラ統合技術

オープンソースベース
単一故障点が存在しない高信頼構成
容易なメンテナンス・柔軟なスケーラビリティ
充実した監視機構とモニタリング

Ganglia によるモニタリング

監視対象の追加が容易
LVS 側でアプリごとのパケットを計測して表示

Symfony ベース (Symfony を大幅に改造)
高速画像合成ライブラリや Flash 合成ライブラリは C++ で書かれた PHP エクステンション(自社開発)を利用
画像構成について

「背景画像 + ボディ画像 + 表情画像 + ドレス画像 + 髪型画像」の合成でキャバ嬢のアバターを生成
アバター画像キャッシュは非効率、かつ不要
1 ユーザー(50KB) × 100 万

合成したアバター画像だけで 50GB

memcached へのキャッシュは非現実的
ローカルファイルへのキャッシュは、I/O アクセス増加でむしろ遅くなる
素材ファイルは数百から数千程度なのでキャッシュ可能
画像ライブラリの高速化 + キャッシュなし

3. リソース有効活用テクニック

マスター DB 有効活用

なるべくデータベースに接続しない

コネクション数を減らす

データベースへの接続時間を短くする

クエリを最適化
接続を切る

SQL 最適化、DB サーバチューニングの話はソーシャルアプリに限らないので省略 (とても重要だが)
DB コネクションの節約方法について

キャッシュサーバの利用

効率的なキャッシュの利用

memcached の最大接続数は数万から数十万
秒間数万リクエストを処理

先にキャッシュを検索、なければ DB に問い合わせ
DB 更新時にキャッシュも更新
更新が少ないデータなら APC キャッシュも有効

KVS の利用

更新の一部を KVS に分散する
Tokyo Tyrant

平林幹雄さん(mixi)作
memcached に近い高速な処理
エビクション(データ消滅)の心配がない
使い道

頻繁に更新されるユーザーステータス

体力、アイテム装備情報、ログイン情報など

RDB の機能が必要でないデータ

注意点

Tokyo Tyrant (TT)と MySQL の間の不整合が起こりうる
アトミックな更新処理は困難
ユーザーが得する方向で処理を行う

ユーザーの利益になる処理 on TT (体力回復)
MySQL への更新処理 (アイテム消費など)
ユーザーの損になる処理 on TT (体力消費)

スレーブ DB への分散

スレーブ DB: マスターからデータをコピーした DB (レプリケーション)
DB への参照をスレーブ DB に逃がすことで、マスター DB への負荷を減少させられる
注意点

最新のデータがあるとは限らない
レプリケーション遅延はいつでも起こりうる
ランキングなど、更新が少なく、遅延が致命的でないデータに利用する

ソーシャル API 利用の注意点

ガジェットサーバー経由の認証情報を利用し、API サーバーに問い合わせる
API との通信は HTTP なので、最短でも数十 ms のコスト(時間のかかる処理)
レスポンスアウトは日常的に起こりえる
API 通信が常に成功する前提でアプリケーションを開発してはいけない
危険なコード

トランザクション開始→API 問い合わせ→トランザクション終了
通信が成功しても、数十 ms 程度のロスが発生

それでも足りない場合

水平分割/垂直分割を利用
データベースを複数に分割

[A-6] Scaling the Worlds Largest Social Gaming Network (Zynga Justin Waldron 氏、Don Mosite 氏)

Zynga とは?

mission: connecting the world through games
Facebook = cocktail party、ゲームがコミュニケーションの促進によいと判断

ソーシャルゲームとは?

プレイが簡単で楽しい
本物のソーシャル・インターアクション

人々が共同して何かをすると言うことが最重要

Zynga

月間ユーザー数 2 億 4600 万
Zynga のゲームプレイ体験者数 321,000,400 人
グローバルに展開するグローバル企業
文化の主流の一部になることが目標(飲料、アイスなどにキャラクターが採用)
毎月、世界のネット人口のうちの 10% 以上が Zynga のゲームでプレイ
受理されたギフト数 190 億
Facebook における人気ゲームの上位 7 つが Zynga で開発されている

テクノロ ジーはどういう風にスケールするのか?

アクセスの多い週には 1000 台のサーバーを追加
一日のデータスループット 1PB
ユニークな挑戦

書き込み頻度が多く、高度にインタラクティブなアプリケーション
リリース後数日以内の大量の負荷に対応できる新たなゲームコード
常に変化を続けるプラットフォームのトップに位置

インフラストラクチャー・デザイン

クラウド上のオートスケールウェブサーバー
サーバー・アーキテクチャの全部分は水平方向にスケールする

クラウドにおけるオートスケール

ロード次第でウェブサーバーを追加
新規インスタンスはロードバランサに通知
完全に自動化・API 化されている

ハイスケール・プラットフォーム

例: ソーシャルネットワーク・ラッパー
高度にダイナミックな API は使いにくい
API レスポンスキャッシュ内蔵
クロスプラトフォーム・ゲームを可能に
プラットフォームが落ちてもゲームが継続

ハイスケール・コードデプロイメント

例: Mafia Wars + BitTorrent
リリースをプッシュするためのソフトウェア・ディストリビューション・システム
よりシンプルなデプロイメントとロールバック
より迅速なリリースが可能。より少ないチームリソースで対応可能

ハイスケール・データ

NoSQL: Memcached を KVS として利用
DB は持続型データストアとしてのみ使用
MySQL は非同期で

Membase

分散型 KVS: 持続型 memcached
Apache 2.0 ライセンスでリリース
特徴

シンプル

キーバリューストア

早い

目標: 高速アクセスができ、かつ信頼性が高い分散型ハッシュテーブル形式データ
最低でも最適化された DBMS 程度の速度

柔軟性がある

データのアクセスが途切れずにノードを追加
データアクセス時に一貫性を維持

Membaseは CA タイプのシステム (一貫性があり、常にアクセス可能)

クラスター内に存在
オープンソース

msmux: Memcached 用のコネクション・マルチプレクサー
pecl-memcached
FontLabel
今後も増強予定

質疑応答

Membase で、あるハードウェアが障害になった時にどうやって復帰しているのか?

→自動的にバックアップのサーバーへフォワードされる
ゲームのキャラクターは目が大きく、日本のマンガに影響を受けたような作りだが、意図的なのか。その狙いは効果があったのか?

→とてもよい質問だが、Zynga 本社のアートディレクターに聞かないと分からない。ユーザーテストのフィードバックで一番ウケがいいものを採用しているはず。大衆ウケするものにしようという努力、反感を受けないものにするという努力を絶えずしている
日本・中国・インドにも展開しているそうだが、日本人やアジア人向けのゲームを独自に開発する計画は?

→アジアだけで出すゲームは計画している。例えば、実際に中国向けにローカライズされたバージョンのゲームもある
東京オフィスの機能は、そういったカスタマイズのためか。

→東京で独自に機能するオフィス。東京で独自にゲームを出すこともやると思う。人材募集中です
Zynga 本社に日本人やアジア人の社員はいるのか?

→東京には Zynga US から来た人が 8 人、残りは日本人で 50 人くらい。本社は多すぎて分からないが、10人、20人はいるらしい
MySQL を使う決定的な理由は?

→LAMP スタックが信頼性の高いもので、最初に決めた時も信頼性の高いものにしようということになった。もう一つは、始めた頃は MySQL のレイヤーの上に積み重ねていくのが自然だった
ウノウは Symfony を使っているとのことだったが、Zynga ではオープンソースのフレームワークを利用しているか? 理由も。

→ゲームごとに作り方は違う。1 から作り上げたものはかなりあるので、Zynga の外のフレームワークに頼ることはない

[A-2] 基調講演「ソーシャルゲーム市場の拡大と GREE Platform の展開」 (青柳 直樹氏)

GREE Platform オープン化の背景

ソーシャルゲーム市場の展望

2011-12 年に本格的なソーシャル時代を迎える

ソーシャルゲームの特性

GREE Platform の展開

GREE のスマートフォン展開

グローバル展開

[A-3] CakePHP で作るニフティ Web サービスのレシピ (小田 祐史氏)

会社概要

自己紹介

PHP とニフティ

CakePHP

冗長化とCakePHP

効率的なデプロイ

ニフティクラウドのご紹介

ニフティクラウドの今後について

質疑応答

[A-4] ユニットホスティングを使った効率的な PHP プラットフォームのご紹介 (高原 芳浩氏)

ディノについて

ユニットホスティングのご紹介

料金体系

これまで

運用事例──とある大人気 EC サイト

必須条件

ユニットホスティングの設計思想

ユーザスクリプトを利用した OpenPNE の瞬間設置例 (デモ)

API を利用した MapReduce 環境の構築 (デモ)

今後の予定

[A-5] 大ヒットソーシャルアプリの裏側 (高田 敦史氏、新田 祐介氏)

会社紹介

スピーカー紹介

第 1 部: ソーシャルアプリの概要 (新田氏)

ソーシャルアプリとは?

特徴

どうやって差別化していくか?

第 2 部: 激戦! ソーシャルアプリ開発日記 (新田氏)

その 1 集中砲火

その 2 ハイブリッド化

第 3 部: ソーシャルアプリ負荷対策 (高田氏)

1. ソーシャルアプリの負荷特性

2. KLab のシステム構成

3. リソース有効活用テクニック

[A-6] Scaling the Worlds Largest Social Gaming Network (Zynga Justin Waldron 氏、Don Mosite 氏)

Zynga とは?

ソーシャルゲームとは?

Zynga

テクノロジーはどういう風にスケールするのか?

質疑応答

[A-2] 基調講演「ソーシャルゲーム市場の拡大と GREE Platform の展開」 (青柳直樹氏)

[A-3] CakePHP で作るニフティ Web サービスのレシピ (小田祐史氏)

[A-4] ユニットホスティングを使った効率的な PHP プラットフォームのご紹介 (高原芳浩氏)

[A-5] 大ヒットソーシャルアプリの裏側 (高田敦史氏、新田祐介氏)