re:Invent 2025: Amazon ECSで実現する開発者プラットフォーム構築とGoDaddyの事例

はじめに

海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！

re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください

📖re:Invent 2025: AWS re:Invent 2025 - From code to cloud: Accelerate application development with Amazon ECS (CNS341)

この動画では、Amazon ECSを活用した開発者プラットフォームの構築について解説しています。ECSの特徴として、フルマネージドでバージョンレスなコントロールプレーン、Fargateによるサーバーレス実行、新たに登場したECS Managed Instancesが紹介されます。プラットフォーム設計の3原則として、ライフサイクル管理、規模の経済、break glass proceduresが示され、抽象化とcompositionのバランスの重要性が議論されます。新機能のAmazon ECS Express Modeは、コンテナイメージと2つのIAMロールだけで高可用性なサービスを構築でき、Application Load Balancerの自動共有やスケーリング、CloudFormationテンプレートの大幅な簡素化を実現します。GoDaddyのKeith氏は、2000人以上のエンジニアを支えるKatanaプラットフォームの実例を紹介し、統合ダッシュボード、生成AIサポート、柔軟なエスケープハッチの実装について詳述しています。

https://www.youtube.com/watch?v=Ns88rkEvhTE
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。

本編

Amazon ECSの紹介：フルマネージドコンテナオーケストレーションサービスの基礎

こちらはCNS 341です。AWSでコードをより速くデプロイする方法を探している開発者の方、正しい場所にいらっしゃいます。また、チームを加速させるためのパターンやガイダンスを探しているプラットフォームチームやインフラストラクチャエンジニアの方も、正しい場所にいらっしゃいます。私の名前はJenniferです。こちらはTsahiです。本日、私たちがECSのエキスパートを務めさせていただきます。また、少し後にKeithも加わります。彼はGoDaddyの方で、Amazon ECS上にプラットフォームを構築されており、それについてお話しいただきます。皆さん、ありがとうございます。それでは、始めましょう。

まず、コンテキストを設定するために、本日お話しするサービスの基礎を説明したいと思います。それはAmazon ECSです。 Amazon ECSは、組織がAWS上でコンテナ化されたアプリケーションを構築、デプロイ、管理するための最も簡単な方法を提供する、フルマネージドのコンテナオーケストレーションサービスです。コンピュートレイヤーとしても、多くの柔軟性を提供しています。EC2インスタンス上でコンテナを実行できます。ECS Anywhereを使えば、ご自身のハードウェア上でも実行できます。しかし、お客様の大多数はAWS Fargate上で実行されています。Fargateはサーバーレスで究極のシンプルさを提供します。私たちがコンピュートを完全に管理します。使った分だけお支払いいただくので、EC2インスタンスサイズの比率に縛られることはありません。

ECS Managed Instancesは、先月リリースしたばかりの新しい提供形態で、 非常に幅広いEC2インスタンスサイズへのアクセスを提供しながら、インフラストラクチャ管理を排除するフルマネージドコンピュートです。 これは、GPUやネットワーク最適化インスタンス、メモリ最適化インスタンスなど、特定のEC2インスタンスをお探しの場合に最適で、同時に、メンテナンスやパッチ適用、スケーリングなど、私たちが対応するFargateの優れた側面を活用できます。ECS Managed Instancesは、その特定性が必要でありながら、ECSに運用負荷を任せたい場合に最適なオプションです。

運用負荷を取り除くというテーマを続けますと、ECSを本当にユニークにしているのは、フルマネージドでバージョンレスであることです。 管理すべきコントロールプレーンはありません。コントロールプレーンのアップグレードを調整する必要も、コントロールプレーンのパッチ適用をスケジュールする必要もありません。私たちがその運用上の複雑さをすべて処理します。これは今週一週間、お客様から聞いていることですが、ECSを本当に愛している理由の一つは、私たちが彼らに代わって多くのことを処理しているからです。

クラスターを作成するとき、それは本質的には論理的なグループ化に過ぎません。大切に扱わなければならない何かではないのです。好きなだけクラスターを作成でき、サービスをグループ化するために好きなように使用できます。なぜなら、私たちがコントロールプレーンを管理しているので、それについて考える必要がないからです。そして、FargateやManaged Instancesを使用している場合、サーバーをプロビジョニングしたりスケールしたりする必要はありません。オペレーティングシステムを管理したりパッチを適用したりする必要もありません。私たちがそのすべてを皆さんに代わって管理します。

そして特にFargateでは、テナント分離が実現できます。これは金融サービスのお客様に特に好評なんですが、その理由はセキュリティ境界がコンテナではなくEC2インスタンスになるからです。Fargateでは、すべてのタスクが固有のEC2インスタンスを取得します。これはECS Managed Instancesでも実現できますが、その場合、Managed Instancesの価値の一部と、私たちが提供しているビンパッキングや基盤となるインスタンスのスケーリングといった最適化の恩恵を失うことになります。

そして次に、私たちがECSにネイティブで組み込んだ機能についてお話しします。まず最初がネイティブのサービスディスカバリーです。これはECSにある機能の中で過小評価されているように感じています。私たちはサービスディスカバリーとサービスメッシュを組み込んでいて、それがService Connectという名前のサービスです。Service Connectをインストールしたり、パッチを当てたり、メンテナンスしたりする必要はありません。ただそこにあって、使えるようになっているんです。すべてのサービスにアクセスするための統一された方法があります。DNSを維持したり、複雑な管理をしたりする必要はありません。いつでもセットアップしてアクセスできるようになっています。

最後に、ネイティブのデプロイメントメカニズムです。ECSには常にデプロイメントメカニズムがありました。ローリングデプロイメントメカニズムを使ってサービスを更新することは常に可能でしたが、多くのお客様がECSの外部に出て、例えばCodeDeployを使ってblue-greenを行うといった、他の外部デプロイメント戦略を使っていることがわかりました。

そこで、この夏にネイティブのblue-green戦略をリリースし、約1ヶ月前にはCanaryとLinear戦略をリリースしました。すべてECS内でネイティブに実現しています。これが本当に重要なのは、ECSにネイティブにすることで、デプロイメント戦略をセットアップするためにECSの外に出なければならないという負担を取り除いているだけでなく、blue側とgreen側をセットアップするためのターゲットグループの配線もすべてECS内に存在するため、それぞれのデプロイメントがずっとシンプルになるからです。

さて、これらすべてを合わせたものが、今日お客様がECSを採用する大きな理由なんです。そしてECSを採用すると、非常に良い仲間に加わることになります。毎週30億以上のタスクがECSで起動されています。すべての新規AWSコンテナのお客様の65%以上がAmazon ECSを使用しており、Amazon内部でも非常に多く使われています。実際、私たちはAmazon ECSを基盤サービスの1つと呼んでいます。そう呼ぶ理由は、AWSで新しいリージョンを立ち上げるたびに、ECSが最初に導入されなければならないサービスの1つだからです。その理由は、非常に多くの他のAWSサービスがECSを使ってインフラストラクチャを構築しているからです。ですから、ECSを使っているということは、良い仲間に加わっているということなんです。

アプリケーションデプロイメントの複雑性と開発者プラットフォームの必要性

それでは、今日お話しするサービスについて少しご紹介しました。ここからはTsahiにバトンタッチして、アプリケーションについてお話しします。ありがとう、Jen。セッションの次のパートでは、実際にアプリを本番環境にデプロイする際の実際の様子についてカバーしていきます。ですが、その前に、デプロイメカニズムがどのように機能するのかを理解する必要があります。また、2つの視点を切り替えながら進めていきます。1つは開発チームの視点、つまりアプリを構築し、本番環境にデプロイする人たちの視点です。そしてもう1つはプラットフォームビルダーの視点、つまり開発チームの仕事を楽にするためにツールや自動化を構築している人たちの視点です。

