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

2021年6月28日(月)に開催されたJAWS-UGコンテナ支部 #19に参加してきました！今回もYouTube Liveの限定公開にて開催されました。各セッションのレポートをまとめています。

#コンテナ

#JAWS-UG

島川寿希也

2021.06.28

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

前回からもう半年。re:Inventも挟みアップデート内容含めて今回も内容が盛りだくさんです！ ※前回ブログものせておきます。

当日Youtube Liveはアーカイブでも見ることができます

1. AWS コンテナサービスアップデート(youtube 00:07:10 ~)

登壇者

by 苅野秀和 - ソリューションアーキテクト / アマゾンウェブサービスジャパン株式会社

内容

2020年12月～のアップデートがまとまっています。約半年ですがコンテナ系サービスだけで相当な数のアップデートですね?

Amazon ECS のアップデート

Amazon ECS Anywhereの発表(2020/12/04)
- どこでもECSを起動できるサービス
- コンプライアンス、ロケーションの制約、社内ルール等のルールでAWS使えない時に使える
- オンプレミスの資産の有効活用など
- サービスページ
- ECS Anywhere を Azure と Google Cloud (GCP) を使って動かしてみた
- ECS Anywhere GA(2021/05/27)
ECS デプロイメントサーキットブレーカーのプレビューを発表(2020/12/04)
- ECS デプロイメントサーキットブレーカーの一般提供を発表(2020/12/22)
Amazon Elastic Container Service が新しいマネジメントコンソールの提供を開始(2020/12/30)
Amazon ECS でのデーモンサービスの改善(2021/05/06)
VPC エンドポイントポリシーのサポートが開始されました(2021/06/16)
サービスごとのタスク、およびクラスターごとのサービスに設定されるサービスクォータの引き上げを開始(2021/01/21)
Amazon EC2 または AWS Fargate で実行されているコンテナでのコマンドの実行が可能に(2021/03/15)
- SSMを経由してシェルを叩けるようになったアップデート

Amazon EKS のアップデート

Amazon EKS Anywhereの発表(2020/12/04)
Amazon EMR on Amazon Elastic Kubernetes Service (EKS)(2020/12/09)
Amazon EKS クラスターが OIDC 互換 ID プロバイダーのユーザー認証をサポート(2021/02/12)
Amazon EKS および EKS Distro で Kubernetes バージョン 1.19 のサポートを開始(2021/02/16)
Amazon EKS および EKS Distro が Kubernetes バージョン 1.20 のサポートを開始(2021/03/18)
シークレットのセキュリティを強化するために、既存のクラスターへの KMS エンベロープ暗号化の追加のサポートを開始(2021/03/01)
- クラスターの作成時にのみだけではなくいつでもエンベローブ暗号化を有効にすることができる
AWS CloudFormation を使用したアドオンの作成と管理がサポートされるようになりました。(2021/03/05)
EKS クラスターのコントロールプレーン作成時間を 40% 短縮(2021/03/19)
- 平均9分以内でEKSクラスターのコントロールプレーンを作成できるようになった。
Elastic Fabric Adapter のサポートを開始(2021/03/26)
P4d インスタンスをサポート開始(2021/03/26)
eksctl が、リソース仕様とドライランモードを使用したノードグループの作成のサポートを開始(2021/04/08)
EMR で Kubernetes ポッドテンプレートを使用して、Spark ワークロードの実行を簡素化し、コストを管理(2021/05/07)
AWS Secrets Manager が Provider for Kubernetes Secrets Store CSI ドライバーを提供(2021/04/26)
- AWS Secrets managerからシークレットを安全に取得できるようになった
- Kubernetes Secrets StoreとContainer Storage Interface(CSI)ドライバーを利用してSecrets Managerに保存されたシークレットをボリュームとしてPodにマウントできる
Amazon EKS マネージドノードグループが Kubernetes ノードの taint のサポートを追加(2021/05/11)
EKS のアドオンで、CoreDNS と kube-proxy のサポートを開始(2021/05/20)

