月別アーカイブ: 2010年10月

楽天テクノロジーカンファレンス2010へ行ってきました。

楽天テクノロジーカンファレンス2010へ参加してきたので、その時のメモを公開させて頂きます。当日は楽天の三木谷社長、まつもとゆきひろさんの講演を生で聞くことができました。

聞き違い等あるかもしれませんがご容赦ください。
なおUSTREAM等でも当日の様子が公開されているみたいです。

———————-
特別講演
———————-
楽天:
・英語公用語化
・国際化している

グローバル化する意味:
・世界における日本のGDPシェア:
 2006年は12%
 予測では2050年には3%になる
→情報格差が縮まっている

アマゾン・Eベイ:
・売り上げの半分はアメリカ以外
・広範囲に広がっている

国際化は技術的にも良い:
技術者も世界に広がっている

自国の言葉に翻訳された技術書を読んでいるのは日本人ぐらい

楽天→70%の売り上げを海外で上げることを目指す

世界中のエンジニアを束ねていきたい

ソース・アプリをどうシェアするか→プライベートクラウドによるグローバルネットワーク
・グローバルエンジニア
  日本語のできないエンジニアも参加できるようにする
・オープンソースストラテジ
  できるだけオープンソースでやっていく
・クラウド
  生産性の向上
  パブリッククラウドの利用
・RIT(楽天技術研究所)
  さらに広げていく

一流の技術者:
グローバルに活躍している

オープンソースの強化

パブリッククラウドの利用・提供:
・プライベートクラウドに取り込んでいく

ソフトの世界でも世界レベルを目指していく

楽天:
・パートナースタッフを含めて1万人
・技術が重要になってくる

オープン化、テクノロジーの差別化
→これをやりきることが重要

ハードルを乗り越えていくということにロマンや大きな喜びを持つ

楽天主義=今までやってきた事による収穫

過去に買収しグループ化した会社が大きなシナジーを生み出す
→楽天経済圏

国際レベルでビジネス/技術の共有を行い強くなる

熱い心/夢が重要

———————-
基調講演「グローバル・エンジニア」
———————-

自分の限界は自分で決める
→壁を突き破る必要がある

成功するために:
・成功とは何かを定義する
・成功の定義は人によって違う
・定義しなければ何をして良いのか分からない

成功例:
・金持ち
・名声を得る
・最強になる(能力の最高を目指す)
・平穏に暮らす
→自分で決めなければならない

人生は平等ではない:
・貧乏、金持ち、才能・・・
・理不尽でもある

成功のために向かう方向(ゲームのルール)は似ている

人間の本質;今と昔でそんなに変わらない

ゲームのルール:
・目標を持つ
  短期(1~5年以内)=現在予測できる目標
  長期(人生の目標)=テクノロジーの変化は影響しない目標、適切に立てる
  中期はいらない(予測できない、無理)
・行動する

自分自身であれ:
・(まつもと氏)プログラミングが好きだった=どこから来るかわからない強み
・好きな分野、情熱を持ち続けられるかどうか

そして実際に行動する:
・行動無くして成功なし

運・タイミングもある=かなり大きい
・Rubyでは英語のドキュメントを作成した
  →外国人の目に触れた

成功する確率は上げられる:
・時間的に
  最後までいれば勝者
  成功するまでやる
  ただし100%ではない
・ラーメン代分のもうけ
  コスト削減→ラーメンだけで生活
  軽量言語→簡単に作れる
  クラウド→初期費用を抑えられる
  ラーメン代分のもうけがあればよいと考えると
   →思い切って挑戦できる
   →失敗しても痛みが少ない
・空間的に=どこで戦うか
  専門分野で(ニッチなところ)
  広いマーケットで(ある程度お客さんがいる)
  矛盾:人がいないところでは成功できないが、
     ニッチなところでしか成功できない=ロングテール理論

グローバルなマーケットで世界に届くためのコスト
・物流
・通信
・言語
・意識

物流と通信の壁:
・20年前は海外にメールが送れなかった
・現在は壁がなくなった

言語と意識の壁:
・まだ壁がある
・北欧→英語が通じる(英語を話せないと生きていけないことを知っているから)
・日本もそうなる

自分の言葉に伝える価値があればひどい英語でも聞いてもらえる

伝える気があるか、
外に出て行く気があるか、が重要

Rubyメーリングリスト:
15年前の購読者数:200人
現在:数千人

Rubyのユーザ:
・世界で百万人を超えている
・世界が共感してくれている

今まで見ることのできなかった風景を見ることができる
→日本だけでは勿体ない

日本語でブログを書く:
・日本人にしか見てもらえない
・英語で書けば世界中の人から見てもらえる
・まだ見ぬ友と出会わないのは勿体ない

—————————————————–
HTML5 とその先にある Web of Data
—————————————————–
この内容はWebサイトでも公開されている

HTML:
・ハイパーリンク付き文章ファイル(基本はこれ)
・シンプルな役目が世界を広げる
・ウェブサイトを作成する時の材料(20世紀の定義)

ウェブブラウザ経由で見れるもの:
・見れる範囲がものすごく広がってきた
  mail、SNS、ブログ、ワープロ・・・
→今ではアプリ動作環境となっている

ドキュメントプラットフォームからアプリケーションプラットフォームへと進化した
→この変化に根本の規格から対処することになったものがHTML5

HTML5:
・仕様書800ページ超
・アプリプラットフォームとしての規格が増えた
・タグの種類が増えた
・XHTMLの後継でもある
 →きっちり受け継がれている
  XHTML=HTMLにXMLをマシン用に埋め込んだもの
・ページのタイトル、時間、個人のデータを入れるタグができる

セマンティック:
→意味論=ロジックに基づいて処理できる(~ウェブ)
・厳密性が求められている
・単一コンテキストを持つ閉じたネットワークでは有効

Web of Data:
・広大な地域に分散している研究員がデータを共有できるようにしたもの=ウェブ
・WebはもともとDB
・上記のことをきちんととらえ直してみる=Web of Data

リンクがコンセプト:
・関連する情報は役に立つ
・DBに対して貼られているリンクは1.41万個

DBpedia
BBC(英)の辞書

関連づけられたDBが存在することが大切

楽天のWeb of Data:
・WebAPIの公開
・研究所内でのデータ公開(Webからデータを抽出したもの)
・サービスの統合
・実験的な取り組み
・RDFストア

国会図書館:
RDFのデータを提供している

市民レベルの動きもある

LinkedData.jp

これからは自律・分散・協調+データ生成
→意識を変えていく

———————————————–
インターネットガバナンス徒然2010
———————————————–
JPNIC:
IPアドレス事業、インターネット基盤整備を行っている

インターネット:
・拡大している
・誰でも使うようになっている
・回線速度も速い

インターネットにも公共政策が必要になってきた

機器の標準化、ネットワークデザイン、相互接続といったインフラとアプリケーションによって便利になってきた

社会的な生活が営めるようにルールを決めていく→情報社会

社会規範と使い方→考えていく必要がある

何らかのルールを決めていかなければならない

インターネットにはルールがある、
そしてルールは自分で変えられることを知る

変える手順を知る

ルール策定の前提
・オープンフォーラム
 誰でも参加できる
・みんなで決める(ボトムアップ)

コミュニケーションは英語
・相手を正しく理解する
・自分の考えを正しく理解する
・黙っていては分かってもらえない

インターネットガバナンスに関わっている団体:
・IETF:技術標準化
    日本人100人参加
・APNIC:インターネットレジストリ
     2012年にIPV4が枯渇する問題などを扱う
     日本人16人参加
・IGF:インターネットに関する様々な問題を討議する
   政府・市民団体も参加

JPNICのサイトで情報を提供している

アプリケーションエンジニア→サービスを提供している
インフラエンジニア→サービスを受け付ける部分を担当
サービス事業者→知らなければいけないことが多い

