re:Invent 2024: AWSとAdobeが語るAmazon EKSによるスケーラブルなプラットフォーム構築
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - How to build scalable platforms with Amazon EKS (KUB301)
この動画では、Amazon EKSを使用したスケーラブルなプラットフォーム構築について解説しています。Platform Engineeringにおける主要な課題として、開発者からの信頼獲得の重要性を指摘し、その解決策としてKubernetesをプラットフォームとして活用する方法を提示しています。Adobeの事例では、Ethosプラットフォームの構築を通じて、開発者の新規サービスリリースまでの時間を1ヶ月から数日に短縮し、インシデント検出時間を75%以上削減した成果が紹介されています。また、GitOpsやArgo、Backstageなどのオープンソースツールの活用や、CNOEコミュニティを通じた協働の重要性についても言及しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon EKSを活用したスケーラブルなプラットフォーム構築の課題
Principal Solutions ArchitectのNirmal Mehtaです。これからAmazon EKSを使用してスケーラブルなプラットフォームを構築する方法について、セッション301でお話しします。もし間違った部屋に来てしまった方や、EKSについてご存知ない方も、このまま参加していただければ、ここで学ぶことができます。本日はIsaacとJohnも登壇する予定です。後ほど自己紹介させていただきます。では、この素敵な写真についてお話ししていきましょう。これが今日のプレゼンテーションで使用する唯一のスライドです。
ここにPlatform Engineerの方はいらっしゃいますか？現在プラットフォームを構築している方は？なぜプラットフォームが必要なのでしょうか？そうですね、お金の問題です。ガバナンスのコントロールや新しい技術への適応のためですね。この写真のような理想的なField of Dreamsのようなプラットフォームを持っていると思う方はいますか？私たちは皆様のような多くのプラットフォームを構築しているお客様とお話しする機会があります。 そこで繰り返し出てくるテーマの1つが、プラットフォームが見捨てられてしまうということです。採用されないのです。現在そのような問題を抱えている方はいますか？素晴らしいプラットフォームを構築したのに、開発者がそれを採用することに躊躇している、という方は？今日のトークはまさにそのことについてです。EKS上でプラットフォームを構築する際の考え方や、プラットフォームが見捨てられないようにするためのベストプラクティスについてご紹介します。
プラットフォーム構築の必要性と信頼の重要性
私たちがプラットフォームを必要とする理由は、テクノロジーの変化とニーズに対応する必要があるからです。インターネット、スマートフォン、規模、オブジェクトの数、ストレージ、アプリケーションの数、ノードの数、さらにはサーバーの数など、私たちは大きな技術的変革を経験してきました。このような技術の変化や、開発者がアプリケーションを実行するために必要とするものに適応するには、プラットフォームが必要です。皆さんも今まさにそのような状況にあるのではないでしょうか。MLチームとミーティングを行い、突然Machine Learningをアプリケーションやプラットフォームに統合して、そのようなワークロードをサポートしなければならなくなった方はいらっしゃいますか？
インターネットが成長するにつれて、自動化が必要になってきました。手作業で管理できる数十台のマシンでWebサイトをサポートする時代から、ChefやPuppetのようなツールを採用して、サーバーの自動化とガバナンスを実現するようになりました。しかし、その自動化は完全なものにはなりませんでした。 現在では、これらの大規模なアプリケーションをMicroservicesに分割し、コンテナ化を始めました。これによって、このコントロールループ、ガバナンス、自動化の一部が解決されました。しかし、それは複雑性の増加や依存関係の問題、そしてその複雑性を管理するための何かが必要になるという新たな課題をもたらしました。
そこで私たちはこれらのプラットフォームの構築を始めました。そして「作れば、彼らは来る」—開発者たちが来る—と自分に言い聞かせました。Field of Dreamsという映画をご存知の方はいますか？その映画では、農夫が過去の野球選手の幽霊に出会い、自分の畑に野球場を建設すれば、伝説の野球選手たちが集まってくると告げられます。私はAWSに入社する前はPlatform Engineerでしたが、同じような考えを持っていました。自分のプラットフォームは素晴らしく、最高の機能を備え、DockerとContainerを使用していると思っていました。開発者たちが私の輝かしいKubernetesプラットフォームを使いたがるはずだと考えていました。しかし、実際に座って待っていても、私のField of Dreamsには誰も現れませんでした。
なぜ私たちはこのような取り組みを続けているのでしょうか？私たちはプラットフォームの機能だけに注目しがちです。しかし、プラットフォームが見捨てられるのは、単に適切な機能が不足しているからではありません。顧客と対話し、プラットフォームが失敗する理由を調査すると、開発チームやユーザーをプラットフォームに引き付けるのは、実は信頼関係だということがわかります。プラットフォームは信頼を確立できないときに見捨てられます。ニーズに応えて進化するという信頼が失われるとシャドーITが生まれ、開発者が必要とするサービスや機能を提供できるという信頼が失われ、そしてシステムが予期せぬ形で頻繁に壊れないという信頼が失われます。これが信頼の問題だとわかるのは、開発者たちが予測可能な従来のプラットフォーム、つまりボトルネックや限界がわかっているプラットフォームを選び続け、使い続けるからです。最適ではなくても、慣れ親しんだものを信頼するのです。
信頼は3つの要素から成り立っています。私の論理に厳密さがあると信じていただければ、より信頼していただけるでしょう。そして、今日のプレゼンテーションでその論理性をお示しできればと思います。私の真摯さを感じていただければ、より信頼していただけるでしょう。そして、皆さんのニーズを大切にしていると感じていただければ、より信頼していただけるでしょう。
プラットフォームの観点から見ると、真摯さは協調的な共同責任として表れ、成果に対する共通の関心を示します。プラットフォームに対して独自のプロダクトマインドセットを構築するのです。論理性は透明性として表れます。つまり、やると言ったことをやり、言ったことをする、という透明性とコラボレーションへのコミットメントです。共感は信頼性として表れます。サービスをサポートし、確実に動作させることを大切にし、開発者のニーズに応えることを意味します。
IsaacとJohnが信頼に関するこれら3つの概念について説明を続ける間、このことを念頭に置いておいてください。スケーラブルなプラットフォームを構築する際、高い信頼性を維持しながらスケールの要求に応えることには多くの摩擦が生じます。そこにはジレンマがあります。迅速に動いてスケールアウトできますが、信頼性が低下したり、ニーズにすぐに応えられなくなったりして、信頼が損なわれる可能性があります。これらのスケーラブルなプラットフォームを構築する上での課題は、絶えず進化するテクノロジーの要求に応えながら、いかにして高い信頼性を維持するかということです。
少し話を戻しましょう。このプレゼンテーションの準備中、Johnは「結局のところ、開発者が気にしているのは、いかに早くコードをProductionに投入できるかということだけだ」と言いました。例えば、開発チームが慣れ親しんだ3〜4ヶ月のデプロイサイクルを持つモノリシックなパイプラインがあるとします。今はそれをMicroservicesに分割しましたが、新しいプラットフォームがこれらのMicroservicesのデプロイを適切に処理できるとは信頼していません。摩擦ポイントがわからないため、既存のモノリシックなパイプラインに新しいMicroservicesや機能を詰め込もうとする傾向があります。なぜなら、そこではボトルネックや痛みのポイント、摩擦がわかっているからです。これらのプラットフォームの構築とベストプラクティスについて、信頼を維持しながらスケールに対応することに焦点を当てて説明を進めていく中で、このことを念頭に置いておいてください。では、Isaac、どうすればそれが実現できるのか教えてください。
自動化の限界とKubernetesによる新たなアプローチ
Platform Engineeringについて考える時、私たちが常に取り組むことについて詳しく見ていきましょう。私たちは常に自動化に目を向けます。私がPlatformに携わってきた長年の経験の中で、毎年必ず自動化を進めてきました。今年も自動化を進め、そして来年も - 間違いなくあなたのPlatformのプロダクトロードマップには、さらなる自動化が含まれているはずです。私たちはPuppetから始まり、Chefに移行し、そしてAnsibleへ、現在はTerraformへと - 常に自動化を続けています。
しかし、なぜ私たちはまだ自動化の完成に至っていないのでしょうか？他の業界を見てみましょう。皆さんは最後に銀行に行ったのはいつですか？私は正直、最後に銀行に行った時のことを覚えていません。銀行は80年代にATM（Automated Teller Machine）から自動化を始めました - その名前自体が自動化を表しています。他の業界は自動化を実現できているのに、なぜか私たちPlatform Engineerやソフトウェアデベロッパーはまだそれを実現できていません。なぜ私たちは毎年、年々同じように自動化を続けているのでしょうか？そして、同じことを繰り返し続けている限り、私たちはそれを実現することはできないでしょう。
この点について掘り下げてみましょう。Nirmalが話していた点の一つはスケールです - 私たちの世界で他のどの要素よりも変化が大きいのがスケールです。デベロッパーの数、サービスの数 - AWSを長く使っている方なら分かると思いますが、私たちはEC2とS3から始まり、現在では250以上の異なるサービスを提供しています。毎年re:inventで多くの新しいサービスをローンチしています。私たちのスケールは劇的に成長し、そしてそれらの変化に適応していかなければなりません。
成長とスケールに伴い、私たちは物事をより小さな単位に分解していきます。これはマイクロサービスだけを指しているのではありません - 人、組織についても考えます。大きなPlatformチームを小さなチームに分割します。ここで示すように、独自のパイプラインと抽象化を持つネットワーキングチーム、認証 - これらすべてが保存された状態に置かれ、彼らはネットワーキングを担当します。また、EC2インスタンスやKubernetesクラスターのセットアップに焦点を当てたインフラストラクチャーチームもあります - これらはすべて、アプリケーションを実際に実行するために必要な基盤となるインフラストラクチャーです。
また、アプリケーション、インフラストラクチャー、ネットワーキングの可観測性の実現に焦点を当てたObservabilityチームもあり、彼らも独自のパイプラインを持っています。Complianceチームも同様に独自のパイプラインを持ちます。彼らは独自の認証ツール群を持つことになります。運が良ければ、似たようなツールを使用することになりますが、残念ながら実際には、それぞれのチームが独自のツールセットを構築することになってしまいます。
最後に、アプリケーションのデプロイについて説明しましょう。プラットフォームについて語るとき、ほとんどの人が思い浮かべるのは、このCI/CDパイプラインだけです。多くの人はこの点線の左側について考えることはありません。しかし、それだけではありません - アプリケーションをデプロイする際には、依存関係なしでは済まないのです。データベースやS3バケット、Elastic Cacheなど、アプリケーションが必要とする多くの依存関係があります。これは全く別のパイプラインなのです。
さらに複雑なことに、誰も本当に話題にしないけれども存在するパイプラインがあります。 それは、バックグラウンドで動作し、すべてが継続的にコンプライアンスを満たしていることを確認するContinuous Complianceパイプラインです。これまで、ここにいる皆さんは設定をすべてGitに保存し、パイプラインをデプロイすると、デプロイメントパイプラインをプッシュした瞬間はすべてうまく動作しているように見えます。でも、どうやってドリフトが発生するのでしょうか？
ドリフトが発生するのは、バックグラウンドで動作するContinuous Complianceパイプラインのような存在が原因です - これは秘密で、開発者は何も知りません。開発者は何かをGitに入れたと思っていますが、バックグラウンドで別の何かがそれを変更しているのです。また、人間が実際にバックグラウンドで変更を加えている可能性もあります。そのため、私たちが話してきた 「Gitはソースオブトゥルース（真実の源）である」という考えは、実は真実の源ではないのです。あるお客様は「Gitはソースオブトゥルースではなく、ソースオブホープ（希望の源）だ」と言っていました。なぜなら、パイプラインと、私たちが期待する意図した結果、そして実際の結果の間にあまりにも多くのドリフトが存在するからです。
すぐに信頼関係が崩れ始めます - 私たちが築いてきたすべての信頼関係が。開発者にGitに物事を入れるように言い、Gitに入れたものが本番環境と一致すると信じるように言いますが、実際にはそうはなりません。そのため、開発者との信頼関係がすぐに崩れ始めます。これは、Nirmalも触れていたように、システムの採用を促進する上で非常に重要なポイントです。 では、この図に戻って、何が複雑なのかを見てみましょう。なぜこれらのパイプライン間を完全に自動化できないのでしょうか？答えは人間の介在です。開発者や、プラットフォームエンジニアとしてのあなたがプラットフォームに統合したいと考える、多くの新しいサービスや機能をローンチすることになります。これを少し単純化してみましょう。
新しいリソースが必要だと仮定してみましょう。 そのリソースをアプリケーションに組み込んだり、プロビジョニングしたりするためには、インフラストラクチャー層とのやり取りが必要です。インフラストラクチャー層は 開発者に戻って確認する必要があり、そこで私たちはミーティングを設定し、Jiraチケットを追加し、要件を伝えるためだけに常にミーティングを行うことになります。必要な小さな機能が、今や何が必要か、何の正当性が必要か、カレンダーの調整などを議論する何週間ものミーティングに変わってしまうのです。
プラットフォーム構築における信頼関係の確立と協働
また、本番環境にそのまま展開するわけにはいかないため、コンプライアンス部門の承認も必要です。そこでアプリ開発者とコンプライアンス部門との間で新たなミーティングが発生します。アクセス要件のためにネットワークチームも関与する必要があり、さらにミーティングが重なっていきます。先ほどのATMの例を考えてみましょう - そこには人間は関与していません。私たちの作業を遅くし、自動化を不可能にしているのは、実行しているパイプラインと、ミーティングを通じた相互のコミュニケーション方法なのです。AWSで新機能をリリースする際、これらのミーティングやJiraチケット、作業を待つ時間のために、お客様が実際に採用するまでに1年以上かかることもあります。
私たちが知っているのは、ボトルネック以外の改善は単なる幻想だということです。自動化すると言って周辺の小さなことを自動化しても、本当に自動化が必要な核心部分には到達していません。Platform Engineerとして、常にミーティングで話し合い、ニーズを正当化するだけでは、信頼関係を築くことができません。これがPlatform Engineeringの核心です。私たちは最終的に、大規模化によってこれらのパイプラインやミーティングの限界点に達しています。
これをどのように解決すればよいのでしょうか？銀行業界が行ってきたことを参考に、APIを活用することができます。答えは実はシンプルですが、そこに至るのは簡単ではありません。ネットワーキングやBlue-Green Deployment、RDSデータベースやS3バケットの取得などのパイプラインについて考えるのではなく、これらを機能として捉えます。プラットフォームはこの機能をAPIを通じて公開すべきです。APIは宣言的で、その背後のソフトウェアによって制御できます。パイプラインの場合、ボタンを一度押して、うまくいけば壊れないことを期待しますが、そうすると制御を失い始めます。
チームは同じままですが、今はソフトウェア開発とAPIの観点で考え、プロダクトマインドセットでこのプラットフォームを構築しています。以前はすべてのミーティングを必要としていたリクエストは、今ではProduct Managerを通じて優先順位付けされ、最も重要な機能にできるだけ早く取り組めるようになっています。しかし、一つの課題があります：まだボトルネックが存在するのです。開発者からの機能リクエストは、プロダクトやPlatform Engineeringチームが対応できる量を常に上回ります。
開発者は、これらの機能リクエストに対応できない場合、どうするでしょうか？ただ座って待っているわけではありません。彼らはあなたを迂回し、多くの人が知っているShadow Opsとして、独自のプラットフォームを構築したり、知らないうちに別のサービスを使用したりします。しかし、これは私たちが望むものではありません - これは信頼を損なうもう一つの形態です。これは開発者が私たちPlatform Engineerに対する信頼を、少しずつ損なっているのです。
私たちが本当に望んでいるのは、彼らに私たちのPlatformを拡張してもらうことですが、すべてがプロプライエタリで、独自のコードを書き、独自のドキュメントを作成し（時にはそれすら完成させない）という状況では、これを達成することはできません。これは、このような文化をどのように育てていくかという問題を提起します。これはまさにNormaが話していた協働についてです - どのように私たちは互いに協力し合えばよいのでしょうか。
Team Topologiesを読んだことがある方なら、この本の主要な概念の1つとして、私たちPlatformエンジニアは最初、ファシリテーションから始まったということがあります。SREやDevOpsの考え方は、アプリケーションのローンチを支援するために人をチームに組み込むというものでした。現在、ほとんどの人々はXaaS - Database as a Service、Platform as a Service、Kubernetes as a Service、Container as a Serviceへと移行しています。これによって次のレベルのスケーラビリティは得られますが、私たちが目指すべきは協働です。
では、協働を促進するために何を参考にできるでしょうか？銀行の例でAPIを使用したように、実際の協働を支援するために、世界のどのような形態を活用できるでしょうか？ここにいる多くの方々は、きっとOpen Sourceソフトウェアを使用されていると思います。これらのOpen Sourceコミュニティは、透明性、協働、そして信頼を築いてきました。そうして大きく成長してきたのです。私たちのPlatformにOpen Sourceフレームワークを取り入れることで、透明性、協働、信頼といったものも一緒に取り入れることができます。
もし私たちがKubernetesをこのフレームワークとして使用したらどうでしょうか？ここまで、多くの方々はコンテナをデプロイするためにKubernetesを使用し、コンテナオーケストレーションシステムとして考えてきたと思います。これからは、コンテナのオーケストレーションについては話しません。純粋にPlatformとしてのKubernetesについて話していきます。たとえコンテナをデプロイするためにKubernetesを使用しなくても、Platformレイヤーとして使用することができます。
なぜそうしたいのでしょうか？少し奇妙に聞こえるかもしれませんが、KubernetesにはPlatformに必要な基本的な要素がすべて揃っています。APIハンドラーやRBACが組み込まれており、Platformへの出入りを制御し、入力時に変更を加えるMutating Admission Controllerも備えています。Webhook Controllerによるスキーマ検証を組み込むことができ、Kubernetesと連携する他のControllerもあり、独自のビジネスロジックやコンプライアンスを追加することができます。
Adobeの事例：Ethosプラットフォームの構築と成果
最も重要なのは、状態を保存する場所が1つに統一されているということです。以前のPipelineを振り返ってみると、それぞれが独自の方法で状態を保存していました。Terraformでは、Pipelineを実行するたびに新しい状態ファイルが作成されます。これは別の場所に保存される異なる状態であり、それを実際に照会する方法はありません。アプリケーションの状態を理解するには、4〜5つの異なる状態ストアを確認する必要があり、過去の履歴が見えない状況では開発者との信頼関係を築くのが非常に困難です。 ETCDは私たちの単一の状態ストアとして機能し、Capabilityの代わりにKubernetesではControllerと呼んでいます。KubernetesクラスターにControllerやCRDを追加するたびに、実質的にそのプラットフォームに新しい機能を追加していることになります。
すでにKubernetesを使用している方々は、これをすでに実践しています。これは必ずしも新しいことではなく、ただ異なる視点で考えているだけです。 Kubernetesのような仕組みを使用したいもう1つの理由は、複雑さを隠蔽する抽象化の概念です。APIについて考えるとき、まさにそれが起きています - 複雑さをAPIの背後に隠蔽しているのです。先ほどの銀行の例に戻ると、銀行は口座間でお金を移動するプロセスについて尋ねているわけではなく、ただあなたが何を必要としているかを尋ね、APIがそれを処理します。
Kubernetesでは、誰もがDeploymentという抽象化を知っています。Deploymentの抽象化は実際には、ReplicaSetの抽象化の上に構築されており、それはさらにPodの抽象化の上に、そしてContainerの抽象化の上に構築されています。Kubernetesの素晴らしい点は、Blue-Greenデプロイメントのような新機能が必要になった場合、これらすべてを捨てる必要がないことです。代わりに、Blue-Greenを追加し、下層のすべての抽象化を活用できます。ソフトウェア開発では、これをComposability（構成可能性）と呼びます - 異なる機能を組み合わせて1つにまとめることができるのです。Argoを使用している方々にとって、Blue-Greenデプロイメントの機能があります。これは実際、ReplicaSet、Pod、Containerを取り、その上に独自のBlue-Green抽象化を構築しているだけです。なぜなら、開発者はこのインフラストラクチャについて気にする必要がないからです - 彼らは自分のアプリケーションと、それをできるだけ早くProductionに投入することだけを気にしています。
では、さらに抽象化を構築してみましょう。Kubernetes内で、Applicationと呼ばれる新しい抽象化を構築できます。「Application」という用語は、私の組織とあなたの組織で異なる意味を持つ可能性があるので、これは単なる例です。
Applicationには、Ingressが必要かもしれませんし、S3バケットが必要かもしれません。 そしてそのS3バケットにはIAMポリシーが必要で、他の抽象化も構築しています。つながりを見ていくと、チケット発行があります - 通常、コンプライアンスを強制するために JiraチケットやServiceNowチケットを使用します。そのため、コンプライアンスの抽象化もそこにあります。また、デプロイ先の環境も必要です - 開発環境やステージング環境にデプロイしており、 その環境にはアカウント、VPC、サブネットが必要です。Kubernetesクラスターが必要かもしれませんが、これらの抽象化はすべてKubernetes内に存在できます。
これらすべてを組み合わせると、環境を指し示すアプリケーションが出来上がり、そこからコンプライアンスを支援し変更を追跡するためのチケットシステムにつながります。このアプリケーションには、Ingressやバケット、そして独自のチケットシステムがあり、コンプライアンスの確実な実施を可能にします。開発者が本当に気にかけているのは、このアプリケーション、つまりこの小さなボックスだけであり、その下にある他のすべてのものではありません。以前見たパイプラインを思い出してみると、Kubernetesをプラットフォームとして考え、コンポーザビリティについて考え始めると、あれほど必要だったコミュニケーションやミーティングが不要になっていきます。
開発者が気にかけるのはアプリケーションであり、インフラストラクチャではありません。以前お話した継続的コンプライアンスパイプライン、つまりバックグラウンドで動作する秘密のパイプラインを覚えていらっししゃるでしょうか。Kubernetesではこれが必要ないのです。なぜなら、継続的なコントロールループがあり、継続的なコンプライアンスがKubernetesの基盤そのものに組み込まれているからです。Kubernetesをプラットフォームとしてより活用すればするほど、信頼性と透明性が高まります。Kubernetesで何かを照会すると、1回のAPI呼び出しで意図した状態と実際の状態の両方を取得でき、すべてのAPI呼び出しがSpecと実際のStatusを返してくれます。
Kubernetesを活用するもう一つの理由は、その豊富なControllerエコシステムです。 これは一人で行う必要はなく、すでに信頼性と透明性を確立したコミュニティを活用できます。機能を追加するために使用できるオープンソースのControllerが数多く存在します。先ほどArgoについて話しましたが、Blue-Green機能や自動化を自分で構築する必要はなく、ArgoCDを使用して導入すればいいのです。また、最近では、AWSのオブジェクトをKubernetesフレンドリーな方法で表現するACKの上に抽象化を構築するのに役立つCrossplaneもリリースしました。コーディングすることなく、これらの抽象化を開発できる巨大なControllerエコシステムがあります。もちろん、場合によっては独自のCustom Controllerを作成する必要があるかもしれません。
最も重要なのは、これによってチームや人々のコラボレーションの方法が変わることです。パイプラインを通じたやり取りや、言葉やJiraチケットを介したコミュニケーションから、すべてをコード化し、お互いのコンポーネントを活用して新しいものを構築する方向に移行しています。左側には、アプリケーションチームのアーキテクト、データベースアーキテクト、セキュリティコンプライアンスの担当者がいますが、彼らは要件をチケットではなく宣言的な言語で記述しており、Kubernetesがそれを可能にしています。
Kubernetesを使用する素晴らしい点は、多くのWorker Nodeは必要ないものの、Control Planeのスケーラビリティが重要になることです。なぜなら、今やKubernetesを単なるコンテナオーケストレーションシステムではなく、プラットフォームとして使用することで、Control Planeに大きな負荷がかかるからです。ここで Amazon EKS の出番です。私たちは過去7年間をかけて、Amazon EKSを地球上で最もスケーラブルなマネージドKubernetes Control Planeに作り上げてきました。Amazon EKSを使用すれば、それらすべてをAWSに委託でき、多くのものを作成する必要なく、プラットフォームの構築に集中できます。
Worker Nodeを作成して、別の場所でAPIやコンテナを管理する必要はありません。それは私たちが代わりに行います。もう1つの素晴らしい点は、先ほど述べたように、あなたは一人ではないということです。私たちは、カーテンの向こう側のテーブルに皆さんを招待しています。アプリ開発者や他のチームを左側に連れてくることができるだけでなく、コミュニティも参加できます。
そして最後に、Platform Engineeringや独自のコードから離れることで、私たちがサポートできるようになります。私たちにはBlueprintがあり、CNOEというプラットフォームコミュニティがあり、そこではプラットフォームを構築するための設定やオープンソースツールを提供しています。また、ツール構築を支援する専門家もいます。オープンソースで構築する場合、私たちはその仕組みを理解しているので、支援することができます。透明性が確保されているのはそのためです。つまり、プラットフォームについて考えるとき、もはやあなたは一人ではありません。Platform Engineeringチームの壁を超えて、コラボレーションし、より広い視野で考えることができます。これがスケールを実現する方法であり、信頼を構築するための基盤となります。私たちは、開発者や他の人々をPlatform Engineeringチームのカーテンの向こう側に招き入れる段階に来ているのです。
Ethosの成功要因：コミュニティ構築とアカウンタビリティ
実践的な例を見ていきましょう。まず、開発者がGitに設定をプッシュします。次に、ArgoCDやコントローラーがGitを監視して、変更を確認します。ArgoCDや既存のCI/CDシステムがAPI Serverにプッシュします。この時点では、まだKubernetesに何も適用されていません。変更を加える前に、Admission Controllerを通過して、変更が有効で適切かつコンプライアンスに準拠していることを確認する必要があります。それがETCDという単一のステートストアにプッシュされます。これはS3バケット、RDS、アプリケーションのためのものです。先ほど話した抽象化されたものすべてが、テナントNamespaceに配置されるETCDに表現されます。
コントローラーがそこに存在し、変更を監視・調整し、あらゆるAPIと通信します。AWSのAPIについて多く話しましたが、これを使用して他のリソースや観測可能なリソース、APIを持つものすべてを管理できます。7番目は、それらの変更からステータスを取得することです。これで、意図とステータスが同じ場所にあり、ETCDで更新されています。8番目に戻ると、単一のプレゼンテーション層があり、ネットワーク、可観測性、アプリケーション、履歴など、開発者が仕事を完了してアプリケーションを本番環境にデプロイするために必要なすべてを表示できます。この例ではBackstageを使用していますが、独自のものを構築したり、他のオープンソースツールやベンダーのものを使用したりすることもできます。すべてがKubernetesというシングルAPIの背後にあるため、非常にシンプルになります。
重要なポイントをまとめましょう。コミュニティを構築し、コラボレーションしましょう。自分たちを単なるリソースが限られたPlatformチームとして考えるのではなく、オープンソースやAWSについて考えてください。私たちがサポートします。より大きなコミュニティを構築しましょう。また、プロダクトマインドセットを持つことも重要です。開発者に共感し、耳を傾け、彼らが本当に必要とするものを構築することを忘れないでください。APIで複雑さを抽象化することも重要です。パイプラインについて考えるとき、実際には複雑さをすべて開発者に直接さらしているだけで、これは有益ではありません。最後に、透明性のためにオープンソースを活用し、Amazon EKSを利用してControl Planeの管理を任せることで、差別化されていない作業を削減しましょう。
ここまで、Nirmal は高いレベルの話をしてきました。私はもう少し低いレベルの話をしてきましたが、それでもまだ抽象的な内容でした。次は、これを実際の現実にする方法について、Adobe の John Weber をお招きしたいと思います。彼は実際にこれを実践してきた方です。では John、ステージへどうぞ。ありがとうございます。Cube 301: How to stop meetings へようこそ。ありがとうございます、Isaac。本日は Adobe の事例を皆様と共有できることを大変嬉しく思います。Adobe では、新しいサービスをリリースするのが本当に大変なのです。新しい開発者が Greenfield サービスの開発を始めるまでに、約1ヶ月もかかってしまいます。コードを書くだけでなく、監視システムや本番環境へのアクセス権を得るためのチケットを作成し、担当者の対応を待たなければなりません。
その間、開発者はコードの作成、デプロイ、統合テストを行う必要がありますが、チケットを受け取った担当者が要求内容を理解できないということもよくあります。開発者のニーズを調整することに加えて、本番環境への対応準備、モニタリングツールのセットアップ、アラート、バックアップ戦略、そして問題が発生した際のインシデント対応の準備など、考慮すべき事項が山積みです。
私は Developer Platforms グループに所属しており、私たちのモットーはシンプルです：開発者がより良いソフトウェアをより速く書けるようにサポートすることです。問題は、このような複雑な環境でどうやってその目標を達成するかということです。私は開発者のために物事をシンプルに、そして多くの場合は過度にシンプルにする必要がある抽象化とプラットフォームを支持しています。また、私には到底及ばないインフラ管理能力を持つ AWS のようなクラウドプロバイダーも支持しています。
私のキャリアの中で、Adobe が提供するあらゆる顧客向け製品の運用を担当してきました。私の主な課題の一つは一貫性に関するものでした。私がよく言うように、Adobe は「一貫して一貫性がない」状態でした。AWS のようなパブリッククラウドプロバイダーを使用するという技術的な方向性は揃っていても、各エンジニアリングチームが独自の実装方法を取っていました。すべてのチームがそのように実装できてしまうと、拡散を防ぐのが難しくなり、最悪の場合、ひどい顧客体験につながってしまいます。
そこで Adobe では、Ethos を作成し、いくつかの大きな賭けに出ることにしました。Container や Docker のような正解もあれば、Mesos のような間違いもありました。私たちは顧客に柔軟性を提供する必要がありました。基盤となるインフラストラクチャーを気にせず、すぐに使える解決策を求める顧客もいました - それが CaaS（Container as a Service）でした。また、業界が Kubernetes に向かっていることを認識し、ネイティブ API を利用して独自の道を選びたいというチームもいました。これが私たちの PaaS（Platform as a Service）提供につながりました。
開発者が本当に気にかけているのは、たった1つのことだと私は考えています。それは、いかに早くコードを本番環境にデプロイするかということです。Ethosは、開発者がクラウドインフラのスケーリング、堅牢なCI/CDパイプラインの構築、セキュリティとコンプライアンス、GPUなどの限られたリソースのコスト管理について考える必要がないように、これらの機能を提供します。私たちができる場合には、開発者からその負担を取り除き、彼らに代わって行動を起こしたいと考えています。
EthosはAdobeのウェブサイトや一般的なEコマースストアでは購入できませんが、もしあなたがAdobeの製品の顧客やユーザーであれば、Ethosを使用していることになります。プロダクトチームとして、信頼と敬意を築くためにステークホルダーと足並みを揃える必要があります。最初のグループは社内のお客様、つまり開発者です。私の若い頃の失敗の一つは、彼らを顧客と呼ぶことを拒否したことでした。それは完全な間違いでした。開発者を顧客として考え、彼らへの敬意と共感を築かなければ、失敗は避けられません。
お客様に必要なものは何でしょうか？明確なドキュメント、理にかなったUX、そして参入障壁の低さです。使いにくいシステムは誰も使いたくないからです。外部のお客様にとって、Adobeは私たちが提供するすべてのものの基盤であり、ダイヤルトーンのような存在です。私たちは、すべてのエンドユーザーに高品質な機能と価値を提供し、実現することを目指しています。AWSに関しては、AWSがAdobeのニーズを満たすことができるか、そして逆に、私たちがAWSに適切なフィードバックを提供しているかを考える必要があります。Adobeは非常にソフトな文化を持っています。
私たちはユーザーに白紙のキャンバスを提供し、「さあ、Adobeを活用して魔法のような何かを作ってください」と言って、彼らの可能性を解き放つことを大切にしています。開発者に対しても同様のアプローチを取っていますが、ご覧の通り、白紙のキャンバスを開発者に渡すと、物事が間違った方向に進む可能性があります。
私たちがしなければならなかったのは、彼らの賛同を得るためのグラスルーツな活動を構築することでした。現場では、Platform Championsプログラムから始めました。各開発チーム内に現場の声を持ち、あなたが達成しようとしていることの支持者とプロモーターがいて、最も重要なことに、彼らが当事者意識を持っていれば、incredibly強力で活気のあるコミュニティを構築することができます。また、私たちはInner Sourceモデルを採用しています。ビジネスが求めるすべてのことを行うのに十分なリソースを持つことは決してないので、技術だけでなく、運用方法もスケールする必要があります。Adobe内にはEthosへの明確なオープンコントリビューションモデルがあります。お客様の声に耳を傾ける必要があり、私たちはCustomer Advisory Boardsを通じてそれを実践しています。定期的にユーザーと話し合い、彼らの課題に耳を傾けています。彼らは「仕事や生活がとても楽になった」と言ってくれたり、「私たちのために何を作ってくれたんだ？」と言ってくれたりします。厳しい意見も大丈夫です。フィードバックは贈り物なのです。
これが私たちの成果です。今年、組織外からの貢献数が6倍に増加し、Ethosへの25,000件の貢献が、Ethosチーム以外から寄せられました。Adobeの社内では、昨年の230人から増加して、約1,500人のコントリビューターがこの取り組みに参加しています。1,500人の開発者が自発的にあなたのコードベースに貢献してくれることを想像してみてください。本当に素晴らしいことです。
Ethosの具体的な取り組みと成果
成功するためには、アカウンタビリティの文化を構築する必要があります。私は、エンジニアがProduct Ownerとして行動すべきだと考えています。これはAgileの文脈での話です。すべてのEngineering Managerは、顧客の代弁者であるべきです。彼らは自分たちが構築しているものとその機能について、ビジョンを持ち理解している必要があります。価値を提供する相手と継続的な対話を持つべきです。Werner Vogelsの有名な言葉を引用すると、「作ったものは自分で運用する」 - 火曜日の午前2時に何か問題が起きたとき、誰が呼び出されると思いますか？そのソフトウェアを書いた人たちです。問題が発生したとき、開発者は顧客が経験している痛みや負担を理解し、共感する必要があります。面白いことに、毎晩起こされ続けると、人は根本的な問題を修正する強い動機を持つようになります。
私たちが構築している素晴らしい機能を利用する開発者は、クラウドが無料ではないことを理解する必要があります。これには実際のコストがかかります。そこで、私たちは詳細なダッシュボードとコスト帰属の仕組みを構築し、それらのチームに請求書を送っています。私もAdobeのお金を大切にし、彼らもAdobeのお金を大切にしているので、その負担をどう吸収できるか考え方を転換する必要がありました。それを実現したのが、Automatic Resource Configurator（ARC）です。手を挙げてください - 開発者が最初にProductionにデプロイするときに、コンテナのサイジングを正しく設定できると思う人はいますか？誰もいませんね？そうだと思いました。ARCは、Adobeのリサーチチームと一緒に構築したシンプルなシステムです。エンジニアがEthosクラスターでキャパシティをリクエストすると、Open Policy Agent（OPA）と共にPodをデプロイし、Podの仕様を変更できるフックを評価して提供します。利用可能なキャパシティを持つワーカーにワークロードをデプロイし、PrometheusからCortexのような長期時系列データベースに利用状況のメトリクスを記録します。その後、ARCが利用状況を分析し、自動的なPull Requestを通じて開発者にコンテナサイジングを推奨します。開発者が「確かに私の設定が間違っていたかもしれない」とPRを承認すると、GitOpsがマージ後に自動的に処理を行い、コンテナのサイジングが完了します。
どのようなサービスプロバイダーでも、ユーザーとの強制力のある契約が必要です。目標を設定し、測定し、結果とアウトカムに対して自分自身に責任を持つ必要があります。私はこれをService Level IndicatorとService Level Objectiveを採用することで実現しています。デプロイできるか？スケールできるか？ネットワーク接続は確保できているか？といった核となる機能を定義し、継続的にパフォーマンスを測定・評価しています。
私は完全にAmazon EKSを採用しています。EC2ノード上でKubernetesを運用することに栄光はありません - もっと価値のある仕事があるはずです。誰もがインフラの負債を宣言し、すべてをAmazonに任せることを目指すべきです。問題が発生したとき（そして必ず発生します）、あなたのチームは質の高いRCAを書くことができ、それを外部に公開することに抵抗がないでしょうか？本当に高い基準を設定する必要があります。
カスタマーサービスの立場で、リアルタイムに自分の仕事をチェックして、約束したことが確実に実行されているかを確認できたらと思いませんか？私たちAdobeではそれを実現しています。これは社内の誰もが閲覧できるサンプルダッシュボードです。この例では、Ethosクラスターのアウトバウンド通信機能の健全性を評価しています。私たちのチームが管理するKubernetesクラスターの送信ネットワーク接続について、約束した内容をきちんと提供できているでしょうか？
また、お客様の信頼性とアップタイムも重要です。Observabilityを実現するのは本当に大変なことです - エージェント、コレクター、メトリクス、トレース、ログ、イベントなど、様々な要素があります。そこで私たちはOpenSLOを採用しました。これらの課題は既に解決済みなのです。最初は自分たちで構築する必要があると考えていましたが、実際にはそんなに苦労する必要はありませんでした。Ethos上のすべてのアプリケーションは可能な限り自動計装されています。ユーザーからターゲットなど、いくつかの入力を受け取るだけで、私たちのツールが処理を引き継ぎ、OpenSLOの魔法によって、Ethos上のすべてのアプリケーションのエラーバジェットを自動的に計算できるようになっています。
では、私たちはどこに投資をしていて、その投資からどのようなリターンを得ているのでしょうか？運用のスケーリングに関して私が注目している主要なKPIは、クラスターとオペレーターの比率です。Amazon EKSに移行してインフラストラクチャの破産を宣言して以来、オペレーターあたりのクラスター比率を10:1から30:1にスケールアップできたことを嬉しく思います。また、自社開発のソリューションを廃止してGitOpsとArgoを採用することを検討しており、これは生成AIなどの新しいユースケースにもより柔軟に対応できます。最後に、開発者の負担を軽減する必要があります - 開発者が行き来する場所を減らすことで、彼らはより幸せに、より速く仕事ができるようになります。私たちは全てのポータルを1つにまとめ、Backstageを採用することでこれを実現しました。
第4クォーター終了時のスコアボードはどうなっているでしょうか？私たちは勝利を収めているでしょうか？はい、勝利しています。開発者は1ヶ月待つ必要なく、わずか数日で完全な新規スタックをデプロイできるようになりました。会議の数も減り、その新規スタックにはObservabilityプラットフォームも含まれており、インシデントの検出時間を75%以上短縮できたことを嬉しく思います。生成AIの時代に向けて、コストは引き続き重要なテーマとなりますが、GPUのような限られた高価なリソースを扱う際、Ethosを使用することで、今年の初めにコスト効率の目標を達成することができました。最後に、EthosとAdobeの内部プラットフォームの構築により、開発者はより幸せになりました。なぜなら、彼らが気にしているのは、いかに早くプロダクションにリリースできるかということだけだからです。開発者が幸せであれば、それは生産性の高い開発者になることを意味し、結果としてより幸せな顧客につながります。
ご清聴ありがとうございました。ここでNirmalに戻して、締めくくりをお願いしたいと思います。Amazon EKSでプラットフォームを構築することの重要性について、皆さんに理解していただけたと思います。
まとめ：魅力的なプラットフォーム構築のポイントと今後の展望
これにより、信頼性が高くスケーラブルなシステムを構築して、常に変化するニーズに対応できるようになりますが、すべてを自分でする必要はありません。CNOEをご覧ください - CNOEは私たちのCloud-Native Operations Excellenceのオープンコミュニティです。Adobeを含む多くのお客様と話をしたところ、CNCFのランドスケープからObservabilityやデプロイメント用のツールを個々に選定するのではなく、共に意見を出し合って設計したアーキテクチャとオープンソースツールを作ろうということになりました。それがCNOEです。ぜひチェックして、今すぐプラットフォーム構築を加速させてください。
では、魅力的なプラットフォームをどのように構築すればよいのでしょうか？信頼性を通じて、透明性、コラボレーション、そして共感を高めることに焦点を当てましょう。プラットフォームを、継続的に進化する製品として捉えてください。開発者にアンケートやインタビューを実施し、プラットフォームを使うべきと考えられる人々になぜ使っていないのかを尋ねてみましょう。Amazon EKS Kubernetesのコントローラーを通じて複雑さを抽象化し、組織内だけでなく、開発者、その他のステークホルダー、AWS、そしてオープンソースコミュニティを含むより広いコミュニティへと拡大しましょう。あなたは一人ではありません。
本日のセッションにご参加いただき、ありがとうございました。KUBトラックでは、関連する他のセッションも開催されています - 一部はすでに終了していますが、そのBreakoutセッションの動画はYouTubeでご覧いただけます。明日木曜日に開催されるCNOEワークショップでは、CNOEを使用したIDPの構築を実践的に体験できます。また、KUB201では新機能に関する発表がありましたので、Kubernetesで導入される新機能やAmazon EKSの今後の展開について、ぜひそちらのトークもチェックしてください。
Amazon EKSのトレーニングもご活用ください。KubernetesやAmazon EKSを初めて使用される方向けに、無料のAmazon EKSバッジとトレーニングをご用意しています。また、本日のセッションについては、このQRコードから、プラットフォーム構築の取り組みを加速させるためのリンクやリソースにアクセスしていただけます。プラットフォーム構築を楽しんでいただき、本日は有意義な時間となりましたことを願っています。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion