安全なデプロイプラクティスのためのアーキテクチャ戦略

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

OE:11 ワークロードの安全な展開プラクティスを明確に定義します。 小規模かつ段階的で、品質が保証されるリリース方法の理想を強調して示します。 最新のデプロイ パターンと段階的公開手法を使用してリスクを制御します。 定期的なデプロイと、緊急または修正プログラムのデプロイを考慮します。

このガイドでは、安全なデプロイ プラクティス (SDP) を使用するための推奨事項について説明します。 安全なデプロイ プロセスと手順では、ワークロードを安全に変更してデプロイする方法を定義します。 SDP を実装するには、リスク管理の観点からデプロイについて考える必要があります。 SDP を実装すると、デプロイにおける人的エラーのリスクを最小限に抑え、問題のあるデプロイによるユーザーへの影響を制限できます。

安全なデプロイ プラクティスを実装する際に留意すべき重要なガイドラインが 4 つあります。

  • 安全性と一貫性: 運用ワークロードに対するすべての変更には本質的にリスクが伴うため、安全性と一貫性を重視して行う必要があります。

  • 段階的公開: 段階的公開デプロイ モデルを採用することで、デプロイによって引き起こされる問題の潜在的な影響範囲を最小限に抑えることができます。

  • 正常性モデリング: 展開は、段階的な公開の各フェーズを開始する前に、正常性チェックに合格する必要があります。

  • 問題の検出: 問題が検出された場合は、デプロイを直ちに停止し、回復を開始する必要があります。

次のセクションでは、これらの各ポイントに関する詳細な推奨事項を示します。

デプロイの安全性と一貫性を確保する

アプリケーション コードの更新、コードとしてのインフラストラクチャ (IaC)、機能フラグ、または構成の更新プログラムをデプロイする場合でも、ワークロードにリスクが生じます。 運用環境への "低リスク" のデプロイはありません。 すべてのデプロイは標準のパターンに従う必要があります。また、一貫性を確保し、ヒューマン エラーのリスクを最小化するために自動化するようにします。 ワークロードのサプライ チェーンとデプロイ パイプラインが信頼性が高く、セキュリティで保護され、明確に定義されたデプロイ標準を備えていることが重要です。 すべてのデプロイを潜在的なリスクとして扱い、すべてのデプロイを同じレベルのリスク管理の対象にします。 リスクは存在しますが、ワークロードに対して定期的な変更をデプロイし続ける必要があります。 定期的な更新をデプロイできないと、デプロイを通じて対処する必要があるセキュリティの脆弱性など、他のリスクが発生します。 詳細については、「ワークロード開発サプライ チェーンの設計に関する推奨事項」を参照してください。

頻度の低い大規模なデプロイよりも、頻度の高い小規模なデプロイをお勧めします。 小規模な変更の方が、問題が発生したときに容易に解決できます。頻繁にデプロイすることで、チームがデプロイ プロセスに対する自信を築くこともできます。 また、デプロイ中に異常が発生した場合は、ワークロード プロセスを確認して運用環境から学習することも重要です。 インフラストラクチャやロールアウトの設計に弱点が見つかる場合があります。 デプロイ中に問題が発生した場合は、SDP プロセスの一環として "責任の所在を問わない" 事後検証を実施し、インシデントに関する教訓を得るようにします。

段階的公開モデルを採用する

デプロイの問題が発生した場合、目標は、できるだけ早く検出し、エンド ユーザーへの影響を最小限に抑えることです。 この目標を達成するために、段階的ロールアウト デプロイ モデル ("段階的公開モデル" とも呼ばれます) を実装します。 カナリア展開は、段階的な導入の代表的な例です。 このデプロイ モデルでは、内部または外部ユーザーの小規模なグループが最初に新しい機能を受け取ります。 最初のグループで新しいバージョンが問題なく実行されると、ユーザー全体で新しいバージョンが実行されるまで、この機能は順次大きなグループにデプロイされていきます。 機能フラグは、通常、カナリア デプロイの対象ユーザーに対して新しいバージョンを有効にするために使用されます。

