HCP Terraform による開発生産性とセキュリティ向上の実現

参考になった

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

株式会社MIXI / Yusuke Hamano

メンバー / バックエンドエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 301名〜500名

最終更新日2024/07/22投稿日2024/07/22

利用プラン

ツールの利用規模

ツールの利用開始時期

事業形態

Plus プラン

101名〜300名

2023年10月

B to C

C to C

アーキテクチャ

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

導入背景

ツール導入前の課題

MIXI における IaC の成熟度は各プロダクトのエンジニアリング組織でばらつきがありました。また、IaC の CI/CD ワークフローについてもエンジニアリング組織毎に構築しており、生産性が高いとは言えない状況でした。

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

IaC を実践している/実践しようとしているエンジニアリング組織が HCP Terraform をすぐに利用できる状態を目指しました。そのために組織横断のエンジニアリング部署が契約やオーナー業務を担い、利用希望者は簡易な申請のみで利用できるような運用を検討しました。また、HCP Terraform の利用を強制はせずに選択肢の一つとして提供するように立て付けました。

比較検討したサービス

なし

選定理由

Terraform の開発元である Hashicorp 社が提供していること

導入の成果

これまで IaC を実践できていなかった組織への IaC 導入

メンバーの IaC スキルがまだ十分ではなく IaC の導入を躊躇していたエンジニアリング組織が HCP Terraform を活用することで IaC を実践できるようになりました。

マネージドな state ファイル管理

HCP Terraform でのマネージドな state ファイル管理により以下のメリットを享受できました。

state ファイル管理用のストレージ(S3, Cloud Storage等)を別途用意する必要が無くなった
state ファイルの内容や履歴を GUI で確認できる
state ファイル間のリソース参照や参照許可設定がシンプル

CI/CD ワークフロー構築の簡略化

VCS 連携機能を利用することで、PR 作成/更新をトリガーとした plan 実行と PR マージをトリガーとした apply 実行といった CI/CD ワークフローを簡単に実現することができます。これにより各エンジニアリング組織が行っていた CI/CD ワークフロー構築/メンテナンスコストを削減することができました。また、VCS 連携以外にも API, CLI での操作や Run Tasks による plan と apply 前後に任意の処理を組み込むことで独自のワークフローを構築したいといった場合にも対応できます。

terraform version の自動 upgrade

Workspace 毎に指定する terraform version に latest やマイナーバージョンは固定でパッチバージョンは最新を使うといった設定が可能で terraform version の upgrade 作業を自動化できます。

Policy as Code によるセキュリティ向上

Workspace に Policy(Sentinel or OPA) を適用することでセキュリティ向上を実現しました。CIS ベンチマーク(米国の非営利法人 Center for Internet Security が公表している、情報システムの構築・運用における構成要素別のセキュリティ対策のベストプラクティスを定めたガイドライン)などの共通フレームワークによるチェックは全 Workspace に対して advisory(Warning のみ) で設定し、各プロダクトのセキュリティ要件に適したチェックは各プロダクトのエンジニアリング組織が設定する立て付けにしました。VCS で管理している Policy 設定を VCS 連携することで簡単に特定の Project, Workspace に適用させられることも便利でした。

導入時の苦労・悩み

社内マーケティング

IaC の実践に HCP Terraform の利用を全社的に強制する予定は無かったのですが、各エンジニアリング組織に HCP Terraform の存在とメリットを認知してもらいたいと考えていました。そのため、以下の方法で社内マーケティングを行いました。

社内ドキュメントに概要、メリット、利用方法を記載して公開する
社内のエンジニアリング共有会で宣伝する
HCP Terraform に興味を持ってくれたエンジニアリング組織に PoC 段階で利用してもらい、使用感を社内ドキュメントに公開してもらった

権限設計

極力オーナーでしか行えない作業を少なくし、利用者がセルフサービスで利用する運用を検討しましたが具体的にどのような権限設定を行えば良いかドキュメントを見た限りでは分かりませんでした。そのため、PoC を設けてもらい先行利用者と協力しながらどのような権限設計にすれば良いかを検討しました。

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

上長・チームへの説明

導入費用と比較しても十分にメリットがあることを説明しました。具体的には以下の観点について説明しました。

開発生産性向上
- terraform を利用したリソースプロビジョニングのための基本的な CI/CD ワークフローがビルトインされており、開発者側で都度ワークフローを用意する必要が無くなる
- state ファイル管理機能により、開発者側で state ファイル管理用のストレージやロック機構を用意する必要がなくなる
- GUI ベースで操作することが可能なため、terraform に慣れていない開発者の利用ハードルを下げて IaC のセルフサービス化を促進できる
- 社内でよく利用されるリソース群を private module として用意することで、再利用可能とする
セキュリティ向上
- Policy as Code による予防的/発見的な統制を適切な範囲で適用させることが可能

活用方法

各プロダクトのエンジニアリング組織が日々の開発業務の中で開発環境及び本番環境の IaC 実践に利用しています。

よく使う機能

VCS 連携を利用した CI/CD ワークフロー
tfstate 管理
Policy Sets
terraform version の自動 upgrade
Drift Detection
slack notification
Okta を IdP とした SSO
Team ベースの権限管理

ツールの良い点

VCS 連携を利用することで terraform の一般的な CI/CD ワークフロー(PR 作成/更新をトリガーとした plan 実行と PR マージをトリガーとした apply 実行)をすぐに利用できる
各種設定や plan/apply 結果を GUI で操作、確認できる。tfe provider を利用することで設定を terraform で管理することも可能
terraform で管理しているリソース数による課金のため、ユーザー数を気にせずに利用できる

ツールの課題点

課題というよりはこういったことができるようになるとさらに便利になると思っていること

一般的な CI/CD ワークフロー(PR 作成/更新をトリガーとした plan 実行と PR マージをトリガーとした apply 実行)から発展させて、plan と apply の前後に任意の処理を入れる場合は Run Tasks を利用することになるが、HCP Terraform 外の SaaS や自作の処理機構を用意する必要があり、手間な場合がある。こういった処理も HCP Terraform 内で完結して実施できるようになってほしい。
Team への User 追加削除権限を特定 Team に付与した場合にその Team 以外の Team の User 追加削除もできてしまうため、特定の Team に対してのみ User の追加削除を許可できるようにしてほしい。
tfe provider を利用して Workspace を terraform 管理する場合に GitHub Apps による VCS 連携が不可能なため、対応してほしい
HCP Terraform を操作するための API Token が静的なものしか発行できないため、有効期限付きの一時的な Token を発行できるようにしてほしい。
Audit Log が API 経由での取得しか対応していないため、GUI で確認できるようにしてほしい。