Azure App Service と SQL Database にアプリケーションを移行する

[アーティクル]
03/17/2023

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

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

ビジネスドライバー

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

ビジネスの成長への対応。 Contoso は成長を続けており、オンプレミスのシステムとインフラストラクチャに負荷がかかっています。
効率化。 Contoso では、不要な手順を排除し、開発者とユーザーのプロセスを効率化する必要があります。ビジネス部門は IT に対して、時間やコストを無駄にせず、迅速に作業を行ってもらう必要があります。これは、例えば、顧客の要求に素早く対応するためです。
機敏性の向上。 Contoso IT は、グローバル経済における成功を実現するために、ビジネス部門の要求に対して、対応力を向上させる必要があります。市場の変化に対して、より迅速に対応できなければなりません。 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) サービスから成ります。 Azure 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 ホスト contosohost1.contoso.com バージョン 6.5 上に配置されています。
VMware 環境は、VM 上で実行されている vCenter Server 6.5 (vcenter.contoso.com) によって管理されています。
Contoso には、オンプレミスのデータセンター (contoso-datacenter) があり、オンプレミスのドメインコントローラー (contosodc1) が含まれています。
Contoso データセンター内のオンプレミス VM は、移行が行われた後に使用停止にされます。

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

このアプリケーションのデータベース層について、Contoso は「機能の比較: Azure SQL Database と Azure SQL Managed Instance」を参照して、Azure SQL Database と SQL Server を比較しました。そして、いくつかの理由で Azure SQL Database を使用することにしました。
- Azure SQL Database は、マネージドリレーショナルデータベースサービスです。複数のサービスレベルで予測可能なパフォーマンスを実現します。管理作業はほぼゼロです。利点としては、ダウンタイムのない動的スケーラビリティ、組み込みのインテリジェントな最適化、グローバルなスケーラビリティと可用性などがあります。
- Contoso では軽量な Data Migration Assistant を利用して、Azure SQL Database へのオンプレミスデータベースの移行を評価することができます。
- Contoso では Azure Database Migration Service を利用して、Azure SQL Database にオンプレミスデータベースを移行できます。
- ソフトウェアアシュアランスにより、Contoso は、SQL Server 用の Azure ハイブリッド特典を使用して、既存のライセンスと引き換えに、SQL Database のデータベースを割引料金で利用することができます。この方法なら最大 30% のコスト削減が可能です。
- SQL Database では、Always Encrypted、動的データマスキング、行レベルのセキュリティ、SQL 脅威検出などのセキュリティ機能を提供しています。
Contoso では、アプリケーションの Web 層については、Azure App Service を使用することに決めました。この PaaS サービスを使用すると、わずかな構成変更だけでアプリケーションをデプロイできます。 Contoso は Visual Studio を使用して変更を加え、Web サイト用と WCF サービス用の 2 つの Web アプリをデプロイします。
DevOps パイプラインの要件を満たすために、Contoso は Git リポジトリと共に Azure DevOps のソースコード管理を使用します。コードをビルドして Azure App Service にデプロイするには、自動ビルドとリリースが使用されます。

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

Contoso は、次の表のように長所と短所の一覧をまとめて、提案されたデザインを評価します。

考慮事項	詳細
長所	Azure に移行するために SmartHotel360 アプリケーションコードを変更する必要はありません。 Contoso では、SQL Server と Windows Server の両方に Azure ハイブリッド特典を使用して、ソフトウェアアシュアランスへの投資を活かすことができます。移行後は、Windows Server 2008 R2 をサポートする必要がなくなります。詳細については、「Microsoft ライフサイクルポリシー」を参照してください。 Contoso では、複数のインスタンスを保持するアプリケーションの Web 層を構成できるので、Web 層は単一障害点ではなくなります。データベースは古い SQL Server 2008 R2 に依存しなくなります。 SQL Database は技術面の要件をサポートしています。 Contoso で Data Migration Assistant を使用してオンプレミスデータベースを評価したところ、互換性があることがわかりました。 Azure SQL Database には、Contoso が設定する必要がないフォールトトレランス機能が組み込まれています。そのため、データ層がフェールオーバーの単一ポイントではなくなります。 Contoso が Azure Database Migration Service を使用してデータベースを移行する場合、規模に応じてデータベースを移行するためのインフラストラクチャが用意されます。
短所	Azure App Service でサポートされるアプリケーションのデプロイは、各 Web アプリにつき 1 つだけです。これは、2 つの Web アプリをプロビジョニングする必要がある (Web サイト用に 1 つと WCF サービス用に 1 つ) ことを意味します。

