世界規模のネット対戦を支えるマッチング技術　快適なゲーム体験を生み出すために考えるべきこと

Google Cloud Platformを世界で使う

長谷川祐介氏（以下、長谷川）：先ほどご紹介にあずかりました株式会社grasysの長谷川です。

会社の紹介を簡単にしながら「グローバルでゲームをどう構成しているのか？」というところをちょっとご説明します。グローバルでゲームをやるのはとても大変なので、そのあたりも技術的に共有できたらうれしいなと思います。

少し濃い話ができたらうれしいなと思っています。よろしくお願いします。ところでみなさんは、ゲームを実際に作っていらっしゃって、実際にプログラマさんだったりします？

（会場挙手）

簡単に会社紹介をさせてください。株式会社grasysの創業は4年前です。ちょうど来月が期末なので、再来月で5期目になる、まだまだ小さな会社です。

Google Cloudのパートナーをしていまして、HashiCorpのパートナーもしております。Google Cloudは、実は弊社はPremier Partnerになっており、Google Cloud PlatformのCloudサービスの代理店をしております。

HashiCorpさんは、System Integrator PartnerとReseller Partnerをしております。

後ほど紹介しますが、弊社はHashiCorpのツールをたくさん使っていまして、かなりHashiCorpラブなので、HashiCorpさんとはとても仲良くやらせてもらっています。

自己紹介ですが、僕は長谷川と申します。いろいろな会社を転々としているのですが、主にずっとインフラの仕事をしています。僕自身エンジニアで、最近はあんまり触れないのですが、個人的にもっとエンジニアをしたいなと思っています。

grasysの概要

弊社はどのような会社かというとITインフラの専門の会社です。「Google Cloud Platform専門でしょ？」みたいなお話もあるのでちょっと大きな声では言えませんが、「9割ぐらいがGoogleで、残りは実はAWSをやっていたり、オンプレもあったりします。主にGoogle Cloud Platformを使ってオープンソースで設計・構築・運用をしている会社です。

例えば、サービスに対するアクセスが増えることによる急激なスパイク、データが大きくなりすぎて処理に時間がかかる問題といった少し難しい仕事をたくさんいただいていて、その分エンジニアリングして楽しんでいます。

どういうシステムを手がけているかというと、ゲームだと、コンソールもモバイルもアーケードも関わらせていただいています。また、Webシステムや、Eコマースといったサービスも関わらせていただいています。

「Data Analytics」と書いてありますが、大規模分析基盤ですね。GoogleにはBigQueryがあり、非常に大規模な分析基盤を構築するのもローコストで容易にできるノウハウをもっています。

比較的、新規事業のお仕事もいただきやすい環境にいます。（例えば）VRやスマートスピーカー、動画配信系ですね。Video Castなどもやらせていただいています。

grasysの技術スタック

HashiCorpさんが大好きなので、Terraform、Serf、Consulをたくさん使っています。

オーケストレーションや監視ツールや通知系は自社でオリジナルで組んでいます。InfluxDBはmetricsデータを入れる時系列データベースとして使わせていただいています。

一番下にあるrerunは、Bash のコマンドラインフレームワークです。コマンドラインのスニペットみたいな使い方をしています。コマンド、オペレーションなどでいちいち長いものを覚えられないため、それを自動化するために使っています。

またCore Architectureとしてここにはありませんが、KubernetesやDockerも利用しています。GCPで利用しているのでGoogle Container Engine(GKE)です。

オープンソース系はどういうもの使っているのかというと、こんな感じですね。

ここで訂正しなければいけないのですが、弊社は以前EmbulkやFluentdを、たくさん使っていたのですが、最近のプロジェクトでは使っていません。最近はLogstashとElastic Beatsをメインで使っています。

外部ツールについては、うちはまだ創業して4年の小さい会社なので、クラウドサービスをたくさん使っています。

監視業務もしているので、PagerDutyなども使っていますし、いろいろ使わせていただいています。インフラの会社ですが、実は開発・検証用途を除き社内向けにサーバを一つも持っていません。

サンプルのアーキテクチャなのですが、うちがよくやる大規模分析基盤です。

小さいところだとデイリーで20億レコード増えていくぐらいです。後ほど出ますが、一番大きいところだとデイリーで数百億レコードという単位で増えていくような環境もあったりします。

