NetOps向けInfrastructure as Codeとは？

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

DevOpsのアプローチが垣根を越えてネットワーク運用に浸透するにつれ、新たな用語も持ち込まれます。こうした俗語は、初めて耳にするNetOps担当者を混乱させるだけでなく、その手法の導入を迫られているIT部門の経営幹部を困惑させることもあります。

その1つが、Infrastructure as Codeという考え方です。開発者の世界では、インフラストラクチャとは主に、アプリケーションのデプロイやスケーリングに使用するプラットフォーム、サーバー、コンテナシステムを指します。つまり、インフラストラクチャの中心はコンピューティングです。

壁の向こう側には、コンピューティングに加えて、ストレージ、セキュリティ、ネットワークまでを網羅する、より広範で堅牢なインフラストラクチャがあります。結局のところ、4つの運用領域があり、継続的デプロイを実現し、IT部門やビジネス部門のリーダーがデジタルトランスフォーメーションに期待する最適化を可能にするには、そのすべてが連携して稼働しなければなりません。つまり、Infrastructure as Codeが対象とするシステム、デバイス、サービスの範囲は、開発環境よりも本番環境のほうがはるかに広くなります。一般に、アプリをデプロイすると、4つの運用領域それぞれのインフラストラクチャに何らかの変更が加わります。そのため、本番環境でのInfrastructure as Codeはやや複雑になりますが、効率とスピードの向上により大きな効果をもたらします。

これは、自動化によって引き継ぎ間の待ち時間をなくせるためです。こうした待ち時間は、デプロイの非効率を招く原因になりがちで、特に手動プロセスが休暇や病欠、昼休みに重なる場合に顕著です。

これは直喩です

Infrastructure as Codeは直喩です。つまり、少なくとも現時点では、ネットワークやアプリケーションサービスのシステムを、構築してからデプロイするコードに実際に変えたいわけではありません。ほとんどの企業にとって、それは無謀であり、企業ネットワークの安定性と信頼性を損なうことになります。一方で、構成やプロファイルを、それらが稼働するシステムから分離できる仕組みのメリットは活用したいと考えています。

つまり、構成、ポリシー、プロファイルを、それらのデプロイ先であるハードウェアやソフトウェアから分離するということです。

このようにまとめられた構成、ポリシー、プロファイルは「デプロイメントアーティファクト」と見なされ、コードと同様に扱うことができます。つまり、リポジトリでの保存と管理、バージョン管理、レビューが可能です。開発者がリポジトリ（Githubなど）との間でコードをプル、クローン、コミットするのと同じ方法で、これらもプル、クローン、コミットできます。

「自動化アーティファクト」も含める必要があります。これは、選択した自動化ツールキットで使用する自動化タスクを記述したスクリプトと関連ファイルです。Ansibleならプレイブック、Chefならレシピ、Puppetならマニフェストです。単純なPythonスクリプトの場合もあります。

BIG-IPをはじめ、増加しつつあるネットワーク上でホストされるシステムでは、より複雑な構成や標準化された構成を詳細に記述できるテンプレート（iApp）も自動化アーティファクトに含まれます。テンプレートを使用すると、コアツールセットではまだサポートされていない可能性があるオプションやアプリケーションサービスにも対応できるため、有用です。

デプロイメントアーティファクトと自動化アーティファクトを合わせた一連の成果物を「Infrastructure as Code」と呼びます。システムをプロビジョニングした後、そのシステムに対して自動化プロセスを実行し、必要に応じて構成できることを前提としています。

ネットワークサービスとアプリケーションサービスにアプリケーション単位のアプローチを採用し、Infrastructure as Codeのアプローチと組み合わせることで、頻繁なデプロイに伴うリスクを大幅に軽減できます。構成を分離し、その影響を単一のシステム内に限定することで、デプロイの失敗による影響を実質的に排除できます。その結果、ビジネスニーズやユーザーの要求により適合した、アプリケーション単位のスケジュールを採用しやすくなります。

クラウド志向の組織では、Infrastructure as Codeのアプローチを採用することで、データセンターからクラウド、またはクラウド間の移行に伴う負担を軽減できます。構成がシステムから分離されているため、別の場所にある同様のシステムにも展開できると考えられます。

Infrastructure as Codeのアプローチへの移行に取り組むべき十分な理由は数多くあり、移行しない積極的な理由はほとんどありません。Infrastructure as Codeは、マルチクラウドかつアプリ主導のデジタル経済で組織が成功するために必要な、アジャイルなネットワークを実現するうえで、特に有効な方法の1つです。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事