セールス: 1-800-867-1380

Azure 仮想マシンの SQL Server のアプリケーション パターンと開発戦略

SQL Server と Azure に関する技術記事

概要: Azure 環境の SQL Server ベースのアプリケーションに使用するアプリケーション パターンを判断することは設計における重要な決定であり、SQL Server と Azure の各インフラストラクチャ コンポーネントが連動するしくみをしっかり理解していることが要求されます。Azure インフラストラクチャ サービスに SQL Server を置くことで、Windows Server で構築された既存の SQL Server アプリケーションを Azure の仮想マシンに簡単に移行し、保守管理し、監視できます。

この記事の目標は、ソリューションの設計者と開発者に、優れたアプリケーションを構築し、設計するための基礎を提供することです。この基礎に従い、既存のアプリケーションを Azure に移行し、Azure で新しいアプリケーションを開発できます。

アプリケーションのパターンごとに、オンプレミス シナリオ、その個々のクラウド対応ソリューション、関連する技術推奨事項を紹介します。また、アプリケーションを正しく設計できるように、Azure 特有の開発手法についても説明します。アプリケーションのパターンは多数存在し、それぞれにすべて異なるため、設計者と開発者には、アプリケーションとユーザーに最も適したパターンを選択することが推奨されます。

執筆者: Selcin Turkarslan

技術寄稿者: Luis Carlos Vargas Herring、Madhan Arumugam Ramakrishnan

技術校閲者: Corey Sanders、Drew McDaniel、Narayan Annamalai、Nir Mashkowski、Sanjay Mishra、Silvano Coriani、Stefan Schackow、Tim Hickey、Tim Wieman、Xin Jin

更新日付: 06-12-2014

目次

概要

異なるアプリケーション層のコンポーネントを、異なるコンピューターおよび別々のコンポーネントに分離することで、さまざまな種類の n 層アプリケーションを開発できます。たとえば、クライアント アプリケーションとビジネス ルール コンポーネントを 1 つのマシンに置き、フロントエンド Web 層とデータ アクセス層のコンポーネントを別のマシンに置き、バックエンド データベース層をさらに別のマシンに置くことができます。この種類の構造では、層が互いから分離されます。データの発生源を変更する場合、クライアントまたは Web アプリケーションを変更する必要がありません。データ アクセス層のコンポーネントのみを変更します。

一般的な n 層アプリケーションにはプレゼンテーション層、ビジネス層、データ層があります。

  • プレゼンテーション層 (Web 層、フロントエンド層) は、ユーザーがアプリケーションと対話する層です。

  • ビジネス層 (中間層) はプレゼンテーション層とデータ層が互いと通信するために使われる層であり、システムの中枢機能が含まれています。

  • データ層は、基本的に、アプリケーションのデータを保管するサーバーです (SQL Server を実行するサーバーなど)。

アプリケーション層はアプリケーションの機能とコンポーネントの論理的なグループを表します。層は、個々の物理サーバー、コンピューター、ネットワーク、離れた場所にある機能とコンポーネントの物理的分布を表します。アプリケーションの層は同じ物理コンピューター (同じ層) に置かれる場合があります。あるいは、別個のコンピューター (n 層) とコンポーネントに分散され、各層が明確に定義されたインターフェイスを介して他の層のコンポーネントと通信する場合があります。層という用語は、2 層、3 層、n 層など、物理的分布パターンとして考えることができます。2 層アプリケーション パターンには、アプリケーション サーバーとデータベース サーバーの 2 つのアプリケーション層が含まれます。アプリケーション サーバーとデータベース サーバーは直接通信します。アプリケーション サーバーには、Web 層とビジネス層の両方のコンポーネントが含まれています。3 層アプリケーション パターンには、Web サーバー、アプリケーション サーバー (ビジネス論理層とビジネス層の両方または一方のデータ アクセス コンポーネントを含む)、データベース サーバーの 3 つのアプリケーション層があります。Web サーバーとデータベース サーバーの通信はアプリケーション サーバーで行われます。アプリケーション層に関する詳細については、「マイクロソフト アプリケーション アーキテクチャ ガイド」を参照してください。

この記事を読むには、SQL Server と Azure の基礎概念に関する知識が必要です。詳細については、「SQL Server オンライン ブック」、「Azure の仮想マシンにおける SQL Server」、「WindowsAzure.com」を参照してください。

この記事では、簡易なアプリケーションと複雑で高度な企業アプリケーションに適したアプリケーション パターンをいくつか紹介します。各パターンに関する説明を読む前に、Azure ストレージ などの Azure のデータ ストレージ サービス、Azure SQL データベースAzure 仮想マシンの SQL Server に関する知識を身に付けておくことをお勧めします。アプリケーションのための最高の設計を判断するには、データ ストレージ サービスを利用するタイミングを明確に理解します。「データ管理: 正しい技術を選ぶ」という記事で、Azure の各データ ストレージ サービスを詳しく比較しています。