（スライドの）先程も言いましたが真ん中にFluentdとEmbulkと書いてありますが、最近はBeatsとLogstashばかり使っています。経験上、長期の運用をすると不具合が発生することがあり、いわゆるFluentdのプラグインのアップデートの追随などがすごく大変なので、Elasticに切り替えたのが最近です。

もう1つの切り替えた理由としては、ほとんどのサービスにおけるログ収集はファイルシステムベースなので、ファイルロギングに特化したFilebeat + (Logstash) + Elasticsearchという構成にしました。FilebeatはGolangで実装されており、インストールが簡単、軽量、安定した動作を実現します。

手がけているサービス

ゲーム以外で運用しているサービスとしてパズルCAPTCHAがあります。こちらにいらっしゃる方もパズルを合わせて認証するといったものを見られたこともあるかもしれないですが、そのサービスです。サーバも約400インスタンスぐらいあると思いますが、大きなサービスです。実はかなり古くからの弊社のお客さんで、創業期からご一緒させてもらっています。

うちの規模感は、今、社員数15人で、エンジニアが11人です。僕もエンジニアとしてカウントさせてください。寂しいので……。変動もあったりしますがGoogle Cloud Platformのプロジェクト数は、だいたいアクティブで130プロジェクトぐらいです。VMが2,000VMぐらいあります。

Request Per Seconds……全体で200万Request Per Secondsぐらいだと想定されています。

BigQueryは一番大きいものでデイリー800億レコード増ぐらいです。

近年のゲーム業界における5つの当たり前

そろそろ本題です。みなさんゲームを作られているので、たぶんゲームが好きだと思いますし、ゲーム業界やゲームに近い環境で働かれているんだろうなと思います。

僕は40歳、昭和53年生まれです。ファミコン全盛期だったんですよね。ファミコン、スーファミとステップアップしていって。少年時代はずっとゲームをやっていました。今は大人になって子どももできたので、最近は子どもにPlayStationを買い与えたり、Switchを買い与えたり英才教育（笑）しています。

なんというか、子どもにはあんまりぬるいゲームをやらせたくないと思っていて、洋ゲーばかり買っています。『Dying Light』や『Horizon Zero Dawn』といった難しいゲームばかりやらせています。『No Man's Sky』も触らせました。最近は『Fortnite』ばかりやっています。もちろん自分が関わったゲームも触らせていて、今では優秀なテスターになりました（笑）。

少しシステム的なお話をします。最近のゲーム業界の動向で、「5個の当たり前」というのが僕の中にあります。

コンソール、アーケード、モバイルが、全部オンラインになってきています。もうここは当然ですね。

あと、我々が取り扱っているタイトルなどでIPが乗っていたりするものもよくあるので、Global Launchが当たり前になってきています。これはもうコンソールとモバイルですね。

コンソールだと比較的パソコンゲーム業界から流れてくるオンラインゲーム・リアルタイム通信系のゲームの技術が導入されやすいのですが、最近ではモバイルでも、オンライン、しかもリアルタイム通信が徐々に浸透してきている感じがします。

Multi Platformも当たり前ですね。例えば、我々が関わっているタイトルでも、タイトル名は言えませんが、PlayStationやXbox、Steam、Switchなど複数のプラットフォームでシステム的な分断はあるものの発売されるといったことが当たり前に行われています。

また、最近すごいのが、Multi HardwareでMulti Deviceみたいなところです。『Fortnite』などはまさにそうだと思いますが、コンソールからモバイルの携帯ゲーム、スマホまでというかたちでいろんなデバイスに対応し繋がっています。もうプラットフォームの垣根を超えつつあって、すごい世界になってきたなと思っています。

ゲームサーバに求められる役割

よくあるゲームサーバなのですが、たぶんみなさんもいろいろゲームをやられていて、そのゲームの向こう側で動いているサーバの種別ですね。

APIなどはもうごく当たり前ですね。認証やランキングといった、ゲームの本編以外の部分で使われたりします。

あとはMatching。これは後ほどお話します。いわゆるユーザーマッチング。名前のとおりなのですが、グローバルでゲームをやるとなると、例えばアメリカの人とヨーロッパの人を戦わせるのにマッチングシステムが必要になります。

