次の方法で共有

Azure でのミッション クリティカルなワークロードのデプロイとテスト

  • [アーティクル]

失敗したデプロイと誤ったリリースは、アプリケーションの停止の一般的な原因です。 デプロイとテストへのアプローチは、ミッション クリティカルなアプリケーションの全体的な信頼性において重要な役割を果たします。

デプロイとテストは、ミッション クリティカルなワークロードの一貫した結果を確保するために、すべてのアプリケーションとインフラストラクチャの運用の基礎を形成する必要があります。 毎週、毎日、またはより頻繁にデプロイする準備をしてください。 継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインを設計して、これらの目標をサポートします。

この戦略では、次を実装する必要があります。

  • 厳密なプレリリース テスト。 更新プログラムでは、アプリケーションの正常性を危険にさらす可能性のある欠陥、脆弱性、またはその他の要因を発生させるべきではありません。

  • 透過的なデプロイ。 ユーザーに影響を与えることなく、いつでも更新プログラムをロールアウトできる必要があります。 ユーザーは、中断することなく、アプリケーションとの対話を続行できる必要があります。

  • 高可用性の操作。 アプリケーションの全体的な信頼性をサポートするには、デプロイとテストのプロセスとツールを高可用性にする必要があります。

  • 一貫性のあるデプロイ プロセス。 同じアプリケーション成果物とプロセスを使用して、異なる環境にインフラストラクチャとアプリケーション コードをデプロイする必要があります。 エンドツーエンドの自動化は必須です。 手動による介入は、信頼性のリスクが生じる可能性があるため、回避する必要があります。

この設計領域では、ダウンタイムを最小限に抑え、アプリケーションの正常性と可用性を維持することを目的として、デプロイとテストのプロセスを最適化する方法に関する推奨事項を提供します。

重要

この記事は、Azure Well-Architected Framework ミッション クリティカルなワークロード シリーズの一部です。 このシリーズに慣れていない場合は、「ミッション クリティカルなワークロードとは」から開始することをお勧めします。

ダウンタイムなしのデプロイ

ダウンタイムのないデプロイの概要については、次のビデオをご覧ください。


ダウンタイムゼロのデプロイを実現することは、ミッション クリティカルなアプリケーションの基本的な目標です。 営業時間中に新しいリリースがロールアウトされた場合でも、アプリケーションは毎日利用できる必要があります。 リソースをエフェメラルとして扱うかどうかなどの主要な設計上の決定を推進するために、デプロイ プロセスを定義および計画するために、前もって取り組みます。

ダウンタイムなしのデプロイを実現するには、既存のインフラストラクチャの横に新しいインフラストラクチャをデプロイし、十分にテストし、エンド ユーザー トラフィックを移行してから、以前のインフラストラクチャの使用を停止します。 スケール ユニット アーキテクチャなどの他のプラクティスも重要です。

この図に示すように、Mission-Critical Online と Azure Mission-Critical Connected のリファレンス実装は、このデプロイ アプローチを示しています。

ダウンタイムゼロの DevOps パイプラインリファレンスを示す図。

アプリケーション環境

アプリケーション環境の推奨事項の概要については、次のビデオをご覧ください。


デプロイ操作を検証してステージングするには、さまざまな種類の環境が必要です。 型の機能とライフサイクルは異なります。 運用環境を反映し、有効期間が長い環境もあれば、運用よりも有効期間が短く、機能が少ない環境もあります。 開発サイクルの早い段階でこれらの環境を設定すると、機敏性、運用環境と運用前の資産の分離、運用環境にリリースする前の運用の徹底的なテストを確保するのに役立ちます。 すべての環境に可能な限り運用環境が反映されている必要がありますが、必要に応じて低い環境に簡略化を適用できます。 この図は、ミッション クリティカルなアーキテクチャを示しています。

ミッション クリティカルな Azure アーキテクチャを示す図。

いくつかの一般的な考慮事項があります。

  • コンポーネントは、環境間で共有しないでください。 考えられる例外は、ファイアウォールや合成テスト データのソースの場所などのダウンストリーム セキュリティ アプライアンスです。

  • すべての環境で、Terraform や Azure Resource Manager (ARM) テンプレートなどのコードとしてのインフラストラクチャ (IaC) 成果物を使用する必要があります。

開発環境

エフェメラル開発環境と自動機能検証に関する情報については、次のビデオをご覧ください。


設計上の考慮事項

  • 機能。 開発環境では、信頼性、容量、およびセキュリティの要件が低い方が許容されます。

  • ライフサイクル。 開発環境は必要に応じて作成し、短時間存在する必要があります。 ライフサイクルが短いほど、コード ベースからの構成のずれを防ぎ、コストを削減できます。 また、開発環境は多くの場合、機能ブランチのライフサイクルを共有します。

  • 密度。 Teams では、並列機能開発をサポートするために複数の環境が必要です。 これらは、1 つのサブスクリプション内で共存できます。

設計の推奨事項

  • 開発目的でコンテキストが設定された専用サブスクリプションに環境を保持します。

  • 自動化されたプロセスを使用して、機能ブランチから開発環境にコードをデプロイします。

テスト環境またはステージング環境

これらの環境は、テストと検証に使用されます。 多くのテスト サイクルが実行され、運用環境へのバグのないデプロイが保証されます。 ミッション クリティカルなワークロードに対する適切なテストについては、「継続的な検証とテスト」セクションで説明されています。

設計上の考慮事項

  • 機能。 これらの環境には、信頼性、容量、およびセキュリティのための運用環境が反映されている必要があります。 運用環境の負荷がない場合は、合成ユーザー負荷を使用して、現実的なメトリックと貴重な正常性モデリング入力を提供します。

  • ライフサイクル。 これらの環境は有効期間が短くなります。 これらは、テストの検証が完了した後に破棄する必要があります。

  • 密度。 1 つのサブスクリプションで多数の独立した環境を実行できます。 また、専用サブスクリプション内の複数の環境の使用も検討する必要があります。

Note

ミッション クリティカルなアプリケーションは、厳格なテストを受ける必要があります。

1 つの環境で異なるテスト機能を実行できます。場合によっては、実行する必要があります。 たとえば、混乱テストで意味のある結果を得るには、最初にアプリケーションを負荷の下に置き、挿入された障害に対するアプリケーションの応答を理解できるようにする必要があります。 そのため、カオス テストとロード テストは通常、並列で実行されます。

設計の推奨事項

  • 運用環境に似たテストと検証を有効にするために、少なくとも 1 つのステージング環境に運用環境が完全に反映されていることを確認します。 この環境内の容量は、テスト アクティビティの実行に基づいて柔軟に行うことができます。

  • 合成ユーザー 負荷を生成して、いずれかの環境で変更を行う現実的なテスト ケースを提供します。

    Note

    Mission Critical Online リファレンス実装では、ユーザー ロード ジェネレーターの例を示します。

  • 開発およびリリース サイクル内のステージング環境とその目的の数を定義します。

運用環境

設計上の考慮事項

  • 機能。 アプリケーションの最高レベルの信頼性、容量、およびセキュリティ機能が必要です。

  • ライフサイクル。 ワークロードとインフラストラクチャのライフサイクルは変わりませんが、監視やログ記録を含むすべてのデータには特別な管理が必要です。 たとえば、バックアップと回復には管理が必要です。

  • 密度。 一部のアプリケーションでは、異なる運用環境を使用して、さまざまなクライアント、ユーザー、またはビジネス機能に対応することを検討できます。

設計の推奨事項

運用環境とより低い環境に対して明確なガバナンス境界を持つ。 その目標を達成するために、各環境の種類を専用のサブスクリプションに配置します。 このセグメント化により、低い環境でのリソース使用率が運用環境のクォータに影響を与えなくなります。 専用サブスクリプションでは、アクセス境界も設定されます。

エフェメラル ブルー/グリーン デプロイ

青/緑のデプロイ モデルには、少なくとも 2 つの同一のデプロイが必要です。 青色のデプロイは、運用環境でユーザー トラフィックを処理するアクティブなデプロイです。 緑色のデプロイは、トラフィックを受信するために準備およびテストされた新しいデプロイです。 緑のデプロイが完了してテストされると、トラフィックは徐々に青から緑に向けられます。 読み込み転送が成功すると、緑色のデプロイが新しいアクティブなデプロイになります。 古い青色のデプロイは、段階的なプロセスを使用して使用を停止できます。 ただし、新しいデプロイに問題がある場合は中止できます。トラフィックは、古い青色のデプロイに残るか、またはそれにリダイレクトすることができます。

Azure Mission-Critical では、デプロイ スタンプの一部としてインフラストラクチャ とアプリケーション を一緒にデプロイする青/緑のデプロイ アプローチをお勧めします。 そのため、インフラストラクチャまたはアプリケーションに変更をロールアウトすると、常に両方のレイヤーを含む緑色のデプロイになります。 この方法を使用すると、ユーザー トラフィックをリダイレクトする前に、インフラストラクチャとアプリケーションに対する変更の影響を完全にテストして検証できます。 Azure プラットフォーム、リソース プロバイダー、IaC モジュールなどのダウンストリーム依存関係との互換性を検証できるため、このアプローチにより、変更のリリースに対する信頼性が高くなり、ダウンタイムなしのアップグレードが可能になります。

設計上の考慮事項

  • テクノロジの機能。 Azure サービスの組み込みのデプロイ機能を利用します。 たとえば、Azure アプリ Service には、デプロイ後にスワップできるセカンダリ デプロイ スロットが用意されています。 Azure Kubernetes Service (AKS) では、各ノードで個別のポッド デプロイを使用し、サービス定義を更新できます。

  • デプロイ期間。 スタンプには変更されたコンポーネントだけでなくインフラストラクチャとアプリケーションが含まれているため、デプロイの完了に時間がかかる場合があります。 ただし、すべてのコンポーネントが予期したとおりに動作しないリスクによって時間の問題がオーバーライドされるため、これは許容されます。

  • コストへの影響。 デプロイが完了するまで共存する必要がある 2 つのサイド バイ サイドデプロイのため、追加コストが発生します。

  • トラフィックの遷移。 新しいデプロイが検証されたら、トラフィックを青色の環境から緑色の環境に移行する必要があります。 この移行には、環境間のユーザー トラフィックのオーケストレーションが必要です。 移行は完全に自動化する必要があります。

  • ライフサイクル。 ミッション クリティカルなデプロイ スタンプはエフェメラルと見なす必要があります。 有効期間の短いスタンプを使用すると、リソースがプロビジョニングされる前に、毎回新しい開始が作成されます。

設計の推奨事項

  • 青/緑のデプロイ アプローチを採用して、すべての運用環境の変更をリリースします。 すべてのインフラストラクチャとアプリケーションを、あらゆる種類の変更に対して毎回デプロイして、一貫性のある状態とダウンタイムを実現します。 環境は再利用できますが、ミッション クリティカルなワークロードにはお勧めしません。 各リージョンデプロイ スタンプは、1 つのリリースのライフサイクルに関連付けられたエフェメラルとして扱います。

  • Azure Front Door などのグローバル ロード バランサーを使用して、青と緑の環境間のユーザー トラフィックの自動移行を調整します。

  • トラフィックを移行するには、ボリュームの重み (10% など) に低いトラフィックを使用する緑色のバックエンド エンドポイントを追加します。 緑のデプロイのトラフィック量が少ないのが動作し、予想されるアプリケーションの正常性が提供されることを確認したら、トラフィックを徐々に増やします。 その間、短時間のランプアップ期間を適用して、すぐには明らかではない可能性がある障害をキャッチします。

    すべてのトラフィックが切り替わったら、既存の接続から青いバックエンドを削除します。 たとえば、グローバル ロード バランサー サービスからバックエンドを削除し、キューをドレインし、他の関連付けをデタッチします。 これにより、セカンダリ運用インフラストラクチャを維持するコストを最適化し、新しい環境に構成ドリフトが発生しないようにすることができます。

    この時点で、古くて非アクティブな青い環境を使用停止にします。 次のデプロイでは、青と緑の反転でプロセスを繰り返します。

サブスクリプション スコープのデプロイ

アプリケーションのスケール要件によっては、スケール ユニットとして機能する複数の運用サブスクリプションが必要になる場合があります。

ミッション クリティカルなアプリケーションのサブスクリプションのスコープに関する推奨事項の概要については、次のビデオをご覧ください。


設計上の考慮事項

  • スケーラビリティ。 大量のトラフィックを含む大規模なアプリケーション シナリオの場合は、1 つのサブスクリプションのスケール制限によってスケーラビリティが制約されないように、複数の Azure サブスクリプション間でスケーリングするソリューションを設計します。

    重要

    複数のサブスクリプションを使用するには、CI/CD の複雑さが増し、適切に管理する必要があります。 そのため、1 つのサブスクリプションの制限が制限になる可能性が高い極端なスケール シナリオでのみ、複数のサブスクリプションをお勧めします。

  • 環境の境界。 運用環境、開発環境、テスト環境を別々のサブスクリプションにデプロイします。 この方法により、低い環境がスケール制限に貢献しないようにします。 また、管理と ID の境界を明確にすることで、環境が低い更新によって運用環境が汚染されるリスクも軽減されます。

  • ガバナンス。 複数の運用サブスクリプションが必要な場合は、専用のアプリケーション管理グループを使用して、ポリシーの集計境界を介したポリシーの割り当てを簡略化することを検討してください。

設計の推奨事項

  • 各リージョンのデプロイ スタンプを専用サブスクリプションにデプロイして、サブスクリプションの制限がアプリケーション全体ではなく、1 つのデプロイ スタンプのコンテキスト内でのみ適用されるようにします。 必要に応じて、1 つのリージョン内で複数のデプロイ スタンプを使用することを検討できますが、独立したサブスクリプション間でデプロイする必要があります。

  • グローバル共有リソースを専用サブスクリプションに配置して、一貫したリージョン サブスクリプションのデプロイを有効にします。 プライマリ リージョンに特化したデプロイを使用しないでください。

継続的な検証とテスト