Amazon ECR のアップデート

AWS Proton のご紹介

Protonテンプレートを選択してパラメータを入力するだけでデプロイまでできる
インフラはもちろん、CI/CD～モニタリングまで
直近のアップデート
- AWS Proton が使用中のテンプレート用に削除保護を導入(2021/05/19)
- カスタマー管理の環境を導入(2021/04/27)
- デプロイをキャンセルするための API を追加(2021/04/27)
参考

AWS App Runner のご紹介

AWS App Runner: スケーラブルで安全なウェブアプリケーションをコードから数分で作成(2021/05/21)
Webアプリケーションのためのフルマネージドサービス
※次の章でデモありました！
参考

2021/07/02に行われるContainers from the Couch 日本語版でも登場するらしいです。

Copilot? CLI のご紹介

AWSが開発したOSSのCLIツール
- https://aws.github.io/copilot-cli/ja/
ECSでのコンテナアプリケーションの構築・リリース・運用を容易に
インフラではなくアプリ開発に集中できる
- 対話によるECSクラスター、CI/CDの作成
- 宣言的マニフェストによる「アーキテクチャ」の定義
App Runnerへのデプロイもサポートされています！(v1.7.0 ~)
※こちらも次の章でデモありました！

2. CopilotとApp Runnerの欲張りセット(youtube 00:42:50 ~)

登壇者

by 濱田孝治 (ハマコー) - MAD（Modern Application Development）チームマネージャー, CX事業本部 / クラスメソッド株式会社
- Twitter: @hamako9999
- Blog: Developers.IO
- サービス内容: MAD（Modern Application Development）
by 新井雅也（Masaya ARAI）- フルスタックディベロッパー, （株）野村総合研究所 - NRI
- twitter: @msy78
- HatenaBlog: iselegant

内容

デモと一緒にCopilot × App Runnerで簡単ECS構築！?

ECS x Fargateで必要な色んなインフラ作業もCopilotにお任せ

ECS x Fargateで必要なインフラ作業は
- VPCを作る
- サブネットを作る
- インターネットゲートウェイ、ルートテーブルを作成
- ALBを作成
- ECRを作成→コンテナをプッシュ
- ※CloudWatch Log Groupを作ってログの出力先を用意しておく
- ECSのリソースを作る
- IAMロール、クラスター、タスク定義、サービス...。
- そしてアプリをデプロイ
とめちゃくちゃ多い作業をCopilotでCLIベースで一気に解決ができる！
- 裏ではCloudFormationが動いている

App Runnerでインフラリソースの管理を簡略化

Copilotで作ったリソースも実際にはインフラのリソースが存在し、少なからず管理をする必要がある。
- 負荷分散、CI/CD、AutoScaling、セキュリティ、Domain、監視、ログetc...
App Runnerを使うことでほとんどのインフラリソースを抽象化することができる
ただし、いくつか注意点も
- VPC内にApp Runnerインスタンスは作れない
- リソース制限あり(1-2vCPU / メモリ2 or 4GB)
- リクエストは制限なしでインターネットに公開される
- 現状WAFは使えない
- スケールダウン時は最小は1台
- 最低1台は必ず起動するのコストは常に発生する

CopilotでApp Runnerを作る

Copilotのv1.7.0以降でApp Runnerを作ることができる。

セッションメモとQA

App RunnerでWAFは使えない
App Runnerは機能追加リクエストが多い現状
Q.構築は簡単そうですが、削除（お片付け）も簡単にできるのか？
- A. 簡単！
Q.copilotで作成されたAWSリソースはどのようにコード管理されているのか。マニュフェストファイルのみ管理できればいいのか。
- A. IaCの考え方と同じで、複数人で運用する場合はコードはレポジトリ管理したほうがよい。

宣伝

