イオンの大規模環境を支えるHCP Terraform

参考になった

レビュー投稿日の情報になります

イオン株式会社 / morihaya

インフラエンジニア / 従業員規模: 301名〜500名 / エンジニア組織: 51名〜100名

最終更新日2025/11/26投稿日2025/11/27

利用プラン

ツールの利用規模

ツールの利用開始時期

事業形態

HCP Terraform Plus with Silver Support

51名〜100名

2022年

B to B

B to C

利用プラン	HCP Terraform Plus with Silver Support
ツールの利用規模	51名〜100名
ツールの利用開始時期	2022年
事業形態	B to B B to C

アーキテクチャ

アーキテクチャの意図・工夫

HCP Terraformを入り口として、SREチームに限らず開発チーム自身がリソースの状態を確認し、変更依頼を直接出すことができる状態を目指している。加えてIaCでの管理対象をパブリッククラウドのAzure以外のSaaSにも広げても、HCP Terraformの共通するインターフェースで管理を行えている。

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

当社（イオンスマートテクノロジー株式会社）では、システムの基盤としてAzureを利用しており、その構成変更や新プロダクトのためのAzureリソースの構築が紙Excelでの手順書と、複数名チェックでのWebポータルからの手作業によって行われていた。

このやり方は効率が悪いだけでなく、ミスも起きやすく、なにより緊急時の戻し作業であったり、過去の変更経緯を正しく追うことなどが困難な状態となっていた。

この問題を受けてTerraformの導入を開始し、Azure PipelineによるCI/CDを構築しはじめていたが以下のような課題を抱えていた。

CI/CDパイプラインがわかりづらい
DB管理者ユーザのパスワードや秘密鍵などの秘匿情報がbase64エンコードされた状態でリポジトリに格納
tfstateファイルがAzureのストレージに格納されるため、Azure権限があると参照・改ざんができてしまう

どのような状態を目指していたか

Infrastructure as Code(IaC)導入によってプログラム開発の手法をAzureリソースの各種作業に適用したいと考えた。具体的にはOSSとしても広く普及し成熟しているTerraformを用いてAzureリソース管理にIaCを導入することで、最新の状態がコードとして管理され明白となり、追加・変更においてはGitとVCSを利用したレビューの取り組みと変更履歴の記録を実現できるようにしたい。

さらにはTerraformの特徴でもある特定クラウド・SaaSにロックされない幅広い管理対象を活かし、Azure以外のSaaSも同様に管理したいと考えた。

参考：過去のHCP Terraform導入に関する発表資料

比較検討したサービス

Azure PipelineおよびARM(Azure Resource Manager)テンプレートによるCI/CD
Azure PipelineとOSSのTerraformによるCI/CD

比較した軸

今後の内製化を見越して採用する人材およびチームにとって活用しやすいツールであるかを重視した。

選定理由

TerraformはIaC管理のデファクトスタンダードと言えるほど普及しており、経験者の採用が容易と判断した。加えて検証によってAzure Pipelineによる手組みなCI/CDにはわかりづらさがあった。

導入の成果

改善したかった課題はどれくらい解決されたか

上述した主な課題は解消している。

CI/CDパイプラインがわかりづらい
- HCP Terraformが実行するためシンプル。パイプライン自体のコードも不要に
DB管理者ユーザのパスワードや秘密鍵などの秘匿情報がbase64エンコードされた状態でリポジトリに格納
- HCP TerraformのVariableに格納することで参照を防げる
tfstateファイルがAzureのストレージに格納されるため、Azure権限があると参照・改ざんができてしまう
- HCP Terraformが管理するため改ざんを防げる

どのような成果が得られたか

Terraformで管理するAzureリソースは拡大し、Azure以外のSaaS（New Relic、PagerDuty）などもTerraform管理対象にできている。加えてHCP Terraform自体もTerraform管理できることでIaCの恩恵を幅広く受けられる状態となった。

導入時の苦労・悩み

HCP Terraform自体の導入だけでなく、既存のTerraformコードのリファクタリングも並行して行ったことで、初期の設計や検討項目が多く発生した。

導入に向けた社内への説明

上長・チームへの説明

当時の組織の決済者からは「コスト削減への効果」と「必要性」についてより深い説明を求められた。その後は当時のCTOも交え、具体的な課題を共有して理解を得ることで導入に合意を得た。

活用方法

Azureリソースやユーザおよびその権限、各種SaaSの変更などがあり、HCP Terraformが動作しない日はない。加えてチーム朝会では保存したビューを利用してHCP Terraformのワークスペース全体に対して「Driftが発生しているか？」や「正常終了していないものは？」のチェックを行なっている。

よく使う機能

Terraformの実行環境
GitHubやAzure DevOps ReposでPR作成をトリガーとしてterraform planが実行され、マージ後にterraform applyを実行する（多くのワークスペースではapply前にHCP Terraform上で承認処理を入れている）
「Explorer」の「Saved views」
上述したDrift発生および異常終了したワークスペースの特定を朝会で毎日確認している

ツールの良い点

導入とUIがシンプル
AzureやSaaSへの認証情報をまかせられる
認証情報、環境変数などをVariable Setとして簡単に展開できる
Explorerによる各種ワークスペースの状態を簡単に把握できる
HCP Terraform自体をTerraform管理できる
ユーザ管理機能がある

ツールの課題点

サポート対応は過去経験から良いとは言い難い（悪くもないが）
HCP(HashiCorp Cloud Platform)からHCP Terraformへログインすると、セッション時間が1時間固定されて再ログインがストレスとなる
HCPへSSOログインすると、HCPからHCP Terraformへログインできない（今後改善予定とのこと）
フロントエンドの動作が遅い、CIの開始・終了時間が取得しにくいといった使いづらさが少しある

ツールを検討されている方へ

OSSとしてTerraformを利用し、CI/CDをGitHub Actionsなどで自前で運用することは十分可能です。一方でそのパイプライン自体のメンテナンスに工数をかけたくないのであれば、マネージドなHCP Terraformは検討の価値があります。マネージドなCI/CDに加えてシンプルなUI、クレデンシャル管理、ユーザ権限制御、専用の各種ダッシュボードが付属し、HCP Terraform自体をTerraformでIaC管理できる良さもあります。

今後の展望

より多くの開発チームへHCP Terraformを展開する
ユーザ数がコストに影響しないため安心して展開が可能
Sentinelによるポリシーの展開
すでに導入を開始したSentinelにより、組織のドメインに沿わない違反や、planでは気づけない既知のエラーなどを検知できる状態とする
生成AIの活用
先日HCP Terraformに対応したTerraform MCPを活用し、Drift修正などのToil作業をAI Agentに任せていく

イオン株式会社 / morihaya

インフラエンジニア / 従業員規模: 301名〜500名 / エンジニア組織: 51名〜100名

SIerでネットワークエンジニアを2年、その後はインフラエンジニアとしてサーバや仮想基盤の管理を8年、株式会社カプコンへ転職しプライベートクラウドの管理やゲームタイトル付きインフラエンジニアとして3年、オイシックス・ラ・大地株式会社でSRE兼プレイングマネージャとして5年ほどサービス運用に携わり、2024/03より現職。