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
Terraformのレポジトリ、 ディレクトリ構成どうする?/Terraform repository, directory structure What should I do?
Search
Yokoyama Tatsuo
March 19, 2021
Technology
6
2.7k
Terraformのレポジトリ、 ディレクトリ構成どうする?/Terraform repository, directory structure What should I do?
PHPerKaigi2021
Yokoyama Tatsuo
March 19, 2021
Tweet
Share
More Decks by Yokoyama Tatsuo
See All by Yokoyama Tatsuo
SREとその組織類型
tatsuo48
11
2.2k
AWS Fargateでお手軽開発ブランチデプロイ/Easy development branch deployment with AWS Fargate
tatsuo48
0
80
HashiCorp Vaultを使った セキュアなDBアクセスの実現/Secure DB access with HashiCorp Vault
tatsuo48
0
1.5k
インフラエンジニアとアプリ開発
tatsuo48
0
140
Other Decks in Technology
See All in Technology
AOAI Dev Day LLMシステム開発 Tips集
hirosatogamo
16
3.9k
さらに高品質・高速化を目指すAI時代のテスト設計支援と、めざす先 / AI Test Lab vol.1
shift_evolve
0
190
サービス開発を前に進めるために 新米リードエンジニアが 取り組んだこと / Steps Taken by a Novice Lead Engineer to Advance Service Development
nologyance
0
180
開発と事業を繋ぐ!SREのオブザーバビリティ戦略 ~ Developers Summit 2024 Summer ~
leveragestech
0
650
開発生産性をむしろ向上させる セキュリティパートナーの作り方 / Dev Productivity Con 2024
flatt_security
0
400
What if...? 처음부터 다시 LLM 어플리케이션을 개발한다면
huffon
0
1.1k
たくさん本を読んだけど 1年後には綺麗サッパリ!を乗り越えて 学習の鬼になるぞ👹
yum3
0
160
DDDにおける認可の扱いとKotlinにおける実装パターン / authorization-for-ddd-and-kotlin-implement-pattern
urmot
4
390
テストケースの自動生成に生成AIの導入を試みた話と生成AIによる今後の期待
shift_evolve
0
190
Git 研修 Basic【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
330
AWS IAMのアンチパターン/AWSが考える最低権限実現へのアプローチ概略(JAWS-UG朝会#59資料改修20分版)
htan
0
330
AIエージェントを現場に導入する目線とは
masahiro_nishimi
1
1.6k
Featured
See All Featured
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
12
3.8k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
19k
Become a Pro
speakerdeck
PRO
15
4.8k
Practical Orchestrator
shlominoach
185
10k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
149
45k
Rails Girls Zürich Keynote
gr2m
93
13k
Why Our Code Smells
bkeepers
PRO
332
56k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
325
21k
Optimizing for Happiness
mojombo
373
69k
Fontdeck: Realign not Redesign
paulrobertlloyd
79
5.1k
Imperfection Machines: The Place of Print at Facebook
scottboms
262
13k
Building Better People: How to give real-time feedback that sticks.
wjessup
357
18k
Transcript
Terraformのレポジトリ、 ディレクトリ構成どうする? #PHPerKaigi 2021 Hamee 株式会社 横山 達男(@tatsuo4848)
本セッションのターゲット • PHPを利用する開発者の中でも ◦ インフラエンジニア、 SREではないがTerraformでIaCやっている!という方 ◦ インフラエンジニア、 SREとしてバリバリTerraform書いている方 ◦
Terraformファイルの構成について悩んでいる方
本セッションのターゲット 一緒に悩みましょう! • PHPを利用する開発者の中でも ◦ インフラエンジニア、 SREではないがTerraformでIaCやっている!という方 ◦ インフラエンジニア、 SREとしてバリバリTerraform書いている方
◦ Terraformファイルの構成について悩んでいる方
小田原にあるHameeから来ました!
自己紹介 twitterアカウント:@tatsuo4848 GitHubアカウント:tatsuo48 ~ これまでの経歴 ~ 拝承系SIer(インフラエンジニア、お客様サポート) ⬇ 株式会社みんなのウェディング(インフラエンジニア、SRE) ⬇
Hamee株式会社(SRE、TechLead) PHPの会社歴約1年、三度の飯よりAWSが好き
Hameeってこんな会社
Hameeってこんな会社
Hameeってこんな会社
NextEngineの機能
NextEngineのシステム構成 メイン機能 Platform API アプリ アプリ アプリ アプリ アプリ アプリ
NextEngineのシステム構成 メイン機能 Platform API アプリ アプリ アプリ アプリ アプリ アプリ
NextEngineのシステム構成 メイン機能 Platform API アプリ アプリ アプリ アプリ アプリ アプリ
NextEngineのシステム構成 メイン機能 Platform API アプリ アプリ アプリ アプリ アプリ アプリ
AWS 1アカウントで運用中
NextEngineのシステム構成 メイン機能 Platform API アプリ アプリ アプリ アプリ アプリ アプリ
AWS 1アカウントで運用中 AWS 環境ごとに分けた 複数アカウントで運用予定 (さくらインターネットから 移行中)
大量のコンポーネント 1. メイン機能のデータにアクセスするためにAPIを用意 2. アプリを管理するためにPlatformという基盤となるサービスが存在 3. アプリ自体が動作する環境も必要
Terraformの出番!
Hameeがどのように Terraformを扱ってきたか時系列で紹介
Terraform導入期 (AWSリソース単位でstate分割)
AWSリソース単位でstate分割 • 2015年頃からHameeでは利用 • AWSアカウントは1つだが、コン ポーネントごとにレポジトリを作成 • stateファイルはAWSリソース種別 (RDS,network,EC2など)で分割 •
導入対象もまだまだ少ない Git Repositry /network S3 /rds /ec2 課題 • stateファイル間の複雑な依存関係
stateファイル間の複雑な依存関係 • state間の依存関係を考慮して順番に applyする必要あり ◦ /networkで作成したセキュリ ティグループを/rdsで作成する RDSに設定 ◦ /networkで作成したセキュリ
ティグループを/ec2で作成する EC2に設定 • stateファイルという単位で見た場合、 相互参照が発生する危険も Git Repositry /network S3 /rds /ec2
まとめ • IaCによる変更操作への安心感 • インフラ新規構築を素早く実践できるアジリティの獲得 課題 • stateファイル間の複雑な依存関係 得たもの
Terraform成長期 (サービス軸でstate分割)
サービス軸でstate分割 • 相互参照が極力発生しないよう、state ファイルは以下の2軸で分割 ◦ サービスで共通利用するリソー ス ◦ サービス固有のリソース •
stateファイルの参照をシンプルに Git Repositry /network S3 /service_a(rds,ec2...) /service_b(rds,ec2...) 課題 • stateファイルの肥大化 • プロジェクト数の増加 解決した課題 • stateファイル間の複雑な依存関係
stateファイルの肥大化 • 導入期と比較して管理するリソースも 増えstateファイルが肥大化 • plan結果に目を凝らさなければ予期せ ぬ変更が加わるかもしれない恐怖 Git Repositry /network
S3 /service_a(rds,ec2...) /service_b(rds,ec2...)
Git Repositry Git Repositry プロジェクト数の増加 • AWSアカウントは1つだが、コンポー ネントごとにレポジトリを作成 • 初期は良かったがコンポーネントも順
調に増え、どのレポジトリで何を管理 しているのか?の把握が困難 • 最盛期で 53レポジトリ • レポジトリの粒度や構成も作成者によ りさまざま Git Repositry S3 /network /service_a(rds,ec2...) /service_b(rds,ec2...)
まとめ • IaCによる変更操作への安心感 • インフラ新規構築を素早く実践できるアジリティの獲得 課題 • stateファイル間の複雑な依存関係 • stateファイルの肥大化による変更操作への恐怖感
• プロジェクト数の増加による見通しの悪さ 得たもの
Terraform成長期 (CD導入)
CD導入 • atlantisを導入 • PRコメント駆動でterraform planを実施 • Terraformをチームで安全に使うための 環境を獲得 Git
Repositry /network S3 /service_a(rds,ec2...) /service_b(rds,ec2...) 課題 • Atlantisの設定作業の手間
Git Repositry Git Repositry Atlantisの設定作業の手間 • Atlantisのサーバ自体は1つだが各レ ポジトリで設定が必要 Git Repositry
S3 /network /service_a(rds,ec2...) /service_b(rds,ec2...)
まとめ • IaCによる変更操作への安心感 • インフラ新規構築を素早く実践できるアジリティの獲得 • Terraformをチームで安全に使うための環境を獲得 課題 • stateファイルの肥大化による変更操作への恐怖感
• プロジェクト数の増加による見通しの悪さ • Atlantisの設定作業を各プロジェクトごとのレポジトリで行う手間 得たもの
Terraform成長期 (レポジトリ大統一)
レポジトリ大統一 • バラバラだったレポジトリを 2つにまとめる ◦ NextEngine主要コンポーネントのレポ ジトリ ◦ アプリのレポジトリ •
各レポジトリの第一階層を AWSアカウントと定め て分割 • stateファイルの移行は骨が折れるのでそこには 触れない • stateファイルの粒度は様々な状態のまま Git Repositry /account_a/network S3 /account_a/service_a/ /account_b/service_b 解決した課題 • Atlantisの設定作業の手間 • プロジェクト数の増加による見通しの 悪さ
まとめ • IaCによる変更操作への安心感 • インフラ新規構築を素早く実践できるアジリティの獲得 • Terraformをチームで安全に使うための環境を獲得 課題 • stateファイルの肥大化による変更操作への恐怖感
• プロジェクト数の増加による見通しの悪さ • Atlantisの設定作業を各プロジェクトごとのレポジトリで行う手間 得たもの
Terraform成長期 (CI導入)
CI導入 • Lint、静的解析ツール導入 ◦ tflint ◦ checkov ◦ terraform fmt
• PRトリガーでCircleCI上で実行される • Terraformをチームで正しく使うため の環境を獲得 Git Repositry /account_a/network S3 /account_a/service_a/ /account_b/service_b
まとめ • IaCによる変更操作への安心感 • インフラ新規構築を素早く実践できるアジリティの獲得 • Terraformをチームで安全に使うための環境を獲得 • Terraformをチームで正しく使うための環境を獲得 課題
• stateファイルの肥大化による変更操作への恐怖感 得たもの
いったんまとめ
現在のTerraform Git Repositry /account_a/network S3 /account_a/service_a/ /account_b/service_b
平和が見えたが...
開発組織の変!
合併&分裂
開発組織の変! • SRE部、開発部というように別れていた組織が合併&分裂 • 開発スピード向上のために2ピザルールに則った10名程度の部署が3部署に • 更にその中でも4~5人程度のプロジェクトを作成 • プロジェクト単位で元SRE,元開発部が混ざり合い協力する形
ということで 将来こんな形になる?
将来こんな形になる? • 小さなチームでアジャイルに開発する スタイル • 1コンポーネントごとに1AWSアカウント • 各アプリケーションレポジトリにtfファイ ルを内包 •
サービス共通テンプレートをmoduleレ ポジトリに用意するがstateの分け方な どはチーム内で決定 Git Repositry /app S3 /config /terraform Git Repositry /network /rds
まとめ • IaCによる変更操作への安心感 • インフラ新規構築を素早く実践できるアジリティの獲得 • Terraformをチームで安全に使うための環境を獲得 • Terraformをチームで正しく使うための環境を獲得 課題
• stateファイルの肥大化による変更操作への恐怖感 得たもの
まとめ • IaCによる変更操作への安心感 • インフラ新規構築を素早く実践できるアジリティの獲得 • Terraformをチームで安全に使うための環境を獲得 • Terraformをチームで正しく使うための環境を獲得 課題
• CI/CDの設定がプロジェクトによってまちまちになる危険性 得たもの
まとめ • IaCによる変更操作への安心感 • インフラ新規構築を素早く実践できるアジリティの獲得 課題 • CI/CDの設定がプロジェクトによってまちまちになる危険性 ◦ サービス稼働前の最終確認事項のチェックリストを作成することでケアできないか?
得たもの
将来こんな形になる? • 小さなチームでアジャイルに開発する スタイル • 1コンポーネントごとに1AWSアカウント • 各アプリケーションレポジトリにtfファイ ルを内包 •
サービス共通テンプレートをmoduleレ ポジトリに用意するがstateの分け方な どはチーム内で決定 Git Repositry /app S3 /config /terraform Git Repositry /network /rds
あれ? これってなにかに似ていない?
Git Repositry Git Repositry Atlantis入れた頃の構成に近い • コンポーネントごとにレポジトリを作成 • 当時とのTerraformレポジトリとしての 違いは以下程度
◦ CI導入 ◦ 共通module導入 Git Repositry S3 /network /service_a(rds,ec2...) /service_b(rds,ec2...)
その間での 大きな違いは 合併&分裂 があったこと
同じものでも違って見える
組織体制によって ベストなレポジトリ構成は変わる
まとめ!
まとめ! • AWSリソース単位での分割は統制を保って利用していくのが大変 • 自社内でのサービス単位で分けるのがベスト • 組織構造によってベストなレポジトリ構成は変わる ◦ 弊社の場合だとSRE部と開発部が合併して変わったように •
ベストな姿を模索し続けましょう!
最後に宣伝!
積極採用中です! • 採用ページ https://recruit.hamee.co.jp/odawara • めずらしい福利厚生 ◦ 小田原手当 ▪ 小田原周辺地域に居住する正社員に対し、月
2万円を支給! ◦ いざ!小田原 ▪ 正社員の新幹線・特急電車・飛行機・船・高速バスでの通勤 OK(最大上限月5万円)
ご静聴ありがとうございました!