登壇された新井さんが執筆したIaCの本?。これからIaCはじめるかたも既に運用されている方も。

3.AWS上で動かすWindowsコンテナ(youtube 01:17:52 ~)

登壇者

by 浅野佑貴 - ソリューションアーキテクト / アマゾンウェブサービスジャパン株式会社

内容

AWS上で動かすWindows Containerがイメージついていない、よくわからないそんな方に向けたセッションです。

そろそろWindows Container触ってみませんか？

ECSは2017年にEKSは2019年にWindows Containerがサポートされている。

ライセンスについて

Container WorkloadとしてのサポートされているWindowプラットフォーム
- Windows Server (Semi-Annual Channel)
- Windows Server 2019
- Windows Server 2016
- Windows 10 Professional/Enterprise Edition
- Windows10は開発、テスト用途に限られるので注意
Windows Serverの提供形態について
- 長期サービスチャネル(LTSC)
- メジャーバージョンが2-3年ごとにリリース
- Windows Server 2016 / 2019
- インストールオプション
  - Server Core
  - Server with Desktop Experience (GUIが利用可能なもの)
- 半期チャネル(SAC)
- 半年ごとのリリースサイクルで新バージョンがリリース
- 製品名にバージョン番号が付かない
- インストールオプション
  - Container HostとContainer Image用のServer Core
  - Nano Server Container Image

Windowsのコンテナ？

Isolation Modeが二つある
- Process Isolation
  - プロセス分離モードと呼ばれる
  - デフォルトのIsolation
  - ホストOSのカーネルを共有しながら分離されたユーザモードプロセスの実行環境を提供
  - Windows Server Containerと表現されることがある
  - 実行するWindows Containerのバージョン等がホストOSと一致していなければならない
- Hyper-V Isolation
  - Hyper-V ハイパーバイザーを利用して、隔離したContainerごとに専用環境を提供する
  - Host OSのカーネルを共有しない
  - Hyper-V Containerと表現されることがある
  - Host OSとバージョンが一致していないWindows Containerを実行することができる

バージョンの互換性
- Windows Server host OSに対応した利用可能なベースOSイメージのバージョンは下記URL参照
- https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility
イメージに付与されたTagからどのOSバージョンに対応しているかを判断できる
分離モード別のWindows Container 起動可能数について
ECSやEKSでのサポート状況と考慮点
- Process Isolation Modeのみをサポート
- EKSに関してはk8s自体がProcess Isolation Modeのみをサポートしている
- バージョン互換性を考慮すると以下のような対策が必要
- 開発環境と運用環境で同じOSバージョンに基づいてContainer Imageをビルド
- 複数のWindows ServerのOSバージョンが混在するクラスターでは、配置ルールを定義して互換性のあるHost OS上にContainerが配置されるようにする
- Host OSバージョン単位でクラスターを分割する

WindowsコンテナのベースOSイメージについて

Docker Hubにある
- 実態はMicrosoft Container Registry(MCR)にある
利用可能なベースOSイメージとその用途
- Nano Server
- .Net Coreアプリケーション向け。PowerShell,WMI,Windowsサービススタックなし。軽量
- Windows Server Core
- LTSC/SACのServer CoreベースのOSイメージ。.NET Frameworkアプリケーション向け。IISも利用可能。
- Windows
- Server Coreでも依存関係が不足しているときに選択する。イメージサイズ大
Windows Containerでサポートされない機能例
- RDP / OFfice
- ADへの参加
- ADを使う場合はgMSAを利用する

既存アプリケーションの移行検討例

- AWSサービスとのインテグレーション - Amazon FSx for Windows File Server - ECSでもEKSでも使えて、永続ストレージとしての利用

アプリケーションのログの出力先

よくある出力先
- Event Logs
- ETW Providers
- Custom App Logs
- ファイル出力
Log Monitorというサービスでログに対応する
- Microsoft社が公開しているWindowsコンテナ用のログ出力ツール
- ログソースをモニタリングして標準出力へ整形して出力することができる。
- よくある出力先のEvent Logs,ETW,Custom App logsに対応
他にも、オープンソースのMIT License

