Terraform を活用したインフラ構築の紹介

はじめまして！東京ガスリビング戦略部の SRE チームに所属しております迫田と申します。

私は2024年1月に東京ガスに入社し、現在 myTOKYOGAS フロントエンドのインフラ運用やマイクロサービスプラットフォームの構築を担当しています。

今回の記事では、Terraform を活用したインフラ環境の構築についてご紹介します。

Terraform とは？

HashiCorp 社が提供する Infrastructure as Code (IaC) ツールで、パブリッククラウドをはじめ、様々なインフラ設定をコードで管理することができます。 www.terraform.io

チームにおける Terraform の使い方

myTOKYOGAS フロントエンドでは、基本的に Terraform を用いて Azure 環境を構築しています。Terraform コードは GitHub 上で管理し、GitHub Actions を実行することで実際の環境を構築しています。ローカル端末での terraform apply の実行を避けることで、いつ誰が環境に手を加えたのかといった履歴がすぐにわかるようになっています。

また、現在私たちのチームでは AWS 上で Amazon EKS を中心としたマイクロサービスプラットフォームを構築しているのですが、構築のためのツールとして Terraform を採用しました。

マイクロサービスプラットフォームの詳細については以下の記事をぜひご覧ください。 tech-blog.tokyo-gas.co.jp

なぜ AWS 環境でも Terraform を採用したのか

AWS における IaC といえば、AWS CloudFormation や AWS Cloud Development Kit (CDK) も選択肢としてあげられますが、私たちのチームでは、以下の理由で Terraform 導入を決めました。

• myTOKYOGAS フロントエンドで Azure を Terraform で構築・管理しており、チーム内にノウハウが蓄積されていること
• AWS や Azure に限らず、当チームが使用している他のプロダクト (Datadog, PagerDuty 等) も Terraform で構築・管理できること

また、4月より Terraform に非常に明るいメンバーが仲間に加わったことも理由の一つです！

ただし、一度 Terraform に決めたからずっと使い続けるというわけではなく、よりチームにとって適したプロダクトがあればチーム内で相談しつつ、常に柔軟性を持って最善な選択をしていきたいと考えています。

理想と課題

IaC の大きなメリットの一つは、インフラの状態を宣言的にコードで表現できることだと考えています。そして一度作成したコードを複製すればすぐに新しい環境が出来上がる、という状態が理想だと思っています。素早くインフラ環境を用意できるようになれば、アプリケーションの改善や新機能追加のスピードも上がり、結果としてお客さまへの価値提供を早めることができます。また、必要なときに必要な環境を用意できるようになれば、クラウド利用料の削減にもつなげることができます。

しかし、Terraform 以外の方法で作成するリソースがあると順番を意識して構築する必要があったり、秘密鍵やパスワードなどセキュリティリスクを鑑みると Terraform で管理すべきではないリソースがあったりと、単純にコードを複製するだけではすべてのリソースを構築することができない課題に直面しています。

少し細かい話になってしまうのですが、具体例を一つ紹介します。私たちの Amazon EKS クラスタには AWS Load Balancer Controller が導入されているため、Kubernetes リソースの Ingress を作成することで、クラスタ外部からの通信を受ける Application Load Balancer (ALB) を作成しています。 tech-blog.tokyo-gas.co.jp

独自ドメインを設定し、HTTPS で ALB に接続したいため、Amazon Route 53 での A レコード作成、AWS Certificate Manager での証明書発行が必要になります。また、外部からの攻撃を防ぐために AWS WAF を ALB に紐づけることも求められます。これらの AWS リソースも Terraform で作成するのですが、A レコードは ALB が作成された後でないと登録できないため、まずは証明書と WAF を先に Terraform で作成し、次に EKS クラスタ上に Ingress をデプロイすることで ALB を作成し、最後に ALB の DNS 名を A レコードに登録する、という手続き的な方法で構築をすることになります。*1

今のところ一つ一つの作業の負荷は大きくはないのですが、このように手順に従って構築する項目が増えると、宣言的な表現の良さが失われ、人為的なミスや構築スピード低下につながるので本来は避けたいと考えています。今回の例に限らず、Terraform の世界に閉じないリソースをどう管理していくのかが大きな課題であり、チームで日々ディスカッションしながら自分たちにとって最適なプラクティスを模索しています、、、！

さいごに

ご覧いただいたとおり、私たちのチームでは Terraform を活用して AWS や Azure の環境をなるべく宣言的に構築・管理しています。一方、様々な課題にも直面しており、どうすればより早く・正確に環境を用意し、お客さまにいち早く価値を提供できるかを日々チームで議論しながら検討を進めています！

私たちのチームでは、ともに働く仲間を積極的に募集しています。SRE のみならずソフトウェアエンジニアのポジションもございますので、少しでも興味をお持ちいただけましたら、ぜひカジュアル面談からご応募ください！

Application Developers www.wantedly.com

SRE www.wantedly.com

最後までお読みいただきありがとうございました。また次回の記事でお会いしましょう！

*1:Terraform で Ingress を作成するという方法もありますが、ArgoCD を用いた GitOps を実現するために Kubernetes リソースは Terraform とは別のライフサイクルで管理したいと考えています。これも構築や運用を進める中で柔軟に方針を決めていきたいと思っています。