次の方法で共有

コードとしてのインフラストラクチャを使用するための推奨事項

  • [アーティクル]

Azure Well-Architected フレームワークのオペレーショナル エクセレンスに関するチェックリストの次の推奨事項を対象とします。

OE:05 標準化されたコードとしてのインフラストラクチャ (IaC) アプローチを使用して、リソースとその構成を準備します。 他のコードと同様、一貫したスタイル、適切なモジュール化、品質保証を使用して IaC を設計します。 可能な場合は、宣言型アプローチを優先します。

このガイドでは、IaC をインフラストラクチャ デプロイの標準として使用するための推奨事項について説明します。 IaC を使用すると、インフラストラクチャのデプロイと管理を既存のソフトウェア開発プラクティスに統合できます。 これによりワークロードのすべてのコンポーネントに対して、一貫した標準的な開発およびデプロイ手法が提供されます。 手動デプロイに依存していると、ワークロードは、一貫性が損なわれ安全でない設計になる可能性がある、というリスクにさらされます。

定義

相談 定義
宣言型ツール デプロイの終了状態を定義するツールのカテゴリ。定義された終了状態に合わせて、システムに依存してリソースのデプロイ方法を決定します。
イミュータブル インフラストラクチャ デプロイのたびに新しい構成を実行する新しいインフラストラクチャに置き換えられることが想定されたインフラストラクチャ。 インプレースで変更できません。
命令型ツール 目的の終了状態になる実行ステップを一覧表示するツールのカテゴリ。
モジュール リソース グループを分割して複雑なデプロイを簡略化するための抽象化の単位。
変更可能なインフラストラクチャ インプレースで変更されることが想定されたインフラストラクチャ。 デプロイによって、新しいインフラストラクチャに置き換えられるのではなく、インフラストラクチャの構成が変更されます。

主要な設計戦略

サプライ チェーンおよびツールとプロセスの標準化に関するガイドで説明したように、インフラストラクチャの変更 (構成の変更を含む) をコードでのみデプロイする、という厳格なポリシーが必要です。 IaC のデプロイは、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを使用して行う必要があります。 これらのポリシーを採用することで、すべての IaC のデプロイ プロセスで一貫性が確保され、環境間の構成ドリフトのリスクを最小限に抑えられるほか、環境間のインフラストラクチャの一貫性も確保されます。 さらに、スタイル ガイドで IaC の開発とデプロイのツールおよびプロセスを標準化する必要もあります。 スタイル ガイドの推奨事項は次のとおりです。

命令型ツールよりも宣言型ツールを優先する

宣言型ツールとそれに関連するファイルは、命令型ツールよりも、IaC をデプロイおよび管理するための総合的な選択肢として優れています。 宣言型ツールでは、定義ファイルにシンプルな構文が使用され、デプロイ終了後の環境の必要な状態のみが定義されます。 命令型ツールでは、必要な終了状態に到達するには必要な手順を定義する必要があるため、ファイルが宣言型ファイルよりもはるかに複雑になる可能性があります。 宣言型定義ファイルは、デプロイ スクリプトなど、時間の経過とともに蓄積される命令型コードを維持するという技術的負債を減らすのにも役立ちます。

ネイティブおよび業界標準のツールを使用する

クラウド プラットフォームのネイティブ ツールや、プラットフォームにネイティブに統合された業界で認められている他のツールを使用します。 クラウド プラットフォームには、IaC のデプロイを容易かつシンプルにデプロイできるようにするためのツールが用意されています。 独自のソリューションを開発するのではなく、これらのツールや、ネイティブに統合された Terraform などの他のサード パーティ製ツールを活用しましょう。 ネイティブ ツールはプラットフォームでサポートされ、ほとんどのニーズに対応する機能が組み込まれています。 これらはプラットフォーム プロバイダーによって継続的に更新されるため、プラットフォームの進化に合わせて便利になっていきます。

Note

クラウド プロバイダーやサード パーティの開発者によってツールや API が更新されると、ワークロードで最新バージョンを使用するときに予期せぬ問題が発生するリスクがあることに注意してください。 新しいバージョンのツールと API は、採用する前に十分にテストしてください。 同様に、デプロイ コードでツールまたは API を呼び出すとき、"latest" フラグを使用するのは避けてください。 ワークロードに対して最新かつ適切な既知のバージョンを呼び出すことを意識する必要があります。

タスクに適したツールを使用する

特定のタスクおよびインフラストラクチャの種類に適したツールを使用します。 インフラストラクチャのライフサイクルには、デプロイ以外のタスクが複数関係しています。 たとえば、構成を適用して維持する必要があります。また、Bicep などのデプロイのスクリプト作成に使用するツールは、一部の管理操作には最適とはいえない可能性もあります。

