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

こんにちは、城岸です。

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と比べ)

まとめ

コンテナオーケストレーションのECSとEKSの特徴が理解できるセッションでした。 ECS/EKSの特徴を理解した上で最適なコンテナオーケストレーションを選定したいものですね。