Amazon Web Services ブログ
【開催報告】プラットフォームエンジニアリングって何？〜基本から AWS での実現方法について〜
みなさんこんにちは！アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクトの後藤です。
2024 年 2 月 29 日に AWS オンラインセミナー「プラットフォームエンジニアリングって何？〜基本から AWS での実現方法について〜」を開催しました。
本イベントは、プラットフォームエンジニアリングの基本的な概要と現状について解説した上で、SRE や DevOps との関連性、どんな課題をどう解決するのか、実装するとなれば、AWS でどう実現するのかといった点についてご紹介させていただきました。400 名を超える多くの方々にご参加いただきました。ご参加いただいた皆様、誠にありがとうございました！
アジェンダ
AWS メンバーから、プラットフォームエンジニアリングに関する 3 つのセッションを 2 時間でお届けしました。本記事の中に資料や動画のリンクを記載しておりますので、ぜひご活用ください！
- チームとプラットフォームをクラウドネイティブな開発に最適化する (45 分)
- スピーカー: アマゾン ウェブ サービス ジャパン合同会社 Specialist Solutions Architect, Containers 林 政利
- クラウドネイティブな開発では、アプリケーションとクラウドリソースの垣根はあいまいになり、開発チームと運用チームの役割も自ずと変化します。「運用チームがインフラストラクチャーを用意し、開発チームが作ったアプリケーションを載せる」という開発スタイルから、さまざまなクラウドの機能をネイティブに活用したクラウドネイティブ開発へと移行する組織にとって、「基盤 (プラットフォーム)」というものの考え方も大きく変わってくることになります。このセッションでは、プラットフォームエンジニアリングというアプローチを紹介し、クラウドネイティブな開発でどのようにチームと基盤を最適化するべきかご紹介します。
- 資料: https://pages.awscloud.com/rs/112-TZM-766/images/20240229-platform-engineering-1-team_platform_cloudnative.pdf
- 動画: https://youtu.be/Bs2hTbWJveo
- ちがいからみる Platform Engineering – クラウドネイティブ化に伴って生じた新たなチームトポロジー (45 分)
- スピーカー: アマゾン ウェブ サービス ジャパン合同会社 Tech Training Specialist 山田 遼太
- 近年、急速なデジタル変革が進む中で、企業は IT インフラストラクチャの信頼性と効率性を確保するために新たなアプローチを模索しています。そこで、Site Reliability Engineering（SRE）とプラットフォームエンジニアリングが注目を集めています。本セッションでは、SRE とプラットフォームエンジニアリングの役割と相違について探究します。どちらも IT インフラストラクチャに関する技術を扱いますが、責任範囲、目的、チームトポロジー、コミュニケーションスタイルなどが異なります。これらの異なる側面に焦点を当てながら、それぞれの役割がどのように組織において共存し、相互補完的になり得るかについて議論します。さらに、組織がプラットフォームエンジニアリングを導入する際の潜在的な利点や課題、実践的なエンジニアリングにおいて活用できる具体的な手法やベストプラクティスについても提案します。これにより、お客さまは組織のニーズや目標に合わせて、SRE とプラットフォームエンジニアリングを効果的に組み合わせ、持続可能な IT インフラストラクチャを構築するための手法を理解することができます。
- 資料: https://pages.awscloud.com/rs/112-TZM-766/images/20240229-platform-engineering-2-platformengineering_differences.pdf
- 動画: https://youtu.be/w6kDd5B4OSs
- Amazon ECS で実現するプラットフォームエンジニアリング (30 分)
- スピーカー: アマゾン ウェブ サービス ジャパン合同会社 Solutions Architect 後藤 健汰
- ビジネスの拡大やサービスの増加に伴う開発組織の急速な規模拡大により、組織には様々な課題が生じます。そのような状況下で、開発者体験や生産性を向上させ、ビジネス価値の創出を加速することを目的とした「プラットフォームエンジニアリング」というアプローチが、近年注目を集めています。本セッションでは、開発組織が拡大する中で様々な課題を抱えている、または将来的に直面する可能性があると考えられるお客様が「プラットフォームエンジニアリング」を導入していく上で、抑えておくべき考慮事項や Amazon ECS をはじめとしたプラットフォーム構築に活用できる技術についてご紹介いたします。
- 資料: https://pages.awscloud.com/rs/112-TZM-766/images/20240229-platform-engineering-3-amazon_ecs_platformengineering.pdf
- 動画: https://youtu.be/u8KEQl1wIgU
いただいた質問とその回答
セッション当日に頂いたご質問の中で、回答しきれなかったものをこの場で回答させていただきます。
Q. ストリームアラインドチームをプラットフォームエンジニアリングがサポートし負荷を軽減するゴールデンパスの例が IaC テンプレートの利用促進となる理解で正しいでしょか？
A. 正しいです。さらにいうと、テンプレートの利用促進だけではなく、ゴールデンパスのトレーニングや、アーキテクチャレビューもその一例になります。
Q. 受託開発では業務要件を組織内に持っておらず、これを整理し、かみ砕き、複数のコンポーネントを統合した時の結果を保証する必要があります。ストリームアラインドチーム型で構成する時には従来の SI 系開発と比較してこの分割統合の難易度がさらに上がると思うのですが、プラットフォームチームのような、ここをサポートする方法はあるのでしょうか。
A. 受託開発でプラットフォームエンジニアリングの難易度が上がる、というのはご認識の通りです。特に、アプリケーション実装の一部を受託開発して納品し、発注側で統合し、保守運用を他の会社に外注する、というような、ストリームが組織で細かく分断されているケースでプラットフォームエンジニアリングを導入することは現実的ではないでしょう。プラットフォームエンジニアリングは、DevOps の文化が下地にあるため、まずはストリームを「引き継ぐ」場面を最小化する必要があります。例えば、受託開発のスコープを技術的なコンポーネントを単位にするのではなく、ビジネスのユーザーストーリー単位とし、そのストーリーのストリーム、つまり開発から保守運用までを一貫して受注するようなビジネス構造が必要です。多くのストリームとストリームアラインドチームが並行して稼働している環境で、そのチームを支援するような疎結合なプラットフォームを構築できます。
Q. 分散型プラットフォームと中央集権型のプラットフォームはエンジニアの組織規模によってどちらが優れているとかありますでしょうか？
A. 「最小限のプラットフォームから始める」という観点からは、分散型のプラットフォームから検討するといいでしょう。チームの負荷やスケーラビリティが確保しやすくなります。そこから、エンジニアの組織規模によっては、すべてのチームで強制的に適用したいポリシーや開発手法もあるでしょう。このような部分に限って段階的に中央集権的なプラットフォームを導入していくことができます。例えば、AWS のアカウントは BLEA と AWS Control Tower で必要なポリシーが設定されたものを中央集権的に管理し、 アプリケーションのデプロイは CDK テンプレートを開発者に配布するという分散型のプラットフォームで運用するという構成も考えられます。
Q. プラットフォームチームは内製すべきでしょうか？内製するとしてプラットフォームチームはまずどういったメンバーで構成すべきですか？
A. プラットフォームチームは内製すべきです。これは、良いプラットフォームを作るためにサポート対象のストリームアラインドチームのフィードバックを受け続ける環境が必要だからです。一般的には、プラットフォームチームはクラウドインフラストラクチャーに詳しい運用チームのメンバーで構成されます。しかし、ストリームアラインドチームをサポートするには、ソフトウェア開発の経験が必要です。これは、CI/CD やソースコードの管理戦略、テスト戦略、アプリケーションモニタリングなどが含まれます。このような経験や知識を持つメンバーもあわせてプラットフォームチームを構成するといいでしょう。
Q. 中央集権型プラットフォームモデルと従来型の開発/運用分立モデルの明確な相違点は何でしょうか。（従来の「アプリケーション開発チーム」「運用チーム」が「ストリームアラインドチーム」と「プラットフォームチーム」に名前が変わっただけのようにも見えます）
A. 明確な相違点は、チームの自律性です。中央集権型のプラットフォームモデルであっても、プラットフォームエンジニアリングの文化ではストリームアラインドチームは自律的に設計、開発、運用を行います。プラットフォームが使いやすいものであれば採用するし、そうでなければ採用しません。逆に、「プラットフォーム」を運用しているチームが、別チームの作ったアプリケーションを引き継いで運用している、というような状態であれば、従来の開発/運用分立モデルと同じだと言えるでしょう。
Q. プラットフォームチームが行うテンプレートのサポートを AmazonQ が代替できる場合、ストリームアラインドチームが直接 AmazonQ を利用する形態でプラットフォームエンジニアリングが成立しますでしょうか？
A. 成立します。しかし、Amazon Q が提案したテンプレートが本当に要件に合うものか判断できる知見がストリームアラインドチームには必要になります。もし、現時点でそうした知見に不安があるようであれば、プラットフォームチームはさらにレビューやトレーニングをストリームアラインドチームへ提供するというサポートが必要です。
Q. 中央集権型のプラットフォームの実現方法として k8s を利用したものが例として上がっていましたが、ECS を利用した場合の具体的なイメージを知りたいんですが何か良い資料はないでしょうか？
A. 本セミナーの「Amazon ECS で実現するプラットフォームエンジニアリング」のセッションで、ECS を前提にした具体的なイメージが紹介されておりますので、ぜひご参照ください
Q. 分散型のプラットフォームでは、ストリームアラインドチームからプラットフォームへの実運用 IaC コードなどのフィードバックも GitHub などで管理する認識でよいでしょうか、それともサンプルコードのフィードバックだけを受けるのでしょうか
A. これは、プラットフォームエンジニアリング導入のフェーズで変わる部分です。最初は、サンプルコードを提供して、そのフィードバックを受けます。このフェーズでは、プラットフォームチームはストリームアラインドチームと並走してサンプルコードを参考にしたアプリケーション開発、運用のフィードバックを受けることになるでしょう。そして、ストリームアラインドチームの運用が進んだ段階で、サンプルコードを汎用化し、GitHub で管理し、さらに広いストリームアラインドチームへ配布してフィードバックを受けるフェーズへ進みます。もちろん、すでに実運用されているシステムがあれば、サンプルコードを提供するフェーズをスキップして、その内容を直接汎用化することも考えられます。
Q. 弊社では中央集権型のプラットフォームレイヤーを設けており、AWS 上でインフラ構築をしておりますが、成果として構築されたインフラが開発チームのニーズを満たさず、結果として開発チームが調査しプラットフォームチームに修正を依頼しており、開発チームの負荷の増大や開発スケジュールの遅延の原因となっております。プラットフォームチームに「アプリを良く動かすためのインフラの構築」をさせるための方策等あればご教授いただけませんでしょうか。
A. プラットフォームエンジニアリングの観点からは、次に挙げる二点で開発チームのニーズを満たすことが考えられます。まず、「中央集権型のプラットフォーム」が何を提供するのか、というのを明確にします。そして、提供する機能がプラットフォームが開発チームの要件を満たさない部分は、分散型のプラットフォームの考え方を採用し、自律的に作業を行えるようにする、ということが重要です。プラットフォームエンジニアリングのベースにはチームの考え方があり、チームに自律性と必要な権限がなければ実践が難しいというのが実際のところです。また、プラットフォームはプロダクトとして開発する必要があり、例えば開発チームの KPI のような明確な品質の基準を設けるということも重要になるでしょう。
Q. 方法論を DevOps に変えていきたいという現場要求はありつつ、外的な要求、例えば認証規格 (ISO27017 ISMSクラウドセキュリティだとか) によりある程度手法の制約が出るケースがあると思います。社内は頑張って説得するにしても、対外的には(例えば監査機関に)何かしらロジカルに回答する必要があるわけですが、どんなアプローチを取っていったらいいのでしょうか。
A. 適切な回答のためには、準拠すべき要件の土台となる原理・原則や、その要求の背景を学び、解釈をアップデートしていく必要があります。具体的なアプローチとしては「The Era Of DevSecOps ～AWSサービスによる DevOps とセキュリティのマリアージュ～」という発表の中でも触れられておりますので、ぜひご参照ください。
Q. 19 頁 The ROAD to SRE？ Devops でなくとも普通にやることやらないといけないことのように思えましたがどういう意図の説明でしたでしょうか？
「The ROAD to SRE」は、SRE で取り組むべきことについて記述された Medium の記事を参考にお話しさせていただきました。SRE の実践を組織に導入する方法はいくつかありますが、どこから始めればいいか迷うことがあります。具体的なエリアを4 つ示すことで、SRE が具体的にどのエリアの信頼性に関する取り組みを行うのかについて説明させていただきました。
Q. ツーピザチームの自主的に機能するための権限というのは、例えばどのような権限になりますでしょうか? 予算とか、アーキテクチャ選択の自由等でしょうか?
A. ツー・ピザ・チームが自律的に機能するためには、権限と環境の両方が揃っていることが重要です。権限については、ツー・ピザ・チームがお客様のために独立してイノベーションを起こすことができる権限が必要と考えています。従来型の組織構造では、上層部での意思決定によって方針が決まり、具体的なアクションを遂行することのみを求められるような場合があります。一方で、ツー・ピザ・チームは、お客さまに最高の価値を届けるために、チーム内で自ら決断しアクションを遂行します。ここには、技術選定に関わるものから、どのプロジェクトに注力するか、アイデアの創出から実行、継続的な業務改善から絶え間ない製品のイテレーションやイノベーションに至るまであらゆるものに対する権限が含まれます。もう一つの環境の観点では、範囲内での予算を利用できることや、サービスをエンドツーエンドで所有して実行するのに必要なリソース (エンジニアリング、テスト、製品とプログラムの管理、運用など) がチームに組み込まれていることなどイノベーションを起こす上で必要なあらゆるものが含まれています。ただし、自律性と無秩序は別物です。Amazon では無秩序にならないよう適切なレベルの監督体制を確立します。ここでは従来のように上層部がすべての意思決定で乗り越えなければならない障壁となるわけではありません。むしろ、障害を取り除くことをサポートします。Amazon において組織を監督するために用いられている仕組みの 1 つにナラティブと呼ばれる文書があります。Amazon では、新しいサービスのリリース前に運用上の準備状況を厳密にレビューし、サービスのアーキテクチャ、そのリリースの質と手順、および関連するインシデントやイベントの管理手順のさまざまな側面が適切に定められ、文書化するために詳細な確認を行うナラティブを用意しています。ツー・ピザ・チームは説明責任を果たすために、決められたナラティブを作成し提供しなければなりません。
Q. Platform というものがよくわからないです。内部の開発チームに所属している方から品質に不安があるという声があがっています。そういった品質的な部分は Platform Team にお願いして品質の向上基盤、テスト自動化などの API を platform として提供してもらうとかもできるのでしょうか？それらも局所的な要件になるのですか？
A. 特定の課題がプラットフォームによって提供されるべき課題かどうかというのは、組織全体が抱えている課題の状況によって異なります。多くの開発チーム（ストリームアラインドチーム）が抱えている共通の認知負荷であれば、プラットフォームチームにによって解決できるようなプロダクトを作成するチャンスと捉えられます。もしプラットフォームとして課題解決をする場合は、開発チームはプラットフォームチームに対して適切なフィードバックを提供する、機能要求を送るなどのコラボレーションをしながら、適切なプロダクトの開発をサポートすることが推奨されます。
Q. EmbeddedSRE の認知負荷がすごく大きくなるような気がしますがどうなのでしょうか？
A. Embedded SRE チームには、信頼性に関わる技術的に際立った専門性を有しているメンバーを集めます。また、チームにアサインされた場合も、アサインされたチームが抱えている信頼性に関する課題解決や、信頼性に関わる知識の移譲を行うため、サービス自体に関するドメイン知識が求められることはありません。
Q. AWS における two pizza teamとは、特定サービスに強い権限を持つ少数のサービスアラインドチームという理解で相違ないでしょうか？
A. はい。詳しくは、「高いパフォーマンスを発揮する組織 – Amazon ピザ 2 枚チーム | AWS Executive Insights」をご確認ください。
Q. プロトタイプエンジニアとプラットフォームエンジニアの違いはなんなのでしょうか？
A. 一般的にプロトタイプエンジニアは「特定の顧客のユースケースを実現するプロトタイプを開発し、技術的な実現性を確認する」ことを責務として持つロールです。それに対してプラットフォームエンジニアは、ストリームアラインドチームの認知負荷を軽減し開発生産性を高めることを目的とした「プラットフォーム」を開発・運用することを責務として持つロールになります。両方ともにストリームアラインドチームを支援しますが、異なる責務を持ったロールと言えます。
Q. プラットフォームチームは、一般的な組織としてどの部署（情シスのインフラチームとか。。）が担当するのが一般的なのでしょうか？また、兼務したりするのでしょうか？
A. 一般的には、プラットフォームを開発するケイパビリティを持った人材でプラットフォームチームを組成することが多いと考えています。兼務については開発組織の文化などにもよりますが、プラットフォームの開発においては、開発チームと積極的にコラボレーションをする必要があるので、開発チームに対して一定のコミットを求める必要があります。
Q. 責務の分担はプロジェクト開始タイミングで決めた方が良いと思いますが、プロジェクト開始前に開発と運用のマネージャー層だけで決めた方が良いのでしょうか。それとも開始直後にメンバーにヒアリングして現場の意見も含めた方が良いのでしょうか。トップダウン、ボトムアップのどちらの方が成功しやすいのか、実績などからお分かりでしたらご教示ください。
A. 現場の意見を踏まえた上で、最終的にはマネージャー層の合意が必要だと考えています。開発チームの教育などにも一定のコストがかかる可能性があるため、現場のメンバーだけでは決められず、また責務分担の現実的な落とし所を決める際には現場のメンバーの意見が重要になるためです。
Q. セッション３のゴールデンパスの実装において、IaC テンプレートの抽象化のレベルをどう決定していくかに悩んでいます。決定の仕方や、例などを教えていただくことはできるでしょうか。
A. 様々な要因がありますが、開発チームが持っている技術的なナレッジを考慮する、というのは大切です。また「どの程度抽象化するべきか」についてユーザーにヒアリングをしながら決めていく、というのも有効な方法になります。もし抽象化の必要がなくカスタマイズ性を重視するのであれば、一切抽象化していない IaC コードをテンプレートとして提供するというのも、選択肢の一つになりえます。
Q. プラットフォームチームの運用負荷を下げる事が容易になる AWS サービス一覧はありますでしょうか？
A. プラットフォームの構成によって、様々な AWS サービスが活用できます。例えば、プラットフォームチームによる AWS アカウントの管理や統制を支援するサービスとして AWS Control Tower や AWS Control Tower Account Factory といったサービスがあります。
Q. 開発チームとプラットフォームチームがスキルや文化の違い、コミュニケーション不足などで衝突している場面を多くの現場で見かけますが、プロジェクトが成功するためにプラットフォームチームが心がけるポイントなどはございますか？
A. 開発チームへのスキルトランスファーや文化の啓蒙も、プラットフォームチームの責務のひとつです。具体的には、ユーザーのニーズに対応する適切なドキュメントを整備するであったり、開発チーム向けの勉強会やデモを提供するといった、Platform as a Product の思想に基いた活動が大切です。
Q. TVPという考え方がありました。これであれば、あまり深かけずにできることから実現できそうですが、プラットフォームエンジニアリングを選ばないほうが良いケースってどういうものがありますか？
A. プラットフォームエンジニアリングのアプローチを適用すべきかどうかは、現在の開発組織が抱える課題について明らかにした上で、その課題を改善するためにプラットフォームエンジニアリングが必要かを明らかにする必要があります。こちらのブログに開発組織の運用モデルの評価について記載がありますので、ぜひご参照ください。
Q. 非常にためになるセミナーを開催頂きありがとうございます。以下、ご教授願います。複数のシステムを運用しており、各システムはそれぞれアカウント（システムごと、本番、開発ごと）が異なっている状況下です。AWS 上でプラットフォーム（例えば CICD 機能など）を提供する場合にこのようなプラットフォームは 1 つのアカウントに集約して各システムとクロスアカウントで連携するのが望ましいのか、もしくは各アカウントに部品を提供していく形で連携するのが望ましいのか。指標や考え方があればご教授頂きたい。
A. ひとつの考え方として、提供する「部品」の責務を持つのはどのチームか？によって決定するという考え方があります。もし CI/CD パイプラインの責務を開発チームに持たせるのであれば、各 AWS アカウントに配置した方が、トラブルシュート時の確認などが容易に実現できます。
おわりに
本セミナーにご参加いただいた皆様、改めてありがとうございました。今後も様々な切り口からのセミナーを企画してまいりますので、みなさまのご登録をお待ちしております。