re:Invent 2024: AWSとGlobalization Partnersが語るPlatform Engineering
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Balance consistency and developer freedom with platform engineering (SVS208)
この動画では、大規模なソフトウェア開発における開発者の自由と運用管理の一貫性のバランスについて、AWSのSenior Serverless SpecialistのMatthew MeckesとDirector of Specialist SAのRoland Barcia、Globalization PartnersのDave Andersonが語ります。Two-pizzaチームの概念からTeam Topologiesモデルへの発展、Well-Architected Frameworkの実践的な活用方法、Platform Engineeringの具体的な実装例が紹介されます。特にGlobalization Partnersでの事例では、Event Stormingから始まり、EventBridge、Lambda、DynamoDB、API Gateway、Step Functionsを活用した実際のワークロードアーキテクチャまでの過程が詳しく解説されており、Platform Engineeringの実践的なアプローチが示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSエキスパートが語る大規模ソフトウェア開発の課題
みなさん、こんにちは。Mandalay Bayまでお越しいただき、re:inventの最終日のセッションにご参加いただき、ありがとうございます。本日は、大規模なソフトウェア開発における最も困難な課題の1つについて考えていきたいと思います。それは、開発者がイノベーションを起こし、新しいことに挑戦し、顧客に価値を届けるために必要な自由と、規模を拡大しながら効率的に運用・管理していくために必要な一貫性のバランスをどう取るかということです。私はMatthew Meckesと申しまして、AWSのSenior Serverless Specialistを務めています。私自身、JavaやNET開発者として長年開発に携わってきました。今日は、従来型のモデルからクラウドへの移行における私の経験についてお話しさせていただきます。
続いて、同僚のRoland Barciaに引き継ぎます。彼はAWSのDirector of Specialist SAおよびTechチームのディレクターを務めており、インフラストラクチャーの進化と、これらの要素をどのように統合していくかについてお話しします。最後に、Dave Andersonが登壇します。彼はGlobalization Partnersで、サービスファーストで Well-Architectedなプラットフォームエンジニアリング文化を構築する素晴らしい取り組みを行っています。RolandとPrivate私が話す理論的な部分を、GPでどのように実践に移しているかをご紹介します。
今年はピンバッジを付けています。LambdaとECSの10周年記念です。これらのサービスを立ち上げる2年前、Werner VogelsはAWSのKeynoteで大胆な発言をしました。「将来的には、ビジネスロジックだけを書くことになる」と。私たちAWSが目指してきたことの多くは、エンタープライズアプリケーションを構築する上で必要な差別化されていない重労働について考えるのではなく、本当に顧客に価値を提供する部分に注力できるようにすることです。
クラウド時代の運用モデルとDevOpsの進化
私たちが話しているのは、運用モデルの進化についてです。私がキャリアを始めた頃は、コードを書くアプリケーション開発チームと、私が所属していたインフラチームという、2つの明確に分かれたグループがありました。私はJavaアプリケーションを書き、jarファイルをコンパイルし、場合によってはデータベーススクリプトも作成して、インフラチームの人たちに渡していました。そして彼らがそれらのアプリケーションを実行し、ハードウェア上で管理していました。 Serverlessの革命により、これらのチームの役割が変化しました。私たちは、ハードウェアやインフラストラクチャー、クラウドデータベースの利用に関する責任を担うようになりました。
これはDevOps革命と歩調を合わせて進んできました。Amazonでは「Two-pizzaチーム」についてよく話題に上がります。これは、開発者とオペレーション担当者、DevOps担当者が混在する小規模で機動的な分散チームで、単一の目標に焦点を当て、構築と運用において大きな自律性を持つという考え方です。 キャリアを始めた頃、私はコードを書いてjarファイルをコンパイルし、実行してもらうために引き渡すだけでした。 その後、Continuous IntegrationやContinuous Deliveryを行い、機能をビルドしデプロイするスクリプトを書くようになりました。 現在では、自分の機能を自分でデプロイし、その責任を負い、自分のスケジュールで実行しています。オンコール当番に入り、クラウド上のこれらのシステムの面倒を見るようになりました。
セキュリティモデルはクラウドとともに変化し始めました。以前は、セキュリティチームがペリメーターで考慮すれば良く、ネットワークにデプロイする限り問題なかった世界から、開発者である私たちが考慮しなければならない世界へと変わりました。アプリケーションの異なるモジュール間できめ細かなアクセス制御を行うために、どのようなIAMポリシーを使用するかを考える必要が出てきたのです。 コストも、インフラチームが考えることから、開発者である私たちが考えなければならないものへと変わりました。効率的にリソースを使用できているか？数千のLambda関数を使用する代わりに数個で済ませられないか？そしてもちろん、2024-2025年の今、私たち全員が責任を持って、持続可能なコードをどのように実行するかを考えなければなりません。Gravitonを使用しているか？環境に優しいデータベースモデルを使用しているか？
ビジネスロジックだけを書けばいいという約束 - 突然Serverlessの世界に入り込んで、これまでになかった新たな認知負荷を抱えることになりました。コードをデプロイする必要があります。これが本当の課題です。その対処方法は複雑で、解決策の一部はPlatform Engineeringから来ています。 イノベーションのための組織作りにおいて、Two-pizzaチームを持つというのは素晴らしいアイデアですが、それだけでは十分ではありません。考慮すべき他の要素として、文化はどうか？適切な人材を採用しているか？実験や失敗が許され、自信を持って取り組める環境（心理的安全性）をどのように提供するか？といった点があります。
これを実現するために、どのようなアーキテクチャを提供し、どのようなブループリント、ツール、テクノロジーを使用すれば、迅速なイノベーションが可能になるかを考える必要があります。その中でも特に強調したい点がいくつかあります。その一つがメカニズムです - 認知負荷が広範に及ぶ中で、エンジニアの導入をどのように容易にし、本当に気にすべき部分を抽出し、気にする必要のない部分を自動化できるでしょうか？Two-pizzaチームの概念を超えて、これらの組織は実際にどのような姿になるのでしょうか？チームをどのように構成し、チームの機能や相互作用のモードをどのように設定すればよいのでしょうか？
Well-Architected Frameworkとチーム構造の重要性
メカニズムの一つとして、Well-Architected Frameworkは非常に価値があると考えています。 Frameworkの柱を見ると、現代のクラウド開発者が負う認知負荷の一部となるトピックすべてと整合しています。多くの人々はWell-Architected Frameworkを、本番環境にリリースする前に年に一度実施しなければならない監査のようなものと考えています。その結果、十分にWell-Architectedではないと叱責されるわけです。しかし、この考え方を改め、新しいチームのオンボーディングの際に、これらの柱をライフサイクルの実現可能な部分として組み込むべきです。チームがセキュリティ脅威モデリングを行っていない場合、どのようにそれに慣れるようコーチングできるでしょうか？開発者がすべての柱にわたる幅広い知識を得られるようにするにはどうすればよいでしょうか？後ほどDaveが、GPでの取り組みについて話す際に、アジャイルデリバリープロセスの一部として、Well-Architectedをどのように軽量な方法で活用しているかについて詳しく説明します。これは非常に強力なプロセスで、多くの認知負荷を軽減します。
また、Two-pizzaチームの概念も発展させる必要があります。Two-pizzaチームは非常に重要で、革新的なソフトウェア文化において成功するための大きな要素です。以前のVPのDave Limpは素晴らしい言葉を残しています：「何かを失敗したければ、誰かのパートタイムの仕事にすればいい」。Two-pizzaチームは、まさにそれを避けようとしているのです。私たちは何をすべきかを正確に理解し、その成果物に焦点を当てていますが、成功に必要なすべてがそこにあるわけではありません。私は、これがTeam Topologiesモデルにどのように適用されるかについて考えるのが好きです。プラットフォーム文化を構築しているため、多くの人々がこのモデルを採用し始めているのを目にします。
Stream-alignedチームが顧客価値の一部分に焦点を当てる一方で、直接的な価値の流れからは少し離れた、より抽象的なComplicated Subsystemチームも必要になることがあります。例えば、高度な数学的処理が必要な場合や、他のチームが依存する複雑な国際決済システムなどが該当します。そういったものは、サブシステムとして分離し、サービスモデルとして提供することで、他のチームが多くのミーティングややり取りなしに利用できるようになります。また、私はEnablingチームという考え方も気に入っています。Enablingチームは、各チームがクラウドでの作業における成熟度を高めていく過程で、コーチとしてサポートする役割を担います。例えば、セキュリティの専門チームが脅威モデリングを実施しながら、同時に各チームが自身で脅威モデリングを行えるようコーチングするといった具合です。
Team Topologiesモデルには、4つの基本的なトポロジーがあります：Stream-alignedチーム、スキルアップを支援するEnablingチーム、Complicated Subsystemチーム、そしてPlatformチームです。Platformチームの詳細についてはRolandが詳しく説明してくれるでしょう。これらの基本的なチームは、変更のフローを改善することを目的に設計されています。私たちが目指すのは、スケールする際に、これらのチームがアイデアから顧客への提供まで、左から右へできるだけ速やかに届けられるようにすることです。これは全て「You build it, you run it」を実践するStream-alignedチームを成功に導くための仕組みなのです。
これらのチームが他のチームに作業を引き継いだり、プロセスの途中で本番環境への移行や脅威モデリングを別のチームに依頼したりするのではなく、プロセス全体を自分たちで所有することが非常に重要です。他の全ては、彼らの能力を高め、スキルを向上させ、そしてその全行程の完全な所有を可能にすることが目的です。また、チーム間のインタラクションモードについても慎重に検討することが興味深いポイントです。Team Topologiesモデルでは、3つのインタラクションモデルしかありません：同じプロジェクトで協力して何かを提供するCollaborationモード、もしくはサービスとして提供するモードです。サービスとして提供する場合は、できる限りセルフサービス化し、他のチームが多くのミーティングや議論なしに利用できるようにすべきです。Developer Portalにアクセスし、ドキュメントを確認して自分たちのサービスに統合できるようにするのです。
あるいは、Facilitationモードとして、他のチームが機能を提供できるようコーチングを行います。これは全て、アプリケーションチームが迅速なイノベーション、アジリティ、フィードバック、そして新しいサービスを提供できるようにすることが目的です。
インフラ担当者の視点：開発者との協調と課題
もちろん、私の同僚のRolandは一貫性とインフラストラクチャ、そして私たちの安全性確保について非常に関心を持っています。そこで、このパズルのその側面について彼に話してもらいましょう。みなさん、いかがお過ごしですか？今夜のコンサートを楽しみにしていますか？WeezerとDJ Z - 私は誰なのかわかりませんが、年齢がバレますね。インフラ担当者として、楽しみにできることが必要です。日中、開発者のMattから多くの反感を買うことがあります。なぜなら、時として相反する目標を持っているように見えるからです。彼は新しいアプリケーションを構築し、クラウドに素早くデプロイしたいと考え、常に新しいことをしたがっています。一方で私は、パフォーマンス、セキュリティ、コンプライアンス組織が持つ一貫性の基準といったことを考慮しなければならないのです。
私たちはよく、相反する懸念事項を抱えています。彼も同じような懸念を持っているわけですが、私はアプリケーションをサポートするために必要なインフラ全体の観点から考えなければなりません。Mattのアプリは、それぞれが異なるデータベースを使用しています。なぜ同じものを使えないのか理解できません。彼はQueueやTopicを使いたがります。これらはすべて異なるセキュリティとスケーリングのニーズがあるため、私は彼を制限して、チケットを発行するようなプロセスを踏ませなければなりませんでした。問題は、彼だけではないということです。彼は自分のアプリが組織で最高だと思っているのです。しかし、私たちには多くの異なるチームがあり、彼らは私に殺到してきて、私がボトルネックになってしまっているために、多くの不満を受けることになります。
私の組織では、新しいことがたくさん起きています。AIアプリケーションやJupyter Notebookを構築したいと言ってきます。データへのアクセスさえ与えてくれれば、この複雑なバッチ処理や並列データ処理を実行したいと言います。そして突然、GPUの請求書が届き、さらにはそのGPUが見つからなくなってしまいました。そのため、今度はGPUについても心配しなければなりません。新しいタイプの自動化やデータパイプライン、処理が次々と出てきています。これらのアプリケーションに関して、ステートフルな要素が非常に多くなってきているのです。
私たちは、DevOpsがあれば全ての問題が解決するという考えに至りました。CI/CDプロセスさえあれば、組織はスムーズに運営され、すべてのアプリケーションがデプロイされるはずです。そしてDevOpsがこれらを処理し、ツール群を標準化することになります。そして、Infrastructure as Codeを使って、自動化を追加できます。CloudFormation、CDK、Terraformなどを使用してインフラストラクチャをプロビジョニングできます。これで、異なるアプリケーションを持つチームが私のところに来る代わりに、自動化されたプロセスを持つことができます。
問題は、私が管理しなければならないものが多すぎることです。ビジネスは新しいものや新規事業を生み出しているアプリケーション開発チームにすべてのリソースを与えます。多くの場合、これらのPlatformチームはコストとして見られ、仕事を進めるために必要な存在として扱われます。私は協力的でありたいと思います。彼が自律性を求めていることも、自由を望んでいることもわかっています。そこで、私たちは左シフトを行い、これらの開発チームにより多くのコントロールを与えます。そして、MattはClick OpsやCI/CDを使ってアプリケーションを構築し、多くのものを手に入れます。彼は下の方で緑色になっています。しかし、もちろん、この自由を与えると、今度は様々な種類のツールチェーンとパイプラインが出てきます。ある組織はKubernetes EKSと呼ばれるものを使用しています。彼らはGPUを使用したいと言い、Argo CDというタコのような見た目のものやFluxなどの異なるツールを使いたがります。そして別のチームは、Jupyter Notebookを構築していて、これらのデータモデルをデプロイするためのMLOpsパイプラインが必要だと言います。そのため今では、多くの異なるワークフローを管理する必要があり、デプロイメントプロセスの進行状況を把握できなくなることがよくあります。
開発者たちはYAMLやJSONを使用してアプリケーション設定とともにコードを開発し、アーキテクチャのGitリポジトリを持ち、Kubernetes、Lambda、ECSにデプロイする可能性があります。リソースのためのチケットシステムがあり、データベースチームはTerraformでプロビジョニングを行っています。組織でTerraformを標準化できたとしても、異なるチームが分断されたワークフローを持っているという状況は依然として存在します。
Platform Engineeringの実践：G-Pの事例から学ぶ
開発者、データサイエンティスト、データエンジニアの間で、自由度と標準化のバランスを取りながら、システム全体のセキュリティ、パフォーマンス、コスト最適化、可観測性を確保するにはどうすればよいのでしょうか。もう1つの課題は、これらのプロジェクトすべてが同じタイムラインを共有しているわけではないということです。チームがまだ異なるLarge Language Modelを評価し、どのようなアプリケーションを構築するか検討している初期段階のプロジェクトもあれば、アーキテクチャの決定を行い構築を進めているものもあります。スケールアップの段階では、顧客がこれらのアプリケーションを使用し始め、顧客が増えるにつれてSLAを改善し維持する必要が出てきます。最終的には、アプリケーションを廃止する一方で、15年前に書かれたアプリケーションをマイクロサービスに分解したり、Stranglerパターンを使って新しいサービスとして書き直したりすることもあります。
私たちは、異なるタイプの組織が異なるレベルで運営されているのをよく目にします。スタートアップは非常にスクラップ的で自律性が高く、インフラストラクチャやプラットフォームチームが開発チームと同一であることが多いです。金融や公共セクターのような規制の厳しい業界の企業では、より標準化が進む傾向にあります。ここ数年で台頭してきた概念の1つがPlatform Engineeringです。Platform Engineeringとは、プラットフォームをユーザーを持つアプリケーションのような製品として捉えることです。そのユーザーとは、ワークフローやAPIを作成する開発者やデータサイエンティストであり、セキュリティが標準で組み込まれた自動化をAPIとして利用できるようにすることで、開発者により多くの自律性とセルフサービスを提供します。
私の出身地であるJerseyには世界最高のピザがありますが、そこで生まれた「2枚のピザチーム」というコンセプトがここでもうまく当てはまります。プラットフォームチームは、開発者向けにAPIとしてプラットフォームを提供し、イネーブルメントチームの一部として機能する、もう1つの2枚のピザチームとして機能します。プラットフォームスタックの構成については、企業が選択する標準の種類によって構築方法が異なります。一般的に、セキュリティ、コードのデリバリー、可観測性、テナンシー、ネットワーキング、使用するサービスの種類、アカウント戦略のランディングゾーンなど、同様の要素をカバーしています。
Infrastructure as Codeのベストプラクティスは重要な考慮事項です。一般的にDeveloper Portal、Data Science Portal、Internal Developer Portalと呼ばれているものについて見ていきましょう。これらは開発チームが簡単に利用できる自動化のためのユーザーインターフェースを提供し、サードパーティのカタログも含まれています。
プラットフォームチームは、いくつかの重要な課題に直面しています。大きな課題の1つは所有権です。プラットフォームは、製品を所有して提供する専任のプロジェクトチームというよりも、サポート機能として見られがちだからです。プラットフォームに対して単一の責任者を持つ所有権の考え方を持つことが重要です。開発者とプラットフォームの間の抽象化レベルも課題の1つです。実装アプローチについて人々は自然と意見が分かれるためです。特定のサービス、クラスター、またはCode as a ServiceプラットフォームとしてのPlatform as a Serviceを提供するかどうかを決定する必要があります。組織ではこれらのオプションについてよく議論が行われています。
採用面での課題もあります。チームは多くの場合、プロダクトマインドセットを持たずに内部プラットフォームを構築し、そのプラットフォームを使用する開発者やData Scientistとの協力が不足しています。私が関わったあるお客様は、標準を適用するための中央プラットフォームの構築に何年もかけましたが、ワークフローを考慮していなかったため、事業部門から抵抗を受けました。プラットフォームを構築して多くのものを抽象化することもありますが、本番環境で問題が発生した際、開発者が環境に関する特定の知識を必要とするため、トラブルシューティングが複雑になります。チームは多くの場合、構築については考えますが、運用については考えていません。
これらは、お客様がよく採用するデザインパターンの例です。Account as a Serviceは、AWS Organizationsの戦略を確立し、異なる事業部門にアカウントを配布する方法を決定し、適切なガードレールとコスト管理を実装する上で重要です。Template as a Serviceはこれらの自動化を提供し、Cluster as a ServiceはEKS、Kafka、またはSparkジョブやMLワークロード用の特殊なクラスターを提供します。Platform as a Serviceはコードタイプの環境に重点を置き、JavaやPythonなどの言語での展開ユニットを提供します。
内部プラットフォームの様々なバリエーションが見られています。最近、AppsFlyerと一緒にプレゼンテーションを行い、彼らはマイクロサービス用のデフォルトプラットフォームの構築について話しました。誰かがマイクロサービスをデプロイすると、デフォルトのインフラストラクチャとクラスターに配置されます。しかし、分析機能を必要とするユーザーもおり、プラットフォーム内で異なるインフラストラクチャ要素が必要になります。彼らは特定のMLやDataプラットフォームを作成しており、業界固有のプラットフォームも登場しています。覚えておくべきベストプラクティスの1つは、新しいイノベーションのためのエスケープハッチを構築しながら、優れたデフォルトパターンを持つことです。
マルチアカウント戦略を適切に設定することが重要です。これには、事業部門による分離や、SandboxやDevelopment環境などのワークフローの考慮が含まれます。 プラットフォームの一部としてDeveloper Portalを使用することが新しいトレンドの1つとなっています。Spotifyによって作成されたBackstageは、Cloud Native Computing Foundation内で人気のあるDeveloper Portal技術です。 ソフトウェアカタログ、テンプレート、ベストプラクティス、Documentation as a Service、テンプレートのプロビジョニング用のフックポイントなど、多くの有用な機能を提供します。Backstageは、プラットフォームにプロダクトの顔を提供するために頻繁に使用されています。
ここで、Dave Andersonにバトンを渡したいと思います。まだ若輩者ですが、約15年前、私のキャリアの初期に、彼の事業部門をサポートするためのJavaミドルウェアインフラストラクチャと統合ミドルウェアインフラストラクチャを構築するプロジェクトでDaveと一緒に働きました。そして15年後、私たちはAWSで再び一緒に働いています。私にとって感慨深い瞬間です。それでは、Dave Andersonにお渡しします。
Value Flywheelと継続的改善のメカニズム
皆様、こんにちは。15年前、私たちは一緒に仕事をしていましたが、今日は私たちがまだ取り組んでいるメカニズムについてお話ししたいと思います。私はこの15年間、これらのメカニズムを考え出すことに時間を費やしてきました。その多くはPlatform Engineeringに関連するものです。私はDave Andersonと申します。 Globalization Partnersのディレクター・オブ・アーキテクチャーを務めており、Platform Engineeringに関する私たちの取り組みについてお話しさせていただきます。
また、私は「The Value Flywheel Effect」という本の著者でもあります。 この本はクラウドモダナイゼーションのハンドブックと呼ばれています。私とRohanは15年前にLiberty Mutualで一緒に働いており、私とMarkとMichaelは、Liberty Mutualという大企業でのService-firstストラテジーを推進する中で学んだ多くの教訓をValue Flywheel Effectとしてまとめました。本書には複数のケーススタディが含まれており、企業における現代的なクラウドへの移行に向けたモメンタムがどのように生まれるのかを実際に見ることができます。Simon WardleyとAdrian Cockcroftによる序文も付いており、Gene Kimのレーベルと同じIT Revolutionから出版されています。Team TopologiesやAccelerateと同じ出版社からの刊行です。
Value Flywheelそのものはとてもシンプルです。 主なアイデアは、ビジネスとテクノロジーの戦略を結びつけることです。私が常に不満に感じていたのは、ビジネスとテクノロジーを別物として語ることでした。これは一つのものなのです。ビジネスのニーズとエンジニアのニーズの力を結集できれば、そこからモメンタムが生まれます。4つのフェーズがあります。最初は目的の明確化です。私にとって、チームが自分たちが何を作っているのか本当に理解していないという状況ほど frustrating なものはありません。そのため、私が好んで使用するメカニズムの一つが North Star フレームワークで、チームが機能的・非機能的KPIを明確に理解できるようにします。
次のフェーズはチャレンジで、チームに心理的安全性を創出し、自分たちのワークロードと課題を所有していることを理解してもらいます。チームには完全な自律性があり、必要なことを行う権限があります。間違った形で制約されているチームほど良くないものはありません。その次は次のベストアクションで、私にとってこれはService-firstテクノロジー戦略です。チームができるだけ早く動け、フローを生み出し、長期的な価値を見出せるようにするにはどうすればよいでしょうか。チームが何かを作って、それを捨てなければならないような状況は避けたいものです。Well-Architected Frameworkを技術標準として使用することで、チームは品質の高いものを作ることができます。このように作業を可視化すると、慣性、つまり物事を遅らせる要因が見えてきます。このフレームワークのモメンタムが得られると、物事が本当に動き出すのが分かります。
現在、私はG-Pで働いています。G-Pはとても興味深い会社です。グローバル雇用分野で認められたリーダーです。G-Pの主力製品は Employer of Recordと呼ばれています。2年前、私はこれが何なのか全く知りませんでした。説明させていただきますと：例えば、アメリカの企業が私をアイルランドで、あるいは誰かをフランスで雇用したい場合、通常はその国に法人を設立し、その国のローカルルールをすべて理解する必要があります。Employer of Recordカテゴリーでは、G-Pのような企業にアプローチすることができます。アイルランドでも、オーストラリア、ブラジル、タイでも、どこでも構いませんが、その国で誰かを雇用したい場合、G-Pがその専門家のコンプライアンスに則った採用、給与報酬、福利厚生、保険、税金など、すべてを処理します。その人は企業の正社員となりますが、G-Pが追加的な法的雇用面のすべてを処理します。
これにより、世界中どこにいる人材でも採用できるようになります。G-Pはこのカテゴリーを創設した企業であり、だからこそビジネスの成長とともに効果的にスケールできることが魅力的なのです。100カ国以上に拠点があり、180カ国以上でサポートを提供しており、これがグローバリゼーションを本当に支えています。これが機能する理由の1つは、コンプライアンスとアドバイスを支援する多くのHRと法務の専門家がいるからです。現在、約40カ国に1,200人以上の従業員がおり、私たちはリモートファーストの企業として、自社のプロダクトを実際に活用しながら、そのシステムをスケールさせています。
私たちの大きな差別化要因はコンプライアンスです。これは技術面では完全にAWSを採用していることと、雇用面では専門家や契約社員の雇用と給与支払いを行いながらアドバイスを提供していることの両方に関係します。私たちは自分たちの行動に責任を持つ必要があります。これは非常に興味深い課題であり、間違いなく素晴らしい技術的チャレンジです。
Platform Engineeringについて話すとき、私が考えるのはプラットフォームの二分法です。アプリケーション開発チームとインフラストラクチャーチームの間には共生関係があります。お互いに対話する必要があり、一方が他方なしでは生存できません。この2つのチーム間には振り子のような揺れ動きがあります。アプリケーションチームが強すぎると、システムの運用に問題が生じます。インフラストラクチャーチームが強すぎると、開発チームが制約を受けることになります。この振り子のバランスを取るのは本当に難しく、だからこそコラボレーションが必要なのです。万能な解決策は存在しません。
Platform Engineeringのニーズに対応するには、システム全体を考慮する必要がありますが、私が言うシステムとはインフラストラクチャーやアプリケーションだけではありません。チーム、価値の定義、フローも含まれます。ソフトウェアを作る方法について、全体的な視点を持つ必要があります。優れたアーキテクチャがどういうものかという明確な基準が必要です。私にとって、それはWell-Architectedスタンダードです。何百人、もしかしたら何千人ものSolution Architectsがこのフレームワークにベストプラクティスを詰め込んでいるのですから、それを活用しない手はありません。私はアプリケーション開発チームが可能な限り速く進めるよう、制約や障壁をなくしたいと考えています。チームの速度を制限するのは、何をすべきかを見極めようとするProduct Managementだけであってほしいのです。技術的な問題は効果的に解決されている状態で、ビジネスの課題について考えることに時間を費やしたいのです。
これを4つのセクションで枠組みづけたいと思います。最初は、Gerald Weinbergが1985年に述べたこの言葉です：「最初はどう見えようとも、それは常に人の問題なのだ」。 Team Topologiesの著者の一人であるEmmanuel Paは、9月のFast Flow conferenceでこのプラットフォームマニフェストを共有しました。すべてを読み上げることはしませんが、Platform Engineeringのイベントで彼が最初に強調したのは、ツールや機能よりもチームとインタラクションを重視することです。これはTerraformスクリプトを書くことではなく、チームとインタラクションがどのように機能し、変化に対してオープンで、協力し合うかということです。これこそが開発とインフラストラクチャーの間の共生関係なのです。
Event-driven ArchitectureとDomain-driven Designの実践
Platform Engineeringの実際のユーザーが誰なのかを考える必要があります。これは、セルフサービスパターンを通じて社内のカスタマーの障壁を取り除くことに関するものですが、これは非常に達成が困難です。私の過去の経験では、Backstageが登場する前に、IDPを構築するための試みを何度か行いました。インフラ重視のアプローチを試みましたが、うまくいきませんでした。開発者重視のアプローチも試しましたが、これもうまくいきませんでした。本当に効果を発揮し、今も成功し続けているのは、セルフサービスモデルでした。
G-P内のシステムアーキテクチャについてお話しさせていただきます。4、5年前、私たちには複数の製品がありましたが、モノリスでした。Cloud-nativeで、すべてAWS上で、すべてコンテナ化されていました。ECS上でJava Spring Bootを使用し、RDSと連携した、かなりモダンなスタックのモノリスでした。しかし、異なる製品を作っていく中で、単一のデータモデルを使用していたため、チーム同士が互いの作業を妨げ合い、多くの衝突が発生していました。そこで、私たちはシステムの近代化を進め、実質的により Platform的なアプローチに移行しました。 まず、運用のオーバーヘッドを削減するために、Serverless-firstで行くことを決定しました。それを試してみて、どのように進めるべきか検討しました。
その後、組織全体でService-firstの戦略を実装しました。重要なポイントは、この下層の機能群においてDomainとEventドリブンであることでした。これらは私が言うところのコア機能、つまり実際にはドメインです。例えばCustomerについて考えると、Customerドメインには私たちのすべての顧客情報と主要な顧客サービスが単一のドメインに含まれています。そのドメインには複数のBounded Contextやワークロードがあります。単一のBounded Contextは単一のAWSアカウントにあり、そのCustomerドメインを所有する単一のチームが存在します。顧客に関連するすべてのものは、そのチームに属しています - 彼らはAPIコールを処理し、イベントを発行し、顧客に関連するイベントを受信します。彼らは完全に自律的なチームです。
次の層には、私が差別化要因と呼ぶものが含まれています。これらは、請求、支払い方法、価格設定、経費追跡、文書処理といった重要な要素です。これらは製品で使用される機能であり、つまり最上位レベルの製品フォーカスは、本当にこれらの機能の体験と調整に関するものになります。これらはすべて単一のチームが所有するドメインです。各ドメインは、作成時にWell-Architectedレビューを受け、その後も進化に応じて継続的なアーキテクチャレビューを受けており、すべてにおいてSaaSのマインドセットを持っています。
第2セッションでは、1984年のDijkstraのこの引用が気に入っています：「コンピュータサイエンティストの主な課題は、自分たちが作り出した複雑さに惑わされないことだ」。生涯のデベロッパーとして、私はおそらくもっとうまく対処すべきだった複雑さを多く作り出してきました。そこで、アプリケーションチームにはとてもシンプルな選択肢を提供しましょう。まず、Backstageについて話しましたが、私たちはBackstageをチームのための一元的なインターフェースとして使用しています。Developer Enablementチームがあり、彼らのチーム支援における優れた取り組みはすべて基本的にBackstageを通じて提供されています。チームが新しいワークロードを作成したい場合、ここにアクセスしてチェックボックスをクリックするだけで、Service APIのスキャフォールディング、パイプラインのセットアップ、アカウントのセットアップなど、すべてが自動的に処理されます。これは、すべてのドメイン、Bounded Context、チームを表示する一元的なインターフェースです。
私たちはサービスファーストの考え方を持っているので、自前でホストするのではなく、マネージドサービスとして利用したいと考えています。そこで、Roadieという会社が提供するBackstageをマネージドサービスとして利用し、必要な設定を追加しています。これが私たちのフロントドアであり、Developer Enablementチームと開発チームの協業ポイントとなっています。スキルの観点では、今日は素晴らしいものが作られ、発表されました。私はそれらを私たちのチーム向けにローカライズしたいと考えています。チームには業界のベストプラクティスを活用してほしいのです。AWSのサイトなどには、Event-Driven Architectureに関するベストプラクティスや優れたブログがあります。チームには、学習する際にベストプラクティスを参照し、業界標準を採用してほしいと考えています。
シンプル化に関して言えば、これはサービスファーストであってサービスオンリーではありません。チームが新しいワークロードを構築する際には、以下の6つのテクノロジーから始めてほしいと考えています：会社全体の単一のイベントバックボーンとしてのAmazon EventBridge、コンピューティングにはAWS Lambda、標準としてのWell-Architected、オーケストレーションにはAWS Step Functions、ストレージにはAmazon DynamoDB、そしてデプロイメントにはAWS Serverless Application Model。まずはこの6つから始め、商用パッケージ製品のような特別なニーズがある場合はAWS Fargateにフォールバックするか、異なる種類のストレージが必要な場合はそれを使用すればよいのです。要は、まずこの6つから始めて、必要に応じて進化させていくということです。
次に、FinOpsは非常に興味深いトピックです。これらのワークロードはそれぞれ独自のアカウントで運用されているため、エンジニアは自分たちのワークロードのコストを非常に具体的にトラッキングできるダッシュボードを作成できます。コストはアーキテクチャの反映です。効果的で効率的なワークロードであれば、それはコストに表れます。Wernerが「Frugal Architect」について語るように、開発者には数万ドル単位ではなく、ドル単位でコストを考えてほしいと思います。効率的なワークロードの実現に焦点を当てることで、トラフィックの拡大に応じてドメインのパフォーマンスを評価でき、経営層レベルでは明確なビジネスKPIを設定し、成長を技術面まで追跡することができます。
また、チームにはセキュリティの責任も持ってもらいたいと考えています。そのため、チームは独自の脅威モデリングを行います。私たちは長年STRIDEフレームワークを使用してきました。チームには自分たちのワークロードを検証し、データフロー図を作成し、潜在的な脅威について考えてもらいたいと考えています。
例えばスプーフィングを考える場合、データフロー、プロセス、データストア、外部エンティティという4つのコンポーネントタイプがあります。プロセスや外部エンティティに対するスプーフィングの場合、そのコンポーネントの認証の強度についてチームに質問することができます。私たちはチームに対して、データフロー図の作成、脅威の特定、主要な対策の検討を指導しています。これは多くの開発者にとって新しい取り組みです。セキュリティチームが対策の有効性を確認しますが、エンジニアがこのプロセスを経験することは非常に興味深いものです。
これは、Grace Hopperの素晴らしい言葉につながります。「1つの正確な測定は、1000の専門家の意見に匹敵する」という言葉です。私たちはWell-Architectedについて話してきました。 多くの人がWell-Architectedを監査のように考えていますが、私はこれを継続的な改善の仕組みとして捉えています。各チームに対して、派手な図表ではなく、Wikiに基本的なものを作成して、Well-Architectedの柱に関連するパフォーマンス時間、コスト、信頼性、セキュリティの統計を追跡する簡易的なダッシュボードを作成するよう依頼しています。毎月、毎スプリントごとに、誰かがファシリテーターとなってチームと一緒に数値について話し合います。この取り組みをSCORP（Security、Cost、Operational reliability、Performance）と呼んでいます。
SCORPはWell-Architectedの構造を利用していますが、より対話的なプロセスで、質問に時間を費やします。これは、インシデント後の非難のない事後分析のように、非難のない事前分析として考えてください。潜在的な問題が出始めている箇所や、パフォーマンスが少しずつ低下している可能性がある箇所を確認します。開発者が懸念事項を共有できる安全な場を作り出します。通常、Lambda関数の速度低下などの具体的な懸念事項を共有してくれるので、そこに焦点を当ててアイデアを出し合うことができます。このプロセスは、GP内の約40〜50のチームで使用されており、他の企業でも何百ものチームが実施しています。
これの良い点は、チームメンタリングをAtomic Habitとして体系化していることです。すべてのスプリントで非機能的なKPIとトレンドをレビューするところまで到達します。私は、あるチームが他のチームより速いというような比較はしません。代わりに、前回からの数値の推移というトレンドに注目します。トレンドとアクションを考え始めると、進むべき方向が見えてきます。この対話で最も重要な点は、エンジニアが懸念事項を共有しやすい安全な環境を維持することです。
ワークロードの準備に関して、チームが新しいワークロードを作成したい場合、開発アカウントのリクエストを受けた際に最初に尋ねるのは「なぜ？」です。このワークロードの目的、KPI、サービス、イベントを理解する必要があります。それがドメインとビジネス成果に結びついていることを確認できたら、開発者アカウントを提供します。 アーキテクトとしての私の役割は、チームがこれらのプロセスを進められるよう支援し、コーチングすることです。チームはテストアカウントをリクエストする前に、ワークロードの本番候補バージョンを構築します。テストアカウントに進むにつれて、品質管理を強化していきます。これには、脅威モデルの完成、Security Hubへの準拠、パフォーマンステストの実行、コストダッシュボードのレビューが含まれます。QuickSightでコストインテリジェンスダッシュボードを設定し、Well-Architectedレビューを実施し、受け入れテストを検討し、データスキーマがデータプラットフォームに記録されていることを確認し、Trusted Advisorに問題がないことを確認し、デプロイメントパイプラインを確立します。テスト環境を取得すると、ダッシュボードへの直接アクセスはできません。チームはテストアカウントを取得した後、ファイルを直接アップロードしたがることがよくありますが、私たちはInfrastructure as Codeを通じてすべてのアクセスを自動化することを要求します。開発からテストへの移行は、本番環境の条件をシミュレートするため重要です。強化とテストのフェーズを完了すると、本番ワークロードまたは本番アカウントをリクエストしますが、これらは3つの別個のAWSアカウントとなります。
その後、セキュリティスキャンを強化し、Snykとすべてのセキュリティスキャンにクリアであることを確認します。Observabilityが稼働していることを確認し、すべてのダッシュボードに満足していることを確認し、runbookをレビューします。その時点で、本番アカウントをプロビジョニングし、チームは必要に応じてデプロイできるようになります。これで彼らはこのワークロードを所有し、運用することになります。
私のArchitectとしての役割は、この業務を可能にすることです。そして私たちには開発者向けのセキュリティ支援があります。アプリケーションチームがこのパスを進む中で、複数の異なるチームがサポートを提供します。新しいチームにとっては、これは大きな仕事に見えるかもしれません。しかし、チームがこのサイクルを何度か経験すると、非常に熟練してきます。私は素早く実行することもできますが、むしろ左シフトして、チームが早い段階で学習が必要な領域を特定し、本番環境に到達する頃には十分な準備ができているようにすることを好みます。
Adrian Cockcroftの素晴らしい言葉で締めくくりたいと思います：「イノベーションを文化に加えるのではなく、イノベーションの邪魔をしないことだ」。私が「ソフトウェアと人のABC」と呼んでいる3つのことを中心にお話ししたいと思います。まず、ワークロードと構築する機能について合意を形成し（Align）、Event-drivenやDomain-drivenの手法を通じて適切な境界（Boundaries）を見出し、そしてチームがコーディング（Code）できる環境を整えます。
今年経験した実際のシナリオについてお話ししましょう。昨年、私はre:Invent で発表を行い、そこでGP内のあるアイデアについて議論しました。12月中旬に戻ってきた時、私たちはEvent Stormingセッションを実施して、これがどのようなものになるかを理解することにしました。課題は、異なる国でプロフェッショナルを雇用する際に、国ごとに要件が異なる中で、どのように情報を収集するかを決定することでした。私たちはステークホルダーを集め、右上のボードに示されているような主要なイベントを特定しました。1月にイベントを収集し、適切な順序を確保するために時系列的なシーケンスを適用し、Ben EllerbyのEventBridge Stormingテクニックを使用して、各ステップに関与する主要なペルソナを特定しました。
そのコンセプトが固まったら、Domain Driven Designを使用して境界を確立することに移りました。これらをソフトウェアコンポーネントに分割し始め、Bounded Context内のグループ内でこれらのイベントとペルソナがどのように機能するかを、技術ではなくビジネス上の問題に基づいて3つの異なるワークロードにマッピングしました。その後、コードフェーズに入り、この新しいBounded Contextをどのように構築するかを検討しました。右上の図は、Bounded Contextの実際のアーキテクチャ図で、私が言及した基本的なコンポーネントとサービスを使用しています。
チームは4月頃から本番デプロイを開始しました。1月にEvent Stormを実施し、約2〜3ヶ月後には、EventBridge、Lambda、DynamoDB、API Gateway、Step Functionsを使用して、イベントの受信と発信の両方のためのソフトウェアのデプロイを開始しました。これが実際のワークロードのアーキテクチャです - シンプルですが、ビジネス上の問題を理解し、組織を整合させることに最も力を注ぎました。特に印象的なのは、4月から5月頃に本番デプロイを開始し、現在ではシステムが最大規模の14〜15カ国で稼働しており、Event Stormから生まれたこのソリューションを使用して、新しいプロフェッショナルをシステムで処理し、すべての情報をコンプライアンスに準拠して収集できるようになったことです。エレガントな点は、Event Stormの図がソフトウェアの図と一致しており、すべてが私たちの主要なメカニズムを通じて実行されていることです。
チームのシンプルさ、測定、フローについて説明させていただき、そこから得られた重要な学びについてお話しします。私にとって、これらは非常に重要な学びでした：このような新興市場では、目的の明確化が常に進化し続けているため困難です。チームが自分たちの仕事に対して快適さを感じ、方向転換を認識できることが重要です。大きな失敗を避けるために早期の失敗を許容する必要があり、そのためには素早いフィードバックループが必要です。フローに関しては、ServerlessとEDAはまだ学習が難しいため、シンプルさとビジネス課題に焦点を当てる必要があります。最後に、測定が重要です - Well-Architectedは非常に価値がありますが、多くの開発者にとってはまだ馴染みがないため、継続的な改善メカニズムとして考慮することが不可欠です。
結論として、私は以前からコードは特定の状況下では負債になりうると主張してきました - 単にコードを書くだけでは解決できないのです。システム全体を資産として捉える必要があり、Platform engineeringがそれを可能にします。
状況を包括的に見ると、ソフトウェアを迅速に提供する方法について総合的に考える必要があります。Globalization Partnersでは、ソフトウェア提供の処理能力が非常に高く、ビジネスに大きな変革をもたらしていることを嬉しく思います。
Platform Engineeringの成功に向けた重要ポイントと推奨リソース
Globalization Partnersで行っているすべての取り組みを見ることは非常に有益でした。チームのオンボーディングと立ち上げを支援するモデルは本当に素晴らしいものです。このプロセスに携わる方々が覚えておくべき重要なポイントをいくつか挙げて締めくくりたいと思います。「作れば来る」というアプローチ - 顧客のことを考えずにプラットフォームを構築する人々をよく見かけます。Platformチームは単なる別のStream-alignedチームであり、その顧客は開発者です。彼らの要件から逆算して密接に協力することが、本当に重要なものを提供するために不可欠です。
チーム構造は本当に重要で、意図的に取り組む必要があります。Stream-alignedチームへの投資は、ビジネス価値と密接に結びついているため、企業にとって容易です。しかし、価値を提供するために、enablementを行うFacilitatingチームやPlatformチームの構築への投資を確保するために戦う必要があります。時にはそれが大きな戦いとなります。プラットフォームの観点からは、テナンシー、アカウント構造、クラスターPlatform as a Serviceの課題を早期に解決する必要があります。これは相互作用であることを忘れないでください - 「作れば来る」は確かですが、顧客と共に構築しなければ意味がありません。
標準的な自動化に、いくつかのエスケープハッチを設けることで、新しいパターンや異なるパターンが可能になります。ドキュメントと教育が重要です。これらのコンセプトの多くは非常に新しいものなので、人々がこれらを理解していると思い込まないでください。ランチ＆ラーンの内容を文書化し、アイデアを共有し、これらのアイデアについて議論する時間を作り、考え方に疑問を投げかける場を設けましょう。最後に、誰かがビジョンを持つ必要があります。これらは自然に起こることではありません。時には、これらの異なる要素をすべて結びつけることについて大きく考えるArchitectがその役割を担います。すべてを管理するという意味ではありませんが、より大きな全体像を見て、潜在的なボトルネックを特定することができます。
他にもお勧めのセッションをご紹介します。これらは今週の中でも特に人気の高かった3つのセッションです。これらはすべて現在YouTubeで視聴可能ですので、帰りの飛行機での視聴にぴったりですよ。Daveは、彼らのプラットフォーム内で標準的なツールセットをどのように標準化したかについて詳しく話してくれました。彼らのBackstageの多くは、Serverless Landというサイトにリンクしています。これは私のチームで構築しているサイトで、たくさんのパターンが掲載されています。Step Functionsを使用してSagaパターンで状態を管理するオーケストレーションの方法を知りたい場合、Serverless Landにそのパターンとドキュメントがあります。
また、スキルを習得するための完全な学習パスを提供する優れたスキルバッジも用意しています。Powertoolsは、観測可能なロギングや冪等性サポートなど、多くの機能を含む素晴らしいプロジェクトです。分散アプリケーションを構築している場合、Well-Architectedなソフトウェアを迅速に提供するのに役立つ、とても優れたコードが利用可能です。ご清聴ありがとうございました。今週最後のセッションにご参加いただき、ありがとうございます。この後、外で5分ほど待機していますので、質問や話し合いたいことがありましたら、お気軽にお声がけください。re:Inventでの時間を楽しんでいただけたことを願っています。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion