Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

PHPerKaigi2021

Yokoyama Tatsuo

March 19, 2021
Tweet

More Decks by Yokoyama Tatsuo

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  4. 小田原にあるHameeから来ました!

    View full-size slide

  5. 自己紹介
    twitterアカウント:@tatsuo4848
    GitHubアカウント:tatsuo48
    ~ これまでの経歴 ~
    拝承系SIer(インフラエンジニア、お客様サポート)

    株式会社みんなのウェディング(インフラエンジニア、SRE)

    Hamee株式会社(SRE、TechLead)
    PHPの会社歴約1年、三度の飯よりAWSが好き

    View full-size slide

  6. Hameeってこんな会社

    View full-size slide

  7. Hameeってこんな会社

    View full-size slide

  8. Hameeってこんな会社

    View full-size slide

  9. NextEngineの機能

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  16. Terraformの出番!

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  23. サービス軸でstate分割
    ● 相互参照が極力発生しないよう、state
    ファイルは以下の2軸で分割
    ○ サービスで共通利用するリソー

    ○ サービス固有のリソース
    ● stateファイルの参照をシンプルに
    Git Repositry
    /network
    S3
    /service_a(rds,ec2...)
    /service_b(rds,ec2...)
    課題
    ● stateファイルの肥大化
    ● プロジェクト数の増加
    解決した課題
    ● stateファイル間の複雑な依存関係

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  27. Terraform成長期
    (CD導入)

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  34. Terraform成長期
    (CI導入)

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  37. いったんまとめ

    View full-size slide

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

    View full-size slide

  39. 平和が見えたが...

    View full-size slide

  40. 開発組織の変!

    View full-size slide

  41. 合併&分裂

    View full-size slide

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

    View full-size slide

  43. ということで
    将来こんな形になる?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  49. あれ?
    これってなにかに似ていない?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  54. まとめ!

    View full-size slide

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

    View full-size slide

  56. 最後に宣伝!

    View full-size slide

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

    View full-size slide

  58. ご静聴ありがとうございました!

    View full-size slide