Infrastructure as Codeとは？

IaCが重要である理由として、まずインフラのプロビジョニングを簡単かつ迅速に行えること、そして拡張性に優れていることが挙げられます。これを理解するために、インフラ管理の仕組みを見ていきましょう。

これまで開発者やテスト担当者などのインフラ利用者は、インフラリソースのプロビジョニングが必要になると、チケットを作成するか、メールでリクエストを送信していました。そして、IT運用チームがキュー内のチケットを確認して記録し、要求されたリソースをそれぞれ手作業で割り当てるというやり方です。確かに時間はかかるものの、ほとんどの組織では管理対象のインフラが少なかったため、このプロセスで十分でした。企業のデータセンターで何年もの間1台の仮想マシンのみが使われていたり、環境内のインフラ設定やその他の処理を手作業で行うといったことが珍しくなかったのです。

今日のインフラは、自動化ツールやAPI主導のクラウドインフラのおかげで、数カ月や数年ではなく、数日または数週間でリソースをプロビジョニングでき、以前に比べはるかに動的です。ピーク時や季節に合わせてインフラをスケールアップし、需要が通常のレベルに戻ったらそれをスケールダウンするといったこともできます。このような弾力性は、インフラを手作業で管理していたのではまず実現不可能です。必要に合わせてワークロードの容量を増減させるのに、毎日何千ものチケットを送信して、管理者がリクエストを処理するまで待たなければならないでしょう。

IaCでは、手作業による操作を自動でインフラをプロビジョニングして設定できるインターフェイスに置き換えることで、この問題を解決します。たとえば、ワークロードのピーク時にスクリプトを実行して1,000台のマシンをスピンアップし、需要が減少したらスクリプトを再実行してマシンをスピンダウンする、といったことができます。また、DevOpsチームはこのアプローチを活用して、サーバーの作成、オペレーティングシステムの導入、データストレージの設定、その他の必要なインフラコンポーネントの設定を、オンデマンドで行うこともできます。

より迅速にアプリケーションを構築して導入し、すばやく顧客に価値を提供することがますます求められる今日、IaCはほとんどの企業にとって重要なものになっています。

IaCには次のようなさまざまなメリットがあります。

• スピードと効率が向上：ネットワーク、本番環境、仮想サーバー、データベースなど、インフラアーキテクチャ全体のプロビジョニングと設定を自動化することで、より信頼性の高い開発環境、テスト環境、ステージング環境を迅速に構築できるようになります。
• ドキュメンテーションの強化：インフラを記述したコードにはそのインフラがどのようにプロビジョニングされるべきかの記述も含まれるため、インフラに関する知識を持っている従業員が会社を退職しても心配ありません。さらに、必要に応じてインフラのコードをバージョン管理して、サーバー構成の変更をすべて文書化し、追跡、管理、復元することもできます。
• より柔軟な拡張性：IaCでは既存のインフラにリソースを簡単に追加できるため、ワークロードのピーク時にすばやくスケールアップし、需要の減少に合わせてスケールダウンすることができます。
• 再利用性が向上：DevOpsチームでは開発やステージング、本番で同じ組み合わせのリソースをプロビジョニングする必要があることが少なくありません。IaCスクリプトは複数の環境で再利用でき、新たなインフラをゼロから構築する手間が省けます。
• コラボレーションの効率化：コードのバージョン管理を行うことで、複数のユーザーがインフラの各部分について作業する場合でも、お互いに直接やりとりすることなく作業を進めることができます。
• 人的ミスの低減：IaCでは常に同じ方法で構成が適用されるため、コーディングエラーが紛れ込む心配がなく、IT環境全体の一貫性が保たれます。
• ディザスタリカバリーの強化：災害発生後にシステムを復旧させる際、異なる場所にある複数のシステムを同じコードを実行するだけで迅速にオンラインに戻すことができます。あるいは、異なる場所から複数の環境を同時にプロビジョニングし、デリバリーを継続させつつ、より優れたフェイルオーバーサービスを提供することもできます。
• コスト削減：インフラコンポーネントを手作業で設定することで発生するコストが不要になります。また、ほとんどのIaCプラットフォームは使用したリソースに対してのみ課金されるため、長期的に見て費用対効果が高いといえます。
• カスタマーエクスペリエンスの改善：IaCでは、インフラコードのレビュー、テスト、バージョン管理について、ソースコードの管理に使用されるものと同様の十分に確立された手法が適用されるため、エラーが少なく、パフォーマンスが高く、ダウンタイムも短くて済みます。
  