考慮事項

詳細

長所

Azure に移行するために SmartHotel360 アプリケーションコードを変更する必要はありません。

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

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

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

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

SQL Database は技術面の要件をサポートしています。 Contoso で Data Migration Assistant を使用してオンプレミスデータベースを評価したところ、互換性があることがわかりました。

Azure SQL Database には、Contoso が設定する必要がないフォールトトレランス機能が組み込まれています。そのため、データ層がフェールオーバーの単一ポイントではなくなります。

Contoso が Azure Database Migration Service を使用してデータベースを移行する場合、規模に応じてデータベースを移行するためのインフラストラクチャが用意されます。

短所

Azure App Service でサポートされるアプリケーションのデプロイは、各 Web アプリにつき 1 つだけです。これは、2 つの Web アプリをプロビジョニングする必要がある (Web サイト用に 1 つと WCF サービス用に 1 つ) ことを意味します。

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

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

移行プロセス

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

Azure サービス

サービス	説明	コスト
Azure App Service Migration Assistant	コードをほとんど変更することなく、オンプレミスからクラウドに .NET Web アプリをシームレスに移行するための、無料のシンプルなパスです。	このツールは無料でダウンロードできます。
Data Migration Assistant	Contoso は Data Migration Assistant を使用して、Azure でのデータベースの機能に影響を与える可能性のある互換性の問題を評価し、検出します。 Data Migration Assistant は SQL のソースとターゲット間で機能パリティを評価し、パフォーマンスと信頼性の向上箇所を推奨します。	このツールは無料でダウンロードできます。
Azure Database Migration Service	Azure Database Migration Service を使用すると、複数のデータベースソースから Azure データプラットフォームに、ダウンタイムを最小限に抑えながらシームレスに移行できます。	サポートされているリージョンに関する情報と、Database Migration Service の価格に関する情報をご覧ください。
Azure SQL Database	インテリジェントなフルマネージドリレーショナルクラウドデータベースサービス。	コストは、機能、スループット、サイズに基づきます。詳細については、こちらを参照してください。
Azure App Service	フルマネージドプラットフォームを使用した強力なクラウドアプリケーションを作成できます。	価格は、サイズ、場所、使用時間に基づきます。詳細については、こちらを参照してください。
Azure Pipelines	アプリケーション開発のための継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインが用意されています。パイプラインは、アプリケーションコードを管理するための Git リポジトリ、パッケージやその他のビルド成果物を生成するためのビルドシステム、開発、テスト、および運用環境で変更をデプロイするためのリリース管理システムから始まります。

前提条件

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

必要条件	詳細
Azure サブスクリプション	Contoso は、この記事シリーズの前の記事でサブスクリプションを作成しました。 Azure サブスクリプションをお持ちでない場合は、無料アカウントを作成してください。無料アカウントを作成する場合、サブスクリプションの管理者としてすべてのアクションを実行できます。既存のサブスクリプションを使用しており、管理者でない場合は、管理者に依頼して所有者アクセス許可または共同作成者アクセス許可を割り当ててもらう必要があります。
Azure インフラストラクチャ	Contoso は、移行のための Azure インフラストラクチャについての記事で説明されているように、Azure インフラストラクチャを設定します。

必要条件

詳細

Azure サブスクリプション

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

無料アカウントを作成する場合、サブスクリプションの管理者としてすべてのアクションを実行できます。

既存のサブスクリプションを使用しており、管理者でない場合は、管理者に依頼して所有者アクセス許可または共同作成者アクセス許可を割り当ててもらう必要があります。

Azure インフラストラクチャ

Contoso は、移行のための Azure インフラストラクチャについての記事で説明されているように、Azure インフラストラクチャを設定します。

シナリオのステップ

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

ステップ 1:Web アプリの評価と移行。 Contoso では、Azure App Service Migration Assistant ツールを使用して、移行前互換性チェックを実行し、Web アプリを Azure App Service に移行します。
手順 2:Azure SQL Database にデータベースをプロビジョニングする。 Contoso が Azure SQL データベースインスタンスをプロビジョニングします。アプリケーションの Web サイトが Azure に移行されると、WCF サービス Web アプリはこのインスタンスを指します。
ステップ 3:データベースを評価する。 Contoso は、移行するデータベースを Data Migration Assistant を使用して評価し、Azure 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 管理者は、Azure App Service Migration Assistant ツールを使用して、Web アプリを評価し、移行します。このプロセスでは、ASP.NET アプリケーションを Azure に移行するラーニングパスをガイドとして使用します。管理者は、次のアクションを実行します。

Azure App Service 移行評価ツールを使用して、Web アプリ間の依存関係を評価し、オンプレミスの Web アプリと Azure App Service でサポートされているものの間に非互換性がないかどうかを判断します。
Azure App Service Migration Assistant をダウンロードし、Azure アカウントにサインインします。
サブスクリプション、リソースグループ、Web サイトのドメイン名を選択します。

手順 2:Azure SQL Database にデータベースをプロビジョニングする

Contoso 管理者は、Azure SQL データベースインスタンスの作成を決めます。
オンプレミス VM 上で実行されているデータベース (SmartHotel.Registration) と一致するようにデータベース名を指定します。 ContosoRG リソースグループにデータベースを配置します。これは、Azure の運用リソースに使用するリソースグループです。
プライマリリージョンに新しい SQL Server インスタンス (sql-smarthotel-eus2) を設定します。
サーバーとデータベースのニーズに合わせて価格レベルを設定します。既に SQL Server のライセンスを持っているため、Azure ハイブリッド特典で費用を節約することにします。
サイズ設定については、仮想コアベースの購入を使用し、予想される要件の制限を設定します。
データベースインスタンスを作成します。
データベースを開き、Data Migration Assistant を移行に使用するときに必要な詳細情報を書き留めます。

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

SQL データベースのプロビジョニングの手順を参照します。
仮想コアリソースの制限に関する説明を参照します。

手順 3:データベースを評価する

Contoso の管理者は、Data Migration Assistant を使用してデータベースを評価した後、ステップバイステップの移行チュートリアルを参照し、Azure Database Migration Service を使用してそれを移行します。オンライン、オフライン、およびハイブリッド (プレビュー) の移行を実行できます。

管理者が行う作業の概要は次のとおりです。

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

手順 4:Azure DevOps を設定する

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

Contoso Azure DevOps アカウントで、新しいプロジェクト (ContosoSmartHotelRefactor) を作成し、バージョンコントロールに [Git] を選択します。
アプリケーションコードを現在保持している Git リポジトリをインポートします。ダウンロードは、パブリック GitHub リポジトリから行います。
Visual Studio をリポジトリに接続し、チームエクスプローラーを使用して開発用マシンにコードを複製します。
アプリケーションのソリューションファイルを開きます。このファイルには、Web アプリのプロジェクトと WCF サービスのプロジェクトが別々に存在します。

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

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

WCF サービス (SHWCF-EUS2) の Web アプリで、 [設定]>[アプリケーションの設定] の順に選択し、DefaultConnection という名前の新しい接続文字列を追加します。
接続文字列は SmartHotel-Registration データベースからプルし、正しい資格情報を使用して更新します。
Visual Studio で、管理者がソリューションファイルから SmartHotel.Registration.wcf プロジェクトを開きます。このプロジェクトの web.config ファイルの connectionStrings セクションを接続文字列で更新します。
SmartHotel.Registration.Web の web.config ファイルの client セクションを、WCF サービスの新しい場所を指すように変更します。これは、サービスエンドポイントをホストする WCF Web アプリの URL です。
コードの変更は以上で完了です。管理者は、Visual Studio のチームエクスプローラーを使用して、変更のコミットと同期を行います。

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

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

