とても人気が出て、製品の名前がそのマーケット全体を意味するようになることが時々ある。ほんの一例を挙げると、「ウォークマン」、「フォトショップで編集済み」、「ベルクロ」、「ググる」、そして「Terraformでインフラ構築」などだ。

Terraformは、かなり長い間、コードとしてのインフラストラクチャ（IaC）と事実上、同義語だった。Terraformは2014年にリリースされたオープンソースツールで、基本的に1つのことを非常にうまく処理してくれる。望んだ構成と実際のITインフラ（現実世界）とが一致することをTerraformは保証してくれる。

言い換えると、TerraformはREST APIをバックエンドに持つリソースを管理するステートマシンとも言える。

この記事はCAST AIプロバイダーのドキュメントを焼き直したハウツー記事じゃない。この記事では、なぜTerraformなのかについて、私自身の考えを共有していきたいと思っている。

私はTerraformが大好きなんだ。2016年から使っている。CAST AIでは、Terraformを利用して、製品コンセプトの検証もした。

Pulumiという競合製品も出てきたけれど、現時点でTerraformの牙城を崩すようなツールはまだないと考えている。

あなたがエンジニアで、Terraformについてまだ聞いたことがないのなら、履歴書にTerraformについて今すぐ書いた方がいい（1時間、時間を取ってHashiCorp社が提供する優れたチュートリアルを終わらせてしまおう）。

DevOpsエンジニアがIaCに常に惹きつけられるのはなぜだと思う？ブラウザーでAWSコンソールにアクセスして、数回クリックするだけで、EC2インスタンス、VPC、EKSクラスターなど、あらゆるインフラを作成できるというのに。

最も直感的な答えは、「自動化は時間を節約する」からだ。エンジニアというのは、自動化するのが大好きなんだ。この点について極端な例を挙げて説明すると、この記事を読んでみてほしい。遅くまで仕事をした時に妻に（ランダムな理由で）テキストメッセージを送るスクリプトを書いたり、コーヒーコーナーにたどり着くまでにコーヒーを淹れおわるようなスクリプトを書いたりといったハックをしたエンジニアについて書かれている。

90秒以上かかる可能性のある作業はすべて、自動化のターゲットとなりうる。いつものことだけど、このことを説明してくれるxkcd風の図がある:

出典:https://xkcd.com/1205/

もちろんクラウドインフラストラクチャを日常的に作成したり壊したりしていない場合、時間の節約は決定的な要因にはならない。

問題なのは、DevOpsエンジニアが人間的すぎるということなんだ。ミスを犯すし、気が散って疲れて、キーボードやマウスの操作ミスをする。エンジニアを稼働させるにはコストがかかり、同じことを何度も繰り返しさせるとモチベーションを低下させてしまう。

コードとしてのインフラ（IaC）は、一貫性を提供することでこれらの問題を解決してくれる。インフラのプロビジョニング時に、結果が一意になってほしいと思うものだ。

3つ目の大きな理由は、コードでインフラを表現した場合、CI／CDパイプラインとコードレビューがもたらすあらゆる利点を享受できるというものだ。あるエンジニアがIaCでコードを書くとすると、別のエンジニアがそれをレビューするといった具合だ。

この場合、プルリクエストには、HashiCorp Configuration Language（HCL）だけではなくて、Terraform Planの結果が添付されていないといけない。CI／CDパイプラインにTerraform を導入することで、DevOpsエンジニアは神経を消耗するほかの作業に集中でき、ターミナルウィンドウでTerraformの適用状態を常に確認する必要がなくなるんだ。

DevOps（エンジニア）は皆、毎営業日そして、日曜日に2回行われるインフラ変更作業の際に、一貫した方法を利用し、リスクを軽減できるようになる。

また、IaCを使用している場合は、常に最新の状態を表現していることになるから、インフラについてのドキュメントを新規作成したり、メンテナンスしたりする必要性も少なくなる。

私はかつて伝統的な金融業界で働いていた。伝統的な金融業界というのは、歴史的な経緯からとてもITリスクを敬遠する環境にある。しかし、この業界もITリスクを敬遠ばかりしていられなくなったと気づいた。伝統的な企業がイノベーションを迅速に提供し始めなければ、新興のフィンテック企業に負けてしまうからだ。