Mutable(可変)とImmutable(イミュータブル/不変)は、2つの異なるタイプのインフラ環境です。「可変」とは、たとえば新しいサーバーに対応するために、プロビジョニング後にインフラを変更できることを意味します。一方、「イミュータブル/不変」はインフラを変更できません。

可変インフラの主な利点は、既存のサーバーを特定のアプリケーションや開発ニーズに合わせてカスタマイズできることです。そのため、新しいサーバーを構築することなく、各ユーザーのニーズに合ったインフラを実現することができます。

しかし、この「変更できる」という特性には、いくつかの重大な欠点があります。各サーバーがそれぞれ独自の設定を持つため、サーバーの診断や管理が困難になってしまうのです。これを「構成ドリフト」と呼びます。また、一般にサーバーへの変更は文書化されないため、バージョンの追跡ができず、技術的な問題の発見や再現が容易ではありません。

イミュータブルな環境はより厳格であり、インフラのコンポーネントは必ず特定の仕様に従わなければなりません。一旦インフラが構築されたら、必要に応じて変更するといったことはできず、サーバーを変更する必要がある場合は最新の要件に基づいて新しいインフラを構築し、古いインフラを削除する必要があります。これにより構成ドリフトの問題が実質的に解消され、技術的な問題の特定と解決が容易になり、開発から本番までのテストの一貫性も確保されます。

DevOpsチームにとって、イミュータブルなIaCはますます重要なものとなっています。イミュータブルインフラとIaCの概念を組み合わせることで、環境の整合性が保たれ、DevOpsプロセスがさらに加速するとともに、デリバリーパイプラインの遅延が低減し、チームはインフラの管理に時間を費やすことなくイノベーションに集中することができるようになります。

IaCは、HashiCorpのTerraform、Red HatのAnsibleやHelm、およびChef、Puppet、SaltStackなどのオープンソースツールによって、広くサポートされています。オープンソースのIaCツールは、ユーザーが複数のクラウドベンダー間でインフラのプロビジョニングや管理を行えるようにコーディング言語を使用しており、他のオープンソースソリューションとも互換性があります。一方、大手クラウドベンダーは、たとえばAWS Cloud用のAWS CloudFormation、Microsoft Azure用のAzure Resource Managerなどのように、クラウドコンピューティングエコシステムの一部として独自のIaCコードツールを組み込んでいます。これらのツールは、それぞれのクラウドプラットフォームに特化して設計されているという利点がありますが、クローズドアプローチであるため、ユーザーはベンダーロックインに陥る可能性があります。

IaCツールの仕組みはツールごとにそれぞれ異なりますが、どのツールもインフラの自動化には、宣言型または命令型のうちのいずれかのアプローチを採用しています。IaCツールを選ぶ際は、この2つのプログラミング言語の表現方法の違いを理解していることが重要になります。

宣言型のアプローチでは、ユーザーはリソースと必要なプロパティのリストを指定し、プロビジョニングされるインフラがどのようなものになるかを「宣言」します。その後、IaCツールによって、すべてのインフラコンポーネントがインストールされ、設定されて、コードのバージョン管理が行われます。一方、命令型のアプローチでは、ユーザーはIaCに実行させたいコマンドのリストを指定し、それによりインフラが段階的にプロビジョニングされます。簡単に言えば、宣言型プログラミングでは、ユーザーはどのようなインフラリソースを使用したいかを伝え、命令型プログラミングでは、インフラリソースをどのように作成したいかを伝えます。

