ワークロード開発サプライ チェーンを設計するための推奨事項

  • [アーティクル]

この Azure Well-Architected Framework のオペレーショナル エクセレンス チェックリストの推奨事項に適用されます。

OE:06 予測可能な自動化されたパイプラインを通じて提案された変更を推進するワークロードサプライチェーンを構築します。 パイプラインは、環境間でこれらの変更をテストして昇格させます。 サプライ チェーンを最適化して、ワークロードの信頼性、セキュリティ、コスト効率、パフォーマンスを高めます。

このガイドでは、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインに基づくワークロード開発サプライ チェーンを設計するための推奨事項について説明します。 サプライ チェーンを開発して、ワークロードを予測可能で標準化された方法で維持できるようにします。 CI/CD パイプラインはサプライ チェーンの現れですが、単一のサプライ チェーンが必要です。 また、同じプロセスに従い、同じツールを使用するパイプラインがいくつか存在する場合があります。

サプライ チェーンを組み込み、ワークロードの変更を適切に管理しない場合に発生する可能性のある損害からワークロードを保護します。 ワークロードの状態に常に注意してください。そのため、予期しない動作が発生するリスクはありません。 このリスクは、問題が発生したときに重要な時間を過ごし、未確認の変更を再処理する必要がある場合に発生します。 これらのリスクを最小限に抑えるには、サプライ チェーンを定義するプロセスとツールを標準化し、ワークロード チームがその使用に完全にコミットしていることを確認します。

定義

期間 定義
サプライ チェーン クラウド ワークロードでは、サプライ チェーンは、環境全体のインフラストラクチャとアプリケーションの変更に影響を与えるために使用する標準化されたツールとプロセスのスイートです。

主要な設計戦略

注意

このガイドの推奨事項は、コード 昇格チェーン内のワークロード環境を参照しています。 サンドボックスまたはその他の探索的および概念実証環境では、より厳密で構造が少なくて済みます。

コア テネット

次の推奨事項は、サプライ チェーンのコア テネットを定義するのに役立ちます。

サプライ チェーンのプロセスとツールを使用して、提案されたワークロード変更を行います。 自動テンプレート ベースのデプロイの厳格なポリシーを適用します。 この方法は、すべての環境でワークロードの構成が標準化され、明確に定義され、厳密に制御されるようにするのに役立ちます。 コード プロモーション チェーン内の環境では、手動プロセスやクラウド プラットフォームのコントロール プレーン (ポータルや API など) との人間の操作を使用して更新を実行しないでください。 定義したデプロイ プラクティスに従って、パイプラインを通じて環境に対するすべての変更を組み込みます。 このポリシーを適用するには、既定として読み取り専用へのアクセスを制限し、アクセス承認ゲートを使用して書き込みアクセスを許可することを検討してください。

このテネットの重要な側面は、運用環境にデプロイされるまで、すべての変更が提案されるということです。 統合やスモーク テストなどの自動テストを通じて、サプライ チェーンは変更を自動的に拒否できます。

反復可能で不変のインフラストラクチャをコードとしてデプロイする (IaC)。 IaC は、ソース コードをミラー化するバージョン管理システムを使用する記述モデルでのインフラストラクチャの管理です。 アプリケーションを作成するときは、コンパイルされるたびに同じソース コードで同じバイナリを生成する必要があります。 同じような方法で、IaC モデルが適用されるたびに同じ環境が生成されます。

IaC を組み込んで、チームが標準的で確立されたプロセスに従っていることを確認します。 一部の組織では、インフラストラクチャをデプロイして構成するために、1 人または少数の個人グループを指定しています。 完全に自動化されたプロセスを実装する場合、インフラストラクチャのデプロイでは、個人からの管理が少なくて済みます。 責任は自動化プロセスとツールに移されます。 チーム メンバーは、一貫性と品質を維持するためにインフラストラクチャのデプロイを開始できます。

デプロイを簡単かつ反復可能にするために、1 つのテンプレートにバンドルできるコンポーネントの論理グループとしてワークロードを設計します。 これらのバンドルは、 スタンプ または スケールの単位と考えることができます。 詳細については、「 デプロイ スタンプ パターン」を参照してください。 ワークロードをデプロイして同じリージョン内の別のリージョンまたはゾーンにスケールアウトする必要がある場合は、パイプラインを使用してスタンプをデプロイします。 スタンプの設計方法によっては、ワークロード全体ではなくワークロードのサブセットをデプロイする場合があります。 デプロイ スタンプが既存のリソースに自動的に接続されるように、IaC パイプラインにネットワーク コンポーネントを含めます。

一貫性と効率性のために IaC パイプラインを最適化するには、変更可能なインフラストラクチャではなく、不変のインフラストラクチャを設計します。 変更できないインフラストラクチャを実装して、スコープ内のすべてのシステムが更新された構成に同時に置き換えられ、各デプロイと同じになるようにします。

すべての環境とパイプラインで 1 つのコード資産と成果物のセットを使用します。 組織にとって一般的な問題点は、非運用環境が運用環境と異なる場合です。 運用環境と非運用環境を手動でビルドすると、環境間で構成が一致しない可能性があります。 この不一致により、テストが遅くなり、変更が運用システムに害を与える可能性が高くなります。 IaC アプローチでは、これらの問題が最小限に抑えられます。 IaC 自動化を使用する場合は、すべての環境で同じインフラストラクチャ構成ファイルを使用して、ほぼ同じ環境を生成できます。 インフラストラクチャ構成ファイルにパラメーターを追加し、各環境の要件を満たすように調整できます。

コストを制御するには、通常、運用環境と非運用環境の間に差異があります。 多くの場合、運用環境と同程度の冗長性とパフォーマンスは、非運用環境では必要ありません。 リソースの数と SKU は、環境によって異なる場合があります。 変更を加える際に予測可能性を維持するために、標準化されたパラメーターを使用して分散を制御し、理解していることを確認します。

サプライ チェーンとパイプラインの設計に組織構造を反映します。 organizationがチーム間でサイロ化されている可能性があります。 各チームがサプライ チェーンの一部を管理する場合があります。 たとえば、多くの組織には、ネットワーク、データ、コンピューティング リソースなどのインフラストラクチャ ドメインを管理するチームがあります。 これらのチームは、アプリケーションの開発、テスト、デプロイを管理する開発チームとは別です。 一部の組織では、開発チームとインフラストラクチャ チームが DevOps チームに組み込まれ、すべてのインフラストラクチャとアプリケーションのデプロイをまとめて管理します。 サプライ チェーンに関係するチームを編成するには、さまざまな方法があります。 サプライ チェーンは、すべてのチームがシームレスに連携しています。 すべてのチームが標準プロセスに従い、標準ツールを使用してサプライ チェーンを可能な限り効率的にします。

ワークロードライフサイクルの一部をアウトソーシングする場合、サプライ チェーンはサードパーティベンダーに依存している可能性があります。 これらのベンダーは、サプライ チェーンの成功にとって、内部リソースと同じくらい重要です。 使用するプロセスとツールについて、すべてのチームで相互に合意していることを確認します。

デプロイ方法を標準化します。 ワークロードに許容される運用ダウンタイムについて、製品所有者に問い合わせてください。 ダウンタイムが許容される量に応じて、要件に適したデプロイ方法を選択できます。 メンテナンス期間中にデプロイを実行して、複雑さとリスクを軽減するのが理想的です。 ダウンタイムが許容されない場合は、ブルーグリーンのデプロイ方法を使用します。

