クラウドのワークロードを準備する

Azureに移行する前に、ワークロードはクラウド対応である必要があります。 クラウドの準備により、一括リスクが軽減され、Azure サービスとの互換性が確保されます。 運用環境のカットオーバーの前に、Azureでワークロードを検証、セキュリティで保護、自動化します。 Azureアーキテクチャプランとワークロード評価を使用して準備をガイドします。

Azureの互換性の問題を修正する

互換性の問題によってワークロードの移行がブロックされる可能性があり、運用環境のデプロイ前に解決する必要があります。 Azureには、特定の構成、サポートされているオペレーティング システム、および現在のドライバーが必要です。 移行を成功させるために、これらの問題に体系的に対処します。

すべてのワークロード リソースをデプロイする

クラウド アーキテクチャを計画し、アプリケーションランディング ゾーンを準備したら、次の手順では、すべてのワークロード コンポーネントをAzureにデプロイします。 このフェーズにより、環境が適切に分離され、管理され、アーキテクチャ計画に合わせて調整されます。 デプロイが完了したら、テスト環境の完全性を検証して、運用環境に対する準備ができていることを確認します。

1. ワークロード環境Azureサブスクリプションを作成します。 適切な分離、コスト追跡、ガバナンスを確保するために、開発、テスト、運用環境用に個別のサブスクリプションを作成します。 適切な管理グループにサブスクリプションを配置し、環境固有のガバナンス ポリシー、ロールベースのアクセス制御の割り当て、コスト管理の予算を適用します。 詳細については、「 サブスクリプションの作成」を参照してください。

2. アーキテクチャ計画を活用してください。 クラウド導入計画中に定義されたAzure アーキテクチャをデプロイします。 更新されたワークロード要件が反映されていることを確認します。 ガイダンスについては、Azure アーキテクチャ計画を参照してください。

3. すべてのワークロード コンポーネントをデプロイします。 テスト環境 (サブスクリプション) で、コンピューティング (VM、Web アプリ、コンテナー)、データストア (データベース、ストレージ アカウント)、ロード バランサー、マネージド ID、仮想ネットワーク、DNS リソースなど、必要なすべてのコンポーネントをデプロイします。

4. テスト環境の完全性を検証します。 すべての依存関係、構成、および統合が存在することを確認します。 コンポーネントが見つからないと、テスト中に誤検知や検出されない問題が発生する可能性があります。

互換性の問題を解決する

ワークロードを運用環境に移行する前に、パフォーマンス、セキュリティ、またはサポート可能性に影響を与える可能性がある互換性の問題を特定して解決します。 計画フェーズの評価データを使用して修復作業をガイドし、Azureネイティブ ソリューションを使用してテスト環境に修正プログラムを適用します。

1. 文書化されている互換性要件と既知の問題を確認します。 CAF 計画フェーズの ワークロード評価 を使用して、修復する必要があるサポートされていない構成と依存関係を特定します。

2. Azureソリューションを使用して、各互換性の問題を解決します。 ソース環境を変更するのではなく、Azureテスト環境で修復を適用します。 互換性に関する一般的な問題は次のとおりです。

ワークロード機能を検証する

互換性の問題を解決したら、Azure環境でワークロードが正しく機能することを確認します。 すべてのコンポーネント、構成、統合がビジネス要件と技術要件を満たしていることを確認するには、包括的なテストが不可欠です。 この検証プロセスにより、リスクが軽減され、運用環境のデプロイへのスムーズな移行が保証されます。

ネットワークの接続を検証する

信頼性の高いネットワーク接続により、すべてのアプリケーション コンポーネントと外部依存関係が、Azureで意図したとおりに通信できるようになります。 ネットワークが正しく構成されていないと、運用環境で重大な障害が発生する可能性があります。

1. すべてのコンポーネント間の接続をテストします。 Azure Network Watcher接続のトラブルシューティングを使用して、アプリケーション層が相互および外部サービスと通信できることを確認します。 この検証では、ネットワーク セキュリティ グループ、ルーティング テーブル、DNS 構成で必要なトラフィック フローが許可されていることを確認します。 このツールは、接続の問題に関する詳細な分析情報を提供し、通信を妨げる特定の構成の問題を特定します。

2. 外部サービス接続を確認します。 ワークロードが依存する外部 API、データベース、および外部サービスへの接続をテストします。 Network Watcherを使用して、送信接続が正しく機能し、ファイアウォール規則で必要なトラフィックが許可されていることを検証します。 運用環境のデプロイに関する接続要件を文書化します。

認証フローを検証する

認証は、セキュリティとアクセス制御に不可欠です。 これらのフローを検証することで、ユーザーとサービスがAzure環境で問題なく認証できるようになります。

1. ユーザー認証フローをテストします。 テスト ユーザー アカウントを使用して、Microsoft Entra IDなどの ID プロバイダーにアクセスでき、認証が正しく機能することを確認します。 シングル サインオン、多要素認証、パスワード リセット フローなど、さまざまな認証シナリオをテストして、完全な機能を確保します。

2. サービス間認証を検証します。 サービス プリンシパルとマネージド ID を使用して、アプリケーション コンポーネント間の認証をテストします。 Azureロールベースのアクセス制御 (RBAC) アクセス許可が正しく構成されていること、およびサービスがデータベースやストレージ アカウントなどの必要なリソースに対して認証できることを確認します。

機能とパフォーマンスのテストを実施する

機能とパフォーマンスのテストにより、ワークロードがビジネス要件を満たし、稼働前に予想される条件下で確実に実行されます。

1. 包括的な機能テストを実行します。 ユーザー受け入れテスト (UAT)、統合テスト、回帰テストを実施して、アプリケーションがビジネス要件と技術要件を満たしていることを確認します。 すべての重要なユーザー ワークフローとビジネス プロセスをテストして、Azure環境で正常に動作することを確認します。 運用環境のデプロイの前に、機能上の問題を文書化し、解決します。

2. 現実的な負荷条件の下で性能を測定して下さい。 Azure Load Testing を使用して、現実的なユーザー トラフィックをシミュレートし、応答時間、スループット、リソース使用率を測定します。 予想される運用環境の使用パターンとピーク時の負荷シナリオを反映するようにロード テストを構成します。 ロード テストでは、詳細なパフォーマンス メトリックが提供され、ユーザー エクスペリエンスに影響する可能性があるボトルネックが特定されます。

3. ベースラインに対してパフォーマンスを検証します。 CAF 計画ワークロード評価中に文書化されたパフォーマンス ベースライン メトリックを参照します。 テスト結果を、ソース環境から確立されたパフォーマンス ベースラインと比較します。 パフォーマンスの低下を特定し、構成を最適化したり、リソースをスケーリングしたり、パフォーマンス目標を満たすようにコードを変更したりします。

4. 受け入れテストに利害関係者を含めます。 ビジネス ユーザーと受け入れテストを実施して、ワークロードがビジネスの期待とユーザー エクスペリエンスの要件を満たしていることを確認します。 ビジネス検証により、運用環境のデプロイ前にワークロードに期待される価値と機能が確実に提供されます。

再利用可能なインフラストラクチャを作成する

最新化されたソリューションが非運用環境のすべてのテストに合格したら、インフラストラクチャのセットアップと構成をコードとしてキャプチャして、運用環境および将来の環境で簡単にレプリケートできるようにする必要があります。 再利用可能なインフラストラクチャとは、一貫性と速度のためにコードとしてのインフラストラクチャ (IaC) テンプレートと自動化を使用することです。

