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