まとめると、Azure 仮想マシンでは SQL Server を次の場合に選択します。

  • SQL Server オンプレミスとの完全互換性が必要であり、既存のアプリケーションを Azure に現状のまま移動することを考えています。

  • Azure 環境の機能を活用することを考えているか、Azure SQL データベース (SQL データベース) では次のようなアプリケーションまたはデータベースが必要とする機能の一部がサポートされていません。

    • 高可用性と災害復旧: AlwaysOn 可用性グループやデータベース ミラーリングなど、SQL Server の従来の可用性と障害復旧の機能を導入しようと考えています。Azure 仮想マシンに SQL Server を置くことで、完全なコントロールが与えられた上で、アプリケーションのために SQL Server ベースの高可用性と障害復旧のソリューションを設定し、実行できます。この機能を導入することで、Azure のソフトウェアまたはハードウェアの障害またはオペレーティング システムのアップグレードに起因するダウンタイムをデータベースで回避できます。一方で、Azure SQL データベースには Azure のノード レベルの障害に対する回復力が組み込まれています。ノードでエラーが発生した場合は、データベースがいずれかのセカンダリ レプリカに自動的にフェールオーバーします。フェールオーバーの発生はコントロールできないため、SQL データベースに対して実行されているクライアント アプリケーションの接続中断に対処する必要があります。

    • データベース サイズ: 現在のところ、SQL データベースは最大 150 GB のデータのデータベースをサポートします。アプリケーションに 150 GB 以上のデータが必要であるが、カスタム シャーディング ソリューションの実装は望まない場合、Azure 仮想マシンで SQL Server を使用することをお勧めします。

    • HIPAA 準拠: ヘルスケアのお客様と独立系ソフトウェア ベンダー (ISV) は Azure SQL データベース の代わりに Azure 仮想マシンの SQL Server を選択することがあります。Azure 仮想マシンの SQL Server は HIPAA Business Associate Agreement (BAA) に含まれるためです。コンプライアンスに関する詳細については、Azure トラスト センターを参照してください。

    • 機能のギャップ: 一部のお客様は Azure SQL データベースの代わりに Azure 仮想マシンの SQL Server を選択することがあります。データ圧縮やバックアップと復旧における柔軟性など、Azure SQL データベースの機能ギャップがその理由です。詳細については、「Guidelines and Limitations (Azure SQL Database)」を参照してください。

1 層アプリケーション パターン:単一の仮想マシン

このアプリケーション パターンでは、SQL Server アプリケーションおよびデータベースを Azure のスタンドアロン仮想マシンに配置します。同じ仮想マシンに、クライアント/Web アプリケーション、ビジネス コンポーネント、データ アクセス層、データベース サーバーが含まれます。プレゼンテーション、ビジネス、データ アクセス コードは論理的には分離されていますが、物理的には 1 つのサーバー マシンに置かれています。ほとんどのお客様はこのアプリケーション パターンから始め、その後、システムに Web ロールや仮想マシンを追加し、拡張します。

このアプリケーション パターンは次の場合に役立ちます。

  • Azure プラットフォームに簡単な移行を実行し、このプラットホームがアプリケーションの要件を満たすかどうかを評価します。

  • 同じ Azure データ センターの同じ仮想マシンにすべてのアプリケーション層をホストし、層の間の待機時間を短縮します。

  • 短期間で開発とテスト環境をすばやくプロビジョニングします。

  • 変化する作業負荷レベルでストレステストを実行しますが、同時に、多くの物理マシンをずっと所有し、保守管理することは望みません。

次の図は、単純なオンプレミス シナリオと、Azure の 1 つの仮想マシンにクラウド対応ソリューションを配置する方法を示したものです。

1 層アプリケーション パターン

プレゼンテーション層と同じ物理層にビジネス層 (ビジネス ロジックとデータ アクセスのコンポーネント) を配置すると、拡張性とセキュリティの懸念事項に起因して個別の層を使う必要がない限り、アプリケーションのパフォーマンスを最大まで引き出します。

これは最初のパターンとしては非常に一般的であるため、オンプレミス データとアプリケーション ファイルを Azure 仮想マシンに移行する際、次のリンクが役に立つことがあります。Azure の仮想マシンに SQL Server を移行するための準備 および Migrating to SQL Server in an Azure Virtual Machine。また、Azure のインポート サービスとエクスポート サービスを使用し、BLOB ストレージにデータを転送できます。インポート/エクスポート サービスを使用し、インポート ジョブを作成し、Azure ストレージにデータ ファイルを移動します。マイクロソフトはディスクのデータを Azure ストレージにアップロードします。仮想マシンと同じデータ センターの BLOB ストレージにファイル データをアップロードする作業をマイクロソフトが完了したら、リモート デスクトップを使用して仮想マシンに接続し、BLOB ストレージからデータ ファイルをダウンロードできます。Blob ストレージ SDK を利用し、Blob ストレージのファイルにアクセスすることもできます。

3 層の単純なアプリケーション パターン:複数の仮想マシン

このアプリケーション パターンでは、異なる仮想マシンにそれぞれのアプリケーション層を配置し、Azure で 3 層のアプリケーションを展開します。これにより、簡単に拡張または縮小するシナリオのために柔軟な環境が与えられます。1 つの仮想マシンにクライアント/Web アプリケーションが含まれるとき、もう 1 つの仮想マシンはビジネス コンポーネントをホストし、さらにもう 1 つの仮想マシンがデータベース サーバーをホストします。

このアプリケーション パターンは次の場合に役立ちます。

  • 複雑なデータベース アプリケーションを Azure 仮想マシンに移行します。

  • 異なるアプリケーション層を異なる地域にホストします。たとえば、レポート目的で複数の地域に共有データ ソースを配置します。

  • オンプレミスの仮想化プラットフォームから Azure 仮想マシンに企業アプリケーションを移動します。企業アプリケーションの詳細については、「企業アプリケーションとは」を参照してください。

  • 短期間で開発とテスト環境をすばやくプロビジョニングします。

  • 変化する作業負荷レベルでストレステストを実行しますが、同時に、多くの物理マシンをずっと所有し、保守管理することは望みません。

次の図は、異なる仮想マシンに各アプリケーション層を配置し、Azure で単純な 3 層のアプリケーションを展開する方法を示したものです。

3 層アプリケーション パターン

このアプリケーション パターンでは、各層に仮想マシン (VM) が 1 つだけ存在します。Azure に複数の VM がある場合、仮想ネットワークを設定することをお勧めします。Azure 仮想ネットワークは信頼されるセキュリティ境界を作り、プライベート IP アドレスで VM 間の通信を許可します。また、すべてのインターネット接続がプレゼンテーション層のみに進むことを常に確認します。つまり、プレゼンテーション層でパブリックエンドポイントを開き、他の層では開きません。このアプリケーション パターンに従うときは、そのパブリック ポートでネットワーク アクセス制御リスト (ACL) を設定し、特定の IP アドレスへのアクセスを許可する必要があります。詳細については、「ネットワーク アクセス制御リストについて」を参照してください。

この図では、インターネット プロトコルは TCP、UDP、HTTP、HTTPS になります。

重要: Azure には無料で仮想ネットワークを設定できます。ただし、オンプレミスに接続する VPN ゲートウェイに対して課金されます。この請求は、その接続がプロビジョニングされ、利用可能になっている時間に基づきます。

プレゼンテーション層のスケール アウトによる 2 層と 3 層のアプリケーション パターン

このアプリケーション パターンでは、異なる仮想マシンに各アプリケーション層を配置し、Azure 仮想マシンに 2 層または 3 層のデータベース アプリケーションを展開します。また、入ってくるクライアント要求の量が増えるため、プレゼンテーション層をスケール アウトします。

このアプリケーション パターンは次の場合に役立ちます。

  • オンプレミスの仮想化プラットフォームから Azure 仮想マシンに企業アプリケーションを移動します。

  • 入ってくるクライアント要求の量が増えるため、プレゼンテーション層をスケール アウトします。

  • 短期間で開発とテスト環境をすばやくプロビジョニングします。

  • 変化する作業負荷レベルでストレステストを実行しますが、同時に、多くの物理マシンをずっと所有し、保守管理することは望みません。

  • 必要に応じてスケールアップまたはスケールダウンできるインフラストラクチャ環境を所有します。

次の図は、Azure の複数の仮想マシンにアプリケーション層を配置する方法を示したものです。入ってくるクライアント要求の量が増えるため、プレゼンテーション層をスケール アウトします。図からわかるように、Azure ロード バランサーは複数の仮想マシンにトラフィックを分散し、接続する Web サーバーを決定します。ロード バランサーの後に Web サーバーのインスタンスを複数置くことで、プレゼンテーション層の可用性が高くなります。詳細については、「1 つの層に複数の仮想マシンを持つ 2 層、3 層、n 層のアプリケーション パターンのベスト プラクティス」のベスト プラクティスを参照してください。

アプリケーション パターン - プレゼンテーション層のスケール アウト

1 つの層に複数の仮想マシンを持つ 2 層、3 層、n 層のアプリケーション パターンのベスト プラクティス

同じ層に属する仮想マシンを同じクラウド サービスと同じ可用性セットに配置することをお勧めします。たとえば、Web サーバーのセットを CloudService1AvailabilitySet1 に配置し、データベース サーバーのセットを CloudService2AvailabilitySet2 に配置します。Azure の可用性セットを利用し、別個のフォールト ドメインとアップグレード ドメインに高可用性ノードを配置できます。詳細については、「仮想マシンの可用性管理」と「クラウド サービスの仮想マシンに接続する方法」を参照してください。

層の複数の VM インスタンスを活用するには、アプリケーション層間で Azure ロード バランサーを設定する必要があります。各層でロード バランサーを設定するには、各層の VM で負荷が分散されたエンドポイントを別々に作成します。特定の層に対して、最初に同じクラウド サービスで VM を作成します。これで、すべての VM に同じパブリック仮想 IP アドレスが与えられます。次に、その層の仮想マシンの 1 つでエンドポイントを作成します。次に、その層のその他の仮想マシンに同じエンドポイントを割り当て、負荷を分散します。負荷が分散されたセットを作成することで、複数の仮想マシンにトラフィックを分散します。また、ロード バランサーはバックエンド VM ノードに障害が発生したときに接続するノードを決定できます。たとえば、ロード バランサーの後に Web サーバーのインスタンスを複数置くことで、プレゼンテーション層の可用性が高くなります。

ベスト プラクティスとしては、すべてのインターネット接続が最初にプレゼンテーション層に進むことを常に確認します。プレゼンテーション層はビジネス層にアクセスし、ビジネス層はデータ層にアクセスします。たとえば、プレゼンテーション層でエンドポイントを開きます。各エンドポイントにはパブリック ポートとプライベート ポートがあります。プライベート ポートは仮想マシンがそのエンドポイントのトラフィックを待機するために内部で使用されます。パブリック ポートは Azure の外から通信するためのエントリ ポイントであり、Azure ロード バランサーにより使用されます。ネットワーク アクセス制御リスト (ACL) を設定し、アプリケーション層のパブリック エンドポイントのパブリック ポートに入ってくるトラフィックを分離し、制御するルールを定義することをお勧めします。詳細については、「ネットワーク アクセス制御リストについて」を参照してください。

Azure のロード バランサーはオンプレミス環境のロード バランサーと同じように動作することに注意してください。詳細については、「仮想マシンの負荷分散 (Linux) - Azure」を参照してください。

また、Azure 仮想ネットワークを利用し、仮想マシンのプライベート ネットワークを設定することをお勧めします。これにより、プライベート IP アドレスを利用し、仮想マシン間で通信できます。詳細については、「Azure 仮想ネットワーク」を参照してください。

ビジネス層のスケール アウトによる 2 層と 3 層のアプリケーション パターン

このアプリケーション パターンでは、異なる仮想マシンに各アプリケーション層を配置し、Azure 仮想マシンに 2 層または 3 層のデータベース アプリケーションを展開します。また、場合によっては、アプリケーションが複雑なため、アプリケーション サーバー コンポーネントを複数の仮想マシンに分散します。

