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

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

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

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

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

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

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

登壇者

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

内容

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

Amazon ECS のアップデート

Amazon EKS のアップデート

Amazon ECR のアップデート

AWS Proton のご紹介

AWS App Runner のご紹介

Copilot? CLI のご紹介

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

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

登壇者

  • by 濱田孝治 (ハマコー) - MAD(Modern Application Development)チームマネージャー, CX事業本部 / クラスメソッド株式会社
  • by 新井 雅也(Masaya ARAI)- フルスタックディベロッパー, (株)野村総合研究所 - NRI

内容

  • デモと一緒に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を実行することができる

  • バージョンの互換性
  • イメージに付与された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 ~)

登壇者

内容

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

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から初めてみるといいかも。

全体まとめ

半年分のコンテナアップデートの振り返りからコンテナの活用まで充実した2時間30分でございました!特に最近リリースされたApp Runnerはコンテナ体験において非常に触りやすいサービスだと思うのでオススメです!そしてこれからの機能追加に期待です?