1. 実績のある構成用の IaC テンプレートを作成します。 テスト環境の最終的なアーキテクチャ (prod で必要なものを反映) を取得し、体系化します。 インフラストラクチャを定義するには、Bicep、 Teraform、または Azure Resource Manager テンプレート を使用します。 これらのテンプレートをパラメーター化して、開発、テストなどのさまざまなステージに再利用できるように、名前やサイズなどの小さな調整を行います。 このセットアップにより、作成した運用環境がテストした環境と一致します。 手動でAzureポータルをクリックしてリソースを作成する際の人的エラーを回避します。 また、ディザスター リカバリーや新しいリージョンへのデプロイなど、環境を再作成する必要がある場合は、インフラストラクチャをデプロイする準備ができていることも意味します。 詳細については、「 CAF の管理 - コードベースのデプロイの管理」を参照してください。

2. バージョン 管理にテンプレートを格納します。 (アプリケーション コードと共に、または別のリポジトリで) インフラストラクチャ コードを Git リポジトリにチェックインします。 適切なバージョン管理で IaC 資産を管理するには、GitHub または Azure DevOps を使用します。 バージョン管理により、コード レビューが可能になり、チームのコラボレーションがサポートされ、プロジェクト間でのテンプレートの再利用が促進されます。 この方法では、インフラストラクチャの変更を完全に追跡でき、問題が発生した場合のロールバック機能がサポートされます。

3. 依存関係のインストールと構成を自動化します。 これらのテンプレートをデプロイし、必要な構成またはシード処理タスクも処理するスクリプトまたはパイプライン タスクを作成します。 Azure Pipelines、GitHub Actions を使用して、IaC テンプレートを取得し、ターゲット サブスクリプション/リソース グループにデプロイするデプロイ ジョブを実行します。 アプリの依存関係のインストール、設定の構成、 シークレット管理を自動化します。 目標は、ワンクリック (または 1 コマンド) 環境のセットアップです。何もしない環境から、テストした環境と一致する完全に実行されている環境までです。

4. IaC と自動化をエンドツーエンドでテストします。 サンドボックスとして別のAzure サブスクリプションまたはリソース グループを使用し、テンプレートとスクリプトを使用して環境全体をゼロからデプロイする練習を行います。 IaC テンプレート、パイプライン、およびスクリプトが、何もない場所から完全なインフラストラクチャ スタックを作成できることをテストします。 初期デプロイ、構成の更新、ロールバック手順など、さまざまなデプロイ シナリオをテストして、自動化が正しく動作することを確認します。

詳細については、「WAF でのコードとしてのワークロード開発サプライ チェーンとインフラストラクチャの設計」を参照してください。

デプロイに関するドキュメントを作成する

自動化を使用する場合でも、デプロイに関する適切なドキュメントを用意することは、監査、新しいチーム メンバーのオンボード、および将来のメンテナンスのために不可欠です。 展開のドキュメントでは、構成、手順、ロールバック手順を人間が判読できる形式で説明する必要があります。

1. ドキュメントの構成設定と手順。 環境固有のすべての設定、接続文字列、サービス エンドポイント、およびセキュリティ構成をアクセシビリティ対応のドキュメントに記録します。 詳細なデプロイ手順、前提条件、デプロイ後の検証手順を含めます。 このドキュメントでは、一貫性のあるデプロイを可能にし、問題が発生した場合のトラブルシューティングをサポートします。 新しいエンジニアがデプロイする際には、このドキュメントを読み、パイプラインの出力を理解するか、順を追って従うことができます。

2. ロールバックと回復の手順を更新します。 テストを完了したら、デプロイの問題が発生したときに変更を元に戻す手順を形式化します。 ロールバック トリガー、データのバックアップと復元の手順、回復の検証手順を含めます。 ロールバックと復旧の手順を定期的にテストして、必要に応じて正常に動作することを確認します。 この準備により、ダウンタイムが短縮されます。

3. このドキュメントをすべて中央の場所に収集します。 この情報を格納するには、SharePoint、GitHub、または wiki を使用します。 チームとサポート担当者が見つける場所を把握していることを確認します。 ストレスの高いインシデントでは、明確なドキュメントを手元に持つことはライフセーバーです。

次のステップ