Infrastructure as Code (IaC) とは?

Infrastructure-as-code (IaC) は、開発者と運用チームが、機械読み取り可能な定義ファイルを使用して、コンピューターのデータセンターを自動的に管理することを可能にする手法です。

IaC は、ソフトウェア定義された、あるいはプログラム可能なインフラストラクチャとも呼ばれ、物理的なハードウェア構成と構成ツールを排除して、繰り返し使用可能なデジタル構成ファイルを使用します。高水準の記述コーディング言語を使って IT インフラストラクチャのプロビジョニングを自動化し、サーバー、ストレージ、データベース接続などのインフラストラクチャ要素を手動で管理したりプロビジョニングしたりする必要性を排除します。IaC は、DevOps の重要なプラクティスであり、新しいソフトウェアアプリケーションの開発とデプロイメントにおいて、より合理的な一連のプロセスを可能にするものです。IaC は、インフラストラクチャの管理を「配置転換」する手段と言えます。つまり、デプロイメントパイプラインの最後にある手動ステップではなく、開発者や DevOps チームの管理下に置くことができるのです。

一見すると、Infrastructure-as-Code は新しいことを何ももたらしていないように見えるかもしれません。そのように見えるのは、従来は手作業だったもの (IT インフラストラクチャの構成) を変えて、デジタル化しただけだからです。しかし、この転換によって、IT 担当者が何十年にもわたって直面してきたいくつかの重要な問題が解決されることになるのです。

IT インフラストラクチャの管理の難しさ

IT インフラストラクチャの管理は、複雑で手間がかかるだけでなく、コストもかかります。プロセスの各ステージにおいて、エンジニアや保守技術者などが必要不可欠なタスクに対応できるようにしなければなりません。企業は、これらのエキスパートの給与のニーズを満たす必要があります。さらに、確実で適切な調整とリソース配置の必要性が、管理コストの増大を余儀なくさせます。

監視と可視性の問題も、同様に従来の構成における潜在的な問題です。従来のインフラストラクチャ構成は、複数の個人やチームに依存しているため、一貫性がなく、監視やパフォーマンスの最適化が多くの場合、非常に困難になっています。このような一貫性のなさは、誤ったパラメータが使用され深刻な結果を招く可能性のある設定ミスの問題につながる可能性もあります。設定ミスは、大勢の人々に影響を与え人々の注目を集めた、多くのシステム停止の原因とされてきました。

最後に、手動設定は、新しいサーバーのセットアップをシステム管理者に依存しているため、需要増加に対応するのに時間がかかるという問題があります。リソースの必要性が高まると、手動設定では効果的なスケーリングが妨げられ、企業が負荷の増加に対処することが難しくなります。また、バックアップサーバーを利用できない場合は、アプリケーションの可用性が損なわれます。

DevOps の課題

DevOps では、従来の設定手法で作業する際に、独自の問題が起こります。従来の管理では、構築プロセス中に設定ミスやその他の問題を特定して排除することはせず、実行時までこれらの問題が気づかれないことがほとんどです。また、実行時にこれらの問題に対処するために開発者のリソースを再配分しなければならないため、企業は、実質的には重要な障害に対処することなく、経験豊富で専門知識を持つスタッフを他の重要なタスクから引き抜くことを余儀なくされます。

さらに、新しく構成されたインフラストラクチャは、企業の既存の環境に適合するものでなければなりません。特に、クラウドは動的で常に変化する存在であるため、手動で設定すると、より広い環境という状況の中でセキュリティとコンプライアンスの問題が発生する可能性があります。

効果的な Infrastructure-as-code の実践は、従来のインフラストラクチャ構成に関連する多くの問題や非効率性に対する解決策をもたらします。IaC を利用することで、企業は以下のようなメリットを享受することができます。

スピードの向上

IaC では、スクリプトを実行するだけで、完全なインフラストラクチャを簡単、迅速に作成することができます。これは、環境に関係なく、ソフトウェア開発ライフサイクルのあらゆる段階を通じて可能となります。

IaC の価値・効果を示す図

信頼性の高い一貫性

人間の IT 担当者や運用チームが設定を行う場合、不一致が生じることは避けられません。しかし、IaC ファイルが主要な信頼できる情報源として存在する場合は、企業は構成データ管理ツールとポリシーを追加することで、正しい構成を必要な回数だけ一貫して展開することができます。

トラッキングと説明責任の向上

IaC ファイルの利点として見落とされがちなのが、あらゆる変更の明確な記録を維持することです。チームは、いつ、誰が (説明責任が問題になった場合)、どのような変更を行ったかを簡単に確認することができます。また、IaC はアクセス可能なリポジトリで以前のバージョンを維持するため、問題が発生した場合、開発者は以前のインスタンスに戻り、以前の環境を再度展開することができます。

最適な効率性

インフラストラクチャアーキテクチャの展開をコード化し自動化することで、開発ライフサイクル全体を通じて効率性と生産性を大幅に向上させることができます。複数のステージング環境において同時にテストを行うことができ、これらの環境は数分で作成、展開することができます。同時に、IaC では継続的インテグレーションと継続的デプロイの技術を簡単に取り入れることができます。

