ワークロード開発サプライ チェーンの設計に関する推奨事項
Azure Well-Architected フレームワークのオペレーショナル エクセレンスに関するチェックリストの次の推奨事項を対象とします。
| OE:06 | 予測可能な自動化されたパイプラインを通じて提案された変更を推進するワークロード サプライ チェーンを構築します。 パイプラインを通じて、環境全体でこれらの変更がテストされ昇格されます。 サプライ チェーンを最適化して、ワークロードを信頼性が高く安全で、コスト効率に優れたものとし、パフォーマンスを向上させます。 |
|---|
このガイドでは、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインに基づいたワークロード開発サプライ チェーンを設計するための推奨事項について説明します。 ワークロードを予測可能で標準化された方法で維持できるように、サプライ チェーンを開発します。 CI/CD パイプラインはサプライ チェーンの現れですが、サプライ チェーンは 1 つである必要があります。 また、同じプロセスに従い、同じツールを使用する複数のパイプラインがある場合もあります。
サプライ チェーンを統合して、ワークロードをワークロードの変更を適切に管理しない場合に発生しうる損害から保護します。 ワークロードの状態を常に把握して、予期しない動作が発生するリスクにさらされないようにします。 このリスクは、問題の発生時に、説明のつかない変更を遡って調査するのに重要な時間を費やさなければならない場合に悪化します。 これらのリスクを最小限に抑えるには、サプライ チェーンを定義するプロセスとツールを標準化して、ワークロード チームがその使用に全面的にコミットできるようにします。
定義
| 任期 | 定義 |
|---|---|
| サプライ チェーン | クラウド ワークロードでは、サプライ チェーンとは、環境全体でのインフラストラクチャとアプリケーションの変更に作用するために使用される標準化されたツールとプロセスのスイートです。 |
主要な設計戦略
Note
このガイドの推奨事項では、コード昇格チェーンのワークロード環境について取り上げます。 サンドボックスやその他の探索的な概念実証環境では、求められる厳格さや構造の程度は低くなります。
次の推奨事項は、サプライ チェーンの主要原則を定義するのに役立ちます。
テンプレート ベースの自動デプロイの厳格なポリシーを適用する
提案されたワークロードの変更は、サプライ チェーンのプロセスとツールを通じて行います。 テンプレート ベースの自動デプロイの厳格なポリシーを適用します。 この方法は、すべての環境でワークロードの構成が標準化され、明確に定義され、厳密に制御できるようにするのに役立ちます。 コード昇格チェーン内の環境では、手動プロセスやクラウド プラットフォームのコントロール プレーン (ポータルや API など) を使用した人間による操作を用いて更新を実行しないようにします。 定義したデプロイ プラクティスに従って、パイプラインを通じて環境に対するすべての変更を組み込みます。 このポリシーをきちんと適用するために、デフォルトではアクセスを読み取り専用に制限し、アクセス承認ゲートを使用して書き込みアクセス権限を付与することを検討します。
この原則の重要な側面は、すべての変更が、運用環境にデプロイされるまでに "提案された変更" であるということです。 統合テストやスモーク テストなどの自動テストを通じて、サプライ チェーンで変更を自動的に拒否できるようにします。
反復可能で変更不可の、コードとしてのインフラストラクチャをデプロイする
反復可能で変更不可の、コードとしてのインフラストラクチャ (IaC) をデプロイします。 IaC は、ソース コードをミラー化するバージョン管理システムを使用する記述型モデルでのインフラストラクチャの管理です。 アプリケーションを作成する場合、コンパイルのたびに同じソース コードによって同じバイナリが生成されます。 同じような方法で、IaC モデルが適用されるたびに同じ環境が生成されます。
IaC を組み込むことで、チームが標準的で確立されたプロセスに従うことができるようにします。 組織によっては、インフラストラクチャのデプロイと構成を行う個人または少数の個人のグループを指定しています。 完全に自動化されたプロセスを実装する場合、インフラストラクチャのデプロイに個人による管理はそれほど必要とされなくなります。 その責任は、自動化プロセスと自動化ツールに移行します。 チーム メンバーは、一貫性と品質の維持に向けたインフラストラクチャのデプロイを開始できます。
ワークロードをコンポーネントの論理グループとして設計し、1 つのテンプレートにバンドルしてデプロイを容易かつ反復可能なものとすることができます。 これらのバンドルは、"スタンプ" または "スケール ユニット" と考えることができます。 詳細については、「デプロイ スタンプ パターン」を参照してください。 ワークロードを別のリージョンまたは同じリージョン内の別のゾーンにデプロイしてスケールアウトする必要がある場合は、パイプラインを使用してスタンプをデプロイします。 スタンプの設計方法によっては、ワークロード全体ではなくワークロードのサブセットをデプロイすることもできます。 IaC パイプラインにネットワーク コンポーネントを含めて、デプロイ スタンプが既存のリソースに自動的に接続するようにします。
一貫性と効率性を目的として IaC パイプラインを最適化するには、変更可能なインフラストラクチャではなく、変更不可の (イミュータブルな) インフラストラクチャを設計します。 変更不可のインフラストラクチャを実装して、スコープ内のすべてのシステムが同時に、かつ各デプロイが等しくなるように、更新された構成に置き換えられるようにします。
すべての環境で同じデプロイ成果物のセットを使用する
すべての環境とパイプラインでコード資産と成果物のセットを 1 つ使用します。 組織にとって一般的な問題は、非運用環境が運用環境と異なる場合です。 運用環境と非運用環境を手動でビルドすると、環境間の構成が一致しなくなる可能性があります。 この不一致により、テストに時間がかかり、変更が運用環境のシステムに悪影響を与える可能性が高くなります。 IaC アプローチにより、これらの問題が最小限に抑えられます。 IaC オートメーションを使用すると、すべての環境に同じインフラストラクチャ構成ファイルを使用して、ほぼ同じ環境を構築することができます。 インフラストラクチャ構成ファイルにパラメーターを追加して、各環境の要件を満たすように調整を行えます。
コストを抑制するため、通常、運用環境と非運用環境の間には差異があります。 多くの場合、非運用環境では運用環境ほどの冗長性とパフォーマンスを必要としません。 リソースの数と SKU は、環境ごとに異なっていてかまいません。 標準化されたパラメーターを使用して、変更を加える際の予測可能性を維持し、この差異を管理し把握するようにしてください。
組織構造をサプライ チェーンに反映する
組織構造をサプライ チェーンとパイプラインの設計に反映します。 組織がチームごとにサイロ化されている場合があります。 各チームがサプライ チェーンの一部を管理していることもあります。 たとえば、多くの組織には、ネットワーク、データ、コンピューティング リソースなどのインフラストラクチャ ドメインを管理するチームがあります。 これらのチームは、アプリケーションの開発、テスト、デプロイを管理する開発チームとは分かれています。 一部の組織では、開発チームとインフラストラクチャ チームはすべてのインフラストラクチャとアプリケーションのデプロイをまとめて管理する DevOps チームに組み込まれています。 サプライ チェーンに関わるチームを編成するのには、さまざまな方法があります。 サプライ チェーンは、すべてのチームのシームレスな連携にかかっています。 すべてのチームが標準プロセスに従い標準ツールを使用するようにして、サプライ チェーンが可能な限り効率的なものになるようにします。
ワークロード ライフサイクルの一部を外注している場合には、サプライ チェーンはサードパーティ ベンダーに依存していることがあります。 このようなベンダーは、サプライ チェーンの成功にとって、内部リソースと等しく重要です。 使用するプロセスとツールについて、すべてのチーム間で相互に合意しておくようにします。
適切なデプロイ方法を選択する
デプロイ方法を標準化します。 ワークロードで許容可能な運用環境のダウンタイムについて、製品所有者に問い合わせてください。 許容可能なダウンタイムの量に応じて、要件に適したデプロイ方法を選択できます。 理想的には、複雑さとリスクを軽減するために、メンテナンス期間中にデプロイを実行する必要があります。 ダウンタイムが許容できない場合は、ブルーグリーン デプロイ方法を使用します。
段階的公開アプローチを使用して、未検出のバグを顧客のもとで大量に発生させてしまうリスクを軽減します。 カナリア デプロイとも呼ばれるこのメソッドでは、制御されたユーザー グループに段階的な順序で展開していきます。 この方法により、多くのユーザーに影響を与える前に、問題を把握できます。 初期ロールアウト グループとして、ロールアウト戦略を認識している顧客の一部を選択してもいいでしょう。 この顧客グループは、ある程度の想定外の動作を許容してフィードバックを提供できます。 または、内部ユーザーのグループを選択することもできます。この方法はロールアウト中にバグの影響範囲を抑制するのに役立ちます。
デプロイ方法を定義するときは、各デプロイで実行可能な最小の変更のみをデプロイする標準ポリシーを採用します。 ワークロードの重要度やコンポーネントの複雑さなどの要因に応じて、実行可能な最小の変更を決定します。 変更不可のインフラストラクチャを使用する場合、実行可能な最小の変更は、通常、以前のバージョンを実行しているリソースを最新の構成に置き換えるリソースをデプロイすることです。 変更可能なインフラストラクチャを使用する場合、実行可能な最小の変更は、スコープ内のリソース グループに対する単一の更新のみとするといいでしょう。
階層型アプローチに従う
階層型アプローチに沿って、さまざまなライフサイクルを反映します。 基本レイヤーは、ワークロード ライフサイクルの大部分を通じて静的なままにする必要があり、アプリケーション レイヤーは頻繁に変更されます。 これらの違いを考慮するには、各レイヤーで変更を反映するために異なるパイプラインが必要となります。
ランディング ゾーンは最下層のレイヤーにあります。 ランディング ゾーンは、サブスクリプション、管理グループ、リソース グループ、ガバナンス機能、ネットワーク トポロジなどの基本要素の論理的なグループです。 ランディング ゾーンは、ワークロードの容易なデプロイと管理を可能にし、中央運用チームやプラットフォーム チームに環境構成に対する反復可能なアプローチを提供します。 一貫性のある環境を提供するために、すべての Azure ランディング ゾーンには、共通の設計領域のセット、参照アーキテクチャ、参照実装、設計要件に合わせてデプロイを変更するプロセスが用意されています。 Azure ランディング ゾーンの設計原則では、サブスクリプションの民主化とともに、ポリシー主導のガバナンスに基づいて推奨されるプラクティスが挙げられています。 ランディング ゾーンで必要となる変更は、ワークロード ライフサイクルの全過程において最小であるべきです。 ランディング ゾーンの例については、「Azure ランディング ゾーンとは」を参照してください。 この概念アーキテクチャでは、Azure で推奨される一連の意見が提供されています。
イングレス/エグレス ネットワーク コントローラー、負荷分散、ネットワーク ルーティング ソリューション、DNS 管理、コア サーバーなどの主要なインフラストラクチャと機能でも、大きな変更が必要となることは稀です。 ただし、そこでは頻繁な構成の更新が必要となる場合があります。
アプリケーションとデータのレイヤーでは、頻繁な構成の更新とインフラストラクチャの変更が必要となります。 これらのコンポーネントには、最も動的なパイプラインが必要です。
包括的な種類のテストを組み込む
包括的なテスト戦略を策定します。 システムの信頼性の中核となる原則は、"シフト レフト" の原則です。 アプリケーションの開発とデプロイは、左から右へと進行する一連のステップとして示されるプロセスです。 テストの実施をプロセスの最後に限定すべきではありません。 可能な限り、テストを初めの方に (左に) シフトします。 エラーの発見が早期であれば、修復が低コストで済みます。 エラーをアプリケーション ライフサイクルの後半で発見した場合、修復のコストは高くなり、修復できない場合もあります。
アプリケーション コード、インフラストラクチャ テンプレート、構成スクリプトなど、すべてのコードをテストします。 アプリケーションを実行する環境は、アプリケーション コードの場合と同じメカニズムを使用してバージョン管理とデプロイを行う必要があります。 チームがアプリケーション コードで使用しているのと同じテスト パラダイムを使用して、環境をテストし検証することができます。
可能な場合は、自動化されたテストを使用して一貫性を確保します。 サプライ チェーンの設計に、次の種類のテストを含めます。
単体テスト: 単体テストは、通常、継続的インテグレーション ルーチンの一部として実行されます。 単体テストは、広範かつ迅速に行う必要があります。 コードの 100% をカバーし、30 秒以内で実行するのが理想的です。
単体テストを実装して、コードの個々のモジュールの構文と機能が想定どおりに動作すること (既知の入力に対して定義された出力を生成するなど) を確認します。 また、単体テストを使用して、IaC 資産が有効であることの確認も行えます。
テンプレートやスクリプトを含む、すべてのコード資産に単体テストを適用します。
スモーク テスト: スモーク テストでは、ワークロードをテスト環境で立ち上げて、想定どおりに実行できることを確認します。 スモーク テストでは、コンポーネントの相互運用性は検証されません。
スモーク テストでは、インフラストラクチャとアプリケーションのデプロイ手法が機能すること、プロセスの完了後にシステムが意図したとおりに応答することを確認します。
統合テスト: 統合テストでは、アプリケーション コンポーネントが個別に動作することを確認した後、コンポーネントが想定どおりに相互連携できるかを確認します。
大規模な統合テスト スイートを実行するには、かなりの時間がかかる場合があります。 そのため、シフト レフトの原則を組み込み、ソフトウェア開発ライフサイクルの早い段階でテストを実施することをお勧めします。 スモーク テストや単体テストではテストできないシナリオのために統合テストを確保しておきます。
必要に応じて、実行時間の長いテスト プロセスを周期的に実行することができます。 1周期はまずまずの妥協点となる期間で、アプリケーション コンポーネント間の相互運用性の問題を導入後 1 日以内に検出します。
一部のテスト シナリオでは、手動による実行が役立ちます。 人手による操作要素をテストに導入する必要がある場合は、手動テストを使用します。
承認テスト: コンテキストに応じて、手動で承認テストを実行できます。 一部または全面的に自動化できます。 承認テストでは、ソフトウェア システムが要件の仕様を満たしているかどうかを判断します。
このテストの主な目的は、システムのビジネス要件への準拠状況を評価し、エンド ユーザーへの出荷に必要な条件をシステムが満たしているかどうかを判断することです。
コード昇格プロセスに品質ゲートを実装する
テストの実施により、コード昇格プロセス全体に品質ゲートを実装します。 開発やテストなどの下位の環境にコードをデプロイし、ステージングや運用などの上位の環境へと昇格します。 デプロイが品質ゲートを通過することで、変更が運用環境に移行する前に品質目標を満たしていることを確認できます。 ビジネス要件によって、品質ゲートで何を重視するかが決まります。 また、セキュリティ、信頼性、パフォーマンス効率という Well-Architected フレームワークの基本的な原則についても考慮します。
また、承認ワークフローを品質ゲートに統合します。 必要に応じて、承認ワークフローを明確に定義して自動化します。 オートメーションに組み込む品質の受け入れ基準を定義して、ゲートの通過を効率的かつ安全に行えるようにします。
Azure ファシリテーション
Azure DevOps は共同作業に適した、効率的で一貫性のある開発プラクティスを構築するのに役立つサービスのコレクションです。
Azure Pipelines では、アプリケーションの CI/CD をサポートするためのビルド サービスとリリース サービスが提供されます。
Azure 用 GitHub Actions は Azure に統合されて、デプロイを簡略化します。 GitHub Actions を使用すると CI/CD プロセスを自動化できます。 リポジトリに対するすべての pull request をビルドしてテストするワークフローの作成や、マージされた pull request の運用環境へのデプロイを行えます。
IaC デプロイには、Terraform、Bicep、Azure Resource Manager を使用できます。 自組織の要件とツールに対するチームの習熟度に応じて、リソースのデプロイと管理にこれらのツールを 1 つまたは複数、使用するといいでしょう。
例
Azure Pipelines を使用して CI/CD パイプラインを構築する方法の例示は、「Azure Pipelines ベースライン アーキテクチャ」を参照してください。
関連リンク
オペレーショナル エクセレンスに関するチェックリスト
レコメンデーションの完全なセットを参照してください。