オンプレミスのアプリケーションを App Service Web アプリと SQL Managed Instance にリファクターする

  • [アーティクル]

この記事では、Contoso という架空の会社が、Azure への移行の一環として、VMware 仮想マシン (VM) 上で実行される 2 階層の Windows .NET アプリケーションをリファクターする方法を説明します。 Contoso チームは、アプリケーションのフロントエンド VM を、Azure App Service の Web アプリに移行します。 また、Contoso がアプリケーション データベースを Azure SQL マネージド インスタンスに移行する方法についても説明します。

この例で使用する SmartHotel360 アプリケーションは、オープンソース ソフトウェアとして提供されています。 独自のテスト目的に沿って使用する場合は、GitHub からダウンロードできます。

ビジネス ドライバー

Contoso の IT リーダーシップ チームは、ビジネス パートナーと密接に連絡を取り合い、彼らがこの移行で何を達成しようとしているのかを理解しました。

  • ビジネスの成長への対応。 Contoso は成長し続けており、会社のオンプレミスのシステムとインフラストラクチャに負荷がかかっています。
  • 効率化。 Contoso では、不要な手順を排除し、開発者とユーザーのプロセスを効率化する必要があります。 ビジネス部門は IT に対して、時間やコストを無駄にせず、迅速に作業を行ってもらう必要があります。これは、例えば、顧客の要求に素早く対応するためです。
  • 機敏性の向上。 Contoso IT は、ビジネス部門の要求に対して、対応力を向上させる必要があります。 グローバル経済で成功するには、より迅速に市場の変化に対応できる必要があります。 対応の遅さが障害となったり、ビジネスを阻害したりすることがあってはなりません。
  • スケーリング。 ビジネスが成長している中で、Contoso IT 部門は、同じペースで拡張できるシステムを提供する必要があります。
  • コストの削減。 Contoso はライセンス コストを最小限に抑えたいと考えています。

移行の目標

最良の移行方法を見極めやすくするために、Contoso クラウド チームは、以下の目標を設定しました。

要件領域 詳細
Application このアプリケーションは、オンプレミスにおける現状と同様、Azure でもクリティカルなものとなります。

アプリケーションには、VMware での現在のパフォーマンス機能と同等の機能が必要です。

チームは、アプリケーションに投資することは望んでいません。 現在のところ、管理者はアプリケーションをクラウドに安全に移行するだけの予定です。

チームは、アプリケーションが現在実行されている Windows Server 2008 R2 のサポートを終了したいと考えています。

このチームはまた、SQL Server 2008 R2 から最新の PaaS (サービスとしてのプラットフォーム) データベースに移行し、管理の必要性を最小限に抑えたいと考えています。

Contoso では、可能であれば、SQL Server ライセンスとソフトウェア アシュアランスへの投資を活かしたいと考えています。

Contoso は Web 層の単一障害点を軽減したいと考えています。

このアプリケーションは、単一の VM 上で実行されている ASP.NET アプリケーションと Windows Communication Foundation (WCF) サービスで構成されています。 Contoso は、App Service を使用して 2 つの Web アプリにこれらのコンポーネントを分散したいと考えています。
Azure Contoso は、アプリケーションを Azure に移行したいとは考えていますが、それを VM で実行することは望んでいません。 Contoso では、Azure PaaS サービスを Web 層とデータ層に利用したいと考えています。
DevOps Contoso は、ビルドとリリース パイプラインに Azure DevOps を使用した DevOps モデルに移行したいと考えています。

ソリューション設計

Contoso は、目標と要件を決定した後、デプロイ ソリューションを設計してレビューします。 チームはまた、移行に使用する Azure サービスなど、移行プロセスを明確化します。

現在のアプリケーション

  • SmartHotel360 オンプレミス アプリケーションは、2 つの VM (WEBVM と SQLVM) に階層化されています。
  • VM は、VMware ESXi 6.5 ホストの contosohost1.contoso.com 上にあります。
  • VMware 環境は、VM 上で実行されている vCenter Server 6.5 (vcenter.contoso.com) によって管理されています。
  • Contoso にはオンプレミスのデータセンター (contoso-datacenter) があり、そこにオンプレミスのドメイン コントローラー (contosodc1) が含まれています。
  • Contoso データセンター内のオンプレミス VM は、移行が行われた後に使用停止にされます。

提案されるソリューション

  • Contoso では、アプリケーションの Web 層については、App Service を使用します。 Contoso は、この PaaS サービスを使用して、わずかな構成変更だけでアプリケーションをデプロイできます。 Contoso は Visual Studio を使用して変更を加え、Web サイト用と WCF サービス用の 2 つの Web アプリをデプロイします。
  • DevOps パイプラインの要件を満たすために、Contoso は Git リポジトリと共に Azure DevOps のソース コード管理を使用します。 コードをビルドして App Service にデプロイするには、自動ビルドとリリースを使用します。

データベースの考慮事項

Contoso は、ソリューション設計プロセス中に、Azure SQL Database の機能と SQL Managed Instanceの機能を比較します。 チームは、次の考慮事項に基づいて、SQL Managed Instance を使用することを決定しました。

  • SQL Managed Instance では、最新のオンプレミス SQL Server バージョンとのほぼ 100% の互換性を提供することが目的とされています。 SQL Server をオンプレミスまたは IaaS (サービスとしてのインフラストラクチャ) VM で実行しており、最小限の設計変更でアプリケーションをフル マネージド サービスに移行することを望んでいる組織には、SQL Managed Instance が推奨されます。
  • Contoso は、多数のアプリケーションをオンプレミスから IaaS VM に移行することを計画しています。 それらの VM の多くは、独立系ソフトウェア ベンダーから提供されています。 SQL Managed Instance を使用すれば、これらのアプリケーションのデータベース互換性を確保できると Contoso チームは認識しています。 サポートされない可能性がある SQL Database ではなく、SQL Managed Instance を使用するつもりです。
  • Contoso は、完全に自動化された Azure Database Migration Service を使用して、SQL Managed Instance へのリフトアンドシフト移行を実行できます。 Contoso は、今後のデータベース移行にこのサービスを再利用することもできます。
  • SQL Managed Instance では、SmartHotel360 アプリケーションの重要なコンポーネントである SQL Server エージェントがサポートされています。 Contoso ではこの互換性が必要です。 これがないと、アプリケーションで必要なメンテナンス プランを再設計する必要があります。
  • ソフトウェア アシュアランスにより、Contoso は SQL Server 向け Azure ハイブリッド特典を使用して、現在のライセンスと引き換えに、SQL Managed Instance を割引料金で利用できます。 これにより、Contoso では、SQL Managed Instance を使用して最大 30% のコスト削減が可能となります。
  • SQL Managed Instance は仮想ネットワークに完全に含まれるため、Contoso のデータに対してより優れた分離性とセキュリティが提供されます。 Contoso は、パブリック インターネットから分離された環境を維持しながら、パブリック クラウドのメリットを得ることができます。
  • SQL Managed Instance では、Always Encrypted、動的データ マスキング、行レベルのセキュリティ、脅威検出など、多くのセキュリティ機能がサポートされています。

ソリューションのレビュー

Contoso チームは、長所と短所の一覧をまとめて、提案された設計を評価します。

考慮事項 詳細
長所 Azure に移行するために SmartHotel360 アプリケーション コードを変更する必要はありません。

Contoso では、SQL Server と Windows Server の両方に Azure ハイブリッド特典を使用して、ソフトウェア アシュアランスへの投資を活かすことができます。

移行の後、Contoso では Windows Server 2008 R2 をサポートする必要がありません。 詳細については、「Microsoft ライフサイクル ポリシー」を参照してください。

Contoso では、複数のインスタンスを保持するアプリケーションの Web 層を構成できるので、Web 層は単一障害点ではなくなります。

データベースは古い SQL Server 2008 R2 に依存しなくなります。

SQL Managed Instance では、Contoso の技術面の要件と目標がサポートされています。

SQL Managed Instance では、SQL Server 2008 R2 から移行するときに、現在のデプロイとの 100% の互換性が提供されます。

Contoso は、将来の移行で Database Migration Service を再利用できます。

SQL マネージド インスタンスには、Contoso が構成する必要のないフォールト トレランスが組み込まれています。 このフォールト トレランスにより、データ層がフェールオーバーの単一ポイントではなくなります。
短所 App Service でサポートされるアプリケーションのデプロイは、各 Web アプリにつき 1 つだけです。 そのため、Web サイト用に 1 つと WCF サービス用に 1 つの 2 つの Web アプリをプロビジョニングする必要があります。

データ層について、Contoso がオペレーティング システムまたはデータベース サーバーをカスタマイズしたい場合、または SQL Server と共にサードパーティ製アプリケーションを実行したい場合、SQL Managed Instance は最適なソリューションではない可能性があります。 IaaS VM で SQL Server を実行すると、このような柔軟性が提供されます。

提案されたアーキテクチャ

Diagram that shows the proposed architecture.

移行プロセス

  1. Contoso は、Azure SQL Managed Instance をプロビジョニングし、Database Migration Service を使用して SmartHotel360 データベースをそれに移行します。
  2. Contoso では Web アプリをプロビジョニングして構成し、それらに SmartHotel360 アプリケーションをデプロイします。

Diagram that shows the migration process.

Azure サービス

サービス 説明 コスト
App Service 移行アシスタント コードをほとんど変更することなく、オンプレミスからクラウドに .NET Web アプリを移行するのに役立つ、無料の使いやすいツールです。 このツールは無料でダウンロードできます。
Database Migration Service 最小限のダウンタイムで複数のデータベース ソースから Azure データ プラットフォームに移行するために使用できる Azure サービスです。 Azure Database Migration Service の価格およびサポートされているリージョンを参照してください。
SQL Managed Instance Azure 上のフル マネージド SQL Server インスタンスを表すマネージド データベース サービスです。 最新バージョンの SQL Server データベース エンジンと同じコードを使用し、最新の機能、パフォーマンスの向上、セキュリティ更新プログラムが適用されています。 Azure で SQL Managed Instance を使用すると、容量に基づく料金が発生します。 詳細については、SQL Managed Instance の価格に関するページを参照してください。
Azure App Service フル マネージド プラットフォームを使用した強力なクラウド アプリケーションを作成できるようにするサービスです。 価格は、サイズ、場所、使用時間に基づきます。 詳細については、「App Service の価格」をご覧ください。
Azure Pipelines 継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインをアプリケーション開発に提供するサービスです。 パイプラインは、アプリケーション コードを管理する Git リポジトリで始まり、パッケージおよびその他のビルド成果物を生成するためのビルド システムに続き、開発、テスト、運用の各環境で変更をデプロイするためのリリース管理システムに至ります。 Azure Pipelines の価格について確認してください。

[前提条件]

このシナリオを実装するには、Contoso は次の前提条件を満たす必要があります。

要件 詳細
Azure サブスクリプション このシリーズの先行する記事の中で、Contoso はサブスクリプションを作成しました。 Azure サブスクリプションをお持ちでない場合は、無料アカウントを作成してください。

無料アカウントを作成する場合、サブスクリプションの管理者としてすべてのアクションを実行できます。 既存のサブスクリプションを使用するときに、自分が管理者でない場合、管理者に所有者または共同作成者の権限を自分に割り当ててもらう必要があります。
Azure インフラストラクチャ Contoso は、移行のための Azure インフラストラクチャに関する記事で説明されているように、Azure インフラストラクチャを設定します。

シナリオのステップ

Contoso が移行を実行する方法を次に示します。

  • ステップ 1:Web アプリの評価と移行。 Contoso では、App Service 移行アシスタントを使用して、移行前互換性チェックを実行し、Web アプリを App Service に移行します。
  • 手順 2:SQL マネージド インスタンスを設定する。 Contoso では、オンプレミス SQL Server データベースの移行先となる既存のマネージド インスタンスが必要です。
  • 手順 3: Database Migration Service を使用して移行する。 Contoso は、Database Migration Service を使用してアプリケーション データベースを移行します。
  • 手順 4:Azure DevOps を設定する。 Contoso は新しい Azure DevOps プロジェクトを作成し、Git リポジトリをインポートします。
  • 手順 5:接続文字列を構成する。 Contoso は Web 層 Web アプリ、WCF サービス Web アプリ、SQL マネージド インスタンスが通信できるように接続文字列を構成します。
  • 手順 6:ビルドとリリース パイプラインを Azure DevOps で設定する。 最後の手順では、Contoso は、アプリケーションを作成するためのビルドとリリース パイプラインを Azure DevOps で設定します。 その後、それらのパイプラインを 2 つの個別の Web アプリにデプロイします。

手順 1:Web アプリの評価と移行

Contoso 管理者は、App Service 移行アシスタントを使用して、Web アプリを評価し、移行します。 このプロセスでは、ASP.NET アプリを Azure に移行するラーニング パスをガイドとして使用します。 管理者は、次のアクションを実行します。

  • App Service 移行評価ツールを使用して、Web アプリ間の依存関係を評価し、オンプレミスの Web アプリと App Service でサポートされているものの間に非互換性がないかどうかを判断します。

  • App Service 移行アシスタントをダウンロードし、Azure アカウントにサインインします。

  • サブスクリプション、リソース グループ、Web サイトのドメイン名を選択します。

手順 2:SQL マネージド インスタンスを設定する

Azure SQL Managed Instance を設定するには、以下の要件を満たすサブネットが必要になります。

  • サブネットは専用でなければなりません。 空である必要があります。 他のクラウド サービスを含めることはできません。 サブネットはゲートウェイ サブネットであってはなりません。
  • マネージド インスタンスの作成後、Contoso はサブネットにリソースを追加することはできません。
  • サブネットにネットワーク セキュリティ グループを関連付けることはできません。
  • サブネットにはユーザー定義のルート テーブルが必要です。 割り当てられている唯一のルートが 0.0.0.0/0 の次ホップ インターネットである必要があります。
  • 仮想ネットワーク用に省略可能なカスタム DNS が指定されている場合、Azure 上の再帰的なリゾルバーの仮想 IP アドレス 168.63.129.16 をリストに追加する必要があります。 Azure SQL マネージド インスタンスのカスタム DNS を構成する方法を確認してください。
  • サブネットにサービス エンドポイント (ストレージまたは SQL) を関連付けることはできません。 仮想ネットワークではサービス エンドポイントを無効にする必要があります。
  • サブネットには、IP アドレスが少なくとも 16 個必要です。 マネージド インスタンス サブネットのサイズを指定する方法を確認してください。
  • Contoso のハイブリッド環境では、カスタム DNS 設定が必要です。 Contoso は、自社の 1 つ以上の Azure DNS サーバーを使用するように DNS 設定を構成します。 DNS のカスタマイズの詳細については、こちらを参照してください。

マネージド インスタンス用の仮想ネットワークを設定する

Contoso の管理者は仮想ネットワークを次のように設定します。

  1. プライマリ リージョン (米国東部 2) に仮想ネットワーク (VNET-SQLMI-EUS2) を作成します。 その仮想ネットワークを ContosoNetworkingRG リソース グループに作成します。

  2. 10.235.0.0/24 のアドレス空間を割り当てます。 その範囲がエンタープライズ内の他のどのネットワークとも重複しないことを確認します。

  3. ネットワークに以下の 2 つのサブネットを追加します。

    • SQLMI-DB-EUS2 (10.235.0.0/25)。

    • SQLMI-SAW-EUS2 (10.235.0.128/29)。 このサブネットは、マネージド インスタンスにディレクトリを接続するために使用されます。

      Screenshot that shows the values for creating the managed instance.

  4. 仮想ネットワークとサブネットがデプロイされた後、ネットワークを以下のようにピアリングします。

    • VNET-SQLMI-EUS2 と VNET-HUB-EUS2 (米国東部 2 のハブ仮想ネットワーク) とピアリングします。

    • VNET-SQLMI-EUS2 と VNET-PROD-EUS2 (実稼働ネットワーク) をピアリングします。

      Screenshot that shows the peered networks.

  5. Contoso は、カスタム DNS 設定を行います。 DNS 設定は、最初は Contoso の Azure ドメイン コント ローラーを指しています。 Azure DNS はセカンダリです。 Contoso Azure ドメイン コントローラーは、以下のように配置されます。

    • 配置先は、米国東部 2 リージョンにある実稼働ネットワーク (VNET-PROD-EUS2) のサブネット PROD-DC-EUS2 です。

    • CONTOSODC3 のアドレス: 10.245.42.4

    • CONTOSODC4 のアドレス: 10.245.42.5

    • Azure DNS リゾルバー: 168.63.129.16

    Screenshot that shows the network DNS servers.

さらにサポートが必要な場合

ルーティングを設定する

マネージド インスタンスは、プライベート仮想ネットワーク内に配置されます。 Contoso は、仮想ネットワークが Azure 管理サービスと通信できるようにするためのルート テーブルを必要としています。 仮想ネットワークが、仮想ネットワークを管理するサービスと通信できない場合、仮想ネットワークへのアクセスができなくなります。

Contoso は以下の点を考慮します。

  • ルート テーブルには、マネージド インスタンスから送信されるパケットを仮想ネットワーク内でルーティングする方法を指定した一連のルール (ルート) を含めます。
  • ルート テーブルは、マネージド インスタンスがデプロイされているサブネットに関連付けられています。 サブネットから離れる各パケットは、関連付けられたルート テーブルに基づいて処理されます。
  • 1 つのサブネットは、1 つのルート テーブルにのみ関連付けることができます。
  • Azure でのルート テーブルの作成には追加料金はかかりません。

ルーティングを設定するには、Contoso の管理者は次の手順を実行します。

  1. ContosoNetworkingRG リソース グループ内にユーザー定義ルート テーブルを作成します。

    Screenshot that shows the Create route table dialog.

  2. SQL Managed Instance の要件に準拠するため、管理者は、ルート テーブル (MIRouteTable) のデプロイ後、アドレス プレフィックスが 0.0.0.0/0 のルートを追加します。 [ネクスト ホップの種類] の値を [インターネット] に設定します。

    Screenshot that shows the Add route dialog.

  3. VNET-SQLMI-EUS2 ネットワーク内の SQLMI-DB-EUS2 サブネットにルート テーブルを関連付けます。

    Screenshot that shows the Associate subnet dialog.

さらにサポートが必要な場合

マネージド インスタンス用のルートを設定する方法については、こちらを参照してください。

マネージド インスタンスを作成する

次に、Contoso の管理者は、以下の手順を実行して、SQL Managed Instance をプロビジョニングします。

  1. マネージド インスタンスにより、ビジネス アプリケーションにサービスが提供されるため、管理者は、会社のプライマリ リージョン (米国東部 2) にマネージド インスタンスをデプロイします。 そのマネージド インスタンスを ContosoRG リソース グループに追加します。

  2. インスタンスの価格レベル、コンピューティング サイズ、およびストレージを選択します。 詳細については、SQL Managed Instance の価格に関するページを参照してください。

    Screenshot that shows the SQL Managed Instance dialog.

    マネージド インスタンスをデプロイすると、ContosoRG リソース グループ内に、次の 2 つの新しいリソースが表示されます。

    • SQL マネージド インスタンス。

    • 仮想クラスター (複数のマネージド インスタンスが存在する場合)。

      Screenshot that shows new resources in the ContosoRG resource group.

さらにサポートが必要な場合

マネージド インスタンスをプロビジョニングする方法については、こちらを参照してください。

手順 3: Database Migration Service を使用して移行する

Contoso の管理者は、Database Migration Service を使用してマネージド インスタンスを移行します。 ステップバイステップの移行チュートリアルの手順に従います。 オンライン、オフライン、およびハイブリッド (プレビュー) の移行を実行できます。

Contoso の管理者は、次の手順を実行します。

  • 仮想ネットワークに接続されている Premium SKU を使用して、Database Migration Service インスタンスを作成します。
  • Database Migration Service から、仮想ネットワーク経由で確実にリモート SQL Server インスタンスにアクセスできるようにします。 この手順では、仮想ネットワーク レベル、ネットワーク VPN、および SQL Server をホストするマシンで、Azure から SQL サーバーにすべての受信ポートが許可されていることを確認する必要があります。
  • Database Migration Service を構成します。
    • 移行プロジェクトを作成します。
    • ソース (オンプレミス データベース) を追加します。
    • ターゲットを選択します。
    • 移行するデータベースを選択します。
    • 詳細設定を構成します。
    • レプリケーション を開始します。
    • すべてのエラーを解決します。
    • 最終的なカットオーバーを実行します。

手順 4:Azure DevOps を設定する

Contoso は、アプリケーションのために DevOps インフラストラクチャとパイプラインを構築する必要があります。 これを行うために、Contoso 管理者は新しい DevOps プロジェクトを作成し、コードをインポートしてから、ビルドとリリース パイプラインを設定します。

  1. Contoso Azure DevOps アカウントで、新しいプロジェクト (ContosoSmartHotelRefactor) を作成し、バージョン コントロールに [Git] を選択します。

    Screenshot that shows the new project dialog.

  2. アプリケーション コードを現在保持している Git リポジトリをインポートします。 ダウンロードは、パブリック GitHub リポジトリから行います。

    Screenshot that shows the Import a Git repository dialog.

  3. Visual Studio をリポジトリに接続し、チーム エクスプローラーを使用して開発用マシンにコードを複製します。

    Screenshot that shows the Connect to a Project dialog.

  4. アプリケーションのソリューション ファイルを開きます。 このファイルには、Web アプリと WCF サービスのプロジェクトが別々に存在します。

    Screenshot that shows the web app and WCF service projects in Solution Explorer.

手順 5:接続文字列の構成

Contoso の管理者は、Web アプリとデータベースが互いに通信できるようにします。 そのために、コードと Web アプリで接続文字列を構成します。

  1. WCF サービス (SHWCF-EUS2) の Web アプリで、 [設定]>[アプリケーションの設定] の順に選択し、DefaultConnection という新しい接続文字列を追加します。

  2. 接続文字列は SmartHotel-Registration データベースからプルし、正しい資格情報を使用して更新します。

    Screenshot that shows the connection string settings.

  3. Visual Studio で、管理者はソリューション ファイルから SmartHotel.Registration.wcf プロジェクトを開きます。 このプロジェクトで、接続文字列を追加して、web.config ファイルの connectionStrings セクションを更新します。

    Screenshot that shows the connectionStrings section of the web.config file in the SmartHotel.Registration.wcf project.

  4. SmartHotel.Registration.Web の web.config ファイルの client セクションを更新して、WCF サービスの新しい場所を指すようにします。 このポインターは、サービス エンドポイントをホストする WCF Web アプリの URL です。

    Screenshot that shows the client section of the web.config file in the SmartHotel.Registration.wcf project.

  5. 管理者は、Visual Studio のチーム エクスプローラーを使用して、コード変更のコミットと同期を行います。

手順 6:ビルドとリリース パイプラインを Azure DevOps で設定する

次に、Contoso 管理者は、Azure DevOps を構成して、ビルドおよびリリース プロセスを実行します。

  1. Azure DevOps 内で、[Build and release] (ビルドとリリース)>[New pipeline] (新しいパイプライン) の順に選択します。

    Screenshot that shows the New pipeline button in Azure DevOps.

  2. [Azure Repos Git] を選択し、関連するリポジトリを選択します。

    Screenshot that shows the Azure Repos Git button and the selected repository.

  3. [テンプレートの選択] で、ビルド用の ASP.NET テンプレートを選択します。

    Screenshot that shows the Select a template dialog with the ASP.NET template selected.

  4. ビルドの名前に ContosoSmartHotelRefactor-ASP.NET-CI を使用し、[Save & queue] (保存してキューに登録) を選択して、最初のビルドを開始します。

    Screenshot that shows the Save & queue button for the build.

  5. ビルド番号を選択して、プロセスを監視できるようにします。 プロセスが完了すると、管理者はプロセスのフィードバックを確認できます。 [成果物] を選択してビルド結果を確認します。

    Screenshot that shows the build page and the Artifacts button.

    [Artifacts エクスプローラー] ウィンドウが開きます。 ビルド結果が drop フォルダーに表示されます。

    • 2 つの .zip ファイルは、アプリケーションが格納されているパッケージです。
    • これらの .zip ファイルは、App Service にデプロイするためにリリース パイプライン内で使用されます。

    Screenshot that shows the Artifacts explorer.

  6. [リリース]>[New pipeline] (新しいパイプライン) の順に選択します。

    Screenshot that shows the New pipeline button.

  7. App Service 用のデプロイ テンプレートを選択します。

    Screenshot that shows the Select a template dialog.

  8. リリース パイプラインに ContosoSmartHotel360Refactor という名前を付け、[ステージ名] ボックスに、WCF Web アプリの名前として「SHWCF-EUS2」を指定します。

    Screenshot that shows the stage name of the WCF web app.

  9. ステージの下で、[1 個のジョブ、1 個のタスク] を選択して、WCF サービスのデプロイを構成します。

    Screenshot that shows the 1 job, 1 task option.

  10. サブスクリプションが選択および承認されていることを確認し、App Service の名前を選択します。

    Screenshot that shows the app service name.

  11. パイプラインで [成果物]、[成果物の追加] の順に選択し、ソースの種類に [ビルド] を選択して、ContosoSmarthotel360Refactor パイプラインを使用してビルドします。

    Screenshot that shows the Build button in the Add an artifact dialog.

  12. 継続的デプロイ トリガーを有効にするために、管理者は成果物にある稲妻ボタンを選択します。

    Screenshot that shows the lightning bolt button on the artifact.

  13. 継続的デプロイ トリガーを [有効] に設定します。

    Screenshot that shows the continuous deployment trigger set to Enabled.

  14. 管理者は、ステージ [1 個のジョブ、1 個のタスク] に戻り、[Deploy Azure App Service] (Azure App Service のデプロイ) を選択します。

    Screenshot that shows the Deploy Azure App Service option.

  15. [ファイルまたはフォルダーを選択します] で drop フォルダーを展開し、ビルド中に作成された SmartHotel.Registration.Wcf.zip ファイルを選択して、[保存] を選択します。

    Screenshot that shows the Select a file or folder dialog.

  16. [パイプライン]>[ステージ] の順に選択し、[追加] を選択して、SHWEB-EUS2 用の環境を追加します。 別の Azure App Service のデプロイを選択します。

    Screenshot that shows the 1 job, 1 task link.

  17. このプロセスを繰り返して Web アプリの SmartHotel.Registration.Web.zip ファイルを適切な Web アプリに発行し、[保存] を選択します。

    Screenshot that shows the Select a file or folder dialog for selecting the web file.

    次のリリース パイプラインが表示されます。

    Screenshot that shows the release pipeline.

  18. [ビルド] に戻り、[トリガー] を選択して、[継続的インテグレーションを有効にする] を選択します。 この操作でパイプラインが有効になり、変更がコードに対してコミットされると、フル ビルドとリリースが行われます。

    Screenshot that shows the Enable continuous integration checkbox.

  19. [Save & queue] (保存してキューに登録) を選択し、フル パイプラインを実行します。 新しいビルドがトリガーされ、続いてアプリケーションの最初のリリースが App Service に対して作成されます。

    Screenshot that shows the Save & queue button.

  20. Contoso 管理者は、Azure DevOps からビルドとリリース パイプラインのプロセスに従うことができます。 ビルドの完了後、リリースが開始されます。

    Screenshot that shows the build and release progress.

  21. パイプラインが完了すると、両方のサイトがデプロイされ、アプリケーションがオンラインで実行されます。

    Screenshot that shows the running application.

    アプリケーションが Azure に正常に移行されました。

移行後にクリーンアップする

移行後、Contoso チームは、以下のクリーンアップ手順を実行します。

  • vCenter のインベントリからオンプレミスの VM を削除します。
  • ローカルのバックアップ ジョブから VM を削除します。
  • SmartHotel360 アプリケーションの新しい場所を示すように社内ドキュメントを更新します。 このドキュメントには、データベースは SQL Managed Instance で実行され、フロントエンドは 2 つの Web アプリで実行されていることが示されます。
  • 使用停止されている VM と対話しているリソースがないかを確認します。また、関連する設定やドキュメントがあれば、更新して新しい構成を反映します。

デプロイを再調査する

リソースが Azure に移行されると、Contoso は新しいインフラストラクチャを完全に運用化し、そのセキュリティを確保する必要があります。

セキュリティ

  • Contoso は、新しい SmartHotel-Registration データベースのセキュリティを確保します。 詳細については、Azure SQL Database と SQL Managed Instance のセキュリティに関するページを参照してください。
  • 特に、Contoso は証明書で SSL を使用するように Web アプリを更新します。

バックアップ

  • Contoso チームは、SQL Managed Instance のデータベースのバックアップ要件を確認します。 詳細については、「Azure SQL データベースの自動バックアップ」を参照してください。
  • また、SQL Database のバックアップと復元の管理について確認します。 詳細については、自動バックアップに関するページを参照してください。
  • データベースのリージョン内フェールオーバーを提供するようにフェールオーバー グループの実装を検討します。 詳細については、自動フェールオーバー グループの概要に関するページを参照してください。
  • 回復性を高めるために、メイン リージョン (米国東部 2) とセカンダリ リージョン (米国中部) に Web アプリをデプロイすることを検討します。 チームはリージョンの障害が発生しても確実にフェールオーバーされるように Traffic Manager を構成することができます。

ライセンスとコストの最適化

  • すべてのリソースがデプロイされると、Contoso は インフラストラクチャ計画中に決定した Azure タグを割り当てます。
  • すべてのライセンスは、Contoso が使用している PaaS サービスのコストに組み込まれています。 このコストは Enterprise Agreement から差し引かれます。
  • Contoso は Azure Cost Management と Billing を使用して、IT リーダーが定めた予算内で確実に運用されるようにします。

まとめ

この記事の中で、Contoso は、アプリケーションのフロントエンド VM を 2 つの App Service Web アプリに移行することで、Azure にある SmartHotel360 アプリケーションをリファクターしました。 Contoso は、アプリケーション データベースを Azure SQL Managed Instance に移行しました。