そういうものを独自で開発されるパターンがあったり、プラットフォームのマッチング利用したりするパターンがあります。

ただ、うちはけっこうシビアなゲームが多いです。実は「格闘ゲーム」などが多く、プラットフォームの機能だとマッチングが要求に応えられません。そこで、シビアな要件に応えるためにマッチングのサーバを作るという案件がうちには多かったりします。ですので、あえて独立して（スライドに）書いています。

位置情報管理サーバですが会社さんによって呼び方がけっこう違います。

あとは、下でGameやBattleと書いていますが、リアルタイムサーバですね。いわゆる専用サーバモデルで、クライアントとクライアントをつなげるための通信をするためのサーバだったり……会社によっていろんな呼び方があり、GameやBattle、Realtimeなどと呼んだりしています。

最近は、いわゆるモバイルでもP2P接続などがけっこう当たり前に出てきているので、TURN/STAN、いわゆるNAT越えですね。キャリアによってはP2Pができなかったりするので、サーバを中継するみたいな話になるのですが、そういうサーバもあったりします。

だいたいこれぐらいでしょうか。僕が知っている範囲で、いろんなタイトルをやらせてもらっていますが、特殊なサーバはだいたいこれくらいです。データベース……例えばランキング情報などを溜めるなどになれば、また別のデータベースを使ったり、Redisを使ったりという感じになるので、特殊なサーバというとこんな感じかなと思っています。

たぶんPhotonなど、リアルタイムのサーバエンジンみたいなものを聞いたことはあると思いますがそういう製品版を使うパターンもありますし、ある企業様がオリジナルで組んだサーバエンジンみたいなものもよく使っています。

リアルタイムなオンラインゲームにおける通信

よくあるリアルタイムモデルなのですが、Broadcast型というと、たぶんみなさん容易に想像がつくかと思うのですが、Photonなどはわかりやすくいうとこの形です。チャットみたいなものを想像していただけるとわかりやすいとは思います。もちろん位置情報管理を行ったりするのでもう少し複雑なことをしています。

上記とは別でStreamBufferのような動作をしているタイプのサーバモデルで開発されている企業様もいます。

通信プロトコルですが、各種API系はHTTPSが多い感じでしょうか。Realtime系通信はUDPだったりUDPの拡張だったり時折TCPだったりとゲームタイトルや開発される企業様で変わります。

大規模サービスにおけるインフラの裏側

ゲームのモデルにもよると思いますが、Dedicated （Server） Modelがこれから主流になるだろうなという個人的な肌感を持っています。わかりませんけど……。

本音を言いますと、UDP/RUDP/TCPのオリジナルサーバが多くて、Connection StateのHandlingがいろいろ大変です。運用していくところでけっこう苦労しています。

あまり大きな声では言えないですが、HTTPのサービスは簡単だなと個人的には思っています。運用がかなり楽です。どんなに大規模なものが来ても比較的簡単です。しかし大規模でリアルタイムのものはすごく大変です。

いわゆるオンプレでも、クラウドでもいいのですが、「コンピューティングリソースって何？」みたいなところです。「実際にインフラ作ろうぜ」みたいな話になったら気になるところは、今ここに書いてあるぐらいかなと思います。

CPUは、どこのクラウドを使ってもIntelです。よって、あまり変わりません。あとはメモリですが、これも単純に必要なだけ選択してというかたちです。お金がかかるだけです。

ストレージもSSDなどを選択できるようになってきていますが、これも単純に選べばいいと考えています。昔の話ではありますがPCIe/NVMe SSDなど、特殊なスロットに挿すSSDは爆速ですが、そういった極限の性能は、必要になる局面が少ないと感じています。これも適切に選べばいいかなと思っています。お金がかかるだけです。

グローバルなサービスにおけるネットワーク

先ほど「グローバルで通信するゲームを作るのは大変だよ」といったお話をしましたが、ネットワークだけは、どうにもならないなと感じています。これはオンプレも散々やってきましたし、AWSも触っていますし、GCPも散々触っています。これが僕の感想です。

みなさんスマートフォンを使っていると思うのですが、どこどこのキャリアだと速い、遅い、繋がる、繋がらないといろいろ意見があると思うのですが、こういう当たり前の話が、世界中には散らばっています。

