EKSで構築するグリーのエンターテイメントシステム

(1)

EKSで構築するグリーの

エンターテイメントシステム

グリー株式会社開発本部インフラストラクチャ部

リードエンジニア堀口真司

(2)

はじめに

• 堀口真司

• グリー株式会社にて8年目、現在までインフラ部

• DB の運用改善やクラウド環境の改善、ネイティブゲームの開発協力

• AWS Summit は三回目、各種クラウドやゲーム系勉強会にて講演多数

• こんなことやっているチームです

1. Amazon EC2 を中心に効率よく運用できるようになったので、さらに柔軟性も欲しくなる

2. EC2 でのサーバセットアップはインフラ部の対応が必要だけど docker なら開発者が自由に

気軽に構築することができる

3. 当初 docker だけでは運用できなかったが ECS ( Amazon Elastic Container Service) や

(3)

• docker 単体の社内事例

• ECS の社内事例

• EKS の社内事例

(4)

(5)

docker 単体での活用

• 2014 年ごろから流行に乗る形で各々が利用開始

• 他は Vagrant と Hypervisor の組み合わせが主流

• VM に比べると起動が早くメモリ消費も控えめ

(6)

流行らなかった振り返り

• 手元の PC では使い勝手が悪い

• IDE やホストファイルシステムとの相性

• VM で組むのと大差なく、 docker 実行に VM が必要だった

• サーバー側では docker 環境の導入が進まず

• 大きな需要がなかった。鶏卵問題？

• docker 単体では実行ファイル単体と大差なかった

• ビルド環境、コンテナレジストリ、プロセス維持、モニタリングなども課題

• そもそも OS を新しくしないと docker が動かなかった

(7)

流行らなかった振り返り２

• オンプレから AWS へ移行・新規案件導入がピークだった

• いわゆる EC2 の環境整備が優先

• VM は利用者も多く使い勝手がわかりやすかった

• AWS マネージドサービスが先進的だった

• AutoScale/RDS/Lambda/CloudFormation/DynamoDB などなど…

• オンプレ運用で不便だったところがどんどんマネージド化された

• 案件数が多く、お手軽なシステムで可搬性が重視された（と思う）

(8)

導入できた部分

• Ubuntu/Debian パッケージビルドシステム

• EC2 に合わせて新しめの OS のパッケージが必要だった

• docker コンテナ内でパッケージのビルドが使い勝手良かった

(9)

docker 単体運用まとめ

• docker を扱うための環境構築が難しかった

• 新しめの OS、モニタリング、レジストリ

• 当時流行りの Immutable Infrastructure は仮想化でも十分だった

• EC2 環境周辺の整備のほうが効率よかった

• どっちかを選ぶのではなく、どちらにしろ EC2 が必要

• すぐに捨てるビルド・開発環境には便利

• 長く使うには、むしろ不便になりがち

→ 商用サービスには活用しにくい

(10)

(11)

コンテナ化への目標や期待

EC2 では OS や

ミドルウェアは

インフラ部で

対応

コンテナでは OS

やミドルウェアを

開発チームで自由

に選べる。

新しい開発言語や

OS など積極的に取

り入れることがで

き、インフラの負

担も減らせる。

AMI

(12)

ECS について

• 東京リージョンの対応は早かった

• むしろ Registory の方が遅かった

• ECS Optimized AMI があり、安心して利用できる

• ノード側の設定もシンプルで、 UserData のみでも設定できる

• アップデートも積極的でどんどん便利に

• GUI でのオペレーションも便利！

• コンテナオーケストレーションの機能としては十分

• docker swarm, nomad, Kubernetes は構築の敷居が高かった

(13)

メディアサービス構成

VPC

EC2 instance contents

Amazon Elastic

Container Registry

Amazon Elastic Container Service

nginx

app

Amazon ElastiCache

Amazon RDS

cAdvisor

Cluster - staging

Cluster - production

Rule

Users

Developers

(14)

デプロイまでの流れ

• docker build し ECR に Push する

• ビルドの日時と固定のタグ (stg,prd)

• git commit からの自動デプロイなどは使わず

• Task Definition はほぼ固定

• systemControls という GUI では変更できない部分は JSON 直接編集

• Service を Update してコンテナ入れ替え