それでは、開発者の視点からデプロイメントプロセスを見ていきましょう。コンテナイメージをパッケージ化してAmazon ECRに構築した時点から、それを本番環境にデプロイするプロセスは非常に複雑で、多くの異なるステップが含まれます。このスライドでそれをカバーしていきます。まずネットワーキングが必要です。つまりAWS VPC、そしてプロビジョニングするAmazon ECSクラスターが必要で、これが基本的にすべてのアプリケーションを保持します。次に、ECSにアプリの構成が何であるかを伝える方法が必要で、それをECSタスク定義を通じて行います。それがそれを行うためのメカニズムです。

そして、アプリを公開する一般的なパターンは、通常ロードバランサー、Application Load Balancerを通じて行われます。それを行うためには、安全に行う必要があります。証明書が必要です。それを確実に用意する必要があり、そしてALB自体とそのすべてのリソース、つまりターゲットグループ、リスナールール、ルーティング設定などと統合する必要があります。そしてちょうど今、これらすべてを統合し、ECSサービスを作成できるポイントに到達しました。これは基本的にタスク定義を取得し、このタスクの複数のインスタンスを作成し、それらをALBと統合し、アプリを外部に公開します。

しかし、私たちのアプリは静的なエンティティではありません。もちろん、オートスケーリングポリシーを配置する必要があります。それに対処する必要があります。そして、時間の経過とともにアプリを運用し保守するためには、それを観測できる必要があります。つまり、ログ、トレース、メトリクスをオブザーバビリティサービスに送信する必要があります。私たちの場合はAmazon CloudWatchで、ECSと統合されているContainer Insightsを使えば簡単に実行できます。

さて、この複雑なプロセスはすべて単一のアプリのためだけのものです。視点を反転させて、プラットフォームビルダーから見ると、他にもいくつかの課題があります。プラットフォームチームビルダーがサポートする必要がある多くの異なる開発チームがあります。それぞれが独自のアプリケーションと異なる要件を持っています。そして、たとえコンピュートレイヤーで標準化したとしても、例えばAmazon ECSでリソースをプロビジョニングすることで標準化したとしても、異なるアプリごとに異なるバッキングサービスが必要になる可能性があります。例えば、S3バケットが必要なものもあれば、DynamoDBテーブルが必要なものもあり、それを組織全体でスケールできる必要があります。つまり、単一のアプリをどうデプロイするかだけでなく、異なるチームのすべての要件がどのように満たされるかを確実にすることが重要なのです。

優秀なエンジニアがそうするように、私たちは通常、物事を自動化します。

自動化と聞くと、おそらく開発者プラットフォームの構築を思い浮かべるでしょう。開発者がタスクをより簡単に完了できるようにするツール、プラットフォームを構築する必要があります。さて、組織内の他のシステムやアプリと同様に、それには設計原則が必要です。今日は、開発者プラットフォームを構築するための3つの重要な設計原則について説明したいと思います。それらは、ライフサイクル管理、規模の経済、そしてbreak glass proceduresです。では、それぞれについて詳しく見ていきましょう。

開発者プラットフォーム構築の3つの設計原則：ライフサイクル管理、規模の経済、break glass procedures

ライフサイクル管理とは、アプリのデプロイメントのライフサイクル全体を、作成から更新、そして廃止に至るまで所有することを意味します。これは単にアプリをどのようにデプロイするかということだけでなく、更新やアップグレードを通じて時間をかけて維持していくことも含まれます。また、開発者がシステムと対話できるようにするための何らかのエントリーポイントも含まれており、これはAPIやCLI、あるいは次のパートで説明するテンプレートのコレクションなど、何でも構いません。

規模の経済とは、リソースを賢く使うことです。必要のないものをプロビジョニングせず、時間をかけて物事を再利用するようにしてください。これは、前の例のようにリソースを再利用することを意味します。Application Load Balancerがある場合、別のアプリ、2つ目のアプリを公開するために別のALBをプロビジョニングする必要はありません。異なるルーティング設定で同じALBを再利用できます。

また、共有リソースを設定する必要があります。つまり、クラスター、VPC設定、モニタリングダッシュボードなどです。これらすべてを、異なるアプリ全体で共有する必要があります。実際には、各アプリごとに物事を複製するアプローチと、作成するすべてのものが相互接続されている複雑さを避けることとの間でバランスを取ることが重要です。システム内にリソースの混乱を招く可能性があります。

そして最後のもの、これが最も重要だと思うのですが、break glass proceduresです。これはあなたの脱出口です。どんなプラットフォームも、最初からすべてのユースケースに完璧に対応することはできませんし、たとえ成熟してより多くの機能を導入したとしても、すべてのデプロイメントのすべての要件を満たすことはできません。ですから、ユーザー、つまり開発者に、プラットフォームの提供物の間を移行しやすい方法を提供する必要があります。もし彼らがあるデプロイメント方法を使っているなら、将来的にプラットフォーム内の他のデプロイメント方法へ移行したり移動したりできるようにしたいわけです。

また、プラットフォームの機能を拡張できるようにしたいと考えています。プラットフォームが何かをサポートしていない場合、彼ら自身のカスタマイズされたツール、スクリプト、その他何でも使って拡張できるようにするということです。そして最後は、将来的にリソースを自己管理することについてです。多くのお客様で見てきたケースですが、ユーザーが非常に特定の要件を持つようになり、プラットフォームがそれを提供できない段階に達したために、自己管理リソースを採用する必要がある場合があります。プラットフォームから再デプロイして移行するのではなく、それらのリソースを自己管理できる必要があります。ユーザーがプラットフォームの制限に閉じ込められていると感じてほしくないのです。

抽象化とコンポジション：プラットフォームインターフェース設計の哲学的考察

そしてこれは哲学的な質問につながります。これはプラットフォームチームと開発者チームの間で継続的に議論されているもので、プラットフォームインターフェースをどう設計するかということです。抽象化を使うべきでしょうか、これは基盤となるコンポーネントの実装を隠すものです。それとも合成を使うべきでしょうか、これはデフォルト設定でリソースを組み合わせつつ、基盤となる実装をユーザーに公開するものです。あるいは、両方を混ぜて使うべきでしょうか？

そして何を選ぶにしても、基本的にはユーザーがシステムで何が起こっているかを理解する方法に影響を与えます。実際には、何が起こっているか、つまり内部でどう動いているかを理解することと、ユーザーの目標を達成すること、つまり私たちの場合はコードからクラウドへ到達することのバランスなのです。では、それぞれについて深く掘り下げていきましょう。

抽象化では、ユーザーは内部で何が起こっているかを知る必要がありません。実装の決定から解放され、必要なものを非常に素早く簡単に始めることができます。これにはいくつかの利点があります。例えば、参入障壁が非常に低いということです。ユーザーがAWSのエキスパートである必要はありません。プラットフォームを立ち上げて使うだけで、自分のリソースをデプロイできます。また、組織全体で一貫性が保証されます。全員が同じパターンを使い、全員が同じデプロイメントメカニズムを使うので、何が起こっているかを理解しやすくなります。この場合、ライフサイクル管理は通常APIを通じて公開されますが、これはプラットフォームとやり取りするより簡単な方法です。

しかし、いくつかの課題も伴います。