サービス提供者の疑問=ルール等を気にする必要はあるのか?
・ルールはどんどん変わっていく
・ルールを知っていることで多面的にみれるようになる
・使っているOSがIPV6に対応しているか
・お客さんはIPV6、IPV4バラバラでアクセスしてくる
・日本だけで使われている訳ではない
・どこかで使われ始めたものは必ず影響として出てくる
・ルールに従っておくことで、イレギュラーな対応は減る

自律・分散・協調

なぜ地域毎にレジストラがあって、その中で
ルールを決める必要があるのか?
・地域の事情をくみ取る必要がある
・地域ごとに良い意味での競争がある

日本人の意見ははずれが少ないと思われている

世界で意見を通す場合:
・たくさんの他国の人と話して理解する、分かってもらう

現場の人が政策に関わることも大事

世の中のことを見聞きして世界へ出て行く

———————————————–
楽天ブックスiPhoneアプリ開発日誌
~導かれし者たち~
———————————————–
デバイス推進チームが開発

2008年12月:
・楽天トラベルアプリ

2010年6月:
・楽天ブックスアプリ
 雑誌立ち読み
 商品が買える

2010年7月:
・楽天イーグルスアプリ

2010年8月:
・楽天リサーチアプリ
・iPadアプリ

Android版アプリもリリースされている

2010年9月:
・旅メモ
・楽天証券アプリ
・楽天銀行アプリ

総計で12アプリ→力を入れている

Webのスマートフォン対応も進めている

2007年~
アクトビラ向けサービス

楽天ブックスアプリ:
2010年8月~

iJungle=イノベーション・プラットフォーム
    アプリがたくさん生まれた

担当サービスをアプリ化
→やりやすい

うる☆てく

当初社内にはiPhoneアプリのノウハウがなかった

兼務でアプリ開発

アプリで目指すもの:
・自分が使いたいもの
・シンプル
・ブラウザでの体験を越える

WebAPIを利用:
戻りはXML

ライブラリによって
パースにかかる時間に差がある(XML)

NSXMLParserがよい

libXML2もある
→アプリではこちらを採用

NSOperationqueue:
処理実行数などを制御できる

楽天ブックスアプリ=8つの機能がある

デフォルトで付いてくるサンプルプロジェクトが学びやすい

Webの決済機能をすべてカバー

暗号化→カテゴリを使う

NSURLRequest:
HTTPSでオレオレ証明書が使えない

リリース時は非公開クラスは使わない

iPhone4対応もすることになった

NSOperationに注意

画像名の後に@2Xを付ける(例:ul@2x.png)
→iPhone4に対応してくれる
 サイズの違う画像ファイルを2つ入れておく

Xcodeの設定を変えることでデバッグ情報が増える

——————————————–
トークセッション「ITエンジニアのから騒ぎ
~グローバルエンジニアへの道~」
——————————————–
海外で働くこと
・仕事の内容は変わらない
・生活で引っかかるポイントは人によって違う
・ソースコードで通じるところもある(図とソースコードが一番通じる)
・楽しめる、楽しめないは人による
・実際に話をするのが一番通じる
・少し時間が過ぎれば同じになってくる
 心配するほどのものではない(転職と同じくらい)

日本と海外の違い
・外国人は実利をとる
(仕事の進め方やシステムの拡張性に対する考え方など)
・バージョンアップ
  日本人は保守的(ノウハウが溜まってきてから行う)
  海外ではすぐに新しい物を使う(問題が出てきてから考える)
・海外では人の入れ替わりが多い=過去にこだわらない

日本と海外のエンジニアの違い
・プロジェクト内での役割分担などは同じ
・時間の使い方が違う(プライベートと仕事のバランス)
  海外→残業して無理やり終わらせたりはしない。やれる範囲でやる。
     サイドビジネスを掛け持ちでやっている人も多い(残業できない)
     マネージャーが絶対無理をさせない
・女性の仕事への参加の仕方が違う

