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

by pospome

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

登壇者名前：pospome（ぽすぽめ）所属：DMM.com Twitter:@pospome

Slide 3

Slide 3 text

DMMプラットフォーム X プラットフォームエンジニアリング X GKE 概要

Slide 4

Slide 4 text

役割 DMM の各種サービスに対して、共通機能を提供する部署組織規模エンジニアだけで 120 名以上開発チームは 15 チーム程度サービス規模ピーク帯で 19,000 RPS 40 程度のマイクロサービスで構成 DMMプラットフォームについて

Slide 5

Slide 5 text

01 プラットフォームエンジニアリングについて

Slide 6

Slide 6 text

● 多種多様なツールの活用 ● 複雑化するテクノロジー ● DevOps による開発と運用の一体化ソフトウェア開発のコストが高い

Slide 7

Slide 7 text

DMMプラットフォームでカナリアリリース機能についてのアンケートを取ったことがある。 DMMプラットフォームの例 ● カナリアリリースを知らない … 16%

Slide 8

Slide 8 text

プラットフォームエンジニアリングとは、組織において有用な抽象化を行い、セルフサービスインフラストラクチャを構築するアプローチです。 ※画像の置換方法グレーボックスを選択し、右クリックで「画像を置換」を選択し、配置したい画像に差し替えてください。プラットフォームエンジニアリングについて https://cloud.google.com/blog/ja/products/application-development/golden-paths-for -engineering-execution-consistency/

Slide 9

Slide 9 text

● 各チームが責任を持って DevOps などに必要なツールを構築・運用する。 ● 学習コストや作業工数が高い。 ※画像の置換方法グレーボックスを選択し、右クリックで「画像を置換」を選択し、配置したい画像に差し替えてください。概要

Slide 10

Slide 10 text

● プラットフォームチームが各チームに対してツールを提供する。 ● 各チームの学習コストや作業コストを削減することができる。 ※画像の置換方法グレーボックスを選択し、右クリックで「画像を置換」を選択し、配置したい画像に差し替えてください。概要

Slide 11

Slide 11 text

プラットフォームエンジニアリングとは、「組織において有用な」抽象化を行い、セルフサービスインフラストラクチャを構築するアプローチです。 ※画像の置換方法グレーボックスを選択し、右クリックで「画像を置換」を選択し、配置したい画像に差し替えてください。プラットフォームエンジニアリングについて https://cloud.google.com/blog/ja/products/application-development/golden-paths-for -engineering-execution-consistency/

Slide 12

Slide 12 text

仕組みの抽象度デプロイ方法高い開発チームが Slack でプラットフォームチームにデプロイを依頼する。 ~ ~ 低いプラットフォームチームは技術選定だけ担当し、開発チームが CD パイプラインをゼロから構築・運用する。抽象化（例：CD パイプライン）

Slide 13

Slide 13 text

プラットフォームエンジニアリングとは、組織において有用な抽象化を行い、「セルフサービスインフラストラクチャ」を構築するアプローチです。 ※画像の置換方法グレーボックスを選択し、右クリックで「画像を置換」を選択し、配置したい画像に差し替えてください。プラットフォームエンジニアリングについて https://cloud.google.com/blog/ja/products/application-development/golden-paths-for -engineering-execution-consistency/

Slide 14

Slide 14 text

● 開発チームが任意のタイミングで任意の仕組みを利用できること。 ● 可能な限り誰かの承認や作業待ちが発生しないようにする。 ※画像の置換方法グレーボックスを選択し、右クリックで「画像を置換」を選択し、配置したい画像に差し替えてください。セルフサービス

Slide 15

Slide 15 text

02 当時の DMMプラットフォームプラットフォームエンジニアリングに取り組む前の DMMプラットフォームについて

Slide 16

Slide 16 text

● DevOps は高いレベルで実践できていた。 ○ 開発スピードが早いわけではなかった。各チームの習熟度もバラバラだった。スタートアップの集合体

Slide 17

Slide 17 text

● プラットフォームチームを設立し、開発チームの Ops のコストを削減する。プラットフォームエンジニアリングへの取り組み

Slide 18

Slide 18 text

03 テクノロジースタックの統一プラットフォームエンジニアリングへのファーストステップ

Slide 19

Slide 19 text

