CESA Developers Conference 2009現地レポート
コナミがアップデート配信のために投入したP2P技術の秘密を公開
「BitTorrent」を活用して配信コストを大幅に削減。ユニークな取り組みの実態を語る
 |
9月1日～3日開催
会場：パシフィコ横浜
ますますオンライン化が進むコンシューマーゲームの世界。CEDEC 2009では﹁ネットワーク﹂がひとつカテゴリとして扱われており、様々なネットワーク関連の技術セッションが開催されていた。
その中で、多くの開発者の関心を集めたセッションのひとつが、コナミデジタルエンターテイメントの技術者 佐藤良氏が講演した﹁P2P通信技術‥BitTorrentプロトコルを用いた大容量データ配信﹂だ。このセッションでは、コナミの人気タイトルである﹁メタルギアオンライン(MGO)﹂や、﹁ウィニングイレブン 2009﹂のアップデータ配信に使われているP2P技術についての実例紹介が行なわれた。
P2P技術というと、WinnyやShareといったファイル共有ソフトウェアで採用されていることから、一般的には﹁なにか得体の知れない技術﹂というイメージがあり、企業側にとっては﹁通信のクオリティが保証できないのではないか﹂という漠然とした不安が持たれている。そのためメーカーの立場としては、大規模な導入にはかなりの抵抗があるのが実情といえるが、コナミではそれをいち早く導入したところに採用事例としての面白さがある。
果たして、コナミがどのようなP2P通信技術を導入し、それがどのような効果をもたらしたのだろうか。佐藤良氏による実例紹介を通じて、その中身を見てみよう。
■ 速くて確実でカネもかからない、そんな都合の良いデータ配信方法が世の中には存在する!
■ 速くて確実でカネもかからない、そんな都合の良いデータ配信方法が世の中には存在する!
 |
| コナミデジタルエンタテインメントの佐藤良氏。やわらかな語り口で自身の取り組みを紹介した |
 |
 |
| セッションのテーマは「データ配信」。ピーク時に回線がパンクして、なかなかダウンロードできなかったという経験をお持ちの読者も多いはずだ。それを解決する手法があるという |
大容量のデータ配信は、自社でゲーム本体やパッチを配信するゲーム企業にとっては頭痛の種だ。ゲーム本体を配信するには、大規模なゲームになると数GB、小規模なゲームでも数百MBのデータをユーザーにダウンロードしてもらう必要があり、定期的に発生するパッチの配信でも、その都度数十から数百MB単位のデータを配信しなければならない。
しかも、データがダウンロードされるペースには一定の法則がある。すなわち、公開初日にアクセスが集中し、その後は急速に需要が低下するということだ。データを配信する側としては、ユーザーが問題なくゲームデータをダウンロードできるようにするために適切な通信帯域を確保しなければならないが、公開直後に必要な帯域と、長期持続して必要になる帯域との間には数百倍もの差があるために問題が生ずる。
つまり、ピークの通信トラフィックにあわせて通信帯域を確保すると、それがフルに活用されるのは初日か2日目だけで、それ以降はほとんど無駄になってしまうということだ。ところが、一般的なデータの配信方法であるWEBサーバーをデータセンターに置いて運用する方法では、帯域確保の契約が数カ月単位だったりするので、なかなか融通が利かない。
講演を行なったコナミデジタルエンタテインメントの佐藤良氏は、ネットワーク関連の技術開発を担当する立場から、この問題について論点をまとめている。
一般的なデータ配信の方法としては、自社でデータセンターの帯域を確保してWEBサーバーを設置してそこから配信する方法や、データ配信を専門とするCDN(コンテンツ・デリバリー・ネットワーク)企業のサービスを利用する方法がある。佐藤氏によれば、CDNを利用する方法ではコストが配信総量に応じて決まることが多いようで、自社で膨大な帯域を長期間確保するよりは多少効率が良いものの、やはりそれなりの金額がかかってしまう。
そこで佐藤氏が注目したのが﹁P2Pを利用する﹂という方法である。P2Pというと様々なファイル共有ソフトウェアが代表的な例として思い出されるが、佐藤氏が求めたのは﹁配信ファイルを管理できる﹂、﹁匿名性がない﹂、﹁技術的にこなれている﹂の3条件を満たすプロトコルだ。
そこで見つけたのが﹁BitTorrent﹂プロトコルである。これは米BitTorrentが開発、提供しているプロトコルあるいはソフトウェアで、プロトコル仕様が公開されており、商用のクライアントソフトウェアのほか、オープンソースで開発されているクライアントがいくつも存在しているなど、手っ取り早く利用するには非常に都合が良いものだ。
理論的には、P2Pでデータを配信する場合、どこか1箇所にソースとなるデータを用意すれば、あとはそれをダウンロードした利用者自身によって2次配信が行なわれ、連鎖的に利用者間でデータがいきわたることになる。したがって、データ配信の負担は全体で分散され、配信企業側のコスト負担は相当レベルで軽減される。佐藤氏はこれを﹁使う人が、使うだけ負担するモデル﹂と表現し、インターネットの特性的にもっとも好ましい形態なのではないか、と話している。
問題は、十分に快適な通信スピードを確保できるかどうか、全てのユーザーに確実にデータがいきわたるかどうか、ということになる。それが満たされるのならば、WEBサーバーからの配信、CDNを通じての配信に比べ、大きく上回るメリットを持つ配信手法ということになる。果たしてコナミではうまくいったのだろうか。
 |  |  |
 |  |  |