このアプリケーション パターンは次の場合に役立ちます。

  • オンプレミスの仮想化プラットフォームから Azure 仮想マシンに企業アプリケーションを移動します。

  • アプリケーションが複雑なため、アプリケーション サーバー コンポーネントを複数の仮想マシンに分散します。

  • Azure 仮想マシンにビジネス ロジックの重いオンプレミスの基幹業務 (LOB) アプリケーションを移動します。LOB アプリケーションは、経理、人的資源 (HR)、給与支払、サプライ チェーン管理、リソース計画の各種アプリケーションなど、企業を運営するために不可欠な一連のコンピューター アプリケーションです。

  • 短期間で開発とテスト環境をすばやくプロビジョニングします。

  • 変化する作業負荷レベルでストレステストを実行しますが、同時に、多くの物理マシンをずっと所有し、保守管理することは望みません。

  • 必要に応じてスケールアップまたはスケールダウンできるインフラストラクチャ環境を所有します。

次の図は、オンプレミス シナリオとそのクラウド対応ソリューションを示したものです。このシナリオでは、Azure の複数の仮想マシンにアプリケーション層を配置します。ビジネス ロジック層とデータ アクセスのコンポーネントを含む、ビジネス層をスケール アウトします。図からわかるように、Azure ロード バランサーは複数の仮想マシンにトラフィックを分散し、接続する Web サーバーを決定します。ロード バランサーの後にアプリケーション サーバーのインスタンスを複数置くことで、ビジネス層の可用性が高くなります。詳細については、「1 つの層に複数の仮想マシンを持つ 2 層、3 層、n 層のアプリケーション パターンのベスト プラクティス」を参照してください。

ビジネス層のスケール アウトによるアプリケーション パターン

プレゼンテーション層とビジネス層のスケール アウトと SQL Server の高可用性による 2 層と 3 層のアプリケーション パターン

このアプリケーション パターンでは、プレゼンテーション層 (Web サーバー) コンポーネントとビジネス層 (アプリケーション サーバー) コンポーネントを複数の仮想マシンに分散し、Azure 仮想マシンに 2 層または 3 層のデータベース アプリケーションを展開します。また、Azure 仮想マシンのデータベースに高可用性と障害復旧のソリューションを導入します。

このアプリケーション パターンは次の場合に役立ちます。

  • SQL Server の高可用性と障害復旧の機能を実装し、オンプレミスの仮想化プラットフォームから Azure に企業アプリケーションを移動します。

  • 入ってくるクライアント要求の量が増えるため、また、アプリケーションが複雑なため、プレゼンテーション層とビジネス層をスケール アウトします。

  • 短期間で開発とテスト環境をすばやくプロビジョニングします。

  • 変化する作業負荷レベルでストレステストを実行しますが、同時に、多くの物理マシンをずっと所有し、保守管理することは望みません。

  • 必要に応じてスケールアップまたはスケールダウンできるインフラストラクチャ環境を所有します。

次の図は、オンプレミス シナリオとそのクラウド対応ソリューションを示したものです。このシナリオでは、Azure の複数の仮想マシンでプレゼンテーション層とビジネス層のコンポーネントをスケール アウトします。また、Azure の SQL Server データベースに高可用性と障害復旧 (HADR) のテクニックを導入します。

異なる VM であるアプリケーションの複数のコピーを実行することで、VM 間で要求の負荷を分散します。複数の仮想マシンがあるとき、ある時点ですべての VM がアクセス可能であり、実行されていることを確認する必要があります。負荷分散を設定する場合、Azure ロード バランサーは VM の状態を追跡し、入ってくる呼び出しを正常に動作している VM ノードに方向付けます。仮想マシンの負荷分散を設定する方法については、「仮想マシンの負荷分散」を参照してください。ロード バランサーの後に Web サーバーとアプリケーション サーバーのインスタンスを複数置くことで、プレゼンテーション層とビジネス層の可用性が高くなります。詳細については、「SQL Server の高可用性と災害復旧のソリューションを必要とするアプリケーション パターンのベスト プラクティス」を参照してください。

スケール アウトと高可用性

SQL Server の高可用性と災害復旧のソリューションを必要とするアプリケーション パターンのベスト プラクティス

Azure 仮想マシンに SQL Server の高可用性と障害復旧のソリューションを設定するとき、Azure 仮想ネットワークを使用して仮想マシンの仮想ネットワークを設定することが必須となります。仮想ネットワーク内の仮想マシンには、サービスのダウンタイム後でも、安定したプライベート IP アドレスが与えられます。そのため、DNS 名の解決に必要な更新時間を回避できます。また、仮想ネットワークを利用すると、オンプレミス ネットワークを Azure に拡張し、信頼されるセキュリティ境界を作成できます。たとえば、アプリケーションに企業ドメイン制約がある場合 (Windows 認証や Active Directory など)、Azure 仮想ネットワークの設定が必須となります。

Azure で実稼働コードを実行しているほとんどのお客様は、Azure でプライマリとセカンダリの両方のレプリカを維持しています。

高可用性と災害復旧のテクニックに関する包括的情報とチュートリアルについては、「Azure の仮想マシン内の SQL Server の高可用性と災害復旧」を参照してください。

Azure 仮想マシンと Azure クラウド サービス (Web ロールとワーカー ロール) を使用した 2 層と 3 層のアプリケーション パターン

このアプリケーション パターンでは、Azure クラウド サービス (Web ロールとワーカー ロール - サービスとしてのプラットフォーム (PaaS)) と Azure 仮想マシン (サービスとしてのインフラストラクチャ (IaaS)) の両方を利用し、2 層と 3 層のアプリケーションを配置します。プレゼンテーション層とビジネス層に Azure クラウド サービス を利用し、データ層に Azure の仮想マシンにおける SQL Server を利用することが、Azure で実行されているほとんどのアプリケーションで有効です。これは、クラウド サービスでコンピューティング インスタンスを実行すると、管理、配置、監視、スケールアウトが簡単になるためです。

クラウド サービスを利用すると、Azure がユーザーの代わりにインフラストラクチャを保守管理し、定期メンテナンスを実行し、オペレーティング システムにパッチを適用し、サービスとハードウェアの障害からの復旧を試みます。アプリケーションがスケールアウトを必要とするとき、クラウド サービス プロジェクトには自動と手動のスケールアウト オプションを利用できます。アプリケーションにより使用されるインスタンスまたは仮想マシンの数を増減します。また、オンプレミスの Visual Studio を利用し、アプリケーションを Azure のクラウド サービス プロジェクトに配置できます。

まとめると、プレゼンテーション層/ビジネス層に広範囲の管理タスクを所有せず、アプリケーションが複雑な構成のソフトウェアまたはオペレーティング システムを必要としない場合、Azure クラウド サービスを使用します。Azure SQL データベースでは必要な機能の一部がサポートされない場合、データ層に Azure 仮想マシンの SQL Server を使用します。Azure クラウド サービスでアプリケーションを実行し、Azure 仮想マシンにデータを保存すると、両方のサービスの利点が結合されます。詳しい比較については、「Azure の開発戦略:従来の Web 開発と Azure クラウド サービスならびに Azure Web サイトの比較」を参照してください。

このアプリケーション パターンでは、プレゼンテーション層に Azure 実行環境で実行されているクラウド サービス コンポーネントである Web ロールが含まれます。これは IIS と ASP.NET でサポートされ、Web アプリケーション プログラミングのためにカスタマイズされています。ビジネスまたはバックエンド層には Azure 実行環境で実行されているクラウド サービス コンポーネントであるワーカー ロールが含まれます。これは一般的な開発に役立ち、Web ロールのためにバックグラウンド処理を実行できます。データベース層は Azure の SQL Server 仮想マシンに存在します。プレゼンテーション層とデータベース層の間の通信は直接行われるか、ビジネス層のワーカー ロール コンポーネントで行われます。

このアプリケーション パターンは次の場合に役立ちます。

  • SQL Server の高可用性と障害復旧の機能を実装し、オンプレミスの仮想化プラットフォームから Azure に企業アプリケーションを移動します。

  • 必要に応じてスケールアップまたはスケールダウンできるインフラストラクチャ環境を所有します。

  • Azure SQL データベースでは、アプリケーションまたはデータベースが必要とする機能の一部がサポートされていません。

  • 変化する作業負荷レベルでストレステストを実行しますが、同時に、多くの物理マシンをずっと所有し、保守管理することは望みません。

次の図は、オンプレミス シナリオとそのクラウド対応ソリューションを示したものです。このシナリオでは、Web ロールにプレゼンテーション層を置き、ワーカー ロールにビジネス層を置きますが、Azure の仮想マシンにデータ層を置きます。異なる Web ロールでアプリケーションの複数のコピーを実行することで、Web ロール間で要求の負荷を分散します。Azure クラウド サービスと Azure 仮想マシンを組み合わせるとき、Azure 仮想ネットワークも設定することをお勧めします。Azure 仮想ネットワークを利用すると、クラウドの同じクラウド サービス内でプライベート IP アドレスが安定し、一貫性が与えられます。仮想マシンとクラウド サービスに仮想ネットワークを定義すると、プライベート IP アドレスでこれらの間で通信を開始できます。また、仮想マシンと Azure の Web ロール/ワーカー ロールを同じ Azure 仮想ネットワークに置くことにより、仮想ネットワークの待機時間が短くなり、接続がより安全になります。詳細については、「クラウド サービスとは」、「Azure 実行モデル」、「Azure 仮想ネットワーク」を参照してください。

図からわかるように、Azure ロード バランサーは複数の仮想マシンにトラフィックを分散し、接続する Web サーバーまたはアプリケーション サーバーを決定します。ロード バランサーの後に Web サーバーとアプリケーション サーバーのインスタンスを複数置くことで、プレゼンテーション層とビジネス層の可用性が高くなります。詳細については、「SQL Server の高可用性と災害復旧のソリューションを必要とするアプリケーション パターンのベスト プラクティス」を参照してください。

クラウド サービスによるアプリケーション パターン

このアプリケーション パターンを実行する別の手法は、次の図に示すように、プレゼンテーション層とビジネス層の両方のコンポーネントを含む連結 Web ロールを使用することです。このアプリケーション パターンはステートフル設計を必要とするアプリケーションに役立ちます。Azure は Web ロールとワーカー ロールにステートレス コンピューティング ノードを提供するため、次の技術の 1 つを利用してセッション ステートを格納するロジックを実装することをお勧めします。Azure キャッシュAzure テーブル ストレージ または Azure SQL データベース

クラウド サービスによるアプリケーション パターン

Azure 仮想マシン、Azure SQL データベース、Azure Web サイトを使用した混合アプリケーション パターン

このアプリケーション パターンの主な目標は、Azure サービスとしてのインフラストラクチャ (IaaS) と Azure サービスとしてのプラットフォーム (PaaS) をソリューションで結合する方法を示すことです。このパターンはリレーショナル データ ストレージのために Azure SQL データベースに重点を置きます。これには Azure サービスとしてのインフラストラクチャに含まれる Azure 仮想マシンの SQL Server が含まれていません。

このアプリケーション パターンでは、Azure にデータベース アプリケーションを配置します。同じ仮想マシンにプレゼンテーション層とビジネス層を置き、Azure SQL データベース (SQL データベース) サーバーのデータベースにアクセスします。従来の IIS ベースの Web ソリューションを利用し、プレゼンテーション層を実装できます。あるいは、Azure Web サイトを使用し、プレゼンテーション層とビジネス層の結合を実装できます。

このアプリケーション パターンは次の場合に役立ちます。

  • Azure に既存の SQL データベース サーバーを設定しており、アプリケーションをすぐにテストします。

  • Azure 環境の機能をテストします。

  • 短期間で開発とテスト環境をすばやくプロビジョニングします。

  • ビジネス ロジックとデータ アクセスのコンポーネントは Web アプリケーション内で自己完結型にできます。