グローバルで、たくさんのお仕事をさせていただいていて感じることは、瞬間的かつ爆発的な形で凄まじいネットワークの要求が発生し、インフラ面で厳しい状況に置かれたりします。

処理時間がかかるのであればうまいこと並列化すればいいですし、メモリが足りなかったり、IOが足りないとなったら、それも並列化すればいいのですが、通信だけはどうにもならないというのが正直なところです。

ネットワークで気にするべき点

Internal Throughput……いわゆるCloudの中のThroughputです。あとは、Cloudから出たときのThroughput。また、それぞれレイテンシも含む。あとLast 1 Mile……ユーザーに届く直前の環境のお話ですね。

当たり前ですが通信帯域は大きいほうがいいです。大きいほうが短い時間でたくさんのデータを送れるからです。潜在的なクラウドの性能を知るためにすごく良い基準かなと思っています。

往復遅延時間は通信の応答にかかる時間です。通信には応答時間があります。その反応は距離が重要だったりします。実際、今の通信技術は光の速度を超えられないため、そういう意味ではとても距離の影響を受けます。

Googleのネットワーク回線の品質

Google Cloud Platformのネットワークなのですが、Googleは検索の会社の印象がありますよね。検索、YouTubeという印象があると思いますが僕は少し違うと思っていて、Googleはネットワーク回線の会社なんじゃないかと思い始めてます。

独自の回線で品質は非常に安定していて、バタつきも非常に少ないです。機械なので、たまには不安定なこともありますが、単純なネットワーク比較でも、高性能だったりします。

ゲームのRealtime通信において重要なのはレイテンシです。通信の帯域はユーザを１台のVMでどれだけ支えられるかに影響を与えますが、やはり最後に大きな話題になるのはレイテンシであることが非常に多いです。

結論としてはスループットとレイテンシは良いクラウドを使えば手に入ります。

ですが、最後のLast 1 Mileが手に入りません。「クラウドから各端末までどれぐらい？」みたいな情報は手に入らないので、我々は、そこをとても気にしています。

Googleのサービスが高速で利用できる理由

世界中で「Last 1 Mile、なんでGoogleが速いの？」みたいな話があるのですが、実際速いんです。YouTubeを見ていても、あまり再生を待たないですよね。凄まじいです。

みなさんはたぶん、3秒ルール、5秒ルール、8秒ルールなどを聞いたことがあると思います。Googleは、ユーザーにコンテンツを極力速く返すということに命を懸けていたりします。そしてそのバックボーンがそのままGoogle Cloud Platformのネットワークで使われています。よって、速くて当然、みたいな話ですね。

Googleのインターナルネットワークはかなり品質がよく、グローバルを通すよりも速かったりします。やり方にもよると思いますが、実際にベンチマークするとそういうスコアが出たりするので、やってみていただけるとおもしろいかなと思います。下手にアメリカに向かって直結するよりは、Google Cloud Platformのインターナルを使ったほうが速いです。

上記のようにネットワークが優秀なのでグローバルに分散した仕組みも作りやすいです。

グローバルマッチングにおける悩み

クライアントとサーバの通信品質はいったん解決として……我々のレベルではどうにもならないので、次の問題なのですが、「グローバルマッチングの悩み」ということで、我々もすごく悩んでいます。

GlobalでRealtime Gameをする悩みなのですが、「マッチングはどうする？」という課題があります。

ゲームのモデルによって、通信の遅延を待てるゲームと待てないゲームがあります。例えば瞬発力が必要なゲームは待てません。マッチングにレイテンシはとても大切な要素です。距離のあるユーザ同士を繋げても良いのかという悩みが毎回発生します。

次に重要なのはデータサイズです。できるだけ小さなデータで通信できるよう配慮する必要があります。

マッチングにおける課題でよくある対策例が、マッチングさせるクライアントの無難な距離を測るために、GeoLocationで判別しようという話です。

また、クライアント側の通信品質を調べるためのマッチングにおいて、例えば数人対戦で全員集まったら、マッチング中にフルメッシュで全クライアントに対し応答を確認します。その品質を調べて、水準以下というのはよくあります。

グローバルマッチングの難しさを感じる実例