● 開発チームごとに異なるツールを提供するのは工数的に厳しい。 ※画像の置換方法グレーボックスを選択し、右クリックで「画像を置換」を選択し、配置したい画像に差し替えてください。プラットフォームチームの負担

Slide 20

Slide 20 text

● 多くのチームの要件を満たす汎用的なツールの提供が必要になる。プラットフォームチームの負担

Slide 21

Slide 21 text

項目権限設定コンテナプラットフォーム GKE アラート / モニタリング Datadog コンテナレジストリ Artifact Registry CD パイプライン Argo CD ワークフローエンジン Argo Workflows インシデント管理 PagerDuty 提供しているもの一覧

Slide 22

Slide 22 text

● スタンダードクラスタを採用している。 ● シングルクラスターマルチテナント型 1 つの namespace に 1 つのマイクロサービスを配置している。クラスター数を抑えてプラットフォームチームの負担を減らす。 ● プラットフォームチームがクラスターを運用している。 GKE の採用

Slide 23

Slide 23 text

● アプリケーションの特性によって最適解が変わるもの。例：DB ● 各チームで適切に運用できそうなもの。例：Cloud Functions ※画像の置換方法グレーボックスを選択し、右クリックで「画像を置換」を選択し、配置したい画像に差し替えてください。プラットフォームチームが提供しないものプラットフォームチームの Google Cloud プロジェクト会員チームの Google Cloud プロジェクト

Slide 24

Slide 24 text

● テクノロジースタックの統一によって、効率よく各チームの Ops のコストを削減することができた。結果

Slide 25

Slide 25 text

プラットフォームチームを抱える費用 VS 削減できる開発工数プラットフォームチームのコスパが重要

Slide 26

Slide 26 text

04 なぜ GKE か? プラットフォームエンジニアリングと GKE の相性

Slide 27

Slide 27 text

1 2 3 なぜ GKE か? 制約が少ない多様な要件に対応でき、中長期的にプラットフォームを作ることができる。マルチテナント k8s の namespace によってマルチテナント構成が実現しやすい。 OSSエコシステム k8s 自体が OSS なので、 OSS エコシステムが強力である。マルチテナントを考慮されているものが多い。

Slide 28

Slide 28 text

実現方法の正確な操作や手順を規定するのではなく、望ましい状態を宣言する。 https://cloud.google.com/blog/ja/topics/developers-practitio ners/build-platform-krm-part-1-whats-platform ※画像の置換方法グレーボックスを選択し、右クリックで「画像を置換」を選択し、配置したい画像に差し替えてください。 Configuration as Data (CaD)

Slide 29

Slide 29 text

● yaml 形式で望ましい状態を宣言するこのリソース宣言形式は Kubernetes Resource Model (KRM) という。 ● Controller によって yaml で定義されたリソース状態を実現する https://github.com/GoogleCloudPlatform/kubernetes-engine-samples/blob/HEAD/ quickstart/deployment.yaml Kubernetes における CaD の実現

Slide 30

Slide 30 text

実現方法の正確な操作や手順を規定するのではなく、望ましい状態を宣言する。 yaml と Controller によるリソース定義・調整のことであり、 GKE の利用者なら当たり前のものである。 https://cloud.google.com/blog/ja/topics/developers-practitioners/build-platform-krm-part -1-whats-platform ※画像の置換方法グレーボックスを選択し、右クリックで「画像を置換」を選択し、配置したい画像に差し替えてください。 Configuration as Data (CaD)

Slide 31

Slide 31 text

1 2 3 KRM のメリットすべてが yaml になるクラスター上のリソースを yaml という統一的なフォーマットで定義することができる。 GitOps が可能 yaml ファイルを GitHub リポジトリにホスティングすることによって、GitOps が可能になる。ツールチェーンの統一 yaml を扱うためのツールチェーンを揃えれば、任意の処理が可能になる。

Slide 32

Slide 32 text

● yaml で定義された状態を実現するための仕組みである。 ● Go 言語で開発することができる。クラスター上にデプロイされる。 ● Reconciliation Loop によって GKE を常にあるべき姿に調整する。回復性を持つリソースを実現できる。 Controller と Reconciliation Loop

Slide 33

Slide 33 text

● リソースを宣言的に定義する yaml と定義されたリソース状態を実現する Controller が分離している。 CaD によるデータと処理の分離

