【レポート】EKSで構築するグリーのエンターテインメントシステム #AWSSummit

AWS Summit Tokyo 2019

#Amazon EKS

#イベントレポート

#レポート

#AWS

城岸直希

2019.06.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、城岸です。

2019/6/12(水)～14(金) の期間で開催されている、AWS Summit 2019 Tokyo からセッションをレポートします。本記事は「EKSで構築するグリーのエンターテインメントシステム」のセッションレポートになります。

セッション概要

スピーカー：堀口真司氏（グリー株式会社開発本部インフラストラクチャ部ディベロップメントオペレーションズグループリードエンジニア）

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

東京リージョンでも EKS が使えるようになり、コンテナオーケストレーションに ECS との使い分けができるようになりました。両者の違いや使い分けのポイントをゲームやメディア、動画配信などのサービスに適応する事例を交えながらお伝えします。

レポート

アジェンダ

docker単体の社内事例
ECSの社内事例
EKSの社内事例
まとめ

docker単体の社内事例

2014ごろから利用開始
VMに比べると起動が早くメモリ消費も控えめ
社内で開発環境を整えるのに利用

とはいえ当時はあまりはやらず

手元のPCでは使い勝手が悪い
- dockerの実行自体にVMが必要(Not Linuxの場合)、そうなると起動があまり早くない、Dockerのメリットを享受できない
サーバー側での設定が困難
- 本番ワークロードで利用する場合は何かしらのオーケストレーションツールの導入が必須
- モニタリング、レジストリなども
オンプレからのEC2への移行案件がピークだった
AWSのマネージドサービスが先進的でエンジニアの興味がそっちに
dockerを扱うための環境構築が難しかった
Immutable infrastructureは仮想化でも十分だった
すぐに捨てるビルド開発環境には便利
商用には活用しにくい

ECS

コンテナ化への目標や期待
- コンテナにすることで開発チームに言語の指定などを管理させたい
- インフラ担当の負担も減らせる
ECSについて
- 最適化されたAMIがあり安心して利用できる
- アップデートも積極的でどんどん便利に
- オーケストレーションツールとしては十分利用できる
デプロイまでの流れ
- docker buildしてECRにPush
  - git commitからの自動デプロイなどは使わず
- Task Definitionはほぼ固定
- Service Updateでコンテナ入れ替え
モニタリング
- cAdvisorをDAEMONとしてデプロイ
- 文字列ログはCWLogsに
- コンテナ以外は既存のモニタリングと同じ
ECSの利用事例
- WebSocketを使ったチャットサービス
  - nodejs実装が相性良く、ステートフルなのでLambdaで制御
- 分析系のタスク
  - 並列実行がしやすい

EKS

第一印象
- CLIの情報量が多い、使い勝手が良い
- EKSのコントロールプレーンを管理しなくて良いので安心
k8s on EC2とEKSの比較
- k8sは構築がすごく大変(コントロールプレーンの冗長化など)
- それゆえ運用も大変（バージョンアップなどのメンテナンスなど）
- 異常時の対応が大変
  - コードを読めるくらいでないと活用できない
  - 運用しきれずにk8sをやめてしまったこともあり
- K8sで動くサービス自体は小規模でもクラスタの管理が大変
デプロイ方法
- Jenkisマスターコンテナとビルド用のコンテナを実行、コンテナはDockerinDockerでビルド
- ECRにPushするときは最新イメージをlatestに
- コンテナを更新するときはDeploymentsに意味のないannotationに時刻を設定してコンテナも入れ替え
  - （なかなか斬新なデプロイ方法だと感じました）
- Strategyは今の所未調整
モニタリング
- 文字列は一旦DeamonSetのfluentdによってフィルタリング、その後CloudWatchLogsに送信（CloudWatchLogsの料金を考慮）
- EC2側にGrafanaを従来通りに構築
  - コンテナ単位、Pod単位、Node単位でメトリクスを取得
ECSと比べて感じたこと
- 一段抽象的で回りくどい
  - NamespaceやRBACの存在、名前解決など
  - IAMユーザーの権限と、k8sクラスタでの権限管理がわかりにくい（何の権限もないIAMユーザにk8sクラスタのmaster権限を持たせることも設定としては可能）
- CLIのみでの操作
  - ブラウザで操作できないので緊急時に不安
- 一部リソースは標準で対応されていない
  - ALBなど
- コントロールプレーンに対するコストが気になる（ちょっと高い）

まとめ

ECS
- クラスタの管理費がかからない
- VPCネイティブなので既存のサービスからすぐに相互アクセス可能
- マネージドコンソールからの操作が用意
- オートスケールの設定も用意
- 権限の制御をIAMのみで設定可能
EKS
- セットアップが楽(k8s on EC2と比べ)
- kubectl使いやすい
- ロギングやモニタリングなどの追加リソースの選択肢が多く案件ごとに柔軟に対応できる
  - 場合によってはNginxのLBをPodとして構築することも可能
- IAMとRBACKをマッピングできる仕組みが標準で存在し権限管理も柔軟(k8s on EC2と比べ)
- 運用が楽(k8s on EC2と比べ)