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

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

Transcript

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