モンストの大まかな構成と「STUN/TURN」
神谷元太氏：それでは「モンスターストライクのリアルタイム通信を支える技術」というタイトルで発表させていただきます。よろしくお願いします。
(会場拍手）
まず最初に軽く自己紹介をさせていただきたいと思います。2018年に株式会社ミクシィに新卒入社をしました。開発本部CTO室SREグループの神谷と言います。よろしくお願いします。業務内容としては主にモンストの開発や運用などを担当しています。
この発表ではモンストの大まかな構成について触れたあとに、主にモンストがマルチプレイで使っている「STUN/TURN」という技術について紹介していきたいと思います。
まず最初に前提として、モンストのマルチプレイについて軽く触れていきたいと思います。モンストは最大4人で協力してクエストを攻略していくゲームですけど、1つ重要な要素として「アクションゲームである」という点があります。そのため各プレイヤーの行動が他のプレイヤーにリアルタイムに伝わっていく必要があります。
また、ホスト・ゲストという概念が存在して、ホストが部屋を作ってゲストがその中に入っていくというようなイベントになっている点だけ覚えておいてください。
次にモンストの大まかな構成について説明します。こんな感じでモンストにはいろんなサーバがあるんですけど、今回は（スライド左側を指して）この辺だけの説明をします。
このうち、guestと書いてあるのが、いわゆるアプリ側、クライアント側です。クライアントはappサーバとTURNサーバと呼ばれている2種類のサーバと接続します。
このappと呼ばれているものは、普通のHTTPサーバで、これはクエストの外で使われます。そしてもう1つがTURNというサーバで、これはクエスト内でホストとゲストがクエストの状況を同期するのに使われています。
「TURN」とは何か？
次に「このTURNとはなんぞや？」という話をしていきたいと思います。
その前に「なぜSTUN/TURNというものが必要なのか？」という話なんですけど、理想的なマルチプレイの状況としては例えばホストがサーバになったりしてゲストがホストに通信できて、そのままやりとりができたらすごいうれしいですよね。
ただ現実はうまくいかなくて、基本的にホストもゲストもNATの奥側にいるので、ゲストがホストに直接通信をするのは基本的には無理になっています。
それを解決するための技術が、STUNやTURNとか言われているやつですね。まずはその1つ目のSTUNについて説明します。これはRFC5389で定義されているプロトコルで、これはすごい単純なものでクライアントがサーバにSTUNのリクエストを送ったときに、STUNサーバのほうがクライアントのインターネット側から見えるIPアドレスをそのまま返すだけというすごくシンプルなプロトコルになっています。
基本的にSTUNを単体で使うことはなくて、他のSTUNの拡張がこれから出てくるんですけど、そのいろいろな拡張と組み合わせてホストとゲストの通信を実現していくかたちになっていきます。
次にTURNの説明をしていきたいと思います。TURNはRFC5766で定義されているSTUNの拡張です。これはクライアントとサーバ以外にピアと呼ばれるものが出てきます。「ピアとは何か？」というと、TURNサーバを経由してクライアントと通信をしたい人のことです。
TURNサーバはSTUNの持つ機能の他に、クライアントとサーバが通信する以外にももう1個ポートを開けてそこにピアが接続することによって、ピアとクライアントがあたかも直接通信を行っているかのようにデータのやりとりを中継することができます。
さらにTURNでTCPを使うための拡張としてRFC6062で定義されているものがあります。こちらはちょっとやり方が変わって、クライアントとTURNのコネクションが2種類に増えます。片方がコントロールコネクションと呼ばれているもので、これを使ってクライアントはTURNに「このピアと接続したい」というような命令を送ったりします。もう片方がデータコネクションと言われるコネクションで、これを使ってクライアントとピアは疑似的に1対1の通信を行うことができます。
モンストではこの方法を使ってホストとゲストの間でTCP通信を行っています。
モンストでどのようにTURNを使っているか
次に「モンストでどのようにTURNを使っているか？」という話をしていきます。まず最初にサーバ構成のおさらいです。
このようにappとTURNの2つのサーバが出てきて、モンストの場合はホストがTURNのクライアント、ゲストがTURNのピアという扱いになっています。
まず最初にクライアント側。ホストやゲストがどのようにしてTURNサーバを見つけているかの話をしていきたいと思います。まず、ホストは普通のHTTPサーバであるappサーバに対してTURNの所在を問い合わせます。
するとappサーバはappの知っているTURNサーバのIPアドレスとポートの組み合わせの中からランダムに数個をホストに返します。これによってTURNサーバのロードバランシングも兼ねています。
また、TURNのRFCだったりそれ以外とかで、TURNのディスカバリーの方法はいくつか定義されているんですけど、モンストではそういうのは使っておらず、このような方法を取っております。またTURNには「ALTERNATE-SERVER」という「今は自分のTURNサーバは手いっぱいだから他のTURNサーバを見てね」という機能があるんですけど、これもモンストでは使っていません。
次にホスト側につないでからホストとゲストのコネクションが確立されるまでの流れについて説明していきます。ホストは先ほどの手順でTURNサーバのIPアドレスとポートを取得し、TURNサーバに接続をします。そしてTURNサーバのAllocationが取れると、TURNサーバはゲストがつなぐ用のポートを開いてその情報をホストに返します。
するとホストはそれをappサーバに登録します。このようにしてホストとゲストがTURNサーバにつなげために必要な情報をappサーバを介してやりとりします。
最終的にこのようにゲストとホストがTURNサーバを返して接続ができたらクエストが開始されます。
次に、IPv6の対応について説明していきたいと思います。やっぱり今のこのアプリケーションとなるとIPv6に対応していないといけないですし、対応ていないアプリは審査に通らないというようなこともあるので、こうなると重要な話になってきます。
モンストの場合、何が一番大変かと言うと、普通のTURNはIPv4しか対応をしていないんですね。TURNのIPv6に対応できるようなRFCの拡張もあるんですけど、モンストではそれを使わずに次のような方法を取っています。今回はその流れについて説明します。
ホストがIPv6に対応している場合でも、まず最初にTURNのIPアドレスをappサーバから取得するところまではIPv4と同じ流れになっています。このとき返されるIPアドレスもIPv4のものになっています。その後ホストはあらかじめ決められた手順でIPサーバから一意に生成できるドメインを生成します。
これでポイントになっているのは、モンストのTURNサーバはすべて自身のグローバルIPアドレスと、それに対応した一意に生成できるドメインを持っています。
ドメインを生成するとクライアント側はそのドメインに対するAAAAレコードをDNS64サーバに問い合わせます。そして疑似的なTURNのIPv6のアドレスを取得します。
そして、ホストはそのIPv6アドレスがTURNのアドレスと思い込んだまま、TURNと普通に通信をします。しかし、間にNAT64のゲートウェイが挟まっているので、こいつがIPv4に変換をして無事にTURNとつながるというかたちになっています。
クエスト内外で仕組みが大きく異る
まとめを話していきたいと思います。モンストではクエスト内とクエスト外で仕組みがそれぞれ大きく違って、つなぐサーバも違う設計になっています。また、ホストとゲストの間ではTURNというプロトコルを使って、TURNサーバ経由で通信を行っています。そしてIPv6の対応は、TURNのIPv6用の拡張を使うのではなく、DNS64とNAT64を使っています。
モンストは本家のアプリ以外にも「モンスターストライクスタジアム」という対戦用のアプリがあるんですけど、こちらはホストとゲストの通信以外にも各チームごとにクエストの進行状況をやりとりするためのTURNが存在して、このようにチーム1のホストとゲストとチーム2のホストとゲストの間のTURNの他に各チームのホスト同士のTURNの接続も出てきます。
もう1つ、モンストスタジアムを使ったモンストのeスポーツ大会がありまして、これはその先ほどの対戦を会場で行ってそれがリアルタイムで中継されるかたちになっています。その中継の映像を再生する用の観戦端末もこのように各チームのホストとTURNで接続して、それぞれクエストの進行状況をやりとりしている流れになっています。
それでは時間がきましたので、発表は以上にしたいと思います。ご清聴ありがとうございました。
(会場拍手）