| データ配信方法の比較。WEBサーバーをデータセンターに設置する方法では、ピーク時の予想帯域が大きく外れてしまうと企業側、ユーザー側ともに悲惨なことになりがち。CDNを利用する方法ではややコストが削減でき、それと同時にピーク時でも一定のクオリティが期待できる。P2Pではさらにコストが削減でき、極端なアクセス集中が発生しても対応できる可能性がある | ||
■ 「BitTorrent」プロトコルによるデータ配信の仕組み
 |
| BitTorrentのシステム概念図。「トラッカー」、「シーダー」、「リーチャー」の3者がネットワークを構成する |
ここで佐藤氏は﹁BitTorrent﹂のプロトコル仕様について解説を進めた。海外ゲームファンの中には、公式サイトからPCゲームをダウンロードしようとしたら、まずBitTorrentクライアントをダウンロードさせられて、それを実行すると、海外かどこかのホストからじわじわとゲームデータが送られてきた、という経験をした方もいるだろう。基本的には、コナミがとった方式はそれと同じものだ。
BitTorrentプロトコルでは、配信側の設備として3種類のサーバーが必要になる。ファイル本体のありかを特殊なフォーマットで記した﹁.torrent﹂ファイルを配布するWEBサーバーと、接続を管理する﹁トラッカー﹂と呼ばれるサーバー、そしてオリジナルのデータを100%所有し、それを常時配信する﹁シーダー﹂と呼ばれるサーバーである。
まずユーザー(ピア)はWEBサーバーから﹁.torrent﹂を取得して、その情報を元にクライアントが﹁トラッカー﹂に接続する。そして、﹁トラッカー﹂の指示に従って企業側のデータセンターにある﹁シーダー﹂か、他の﹁ピア﹂が一時的に﹁シーダー﹂を勤めている場合はそちらに接続して、配信データを受け取る。このときの﹁ピア﹂は﹁リーチャー(吸い取る者)﹂と呼ぶ。
そして﹁リーチャー﹂がデータを全て受け取ったら、今度はそれが新たな﹁シーダー﹂となって、他の﹁リーチャー﹂からの接続を受け付け、データを配信する側にまわることになる。こうした仕組みが大量のユーザー間で行なわれることによって、それぞれのユーザーに必要なデータが行き渡るわけだ。また、このネットワークは指定されたデータを対象にクローズドであり、﹁トラッカー﹂側で全てのトラフィックが監視できるので、セキュリティ面のコントロールも可能だ。
佐藤氏は、BitTorrentクライアントとしてMITライセンスで公開されている﹁Transmission 0.72﹂を選び、プレイステーション3向けに移植した。ちなみにプレイステーション3での実装では、ソケット仕様の制限やメモリの制約のため、同時最大接続数は16に制限されている。
BitTorrentでは配信するデータを細かなブロックに分割し、その中からランダムに選んだブロックをリクエストしてデータ全体を次第に満たすという方法をとっており、これにより1つの﹁リーチャー﹂が多数の﹁シーダー﹂に接続して必要な帯域を確保する仕組みになっている。佐藤氏はプレイステーション3の実装における接続数の制限により多少の問題が発生したとしており、今後改善したい課題として挙げていた。
そしてコナミでは、この仕組みを実際に﹁MGO﹂のサービスに投入した。さて、次の章ではそこで何が起きたのか見てみよう。
 |  |  |
