1. 最強のマルチプレイ・
ゲームサーバを構築
2016/07/07 Gaming Tech Night
グリー株式会社 開発本部 堀口真司
Docker と ECS と WebSocket で

2. はじめに
• 技術ブログに書いたのが元ネタです
 「 Docker ECS WebSocket 」でぐぐると元ネタページ出ます
 http://labs.gree.jp/blog/2016/06/16024/
• 今回だけの詳細版
 開発と構築と運用ぜんぶ。
• 自己紹介
 コンソール → ネトゲ → アーケード → ソシャゲ
 先週から33歳

3. 稀によくあるプロジェクト要件 (仮)
• リアルタイム・マルチプレイゲームの案件が浮上
 Photon エンジンとか Monobit エンジンとかもあるけど…
• ざっくり要件
 そんなガチゲーじゃないけど、 20 人ぐらいでプレイ
 マップギミックがある
 NPC もいる
 そもそも WebGL クライアントとか
• 技術選定にて
 WebSocket で十分だろう。となると、 nodejs になる
 ステートレスは難しいので、 RDB/KVS は使わない。オンメモリでやる
 モニタリング、デプロイはありもので何とかならないか

4. 一番最初に浮かんだ案
ロードバランサ
IP Masquerade
API サーバ群
WebSocket
Stateful なので
狙ったプロセスに
アクセスするため
DB を持たず
オンメモリで
すべて処理
WebSocket とそれ以外は
使い分ける。マッチング
等は API サーバでやる
永続的な状態は
一応 API 経由
で更新

5. WebSocket サーバ群
API サーバ群
WebSocket サーバ群に負担
ロードバランサ
IP Masquerade
問題なし
デプロイ
モニタリング
メモリリーク
NAT 更新
マルチコア対応
ゲームに関係
ない部分…

6. もんだいだらけの…
• メモリリーク
 ステートフルサーバの場合、状態を内部に持つのでどんどんオブジェクトが溜まっていく。完璧に
対応することもできなくはないが、それをやるコストがかかってしまう。一般的には定期的に再起
動させることで、ある程度のメモリリークを妥協し、効率よく開発する。
• NAT 更新（あるいは案内）
 LB 層での RR や WRR 等は利用できない。各サーバ、全ポート固定で割り振っても良かったが、安
定した内部システムに大量の NAT エントリを作るのはリスクが高かった。できればグローバル IP
直結にし、個別の Firewall が好ましい。いずれにせよ管理コストがふくらむ。
• デプロイ
 ディレクトリスイッチや Apache のリロードのように完璧に近いふるまいができない。 nodejs の
デーモン化ツールは普通のステートレス Web 向けのものがほとんど。となると自前でそれを考慮し
たつくりにしなければならない。
• モニタリング
 プロセスの監視や負荷の監視が要るが、 Apache ではないので何か回収するための仕組みを作らな
いといけない。既存のメトリクス回収システムとのプラグインを作らないといけない。
• マルチコア対応
 nodejs はシングルスレッド・イベントドリブンで安定高速動作するが、マルチコア OS に乗せると
そのサーバの性能を出し切れない。となると、 Prefork 系のアプローチを取ってマルチプロセスで
運用するなど、 NAT の仕組みと競合したり、オーケストレーション層を対応しないといけない。

7. 作るモノが多い問題
• なぜならこの課題に対する世間の需要がほとんどなく OSS が発展してないため。
 わずかなモノも、こちらの要件にマッチすることはほぼない
• たとえば Photon エンジンなら
 ロードバランシング → SPOF だけど、独自のものが用意されてる。
 モニタリング → Windows API で取れる
 マルチコア対応 → どうやら、マルチスレッドで動いてる
 デプロイ → 専用コンソールでボタンをポチポチするだけ
それなりの規模なら作る。
または、買うんだけど
どうしようかな～

8. nodejs プロセスと TCP Port を
完全にマップしたい
いつもの LAMP じゃだめ
なんか？
デプロイどうしよ
オーケストレーションも
コンテナどう？
デプロイツール幾つかあ
るし、中身は root でどん
なプロセスでも動くし、
TCP Port に直結できる
せや！ Amazon ECS にしたろ

