次の方法で共有

安全なデプロイの実践に関する推奨事項

  • [アーティクル]

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

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

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

主要な設計戦略

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

変更、特にデータベース、スキーマ、その他のステートフル コンポーネントの変更のロールバックは複雑になる場合があります。 SDP ガイドラインでは、ワークロードのデータ資産設計に従ってデータ変更を処理する方法について明確な指示を提供する必要があります。 同様に、SDP が無視されず、修正プログラムまたはその他の最小化作業が安全に実行されるように、ロールフォワードは慎重に処理する必要があります。

緊急デプロイのためのプロトコルを確立する

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

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

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

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

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

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

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

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

緊急 SDP プロトコル

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

  • 昇格および承認ステージのアクセラレーション。

  • スモーク テストおよび統合テストのアクセラレーション。

  • ベイク時間の短縮。

場合によっては、緊急事態のために品質およびテスト ゲートが制限される場合がありますが、ゲートは不定期の演習としてできるだけ早く実行する必要があります。 緊急時に SDP アクセラレーションを承認できる人物と、アクセラレーションを承認するために満たす必要がある条件を必ず定義してください。 緊急 SDP プロトコルを緊急対応計画と調整して、すべての緊急事態が同じプロトコルに従って確実に処理されるようにします。

考慮事項

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

Azure ファシリテーション

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

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

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

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

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

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

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

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

例

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

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

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

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