もう 1 つの一般的なデプロイ モデルは、ブルーグリーン アプローチです。 このモデルでは、ワークロード インフラストラクチャの 2 つの同一セット (プール) がデプロイされます。 どちらのプールも、完全な運用負荷を処理できます。 最初の (青色の) プールでは、すべてのユーザーがアクセスする展開の最新バージョンが実行されています。 2 つ目の (グリーン) プールは新しい機能で更新され、内部的にテストされます。 内部テストの後、運用トラフィックのサブセットがブルー プールからグリーン プールにルーティングされます。 カナリア デプロイと同様に、ロールアウトは段階的に行われます。これは、より大きなロールアウトを順次実施して、より多くのトラフィックをグリーン プールに移行するためです。 ロールアウトが完了すると、更新プールがブルー プールになり、グリーン プールは次のデプロイの準備が整います。 2 つのプールは、誤動作から保護するために論理的に分離されます。 一度に 1 つのスタンプにデプロイすることで、デプロイ スタンプ設計パターンを使用するワークロードにブルーグリーン モデルのバリエーションをデプロイできます。

どちらのモデルにおいても、ロールアウトの各フェーズ間の時間は、ワークロードの正常性メトリックを監視するのに十分な長さである必要があります。 異なるリージョンのユーザーや異なるタスクを実行するユーザーがワークロードを通常の容量で使用する時間を確保できるように、ロールアウト グループ間で十分な "ベイク時間" (ロールアウト グループ間の時間) を設ける必要があります。 ベイク時間は、分単位ではなく、時間および日単位で測定する必要があります。 また、1 日の間のさまざまなタイムゾーンや使用パターンを考慮できるように、ロールアウト グループごとにベイク時間を増やす必要もあります。

AI の機会: 手動ロールアウトのチューニングにより、摩擦が生じ、デプロイが遅くなります。 AI は、主観的な意思決定をデータドリブンの推奨事項に置き換えるため、ロールアウトを加速し、インシデントを減らします。

限られた生成 AI の実装から始めます。 モデルにデプロイ ドキュメント、コード レビュー、インシデント履歴への安全なアクセス権を付与して、ロールアウト戦略とパラメーターを分析して提案します。

高度なエージェント型ソリューションは、カナリア テストの割合、展開のタイミング、ターゲット セグメントを予測することができます。 展開ツールと統合すると、ロールアウト構成が自動的に更新されます。 これらのソリューションには、より深い統合、管理された書き込みアクセス、プラットフォームのサポートが必要です。

カスタム予測モデルは、より高い精度を提供しますが、トレーニング インフラストラクチャと機械学習の専門知識に大きな投資が必要です。 ほとんどのチームでは実用的ではない可能性があります。

堅牢なワークロード正常性モデルを開発する

監視プラットフォームと信頼性戦略の一環として、堅牢な正常性モデルを開発します。 正常性モデルでは、ワークロードのコンポーネントと全体的な正常性を詳細に可視化する必要があります。 ロールアウト中に、エンド ユーザーに関連する正常性の変化に関するアラートを受け取った場合は、直ちにロールアウトを停止し、アラートの原因を調査して次の行動方針を判断する必要があります。 エンド ユーザーから報告された問題がなく、ベイク時間を通してすべての正常性インジケーターがグリーンのままである場合は、ロールアウトを続行する必要があります。 ユーザーから報告された問題や負の正常性シグナルが欠如していることで問題が隠れていないことを確認するために、正常性モデルに使用状況メトリックを含めるようにしてください。 詳細については、「正常性モデルの構築」を参照してください。

障害検出メカニズムを実装する

デプロイによってロールアウト グループのいずれかで問題が発生した場合、ロールアウトは直ちに停止する必要があります。 アラートを受信したらすぐに、問題の原因と影響の重大度の調査を実行する必要があります。 問題からの回復には次のものが含まれます。

  • デプロイで行われた変更を元に戻し、最後に確認された動作中の構成に戻すことで、デプロイをロールバックします。

  • 展開の最中に問題に対処することで、展開スケジュールをロールフォワードします。 修正プログラムを適用するか、問題を最小限に抑えることで、ロールアウト中の問題に対処できます。

  • 最後に確認された動作構成を使用することで、新しいインフラストラクチャをデプロイします。

変更、特にデータベース、スキーマ、その他のステートフル コンポーネントの変更のロールバックは複雑になる場合があります。 SDP ガイドラインでは、ワークロードのデータ資産設計に従ってデータ変更を処理する方法について明確な指示を提供する必要があります。 同様に、ロールフォワードの実施にあたっては、SDP が軽視されないよう、またホットフィックスやその他の影響を最小限に抑える措置が安全に行われるよう、細心の注意を払う必要があります。

