Slide 1
Slide 1 text
マイクロサービスとk8sにおける責
任境界設計とリソース管理
Slide 2
Slide 2 text
登壇者
名前：pospome（ぽすぽめ）
所属：DMMプラットフォーム
Twitter:@pospome
Slide 3
Slide 3 text
今回の発表内容について
100人規模の開発組織
x
k8s
x
責任境界設計とリソース管理
Slide 4
Slide 4 text
DMMプラットフォームについて
扱う領域：DMM会員、決済、DMMポイント、不正対策など
エンジニア数：120名以上
開発チーム数：16チーム
マイクロサービス数：約40サービス
ピーク時のリクエスト：14,000RPS
Slide 5
Slide 5 text
DMMプラットフォームとマイクロサービス
プラットフォーム開発は開発規模が大きいので、
DMMプラットフォームは約6,7年前から
マイクロサービスアーキテクチャを採用している。
＊マイクロサービスを前提とした内容になります。
Slide 6
Slide 6 text
DMMプラットフォームのエンジニアリング組織
DMMプラットフォームのエンジニアリング組織は大きく2つに分類することがで
きる。
● SREチーム
DMMプラットフォームの共通インフラを構築・運用するチーム。
● 開発チーム
共通インフラを利用するチーム。
チーム数としては16チーム存在する。
SREチーム以外のチームは開発チームとみなしていい。
Slide 7
Slide 7 text
DMMプラットフォームの共通インフラについて
DMMプラットフォームには120名のエンジニアが利用する共通インフラが存在
する。
● アプリケーション実行環境（GKE/EKS）
● CD Pipeline（ArgoCD）
● Container Registry（GCP Artifact Registry）
● Log/Metrics（Datadog）
Slide 8
Slide 8 text
SREチームのAWSアカウント
Amazon Elastic Kubernetes
Service (EKS)
共通インフラのシステムアーキテクチャ図
Datadog
マイクロサービス
SREチームのGCPプロジェクト
GKE
マイクロサービス
ArgoCD
GAR
DMMプラットフォームは
諸事情によりマルチクラウド環境になっています。
理由は時間の都合上割愛します。
Slide 9
Slide 9 text
マルチテナント型のk8sについて
k8sはマルチテナントになっており、1アプリケーション1namespaceで論理的な
リソース境界を定義している。
GKE/EKS
namespace=x
x-service
namespace=y
y-service
Slide 10
Slide 10 text
DMMプラットフォームは
k8s(GKE & EKS）を利用している
Slide 11
Slide 11 text
再掲：DMMプラットフォームのエンジニアリング組織
DMMプラットフォームのエンジニアリング組織は大きく2つに分類することがで
きる。
● SREチーム
DMMプラットフォームの共通インフラを構築・運用するチーム。
● 開発チーム
共通インフラを利用するチーム。
SREチーム以外のチームは開発チームとみなしていい。
Slide 12
Slide 12 text
共通インフラにおける
責任境界とリソース管理はどうするのか?
Slide 13
Slide 13 text
責任境界とは?
SREチームと開発チームはk8sの利用において、どちらがどの程度責任を負う
のか? という境界のことを指している。
例：k8sのマニフェストファイルは誰が書くのか?
Slide 14
Slide 14 text
リソース管理とは?
共通インフラを構成するリソースの管理方法のことである。
例：
k8sのマニフェストファイルはどこに保存するのか?
k8sのマニフェストファイルをどうやって編集し、反映させるのか?
Slide 15
Slide 15 text
共通インフラならではの課題
エンジニア120人の組織で共通インフラを利用する場合、何でもできる管理者
権限を全員に付与するわけにもいかない。
操作ミスによる意図しない障害が発生する可能性がある。
（k8sに限らず）責任境界とリソース管理を設計する必要がある。
Slide 16
Slide 16 text
まずは責任境界について
Slide 17
Slide 17 text
結論：責任境界の方針
SREチームは開発チームが共通利用するツールや仕組みを構築・運用すること
に責任を持つ。
開発チームはそれらのツールや仕組みをアプリケーションに合わせて適切に利
用する責任を持つ。
Slide 18
Slide 18 text
責任境界のイメージ
例 責任を持つのは?
k8sのノードのスケールやキャパシティプランニング SREチームが責任を持つ。
k8sのポッドのスケールやキャパシティプランニング 開発チームが責任を持つ。
Slide 19
Slide 19 text
責任境界のイメージ
例 責任を持つのは?
CDツールの構築と運用 SREチームが責任を持つ。
CDツールを利用したアプリ
ケーションのデプロイ設定
開発チームが責任を持つ。
CDツールの仕様を理解し、必要な設定を指定する必要があ
る。
Slide 20
Slide 20 text
開発チームが担当する業務
アプリケーション依存のあれこれは開発チームに責任を持ってもらっている。
● マニフェストファイルの設定
● アプリケーションのデプロイ設定
● Datadogを利用したモニター設定、ダッシュボード作成
● 各種ツールのトラブルシューティング
ポッドが立ち上がらないとか
Slide 21
Slide 21 text
再掲：マルチテナント型のk8sについて
k8sはマルチテナントになっており、1アプリケーション1namespaceで論理的な
リソース境界を定義している。
GKE/EKS
namespace=x
x-service
namespace=y
y-service
Slide 22
Slide 22 text
k8sのnamespaceについて
開発チームにアプリケーション依存のあれこれに対して責任をもってもらうた
め、開発チームはnamespaceに対する全権限（全責任）を持つ。
namespaceにどのようなリソースを配置するか、どのように運用するかは開発
チームに委ねられている。
＊ただ、勝手にIngressとか作られると困るので最低限のルールはある。
Slide 23
Slide 23 text
開発チームの学習コストが問題になる
開発チームはアプリケーションに依存するあれこれを自分たちで対応する必要
があるので、共通インフラで採用されている技術に対する学習コストがかかって
しまう。
Slide 24
Slide 24 text
k8sに詳しいSREチームが
責任を持った方がいいのでは?
Slide 25
Slide 25 text
責任境界とコミュニケーションコストについて
仮にSREチームがアプリケーション依存のあれこれにも責任を持ってしまうと、
開発チームとSREチームのコミュニケーションが発生してしまう。
例：
開発チームがマイクロサービスのポッド数を増やすためにSREチームに申請を
出す必要がある。
Slide 26
Slide 26 text
学習コストとコミュニケーションコストのトレードオフ
開発チームの学習コスト
高い 低い
SREチームとのコミュニケーションコスト
低い 高い
Slide 27
Slide 27 text
コミュニケーションコストは予想以上に高くなる
SREチームはアプリケーションに依存する要件を把握する必要があるので、開
発チームとのコミュニケーションコストは想像以上に高くなる可能性が高い。
Slide 28
Slide 28 text
pospomeが目指す本来あるべき姿
自分たちが使う技術は自分たちでちゃんと理解し、開発チーム自身がアプリ
ケーションの開発・運用をワンチームで完結させることを目指している。
＊SREチームにヘルプを依頼できる相談用窓口を用意しているので、困ったら
相談することができるようになっている。
Slide 29
Slide 29 text
開発チームとSREチームのコミュニケーションをなくすことはできない
SREチームが管理している共通インフラ自体に開発チームから変更依頼が来る
ことは当然あるので、開発チームとSREチームのコミュニケーションをなくすこと
はできない。
例：
Datadog AgentでXXXの機能を有効にして欲しい。
Slide 30
Slide 30 text
SREチームが責任を持った方がいいケース
限定的だが、SREチームが責任を持った方がいいケースもある。
● 開発チームにとって理解が難しいインフラを持っている場合
● 何かしらのルールによってSREチームが責任を持たざるを得ない場合
● などなど
Slide 31
Slide 31 text
リソース管理について
Slide 32
Slide 32 text
再掲：リソース管理とは?
共通インフラを構成するリソースの管理方法のことである。
例：
k8sのマニフェストファイルはどこに保存するのか?
k8sのマニフェストファイルをどうやって編集し、反映させるのか?
Slide 33
Slide 33 text
リソース管理のパターン
主に以下のパターンがある。
1. 単一チームによる一元管理
2. 各チームによる個別管理
＊パターンとしては ”単一チームによる個別管理” , “各チームにより一元管理”
もあるが時間の都合上割愛。
Slide 34
Slide 34 text
1.単一チームによる一元管理
e.g. k8sのマニフェストファイルを管理する
会員チームの
マニフェストファイル
決済チームの
マニフェストファイル SREチーム
決済チーム
会員チーム 構築・運用する
編集する
編集する
Slide 35
Slide 35 text
2.各チームによる個別管理
e.g. k8sのマニフェストファイルを管理する
会員チームの
マニフェスト
ファイル
会員チーム
決済チームの
マニフェスト
ファイル
決済チーム
構築・運用・編集する 構築・運用・編集する
Slide 36
Slide 36 text
リソース管理パターンのメリデメ
パターン 組織全体の作業効
率
エコシステム導入 リソース単位の
権限管理
個別要件の対応
一元管理 高い 簡単 難しい 難しい
個別管理 低い 難しい 簡単 簡単
Slide 37
Slide 37 text
リソース管理パターンのメリデメ
パターン 組織全体の作業効
率
エコシステム導入 リソース単位の
権限管理
個別要件の対応
一元管理 高い 簡単 難しい 難しい
個別管理 低い 難しい 簡単 簡単
リソースの所有者によって要件が大きく異なるものは個別管理が向いている。
一元管理で権限や個別要件に対応するには
それなりのエンジニアリソースと作り込みが必要になる可能性が高い。
Slide 38
Slide 38 text
DMMプラットフォームにおいて
共通インフラのリソースはどうなっている?
Slide 39
Slide 39 text
共通インフラ関連のリソースは一元管理する方針
SREチームが管理する共通インフラに関連するリソースは比較的一元管理して
も問題なさそうなものが多いので、一元管理を採用する方針に倒した。
Slide 40
Slide 40 text
共通インフラ関連のリソースは?
● GCPプロジェクトのアカウント
● AWSアカウントのIAM User
● k8sマニフェストファイル
● k8s RBAC
● GitHub アカウント
● GitHub Teams
● Slackアカウント
● Slack User Group
● GCPプロジェクトのIaC
● AWSアカウントのIaC
● Datadog アカウント
● Pager Dutyアカウント
● GAR
● ArgoCDのアカウント
などなど・・・
Slide 41
Slide 41 text
Slack User Group は共通インフラのリソースなのか?
DMMプラットフォームは120人以上のエンジニアが所属する組織であり、マイ
クロサービスを採用しているので、誰がどのマイクロサービスを担当しているの
かを把握するのが難しい。
担当者に連絡できるようにマイクロサービスごとにSlack User Groupを管理して
いる。
Slide 42
Slide 42 text
リソース管理は責任境界を考慮する必要がある
リソースに対して責任を持つ人やチームが自身でそのリソースを安全に操作で
きるようにするのが理想である。
これによってコミュニケーションコストが低くなる。
例：
開発チームが責任を持つk8sマニフェストファイルは開発チーム自身が変更で
きるように管理する。
Slide 43
Slide 43 text
SREチームが構築するリソース管理の仕組みの要件
開発チームが責任を持つリソースは開発チームが自由に操作できるようにする
必要がある。
SREチームが構築・運用する仕組みはこれを満たす形でなければいけない。
Slide 44
Slide 44 text
具体的なリソース管理の仕組みについて
Slide 45
Slide 45 text
リソース管理の仕組み
DMMプラットフォームでは以下の2つの仕組みで共通インフラの各種リソース
を管理している。
1. Super Terraform
2. Osiris
Slide 46
Slide 46 text
Super Terraform
Slide 47
Slide 47 text
Super Terraformとは?
DMMプラットフォームの共通インフラにおけるk8sマニフェストファイル以外を
管理する仕組みである。
実体として単一のGitHubリポジトリにホスティングしているTerraform定義であ
る。
Slide 48
Slide 48 text
Super Terraformとは?
Super Terraformは主に以下を管理する。
● 開発者の各種アカウント
● マイクロサービスの設定
● 共通インフラのIaC
Slide 49
Slide 49 text
開発者の各種アカウント
Terraformのmap型変数に
開発者の情報を指定すると、
自動的に各種アカウントと権限が
設定される。
開発者は変数を追加/編集していくだけ。
Slide 50
Slide 50 text
マイクロサービスの設定
Terraformのmap型変数に
マイクロサービスの情報を指定すると、
自動的に必要なリソースや設定が
実施される。
Slide 51
Slide 51 text
共通インフラのIaC
共通インフラのIaCもホスティングしている。
基本的にSREチームしか触らない。
普通のTerraform定義なので説明することはない。
Slide 52
Slide 52 text
Super Terraformのユースケース
Super Terraformのユースケースを紹介する。
1. 開発者が共通インフラの利用を申請する。
2. 開発者がマイクロサービスを新規作成する。
3. SREが共通インフラのリソースを操作する。
普通にTerraformの定義を修正するだけなので割愛。
Slide 53
Slide 53 text
1. 開発者が共通インフラの利用を申請する
申請者自身が利用申請のPull Requestを出せるようにしている。
申請者はSuper Terraformに対するWrite権限がないので、Slackのスラッシュ
コマンドで自動的にPRを作成できるようになっている。
Slide 54
Slide 54 text
1. 開発者が共通インフラの利用を申請する
Slackコマンドによって
作成された利用申請のPull Requestは、
最低限の閲覧権限のみ付与されたものに
なっている。
Slide 55
Slide 55 text
1. 開発者が共通インフラの利用を申請する
利用申請のPull Requestは
チーム内の承認権限を持っている人に
承認&マージしてもらう。
承認権限は開発者定義の
“github_approver = true” の人が持っている。
Slide 56
Slide 56 text
1. 開発者が共通インフラの利用を申請する
利用申請のPull Requestを
マージするとSuper Terraformへの
Write権限が付与される。
今後は利用者自身が必要に応じて
Pull Requestを作成できる。
Slide 57
Slide 57 text
1. 開発者が共通インフラの利用を申請する
共通インフラは必要となるツールや権限が多いので、
Super Terraformを利用することで必要なアカウントや権限を一括で付与できる
ようにしている。
異動や退職によってエンジニアが離れる場合も定義を削除すればいいだけで
ある。
Slide 58
Slide 58 text
Super Terraformのユースケース
Super Terraformのユースケースを紹介する。
1. 開発者が共通インフラの利用を申請する。
2. 開発者がマイクロサービスを新規作成する。
3. SREが共通インフラのリソースを操作する。
普通にTerraformの定義を修正するだけなので割愛。
Slide 59
Slide 59 text
2. 開発者がマイクロサービスを新規作成する
GitHub ActionsのWorkFlowで
マイクロサービスの新規作成に
必要なリソースや設定を定義した
Pull Requestを作成できる。
Slide 60
Slide 60 text
2. 開発者がマイクロサービスを新規作成する
Pull Requestがマージされると、
以下のリソースが作成される。
● GARリポジトリ作成 & 権限付与
● Transit Gatewayとの接続
● Slack User Group
● などなど・・・
＊今まではSREチームに依頼が必要だった。
Slide 61
Slide 61 text
2. 開発者がマイクロサービスを新規作成する
マイクロサービスの設定はCODE OWNERによって権限設定されているので、
他チームのマイクロサービスの設定を変更することはできない。
Slide 62
Slide 62 text
2. 開発者がマイクロサービスを新規作成する
マイクロサービスの新規作成は誰でもできるようになっている。
DMMプラットフォームではマイクロサービスを新規作成する際にDesign Docの
レビューがあるので、おかしなマイクロサービスが新規作成される可能性は低
い。
Slide 63
Slide 63 text
Super Terraformのあれこれ
Slide 64
Slide 64 text
Super Terraformにおける役割分担
チーム 責任
SREチーム TerraformをホスティングするGitHubリポジトリの構築・運用や
Terraform自体の設計を担当する。
開発チーム 自分たちが管理する Terraform定義のmap型変数の値が妥当であ
ることに責任を持つ。
Slide 65
Slide 65 text
SREチームとのやりとりを極力なくす
Super Terraformは開発チーム自身が自分たちでアカウント作成や権限設定
ができるようになっている。
以前はSREチームの作業待ちが発生していたが、大分削減できるようになっ
た。
Slide 66
Slide 66 text
SREチームが許可した権限のみを提供できる
開発チームはTerraformのmap型変数を
編集するだけなので、
Super Terraformで設定できる権限は
SREがあらかじめ許可したものに
限定することができる。
Slide 67
Slide 67 text
組織構造を取り入れない
Super Terraformは開発者、マイクロサービスという粒度でリソースを管理して
おり、チームや部署といった組織構造を取り入れることはしていない。
組織構造は定期的に変わってしまうので、Super Terraform上でのマイグレー
ション作業が発生するのを避けたかった。
現在のSREチームではそこをメンテする工数が割けないので、
初期要件から落とした。
Slide 68
Slide 68 text
アカウント情報以外のIaCは管理していない
Datadog, Pager Dutyに限ってはアカウント情報のみIaCで管理しており、それ
以外のリソースはUI上でポチポチ操作してもらっている。
既存のリソースをIaC化するのが大変だった & 今まで通りUIから操作してもら
えればいいという判断で初期要件から落としている。
Slide 69
Slide 69 text
実はリソースカタログが欲しかった
今後の共通インフラは少し手の込んだ自動化を進める段階に入っていくので、
このタイミングでDMMプラットフォーム内のリソースを管理するリソースカタログ
が必要だった。
Super Terraformは元々リソースカタログが欲しくて作り始めた仕組みだったり
する。
Slide 70
Slide 70 text
Osiris
Slide 71
Slide 71 text
Osirisとは?
DMMプラットフォームの共通インフラにおけるk8sマニフェストファイルを管理す
る仕組みである。
Slide 72
Slide 72 text
Osirisとは?
● 実体としては単一のGitHubリポジトリである。
● マニフェストファイルはkustomizeにより抽象化できるようになっている。
● Super Terraformで開発者登録するとOsirisへのWrite権限が付与され
る。
Slide 73
Slide 73 text
Osirisとは?
Osirisは主に以下を管理する。
● 開発チームが管理するマニフェストファイル
主にWebアプリケーションのマニフェストファイルである。
● SREチームが管理するマニフェストファイル
ArgoCD, Datadog Agent など共通インフラを構成するツールのマニフェス
トファイルである。
Slide 74
Slide 74 text
Osirisのユースケース
Osirisのユースケースを紹介する。
1. 開発者がマイクロサービスを新規作成する。
2. 開発者がマニフェストファイルを変更する。
3. SREが共通インフラのマニフェストファイルを変更する。
2番とほぼ同じなので割愛する。
Slide 75
Slide 75 text
1. 開発者がマイクロサービスを新規作成する
Super Terraformと同様に
GitHub ActionsのWorkflowによって
Pull Requestを作成する。
Slide 76
Slide 76 text
1. 開発者がマイクロサービスを新規作成する
Pull RequestにはGitHub Actionsの
Workflowによって入力された値を
反映したマニフェストファイルが
自動的に作成される。
Slide 77
Slide 77 text
1. 開発者がマイクロサービスを新規作成する
開発者はPull Requestで自動生成されたマニフェストファイルをアプリケーショ
ンに合わせて修正する必要がある。
● ArgoCDのデプロイ設定
● Deploymentの環境変数定義
● HPAのスケール設定
● などなど
Slide 78
Slide 78 text
1. 開発者がマイクロサービスを新規作成する
作成されたPull Requestは開発チーム自身でレビューし、問題なければそのま
まマージしてもらう。
任意でSREチームにレビューを依頼することもできる。
Slide 79
Slide 79 text
Osirisのユースケース
Osirisのユースケースを紹介する。
1. 開発者がマイクロサービスを新規作成する。
2. 開発者がマニフェストファイルを変更する。
3. SREが共通インフラのマニフェストファイルを変更する。
2番とほぼ同じなので割愛する。
Slide 80
Slide 80 text
2. 開発者がマニフェストファイルを変更する
マニフェストファイルの変更も
開発チームがPull Requestを作成し、
チーム内でレビュー&マージする。
マニフェストファイルは
kustomizeで抽象化されており、
全環境共通の設定と環境差分を
それぞれ管理できるようになっている。
Slide 81
Slide 81 text
2. 開発者がマニフェストファイルを変更する
Pull Requestをmainブランチにマージしても
マニフェストファイルがk8sに
反映されることはない。
マニフェストファイルの反映は
GitHub Actions の Workflowにて実行する。
Slide 82
Slide 82 text
2. 開発者がマニフェストファイルを変更する
Workflowを実行すると、
自動的にPull Requestが作成される。
これをマージすると反映される。
Pull Requestでは
既存のマニフェストファイルとの
差分をk8sのプレーンなyamlで
確認することができる。
Slide 83
Slide 83 text
補足：アプリケーションのデプロイについて
アプリケーションのデプロイはGARを利用したImageOpsになっているので、ア
プリケーションのデプロイでOsirisが利用されることはない。
Slide 84
Slide 84 text
Osirisのあれこれ
Slide 85
Slide 85 text
Osirisにおける役割分担
チーム 責任
SREチーム マニフェストファイルをホスティングする GitHubリポジトリの構築・運
用を担当する。
マニフェストファイルのディレクトリ構成設計、 CI実装、抽象化ツール
の選定を担当する。
開発チーム 自分たちが管理するマニフェストファイルの各種設定が妥当である
ことに責任を持つ。
e.g. ポット数、スケール設定
Slide 86
Slide 86 text
SREチームとのやりとりを極力なくす
Super Terraformと同様に開発チーム自身が自分たちでマニフェストファイルを
変更することができる。
マニフェストファイルはCODE OWNERによって権限管理されている。
Slide 87
Slide 87 text
CI周りの不足
● マニフェストファイル上のAPI Versionの更新案内
● マニフェストファイルの修正依頼
CPU, Memoryのrequestが大きすぎるなど。
まだまだ作り込みが甘いと思っている。
Slide 88
Slide 88 text
まとめ
Slide 89
Slide 89 text
DMMプラットフォームの責任境界
チーム名 責任
SREチーム アプリケーションに依存しないチーム横断で必要となる領域に責任を持つ
開発チーム 自分たちが管理するアプリケーションに依存する領域に責任を持つ
Slide 90
Slide 90 text
DMMプラットフォームのリソース管理
リソースはSREチームによって一元管理されるが、責任境界に沿った形で各種
ユースケースを実現できるようにする。
Slide 91
Slide 91 text
適切な責任境界とリソース管理
適切な責任境界とリソース管理は組織によって異なるので、自分たちに合った
方針を考える必要がある。
DMMプラットフォームの事例が良くも悪くも役に立てばいいなと思っています。
Slide 92
Slide 92 text
おわり