エンジニアにとっての英語
・英語使うきっかけ=オープンソースの作者にメールを送った
・相手とどうコミュニケーションしたいのかが重要
・少し話し始めると通じる(共通の言語ができる)
・アメリカ人は他国の人が話す英語に慣れている

やりたいことをアピールしておくとチャンスが回ってくる

Eclipseでタブを半角スペースで入力したい場合

仕事でeclipseを使ってPHPのコーディングをしているのですが、タブを半角スペースで入力する設定にする際に時間を使ってしまいました。この手の設定は一度行うと後はそのままで問題なく使えてしまうため、毎回覚えずに終了してしまいます。なので、ここに書いておこうかと思います。

Pleiades All in One Eclipse 3.6 を利用している場合、
ウインドウ⇒設定から
「テキスト・エディター」を選択して、
「タブでスペースを挿入」のチェックボックスをチェックすればできました。

PHPカンファレンス2010へ行ってきました。(その2)

PHPカンファレンス2010で講演を聞いてきた時のメモ書きの続きです。聞き違いの部分などもあるかと思いますがご容赦下さい。

9/25 テックデイ
—————————–
基調講演 「PHP Then and Now」
—————————–
PHPの歴史
1993年 mozaicウェブブラウザ
1994年 PHP1
1995年 PHP2:今のような構文になった。オブジェクト指向ではなかった。

2005年 完全なオブジェクト指向へ

最新ver5.3:
・ver4に比べて高速
・スタック実装の改善
・例外処理も高速でシンプル
・コンパイラも高速かつサイズ小
・Win版は40%性能改善
・全体的に5~15%高速化

目玉となる機能:
・closuresの実装
処理の間に関数を呼び出せる
・namespaceの実装
バックスラッシュを1文字で扱える
・メソッドがどのクラスで実装したのか分かるようになった(__CLASS__)
・ガベージコレクションの実装/工夫
・NOWDOC、gotoの追加
・__DIR__の追加
・php_fpmの実装
・php.iniのユーザ向けファイル→.user.ini
・opensslの強化、openidの実装

変数でクラス名、メソッド名を指定できる

日付取得処理の改善:
・第三木曜日をイテレータで取得できたりする
・datecreateformat

この講演の資料:
talks.php.net/show/phpjp10
で公開される

古いバージョンのPHPソース:
museum.php.net
でダウンロードできる

—————————-
フレームワークアップデートLT
—————————-
CakePHP:
・リファクタリングが進んでいる
・PHP5専用になる
・PHPUnitの導入
Lithium:
・PHP5.3専用のフレームワーク
・ドキュメント 1.0のリリース時に用意される
Ethna:
・2009年10月2.5.0リリース
・UTF-8化
・国際化対応
・3.0開発中
racho:
・Object.php
・Doctest
・PHP単体で動く
Agavi:
・IISのサポート
・Azureのサポート
・例外処理の連結
codelgniter:
・世界第二位
・2011/2/19に東京でイベント
・軽い、覚えやすい、拡張が容易
ZEND:
・ドキュメントのアップデート
・コンポーネントの追加
Symfony:
・2.0開発中
・Httpkernel
・HttpAceralator=レスポンスをキャッシュ
・profiler

————————–
HiPHoP for PHP
————————–
facebook:
・ユーザは80億分/1日ぐらいの時間をサイトで使っている
・毎月30億枚の写真がアップロードされる
・1億人が利用している

PHP:
・言語の中で最も処理に時間がかかる
・メモリ使用量が多い

facebookでは、PHPのソースを他の言語でも再利用している

HipHoP for PHP:
・PHPのソースをC++に変換
・C++をコンパイルして実行

処理の流れ:
ソースの分析→型の推定を行う→コードを生成/出力

HipHoP用にソースを書き直さなければならない部分もある:
・eval()、create_function()
・順番(関数の定義順)は意味がなくなる
・コンパイルには時間がかかる→インタプリタを使う(HPHPi)
・apacheなしでも動く