| 佐藤氏はBitTorrentの実装のひとつを選択し、プレイステーション 3に移植した。データセンターに用意するサーバーマシンは提供地域ごとにバックアップを含めて4台づつとなり、かなり小規模な設備で事足りている | ||
■ 「MGO」でBitTorrentによるデータ配信を実戦投入! その結果は?
 |
| 「MGO」でアップデートが配信された際、ユーザーが通信方法を選択する画面 |
 |
| パッチはバージョン毎に細かく差分をつくり、サイズができるだけ小さくなるよう工夫されている |
﹁MGO﹂ではアップデートの配信が始まると、ゲームの起動時に通知を行ない、アップデートが完了しなければゲームをプレイできない仕様になっている。ここでユーザーは﹁ピアツーピアーでダウンロード(推奨)﹂もしくは﹁httpでダウンロード﹂するかを選択できる。ここでP2Pを選択するとBitTorrentプロトコルでのダウンロードが始まり、ダウンロード後、パッチの適用が完了するまでの間、そのユーザーは﹁シーダー﹂となる仕組みだ。
P2PだけでなくHTTPによる配信も選択肢に入れた理由は、佐藤氏によると﹁ISPの帯域防御対策﹂であるそうだ。アップロード帯域を大量に使用すると帯域を制限し始めるISPや、もっと厳しいところではP2Pプロトコルを検知すると即座に絞り始めるというISPが存在するようで、そういったISPを利用するユーザーのためにもオーソドックスなダウンロード手段は必須だったという。
とはいえ、﹁MGO﹂ではおよそ半数のユーザーがアップデートのダウンロードのためにP2P方式を利用した。それによってどの程度、コナミ側のサーバー負荷が軽減されたかが注目ポイントとなってくる。これについて佐藤氏は、﹁大人の事情で具体的な数字は明かせません﹂としつつも、かなり具体性のあるデータを提示して運用状況を説明してくれた。
運用状況の調査対象となったのは2008年11月25日から配信された﹁MGO﹂の1.1xから1.20へのパッチで、サイズは470MB。基本的にゲームをプレイする全てのユーザーがダウンロードすることになるので、総転送量は470MB×数万～数十万という単位になる。
ダウンロード数のグラフを見ると、通例どおり公開初日にほとんどのアクセスが集中し、その後は少しづつ配信が進むという形だ。このとき、データを最初にダウンロードしはじめたユーザー、または他に﹁シーダー﹂が存在しないときにダウンロードするユーザーは、コナミ側が用意したデータセンター上の﹁シーダー﹂からデータをダウンロードすることになるが、同時に利用するユーザーが多ければ多いほどユーザー側の﹁シーダー﹂が増えるので、ピーク時でもコナミ側の帯域がパンクしてしまうことはない。
ちなみにピーク時の総転送速度は4.5Gbpsにも達したという。これはコナミ側の﹁シーダー﹂と、ユーザー側の﹁シーダー﹂が転送した速度の累計だ。もしこれをWEBサーバーのみ、あるいはCDNのみで確保した場合、相当大きなコストがかかる上、いずれにしても帯域がパンクしてなかなかダウンロードできないユーザーが多く出てしまったことは想像に難くない。
では、﹁リーチャー﹂側の速度はどうだったのだろうか。つまりユーザーが快適にデータをダウンロードできたかどうか、ということだが、この点もおおむね満足いく結果が得られているようだ。﹁リーチャー﹂がデータを受け取る速度にはかなりの波が存在しているが、平均としては1.3Mbpsと、なかなかの高速を達成している。
 |  |  |