展開用安全ガードレールを確立する

  • 必要に応じてロールバックおよびロールフォワードできるように、ビルド成果物全体にバージョン管理を実装します。

  • Gitflow や環境ベースの分岐構造ではなく、リリース フローまたはトランクベースの分岐構造を使用して、開発チーム全体で緊密に同期されたコラボレーションを実施します。

  • SDP を可能な限り自動化します。 IaC およびアプリケーションの継続的インテグレーションと継続的デリバリー (CI/CD) プロセスの自動化に関する詳細なガイダンスについては、「自動化を実装するための推奨事項」を参照してください。

  • CI プラクティスを使用して、コードの変更を定期的にリポジトリに統合します。 CI プラクティスは、統合の競合を特定し、大規模でリスクの高いマージの可能性を減らすのに役立ちます。 詳細については、「継続的インテグレーション ガイド」を参照してください。

  • 機能フラグを使用して、運用環境で新機能や変更を選択的に有効または無効にします。 機能フラグは、新しいコードの公開を制御し、問題が発生した場合にデプロイをすばやくロールバックするのに役立ちます。

  • 運用環境をミラーリングするステージング環境に変更をデプロイします。 プラクティス環境を使用すると、ライブ環境にデプロイする前に、制御された設定で変更をテストできます。

  • コード レビュー、セキュリティ スキャン、コンプライアンス チェックなど、デプロイ前チェックを確立して、変更を安全にデプロイできることを確認します。

    1 種類のテストだけに依存しないでください。 テストによって、さまざまなクラスのエラーがキャッチされます。 たとえば、コントラクトの安定性テストでは API 図形に互換性があるかどうかを検証し、動作テストでは API の機能が正しいかどうかを検証します。 ネットワーク セキュリティ規則への変更をデプロイしようとしている場合は、最初に影響をシミュレートして、重要なトラフィックを誤ってブロックして停止を引き起こさないようにします。 リリースによって NSG または Azure Virtual Network Manager のセキュリティ管理者ルールが変更される場合は、デプロイ前チェックにネットワーク ポリシー シミュレーションを含めてください。 ルール影響アナライザー Azure Network Watcher、適用前にライブ トラフィック パターンに対して提案されたルールの変更を検証し、重要なアプリケーションと管理フローが意図せずにブロックされないようにすることができます。 このチェックにより、ロールアウトによって発生する停止の可能性が低くなります。 分析は使用可能なトラフィック データと同じくらい完全であるため、段階的なデプロイとロールバックの計画で使用する必要があります。

  • サーキット ブレーカーを実装して、問題が発生しているサービスへのトラフィックを自動的に停止します。 そうすることで、システムのさらなる機能低下を防ぐのに役立ちます。

緊急 SDP プロトコル

修正プログラム、またはセキュリティ侵害や脆弱性の漏洩などの緊急の問題に合わせて、SDP を調整する方法を定義する規範的なプロトコルを確立します。 たとえば、緊急 SDP プロトコルには次のようなものが含まれる場合があります。

  • 昇格および承認ステージの加速。

  • スモークテストと統合テストの迅速化。

  • ベイク時間の短縮。

状況によっては、緊急事態により品質管理やテストのチェックポイントに制約が生じる場合もありますが、それでもチェックポイントは、通常とは異なる手順による作業として、可能な限り迅速に実行する必要があります。 緊急時に SDP アクセラレーションを承認できる人物と、アクセラレーションを承認するために満たす必要がある条件を必ず定義してください。 緊急 SDP プロトコルを緊急対応計画と調整して、すべての緊急事態が同じプロトコルに従って確実に処理されるようにします。

安全な使用停止の計画と実行

コンポーネントの削除または非推奨化は、可能な最もリスクの高い変更の 1 つです。 一度削除すると、多くの場合、リソースは適切に使用されなくなり、復旧が困難になる可能性があります。 動作していないように見えるものや重要ではないと考えられるものでも、重要な隠れた依存関係をサポートし続けていることがあります。 すべての削除を元に戻せないものとして扱い、次のような意図的で安全優先のアプローチに従います。

  • 非アクティブ状態を検証します。 リソースが本当に使用されていないことを確認します。 完全なユーザーまたはビジネス サイクル全体の非アクティブ状態の明確なインジケーターを定義します。 要求、ルート ヒット、キューの深さの変更、機能フラグの評価、DNS クエリなどのアクティビティが表示される場合は、続行する前に調査して確認してください。

  • 削除前の状態を保持します。 リソースのスナップショット、エクスポート、またはバックアップを作成し、破棄またはレビュー日でタグ付けします。

  • 削除する前に無効にします。 可能な場合は、コンポーネントをすぐに削除するのではなく、無効またはオフライン モードに移動します。 これにより、非表示の依存関係を安全に公開できます。 コンプライアンスまたはセキュリティ要件で即時削除が必要な場合にのみ、この手順をスキップしてください。

  • ウォッチ ウィンドウを使用して監視します。 通常の使用パターンとピーク時の使用パターンの両方をカバーするウォッチ ウィンドウを監視します。 この期間中に予期せぬ活動があれば、使用停止プロセスをリセットするべきです。

  • 残留参照をクリーンアップします。 完全な非アクティブ状態に自信を持ったら、削除されたコンポーネントへの関連する参照をクリーンアップします。

考慮事項

安全なデプロイ プラクティスの構築と維持は複雑です。 堅牢な標準を完全に実装できるかどうかは、ソフトウェア開発の多くの分野にわたるプラクティスの成熟度にかかっています。 自動化、IaC 専用インフラストラクチャの変更、一貫性のある分岐戦略、機能フラグ、その他のプラクティスは、安全なデプロイを確保するのに役立ちます。 このガイドを使用して、ワークロードを最適化し、プラクティスの進化に合わせて改善計画を通知します。

Azure ファシリテーション

  • Azure Pipelines と GitHub Actions は、承認ゲートを使用して多段階デプロイをサポートします。これは、デプロイの段階的公開ロールアウトの設計に役立ちます。

  • Azure App Service ステージング スロット を使用すると、コードのバージョン間の入れ替えが容易になります。 ステージング スロットは、ステージング環境でのテストに役立ち、ブルーグリーン デプロイにも使用できます。

  • Web アプリの機能フラグを Azure App Configuration に保存して管理します。 このサービスを使用すると、統合管理プレーンで機能を作成、変更、デプロイできます。

  • VM アプリケーションを使用して、仮想マシンにワークロード アプリケーションをデプロイします。

  • Azure ロード バランサーを使用してデプロイ戦略を実装し、ネイティブ リソースを使用してワークロード アプリケーションの正常性を公開します。

  • ルール影響アナライザー Azure Network Watcher、適用前にライブ トラフィック パターンに対して提案されたルールの変更を検証し、重要なアプリケーションと管理フローが意図せずにブロックされないようにすることができます。 このチェックにより、ロールアウトによって発生する停止の可能性が低くなります。 分析は使用可能なトラフィック データと同じくらい完全であるため、段階的なデプロイとロールバック計画で使用します。

  • アプリケーション正常性拡張機能を使用して、仮想マシン スケール セット インスタンス内からアプリケーションの正常性についてレポートします。 この拡張機能は、ローカル アプリケーション エンドポイントに対してプローブを実行し、アプリケーションから受信した TCP/HTTP(S) 応答に基づいて正常性状態を更新します。

  • Azure Logic Apps を使用して、アプリケーションが更新されるたびに新しいバージョンを作成します。 Azure ではアプリケーション バージョンの履歴が保持されており、以前のバージョンに戻したり、バージョンを昇格したりできます。

  • Azure Functions Flex Consumption は、更新中にインスタンスを徐々に置き換えます。これにより、デプロイのロールアウト中の中断を減らすことができます。 この動作は、依存関係の検証、ロールバックドリル、バージョン互換性テストの代わりにではなく、ブラスト半径の削減として扱います。

  • 多くの Azure Database サービスには、ロールバックに役立つポイントインタイム リストア機能が用意されています。 ポイントインタイム リストアをサポートするサービスには次のものがあります。

例

このデプロイ モデルの使用方法の例については、「Azure Kubernetes Service (AKS) クラスターのブルーグリーン デプロイ」アーキテクチャ ガイドを参照してください。

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

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

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

  • Last updated on