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

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

まとめ

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