私たちはplatform teamに新しい機能のprovisioningや取得を依存しています。platformの機能を拡張する必要があるときはいつでも、platform teamがこれを構築してplatformと統合するのを待つ必要があります。また、問題が発生したときにも課題が生じます。エラーが発生してデバッグや調査が必要になると、結局、基盤となるリソースが実際に何であるかを理解し、実際の設定を掘り下げることになり、これではエントリーの障壁を下げるという目的が台無しになってしまいます。これも考慮すべき点ですし、メンテナンスの労力も高くなります。これは他のアプリと同じようなシステムであり、アップデート、アップグレード、運用効率を含めて、時間をかけてメンテナンスしていく必要があります。つまり実際には、始めるのは簡単ですが、進化はplatform teamsによってボトルネックになるということです。

一方、Compositionは異なります。これはセットアップを自動化しながらも、すべてをユーザーに見えるようにしておくことです。その良い点は、開発者がplatformが提供するものの一部を使って、必要な結果を得られることです。彼らは非常に素早く適応でき、platformが提供するものを自由に切り分けて、本番環境にデプロイできます。柔軟性もここではプラスになります。なぜなら、必要な結果を得るために、テンプレートやツールを調整できるからです。そして、見たものがそのまま得られます。隠し事はなく、裏側に隠された実装もないので、何かを確認したり更新したりする必要があるときは、簡単にできます。

しかし、これにはいくつかの別の課題があります。より急な学習曲線が必要になります。エキスパートである必要はありませんが、操作しているドメインに関するドメイン知識が必要です。例えば、私たちのケースでは、開発者はAmazon ECSの概念、例えばECS clusterやApplication Load Balancerなどを理解する必要があります。また、デプロイメントに関する断片化も生じます。各チームが独自のデプロイメント方法をカスタマイズできるため、それぞれが異なる方法でデプロイすることになり、私たちのplatformの観点からは、組織全体で管理するのが難しくなる可能性があります。

そして最後に、ライフサイクル管理についてですが、これは難しくなる可能性があります。特にテンプレートについて話すとき、組織全体でこれをスケールさせるのが難しくなる可能性があります。つまり、ここでのトレードオフは、ユーザーにより多くのドメイン知識を要求することですが、チームは独立して進化できるということです。これら2つのアプローチをまとめると、それらをブレンドできたら素晴らしいでしょう。つまり、始めるのをより簡単にしながらも、実装の詳細を最初から隠さないようにする。何かを更新する必要があるときでも、それができるようにするということです。

理想的なデプロイメント体験：シンプルさと柔軟性のバランス

それでは、最初に始めた時と同じエントリーポイントを見てみましょう。アプリがデプロイされ、Amazon ECRにパッケージ化されてデプロイの準備ができている状態です。もしシンプルに始められる方法を提供できたら、つまり、いくつかのパラメータだけを必要とする非常に軽量なインターフェースで、それ以上は不要だけれども、ライフサイクル管理が付いてくるとしたら、何かを更新するたびに、このサービスがライフサイクル操作全体を制御してくれます。そしてその結果、前のスライドで見ていただいたすべてのもの、つまりクラスター、VPC設定、ロードバランサー、Application Load Balancer、そしてAmazon CloudWatchとの統合、これらすべてをプロビジョニングしますが、これらはすべてユーザーに対して可視化されています。

そして、組織内に別のアプリがある場合は、自動的に同じデプロイメカニズムを使用し、すでにプロビジョニングした同じリソースを統合して再利用します。このアプローチは、始めるために必要な知識レベルと、将来的に変更を加える柔軟性とのバランスを取っています。このセッションの次のパートでは、Jenが、Amazonがこれらすべてを実現するためにどのように支援できるかをカバーします。

Amazon ECS Express Modeの発表：3つのパラメータで始める新しいデプロイメント体験

ありがとうございます、Zahi。本日、Amazon ECS Express Modeをご紹介できることを大変光栄に思います。この機能は先週導入したばかりで、開発者の皆さんがECSをまったく新しい方法で体験できるように作りました。Zahiが今お話しした、ECSが長年のプラットフォーム経験から学んだすべてのことを活用しています。そして、その知識をユーザーの皆さんに提供することで、アプリケーションをより速く立ち上げることができるようになります。

私たちは、Amazonのすべてのアプリケーションや製品で行っているように始めました。お客様から逆算して作業を進めたのです。そして、ほとんどのECSのお客様が、本当に繰り返し可能なパターンを実装していることがわかりました。Tsahiが先ほど示していたのと同じものです。しかし、そのパターンの多くはECSの外に存在していました。ロードバランサー、オートスケーリング、ドメイン名、証明書、ネットワーキング、オブザーバビリティといった他のAWSサービスが含まれていました。そこで私たちは自問しました。ECSが最も得意とすることを行い、お客様からその負担を取り除くことができないだろうか？より多くの責任を引き受けることができないだろうか？

私たちが何をしたかお見せしましょう。Amazon ECS Express Modeでアプリを作成するには、3つのものだけを提供していただく必要があります。コンテナイメージと2つのIAMロールです。それ以外のすべてについてはデフォルトを使用しますが、追加の設定も利用可能です。デプロイが完了するとすぐに、アプリケーションURLが取得でき、そのURLによってアプリケーションをエンドツーエンドでテストできます。これらのオプションを使用してアプリケーションを設定することができ、すべてのオプションが何であるかについては、すぐに説明します。しかし、これらは、私が今画面に表示しているプロビジョニングしているすべてのリソースで設定する必要があった数百のパラメータと比較して、大幅に削減されています。

Express Modeは、AWS のベストプラクティスを使用して、高可用性でスケーラブルなコンテナ化されたサービスを立ち上げるために必要なすべてのリソースをプロビジョニングします。これには、カナリアデプロイメント、アラームベースのロールバック、TLS証明書、オートスケーリングポリシー、CloudWatchロギング、アベイラビリティーゾーンのリバランシング、そして最小限の許可を持つインバウンドセキュリティグループなどが含まれており、これらすべてが設定され、連携するように配線されているので、始めるにあたって考える必要がありません。そして、このデプロイメントの最後には、ライブアプリケーションが完成しています。コマンドラインビューも同様に非常にシンプルです：1つのコンテナ、2つのIAMロールです。

最初のIAMロールはタスク実行ロールで、ECSに詳しい方ならご存知だと思いますが、これはAmazon ECRからコンテナイメージを取得し、ロギングをセットアップするために使用するものです。2つ目は新しいものです。これはインフラストラクチャロールで、右側のすべてのリソースをプロビジョニングするために使用します。そして、どのようにしてこのアーキテクチャと選択したデフォルト設定に至ったのか、疑問に思われるかもしれません。私たちはいくつかのことのバランスを取ろうとしていました。

1つは、AWSではデータを大切にしています。そこで、お客様が現在何を設定しているかを調べたところ、これは非常に一般的なパターンでした。お客様は個別のタスクではなく、サービスを設定していました。他のタイプのネットワーキングではなく、ロードバランサーを接続していました。2つ目は、ベストプラクティスを調べ、プリンシパルエンジニアやソリューションアーキテクトと話をしました。本当に難しい会話、白熱した議論をたくさん行い、開発ワークロードやテストワークロードで素早く始められるようお客様を支援することと、長期的にも準備が整っていることを確認することの間で、どのようにバランスを取るかを検討しました。

なぜなら、本番ワークロードを実行するために必要なものによって過度な負担をかけない場所にすることを確実にしたいと同時に、本番ワークロードを実行するためのすべてが整っていることを知った上で始められる場所にもしたいからです。ですから、必要なすべてのサブネットとすべてのアベイラビリティーゾーンをセットアップし、アベイラビリティーゾーンのリバランシングをオンにして、準備ができたら希望するカウントを3に増やすだけで、3つのアベイラビリティーゾーンで高可用性を実現できるようにしています。しかし、最初は1つから始めるので、多数のタスクやそれらすべてのコストに対処する方法に悩まされることはありません。これらすべては、物事を本当にシンプルで簡単に始められるようにすることを中心に構築されています。

