Azure でのミッション クリティカルなワークロードのデプロイとテスト
デプロイの失敗と誤ったリリースは、アプリケーションの停止の一般的な原因です。 デプロイとテストへのアプローチは、ミッション クリティカルなアプリケーションの全体的な信頼性において重要な役割を果たします。
デプロイとテストは、ミッション クリティカルなワークロードの一貫した結果を確保するために、すべてのアプリケーションとインフラストラクチャの運用の基礎を形成する必要があります。 毎週、毎日、またはより頻繁にデプロイする準備をしてください。 継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインを設計して、これらの目標をサポートします。
戦略では、次を実装する必要があります。
厳密なプレリリース テスト。 更新は、アプリケーションの正常性を危険にさらす可能性のある欠陥、脆弱性、またはその他の要因を発生させるべきではありません。
透過的なデプロイ。 ユーザーに影響を与えることなく、いつでも更新プログラムをロールアウトできる必要があります。 ユーザーは、中断することなくアプリケーションとの対話を続行できる必要があります。
高可用性操作。 アプリケーションの全体的な信頼性をサポートするには、デプロイとテストのプロセスとツールを高可用性にする必要があります。
一貫したデプロイ プロセス。 同じアプリケーション成果物とプロセスを使用して、さまざまな環境にインフラストラクチャとアプリケーション コードをデプロイする必要があります。 エンドツーエンドの自動化は必須です。 手動による介入は、信頼性のリスクが生じる可能性があるため、回避する必要があります。
この設計領域では、ダウンタイムを最小限に抑え、アプリケーションの正常性と可用性を維持することを目的として、デプロイとテストのプロセスを最適化する方法に関する推奨事項を提供します。
重要
この記事は、 Azure Well-Architected Framework のミッション クリティカルなワークロード シリーズの 一部です。 このシリーズに慣れていない場合 は、「ミッション クリティカルなワークロードとは」から始めてお勧めします。
ダウンタイムなしのデプロイ
ダウンタイムなしのデプロイの概要については、次のビデオをご覧ください。
ダウンタイムゼロのデプロイの実現は、ミッション クリティカルなアプリケーションの基本的な目標です。 営業時間中に新しいリリースがロールアウトされた場合でも、アプリケーションは毎日、終日利用できる必要があります。 リソースをエフェメラルとして扱うかどうかなどの主要な設計上の決定を推進するために、デプロイ プロセスを定義および計画するために、前もって取り組みを行います。
ダウンタイムゼロのデプロイを実現するには、既存のインフラストラクチャの横に新しいインフラストラクチャをデプロイし、徹底的にテストし、エンド ユーザー トラフィックを移行してから、前のインフラストラクチャの使用を停止します。 スケール ユニット アーキテクチャなどの他のプラクティスも重要です。
この図に示すように、 Mission-Critical Online と Azure Mission-Critical Connected のリファレンス実装では、このデプロイ アプローチを示しています。
アプリケーション環境
アプリケーション環境の推奨事項の概要については、次のビデオをご覧ください。
デプロイ操作を検証してステージングするには、さまざまな種類の環境が必要です。 型の機能とライフサイクルは異なります。 一部の環境では、運用環境が反映され、有効期間が長くなる場合があります。また、有効期間が短く、運用環境よりも機能が少ない環境もあります。 開発サイクルの早い段階でこれらの環境を設定すると、機敏性、運用環境と運用前資産の分離、運用環境へのリリース前の運用の徹底的なテストを確保するのに役立ちます。 必要に応じて低い環境に簡略化を適用できますが、すべての環境は可能な限り運用環境を反映する必要があります。 この図は、ミッション クリティカルなアーキテクチャを示しています。
いくつかの一般的な考慮事項があります。
コンポーネントは、環境間で共有しないでください。 考えられる例外は、ファイアウォールや合成テスト データのソースの場所などのダウンストリーム セキュリティ アプライアンスです。
すべての環境では、Terraform や Azure Resource Manager (ARM) テンプレートなどのコードとしてのインフラストラクチャ (IaC) 成果物を使用する必要があります。
開発環境
エフェメラル開発環境と自動機能検証に関する情報については、次のビデオをご覧ください。
設計上の考慮事項
機能。 開発環境では、信頼性、容量、およびセキュリティの要件が低い方が許容されます。
ライフサイクル。 開発環境は必要に応じて作成し、短時間存在する必要があります。 ライフサイクルが短いほど、コード ベースからの構成のずれを防ぎ、コストを削減できます。 また、開発環境は多くの場合、機能ブランチのライフサイクルを共有します。
密度。 Teams では、並列機能開発をサポートするために複数の環境が必要です。 これらは、1 つのサブスクリプション内で共存できます。
設計の推奨事項
開発目的でコンテキストが設定された専用のサブスクリプションに環境を保持します。
自動化されたプロセスを使用して、機能ブランチから開発環境にコードをデプロイします。
テスト環境またはステージング環境
これらの環境は、テストと検証に使用されます。 多くのテスト サイクルが実行され、運用環境へのバグのないデプロイが保証されます。 ミッション クリティカルなワークロードに対する適切なテストについては、「 継続的な検証とテスト 」セクションで説明されています。
設計上の考慮事項
機能。 これらの環境には、信頼性、容量、およびセキュリティのための運用環境が反映されている必要があります。 運用負荷がない場合は、合成ユーザー 負荷を使用して、現実的なメトリックと貴重な正常性モデリング入力を提供します。
ライフサイクル。 これらの環境は短命です。 これらは、テスト検証が完了した後に破棄する必要があります。
密度。 1 つのサブスクリプションで多数の独立した環境を実行できます。 また、専用サブスクリプション内の複数の環境を使用することも検討する必要があります。
Note
ミッション クリティカルなアプリケーションは、厳格なテストを受ける必要があります。
1 つの環境で異なるテスト関数を実行できます。場合によっては、実行する必要があります。 たとえば、カオス テストで意味のある結果を得るには、まずアプリケーションを負荷の下に置き、挿入された障害に対するアプリケーションの応答を理解できるようにする必要があります。 そのため、カオス テストとロード テストは通常、並列で実行されます。
設計の推奨事項
運用環境に似たテストと検証を可能にするために、少なくとも 1 つのステージング環境に運用環境が完全に反映されていることを確認します。 この環境内の容量は、テスト アクティビティの実行に基づいて柔軟に行うことができます。
いずれかの環境で変更を行う現実的なテスト ケースを提供するために、合成ユーザー負荷を生成します。
Note
Mission Critical Online リファレンス実装では、ユーザー ロード ジェネレーターの例を示します。
開発およびリリース サイクル内のステージング環境とその目的の数を定義します。
運用環境
設計上の考慮事項
機能。 アプリケーションの最高レベルの信頼性、容量、およびセキュリティ機能が必要です。
ライフサイクル。 ワークロードとインフラストラクチャのライフサイクルは変わりませんが、監視やログ記録を含むすべてのデータには特別な管理が必要です。 たとえば、バックアップと回復には管理が必要です。
密度。 一部のアプリケーションでは、異なる運用環境を使用して、さまざまなクライアント、ユーザー、またはビジネス機能に対応することを検討することをお勧めします。
設計の推奨事項
運用環境とより低い環境に対して明確なガバナンス境界を持つ。 その目標を達成するために、各環境の種類を専用のサブスクリプションに配置します。 このセグメント化により、低い環境でのリソース使用率が運用環境のクォータに影響を与えないことを保証します。 専用サブスクリプションでは、アクセス境界も設定されます。
エフェメラルブルー/グリーンデプロイ
青/緑のデプロイ モデルには、少なくとも 2 つの同一のデプロイが必要です。 青色のデプロイは、運用環境でユーザー トラフィックを提供するアクティブなデプロイです。 緑色のデプロイは、トラフィックを受信するために準備およびテストされた新しいデプロイです。 緑のデプロイが完了してテストされると、トラフィックは徐々に青から緑に向けられます。 読み込み転送が成功すると、緑色のデプロイが新しいアクティブなデプロイになります。 古い青色のデプロイは、段階的なプロセスを使用して使用を停止できます。 ただし、新しいデプロイに問題がある場合は中止することができ、トラフィックは古い青色のデプロイに残るか、それにリダイレクトできます。
Azure Mission-Criticalでは、デプロイ スタンプの一部としてインフラストラクチャ とアプリケーション を一緒にデプロイする青/緑のデプロイ アプローチをお勧めします。 そのため、インフラストラクチャまたはアプリケーションに変更をロールアウトすると、常に両方のレイヤーを含む緑色のデプロイが行われます。 このアプローチを使用すると、ユーザー トラフィックをリダイレクトする前に、インフラストラクチャとアプリケーションのエンドツーエンドに対する変更の影響を完全にテストおよび検証できます。 Azure プラットフォーム、リソース プロバイダー、IaC モジュールなどのダウンストリーム依存関係との互換性を検証できるため、このアプローチにより、変更のリリースに対する信頼度が向上し、ダウンタイムなしのアップグレードが可能になります。
設計上の考慮事項
テクノロジ機能。 Azure サービスの組み込みのデプロイ機能を利用します。 たとえば、Azure App Serviceでは、デプロイ後にスワップできるセカンダリ デプロイ スロットが提供されます。 Azure Kubernetes Service (AKS) では、各ノードで個別のポッドデプロイを使用し、サービス定義を更新できます。
デプロイ期間。 スタンプには、変更されたコンポーネントだけでなくインフラストラクチャとアプリケーションが含まれているため、デプロイの完了に時間がかかる場合があります。 ただし、すべてのコンポーネントが予期したとおりに動作しないリスクによって時間の問題がオーバーライドされるため、これは許容されます。
コストへの影響。 デプロイが完了するまで共存する必要がある 2 つのサイド バイ サイド デプロイにより、追加コストが発生します。
トラフィックの切り替え。 新しいデプロイが検証されたら、トラフィックを青色の環境から緑色の環境に移行する必要があります。 この移行には、環境間のユーザー トラフィックのオーケストレーションが必要です。 移行は完全に自動化する必要があります。
ライフサイクル。 ミッション クリティカルなデプロイ スタンプはエフェメラルと見なす必要があります。 有効期間の短いスタンプを使用すると、リソースがプロビジョニングされる前に、毎回新しい開始が作成されます。
設計の推奨事項
ブルー/グリーンデプロイアプローチを採用して、すべての運用環境の変更をリリースします。 すべてのインフラストラクチャとアプリケーションを、あらゆる種類の変更に対して毎回デプロイして、一貫した状態とダウンタイムを実現します。 環境は再利用できますが、ミッション クリティカルなワークロードにはお勧めしません。 各リージョンデプロイ スタンプは、1 つのリリースのライフサイクルに関連付けられたエフェメラルとして扱います。
Azure Front Door などのグローバル ロード バランサーを使用して、青と緑の環境間のユーザー トラフィックの自動移行を調整します。
トラフィックを移行するには、低トラフィックを使用する緑色のバックエンド エンドポイントをボリュームの重み (10% など) に追加します。 緑のデプロイのトラフィック量が少ないことを確認し、予想されるアプリケーションの正常性を提供したら、トラフィックを徐々に増やします。 その間、すぐには明らかではない可能性がある障害をキャッチするために、短いランプアップ期間を適用します。
すべてのトラフィックが切り替わったら、既存の接続から青いバックエンドを削除します。 たとえば、グローバル ロード バランサー サービスからバックエンドを削除し、キューをドレインし、他の関連付けをデタッチします。 これにより、セカンダリ運用インフラストラクチャを維持するコストを最適化し、新しい環境に構成ドリフトがないことを確認できます。
この時点で、古くて非アクティブなブルー環境の使用を停止します。 次のデプロイでは、青と緑を反転してプロセスを繰り返します。
サブスクリプション スコープのデプロイ
アプリケーションのスケール要件によっては、スケール ユニットとして機能する複数の運用サブスクリプションが必要になる場合があります。
ミッション クリティカルなアプリケーションのサブスクリプションのスコープ設定に関する推奨事項の概要については、次のビデオをご覧ください。
設計上の考慮事項
スケーラビリティ。 大量のトラフィックを含む大規模なアプリケーション シナリオの場合は、1 つのサブスクリプションのスケール制限によってスケーラビリティが制約されないように、複数の Azure サブスクリプション間でスケーリングするようにソリューションを設計します。
重要
複数のサブスクリプションを使用するには、CI/CD の複雑さが増す必要があり、適切に管理する必要があります。 そのため、1 つのサブスクリプションの制限が制限になる可能性が高い極端なスケールのシナリオでのみ、複数のサブスクリプションをお勧めします。
環境の境界。 運用環境、開発、テスト環境を別々のサブスクリプションにデプロイします。 この方法により、低い環境がスケール制限に貢献しないようにします。 また、明確な管理と ID 境界を提供することで、運用環境を汚染する低環境の更新のリスクも軽減されます。
ガバナンス。 複数の運用サブスクリプションが必要な場合は、専用のアプリケーション管理グループを使用して、ポリシーの集計境界を介したポリシーの割り当てを簡略化することを検討してください。
設計の推奨事項
各リージョンデプロイ スタンプを専用サブスクリプションにデプロイして、サブスクリプションの制限がアプリケーション全体ではなく、1 つのデプロイ スタンプのコンテキスト内でのみ適用されるようにします。 必要に応じて、1 つのリージョン内で複数のデプロイ スタンプを使用することを検討できますが、独立したサブスクリプション間でデプロイする必要があります。
グローバル共有リソースを専用サブスクリプションに配置して、一貫したリージョン サブスクリプションのデプロイを可能にします。 プライマリ リージョンに対して特殊なデプロイを使用しないようにします。
継続的な検証とテスト
テストは、アプリケーション コードとインフラストラクチャの正常性を完全に検証できる重要なアクティビティです。 具体的には、テストを使用すると、信頼性、パフォーマンス、可用性、セキュリティ、品質、スケールに関する標準を満たすことができます。 テストは、アプリケーション設計と DevOps 戦略の一部として適切に定義され、適用される必要があります。 テストは、ローカル開発者プロセス ( 内部ループ) の間、および完全な DevOps ライフサイクル ( 外部ループ) の一部として重要な懸念事項です。これは、リリース パイプライン プロセスから運用環境へのパスでコードが開始される場合です。
継続的な検証とテストの概要については、次のビデオをご覧ください。
このセクションでは、外部ループ テストに焦点を当てます。 さまざまな種類のテストについて説明します。
| Server1 | 説明 |
|---|---|
| 単体テスト | アプリケーション のビジネス ロジックが期待どおりに動作することを確認します。 コード変更の全体的な効果を検証します。 |
| スモーク テスト | インフラストラクチャとアプリケーション コンポーネントが使用できるかどうかを識別し、期待どおりに機能します。 通常は、単一の仮想ユーザー セッションのみがテストされます。 結果は、システムが期待される値と動作で応答する必要があります。 一般的なスモーク テスト シナリオには、Web アプリケーションの HTTPS エンドポイントへの到達、データベースのクエリ、アプリケーションでのユーザー フローのシミュレートなどがあります。 |
| UI テスト | アプリケーション ユーザー インターフェイスがデプロイされていること、およびユーザー インターフェイスの相互作用が期待どおりに機能することを検証します。 UI オートメーション ツールを使用して自動化を推進する必要があります。 UI テスト中、スクリプトは現実的なユーザー シナリオを模倣し、アクションを実行して意図した結果を達成するための一連の手順を完了する必要があります。 |
| ロード テスト | 事前に定義されたしきい値に達するまで、負荷を迅速に増加させ、または徐々に負荷を増やすことで、スケーラビリティとアプリケーションの動作を検証します。 ロード テストは、通常、定義された負荷の下でアプリケーション要件が満たされていることを確認するために、特定のユーザー フローを中心に設計されます。 |
| ストレス テスト | 既存のリソースをオーバーロードするアクティビティを適用して、ソリューションの制限を決定し、システムが正常に回復する機能を確認します。 メインの目標は、潜在的なパフォーマンスのボトルネックとスケール制限を特定することです。 逆に、システムのコンピューティング リソースをスケールダウンし、負荷の下での動作を監視し、回復できるかどうかを判断します。 |
| パフォーマンス テスト | 負荷テストとストレス テストの側面を組み合わせて、負荷の下でパフォーマンスを検証し、アプリケーション操作のベンチマーク動作を確立します。 |
| カオス テスト | システムに人工的な障害を挿入して、それがどのように反応するかを評価し、回復性対策、運用手順、軽減策の有効性を検証します。 インフラストラクチャ コンポーネントのシャットダウン、パフォーマンスの意図的な低下、アプリケーションエラーの導入は、シナリオが実際に発生したときにアプリケーションが想定どおりに動作することを確認するために使用できるテストの例です。 |
| 侵入テスト | アプリケーションとその環境が、想定されるセキュリティ体制の要件を満たしていることを確認します。 目標は、セキュリティの脆弱性を特定することです。 セキュリティ テストには、エンド ツー エンドのソフトウェア サプライ チェーンとパッケージの依存関係が含まれており、既知の一般的な脆弱性と露出 (CVE) のスキャンと監視が含まれます。 |
設計上の考慮事項
オートメーション。 自動テストは、アプリケーションまたはインフラストラクチャの変更をタイムリーかつ反復可能な方法で検証するために不可欠です。
テスト順序。 テストを実行する順序は、実行中のアプリケーション環境が必要な場合など、さまざまな依存関係があるため、重要な考慮事項です。 テスト期間も順序に影響します。 実行時間が短いテストは、可能な限りサイクルの早い段階で実行して、テストの効率を向上させる必要があります。
スケーラビリティの制限。 Azure サービスには、ソフト制限とハード制限が異なります。 ロード テストを使用して、システムが予想される運用環境の負荷の間にそれらを超えるリスクがあるかどうかを判断することを検討してください。 ロード テストは、自動スケーリングに適切なしきい値を設定する場合にも役立ちます。 自動スケーリングをサポートしていないサービスの場合、ロード テストは自動化された運用手順を微調整するのに役立ちます。
アクティブ/パッシブ ネットワーク コンポーネントやデータベースなどのシステム コンポーネントを適切にスケーリングできない場合は、制限が厳しい場合があります。 ストレス テストは、制限事項を特定するのに役立ちます。
障害モードの分析。 ソリューションの冗長性メカニズムを評価するには、アプリケーションと基になるインフラストラクチャに障害を導入し、その効果を評価することが不可欠です。 この分析中に、リスク、影響、影響の幅 (部分的または完全な停止) を特定します。 Mission Critical Online リファレンス実装用に作成された分析の例については、「個々のコンポーネントの停止リスク」を参照してください。
監視。 テスト結果を個別にキャプチャして分析し、時間の経過に伴う傾向を評価するためにそれらを集計する必要があります。 テスト結果の精度とカバレッジを継続的に評価する必要があります。
設計の推奨事項
次のビデオを参照して、回復性テストを Azure DevOps CI/CD パイプラインと統合する方法を確認します。
インフラストラクチャとアプリケーション コンポーネントに対するすべてのテストを自動化することで、一貫性を確保します。 CI/CD パイプラインにテストを統合して、必要に応じて調整して実行します。 テクノロジ オプションの詳細については、「 DevOps ツール」を参照してください。
すべてのテスト成果物をコードとして扱います。 これらは、他のアプリケーション コード成果物と共に維持およびバージョン管理する必要があります。
テスト インフラストラクチャの SLA を、デプロイおよびテスト サイクルの SLA に合わせます。
すべてのデプロイの一部としてスモーク テストを実行します。 また、広範なロード テストとストレス テストとカオス テストを実行して、アプリケーションのパフォーマンスと操作性が維持されていることを検証します。
- 実際のピーク使用パターンを反映した負荷プロファイルを使用します。
- ロード テストと同時にカオス実験と障害挿入テストを実行します。
ヒント
Azure Chaos Studio は、カオス実験ツールのネイティブ スイートです。 このツールを使用すると、カオス実験を簡単に実行し、Azure サービスとアプリケーション コンポーネント内に障害を挿入できます。
Chaos Studio は、一般的な障害シナリオ用の組み込みのカオス実験を提供し、インフラストラクチャとアプリケーション コンポーネントを対象とするカスタム実験をサポートします。
ロード テストやスモーク テストにレコードの作成などのデータベース操作が必要な場合は、特権が低下したテスト アカウントを使用し、テスト データを実際のユーザー コンテンツから分離できるようにします。
既知の CVE のエンド ツー エンドのソフトウェア サプライ チェーンとパッケージの依存関係をスキャンして監視します。
- GitHub リポジトリの Dependabot を使用して、リポジトリが依存するパッケージとアプリケーションの最新リリースで自動的に最新であることを確認します。
コードとしてのインフラストラクチャのデプロイ
コードとしてのインフラストラクチャ (IaC) は、インフラストラクチャ定義を、他のアプリケーション成果物と共にバージョン管理されたソース コードとして扱います。 IaC を使用すると、環境間でのコードの一貫性が向上し、自動デプロイ中の人的エラーのリスクが排除され、追跡可能性とロールバックが提供されます。 青/緑のデプロイでは、完全に自動化されたデプロイで IaC を使用することが不可欠です。
ミッション クリティカルな IaC リポジトリには、グローバル リソースとリージョン リソースにマップされる 2 つの異なる定義があります。 これらの種類のリソースの詳細については、 コア アーキテクチャ パターンに関するページを参照してください。
設計上の考慮事項
反復可能なインフラストラクチャ。 ミッション クリティカルなワークロードを、毎回同じ環境を生成する方法でデプロイします。 IaC はプライマリ モデルである必要があります。
オートメーション。 すべてのデプロイを完全に自動化する必要があります。 人間のプロセスはエラーが発生しやすいです。
設計の推奨事項
IaC を適用して、すべての Azure リソースが宣言型テンプレートで定義され、ソース管理リポジトリに保持されるようにします。 テンプレートがデプロイされ、CI/CD パイプラインを介してソース管理からリソースが自動的にプロビジョニングされます。 命令型スクリプトを使用することはお勧めしません。
すべての環境に対する手動操作を禁止します。 唯一の例外は、完全に独立した開発環境です。
DevOps ツール
DevOps プロセスは全体的な機能とアプリケーションの設計に影響を与えるので、デプロイ ツールの効果的な使用は全体的な信頼性にとって重要です。 たとえば、フェールオーバーとスケーリングの操作は、DevOps ツールによって提供される自動化に依存する場合があります。 エンジニアリング チームは、全体的なワークロードに関して、デプロイ サービスが利用できないことの影響を理解する必要があります。 デプロイ ツールは、信頼性が高く高可用性である必要があります。
Microsoft は、ミッション クリティカルなアプリケーションを効果的にデプロイおよび管理できる 2 つの Azure ネイティブ ツールセット (GitHub Actionsと Azure Pipelines) を提供しています。
設計上の考慮事項
テクノロジ機能。 GitHub と Azure DevOps の機能は重複しています。 これらを一緒に使用して、両方を最大限に活用できます。 一般的な方法は、デプロイに Azure Pipelines を使用しているときに、GitHub.com または GitHub AE にコード リポジトリを格納することです。
複数のテクノロジを使用する場合に追加される複雑さに注意してください。 全体的な信頼性に対して豊富な機能セットを評価します。
リージョンの可用性。 最大の信頼性の観点からは、単一の Azure リージョンへの依存関係は運用上のリスクを表します。
たとえば、トラフィックがリージョン 1 とリージョン 2 の 2 つのリージョンに分散しているとします。 リージョン 2 は、Azure DevOps ツール インスタンスをホストします。 リージョン 2 で障害が発生し、インスタンスが使用できないとします。 リージョン 1 では、すべてのトラフィックが自動的に処理され、適切なフェールオーバー エクスペリエンスを提供するために追加のスケール ユニットをデプロイする必要があります。 ただし、リージョン 2 での Azure DevOps の依存関係のため、 を実行することはできません。
データ レプリケーション。 メタデータ、パイプライン、ソース コードなどのデータは、リージョン間でレプリケートする必要があります。
設計の推奨事項
どちらのテクノロジも 1 つの Azure リージョンでホストされるため、ディザスター リカバリー戦略が制限される可能性があります。
GitHub Actionsはビルド タスク (継続的インテグレーション) に適していますが、複雑なデプロイ タスク (継続的デプロイ) の機能が不足している可能性があります。 Azure DevOps の豊富な機能セットを考えると、ミッション クリティカルなデプロイに推奨されます。 ただし、トレードオフを評価した後で選択する必要があります。
デプロイ ツールの可用性 SLA を定義し、より広範なアプリケーション信頼性要件との整合性を確保します。
アクティブ/パッシブまたはアクティブ/アクティブのデプロイ構成を使用する複数リージョンのシナリオでは、デプロイ ツールセットをホストするプライマリ リージョンが使用できなくなった場合でも、フェールオーバー オーケストレーションとスケーリング操作が引き続き機能することを確認してください。
ブランチ戦略
分岐には多くの有効な方法があります。 最大限の信頼性を確保する戦略を選択する必要があります。 適切な戦略により、並列開発が可能になり、開発から運用環境への明確なパスが提供され、高速リリースがサポートされます。
設計上の考慮事項
アクセスを最小限に抑えます。 開発者は 、feature/* ブランチと fix/* ブランチで作業を行う必要があります。 これらの分岐は、変更のエントリ ポイントになります。 ブランチ戦略の一環として、ロールベースの制限をブランチに適用する必要があります。 たとえば、管理者のみがリリース ブランチを作成したり、ブランチの名前付け規則を適用したりできるようにします。
緊急時の高速プロセス。 分岐戦略では、修正プログラムをできるだけ早くメインにマージできるようにする必要があります。 そうすることで、将来のリリースには修正プログラムが含まれており、問題の繰り返しは回避されます。 このプロセスは、緊急の問題に対処する軽微な変更にのみ使用し、それを抑制して使用します。
設計の推奨事項
-
重要
機能の作業とリリースを最小限に抑えて詳しく説明する分岐戦略を作成し、ブランチ ポリシーとアクセス許可を使用して戦略が適切に適用されるようにします。
自動テスト プロセスをトリガーして、コード変更コントリビューションが受け入れられる前に検証します。 チーム メンバーも変更を確認する必要があります。
メイン ブランチは、主に統合テストに使用される、継続的に前進する安定したブランチとして扱います。
- PR を介してのみメインに変更が加えられたことを確認します。 直接コミットを禁止するには、ブランチ ポリシーを使用します。
- PR がメインにマージされるたびに、統合環境に対するデプロイが自動的に開始されます。
- メインブランチは安定していると見なす必要があります。 いつでもメインからリリースを作成することは安全です。
メイン ブランチから作成され、運用環境へのデプロイに使用される専用のリリース/* ブランチを使用します。 release/* ブランチはリポジトリに残る必要があり、リリースにパッチを適用するために使用できます。
修正プログラム プロセスを文書化し、必要な場合にのみ使用します。 修正/ * ブランチに修正プログラムを作成し、その後リリース ブランチにマージし、運用環境に展開します。
DevOps 用 AI
CI/CD パイプラインで AIOps 手法を適用して、従来のテスト アプローチを補完できます。 これにより、潜在的な回帰または低下を検出でき、潜在的な悪影響を防ぐためにデプロイを先取りして停止できます。
設計上の考慮事項
テレメトリ データの量。 CI/CD パイプラインと DevOps プロセスは、機械学習モデルに対してさまざまなテレメトリを生成します。 テレメトリの範囲は、テスト結果とデプロイの結果から、複合デプロイ ステージのテスト コンポーネントに関する運用データまでです。
スケーラビリティ。 抽出、変換、読み込み (ETL) などの従来のデータ処理アプローチでは、デプロイ テレメトリとアプリケーションの監視データの増加に対応するためにスループットをスケーリングできない場合があります。 データ仮想化などの ETL やデータ移動を必要としない最新の分析アプローチを使用して、AIOps モデルによる継続的な分析を可能にすることができます。
デプロイの変更。 デプロイの結果に対する自動分析と関連付けのために、デプロイの変更を格納する必要があります。
設計の推奨事項
収集する DevOps プロセス データとその分析方法を定義します。 テレメトリは、各デプロイ内のテスト実行メトリックや変更の時系列データなど、重要です。
- AIOps モデル内の分析と相関関係のために、ステージング環境、テスト環境、および運用環境からアプリケーション監視データを公開します。
スキーマと動作の変更に対処するための自動特徴エンジニアリングを使用して予測を提供するために、コンテキスト対応と依存関係に対応した分析モデルを開発します。
デプロイ パイプライン内で最適なトレーニング済みモデルを登録してデプロイすることで、モデルを運用化します。
次のステップ
セキュリティに関する考慮事項を確認します。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示