CESA Developers Conference 2010(CEDEC 2010)レポート
各社が公開、大規模オンラインゲームのバックエンドの秘密
データベース運用やインフラ構築のノウハウ。サービスを支える知恵と工夫
データベース運用やインフラ構築のノウハウ。サービスを支える知恵と工夫
8月31日より9月2日まで開催されたゲーム開発者向けカンファレンス「CEDEC 2010」。今年の特徴としてソーシャル系を含むネットワーク関連のセッションが充実していたことが挙げられる。中でもこのような機会でなければ滅多に聞くことのできない、オンラインゲームのバックエンドについての話題も豊富であった。
本稿ではソーシャルゲームやオンラインゲームのインフラとなっているバックエンドシステムについての講演を複数ピックアップしてお届けしよう。ソーシャルゲームの雄として知られるGREE、幅広いジャンルのオンラインゲームを手掛けるセガ。趣の異なるジャンルでサービスを提供している各社の、それぞれの手法に注目したい。
■ ソーシャルゲームは、データベースとの戦い──GREEの講演より
GREE取締役執行役員CTO、藤本真樹氏 |
GREEにてバックエンド担当エンジニアを務める、増山和幸氏 |
GREEのサービス構成 |
ソーシャルゲームでのバックエンド構成。データベースサーバーのボトルネック解消がキモとなる |
まずご紹介するのは「大規模ソーシャルゲームのつくりかた~60分でわかるサーバーサイド技術~」と題するセッション。国内大手のSNS「GREE」を運営する株式会社GREEのCTO藤本真樹氏、エンジニア増山和幸氏が登壇し、ソーシャルゲームのバックエンドについてのノウハウが披露された。
GREEではSNSサービスを提供すると同時に多数のソーシャルゲームの提供も行なっている。藤本氏の紹介によれば、2010年6月時点の会員数は2,059万人、月間357億、1日11億のページビューを叩き出す。ユーザーの最大同時接続数は10,000以上、数千台のサーバーで平均0.2秒のレスポンスタイムを達成しているという。
続いて増山氏がソーシャルゲームのしくみについて解説。非常に規模感のある形で提供されているソーシャルゲームだが、サーバー構成の基本概念は一般的なコンシューマー向けオンラインゲームとほぼ同じ。クライアントがウェブブラウザになり、ゲームサーバーがウェブサーバーになったという形だ。
その中で決定的に異なるのは、通信の内容だ。一般的なオンラインゲームでは長いセッションの中で通信が非同期に行なわれることに対し、ソーシャルゲームは一般的に1セッションがごく短く、「リクエスト→待機→応答」という形で同期して完結する。Webブラウザでの実行を前提とするからこその特性だが、それゆえソーシャルゲームは大規模方向へスケールしやすい。Webサーバーを増やし、アクセスを分散すれば良いためだ。
しかし、そこには避けがたいボトルネックがある。ソーシャルゲームでは1セッションが短く、クライアント側に情報が長期的に保持されない。このため情報は基本的にサーバー側で常に保存状態にしておく必要があり、アクセスがあるたびに毎回、データベースからの読み出しと更新が発生する。こうしてほとんどのケースで、CPU、メモリ、ネットワークよりも、データベースのディスクアクセスが先に限界になってしまうという。ソーシャルゲームは、「日々、ディスクI/Oをどう捌くかとの戦い」と言う藤本氏。
そこで、ソーシャルゲームを上手く運営するためには、データベースへの負荷を低減する、あるいは負荷を分散することが必要になってくる。藤本氏はそのための策として、(1)レプリケーションによって参照専用のデータベースサーバーを増やし、読み出しアクセスの負荷を分散する、(2)オンメモリファイルシステムでデータベースを運用し、ディスクアクセスをなくす、(3)メモリキャッシュや、Key Value Store(KVS)と呼ばれる低負荷のデータ保存システムを間に挟むことでディスクアクセスを減らす、の3手法を紹介した。
また、コミュニティ管理者がメンバーにメールを一斉配信するような機能については、通常の同期通信で数十万ユーザーが対象となってしまうと時間がかかりすぎて破綻してしまうという。こういった重い処理については、ウェブサーバーの裏に「Queue Server」と呼ばれる、タスクをキューイングして非同期処理サーバーに割り当てていくシステムを設置して対応しているとのことだ。
このほか藤本氏は、データベースサーバーがダウンした際の対処をサービスを停止することなく行なう方法や、現在のサービスで利用しているソフトウェアについてなど、実践的なノウハウを幅広く紹介した。大規模に提供されるソーシャルゲームをいかに少人数で効率よく運営するか。そこにはWebサーバー、データベース、各種のソリューションからなる「パズル」を解くような面白さがあった。
■ データセンターの裏側で、コストとの戦いを繰り広げるセガのインフラチーム
講演を行なった阿形氏。インフラ担当の切実な思いを込めてスピーチした |
反論を許さない説得力 |
「オンラインゲームのインフラ構築」と題するセッションでは、よりハードウェア寄りの話題が展開した。講演を行なったのはセガのネットワーク運営部、技術チームに所属する阿形佳美氏。
阿形氏は「ファンタシースター」シリーズ、「プロ野球チームをつくろうオンライン」、「Jリーグプロサッカークラブをつくろうオンライン」その他セガのオンラインタイトルを支える、サーバーインフラの構築を担当している。その他にもWebサイトのサーバー構築も担当するなど、なかなか幅広く携わっている様子だ。
阿形氏によると、セガのオンラインゲームを運用するためのサーバーインフラに求められる条件は次の通り。年中無休で稼働し、アクションゲームもあることから低遅延であることが必要。ゲームパッチ等のダウンロードが常時発生するため定常的に200~300Mbpsの帯域を使用する。タイトルのリリースやアップデート時に生ずる短期集中的な転送量増大への対応も必要で、新規タイトル等のために拡張性も確保。海外へのサービスも行なっているため海外向けのインフラも考慮しなければならない。
といった条件を満たすインフラを整備するのが阿形氏ら技術チームのミッションだが、とにかく上からは「安くしてね!」の一点張りで、常にコストとの戦いを繰り広げているという。確かにお金をかければなんとかなるが、それでは商売が成り立たないというわけだ。そこで基本は阿形氏が「ケチケチ・インフラ構築」と呼ぶ哲学に基づくことになる。
コストを下げる上で重要となるというのがインフラの稼働率。この点で阿形氏は大胆な割り切りをしている。曰く「ゲームが止まっても人は死なない」。限りなく100%の稼働率を目指せば大きなコストがかかってしまうため、敢えてシンプルな構成にすることでトラブル時の対応を簡単にしている。システムの冗長化もほぼ最低限。それでも年間稼働率99.999%くらいの稼働率を達成しているそうで、無理にそれ以上を求めることはしていないということのようだ。
続けて阿形氏は「サービスの基本ポリシーなんてだいたい綺麗事です。全部貧乏が悪いんです」と冗談めかして毒を吐きつつも、限られたコストの中でいかに現実的なインフラを構築するか、そのノウハウについて話を進めていった。
サーバー設計においては開発部署・会社の違い、担当者の違い、開発時期、サービス内容といった各種の違いによって全部違う設計になってしまうという。これはインフラ担当者には相当な負担になってしまうようで、阿形氏は「ホント勘弁してください」と連発。これには会場の聴講者も、幾分の共感と同情を交えた苦笑を禁じえなかったようだ。
・実地に生かされる、経験に学んだノウハウ
電力の削減方法。地道にミニマム主義を実践 |
深刻なパフォーマンス問題は、根本的にソフト側に問題があることが多く、ハードウェア増強で解決できないこともあるという |
セガのネットワークインフラの構成。コスト対策や冗長性の確保のため自前でBGPを管理。複数のISPに接続している |
仕事の裁量が許される範囲としてハードウェアの選定やネットワーク設計くらいしかないというインフラチームだが、とりあえずその範囲内でやれることとして「消費電力の削減」を挙げている。電力を減らせばラックあたりのサーバー台数が増やせて年間数百万円の節約になることも。また電気代も数十万円という規模でのコスト削減につながるという。
排熱によってサーバーが壊れるというトラブルの削減にもなる。実際にあったトラブルとしては、一般的なインフラ構築で勧められる形のままスイッチングハブをラックの最上段に設置していたところ、サーバーの排熱が全部集まってきてスイッチがクラッシュし、そのラックの通信が全滅してしまったことがあるという。「スイッチは1番下に置くことをオススメします」と阿形氏。
また、オンラインゲームサービスで必ず問題になるパフォーマンスについても面白い知見があった。通常は性能が足りなければハード追加でなんとかなると考えるものだが、実際はそれで解決できた試しがない、たいていはソフト側に問題があることが多いのだという。
ある例では、開発チームの求めるままハードを追加した挙句、症状は悪化の一途を辿った。さらにハードを追加して……とやっている間に、やがてソフト側の修正で問題が劇的に解消。その瞬間から大量のハードウェアが余ってしまうという結果に。「どうすんだよこのサーバー……」と毒を吐く様子に、会場も大爆笑だ。
その教訓として、ゲームのリリース前に「ユーザー行動を模擬するシナリオテストをしっかりやることが必要」という阿形氏。しかし現状としては、おざなりになりやすく、現在もおざなり気味だという。シナリオテストのためには全システムが完成せねばならず、その段階ではリリーススケジュールが差し迫っているケースがほとんどで、重厚なテストを実施する余裕はなかなか……という現実があるようだ。
このほか、データセンターと回線周りの話題もあった。セガでは既存のデータセンターにシステムを置いて、回線は自前で引いているという。回線は複数のISPから引きこんでおり、ISP間の通信経路制御に使われるBGPルーターを自前で設置。このシステムではISPを自由に選べるので、ゲーム用の通信は遅延の少ない最適経路にルーティングし、ダウンロードの通信は値段の安いISPに流すというポリシーを用いる。これもコスト削減につながってくる工夫だ。
回線の使用についてありがちだと阿形氏が指摘するのが、ゲームクライアントやパッチの配布開始時のアクセス集中。中でもクライアント配布日時を事前にアナウンスするのは危ないという。ユーザーが大挙して待ち構えてしまい、公開した瞬間に凄まじいアクセスが集中してしまうからだ。
実際にあった失敗談として次のようなエピソードが紹介された。あるゲームでサービス開始とクライアント配布を同時に設定し、しかも、ゲームサーバーとダウンロードサーバーが同一のネットワークにあったというケース。当然アクセスが集中してクライアントはDLできない、よしんばDLできても回線がパンクしていてゲームもできない、という最悪の状況。「やるなら予算を確保してくださいね」と阿形氏の切実なリクエストが心に突き刺さった。
・自分たちが何も悪くてもトラブルは発生する。そんな例
構成の選定について。仮想化はパフォーマンス的に益が薄いが、クラウドの拡張性は正しく使えば魅力的 |
あくまで身の丈に合った方法で最善を目指す。専門家特有の「知恵」を感じられるセッションだった |
新しい試みとしては、セガでは現在クラウドシステムの利用を視野に入れているそうだ。パフォーマンスが重要なオンラインゲームのサービスでは基本的に従来型のシステムが良いものの、クラウドのスケーラビリティも魅力。そこで、パフォーマンス問題については「クラウドを前提としてゲームを設計し、問題ないようにしている」とのことだ。
このほか、いくつかの興味深いトラブル例が紹介された。どこかのISPの接続点で輻輳が置き、それがたまたまセガのデータセンターに対する通信のベストパスだったというケース。ユーザーからの通信がすべて海外を経由するようになってしまい、「ファンタシースターユニバース」のユーザーから「どうなってるの?」と問い合わせが殺到したという。
チェコを震源地として誤ったルーティング情報が伝達され、各所で切断が発生した事件。これについては、BGPを制御できる強みを活かして、影響を受けていないルートに経路を切り替えることで対応が可能だった。
パケットフィルタリング事件というのもある。P2Pファイル交換の使用を抑制する目的で各ISPの最新ルーターにフィルタが導入された際、「〇〇チームをつくろう」シリーズのパケットがBitTorrentのパケットと誤認され、プレイ開始数分で切断される症状が続発。急ぎ連絡をとりセガのネットワークはスルーするよう変更してもらい、なんとか対応したとのことだ。
まさにインターネットは複雑怪奇、どこかで発生した不具合の影響が表に現われてくるか予測しにくい世界。ゲーム中にサーバーダウンや通信不良で不便な思いをすることがあっても、それが「滅多にない」ような話であれば、あまり目くじらを立てず、阿形氏のような裏方の努力を応援してあげて欲しい。そんなことを思うようになったセッションであった。
http://www.cesa.or.jp/
□「CESA Developers Conference 2010(CEDEC 2010)」のホームページ
http://cedec.cesa.or.jp/
(2010年 9月 3日)