HipHoP:
・オープンソース化されている
・PHPエクステンションをサポート
・5秒かかっていた処理を1秒に短縮
・実際の処理時間は2分の1程度になる
・PHPの最適化が限界に来たので開発された

————————————————-
Microsoft ♥ PHP ~ 2nd Stage ~
WebMatrix 登場!
————————————————-
IIS7でPHPサポート:
実行環境までマイクロソフトが作成している

SQLserverと接続するドライバも開発されている(PDOも使える)

PHP環境作成ツール:
Web PI→PHPのインストーラ=Web環境を作成する
Web Matrix→Webサイトを構成する

上記のツールの特徴:
・IISを個別にインストールする必要はない
・簡易的に様々な開発が行える
・DBクエリの実行も行える
・テンプレートも存在している(ASP用)
・ブラウザを切り替えて表示を確認できる
・SEOのチェックができる(外部サイトも可能)

http://microsoft.com/webに情報がある

————————————————-
文字コードに起因する脆弱性とその対策
————————————————-
Unicode: /¥ → MS標準: ¥

多対一の変換になるもの=文字化けが発生する

UTF-8:
・1〜4バイトで文字を表現
・5C問題は発生しない

半端な先行バイトによるXSS

5C問題:
・shift_jisで0x5cのコードが存在する文字を利用することによる問題
・SQLインジェクションに利用される

charsetの定義は正しく行う
→脆弱性が発生する場合がある

対策:
・最新のPHPを使う
・文字コードの指定をさぼらない
・mb_xxxxxx関数を使う

————————————————-
PHPストリーム概説
————————————————-
ストリーム:
・何でもファイルのように扱える、標準入出力みたいなもの
・Get、Postの指定、リクエストヘッダ等

ストリームフィルタ:ストリームを加工できる

————————————————-
新潟アクセス修飾子のご提案
————————————————-
アクセス修飾子:
public
protect
private

zendエンジンを修正することで修飾子を追加することができる

エラーメッセージの出力部分を探してそこからソース解析する

zend中間表記+パースの部分を修正する

————————————————-
PHPの中の人によるパネルディスカッション
————————————————-
PHPによって容易にウェブにアクセスできるようになった

PHP6での国際化:
・いまのところプランはない
・Unicode対応を急ぎすぎた

様々な機能を追加:
・使いやすさが減少して行く心配がある

型のチェックを厳しくするとソース全体へ影響を与える

内部をすべてUTF-8化する取り組み→4年位続いている

PHPのコミッタ:世界で1500人位いる

一人がすべてを決めるのではなく、
グループがコンセンサスをとりながら開発して行く形が望ましい

ユニコード対応:
マルチバイト圏の開発者はまだ少ない

facebook側:理想を言えばPHPの方でユニコード対応してほしい

————————————————-
ライトニングトークス
————————————————-
■CodeIgniterをベースとしたCMS「seezoo」をオープンソースでリリース
seezoo:
・CMS
・codelgniterを使っている
・2010/10/1に安定版をリリース

■日本一の twitter bot サービス twitter bot GENERATOR
twittbot:
・twitterボットを作成できる
・138万/1日つぶやき
・twitter全体のつぶやきの1%を占める

■激安VPS + nginx + PHP-FPM
nginx:HTTPサーバ、メモリを消費しない

■PirumではじめるオレオレPEARチャンネルサーバー
Pirum:
・PEARチャンネルを管理するツール
・PEARからインストールできる

■PHP で 3D プログラミング
phpopengl:OPENGLを使っている

■やったーPHPでPEGパーサコンビネータできたよー
OpenPEARPEG:
・パーサコンビネータ
・パーサを記述できる

PHPカンファレンス2010へ行ってきました。

先週のことになりますが、PHPカンファレンス2010という催しで講演を聞いてきましたので、その時のメモ書きを公開させて頂きます。聞き違いの部分などもあるかと思いますがご容赦下さい。USTREAM等でも当日の様子が公開されているみたいです。