• Force new deployment を有効にして、同じタグのイメージを強制的に取得

(15)

モニタリング

• cAdvisor を DAEMON としてデプロイ

• 同 VPC の EC2 に構築した Grafana 経由にてメトリクス表示

• アラートも Grafana 側から独自システム経由でトリガー

• 文字列ログは CloudWatch Logs

• アラームをセットして SNS 経由で Lambda 実行し、 Slack や PagerDuty へ通知

• フィルターだけでなく CloudWatch Event 全般で通知も併用

(16)

その他 ECS の利用事例

• WebSocket を使ったチャットのサービス

• nodejs 実装が相性良く、ステートフルなので Lambda でさらに制御

• 分析系のタスク

• 一度にたくさん実行し、並列度の調整がしやすい

• いずれにしても既存の VPC/EC2 と相性がよく、既存サービスと共存す

る形で小規模から利用できる

(17)

(18)

EKS 第一印象

• ほとんどの操作を完成度の高い標準 CLI で行える

• マネージドなので安心して使える

• ノード起動までがちょっとめんどう

• VPC の中にも AWS があるイメージ

• プライベートクラウドや OpenStack のようなものではない

(19)

Kubernetes on EC2 との比較

• 構築がとても大変

• VPC の中に仮想化された名前解決、ストレージ、 API などを持つマスターと実際にコンテ

ナを動作させるためのノードの構築が必要

• 運用がとても大変

• ノードの増減対応やモニタリング、メンテナンスが必要

• 異常時の対応がとても大変

• クラスタの異常時にはドキュメントではなくコードを読めるぐらいでないと活用できない

• 運用しきれずに Kubernetes をやめてしまったこともあり

• Kubernetes の中で動かすサービスは小規模でも Kubernetes 自体の運

用に多くのリソースと熟練度が必要

• 我々は Kubernetes の運用がしたいわけではない！

(20)

ゲームでの構成(リリース前)

VPC

Amazon Elastic

Container Registry

Amazon ElastiCache

Users

API pod

Auto Scaling group

app

_fluentd

Jenkins pod

master

Batch pod

app

Build server

Amazon Elastic File System

EC2 instance

Amazon Aurora

Amazon Kinesis

Amazon CloudWatch

(21)

デプロイ方法

• Jenkins マスターコンテナとビルド用のコンテナを実行、コンテナは

DinD でビルド

• ECR に Push するときは latest タグも上書き

• Deployments を更新するときは意味のない annotation に時刻を設定

してコンテナも入れ替え

• いちおう Kustomize で環境ごとにテンプレ化

(22)

モニタリング

• 文字列ログはいったん DaemonSet の fluentd によってフィルタリン

グしてから CloudWatch へ転送

• EC2 側に Grafana を従来通り構築

• Kubernetes クラスタ内に Metrics 収集用の Agent を置き、クラスタ外へ転送

(23)

ECS と比べてみて感じたこと

• 一段抽象的で回りくどい

• Namespace や RBAC の存在、名前解決など

• 社内では用途ごとにアカウントを分けているので、ややミスマッチ

• CLI のみで操作可能

• 開発時は便利だけど、自宅や緊急時に不安

• 一部リソースは標準で対応されてない

• ロギングや ALB 、 EFS が標準対応ではなく、 annotation による補足が大量に発生する

• クラスター費用が心なしか高額

• 1時間あたり 0.2 USD 日本円にすると月額約 15000 円なので極小サービスには向いてない

(24)

(25)

ECS の良さ

• docker のセットアップ不要で管理費用は掛からない

• VPC ネイティブなので既存サービスからすぐに相互アクセスできる

• マネジメントコンソールで操作できる

• CloudWatch や CloudTrail の連携が強く、通知やアラートトリガーが

お手軽に設定できる

• AutoScale や ALB/TargetGroup にも対応している

• 他の AWS API と同じ IAM なので Lambda による運用の自動化と相性

(26)

EKS の良さ

• Kubernetes 環境一式のセットアップが不要、公式 AMI もある

• kubectl で操作できるので開発しやすい

• ロギングやモニタリングなどの追加リソースの選択肢が多く、案件ごと

に柔軟に対応できる

• IAMとRBACはマッピングできる仕組みが標準であり、権限管理も柔軟

• とにかくマネージドの安心さ！

