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

#コンテナ

島川寿希也

2020.11.24

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

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にまとまってあります。

20200624 AWS Black Belt Online Seminar Container Services Update from Amazon Web Services Japan

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

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

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

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

AWS Copilot CLI is now Generally Available
- AWS CopilotがGA!?

セッション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でやっていたが色んな問題が
  - 当時のブログ-> EnvoyとAmazon ECS Service Discoveryを利用したgRPCの負荷分散
  - gRPCサーバをRolling UpdateするとSTOP済みのコンテナのIPが返ってきてリクエストが落ちてしまうためJenkinsでBlue/Green
  - ワークアラウンド感満載だった
- 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に移行した
- EKS クラスタの CronJob を Fargate 上で実行する方法
- Jenkinsはどんどんジョブが増えて何がどうなっているか分からなくなっていた
- k8sのCronJobにすることでYAML管理するようにした。

まとめ

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を自動スケーリングを作成するデモをした。
- aws-samples / aws-fargate-fast-autoscaler
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の場合

LBが各ノードのNodePortにロードバランシングしつつ通信を転送
NodePort ServiceからPodのいるノードに通信を転送
Podに通信が到達

IP modeの場合

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に投げる自作ツールを用いて実施
- https://github.com/ohsawa0515/gpu-cloudwatch-reporting
このメトリクスを元にアラームを作成する。ECS Capacity Providersでコンテナインスタンスが自動的に増減するようにしておくと幸せ