Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

pospome
November 29, 2023

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

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

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

pospome

November 29, 2023
Tweet

More Decks by pospome

Other Decks in Technology

Transcript

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

    View full-size slide

  2. 登壇者
    名前:pospome(ぽすぽめ)
    所属:DMM.com
    Twitter:@pospome

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  51. 07 まとめ

    View full-size slide

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

    View full-size slide