この記事はFinatext Advent Calendar 2025 5日目の記事です。
はじめに
こんにちは。証券ドメインでインフラエンジニアをやっているぐらにゅです。
今回は複数のTerraformリポジトリを集約した話と、そこから1年運用してみての感想をまとめます。
集約する前の課題
Finatextの証券ドメインでは、証券サービスの提供に必要なコア機能を集約している金融インフラストラクチャ（BaaS）と、それに接続するパートナーサービス群で構成されています。
当時はパートナーサービス毎にTerraformリポジトリを作成・管理していたため、以下のような課題がありました。
- パートナーサービスが増えるごとにリポジトリを作成する必要があるため、管理するリポジトリがどんどん増えていき、管理コストが増大してしまう
- リポジトリによって、aws-providerのupdateに伴う対応にばらつきが発生する
- 例：リポジトリ個別に、どのバージョンの記述を利用しているのかの確認や、非推奨となった記述の修正を行う必要があった
また当時の開発環境は以下の状況だったこともあり、開発によりコストを集中できるよう管理コストを減らしていく必要性がありました。
- 管理対象のTerraformリポジトリ: 9
- パートナーサービスに関わる開発者数: 15人
そのため、ここで挙げた課題解消を目的にTerraformリポジトリをモノレポ化することにしました。
Terraformリポジトリを集約するにあたって考えたことや実施したこと
ディレクトリ構成について
各Terraformリポジトリがbeforeのディレクトリ構成になっていたので、検討の結果、集約するリポジトリではafterのようなディレクトリ構成としました。
- accounts
- PartnerService-dev
- PartnerService-stg
- PartnerService-prod
- modules
- service
- template
- aws
- Makefile
- accounts
- PartnerServiceA-dev
- api.tf
- main.tf
- network.tf
- variables.tf
- PartnerServiceA-stg
- PartnerServiceA-prod
- PartnerServiceB-dev
- modules
- common
- PartnerServiceA
- service
- template
- PartnerServiceB
- gcp
- Makefile
- accounts
- PartnerServiceA-dev
- modules
- PartnerServiceA
- modules
- settings
AWSディレクトリについては以下のような構造になっています。
- accountsに
${PartnerService}-${environment}単位でディレクトリを分け、実際にリソースと紐づくコードを管理 - modulesには汎用module（パートナーサービスによらないもの）と、パートナーサービス毎のmoduleを管理
パートナーサービスによってはAWS以外にGoogle Cloudも利用しているのですが、そこまで数が多くないのでクラウドサービス単位でディレクトリを分ける形とし、リポジトリまでは分けないことにしました。
（リポジトリ作成当時はGoogle Cloud Platformだったのでディレクトリ名もそのままになっています）
またクラウドサービスを跨るような設定（例：自社のIPアドレス）については、root直下のmodules/settingsに集約することで、管理コストや認知コストを低減させることにしました。
移行作業
前提としてtfstateは各AWSアカウントに専用のS3バケットがあり、その中で管理しています。
例えばPartnerServiceA-devであれば、PartnerServiceA-dev用のAWSアカウント内にtfstate用のS3バケットがあります。
この移行作業ではリポジトリの統合のみを行いたかったので、tfstateの配置は変えず、引き続き各AWSアカウントにあるバケット内で管理することにしました。
そのため、移行作業としては各Terraformリポジトリから統合先のTerraformリポジトリへコードを移動させるだけでした。
また、tfstateが上記のような構成になっているため、モノレポ化してみたものの「ポリレポ化の方が管理しやすい」となった時には同じくコードの移動のみで済むというのも、モノレポ化に踏み切りやすかった理由の1つでした。
1年運用した感想
移行して大体1年経過したので、この形で運用してみた感想をまとめました
- default_tags付与など、管理に利用する変更を一括でかつ1箇所で取り扱えるようになった
- 色々なパートナーサービスのコードやPRも気軽に見れるようになったので、知識共有がしやすくなった
- セキュリティやコンプライアンスにかかる設定をmoduleとして提供・利活用しやすくなった
- 例：S3のサーバサイドエンクリプション・バージョニング・パブリックアクセスブロック
まとめ
モノレポ/ポリレポどちらがいいのかは、組織内でのインフラ管理の考え方やインフラ構成にもよると思いますが、今回についてはモノレポ化することで嬉しい面が多かったかなと思います。
この記事がTerraformリポジトリの管理方法に悩んでいる方の考えの一助になれば幸いです。
Discussion