セッションメモとQA

Q. FargateがWindowsコンテナをサポートする予定はあるか。
- A. まだ未定
Q. Hyper-V Isolationのほうが、Process Isolationより性能面でアドバンテージがあるという理解でよいか
- A. 実際のアプリケーションの動作に影響が出るかといえばそれはケースバイケースである

4. 転職会議SRE meets EKS ~ 転職会議の運用で得られたEKSの知見を大公開(youtube 01:48:00 ~)

登壇者

by 山﨑理弘 - 転職会議事業部 SRE / 株式会社リブセンス
- Twitter: @katainaka0503
- 会社テックブログ: https://made.livesense.co.jp
- 個人ブログ: https://katainaka0503.hatenablog.com<

内容

転職会議では2020年一年をかけてECS主体のシステムからEKS基盤上に移行し、その後もEKSの運用に関してのノウハウを積み重ねてきました。今回の登壇では、実際の運用で感じたECSとEKSを比較した際のメリデメや、アプリケーションエンジニアへの知識移転での工夫にいたるまで、転職会議のSREチームで蓄積した知見を大公開します！

JAWS-UG コンテナ支部 #19 from 理弘山崎

EKS化以前の転職会議のECS基盤の課題

SREがいないと新しいサービスをデプロイできない
ECSのデプロイツールが独自
ECS/EC2/Lambdaで作られたシステムが混在
クレデンシャルの扱い方に問題がある

EKS移行をどう進めたか

マイクロサービスごとに順次切り替え
- 一度に切り替えずマイクロサービス毎に
- マイクロサービス毎に切り替えることで障害半径を最小化
- ALB + ECSを指しているRoute53のレコードをExternalDNS配下に移してRoute53で切り替え
- 切り戻しはRoute53レコードを元に戻す
完璧をいきなり作るのではなく、フェーズを切って順番に完成度を高めていく
- Kubernetesエコシステムの膨大な選択肢に圧倒されて、移行が進まなくなることを防ぐ。
- フェーズごとに最低限満たしているべき状態を意識しながら進めた
- ステージングから順繰りと。
開発者への知識移転
- アプリケーション開発者を対象にした勉強会の開催
- 練習問題を使った勉強会
- モブプロ形式で一緒にEKS化

転職会議のEKS基盤

CI/CD
- Fluxを採用
- GitOpsによるCI/CDを実現
Kubernetesリポジトリの設定内容をGitHubと同期
- 新しいイメージをデプロイしたらGitHubにイメージを書き戻す
- チャットボットと連携したブランチデプロイの整備
新しいイメージのタグでステージングを自動で更新
特定のブランチから作られたイメージをChatOpsでステージングにデプロイ
- プルリクブランチから作られたイメージをChatOpsでデプロイ
- マイクロサービス間の動きをあらかじめ確かめておきたい
本番にChatOpsで新しいイメージをデプロイ
なぜFluxを選んだか
- 「YAMLの更新」と「新しいイメージのデプロイ」の2つのユースケースを両立させるため
- 今ではFlux以外にもArgoCDやPipeCDのGUIもいいかなと思っている
監視
- 監視はDatadog
- DeploymentやCronJobの状態を監視
- AWS Load Balancer Controllerなど、カスタムコンポーネントもメトリクスを監視
- 壊れた設定をデプロイしたら即アラート
- Kubernetesのクラスターの中にDatadogのAgentがいる
ログ
- ログは Grafana Loki
- S3をデータ保存先にしている
- CloudWatch LogsやDatadog Logsに比べて安い
- ログにはPodのメタデータからログにメタデータを付与
自動スケーリング
- Cluster Autoscalerでノードを自動で増減
- Horizontal Pod AutoscalerでPodを自動で増減
その他
- クレデンシャル管理「SealedSecret」
- SealedSecretの鍵のバックアップ「Velero」
- ConfigMap,SealedSecret更新時のrestart「Reloader」
- バッチ処理「Argo Workflow」
- AWSのリソース管理「ExternalDNS」,「AWS Load Balancer Controller」