次の図は、オンプレミス シナリオとそのクラウド対応ソリューションを示したものです。このシナリオでは、Azure の単一仮想マシンにアプリケーション層を置き、Azure SQL データベースのデータにアクセスします。

混合アプリケーション パターン

Azure Web サイトを使用し、Web とアプリケーション層の結合を実装する場合、Web アプリケーションのコンテキストで中間層またはアプリケーション層を動的リンク ライブラリ (DLL) として保有することをお勧めします。

また、本記事の終わりにある「Azure の開発戦略:従来の Web 開発と Azure クラウド サービスならびに Azure Web サイトの比較」セクションの推奨事項を読み、プログラミング技術についてさらに学習してください。

N 層ハイブリッド アプリケーション パターン

n 層のハイブリッド アプリケーション パターンでは、オンプレミスと Azure の間で分散された複数の層でアプリケーションを実装します。そのため、他の層を変更しなくても特定の層を変更または追加できる、柔軟かつ再利用可能なハイブリッド システムを作成します。企業ネットワークをクラウドに拡張するために、Azure 仮想ネットワークサービスを使用します。

このハイブリッド アプリケーション パターンは次の場合に役立ちます。

  • 一部をクラウドで、一部をオンプレミスで実行するアプリケーションを構築します。

  • 既存のオンプレミス アプリケーションの全部または一部の要素をクラウドに移行します。

  • オンプレミスの仮想化プラットフォームから Azure に企業アプリケーションを移動します。

  • 必要に応じてスケールアップまたはスケールダウンできるインフラストラクチャ環境を所有します。

  • 短期間で開発とテスト環境をすばやくプロビジョニングします。

  • 対費用効果が高い方法で企業データベース アプリケーションをバックアップします。

次の図は、オンプレミスと Azure にわたる n 層のハイブリッド アプリケーション パターンを示したものです。図に示されるように、オンプレミス インフラストラクチャには Active Directory ドメイン サービス ドメイン コントローラーが含まれ、ユーザーの認証と承認をサポートします。データ層の一部がオンプレミス データ センターに、一部が Azure に存在するシナリオをこの図が示していることに注意してください。アプリケーションのニーズに基づき、その他のハイブリッド シナリオをいくつか実装できます。たとえば、プレゼンテーション層とビジネス層はオンプレミス環境に置きますが、データ層は Azure に置きます。

Azure ライブラリでこのトピックの表示に問題がある場合は、MSDN ライブラリで表示してみてください。

N 層アプリケーション パターン

Azure では、組織のスタンドアロン クラウド ディレクトリとして Active Directory を使用できます。あるいは、既存のオンプレミス Active Directory を Azure Active Directory と統合できます。図からわかるように、ビジネス層のコンポーネントは複数のデータ ソースにアクセスできます。たとえば、プライベート内部 IP アドレスを介して Azure の SQL Server に、仮想ネットワークを介してオンプレミス SQL Server に、.NET フレームワーク データ プロバイダー技術を利用して SQL データベースにアクセスできます。この図では、Azure SQL データベース (SQL データベース) は任意のデータ ストレージ サービスです。

n 層のハイブリッド アプリケーション パターンでは、指定された順序で次のワークフローを実装できます。

  1. Microsoft Assessment and Planning (MAP) Toolkit を使用し、クラウドに上げる必要がある企業データベース アプリケーションを特定します。MAP Toolkit は、仮想化を検討しているコンピューターからインベントリ データとパフォーマンス データを収集し、処理能力に関するアドバイスやアセスメント計画を行うツールです。

  2. ストレージ アカウントや仮想マシンなど、Azure プラットフォームで必要なリソースと設定を計画します。詳しい移行計画については、「Azure の仮想マシンに SQL Server を移行するための準備」を参照してください。

  3. 企業ネットワーク オンプレミスと Azure 仮想ネットワークの間のネットワーク接続を設定します。企業ネットワーク オンプレミスと Azure の仮想マシンの間に接続を設定するには、次の 2 つの方法の 1 つを使用します。

    1. Azure の仮想マシンのパブリック エンドポイント経由でオンプレミスと Azure の間の接続を確立します。この方法の場合、設定が簡単で、仮想マシンで SQL Server 認証を利用できます。また、パブリック ポートでネットワーク アクセス制御リスト (ACL) を設定し、特定の IP アドレスへのアクセスを許可します。詳細については、「ネットワーク アクセス制御リストについて」を参照してください。

    2. Azure 仮想プライベート ネットワーク (VPN) トンネル経由でオンプレミスと Azure の接続を確立します。この方法の場合、ドメイン ポリシーを Azure の仮想マシンに拡張できます。また、ファイアウォール ルールを設定し、仮想マシンで Windows 認証を使用できます。現在のところ、Azure では安全なサイト間 VPN 接続とポイント対サイト VPN 接続がサポートされています。

      • 安全なサイト間接続を利用すると、オンプレミスと Azure の仮想ネットワークの間でネットワーク接続を確立できます。オンプレミス データ センター環境を Azure に接続することをお勧めします。

      • 安全なポイント対サイト接続を利用すると、Azure の仮想ネットワークとあらゆる場所で実行されている個別コンピューターの間でネットワーク接続を確立できます。多くの場合、開発およびテスト目的にお勧めします

      Azure の SQL Server に接続する方法の詳細については、「Azure 仮想マシンにおける SQL Server の接続に関する考慮事項」を参照してください。

  4. Azure の仮想マシン ディスクにオンプレミス データをバックアップするようにスケジュールされたジョブとアラームを設定します。詳細については、「Azure BLOB ストレージ サービスを使用した SQL Server のバックアップと復元」と「Azure の仮想マシンにおける SQL Server のバックアップと復元」を参照してください。

  5. アプリケーションのニーズに基づき、次の 3 つの一般的なシナリオの 1 つを実装できます。

    1. Web サーバー、アプリケーション サーバー、機密ではないデータを Azure のデータベース サーバーで保持し、機密データをオンプレミスで保持できます。

    2. Web サーバーとアプリケーション サーバーをオンプレミスで保持し、データベース サーバーを Azure の仮想マシンで保持できます。

    3. データベース サーバー、Web サーバー、アプリケーション サーバーをオンプレミスで保持し、データベースのレプリカを Azure の仮想マシンで保持できます。この設定では、オンプレミスの Web サーバーまたはレポート アプリケーションが Azure のデータベース レプリカにアクセスできます。そのため、オンプレミス データベースの作業負荷を下げることができます。重い読み取り作業負荷と開発目的でこのシナリオを実装することをお勧めします。Azure のデータベース レプリカを作成する方法については、「Azure の仮想マシン内の SQL Server の高可用性と災害復旧」の AlwaysOn 可用性グループを参照してください。