実際にあった例です。本当にグローバルでいろんなゲームインフラの運用をしているのですが、4人対戦でいったんマッチングルームに入れPINGの応答速度を見る形のマッチングにおいて、おもしろいことに、毎回マッチングが失敗するケースがありました。

調査したところ、4ユーザ中、1ユーザの通信品質が悪く、そのユーザが熱心にマッチング参加要求を投げることでいつまでもマッチングが成立しないといった内容でした。東京であればIXがあって、なんとなく回線状況を知っていたりしますが、世界になるとわかりません。そういうことが見えてきておもしろいんです。

我々はインフラなので、目的としてはやはりゲームのリリース時の品質を上げていきたいという思いがあります。また個人的にもゲームが好きなので、よくしたいという思いがあります。

通信品質をスコア化しゲームの品質向上に役立てていけたらと考えています。

以上です。ありがとうございます。

（会場拍手）

モバイル回線のユーザーをどうするか？

司会者：ありがとうございました。このあとにミートアップの時間も用意していますが、せっかくですので、もしご質問等があればこの場で1つか2つ、受けていければと思います。ご質問等のある方はいらっしゃいますでしょうか？　お願いします。

質問者1：今日はありがとうございました。品質の問題ではあるのですが、なるべく回線品質がいい人自体をつなげていこうという話だと思うのですが、そもそも「どうやっても悪いじゃん、こいつ」みたいな人がいた場合、悪いなりの「ラグい人たち」を集めるようなマッチング方法みたいなものも検討したりするのでしょうか？

長谷川：ゲームモデルによりますね。あるゲームでは、ずっとマッチングが不成立のまま時間が過ぎちゃったりということもあります。また、たぶんみなさんは実際にゲームをやられていて気づくと思うのですが、待てるのは40秒ぐらいなんですよね。40秒でフルメッシュで通信するとなると、だいたい1回あたり6〜8秒ぐらいかかるので、試行できる回数が4回ぐらいしかないんですよね。すると、諦めさせちゃいます。

通信の品質が高い人たちだけを乗せるようなかたちも、あまり通信要件が高くなければいいと思います。ただ、ある国ではユーザーが少ないといったこともあり、グローバルだとなかなか難しいですね。ユーザーが少ないとまた難しくなりますし、（一方で）ある国はかなり密度が高いしといったように、「どうする、これ？」みたいになると思います。

質問者1：ありがとうございます。

スマートフォンでのマッチングの問題

長谷川：マルチ対戦でホストになるユーザーがいたりします。例えば何人かがいて、パーッと通信をしてゲームモデルが成立していくような……。今の業界はこの流れだったりするのですが、やはり品質を整えるのがけっこう難しいです。

その観点だと、Dedicated （Server Model）……「サーバに寄せちゃおう」みたいな選択をすることが多くなっています。Switchぐらい性能があればいいのですが、スマートフォンも視野に入れると、やはりサーバに接続させたほうがいいんですよね。

その観点では、多人数対戦のゲームは作れません。でも、Dedicated （Server） Model……要はサーバに全員が接続するモデルでやれば、大人数で、マルチプラットフォームかつマルチデバイスでできそうです。

逆にホストユーザーがいて、つながってくるゲームモデルだと、ホスト有利問題と、逆にホスト不利問題もあって、そういう話はすごくおもしろいです（笑）。

質問者1：ホスト電池なくなる問題。

長谷川：そうですね。ホスト電池なくなる問題、ありますね（笑）。だから、おもしろいなと思います。

今、e-Sports（などのブームが）来ているので、公正に、公平に、フェアにゲームを成立させるとなったら、もうDedicated （Server Model）しかないと思います。

質問者2：民間サーバという考え方はないですか？　少し時代に逆行していますが。

長谷川：それもまた「あり」かもしれないですね。コンポーネントを提供して、ダウンロードして、パッと起動してくれれば、なにかサーバ1台でバーッと出てきて、そこにつなぐ。最近は『Minecraft』ぐらいしかないですよね。自前でサーバが作れるものは。

質問者1：そうですよね。

長谷川：うちの子どもに「『Minecraft』もサーバ作れるよ」といって、作ってあげたのですが、感動していました。e-Sportsなどを視野に入れると、やはり個人個人の有利・不利を極力排除してあげるのがいいんだろうなと思っています。

司会者：はい。ありがとうございました。