過去50年にわたり、ネットワークはさまざまな接続の時代（クライアント・サーバーなど）を経て変化し、プラットフォームやプロセス、手順も、その時々のトレンドや新たなイノベーションに合わせて進化してきた。
ネットワークアーキテクチャの構成要素をめぐる最新のトレンドが、Infrastructure as Code（IaC）という考え方だ。
IaCは、ITネットワークの構造と、データストレージ容量および関連機能を定義・プロビジョニングするための記述モデルである。
これにより、ユーザーはサーバー構成やロードバランサー、その他のソフトウェア管理層を定義できる。アプリケーション開発で一般的に使われているわけではないが、IaCは、ユーザーが依存するコンピューティングの下位基盤層に適用される。
接続トポロジーを定義する
形状と機能の観点から見ると、Infrastructure as Codeは通常、専用のソフトウェア言語で記述されたテキストファイルの形を取り、Terraform、AWSのCloudFormationなどがある。ケーブルや配線で構築されたネットワークとは異なり、このタイプのネットワークは、接続トポロジーを定義する記述モデルのソースコードファイルから構築される。
IaCがクラウドの基盤に定着しつつある今、企業やITチームは、日々運用する構造やシステムにIaCがもたらす影響に備える必要がある。
関連記事：AIとMLでDevOpsを自動化する
DevOpsと本番環境の一貫性への影響
IaCは、インフラの構築を自動化し、新しい環境を展開するとともに、作成したものをすべて追跡するための生きたドキュメントとして機能する仕組みを必要とする、クラウド中心のITチームに適している。開発、ステージング、テスト、本番を含む本番環境のあらゆるレベルにまたがって機能するため、こうしたニーズの多く、あるいはすべてに応えられる。
本番環境にデプロイする前にコードの変更をテストするには、複数の環境が役立つ。しかし、開発から本番まで環境間の一貫性を保つことは大きな懸念事項だと、Yoni Farin氏（CoralogixのCTO兼共同創業者）は指摘する。同社は、ストレージやインデックス作成に依存せず、リアルタイムのインサイトと長期的なトレンド分析を提供するステートフルストリーミング分析プラットフォームで知られている。
「IaCでは、各環境を手作業で作成して一貫性を期待するのではなく、コードベースで変更を加え、その変更を各環境に適用します」とFarin氏は語る。「つまり、エンジニアがコードに従う限り、環境の完全な一貫性を保てるということです」
コード機能のドリフトによる変化
Farin氏は、一貫した変更を実現するには、コード機能のドリフトが従来から常に発生していることを認識しなければならないと説明する。異なる本番デプロイゾーンやシステム固有の複雑さ、単純なヒューマンエラーによって、変更が稼働中の本番環境に現れる可能性がある。
「しかしIaCなら、ある環境で変更が機能し、環境間の一貫性が保たれていれば、次の環境でも同じ変更が機能するはずだと分かります」とFarin氏は語る。「一貫した変更は信頼性を高め、エラー率を下げ、それによってデプロイの頻度を高めます」
ローコード／ノーコード開発の普及や、いわゆる市民開発者、市民データサイエンティストなどの登場を考えれば、市民ネットワークエンジニアが登場しないと考える理由はないだろう。システム構造の挙動に影響を及ぼし得る変更が、より多くの方向からもたらされるようになる中、すべてのサービスと、その基盤となるインフラ全体を可視化する方法が必要だ。
関連記事：ローコードでネットワーク自動化を実現する
不可欠な可視化手段としてのIaC
CoralogixのFarin氏は、IaCがサービスとそのインフラの可視化手段になり得ると提案する。
「ある時点で、誰かがクラウドアーキテクチャについて、『では、何を使っているのですか？』という単純な質問をするでしょう」とFarin氏は語る。「これは本来、簡単な質問のはずですが、残念ながらアーキテクチャが拡張するにつれて、答えるのが難しくなります。
「IaCによってこの可視性を実現できます。すべての変更はコードベースを経由するはずだからです。コードを見れば、アーキテクチャがどのように組み合わさっているかを理解できます。これは、設計上つねに最新の状態に保たれる生きたドキュメントとして機能します」
このコードは、例えばterraform graphsを使ってdot図を生成するためにスキャンすることもできる。これにより、一連の図やワークフロー、その他の可視化を作成し、インフラに関する意思決定を文書化・追跡するプロセスの大部分を自動化できる。
ここでの目的は、再利用可能なコードモジュールを把握できるようにすることにある。非常に高いスキルと自制心、そして目的への献身を備えたDevOpsチームであっても、可能な場面でコードを再利用できればメリットを得られる。
クラウド開発では、ITチームが同じ、あるいは似たタスクを何度も実行するために、ユーザーインターフェースをクリックし続けることが多い。しかし、これは貴重なチームの時間を使う生産的でも費用対効果の高い方法ではない。代わりに、こうしたクリック操作の自動化を目指すべきだ。
「IaCにより、DevOpsチームはデータベースやサーバーレスインフラ、サーバーなどのクラウドリソースを生成するコードモジュールを作成できます」とFarin氏は語る。「こうしたモジュールは、本来なら単調な作業になるタスクの自動化に適しています」
ライフサイクル管理の維持を目指して今後取り組む上で、IaCから得られるものはさらにある。
クラウドの解体を分解する
「クラウドインフラについて語るとき、すべてを解体する段階で何が必要になるかを考える人はほとんどいません」とFarin氏は語る。「ライフサイクル管理は複雑な取り組みです。ほかの機能開発が優先されて後回しにされるため、そもそも実施されないか、プロジェクトの途中で付け加えられるのが普通です。
「特に1つのアカウントに複数の製品がある場合、クラウドインフラを解体するのは容易ではありません。エラーや処理速度の低下を避けるには、特定のリソースを正しい順番で一つずつ選び、削除していく必要があります」
しかしIaCを使えば、ITチームは解体作業を1つのコマンドにまとめられる。Farin氏とチームは、ここでterraformを使って「terraform destroy」 コマンドを実行する例を挙げている。このコマンドにより、特定のモジュールに関連するインフラをすべて解体できる。
「つまり、同じクラウドアカウントに複数のプロジェクトがあっても、コンポーネントを正しい順番で、完全に自動化された方法で、狙いどおりに削除できます」とFarin氏は語る。「これにより、スムーズな解体が実現するだけでなく、自分たちのインフラと並行して存在する可能性のある他のプロジェクトのインフラに影響を与えないことも保証されます」
可観測性を実現する能力
最後に、IaCはより高度な可観測性を実現し、システムやインフラの監視・管理をより適切に制御できるようにする。
「インフラをコードとして実行する場合、可観測性のルールをそのコード内で宣言できなければなりません」とFarin氏は語る。「これにより、システムがどのように機能するかだけでなく、どのように監視されるかも記述できます。
「運用ルールをコード内に組み込むことは、インフラを拡張・管理するための非常に強力な仕組みです」
Infrastructure as Codeの将来は、間違いなく明るい。このネットワーク基盤層へのアプローチには多くの支持があり、クラウドの設定ミスをはるかに簡単に探せるため、IaCは魅力的なセキュリティ制御も提供する。
ここで紹介した理由やその他多くの要因から、IaCは今後も、大企業や成長企業にとって魅力的なインフラソリューションとして普及し続ける可能性が高い。