Azure DevOps 内で、 [Build and release](ビルドとリリース)>[新しいパイプライン] の順に選択します。
[Azure Repos Git] を選択し、[リポジトリ]ドロップダウンリストから適切なリポジトリを選択します。
[テンプレートの選択] で、ビルド用の ASP.NET テンプレートを選択します。
ビルドの名前に ContosoSmartHotelRefactor-ASP.NET-CI を使用し、 [保存してキューに登録] を選択して、最初のビルドを開始します。
プロセスを監視するビルド番号を選択します。完了後、管理者はプロセスのフィードバックを表示し、 [成果物] を選択してビルドの結果を確認できます。

[成果物エクスプローラー] ペインが開き、drop フォルダーにビルド結果が表示されます。
- 2 つの .zip ファイルは、アプリケーションが格納されているパッケージです。
- これらの .zip ファイルは、Azure App Service にデプロイするためにリリースパイプライン内で使用されます。
[リリース]>[+ New pipeline](+ 新しいパイプライン) の順に選択します。
Azure App Service 用のデプロイテンプレートを選択します。
リリースパイプラインに ContosoSmartHotel360Refactor という名前を付け、 [ステージ名] ボックスに、WCF Web アプリの名前として「SHWCF-EUS2」を指定します。
ステージ下で、 [1 個のジョブ、1 個のタスク] を選択して WCF サービスのデプロイを構成します。
サブスクリプションが選択および承認されていることを確認し、 [App Service の名前] を選択します。
パイプライン >[成果物] で、[+ Add an artifact](+ 成果物の追加) を選択し、ContosoSmarthotel360Refactor パイプラインを使用してビルドするように選択します。
継続的デプロイトリガーを有効にするために、管理者が成果物の稲妻アイコンを選択します。
継続的デプロイトリガーを [有効] に設定します。
管理者は、ステージ [1 個のジョブ、1 個のタスク] に戻り、 [Deploy Azure App Service](Azure App Service のデプロイ) を選択します。
[Select a file or folder](ファイルまたはフォルダーの選択) で drop フォルダーを展開し、ビルド中に作成された SmartHotel.Registration.Wcf.zip ファイルを選択して、 [保存] を選択します。
[パイプライン]>[ステージ] の順に選択し、 [+ 追加] を選択して、SHWEB-EUS2 用の環境を追加します。別の Azure App Service のデプロイを選択します。
このプロセスを繰り返して SmartHotel.Registration.Web.zip ファイルを適切な Web アプリに発行し、 [保存] を選択します。

次のリリースパイプラインが表示されます。
[ビルド] に戻り、[トリガー] を選択して、[継続的インテグレーションを有効にする] チェックボックスをオンにします。この操作でパイプラインが有効になり、変更がコードに対してコミットされると、フルビルドとリリースが行われます。
[保存してキューに登録] を選択し、フルパイプラインを実行します。新しいビルドがトリガーされ、続いてアプリケーションの最初のリリースが Azure App Service に対して作成されます。
Contoso 管理者は、Azure DevOps からビルドとリリースパイプラインのプロセスに従うことができます。ビルドの完了後、リリースが開始されます。
パイプラインが完了すると、両方のサイトがデプロイされ、アプリケーションがオンラインで稼働します。

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

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

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

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

デプロイを再調査する

リソースを Azure に移行したら、新しいインフラストラクチャを完全に運用可能な状態にすると共に、そのセキュリティの保護に努める必要があります。

セキュリティ

Contoso は新しい SmartHotel-Registration データベースのセキュリティ保護に努めます。詳細については、こちらを参照してください。
特に、Contoso は証明書で SSL を使用するように Web アプリを更新します。

バックアップ

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

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

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

まとめ

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

Azure App Service と SQL Database にアプリケーションを移行する

ビジネスドライバー

移行の目標