こんにちは。
カスタマーサクセス部の山本です。😺
Re:Invent のセッション動画を、少しずつ観ています。
感想や内容をブログ記事に書くことで、誰かの役に立てればと思います。
業務で ECS (Elastic Container Service) を使ったワークロードを扱うことが多いので、一回目の今回は ECS のセッションです。
- セッション名：AWS re:Invent 2024 - Unleashing the power of Amazon ECS for platform teams (SVS330)
- 概要
- 登壇者
- セッションの内容
- 余談
セッション名：AWS re:Invent 2024 - Unleashing the power of Amazon ECS for platform teams (SVS330)
タイトルを和訳するなら、「プラットフォームチームに、ECS の持つ力を解き放つ！」と言ったところでしょうか。
ECS を使って、パフォーマンスも運用効率もコスト効率も上げていこう！という内容のようです。
概要
セッション の Level の記載がなく分からないのですが、全体を通して、技術的に深い内容には触れないので、100 または 200 と思いました。
- Account as a Service
- Platform as a Service
- Cluster as a Service
- Template as a Sevice
という ECS を運用するための 4 つの構成を取り上げています。 インフラ担当者と開発者がそれぞれ取り組むことを説明しています。
また、事例として取り上げる内容は、35 万行ある Java でできたローン会計システムを ECS on Fargate に移行し・・・
バッチ処理の実行時間が 65 % 改善し、
システムの保守コストが 33 % 改善し、
コード量も 22 % 減った、
という話のようでした。
登壇者
- Jennifer Lin
- Principal Product Manager Amazon ECS and App Runner
- Olly Pomeroy
- Specialist Solution Architect AWS Containers Services
- Michael Lee
- Vice President Finance Technology
- Fannie Mae
講師のJenniferとOllyが、ECSを利用する際の一般的なパターンについて解説し、Fannie MaeのMichaelが事例を共有します。
Fannie Mae（Federal National Mortgage Association、FNMA）は、アメリカ合衆国の政府支援企業（GSE：Government-Sponsored Enterprise）です。
民間企業と政府の中間的な存在として、住宅市場の健全性を維持し、経済全体の安定を支える重要な機関です。
住宅所有をより多くのアメリカ人に可能にすることを目指しています。
1938年に設立され、86 年の歴史があります。
セッションの内容
セッションの内容を、印象に残ったスライドと共に見ていきましょう。
スライド→説明という形で記載していきます。
導入
Let's start with abstractions
ECS利用の4つの抽象化レベルを食べ物の比喩で説明しています
- 食材の袋（Account as a Service）: 開発者が AWS にフルアクセスし、インフラからアプリケーションコードまで全てを管理。
- 家庭用ミールキット（Template as a Service）: 開発者は事前設定されたインフラのテンプレートを使用して、ある程度のカスタマイズが可能。
- 冷凍ディナー（Cluster as a Service）: 事前設定済みクラスターに開発者がサービスをデプロイするのみ。
- シェフが準備した食事（Platform as a Service）: 完全なプラットフォーム上で開発者がコンテナイメージだけをデプロイ。
主なポイントは、プラットフォームチームが開発者の自律性と標準化について考えつつ、運用効率とのバランスを取る必要があるということです。
Increaseing developer productivity...
AWS でコンテナを利用する顧客の 65 % が ECS を使用しています。
またそのうち 78% が、ECS on Fargate を選択しています。
そして、毎週 24 億の ECS タスクがバッチ実行されています。
Removing the operational burden
ECS on Fargate では、コントロールプレーンやデータプレーンの管理、パッチ適用が不要です。ネイティブに名前解決の仕組みを用意していたり、テナントの分離も用意です。
Deep service integrations
ECS on Fargate では、他のAWSサービスとの統合が容易です。これにより、運用の重荷を軽減することができます。例えば、Application Load Balancer (ALB) のヘルスチェックに失敗したECSタスクは、単にALBのターゲットグループから外されるだけでなく、その ECSタスクも削除されます。そして、新しいECS タスクが起動されて ALB ターゲットグループに追加されます。
他にも、ECR にコンテナイメージを push すると、Inspector が自動でスキャンします。
Account as a Service
Is Account as a Service right for me ?
各ワークロード用に１つのAWS アカウントを作成する方法です。
AWS アカウントレベルの制約やコストの分離といったメリットがある反面、標準化がしにくくトラブルシューティングに時間がかかります。
Platform as a Service
Building a Platform as a Service on Amazon ECS
インフラチームが ECS クラスターやサービス、RDS などのデータストアや CI/CD パイプライン、監視基盤を用意します。
開発者はコンテナイメージを作成します。
私の担当するお客様は、このパターンが多いと思います。
Build, run, and secure containerlized web and API workloads without managing the infrastructure
App Runner を使うと、WEB や API の実行基盤をインフラ管理せずに用意できます。
機械学習といったワークロードには向かないため、用途は限定的です。
Is Platform as a Service right for me ?
標準化された環境が用意されているので、開発者にとってデプロイが容易で迅速です。
一方で、インフラ担当者の負担が大きくなります。App Runner では用途が web など限定的になります。
Cluster as a Service
Is Cluster as a Service right for me ?
Cluster as a Service では、インフラ担当者が特定のリソース（VPC、ALB）を使用可能なECSクラスターを作成します。
開発者はそのクラスター内にサービスをデプロイします。
クラスターは分離性が高く、作成可能なサービスも柔軟性が高いです。
ただし、開発者が多少インフラの理解をする必要があります。
Template as a Service
How to define templates for Amazon ECS?
ワークロードのコードをインフラを含めて全てテンプレート化します。
Backstage.io
Backstage.io は、Spotifyによって開発されたオープンソースのプラットフォームです。
開発者が自分たちのソフトウェアインフラストラクチャを効率的に管理するためのツールです。
Backstageは、マイクロサービスやAPI、データパイプライン、クラウドリソースなど、さまざまなソフトウェアコンポーネントを一元的に可視化・管理できるダッシュボードを提供します。
ワークロードのコードをインフラを含めて全てテンプレート化している際の管理が容易になります。
オープンソース化しているので利用は無料のようです。
参考：
youtu.be
Is Template as a Service right for me ?
インフラ担当者が書いたテンプレートをもとに、開発者がすぐに開発を開始できます。
また、インフラ担当者は、テンプレートのメンテナンスをするのみです。
IaC を達成でます。
一方で、開発者がインフラのコードとも向き合うことになります。
また、様々なツールを使うため、インフラ担当者は開発者の ID 管理を行うタスクが増えます。
事例
Mission critical legacy application
35 万行の java コードを持つアプリを、3 年かけて 200 人で作成したそうです。
Leapfrogged traditional journey to Cloud Native
AWS 上に新システムを 1 年かけて 40 人で作成しました。
New system using ECS and adjacent services
会計士と技術者が完全な権限を持ち、開発者が独立してそれぞれにビルドを主導できるようになりました。
ECS on Fargate enables semaless compute at scale
ECS の自動スケーリングによって、65 %の時間が削減されました。
また、33 % のコスト削減ができました。
Business outcomes
ビジネスのリアルタイム性とスピード感が大きく上がりました。データ活用もできるようになりました。
まとめ
... as a Service の説明をもう一度、言葉を変えながら掲載します。
- 食材の袋（Account as a Service）: ワークロード用に１つのAWS アカウントを作成し開発者が利用します。隔離性・柔軟性は高いものの、標準化がしにくくトラブルシューティングに時間がかかります。開発者がインフラも含めて管理します。
- 家庭用ミールキット（Template as a Service）: ワークロードのコードをインフラを含めて全てテンプレート化します。インフラ担当者が最初のテンプレートを作成し、開発者がカスタマイズします。IaC を達成できる反面、開発者もインフラのコードに向き合うことになります。
- 冷凍ディナー（Cluster as a Service）: インフラ担当者が特定のリソース（VPC、ALB、RDS）を使用可能なECSクラスターを作成します。開発者はそのクラスター内にワークロードのサービスをデプロイします。開発者が ECS サービスや ALB などのインフラを理解する必要があります。
- シェフが準備した食事（Platform as a Service）: インフラチームが ECS クラスターやサービス、RDS などのデータストアや CI/CD パイプライン、監視基盤を用意します。開発者はコンテナイメージを作成します。
事例の紹介について、まとめます。
86年の歴史を持つFanny Maeは、現代の技術を取り入れつつも、レガシーチャレンジに直面していました。特に、巨大なローン会計システムは維持が困難で、開発者の経験にも悪影響を及ぼしていました。そのため、同社はクラウド移行の一環としてシステムをリファクタリングし、AWSのサービスとカスタムローコードプラットフォームを活用して、効率的で自動化されたシステムを構築しました。
新しいシステムは、ECS Fargateを使用して、何百万ものイベントを処理し、処理速度を65%向上させ、コストを33%削減しました。また、AWSの他のサービスともシームレスに統合され、セキュリティも強化されています。この取り組みは、開発者の体験を向上させ、ビジネスのニーズに迅速に対応する能力を向上させました。
私の感想
私は普段、ECS on Fargateを利用するお客様と関わることが多く、そのニーズに寄り添って対応しています。私の担当するお客様では、案件開始から1〜2ヶ月でサービスを開始することがあり、ECS on Fargateをスピーディに利用しています。
コンテナの特性として、メインプロセスが停止するとコンテナも停止します。これを利用して、ECSタスクをバッチ処理に使うと、処理が終わればコンテナが自動で停止し、効率的にコンピューティングリソースを利用できます。料金削減には、このコンテナ技術の利点も貢献しているようです。
また、ECS on Fargateの魅力は、AWSマネジメントコンソール上でほとんどの操作が行える点です。運用においては、コンテナ技術の基本だけ知っていれば、ECS on Fargateのクラスターやサービスの管理は簡単に理解できると思います。
さらに、ECS on FargateはAWSのAutoScaling、CloudWatch、GuardDutyなどと統合されており、パフォーマンス、監視、セキュリティを一定の水準で確保できます。加えて、ALBとのシームレスな統合や、CodeDeployによるCI/CD基盤の自動作成も大きな魅力です。
開発者とインフラ担当者の境界分離もしやすいので、DevOps がうまくいき、平和な空気が生まれることも多いです。
余談
伊豆トレイルジャーニーという、トレイルランニングの大会に出てきました。
トレランを始めた１年前から憧れていた大会で、70km 完走できて嬉しかったです。
寝不足から序盤で足を攣って、残り 50km 瀕死だったので、来年はベストパフォーマンスで頑張りたいです。
しっかり富士山も見えたのですが、必死だったので写真はこれしかありません。(笑)
