Weitere ähnliche Inhalte Ähnlich wie Docker と ECS と WebSocket で最強のマルチプレイ・ゲームサーバを構築 (20) 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 は使わない。オンメモリでやる
モニタリング、デプロイはありもので何とかならないか
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 では、あらゆるアプリがコンテナ運用らしい。
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 が起動する
テスト用などはそもそも
一つしか起動させていない
ホスト内で競合する場合は、
一台に一つのコンテナしか
起動できない
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)もやれば、運用に乗る