re:Invent 2024: AWSがECSを活用したプラットフォーム戦略を解説
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Unleashing the power of Amazon ECS for platform teams (SVS330)
この動画では、Amazon ECSを活用したプラットフォーム戦略の最適化について解説しています。Account as a Service、Platform as a Service、Cluster as a Service、Template as a Serviceという4つの異なるアプローチを詳しく説明し、それぞれの利点と課題を明確に示しています。特に注目すべき事例として、Fannie Maeが200人以上で3年かけて構築した巨大なローン会計システムを、Amazon ECSとTemplate as a Serviceアプローチを活用することで40人・1年で再構築し、処理時間を65%削減、コストを33%削減した成功例が紹介されています。また、Internal Developer Platform（IDP）の実装方法や、Backstage.ioを活用したプラットフォーム構築についても具体的に解説しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon ECSを活用したプラットフォーム戦略の概要
こんにちは。SV S3 30へようこそ。本日は、Amazon ECSがプラットフォーム戦略の最適化にどのように役立つかについてご説明させていただきます。ECSを始めようとお考えの方も、すでにご利用中でベストプラクティスをお求めの方も、どちらも対象としています。今日は、現在お客様が実際に活用している一般的なパターンについてご紹介していきます。私はJennifer Linです。そしてこちらがOlly Pomeroyです。本日は私たちがECSのエキスパートとしてご説明させていただきます。後ほど、Fannie MaeのMichael Leeにも加わっていただき、ECS導入における彼のチームの経験についてお話しいただく予定です。
それでは始めましょう。まず、Platform Teamという言葉から説明させていただきます。組織によっては、中央IT部門やCloud Center of Excellenceなど、異なる呼び方をされているかもしれません。通常、Platform Teamが必要となるのは、多くのアプリケーションチームが様々なAWSサービスを使用して数多くのアプリケーションに取り組んでいる場合です。こうしたサービスの組み合わせや例外的な使用が、組織内での乱雑な状況を生み出すことになります。
Platform Teamが話題に上がると、必ず「どのようなPlatform Teamになるべきか」という議論が生まれます。アプリケーションチームがDevOpsモデルで運用できる分散型を選び、チームが自身のインフラストラクチャをデプロイ・管理し、デプロイしたものに対して責任を持つ形にするのか。それとも、より集中型にして、チームの柔軟性は制限されるものの、ビジネス価値の創出とコーディングに集中できるようにするのか。実際には、これは二者択一というよりも、連続的なスペクトラムとして捉えるべきものです。
プラットフォームチームの役割と抽象化レベルの比喩
この概念を説明するために、食べ物を例に挙げてみましょう。左端には食材の袋があり、これはAWS APIを直接利用することを表しています。すべてにアクセスでき、レシピを選び、材料を洗って切り、すべての工程を自分で管理します。次にミールキットがあります。これは、ある程度の選択肢が事前に決められている状態です。正確に計量された材料が提供されますが、カスタマイズの余地は残されています。冷凍食品は、より準備の整った解決策を表しており、多くの作業が事前に完了していますが、デプロイに関してはまだ選択肢があります。最後にシェフの調理した食事があります。調理の詳細は分からないかもしれませんが、完全に管理された体験が得られます。
開発者の視点から見ると、左端の食材の袋のアプローチでは、開発者はAWSのすべてに触れることができ、所有権、柔軟性、透明性を求めることができます。右端では、開発者はソースコードを提供してデプロイを要求するだけの集中型モデルとなります。実際には、ほとんどのお客様は中間に位置しており、単一のパターンに固執するのではなく、複数のアプローチを組み合わせて使用していることが多いのです。
これらは通常、ブループリントの要求という形で現れます。インフラストラクチャをコード化したブループリントのように見えますが、インフラの詳細を知らなくてもアプリケーションを実行できるようにしたいというものです。アプリケーションの実行に必要なことを伝えるだけで済むようなモデルを提供できないでしょうか？ これから評価するパターンについて少しお話ししましょう。後ほど詳しく説明しますが、まずはなぜこのセッションがAmazon ECSについてなのか、そしてECSとは何かについてお話ししたいと思います。
Amazon ECSはElastic Container Serviceの略で、AWSが提供する独自のコンテナオーケストレーターです。コンテナを実行するコンピュートについては、いくつかの選択肢があります。EC2インスタンスを使用することもできますし、ECS Anywhereで自社のハードウェアを使用することもできますが、圧倒的多数のお客様がAWS Fargateを選択しています。Fargateはコンテナ向けのサーバーレスな従量課金型コンピュートです。お客様がFargateを好む理由は、EC2インスタンスを自前で使用する場合に必要となるオペレーティングシステム、パッチ適用、セキュリティアップデートなどを私たちが管理するからです。これらは差別化につながらない重労働であり、お客様から解放したいと考えています。
Amazon ECSの最新の統計をご紹介しましょう。 毎週240億以上のタスクを起動しています。 AWSの新規コンテナユーザーの65%以上がAmazon ECSを選択し、その大多数がAWS Fargateを選んでいます。ちなみに、Amazon ECSはAWSの基盤となるサービスと考えられており、新しいリージョンを立ち上げる際には、多くのサービスが私たちに依存し、その上に構築されているため、必ず最初に導入されるサービスの1つとなっています。
Amazon ECSの特徴と統合機能
Amazon ECSはコンテナプラットフォームとして優れた選択肢ですが、なぜPlatformチームにとって素晴らしい選択肢なのでしょうか？ その理由は、Amazon ECSの上に構築することは、すなわちAWSの上に構築することだと考えているからです。これは当たり前のように聞こえるかもしれませんが、私たちが意味しているのは、他のAWSサービスとの深い統合に本当に重点を置いているということです。コンテナ化されたアプリケーションにとって意味のあるAWSサービスがある場合、お客様がそれらのメリットを簡単に活用できるようにしたいと考えています。私たちは他のチームと協力して、AWSの他のサービスを活用する場を確実に提供しています。
少しお時間をいただいて、 これらの統合について説明させていただき、深い統合とは具体的にどのようなものかをご理解いただきたいと思います。まず、インフラストラクチャに関して、Amazon ECSの重要な特徴の1つは、管理すべきコントロールプレーンがないことです。維持、アップグレード、パッチ適用の必要はなく、私たちがお客様に代わってコントロールプレーンを実行します。AWS Fargateを選択した場合、データプレーンのパッチ適用とスケーリングも管理します。AWS Cloud Mapによるネイティブなサービスディスカバリーが組み込まれており、AWS Fargateによるテナント分離も提供しています。これは優れた組み込みのセキュリティ機能で、Fargateを使用することでEC2インスタンスの境界のメリットを得られます - 同じECSサービス内であっても、各タスクは独立したEC2インスタンスを取得します。
セキュリティについて考えると、私たちは主に、ほとんどのAWSサービスと同様に、制限や権限付与のメカニズムとしてIAMを使用しています。Amazon ECS内で利用可能なリソースについては、プラットフォームチームが制限したり許可したりする権限が適切なものになるよう、慎重に検討を重ねてきました。昨年のre:Inventでは、ランタイムの脅威保護のためのAmazon GuardDutyとの統合を発表し、これはECSのアカウントレベルまたはクラスターレベルで有効にすることができます。また今年初めには、VPC Flow Logsとの統合を発表しました。これにより、Flow Logのサブスクリプションを通じて、ECSクラスター、サービス、またはタスクに関するデータを追加できるため、ECSサービス内からそれらの呼び出しを行っているのが誰なのかを把握できるようになりました。
さらにいくつかの統合についてお話ししましょう。ワークロードによっては、ECSサービスがタスクを起動する最適な方法とは限らないため、アクションをトリガーできるAWS Step Functionsや、多数のタスクを一度に起動できるAWS Batchとも統合しています。また、Elastic Load Balancerとは常に非常に深い統合を維持してきました。コンソールから直接ターゲットグループを作成でき、ELBのヘルスチェックはスケジューリングの判断材料としても考慮されます。つまり、Application Load Balancerでヘルスチェックに失敗した場合、そのタスクは異常とみなされ、置き換えられることになります。
また、つい1週間ほど前にはAmazon VPC Latticeとの統合を発表し、今後はそのヘルスチェックも考慮されるようになります。そして昨日は、お客様から非常に好評をいただいているContainer Insightsの機能強化を発表しました。クラスターレベルで有効にすると、CloudWatchで自動的にダッシュボードが作成され、サービスやクラスターに関するメトリクスが取得できます。今回の機能強化により、タスクやコンテナに関するメトリクスも取得できるようになりました。
Account as a ServiceからPlatform as a Serviceまで：多様な抽象化レベル
開発者のニーズのスペクトラムと、そこで検討すべきオプションに話を戻しましょう。それぞれに名前を付けていきましょう。左側から始めて、Account as a Serviceについて説明します。 これは非常にわかりやすい概念なので、フレームワークを設定するのに使用しましょう。これらの名称は他の文脈でも使用されている可能性があり、やや意味が重複しているかもしれません。しかし、Amazon ECSのコンテキストでこれらを考え、皆さんの組織に適しているかどうかを判断できるよう、名前を付けることが目的です。
では、プラットフォームチームにとってのAccount as a Serviceとは何でしょうか？これはランディングゾーンを作成することを意味します。 AWSには、ランディングゾーンとは何か、そしてアカウントを開発者に引き渡す前に、アカウントレベルでどのようなセキュリティコントロール、IAMポリシー、制限を設定できるかについての豊富なドキュメントがあります。これにはAWS Control Towerを使用できます。また、Amazon ECS内にもアカウントレベルの設定があり、タグ付け、Container Insights、Amazon GuardDutyなどの統合機能をアカウントレベルで設定できるため、そのアカウントで起動されるすべてのECSサービスがこれらの機能を使用することを確実にできます。アプリケーションチームにとって、これは 開発責任と運用責任の両方を持ち、許可されたAPIにアクセスできることを意味します。
それでは、これらのパターンそれぞれについて、良い点と悪い点を見ていきましょう。緑色の虹の側では、開発者が完全な自律性を持ち、非常に幅広いワークロードタイプをサポートしています。Amazon ECSはロードバランス型のWebアプリケーションの実行に非常に優れていますが、制限を設けなければ、イベント駆動型やAIワークロード、あるいはキューやバックグラウンドワーカーからの処理など、あらゆる種類のワークロードを実行できます。これは抽象化のレベルを上げると柔軟性が下がるという原則に従っています。このパターンは最も低い抽象化レベルで、最も高い柔軟性を提供します。また、チーム間やワークロード間の完全な分離も実現できます。AWS Fargateで既に説明した分離境界に加えて、アカウントレベルでさらなる分離レベルが提供されます。もう1つの利点は、特定のチームやワークロードにコストを簡単に帰属させることができる点です。
ただし、考慮すべき点もあります。このモデルには標準化がほとんどないため、パターンを見つけることが非常に困難です。アプリケーションチームは特にトラブルシューティングに関して、その認知的負荷を負うことになります。これがAccount as a Serviceです。開発者が非常に積極的な場合など、一部の顧客やワークロードには非常に適していますが、ここでスペクトラムの反対側についてOllyに説明を譲りたいと思います。
ありがとうございます。私たちは今、一方の極から他方の極に移ります。ここではPlatform as a Serviceを見て、このパターンがAmazon ECSにどのように適合するかを検討します。冒頭でJenniferが使った比喩に戻ると、Platform as a Serviceはレストランで食事をするようなものだと言いました。開発者としては、何も準備する必要がなく、メニューから選ぶだけで料理が提供されるのです。アプリケーション開発に例えると、ソースコードを持ち込むだけで、それがどこでどのように実行されているかを気にする必要がありません。Platform as a Serviceには多くの定義があり、新しい用語ではありませんが、このプレゼンテーションに関連して整理すると、アプリケーションチームはアプリケーションの構築、ビジネスロジックの作成とコードの作業に専念するだけです。アプリケーションがどこで実行されるかについての知識は限られています。
実際、クラウドで実行されているのか、コンテナで実行されているのか、Amazon ECSで実行されているのかを知る必要はなく、ビジネスロジックに取り組むことだけに専念できます。プラットフォームチームはプラットフォームの構築と運用を担当し、開発者に限られた数のワークロードタイプ、つまりメニューを提供することが彼らの仕事です。
Amazon ECSではこれはどのように見えるでしょうか？ECS自体がPlatform as a Serviceだと言っているわけではありません。PaaSを構築するには追加のコンポーネントが必要です。しかし、先ほどJenniferが指摘したECSの主要な利点は、PaaSを構築する際に非常にうまく適合します。なぜなら、コントロールプレーンが管理されているため、プラットフォームチームの負担が少なく、データプレーンについても同様だからです。特にAWS Fargateを使用した場合のシングルテナンシーモデルにより、複数のアプリケーションチームが同じPaaSを利用する場合でも、AWS Fargateが各ワークロードを分離するため、セキュリティ境界について心配する必要がありません。
とはいえ、ECSをPaaSに変えるためには、Platform Teamは開発を始める必要があります。おそらく、開発チーム向けのフロントドアとして独自のAPIレイヤーやコンソールを構築し、さらにスタックの残りの部分を組み立てていくことになるでしょう。CI/CDパイプラインや監視機能を構築し、ワークロードの種類に応じてデータベースサービスなどの追加のAWSサービスと組み合わせることもあるでしょう。このようなモデルを採用したいものの、Platformの構築は避けたい場合、AWS App Runnerを検討してみるのもよいでしょう。
AWS App RunnerはECSの上に構築されており、PaaSに必要なコンポーネントの多くがマネージドサービスとして組み込まれています。開発者は引き続きアプリケーションの構築やビジネスロジックの記述に専念できますが、PaaSの運用負荷の多くがAWSに移管されます。AWS App Runnerは、APIやWebベースのワークロードに最適なサービスです。App Runnerは、Platformの運用に関する煩雑な作業の多くを担当します。開発者からコンテナイメージのビルドの負担を取り除きたい場合はApp Runnerがそれを担い、Layer 7ロードバランサーが統合されており、そのロードバランサーが受け取るリクエスト数に基づく自動スケーリング機能も備えています。さらに、ビルトインのパイプラインと監視機能も提供されています。
そのため、PaaSの方向性を検討している場合、特定のワークロードタイプに限定してでも、AWS App Runnerを検討してみることをお勧めします。PaaSの運用負荷の多くをAWSに移管できる方法を確認してみてください。では、PaaSは自分たちに適しているのでしょうか？Platform as a Serviceのスコアカードはどうなるでしょうか？まず良い点として、開発者は素早くデプロイでき、ビジネスロジックに集中できます。場合によってはアプリケーションをコンテナイメージとしてパッケージ化するだけで、他のすべては自動的に処理されます。認知負荷が軽減され、インフラストラクチャやAWSサービスについて学ぶ必要がありません。標準化されたワークロードタイプとパターンが得られ、すべてのアプリケーションが同じツールセットで同じ方法でデプロイされ、組織レベルでの標準化が実現します。さらに、AWS App Runnerを使用すると、Platformの運用負荷の多くをAWSに移管できます。
一方、デメリットとしては、Platform as a Serviceは通常、特定のワークロードタイプに限定されています。これは対象のワークロードタイプに適合する場合は素晴らしいのですが、開発者が新しい機械学習やトレーニングワークロードを持ち込んだ場合、追加のワークロードタイプをサポートするのは大きな負担となり、かなり制限的になる可能性があります。このモデルを採用する場合は、他のワークロードをデプロイするための代替手段やエスケープハッチが必要になるかもしれません。最後に、PaaSの構築と運用は負担になる可能性があります。特に多くのアプリケーションチームがオンボーディングする場合は、Platform Teamも相応にスケールする必要があるかもしれません。
Cluster as a Service：ECSリソースの責任分担モデル
それでは、Clusterについて話すためにJenniferにバトンタッチします。冒頭で述べたように、両極端な選択をする顧客は少なく、ほとんどの場合はスペクトラムの中間のどこかに位置し、これらのパターンの一部を組み合わせて利用しています。ここで何を話そうとしているのでしょうか？
それでは、Cluster as a Serviceについて、まだ触れていないAmazon ECSのリソースについてお話しします。 まず、使用するコンピュートの種類を定義する論理的なグループとしてのClusterがあります。次に、アプリケーション、アプリケーションのネットワーキング、デプロイ方法を記述するService - これが実際にアプリケーションの中核となります。そして、コンテナの定義であるTaskとTask Definitionがあります。これらのリソースを個別に分けることで、責任分担が可能になります。
Cluster as a Serviceと言う場合、実際にはプラットフォームチームがClusterを作成し、開発者に提供することを指します。「このCluster、このVPC、このLoad Balancerを使ってください」というように、開発者に代わって作成したものを提供するのです。開発者はServiceとTask Definitionを使って、それらを組み合わせてアプリケーションを構築できます。 このモデルでは、アプリケーションチームはAmazon ECSにデプロイしていることを認識しており、ServiceやTask Definition、それに付随するメトリクスにアクセスできるため、トラブルシューティングも可能です。
プラットフォームチーム側では、これらのClusterを作成して共有したり、チームやワークロードごとに独立したClusterを作成したりします。また、その前にガバナンスされたパイプラインを配置するオプションもあります。 視覚的に見ると、プラットフォームチームと開発者の区別がこのようになります。特に強調したいのは、右側の部分で、依然として責任共有モデルが存在することです。L7ロードバランシングなど、考慮すべき点があります。多くのチームは、開発者が独自にLoad Balancer用のセキュリティグループを作成することを望まないため、Load Balancerを作成してそのARNを開発者に提供し、開発者はそれをServiceに組み込むことになります。
CI/CDパイプラインについては、プラットフォームチームが設定し、開発者はそれを利用してコードをパイプラインにプッシュする必要があるかもしれません。セキュリティに関しては、トップレベルでAmazon GuardDutyを有効にできますが、パブリックサービスにするかプライベートサービスにするかは開発者の責任になる場合があります。可観測性については、トップレベルでContainer Insightsを有効にできますが、Task Definition内でロググループを設定する必要があるかもしれません。 Amazon ECS Clusterの特徴は、管理すべきコントロールプレーンがないため、多数のClusterを作成するオーバーヘッドが最小限で済むことです。100のチームがあって100の異なるClusterが必要な場合でも、それは可能です。
一部のマイクロサービスは何らかの境界や名前空間を共有し、相互に通信する必要があるため、それらも非常に簡単に共有できます。これがAmazon ECSの大きな利点です - 必要に応じて境界を簡単に作成できる単純さです。 このモデルでは、開発者はServiceとTask Definitionを完全にコントロールできるため、大きな自律性を持っています。しかし、プラットフォームチームが作成して提供する他のインフラストラクチャサービスについて考える必要がないため、認知負荷が軽減されています。また、ClusterレベルとAWS Fargateによって提供されるEC2インスタンス境界の両方から、テナント分離が組み込まれています。
一方で、開発者はタスク定義について学び、ロードバランサー用のターゲットグループの作成方法とそれをサービスに統合する方法を理解する必要があります。確かに認知的な負荷は存在しますが、その範囲は限定的です。 ここで、次のトピックについて説明するためにOllyに戻したいと思います。4つのパターンの最後は、Template as a Serviceです。先ほどの例えに戻りますと、これはミールキットのようなものです。開発者には作るものについてある程度の指示が与えられますが、実際にそれを作り、調理し、運用する作業は開発者自身が行うという考え方です。
Template as a Service：テンプレートを活用した開発者体験の向上
Template as a Serviceとは何でしょうか？まずプラットフォームチーム側から見ていきましょう。これは、プラットフォームチームがベストプラクティスやアーキテクチャパターン、設計をInfrastructure as Codeのテンプレートにパッケージ化するというものです。
プラットフォームチームは、特定のワークロードタイプやネイティブサービスを実行するための最適な方法を研究し、その知見をInfrastructure as Codeのテンプレートにパッケージ化する責任を負います。これにより、新しいベストプラクティスや機能、オプションが利用可能になった時点で、プラットフォームチームがこれらのテンプレートを改善していく分散型モデルが作られます。 アプリケーションチームは、これらのテンプレートを利用し、必要なものを選択して、デプロイし、運用します。
様々な顧客と話をする中で、組織によって開発者に何をどの程度公開し、どの程度の自律性を与えるかに応じて、このテンプレートの実装方法が異なることに気づきました。これらのテンプレートには複数の抽象化レベルが存在します。 基盤レベルでは、Amazon ECSサービスやVPCサブネット、セキュリティグループなどのAWSリソースを明示的にアプリケーションチームに公開することを好む組織もあります。プラットフォームチームは、適切なセキュリティグループ、ルーティングルール、ゲートウェイなどを含むベストプラクティスに基づいたVPC設定のAWS CloudFormationテンプレートを作成し、それをアプリケーションチームに提供します。これにより、アプリケーションチームはプラットフォームチームが承認したテンプレートを使用して、異なる環境で新しいVPCをデプロイできます。同様のアプローチはAWS CDKやTerraformを使用しても実装できます。
次の抽象化レベルは、プラットフォームチームがワークロードのデプロイに関する意見を持ち、基盤コンポーネントを抽象化し始める段階で現れます。彼らは、ロードバランス型のWebサービスやキューコンシューマーベースのサービスなど、ワークロード固有の高レベルモジュールやテンプレートを作成します。プラットフォームチームは、これらの基盤コンポーネントを高レベルテンプレートにまとめる作業をすべて処理します。AWSはAmazon ECS用のLayer 2 CDKモジュールを提供しており、Webベースのサービスやキューコンシューマーサービス用のモジュールを提供しています。あるいは、Terraformを使用して独自のワークロード固有モジュールを作成することもできます。
最後のオプションは最も高度な抽象化レベルを表しており、組織が独自のワークロード定義標準や仕様を作成するというものです。アプリケーションチームに対して、3つか4つ、あるいは5つのパラメータを含むJSONやYAMLファイルを作成するよう指示し、それがデプロイ時にパイプライン内のモジュールに展開されます。より多くの組織が、このようなモジュールやテンプレートを提供しながら、複雑さの多くを抽象化するアプローチを採用するようになってきています。このテンプレートモデルを通じて、開発者の認知負荷を効果的に軽減しているのです。
どのテンプレートを選択するにしても、それをアプリケーションチームにどのように配布するかという問題が生じます。さまざまな方法がありますが、 人気のあるアプローチの1つが、Internal Developer Platform（IDP）の実装です。internaldeveloperplatform.orgによると、IDPはプラットフォームチームによって構築され、ゴールデンパスを作成し、開発者のセルフサービスを可能にするものです。このアプローチにより、IDPを通じてアプリケーションチームにテンプレートを配布することができます。 これらのIDPには共通の特徴があります。その1つがRole-Based Access Controlで、アプリケーションチームがIDPを通じてプロビジョニングできるテンプレートやリソースを制限します。各アプリケーションチームは、自分たちのリソースにのみアクセスできます。プラットフォームはセルフサービスであるべきで、アプリケーションチームはプラットフォームチームの介入を常に必要とすることなく、ログインしたりAPIを使用したりしてテンプレートを利用し、リソースを確認できるようにする必要があります。新しいリソースをデプロイしたいときに、毎回プラットフォームチームを通す必要があってはいけません。
そのワークロードに合わせてテンプレートをカスタマイズできる設定可能性が必要です。これは、アプリケーションチームがサービス名やコンテナイメージ、環境変数を入力する、社内で開発されたワークロード仕様やワークロード定義を通じて実現できます。 また、IDPからデプロイメントパイプラインへの統合も必要で、IDPの1つの場所から進行中のデプロイメントを可視化し、追跡し、過去のデプロイメントのステータスを確認できるようにする必要があります。 さらに、これらのIDPが自動化をトリガーし、環境内にリソースをデプロイするというオーケストレーションのレベルも必要です。
多くのIDPツールが利用可能ですが、Backstage.ioが大きな勢いを得ています。BackstageはCloud Native Computing Foundation（CNCF）のインキュベーティングプロジェクトで、もともとSpotifyによって作成され、その後オープンソース化されてCNCFに寄贈され、現在は急速に発展しています。Backstageは開発者ポータルを構築するためのオープンソースフレームワークで、プラグインアーキテクチャを採用しています。 プロビジョニングされたリソースを発見するためのソフトウェアカタログ、プラットフォームチームが共有するソフトウェアテンプレート、組み込みのドキュメント、組み込みの検索機能などのコアモジュールを含んでいます。豊富なプラグインのエコシステムを通じてカスタマイズでき、組織に最適なIDPを作成することができます。
Backstageをソース管理、CDパイプライン、インフラストラクチャ、AWSサービスと統合することは理にかなっています。 BackstageのためのAWSサービスには、AWS CodePipeline、AWS CodeBuild、Amazon ECSのプラグインなどがあります。これらの統合により、アプリケーションチームはCI/CDのステータスを監視し、ECS内のリソースのステータスを確認することができます。 Backstage内では、ソフトウェアカタログでプロビジョニングされたリソースを表示でき、それらのリソースがタグを使用してECSでプロビジョニングされている場合、プロビジョニングされたリソースでBackstageを更新することができます。
チームがBackstageを使い始める際の支援として（最初は少し intimidatingかもしれませんが）、AWSはHarmonix on AWSというプロジェクトを立ち上げました。これは、AWSにおけるBackstageのリファレンス実装で、導入ガイダンスを提供し、多数のコミュニティプラグインがプリインストールされています。さらに、Amazon ECSやその他のサーバーレスサービス上の様々なワークロードタイプのテンプレートと共に、各アプリケーションチーム向けの環境を作成・提供するためのリファレンス実装も用意されています。
Template as a Serviceについて、スコアカードを確認してみましょう。 開発者は、どの抽象化レベルを選んだとしても、IDPからテンプレートを選んでデプロイするだけで素早く開始できます。 このモデルでは、プラットフォームチームはインフラの所有や運用に責任を持つのではなく、単にテンプレートを提供するだけなので、効率的にスケールすることができます。 インフラストラクチャ・アズ・コードにベストプラクティスを組み込むことで標準化を実現しつつも、必要に応じてテンプレート以外のリソースを作成したり、アプリケーションチームのニーズに合わせてカスタマイズしたりすることも可能です。
ただし、考慮すべきデメリットもあります。アプリケーションチームがインフラに触れることになるため、開発者がソースコードを提供するだけで実行環境を気にしなくて済むような Platform as a Service的な体験を望む場合には、このモデルは理想的ではありません。とはいえ、先ほど述べたように、アプローチを組み合わせることは可能です。
先ほど触れたように、組織によっては異なるアプリケーションチームに対して異なるモデルを選択することがあります。WebアプリやAPIワークロードにはPlatform as a Serviceを、その他のワークロードにはTemplate as a Serviceを採用するといった具合です。 そして最後の考慮点として、プラットフォームチームへの依存は依然として存在します。彼らはおそらくIDPの運用や保守、新しいプラグインの実装などを担当することになるでしょう。
Fannie Maeのケーススタディ：ECSを活用したローン会計システムの変革
このプレゼンテーションを通じて、私たちは抽象化のスペクトラムについて紹介してきました。 Amazon ECS上でプラットフォームを構築するさまざまな方法について説明してきました。正解は確かにありませんが、異なるアプローチや、様々な顧客で見られる一般的なパターンについて十分なイメージを提供できたと思います。それは、Account as a Serviceでアプリケーションチームにアカウントやランディングゾーンを提供するアプローチかもしれませんし、Template as a Serviceでプラットフォームチームがベストプラクティスをインフラストラクチャ・アズ・コードのテンプレートに組み込むアプローチかもしれません。あるいは、Cluster as a Serviceでプラットフォームチームがクラスターを提供し、Amazon ECSとAWS Fargateのテナンシーモデルを活用して各アプリケーションチームや各ワークロードに専用のクラスターを提供するアプローチ、さらには Platform as a Serviceで、プラットフォームチームがインフラの運用と実行を担い、開発者がソースコードとビジネスロジックに集中できるようにするアプローチもあります。
Amazon ECS、AWS Fargate、その他のAWSサービスを使用してFannie Maeがどのようにローン会計システムを変革したのか、そしてその理由について、とてもワクワクしながらお話しさせていただきます。また、AWSを活用したIDPの活用方法についてもご紹介できることを楽しみにしています。Fannie Maeでは、開発者のオンボーディングの加速化をはじめ、開発者の満足度（私たちが「Developer Joy」と呼んでいるもの）が大幅に向上し、さらに最も重要な点として、ステークホルダーのセルフサービス化を実現することができました。
私はMichael Leeです。Fannie Maeで財務、人事、気候変動関連の業務をサポートしています。 本題に入る前に、簡単な歴史的背景をお話しさせていただきます。Fannie MaeはワシントンDCに本社を置き、8,100人の従業員を擁しています。Fannie Maeは1938年に議会によって設立され、持ち家促進と手頃な価格の住宅供給を使命としています。いくつか印象的な数字をご紹介します。米国の住宅ローンの4件に1件を融資し、1,800万件以上のローンを管理し、4兆ドルの資産を保有しています。面白い事実として、米国最大、世界で5番目に大きいバランスシートを持っています。
ただし、重要なポイントとして、Fannie Maeは貸し手ではありません。私たちの役割は、貸し手からローンを購入して保証し、それらを住宅ローン担保証券にパッケージ化することで流動性を高めることです。これらは二次住宅ローン市場に流通し、最終的にはアクセシビリティ、手頃な価格、安定性という面で住宅市場を支えています。さらに、Fannie Maeはサステナビリティから手頃な価格の住宅やレンタルオプションまで、住宅に関するあらゆる分野でイノベーションとポジティブな変化を推進しています。
設立から86年を迎える、基本的にリスク管理プラットフォームであるこのミッションクリティカルな企業は、実に素晴らしい最新テクノロジーの上に構築されています。しかし、86年の歴史を持つ企業には必然的にレガシーな課題があり、今日はその一つについてお話しします。それは、200人以上の人員と3年以上の期間を要して構築された巨大なローン会計システムで、最終的に当社の巨大なバランスシートの90%を管理する巨大アプリケーションとなりました。その規模は途方もなく、10,000の計算処理と5,000のビジネスルールを含んでいます。さらに、毎月2億件の会計イベントを処理するという時間との戦いを続けています。その一方で、35万行のJavaコードと重いETL（抽出、変換、ロード）プロセスで構築された、いわば時代遅れの重い足かせを背負って走っているような状態でした。
このレガシーアプリケーションには、直感的でないサイロに埋め込まれた依存関係のあるビジネスルールも存在していました。500以上のテーブルを持つデータベース規模で、70以上のシステムとインターフェースを持っています。
Fannie Maeは、インフラストラクチャーとカスタマイズの課題により、サイロ化と開発者体験の低下というティッピングポイントに達していました。私のポートフォリオには、開発者の喜びがほとんど見られませんでした。また、一貫性のないデザインパターンによって断片化した環境は、毎月のメンテナンスを悪夢のようなものにする技術的な混乱も抱えていました。最も重要なのは、私の大切な会計担当者たちが、労力のかかるプロセスに苦心し、認知負荷が増大するという手作業の混乱に直面していたことです。
ビジネス部門と緊密に協力し、クラウドジャーニーの一環として決断を下しました。単純な再ホスティングではなく、AWSの長期的なメリットとカスタムビルドのLow Codeプラットフォームを目指してリファクタリングを選択しました。クラウドネイティブの魔法としか言いようがありませんが、私たちはAWSサービスとコスト効率の高いサービスを活用して、40人で1年という期間で完全に機能するシステムを構築しました。ECS Template as a Serviceは私たちにとって大きな成功でした。なぜなら、標準化されたIDPを実現し、専任のインフラチームではなく、権限を与えられた開発チームによるシステム実装を可能にしたからです。
私たちのLow Codeエンジンは大きな推進力となりました。要件の収集、モデリング、検証を行い、手作業による開発なしでNode.jsコードを自動生成できるようになったからです。コード行数を22%削減し、システムパフォーマンスを65%向上させ、現在では90%のコードが自動生成されています。最も素晴らしいのは、私の会計担当者たちがこれを気に入っていることです - テクノロジーコストを33%削減できました。
新しい会計システムは、ECS Template as a Serviceの設計とサーバーレスなFargateコンテナの力を活用しています。 この統合されたテクノロジースタックは、高い再利用性を持つ設計のIDPとして機能し、ETLアウトバウンドデータフレームワーク、コアエンジン、そしてIDP内の様々なユーティリティに最適です。Terraformテンプレートは、ECSやその他の標準的なインフラストラクチャーをプロビジョニングし、AWS Service Catalogは組織の標準への一貫性とコンプライアンスを確保します。
ECSの素晴らしい点は、会計エンジンのトランザクションデータベースの中核となるAurora PostgreSQLとシームレスに統合できることです。また、ECSは上流システムからのインバウンドデータと下流システムへのアウトバウンドデータの両方を管理するS3ファイルストレージとも統合されています。 私たちのシステムは最終的にAWSとECSを活用することで、真に素晴らしい自動化されたオーケストレーションと堅牢なイベントドリブンアーキテクチャを実現しています。AWS Step Functionsがプロセス全体をオーケストレーションし、Lambda、EventBridge、SQSがイベントドリブンパターンを促進してFargateタスクを開始し、CloudWatchが可観測性を提供して例外のリアルタイム通知を可能にしています。
このシステムにおいて、Personaは重要な役割を果たしています。当初の設計では、私にとって開発者体験が重要だったため、開発者を中心に据えました。ECSによって開発者は、専任のプラットフォームチームのサポートを必要とせずに、独自にビルドを主導できるようになりました。
KPMGが開発したカスタムLow Codeエンジンは、ビジネスロジックを機能テーブルとして作成し、データをモデル化し、サンプルデータで検証し、Node.jsのJavaScriptコードを生成する作業を支援してくれました。これらはすべて、標準化されたGitLab Terraformパイプラインを使用してデプロイすることができました。
このような権限委譲により、ビジネスステークホルダーに主導権が戻り、会計担当者とテクニカルチームが今ではこのシステムの完全な所有権を持っています。彼らはシステムのコスト、構築、運用に責任を持っています。先ほど申し上げたように、毎月の会計締めの重要な時期には、何億ものイベントを処理しています。ECSは、オンデマンドで高性能かつスケーラブルなFargateを提供します。エンジンを実行する際には、128個のFargateタスクを起動し、並列処理のために900個のNode.jsワーカーを一斉に立ち上げます。
私たちのデータベースは128個のハッシュパーティションに分割されています。各Fargateタスクは、データベースの競合なしに、それぞれ独立したセクションで動作してこのプロセスを開始します。イベントがLambda関数をトリガーし、2段階のプロセスが実行されます。まず、128個のデータベースパーティション全体にデータを展開するためにSQSに投入し、次にLambda関数がFargateタスクを開始します。処理が完了すると、コンテナは自動的にシャットダウンされ、システムは月の特定の時期にのみ稼働するため、コストが削減されます。
では、これらすべての取り組みの大きな成果は何でしょうか？ ECSとFargateにより、私たちの会計システムは何億ものイベントを処理できるようにスケールアップし、処理速度を65%向上させ、さらにスケールダウンしてコストを3分の1以上削減することができました。そしてこれはまだ終わりではありません - 実際にはもっと改善できる余地があります。また、ECSとFargateが、隣接するAWSサービスとシームレスに統合された、応答性の高いEvent-Driven Architectureをサポートしていることも確認できました。
これは私の好きな部分です。というのも、Fannie Maeはミッションクリティカルな観点から、私たちが行うことの範囲について非常に慎重だからです。私たちは包括的なセキュリティ対策を組み込んでいます。ECSとFargateを通じたガードレールとセキュリティポリシーは、Cloud Center of Excellenceによって強化・実施されています。これは、機能ロジックの効率的な管理とガバナンスのために構築した低コードエンジンによってさらにサポートされています。IAMを活用した高度なアイデンティティとアクセス管理も実施しています。最小権限の原則に従い、ユーザーやサービスには必要な権限のみを付与することで、セキュリティリスクと誤用の可能性を大幅に軽減しています。
新しいローン会計システムは、ビジネスにも恩恵をもたらしています。処理時間が65%削減されたことは、継続的な会計処理を可能にする重要な要素となり、財務取引のリアルタイム処理によってデータが常に最新かつ即座に利用可能な状態を確保しています。実績から予測までの時間が短ければ短いほど、最終的には全員にとって良い結果となります。AWS ECS、その他のサービス、そして私たちの低コードエンジンにより、ビジネスステークホルダーの進化するニーズに素早く対応して変更を加えることができます。データは今や、より高い精度とアクセシビリティで、ビジネス全体にとってより迅速に利用可能となっています。
OllyとJenに戻す前に、彼らはAbstraction Spectrumについて多く語りましたが、Fannie Maeは Template as a Serviceを効果的に活用した一例に過ぎません。その前に、Developer ExperienceとDev Joyの重要性について一言申し上げたいと思います。一つアドバイスをさせていただくとすれば、それは：誰もが話題にするツールと、誰も使わないツールがあるということです。開発者が声を上げないのであれば、それは一つのサインです。ありがとうございました。Olly、お返しします。
セッションのまとめと追加リソースの案内
Michael、ありがとうございました。Fannie MaeがイベントドリブンのワークロードにECSをどのように活用しているかについて、素晴らしいケーススタディを聞かせていただきました。処理時間65%削減、コスト33%削減 - コンテナ使用における実践的なビジネスメトリクスですね。本セッションにご参加いただき、ありがとうございました。スライドのコピー、BackstageのPluginへのリンク、 Harmonixへのリンクなど、追加リソースはすべてランディングページに用意してあります。QRコードをスキャンしていただければ、それらすべてにアクセスできます。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion