安全な展開方法に関する推奨事項

  • [アーティクル]

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

OE:11 ワークロードの安全なデプロイプラクティスを明確に定義します。 小規模で増分的な品質ゲートリリース方法の理想を強調します。 リスクを制御するには、最新のデプロイ パターンと段階的な公開手法を使用します。 定期的な展開と緊急または修正プログラムの展開のアカウント。

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

主要な設計戦略

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

  • 安全性と一貫性: 運用環境のワークロードに対するすべての変更は本質的に危険であり、安全性と一貫性に重点を置いて行う必要があります。

  • 段階的な露出: 段階的な露出デプロイ モデルを採用することで、デプロイによって発生する問題の潜在的な爆発半径を最小限に抑えることができます。

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

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

次のセクションでは、これらの各点に関する詳細な推奨事項について説明します。

安全性と一貫性

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

大規模な展開の頻度が低い場合は、小規模なデプロイを頻繁に行う方が適しています。 小さな変更は、問題が発生したときに簡単に解決でき、頻繁にデプロイすることで、チームがデプロイ プロセスに対する信頼を構築するのに役立ちます。 また、デプロイ中に異常が発生したときにワークロード プロセスを確認して、運用環境から学習することも重要です。 インフラストラクチャまたはロールアウトの設計に弱点が見つかる場合があります。 デプロイ中に問題が発生した場合は、 責任のない 事後分析が、インシデントに関する教訓をキャプチャするための SDP プロセスの一部であることを確認します。

段階的な露出の展開

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

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

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

正常性モデル

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

問題の検出

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

  • デプロイで行われた変更を元に戻し、最後の既知の動作構成に戻すことによって、デプロイをロールバックします。

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

  • 最新の既知の動作構成を使用した新しいインフラストラクチャのデプロイ。

変更 (特にデータベース、スキーマ、またはその他のステートフル コンポーネントの変更) のロールバックは複雑になる可能性があります。 SDP ガイドラインでは、ワークロードのデータ資産設計に従ってデータの変更に対処する方法に関する明確な指示を提供する必要があります。 同様に、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 ロード バランサーを使用してデプロイ戦略を実装し、ネイティブ リソースを使用してワークロード アプリケーションの正常性を公開します。

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

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

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

例

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

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

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

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