厳密な変更管理プロセスとQA承認プロセスにしたがって、ビジネス部門は新機能を作成していたけれど、いつもこんな状況が起きていた。

開発環境とステージング環境では正常に動作していたけれど、本番環境ではまた動かなかった！

問題は、時間の経過とともに、開発、ステージング、本番環境の設定が次第にずれていってしまうことだった。（これは暗黒の時代のことなんだけど）四半期ごとに大規模なバッチでテストしてリリースすると、インフラとアプリケーションの互換性に関するバグを見つることができず、それがビジネスアプリケーションのダウンタイム発生の原因となっていたんだ。

この問題は今でも、Openstack、VMware Cloud Director、または単一のパブリッククラウド環境などのホモジニアスなプライベートクラウドなどでも起きうるし、ハイブリットクラウドやマルチクラウドの場合はより深刻なものになる。

金融業界で働いていたとき、当時のプライベートクラウド用のTerraformプロバイダーを作成した。このプロバイダーは基本的な枠組みを作成してくれるもので、サーバー／K8sクラスターとネームスペースを作成、RBACの設定、ミドルウェアとデータベースをデプロイ、内部ネットワーク構築、ファイアウォールの設定、ロードバランサーの設定、セキュリティサンドウィッチを経由してアプリケーションをインターネット越しに公開などを実施してくれた。

プロバイダーはそれほど行数の多くないTerraformファイルだったけれど、100以上の個々のタスクを抽象化していて、1つ1つのgitリポジトリに格納された同じTerraformのコードが、開発、ステージング、および本番環境向けに使用されていた。これが環境差異を避けるための重要なポイントなんだ。

補足: IaCの仕組みの信頼性は、IaCを利用せずに決してインフラを変更しないという自制心を持ち続けられるかにかかっている。みんな、こんな悲しい宣言を聞いたことがあるんじゃないかと思う。

緊急のP1インシデントが発生時ときにクラウドのウェブコンソールからこの設定を変更するけれど、設定変更は一時的なもので、必ず元に戻すよ。

Terraformの主な強みは、誰でも、任意のAPIを実行するためのTerraformプロバイダーを書けることだ。Terraformプロバイダー （「プラグイン」と呼ばれるときもある）は、Goで書かれたLinux／Mac／Windows向けのバイナリーファイルだ。プロバイダーはオフィシャルなTerraformレジストリに公開されると、自動的にマシンにインストールされるようになっている。もちろん、手動でプロバイダーを配布／インストールすることもできる。この方法を利用するのは、特にAPIエンドポイントがインターネット上で公開されていないような場合だ（内部アプリケーションやカスタムプライベートクラウドなど）。

現在、671のTerraformプロバイダーがパブリックレジストリで公開されていて、数えきれないほど多くの内部向けのプロバイダーがあるのも間違いない。すべてのクラウドプロバイダーはプロバイダーを用意していて、主要なSaaSプロバイダーもプロバイダーを用意している。また、ふざけたプロバイダーもいくつかあって、ピザを注文したり、Google ファイバー ケーブルを敷設したり、ToDo リストを作成したりするものなどもある。

このことが意味するのは、複数ベンダー、および複数コンポーネントにまたがる構成を単一のコードリポジトリで管理しながら、それらの依存関係を管理できるということだ。具体例を挙げると、Terraformを用いて、CAST AIのKubernetesクラスターを作成し、AWS上でS3バケットをセットアップ、Terraform Helmチャートプロバイダーを利用して既知のミドルウェアをインストール、Terraform Kubernetesプロバイダーを利用して、K8sのYAMLマニフェストファイルを書かずに、ビジアプリケーションプリをデプロイし、最後にパブリックDNSレコードを作成できるということだ。

もちろん、CAST AIのTerraformプロバイダーもあるよ。

