次に、計画された戦略に従って、ソリューションをライブ Azure 環境にデプロイします。 このフェーズには、最終的な準備、デプロイの実行、デプロイ後の検証とサポートが含まれます。
クラウドネイティブ デプロイの利害関係者を準備する
デプロイ スケジュールと予想される影響を発表します。 運用環境のデプロイを開始する前に、関連するすべての利害関係者に計画と価値を伝えます。 展開スケジュールと予想されるユーザー効果を発表します。 たとえば、新機能の場合は、ダウンタイムやユーザーに表示される変更を事前にメモしておきます。 利害関係者は、ビジネス イベントとの競合を特定したり、タイミングに関する懸念を引き起こす可能性があります。 フィードバックのチャネルを提供し、デプロイ ウィンドウが運用上の優先順位と一致していることを確認します。 中断を回避するために、必要に応じてスケジュールを調整します。
サポート チームと影響を受けるグループに通知します。 ユーザーの問題や問い合わせを処理できるように、サポート チームがスタンバイ状態であり、リリースされている内容を認識していることを確認します。 展開がエンド ユーザーやその他のシステムに影響する可能性がある場合は、それらのグループにも通知します。
デプロイ期間中に機能に対する期待値を設定します。 展開ウィンドウには、機能の削減や一時的な遅延が伴う場合があります。 混乱を防ぎ、ビジネス継続性を確保するために、これらの条件を利害関係者に通知します。 該当する場合は、フォールバック手順または回避策を含めます。
展開前の準備状況のレビューを実施します。 準備レビューでは、すべてのチームが自分の役割を理解し、必要なアクセス権を持っていることを確認します。 各サポート チームの代表者と会議を開催して、デプロイ計画、成功条件、ロールバック条件を確認します。 サポート チームに適切なシステム アクセスおよび監視ツールが構成されていることを確認します。 この準備により、移行中に発生する問題に対する協調的な対応が保証されます。
クラウドネイティブ デプロイを実行する
デプロイ手順は、新しいスタンドアロン ワークロードであるか、既存のシステムの機能更新であるかによって若干異なります。
新しいクラウドネイティブ ワークロードをデプロイする
運用環境を作成します。 CI/CD パイプラインを使用して、ステージングでテストされたのと同じ構成を使用して運用デプロイ パイプラインをデプロイします。 ステージングで検証に合格したのと同じビルド 成果物、IaC テンプレート、デプロイ スクリプトを使用します。 別の環境にデプロイするため、IaC テンプレートを使用して必要なすべての Azure リソースを作成し、アプリケーション コードまたは成果物をデプロイします。
スモーク テスト。 デプロイが完了したら、運用環境でスモーク テスト (基本チェック) を実行して、すべてのサービスが稼働していて、コア機能がライブ環境で動作することを確認します。 キー サービスが実行されていること、データベースにアクセス可能であることを確認し、アプリケーションが応答することを確認します (正常性チェック エンドポイントまたはいくつかのキー ページにヒットします)。 コンポーネントに影響を与える可能性があるリージョン内のプラットフォームの問題がないか 、Azure Service Health を確認します。 このテストは、ユーザーがシステムに転送される前のチェックです。
少数のユーザー グループへのロールアウト。 少数のユーザーに新しいシステムを公開して、プログレッシブ ロールアウトを実装します。 このロールアウトは、内部ユーザーのみに機能をリリースするか、新しいデプロイにごく一部のライブ ルーティングを行うことで行うことができます。 エラーやパフォーマンスの問題を注意深く監視します。 Application Insights とカスタム ダッシュボードを使用して、エラー率、応答時間、リソース使用率をリアルタイムで監視します。 また、カナリア バージョンのパイロット ユーザーから定性的なフィードバックを収集します。
監視し、徐々に拡張します。 段階的なロールアウトにより、リスクが軽減され、完全リリース前の実際の検証が可能になります。 カナリア ユーザーの小さなグループにアプリケーションを解放します。 Azure Front Door や Traffic Manager などのロード バランサーを使用して、トラフィックのサブセットを新しいデプロイにルーティングします。 フィードバックを収集し、パフォーマンスを監視します。 検証が成功した後、すべてのユーザーへのアクセスをスケールアップまたは開きます。
新しいクラウドネイティブ機能を既存のワークロードにデプロイする
既存のクラウドネイティブ ワークロードに新しい機能をデプロイする場合は、リスク許容度、インフラストラクチャの制約、ロールアウトの目標に合わせたデプロイ戦略を選択します。 2 つの一般的な方法は、インプレースデプロイとブルーグリーン (並列環境) デプロイです。
インプレース デプロイを使用して、同じ環境内で段階的なロールアウトを行う
別の環境をプロビジョニングせずに既存のワークロードに新しい機能を追加する場合は、インプレース デプロイを使用します。 この方法により、インフラストラクチャのオーバーヘッドを最小限に抑えながら、安全で段階的なロールアウトが可能になります。
小さなユーザー セグメントの機能を有効にする 機能フラグまたは構成トグルを使用して、新しい機能を既存の環境にデプロイします。 まず、内部ユーザー、ベータ テスト担当者、ライブ トラフィックのごく一部など、限られた対象ユーザーに対して機能を有効にします。 この方法では、問題が発生した場合に機能をすばやく無効にする機能を維持しながら、実際の検証を行うことができます。 機能が有効になっているユーザーまたはセッションを区別するために、ユーザーの操作がタグ付けされていることを確認し、サイド バイ サイド比較を有効にします。
スモーク テスト。 デプロイが完了したら、運用環境でスモーク テスト (基本チェック) を実行して、すべてのサービスが稼働していて、コア機能がライブ環境で動作することを確認します。 キー サービスが実行されていること、データベースにアクセス可能であることを確認し、アプリケーションが応答することを確認します (正常性チェック エンドポイントまたはいくつかのキー ページにヒットします)。
監視し、徐々に拡張します。 Application Insights や Azure Monitor などのツールを使用して、アプリケーションの正常性、パフォーマンス、エラー率を継続的に監視します。 異常を検出するために、機能が有効になっているユーザーとないユーザーの間でメトリックを比較します。 問題が検出されない場合は、機能フラグのロールアウト率を徐々に増やすか、ユーザー グループを展開します。 各増分の後に監視を繰り返します。 完全なロールアウト後、最終的な検証を実行して、すべてのインスタンスとユーザー セグメントで一貫した動作を確認します。
並列環境に新機能をデプロイする
新しい機能を既存のワークロードに導入する場合は、並列運用環境にデプロイすることで、ブルーグリーンデプロイを使用します。 この方法では、ユーザー トラフィックを新しいバージョンに切り替える前に完全な検証を許可することで、リスクを最小限に抑えます。
並列環境 (緑) を作成します。 CI/CD パイプラインを使用して、ステージングでテストされたのと同じ構成を使用して運用デプロイ パイプラインをデプロイします。 ステージングで検証に合格したのと同じビルド 成果物、IaC テンプレート、デプロイ スクリプトを使用します。 別の環境にデプロイするため、IaC テンプレートを使用して必要なすべての Azure リソースを作成し、アプリケーション コードまたは成果物をデプロイします。
煙は並列環境をテストします。 デプロイが完了したら、運用環境でスモーク テスト (基本チェック) を実行して、すべてのサービスが稼働していて、コア機能がライブ環境で動作することを確認します。 キー サービスが実行されていること、データベースにアクセス可能であることを確認し、アプリケーションが応答することを確認します (正常性チェック エンドポイントまたはいくつかのキー ページにヒットします)。 コンポーネントに影響を与える可能性があるリージョン内のプラットフォームの問題がないか 、Azure Service Health を確認します。 このスモーク テストは、ユーザーがシステムに転送される前のチェックです。
トラフィックのサブセットを並列環境にルーティングします。 段階的なロールアウトにより、リスクが軽減され、完全リリース前の実際の検証が可能になります。 カナリア ユーザーの小さなグループにアプリケーションを解放します。 Azure Front Door や Traffic Manager などのロード バランサーを使用して、トラフィックのサブセットを新しいデプロイにルーティングします。 または、ルーティング 規則または機能フラグを使用して、特定のユーザー セグメントにのみ新しい機能を公開します。 Application Insights または Azure Monitor を使用して、パフォーマンス、エラー率、ユーザー エクスペリエンスを監視します。 青と緑の環境の間のユーザー トラフィックを比較して、回帰や異常を検出します。
監視し、徐々に拡張します。 新しいバージョンが正常に動作する場合は、負荷の 100% を処理するまで、トラフィック ルーティングを段階的に増やします。 環境に優しいデプロイを主要なものにします。 このプロセス中、古い "blue" デプロイはそのまま保持されるため、ロールバックが容易になります。 重大な問題が検出された場合は、すべてのトラフィックを安定したバージョンに即座に切り替えることができます。
カットオーバーの最終処理。 検証が成功したら、すべてのユーザーを新しいシステムにルーティングするか、非表示にされた場合は正式にライブ通知します。 更新された機能の場合、古い環境は、安全な検証期間後の使用停止と見なすようになりました。
デプロイの成功を検証する
新しいワークロードまたは機能をデプロイした後は、技術的にもユーザーの観点からも、システムが正しく機能していることを確認することが不可欠です。
重要なユーザー体験を検証します。 スモーク テストを超えて、すべての主要なユーザー フローがライブ環境で期待どおりに動作することを確認します。 自動化されたテスト スイートまたは手動 QA を使用して、実際のシナリオを検証します。 認証、トランザクション、データ ワークフローなどの価値の高いパスに焦点を当てます。 このテストでは、デプロイで新しいシステムが導入されたか、既存のシステムが拡張されたかが適用されます。
バックグラウンド プロセスと統合を確認します。 バックグラウンド プロセス、統合、スケジュールされたジョブが正しく実行されていることを確認します。 ログ、ジョブの状態、統合エンドポイントを確認して、期待どおりに機能していることを確認します。 この手順により、ユーザーにすぐには表示されない可能性があるサイレント エラーが防止されます。
システム正常性の監視ダッシュボードを確認します。 Azure Monitor と Application Insights を使用して、ログとメトリックを検査します。 エラー率、待機時間、CPU/メモリ使用量、スループットの異常を探します。 監視データが正しく流れ、データが見つからないか、誤ってルーティングされていないことを確認します。
予期しないトリガーに対するアラート機能を調査します。 構成されたアラートで、エラー率、待機時間、またはリソースの使用状況を確認します。 アラートが予期せず発生していないことを確認します。 アラートがトリガーされた場合は、根本原因を調査し、デプロイ関連の問題を示しているかどうかを評価します。
利害関係者とユーザーのチェックインを行います。 また、展開後に少数のエンド ユーザーまたは利害関係者と迅速にチェックインして、ユーザーの観点から作業していることを人間が確認できるようにすることも賢明です。
完全な検証後にのみデプロイの完了を宣言します。 すべての検証手順が成功し、システムが受け入れ基準を満たしている場合にのみ、デプロイが完了することを検討してください。 問題が見つかった場合は、すぐに重要なものを修正します。 今後の更新プログラムで解決するための軽微な問題をログに記録します。
安定化中のワークロードのサポート
監視とサポート体制の強化を確立します。 運用環境へのデプロイは、体験の最後ではありません。 稼働直後の数時間と数日で、監視を増やし、システムが実際の負荷の下で "上昇" している間の警戒をサポートします。 それらの変更を最もよく理解している開発チームが運用チームと共に待機して、問題が発生した場合はすぐに調査して解決できるように、準備しておくことをお勧めします。
システム メトリックとユーザー フィードバックを継続的に追跡します。 最初の 1 週間または 2 週間を安定化期間として扱います。 Azure Monitor と Application Insights を使用して、CPU、メモリ、エラー率、応答時間などのメトリックを監視します。 サポート チャネルまたは直接アウトリーチを通じてユーザー フィードバックを収集します。 これにより、自動化されたシステムで見落とされる可能性がある問題を検出できます。
観察された動作に基づいて構成を調整します。 必要に応じて構成を調整します。 たとえば、使用量が予想よりも高い場合は、スケールアウトを増やします。 ログが詳細すぎるか、またはスパースすぎる場合は、ログ レベルを変更します。 これらの変更は、ピーク使用時のパフォーマンスと可観測性を維持するのに役立ちます。 今後の改善のために、このフェーズで検出された問題に対処するか、追跡システムに入力してください。
安定化中に検出されたすべての問題をログに記録してトリアージします。 このアクティブなサポート フェーズでは、運用環境でのみ明らかになる問題をキャッチし、ワークロードがその目標を真に満たしていることを確認します。 この安定化期間が経過すると、システムのパフォーマンスに自信が持てたら、通常の操作と監視手順に移行できます。
安定化の終了基準を定義します。 システムパフォーマンス、エラー率、およびユーザー満足度の明確なしきい値を設定します。 システムがこれらの基準を一貫して満たしたら、標準の運用と監視手順に移行します。 これらの条件は滑らかな引き渡しを保障し、サポートフェーズの早期閉鎖を避ける。