Cloud Native Days Tokyo 2022 の資料です。 動画は以下にあります（CloudNative Days Tokyoのサイトにログインしないと見れないと思います）。 https://event.cloudnativedays.jp/cndt2022/talks/1559
マイクロサービスとk8sにおける責任境界設計とリソース管理
View Slide
登壇者名前：pospome（ぽすぽめ）所属：DMMプラットフォームTwitter:@pospome
今回の発表内容について100人規模の開発組織xk8sx責任境界設計とリソース管理
DMMプラットフォームについて扱う領域：DMM会員、決済、DMMポイント、不正対策などエンジニア数：120名以上開発チーム数：16チームマイクロサービス数：約40サービスピーク時のリクエスト：14,000RPS
DMMプラットフォームとマイクロサービスプラットフォーム開発は開発規模が大きいので、DMMプラットフォームは約6,7年前からマイクロサービスアーキテクチャを採用している。＊マイクロサービスを前提とした内容になります。
DMMプラットフォームのエンジニアリング組織DMMプラットフォームのエンジニアリング組織は大きく2つに分類することができる。● SREチームDMMプラットフォームの共通インフラを構築・運用するチーム。● 開発チーム共通インフラを利用するチーム。チーム数としては16チーム存在する。SREチーム以外のチームは開発チームとみなしていい。
DMMプラットフォームの共通インフラについてDMMプラットフォームには120名のエンジニアが利用する共通インフラが存在する。● アプリケーション実行環境（GKE/EKS）● CD Pipeline（ArgoCD）● Container Registry（GCP Artifact Registry）● Log/Metrics（Datadog）
SREチームのAWSアカウントAmazon Elastic KubernetesService (EKS)共通インフラのシステムアーキテクチャ図DatadogマイクロサービスSREチームのGCPプロジェクトGKEマイクロサービスArgoCDGARDMMプラットフォームは諸事情によりマルチクラウド環境になっています。理由は時間の都合上割愛します。
マルチテナント型のk8sについてk8sはマルチテナントになっており、1アプリケーション1namespaceで論理的なリソース境界を定義している。GKE/EKSnamespace=xx-servicenamespace=yy-service
DMMプラットフォームはk8s(GKE & EKS）を利用している
再掲：DMMプラットフォームのエンジニアリング組織DMMプラットフォームのエンジニアリング組織は大きく2つに分類することができる。● SREチームDMMプラットフォームの共通インフラを構築・運用するチーム。● 開発チーム共通インフラを利用するチーム。SREチーム以外のチームは開発チームとみなしていい。
共通インフラにおける責任境界とリソース管理はどうするのか?
責任境界とは?SREチームと開発チームはk8sの利用において、どちらがどの程度責任を負うのか? という境界のことを指している。例：k8sのマニフェストファイルは誰が書くのか?
リソース管理とは?共通インフラを構成するリソースの管理方法のことである。例：k8sのマニフェストファイルはどこに保存するのか?k8sのマニフェストファイルをどうやって編集し、反映させるのか?
共通インフラならではの課題エンジニア120人の組織で共通インフラを利用する場合、何でもできる管理者権限を全員に付与するわけにもいかない。操作ミスによる意図しない障害が発生する可能性がある。（k8sに限らず）責任境界とリソース管理を設計する必要がある。
まずは責任境界について
結論：責任境界の方針SREチームは開発チームが共通利用するツールや仕組みを構築・運用することに責任を持つ。開発チームはそれらのツールや仕組みをアプリケーションに合わせて適切に利用する責任を持つ。
責任境界のイメージ例 責任を持つのは?k8sのノードのスケールやキャパシティプランニング SREチームが責任を持つ。k8sのポッドのスケールやキャパシティプランニング 開発チームが責任を持つ。
責任境界のイメージ例 責任を持つのは?CDツールの構築と運用 SREチームが責任を持つ。CDツールを利用したアプリケーションのデプロイ設定開発チームが責任を持つ。CDツールの仕様を理解し、必要な設定を指定する必要がある。
開発チームが担当する業務アプリケーション依存のあれこれは開発チームに責任を持ってもらっている。● マニフェストファイルの設定● アプリケーションのデプロイ設定● Datadogを利用したモニター設定、ダッシュボード作成● 各種ツールのトラブルシューティングポッドが立ち上がらないとか
再掲：マルチテナント型のk8sについてk8sはマルチテナントになっており、1アプリケーション1namespaceで論理的なリソース境界を定義している。GKE/EKSnamespace=xx-servicenamespace=yy-service
k8sのnamespaceについて開発チームにアプリケーション依存のあれこれに対して責任をもってもらうため、開発チームはnamespaceに対する全権限（全責任）を持つ。namespaceにどのようなリソースを配置するか、どのように運用するかは開発チームに委ねられている。＊ただ、勝手にIngressとか作られると困るので最低限のルールはある。
開発チームの学習コストが問題になる開発チームはアプリケーションに依存するあれこれを自分たちで対応する必要があるので、共通インフラで採用されている技術に対する学習コストがかかってしまう。
k8sに詳しいSREチームが責任を持った方がいいのでは?
責任境界とコミュニケーションコストについて仮にSREチームがアプリケーション依存のあれこれにも責任を持ってしまうと、開発チームとSREチームのコミュニケーションが発生してしまう。例：開発チームがマイクロサービスのポッド数を増やすためにSREチームに申請を出す必要がある。
学習コストとコミュニケーションコストのトレードオフ開発チームの学習コスト高い 低いSREチームとのコミュニケーションコスト低い 高い
コミュニケーションコストは予想以上に高くなるSREチームはアプリケーションに依存する要件を把握する必要があるので、開発チームとのコミュニケーションコストは想像以上に高くなる可能性が高い。
pospomeが目指す本来あるべき姿自分たちが使う技術は自分たちでちゃんと理解し、開発チーム自身がアプリケーションの開発・運用をワンチームで完結させることを目指している。＊SREチームにヘルプを依頼できる相談用窓口を用意しているので、困ったら相談することができるようになっている。
開発チームとSREチームのコミュニケーションをなくすことはできないSREチームが管理している共通インフラ自体に開発チームから変更依頼が来ることは当然あるので、開発チームとSREチームのコミュニケーションをなくすことはできない。例：Datadog AgentでXXXの機能を有効にして欲しい。
SREチームが責任を持った方がいいケース限定的だが、SREチームが責任を持った方がいいケースもある。● 開発チームにとって理解が難しいインフラを持っている場合● 何かしらのルールによってSREチームが責任を持たざるを得ない場合● などなど
リソース管理について
再掲：リソース管理とは?共通インフラを構成するリソースの管理方法のことである。例：k8sのマニフェストファイルはどこに保存するのか?k8sのマニフェストファイルをどうやって編集し、反映させるのか?
リソース管理のパターン主に以下のパターンがある。1. 単一チームによる一元管理2. 各チームによる個別管理＊パターンとしては ”単一チームによる個別管理” , “各チームにより一元管理”もあるが時間の都合上割愛。
1.単一チームによる一元管理e.g. k8sのマニフェストファイルを管理する会員チームのマニフェストファイル決済チームのマニフェストファイル SREチーム決済チーム会員チーム 構築・運用する編集する編集する
2.各チームによる個別管理e.g. k8sのマニフェストファイルを管理する会員チームのマニフェストファイル会員チーム決済チームのマニフェストファイル決済チーム構築・運用・編集する 構築・運用・編集する
リソース管理パターンのメリデメパターン 組織全体の作業効率エコシステム導入 リソース単位の権限管理個別要件の対応一元管理 高い 簡単 難しい 難しい個別管理 低い 難しい 簡単 簡単
リソース管理パターンのメリデメパターン 組織全体の作業効率エコシステム導入 リソース単位の権限管理個別要件の対応一元管理 高い 簡単 難しい 難しい個別管理 低い 難しい 簡単 簡単リソースの所有者によって要件が大きく異なるものは個別管理が向いている。一元管理で権限や個別要件に対応するにはそれなりのエンジニアリソースと作り込みが必要になる可能性が高い。
DMMプラットフォームにおいて共通インフラのリソースはどうなっている?
共通インフラ関連のリソースは一元管理する方針SREチームが管理する共通インフラに関連するリソースは比較的一元管理しても問題なさそうなものが多いので、一元管理を採用する方針に倒した。
共通インフラ関連のリソースは?● GCPプロジェクトのアカウント● AWSアカウントのIAM User● k8sマニフェストファイル● k8s RBAC● GitHub アカウント● GitHub Teams● Slackアカウント● Slack User Group● GCPプロジェクトのIaC● AWSアカウントのIaC● Datadog アカウント● Pager Dutyアカウント● GAR● ArgoCDのアカウントなどなど・・・
Slack User Group は共通インフラのリソースなのか?DMMプラットフォームは120人以上のエンジニアが所属する組織であり、マイクロサービスを採用しているので、誰がどのマイクロサービスを担当しているのかを把握するのが難しい。担当者に連絡できるようにマイクロサービスごとにSlack User Groupを管理している。
リソース管理は責任境界を考慮する必要があるリソースに対して責任を持つ人やチームが自身でそのリソースを安全に操作できるようにするのが理想である。これによってコミュニケーションコストが低くなる。例：開発チームが責任を持つk8sマニフェストファイルは開発チーム自身が変更できるように管理する。
SREチームが構築するリソース管理の仕組みの要件開発チームが責任を持つリソースは開発チームが自由に操作できるようにする必要がある。SREチームが構築・運用する仕組みはこれを満たす形でなければいけない。
具体的なリソース管理の仕組みについて
リソース管理の仕組みDMMプラットフォームでは以下の2つの仕組みで共通インフラの各種リソースを管理している。1. Super Terraform2. Osiris
Super Terraform
Super Terraformとは?DMMプラットフォームの共通インフラにおけるk8sマニフェストファイル以外を管理する仕組みである。実体として単一のGitHubリポジトリにホスティングしているTerraform定義である。
Super Terraformとは?Super Terraformは主に以下を管理する。● 開発者の各種アカウント● マイクロサービスの設定● 共通インフラのIaC
開発者の各種アカウントTerraformのmap型変数に開発者の情報を指定すると、自動的に各種アカウントと権限が設定される。開発者は変数を追加/編集していくだけ。
マイクロサービスの設定Terraformのmap型変数にマイクロサービスの情報を指定すると、自動的に必要なリソースや設定が実施される。
共通インフラのIaC共通インフラのIaCもホスティングしている。基本的にSREチームしか触らない。普通のTerraform定義なので説明することはない。
Super TerraformのユースケースSuper Terraformのユースケースを紹介する。1. 開発者が共通インフラの利用を申請する。2. 開発者がマイクロサービスを新規作成する。3. SREが共通インフラのリソースを操作する。普通にTerraformの定義を修正するだけなので割愛。
1. 開発者が共通インフラの利用を申請する申請者自身が利用申請のPull Requestを出せるようにしている。申請者はSuper Terraformに対するWrite権限がないので、Slackのスラッシュコマンドで自動的にPRを作成できるようになっている。
1. 開発者が共通インフラの利用を申請するSlackコマンドによって作成された利用申請のPull Requestは、最低限の閲覧権限のみ付与されたものになっている。
1. 開発者が共通インフラの利用を申請する利用申請のPull Requestはチーム内の承認権限を持っている人に承認&マージしてもらう。承認権限は開発者定義の“github_approver = true” の人が持っている。
1. 開発者が共通インフラの利用を申請する利用申請のPull RequestをマージするとSuper TerraformへのWrite権限が付与される。今後は利用者自身が必要に応じてPull Requestを作成できる。
1. 開発者が共通インフラの利用を申請する共通インフラは必要となるツールや権限が多いので、Super Terraformを利用することで必要なアカウントや権限を一括で付与できるようにしている。異動や退職によってエンジニアが離れる場合も定義を削除すればいいだけである。
2. 開発者がマイクロサービスを新規作成するGitHub ActionsのWorkFlowでマイクロサービスの新規作成に必要なリソースや設定を定義したPull Requestを作成できる。
2. 開発者がマイクロサービスを新規作成するPull Requestがマージされると、以下のリソースが作成される。● GARリポジトリ作成 & 権限付与● Transit Gatewayとの接続● Slack User Group● などなど・・・＊今まではSREチームに依頼が必要だった。
2. 開発者がマイクロサービスを新規作成するマイクロサービスの設定はCODE OWNERによって権限設定されているので、他チームのマイクロサービスの設定を変更することはできない。
2. 開発者がマイクロサービスを新規作成するマイクロサービスの新規作成は誰でもできるようになっている。DMMプラットフォームではマイクロサービスを新規作成する際にDesign Docのレビューがあるので、おかしなマイクロサービスが新規作成される可能性は低い。
Super Terraformのあれこれ
Super Terraformにおける役割分担チーム 責任SREチーム TerraformをホスティングするGitHubリポジトリの構築・運用やTerraform自体の設計を担当する。開発チーム 自分たちが管理する Terraform定義のmap型変数の値が妥当であることに責任を持つ。
SREチームとのやりとりを極力なくすSuper Terraformは開発チーム自身が自分たちでアカウント作成や権限設定ができるようになっている。以前はSREチームの作業待ちが発生していたが、大分削減できるようになった。
SREチームが許可した権限のみを提供できる開発チームはTerraformのmap型変数を編集するだけなので、Super Terraformで設定できる権限はSREがあらかじめ許可したものに限定することができる。
組織構造を取り入れないSuper Terraformは開発者、マイクロサービスという粒度でリソースを管理しており、チームや部署といった組織構造を取り入れることはしていない。組織構造は定期的に変わってしまうので、Super Terraform上でのマイグレーション作業が発生するのを避けたかった。現在のSREチームではそこをメンテする工数が割けないので、初期要件から落とした。
アカウント情報以外のIaCは管理していないDatadog, Pager Dutyに限ってはアカウント情報のみIaCで管理しており、それ以外のリソースはUI上でポチポチ操作してもらっている。既存のリソースをIaC化するのが大変だった & 今まで通りUIから操作してもらえればいいという判断で初期要件から落としている。
実はリソースカタログが欲しかった今後の共通インフラは少し手の込んだ自動化を進める段階に入っていくので、このタイミングでDMMプラットフォーム内のリソースを管理するリソースカタログが必要だった。Super Terraformは元々リソースカタログが欲しくて作り始めた仕組みだったりする。
Osiris
Osirisとは?DMMプラットフォームの共通インフラにおけるk8sマニフェストファイルを管理する仕組みである。
Osirisとは?● 実体としては単一のGitHubリポジトリである。● マニフェストファイルはkustomizeにより抽象化できるようになっている。● Super Terraformで開発者登録するとOsirisへのWrite権限が付与される。
Osirisとは?Osirisは主に以下を管理する。● 開発チームが管理するマニフェストファイル主にWebアプリケーションのマニフェストファイルである。● SREチームが管理するマニフェストファイルArgoCD, Datadog Agent など共通インフラを構成するツールのマニフェストファイルである。
OsirisのユースケースOsirisのユースケースを紹介する。1. 開発者がマイクロサービスを新規作成する。2. 開発者がマニフェストファイルを変更する。3. SREが共通インフラのマニフェストファイルを変更する。2番とほぼ同じなので割愛する。
1. 開発者がマイクロサービスを新規作成するSuper Terraformと同様にGitHub ActionsのWorkflowによってPull Requestを作成する。
1. 開発者がマイクロサービスを新規作成するPull RequestにはGitHub ActionsのWorkflowによって入力された値を反映したマニフェストファイルが自動的に作成される。
1. 開発者がマイクロサービスを新規作成する開発者はPull Requestで自動生成されたマニフェストファイルをアプリケーションに合わせて修正する必要がある。● ArgoCDのデプロイ設定● Deploymentの環境変数定義● HPAのスケール設定● などなど
1. 開発者がマイクロサービスを新規作成する作成されたPull Requestは開発チーム自身でレビューし、問題なければそのままマージしてもらう。任意でSREチームにレビューを依頼することもできる。
2. 開発者がマニフェストファイルを変更するマニフェストファイルの変更も開発チームがPull Requestを作成し、チーム内でレビュー&マージする。マニフェストファイルはkustomizeで抽象化されており、全環境共通の設定と環境差分をそれぞれ管理できるようになっている。
2. 開発者がマニフェストファイルを変更するPull Requestをmainブランチにマージしてもマニフェストファイルがk8sに反映されることはない。マニフェストファイルの反映はGitHub Actions の Workflowにて実行する。
2. 開発者がマニフェストファイルを変更するWorkflowを実行すると、自動的にPull Requestが作成される。これをマージすると反映される。Pull Requestでは既存のマニフェストファイルとの差分をk8sのプレーンなyamlで確認することができる。
補足：アプリケーションのデプロイについてアプリケーションのデプロイはGARを利用したImageOpsになっているので、アプリケーションのデプロイでOsirisが利用されることはない。
Osirisのあれこれ
Osirisにおける役割分担チーム 責任SREチーム マニフェストファイルをホスティングする GitHubリポジトリの構築・運用を担当する。マニフェストファイルのディレクトリ構成設計、 CI実装、抽象化ツールの選定を担当する。開発チーム 自分たちが管理するマニフェストファイルの各種設定が妥当であることに責任を持つ。e.g. ポット数、スケール設定
SREチームとのやりとりを極力なくすSuper Terraformと同様に開発チーム自身が自分たちでマニフェストファイルを変更することができる。マニフェストファイルはCODE OWNERによって権限管理されている。
CI周りの不足● マニフェストファイル上のAPI Versionの更新案内● マニフェストファイルの修正依頼CPU, Memoryのrequestが大きすぎるなど。まだまだ作り込みが甘いと思っている。
まとめ
DMMプラットフォームの責任境界チーム名 責任SREチーム アプリケーションに依存しないチーム横断で必要となる領域に責任を持つ開発チーム 自分たちが管理するアプリケーションに依存する領域に責任を持つ
DMMプラットフォームのリソース管理リソースはSREチームによって一元管理されるが、責任境界に沿った形で各種ユースケースを実現できるようにする。
適切な責任境界とリソース管理適切な責任境界とリソース管理は組織によって異なるので、自分たちに合った方針を考える必要がある。DMMプラットフォームの事例が良くも悪くも役に立てばいいなと思っています。
おわり
pospome
nishiuma
terahide
oracle4engineer
lmi
colopl
ryokaneoka0406
salaboy
cheng_wei_chen
pf_businessdivision
line_developers
linedevth
bengo4com
jlugia
frogandcode
phodgson
jeffersonlam
bermonpainter
iamctodd
sonatard
denniskardys
chrislema
caitiem20
bkeepers
zakiyama