Azure の開発戦略:従来の Web 開発と Azure クラウド サービスならびに Azure Web サイトの比較

Azure に多層 SQL Server ベース アプリケーションを実装し、配置するには、次の 2 つのプログラミング方法のいずれかを利用します。

  • 従来の Web サーバー (IIS - インターネット インフォメーション サービス) を Azure に設定し、Azure 仮想マシンの SQL Server のデータベースにアクセスします。

  • クラウド サービスを実装し、Azure に展開します。次に、このクラウド サービスが Azure 仮想マシンの SQL Server のデータベースにアクセスできることを確認します。クラウド サービスには複数の Web ロールとワーカー ロールを含めることができます。

次の表は、Azure 仮想マシンの SQL Server の観点から、従来の Web 開発と Azure クラウド サービスならびに Azure Web サイトを比較したものです。この表には Azure Web サイトが含まれています。そのパブリック仮想 IP アドレスまたは DNS 名を介して、Azure Web サイトのデータ ソースとして Azure VM の SQL Server を使用できるためです。

Azure ライブラリでこのトピックの表示に問題がある場合は、MSDN ライブラリで表示してみてください。

 

Azure 仮想マシンの従来の Web 開発

Azure のクラウド サービス

Azure Web サイトによる Web ホスティング

オンプレミスからのアプリケーション移行

  • 既存のアプリケーションの現状有姿のまま。

  • アプリケーションは Web ロールとワーカー ロールを必要とします。

  • 既存のアプリケーションの現状有姿のままですが、短期間での拡張を必要とする自己完結型の Web アプリケーションと Web サービスに適しています。

開発と配置

  • Visual Studio、WebMatrix、Visual Web Developer、WebDeploy、FTP、TFS、IIS Manager、PowerShell。

  • Visual Studio、Azure SDK、TFS、PowerShell。各クラウド サービスには、サービス パッケージと設定を配置できる 2 つの環境、つまり、ステージング環境と運用環境があります。クラウド サービスをステージング環境に配置し、本稼働に昇進させる前にテストできます。

  • Visual Studio、WebMatrix、Visual Web Developer、FTP、GIT、BitBucket、CodePlex、DropBox、GitHub、Mercurial、TFS、Web Deploy、PowerShell。

管理と設定

  • ユーザーはアプリケーション、データ、ファイアウォール ルール、仮想ネットワーク、オペレーティング システムの管理タスクを担当します。

  • ユーザーはアプリケーション、データ、ファイアウォール ルール、仮想ネットワークの管理タスクを担当します。

  • ユーザーはアプリケーションとデータのみの管理タスクを担当します。

高可用性と障害復旧 (HADR)

  • 仮想マシンを同じ可用性セットと同じクラウド サービスに配置することをお勧めします。同じ可用性セットに VM を保持することで、Azure は別個のフォールト ドメインとアップグレード ドメインに高可用性ノードを配置できます。同様に、同じクラウド サービスに VM を保持すると負荷を分散できます。VM は Azure データ センター内のローカル ネットワークで互いに直接通信できます。

  • ユーザーは、あらゆるダウンタイムを避けるために、Azure 仮想マシンの SQL Server に高可用性と障害復旧のソリューションを導入することを担当します。サポートされる HADR 技術については、「Azure の仮想マシン内の SQL Server の高可用性と災害復旧」を参照してください。

  • ユーザーは自分のデータとアプリケーションのバックアップを担当します。

  • Azure は、ハードウェアの問題に起因してデータ センターのホスト マシンに障害が発生した場合、仮想マシンを移動できます。また、セキュリティまたはソフトウェアの更新でホスト マシンが更新されるとき、VM のダウンタイムが計画されることがあります。そのため、アプリケーション層ごとに少なくとも 2 つの VM を保守管理し、可用性を継続させることをお勧めします。Azure は単一仮想マシンのために SLA を提供しません。詳細については、「Azure Business Continuity Technical Guidance」を参照してください。

  • Azure は、基礎にあるハードウェアまたはオペレーティング システム ソフトウェアから結果的に発生する障害を管理します。Web ロールまたはワーカー ロールの複数のインスタンスを実装し、アプリケーションの可用性を高くすることをお勧めします。詳細については、「クラウド サービス、仮想マシン、仮想ネットワーク サービスのサービス レベル アグリーメント」と「Azure アプリケーションの障害復旧と高可用性」を参照してください。

  • ユーザーは自分のデータとアプリケーションのバックアップを担当します。

  • Azure 仮想マシンの SQL Server に置かれているデータベースに関して、ユーザーは、あらゆるダウンタイムを避けるために、高可用性と障害復旧のソリューションを導入することを担当します。サポートされる HADR 技術については、「Azure の仮想マシン内の SQL Server の高可用性と災害復旧」を参照してください。

  • SQL Server データベース ミラーリング: Azure クラウド サービス (Web/ワーカー ロール) と共に使用するときにサポートされます。SQL Server VM とクラウド サービス プロジェクトを同じ Azure 仮想ネットワークに入れることができます。SQL Server VM が同じ仮想ネットワークにない場合、SQL Server エイリアスを作成し、SQL Server のインスタンスに通信を送る必要があります。また、エイリアス名は SQL Server 名に一致する必要があります。

  • 高可用性は Azure ワーカー ロール、Azure blob ストレージ、Azure SQL データベースから継承されます。たとえば、Azure ストレージは、すべての BLOB、テーブル、およびキュー データの 3 つのレプリカを保持します。どの時点においても、Azure SQL データベースはデータの 3 つのレプリカを実行しています。1 つのプライマリ レプリカと 2 つのセカンダリ レプリカです。詳細については、「ストレージ」と「SQL データベース」を参照してください。

  • Azure Web サイトのデータ ソースとして Azure VM の SQL Server を使用するときは、Azure Web サイトで Azure 仮想ネットワークがサポートされないことに注意してください。言い換えれば、Azure Web サイトから Azure の SQL Server VM へのすべての接続が仮想マシンのパブリック エンドポイントを通過する必要があります。そのため、高可用性と障害復旧のシナリオにいくつかの制約が発生することがあります。たとえば、データベース ミラーリングで SQL Server VM に接続する Azure Web サイトのクライアント アプリケーションは、新しいプライマリ サーバーに接続できないことがあります。データベース ミラーリングでは、Azure の SQL Server ホスト VM 間で Azure 仮想ネットワークを設定する必要があるためです。そのため、現在のところ、SQL Server データベース ミラーリングは Azure Web サイトで利用できません。

  • SQL Server AlwaysOn 可用性グループ: Azure の SQL Server VM で Azure Web サイトを使用するとき、Server AlwaysOn 可用性グループを設定できます。ただし、負荷が分散されたパブリック エンドポイント経由でプライマリ レプリカに通信を送るように AlwaysOn 可用性グループ リスナーを設定する必要があります。

