re:Invent 2024: トヨタがBackstageでDeveloper Experience向上
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Elevating the developer experience with Backstage on AWS (OPN405)
この動画では、AWS上でBackstageを活用したDeveloper Experienceの向上について、Toyota Motor North AmericaのKishore Jonnalagedda氏らが解説しています。Developer Cognitive Loadの軽減を目指し、40以上の承認済みTemplateを提供することで、開発者1人あたり年間52週間の時間削減を実現した事例が紹介されています。BackstageのSoftware Catalog、Templates、TechDocsなどの基本機能に加え、Amazon Bedrockを活用したGenerative AIボットChofer Archieの導入により、開発者の作業効率を向上させた具体的な取り組みが示されています。また、Platform Engineeringチームの構成や、セルフサービス化、ネットワーク効果、継続的改善の重要性についても詳しく解説されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS re:Inventにおける開発者体験向上の取り組み
みなさん、本日はご参加いただき、誠にありがとうございます。お話しさせていただくことがたくさんありますが、まず始める前にKishoreさんとNiallさんをご紹介する前に、皆様のご参加に感謝申し上げたいと思います。re:Inventの会場内の移動が大変なことは承知しています。黄色いバッジをつけて走り回っている私たちスタッフを見かけたら、私たちが皆様のことを大切に思っており、ご参加に深く感謝していることをお伝えしたいと思います。スウェーデンからSpotifyの方々や、日本からToyotaの同僚の方々など、様々な国からお越しいただいています。ご参加が大変だったことと思いますが、本当にありがとうございます。
AWS上のBackstageによるDeveloper Experienceの向上についてご紹介させていただきます。私はBryan Landesと申します。本日は、Toyota Motor North AmericaのKishore Jonnalagedda氏と、Developer PortalやPlatformの構築をサポートしてくれている同僚のNiall Thomsonをお迎えしています。お二人には後ほど自己紹介をしていただきます。私は約6年間、Toyotaのサポートを担当しており、Connected MobilityやDealership、そして素晴らしいお客様のCloud Journey全般についてお手伝いをさせていただいています。このような機会を得られて、大変光栄に思っています。
それでは、本日の流れについてご説明させていただきます。まず、BackstageとDeveloper PortalやPlatformが現在注目を集めている理由について、簡単に概要をお話しします。その後、Toyotaの事例に移り、私がオープンソースソリューションについて話すよりも、はるかに大規模で重要な取り組みについてお聞きいただけると思います。彼らは素晴らしい成果を上げており、私の話よりも、むしろ彼らの話をお聞きになりたいのではないでしょうか。
Developer Cognitive Loadの課題とDeveloper Portalの重要性
これらの様々な課題を通じて解決しようとしているのが、Developer Cognitive Load（開発者の認知負荷）の問題です。特に企業において、開発者のCognitive Loadは比較的低く抑えられるべきで、迅速な構築とインフラの自己サービス化が可能であるべきです。大企業では物事が複雑で大規模になりがちですが、それは仕方のないことです。インフラの観点からデータベースやVPC、その他のリソースをリクエストする際に、チケットを発行したり申請したりすると、本来の仕事を進めたいだけなのに、数週間から数ヶ月かかってしまうことがよくあります。
Spotifyから借用させていただきたい考え方があります。ちなみにSpotifyの方々もいらっしゃいますので、Expo Hallに行けば、どこかでセッションを行っているかもしれません。Ben Patrickさんをはじめ、ご参加の皆様にシャウトアウトしたいと思います。15～20個のChromeタブやFirefoxタブを開いている代わりに、たった2つのタブだけで済むとしたらどうでしょうか？1つはシングルペインのガラス（統合インターフェース）で、もう1つはGitHubやGitLab、あるいは他のツールです。特にコンテキストスイッチングを含む認知負荷を減らすことが重要です。これは常に複雑で困難な課題でした。
このスライドは見せないように言われていたのですが、あえてお見せすることにしました。DevOpsは複雑です - このスライドが示しているのはまさにそのことです。大規模なDevOpsを実践するには、基本的にこのようなフローに従うことになります。実は、技術的な部分が最も簡単だと私は考えています。私たちはみんなナードで、ナードであることが大好きですからね。でも、最も難しい問題はおそらく文化の部分です。これらのDeveloper PortalやPlatformがあれば、焦点となる1つの場所を設け、そこを通じて企業全体を動かし、特にセルフサービスの観点から、大規模なDevOpsを実現できるのではないでしょうか。DevOpsは複雑なのです。
The Phoenix Projectのような書籍を読んでも分かる通り、私たちはみんな今も一緒に学び、実践している最中なのが興味深いところです。完璧ではなく複雑ではありますが、Developer PortalやPlatformはまさにこの課題を解決しようとしているのです。
私たちが本当に目指しているのは、開発者が機能を素早く構築し、効果的にスケールし、認知負荷を減らせるようにすることです。エンジニアリングや企業のDevOpsの観点からすると、中央集権的な企業チームは6,000もの異なるツールを必要としないかもしれません。むしろ、それらのツールを統合し、混沌をより良くコントロールしようとしているのです。チームが構築している環境に特化して、標準化や自動化を進め、プロセスをより効率的にすることに取り組んでいます。さらに、知識やベストプラクティスの共有も重要です。例えば、私が会社を去る際に、学んだことを新しく入ってくる人とどのように共有するのか？だからこそ、すべてを一元化された場所、シングルペインオブグラスに集約することが非常に重要なのです。
内部開発プラットフォームの台頭とBackstageの役割
私たちが正しい方向に進んでいることを確認するため、この状況に関するGartnerの見解を参考にしました。Inner Loop、Outer Loop、そしてOrganizational Loopが存在することになります。Developer Portalはこれらの側面に対応できます。Inner Loopには、コードの作成、コンパイル、CLIからのテストなど、より頻繁に行われる活動が含まれます。Outer Loopは、コードの標準化とコンプライアンスに焦点を当てています。Organizational Loopは、オンボーディングなどの側面を扱います。例えば、一部の顧客は実際にオンボーディング時間を計測していますが、Developer PlatformやPortalを使用することで、そのプロセスを大幅に加速できます。Gartnerやその他のアナリストも、私たちと同じトレンドを見ているのです。
これは内部開発プラットフォームの台頭につながっており、まさに私たちが注目しているポイントです。通常、オンプレミス、エッジ、またはクラウドネイティブなど、何らかのクラウドインフラストラクチャを持つことになります。VMやコンテナをスピンアップするために、KubernetesやAWS CloudFormation、Terraformなどのオーケストレーションツールを使用することになります。これらは上の行に示されているのと同じコンポーネント - CI/CD、セキュリティ、テナンシー、そして全体的なインフラストラクチャを管理することになります。
私たちが目指しているのは、そういった複雑さを全て抽象化することです。開発者は、これらの基盤となるコンポーネントに触れる必要が一切ないようにすべきです。これは一つの旅路であり、Toyotaがどのようにしてこれを実現したのかについて後ほど詳しく共有しますが、要するに複雑さを抽象化することが全てです。 開発者がInfrastructure as Codeやその他のリソースにアクセスできるセルフサービス型のインターフェースが用意されることになります。私たちは複雑さを抽象化することで、迅速な開発とデプロイメントを可能にしようとしているのです。
ここで強調しておきたいのは、これは開発者だけのためのものではないということです。Data Scientistやビルダー、その他の方々のためのものにもなり得ます。ただし、最初は開発者向けに構築することが重要です。なぜなら、開発者が主要な顧客だからです - これがPlatform as a Productの考え方です。異なるビジネスユニット向けにプラットフォームを構築していく中で、Data Science向けなど、徐々に機能を追加していくことができます。 様々なチームやアプリケーションが存在することになりますが、それらは全て開発者プラットフォームというフォーカルポイントを通じてつながることになります。
ここでBackstageの出番となります。Backstageはオープンソースプロジェクトで、実は私はRed HatとSpotifyと一緒にBackstage Conを共同開催しました。私たちは、Backstageがプラットフォーム上に セルフサービスインターフェースを実装する優れたソリューションであることを実感しています。
私たちの目標は、これらすべてのサービスと機能のためのシングルペインオブグラスを提供することです。つまり、何を目指しているのか？シングルペインオブグラスの提供です。500個のChromeタブを開かせたくありません - 2つで十分なはずです。開発者ポータルにアクセスすれば、すべてのリソースや連絡先などが確認できるようにしたいのです。Software Catalogは、すべてのインフラストラクチャの中心的な記録として機能します。後ほどPureが話すように、30万以上のアプリケーションを持つような大規模な顧客もいます。Toyotaも製造工場や3,500の販売店を持つ非常に大きな規模ですが、すべてのものが集中管理される場所があることで、誰もが必要な連絡先を見つけることができます。
Backstageの素晴らしい点の一つは拡張性です。これから基本機能について説明しますが、プラグインを利用する機能もあります。Jiraが必要な場合は、Jiraプラグインを作成してインフラストラクチャに追加し、チームがクラウドの課題を解決するためにより多くの接続性を持たせることができます。 Backstageの主要な基本機能は、非常に大まかに言うと、Software Catalog、Templates、TechDocs、そしてSearchで構成されています。
Backstageの主要機能と実装アーキテクチャ
Software Catalogは、インフラ全体を一元的に把握できる非常に優れた方法です。これはすべてGitと連携しているので、GitOpsを活用することをお勧めします。誰が何を使用しているのか、どのチームが何を使用しているのか、そしてコンポーネント同士がどのように連携して動作しているのかといったコンテキストを把握できます。Neilが後ほど話すと思いますが、新しいプラグインでは、Gitリポジトリだけでなく、依存しているAWSインフラも確認できます。例えば、Reactを使用している場合、このCatalog内でRDSやECSを使用しているかどうかを確認できます。
もう一つの重要な機能がSoftware Templatesです。Pureがこれについて話をする予定です - 現在約40個のテンプレートがあると思います。これにより、インフラを素早くセルフサービスで構築できます。ECSやAPI Gatewayをスピンアップできるだけでなく、ベストプラクティスも組み込めます。大企業でもSMBでも、VPCがインターネットアクセスを持たないようにするなど、ガードレールやベストプラクティスを設定できます。必ずしもインフラに限らず、人的なやり取りにも使えます。新しいGitリポジトリが必要な場合は、テンプレートを作成してAPIコールを実行できます。私は、R&Dチームがテストに必要なAWSアカウントを、テンプレートに記入して200ドルの予算を設定するだけで取得でき、使用後は別のテンプレートでAWSアカウントを削除できる、アカウント自動販売機のような仕組みを見たことがあります。
Backstageの検索機能は非常に優れています。OpenSearchを連携させて使用している事例をよく見かけます。新しいコネクターを使用すると、OpenSearchをConfluenceなどの他のシステムと連携させることができます。これにより、誰もが中央のポータルからConfluence、GitHub、その他のシステムをエンタープライズ検索で検索できるようになります。認知負荷を減らし、ワンストップショップを実現することが目標です。これらのSoftware Catalogやドキュメントはすべて検索可能です。
TechDocsに関して、ドキュメント作成は誰もが好きな作業ではないかもしれませんが、オンボーディングをサポートし、情報を一元管理できる素晴らしい機能です。Confluenceの内容をすべてTechDocsに移行している組織もあります。すべてがMarkdownで記述され、WYSIWYGエディタも用意されているので、技術的な知識が少なくてもトレーニングやブログを作成する必要があるビジネス担当者でもドキュメントを追加できます。すべてのコンテンツはS3に保存され、TechDocsで管理され、検索可能です。今年も、ナレッジプラクティスとベストプラクティスが重要なテーマとなっています。
ドキュメントからアーキテクチャの話に移りますが、これは前回もお見せした一般的なアーキテクチャです。アーキテクチャ自体は特に複雑ではありませんが、アーキテクチャレビュープロセスは依然として存在します。Platform Engineeringチームがプラットフォームを定義し、大規模な企業では、複数のアーキテクトがすべてをレビューして、不正なインターネットアクセスを防ぐなど、適切なセキュリティ対策が講じられていることを確認します。クラウド、オンプレミス、エッジデプロイメントに関わらず、すべてを定義し続けることになります。
何らかのLanding Zoneが必要となりますが、これはTerraformやAWS Control Towerで実装される可能性があります。また、TerraformやCDK、Kubernetesなどのような何らかのオーケストレーターを使用することになります。Backstageは基盤となるインフラのセルフサービスを担当し、そしてプラットフォーム自体は異なる個別のアカウントやVPCにデプロイされます。最近よく目にする点なので強調しておきたいのですが、開発者のために構築することを忘れないでください - 彼らが主要な顧客なのです。その後、ビルダーやデータサイエンティストへと展開できます。多くの組織では、ユーザーが異なるアイデアをプラットフォームに提供できるセルフサービスフォームを実装しています。
ToyotaにおけるDeveloper Platform「Chofer」の構築
Toyotaについてお話ししましょう。Toyota North Americaのキショア・ジョンナラゲッダです。私たちは約4年前にこのプラットフォームの取り組みを開始しました。 Toyotaの理念とTPSについて紹介させていただきます。Toyota Production Systemをご存知かもしれませんが、これは高品質、低コスト、最短のリードタイムという指針に従っています。中核となる運営モデルは、私たちが「ムダ」と呼ぶものの削減と、さらに重要な「カイゼン」- 継続的改善に焦点を当てています。Toyotaには「最高」はなく、「より良い」があるだけです。これが継続的改善の背後にある原則です。
Toyotaのシステムは時間をかけて有機的に構築されてきました。工場や様々な販売システムに組み込まれた大量のレガシーインフラが存在します。ディーラーショップに行かれたことがある方は、これらのシステムを経験されたことがあるでしょう。これらは当時、ローカルで最適化されたものであり、何百何千というアプリケーションと共に20-30年の開発の歴史があります。
ある時点で、現地現物の原則に従って - 文字通り現場に行って、アプリケーションがどのようにデプロイされているかを見ることにしました。パターンを理解するためにこのマップを作成しました。アプリケーションの構築とデプロイメントに多くの反復作業があり、デプロイメント方法に一貫性がないことを特定しました。開発チームにコンテナのデプロイ方法を尋ねたところ、17の異なる回答がありました。また、時間の経過に伴う変更の規模も考慮しました - これは初日だけの問題ではなく、アプリケーションは長期間存続するため、2日目以降の運用が重要になります。開発者が環境に適応するのにかかる時間は、何百ものアプリケーションに掛け合わせると、かなりのオーバーヘッドとなります。
開発者にアプリケーションの定義について聞いたとき、このような図が返ってきました：アプリケーションとは、彼らのラップトップに収まるもの - データベース、API、Javaを書いている場合は、コンパイルして作業できるもの、PostgreSQLサーバーをダウンロードできるものです。しかし、現実は大きく異なります。広範なDevOpsパイプラインと専門知識が必要です。データベースに単純にログインして作業を始めることはできません - アクセスには特定のツールが必要です。クラウドリソースについても同様です - Javaの開発者として採用された人が、最初の仕事としてIAMポリシーを書き始める人がいるでしょうか？そして、誰が最優先事項として可観測性について考えるでしょうか？通常、障害が発生して特定の情報をログに記録していなかったことに気付くまで、考慮されません。認知負荷とその削減について話すとき、
このコンテキストでは、右側のエキスパートである必要も、左側で作業している必要もありません。フレームワークやツールがあるので、もはやHello Worldを書く必要はないのです。興味深いフレームワークがあり、それ自体が認知負荷となり、さらにその上に他にもやるべきことがたくさんあります。これらが実際に組み合わさって機能するのです。
そこで私たちは、これをより良くする方法を考えました。これは2021年のことで、Platform Engineeringという用語がまだ生まれる前でした。私たちは、それがPlatform Engineeringだと気付かないうちに、実際にPlatform Engineeringを始めていたのです。最終的に、私たちはPlatform Engineeringの一部である発見可能なコンテンツを構築していることに気付きました。人々はドキュメントや、AからBに到達する方法に関する興味深いコンテンツを求めています。アプリケーションを構築したい場合、Cloudアカウントの取得方法、コンパイルやデプロイのプロセスを理解したいだけです。再利用可能なコンポーネントがあれば素晴らしいのですが、ガバナンスやセキュリティを含む、再利用可能なコンポーネントと互換性のための信頼できる一貫した場所が必要です。
私たちのミッションでは、プロダクトチームがプロダクトを構築することをいかにシンプルにするかに焦点を当てました。私たちが望むのは、良いビジネスプロダクトを生み出すことであり、必ずしもAWSのエキスパートになることではありません。そこで私たちはプラットフォームの構築を始めました。 プラットフォームを切り分けて見方を変えると、テクノロジー、人、プロセスという三角形として見ることができます。テクノロジーとは、適切な場所で適切なテクノロジーを使用することを意味します。例えば、Developer Portalを使用していました - BackstageとSpotifyには素晴らしい仕事をしていただき、感謝しています。私たちはそれらのPluginやGolden Pathsの美しい構築の初期採用者でした。これから話すことですが、私たちはそれらをBlueprintと呼んでいます。アプリケーションをProductionに移行するのを助けるPipelineです。そしてもちろん、そこにAIを少し加える必要があります。
人の側面は興味深いものです。開発者は一つのやり方でものごとを行ってきました。新しいことを始める時、快適なゾーンを作りたいものです。心理学者が言うところの「リアクタンス」を生まないようにするためです。快適なものを奪われると人々は閉じこもってしまいます - 彼らはあなたのプロダクトを信頼して使う必要があります。私たちにはコミュニティで構築されたもの、コンセンスの形成、そしてToyotaで私たちが「なわひ（Nawahi）」と呼ぶものがあります。週次のCloudEdの時間があり、オープンソースプロダクトと同様に、十分にドキュメント化されたプロダクトがあります。私たちは内部プロダクトも同じ厳密さで扱うので、誰かがBlueprintのようなものを使おうとする場合、誰かに電話する必要なく始められるだけの十分なドキュメントがあるはずです。
プロセスは極めて重要です - プロジェクトやソフトウェアを構築する自然な一部として人々が認識できるような計画や構築メカニズムです。インセプションと計画の段階で、予算やリソースへのアクセス方法を理解するためのフックの作成について話しています。単に「プラットフォーム」と言っても多くの人は理解できないので、私たちはそれにブランドを作りました - Choferと呼んでいます。これはToyotaの自動運転プログラムから来ていますが、英語のスペルが長すぎるのでスペイン語のスペルChoferを使用しています。財務チームや全員が私たちが何をしようとしているのかを理解できるようにしました。FinOpsは大きな課題であり、コンプライアンスと監査も間違いなく重要な要素です。
Choferの内部構造とプラットフォームチームの役割
それでは、私たちがこれらの課題にどのようにアプローチしているのか、内部を見ていきましょう。Platformチームとはどのようなものでしょうか？
まず、Subject Matter Expertが必要です。このユニコーンの画像を見て、きっと彼らは誇らしく思うことでしょう。彼らが何かを発言したり、ビジョンが設定されたりする際には、それを実行するLeadershipが必要であり、それを実装するエンジニア、そしてそのエンジニアをサポートするチームメンバーが必要です。この人数構成はピラミッド型になっており、強い技術力を持つマネージャーが必要です。これはエンジニア向けのProductとPlatformを構築しているので、マネージャーには技術的な強みと弱みを理解できる高い技術力が求められます。最も重要なのは、これをProductとして扱うTechnical Product Managerの存在です。なぜなら、この仕事は初日で終わるものではないからです。このPlatformをローンチした後も、他のProductと同様に継続的な改善が必要です。
そのため、私たちは毎年新しい機能をリリースしており、それに伴ってスキルも更新していく必要があります。何が良くて何が良くないのか、いつ何を使うべきかを判断し、ベストプラクティスに従い、素早く学び、素早く失敗し、そして効果的にコミュニケーションを取る必要があります。他のアプリケーションチームの声を聞き、対話することも重要です。これらが、私たちのPlatformチームに組み込んでいるスキルセットの一部です。もしこれらのスキルをお持ちでしたら、採用を行っていますよ。
先ほど、左側と右側が一緒になる必要があると言及したのを覚えていますか？ここでAccess Codeが重要になってきます。私たちが「すべての中心にいたくない」というビジョンを掲げ、セルフサービスとして提供したいと考え始めた時、それはPlatformの基本的な要件となりました。私たちは、ガードレールやセキュリティレール、そして2日目に発生する自動アップグレードを設定したいと考えています。例えば、古いバージョンのEBSで始めた人が、突然Graviton 3が利用可能になった場合、6ヶ月もかけて人々と話し合う必要があってはいけません。それはコードに組み込まれ、誰もが自然に利用できるようになるべきです。Access Codeと、SLA、SLO、SLI（Service Level X）を忘れないでください - これらはすべて、私たちがソリューションを提供する際の契約の一部となります。
チームの構成について説明させていただきます。私たちはTeam Topologiesという素晴らしい本を参考にしました。Productチームは私たちにとって非常に重要で、特定の事項に焦点を当てています。例えば、Chofer Portalは一つのProductチームです。何かを構築している2つのチームについて考えてみてください。同様に、Developer Experience PipelinesチームもProductチームですが、彼らは非常に焦点を絞っています。それぞれのロードマップがあり、重複はなく、各Productに対して単一の責任があります。もしIACを構築している別のチームのBlueprintをデプロイしたい場合、それは自動的にコードにデプロイされることはありません。通常の開発者と同じように、PRを通じて、通常行うリリースの全プロセスを経ることになります。
Product Roadmapが公開・更新され、それに合わせてOKRsが設定され、Jiraのタスクも連携されています。また、製品は先ほど言及した契約、つまり稼働時間やP1バグ、P2バグの修正にかかる時間を明示したSLAを保持しています。Product Lifecycleは非常に重要です。例えば、新しいServerless機能が登場した場合、それをBlueprintに組み込むタイミングはいつになるのか、そういったライフサイクルが明確に定められています。最も重要なのは、プロダクトチームに実際のユーザーとの対話を促していることです。エンジニアの主な業務ではありませんが、開発者が実際に使用している様子を聞き、同じエンジニアとして何が機能していて何を改善すべきかを直接聞くことは、彼らの責任の一つとなっています。
Enablementチーム、先ほど言及したSubject Matter Expertsのことですが、彼らは最前線で活動している専門家です。誰かが次の会計年度の予算を計画していて何かを実施しようとしている場合、これらの専門家が「これは良いBlueprintで、かなりの時間を節約できますよ」というアドバイスを提供しています。
そのため、予算は本来必要以上に膨らむ必要がありません。これは最初から考慮されています。根回しを通じてApplicationチームと協力し、私たち自身が得た新しい知見をチームに教育します。オンプレミスからCloudへのワークロード移行を担当するArchitectたちは、専門チームやSREです。
プロセスを見てみましょう。 財務は重要です - Financeチームを巻き込んで、これらがどのように機能するか理解してもらう必要があります。私たちは100%のChargebackを採用しており、請求書を支払った後、事業部門に費用を配分します。ShowbackかChargebackかに関係なく、どの企業にとってもお金は重要です。Financeチームを巻き込んで、OpExがどのように機能し、従来のオンプレミスのハードウェア購入とどう異なるかを理解してもらう必要があります。FinOpsのプロセスと計画を組み込んで、これらの仕組みやタイムラインについて全員が認識を共有できるようにします。
エンジニアリングプロセスについて、コンソールに入ってクリックで作業したいという要望がよくありますが、最初の回答は常に「コードについて話し合いましょう」です。6ヶ月もかかるような場合を除いて、コードとAutomationを優先します。これは自分のチームがアカウントのオンボーディングやその他の作業をする場合にも適用されます - まずはコードです。きちんと話し合いを行わない限り、Click-opsで進めることは認めません。私たちがリリースするすべてのServiceとProductには、独自のドキュメントが必要です。
プロダクトマネジメントは、お客様とのコミュニケーションにおいて重要な要素です。どのようなプロダクトでも、ビジョンを明確に示すことが大切です。私たちは、セキュリティとコスト最適化を備えたクラウドを、セルフサービスで利用・導入できる手段を提供するという、シンプルなビジョンを掲げています。これが私たちのプラットフォームの根底にある原則であり、このビジョンの実現とロードマップの整合性を確保したいと考えています。普及活動には、NPSを把握し、継続的に問題点を理解することが必要です。お客様からフィードバックを得て、同様にTech Radarを活用して、他者が既に実施したことを誰かが再度試みようとしている場合には、それを文書化します。
Chofer Portalの機能と実装例
Day2オペレーションは極めて重要で、教育もこの全体の一部です。プラットフォームチームだけが教育を行うのではなく、AWSの専門家を招き、時には彼らと協力して始め方を実演することもあります。例えば、ECSについて話す場合、他のチームがどのように使用したか、どのBlueprintを活用すれば目標に到達できるかを示すために、私たちも加わります。複数の専門家とのパートナーシップで仕事を進めています。最も重要なのは、ブログ投稿を通じて貢献を促し、Provisionedアプローチと Serverlessアプローチの違いなど、さまざまなアプローチでの経験を他者と共有できるようにすることです。
最も重要なのは、プロセスの観点から見て、これが共同責任であることを理解することです。私たちがBlueprintを構築し、皆さんがそれを使用できるようにコーディングする必要があることを理解してください。同じことが、これらすべての要素においてチェーン全体に当てはまります。
ポータルについて少し見てみましょう。Backstageについて話します。ポータルに対する私たちの見方とは？これがChofer Portalです。これが、シングルペインオブグラスを初めてお見せする機会です。
複数のシステムにアクセスする機会があります。セキュリティスコアカードの仕組みがあり、その様子を少しお見せしたいと思います。より詳しい情報が必要な場合は、そこをクリックしてソースに移動できます。コストトレンドと予算モニタリングについても同様です。予算を見ると、緑色になっており、順調であることを示しています。注目していただきたいのは一連の黒いバーです。これらはすべてプラグインであり、これがBackstageの力です。これらのプラグインは組織に合わせてカスタマイズでき、すべての人を巻き込むエコシステムを構築することができます。
そのプラグインの1つがBlueprintsで、これは私たちのGolden Pathsとなっています。例えば、Spring BootをECSにデプロイするためのBlueprintがあります。これには約12,000行のTerraformコードが含まれています。さらに、認証をサポートするためのLambda関数もあります。ここで話しているのはECSだけではなく、API Gateway、ファイアウォール、そして数多くのIAMコンポーネントを含む全体のアーキテクチャについてです。ポリシーが変更された場合は、このBlueprintを更新してバージョン2をリリースするだけで、このBlueprintを使用している全てのユーザーのPull Requestに反映されます。チームがCreateボタンを押すと、アカウント番号などの必要事項を入力するだけで、最終的に彼らのリポジトリへのPRとして作成され、そこから先に進めることができます。
ここで強調したい重要な点は、Well Architectedスコアです。これは、Platform TeamがSecurityチームや他のチーム外のメンバーと協力して、全ての評価が明確に示されたWell Architectedスコアを公開していることを示しています。これはエコシステムに必要な基準を満たしています。ランタイムを監視するツールや、可観測性のために使用する他のツールもあり、このBlueprintは様々なチェックボックスに準拠しています。
もう1つの重要な機能がCatalogです。何百ものアプリケーションがある中で、私たちは静的と動的の両方のビューを持っています。CMDBは静的なビューを提供しますが、私たちは動的なビューも維持しています。このページでは、開発したチーム、そのコード、CI/CDパイプライン、最新のステータスを確認できます。コードをチェックインしたチームやGitのグループを表示しています。これらがSource of Truthとなるからです。誰かがCMDBを更新しなくても（これは開発者の通常の活動範囲外です）、私たちは自動的に全てを集約します。誰かがAPIを使い始めると、依存関係が自動的にリンクされます。私たちは、静的ビューと動的ビューを統合して、この検索可能なCatalogを作成しています。
これは、顧客のニーズに応えるために構築した最も人気のあるプラグインの1つです。デフォルトのBackstageバージョンからカスタマイズしたもので、財務担当者のような非技術系スタッフから、エンジニア、そして経営陣まで幅広く使用されています。異なるペルソナごとに、それぞれの責任に合わせた異なるビューを持つことができます。アカウントやペルソナでフィルタリングでき、様々なタイムライン機能を操作できます。最も重要なのは、トレンドラインを予測し、目標に向かって順調かどうかを示すインテリジェンス機能です。これは非常に重要です。なぜなら、会計年度末に突然資金が底をつくような予期せぬ事態を防ぐのに役立つからです。トレンドラインがどのように推移しているかを確認でき、状況を把握できる月次メールも送信されます。また、このシステムにGenerative AIも組み込んでいます。約50のアカウントのうち5つが過去数ヶ月と比べて高いトレンドを示しているといった洞察を提供します。
これによって私たちのリーダーシップ間の対話が促進され、ChargebackかShowbackかに関係なく、重要な洞察とともに情報が提供されます。
最後に重要なのが、トレーニングとブログです。 これは2分程度の短い動画や記事、FAQなどに必要です。私たちは独自のチャンネルを持っており、Teams、Slackチャンネルなど、効果的なものを使用しています。質問が寄せられて共通の問題になると、自動的に検索可能なFAQとなります。Amazon OpenSearchを使用しており、最近人気のあるものや新しく追加されたものを自動的に見つけることができます。コンテンツの公開はソフトウェアの公開とは別に行っています。FAQを書ける人が書いて、別のリポジトリで簡単なレビューを受けた後、すぐに公開される仕組みになっています。
これらは常に最新の状態に保たれています。動画を作って放置し、6ヶ月後には陳腐化してしまうということはありません。コンテンツを常に最新の状態に保ち、新しく参加した人がすぐに使えるようにすることが重要です。大切なのは、 各ページにある - あのアイコンに気付いたかもしれませんが、電話で話している女性のアイコンはサポートを表しています。より文脈に応じたサポートを提供しています。適切なレベルのサポートを提供することで、質問の数が減り、採用がより容易になることがわかりました。究極的には、開発者の思考プロセスを妨げることなく、必要なものを使えるようにすることが目的です。
Backstageを活用したGenerative AIの実装と可能性
内部構造を見てみましょう。青い線や赤い線で接続されている配線図です。Brianの図を見たとき、私はこれを単純化する必要があると感じました。これがその単純化されたビューです。ご覧の通り、主にBackstageの一般的なモデルを使用し、他のユーザーのために公開されているBlueprintも使用しています。私たちは自社製品を積極的に活用しています。自社のチーム、自社のプロダクトチームが、他のユーザーと同じBlueprintを使用するようにしています。RDS Blueprintは他のユーザーのために公開しているBlueprintです。アップグレードが行われる際、これらがどのように機能しているかを私たち自身が最初に知ることができます。
最後に締めくくりたいことがあります。私たちは生成AIボットのChofer Archieを導入しました。「ソリューションはどこで見つけられますか？」や「私の問題に対するソリューションはありますか？」といった質問に対して、開発者が必要なBlueprintやドキュメントにたどり着けるよう支援しています。大量のドキュメントがある場合、検索が困難になるため、このように案内しています。最適なBlueprintへのリンクがそこに表示されます。このスクリーンショットは、これを実行するためのコストを示しています。実際には、様々なワークロードでこれらのBlueprintを使用している他のユーザーからのデータを基にしています。
セキュリティ要件の解決方法や、どのソリューションを使用すべきかについて誰かが質問すると、利用可能なBlueprintを見つけて表示します。開発者がこれを使い始めることを期待しています - これはかなり新しい機能です。Amazon Bedrockを使用して立ち上げました。 最後に、これらは実際の数字です。私たちが認識を新たにし、選択肢を得た時 - それは全チームを集結させた journey でしたが - 大きなコスト削減が実現し、その分を今年リリースされた収益を生み出すプロダクトに振り向けることができました。40以上の承認済みTemplateがありますが、重要なのはTemplateの数ではなく、それらの質なのです。
RDSには、VPCについて深く考えることなく、HAやDRを含む様々な構成が用意されています。私たちは、テンプレートをコンパクトながらも充実した内容に保つよう心がけています。この取り組みの結果、開発者から直接フィードバックを得たところ、12週間もの時間削減を実現できました。さらに、早期に採用したチームは、アップグレードによって約40週間の追加削減効果も得られました。つまり、全体で52週間の時間削減効果があったということです。4人の開発者で計算すると、組織にとって大きなコスト削減となります。
おはようございます。最後に、Generative AIの部分についてより詳しくお話ししたいと思います。今週、皆さんがどこを見ても、この2つの言葉を目にされたことと思います。 ここでこのトピックを取り上げるのは、これが繰り返し話題に上がってきているからです。コンテナのスペシャリストとして、私は多くのAmazon ECSのお客様、Amazon EKSのお客様、そしてプラットフォームを構築している方々と話をしています。先ほど紹介したように、Platform EngineeringのユースケースにGenerative AIを適用し、そこでの課題を解決しようとする実践的な取り組みが始まっています。
私たちは、Generative AIの可能性のあるユースケースすべてを、Platform Engineering特有の繰り返し発生するユースケースに絞り込もうとしています。1つ目は実現性（enablement）です。開発者がドキュメントを検索し続けることなく、特定の質問に対する答えを得られるようにすることです。2つ目は、運用、セキュリティ、コストに関連する問題の解決で、過度な労力をかけることなく、より迅速に解決に到達できるようにすることです。 先日、私たちのコンテナソリューションアーキテクトの1人がOutshift by Ciscoと話をする機会がありました。QRコードは、このセッション後に添付されるスライドに含まれています。彼らはYouTubeで素晴らしい具体的なデモを公開しており、私たちのソリューションアーキテクトの1人と一緒に視聴できます。彼らは、JiraやGitHubのイシュー作成から、ナレッジベースに基づく質問の理解まで、様々な機能を実装しています。
なぜ、ここで話している内容にBackstageが有用なのでしょうか？これらの機能を実装する方法は多々ありますが、Backstageには特別な利点があります。まず、先ほど紹介したカタログには、ワークロード、開発者、チーム、そしてそれらの関係性について豊富な知識が含まれており、これらのモデルが活用できる優れたコンテキスト情報を提供します。次に、先ほど見たすべてのプラグインが、プラットフォームの様々な部分にアクセスできます。最後に、開発者は既に毎日ポータルを使用しているはずです。 もし使用していないのであれば、使用するように促す必要があります。これにより、開発者が既に作業しているはずの場所に、これらの機能を構築する絶好の機会が得られます。
多くのお客様は、シンプルなところから始めます。そして、そこに留まる場合もあるでしょう。 Backstageでの実装に関して、いくつかのプラグインが登場してきています。実装は簡単です。Backstageの拡張性を活用して、ブラウザにインターフェースを公開するReactを使用したフロントエンドプラグインを構築します。ユーザーがプロンプトを作成すると、そのプラグインはBackstageのバックエンドプラグインにそれを送信し、そこで追加のシステムプロンプトでコンテキストやユーザーIDを追加し、すべてを集約してAmazon Bedrockなどのバックエンドのモデルに送信します。
実際の問題解決のために、BackstageとAWS Security Hubを連携させる方法を示すデモプラグインを用意しました。このプラグインは、特定のワークロードに関するセキュリティ上の発見事項をタブで表示し、その特定のアプリケーションに関する発見事項のみを示します。これらの発見事項は、集計処理を行わずにAWS Security Hub APIから直接取得されます。開発者として解決すべき問題として、 Amazon ECSコンテナが適切なファイルシステムの制限なしで実行されることを許可してしまっている、という重大度の高いセキュリティ上の発見がありました。
具体的には、ECSコンテナにファイルシステムへのフルアクセスを許可してしまっており、これは修正が必要です。既存のシンプルなアーキテクチャを使用すると、基本的な機能は得られます。質問をして回答を得ることはできますが、本当に有用な情報が得られているのか、詳しく見ていきましょう。
最も面倒な点は、タスクを取り上げ、プロンプトを作成し、ある画面から別の画面に情報をコピー＆ペーストしなければならないことです。これまでの文脈の多くが失われてしまいました。システムは私がどのワークロードについて話しているのかを把握できていません。ECSを使用していることや、この場合はTerraformを使用してインフラを構築していることを、わざわざ伝えなければなりませんでした。ここでは多くの作業が必要で、これは理想的ではありません。回答に関して言えば、この回答は正しいものです。この回答を適用すれば、問題は解決されるでしょう。しかし、この架空のシナリオでは、私たちのプラットフォームチームは、多くの企業と同様に、開発者が使用するための事前パッケージ化されたTerraformモジュールを作成しています。開発者は直接Terraformプロバイダーとやり取りすることはありません。そのため、この回答は正しいものの、これらのLLMを基本的なアプローチで使用する多くのツールと同様に、実際には使用できません。プラットフォームの実態を反映していないからです。
Backstageは、Backstage Conで「ネクサスシステム」と呼ばれているのを耳にしましたが、これは適切だと思います。Backstageはプラットフォームのさまざまなコンポーネントとつながっています。CatalogやSearch、TechDocsなどのコア機能間のプラグインは、CI/CDパイプラインを表示したり、コスト情報を表示したりするかもしれません。多くの場所とのつながりがあり、より良い回答を得るために活用できる情報が豊富にあります。
私たちが検討している手法の1つは、Tool UseやFunction Callingと呼ばれる方法を通じて、BedrockのClaudeのようなベースモデルを拡張することです。これらのモデルにコンテキストを追加するには、検索による拡張生成やモデルのファインチューニングなど、さまざまな方法があります。私たちがToolsに注目しているのは、興味深い特性があるからです。このメカニズムでは、モデルは必要な追加コンテキストを特定し、それをどこから取得できるかを判断する責任をより多く担います。また、私たちに代わってアクションを実行することもできます。
このメカニズムを探求している人々を目にしていますが、基本的に従来のアプローチと比較すると、プロンプトに「Tool定義」と呼ばれる利用可能な機能セットを追加し、それらを一つにまとめてモデルに送信します。すると、モデルは与えられたツールを使用してタスクをステップに分解する Chain of Thoughtのようなアプローチを適用します。APIの呼び出しや検索、天気の取得、イシューの作成など、それらのアクションの実行が必要な場合、モデルはそのツールの呼び出しを要求します。私たちはモデルにレスポンスを返し、モデルは最終的な回答をユーザーに送り返すまで処理を継続します。
これは一部のモデルが実行できる強力なメカニズムです。Claudeはその好例であり、今週AWS re:Inventで発表したばかりのNovaも同様です。Backstageにおいては、このアーキテクチャにツールを実装することになります。 これらのPluginをモデルに公開し、素晴らしい機能を持つPluginがすべて利用可能だと伝えます。モデルがCatalogの検索やドキュメントの検索、Jenkins CI/CDの実行結果の取得を必要とする場合、それらを実行することができます。これにより、モデルはオープンソースのものとSpotifyが提供するものの両方を含む、Backstageを通じて既に持っている素晴らしい統合機能をすべて活用して回答を構築できるようになります。
この新しいアーキテクチャを追加した後で、私たちのタスクを見直してみましょう。もう少し詳しく見ていきましょう。最初に実現できたことは、 質問の仕方を完全に変えられるということです。自分のマイクロサービスについて質問できます - Carts APIマイクロサービスを確認できます。ECSを使用していることやTerraformに関することを明示的に伝える必要はありません。Catalogの項目を質問の中で直接参照でき、Security Hubの検索を指示することもできます。ある場所から別の場所に情報をコピー＆ペーストすることなく、検出結果を直接参照できます。
回答に関して言えば、既存のPluginを再利用してSecurity Hubを呼び出し、検出結果を取得し、それを使用して回答を導き出しています。これはAPIからリアルタイムで取得された実際のデータです。知識ベースにデータを入れるためのRAGは行っていません - データは直接APIから取得されるため、 構築が非常に簡単です。そして最後に、回答は内部プラットフォームのドキュメントをすべて追加したBackstageのTech Docsから情報を取得しています。
カスタムTerraformモジュールを参照し、読み取り専用ファイルシステムを使用するためのフラグを設定できるという実行可能な回答を提供しています。これは、以前の回答と比べて正確で実行可能です。以前の回答は、私たちのカスタムTerraformモジュールがそのような方法では動作しないため、実際には使用できませんでした。これらすべてのツールを活用し、Backstageとそのすべての統合機能を使用することで、 モデルの組み込み知識に頼るだけでなく、プラットフォームとユーザーにとってより関連性の高い実行可能な回答を構築することができました。
私たちが顧客の間で見てきたもう一つの傾向は、Prompt Engineeringという課題を回避しようとする動きです。これらのプロンプトを作成し、適切な質問を投げかけることは、かなり難しい作業です。練習と経験が必要で、Prompt Engineeringは本当に大変です。考慮しなければならない要素が多いのです。そこで、最近では別のアプローチを取る組織も出てきています。それは、Backstageのフローの中にGenerative AIを組み込むというものです。チャットボットを使う代わりに、プラグインに直接ボタンを追加して、すぐに実用的な回答を表示させるのです。Amazon Qをコンソールでお使いの方なら、トラブルシューティングボタンを押すとチャットボットに入力することなく回答が表示される機能をご存じかもしれません。Backstageユーザーの中には、これを社内で自主的に構築している例も見られます。このアプローチでは、ユーザーがPrompt Engineeringを理解する必要がありません。構造化された回答を提供でき、より実用的で理解しやすい形で情報を提示できます。また、より直接的なアプローチなので、キャッシングなど、さまざまな興味深い機能をバックエンドに実装することができます。
このプラグインは今週、AWSのCommunityリポジトリの一部としてGitHubでリリースする予定です。先ほどご覧いただいた基本的なチャットアシスタントの機能と、Backstageにより直接的に組み込めるような誘導型フローを構築するためのツールを提供します。これにより、別途30分ほど話せるような様々な興味深い機能が利用可能になります。私たちは、Platform EngineeringにおけるGenerative AIとBackstageの組み合わせを試してみたい方々に、クイックスタートとしてこれを活用していただければと考えています。Toyotaのように、より本格的なアーキテクチャ構築に投資している組織もありますが、このプラグインが、試験的な導入から始めて、さらなる可能性を探るきっかけになればと思います。
Platform Engineeringにおける重要ポイント
では、ここで主なポイントを振り返って、まとめに入りたいと思います。これら3つのポイントが、先ほどの事例と合わせて皆様のお役に立てば幸いです。まず、Platformの戦略の一部としてのセルフサービス - これは基本中の基本です。先ほど申し上げたように、自動化を第一に考え、セルフサービスを重視する - 全ての相談が中央チームに集中するような形は避けるべきです。次にネットワーク効果が非常に重要です。実際に作業を行うチームと対話し、その専門知識を製品に取り入れていくことが大切です。そして最も重要なのは継続的な改善です。どんな製品も一度作って終わりということはありません。Day 2の運用は常に続いていくものですから、これは長期的な取り組みになります。これらが確実に実施されているか確認してください。以上が、本日の講演から皆様に持ち帰っていただきたい重要なポイントです。これらの内容を共有できて大変嬉しく思います。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion