Microsoft AZ-400: リリース管理とデプロイ戦略 — 学習ガイド

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

こちらの一部です： Microsoft DevOps Engineer Expert AZ-400 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Azureでのリリース管理は、可用性を保護しつつフィードバックを加速させる、反復可能でポリシーに基づいたデリバリーを要とします。デプロイ戦略、ゲート付き検証、リングベースの公開、機能フラグによるダークローンチを習得することで、チームは安全性を犠牲にすることなく継続的にシップできます。Azure Pipelines、Azure Deployment Environments、Azure Front Door/Traffic Manager、およびAzure App Configurationは、プログレッシブデリバリー、マルチ環境オーケストレーション、監査可能な変更管理のためのまとまりのあるツールチェーンを提供します。このセクションでは、各機能をいつ、どのように使用するか、それらをどのように連携させるか、そして本番環境グレードのパイプラインで期待されるロールバックとドキュメント化の実践について説明します。

デプロイ戦略とプログレッシブデリバリー

ブルーグリーン（レッド/ブラック）は、現在の（ブルー）環境がトラフィックを処理している間に、新しいバージョンを並列環境（グリーン）にデプロイします。Azure App Serviceでは、デプロイスロットがブルーグリーンを実装します。ステージングにデプロイし、ウォームアップしてから、スロットスワップを実行します。ロールバックはスワップバックすることで瞬時に行えるため、ブルーグリーンは最速のロールバックオプションです。スロットスワップを「プレビュー付きスワップ」と組み合わせることで、トラフィックを移動する前にバインディングとアプリ設定を検証します。

カナリアデプロイは、まず少数のユーザーにデプロイし、健全性が維持されるにつれてトラフィックを段階的に増やします。Azureでは、カナリアを次のように実装します：

• Azure Front Doorの加重ルーティングを使用して、アプリケーション層でヘルスプローブとWAFを用いて古いバックエンドと新しいバックエンドの間でトラフィックを分割します。
• Azure Traffic Managerの加重エンドポイントを使用して、リージョンレベルの制御が必要な場合にDNSベースのグローバルカナリアを実現します。
• Ingress（例：NGINXのカナリアアノテーション）またはサービスメッシュのトラフィックスプリッティングによるAKSカナリア。ゲートは、次に進む前にエラーバジェット、レイテンシのパーセンタイル、彩度を評価する必要があります。

ローリングアップデートはインスタンスを段階的に置き換え、デュアルフリートのコストを回避します。AKSでは、maxSurgeとmaxUnavailableを使用してrollingUpdateを設定し、readiness/livenessプローブとPDBが可用性を保護することを確認します。VM Scale Setsでは、アプリケーションヘルスプローブを備えたローリングアップグレードポリシーを使用します。ローリングは経済的ですが、システム全体のリグレッションからの回復はブルーグリーンよりも遅くなります。

機能フラグはリリースとデプロイを分離します。ダークローンチは、デフォルトで無効化されたコードパスをシップし、機能を公開せずにインフラストラクチャを試します。フラグを使用して、コストのかかる移行をゲートし、UIを段階的に公開し、問題のある動作を迅速に停止します。これはカナリアとリングを補完します：広範囲にデプロイし、その後段階的に有効化します。

リングベースのデプロイは、コホート全体での段階的な公開を形式化します。R0（内部）、R1（カナリア顧客）、R2（1リージョン）、R3+（グローバル）などのリングを定義します。昇格基準は客観的でなければなりません：SLOへの準拠、Sev2以上のインシデントがないこと、許容可能なビジネスKPIなどです。リングをトラフィックシフト（Front Door/Traffic Manager）、環境チェック、承認ゲートと組み合わせて、早期に停止またはロールバックします。

プログレッシブなトラフィックシフトにおけるAzure Front DoorとTraffic Managerの比較：Front Doorはレイヤー7で動作し、即時の変更、ヘルスプローブ、セッションアフィニティ、パスベースのルーティング、加重分割を備えており、アプリ層のカナリアやA/Bテストに最適です。Traffic ManagerはDNSで動作します。ジオルーティング、クロスクラウドフェイルオーバー、またはリージョンレベルのカナリアに適していますが、DNS TTLの考慮事項があり、アプリケーション層の機能はありません。

環境、承認、ゲート

Azure Deployment Environmentsは、ガードレール付きで開発/テスト環境のプロビジョニングを標準化します。環境定義は、反復可能なスタックを記述するinfrastructure-as-codeテンプレート（Bicep/ARM/Terraform）です。定義はカタログ（サービスに登録されたGitリポジトリ）に存在し、バージョン管理された、発見可能な環境のブループリントを可能にします。開発者は、企業のポリシー（クォータ、RBAC、ネットワーキング）によって制約された開発/テストインスタンスをセルフサービスで利用でき、スノーフレークを排除し、下位環境を本番トポロジに合わせることができます。

承認は、必要な場合に人間が介在する（human-in-the-loop）制御を確立します。Azure Pipelinesでは：

• デプロイ前承認は、指定された承認者が同意するまでステージをブロックします。ステージングから本番への移行や、カナリアを超えるリングのエスカレーションなど、リスクの高い移行に使用します。
• デプロイ後承認は、リリースが完了とマークされる前に、検証アクティビティ（UATのサインオフ、監査ステップ）を確認します。
• 承認タイムアウトを設定してリクエストが自動的に期限切れになるようにします。期限切れの承認はステージを失敗させ、制御不能なドリフトを防ぎます。職務の分離が必要な場合は、複数の承認者を要求するか、承認を順序付けます。一貫したガバナンスのために、「承認とチェック」を介して環境とサービス接続に承認を適用します。

リリースゲートは、昇格前に客観的なエビデンスを強制します。Azure Pipelinesは、次のようなチェックをサポートしています：

• メトリックやアラートをクエリするAzure Monitorチェック（例：アクティブなSev2アラートがない、エラー率がしきい値未満、p95レイテンシがターゲット未満）。ゲートは、成功/失敗またはタイムアウトまで、定義された間隔で再評価します。
• 外部の品質サービス、ロードテスト、または内部のコンプライアンスエンドポイントを呼び出すためのInvoke REST APIチェック。応答を解析し、基準が満たされない場合はブロックします。
• リリース前に必要なタスク、バグ、または変更要求が正しい状態にあることを確認するための作業項目クエリチェック（例：すべての「修正必須」の不具合が解決済み）。リリースまたはコミット範囲にスコープされたクエリを使用します。

リングの境界やカナリア中にゲートを実装し、主観的な昇格決定から測定可能な昇格決定へと移行します。

マルチ環境パイプライン、変数、依存関係

明示的な依存関係と環境スコープを持つマルチステージのYAMLパイプラインを設計します。strategyブロック（runOnce, rolling, canary）を持つデプロイメントジョブを使用してプログレッシブロールアウトをモデル化し、自動ロールバックのためにpreDeploy, routeTraffic, postRouteTraffic, on: failureのフックを含めます。ステージではdependsOnとconditionsを宣言し、後の環境は前の環境がゲートと承認を通過した後にのみ実行されるようにします。

環境固有の設定は、以下を通じて管理します：

• 環境でスコープされ、シークレットのためにAzure Key Vaultにリンクされた変数グループ。ステージごとにグループを参照し、機密性の高い値はソース管理から除外します。
• サービス間のデプロイを標準化し、環境固有の値（接続文字列、機能フラグのデフォルト値、Front Doorの重み付けなど）を渡すためのYAMLテンプレートとランタイムパラメータ。
• appsettingsやKubernetesマニフェストのトークン化または変換タスクにより、ドリフトのないConfiguration as Codeを保証します。

複数の環境へのデプロイには、プロモーションを伴うイミュータブルなアーティファクト（一度ビルドし、多数の環境にデプロイ）が推奨されます。作業項目をコミットとビルドに紐付け、同じアーティファクトが開発環境から本番環境へ流れる際のトレーサビリティを維持し、正確なリリースノートと監査を可能にします。

ロールバック戦略とデータベースに関する考慮事項

リリースする前にロールバックを計画します：

• 自動ロールバックは、ヘルスシグナルを使用して人手を介さずに元に戻します。AKSでは、maxSurge/maxUnavailableを控えめに設定し、ロールアウト失敗時の自動ロールバックを有効にします。kubectl rollout undoを使用するか、デプロイメント戦略の失敗フックに依存して以前のReplicaSetをトリガーします。Azure App Serviceでは、スロットのスワップバックは瞬時に行われます。ヘルスチェックとデプロイメントゲートを組み合わせて自動的に判断します。
• 手動ロールバックは、復旧にオペレーターの判断が必要な場合（データリスク、部分的な障害）に適切です。Front Door/Traffic Managerの重み付けを再ルーティングしたり、スロットスワップを元に戻したり、最後に正常だったビルドを再デプロイしたりするワンクリックのパイプラインタスクを提供します。以前のアーティファクトをすぐに利用できるように保持し、意思決定プロセスを文書化します。
• データベースのロールバックは特に注意が必要です。後方互換性のない変更は避けてください。拡張-縮小（expand-contract）パターンを使用します：読み書きの互換性を保ちながら列/テーブルを追加してデータを投入し、必要であれば両方のスキーマに書き込むコードをデプロイし、その後で非推奨の要素を削除します。Azure SQL Databaseでは、以下を組み合わせます：
  • 冪等性のあるバージョン管理されたスクリプトと、デプロイ前後の検証を伴うDACPACやマイグレーションフレームワーク（EF Core）。
  • ロック競合を最小限に抑えるためのオンライン操作（再開可能なインデックス再構築、パーティションスイッチング）。
  • データ損失のリスクを認識した上での最終手段としての、ポイントインタイムリストアとアクティブ地理レプリケーション。スキーマのダウングレードを行う前に、フラグを介して機能をオフにします。Azure MonitorとQuery Storeでキャプチャされたデータベースの健全性（DTU/CPU、デッドロック）に基づいてプロモーションをゲートします。

Azure App Configurationによる機能フラグとリリースノートの自動化

Azure App Configurationは、.NET、Java、Node.jsなどのSDKを使用して機能管理を一元化します。ラベルを使用して環境やリングごとにフラグのスコープを定義し、動的リフレッシュを有効にすることで、アプリは再デプロイなしで変更を取得できます。

• ターゲットフィルターにより、ユーザー/グループ、クレーム、デバイス、またはカスタム属性に基づいて、きめ細かな有効化が可能になります。コホート（例：内部テナント、VIP顧客）を定義して、リングと整合させます。
• パーセンテージロールアウトは、ランダムなサブセットに機能を段階的に公開します。1〜5%から開始し、KPIを検証し、その後ステップアップします。Front Doorの重み付けと連携して、ユーザーレベルとトラフィックレベルで階層的な制御を行います。
• キルスイッチは、インシデント発生時に機能を即座に無効化します。リスクの高いパス（支払い、データ書き込み）を、実行にデプロイが不要なグローバルなオフトグルで保護します。すべてのトグルを監査用にログに記録し、インシデントと関連付けます。

リリースノートを自動化して、トレーサビリティとコミュニケーションを提供します：

• コミットメッセージとPRにIDの参照を要求することで、作業項目のリンクを強制します。Azure DevOpsは、ビルドとリリースを作業項目やコミットと自動的に関連付けます。
• パイプラインで、Generate Release NotesタスクまたはREST API呼び出しを使用して、ターゲット環境への前回の正常なデプロイ以降の変更と作業項目をリストアップし、変更ログを生成します。機能、修正、破壊的変更、データベース移行のセクションを含むMarkdownを出力します。
• ノートをプロジェクトのWikiに公開し、ビルド成果物としてパッケージ化し、リリースに添付します。コンプライアンスのために、デプロイメタデータ（ビルド番号、コミットSHA、環境、承認者、通過したゲート）を含めます。

実践的な問題シナリオ

Adobeは、ピークキャンペーン中のコンバージョン率をリスクにさらすことなく、Azureでホストされているマーケティングサイトに新しいパーソナライゼーションエンジンを導入する必要があります。チームは、頻繁にデプロイし、機能を段階的に公開し、SLOを検証し、KPIが悪化した場合は即座にロールバックする必要があります。

1. Azure Deployment Environmentsで環境を定義する

