apply-before-mergeで実践するTerraformのflaky applyへの対応法 by Shoma Okamoto

■ 発表カテゴリ
募集要項（https://srekaigi.notion.site/SRE-Kaigi-2026-CfP-25a6f7392c108187a9e6e47c346396b2） にある6つの発表カテゴリからお選びください

・Tech: SREを支える具体的な技術や手法
・Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）

「Terraformでplanまでは成功していたけど、 Pull RequestをMergeしてapplyしたら失敗してしまった」

Terraformのこのような事象はflaky applyと呼ばれます。システム運用する方はInfrastructure as Code自体の重要性は理解しているかと思いますが、実運用にあたり複数人で複数のtfstateを運用しようとすると、このような課題にぶつかり理想とのギャップに悩まれることがあるのではないでしょうか。

スマートバンクのSREは2024年までは2人体制でしたが、2025年から4人体制になりました。それに伴い、Terraformのplan/applyを自動化できていない問題や同じtfstateに対する作業が衝突する問題、flaky applyなどの問題が顕在化し、業務に支障が出るようになりました。私たちはこの課題に対して、TACOS(Terraform Automation and Collaboration Software) であるAtlantisを用いたTerraformのapply-before-merge戦略を取り入れることにしました。

Atlantisを導入した結果、flaky applyをはじめとする各種課題について頭を悩ませることがなくなりました。

本セッションでは、Terraformの運用を段階的に改善してきたケーススタディをお届けします。

■ 発表の詳細（1000字程度）

Terraformではvalidateで構文チェック、planで実行計画を確認できますが、実際のapplyが成功するかどうかは実行してみないと分からない不確実性があります。Terraformを使ったことある方は1度は遭遇したことがあるのではないでしょうか。

このようなflakyなapplyを防ぐための戦略としてapply-before-mergeがあります。

これはPRをマージした後にapplyする（apply-after-merge）のではなく、"あえて"PRをマージする前にapply（apply-before-merge）するという戦略です。

apply-before-mergeを実現するためにはどのようなアプローチがあるのでしょうか。実際の事例を交えて、お伝えいたします。

以下のようなアウトラインを想定しています。

• スマートバンクのSREの変遷（3分）
• スマートバンクのTerraformの課題 （5分）
  • どのタイミングでapplyするかは各々に委ねられているローカルでの手動plan/apply
    • PRをマージした後にapplyしてエラーになってRevertするのが面倒なので、事前にapplyしがち問題
    • 予期せぬapplyが起きる例
  • 同一tfstateに対する作業の衝突
• 課題に対するアプローチ（15分）
  • terraform apply戦略
    • apply-before-mergeとapply-after-mergeの説明とその違い
  • apply-before-mergeを実現するのに必要な条件
    • ロック可能であること
    • ブランチが最新の状態であること
    • PRが特定のメンバーから承認済みであること
    • PRがマージ可能な状態であること
  • apply-before-mergeを実現するツールの候補
    • GitHub Actions、Digger、Atlantis等
    • pros/cons
    • 実装例
• スマートバンクで採用したAtlantis on ECS/Fargate（7分）
  • インフラ構成図
  • Webhookのセキュリティの担保
    • IP制限
    • Webhook Secret
    • 検証
  • 維持費用
    • 意外と安い！2万/月でそこそこ動くAtlantis
  • Amazon Cognitoを用いたWeb UIのカスタム認証の実装
    • Google OAuth
  • ハマりどころ
    • 並列実行時のplugin cache

■ 対象聴衆とその人たちが得られるもの
対象聴衆者:

• Terraformの運用を改善したいエンジニア
• Infrastructure as Codeに興味のあるエンジニア

得られるもの:

• Terraformのflaky applyへの対応法
• Terraformの各apply戦略（apply-before-merge/apply-after-merge）とそのメリット/デメリット
• Amazon ECS/FargateでのAtlantisの導入事例と実装のポイント

■ なぜこのトピックについて話したいのか（モチベーション）
私はTerraformを使ったAWSの運用を約5年ほど経験してきました。このプロポーザルを検討した背景にはTerraformは便利で普及しているツールである一方、その運用に関する情報発信があまり多くないという課題意識があります。Terraform（HCL）は宣言的に記述するため、コードリーディング自体は比較的難しいものではありません。しかし、実運用では複数のエンジニアで複数のtfstateを安全にオペレーションすることが求められます。さらに、スタートアップの場合はエンジニアリング組織の規模が拡大しても耐えうる運用設計になっているかというスケーラビリティをどう担保するかも重要になってきます。1度tfstateに取り込むためにimport/createしたら終わりではなく、継続的に安全に変更し続ける営みにこそ価値があり、そこに焦点を当てたいと考えています。

この発表を通じて、同じ悩みを抱える方の参考になれば幸いです。