CNPA — クラウドネイティブプラットフォームエンジニアリングアソシエイト
何を測ればプラットフォームは良くなるのか
一言でいうと
DORAの4つのメトリクスは、デプロイパイプラインの健全性を測る道具であって、プラットフォームの成功を測る道具ではありません。プラットフォームは、採用率・リードタイム・認知負荷で別に測る必要があり、プラットフォーム自身もSLOを持つべきです。
なぜ必要なのか
プラットフォームチームが成果を報告するときに最も多い間違いは、「自分たちが作ったもの」を並べることです。「CIテンプレート12種、チャート30個、ダッシュボード40個」。これはアウトプット(output)であって、アウトカム(outcome)ではありません。その12種を、誰も使っていないかもしれません。
成果を測るには、ユーザー側から見る必要があります。そして、ユーザーとは他の開発チームです。
どう動くのか
DORAの4つのメトリクスとその限界
| メトリクス | 意味 |
|---|---|
| デプロイ頻度(Deployment Frequency) | どのくらいの頻度で本番環境に出しているか |
| 変更のリードタイム(Lead Time for Changes) | コミットが本番環境に到達するまで |
| 変更失敗率(Change Failure Rate) | デプロイのうち、障害につながった割合 |
| サービス復旧時間(MTTR / Failed Deployment Recovery Time) | 失敗から回復するまで |
前の2つは速度(throughput)、後ろの2つは安定性(stability)です。DORA研究の核心的な発見は、この2つが相反しないということでした。速い組織は、おおむねより安定しています。
限界も明確です。
- 数字を操作されやすいです。デプロイを細かく分割すると、頻度が上がります。失敗の定義を狭めると、失敗率が下がります。
- チームごとの文脈が消えてしまいます。規制審査が必要な決済サービスと、社内ダッシュボードを同じ物差しで比べると、誤った結論が出ます。
- プラットフォームの貢献を直接示せません。リードタイムが短くなったとき、それがプラットフォームのおかげなのか、チームが小さくなったおかげなのかは、メトリクスだけではわかりません。
- 開発者が実際に感じる苦痛とずれることがあります。デプロイは速いのに、ローカル開発環境のセットアップに2日かかる組織では、DORAはすべて緑色です。
そのため、DORAは警報装置として使い、プラットフォームの成果は別に測る必要があります。
プラットフォーム固有のメトリクス
- 採用率(adoption): 強制されていない状態で、どのくらい使われているかを見ます。アクティブに使っているチームの数や、ゴールデンパスで作られたサービスの割合です。
- 最初のデプロイまでの時間(time-to-first-deploy): 新しいチームや新しいサービスが、何もない状態から本番環境へのデプロイに到達するまでの時間です。プラットフォームの中核的な約束を、最も直接的に測ります。
- サポートチケットの数と種類: 減っていれば、セルフサービスになってきているという意味です。増えている種類が、そのまま次のゴールデンパスの候補です。
- 認知負荷アンケート: 定性的なメトリクスですが、目標を直接測れる唯一のものです。「必要なものを探すのはどれくらい簡単だったか」「この作業に何日かかりそうか」のような質問項目を、四半期ごとに同じ形式で尋ねて、傾向を見ます。
ここでよく出てくる落とし穴があります。アンケートを1回しかやらなければ、何の役にも立ちません。絶対値は解釈できず、傾向だけに意味があります。
プラットフォームもSLOを持つべきです
プラットフォームが他のチームの依存先になった瞬間、プラットフォームの可用性は、そのままそれらのチームの可用性になります。ところが、多くのプラットフォームチームはSLOなしで運用しています。
プラットフォームSLOの例です。
- デプロイパイプラインの成功率とP95の所要時間
- セルフサービスのプロビジョニングリクエストの完了時間(例: 新しいネームスペースの95%が2分以内)
- 内部APIとポータルの可用性
- ゴールデンパスのスキャフォールディングの成功率
SLOがあればエラーバジェットが生まれ、エラーバジェットがあれば、「今四半期は新機能を出すか、安定化を行うか」を、勘ではなく数字で決められます。SREの方法論を、プラットフォームチームが自分自身に適用するということです。
マルチテナンシーの分離レベル
プラットフォームは、複数のチームにリソースを共有させます。分離レベルの選択肢は、おおよそ次のとおりです。
| レベル | 分離 | コスト | 運用負担 |
|---|---|---|---|
| ネームスペース | 論理的です。RBAC・クォータ・NetworkPolicyで区別します | 最も安い | 低い |
| ノードプール分離 | テナントごとのノードです。taint/tolerationで配置します | 中程度(遊休リソースが発生) | 中程度 |
| クラスター分離 | コントロールプレーンまで分離します | 高い | 高い(クラスターの数だけアップグレードが必要) |
| アカウント・サブスクリプション分離 | クラウドの境界まで分離します | 最も高い | 最も高い |
選択基準は、「このテナント同士の信頼関係はどうか」と「規制要件があるか」です。同じ会社のチーム同士であれば、ネームスペースで十分な場合が多く、外部の顧客がコードを実行するなら、最低でもノード分離、たいていはクラスター分離が必要です。ソフトマルチテナンシー(信頼するテナント)とハードマルチテナンシー(信頼しないテナント)を区別する語彙が、試験に出ます。
FinOps: コストも開発者体験です
コストは事後の請求書ではなく、フィードバックシグナルであるべきです。中核となる実践は3つです。
- 帰属(showback/chargeback): ラベルとネームスペースで、コストをチームに対応付けます。誰のものかわからなければ、誰も減らしません。showbackは見せるだけで、chargebackは実際に請求します。
- requestsと実際の使用量の差: Kubernetesのコストで最大の無駄は、過大なrequestsです。requestsに対する実使用率をチームに見せるだけでも、かなりの部分が減ります。
- ライトサイジングをゴールデンパスに入れる: デフォルトテンプレートのrequestsの値が妥当なら、誰も気にしなくても、コストが節約されます。
現場での姿
筆者のホームラボは、kube-prometheus-stackとGrafana(10.0.0.203)でオブザーバビリティをそろえており、残りの課題リストに、「コントロールプレーンの負荷観察: 4C/14GBのミニPCがetcdとapiserverをどこまで支えられるか」が挙がっています。これがプラットフォームSLOの考え方の縮図です。コントロールプレーンが遅くなれば、その上のすべてのチームが遅くなるので、プラットフォームのリソースの余裕は、プラットフォームだけの問題ではなく、ユーザー全体の問題です。
分離の話も、同じクラスターでそのまま出てきます。GPUは24GB・32GB・8GB(2枚)と等級がばらばらなので、何も対策しなければ、大きな学習が小さなカードに載ってしまいます。これは性能の問題であると同時に、公平性の問題でもあります。1つのテナントが大きなカードを独占すると、ほかのテナントのリードタイムが延びるからです。そこで、gpu.homelab/tierラベルとnodeSelectorで配置ルールを作りました。分離はセキュリティだけの話題ではなく、予測可能性の話題でもあります。
そして、「状態がReady」と「実際に動く」は別の命題だという、このクラスターで繰り返された教訓は、測定にもそのまま当てはまります。コンポーネントのヘルスチェックがすべて緑でも、ユーザーが体験することは悪いかもしれません。プラットフォームのメトリクスは、コンポーネントの状態ではなく、ユーザージャーニーで測る必要があります。
次のクイズで確認すること
このモジュールは、クイズで締めくくります。前のモジュールで作ったCRDとクォータ、ゴールデンパスのスキャフォールドが、ここで述べたメトリクスとどうつながるのか、たとえば、クォータとLimitRangeのデフォルト値が、そのままコストのメトリクスに影響する点を、振り返っておくとよいでしょう。