Terraformのレポジトリ、ディレクトリ構成どうする？/Terraform repository, directory structure What should I do?

Slide 1

Slide 1 text

Terraformのレポジトリ、ディレクトリ構成どうする？ #PHPerKaigi 2021 Hamee 株式会社横山達男(@tatsuo4848)

Slide 2

Slide 2 text

本セッションのターゲット ● PHPを利用する開発者の中でも ○ インフラエンジニア、 SREではないがTerraformでIaCやっている！という方 ○ インフラエンジニア、 SREとしてバリバリTerraform書いている方 ○ Terraformファイルの構成について悩んでいる方

Slide 3

Slide 3 text

本セッションのターゲット一緒に悩みましょう！ ● PHPを利用する開発者の中でも ○ インフラエンジニア、 SREではないがTerraformでIaCやっている！という方 ○ インフラエンジニア、 SREとしてバリバリTerraform書いている方 ○ Terraformファイルの構成について悩んでいる方

Slide 4

Slide 4 text

小田原にあるHameeから来ました！

Slide 5

Slide 5 text

自己紹介 twitterアカウント：@tatsuo4848 GitHubアカウント：tatsuo48 ~ これまでの経歴 ~ 拝承系SIer(インフラエンジニア、お客様サポート) ⬇ 株式会社みんなのウェディング(インフラエンジニア、SRE) ⬇ Hamee株式会社(SRE、TechLead) PHPの会社歴約1年、三度の飯よりAWSが好き

Slide 6

Slide 6 text

Hameeってこんな会社

Slide 7

Slide 7 text

Hameeってこんな会社

Slide 8

Slide 8 text

Hameeってこんな会社

Slide 9

Slide 9 text

NextEngineの機能

Slide 10

Slide 10 text

NextEngineのシステム構成メイン機能 Platform API アプリアプリアプリアプリアプリアプリ

Slide 11

Slide 11 text

NextEngineのシステム構成メイン機能 Platform API アプリアプリアプリアプリアプリアプリ

Slide 12

Slide 12 text

NextEngineのシステム構成メイン機能 Platform API アプリアプリアプリアプリアプリアプリ

Slide 13

Slide 13 text

NextEngineのシステム構成メイン機能 Platform API アプリアプリアプリアプリアプリアプリ AWS 1アカウントで運用中

Slide 14

Slide 14 text

NextEngineのシステム構成メイン機能 Platform API アプリアプリアプリアプリアプリアプリ AWS 1アカウントで運用中 AWS 環境ごとに分けた複数アカウントで運用予定 (さくらインターネットから移行中)

Slide 15

Slide 15 text

大量のコンポーネント 1. メイン機能のデータにアクセスするためにAPIを用意 2. アプリを管理するためにPlatformという基盤となるサービスが存在 3. アプリ自体が動作する環境も必要

Slide 16

Slide 16 text

Terraformの出番！

Slide 17

Slide 17 text

Hameeがどのように Terraformを扱ってきたか時系列で紹介

Slide 18

Slide 18 text

Terraform導入期 (AWSリソース単位でstate分割)

Slide 19

Slide 19 text

AWSリソース単位でstate分割 ● 2015年頃からHameeでは利用 ● AWSアカウントは1つだが、コンポーネントごとにレポジトリを作成 ● stateファイルはAWSリソース種別 (RDS,network,EC2など)で分割 ● 導入対象もまだまだ少ない Git Repositry /network S3 /rds /ec2 課題 ● stateファイル間の複雑な依存関係

Slide 20

Slide 20 text

stateファイル間の複雑な依存関係 ● state間の依存関係を考慮して順番に applyする必要あり ○ /networkで作成したセキュリティグループを/rdsで作成する RDSに設定 ○ /networkで作成したセキュリティグループを/ec2で作成する EC2に設定 ● stateファイルという単位で見た場合、相互参照が発生する危険も Git Repositry /network S3 /rds /ec2

Slide 21

Slide 21 text

