DMMプラットフォームにおける GKE を利用した プラットフォームエンジニアリングへの 取り組み

Google Cloud Next Tokyo '23 の登壇資料です。

登壇時の資料はGoogle Cloud仕様のデザインでしたが、
個人のSpeaker Deckにそのデザインのままアップロードできないという規約があるので、
デザインを落としたものになっています。
スライドの内容は登壇時と同じです。

Transcript

1. DMMプラットフォームにおける GKE を利用した プラットフォームエンジニアリングへの取り組み @pospome
2. 登壇者 名前：pospome（ぽすぽめ） 所属：DMM.com Twitter:@pospome
3. DMMプラットフォーム X プラットフォーム エンジニアリング X GKE 概要
4. 役割 DMM の各種サービスに対して、 共通機能を提供する部署 組織規模 エンジニアだけで 120 名以上 開発チームは 15 チーム程度 サービス 規模 ピーク帯で 19,000 RPS 40 程度のマイクロサービスで構成 DMMプラットフォームについて
5. 01 プラットフォーム エンジニアリング について
6. • 多種多様なツールの活用 • 複雑化するテクノロジー • DevOps による開発と運用の一体化 ソフトウェア開発のコストが高い
7. DMMプラットフォームで カナリアリリース機能についての アンケートを取ったことがある。 DMMプラットフォームの例 • カナリアリリースを知らない … 16%
8. プラットフォーム エンジニアリングとは、組織に おいて有用な抽象化を行い、 セルフサービス インフラストラクチャを 構築するアプローチです。 ※画像の置換方法 グレーボックスを選択し、右クリックで「画像を置 換」を選択し、配置したい画像に差し替えてくださ い。 プラットフォーム エンジニアリングについて https://cloud.google.com/blog/ja/products/application-development/golden-paths-for -engineering-execution-consistency/
9. • 各チームが責任を持って DevOps などに必要なツールを 構築・運用する。 • 学習コストや作業工数が高い。 ※画像の置換方法 グレーボックスを選択し、右クリックで「画像を置 換」を選択し、配置したい画像に差し替えてくださ い。 概要
10. • プラットフォームチームが 各チームに対してツールを提供する。 • 各チームの学習コストや 作業コストを削減することができる。 ※画像の置換方法 グレーボックスを選択し、右クリックで「画像を置 換」を選択し、配置したい画像に差し替えてくださ い。 概要
11. プラットフォーム エンジニアリングとは、「組織 において有用な」抽象化を行い、 セルフサービス インフラストラクチャを 構築するアプローチです。 ※画像の置換方法 グレーボックスを選択し、右クリックで「画像を置 換」を選択し、配置したい画像に差し替えてくださ い。 プラットフォーム エンジニアリングについて https://cloud.google.com/blog/ja/products/application-development/golden-paths-for -engineering-execution-consistency/
12. 仕組みの抽象度 デプロイ方法 高い 開発チームが Slack でプラットフォーム チームに デプロイを依頼する。 ~ ~ 低い プラットフォーム チームは技術選定だけ担当し、 開発チームが CD パイプラインをゼロから構築・運用する。 抽象化（例：CD パイプライン）
13. プラットフォーム エンジニアリングとは、 組織において有用な抽象化を行い、 「セルフサービス インフラストラクチャ」を 構築するアプローチです。 ※画像の置換方法 グレーボックスを選択し、右クリックで「画像を置 換」を選択し、配置したい画像に差し替えてくださ い。 プラットフォーム エンジニアリングについて https://cloud.google.com/blog/ja/products/application-development/golden-paths-for -engineering-execution-consistency/
14. • 開発チームが任意のタイミングで任意 の仕組みを利用できること。 • 可能な限り誰かの承認や 作業待ちが発生しないようにする。 ※画像の置換方法 グレーボックスを選択し、右クリックで「画像を置 換」を選択し、配置したい画像に差し替えてくださ い。 セルフサービス
15. 02 当時の DMMプラットフォーム プラットフォーム エンジニアリングに取り組む前の DMMプラットフォームについて
16. • DevOps は高いレベルで実践できていた。 ◦ 開発スピードが早いわけではなかった。 各チームの習熟度もバラバラだった。 スタートアップの集合体
17. • プラットフォーム チームを設立し、 開発チームの Ops のコストを削減する。 プラットフォーム エンジニアリングへの取り組み
18. 03 テクノロジースタックの統一 プラットフォーム エンジニアリングへのファーストステップ
19. • 開発チームごとに 異なるツールを提供するのは工数的に厳しい。 ※画像の置換方法 グレーボックスを選択し、右クリックで「画像を置 換」を選択し、配置したい画像に差し替えてくださ い。 プラットフォーム チームの負担
20. • 多くのチームの要件を満たす 汎用的なツールの提供が必要になる。 プラットフォーム チームの負担
21. 項目 権限設定 コンテナ プラットフォーム GKE アラート / モニタリング Datadog コンテナ レジストリ Artifact Registry CD パイプライン Argo CD ワークフロー エンジン Argo Workflows インシデント管理 PagerDuty 提供しているもの一覧
22. • スタンダード クラスタを採用している。 • シングルクラスター マルチテナント型 1 つの namespace に 1 つのマイクロサービスを配置している。 クラスター数を抑えてプラットフォーム チームの負担を減らす。 • プラットフォーム チームがクラスターを運用している。 GKE の採用
23. • アプリケーションの特性によって 最適解が変わるもの。 例：DB • 各チームで適切に運用できそうなもの。 例：Cloud Functions ※画像の置換方法 グレーボックスを選択し、右クリックで「画像を置 換」を選択し、配置したい画像に差し替えてくださ い。 プラットフォーム チームが提供しないもの プラットフォームチームの Google Cloud プロジェクト 会員チームの Google Cloud プロジェクト
24. • テクノロジー スタックの統一によって、 効率よく各チームの Ops のコストを 削減することができた。 結果
25. プラットフォーム チームを抱える費用 VS 削減できる開発工数 プラットフォーム チームのコスパが重要
26. 04 なぜ GKE か? プラットフォーム エンジニアリングと GKE の相性
27. 1 2 3 なぜ GKE か? 制約が少ない 多様な要件に対応でき、 中長期的にプラットフォームを 作ることができる。 マルチテナント k8s の namespace によって マルチテナント構成が実現し やすい。 OSSエコシステム k8s 自体が OSS なので、 OSS エコシステムが強力であ る。マルチテナントを考慮され ているものが多い。
28. 実現方法の正確な操作や 手順を規定するのではなく、 望ましい状態を宣言する。 https://cloud.google.com/blog/ja/topics/developers-practitio ners/build-platform-krm-part-1-whats-platform ※画像の置換方法 グレーボックスを選択し、右クリックで「画像を置 換」を選択し、配置したい画像に差し替えてくださ い。 Configuration as Data (CaD)
29. • yaml 形式で望ましい状態を宣言する このリソース宣言形式は Kubernetes Resource Model (KRM) という。 • Controller によって yaml で 定義されたリソース状態を実現する https://github.com/GoogleCloudPlatform/kubernetes-engine-samples/blob/HEAD/ quickstart/deployment.yaml Kubernetes における CaD の実現
30. 実現方法の正確な操作や 手順を規定するのではなく、 望ましい状態を宣言する。 yaml と Controller による リソース定義・調整のことであり、 GKE の利用者なら当たり前のものである。 https://cloud.google.com/blog/ja/topics/developers-practitioners/build-platform-krm-part -1-whats-platform ※画像の置換方法 グレーボックスを選択し、右クリックで「画像を置 換」を選択し、配置したい画像に差し替えてくださ い。 Configuration as Data (CaD)
31. 1 2 3 KRM のメリット すべてが yaml になる クラスター上のリソースを yaml という統一的なフォー マットで定義することができ る。 GitOps が可能 yaml ファイルを GitHub リポ ジトリにホスティングすること によって、GitOps が可能にな る。 ツールチェーンの統一 yaml を扱うためのツール チェーンを揃えれば、任意の 処理が可能になる。
32. • yaml で定義された状態を 実現するための仕組みである。 • Go 言語で開発することができる。 クラスター上にデプロイされる。 • Reconciliation Loop によって GKE を常にあるべき姿に調整する。 回復性を持つリソースを実現できる。 Controller と Reconciliation Loop
33. • リソースを宣言的に定義する yaml と 定義されたリソース状態を実現する Controller が分離している。 CaD によるデータと処理の分離
34. • リソースを任意の状態に設定するために yaml を編集するだけでいい。 利用者の DevOps のハードルが下がる。 CaD によるデータと処理の分離
35. • Controller は Go 言語によるリソース操作によって、 複雑な要件を実現することができる。 要件の実現方法は Controller の開発者だけが知っていればいい。 CaD によるデータと処理の分離
36. • yaml の定義と Controller は自作することができる。 任意のリソースに対して任意の操作ができる。 • フレームワークである。 • 当然 OSS もこのフレームワークに乗っている。 Custom Controller と Custom Resource Definition (CRD)
37. 項目 できること Argo CD CD パイプラインの定義 Argo Workflows ワークフローの定義 Kyverno ポリシーの定義 Custom Controller と CRD の例
38. • KRM は汎用性の高いリソース管理フレームワーク とみなすことができる。 • Config Connector は KRM によって Google Cloud リソースを 管理することができるサービスである。 ※画像の置換方法 グレーボックスを選択し、右クリックで「画像を置 換」を選択し、配置したい画像に差し替えてくださ い。 あらゆるリソースを管理できる
39. • Web アプリケーションを動かすコンテナ プラットフォームに収まらない。 あらゆるリソースを一元管理できる巨大な CaD プラットフォームになりうる。 例：Config Connector • リソースによって利用するツールや仕組みを変えなくてもいい。 DevOps のコストを限りなく下げることができる。 Configuration as Data の可能性
40. • エコシステムの導入・運用するコスト • CaD プラットフォームの実現 GKE のポテンシャルを活かせるか?
41. 05 有用な抽象化 開発チームにどこまで責任を持たせるか?
42. • 開発チームに提供する仕組みの抽象度を適切に設定する必要がある。 • DMMプラットフォームでは、 既存のツールをそのまま開発チームに提供することが多い。 例：標準リソース（Deployment,HPA など）, Kustomize, Argo CD, etc. 有用な抽象化
43. • 各チームにはそれ相応の学習コストをかけてもらう。 • 「自分たちが利用する技術は自分たちで理解すべき」という思想がある。 理解が浅いと運用ができない（DevOps ができない）。 有用な抽象化
44. 06 セルフサービス リードタイムを短縮する
45. • 開発チームが任意のタイミングで 任意の目的を達成できるようにする必要がある。 • DMMプラットフォームでは各チームが自由にツールを利用できる環境になって いる。 承認や作業待ちは基本的に発生しない。 セルフサービス
46. 項目 開発チームの責任 GKE 自分が管理するマイクロサービスの マニフェスト ファイルを管理 Argo CD 自分が管理するマイクロサービスの CD パイプラインを管理 Datadog 自分が管理するマイクロサービスの モニターを管理 GAR 自分が管理するマイクロサービスの リポジトリを管理 開発チームの責任
47. • 開発チームのセルフサービス化が進めば進むほど、 権限管理を考えなければいけない。 • 管理者権限を与えるのが手っ取り早いが、そうもいかない。 セルフサービスと権限管理
48. 項目 権限設定 GKE 自分が管理するマイクロサービスの namespace のみ操作可能 Argo CD 自分が管理するマイクロサービスの 設定のみ操作可能 Datadog 誰でもすべてのリソースを操作可能 GAR 自分が管理するマイクロサービスの リポジトリにのみ push 可能 権限管理
49. 項目 権限設定 GKE 自分が管理するマイクロサービスの namespace のみ操作可能 Argo CD 自分が管理するマイクロサービスの 設定のみ操作可能 Datadog 誰でもすべてのリソースを操作可能 GAR 自分が管理するマイクロサービスの リポジトリにのみpush可能 権限管理
50. 監査ログとモニターによる検知
51. 07 まとめ
52. プラットフォーム エンジニアリングで重要なのは以下である。 • 組織にとって有用な抽象化 • セルフサービスなインフラストラクチャ • プラットフォーム チームのコストを上回る組織の規模感 Configuration as Data を備える GKE が これらをサポートする強力なツールになるかもしれない。 まとめ