Express Modeの完全なライフサイクル管理とInfrastructure as Codeサポート

そして、これは私たちが本当に興奮していることで、AWS CLIではあまり見られないものです。多くの開発者がIDEやターミナルで直接作業することを好むことを知っています。この呼び出しにmonitor resourcesフラグを追加すると、次のようなインタラクティブな体験が得られます。これはコンソールと非常に似ているので、ECSデプロイメントで何が起こっているかを本当に視覚的な方法で確認できます。そして、これはExpress Modeサービスの作成、更新、削除時に行われます。

私たちは、Tsahiが話していたことに戻りますが、compositionというものの可観測性は本当に重要な概念だと感じています。そのため、コンソールとCLIの両方のエクスペリエンスにおいて、リソースのARN、ステータス、そして受信しているイベントやエラーがこれらのビューにパイプされているのが見えると思います。これにより、環境で何が起こっているのかを非常に堅牢に理解できるようになっています。

今ちょっと触れましたが、Tsahiが言っていたライフサイクル管理に戻ると、Express Modeは完全なライフサイクルです。このエクスペリエンスには作成、更新、削除があり、もしこのエクスペリエンスに満足していれば、基盤となるリソースについて学ぶ必要は一切ありません。Application Load BalancerやTarget Groupを見に行く必要もありませんし、タスク定義のすべての設定が何なのかを理解する必要もありません。

初心者ユーザーにとって、これはコンテナを起動する体験をする本当に素晴らしい方法になり得ます。また、ここでは今日のECSよりもずっとシンプルにする多くのことを行っています。例えば、ポートやヘルスチェックの更新などです。今日ECSでそれをやったことがある方なら、それが潜在的に破壊的で、調整するのが本当に難しいことだとご存知でしょう。Express Modeではそのすべてを私たちが処理します。パブリックサービスからプライベートサービスへ、またはその逆への移行は、異なるサブネットを渡してアップデートをプッシュするだけの問題です。Express Modeで私たちが行っていることには、非常に複雑なものが非常にシンプルになるものがあります。

お見せしましょう。可観測性については、通常のCPUとメモリを表示しますが、ロードバランサーがあるため、ターゲットレスポンスタイム、4XX、5XXエラーもあります。アプリケーションログも取得できます。タイムラインビューで見たResourcesタブを新しく追加しましたが、ディープリンクのリストも表示されます。さて、アップデートについてですが、これはすべての作成オプションを表示します。コンテナ設定、ポート、ヘルスチェック、環境変数、シークレット、コマンド、そしてIAM経由で他のAWSサービスにアクセスするために追加できるタスクロールがあります。

コンピュートについては、CPUとメモリ、そしてオートスケーリングがあります。CPU、メモリ、リクエスト、最小値と最大値があります。ネットワーキングについては、サブネットとセキュリティグループがあり、また独自のロググループとログストリームプレフィックスに名前を付けることもできます。削除する際には、削除のプロセスも確認できます。そのサービスに固有のリソースはすべて削除します。

皆さん、Infrastructure as Codeについて疑問に思われているかもしれませんね。ぜひそれについてお話しさせてください。左側には、Express Modeアーキテクチャの完全なCloudFormationがあり、右側には必要なパラメータを持つExpress Gateway Serviceリソースがあります。この削減には本当に興奮しています。皆さんはどうでしょうか。ええ、ありがとうございます。拍手していただいて構いません。サイレントセッションですが、拍手は大丈夫ですよ。

Application Load Balancerの自動共有とスケーリング、そして抽象化の中のコンポジション

こちらにはオプションパラメータもありますが、クラスターやサブネット、セキュリティグループなど、独自のリソースを持ち込める箇所をハイライトしています。これにより、独自の定義を持ち込む柔軟性が得られます。さて、Tsahiもスケールメリットについて話していましたが、同じアカウント内の同じサブネットセットにデプロイされたExpress Modeサービスは、Application Load Balancerを共有することをお伝えできて非常に嬉しく思います。これはホストヘッダーベースのリスナールールを使用して実現しています。そして共有するだけでなく、スケールもさせています。

どういう意味かと言いますと、お見せしましょう。こちらにExpress Modeによってプロビジョニングされたロードバランサーがあります。そしてリスナーを見ると、25個のExpress Modeサービスがあることがわかります。Application Load Balancerは最大25個のExpress Modeサービスと共有できます。これらはすべて一意のTLS証明書も持っています。では、ECSに戻ってExpress Modeで26個目のサービスをプロビジョニングして、何が起こるか見てみましょう。

皆さんお気に入りのNGINXイメージをプルしているところです。デプロイが完了するのを待つ必要もありません。すでに開始されますから。EC2コンソールに戻って、ロードバランサーを見ると、2つ目のロードバランサーのプロビジョニングが開始されていることがわかります。これが、ロードバランサーをスケールさせるという意味です。

2つ目のサービスをプロビジョニングすると、2つ目のロードバランサーをプロビジョニングします。2つ目のサービスを削除すると、その2つ目のロードバランサーを削除します。サービスに固有のものはすべて削除されます。

さて、コンテナを受け取ってURLを提供してくれるサービスは世の中にたくさんあります。実際、AWSにも今日すでにいくつか存在していますので、そのことについては正直に申し上げておきたいと思います。しかし、Express Modeの本当にユニークな点について明確にしておきたいのです。それは、アカウント内にあるこれらすべてのリソースにアクセスでき、それらを変更する能力があるということです。そして、そのおかげで、Tsahiが話していた抽象化とコンポジションの話に戻りますが、もしここで私に同意できない方がいらっしゃれば、後で哲学的な議論をさせていただきたいですね、きっと楽しいと思いますが、私はExpress Modeは抽象化の中のコンポジションであると信じています。

抽象化の中に留まる能力があるのです、もしそうしたければ。その下に何があるかを知る必要は一切ありません。抽象化のシンプルさを得ることができ、それを持つことができます。望むなら、その世界の中に留まることができますが、その下にはコンポジションがあり、そのコンポジションのすべての良さと、望むならその柔軟性にアクセスできるのです。さらに、それにアクセスするために卒業したり移行したりする必要もありません。多くのサービスでは、ある状態から別の状態に移行するために、その明確な線を引かなければなりません。つまり、必要な機能にアクセスするためにシンプルさを諦めなければならないのですが、Express Modeではそうではありません。

Express Modeでは、必要なものにアクセスしたい場合、それをオンにすることができます。そのパラメータを設定して、それから日常的に行っているイメージの更新やオートスケーリングなど、何であれ、Express Modeに戻って続けることができるのです。そして、これが非常に差別化されていると思います。つまり、開発者としてシンプルなモデルを維持しながら、ECSの全機能セットにアクセスできるようにあなたに力を与えるということです。10年以上前から存在し、10年以上にわたって非常に大規模なサービスを運用してきたECS、そして私たちがプロビジョニングしている他のすべてのサービスです。

Express Modeの柔軟性：アウトオブバンド変更の永続化とマルチプラットフォーム対応

Application Load Balancerもそれ自体が非常に堅牢なサービスです。アプリケーションで必要なことをプロビジョニングするために、これらのサービスのすべての機能にアクセスできるのです。シンプルに始めますが、必要なものすべてにアクセスできます。少しお見せしましょう。Express Modeサービスを使って、リソースタブに移動し、タスク定義に変更を加えます。JSONに直接入ります。ECSコンソールでは実際にJSONを編集できます。では、2つ目のコンテナ定義を追加します。

