Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
マイクロサービス環境におけるToilを削減するTerraformの活用 in DMMプラットフォーム
Search
pospome
September 21, 2023
Programming
3
1.3k
マイクロサービス環境におけるToilを削減するTerraformの活用 in DMMプラットフォーム
Cloud Operator Days Tokyo 2023 の登壇資料です。
https://cloudopsdays.com/
pospome
September 21, 2023
Tweet
Share
More Decks by pospome
See All by pospome
DMMプラットフォームがTiDB Cloudを採用した背景
pospome
9
4.5k
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
pospome
29
11k
マイクロサービス環境におけるDB戦略 in DMMプラットフォーム
pospome
12
3.5k
組織全体で開発生産性に取り組むために 専門チームを作った話
pospome
2
1.5k
DMMプラットフォームにおける GKE を利用した プラットフォームエンジニアリングへの 取り組み
pospome
1
460
DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実
pospome
3
2.3k
(再アップロード)Microservices & APIs
pospome
0
78
(再アップロード)Datastore/Go のデータ設計と struct の振る舞いについて
pospome
0
76
組織のコード品質を向上させる “レビューシステム”の取り組み
pospome
14
7.7k
Other Decks in Programming
See All in Programming
戦略的DDDは重いのか? / Is strategic DDD heavy?
pictiny
3
2.2k
GitLab CI/CD で C#/WPFアプリケーションのテストとインストーラーのビルド・デプロイを自動化する
hacarus
0
620
Amazon Aurora Serverless v2が意外と高かった話と、AWS Database Migration Serviceの話
satoshi256kbyte
1
110
TypeScriptの型とパフォーマンス (TSKaigi 2024)
ypresto
14
5.2k
Prepare for Jakarta EE 11 - Performance and Developer Productivity
ivargrimstad
0
360
TypeScript Custom GitHub Action Development Tips
peaceiris
5
850
TypeScriptとGraphQLで実現する 型安全なAPI実装 / TSKaigi 2024
hokaccha
5
2.9k
Using "modern" Ruby to build a better, faster Homebrew
mikemcquaid
2
300
FoodGram
iseruuuuu
0
230
Productivity is Messing Around and Having Fun
hollycummins
1
190
Effectで作る堅牢でスケーラブルなAPIゲートウェイ / Robust and Scalable API Gateway Built on Effect
yasaichi
7
1.2k
The World is a Network (and We Are Just Nodes)
whatyouhide
0
100
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
504
110k
Practical Orchestrator
shlominoach
183
9.8k
Designing Experiences People Love
moore
136
23k
For a Future-Friendly Web
brad_frost
172
9k
Reflections from 52 weeks, 52 projects
jeffersonlam
345
19k
StorybookのUI Testing Handbookを読んだ
zakiyama
13
4.7k
A designer walks into a library…
pauljervisheath
201
23k
What’s in a name? Adding method to the madness
productmarketing
PRO
17
2.7k
Statistics for Hackers
jakevdp
790
220k
A Philosophy of Restraint
colly
197
16k
How to train your dragon (web standard)
notwaldorf
75
5.2k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
22
1.6k
Transcript
マイクロサービス環境におけるToilを 削減するTerraformの活用 in DMMプラットフォーム @pospome
登壇者 名前:pospome(ぽすぽめ) 所属:DMM.com Twitter:@pospome
内容について マイクロサービス環境におけるTerraformの活用についてToil削減という観点で 話します。
DMMプラットフォーム 扱う領域:DMM会員、決済、DMMポイント、不正対策など エンジニア数:120名以上 開発チーム数:16チーム マイクロサービス数:約40サービス ピーク時のリクエスト:19,000RPS *2016年くらいからマイクロサービスに取り組んでいる。
プラットフォームエンジニアリングへの取り組み DMMプラットフォームはプラットフォームエンジニアリングに取り組むことで開 発効率を向上させている。 開発 チーム プラットフォーム チーム 共通利用するインフラ環境や ツールを提供している
プラットフォームエンジニアリングへの取り組み 提供するツールの例 • EKS/GKE • ArgoCD • Container Registry •
Datadog • Pager Duty
コミュニケーションコストを低くする必要がある 開発チームからプラットフォームチームに申請や作業依頼をする形にすると、 待ちが発生してしまう。 開発 チーム プラットフォーム チーム 共通利用するインフラ環境や ツールを提供している 申請
or 作業依頼
開発チームに独立性を持たせる 開発チームが自身で責任を持ってツールを利用することで、 プラットフォームとコミュニケーションせずに開発を進めることができる。 対象 プラットフォームチーム 開発チーム k8s(GKE & EKS) クラスターの構築・運用
k8sマニフェストの管理 CDパイプライン ArgoCDの構築・運用 ArgoCDを利用したデプロイの実行
開発チームに独立性を持たせる 提供するツールを開発チーム自身で適切に利用できる世界を目指す。 • EKS/GKE • ArgoCD • Container Registry •
Datadog • Pager Duty
トイルが発生してしまう 開発チームに独立性を持たせても、プラットフォームチームへの作業依頼をゼ ロにすることはできない。 • k8sへのアクセス権限の付与 • Datadogへのログインアカウント発行 • Container Registryのリポジトリ作成
トイルが発生してしまう 開発チームを待たせないためにも即時対応しなければいけないものが多い。 作業自体は数分で終わるものでも単純な作業工数で計れない悪影響がある。 • コンテキストスイッチの切り替えによる作業効率の低下 • 作業者のモチベーション低下
どうやって解決しているのか?
Terraformを利用することでトイルを削減している “Super Terraform”という リソース管理の仕組みで トイルを削減している。 実体としてはTerraformである。
Super Terraformのコンセプト
Super Terraformはリソース管理の仕組み Super Terraformはプラットフォームチームが提供するツール群に関連するリ ソースを管理するための仕組みである。 単なるクラウドインフラのIaCではなく、“トイルを削減する” という思想をベース に設計されている。
Super Terraformはリソース管理の仕組み 開発者が自身でSuper Terraform上のTerraform定義を編集することで以下の 作業を完了することができる。 • k8sへのアクセス権限の付与 • Datadogへのログインアカウント発行 •
Container Registryのリポジトリ作成
Terraformの変数の値を編集するだけ 開発者フレンドリーな形で 抽象化されており、 開発者はTerraformのプロバイダーを 直接扱う必要はない。 開発チームはTerraformの変数を 編集するだけで任意の設定が できるようになっている。
最低限のガードレールは用意している Super Terraform内のディレクトリとファイルは CODEOWNERによって権限設定がされている。
最低限のガードレールは用意している Terraformの変数に指定する値も バリデーションしていたり、 特定の値しか指定できないようにしている。
あくまでも最低限のガードレール ガードレールを厳しくすると申請の承認などが発生してしまい、本末転倒なので ガードレールとはいえ最低限のものである。 誤操作や本当にヤバい設定を防ぐことを目的にしている。
各種トイルの解消例
トイルの種類 トイルには大きく分けて2つの種類がある。 1. 開発者管理 2. アプリケーション管理
トイルの種類 トイルには大きく分けて2つの種類がある。 1. 開発者管理 2. アプリケーション管理
開発者管理 Super Terraformで扱う開発者管理のユースケースは以下である。 1. 各種ツールの利用申請 2. 各種ツールの権限設定 3. 各種ツールの権限削除
開発者管理 Super Terraformで扱う開発者管理のユースケースは以下である。 1. 各種ツールの利用申請 2. 各種ツールの権限設定 3. 各種ツールの権限削除
各種ツールの利用申請 DMMプラットフォームで 開発をするエンジニアは 最初に各種ツールの利用申請を することになる。 申請者自身がSlack Workflowで 必要情報を入力することで申請できる。
なぜSlackなのか? DMMは入社時に Slackアカウントが付与されているので、 誰でもWorkflowを実行できる。 誰かが代わりに申請する手間が省ける。
各種ツールの利用申請 Slack Workflowの実行によって、 Super Terraform上にPRが作られる。 このPRをmergeすると、 指定した権限で 各種ツールが利用できる状態になる。
各種ツールの利用申請 PRをmergeできる権限を持つのは、 各チームの限られた人のみである。 具体的には github_approver という 属性がtrueになっている人であれば、 merge できるようになっている。
各種ツールの利用申請 申請者は自チームのエンジニアに PRのmergeを依頼することになる。 利用申請が各チームで完結する。
各種ツールの利用申請 誰を github_approver=true にするかは、 各チームに任せている。 各チームに責任を持って管理してもらう 方針に倒している。
Super Terraformでも開発チームに独立性を持たせる Super Terraformでも開発チームに独立性を持たせることで、 プラットフォームチームとのコミュニケーションをなくす。 • Slack Workflowで申請者自身が利用申請できるようにする。 • 各チームに承認者を配置する。
開発者管理 Super Terraformで扱う開発者管理のユースケースは以下である。 1. 各種ツールの利用申請 2. 各種ツールの権限設定 3. 各種ツールの権限削除
各種ツールの権限設定 Slack Workflowによる利用申請が完了すると、申請者自身がSuper TerraformにPRを作成することができるようになる。 申請後は任意のタイミングで任意の権限設定が可能になる。
開発者管理 Super Terraformで扱う開発者管理のユースケースは以下である。 1. 各種ツールの利用申請 2. 各種ツールの権限設定 3. 各種ツールの権限削除
各種ツールの権限削除 Super Terraformから定義を削除すれば各種ツールの利用も停止することがで きる。
Super Terraformの退職者検知機能について 退職者が出た場合、Super Terraformが自動的に定義を削除してくれる。削除 した場合、退職者の所属チームにSlackで連絡がいく。
Super Terraformの退職者検知機能について 各チームで適切に退職者対応をしない可能性があるので、 ガードレールとして用意している機能である。
トイルの種類 トイルには大きく分けて2つの種類がある。 1. 開発者管理 2. アプリケーション管理
アプリケーション管理のユースケースについて 開発者管理のユースケースは以下である。 1. 新規アプリケーションの開発に必要なリソースを作成する 2. 各種設定変更
アプリケーション管理のユースケースについて 開発者管理のユースケースは以下である。 1. 新規アプリケーションの開発に必要なリソースを作成する 2. 各種設定変更
新規アプリケーションに必要なリソースを作成する DMMプラットフォームでは各種ツールを利用してアプリケーションを開発するた めに以下のリソースが必要になる。 1. k8s上で動かすアプリケーションのマニフェストファイル 2. ArgoCDのデプロイ設定ファイル(k8sのCRD定義) 3. コンテナイメージを保存するContainer Registry
4. AWS Transit Gatewayの接続設定(EKSを利用する場合のみ)
新規アプリケーションに必要なリソースを作成する アプリケーションを開発するためのリソースは Super TerraformのGitHubリポジトリの GitHub ActionsのWorkflowで 作成することができる。
作成されるPR Workflowを実行すると、PRが作成される。 PRを適切に編集して、 mergeすると各種リソースが作られる。
新規アプリケーションに必要なリソースを作成する Super Terraformで各種ツールの利用申請をした人であれば、 誰でもWorkflowを実行することができる。 PRのmergeも各チームで実行可能になっている。 ツールの利用申請と同様に開発チームで作業が完結する方針で設計してい る。
アプリケーションと開発者の紐づけ developersというフィールドで、 アプリケーションと開発者を 紐付けることができる。 この設定は以下に利用される。 • アプリケーションごとのリソース権限管理 • 連絡用のSlack User
Groupの作成
Slack User Groupの作成
k8sマニフェストの生成とGitHubリポジトリ間の連携について k8sマニフェストは他のリポジトリで管理されているので、そのリポジトリに対し てPRを作成する形になっている。 Super Terraform k8sマニフェスト GitHubリポジトリ PRをmerge PRを作成
k8sマニフェストの生成とGitHubリポジトリ間の連携について k8sマニフェストを管理するGitHubリポジトリに k8sマニフェストのPRが作成される。 開発チームはPRを適切に編集し、 mergeするだけでいい。
アプリケーション管理のユースケースについて 開発者管理のユースケースは以下である。 1. 新規アプリケーションの開発に必要なリソースを作成する 2. 各種設定変更
各種設定を変更する アプリケーションの各種設定を変更する場合はTerraformの定義を編集するだ けでいい。
おまけ:アプリケーションの削除 Super Terraformではアプリケーションの削除をサポートしていない。 アプリケーションを削除する機会が少ないからである。 削除する場合はプラットフォームチームが手動で削除する。 削減効果の高いToilのみ対応する方針になっている。
Super Terraformの課題
マイクロサービスと開発者の管理が甘い 最終的にサービスカタログとして機能させる予定なので、 Backstage, Datadog Service Catalog とのインテグレーションを進める予定だっ た。 しかし、現状のSuper Terraformはリソース設計が甘く、改修を入れる必要があ
る。
複雑な処理になると辛い Super TerraformはTerraformとGitHub Actions(シェル)で開発しているが、複 雑な自動化になると、これらで完結させることが難しい。 何かしらのプログラミング言語と組み合わせてプログラマブルに処理できるよう にする必要がある。 現時点では Dagger の採用を検討している。
まとめ
まとめ Super Terraformによってプラットフォームチームが抱えていた各種トイルを削 減することができた。 しかし、今後作り込もうとすると、辛くなりそうな雰囲気を感じている。