どちらのアプローチを使用しても目的のインフラを作成できますが、考慮すべき違いがいくつかあります。その違いを明確にするため、「空港までタクシーで行く」という例を使って、それぞれのアプローチがどのように指示を処理するかを説明してみます。宣言型の指示では、運転手に「午前11時までに空港に連れて行ってください」と伝えます。ここでは、求める結果を述べており、時間どおりに到着するために最適なルートや速度、その他の要素はタクシーの運転手が決めます。

これに対して命令型の指示では、運転手に「午前11時までに空港に到着する方法」について明確な指示を与えます。たとえば、「午前10時15分に迎えに来て、角を左に曲がって高速道路に乗って、時速約100キロで...」といった具合です。どちらのアプローチでも必要な目的地に到着できますが、2番目のアプローチでは、道路の迂回や高速道路での交通事故など、運転手が予期せぬ障害に遭遇した場合に対応の余地があまりありません。宣言型と命令型の指示は、IaCでも同じように機能します。

宣言型のアプローチでは、目的のインフラをプロビジョニングする際のあらゆる複雑さをツールが処理します。しかし、なぜそのように行われたのかについては、ツールの管理者に相談しないとわからないでしょう。命令型のアプローチでは、インフラのプロビジョニング方法をより細かく制御できますが、開発者がより多くの作業を行う必要があります。また、指示が明確である分、いずれかのステップで障害が発生した場合は、中断して解決策を考えなければならず、大規模な管理は難しいといえるでしょう。「ベストな」選択は、記述するコードの量や、将来的にインフラを更新する可能性、クラウドサービスへ変更を加える方法をどの程度制御する必要があるかなど、複数の要因によって変わってきます。

Terraformは、人気の高いオープンソースのクラウド非依存型IaCツールです。宣言型プログラミング言語であるHCL(HashiCorp Configuration Language)と呼ばれる高レベルの構成言語を使用して、アプリケーションを実行するためのインフラを定義し、プロビジョニングを行います。

Terraformは基本的に、インフラの「最終状態」を記述したコードを読み取り、リストされたリソースとそれらの相互関係を示すグラフを作成することで機能します。そして、そのグラフとクラウド内のリソースを比較し、クラウドに行う変更とその状態に達するための順序についてまとめた計画を生成して、その計画を実行し、インフラをプロビジョニングします。

Terraformは次のような理由から開発者に人気があります。

• オープンソースである。Terraformは、コントリビューターや組織から成る大規模なコミュニティに支えられており、Microsoft Azure、AWS、Google Cloud Platform、Kubernetesなど、ほぼすべての主要なクラウドプロバイダーやサービスで利用できるプラグイン、拡張機能、専門的なサポートが提供され、定期的に改良されています。
• プラットフォームに依存しない。AWS CloudFormationやAzure Resource Managerなどの特定のクラウドプロバイダーでのみ使用するように設計されたツールとは異なり、Terraformはどのクラウドサービスプロバイダーでも使用することができます。
• イミュータブルインフラをプロビジョニングする。上述したように、DevOpsにとってイミュータブルインフラはますます重要なものになっています。Terraformでは、環境に変更が加えられるたびに、現行の構成を変更を反映した新しい構成と置き換えて、インフラを再度プロビジョニングし直します。そして以前の構成をバージョンとして保持し、必要に応じてロールバックすることができます。
  

Terraformのコアワークフローには3つのステップがあります。1人で作業する場合も、チームで協力して作業する場合も、ワークフローは同じですが、複数での作業では各ステップに追加のプラクティスが生じます。