テストは、アプリケーション コードとインフラストラクチャの正常性を完全に検証できる重要なアクティビティです。 具体的には、テストを使用すると、信頼性、パフォーマンス、可用性、セキュリティ、品質、スケールに関する標準を満たすことができます。 テストは、アプリケーション設計と DevOps 戦略の一部として明確に定義され、適用される必要があります。 テストは、ローカル開発者プロセス ( 内部ループ) の間、および完全な DevOps ライフサイクル ( 外側のループ) の一部として重要な懸念事項です。これは、リリース パイプライン プロセスから運用環境へのパスでコードが開始されたときです。

継続的な検証とテストの概要については、次のビデオをご覧ください。


このセクションでは、外側のループ テストに焦点を当てます。 さまざまな種類のテストについて説明します。

テスト 説明
単体テスト アプリケーション ビジネス ロジックが期待どおりに動作することを確認します。 コード変更の全体的な効果を検証します。
煙のテスト インフラストラクチャとアプリケーション コンポーネントが使用可能で、期待どおりに機能するかどうかを識別します。 通常は、単一の仮想ユーザー セッションのみがテストされます。 結果は、システムが期待される値と動作で応答する必要があります。
スモーク テストの一般的なシナリオには、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/*行う必要があります。 これらの分岐は、変更のエントリ ポイントになります。 ロールベースの制限は、ブランチ戦略の一部としてブランチに適用する必要があります。 たとえば、管理者のみがリリース ブランチを作成したり、ブランチの名前付け規則を適用したりできるようにします。

  • 緊急時の高速プロセス。 分岐戦略では、修正プログラムを実用的な時点ですぐにマージ main できるようにする必要があります。 そうすることで、今後のリリースには修正プログラムが含まれており、問題の再発は回避されます。 このプロセスは、緊急の問題に対処する軽微な変更にのみ使用し、制約付きで使用します。

設計の推奨事項

  • ソース管理に GitHub の 使用に優先順位を付けます。

    重要

    機能の作業とリリースを最小限に抑える分岐戦略を作成し、ブランチ ポリシーとアクセス許可を使用して戦略が適切に適用されるようにします。

  • コード変更のコントリビューションが受け入れられる前に、自動テスト プロセスをトリガーして検証します。 チーム メンバーも変更を確認する必要があります。

  • このブランチは main 、主に統合テストに使用される、継続的に前方に移動する安定したブランチとして扱います。

    • 変更が PR 経由でのみ行 main われるようにします。 ブランチ ポリシーを使用して、直接コミットを禁止します。
    • PR がマージされるたびに、統合環境に main対するデプロイが自動的に開始されます。
    • ブランチは main 安定と見なす必要があります。 任意の時点から main リリースを作成しても安全です。

  • ブランチから作成され、運用環境へのデプロイにmain使用される専用release/*ブランチを使用します。 release/* ブランチはリポジトリに残る必要があり、リリースにパッチを適用するために使用できます。

  • 修正プログラム プロセスを文書化し、必要な場合にのみ使用します。 ブランチに修正プログラムを作成し、 fix/* その後リリース ブランチにマージし、運用環境に展開します。

DevOps のための AI

CI/CD パイプラインで AIOps 手法を適用して、従来のテスト アプローチを補完できます。 これにより、潜在的な回帰や低下を検出でき、潜在的な悪影響を防ぐためにデプロイを先取りして停止できます。

設計上の考慮事項

  • テレメトリ データの量。 CI/CD パイプラインと DevOps プロセスは、機械学習モデルに対してさまざまなテレメトリを出力します。 テレメトリの範囲は、テスト結果とデプロイの結果から、複合デプロイ ステージのテスト コンポーネントに関する運用データまでです。

  • スケーラビリティ。 抽出、変換、読み込み (ETL) などの従来のデータ処理アプローチでは、デプロイ テレメトリとアプリケーションの監視データの増加に対応するためにスループットをスケーリングできない場合があります。 データ仮想化などの ETL やデータ移動を必要としない最新の分析アプローチを使用して、AIOps モデルによる継続的な分析を有効にすることができます。

  • デプロイの変更。 デプロイの結果に対する自動分析と関連付けのために、デプロイの変更を格納する必要があります。

設計の推奨事項

  • 収集する DevOps プロセス データとその分析方法を定義します。 テレメトリは、テスト実行メトリックや、各デプロイ内の変更の時系列データなど、重要です。

    • AIOps モデル内の分析と相関関係のために、ステージング環境、テスト環境、および運用環境からアプリケーションの可観測性データを公開します。

  • MLOps ワークフローを採用します。

  • スキーマと動作の変更に対処するための自動化された特徴エンジニアリングを使用して予測を提供するために、コンテキスト対応および依存関係に対応する分析モデルを開発します。

  • デプロイ パイプライン内で最適なトレーニング済みモデルを登録してデプロイすることで、モデルを運用化します。

次のステップ

セキュリティに関する考慮事項を確認します。

Security