Terraformに学ぶ、Infrastructure as Codeの導入と組織に起こる変化

企業のIT環境の多くが、クラウドへ移行しています。インフラ運用を効率化するため、Infrastructure as Code（IaC）^※1ツールの導入を検討する企業が増えてきました。しかし、単にツールを導入するだけでは、セルフサービスと自動化といったクラウドのメリットを最大限引き出すことはできません。ビジネスオーナー、開発者、セキュリティ担当者、システム運用者は、どのような変化を受け入れる必要があるのでしょうか。

Infrastructure as Code（IaC）：インフラの構成要素をコードで記述することにより、プロビジョニングの自動化やバージョン管理、構成の再利用を可能にする技術を指す。代表的なツールに、HashiCorp社のTerraformやAWSのCloud Formation、AzureのResource Managerテンプレート等が挙げられる。

ここでは「Terraformに学ぶ、IaCの導入と組織に起こる変化」と題した翻訳記事をお届けします。著者のKseniia Ryuma氏は、HashiCorp社のクラウドソリューションエンジニアであり、IaCを導入する組織の課題とそれに対するTerraformの役割や組織に起こる変化について、分かりやすく解説しています。

---

おかしいと思いませんか？地上では自動運転車が走り始めているのに、多くの企業では、情報システムのインフラ（サーバやネットワークなど）の変更は、依然としてチケットベースの手作業による運用で行われています。自動運転が実用化されているなら、ビジネスを支える情報システムのインフラも、自動化を本気で考えてみてもいいのではないでしょうか。

「ローマは一日にしてならず」と言いますが、セルフサービスのインフラを1日で構築することはできません。しかし、適切なリーダーシップや文化、そして手段を確立すれば可能です。「自動化されたセルフサービスインフラを確立する方法」について詳しく見ていく前に、まずは用語を定義しておきましょう。「セルフサービスインフラス」は、承認済のインフラのライブラリを使って、ユーザはインフラを簡単にプロビジョニングできます。そして、「自動化」では全てのプロビジョニングが管理・統制されていることが保証されます。もし、あなたの組織が、事前に承認され、テスト済のインフラを組み合わせたライブラリを既に使用していたとしても、必ずしもインフラがエンドツーエンドでセルフサービス化していることを意味するものではありません。

Terraformを例にして説明しましょう。誰でもオープンソース（OSS）のTerraformと公開されているTerraform Registryを利用できます^※2。HashiCorp社のTerraformは、世界中の企業で最も広く使われているクラウドプロビジョニングツールです。Terraformを使えば、幅広い範囲のリソース、つまりあらゆる環境（AWS、GCP、Azure、またはオンプレミス）におけるハードウェアやIaaS、PaaS、そしてSaaSサービスを管理できます。しかしながら、オープンソースのTerrarformは、この記事で言う「セルフサービス」の機能を備えていません。オープンソースのTerraformは小さなプロジェクトで使用するには適していますが、企業規模での使用には向いていません。下図を見てください。後述するように、オープンソースのTerraformでは赤色の部分の機能が制限されています。

※2 Terraform OSSは、こちらからダウンロードできる。また、Terraform Registryでは公開されているTerraformのプロバイダーやモジュールをダウンロードして利用できる。

今日に至るまで、多くの組織では、インフラ関連の工程は機能ごとにサイロ化されていました。

私たちは常にサイロを生み出す危険性があります。採用したインフラ技術の数が問題なのではありません。人々がそれらの技術をどうやって採用したかが問題なのです。
　―　Brian Dawson氏

ツールの標準が存在しないので、プロビジョニングされたインフラを監視できず、結果として余分なインフラや孤立したインフラが生まれ、ビジネスの視点では追加の出費が必要となります。組織が既にTerraform OSSまたはそれに類するIaCのツールを導入していると仮定しましょう。IaCはIT環境に多くの価値を提供しますが、見逃せない課題が存在します。

1．チームマネジメント　―　多くのIaCツールはCLI（コマンドライン）ベースで動作します。そのため、特定のインフラ作業だけを実施する利用者に対して、細かなロールベースアクセス制御（RBAC）を付与できません。現実には、担当者全員に組織全体のIaCを管理する全てのGitリポジトリへのアクセス権が付与されていることでしょう。加えて、開発者の大半がコンソールへのアクセス権（好きな時にログインして手作業で変更を加えることができます）を持つだけではなく、全てのシークレット（APIトークンやDBの認証情報、TLS証明書など）へのアクセス権を組織レベルで持っている企業もあるでしょう。このような運用には、セキュリティ上の懸念があります。

2．サービスガバナンスとポリシー　―　誰かがインフラに変更を実施した際に、どんなタグを設定したかを確かめるにはどうすればいいのでしょうか？どのように本番環境や開発環境のインスタンスのサイズ変更を監視すればいいでしょうか？そして、禁止されているはずのIAMアクションが実行できるインスタンスの作成を防ぐにはどうすればいいのでしょうか？ポリシーがないと、例えば、セキュリティグループのCIDRブロックを外部に向けて"0.0.0.0/0"とするインフラリソースを作成できてしまいます。また、プライベートのリソースをパブリックなインターネットに公開できてしまいます。よく考慮されたガードレールを設けておくことの効果、そしてどのようなインフラがプロビジョニングされるかを検証しておくことの重要性を理解いただけるでしょうか？