HashiCorp社は実際のTerraformのみを開発保守しているけれど、プロバイダーはAPIオーナーによって書かれている。このことが意味するのは、プロバイダーはHCL（HashiCorp ConfiguratioLanguagege）に準拠するけれど、類似したベンダー間でセマンティクスを統一できていないということだ。

単一のベンダーのみ利用していれば、このことは問題にはならない。しかし、ある特定のサービスプロバイダーにロックインするのを良しとしない場合は、とても面倒なことになる。

すべてのクラウドサービスプロバイダーは、独自の非常に特別な「競争上の優位性」を示す名前を使用してリソースの名前付けをする必要があって、この傾向はTerraformプロバイダーにも根強く残っている。たとえば、各クラウドベンダーで仮想マシンは次のように呼ばれる:

• EC2 instance（AWSのEC2インスタンス）
• Compute Engine instance（GCPのCompute Engine instance）
• Virtual Machine（AzureのVirtual Machime）
• Droplet （DigitalOceanのDroplet）

各クラウドTerraformプロバイダーで仮想マシンを作成する際のスニペットはこのようになる。

  resource "aws_instance" "web" {
     instance_type = "t3.micro"
  }
                                       
  resource "azurerm_virtual_machine" "web" {
     location = "East US"
     vm_size = "Standard_DS1_v2"
  }
                                       
  resource "google_compute_instance" "web" {
     machine_type = "e2-medium"
     zone = "us-east4"
  }
                                       
  resource "digitalocean_droplet" "web" {
     region = "nyc2"
     size = "s-1vcpu-1gb"
  }

                        

同じパターンは、VPN、VPC、セキュリティグループなどのほかのリソースでも繰り返される。PostgreSQLのマネージドサービスのようなSaaSの領域まで掘り下げてみても、同じだ: RDS／Cloud SQL／Azure Database for PostgreSQLサーバーグループ／Databaseクラスターなど。

本当の名前がわかれば、クラウドサービスプロバイダー間の名づけの違いに惑わされなくなるんだ。

例に挙げたスニペットのVMインスタンス種別が同じクラウドプロバイダーの中でも必ずしも直感的ではないことにきっと気づいていることと思う。けれど、ベンダーをまたいだ名前付けはどうだろうか？t3.micro、Standard_DS1_v2、e2-medium、s-1vcpu-1gb。名前付けの差異の詳細については、このブログ投稿を読んでほしい。

各クラウドのセマンティクスを学習して、複雑なIaCを作成する。誰がそのための時間を確保できるというんだ？

これらの問題に対処するためにたち私達はTerraformプロバイダーを作成して公開し、ユーザーが複数クラウドにまたがる単一のKubernetesクラスターを作成できるようにした。これが例だ。VPC、セキュリティグループ、VPN、ディスク、ロードバランサーの詳細はすべて抽象化されている。 まずはお好みの単一のクラウドプロバイダーにマネージドのKubernetesをデプロイして、その後で準備ができたらマルチクラウド環境に拡張することもできるようにしてある。

また、CAST AIで作成されたクラスターには自己修復機能がある。たとえば、ロードバランサーやK8sノードがせっかちな若手のDevOpsエンジニアによってクラウドコンソールから誤って削除されたとする。そうした場合でも、Terraformを再実行しなくても、私たちのプラットフォームが自動的に復旧してくれるようになっている。最上位のリソースcastai_cluster情報のみがTerraformステートファイルに保存されるんだ。つまり、すべての依存関係はTerraformの外部で維持されているということだ。

また、同一のIaC gitリポジトリで、本番環境のCAST AIクラスターと、ほかのリソース設定とを一緒に管理できるようになる。

IaCとTerraformをもっと高度に活用したいなら、コードのマージリクエストのたびにマルチクラウドの開発環境用K8sクラスターを作成し、エンドツーエンドのアプリケーションテストを実行、マルチクラウドKubernetesクラスターを破棄するといった作業をわずか数分で行うことができる。開発環境としては手ごろな価格なんてもんじゃない。ありえないくらい安いんだ。そういうことを私たちはやっているんだ

ここまで読んでくれた皆さんには、CAST AIで上記のことをぜひ試してみてほしい。ここからサインアップできるし、Terraformのドキュメントはここにある。