はじめに
昨今の開発環境の複雑化に加えて、AIの台頭により、「プラットフォームエンジニアリング」はより一層重要度を増しています。
私も普段の業務で「プラットフォームエンジニアリング"っぽいこと"」をやる機会はあったのですが、今後この領域にもっと深く携わるようになりたいと思い、解像度を上げるために以下の技術書を読みました。
以降は、本書籍の第1章「プラットフォームエンジニアリングとは何か」の内容を引用、および自分なりに要約したものです。
概要
- プラットフォームエンジニアリングは、開発者がインフラやツールをセルフサービスで使えるプラットフォームを提供し、認知負荷を減らして自律的に開発できるようにする取り組みである
- DevOpsは多くの組織で、中央のDevOpsチームがボトルネックになり失敗した。プラットフォームエンジニアリングはDevOpsを否定せず、その先へ進むものである
- 社内プラットフォームはプロダクトとして扱うべき。そのために動き方をモデル化する。
- プロダクトマネジメント：開発者のニーズをもとに何を作るか決め、フィードバックを反映する
- プロダクトドメイン：プラットフォームを8つのドメインに分け、その区切りでチームを構成する
- エンジニアリング原則：ソフトウェア・デファインドを中核に、セルフサービスやガバナンスの自動化など7つの原則に従って作る
- DevEx・DevOps・SREは、プラットフォームエンジニアリングを置き換えるものではなく、支えるものである
プラットフォームエンジニアリングとは何か
プラットフォームエンジニアリングとは、社内の開発チーム向けにエンジニアリングプラットフォームを構築・提供し、開発者の認知負荷を減らして、チームが自律的に開発を進められる状態を実現する取り組みである。
具体的には以下のような状態を実現する。
- 開発から運用までに必要なツール・技術・インフラに、開発者がセルフサービスでアクセスできる
- セキュリティやガバナンスといった組織のコンプライアンス要件があらかじめ組み込まれており、開発者が個別に対応する手間を減らせる
- アップグレードや新技術の導入が頻繁に起きる環境でも、ソフトウェアを効果的かつ効率的に運用し続けられる
DevOpsでは達成できないこと
DevOpsとは、開発チームと運用チームが密に連携し、インフラ構成の自動化を重視するアプローチである。
理想は「開発チームが自分たちでインフラも扱える状態」だが、多くの組織では次のような経過をたどり、うまくいかなかった。
- インフラのうち一部（サーバー設定、検証環境へのデプロイなど）だけが開発チームに移管され、DevOpsに詳しい人が2〜3人配置される。それ以外の依存関係は、従来どおり別部署が管理したまま。
開発者はトレーニングを受ける機会がなく、締め切りにも追われているため、インフラ作業はチーム内の詳しい1〜2人に任せきりになる。 - 他のチームでも同じことが起き、やがて2〜3の開発チームで1つのDevOpsチームを共有するようになる。
- セキュリティやガバナンスの部門が、チェックを確実に通すためにCI/CDパイプラインを管理下に置き、専任のパイプラインチームを作る。パイプラインの変更にはこのチームを通す必要があり、ボトルネックになる。
- 会社全体では数十のDevOpsチームが、同じような課題をそれぞれ別の方法で解決しようとする。作業が重複し、人件費もクラウド費用も膨らむ。
- 複雑さは増す一方で、適切な人材も足りない。集中化がさらに進み、作業はチケットで依頼して順番を待つ方式に逆戻りする。
- 中央のDevOpsチームはキャパオーバーとなり、依頼をさばけなくなる。オンボーディングも新しい取り組みも本番リリースも遅れ、リードタイムはDevOps導入前とほぼ同じになる。
既存の組織構造に囚われたまま、これまでの常識を当てはめるだけでは限界がある。
成果を出すには、たとえば「セキュリティやコンプライアンスの要件を担う社内ステークホルダーと、開発者との連携の仕組み」を根本から見直すような、新しい考え方が必要になる。
プラットフォームエンジニアリングは、DevOpsを否定するものではなく、DevOpsのさらに先へ進むための取り組みである。
プラットフォームエンジニアリングの基礎概念
ユーザーのニーズは多様かつ変動的なものである。
ユーザーや機能、チームが増えていく中でもプロダクト（＝プラットフォーム）の品質を損なわないためには、プロダクトデリバリーモデルを適用する必要がある。
プロダクトデリバリーモデル
プロダクトマネジメント・プロダクトドメイン・エンジニアリング原則の3つの概念が互いに依存し合い、次のようなサイクルで回っている。
- プロダクトマネジメントが、開発者のニーズをもとに、プラットフォームで何ができるようにするか、どんな機能を作るか、使い心地をどうするかを決める
- 決めた内容をプロダクトドメイン（領域）に分割し、そのドメインの区切りを軸にチームを構成する
- 各ドメインチームは、共通のエンジニアリング原則に従ってプラットフォームを構築する
- できあがったプラットフォームを開発者が使い、その体験から生まれたフィードバックが、再びプロダクトマネジメントのロードマップに反映される
従来は、インフラやツールをトップダウンで押し付けるのが当たり前で、開発者体験は蔑ろにされてきた（費用対効果の面では、それが合理的だった）。
そうではなく、プラットフォームをユーザ（=社内の開発者）向けのプロダクトとして扱うことが重要である。
プロダクトドメイン
ドメイン駆動設計の考え方をプラットフォームにも適用し、ドメインごとにチームを構成する。
- 境界は、従来のIT部門の機能区分（ネットワーク課、サーバー課など）ではなく、ユーザー体験を基準に決める
- 境界が適切であれば、各チームは独自のバックログと優先順位を持ち、自律的に動ける
- ドメイン間の調整は、プロダクトオーナーやアーキテクトのレベルで行うものであり、個々のエンジニア同士で日常的に起きるものではない
- 他チームにSlackやZoomで連絡を取る必要が出てきた時点で、境界の引き方がおかしい可能性あり。継続的に境界を調整していく必要がある
本書では、エンジニアリングプラットフォームを構成する有効なモデルとして、以下の8つのドメインが紹介されている。
番号は、新しいプラットフォームを立ち上げる際の依存関係の順序（＝構築順）を表す。
| # | ドメイン | 概要 | 具体例 |
|---|---|---|---|
| 1 | クラウド管理ID | クラウドの組織・アカウント構造と、インフラ自動化で使うサービスアカウントのIDと権限 | AWSの組織アカウントとOU構造, aws-iam-profiles |
| 2 | クラウドアカウントベースライン | 全アカウントに共通して適用するアカウントレベルの設定 | aws-platform-observability-base, aws-platform-hosted-zones |
| 3 | トランジットネットワークレイヤー | プラットフォーム上のあらゆる通信（インターネット、サービス間、リージョン間など）のためのネットワーク | VPC, Transit Gateway, AWS Cloud WAN |
| 4 | 顧客IDプロバイダー | クラウドのIAMから独立した、利用者（開発者）向けの認証・認可。権限はチーム単位で付与する | Auth0 + GitHub |
| 5 | クラウドコントロールプレーン基盤 | インフラを動かす中核のコントロールプレーン。クラウドベンダーが運用を管理する部分に限る | Amazon EKS とマネージドアドオン, Karpenter |
| 6 | コントロールプレーンサービス | コントロールプレーンに標準で載せる機能。クラスターやアプリの状態を収集・分析する | オブザーバビリティコレクター, 垂直オートスケーラー, ポリシーおよびセキュリティスキャン |
| 7 | コントロールプレーンエクステンション | Kubernetes APIを拡張し、標準にないリソースを開発者がプロビジョニングできるようにする | ストレージクラス, インフラオペレーター, サービスメッシュ |
| 8 | プラットフォームプロダクトサービス | ソフトウェアの品質向上を速め、標準化するための開発者向けツールやリソース（DevExもここに含まれる） | vsctl, 言語別スターターキット, フィーチャーフラグの自動化 |
補足：
- 8つのドメインに8つのチームが必要なわけではない。単一チームから始めても、各ドメインを念頭に置いて設計できる。チーム数は実際のユーザー需要とビジネス価値に応じて拡大していけばよい
- ゼロから構築する場合は順序の制約がある（例：ネットワークが整うまでコントロールプレーンはデプロイできない）。ただし立ち上げ後は、各ドメインが自律的に進化できる
- ほぼすべてのドメインに高品質なSaaSの選択肢があり、ドメインの設計方針に沿う形であれば採用してよい
エンジニアリング原則
プロダクトデリバリーモデルとプロダクトドメインは、チームをどう分けて、仕事をどう回すかという組織の仕組みの話である。
一方、エンジニアリング原則は、各チームが実際にプラットフォームをどう作るかという、現場のやり方の話である。
本書では、プラットフォームが提供するあらゆるケイパビリティ（＝開発者がプラットフォームでできること）や機能の性質を形作るものとして、7つの原則が挙げられている。
ソフトウェア・デファインド
ここでいうソフトウェア・デファインドとは、プラットフォームの機能や振る舞いをソフトウェア（コード）で定義・制御できることであり、プラットフォームが届けるすべてのものの中核となる原則である。
プラットフォームエンジニアリングチームはソフトウェアチームであり、統合・機能・自動化・技術を含むプラットフォーム全体を、バージョン管理されたソースコードからデプロイできる状態にし、CI/CDパイプラインで管理する。
セルフサービス
プラットフォームでできることは、すべて開発者が自分で（セルフサービスで）使えるようにする。
出発点はサービスインターフェースの設計である。つまり、どのケイパビリティにもAPIが必要になる。自分たちで構築する場合は、まずAPIを作り、その上にUIやCLIなどの開発者ツールを重ねていく。
このAPIファーストの設計によって、セルフサービスを持続的に提供でき、チーム間の作業境界も明確になる。
進化的アーキテクチャ
アーキテクチャの決定は、時間とともに変わるものだという前提に立つ。
新しい技術は次々に登場し、利用者の期待も変わる。プラットフォームのアーキテクチャに「最終形」はない。
小さな変更を素早く積み重ねられる設計にし、あとからソリューションを差し替えられる余地を残しておく。
指標駆動の成功
プラットフォームの各機能が、約束どおりの価値を届けているかをデータで証明する。
自動化で速くするなら実際に速くなったことを、品質改善のためなら改善の度合いを計測できなければならない。
また、測定は特定のプロセスではなく、組織のデリバリープロセス全体で行う。あるチームのための改善が、別のチームを遅らせていることもあるためである。
セキュアかつコンプライアンス準拠
セキュリティとコンプライアンスの要件には、次の2種類がある。
- プラットフォーム自身が満たすべき要件：プラットフォームチームが直接責任を負う
- プラットフォームの利用者に適用される要件：プラットフォームチームは、利用者が要件を満たせるよう支援するツールを提供する
つまり、プラットフォームのセキュリティはプラットフォームチームが、その上で動くアプリケーションのセキュリティは開発者が責任を負う共有責任モデルになる。
開発者が書いた脆弱なコードをプラットフォームが自動的に直すことはできない。
ただし、コードのセキュリティを評価し、既知の脆弱性を知らせるケイパビリティは提供できる。
また、障害時にデータ損失やサービス停止を防ぐレジリエンスもセキュリティの一部である。
可用性が「冗長化して、正常なインフラにトラフィックを振り向けられる能力」であるのに対し、レジリエンスは「障害から自律的に復旧できる能力」を指す。
ガバナンスの自動化
開発者は、ビルドやデリバリーのやり方を自分たちで決めて、他のチームを待たずに速く変更したい。
一方、セキュリティやガバナンスを担うチームは、ルールが守られていることを確かめられる材料がほしい。
この2つは対立するように思える。
チェックの責任を丸ごと別のチーム（たとえばセキュリティチーム）に引き渡す形では、開発者がそのチームを待つことになる。
責任を丸ごと引き渡さずに、ルールが守られていることを示すには、コンプライアンスを満たす作業と、それを検証する仕組みを分ける必要がある。
- 開発者は、プラットフォームのセルフサービスツールを使ってコンプライアンスを満たす
- 検証はパイプラインから切り離し、プラットフォームのコントロールプレーンに組み込む
コントロールプレーンは、プラットフォームへのあらゆる変更を受け付ける入口なので、変更が反映される直前に必ずチェックを通すことができる。
これにより、開発者は他チームを待たずに作業でき、かつ変更が加えられる前にコンプライアンスを確認できる。
これを**compliance at the point of change（変更時点でのコンプライアンス）**と呼ぶ。
compliance at the point of change
コードやインフラストラクチャを変更・作成するまさにその瞬間（コーディング、コミット、デプロイのタイミング）に、自動でセキュリティやコンプライアンスの規程を検証・適用するアプローチ
オブザーバビリティ
オブザーバビリティ（可観測性）と混同されがちな言葉として「監視」があるが、両者は異なるものである。
- 監視：CPU使用率やエラー率のように、「正常」「異常」の基準がすでにわかっている指標を追跡する。オブザーバビリティの一部
- オブザーバビリティ：ログ・メトリクス・トレースなど、システムが出力する幅広いデータから、内部で何が起きているかを理解する。予期していなかった未知の問題も見つけられる
監視が車の警告灯のチェックだとすれば、オブザーバビリティは原因不明の異音や挙動も診断できる整備士のようなものである。
さらに重要なのは、技術的なメトリクスが、ビジネスの成果やユーザー体験とどう結びついているかまで把握できることである。
原則同士のつながり
ソフトウェア・デファインド以外の6つの原則は互いにつながっており、ある原則の適用の仕方が、他の原則を活かすことも台無しにすることもある。
- テストできない形でセキュリティ要件を実装すると、内部で何が起きているかを確かめられず、オブザーバビリティが損なわれる
- セルフサービスを実装しても、利用状況のデータを取らなければ、価値をデータで示せず指標駆動の成功を満たせない
1つの原則を実装するときも、他の原則への影響を意識する必要がある。
プラットフォームエンジニアリングを支える要素
プラットフォームエンジニアリングの成功を後押しする、触媒のようなプラクティスとして「開発者体験（DevEx）」「SRE」「DevOps文化」の3つが挙げられている。
開発者体験（DevEx）
近年、開発者体験（DevEx）が注目され、Backstageのような開発者ポータルが重視されている。
ただし、ポータルを「プラットフォームの機能を開発者に届ける窓口」とみなすのは適切ではない。
プラットフォームのプロダクト戦略全体が、そもそも開発者体験を良くするためのものだからである。
また、プラットフォームの機能とDevExが扱う領域は重なっている。境界を決めないままDevEx専門チームを立ち上げると、プラットフォームチームと衝突しはじめる。
そのため、DevExはプラットフォーム内部のサブドメインとして扱うのが効果的である。8つのドメインでは、⑧プラットフォームプロダクトサービスに位置づけられる。
DevOps
DevOpsは、特定のチームや職務名ではなく、開発と運用を1つにまとめる「文化」として機能するときに最も効果を発揮する。
優れたDevOps文化に共通するのは、設計・実装・ビルド・テストをする開発者自身が、デプロイや監視、サポートにも責任を持つことである。
プラットフォームについても同様で、プラットフォームのケイパビリティを作ったエンジニアが、本番環境での運用・監視・サポートも担う必要がある。
SRE
SREは、プラットフォームチーム、DevEx、一般の開発チームのいずれにも属さず、それらの外側に位置する。
役割は、すでに効率よく開発・運用できている開発チームを、さらに強くすることである。別の運用チームとして切り出されるのではなく、エンドツーエンドで品質を継続的に改善する取り組みとして導入される。
具体的には、SREは成熟したプロダクトチーム（プラットフォームチームを含む）に短期間だけ配属される。そこで得た学びを他のチームへ持ち込み、プラットフォーム自体にも反映させていく。
もしSREチームが自分たち専用のコードを抱えているなら、それはスメル（＝何かがおかしいサイン）である。
SREの仕事は、自分たちのコードを育てることではなく、配属先のチームのコードを良くすることだからである。