これは、すでにご存知でなければ、サイドカーと呼ばれるものです。ECSの多くのお客様がロギングサイドカーを追加しています。一般的なものにFirelensと呼ばれるものがあり、CloudWatchではなく別の宛先にログを送信できます。そして、ECSでサービスやタスク定義を更新するには、新しいタスク定義リビジョンを作成してから、サービスを更新する必要があります。これがここで行っていることです。サービスを更新したところで、Express Modeサービスに戻ってそのデプロイメントが行われているのを見ています。

では、今ご覧いただきたいのは、Express Modeサービスとは別にアウトオブバンドでアップデートを行った後、Express Modeに戻って再度アップデートを実行し、その変更が永続化されているかを確認することです。では、Express Modeでイメージをアップデートします。私のAmazon ECRリポジトリの最新版に移行しました。JSONに戻って見てみましょう。イメージが新しいものになっています、これが最新のSHAです。そして2つ目のコンテナ定義もそこにあります。

これがまさにパワーなんです。これらのリソースに変更を加える能力があるということです。私たちは変更を永続化し、皆さんは日常的な変更のためのシンプルなアップデートにExpress Modeを使い続けることができます。ECS自体と同様に、Express Modeは追加料金なしで利用できます。プロビジョニングされたリソースに対してのみお支払いいただくことになり、この文脈ではFargateとApplication Load Balancerがそれにあたります。

私たちはこれらのコストをすべてのサービスに分散させる支援をしています。コンソールをお見せしました、CLIもお見せしました、API、SDK、そしてInfrastructure as Codeもお見せしました。CDKではL1コンストラクトとしても利用できます。先週Terraformをローンチしました。そして、約2日前、1日前に新しいGitHub actionをローンチしたことを発表できることを大変嬉しく思います。つまり、GitHubリポジトリを使って、他のGitHub actionsを使ってそれをコンテナにビルドし、ECRにプッシュし、そして私たちのactionを使ってExpress Modeサービスにプッシュして、リポジトリから直接URLを取得できるようになりました。

ということで、Express Modeは開発者がECSで素早く始められるように構築されました。また、多くのプラットフォームチームとも話をしてきましたが、彼らはこれを開発者体験を加速させる方法として、アプリケーションチームに体験を提供する方法として、あるいはアーキテクチャがどのように見えるかをあまり気にしない小規模なPOCを立ち上げる方法として捉えています。ですので、プラットフォームチームの方々も、ぜひチェックしてみることを検討してみてください。

GoDaddyのKatanaプラットフォーム：2,000人以上のエンジニアを支える統合開発者プラットフォーム

さて、今日は、プラットフォームチームが現在Amazon ECSをどのように使用しているか、そしてベストプラクティスは何かについても見ていきたいと思います。GoDaddyは素晴らしい仕事をしてくれました、特にKeithが、そして彼がやってきたことをお見せできることを本当に嬉しく思っています。彼はExpress ModeやECS Managed Instances、ネイティブのblue-greenにはアクセスできませんでしたが、私は確実に彼が構築したものから多くのインスピレーションを得ました。ですので、皆さんにそれをご覧いただけることを楽しみにしています。ありがとうございます、Jen。

皆さんこんにちは、私の名前はKeith Bartholomewです。GoDaddyのPrincipal Engineerを務めています。Jenが言ったように、今日これからお見せする内容の多くは、私たちがどのようにECSを使ってGoDaddyのエンジニアのためのプラットフォームを構築してきたかということです。そして、私たちはExpress Modeのような機能が登場する前、blue-greenやcanaryデプロイメントが登場する前、そしてManaged Instancesが登場する前に、これらすべてを行いました。ですから、これからお見せするすべてのことは、もし皆さんが自分でやろうと思えば、約10倍簡単にできるということを認識しておいてください。私たちは難しい方法でやりましたが、今では皆さんは簡単な方法でできるのです。

さて、皆さんはGoDaddyをドメインレジストラとしてご存知かもしれません。それが最も古いビジネスで、私たちが本当に知られているものですが、今日では私たちはそれ以上のことをたくさん行っています。私たちは顧客をeveryday entrepreneursと呼んでいます。彼らは副業を持っているような人たちで、副業としてビジネスを運営しています。それは彼らの主な収入源ではありませんが、彼らが本当に情熱を注いでいるものです。そして私たちは、これらのeveryday entrepreneursが小規模ビジネスを運営するために必要なすべてのことを行えるようサポートするサービスを提供しています。ですから、それにはドメイン名の取得、ウェブサイトの取得も含まれますが、eコマースストアフロントの運営や、ファーマーズマーケットなどでのPOS決済の受け付けなども含まれます。そして私たちは、これらすべてのタッチポイントをEntrepreneur's Wheelと呼んでいます。

さて、生成AIが私たちエンジニアや技術者の働き方を変えたのと同じように、それは私たちのeveryday entrepreneursが必要なことを行う方法も変えました。GoDaddy Airoは、GoDaddyのすべての製品にわたって動作する、私たちのAI搭載エクスペリエンスです。ドメイン名のアイデアを得ることから、ウェブサイト上でロゴを生成すること、さらにはソーシャルメディアマーケティングまで、私たちはこれらのアイデア、手の届かないように思えるナプキンの裏に書いたようなビジネスアイデアを、これらのeveryday entrepreneursの手に届けています。そうすることで、彼らがあらゆるビジネスアイデアをこれまで以上にアクセスしやすくできるようにしているのです。

さて、これらすべてのイノベーションの背後には、このようなものを運営するために必要なすべてのサービスを立ち上げるために、たゆまず働いている何千人ものビルダーがいます。そして、そこで今日皆さんにお話しできることを楽しみにしているのが、GoDaddyの分散型開発者プラットフォームです。すべてはCI/CDから始まります。そこでは私たちの開発者が基本的に好きなことを何でもやっています。ですから、彼らの中には自己管理のJenkinsクラスターを運用している人もいます。必要に応じてGitHub Actionsワーカーを立ち上げる人もいますし、それが重要だと考えて独自のCI/CDを手作りした人も少数います。

インフラストラクチャについては、開発者に選択させたいと本当に思っているので、少しECSがあり、EKSもあり、そして私たちのチームの中にはオンプレミスでOpenStackを使っている人もいます。そしてセキュリティについては、彼らの邪魔をしたくないので、脆弱性のパッチは好きなときに適用してもらっています。私たちの関知するところではありませんよね?そしてオブザーバビリティについては、Prometheusが好きな人たちがいます。それを本当に楽しんでいて使いたいという人たちがいて、それで問題ありません。Elasticが好きな人もいて、それも使えます。

これはかなり見るに堪えないスライドですよね？これは私たちがプラットフォームで見たいものではないということに、皆さん同意していただけますよね？はい、わかりました。これは多少誇張していますが、私たちがこのプラットフォームを構築し始める前のGoDaddyの状況を大まかに表したものです。そこで私たちは、これらの中で起きていた良いことをたくさん取り入れて、それらをまとめて、すべてのエンジニアのための一元化された統合プラットフォームを作りました。私たちのエンジニアは、ボタンを押すだけで使える堅牢化されたプライベートGitHub actionランナーにアクセスでき、それらは自動的に私たちのIAMシステムに接続されているので、文字通りボタンを押すだけでデプロイできるんです。

Katana自体、これが私たちのインフラストラクチャプラットフォームの名前なんですが、マネージドコンピュートプラットフォームで、ボタンを押すだけでECS Fargateサービス、ALB、そしてそこで必要な他のすべてのサポート機能にアクセスできるようにしています。

セキュリティも統合しました。セキュリティとガバナンスのチームと非常に密接に連携して、すべてのLambdaランタイムが必要なときに確実に更新されるように、すべてのECRイメージに脆弱性がないようにといったことを確認しています。そしてこれらは、そのチームとの本当に緊密な連携を通じて実現できているんです。そして一元化されたオブザーバビリティ。私たちには世界クラスの素晴らしいオブザーバビリティチームがいて、私は彼らと一緒に働けてとても幸運なんですが、彼らはこのプラットフォームを使用するすべての人が、設定ゼロで、すべてのログ、トレース、メトリクスを私たちの一元化されたオブザーバビリティプラットフォームにパイプできるようにするために多くの作業をしてくれました。そこで彼らはダッシュボードやアラームを作成したり、アプリケーションがどのように動作しているかを理解したりできるんです。

Katanaの技術アーキテクチャ：エージェントベースの管理とダークリリースパターン

私たちのエンジニアの多くがこのプラットフォームとやり取りする方法は、この統合されたシングルペインオブグラスを通じてです。これは少し使い古された言葉だとわかっていますが、私たちの開発者は本当にこれを気に入っています。この価値を強調するために考えてみてください。GoDaddyには2,000人以上のエンジニアがいて、それぞれのチームがベストプラクティスに従って、devアカウント、testアカウント、stageアカウント、prodアカウントを持っていて、さらに他のアカウントもあります。そしてまた、大規模な組織は複雑だということも考慮してください。ほとんどのエンジニアは単一のプロジェクトに取り組んでいるわけではありません。彼らは3つ、4つ、あるいは5つのプロジェクトに時間を分けているんです。

私たちには30のAWSアカウントにアクセスする必要があるエンジニアがいて、彼らはそのアプリケーションを30の異なるAWSアカウントにデプロイする必要があります。すべてのAWSコンソールをクリックして回るのはかなり疲れることですから、私たちはそれらをすべてまとめて、エンジニアが一箇所でこのサービスはどうなっているか、あのロールバックはどのように起きたか、これが失敗したときにECSから出たログは何だったか、これは別のアプリの障害によってどのような影響を受けているか、といったことを見られるようにしました。彼らはこれらすべてを一箇所でまとめて取得できるんです。彼らはまたGitHub Actionsも使っていて、私たちがそれを多く管理していますが、より自動化されたCIの観点から同じことを行っています。

この統合ダッシュボードは、オブザーバビリティに関して本当に力を発揮しますし、非常に価値があります。私が何度ページングされて、プロダクトチームと電話会議に入ったときに、画面共有で最初に目にするのがこの画面なんです。彼らはこれを見て、US Eastのロードバランサーと比較してUS West 2のロードバランサーはどうか、こちらのエラー率が急上昇しているか、こちらはアイドル状態かといったことを確認しています。そして私たちの開発者は、複数のアカウント、複数のサービスにまたがって、全体的にどのように動作しているかを本当に大きな視点で理解する方法として、これを使うことを非常に気に入っています。

また、生成AI のサポートも組み込んでいます。私たちのプラットフォームをできる限りシンプルにして、どのエンジニアでも理解しやすくするために多くの努力をしてきましたが、それでもやはり複雑なんですよね。そして時には、私たちがラップしたり抽象化したりできないECSの障害が発生することがあり、その場合はECSからの直接的な障害をそのまま表示するしかないんです。そうするとエンジニアはそれが何を意味するのか本当には理解できないわけです。そこで、先ほどご覧いただいたダッシュボードに直接エージェントを組み込みました。このエージェントは、私たちのすべてのドキュメントを含むBedrockナレッジベースと、彼らのニーズに合わせて私たちが特別にインフラをカスタマイズする方法に関する情報にアクセスできます。そして、ツールやファンクションコーリングを使って彼らのアカウントにリーチし、リアルタイムで、オーケー、あなたのサービスはどうなっているか、デプロイメントイベントを読み取って、CloudFormationイベントを読み取って、どうなっているのかを理解することができます。

そして、ユーザーに対して非常に詳細で、汎用的ではない、実行可能なステートメントを提供します。ユーザーはそれを使って自分で問題を解決することができますし、場合によっては別のツールと組み合わせて使って、私たちのサポートチャネルにチケットを作成することもあります。その際、完全に事前トリアージされたインシデントを持ち込んでくれるので、必要に応じて私たちはサポート問題に取り組み始めることができます。ですから、これは私たちにとって非常に、非常に強力なものとなっています。

このスケールでは、数百ものAWSアカウントがあります。これらすべてのアカウントにアクセスすることは不可欠です。明らかに、プラットフォームとして、私たちが管理している多くのサービスの健全性を理解するために、それらのアカウントで何が起こっているかを確認できる必要があります。ユーザーもその情報を見る必要がありますし、それを安全に行う必要があります。そこで私たちがこれを実現した方法は、エージェントをインストールすることです。これはAIの種類のエージェントではありません。彼らがその言葉を私たちから奪う前に、私たちがそう名付けたんです。昔ながらのエージェントです。各アカウントでそのうちの1つを実行していて、そのエージェントはAPI GatewayといくつかのLambdasで構成されています。これらを選んだのは、実行コストが非常に低いからです。

アイドル状態のときは、実質的にゼロドルしか消費しません。LambdasのコードのためのS3に1ペニーくらい支払ったと思います。これは素晴らしいことです。なぜなら、プラットフォームを使用して私たちの管理機能を利用している人が、プラットフォームを使うためだけに過度な負担を負うことがないということを意味するからです。ですから、私たちが行っていることのコントロールプレーンは可能な限り低コストです。しかし、セキュリティもここでは重要です。API Gatewayを使うことで、そのエントリーポイントにIAM認証を使用できます。専用の管理アカウントのIAMロールのみがこのAPI Gatewayを呼び出すことができると指定でき、これらすべてが私が一行もコードを書くことなく実現されます。そして、私のコードが問題の原因にならないことを知って、どれだけ安心して眠れることか、言葉では言い表せません。私は自分自身よりもAWSのIAMエンジニアの方をはるかに信頼しています。

しかし同時に、このエージェントができることも制限しています。つまり、アカウント内のすべてに対する無制限のアクセスではないということです。ECS、CloudFormation、Application Load Balancerに関する特定の情報を取得する必要がありますが、私たちの関心事ではないその他のものについては、それを実行できるLambdaハンドラーは存在しません。このようにして、影響範囲を制限しているわけです。そして実際に私たちが行う書き込み操作は、CloudFormationスタックの管理、あとは何をしていたかな、時々ECSを再起動することですね。

サービスを時々再起動します。単純に、再起動すれば問題が解決することもありますからね。しかし、私たちのエンジニアがこれらすべてから得られるものは、ボタン一つで実現できるレジリエンスです。2,000人以上のエンジニアがいて、彼らは非常に幅広いバックグラウンドを持っています。中には本当に優秀なDevOpsエンジニアもいます。彼らはすべてのAWS製品に精通していて、認定資格も持っています。一方で、ALBとNLBの違いを説明できないエンジニアもいます。そして私たちは、これらすべてのエンジニアが同じ体験を得られるようにする必要があるのです。

すべてはRoute 53レコードから始まります。これにより、私たちのシステム上で動作しているすべての人が、リージョン間でレイテンシーベースのルーティングを利用でき、障害が発生した際にはそれらのリージョン間でフェイルオーバーできるようになっています。私たちのチームの中には、4つや5つの異なるリージョンで運用しているところもあります。2つだけのところもあります。本当に彼らのニーズ次第です。彼らはこのフェイルオーバーを設定する必要はありません。最初から利用できるのです。そしてこれらのRoute 53レコードは、アプリケーションへと導くネットワークリソースを指しています。ほとんどの場合、それはApplication Load Balancerです。また、エッジでより多くのポイントオブプレゼンスを提供するためにCloudFrontを使用しているチームもあります。そして私たちは、これらすべてをRoute 53レコードと直接統合しています。

そして最終的にECSサービスにたどり着きます。各デプロイメントでは、新しいECSサービスを実行し、エンジニアがALBからサービスへのかなり複雑なルーティングを行えるようにしています。ABテストを行う場合は50/50の分割ができますし、カナリアなどの場合は5%の分割を使用することもできます。つまり、こうした本当に詳細でかなり複雑なデプロイメント戦略を、これもまたボタン一つで実現できるのです。

そこで重要なのが、先ほど触れたこれらのデプロイメントについてです。Katanaでのすべてのデプロイメントは新しいECSサービスを作成します。これを行うのは、何か悪いことが起きた場合に、本当に信頼性の高いウォームスタンバイを確保するためです。例えば、ここでは私のサービスのバージョン1が本番環境で稼働しているとしましょう。すべてのユーザーがバージョン1にアクセスしています。そして可能な限り、そのサービスには触れたくないのです。そうですね、まるでインディ・ジョーンズと魔宮の伝説のようなものです。壊れていないなら、いじるな、ということです。だからサービス1には触れたくないのですが、開発チームはバージョン2に取り組んでいます。彼らはいくつかの変更を加えていて、それをデプロイする必要があります。

そして、最終的にデプロイを行い、バージョン2をデプロイすると、完全に分離されたECSサービス、完全に分離されたターゲットグループが立ち上がり、サービス1は全く触れられません。そのままの状態で完全に保たれます。さて、バージョン2が動作していることを確認する必要がありますので、特定のヘッダー、例えばX version twoや、X version twoというクエリ文字列、あるいはCookieを使って、QAチームにバージョン2のアプリケーションをテストしてもらったり、バージョン2のアプリケーションに対して自動化されたスモークテストを実行して、期待通りに動作していることを証明することができます。

そして最後に、それに自信が持てたら、小さな変更を加えます。変更されるのは、ターゲットグループをバージョン1ではなくバージョン2を指すように変更するだけです。繰り返しますが、バージョン1は触れられておらず、単にトラフィックをそこから移動させているだけです。YOLOで行きたければ、これを一度に全部やることもできますし、パーセンテージルートを使ってゆっくりと、バージョン2のアプリケーションへのトラフィックを徐々に増やしていくこともできます。そしてこの場合、バージョン1はウォームスタンバイとして稼働しています。ですから、負荷がかかった時にバージョン2が劣化し始めた場合でも、バージョン1がフォールバックとしてまだそこにあるわけです。

繰り返しますが、これは単にプラットフォームに組み込まれているものです。これはデプロイメントを管理するためのかなり複雑な方法ですが、私たちのエンジニアは日常的にこれについて考えることはありません。しかし、彼らはこれを本当に創造的な方法で使って、ライブプレビュー環境を作っています。時には、同時に2つのバージョンだけでなく、5つ、6つ、最大で12個くらい実行していることもあると思います。本当に忙しいチームが常に物事をテストし、このようなダークリリースパターンを使ってデプロイしているんです。

エスケープハッチとガバナンス：ユーザーの自律性を保ちながら安全性を確保する設計

さて、TsahiとJenの両方が言及したように、エスケープハッチはプラットフォームにとって本当に重要ですよね。私たちは正しい種類の抽象化について多くの良い選択をしてきたと思いますし、ほとんどの場合それはうまく機能しますが、時々人々はそこから成長する必要があったり、本当に自分たち独自の方法でやりたいことがあったりします。そして、私たちがこれを行う方法の一例がWAFです。私たちがプロビジョニングするすべてのロードバランサーにはWAF ACLがあります。自分でWAF ACLを設定したことがあるかどうかわかりませんが、かなり複雑です。ルールやバイパス、順序を表現するためのJSON言語は、本当に大変です。私にとっては丸一日ドキュメントを読む作業でした。

ですから、私たちはユーザーにそのすべてを知ることを要求していません。単にこう言っています、ほとんどの方はレート制限が必要になるでしょう、特定のサブネットを許可したりブロックしたりする必要があるでしょう、一般的な攻撃を防ぐためのAWSマネージドルールを提供します、と。しかし、もしアプリケーションがリクエストで大きなボディサイズを本当に必要とする場合は、ニーズに応じてそれらのものをオプトアウトすることができます。そして、私たちのユーザーのほとんどはこれで非常にうまくいっていて、WAF ACLのJSON言語に触れることは決してありません。

しかし時々、本当に複雑なIPセットを持っていて、この機能ではサポートしていない何かをする必要がある人が現れます。そして、それを抽象化に組み込んで、私たちがこれらの機能を構築する間彼らを待たせるのではなく、私たちは単純に、わかりました、自分でWAF ACLを作成してください、と言います。作成したACLのARNを教えてください、そうすればそれをロードバランサーに関連付けます、そして先に進みます。そうすることで彼らはコントロールを取ることができます。彼らはWAF ACLの責任を引き継ぎますが、プラットフォームの残りの部分から得られる利益を犠牲にする必要はありません。以前と同じようにそれらすべてを使い続けることができます。

私たちは他のいくつかのことでもこれを行っています。セキュリティグループについては、私たちが管理するものが互いに通信できるように自動的にセキュリティグループを設定しますが、複雑なセキュリティグループがある場合は、それを渡すことができます。またはIAMポリシーについては、うまくいく場合はインラインで定義できるようにしていますが、時々これらのポリシーが管理するには少し大きくなりすぎることがあります。そういう場合は、わかりました、ポリシーのARNを教えてください、そうすればそれをタスクロールにアタッチします、と言います。

GoDaddyの全員がCDKを使っています。私たちはすべてのAWSインフラストラクチャの管理ツールとしてCDKに集約しています。そして、開発者がKatanaを得意なことに使い、それを拡張する必要があるというケースを見つけることは非常によくあります。ECSタスクをDynamoDBテーブルに関連付ける必要があったり、何かの動作を変更したいと思ったりします。そして彼らは、自分のCDKコード内でKatanaがプロビジョニングするものを拡張するためにコンストラクトを使うことができます。つまり、新しいKatana環境を作成します、と言えるわけです。これは実際にはコンテキスト値を検索して追加しているだけです。ここに何がありますか？リスナーは事前に予測できないランダムな文字列を取得するので、それをライブで検索し、そのコンテキストを取得します。そして彼らはこのコンテキストの一部を使って、後で独自のカスタムリスナールールを追加し、私たちが管理しているインフラストラクチャを取得して、彼らのニーズに合う方法で拡張することができます。

ですから、これらすべてのガードレールとオフランプは非常に重要です。これはすべて、ガバナンスシステムを中心に構築されており、ここの列にいる私の同僚の一人が使っていると思います。私たちはCloudFormationフックを使って人々ができることを制限しているので、開発者は本当に間違いを犯すことができません。パブリックIPを持つECSサービスを作成することはできません。それは起こりません。そしてKatanaはこのガバナンスシステムの上に構築されており、これによって私たちはプラットフォームとして何か間違ったことをしないという大きな自信を得ています。そしてプラットフォーム内で行うことは何でも、これらのルールに従うことになります。

先ほど言ったように、私たちは全員が共通のCDKツールセットを使っているので、チーム間で使う共通言語のようなものが得られます。CDKが私たちのコミュニケーション方法です。Katanaが管理するインフラストラクチャ自体は、実際には非常に、非常に大きなCDKアプリケーションです。そのため、場合によっては、ユーザーは私たちのコードから学ぶことができ、私はそれで構いません。彼らはソースコードを盗んで、ああ、あなたたちが何をしたか分かった、と言って、それを自分のものに適用できます。そして魔法はありません。つまり、私たちのプラットフォームが行うことで、ユーザー自身ができないことは何もありません。私たちには魔法の権限はありません。私たちにはこれができるけれどあなたにはできない、なぜなら私たちだけが信頼されているから、というような特権的なことは何もありません。私たちはユーザー自身ができることをやっているだけで、それを行うための道のりを加速しているだけです。これによって彼らに本当に強力なオフランプが提供されます。ですから、もし彼らが私たちのCloudFormationスタックの一つを取って、それを別々に自分で管理する必要が生じた場合、彼らはそれを行うことができ、私たちのガバナンスフレームワーク内でそれを行うのに何の問題もありません。

ビジネス統合とECS Fargateの選択理由：GoDaddyが学んだ教訓

さて、GoDaddyのような規模の会社では、インフラの管理は重要ですが、実際にエンジニアが価値を実感し始めるのは、そのインフラをビジネスの他の部分とどう統合するかという点なんです。先ほど申し上げたように、私たちには非常に優秀なオブザーバビリティチームがあり、Katanaが管理するすべてのECSサービスには、最初からFluent Bitサイドカーが付いていて、FireLensを使ってログをオブザーバビリティシステムに送信します。現在、共有のOpenTelemetry Collectorに取り組んでいて、トレースを収集して同じことを行います。これはエンジニアにとって非常に大きなメリットです。この恩恵を受けるために何もする必要がないんです。最初から用意されているんですね。

コンプライアンスとセキュリティについては、先ほど触れましたが、これらのチームと密接に連携して、すべてが常にパッチされた状態を保つようにしています。プラットフォーム全体を監督しているおかげで、個々のチームが単独ではできない規模でこれを実現できています。GoDaddyは大手の証明書レジストラまたは証明書発行者であり、DNSも扱っているので、社内の証明書APIと連携して、エンジニアがプロビジョニングした証明書を適切なAWSアカウントにインポートし、ロードバランサーで動作するようにして、自動的に更新されるようにしています。そして実験です。実験はGoDaddyのDNAの大きな部分を占めていて、実験というとブラウザでのABテストのようなフロントエンドの関心事だけだと思われるかもしれませんが、私たちはインフラの変更も実験だと考えています。アプリケーションのバージョン2は、バージョン1が抱えていたパフォーマンスのボトルネックを解決するかもしれませんし、それがチェックアウトファネルのクリックスルー率を改善するかもしれません。ですから、新しいアプリケーションがデプロイされたり、アプリケーションの新しいインスタンスバージョンがKatana上にデプロイされるたびに、そのデータを実験プラットフォームに送信して、データサイエンティストが仮説や他のデータソースと相関させて、それがどのように影響するかを確認できるようにしています。

そしてエンタープライズネットワーキングは厄介です。複雑なんです。AWSアカウントとオンプレミスが混在しています。オンプレミスアクセスが必要な場合、やり方は分かっています。特定のサブネットグループにアタッチする必要があるとか、そういったことです。私たちのユーザーにとっては、チェックボックスをクリックするだけです。これらのチームと協力して、ネットワーキングをできる限り簡単にするために、こうしたことを行っています。

では、なぜECS Fargateなのか？AWSには多くのコンピュートプラットフォームがあります。 その多くがコンテナをサポートしていて、これは私たちにとって良いことです。ECS Fargateを選んだのは、コスト管理と柔軟性のバランスが本当に良かったからです。管理は非常に重要で、プラットフォームを運用する小規模なチーム、約7、8人のエンジニアがいて、2,100人のエンジニアにサービスを提供しなければなりません。ですから、毎日EKSインスタンスにパッチを当てるなんて、できません。その規模では管理できないんです。ECS Fargateを使えば、インスタンスの管理やパッチ適用をする必要がありません。

先ほど言ったように、これはECS Managed Instancesの前に作られたもので、それによって状況は少し変わりますが、スケジューリングなどを扱う必要もありません。以前ISTIOを一度だけ運用したことがある者として言えるのは、これをやらなくていいのは本当に素晴らしいということです。しかし、柔軟性を犠牲にすることはありません。すべてのコンテナ設定、VPC接続、Service Connectのような機能へのフルアクセスが可能です。そして、私たちが運用するサービスの種類にとって、コスト面でも適しています。常時稼働している顧客向けのWebアプリが多く、ECSの価格設定方法に非常にマッチしているんです。

それでは最後に、私たちが学んだ教訓についてです。私たちのユーザーは、シングルペインオブグラスを本当に高く評価しています。彼らがそれをどれほど気に入ってくれるか、私は過小評価していました。CloudFormationを介して運用するのは、ちょっと難しいところがあります。CloudFormationはインフラストラクチャを表現する方法が非常に静的なのですが、ECSサービスは非常に動的です。デプロイメントを行うと何百ものイベントが作成され、ヘルスチェックを確認したりと、かなり多くのことが起こっています。ですから、これらの間でインピーダンスを一致させることは、私たちがある程度の作業を投入しなければならなかったことの一つです。

しかし、それには利点もあります。もし私たちが再び窮地に陥った場合、リージョンからトラフィックを移動させ、すべてのスタックを削除し、以前とまったく同じ方法で再作成すれば、アプリは望み通りに動作します。そして、私たちは他のチームと協力しなければなりません。私たちは自分たちのことを「プラットフォームのプラットフォーム」と呼んでいます。私たちは皆、プラットフォームのマインドセットで考えていますが、私はすべてを自分で修正することはできません。ですから、オブザーバビリティチーム、セキュリティチーム、ガバナンスチームと協力することが、開発者のニーズを満たすプラットフォームを作る上で本当に不可欠でした。

それでは、私たちの哲学的な緊張関係についてお話しして終わりにしたいと思います。もう一つ共有したい哲学的な緊張関係があります。開発者を一種類の人間として考えるのは大きな間違いだと思います。つまり、AWSエキスパートからAWS初心者までのこのスペクトラムにおいて、あなたの会社には一種類のエンジニアしかいないと言うのは間違いです。明らかに、その全体にわたって存在する人々を見つけることになるでしょう。そして私たちが発見したのは、彼らのニーズを満たすためには、彼らが幅広いスペクトラムを持っていることを理解し、それらすべてのニーズを満たすプラットフォームを構築する必要があるということです。それは、AWSエキスパートが繁栄し、彼らが望むコントロールを持てるようにし、同時にAWS中心ではない人々が、すべてを知ったり認定を取得したりすることなく仕事を完了できるようにするプラットフォームです。

ですから、皆さんが帰られる際に、もしプラットフォームの構築を検討されているなら、あるいは自分自身のプラットフォームに取り組んでいるなら、できるだけ幅広いスペクトラムのエンジニアのニーズを満たすプラットフォームを作ることを検討してください。そうすれば、幅広い人々に対して成功を得ることができます。それでは、Jenに戻します。ありがとうございました。

まとめ：ECS Express Modeの可能性とセッションリソース

もう一度言わせてください。私はKeithがGoDaddyで構築したものから、本当に多くのインスピレーションを得たと感じています。彼が行ったことのいくつかから、私たちのロードマップに追加したいと既に考えていることがあります。ですから、Keith、あなたが構築したものを共有してくれて改めて感謝します。このセッションから多くのことを得られたことを願っています。ぜひECS Express Modeを試してみてください。アプリケーション開発の加速について、ECS上でのプラットフォーム構築について、少しでも学んでいただけたなら幸いです。

こちらのQRコードをご覧ください。このセッション専用のものです。スライドのPDFをダウンロードできます。また、ECS immersion dayワークショップへのリンクもあります。こちらには現在ECS Express Modeが含まれています。そして、先ほどローンチしたばかりのGitHub アクションへのリンクもあります。改めてありがとうございました。セッションアンケートへのご記入をお願いいたします。ありがとうございました。

---

※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。