• Kubernetes そのものの運用に多くのリソースを割くのは無駄である

(27)

まとめ

• ECS はシンプルに他のマネージドサービスとの連携ができる。小さい

単位で始められて、後からでも導入しやすい

• EKS は Kubernetes の運用が不要になり、安全にカスタマイズできる

環境ができるようになった

• 運用がラクになり、対応範囲が増えたので、新たなチャレンジが増えた

• 守備範囲が増えて採用も良くなり、こんな環境に興味がある人はぜひ。

(28)

(29)

映像配信システム構成（検証のみ）

Encoder pod

ffmpeg

EC2 instance

uploader

fluentd

Amazon Simple Storage

Service (S3)

Amazon CloudFront

Encoder pod

(30)

デプロイ

• ライブ中のコンテナは Readiness を落とす

• ECR まで上げるところは今までと同じ流れ

• ライブ中ではない古い Pod を地道に削除

• またはサービス全体メンテの時に総入れ替え

• Readiness が落ちてるものは優先度が低くシステムに削除されやすい

• 数時間単位でのインメモリ・ステートフルコンテナは

Replicaset/Deployments とあまり相性が良くない

• 対戦ゲーム、MMORPG、 FPS などの寿命の長いサーバは運用が難しい

(31)

モニタリング

• Pod を占有するので AvailablePods に関心を持つ

• エンコードの性能が落ちてないか確認のため、 ffmpeg のログの FPS

をグラフ化

• Pod を削除しても配信ツールが再接続して他の Pod にコネクションを張るので復帰は大丈夫

• 重要な配信は解像度やビットレートの設定が間違ってないか確認のため、

受信したパラメータを Slack 通知

EKSで構築するグリーの エンターテイメントシステム

EKSで構築するグリーの

エンターテイメントシステム

グリー株式会社 開発本部 インフラストラクチャ部

リードエンジニア 堀口真司

はじめに

•

堀口真司

•

グリー株式会社にて8年目、現在までインフラ部

•

DB の運用改善やクラウド環境の改善、ネイティブゲームの開発協力

•

AWS Summit は三回目、各種クラウドやゲーム系勉強会にて講演多数

•

こんなことやっているチームです

1.

Amazon EC2 を中心に効率よく運用できるようになったので、さらに柔軟性も欲しくなる

2.

EC2 でのサーバセットアップはインフラ部の対応が必要だけど docker なら開発者が自由に

気軽に構築することができる

3.

当初 docker だけでは運用できなかったが ECS ( Amazon Elastic Container Service) や

もくじ

•

docker 単体の社内事例

•

ECS の社内事例

•

EKS の社内事例

docker 単体での活用

•

2014 年ごろから流行に乗る形で各々が利用開始

•

他は Vagrant と Hypervisor の組み合わせが主流

•

VM に比べると起動が早くメモリ消費も控えめ

流行らなかった振り返り

•

手元の PC では使い勝手が悪い

•

IDE やホストファイルシステムとの相性

•

VM で組むのと大差なく、 docker 実行に VM が必要だった

•

サーバー側では docker 環境の導入が進まず

•

大きな需要がなかった。鶏卵問題？

•

docker 単体では実行ファイル単体と大差なかった

•

ビルド環境、コンテナレジストリ、プロセス維持、モニタリングなども課題

•

そもそも OS を新しくしないと docker が動かなかった

流行らなかった振り返り２

•

オンプレから AWS へ移行・新規案件導入がピークだった

•

いわゆる EC2 の環境整備が優先

•

VM は利用者も多く使い勝手がわかりやすかった

•

AWS マネージドサービスが先進的だった

•

AutoScale/RDS/Lambda/CloudFormation/DynamoDB などなど…

•

オンプレ運用で不便だったところがどんどんマネージド化された

•

案件数が多く、お手軽なシステムで可搬性が重視された（と思う）

導入できた部分

•

Ubuntu/Debian パッケージビルドシステム

•

EC2 に合わせて新しめの OS のパッケージが必要だった

•

docker コンテナ内でパッケージのビルドが使い勝手良かった

docker 単体運用まとめ

•

docker を扱うための環境構築が難しかった

•

EKSで構築するグリーのエンターテイメントシステム

グリー株式会社開発本部インフラストラクチャ部

リードエンジニア堀口真司