9/24 ビジネスデイ
———————————————————————————–
基調講演 「GREE Platformの現状と今後の取組について」
———————————————————————————–
お題:
・どのようにしていきたいのか
・オープン化してみて

2010年7月の会員数→2100万人以上(mixi、モバゲーも同じくらい)

Nintendo DSの販売数=3000万台
→GREEも同じスピードで成長

30代以上の会員も3~4割存在

GREE:オープン化でアプリの充実を目指す(会員数3000万を目指す)

ソーシャルゲーム市場は数億円規模に:
2011~2012年には本格的になる見通し

ソーシャルゲーム:
・開発費を抑えてスモールスタートが可能
・広告費も段階的に増やして行け、かつ高い利益を目指せる

運用/PDCAの重要度が高い

2010年6月末オープン化開始:
・改善を続けていかないとプラットフォームとして育たない
・画面/仕様を変更
・パートナーさんのアプリをCMで紹介(GREEが全額を負担)
・コンサルティングを行う

オープン化の結果:
・ユニークユーザー数の増加
・自社開発ゲームへのネガティブな影響はなし
・サイト導線を改善し、課金額・会員数も増加

4つのポイント:
・オープン=参入しやすい
・サービス改善=変更・改善を繰り返してゆく。トラフィックも変わってくる
・コンサルティング=データの提供、データに基づいたアドバイス(パートナーとともに成長してゆく)
         ゲームはそのまま公開してうまくいくケースは少ないので、ベータ期間を設けたりする
・プロモーション支援=年末までに30タイトルのTVCM(GREEが全額負担)

今後の展開:
・スマートフォン対応(アンドロイドがくる)
・アジア・北米への展開

—————————————————–
モバイル ソーシャルアプリの開発と運用
—————————————————–
ウノウ(株):フォト蔵を運営

まちつく:300万インストール

オープンソーシャル:
・ユーザはプラットフォームを介してアクセスする
・友達・自分情報を取得できる
・APIを利用する
・OAuthで機種/個人を特定する

OAuth(opensocial_php_client)→グーグルコードのサンプルソースが参考になる

OAuthが使えるライブラリ:
・OAuth Consumer And Server Library for PHP
・Pear OAuth
・PECL OAuth
→Pear OAuthが一番良い

毎回データを取りに行くと遅くなる=キャッシュ、キューを使う処理が必要

APIがつながらないことが多いので、そのための処理が必要

オープンソーシャルのサポート側:
・問い合わせが多いのでシステム化が必要(1日最高でメール1000通)
・問い合わせを減らす工夫が必要
・重い負荷のかかった機能を一旦切り離して停止させる覚悟も必要

オープンソーシャルの運用:
・エンジニアに負担をかけないようにする
・ユーザアクセス数の少ない時間帯にメンテナンスを行う

オープンソーシャルの設計・企画:
・友達リストを取得するような処理は重いので避けた方がよい
・APIをできるだけ使わないようにする
・一日一回しかできない機能=午前4時などに更新するようにするとトラフィックが安定する
・やっている時にニヤッとしてしまうような機能がソーシャルには重要

オープンソーシャルの開発方法:
・Proxyサーバ、sandobox+firemobilesimulatorを利用
・もしくは通常のサイトとして開発

システム構成:基本はLAMP環境
・memchache→これがないと死ぬ
・Q4M
・Nginx→プロキシ
(下記二つは運用・設定ファイルの更新に利用)
・Puppet
・Capistrano

DB:
・可能な限りメモリを増やす
・ボトルネックはDISKアクセス
・できるだけデータをメモリにのせる
・レプリケーションはあまり効果がない
・マスター分割すると性能が2倍になる(ただし開発コストも増大)

フレームワーク:
・symfony(ORMに詳しくなくても実装できる)

swfEditor:swfのバイナリを書き換えられるツール

—————————————————–
~モバイルオープンソーシャルにも対応!
~ OpenPNE Ver3.6紹介
—————————————————–
手嶋屋:OpenPNE(2005年スタート)を開発、オープンソース化した会社