まとめ ● IaCによる変更操作への安心感 ● インフラ新規構築を素早く実践できるアジリティの獲得課題 ● stateファイル間の複雑な依存関係得たもの

Slide 22

Slide 22 text

Terraform成長期 (サービス軸でstate分割)

Slide 23

Slide 23 text

サービス軸でstate分割 ● 相互参照が極力発生しないよう、state ファイルは以下の2軸で分割 ○ サービスで共通利用するリソース ○ サービス固有のリソース ● stateファイルの参照をシンプルに Git Repositry /network S3 /service_a(rds,ec2...) /service_b(rds,ec2...) 課題 ● stateファイルの肥大化 ● プロジェクト数の増加解決した課題 ● stateファイル間の複雑な依存関係

Slide 24

Slide 24 text

stateファイルの肥大化 ● 導入期と比較して管理するリソースも増えstateファイルが肥大化 ● plan結果に目を凝らさなければ予期せぬ変更が加わるかもしれない恐怖 Git Repositry /network S3 /service_a(rds,ec2...) /service_b(rds,ec2...)

Slide 25

Slide 25 text

Git Repositry Git Repositry プロジェクト数の増加 ● AWSアカウントは1つだが、コンポーネントごとにレポジトリを作成 ● 初期は良かったがコンポーネントも順調に増え、どのレポジトリで何を管理しているのか？の把握が困難 ● 最盛期で 53レポジトリ ● レポジトリの粒度や構成も作成者によりさまざま Git Repositry S3 /network /service_a(rds,ec2...) /service_b(rds,ec2...)

Slide 26

Slide 26 text

まとめ ● IaCによる変更操作への安心感 ● インフラ新規構築を素早く実践できるアジリティの獲得課題 ● stateファイル間の複雑な依存関係 ● stateファイルの肥大化による変更操作への恐怖感 ● プロジェクト数の増加による見通しの悪さ得たもの

Slide 27

Slide 27 text

Terraform成長期 (CD導入)

Slide 28

Slide 28 text

CD導入 ● atlantisを導入 ● PRコメント駆動でterraform planを実施 ● Terraformをチームで安全に使うための環境を獲得 Git Repositry /network S3 /service_a(rds,ec2...) /service_b(rds,ec2...) 課題 ● Atlantisの設定作業の手間

Slide 29

Slide 29 text

Git Repositry Git Repositry Atlantisの設定作業の手間 ● Atlantisのサーバ自体は１つだが各レポジトリで設定が必要 Git Repositry S3 /network /service_a(rds,ec2...) /service_b(rds,ec2...)

Slide 30

Slide 30 text

まとめ ● IaCによる変更操作への安心感 ● インフラ新規構築を素早く実践できるアジリティの獲得 ● Terraformをチームで安全に使うための環境を獲得課題 ● stateファイルの肥大化による変更操作への恐怖感 ● プロジェクト数の増加による見通しの悪さ ● Atlantisの設定作業を各プロジェクトごとのレポジトリで行う手間得たもの

Slide 31

Slide 31 text

Terraform成長期 (レポジトリ大統一)

Slide 32

Slide 32 text

レポジトリ大統一 ● バラバラだったレポジトリを 2つにまとめる ○ NextEngine主要コンポーネントのレポジトリ ○ アプリのレポジトリ ● 各レポジトリの第一階層を AWSアカウントと定めて分割 ● stateファイルの移行は骨が折れるのでそこには触れない ● stateファイルの粒度は様々な状態のまま Git Repositry /account_a/network S3 /account_a/service_a/ /account_b/service_b 解決した課題 ● Atlantisの設定作業の手間 ● プロジェクト数の増加による見通しの悪さ

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Terraform成長期 (CI導入)

Slide 35

Slide 35 text

CI導入 ● Lint、静的解析ツール導入 ○ tflint ○ checkov ○ terraform fmt ● PRトリガーでCircleCI上で実行される ● Terraformをチームで正しく使うための環境を獲得 Git Repositry /account_a/network S3 /account_a/service_a/ /account_b/service_b

