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

マイクロサービスとk8sにおける責任境界設計とリソース管理

pospome
November 23, 2022

 マイクロサービスとk8sにおける責任境界設計とリソース管理

Cloud Native Days Tokyo 2022 の資料です。
動画は以下にあります(CloudNative Days Tokyoのサイトにログインしないと見れないと思います)。
https://event.cloudnativedays.jp/cndt2022/talks/1559

pospome

November 23, 2022
Tweet

More Decks by pospome

Other Decks in Technology

Transcript

  1. マイクロサービスとk8sにおける責
    任境界設計とリソース管理

    View Slide

  2. 登壇者
    名前:pospome(ぽすぽめ)
    所属:DMMプラットフォーム
    Twitter:@pospome

    View Slide

  3. 今回の発表内容について
    100人規模の開発組織
    x
    k8s
    x
    責任境界設計とリソース管理

    View Slide

  4. DMMプラットフォームについて
    扱う領域:DMM会員、決済、DMMポイント、不正対策など
    エンジニア数:120名以上
    開発チーム数:16チーム
    マイクロサービス数:約40サービス
    ピーク時のリクエスト:14,000RPS

    View Slide

  5. DMMプラットフォームとマイクロサービス
    プラットフォーム開発は開発規模が大きいので、
    DMMプラットフォームは約6,7年前から
    マイクロサービスアーキテクチャを採用している。
    *マイクロサービスを前提とした内容になります。

    View Slide

  6. DMMプラットフォームのエンジニアリング組織
    DMMプラットフォームのエンジニアリング組織は大きく2つに分類することがで
    きる。
    ● SREチーム
    DMMプラットフォームの共通インフラを構築・運用するチーム。
    ● 開発チーム
    共通インフラを利用するチーム。
    チーム数としては16チーム存在する。
    SREチーム以外のチームは開発チームとみなしていい。

    View Slide

  7. DMMプラットフォームの共通インフラについて
    DMMプラットフォームには120名のエンジニアが利用する共通インフラが存在
    する。
    ● アプリケーション実行環境(GKE/EKS)
    ● CD Pipeline(ArgoCD)
    ● Container Registry(GCP Artifact Registry)
    ● Log/Metrics(Datadog)

    View Slide

  8. SREチームのAWSアカウント
    Amazon Elastic Kubernetes
    Service (EKS)
    共通インフラのシステムアーキテクチャ図
    Datadog
    マイクロサービス
    SREチームのGCPプロジェクト
    GKE
    マイクロサービス
    ArgoCD
    GAR
    DMMプラットフォームは
    諸事情によりマルチクラウド環境になっています。
    理由は時間の都合上割愛します。

    View Slide

  9. マルチテナント型のk8sについて
    k8sはマルチテナントになっており、1アプリケーション1namespaceで論理的な
    リソース境界を定義している。
    GKE/EKS
    namespace=x
    x-service
    namespace=y
    y-service

    View Slide

  10. DMMプラットフォームは
    k8s(GKE & EKS)を利用している

    View Slide

  11. 再掲:DMMプラットフォームのエンジニアリング組織
    DMMプラットフォームのエンジニアリング組織は大きく2つに分類することがで
    きる。
    ● SREチーム
    DMMプラットフォームの共通インフラを構築・運用するチーム。
    ● 開発チーム
    共通インフラを利用するチーム。
    SREチーム以外のチームは開発チームとみなしていい。

    View Slide

  12. 共通インフラにおける
    責任境界とリソース管理はどうするのか?

    View Slide

  13. 責任境界とは?
    SREチームと開発チームはk8sの利用において、どちらがどの程度責任を負う
    のか? という境界のことを指している。
    例:k8sのマニフェストファイルは誰が書くのか?

    View Slide

  14. リソース管理とは?
    共通インフラを構成するリソースの管理方法のことである。
    例:
    k8sのマニフェストファイルはどこに保存するのか?
    k8sのマニフェストファイルをどうやって編集し、反映させるのか?

    View Slide

  15. 共通インフラならではの課題
    エンジニア120人の組織で共通インフラを利用する場合、何でもできる管理者
    権限を全員に付与するわけにもいかない。
    操作ミスによる意図しない障害が発生する可能性がある。
    (k8sに限らず)責任境界とリソース管理を設計する必要がある。

    View Slide

  16. まずは責任境界について

    View Slide

  17. 結論:責任境界の方針
    SREチームは開発チームが共通利用するツールや仕組みを構築・運用すること
    に責任を持つ。
    開発チームはそれらのツールや仕組みをアプリケーションに合わせて適切に利
    用する責任を持つ。

    View Slide

  18. 責任境界のイメージ
    例 責任を持つのは?
    k8sのノードのスケールやキャパシティプランニング SREチームが責任を持つ。
    k8sのポッドのスケールやキャパシティプランニング 開発チームが責任を持つ。

    View Slide

  19. 責任境界のイメージ
    例 責任を持つのは?
    CDツールの構築と運用 SREチームが責任を持つ。
    CDツールを利用したアプリ
    ケーションのデプロイ設定
    開発チームが責任を持つ。
    CDツールの仕様を理解し、必要な設定を指定する必要があ
    る。

    View Slide

  20. 開発チームが担当する業務
    アプリケーション依存のあれこれは開発チームに責任を持ってもらっている。
    ● マニフェストファイルの設定
    ● アプリケーションのデプロイ設定
    ● Datadogを利用したモニター設定、ダッシュボード作成
    ● 各種ツールのトラブルシューティング
    ポッドが立ち上がらないとか

    View Slide

  21. 再掲:マルチテナント型のk8sについて
    k8sはマルチテナントになっており、1アプリケーション1namespaceで論理的な
    リソース境界を定義している。
    GKE/EKS
    namespace=x
    x-service
    namespace=y
    y-service

    View Slide

  22. k8sのnamespaceについて
    開発チームにアプリケーション依存のあれこれに対して責任をもってもらうた
    め、開発チームはnamespaceに対する全権限(全責任)を持つ。
    namespaceにどのようなリソースを配置するか、どのように運用するかは開発
    チームに委ねられている。
    *ただ、勝手にIngressとか作られると困るので最低限のルールはある。

    View Slide

  23. 開発チームの学習コストが問題になる
    開発チームはアプリケーションに依存するあれこれを自分たちで対応する必要
    があるので、共通インフラで採用されている技術に対する学習コストがかかって
    しまう。

    View Slide

  24. k8sに詳しいSREチームが
    責任を持った方がいいのでは?

    View Slide

  25. 責任境界とコミュニケーションコストについて
    仮にSREチームがアプリケーション依存のあれこれにも責任を持ってしまうと、
    開発チームとSREチームのコミュニケーションが発生してしまう。
    例:
    開発チームがマイクロサービスのポッド数を増やすためにSREチームに申請を
    出す必要がある。

    View Slide

  26. 学習コストとコミュニケーションコストのトレードオフ
    開発チームの学習コスト
    高い 低い
    SREチームとのコミュニケーションコスト
    低い 高い

    View Slide

  27. コミュニケーションコストは予想以上に高くなる
    SREチームはアプリケーションに依存する要件を把握する必要があるので、開
    発チームとのコミュニケーションコストは想像以上に高くなる可能性が高い。

    View Slide

  28. pospomeが目指す本来あるべき姿
    自分たちが使う技術は自分たちでちゃんと理解し、開発チーム自身がアプリ
    ケーションの開発・運用をワンチームで完結させることを目指している。
    *SREチームにヘルプを依頼できる相談用窓口を用意しているので、困ったら
    相談することができるようになっている。

    View Slide

  29. 開発チームとSREチームのコミュニケーションをなくすことはできない
    SREチームが管理している共通インフラ自体に開発チームから変更依頼が来る
    ことは当然あるので、開発チームとSREチームのコミュニケーションをなくすこと
    はできない。
    例:
    Datadog AgentでXXXの機能を有効にして欲しい。

    View Slide

  30. SREチームが責任を持った方がいいケース
    限定的だが、SREチームが責任を持った方がいいケースもある。
    ● 開発チームにとって理解が難しいインフラを持っている場合
    ● 何かしらのルールによってSREチームが責任を持たざるを得ない場合
    ● などなど

    View Slide

  31. リソース管理について

    View Slide

  32. 再掲:リソース管理とは?
    共通インフラを構成するリソースの管理方法のことである。
    例:
    k8sのマニフェストファイルはどこに保存するのか?
    k8sのマニフェストファイルをどうやって編集し、反映させるのか?

    View Slide

  33. リソース管理のパターン
    主に以下のパターンがある。
    1. 単一チームによる一元管理
    2. 各チームによる個別管理
    *パターンとしては ”単一チームによる個別管理” , “各チームにより一元管理”
    もあるが時間の都合上割愛。

    View Slide

  34. 1.単一チームによる一元管理
    e.g. k8sのマニフェストファイルを管理する
    会員チームの
    マニフェストファイル
    決済チームの
    マニフェストファイル SREチーム
    決済チーム
    会員チーム 構築・運用する
    編集する
    編集する

    View Slide

  35. 2.各チームによる個別管理
    e.g. k8sのマニフェストファイルを管理する
    会員チームの
    マニフェスト
    ファイル
    会員チーム
    決済チームの
    マニフェスト
    ファイル
    決済チーム
    構築・運用・編集する 構築・運用・編集する

    View Slide

  36. リソース管理パターンのメリデメ
    パターン 組織全体の作業効

    エコシステム導入 リソース単位の
    権限管理
    個別要件の対応
    一元管理 高い 簡単 難しい 難しい
    個別管理 低い 難しい 簡単 簡単

    View Slide

  37. リソース管理パターンのメリデメ
    パターン 組織全体の作業効

    エコシステム導入 リソース単位の
    権限管理
    個別要件の対応
    一元管理 高い 簡単 難しい 難しい
    個別管理 低い 難しい 簡単 簡単
    リソースの所有者によって要件が大きく異なるものは個別管理が向いている。
    一元管理で権限や個別要件に対応するには
    それなりのエンジニアリソースと作り込みが必要になる可能性が高い。

    View Slide

  38. DMMプラットフォームにおいて
    共通インフラのリソースはどうなっている?

    View Slide

  39. 共通インフラ関連のリソースは一元管理する方針
    SREチームが管理する共通インフラに関連するリソースは比較的一元管理して
    も問題なさそうなものが多いので、一元管理を採用する方針に倒した。

    View Slide

  40. 共通インフラ関連のリソースは?
    ● GCPプロジェクトのアカウント
    ● AWSアカウントのIAM User
    ● k8sマニフェストファイル
    ● k8s RBAC
    ● GitHub アカウント
    ● GitHub Teams
    ● Slackアカウント
    ● Slack User Group
    ● GCPプロジェクトのIaC
    ● AWSアカウントのIaC
    ● Datadog アカウント
    ● Pager Dutyアカウント
    ● GAR
    ● ArgoCDのアカウント
    などなど・・・

    View Slide

  41. Slack User Group は共通インフラのリソースなのか?
    DMMプラットフォームは120人以上のエンジニアが所属する組織であり、マイ
    クロサービスを採用しているので、誰がどのマイクロサービスを担当しているの
    かを把握するのが難しい。
    担当者に連絡できるようにマイクロサービスごとにSlack User Groupを管理して
    いる。

    View Slide

  42. リソース管理は責任境界を考慮する必要がある
    リソースに対して責任を持つ人やチームが自身でそのリソースを安全に操作で
    きるようにするのが理想である。
    これによってコミュニケーションコストが低くなる。
    例:
    開発チームが責任を持つk8sマニフェストファイルは開発チーム自身が変更で
    きるように管理する。

    View Slide

  43. SREチームが構築するリソース管理の仕組みの要件
    開発チームが責任を持つリソースは開発チームが自由に操作できるようにする
    必要がある。
    SREチームが構築・運用する仕組みはこれを満たす形でなければいけない。

    View Slide

  44. 具体的なリソース管理の仕組みについて

    View Slide

  45. リソース管理の仕組み
    DMMプラットフォームでは以下の2つの仕組みで共通インフラの各種リソース
    を管理している。
    1. Super Terraform
    2. Osiris

    View Slide

  46. Super Terraform

    View Slide

  47. Super Terraformとは?
    DMMプラットフォームの共通インフラにおけるk8sマニフェストファイル以外を
    管理する仕組みである。
    実体として単一のGitHubリポジトリにホスティングしているTerraform定義であ
    る。

    View Slide

  48. Super Terraformとは?
    Super Terraformは主に以下を管理する。
    ● 開発者の各種アカウント
    ● マイクロサービスの設定
    ● 共通インフラのIaC

    View Slide

  49. 開発者の各種アカウント
    Terraformのmap型変数に
    開発者の情報を指定すると、
    自動的に各種アカウントと権限が
    設定される。
    開発者は変数を追加/編集していくだけ。

    View Slide

  50. マイクロサービスの設定
    Terraformのmap型変数に
    マイクロサービスの情報を指定すると、
    自動的に必要なリソースや設定が
    実施される。

    View Slide

  51. 共通インフラのIaC
    共通インフラのIaCもホスティングしている。
    基本的にSREチームしか触らない。
    普通のTerraform定義なので説明することはない。

    View Slide

  52. Super Terraformのユースケース
    Super Terraformのユースケースを紹介する。
    1. 開発者が共通インフラの利用を申請する。
    2. 開発者がマイクロサービスを新規作成する。
    3. SREが共通インフラのリソースを操作する。
    普通にTerraformの定義を修正するだけなので割愛。

    View Slide

  53. 1. 開発者が共通インフラの利用を申請する
    申請者自身が利用申請のPull Requestを出せるようにしている。
    申請者はSuper Terraformに対するWrite権限がないので、Slackのスラッシュ
    コマンドで自動的にPRを作成できるようになっている。

    View Slide

  54. 1. 開発者が共通インフラの利用を申請する
    Slackコマンドによって
    作成された利用申請のPull Requestは、
    最低限の閲覧権限のみ付与されたものに
    なっている。

    View Slide

  55. 1. 開発者が共通インフラの利用を申請する
    利用申請のPull Requestは
    チーム内の承認権限を持っている人に
    承認&マージしてもらう。
    承認権限は開発者定義の
    “github_approver = true” の人が持っている。

    View Slide

  56. 1. 開発者が共通インフラの利用を申請する
    利用申請のPull Requestを
    マージするとSuper Terraformへの
    Write権限が付与される。
    今後は利用者自身が必要に応じて
    Pull Requestを作成できる。

    View Slide

  57. 1. 開発者が共通インフラの利用を申請する
    共通インフラは必要となるツールや権限が多いので、
    Super Terraformを利用することで必要なアカウントや権限を一括で付与できる
    ようにしている。
    異動や退職によってエンジニアが離れる場合も定義を削除すればいいだけで
    ある。

    View Slide

  58. Super Terraformのユースケース
    Super Terraformのユースケースを紹介する。
    1. 開発者が共通インフラの利用を申請する。
    2. 開発者がマイクロサービスを新規作成する。
    3. SREが共通インフラのリソースを操作する。
    普通にTerraformの定義を修正するだけなので割愛。

    View Slide

  59. 2. 開発者がマイクロサービスを新規作成する
    GitHub ActionsのWorkFlowで
    マイクロサービスの新規作成に
    必要なリソースや設定を定義した
    Pull Requestを作成できる。

    View Slide

  60. 2. 開発者がマイクロサービスを新規作成する
    Pull Requestがマージされると、
    以下のリソースが作成される。
    ● GARリポジトリ作成 & 権限付与
    ● Transit Gatewayとの接続
    ● Slack User Group
    ● などなど・・・
    *今まではSREチームに依頼が必要だった。

    View Slide

  61. 2. 開発者がマイクロサービスを新規作成する
    マイクロサービスの設定はCODE OWNERによって権限設定されているので、
    他チームのマイクロサービスの設定を変更することはできない。

    View Slide

  62. 2. 開発者がマイクロサービスを新規作成する
    マイクロサービスの新規作成は誰でもできるようになっている。
    DMMプラットフォームではマイクロサービスを新規作成する際にDesign Docの
    レビューがあるので、おかしなマイクロサービスが新規作成される可能性は低
    い。

    View Slide

  63. Super Terraformのあれこれ

    View Slide

  64. Super Terraformにおける役割分担
    チーム 責任
    SREチーム TerraformをホスティングするGitHubリポジトリの構築・運用や
    Terraform自体の設計を担当する。
    開発チーム 自分たちが管理する Terraform定義のmap型変数の値が妥当であ
    ることに責任を持つ。

    View Slide

  65. SREチームとのやりとりを極力なくす
    Super Terraformは開発チーム自身が自分たちでアカウント作成や権限設定
    ができるようになっている。
    以前はSREチームの作業待ちが発生していたが、大分削減できるようになっ
    た。

    View Slide

  66. SREチームが許可した権限のみを提供できる
    開発チームはTerraformのmap型変数を
    編集するだけなので、
    Super Terraformで設定できる権限は
    SREがあらかじめ許可したものに
    限定することができる。

    View Slide

  67. 組織構造を取り入れない
    Super Terraformは開発者、マイクロサービスという粒度でリソースを管理して
    おり、チームや部署といった組織構造を取り入れることはしていない。
    組織構造は定期的に変わってしまうので、Super Terraform上でのマイグレー
    ション作業が発生するのを避けたかった。
    現在のSREチームではそこをメンテする工数が割けないので、
    初期要件から落とした。

    View Slide

  68. アカウント情報以外のIaCは管理していない
    Datadog, Pager Dutyに限ってはアカウント情報のみIaCで管理しており、それ
    以外のリソースはUI上でポチポチ操作してもらっている。
    既存のリソースをIaC化するのが大変だった & 今まで通りUIから操作してもら
    えればいいという判断で初期要件から落としている。

    View Slide

  69. 実はリソースカタログが欲しかった
    今後の共通インフラは少し手の込んだ自動化を進める段階に入っていくので、
    このタイミングでDMMプラットフォーム内のリソースを管理するリソースカタログ
    が必要だった。
    Super Terraformは元々リソースカタログが欲しくて作り始めた仕組みだったり
    する。

    View Slide

  70. Osiris

    View Slide

  71. Osirisとは?
    DMMプラットフォームの共通インフラにおけるk8sマニフェストファイルを管理す
    る仕組みである。

    View Slide

  72. Osirisとは?
    ● 実体としては単一のGitHubリポジトリである。
    ● マニフェストファイルはkustomizeにより抽象化できるようになっている。
    ● Super Terraformで開発者登録するとOsirisへのWrite権限が付与され
    る。

    View Slide

  73. Osirisとは?
    Osirisは主に以下を管理する。
    ● 開発チームが管理するマニフェストファイル
    主にWebアプリケーションのマニフェストファイルである。
    ● SREチームが管理するマニフェストファイル
    ArgoCD, Datadog Agent など共通インフラを構成するツールのマニフェス
    トファイルである。

    View Slide

  74. Osirisのユースケース
    Osirisのユースケースを紹介する。
    1. 開発者がマイクロサービスを新規作成する。
    2. 開発者がマニフェストファイルを変更する。
    3. SREが共通インフラのマニフェストファイルを変更する。
    2番とほぼ同じなので割愛する。

    View Slide

  75. 1. 開発者がマイクロサービスを新規作成する
    Super Terraformと同様に
    GitHub ActionsのWorkflowによって
    Pull Requestを作成する。

    View Slide

  76. 1. 開発者がマイクロサービスを新規作成する
    Pull RequestにはGitHub Actionsの
    Workflowによって入力された値を
    反映したマニフェストファイルが
    自動的に作成される。

    View Slide

  77. 1. 開発者がマイクロサービスを新規作成する
    開発者はPull Requestで自動生成されたマニフェストファイルをアプリケーショ
    ンに合わせて修正する必要がある。
    ● ArgoCDのデプロイ設定
    ● Deploymentの環境変数定義
    ● HPAのスケール設定
    ● などなど

    View Slide

  78. 1. 開発者がマイクロサービスを新規作成する
    作成されたPull Requestは開発チーム自身でレビューし、問題なければそのま
    まマージしてもらう。
    任意でSREチームにレビューを依頼することもできる。

    View Slide

  79. Osirisのユースケース
    Osirisのユースケースを紹介する。
    1. 開発者がマイクロサービスを新規作成する。
    2. 開発者がマニフェストファイルを変更する。
    3. SREが共通インフラのマニフェストファイルを変更する。
    2番とほぼ同じなので割愛する。

    View Slide

  80. 2. 開発者がマニフェストファイルを変更する
    マニフェストファイルの変更も
    開発チームがPull Requestを作成し、
    チーム内でレビュー&マージする。
    マニフェストファイルは
    kustomizeで抽象化されており、
    全環境共通の設定と環境差分を
    それぞれ管理できるようになっている。

    View Slide

  81. 2. 開発者がマニフェストファイルを変更する
    Pull Requestをmainブランチにマージしても
    マニフェストファイルがk8sに
    反映されることはない。
    マニフェストファイルの反映は
    GitHub Actions の Workflowにて実行する。

    View Slide

  82. 2. 開発者がマニフェストファイルを変更する
    Workflowを実行すると、
    自動的にPull Requestが作成される。
    これをマージすると反映される。
    Pull Requestでは
    既存のマニフェストファイルとの
    差分をk8sのプレーンなyamlで
    確認することができる。

    View Slide

  83. 補足:アプリケーションのデプロイについて
    アプリケーションのデプロイはGARを利用したImageOpsになっているので、ア
    プリケーションのデプロイでOsirisが利用されることはない。

    View Slide

  84. Osirisのあれこれ

    View Slide

  85. Osirisにおける役割分担
    チーム 責任
    SREチーム マニフェストファイルをホスティングする GitHubリポジトリの構築・運
    用を担当する。
    マニフェストファイルのディレクトリ構成設計、 CI実装、抽象化ツール
    の選定を担当する。
    開発チーム 自分たちが管理するマニフェストファイルの各種設定が妥当である
    ことに責任を持つ。
    e.g. ポット数、スケール設定

    View Slide

  86. SREチームとのやりとりを極力なくす
    Super Terraformと同様に開発チーム自身が自分たちでマニフェストファイルを
    変更することができる。
    マニフェストファイルはCODE OWNERによって権限管理されている。

    View Slide

  87. CI周りの不足
    ● マニフェストファイル上のAPI Versionの更新案内
    ● マニフェストファイルの修正依頼
    CPU, Memoryのrequestが大きすぎるなど。
    まだまだ作り込みが甘いと思っている。

    View Slide

  88. まとめ

    View Slide

  89. DMMプラットフォームの責任境界
    チーム名 責任
    SREチーム アプリケーションに依存しないチーム横断で必要となる領域に責任を持つ
    開発チーム 自分たちが管理するアプリケーションに依存する領域に責任を持つ

    View Slide

  90. DMMプラットフォームのリソース管理
    リソースはSREチームによって一元管理されるが、責任境界に沿った形で各種
    ユースケースを実現できるようにする。

    View Slide

  91. 適切な責任境界とリソース管理
    適切な責任境界とリソース管理は組織によって異なるので、自分たちに合った
    方針を考える必要がある。
    DMMプラットフォームの事例が良くも悪くも役に立てばいいなと思っています。

    View Slide

  92. おわり

    View Slide