クロスプレミス接続

  • Azure 仮想ネットワークを使用し、オンプレミスに接続できます。

  • Azure 仮想ネットワークを使用し、オンプレミスに接続できます。

  • Azure 仮想ネットワークはサポートされません。

スケーラビリティ

  • 仮想マシンのサイズを増やすか、ディスクを追加することでスケールアップできます。仮想マシンのサイズの詳細については、「Azure の仮想マシンおよびクラウド サービスのサイズ」を参照してください。

  • データベース サーバーの場合: データベースのパーティション分割技術と SQL Server AlwaysOn 可用性グループを利用し、スケールアウトできます。

    作業負荷の重い読み取りの場合、複数のセカンダリ ノードに AlwaysOn 可用性グループを使用し、また、SQL Server レプリケーションを使用できます。

    作業負荷の重い書き込みの場合、複数の物理サーバー間でデータの行方向のパーティション分割を行って、アプリケーションをスケール アウトできます。

    また、データ依存型ルーティングを使用した SQL Server を使用し、スケールアウトを実装できます。データ依存型ルーティング (DDR) を利用するとき、クライアント アプリケーションに、一般的にはビジネス層に、パーティション分割メカニズムを実装し、複数の SQL Server ノードにデータベース要求を送る必要があります。ビジネス層には、データのパーティション分割方法とデータが含まれるノードへのマッピングが含まれています。

    仮想マシンを実行しているアプリケーションの規模を設定できます。詳細については、「クラウド サービスおよびリンクされたリソースの規模の設定方法」を参照してください。

  • 複数の Web ロールとワーカー ロールを使用することでスケールアップできます。Web ロールとワーカー ロールに対応した仮想マシンのサイズの詳細については、「クラウド サービスのサイズを構成する」を参照してください。

  • Cloud Services を使用すると、複数のロールを定義して処理を分散し、アプリケーションの規模を柔軟に設定できます。各クラウド サービスには 1 つまたは複数の Web ロールとワーカー ロールが含まれ、それぞれに独自のアプリケーション ファイルと設定があります。ロールに配置するロール インスタンス (仮想マシン) の数を増やしてクラウド サービスをスケールアップしたり、ロール インスタンスの数を減らしてクラウド サービスをスケールダウンしたりできます。詳細については、「Azure 実行モデル」を参照してください。

  • クラウド サービス、仮想マシン、仮想ネットワークのサービス レベル アグリーメントおよびロード バランサーで組み込まれる Azure 高可用性により、スケールアウトできます。

  • 多層アプリケーションに関しては、Azure 仮想ネットワークを介して Web/ワーカー ロール アプリケーションをデータベース サーバー VM に接続することをお勧めします。また、Azure は同じクラウド サービスの VM の負荷を分散し、VM の間でユーザー要求を分散します。この方法で接続される仮想マシンは、Azure データ センター内のローカル ネットワークで互いと直接通信できます。

  • Management Portal で AutoScale とスケジュール時間を設定できます。詳細については、「クラウド サービスおよびリンクされたリソースの規模の設定方法」を参照してください。

  • スケールアップとスケールダウン: Web サイトに予約されるインスタンス (VM) のサイズを増減できます。

  • スケールアウト: Web サイトに予約されるインスタンス (VM) を追加できます。

  • Management Portal で AutoScale とスケジュール時間を設定できます。詳細については、「Web サイトの規模設定方法」を参照してください。

これらのプログラミング方法の選択については、「Azure の Web サイト、クラウド サービス、および VM: いつ、どれを使用するか」を参照してください。

その他のリソース

参照

この情報は役に立ちましたか。
(残り 1500 文字)
フィードバックをいただき、ありがとうございました

コミュニティの追加

表示:
© 2014 Microsoft