• Gitベースのカタログに、アプリ、AKS、Azure SQL、Front Door用の環境定義（Bicep）を作成します。開発者は安全にdev/testをセルフプロビジョニングし、本番環境とのパリティを確保し、実験用のエフェメラルなテストスタックを可能にします。ADEは、支出とアクセスを制御するためにクォータとRBACを強制します。

2. マルチステージYAMLで一度ビルドし、多段階にデプロイする

• 単一の成果物が、ring-r0、ring-r1、ring-r2、prodの各ステージを通じてプロモートされます。ステージは互いに依存し、適切な場所でcanaryおよびrolling戦略を持つデプロイメントジョブを使用し、リング間で一貫したバイナリを保証します。

3. レガシーWeb層にApp Serviceスロットでブルーグリーン展開を使用する

• ステージングスロットにデプロイし、ウォームアップしてから、ring-r0の内部ユーザー向けにスワップします。AdobeのSLOが悪化した場合、スロットをスワップバックすることで、ほぼゼロダウンタイムで最速のロールバックが提供されます。

4. Azure Front Doorの重み付けルーティングでカナリア展開を導入する

• レガシーと新しいパーソナライゼーションの両方のバックエンドを登録します。ring-r1で、新しいバックエンドへのトラフィックを1%から開始します。Front Doorのヘルスプローブと即時の重み更新により、トラフィックパターンに合わせた安全で迅速な調整が可能になります。

5. 客観的なチェックでプロモーションをゲート管理する

• Application Insightsから取得したp95レイテンシ、エラー率、コンバージョンKPIのAzure Monitorチェックを追加します。ガードレールメトリクスを確認するために、Adobeの内部実験サービスへのREST APIチェックを追加します。リングを進める前に「Must Fix」のバグがクローズされていることを確認するために、作業項目クエリチェックを構成します。ゲートは定期的に評価され、停滞した変更を防ぐためにタイムアウトします。

6. 重要な移行時に承認を要求する

• ring-r2とprodへのデプロイ前承認では、宙ぶらりんのリリースを避けるために、マーケティングとSREのサインオフを4時間のタイムアウト付きで要求します。デプロイ後承認は、リリースをクローズする前にUATと分析の検証が完了したことを確認します。

7. Azure App Configurationの機能フラグで公開範囲を制御する

• ダークローンチを実装し、新しいエンジンは存在するが最初は無効になるようにします。ターゲットフィルターを使用して、内部スタッフ（ring-r0）および選択された顧客コホート（ring-r1）向けに有効化します。パーセンテージロールアウトを適用して公開範囲を拡大します。キルスイッチは、異常が検出された場合に、再デプロイすることなくエンジンを数秒でグローバルに無効化します。

8. 拡張-縮小移行でデータを保護する

• まず追加的なSQL変更をデプロイし、非同期でデータをバックフィルし、必要に応じてデュアルライトを行います。安定性が証明された後にのみ、非推奨のスキーマを削除します。ゲートはDTU、デッドロック、長時間実行クエリを監視し、安全でないプロモーションを防ぎます。

9. ロールバックパスを自動化する

• デプロイジョブの失敗フックがロールバックをトリガーします：Front Doorの重みは新しいバックエンドに対して0%に戻ります。App Serviceは逆のスロットスワップを実行します。AKSはkubectl rollout undoを実行します。複雑なシナリオのために、オペレーターは手動のワンクリックロールバックも利用可能です。

10. リリースドキュメントを自動化する

• パイプラインは、関連する作業項目とコミットからMarkdown形式のリリースノートを生成し、有効化された機能、データベースの変更、通過したゲートを強調表示します。ノートはAzure DevOps Wikiに公開され、リリースに添付されることで、監査とステークホルダーの可視性を満たします。

このアプローチは、各ツールをその強みに応じて使用します：安全で再現可能な環境のためのADE、統制されたフローのためのYAML戦略と承認、階層的な段階的配信のためのFront DoorとApp Configuration、客観的な品質管理のためのAzure Monitorとゲート、そして回復力とトレーサビリティのための自動ロールバックとリリースノートです。

← コンテナ化と Kubernetes · すべてのドメイン · セキュリティ、コンプライアンス、DevSecOps →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Microsoftを閲覧 →