Slide 34

Slide 34 text

● リソースを任意の状態に設定するために yaml を編集するだけでいい。利用者の DevOps のハードルが下がる。 CaD によるデータと処理の分離

Slide 35

Slide 35 text

● Controller は Go 言語によるリソース操作によって、複雑な要件を実現することができる。要件の実現方法は Controller の開発者だけが知っていればいい。 CaD によるデータと処理の分離

Slide 36

Slide 36 text

● yaml の定義と Controller は自作することができる。任意のリソースに対して任意の操作ができる。 ● フレームワークである。 ● 当然 OSS もこのフレームワークに乗っている。 Custom Controller と Custom Resource Definition (CRD)

Slide 37

Slide 37 text

項目できること Argo CD CD パイプラインの定義 Argo Workflows ワークフローの定義 Kyverno ポリシーの定義 Custom Controller と CRD の例

Slide 38

Slide 38 text

● KRM は汎用性の高いリソース管理フレームワークとみなすことができる。 ● Config Connector は KRM によって Google Cloud リソースを管理することができるサービスである。 ※画像の置換方法グレーボックスを選択し、右クリックで「画像を置換」を選択し、配置したい画像に差し替えてください。あらゆるリソースを管理できる

Slide 39

Slide 39 text

● Web アプリケーションを動かすコンテナプラットフォームに収まらない。あらゆるリソースを一元管理できる巨大な CaD プラットフォームになりうる。例：Config Connector ● リソースによって利用するツールや仕組みを変えなくてもいい。 DevOps のコストを限りなく下げることができる。 Configuration as Data の可能性

Slide 40

Slide 40 text

● エコシステムの導入・運用するコスト ● CaD プラットフォームの実現 GKE のポテンシャルを活かせるか?

Slide 41

Slide 41 text

05 有用な抽象化開発チームにどこまで責任を持たせるか?

Slide 42

Slide 42 text

● 開発チームに提供する仕組みの抽象度を適切に設定する必要がある。 ● DMMプラットフォームでは、既存のツールをそのまま開発チームに提供することが多い。例：標準リソース（Deployment,HPA など）, Kustomize, Argo CD, etc. 有用な抽象化

Slide 43

Slide 43 text

● 各チームにはそれ相応の学習コストをかけてもらう。 ● 「自分たちが利用する技術は自分たちで理解すべき」という思想がある。理解が浅いと運用ができない（DevOps ができない）。有用な抽象化

Slide 44

Slide 44 text

06 セルフサービスリードタイムを短縮する

Slide 45

Slide 45 text

● 開発チームが任意のタイミングで任意の目的を達成できるようにする必要がある。 ● DMMプラットフォームでは各チームが自由にツールを利用できる環境になっている。承認や作業待ちは基本的に発生しない。セルフサービス

Slide 46

Slide 46 text

項目開発チームの責任 GKE 自分が管理するマイクロサービスのマニフェストファイルを管理 Argo CD 自分が管理するマイクロサービスの CD パイプラインを管理 Datadog 自分が管理するマイクロサービスのモニターを管理 GAR 自分が管理するマイクロサービスのリポジトリを管理開発チームの責任

Slide 47

Slide 47 text

● 開発チームのセルフサービス化が進めば進むほど、権限管理を考えなければいけない。 ● 管理者権限を与えるのが手っ取り早いが、そうもいかない。セルフサービスと権限管理

Slide 48

Slide 48 text

項目権限設定 GKE 自分が管理するマイクロサービスの namespace のみ操作可能 Argo CD 自分が管理するマイクロサービスの設定のみ操作可能 Datadog 誰でもすべてのリソースを操作可能 GAR 自分が管理するマイクロサービスのリポジトリにのみ push 可能権限管理

Slide 49

Slide 49 text

Slide 50

Slide 50 text

監査ログとモニターによる検知

Slide 51

Slide 51 text

07 まとめ

Slide 52

Slide 52 text

プラットフォームエンジニアリングで重要なのは以下である。 ● 組織にとって有用な抽象化 ● セルフサービスなインフラストラクチャ ● プラットフォームチームのコストを上回る組織の規模感 Configuration as Data を備える GKE がこれらをサポートする強力なツールになるかもしれない。まとめ