実行は、プランが現実に変わる場所です。 この手順では、すべてのユーザーに変更の準備を行い、非運用環境で開発作業を行います。 徹底的にテストし、制御された方法で運用環境にデプロイします。 重要なのは、変更が大きくなる可能性がある場合に、ビジネスの中断を最小限に抑えるための厳格なテストと安全な展開プラクティスです。
最新化のために利害関係者を準備する
[デプロイ] ボタンをクリックする前に、すべての関係者とユーザーが今後の予定を準備することが重要です。 驚きは、混乱や運用上の問題につながる可能性があります。 主要な準備手順には、コミュニケーション、変更の凍結 (前述)、およびサポート プランが含まれます。
すべての関係者に展開スケジュールを発表します。 事前に、最新化のデプロイが行われる必要があるときに、影響を受けるすべての関係者に連絡し、何を期待するかを伝えます。 関係者が適切に準備できるように、変更の凍結の開始日や稼働開始期間などの重要な日付を含めます。 期待値を設定することで、ユーザーはダウンタイムに関する計画を立てることができ、社内チームの準備を整えることができます。
ソースワークロードと依存ワークロードに変更凍結を実装します。 ガバナンスの前に計画したように、今は実際に凍結を強制する時です。 デプロイの前と実行中に、ワークロード (および依存ワークロード) でコードの変更、構成の調整、またはその他のデプロイが行われないようにします。 これにより、環境が安定します。 すべてのチームメンバーと関連のあるサードパーティがそれを知っていることを確認してください。 混乱を避けるために、特定の開始時刻と終了時刻を含むフリーズ ウィンドウを明確に定義します。
最終的なユーザー アクションとデプロイ後の変更を伝えます。 ユーザーは、ワークフローの中断を防ぐために、デプロイの前後に必要なアクションを事前に通知する必要があります。 カットオーバーが開始される前に、サインアウトまたは作業を保存するようにユーザーに指示します。 新しいアクセス URL、Microsoft Entra ID サインイン要件などの認証の変更、毎日の操作に影響を与える更新されたワークフローを共有します。 サポート ドキュメントとクイック スタート ガイドを提供して、最初の日の混乱を軽減します。
デプロイのサポート スタッフを調整します。 IT 運用チームと開発チームは、重要な展開フェーズ中に問題を監視して対応できる必要があります。 問題が発生する可能性が最も高い場合は、デプロイ後の最初の営業日に延長サポート時間やその他のスタッフをスケジュールします。 迅速な問題解決を確実にするために、展開後のサポート計画とエスカレーション手順を部署に通知します。
重要なワークロードのフォールバック 手順を定義します。 ミッション クリティカルなワークロードでは、展開期間中に業務を維持するために、手動による回避策とコンティンジェンシー計画が必要です。 ワークロードの読み取り専用期間中の手動注文処理などの特定の手順を文書化します。 これらの手順を事前に共有し、影響を受けるチームとの準備状況を確認して、必要に応じてシームレスに実行できるようにします。
非運用環境での最新化の開発
最新化の変更のすべての開発と統合は、運用環境 (開発、テスト、ステージング環境) の外部で行う必要があります。 基本原則: prod に似た環境で最初にビルドしてテストし、prod にデプロイするときに既に既知の量になるようにします。
実装時 Well-Architected フレームワークの原則に従ってください。 新しい変更をコーディングして構成するときは、Azure のWell-Architected Framework (WAF) のベスト プラクティスを継続的に適用します。 Azure Advisor の推奨事項とアーキテクチャ レビュー プロセスを使用して、設計上の決定を検証します。 このアプローチにより、最新化されたコンポーネントが Azure のベスト プラクティスと運用標準を確実に満たされるようになります。
運用環境をミラーリングする非運用環境を作成します。 運用環境のセットアップにできるだけ近い Azure の開発/テスト環境を起動します。 運用環境で特定の Azure サービスを使用する場合は、コストを節約するために、テスト、小規模、または低パフォーマンスレベル (SKU) で同じものを使用します。 テスト環境が運用環境に近いほど、テスト結果を運用環境の動作に引き継ぐ必要があることを確信できます。
ソース管理と CI/CD を使用して、変更を段階的に実装します。 他のソフトウェア プロジェクトと同様に、最新化の取り組みを扱います。 コード スクリプトとして、すべてのコード変更とインフラストラクチャに Git またはその他のソース管理を使用します。 必要に応じて、履歴とコードをロールバックする機能を提供します。 作業を小さな区切りに分割し（例えば、機能や修正ごとに）、機能ブランチを活用してください。 コードレビュー後、変更を頻繁にマージします。 各コミットでテスト スイートを実行するように継続的インテグレーション ビルドを設定して、問題を早期にキャッチできるようにします。
テストを使用して最新化の変更を検証する
テストは重要です。 最新化では新しい機能が追加されないため、回帰テスト (何も壊れない) とパフォーマンス/セキュリティ テスト (以前よりも適切に機能し、悪くない) に重点を置いています。 運用環境に触れる前に、テスト環境でワークロードのすべての側面を確認する必要があります。
変更されたすべてのコンポーネントに対して単体テストと統合テストを実行します。 開発者は、リファクタリングされたコードの単体テストを作成または更新する必要があります。 レガシ コードであっても、重要な関数の単体テストを記述すると、リファクタリングによって誤って動作が変更された場合にキャッチするのに役立ちます。 CI パイプラインで単体テストを継続的に実行します。 さらに、統合テストを実行して、コンポーネントが正しく通信していることを確認します。 バグを修正した後、関連するテストを再実行して、バグが実際に解決され、他に何も壊れないことを確認します (回帰を避けます)。
エンドツーエンドの機能テストを実施します。 ステージング環境またはテスト環境では、エンド ユーザーであるかのように完全なワークフロー テストを実行します。 このテストは、QA または自動化された UI テストによる手動テストです。 アプリケーションにサインインし、主要なタスクを実行します。 変更されていない機能が変更されていないことを確認します。 基本的には、単体テストで見逃す可能性のあるものをキャッチするために、実際の使用をシミュレートします。
利害関係者と共にユーザー受け入れテスト (UAT) を実行します。 一部の実際のエンド ユーザーまたはビジネス利害関係者が、最新化されたワークロードを公開する前にテストするのも賢明です。 開発者が見落とす微妙な違いをキャッチする可能性があります。 使いやすさ、パフォーマンス、機能のギャップに関するフィードバックをキャプチャします。 展開前に重要なユーザー受け入れテスト (UAT) の問題を解決し、利害関係者から正式な承認を得て、ビジネスの準備を確認します。
現実的な条件下でロード テストを使用してパフォーマンスを検証します。 モダン化は、理想的にはパフォーマンスを向上または維持する必要があります。 ロード テスト ツール (Azure Load Testing など) を使用して、現実的な使用パターンをシミュレートします。 ソース環境のパフォーマンス ベースラインと結果を比較して、低下を特定します。 予想される負荷の 150% でストレス テストを実施し、ワークロードの制限を決定し、負荷がかかった場合の回復性を検証します。
セキュリティ検証とコンプライアンス チェックを実行します。 新しいコードとコンテナー イメージに対して脆弱性スキャンを実行して、セキュリティ リスクを検出します。 業界固有のツールを使用して、規制対象ワークロードのコンプライアンス検証を実行します。 Microsoft Defender for Cloud を使用して、インフラストラクチャの構成ミスをスキャンし、セキュリティコントロールが要件を満たしていることを検証します。
運用環境のデプロイ前にすべての重大な問題を解決します。 テスト フェーズ中に特定された機能、パフォーマンス、およびセキュリティの問題を修正します。 すべてのテストが成功し、パフォーマンスがサービス レベル アグリーメント (SLA) を満たしていることを確認します。 優先度の低い問題を文書化し、デプロイ後の解決のための修復計画を作成します。
再利用可能なインフラストラクチャを作成する
最新化されたソリューションが非運用環境のすべてのテストに合格したら、インフラストラクチャのセットアップと構成をコードとしてキャプチャして、運用環境および将来の環境で簡単にレプリケートできるようにする必要があります。 再利用可能なインフラストラクチャとは、一貫性と速度のためにコードとしてのインフラストラクチャ (IaC) テンプレートと自動化を使用することです。
実績のある構成用の IaC テンプレートを作成します。 テスト環境の最終的なアーキテクチャ (prod で必要なものを反映) を取得し、体系化します。 Bicep、Terraform、または Azure Resource Manager テンプレートを使用して、インフラストラクチャを定義します。 これらのテンプレートをパラメーター化して、開発、テストなどのさまざまなステージに再利用できるように、名前やサイズなどの小さな調整を行います。 このセットアップにより、作成した運用環境がテストした環境と一致します。 Azure portal を手動でクリックしてリソースを作成する場合の人的エラーを回避します。 また、ディザスター リカバリーや新しいリージョンへのデプロイなど、環境を再作成する必要がある場合は、インフラストラクチャをデプロイする準備ができていることも意味します。 詳細については、「 CAF の管理 - コードベースのデプロイの管理」を参照してください。
バージョン 管理にテンプレートを格納します。 (アプリケーション コードと共に、または別のリポジトリで) インフラストラクチャ コードを Git リポジトリにチェックインします。 GitHub または Azure DevOps を使用して、適切なバージョン管理で IaC 資産を管理します。 バージョン管理により、コード レビューが可能になり、チームのコラボレーションがサポートされ、プロジェクト間でのテンプレートの再利用が促進されます。 この方法では、インフラストラクチャの変更を完全に追跡でき、問題が発生した場合のロールバック機能がサポートされます。
依存関係のインストールと構成を自動化します。 これらのテンプレートをデプロイし、必要な構成またはシード処理タスクも処理するスクリプトまたはパイプライン タスクを作成します。 Azure Pipelines、GitHub Actions を使用して、IaC テンプレートを受け取り、ターゲット サブスクリプション/リソース グループにデプロイするデプロイ ジョブを実行します。 アプリの依存関係のインストール、設定の構成、 シークレット管理を自動化します。 目標は、ワンクリック (または 1 コマンド) 環境のセットアップです。何もしない環境から、テストした環境と一致する完全に実行されている環境までです。
IaC と自動化をエンドツーエンドでテストします。 サンドボックスとして別の Azure サブスクリプションまたはリソース グループを使用し、テンプレートとスクリプトを使用して環境全体をゼロからデプロイする練習を行います。 IaC テンプレート、パイプライン、およびスクリプトが、何もない場所から完全なインフラストラクチャ スタックを作成できることをテストします。 初期デプロイ、構成の更新、ロールバック手順など、さまざまなデプロイ シナリオをテストして、自動化が正しく動作することを確認します。
詳細については、「WAF でのコードとしてのワークロード開発供給の変更とインフラストラクチャの設計」を参照してください。
デプロイに関するドキュメントを作成する
自動化を使用する場合でも、デプロイに関する適切なドキュメントを用意することは、監査、新しいチーム メンバーのオンボード、および将来のメンテナンスのために不可欠です。 展開のドキュメントでは、構成、手順、ロールバック手順を人間が判読できる形式で説明する必要があります。
ドキュメントの構成設定と手順。 環境固有のすべての設定、接続文字列、サービス エンドポイント、およびセキュリティ構成をアクセシビリティ対応のドキュメントに記録します。 詳細なデプロイ手順、前提条件、デプロイ後の検証手順を含めます。 このドキュメントでは、一貫性のあるデプロイを可能にし、問題が発生した場合のトラブルシューティングをサポートします。 新しいエンジニアがデプロイを行う必要がある場合、このドキュメントを読んでプロセスに従うか、パイプラインの出力を理解することができます。
ロールバックと回復の手順を更新します。 テストを完了したら、デプロイの問題が発生したときに変更を元に戻す手順を形式化します。 ロールバック トリガー、データのバックアップと復元の手順、回復の検証手順を含めます。 ロールバックと復旧の手順を定期的にテストして、必要に応じて正常に動作することを確認します。 この準備により、ダウンタイムが短縮されます。
このドキュメントをすべて中央の場所に収集します。 SharePoint、GitHub、または Wiki を使用して、この情報を格納します。 チームとサポート担当者が見つける場所を把握していることを確認します。 ストレスの高いインシデントでは、明確なドキュメントを手元に持つことはライフセーバーです。
最新化プロセスを展開する
運用環境のデプロイは、最新化の取り組みのクライマックスです。 選択した戦略 (インプレースと並列) に応じて、手順が異なります。 実行する前に、すべての準備手順が完了していることを再確認します。関係者に通知され、有効な状態でフリーズし、バックアップが作成され、スタンバイ状態で監視されます。
最新化をその場でデプロイする
メンテナンスウィンドウをスケジューリングしてください。 変更にダウンタイムが必要な場合や、データベース スキーマの移行など、リソースをロックするスクリプトを実行する必要がある場合は、事前に発表されたメンテナンス期間で行います。 すべてのユーザーが、その時点でワークロードをオフにしていることを確認します。 また、明確なウィンドウを使用すると、デプロイを完了したり、時間が不足した場合にロールバックを決定したりするターゲットも得られます。
デプロイには CI/CD パイプラインを使用します。 運用の展開には、テストに使用したのと同じ自動化されたパイプラインを使用し、運用環境をターゲットとして指定する必要があります。 このセットアップにより一貫性が確保されるため、インフラストラクチャとコードは同じ方法でデプロイされます。 実行する前に、重要なデータ (データベース) の最終バックアップを作成します。 ロールバックできる場合でも、バックアップを作成することは、問題が発生した場合に備えて追加のセーフティ ネットになります。 パイプラインを実行して、新しいコードとインフラストラクチャの変更をデプロイします。 ログと監視をリアルタイムで表示します。 いずれかのステップが失敗した場合は、一時停止して、前に進めるか、ロールバックする必要があるかを評価します。
可能であれば、プログレッシブ トラフィック ルーティング (カナリア) を実装します。 多くの Azure サービスでは、インプレース シナリオであっても、スロットのスワップや段階的なトラフィックシフトが可能です。 Azure では、Azure App Service デプロイ スロット、Azure Container Apps のトラフィック分割、および Azure Pipelines を使用した Azure Kubernetes Service によって、カナリアデプロイがサポートされています。 ロード バランサーの背後に複数の仮想マシンがある場合は、一度に 1 つのインスタンス (ローリング アップグレード) を更新して、他のユーザーがトラフィックを運ぶようにしてから、ローテーションします。
監視中は、トラフィック全体に徐々に増加します。 新しいバージョンが公開されたら、それを注意深く監視します。 アプリケーション ログ、パフォーマンス メトリック、エラー率を確認します。 ユーザーのごく一部から開始します (または、可能な場合は検証モードでワークロードを開始します)。 数分後に問題がなければ、トラフィックを例えば25%まで増やします。 メトリックをもう一度確認します (500 エラーの急増なし、通常の応答時間)。 50%に増やし、計画した期間で 100%。 注意が必要な場合は、1 時間以上かかる可能性があります。 いずれかの手順で重大な問題が観察された場合は、すべてのユーザーに影響を及ぼす前に、ロールバックを開始してください。
デプロイ中にデータの整合性を維持します。 インプレース デプロイでは、既存のデータ エンドポイントが保持され、データ スキーマが変更される可能性があります。 旧バージョンと新しいアプリケーション バージョンの両方をカナリア リリース中にサポートするには、下位互換性のある方法でデータベース スキーマの変更を適用します。 デプロイが正常に完了するまで既存の構造を削除せずに、新しい列またはテーブルを追加するデータベース移行スクリプトを使用します。
最新化を並列環境にデプロイする
並列運用環境を作成します。 IaC テンプレートを使用して、テストした内容を反映する新しい運用環境を Azure に作成します。 この環境には、すべてのコンピューティング、ネットワーク、ストレージが含まれます。 これは稼働しているはずですが、現在、ユーザー トラフィックはありません。 ネットワーク セキュリティ グループ、ファイアウォール、ID (マネージド ID またはサービス プリンシパル)、監視がすべて必要に応じて構成されていることを確認します (基本的に、prod サブスクリプションでテスト環境のセットアップを繰り返します)。
データベース レプリケーションを確立します。 データベース プラットフォームのネイティブ レプリケーション機能を構成して、ソースと Azure ターゲット ワークロードの間で継続的なデータ レプリケーションを確立します。 初期データ同期が正常に完了し、レプリケーションが正常であることを確認します。 バックアップまたはスナップショットからデータベースの初期一括コピーを実行し、新しいトランザクションのレプリケーションを有効にすることができます。 データベース プラットフォームの監視ツールを使用して、レプリケーションのラグを監視します。 待機時間が長いほど、カットオーバーのリスクと期間が増加します。 レプリケーションのラグがゼロになるまで、次の手順に進む必要はありません。
非構造化データとファイルをコピーします。 最終的なカットオーバーの前に、非構造化データとファイルを Azure にコピーします。 オブジェクト とファイルの移行にツールを使用し、 適切な Azure ストレージ サービスにファイルを転送する機能を使用します。 この準備により、最終的なカットオーバー中にコピーする必要があるデータの量が減ります。
最終的なデータ同期を完了します。 カットオーバー時に、データ損失をゼロまたは最小限に抑える必要があります。 データベースの場合は、保留中のトランザクションがソース ワークロードに残っていないか確認し、データベース レプリケーションがキャッチアップされていることを確認します。 場合によっては、最終的な変更 (特にトランザクション整合性など) をフラッシュするために、ソース データベースの書き込みを一時的に一時停止することが必要になる場合があります。 トランザクション ログ配布や短いダウンタイムなどの手法を使用して、最後の増分バックアップ復元を実行できます。 AzCopy または同様のツールを使用して、変更された非構造化データをコピーします。
新しい環境へのユーザー トラフィックを徐々に削減します。 ユーザー トラフィックを Azure 環境に転送するように、DNS レコードとロード バランサーの構成を更新します。 ワークロードの正常性とパフォーマンスを監視します。 Azure ロード バランサーでの重み付けルーティングを使用して、最新化されたワークロードに送信される 1% のライブ トラフィックから始めます。 応答時間、エラー率、データベース接続の正常性などのリアルタイム メトリックを監視します。 しきい値を超えた場合に自動ロールバック トリガーを使用して、時間ではなく数分でトラフィックを迅速に増やします (5%、15%、50%)。
100%に完全に切り替えます。 自信が持てたら、すべてのユーザーを新しい環境にルーティングします。 このスイッチは DNS カットオーバーである可能性があります。TIME TO LIVE (TTL) 値が低かった場合や、ロード バランサーの構成を反転した場合、数秒から数分かかる場合があります。 この時点で、ユーザーは最新化されたワークロードで稼働しています。
カットオーバー後に直ちに確認と監視を行います。 カットオーバー後の検証チェックを実行します。 自動化されたテスト スイートを使用して、すべての重要なビジネス プロセスのエンドツーエンドの機能テストを実行します。 ソースワークロードとターゲットワークロードのチェックサム検証とハッシュ関数の比較を使用して、データの精度を検証します。 ワークロード所有者に、すべての主要な機能が正しく動作することを確認させます。 カットオーバー後の最初の 24 ~ 48 時間のワークロード パフォーマンス、エラー率、およびユーザー アクセス パターンを監視して、パフォーマンスの低下や機能の問題を特定します。
しばらくの間、古い環境を実行したまま (ホット スタンバイ) します。 まだ何も引き裂かないでください。 古いワークロードを少なくとも 24 ~ 72 時間ホット スタンバイとして保持し、可能であれば継続的なデータ同期を行う (またはすぐに同期する準備ができている) ことをお勧めします。 運用環境で予期しない重大な問題が発生した場合でも、トラフィックを元に戻すことでロールバックを決定できます。 ログやその他の方法に追いつくことができるため、最小限のデータを失う必要があります。
モダン化の成功を検証する
新しいワークロードが稼働したら、運用環境ですべてが意図したとおりに動作し、受け入れ基準を満たしていることを検証する必要があります。
成功したユーザー アクセスとワークロードのパフォーマンスを確認します。 ユーザー アクセスの検証により、最新化が透過的になり、パフォーマンスが期待を満たすことが保証されます。 この確認では、ユーザーが中断することなくワークロードにアクセスできることを検証します。 移行後の初期期間中に、ユーザー のアクセス パターン、ワークロードのパフォーマンス メトリック、エラー率を監視します。
完全な検証後にのみ、移行の成功を発表します。 完全な検証により、すべての関係者がワークロードが安定して機能していることを確認できます。 この確認により、後で問題が発生する可能性のある早期の成功宣言を防ぐことができます。 ワークロードがすべての要件を満たし、正常に動作していることを、ワークロードの所有者、テスト担当者、およびビジネス利害関係者から確認します。
安定化中のワークロードのサポート
起動が成功した後でも、ワークロードに特別な注意を払う安定化期間を計画します。 新しく最新化されたワークロードでは、未知の問題が発生する可能性があります。これは、しばらくしてから実際の使用パターンでのみ発生します。
安定化期間中のサポート範囲の強化を確立します。 稼働後の最初の数日間または数週間 (複雑さに応じて) は、サポート プロトコルが強化されています。 経験豊富な IT スタッフまたは移行パートナーを割り当ててワークロードを注意深く監視し、通常の運用よりも短い SLA を提供します。
運用ドキュメントとツールを更新します。 新しい現実を反映するように、すべての Runbook、サポート ドキュメント、および監視構成が更新されていることを確認します。 新しいバックアップ プロセス、マイクロサービスの新しい再起動手順などの新しい手順について、運用チームをトレーニングします。 最新化されたワークロードを、完全な知識転送を使用して運用/サポート チームに引き渡します。 資産インベントリ/CMDB が新しいサーバー、IP、サービスを記録し、レガシ サーバーを削除またはマークしていることを確認します。