3．アドバンスドセキュリティ　―　多くの企業ではOktaやActive Directory、そしてSAMLといったID管理ツールを採用しています。シングルサインオン（SSO）の機能があれば、従業員のあらゆるアプリケーションやデバイスに対するアクセスを集中管理できます。SSOを採用すれば、ユーザの使用するアプリケーションの管理を一元化でき、アカウントおよびユーザ管理について説明責任を果たし、高度なセキュリティを実現できます。SSOと連携できるIaCツールはほとんどありません。この連携機能については、後述します。

4．モニタリング　―　CLIドリブンのワークフローでは、作成されるインフラの青写真を見られません。一元化されたプラットフォームでIaCが動作し、適切な監査ログが出力されなければ、組織が管理するインフラの重要なイベントを可視化できません。

標準化されたプラットフォームがなければ、IT環境の一貫性の欠如、プロビジョニング時間の長期化、手作業の介入、そしてエンドツーエンドでの自動化が困難である、といった問題が起こります。加えて、ロールベースアクセス制御（RBAC）の実現も困難であり、セキュリティ上の脆弱性を生み出すことにもつながります。Solarwind社の製品を使った米国の民間企業100社がセキュリティ侵害を受けたといわれるSolarwind社の悲劇により、ソフトウェアとハードウェアを閉じられた管理下に置くことの重要性が改めて認識されました。最後に、プロビジョニングを標準化していなければ、上記で述べたような企業全体の視点での管理は難しくなります。

・・・

セルフサービスのプロビジョニングに基づく標準化された手順を導入すれば、組織はITリソースの利用を最大化し、コストを削減し、エンドユーザーに権限を委譲しつつ、同時に強固なセキュリティを実現できます。最終的には、開発者が必要に応じてインフラをプロビジョニングする権限と、それに必要なアクセス権を提供できるでしょう。加えて、構築したリソースを監視し続けるには、一元管理と、標準化が必要不可欠です。これが、インフラを統制し、セキュリティやコンプライアンス、ガバナンスを点検し、運用のベストプラクティスを実現するための方法です。

新しい運用方法を適用する際には、システムではなく、新しい運用モデルに移行できるかどうかが重要です。つまり、新しい運用モデルに移行するには、組織全体にわたるカルチャーの変革が必要です。組織内の全てのチームを巻き込んだ連携を実現しなければ、大規模なアジリティを発揮できません。（チーム管理やガバナンス、アドバンスセキュリティ、モニタリング等の機能を持つ）Terraform Cloudプラットフォームは、標準的な手順とインフラ管理における全てのキーパーソンを束ねる「司令塔」になってくれます。

ビジネスラインリーダー　―　データを監視し、データに基づき意思決定します。監査証跡は、コンプライアンスに求められる透明性と保護を提供します。企業は、監査証跡を記録の照合や報告書、予算計画、ないしリスクマネジメントに利用できます。

ポリシーオーナー　―　単一のワークフローを用いることで、プロビジョニングを実施したのが誰であろうとも、セキュリティ・統制・監査に関するリスクを低減できます。セキュリティチームは、ポリシー外のインフラがプロビジョニングされることを防ぐ安全なサンドボックスを用意できます。このアプローチは、Terraformのプラットフォームによってプロビジョニングされた全てのインフラは、コンプライアンスを順守し、かつ統制されたものであることを保証します。

開発チーム　―　開発者にセルフサービスなインフラのプロビジョニングを認めることにより、インフラ運用担当者との間のボトルネックが解消し、開発者のアジリティが増加します。開発者はインフラをコードで表現できるので、インフラの管理に集中できます。Terraform Cloudプラットフォームは、Terraformを一貫性があり信頼できる環境で実行するように管理します。すなわち全てのソフトウェアの開発サイクルが、より効果的になり、チームの生産性を新しいレベルに引き上げます。

運用チーム　―　事前に定義したモジュールを使用することで、運用担当者はより多くのインフラ要求に対応でき、生産性が向上します。このモジュールは、小さくて再利用可能なTerraformのコンフィギュレーションファイル群のことで、関連する複数のリソースを単一のものとして管理できます。モジュール化のアプローチを採用することで、インフラを再利用可能にします。

エンドユーザー　―　プロビジョニングを自動化できます。組織がServiceNow^※3と連携することで、エンドユーザーは、Terraformのカタログからリソースを選択して、プロビジョニングできるようになります。ユーザは、Terraformのコンフィギュレーションファイルの仕様を理解する必要がなく、VPCや新しいインスタンス、またはアプリケーションを要求し、立ち上げられます。

※3 ServiceNow社が提供する組織のワークフローを統合するためのIT管理ツール。Terraformの有償版は、ServiceNowとの連携機能を提供している。
参考：Setup Instructions - ServiceNow Service Catalog Integration - Terraform Cloud and Terraform Enterprise - Terraform by HashiCorp

最後に、Terraformの管理者は、プラットフォームにログインして全てのコミットやバージョン、そしてインフラの変更をユーザフレンドリーなインターフェース（GUI画面）を通して確認できます。

Terraformのプラットフォームは、人とプロセスのバランスが作業を促進するという方法論にフォーカスしています。運用担当者はいつでも必要な時にアクセスできる必要があります。この記事で説明したようなセルフサービスインフラを使えば、基盤ITサービスチームに依頼するよりも早く作業を終えられます。ビジネスに責任を持つ方に伺います。競争上の優位性やセキュリティリスクの低減、そして売り上げの増加はあなたにとって重要事項でしょうか？答えが「yes」なら、変化を受け入れ、自動化への旅路を歩き始めましょう。