9. コンテナとは
• VM より小さく、プロセスより大きい
 ホスト OS とは違うものが使える。 AmazonLinux 内に Ubuntu とか。
 ミドルウェア類も全部別のバイナリで動作する
 CPU はエミュレートされない。なので高速動作する
 GPU もエミュレートされない。そもそもハードウェア仮想化ではない
 コンテナ毎にリソースの上限が設定できるのもある
 IP アドレス(ネットワーク)はホストと共有される
 コンテナ内のファイルディスクリプタは独立するので、一見すると NAT っぽいふるまい
 コンテナ間で同じものは共有される
 ストレージは設定しないと書き込めない
 設定すればホスト側のボリュームも読み書きできる
 コンテナのエントリポイント（＝プロセス）が終了するとコンテナも消える
 コンテナ内は root ユーザで動作する
 “本物のオブジェクト指向”でいう、オブジェクトっぽい立ち位置。
• Google では、あらゆるアプリがコンテナ運用らしい。

10. ここから構築
と設定

11. じぶんの PC
ECS Host
Amazon
ECR
Amazon ECS
fetch
build
push
AWS
Lambda
API
Auto Scaling group
ECS Host
Post
room-status
deploy
Container-status
log
pull
社内ネット
Amazon API
Gateway

12. じぶんの PC
shinji.horiguchi@G-PC-00366540 MINGW64 ~
$ docker run -P -d websocket
75ff4f9b1eee9933d867b628f75dde046467ae7f426a67344ebe6806f407f6d3
shinji.horiguchi@G-PC-00366540 MINGW64 ~
$ docker run -P -d websocket
38bb67d2895d4d3ac03732ce0f5631780118737c70b79c652ba293bb862cf702
shinji.horiguchi@G-PC-00366540 MINGW64 ~
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS
NAMES
38bb67d2895d websocket "node /home/app/serve" 4 seconds ago Up 3 seconds
0.0.0.0:32769->3000/tcp nauseous_engelbart
75ff4f9b1eee websocket "node /home/app/serve" 37 seconds ago Up 36 seconds
0.0.0.0:32768->3000/tcp berserk_golick
Windows でも docker tools
入れるだけでオッケー。
開発環境のセットアップに
一時間もかからない
コンテナ操作や管理は
GUI なので、非エンジニア
でも安心の Kitematic

13. Amazon
ECR
fetch
build
push
docker が使える slave を
追加しておく。古いやつは
ECR 未対応でダメ。
Jenkins ジョブに必要なので作る。超簡単。
US 系リージョン。作った後に案内されるペー
ジの内容にログイン方法やアドレスが書いてあ
るので必ずメモっておく。
でもデフォの latest タグのままはダメ。
ADD app /var/app
WORKDIR /var/app
RUN npm install
RUN npm install -g bower
RUN bower install --allow-root
• WORKDIR – 使える
• ENV – 使える
• ENTRYPOINT – 使える
• EXPOSE – 使えない
• CMD – 使える
• 他 – わからん
Registory API v2
に対応したクライアントが必要
Dockerfile に全部書く。
docker build するまえに、
ゲーム本体も fetch してくる
Dockerfile は別リポジトリ。
どうせ冪等性ないのでビルド
後のハッシュやタグで管理
ECS 側で
設定必須

14. Amazon
ECR
Amazon ECS
ECS Host
deploy
pull
ECR で案内された URL をそのまま Task 定義に設定すれ
ばオッケー。 Docker Hub のも同じく使えるので、
cAdvisor はそのままデプロイ
cAdvisor はコンテナホスト単位でデプロイする。
Portmap でホスト側のポートを指定すると一台に
一つのコンテナしかデプロイされないので、この
仕組みを活用する。 Prometheus と組み合わせる
と間違いなく最強。時系列
データを行列のまま扱えて
関数と式でグラフを描ける
fluentd はホストで動作させ、
コンテナ内から
localhost:port に流す