プログレッシブ露出アプローチを使用して、検出されていないバグを顧客に大規模に導入するリスクを軽減します。 カナリア デプロイとも呼ばれるこのメソッドは、制御されたユーザー グループに段階的にデプロイします。 より多くのユーザーに影響を与える前に、問題をキャッチします。 最初のロールアウト グループは、ロールアウト戦略を認識している顧客のサブセクションである可能性があります。 このお客様のサブセクションでは、ある程度の予期しない動作を許容し、フィードバックを提供できます。 または、ロールアウト中にバグの爆発半径を含めるのに役立つ内部ユーザーのグループである可能性があります。

デプロイ方法を定義する場合は、各デプロイで実行可能な最小の変更のみをデプロイする標準ポリシーを採用します。 ワークロードの重要度やコンポーネントの複雑さなどの要因に応じて、実行可能な最小の変更を決定します。 不変インフラストラクチャを使用する場合、最も小さな実行可能な変更は、通常、以前のバージョンを実行するリソースを置き換える最新の構成を使用したリソースのデプロイです。 変更可能なインフラストラクチャを使用する場合、実行可能な最小の変更は、スコープ内のリソース のグループに対する 1 つの更新に過ぎないと判断できます。

階層化されたアプローチに従って、さまざまなライフサイクルを反映します。 基本レイヤーはワークロード ライフサイクルの大部分を通じて静的であり、アプリケーション レイヤーは頻繁に変更されます。 これらの違いを考慮するには、各レイヤーで変更を反映するために異なるパイプラインが必要です。

ランディング ゾーンは最も低いレイヤーにあります。 ランディング ゾーンは、サブスクリプション、管理グループ、リソース グループ、ガバナンス機能、ネットワーク トポロジなどの基本的な要素の論理的なグループです。 ランディング ゾーンを使用すると、ワークロードを簡単にデプロイおよび管理でき、環境構成に対して反復可能なアプローチで中央運用チーム (プラットフォーム チーム) を提供できます。 一貫性のある環境を提供するために、すべての Azure ランディング ゾーンには、一連の共通設計領域、参照アーキテクチャ、参照実装、および設計要件に合わせてデプロイを変更するプロセスが用意されています。 Azure ランディング ゾーンの設計原則では、サブスクリプションの民主化と共に、ポリシー主導のガバナンスに基づいて推奨されるプラクティスが提供されます。 ランディング ゾーンでは、ワークロードライフサイクルの過程で最小限の変更が必要です。 ランディング ゾーンの例については、「 Azure ランディング ゾーンとは」を参照してください。 この概念アーキテクチャでは、Azure に推奨される一連の意見が提供されます。

イングレスおよびエグレス ネットワーク コントローラー、負荷分散、ネットワーク ルーティング ソリューション、DNS 管理、コア サーバーなどのコア インフラストラクチャと機能でも、あまり大きな変更は必要ないはずです。 ただし、頻繁に構成を更新する必要がある場合があります。

アプリケーションレイヤーとデータ層では、頻繁に構成を更新し、頻繁にインフラストラクチャを変更する必要があります。 これらのコンポーネントには、最も動的なパイプラインが必要です。

包括的なテスト戦略を計画します。 システムの信頼性の中核となる原則は、 シフト左 の原則です。 アプリケーションの開発とデプロイは、左から右への一連の手順として示されるプロセスです。 テストをプロセスの最後に限定しないでください。 可能な限り、最初または左にテストをシフトします。 エラーは、早くキャッチしたときに修復する方が安価です。 アプリケーションのライフサイクルの後半で修正するには、コストがかかる場合や不可能な場合があります。

アプリケーション コード、インフラストラクチャ テンプレート、構成スクリプトなど、すべてのコードをテストします。 アプリケーションを実行する環境は、アプリケーション コードと同じメカニズムを使用してバージョン管理およびデプロイする必要があります。 チームがアプリケーション コードに既に使用しているのと同じテスト パラダイムを使用して、環境をテストおよび検証できます。

