マイクロサービス環境におけるToilを削減するTerraformの活用 in DMMプラットフォーム

Cloud Operator Days Tokyo 2023 の登壇資料です。
https://cloudopsdays.com/

Transcript

1. マイクロサービス環境におけるToilを 削減するTerraformの活用 in DMMプラットフォーム @pospome
2. 登壇者 名前：pospome（ぽすぽめ） 所属：DMM.com Twitter:@pospome
3. 内容について マイクロサービス環境におけるTerraformの活用についてToil削減という観点で 話します。
4. DMMプラットフォーム 扱う領域：DMM会員、決済、DMMポイント、不正対策など エンジニア数：120名以上 開発チーム数：16チーム マイクロサービス数：約40サービス ピーク時のリクエスト：19,000RPS ＊2016年くらいからマイクロサービスに取り組んでいる。
5. プラットフォームエンジニアリングへの取り組み DMMプラットフォームはプラットフォームエンジニアリングに取り組むことで開 発効率を向上させている。 開発 チーム プラットフォーム チーム 共通利用するインフラ環境や ツールを提供している
6. プラットフォームエンジニアリングへの取り組み 提供するツールの例 • EKS/GKE • ArgoCD • Container Registry • Datadog • Pager Duty
7. コミュニケーションコストを低くする必要がある 開発チームからプラットフォームチームに申請や作業依頼をする形にすると、 待ちが発生してしまう。 開発 チーム プラットフォーム チーム 共通利用するインフラ環境や ツールを提供している 申請 or 作業依頼
8. 開発チームに独立性を持たせる 開発チームが自身で責任を持ってツールを利用することで、 プラットフォームとコミュニケーションせずに開発を進めることができる。 対象 プラットフォームチーム 開発チーム k8s(GKE & EKS) クラスターの構築・運用 k8sマニフェストの管理 CDパイプライン ArgoCDの構築・運用 ArgoCDを利用したデプロイの実行
9. 開発チームに独立性を持たせる 提供するツールを開発チーム自身で適切に利用できる世界を目指す。 • EKS/GKE • ArgoCD • Container Registry • Datadog • Pager Duty
10. トイルが発生してしまう 開発チームに独立性を持たせても、プラットフォームチームへの作業依頼をゼ ロにすることはできない。 • k8sへのアクセス権限の付与 • Datadogへのログインアカウント発行 • Container Registryのリポジトリ作成
11. トイルが発生してしまう 開発チームを待たせないためにも即時対応しなければいけないものが多い。 作業自体は数分で終わるものでも単純な作業工数で計れない悪影響がある。 • コンテキストスイッチの切り替えによる作業効率の低下 • 作業者のモチベーション低下
12. どうやって解決しているのか?
13. Terraformを利用することでトイルを削減している “Super Terraform”という リソース管理の仕組みで トイルを削減している。 実体としてはTerraformである。
14. Super Terraformのコンセプト
15. Super Terraformはリソース管理の仕組み Super Terraformはプラットフォームチームが提供するツール群に関連するリ ソースを管理するための仕組みである。 単なるクラウドインフラのIaCではなく、“トイルを削減する” という思想をベース に設計されている。
16. Super Terraformはリソース管理の仕組み 開発者が自身でSuper Terraform上のTerraform定義を編集することで以下の 作業を完了することができる。 • k8sへのアクセス権限の付与 • Datadogへのログインアカウント発行 • Container Registryのリポジトリ作成
17. Terraformの変数の値を編集するだけ 開発者フレンドリーな形で 抽象化されており、 開発者はTerraformのプロバイダーを 直接扱う必要はない。 開発チームはTerraformの変数を 編集するだけで任意の設定が できるようになっている。
18. 最低限のガードレールは用意している Super Terraform内のディレクトリとファイルは CODEOWNERによって権限設定がされている。
19. 最低限のガードレールは用意している Terraformの変数に指定する値も バリデーションしていたり、 特定の値しか指定できないようにしている。
20. あくまでも最低限のガードレール ガードレールを厳しくすると申請の承認などが発生してしまい、本末転倒なので ガードレールとはいえ最低限のものである。 誤操作や本当にヤバい設定を防ぐことを目的にしている。
21. 各種トイルの解消例
22. トイルの種類 トイルには大きく分けて2つの種類がある。 1. 開発者管理 2. アプリケーション管理
23. トイルの種類 トイルには大きく分けて2つの種類がある。 1. 開発者管理 2. アプリケーション管理
24. 開発者管理 Super Terraformで扱う開発者管理のユースケースは以下である。 1. 各種ツールの利用申請 2. 各種ツールの権限設定 3. 各種ツールの権限削除
25. 開発者管理 Super Terraformで扱う開発者管理のユースケースは以下である。 1. 各種ツールの利用申請 2. 各種ツールの権限設定 3. 各種ツールの権限削除
26. 各種ツールの利用申請 DMMプラットフォームで 開発をするエンジニアは 最初に各種ツールの利用申請を することになる。 申請者自身がSlack Workflowで 必要情報を入力することで申請できる。
27. なぜSlackなのか? DMMは入社時に Slackアカウントが付与されているので、 誰でもWorkflowを実行できる。 誰かが代わりに申請する手間が省ける。
28. 各種ツールの利用申請 Slack Workflowの実行によって、 Super Terraform上にPRが作られる。 このPRをmergeすると、 指定した権限で 各種ツールが利用できる状態になる。
29. 各種ツールの利用申請 PRをmergeできる権限を持つのは、 各チームの限られた人のみである。 具体的には github_approver という 属性がtrueになっている人であれば、 merge できるようになっている。
30. 各種ツールの利用申請 申請者は自チームのエンジニアに PRのmergeを依頼することになる。 利用申請が各チームで完結する。
31. 各種ツールの利用申請 誰を github_approver=true にするかは、 各チームに任せている。 各チームに責任を持って管理してもらう 方針に倒している。
32. Super Terraformでも開発チームに独立性を持たせる Super Terraformでも開発チームに独立性を持たせることで、 プラットフォームチームとのコミュニケーションをなくす。 • Slack Workflowで申請者自身が利用申請できるようにする。 • 各チームに承認者を配置する。
33. 開発者管理 Super Terraformで扱う開発者管理のユースケースは以下である。 1. 各種ツールの利用申請 2. 各種ツールの権限設定 3. 各種ツールの権限削除
34. 各種ツールの権限設定 Slack Workflowによる利用申請が完了すると、申請者自身がSuper TerraformにPRを作成することができるようになる。 申請後は任意のタイミングで任意の権限設定が可能になる。
35. 開発者管理 Super Terraformで扱う開発者管理のユースケースは以下である。 1. 各種ツールの利用申請 2. 各種ツールの権限設定 3. 各種ツールの権限削除
36. 各種ツールの権限削除 Super Terraformから定義を削除すれば各種ツールの利用も停止することがで きる。
37. Super Terraformの退職者検知機能について 退職者が出た場合、Super Terraformが自動的に定義を削除してくれる。削除 した場合、退職者の所属チームにSlackで連絡がいく。
38. Super Terraformの退職者検知機能について 各チームで適切に退職者対応をしない可能性があるので、 ガードレールとして用意している機能である。
39. トイルの種類 トイルには大きく分けて2つの種類がある。 1. 開発者管理 2. アプリケーション管理
40. アプリケーション管理のユースケースについて 開発者管理のユースケースは以下である。 1. 新規アプリケーションの開発に必要なリソースを作成する 2. 各種設定変更
41. アプリケーション管理のユースケースについて 開発者管理のユースケースは以下である。 1. 新規アプリケーションの開発に必要なリソースを作成する 2. 各種設定変更
42. 新規アプリケーションに必要なリソースを作成する DMMプラットフォームでは各種ツールを利用してアプリケーションを開発するた めに以下のリソースが必要になる。 1. k8s上で動かすアプリケーションのマニフェストファイル 2. ArgoCDのデプロイ設定ファイル（k8sのCRD定義） 3. コンテナイメージを保存するContainer Registry 4. AWS Transit Gatewayの接続設定（EKSを利用する場合のみ）
43. 新規アプリケーションに必要なリソースを作成する アプリケーションを開発するためのリソースは Super TerraformのGitHubリポジトリの GitHub ActionsのWorkflowで 作成することができる。
44. 作成されるPR Workflowを実行すると、PRが作成される。 PRを適切に編集して、 mergeすると各種リソースが作られる。
45. 新規アプリケーションに必要なリソースを作成する Super Terraformで各種ツールの利用申請をした人であれば、 誰でもWorkflowを実行することができる。 PRのmergeも各チームで実行可能になっている。 ツールの利用申請と同様に開発チームで作業が完結する方針で設計してい る。
46. アプリケーションと開発者の紐づけ developersというフィールドで、 アプリケーションと開発者を 紐付けることができる。 この設定は以下に利用される。 • アプリケーションごとのリソース権限管理 • 連絡用のSlack User Groupの作成
47. Slack User Groupの作成
48. k8sマニフェストの生成とGitHubリポジトリ間の連携について k8sマニフェストは他のリポジトリで管理されているので、そのリポジトリに対し てPRを作成する形になっている。 Super Terraform k8sマニフェスト GitHubリポジトリ PRをmerge PRを作成
49. k8sマニフェストの生成とGitHubリポジトリ間の連携について k8sマニフェストを管理するGitHubリポジトリに k8sマニフェストのPRが作成される。 開発チームはPRを適切に編集し、 mergeするだけでいい。
50. アプリケーション管理のユースケースについて 開発者管理のユースケースは以下である。 1. 新規アプリケーションの開発に必要なリソースを作成する 2. 各種設定変更
51. 各種設定を変更する アプリケーションの各種設定を変更する場合はTerraformの定義を編集するだ けでいい。
52. おまけ：アプリケーションの削除 Super Terraformではアプリケーションの削除をサポートしていない。 アプリケーションを削除する機会が少ないからである。 削除する場合はプラットフォームチームが手動で削除する。 削減効果の高いToilのみ対応する方針になっている。
53. Super Terraformの課題
54. マイクロサービスと開発者の管理が甘い 最終的にサービスカタログとして機能させる予定なので、 Backstage, Datadog Service Catalog とのインテグレーションを進める予定だっ た。 しかし、現状のSuper Terraformはリソース設計が甘く、改修を入れる必要があ る。
55. 複雑な処理になると辛い Super TerraformはTerraformとGitHub Actions（シェル）で開発しているが、複 雑な自動化になると、これらで完結させることが難しい。 何かしらのプログラミング言語と組み合わせてプログラマブルに処理できるよう にする必要がある。 現時点では Dagger の採用を検討している。
56. まとめ
57. まとめ Super Terraformによってプラットフォームチームが抱えていた各種トイルを削 減することができた。 しかし、今後作り込もうとすると、辛くなりそうな雰囲気を感じている。