SNS:情報ネットワーク社会のさきがけ
   週100~150サイトが新規開設されている

エンタメ系のSNSが多い(オンラインゲーム、ファンクラブ、ケータイゲームなど)

OpenPNE:日立、NEC、セイコーエプソン、バンダイ等で使われている

OpenPNE3.0:
・つぶやき機能を追加
・日記、ランキング、コミュニティもあり
・機能は着脱可能、モバイルでも利用可能
・モバイル対応

Symfonyを利用している:
・OpenPNEのプラグインはSymfonyのプラグイン機能を利用している
・OpenPNEソースはSymfony開発時に参考になる

Ver3.7以降、最新のモバイルオープンソーシャルに対応していく:
・twitter機能に対応
・iPhoneにも対応予定

OpenPNEを利用している150万ユーザークラスのサイトも存在している

資料はあとでブログに公開される(という話でした。)

—————————————————–
大ヒットソーシャルアプリの裏側
—————————————————–
ソーシャルアプリ:
・SNSの機能が使えるアプリ
・APIなどを利用する
・集客コストがかからない
・OpenSocialAPIを使うことによる開発コストの削減

誰も考えないようなテーマ、独自の機能を考えることが重要

他社との差別化をしないと生き残れない

恋したキャバ嬢:
・大ヒット
・負荷がすごい(最大2000PV/sec)

競合他社とテーマが重なった場合、新規機能を追加して差別化をしていかないとだめになる

手戻りが発生するとリリースが遅くなる(機会損失)
→自ら提案することで企画の意図が分かるようになり、手戻り減につながる

企画と一体になる=楽になる

負荷について:
ユーザ固有のデータ=アクセス、更新頻度高
→ソーシャルアプリでは特に負荷が高い、マスターDBへの負荷集中

Ganglia=オープンソースのモニタリングソフト

Symfonyがベース

画像合成処理:
・キャッシュは非効率
・ローカルファイルはI/Oアクセスが増える
・素材ファイルのみキャッシュ+GD高速化で対応

マスターDB対策:
・なるべくDBに接続しない
・クエリ最適化
・使わなければ接続を切る

DBコネクションの節約方法:
・memchacedの利用
 DB更新時にキャッシュも更新
・APCキャッシュ→更新が少ないときに有効
・KVSの利用(TokyoTyrant)
 1.データ消滅の心配がいらない
   →頻繁に更新されるステータスに有効
 2.不整合が起こりうる
   →例外が発生してもユーザが得をするかたちで解消できるような処理の流れを作る
・スレーブDBを利用
 レプリケーションの遅延は起こりうる 

APIとの通信:
・レスポンスタイムアウトは普通に起こりうる
・APIへのリクエスト→DB更新とは分ける

—————————————————–
Scaling the Worlds Largest Social Gaming Network
世界最大ソーシャルネットワークゲームのスケーリング
—————————————————–
Zyngaのミッション:ゲームを通じて世界とつながる

ソーシャルゲーム:
・プレイが簡単で楽しい
・他人とつながる

月間ユーザ2億4000万
ゲームの体験者数:3億2000万

拠点は世界にある:
・世界のインターネット人口の10%がプレイしている

Facebookのトップゲーム:Zyngaが占めている

一週間に1000台のサーバを増設することもある

データ量1PB

システムの構成:
Webサーバ ー memchache - DB

サーバはすべて水平方向にスケール:
・キャッシュし、非同期

完全に自動化、API化されている

APIレスポンスキャッシュ内蔵

KVSを利用

DBはデータストアとしてのみ利用する

持続型memchached(membase)を利用
→分散型KVS
・速度、柔軟性がある
・クラスター内に存在している

利用しているもの:
membase
mcmux
(上記2つはオープンソース)
pecl-memchached
FontLabel

ゲームごとに作り方が違う

既存のソースを流用しているため、
特定のフレームワークに頼る必要は無い