同様に、さまざまなインフラストラクチャの種類に Desired State Configuration (DSC) を適用するには、さまざまなツールが必要になる場合があります。 たとえば、VM の DSC 管理を目的とした Ansible などの特別なツールがあります。一方、Flux は、Kubernetes クラスターでの DSC 管理に適しています。 サービスとしてのプラットフォーム (PaaS) サービスには、IaC で処理できる構成管理用のツール (Azure App Configuration など) が各種用意されている場合があります。 サービスとしてのソフトウェア (SaaS) サービスは、プラットフォームによってより厳しく制御されるため、より大きな制限を受ける可能性があります。

インフラストラクチャのタスクと種類のうち、IaC プラクティスの対象となるものすべてについて考え、必要なジョブを実行し、開発と管理のプラクティスに統合できるツールを標準化します。

複数の環境をサポートする

さまざまな環境を簡単にデプロイできるように、スクリプトとテンプレートは十分な柔軟性を備えている必要があります。 パラメーター、変数、および構成ファイルを使用して、標準のリソース セットをデプロイします。これは、コード昇格スタックのどの環境でもデプロイできるように変更することができます。 リソースのサイズ、数、名前、デプロイ先、構成設定などの設定を抽象化します。 ただし、抽象化しすぎないように注意してください。 ワークロード ライフサイクルの過程で実際には変更されない可能性のある、または、ほとんど変更されない可能性があるパラメーターまたは変数で抽象化できる設定が存在します。 これらは抽象化しないでください。

Note

環境ごとに異なる IaC 資産を使用することは避けます。 たとえば、運用環境とテスト環境にそれぞれ異なる Terraform ファイルを含めないでください。 すべての環境で 1 つのファイルを使用するようにします。 必要に応じてそのファイルを操作してさまざまな環境にデプロイできます。

機能をカプセル化するときに適切なバランスを取る

モジュールの使用について戦略を立て、標準化します。 パラメーターや変数と同様、モジュールを使用すると、インフラストラクチャのデプロイを繰り返し可能にすることができます。 ただし、それをどのように使用するかについては注意が必要です。 標準化された抽象化戦略によって、合意された特定の目標を満たすモジュールを確実に構築できるようになります。 モジュールを使用して、複雑な構成またはリソースの組み合わせをカプセル化します。 リソースの既定の構成のみを使用している場合、モジュールを使うのは避けます。 また、新しいモジュールを開発するときは、慎重に取り組むようにしてください。 たとえば、機密性のないシナリオで、メンテナンスされたオープン ソース モジュールを使用します (適切な場合)。

手動の手順を文書化する

手動の手順の標準を文書化します。 インフラストラクチャのデプロイと保守に関連して、使用している環境に特有の手順で、手動による介入を必要とするものが存在する場合があります。 これらの手順を最小限に抑え、明確に文書化します。 スタイル ガイドと標準の運用手順で、手動の手順を標準化して、タスクが安全かつ一貫して実行されるようにします。

孤立したリソースを処理するための標準を文書化する。 構成管理に使用するツールとその制限によっては、ワークロードで特定のリソースが不要になり、IaC ツールでそのリソースを自動的に削除できない場合があります。 たとえば、何らかの機能のために VM から PaaS サービスに移行していて、廃止されたリソースを削除するロジックが IaC ツールにないとします。 ワークロード チームがそのリソースを手動で削除することを覚えていないと、これらのリソースは孤立する可能性があります。 これらのシナリオを処理するには、孤立したリソースをスキャンして削除する戦略を標準化します。 また、テンプレートが最新であることを確認する方法も検討する必要があります。 IaC ツールの制限事項を調べて、このような状況で何を計画する必要があるかを把握しましょう。

ワークロードに IaC を使用する場合に適用される次の推奨事項を検討してください。

IaC パイプラインに階層化アプローチを使用する

階層化されたアプローチを使用して、ワークロード スタック内で IaC パイプラインを調整します。 IaC パイプラインをレイヤーに分離すると、複雑な環境を管理するのに役立ちます。 何十または何百ものリソースを単一のパッケージとしてデプロイすることは非効率的であり、依存関係の破損などの複数の問題が発生する可能性があります。 デプロイのライフサイクルや機能などの要素が厳密に一致するリソースで構成されるレイヤーに合わせて複数のパイプラインを使用すると、IaC デプロイの管理が容易になります。

ネットワーク リソースなどのコア インフラストラクチャでは、構成の更新よりも複雑な変更が必要になることはほとんどないため、これらのリソースは、"ロータッチ" の IaC パイプラインを構成します。 ワークロードの複雑さに応じて、1 つ以上の "ミディアムタッチ" および "ハイタッチ" の IaC パイプラインがリソースに対して存在する場合があります。 Kubernetes ベースのアプリケーション スタックを例にとると、1 つのミディアムタッチのレイヤーが、クラスター、ストレージ リソース、およびデータベース サービスで構成されている場合があります。 ハイタッチ レイヤーは、継続的デリバリー モードで頻繁に更新されるアプリケーション コンテナーで構成されます。

IaC とアプリケーション コードを同じように扱う