Slide 36

Slide 36 text

まとめ ● IaCによる変更操作への安心感 ● インフラ新規構築を素早く実践できるアジリティの獲得 ● Terraformをチームで安全に使うための環境を獲得 ● Terraformをチームで正しく使うための環境を獲得課題 ● stateファイルの肥大化による変更操作への恐怖感得たもの

Slide 37

Slide 37 text

いったんまとめ

Slide 38

Slide 38 text

現在のTerraform Git Repositry /account_a/network S3 /account_a/service_a/ /account_b/service_b

Slide 39

Slide 39 text

平和が見えたが...

Slide 40

Slide 40 text

開発組織の変！

Slide 41

Slide 41 text

合併＆分裂

Slide 42

Slide 42 text

開発組織の変！ ● SRE部、開発部というように別れていた組織が合併＆分裂 ● 開発スピード向上のために2ピザルールに則った10名程度の部署が3部署に ● 更にその中でも4~5人程度のプロジェクトを作成 ● プロジェクト単位で元SRE，元開発部が混ざり合い協力する形

Slide 43

Slide 43 text

ということで将来こんな形になる？

Slide 44

Slide 44 text

将来こんな形になる？ ● 小さなチームでアジャイルに開発するスタイル ● 1コンポーネントごとに1AWSアカウント ● 各アプリケーションレポジトリにtfファイルを内包 ● サービス共通テンプレートをmoduleレポジトリに用意するがstateの分け方などはチーム内で決定 Git Repositry /app S3 /config /terraform Git Repositry /network /rds

Slide 45

Slide 45 text

Slide 46

Slide 46 text

まとめ ● IaCによる変更操作への安心感 ● インフラ新規構築を素早く実践できるアジリティの獲得 ● Terraformをチームで安全に使うための環境を獲得 ● Terraformをチームで正しく使うための環境を獲得課題 ● CI/CDの設定がプロジェクトによってまちまちになる危険性得たもの

Slide 47

Slide 47 text

まとめ ● IaCによる変更操作への安心感 ● インフラ新規構築を素早く実践できるアジリティの獲得課題 ● CI/CDの設定がプロジェクトによってまちまちになる危険性 ○ サービス稼働前の最終確認事項のチェックリストを作成することでケアできないか？得たもの

Slide 48

Slide 48 text

Slide 49

Slide 49 text

あれ？これってなにかに似ていない？

Slide 50

Slide 50 text

Git Repositry Git Repositry Atlantis入れた頃の構成に近い ● コンポーネントごとにレポジトリを作成 ● 当時とのTerraformレポジトリとしての違いは以下程度 ○ CI導入 ○ 共通module導入 Git Repositry S3 /network /service_a(rds,ec2...) /service_b(rds,ec2...)

Slide 51

Slide 51 text

その間での大きな違いは合併＆分裂があったこと

Slide 52

Slide 52 text

同じものでも違って見える

Slide 53

Slide 53 text

組織体制によってベストなレポジトリ構成は変わる

Slide 54

Slide 54 text

まとめ！

Slide 55

Slide 55 text

まとめ！ ● AWSリソース単位での分割は統制を保って利用していくのが大変 ● 自社内でのサービス単位で分けるのがベスト ● 組織構造によってベストなレポジトリ構成は変わる ○ 弊社の場合だとSRE部と開発部が合併して変わったように ● ベストな姿を模索し続けましょう！

Slide 56

Slide 56 text

最後に宣伝！

Slide 57

Slide 57 text

積極採用中です！ ● 採用ページ https://recruit.hamee.co.jp/odawara ● めずらしい福利厚生 ○ 小田原手当 ■ 小田原周辺地域に居住する正社員に対し、月 2万円を支給！ ○ いざ！小田原 ■ 正社員の新幹線・特急電車・飛行機・船・高速バスでの通勤 OK(最大上限月５万円)

Slide 58

Slide 58 text

ご静聴ありがとうございました！