15. ECS でのインスタンス概念
• Task Definition
 コンテナの URL や起動パラメータ、ヴォリュームやポート設定を行う
 コンテナタグをつけかえて、バージョンアップとかできる
• Service
 デプロイ設定。一部を変えると差分を埋めるようにトポロジが維持される
 どの Task definition を、どれだけ
• Cluster
 Service のデプロイ先で、 EC2 によるコンテナホストが複数含まれる
 複数の Service が一つの Cluster に同居できる
• Task
 稼働中のコンテナ。いわゆる docker ps コマンド

16. ECS Host
Amazon ECS
Auto Scaling group
ECS Host
deploy
Desired:10
Minimum healthy: 100%
Maximum: 120%
新デプロイを設定すると
Max まですぐに増加する
デプロイ時にローリングリスタートされる容
量＝Max-Min となり、この設定の場合 20%
分ずつコンテナが入れ替わっていく。
Min 設定を 100% 未満にするとデプロイ時に
いきなり殺されてしまうのでサービスの場合
は 100% 以外に選択肢は無い。
初期値の 50% では半数で障害となる
コンテナホストは AutoScaling と
Userdata のみで運用できる。
ssh すら不要で、 AMI も標準の
ECS Optimized で良い。

17. Cluster 画面 Task Definition で競合
が無ければ Desired
だけ Task が起動する
テスト用などはそもそも
一つしか起動させていない
ホスト内で競合する場合は、
一台に一つのコンテナしか
起動できない

18. Rolling 時

19. 類似サービス
• Kubernetes
 クゥーバーネイテス。
 Google 系
 ECS とだいたい同じ機能
• Nomad
 ノマド。
 Hashicorp 系
 だいたい同じ
• Docker 1.12
 だいたい同じ
 オーケストレーション強化

20. AWS
Lambda
API
Post
room-status
Container-status
いわゆる Tasks で取れるような情
報を管理 API に伝える
ホスト名＋ポート番号は必須
コンテナはブラックボック
ス化の原則に則って、
必要な情報は外から与える。
AWS 依存の情報や docker
依存の情報など。
それらの情報に加えて、コ
ンテナのみが保持している
状態を管理 API に伝える
コンテナへの案内やゲー
ムのマッチングを行う。
案内には NAT64/DNS64
対応のため FQDN で行う。
Amazon API
Gateway

21. 最強ポイントまとめ
４つのポイント

22. 書くものが少ない
• タスク一覧を取得し、管理 API に POST する
• コンテナ内に観測情報を set する
• 管理 API に WebSocket サーバの状態をいろいろ POST する
• Dockerfile 書く
• Jenkins ジョブ書く
• 監視やロギングの設定

23. 落ちない
• すべてが分散配置され、 SPOF が無い
 ホストは AZ バランス、コンテナは分散、 Lambda も分散、 API は ELB 配下で完璧
• Rolling または Blue-Green どちらでも対応できて、メンテ停止も不要
• Service 設定を一つ変えるだけで、ロールバックも超簡単
• テスト、一部公開も同じく容易
• モニタリングツールがたくさんある
 これがこの分野で意外と厄介である。

24. 依存が少ない
• 環境依存が少なく、コンテナを手元の PC で建てることもできる
 チョイ確認したいときとか
• nodejs なら、そのまま Windows/Mac で建てても良い
 gulp 等と相性が良く、開発しやすい
• WebSocket で SSL 対応もできる
 将来 HTTPS しか通らなくなっても大丈夫
 socket.io で WebSocket すら通らなくても大丈夫
 シンプルなルーティングなので IPv6 も大丈夫

25. ロックインしない
• Amazon ECS を利用しているものの、類似サービスが他にもある
 コンテナ関連は情報量も多くなった
 それ以外の部分もだいたい検索すればすぐに解決方法が見つかる
• コンテナやめて、従来型の運用ツール一式に戻っても良い
 当手法にかかるコストが極端に少ないので、手戻りがそもそも少ない
 nodejs 単体で動作するものがあるとして、ビルドからデプロイまで一通りやっても一
週間(40h)もやれば、運用に乗る

26. ご清聴ありがとうございました