ECS/EKSのメリデメ

ECSでもEKSでもできること
- ECSでも必要な機能のほとんどができる
- Fargateもどっちも使える
- デバッグ(ECS Exec)も、サービスメッシュの利用も。
EKSのメリット
- シンプルなコンポーネントを組み合わせて基盤をゼロから作るのに向く
- 質の高い基盤が作れればアプリケーション開発者が自立して新サービスのデプロイに取り組める
- ただし、コンポーネントが増えるたびに監視やアップグレードの対象が増えることには注意
- Kubernetesエコシステムの資産を利用可能
- GitOpsの実現の容易さ
ECSのメリット
- 簡単にコンテナ基盤を構築できる
- Copilotなどの便利なツール
- クラスタのアップグレードにかかる工数が低い
- クラスタ自体が無料
EKSで注意すること
- Podを安全に終了する
- アプリケーションをSIGTERM受信時に終了するように実装
  - ECSでも同じ
- トラフィックを受け付けるPodのpreStopフックでsleepする
- Serviceからのエンドポイントの除外とPodの終了処理は非同期で進むため、Serviceからのエンドポイントの除外が終わってからPodの終了処理を進めるようにする
- STSのリージョナルエンドポイントを使う
- EKSのIAM Role for Service AccountsではIAMの権限を得るためにk8sのID TokenをAWSの一時クレデンシャルに引き換えている
- STSのリージョナルエンドポイントを使わないとトークンの更新時にレイテンシが上がる
- PodからAWS SDKを使う場合はSTSリージョナルエンドポイントを使う設定を入れたほうがよい
  - AWS_STS_REGIONAL_ENDPOINTS=regional
- システムコンポーネントの監視
- AWS Load Balancer ControllerやExternalDNS等は誤った設定による処理の失敗の監視を行えない。
  - YAMLを修正したけど本番環境にエラーで適用されていなかったケース
- Prometheusエンドポイント等からメトリクスを取得してエラー発生には通知が飛ぶようにする。
- Datadogの場合はAutodiscoveryという機能が使える

まとめ

EKSクラスタは労力がかかるがやりきったときのメリットは大きい
- アプリケーション担当者が自律的に動ける点
システムの性質や開発組織の状況からECSかEKSかを判断する
- EKS化よりも先にあたりまえを整えるという戦略もありかも

セッションメモとQA

構成図にはみえなかった、istio、App Meshによるトラフィック制御は導入していないのか
- SREが2人というのもありまだ導入に至っていない。現状でも十分だと思っている。
Tシャツはどこで作ったんですか？
- クラスメソッドの退職祝いでもらったTシャツです
Argo Workflowの感触について
- AというバッチとBというバッチは同時に実行させない等柔軟な処理に対応ができる点が良い。かなりいけてると思う。
AWS Controllers for Kubernetes(ACK)は今後GitOpsしているのであれば検討するのか
- DynamoDBやS3などのリソースのライフサイクルが長いものは難しそうだけどIAM Roleとかは検討してもいいかもという気持ち
本番環境のクラスターアップグレードはどうやっているか
- in-place upgradeでやっている。ステージングで確認してから本番へ適用
EKSクラスタは何で作成/管理しているか
- Terraformで管理している
EKS化にかかった期間は？
- 1年かけて
バッチ処理は色んな選択肢があると思うが、使い分けはしているのか？
- 全部Argoで統一
ECSとEKSどちらが良さそうですか？k8sもコンテナも知らない人が大半だとk8sは大変。
- まずはコンテナを知るためにECSから初めてみるといいかも。