i3- 03 eksで構築するグリーのエンターテイメントシステム · はじめに •...

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.S U MMIT

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

グリー株式会社開発本部インフラストラクチャ部リードエンジニア堀口真司

I 3 - 0 3


はじめに

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

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

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

• こんなことやっているチームです1. Amazon EC2 を中心に効率よく運用できるようになったので、さらに柔軟性も欲しくなる

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

3. 当初 docker だけでは運用できなかったが ECS ( Amazon Elastic Container Service) やEKS (Amazon Elastic Container Service for Kubernetes) の登場により現実的になる

4. いずれにしても良し悪しがあり、チームで上がった話題や課題が今日の内容


もくじ

• docker 単体の社内事例

• ECS の社内事例

• EKS の社内事例

• まとめ


docker 単体の社内事例docker run による運用改善のもくろみ


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 を扱うための環境構築が難しかった• 新しめの OS、モニタリング、レジストリ

• 当時流行りの Immutable Infrastructure は仮想化でも十分だった• EC2 環境周辺の整備のほうが効率よかった

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

• すぐに捨てるビルド・開発環境には便利• 長く使うには、むしろ不便になりがち

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


ECS の社内事例


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

EC2では OS やミドルウェアはインフラ部で

対応

コンテナではOS やミドルウェアを開発チームで自由に選べる。

新しい開発言語やOSなど積極的に取り入れることができ、インフラの負担も減らせる。

AMI


ECS について

• 東京リージョンの対応は早かった• むしろ Registory の方が遅かった

• ECS Optimized AMI があり、安心して利用できる• ノード側の設定もシンプルで、 UserData のみでも設定できる

• アップデートも積極的でどんどん便利に• GUI でのオペレーションも便利！

• コンテナオーケストレーションの機能としては十分• docker swarm, nomad, Kubernetes は構築の敷居が高かった

• なによりマネージドであることが重要


メディアサービス構成VPC

EC2 instance contents

Amazon Elastic Container Registry

Amazon Elastic Container Service

nginx

nginx

nginx

nginx

app

app

app

app

Amazon ElastiCache

Amazon RDS

cAdvisor

Cluster - staging

Cluster - production

Operators

Rule

Users

Developers


デプロイまでの流れ

• docker build し ECR に Push する• ビルドの日時と固定のタグ (stg,prd)

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

• Task Definition はほぼ固定• systemControls という GUI では変更できない部分は JSON 直接編集

• Service を Update してコンテナ入れ替え• Force new deployment を有効にして、同じタグのイメージを強制的に取得

• Minimum healthy 100% Maximum 200% で一気に全部入れ替え


モニタリング

• cAdvisor を DAEMON としてデプロイ• 同 VPC の EC2 に構築した Grafana 経由にてメトリクス表示

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

• 文字列ログは CloudWatch Logs• アラームをセットして SNS 経由で Lambda 実行し、 Slack や PagerDuty へ通知

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

• コンテナ以外は既存のモニタリングと同じ


その他 ECS の利用事例

• WebSocket を使ったチャットのサービス• nodejs 実装が相性良く、ステートフルなので Lambda でさらに制御

• 分析系のタスク• 一度にたくさん実行し、並列度の調整がしやすい

• いずれにしても既存の VPC/EC2 と相性がよく、既存サービスと共存する形で小規模から利用できる


EKS の事例


EKS 第一印象

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

• マネージドなので安心して使える• ノード起動までがちょっとめんどう

• VPC の中にも AWS があるイメージ• プライベートクラウドや OpenStack のようなものではない


Kubernetes on EC2 との比較

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

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

• 運用がとても大変• ノードの増減対応やモニタリング、メンテナンスが必要

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

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

• Kubernetes の中で動かすサービスは小規模でも Kubernetes 自体の運用に多くのリソースと熟練度が必要• 我々は Kubernetes の運用がしたいわけではない！

• しかも運用を始めるとクラスタ一つでは足りないこともしばしば…


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

Amazon Elastic Container Registry

Amazon ElastiCache

Users

API pod

Auto Scaling group

app fluentd

Jenkins pod

master

Batch pod

app

Jenkins pod

slave

Build server

Amazon Elastic Block Store (EBS)

Amazon Elastic File System

EC2 instance

EC2 instance

Amazon Aurora

Amazon Kinesis

Amazon CloudWatch


デプロイ方法

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

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

• Deployments を更新するときは意味のない annotation に時刻を設定してコンテナも入れ替え• いちおう Kustomize で環境ごとにテンプレ化

• Strategy は今のところ未調整


モニタリング

• 文字列ログはいったん DaemonSet の fluentd によってフィルタリングしてから CloudWatch へ転送

• EC2 側に Grafana を従来通り構築• Kubernetes クラスタ内に Metrics 収集用の Agent を置き、クラスタ外へ転送

• Container 単位、Pod 単位、 Node 単位で取得


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

• 一段抽象的で回りくどい• Namespace や RBAC の存在、名前解決など

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

• CLI のみで操作可能• 開発時は便利だけど、自宅や緊急時に不安

• 一部リソースは標準で対応されてない• ロギングや ALB 、 EFS が標準対応ではなく、 annotation による補足が大量に発生する

• クラスター費用が心なしか高額• 1時間あたり 0.2 USD 日本円にすると月額約 15000 円なので極小サービスには向いてない

• Kubernetes on EC2 のマスターを t3.micro で 3 台なら 0.0408 USD


まとめ


ECS の良さ

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

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

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

• CloudWatch や CloudTrail の連携が強く、通知やアラートトリガーがお手軽に設定できる

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

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


EKS の良さ

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

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

• ロギングやモニタリングなどの追加リソースの選択肢が多く、案件ごとに柔軟に対応できる

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

• とにかくマネージドの安心さ！• Kubernetes そのものの運用に多くのリソースを割くのは無駄である


まとめ

• ECS はシンプルに他のマネージドサービスとの連携ができる。小さい単位で始められて、後からでも導入しやすい

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

• 運用がラクになり、対応範囲が増えたので、新たなチャレンジが増えた• 守備範囲が増えて採用も良くなり、こんな環境に興味がある人はぜひ。


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

Encoder pod

ffmpeg

EC2 instance

uploader fluentd

Amazon Simple Storage Service (S3)

Amazon CloudFront

Encoder pod

ffmpeg uploader fluentd


デプロイ

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

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

• ライブ中ではない古い Pod を地道に削除• またはサービス全体メンテの時に総入れ替え

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

• 数時間単位でのインメモリ・ステートフルコンテナはReplicaset/Deployments とあまり相性が良くない• 対戦ゲーム、MMORPG、 FPS などの寿命の長いサーバは運用が難しい


モニタリング

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

• エンコードの性能が落ちてないか確認のため、 ffmpeg のログの FPSをグラフ化• Pod を削除しても配信ツールが再接続して他の Pod にコネクションを張るので復帰は大丈夫

• 重要な配信は解像度やビットレートの設定が間違ってないか確認のため、受信したパラメータを Slack 通知

i3- 03 eksで構築するグリーの エンターテイメントシステム · はじめ に •...

Documents

i3- 03 eksで構築するグリーのエンターテイメントシステム · はじめに •...