IaC の成果物をアプリケーション コードの成果物と同じように扱うと、すべてのパイプラインのコードの管理に同じ厳密さを適用できます。 さらに、IaC の開発とデプロイのプラクティスは、アプリケーションのプラクティスをミラーする必要があります。 バージョン管理、分岐、コードの昇格、品質の標準はすべて同じである必要があります。 また、IaC 資産をアプリケーション コード資産と併置することも検討してください。 これを行うと、すべてのデプロイで同じプロセスを確実に実行でき、必要なアプリケーション コードの前にインフラストラクチャを誤ってデプロイする、またはその逆を行う、などの問題を回避できます。

一元化された標準とリソースを使用する

組織内の他のチームとの共同作業により標準化と再利用を実現します。 大規模な組織では、複数のチームがワークロードの開発とサポートを行っている場合があります。 標準に同意するためのチーム間のコラボレーションにより、ライブラリ、テンプレート、モジュールを再利用して、ワークロード環境全体の効率性と一貫性を高めることができます。 同様に、IaC ツールも、実用的な範囲で組織全体で標準化する必要があります。

IaC コードでセキュリティを適用する

"コードとしてのセキュリティ" の原則を適用して、セキュリティが確実にデプロイ パイプラインの一部となるようにします。 IaC 開発プロセスの一環として、脆弱性スキャンと構成の強化を含めます。 IaC リポジトリで、公開されているキーとシークレットをスキャンします。 IaC を使用する利点の 1 つは、セキュリティに重点を置いたチーム メンバーが、セキュリティによってリリースが承認された構成が確実に運用環境に実際にデプロイされるように、デプロイ前にコードを確認できることです。 詳しい説明については、「開発ライフサイクルをセキュリティで保護するための推奨事項」を参照してください。

ルーチン アクティビティと非ルーチン アクティビティをテストする。 デプロイ、構成の更新、および復旧プロセス (デプロイ/ロールバック プロセスを含む) をテストします。

変更不可のデプロイ モデルを採用する

変更可能なインフラストラクチャと変更不可のインフラストラクチャのどちらをデプロイするかは、いくつかの要因によって決まります。 ワークロードがビジネス クリティカルな場合は、変更不可のインフラストラクチャを使用することをお勧めします。 同様に、デプロイ スタンプに基づく成熟したインフラストラクチャ設計がある場合は、アプリケーション コードと新しいインフラストラクチャを確実にデプロイできるため、変更不可のインフラストラクチャを使用するのが理にかなっています。 逆に、安全なデプロイ プラクティスで、デプロイに関する緩和可能な問題が発生したときにデプロイをロールフォワードすることが推奨される場合は、変更可能なインフラストラクチャを使用することをお勧めします。 この場合は、おそらくインフラストラクチャをインプレースで更新することになります。

考慮事項

専門性が上がる: ワークロード チームへの新しい言語の導入には学習曲線が伴うことがあり、ベンダー ロックインは選択を誤らせかねません。 チーム メンバーをトレーニングし、クラウド プロバイダーのツール サポートに基づいて適切なツールを分析する必要があります。

メンテナンス作業が増加する: コード ベースとツールのメンテナンスは、IaC の実装を最新かつ安全に保つうえで必要です。 技術的負債を適切に追跡し、負債を削減することが報われる文化を育みます。

構成変更にさらに時間がかかる: インフラストラクチャのデプロイを、コマンドライン命令を使用して、またはポータルから直接行えば、コーディング時間やテスト成果物は不要です。 コード レビューや品質保証プラクティスなどの推奨プラクティスに従って、デプロイ時間を最小限に抑えます。

モジュール化がさらに複雑になる: モジュールとパラメーター化が増えると、システムのデバッグと文書化の所要時間が長くなり、抽象化のレイヤーが追加されます。 モジュール化をバランスよく利用して複雑さを軽減し、過剰なエンジニアリングを回避します。

Azure ファシリテーション

Azure Resource Manager テンプレート (ARM テンプレート) と Bicep は、宣言型構文を使用してインフラストラクチャをデプロイするための Azure ネイティブ ツールです。 ARM テンプレートは JSON で記述されますが、Bicep はドメイン固有言語です。 どちらも Azure パイプライン や GitHub Actions CI/CD パイプラインに簡単に統合できます。

Terraform も Azure で完全にサポートされている宣言型 IaC ツールです。 これはインフラストラクチャのデプロイと管理に使用でき、CI/CD パイプラインに統合できます。

Microsoft Defender for Cloud を使用すると、IaC で誤った構成を検出できます。

例

提供された Resource Manager、Bicep、または Terraform ファイルを使用してデプロイできる Virtual Desktop 実装の例については、Azure Virtual Desktop ランディング ゾーン アクセラレータ アーキテクチャおよび関連する参照の実装に関するページを参照してください。

オペレーショナル エクセレンス チェックリスト

レコメンデーションの完全なセットを参照してください。

オペレーショナル エクセレンスに関するチェックリスト