可能な場合は、自動テストを使用して一貫性を確保します。 サプライ チェーン設計には、次の種類のテストを含めます。

  • 単体テスト: 単体テストは、通常、継続的インテグレーション ルーチンの一部として実行されます。 単体テストは広範かつ迅速である必要があります。 理想的には、コードの 100% をカバーし、30 秒以内に実行する必要があります。

    単体テストを実装して、コードの個々のモジュールの構文と機能が、既知の入力に対して定義された出力を生成するなど、適切な方法で動作することを確認します。 単体テストを使用して、IaC 資産が有効であることを確認することもできます。

    テンプレートやスクリプトを含むすべてのコード資産に単体テストを適用します。

  • スモーク テスト: スモーク テストでは、テスト環境でワークロードを立ち上げ、期待どおりに実行できることを確認します。 スモーク テストでは、コンポーネントの相互運用性は検証されません。

    スモーク テストでは、インフラストラクチャとアプリケーションのデプロイ手法が機能し、プロセスの完了後にシステムが意図したとおりに応答することを確認します。

  • 統合テスト: 統合テストでは、アプリケーション コンポーネントが個別に動作することを確認し、コンポーネントが必要に応じて相互に対話できるかどうかを判断します。

    大規模な統合テスト スイートを実行するには、かなりの時間がかかる場合があります。 そのため、シフト左の原則を組み込み、ソフトウェア開発ライフサイクルの早い段階でテストを実行することをお勧めします。 スモーク テストまたは単体テストではテストできないシナリオの統合テストを予約します。

    必要に応じて、実行時間の長いテスト プロセスを定期的に実行できます。 一定の間隔で適切なセキュリティ侵害が発生し、アプリケーション コンポーネント間の相互運用性の問題が発生してから 1 日も経たない間に検出されます。

    一部のテスト シナリオでは、手動実行の利点があります。 人間の対話機能要素をテストに導入する必要がある場合は、手動テストを使用します。

  • 受け入れテスト: コンテキストに応じて、受け入れテストを手動で実行できます。 部分的または完全に自動化できます。 受け入れテストでは、ソフトウェア システムが要件仕様を満たしているかどうかを判断します。

    このテストのメイン目的は、システムのビジネス要件への準拠を評価し、システムがエンド ユーザーへの配信に必要な条件を満たしているかどうかを判断することです。

テストを使用して、コードプロモーションプロセス全体で品質ゲートを実装します。 開発やテストなどの低い環境にコードをデプロイし、ステージングや運用環境などのより高い環境を介してコードをデプロイします。 デプロイが品質ゲートを通過するにつれて、変更が運用環境に移行する前に品質目標を満たしていることを確認します。 ビジネス要件によって、品質ゲートの焦点が決まります。 また、フレームワークの基本的な原則である セキュリティ、 信頼性、 パフォーマンス効率 Well-Architected 考慮してください。

また、承認ワークフローを品質ゲートに統合します。 必要に応じて、承認ワークフローを明確に定義して自動化します。 品質の受け入れ基準を自動化に定義して、ゲート内を効率的かつ安全に移動できるようにします。

Azure ファシリテーション

Azure DevOps は、コラボレーション、効率的、一貫性のある開発プラクティスを構築するのに役立つサービスのコレクションです。

Azure Pipelines には、 アプリケーションで CI/CD をサポートするためのビルド サービスとリリース サービスが用意されています。

azure のGitHub Actionsは、デプロイを簡略化するために Azure と統合されます。 ci/CD プロセスを自動化するには、GitHub Actionsを使用します。 リポジトリに対するすべての pull request をビルドしてテストするワークフローを作成したり、マージされた pull request を運用環境にデプロイしたりできます。

IaC デプロイには、Terraform、Bicep、Azure Resource Managerを使用できます。 要件とツールに関するチームの知識によっては、リソースのデプロイと管理にこれらのツールを 1 つ以上使用する場合があります。

例

Azure Pipelines を使用して CI/CD パイプラインを構築する方法を示す例については、「 Azure Pipelines のベースライン アーキテクチャ」を参照してください。

操作の卓越性のチェックリスト

推奨事項の完全なセットを参照してください。

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