[レポート]JAWS-UGコンテナ支部 #18に参加してきました #jawsug_ct

2020.11.24

2020年11月20日(金)に開催されたJAWS-UGコンテナ支部 #18に参加してきました!YouTube Liveの限定公開にて開催されました。各セッションのレポートをまとめています。

JAWS-UGコンテナ支部 #18

当日のYouTube Liveはこちらから

セッション1. AWS コンテナサービスアップデート

概要

2020 年の AWS コンテナ関連サービスアップデートについて振り返りたいと思います。

スピーカー

Amazon Web Services Japan 落水 恭介氏 (Kyosuke Ochimizu) - Specialist Solutions Architect, Containers

Twitter : @otty246

資料

内容

2020年上半期のアップデート

2020年6月24日にあったBlackBeltにまとまってあります。

レポートブログもあるので合わせて参考にしてください。

2020年上半期のコンテナサービスのアップデートをBlack Beltで振り返る with JAWS-UG コンテナ支部のみなさま

2020年下半期のアップデート

★3連休中にもアップデートがありました。


セッション2. ECSからEKSへ移行事例の紹介

概要

スタディサプリENGLISHはコンテナオーケストレーションに2015年のサービスリリース当初からECSを使ってきましたが、環境の変化とともに2020年、EKSに移行しました。EKSを採用した背景から全体のアーキテクチャを話した後、Argo CDによるgitops、App Meshを使ったgRPCの負荷分散、Spot Oceanを使ったクラスター管理、EKS FargateのCronJobの事例などを紹介したいと思います。

スピーカー

リクルートマーケティングパートナーズ 大島 雅人氏 - Software Engineer / SRE

Twitter : @_mpon

資料

内容

スタディサプリEnglishについて

サービス構成の概要

  • データベースを分離しているため、別のデータベースにはgRPC経由データを取りに行く必要がある
  • Kinesisを利用して学習したデータをConsumer側で集計してデータベースのアップデートをしている
  • S3は画像、音声を保存していてnginxで配信してる というのが50サービスくらいある。環境も20環境に分かれている。

ECSからEKSへ移行した背景

  • ECSでは環境を増やすのがつらかった問題
    • 基本的にTerraformで作成していた。Task定義のみ独自ツールも使用していた。
      • 環境ごとにTerraformを作っていくのがつらかった。
      • ライフサイクルの管理なども難しかった
    • EKSにすることでインスタンスのみTerraform + Spot Ocean で他はk8sのYAMLで記載できるようになった。
      • ほぼk8sのオブジェクトで完結するため管理がしやすい
  • ECSではどこに何がデプロイされているのかわかりにくかった問題
    • どの環境にどのブランチがデプロイされているのか把握が難しかった
    • gitopsツールとしてArgo CDを導入した
      • k8sのReconciliation Loopというアーキテクチャが元になっている
      • Argo CDのApplication Controllerがgitレポジトリとの差分を定期的にチェックしていて、差分があればデプロイする仕組みになっている
      • そのためgitレポジトリの確認だけでデプロイ状況が把握できるようになった   - Dashboardがあったり、Sync Phase and Wavesでデプロイの依存関係をPhase毎に書くことができるのも便利   - Ingress Controller、Datadog Agentも管理できる   - kubectlですぐに状況把握もできる
  • gRPCの負荷分散問題
    • ECSではCloud Mapでやっていたが色んな問題が
    • EKSとApp Meshを活用して解決
      • Amazon EKSでAWS App Meshを利用してgRPCサーバーを運用する
      • 公式に用意されているAWS App Mesh Controller for k8sを利用
      • App MeshはgRPC routingをサポートしている
      • envoyの管理もretryPolicy、k8sのPod Lifecycleを活用してリクエストを落とさずにデプロイできたりした
      • 開発環境を増やすのも簡単、YAMLで書ける
      • デプロイ時にリクエスト落ちる問題も、PodのpreStopでsleepを入れて、Serviceから切り離されるのを待つことで解決
      • AWSのサポートのおかげもあって、無事デプロイできるようになった。
      • というタイミングでALBのgRPCがサポートされたり...もう少し早くほしかった(笑)

EKS移行後の構成について

  • ECSの場合はALB->APIサーバ->Envoy->gRPCの流れ
  • EKSはALB->Nginx->AppMeshにinjectされたEnvoyを経由してAPIサーバと通信という流れに変更されている
    • Cloud Mapは残している
  • Spot Oceanを使ったクラスター管理
    • EKSクラスタの効率的なリソース管理にSpotinst Oceanを使おう
    • PodがUnschedleにならないようにNodeをオートスケーリングしてくれる
    • Podに割り当てるrequestだけを考えればOK
    • Nodeは意識しなくていいのでFargateみたいに使える
    • Spot Instanceから最適なインスタンスを選んでくれる
    • オンデマンドで動いてほしいpodにannotation付与するだけでOK
    • Terraform管理もできる
    • Headroomという余剰ノードを確保しておいてくれる機能あり
    • Cluster Rollで安全なRolling Update
  • JenkinsのJobをCronJobに移行した

