Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à Zynga
Similaire à Zynga (20)
Zynga
- 2. 自己紹介 新井啓太 Zynga Japanテクノロジーチーム GM • twitter id: cocoitiban • Mail: cocoiti@gmail.com 趣味 • ドメイン取得(himote.jpとか..) • お酒飲みながらPHPマニュアル読む こと 2
- 3. 自己紹介 •技術とのかかわり • 個々一番とネットでは名乗っていま す • だいたいPHPエンジニアです。 • Net_TokyoTyrant • Ethna 今日はPHPの話しません 3
- 4. ジンガジャパン株式会社 元ウノウ株式会社 • ウノウラボ http://labs.unoh.net/ • フォト蔵 http://photozou.jp/ • まちつく! http://mt9.jp/ 2010年8月に ジンガジャパン株式会社に！ 4
- 5. Zynga? Facebookで見かけませんか？ • CityVille • FarmVille • Treasure Isle And more….. 5
- 6. Zynga Japan のサービスたち 6
- 7. Zynga Japan Amazon Web Service 使ってます！！！ 7
- 9. 2009年10月くらいまでは小企業 •17人の会社 mixiリリース リリースしてから1日10万人登録 2011年4月6日現在340万インストール 9
- 10. 2010年8月までこんなキーワードの会社 PHP5.x(5.3も使ってた） Apache Nginx MySQL(and Q4M) memcache Puppet, capistrano, nagios ,cacti 10
- 11. クラウドへの歩み Zynga Japanでは物理的なサーバを持ってい ます(500台程度) 5人くらいで回してます Zynga 本社は、AWSのヘビーユーザ。 「今日はアクセス多いから1000台増やして おこうぜ」 みたいな会話が成立するような会社 11
- 12. Zynga Japan と Zynga 本社
- 13. 関係性 技術に関しては 「似ているが、違うアーキテクチャ」 •携帯という特殊なバックグラウンド •分離していて適用できるころは適用 解析ツール 本社が提供しているAPI群 13
- 16. ソーシャルゲームの特徴
- 17. (モバイル）ソーシャルゲームでの実装 ひたすらAPIをたたく • 友達取得 • Feed 負荷との戦い • 想定しにくいアクセス数 –友達招待やプラットフォーム側からの 導線で、突然すごいことに • スケールアウトの手法も時には大切 17
- 18. 負荷との戦い •まちつく!mixi版は時間との戦いでした • 一日10万ユーザーづつくる状況 • 画像処理をキュー処理(1日) • データベース分割 (2日) • あらゆる動かない箇所の修復 サーバ購入も進めていたが、一週間くらい は待ち状態となってしまった 18
- 19. 負荷との戦い •そういえば2009年にもAmazon使ってまし た。 • DiskIOとネットワーク帯域の問題から動 的に変更される画像をS3に配置する処理 19
- 20. クラウド
- 22. Zynga Japanの現在のクラウドにおける環境 AWS - （主に)東京リージョン - EC2 - EBS - S3 - etc.. RightScale 22
- 23. Zynga Japanの基本的な構成 Nagios puppetとか Nginx Nginx Apache + PHP Apache + PHP Apache + PHP Apache + PHP c1.xlarge m1.xlarge memcache memcache MySQL MySQL ※MySQL以外も利用している案件があります 23
- 25. Zynga Japanと、AWS Tokyo そして苦悩 「APIのエントリポイントわからない」 「そういえば、誰もRightScaleの方に連絡し てないからまだ使えなくね？」「あ・・」 「s3がないとEBSSnaphot使えなよね」 25
- 26. AWSを使ってよかった点 •人的コストが下がった • DCやネットワーク機器などのメンテナン スコストが含まれた金額 • 管理画面等のツールがRightScaleに一部 統合できた •ハードウェアにまつわるコスト • ハードの選定 • 資産持たなくていい 26
- 27. 東京リージョン利用開始しはじめていいと思った所 低いレイテンシ？ • sshでログインして開発しようという気に なる。 全機能使えるので、個人のブログレベルで 相当な情報がある。 玉川さんがいる。 27
- 28. AWSでサイトを構築するコツ
- 32. サーバが起動したらサービス利用可能であること •起動時の設定 • RightScriptを定義する • RightScaleのTemplateでRightScriptを組 みわせる • 起動時に定義を入力する • Ex. MySQLのマスターかスレーブか、 どのサーバのスレーブか 32
- 33. サーバが起動したらサービス利用可能であること •設定の維持 • Puppet（もちろん別のツールでOK) •監視/統計の自動追加 • Nagiosへの自動追加ツール乃作成 • RightScript + collectd 33
- 34. リリース手順が用意であること •デプロイツール • capistrano(サーバ全体にアクセスする） • 1台のサーバから、デプロイするファ イルを配信する形 • デプロイ先のサーバは、AWS及び RightScaleのAPIから取得(サーバ名、 タグで判別） •将来的にはCIとの統合も検討 34
- 36. 冗長化 冗長化が簡単なもの • Webサーバ - ロードバランサで対応 • ロードバランサ – DNSラウンドロビン • すいませんELB使ってません… 冗長化にアプリケーションの配慮が必要なため 使っていないもの • データベース(すいませんRDBは使ってません) • nosql (membase, cassandra) 36
- 37. 冗長化 冗長化が必要ないようにするという判断したもの • memcache (キャッシュとして利用する） あと、AWS 全体を冗長化 • マルチアベイラビリティゾーン（まだ、 私たちは利用開始してないですが。） 37
- 38. スケーラビリティ •スケールアップ •スケールアウト 38
- 39. スケールアップ ワンランク上のインスタンスを使う • DBだったらメモリが多いとか DISKを高速化する • EBSを利用しソフトウェアRAID0の構成 を組む • ただしRAID0なので、EBSの障害等のリ スクが増すことになる 39
- 40. スケールアウト データベース分割 • テーブル単位での分割1,2 –トランザクションが利く単位で分割 –二層コミットを利用する –トランザクションをあきらめる • ユーザID単位での分割※注意 –シェアーディング –KVSにも適用可能(nosqlではなく） 40
- 42. 独立性 サービスの継続性 • 一部の機能が使えなくても一部は使える ような状態 • ユーザ単位でサーバが分離した場合 42
- 43. 独立性 システムの運用 • インスタンスを10個同時に立ち上げるよ うな処理、svnから特定のデータをチェッ クアウトしようとする->SVNサーバが落 ちた • 独立性を確保できないものについてはs3 を利用する。（クラウド！） 43
- 44. 終わり