コストの削減

IaC の最大のメリットは、コスト削減と利益率の向上です。設定と展開を自動化することで、企業はハードウェア、スタッフ、トレーニング、管理に関連する多くの費用を削減し、経験豊富な IT 担当者はより価値の高いタスクにエネルギーを再び注力できるようになります。

これに、前述のスピード、一貫性、効率性を加味すると、IaC への投資をいかに迅速に回収できるかがより明確になります。

IaC は、DevOps がソースコードに使用するのと同じバージョニングを使用します。実際、DevOps では IaC を DevOps ツールチェーンにおける他のコード開発と同様に扱います。つまり、インフラストラクチャのコード変更は、DevOps の他のタスクと一緒に管理されます。

DevOps は、IaC の変更にポリシーを適用し、ServiceNow DevOps を使用して変更を自動化するなどして、変更の自動化されたトラッキングや承認を可能にすることもできます。IaC ではまた、DevOps が開発サイクルのどのステージでも本番環境と同じテスト環境を簡単に作成できるようにすることで、潜在的に重大な展開の問題を起こす可能性を低減します。IaC を使用することで、DevOps は一貫したプラクティスとツールを使用して効果的に連携し、アプリケーションとインフラストラクチャを迅速、そして確実に、需要に応じて拡張できる能力を備えることができるようになります。

CI/CD プロセスでは、Infrastructure as Code の制御が IT 運用担当者から開発者に移ります。これにより、DevOps チームはインフラストラクチャの変更をその他のコードと同様に扱い、DevOps、サイト信頼性エンジニアリング (SRE) ツール、製品に適用して、バリューストリーム全体を通じて監視を行うことができます。

IaC 戦略を最大限に活用するには、ベストプラクティスを特定して、それに従う必要があります。試行錯誤から得られたこれらの提案により、構成と展開に対する効果的な IaC アプローチが実現します。

仕様の文書化を避ける

インフラストラクチャの仕様に関する外部文書は、不正確で最新の状態が分からなくなりがちです。外部文書化の習慣をやめ、その代わりに、常に正確で利用可能な設定ファイル自体に仕様を記述するようにします。

コードが信頼できる唯一の情報源であることを認識する

前項で述べたように、インフラストラクチャの仕様を設定ファイルに書き込むことは、外部文書を使用するよりも望ましいことです。また、インフラストラクチャの仕様をコーディングした後は、インフラストラクチャ管理に関連するすべての事柄についての、信頼できる唯一の情報源としてその設定ファイルを参照するようにします。

徹底してテストを行う

物理的な構成と比較した場合のコードの価値・効果の 1 つは、コードをテストできることです。IaC テストツールを使用して、本番環境に移行する前に、構成にエラーや矛盾がないことを確認します。

すべてについてバージョン管理を行う

IaC は、開発に対する CI/CD アプローチと非常に相性が良いため、開発は猛烈なスピードで進む可能性があります。新しい変更が展開されるときは、古いバージョンをソースコントロールによって安全に利用できるようにしておきます。これにより、新しい展開で予期せぬ問題が発生した場合に、チームは以前のバージョンにアクセスして、再ロードすることができます。

ServiceNow と IaC

前述のとおり、設定ミスはインフラストラクチャの大きな課題です。セキュリティの不備や個人情報の流出、数百万人のユーザーに影響を与える大規模なシステム停止などの原因とされてきました。

2020 年、ServiceNow は Sweagle という会社を買収し、現在は DevOps Config として DevOps ポートフォリオの一部となっています。DevOps Config は、構成データを管理するための一元的な場所を提供するものです。これにより、IaC を使用する際に DevOps チームに残された次のような問題が解決されます。

  • 構成データに Access Control を適用し、許可されたユーザーのみに、IaC で使用する構成ファイルの変更と定義の権限を付与することができます。これにより、パスワードやその他の機密データを保護し、スタンドアロンの構成ツールで起こりうる変更を防止することができます。
  • ポリシーは、構成情報に適用することができます。例えば、アプリケーションのテスト用と本番用で異なるデータベースを使用することがよく行われます。内部テストと実運用へのリリースの間に、IaC でデータベース構成文字列が正しく変更されていることを、ポリシーを使用して検証することができます。
  • システムは、問題発生の原因となった以前の設定から学習することができます。人工知能と機械学習を適用して、問題が再発しないように新しいポリシーを作成することができます。
  • インフラストラクチャの構成を一元的に管理することで、単一のリポジトリによる監視が可能になります。構成を理解するために、Git のコードリポジトリ、ネットワーク設定ツール、その他のソースを探す必要がなく、すべて 1 つの場所から利用できます。また、以前の設定バージョンのスナップショットを保存しておくこともでき、後のトラブルシューティングに役立てることが可能です。

ビジネスに合わせて機能を拡張

企業全体で DevOps を有効活用できます。高速化によるリスクを取り除き、IT の運用と開発の間の摩擦を最小限に抑えます。

連絡先
Demo