ステップ1：記述。最初のステップは、Infrastructure as Codeの記述です。チームで共同作業する場合も、あたかも自分1人で作業しているかのように、好みのエディターでTerraformの設定を変更できます。ただし、お互いの作業を上書きしないように、各自が変更内容をバージョン管理ブランチに保存する必要があります。チームメンバーは計画を繰り返し実行して、構文エラーの特定や構成のテストを行い、フィードバックループを作成します。

ステップ2：計画。「記述」ステップのフィードバックループで実行可能な変更が生じたら、チームメンバーが互いの作業をレビューし、コードを個人の作業ブランチから共有チームブランチにマージする際に問題を引き起こす可能性のある変更が持ち込まれないようにします。また、変更をすぐにマージするか、変更によってサービスが中断する可能性がある場合はメンテナンスの時間枠が決まるまでプルリクエストのマージを遅らせるか、決めることができます。

ステップ3：適用。プルリクエストが承認されマージされた後、共有チームブランチに対して実行される最終的な計画を再確認します。チームはこの時点で、サービス中断のリスクや誰に通知する必要があるかなど、変更の適用に伴う潜在的な影響を評価します。変更の適用と同時進行で状況を注意深く監視していくことにすることもできます。

チームでの作業の場合、このコアワークフローは各変更に対して繰り返して行われ、1日または1週間に数回発生する可能性があるものです。

Terraformでのインフラのプロビジョニングには、ベストプラクティスが多数あります。そのいくつかをここでご紹介します。

• モジュールを適度に使用する。モジュールとは、一連の関連リソースが含まれたコンテナです。「ルート」モジュールに加え、事前設定したロードバランサーやKubernetesクラスターなど、さまざまな機能をモジュールを使って組み込むことができます。独自にモジュールを作成する代わりに、Terraformの公式モジュールを使用したり、それを変更したりすることで、時間と労力を節約できますが、インフラに追加するモジュールが多くなりすぎると、設定が複雑になり、コードの実行が遅くなったり、デバッグが難しくなるなどの問題が起こる場合があります。 
• 複数のワークスペースを使用する。1つのTerraformワークスペースですべてを管理するのではなく、環境を開発、ステージング、本番の領域に分けて管理します。小規模なワークスペースは管理しやすく、特定のチームに委任してワークロードを共有することもできます。
• システム状態をバックアップする。Terraformでは、インフラのリソースやメタデータを追跡する「ステートファイル」を使用します。このファイルが失われると、デプロイしたリソースやそれらのリソースへの到達方法がわからなくなるため、アクティブな環境ごとに常にステートファイルをバックアップしておくことが重要です。
• 常に最新のバージョンを使用する。Terraformの開発コミュニティの活動は非常に活発で、新機能を頻繁にリリースしています。そのため、それらを常に把握して、アップグレードを管理しやすい状態にしておくことをおすすめします。一度に複数のメジャーリリースをスキップして追いつこうとすると、アップグレードが必要以上に複雑になることがあります。
  

今後IaCは、おそらくコンピューティングリソースのプロビジョニング、管理、オーケストレーションの標準となっていくでしょう。ハードウェアを調達してインストールし、設定を行って、構成管理ツールで新しい環境に統合するという従来のアプローチは、柔軟性や応答性に優れたインフラを必要とする企業にとって、もはや実用的とは言えません。物理的なハードウェア管理の問題はクラウドネイティブな開発や仮想化によって解消されました。次は、IaCが、開発者が必要に応じてインフラのプロビジョニングを自動化するための支援をしていく番です。IaCは市場投入までの時間を短縮し、コストを削減して、ROIを向上させることができ、すでにDevOpsに欠かせない要素として位置付けられています。

IaCを使用することで、組織のインフラのプロビジョニングプロセスとライフサイクルが高速化し、開発環境全体の一貫性が保たれます。これにより、ITチームはより価値の高い活動に注力できるようになります。IaCは、スピードと拡張性に優れたデリバリーを必要とする組織に対し、現在そして将来にわたり、そのための基盤を提供します。