| パッチデータのダウンロードが完了した時点で「シーダー」になり、他の「リーチャー」に対して接続の受付け、データの送信を行なう。パッチのインストールが終了した時点で「シーダー」を完了する仕組みなので、それほど長い時間送信を続けるわけではないようだ | ||
 |  |  |
| 「MGO」におけるパッチ配信の統計データ。ピーク時の転送量は全体としてものすごいビットレートとなっているが、BitTorrentの仕組みで全体に負荷が分散されることにより、コナミ側がデータセンターに設置したオリジナルの「シーダー」による転送量は緩やかな伸びになっている。その「オフロード率」はパッチの公開期間全体を通して83%を達成 | ||
■ 80%以上のオフロード率を達成。
配信コストの大幅な削減が期待できるが、改善の余地も
 |
| βテスト時におけるプロトコルの選択割合は、P2PとHTTPでおよそ半々 |
 |
| ユーザー側のダウンロード平均速度は1.3Mbpsに達した。なかなか快適な速度だが、佐藤氏は「もっと速度が出せれば」と語っていた |
こうして結果的には、佐藤氏の狙い通り、WEBサーバーやCDNを通じて転送する方法に対して、サーバー側の負荷をかなり軽減することに成功したという。この軽減率を﹁オフロード率﹂というが、日本の場合のオフロード率は83%に達した。北米の場合は69%、欧州では73％と、ややオフロード率が低くなっているが、北米・欧州でADSLが主流であるため、各﹁シーダー﹂のアップロード帯域が十分に確保できていない、と佐藤氏は説明している。
日本と海外で差はあったものの、佐藤氏はP2Pでのデータ配信に相当大きな手ごたえを感じたようだ。従来の手法に対して少なくとも70%以上のオフロード率が見込め、特に公開初日付近のピーク時には99%以上もオフロードされているので、サーバー側の負担は非常に少なくなる。しかも、ユーザーからダウンロードに関するトラブルの問い合わせなどはほとんどなかったとのことで、コンシューマー機のタイトルが提供すべきクオリティを最低限満たしたと感じているようだ。
だが課題もある。前節で述べたように、佐藤氏はプレイステーション3版のBitTorrent実装において、接続数が16に限られている制限を指摘し、それが北米、欧州における低速なダウンロードという結果を引き起こしたと分析。これを改善するためには﹁より速いシーダーに優先的に接続する﹂、﹁ネットワーク的な距離を考慮する﹂あるいは﹁ISP内での接続を積極的に行なうP4P﹂の採用を見当する、といったいくつかの改善案を提出している。
また、﹁NAT越えが困難﹂であるために、接続数が上がらないという問題点も佐藤氏の懸念事項だ。これについて佐藤氏は通信にTCPを使うのではなく、UDPに変更することで解決が可能ではないか、という提案をしている。また、UDPでは事実上接続数の制限がないため、速度向上にも寄与できる可能性がありそうだ。
大量のデータ配信コストを大きく削減でき、ユーザーにも快適な環境を提供する可能性を持つP2Pプロトコルの活用。コナミの勇気ある取り組みはうまく実を結んだようにも見える。しかし、速度面以外にもセキュリティ面など今後配慮すべき問題はまだまだありそうだ。この技術が今後どのように発展していくか、ネットワークを扱うゲーム技術者にとっては興味深いトピックである。
 |  |  |
 |  |  |
| 日本では理想に近い効果を発揮したP2Pによるデータ配信だが、やはりユーザー側にそれなりの回線速度が求められるため、ADSLが中心の北米、欧州ではあまり速度が出ないという問題に直面している。佐藤氏はいくつかの改善策を提案していたが、インフラの整備が進むことで自然と解消されてくる部分も大きくなりそうだ | ||
□コンピュータエンターテインメント協会(CESA)のホームページ
http://www.cesa.or.jp/
□「CEDEC 2009」のホームページ
http://cedec.cesa.or.jp/
http://www.cesa.or.jp/
□「CEDEC 2009」のホームページ
http://cedec.cesa.or.jp/
（2009年 9月 4日）