Platform Engineeringの功罪 in DMM

DMMプラットフォームはエンジニアが120名以上所属する開発組織であり、4年前からプラットフォームエンジニアリングに取り組んでいます。

4年間の成功体験とその裏に佇む課題についてお話ししました。

Platform Engineering Kaigi 2024 で使用したスライドです。
https://www.cnia.io/pek2024/sessions/89133451-1afe-479e-a4d5-1dc32efb32ba/

Transcript

1. Platform Engineeringの功罪 in DMM 合同会社DMM.com 城野太河
2. 発表者 - 城野 太河 - 合同会社DMM.com プラットフォームチーム チームリーダー - バックエンド→クラウドインフラ→プラットフォーム
3. - DMMのプラットフォーム - 取り組んできた功罪 - マルチクラウドk8s の功罪 - セルフサービスの功罪 - プラットフォームチームの功罪 今日話すこと
4. DMMのプラットフォーム
5. DMMの部署の一つ。 DMM会員・決済・DMMポイントなどの共通機能を他部署に提供。 DMMプラットフォーム 開発チーム 15チーム エンジニア数 120人 マイクロサービス歴 2016年~ マイクロサービス数 40個 最大RPS ピーク 20,000rps
6. プラットフォームチーム DMMプラットフォームの開発効率を向上するチーム。 マイクロサービスプラットフォーム というインフラ基盤を運用。 - エンジニア数: 4人 ※可用性向上は SREチーム という別チームに分離
7. マイクロサービスプラットフォーム DMMプラットフォームの120人が利用するプラットフォーム。
8. マイクロサービスプラットフォームのインフラ コンテナ以外のインフラは個別に管理
9. マルチクラウドk8sの功罪
10. 背景: プラットフォームエンジニアリングへの要求 プラットフォームエンジニアリング以前からマイクロサービス構成だった。 開発チーム毎に個別のエコシステムを構築・運用していた。 組織としては効率が悪い - 構築・運用コストが15チーム分発生 - エコシステムの品質や技術スタックがチームごとにバラバラ → 共通化したい。
11. AWS を使うチームと GC を使うチーム が混在していた。 シンプルに構築するならどちらかに統一したいが... - AWS と GC で同じサービスが揃ってるわけではない - 移行コストもかかる ↓ クラウドの統一は現実的に難しい。 AWS/GCの既存のインフラを使える様に構成しないといけない。 背景: 既存インフラの制約
12. AWS/GC で共通の仕組みを提供する為の技術選定が必要 - 開発者に共通のインタフェースを提供できること - プラットフォームとして十分なエコシステムが構築可能であること - 運用コストがなるべく共通化できること → k8s の採用 k8sによる共通化
13. AWS/GCに散在する既存インフラを使いながら、 共通したエコシステムを提供できるプラットフォーム。 マルチクラウドk8sなプラットフォーム
14. 開発に使うエコシステムや機能の大半を共通化できた。 功: 共通エコシステムの提供 ↓ ArgoCDのApplication一覧。全チームで共通利用される。 コンテナプラットフォーム EKS/GKE CDパイプライン ArgoCD ワークフローエンジン ArgoWorkflow 監視 Datadog アラート PagerDuty
15. マルチクラウドk8sの罪 - 罪①: 当然EKSとGKEは別物 - 罪②: クラウド間の差分との付き合い
16. EKSは構成可能なコンポーネントが多い。 例えばCNI は vpc-cni というアドオンで提供されている。 - サブネットやネットワークインタフェースの分離 - IP確保時のプレフィックス利用 複雑な要件に対応できて嬉しい 罪①: 当然EKSとGKEは別物
17. 事例: 挙動を誤解して軽い障害に発展した - デフォルト値の変更に気づかなくてNodeLocalDNSが死んだ - 設定値の誤りに気づかずNode用のサブネットにPodが流れ込んだ EKSでは構成や挙動をしっかり把握しておく必要がある。 罪①: 当然EKSとGKEは別物
18. GKEはマネージドなコンポーネントが多い。 例えばクラスタのログ収集を設定一つで構成できる - マネージドなfluentbitが勝手に収集・転送してくれる 構築や運用が簡単で嬉しい 罪①: 当然EKSとGKEは別物
19. 事例: fluentbitの想定スループットを超えてログが欠損する - リソースを自分たちで直接いじれない - SAと相談して最終的には別のfluentbitを導入 - 1ヶ月弱くらいの期間、ログがちょっと欠損している GKEでは提供されている機能以上のことをする際は事前考慮が必要。 ※過去の事例。現在のマネージドfluentbitはスループット改善されている 罪①: 当然EKSとGKEは別物
20. GKE - マネージドなコンポーネント多 - “self managed fluentbit” の対応 - cluster-autoscaler の設定値に依存しな いノードのプランニング - GCの機能との連携 - GC-GKEでIAMの統制 - Cloud NATのポート設計 罪①: 当然EKSとGKEは別物 EKS - 構成可能なコンポーネント多 - cniの設定値や挙動の把握 - kube-proxyやcoredns等コアコンポーネ ントのバージョン管理 - AWS機能との連携 - AWS IAMと連携する為のyaml管理 - 他アカウントと連携にTransitGatway 開発者のインタフェースは共通化できても、 認知負荷や運用工数は全然共通化できない。
21. 開発チームには共通インタフェースを提供しつつ、 プラットフォーム機能を開発する際はクラウド間の差分吸収が必要。 - 開発チームのエンジニアに権限を付与する機能 - 開発チームのネットワークと繋ぐ機能 罪②: クラウド間の差分との付き合い ↓開発チームのネットワークと接続する仕組みの裏側
22. 既存ツールを用いる場合でも構成を考えないと共通化が難しい - ArgoWorkflowはマルチクラスタ対応していない。 認証コンポーネントだけArgoCDと共有できる - ArgoCDはマルチクラスタ対応しているが、 クラスタのservice account tokenが必要 技術選定がAWS/GC対応どう実現するか？に左右される 罪②: クラウド間の差分との付き合い
23. AWS/GCの既存インフラを使いつつエコシステムを共通化する必要があった為、 マルチクラウドk8sという構成によって達成した。 その一方で運用負荷は想定を上回っており、 EKS/GKEやクラウド自体の差分と付き合っていくことになった。 まとめ: マルチクラウドk8sの功罪
24. セルフサービス化の功罪
25. Self-service. (中略) Users must be able to request and receive capabilities autonomously and automatically. This property is key to allowing a platform team to enable multiple product teams and scale as needed. CNCF Platforms White Paper “Attributes of Platform” 意訳すると 「必要な時に必要な機能がすぐ使えること」 - 開発チームはリードタイムを削減できる - プラットフォームはスケール性を高められる 背景: セルフサービス化
26. プラットフォームエンジニアリングを始める前は、 開発チーム内でインフラやエコシステムを構築・運用できていた。 - インフラを安全に扱うことができる - 必要なオペレーションを自分たちで実践できる ↓ プラットフォームがセルフサービス化しても使いこなせる勝算 セルフサービスとの相性が良い。 背景: DMMプラットフォームとセルフサービスの相性
27. ほぼ全てのオペレーションは開発チームがセルフサービスで実施可能。 - プラットフォームで利用するアカウントの発行 - マイクロサービスで使うインフラの作成・運用 - マニフェストの作成・変更・デプロイ - 監視・アラートツールの利用 セルフサービス化されたプラットフォーム
28. セルフサービス化されたプラットフォーム プラットフォームチームとのコミュニケーションが必要なケースはこれくらい - プラットフォームへの機能要望 - マイクロサービスの削除 (年3回程度)
29. 利用開始から開発・デプロイ・運用までセルフサービスで実施できる。 リードタイムのない開発環境。 2024年のマニフェストのリリースは月平均 300回程度。 功: 開発サイクルの自律化 月 1月 2月 3月 4月 5月 リリース数 230 304 384 219 342
30. セルフサービスをしなかった場合... 4人で月間300PRのレビューを捌き続ける必要がある ↓ 頑張ればレビューはできるが、かなり負荷が高い。 - レビューが詰まって開発チームのボトルネックになる - 手間を減らすためにレビューが形骸化してしまう 功: 開発サイクルの自律化
31. プラットフォームチームによるレビューはコストが高い。 技術面もあるが、自分たちのアプリケーションではないため。 - PRごとの変更背景や妥当性を調査するコミュニケーション - マイクロサービス毎の仕様の把握 (DMMプラットフォームだと40個) → DMMプラットフォームのスケールにはセルフサービス化が必須だった 功: 開発サイクルの自律化
32. セルフサービス化の罪 - 罪①: リソースが最適化しきれない - 罪②: セキュリティリスクに気づく機会が減る
33. 事例: - 要求したcpu/memoryの10%未満しか使わないPod - ノード1台のcpu/memoryを丸ごと要求するPod Podがリソースを過剰に要求することが多い。 概ね80%の要求に対して25%しか使用されてない。 罪①: リソースが最適化しきれない ↓ Podが要求しているCPUの割合(%) ↓ Podが実際に使用しているCPUの割合(%)
34. 原因は様々。 - スパイクが予期される - 移行初期なので安定稼働まで最適化したくない (Lift) - 特に理由はないが不安 要求されるリソースが妥当かどうかは機械的に判断できない 罪①: リソースが最適化しきれない
35. 罪①: リソースが最適化しきれない プラットフォームチームとしては... - 料金インパクトが大きいものは都度ヒアリング - 定期的なプラットフォームチーム主導のリソース見直し ボトルネックにはならないものの、結局レビューに近いことをしている コミュニケーションコストは削減しきれなかった
36. 事例: 開発チームがアクセス制限のない Ingress を作れてしまう。 ステージング環境で不正アクセスを受けるまで検知できなかった 罪②: セキュリティリスクに気づく機会が減る
37. プラットフォームのガードレールに穴があったので作れてしまった。 セルフサービス化する以上はガードレールに力を入れる必要がある。 - 遅れていたポリシーチェックエンジンの導入 - クラウドのセキュリティ機能の見直し 罪②: セキュリティリスクに気づく機会が減る
38. 罪②: セキュリティリスクに気づく機会が減る 今回の事例はマニフェストのPRをレビューしていれば正直防げた。 結局レビューは必要なのか？ ↓ DMMプラットフォームでは方針を変更しない。 レビューよりも仕組みの強化に工数を割く方針をとっている。 - 未知の脅威をレビューで防げるとは限らない - セルフサービスによるメリットを重視している。 組織が重視するものによって答えは変わってくると思う。
39. DMMプラットフォームは元々DevOpsできていた組織だった。 セルフサービス化によって自律的でリードタイムのないプラットフォームを 実現できた。 しかしリソースの効率化が困難だったり、 セキュリティリスクと改めて向き合うことになった。 まとめ: セルフサービス化の功罪
40. プラットフォームチームの功罪
41. DMMプラットフォームの開発効率を向上させるためのチーム。 マルチクラウドなk8sで工数の共通化や開発効率を向上しつつ、 セルフサービス化を重視してDevOpsを損なわないプラットフォームを構築。 開発チームに向けたその他の取り組み: - 利用ドキュメントやオンボーディング資料の整備 - トラブルシュートのサポート - 定期的なサーベイによる課題抽出・対応 プラットフォームチーム
42. エコシステムの共通化 - 組織として見た工数を最適化 - 改善を通じて全体の開発効率を底上げできる 開発チームもアプリケーション開発に注力できる - エコシステムの細部に関与しなくて良い - 追加のリードタイムも発生しない 功: プラットフォームエンジニアリングの導入 AWS Well-Architected Framework 分離されたアプリケーションのエンジ ニアリングと運用 (AEO) および一元化されたガバナンスを備えたインフラ ストラクチャのエンジニアリングと運用 (IEO)
43. 基本的に開発チームからは「問い合わせ」としてサポート依頼が来る。 - プラットフォームチームしか対応できない問い合わせ (46%) - kustomizeをArgoWorkflowリソースに対応してほしい - Datadogのメトリクスを使ってカナリアリリースする機能が欲しい - 開発チームで対応できそうな問い合わせ (38%) - 新しいメンバがpodを見れない - LivenessProbeが失敗する - MFAをリセットできない 本当に必要な問い合わせは半分程度。 罪: プラットフォームチームへの依存
44. プラットフォームチームの工数がかかる。 - 週あたりの問い合わせ: 2~10件程度。 - 所要時間: 5分~半年 (非同期コミュニケーション)。 持ち回りで問い合わせ対応しており、 週によってはエンジニア一人が磔になっている (=チームの25%)。 本来取り組むべきプラットフォームの機能改善が停滞してしまう 罪: プラットフォームチームへの依存①
45. 工数負担するチームが変わっただけでは？ 組織全体としては特にデメリットがないのでは？ → そうとも言い切れない... 罪: プラットフォームチームへの依存②
46. 本来不要だったはずのリードタイムが発生する。 - 緊急性のない問い合わせはベストエフォートで対応される。 一次返答に最大24h。やりとりが続くと更にリードタイムが発生する。 - 障害など緊急性があるものは最優先で対応される。 ただしコミュニケーションコストが発生する。 プラットフォームチームが開発・運用のボトルネックになってしまう。 罪: プラットフォームチームへの依存②
47. 問い合わせなくても利用できる様に補助を拡充している。 - ドキュメントの拡充 - オンボーディングやサンプルアプリケーションの提供 - 自動化できるものはプラットフォーム機能として実装 しかしドキュメントが読まれなかったり、 「調査する前にまず問い合わせる」チームがいたりする。 不要な依存をなくすまでの道のりは長そう。 罪: プラットフォームチームへの依存③ ↓提供するドキュメント群の一角
48. プラットフォームを提供して組織の開発効率を向上させた。 その裏で予想以上に依存が発生してしまった。 開発チームで完結した開発を行えるように取り組みを続けている。 まとめ: プラットフォームチームの功罪
49. まとめ
50. 我々のミッションであった「開発効率の向上」を起点に、 今に至るまでのプラットフォームに関する成功と失敗を紹介した。 中でも開発チームが関わる失敗は、 「発生は予期していたが想定を上回っていた」類のものが多い。 より適切な意思決定の為に開発チームと目線を合わせ続ける必要がありそう。 まとめ
51. ご清聴ありがとうございました