完全公開!ソーシャルゲーム設計事例:プロローグ

はじめに

こんにちは。樽八です。

ちょうど1年ほど前になりますが、弊社にてGREEプラットフォームにおけるソーシャルアプリ携帯ゲーム「偉人伝心」のリリースを致しました。
その時のシステムに対する機能要求および非機能要求に対してできたこと、できなかったことをエンジニア視点で列挙したいと思います。

システムに対する要求と、達成、未達成状況

ほぼ達成された要求項目(4項目)

2000万PV/日のアクセスに耐えるシステムを作ること。

  →負荷試験時において、画像合成、Flash合成ページを含めて、webサーバ10台時の構成において、1400リクエスト/秒(単純計算だと1億2000万PV/日)以上のスループットを達成。
 (※残念なことに、これだけの負荷が実際に掛かることはありませんでした。)

会員数の増減に合わせて速やかにシステム全体の構成を変更出来ること。

  →サーバの追加に応じてシステム全体のスループットを上げることのできる、スケールアウト可能な構成としました。
  →上記負荷試験時の数字もWebサーバの追加によりさらに引き上げることが出来る事を確認しました。

予期される障害発生に関しては、たとえスループットが落ちた状態状態であったとしても通常サービスの継続が可能であること。

  →全てのHW機器を冗長化して構築しました。

特定の機器が障害によって復旧不可能な状態に陥っても、サービス継続に必要なデータが復旧可能であること。

  →上記、HW機器の冗長化に加えて、データの保有に関しても冗長化を行いました。

一部達成できなかった要求項目(2項目)

負荷のピーク時においても、各ページの応答時間が5秒を超えないこと。

 負荷試験時には問題が無かったのですが、実際の運用環境においては夜間の高負荷時において、上流のSNSプラットフォームへのAPI発行に時間がかかるようになりました。キャッシュ可能なAPIはキャッシュを参照していたのですが、規約上キャッシュ不可のAPIもあり、5秒の制約を守るためにはAPIの実行結果を待たずに混雑中のページを表示させなければならないことが発生しました。

サービスを動かしながらの頻繁なアップデートおよびデータ更新が可能であること。

 基本的には無停止でのアップデートを行っていたのですが、MySQLのAlterTable文を発行しなければならない場合においては一時的なメンテナンスによるサービス停止(数分程度)を必要としました。
  これを回避する手段はあるのですが、非常に複雑なシステムとなり、また、HW投資もかさむため、今回のシステムにては上記のメンテナンスの為のサービス停止を許容しました。

どうやって要求を達成したか(以下、本編を前編:後編の2回に分けて記載します。)

上記要求項目の達成に関して行ったことを以下の4つの観点から記事を公開ていきたいと思います。

各種コンテンツ生成Webサーバの最適化について

  • XHTMLのコンテンツを吐き出すWebサーバ
  • 画像動的合成Webサーバ
  • Flashの動的合成Webサーバ

それぞれの役割と構成についての簡単な説明。

キャッシュの利用ポリシーについて

  • 生成されたコンテンツのキャッシュ
  • リロード対策用ページキャッシュ
  • 関数キャッシュ
  • DBへのアクセスのキャッシュ
  • SNSプラットフォームへのAPI発行

等のキャッシュポリシーについて説明 。

データ保存レイヤの最適化について

  • サービスで扱う各種のデータをどういうデータとして分類したか。
  • 上記のそれぞれに分類されたデータをどう扱ったのか。 

各サーバの冗長化について

今回のサービスにおいて利用したサーバそれぞれにおける冗長化についての簡単な説明


Comments are closed.