まとめ

  • ECSからEKSの移行のお話し
  • gitposやk8sのエコスステムで独自仕様をなくして持続性のあるシステムへ
  • App Mesh問題なく使えてる
  • ECSは今だとFargate Spot、ALBのgRPCサポートもあって使えるかどうか試してみたい
    • ecspressoを使えばもっとうまくできたかもしれない
  • ECSでサービス周りが統一して管理設定できるツールがあればいいかも
    • Copilot?
  • コンテナはいいぞ
    • AWSのマネージドサービスあってこそ

セッション3. Meet Developers Where They Are

概要

In this session, Pahud Hsieh is going to share some recent updates about the Taiwan CDK Meetup community in Taiwan and how we built and innovated with community developers during the past few months. (同僚による超訳) 台湾の CDK ミートアップコミュニティでこの数ヶ月に起こったオーサムな出来事を話すぜ・・・!

スピーカー

Amazon Web Services Pahud Hsieh (謝洪恩) - Developer Advocate

Twitter : @pahudnet

内容

※英語でのセッションでした。翻訳しながらかなりかみ砕いて書いています。

CDKのコミュニティ活動

  • ここ最近、AWS SDKはコンテナだけではなく様々なデータベースサービスでの利用が増えてきている
  • 日本でもAWS CDKへの注目度が高まってきていると思っている。
  • 昨年、台湾でCDKコミュニティを結成した。そこでCDKでFargateを自動スケーリングを作成するデモをした。
  • Meetupを実施しその中で金融系会社の方と出会い、結果的にCDKを使ってコンテナの周りを構築してくれた。うれしい。

コミュニティメンバーのサポート

  • コミュニティメンバーがGitLab RunnerとCDKをまとめた"CDK Lab Runner"を作った。
  • 非常に面白い仕組みで、簡単に実行できた。ここからさらに革新を進めることにした。
  • 具体的にはaws-cdk-for-k3sclusterを公開した。
    • 新しい3つのクラスターを作成し、CDKコンストラクトライブラリとして公開
    • AWSにk8sをデプロイするための方法の一つ
  • 安価なArmベース(MG6)インスタンスでデプロイできるようにした
  • RDSプロキシ、コンテナ、サーバレス、API Gatewayなど多くのものをまとめている。
  • 実行環境はLaravel。簡単にRDSとRDSプロキシをサポートした環境ができる

活動を通して

  • 日本でも多くのユーザーがCI/CD、DevOps...と考えているのは知っている
  • 少しでもFargateの体験をシンプルにしていきたいと思っている
  • そのために CDK GitLabライブラリを作った
  • とても素晴らしい体験ができると思う
  • ぜひこれを知ってほしい。好きになってもらえるはず!
  • 活動は会場だけでなくオンラインでもやってるので見に来てほしい。

YouTube紹介

Pahud Dev


LT1. ALB Ingress ControllerあらためAWS Load Balancer Controllerクイックオーバービュー

スピーカー

Twitter : @_inductor_

資料

内容

  • LoadBalancer ServiceがCon

LoadBalancer ServiceをEKSで使う場合

  • CLB
  • NLB(instance mode)
  • NLB(ip mode) の3種類があるが、NLB(ip mode)がLoadBalancer Controllerで作られるリソース

なぜIPモードの対応が必要なのか

  • instance modeの場合
  1. LBが各ノードのNodePortにロードバランシングしつつ通信を転送
  2. NodePort ServiceからPodのいるノードに通信を転送
  3. Podに通信が到達
  • IP modeの場合
  1. TargetGroupが直接Destination Pod行く

シンプルになった→ホップ数が減って、パフォーマンスが上がる

まとめ

Load Balancer ControllerのNLB-IPを使うとネットワークのボトルネックが改善される!

LT2. ECSでGPUを使う 2020年版

スピーカー

Twitter : @ohsawa0515

資料

内容

ECS GPU-optimized AMIを使う

  • 現状だとEC2でのみ使用できる
  • ECSでGPUを使うのに最適化されたAMIを使用
aws ssm get-parameters \
--names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended \
--output text --query 'Parameters[].Value[]' | jq -r 'image_id' \

ECSタスク定義でGPUを指定できる

  • タスク定義でGPUが指定できる

ECSタスク定義でGPU数を指定することの問題点

  • 1つのGPUを複数のECSタスクで共有することができない
    • g4dn.xlargeはGPUが1つなのでECSインスタンス1台につきGPUを扱うECSタスクを1つしか配置できない
  • GPUを使うECSタスクを同時に実行できない
    • サイドカーなど
  • Dockerのデフォルトランタイムを変更することで解決
    • /etc/sysconfig/docker--default-runtime nvidiaを追加したAMIを作成する
    • AMIの管理コストは発生してしまう

GPU使用率に基づいたAuto Scalingがしたい

  • GPUメトリクスをCloudWatchに投げる自作ツールを用いて実施
  • このメトリクスを元にアラームを作成する。ECS Capacity Providersでコンテナインスタンスが自動的に増減するようにしておくと幸せ

さいごに

今年も気が付けばre:Inventの時期です。すでにオーバーフロー気味ですが、コンテナ系アップデートが続々追加されると思うので頑張って追いついていきたいですね

以上、ネクストモードの島川でした。