Freigeben über

Windows Azure 仮想マシンで SQL Server ワークロードを実行する際に知っておくべき 10 のこと

  • Artikel

このポストは、6 月 4 日に投稿された The Top 10 Things to Know When Running SQL Server Workloads on Windows Azure Virtual Machines の翻訳です。

2012 年 6 月、マイクロソフトは Windows Azure 仮想マシンおよび仮想ネットワーク (合わせて Windows Azure インフラストラクチャ サービスと総称) のプレビュー版のリリースを発表しました。これを受けて、世界各地の企業が既存の Microsoft SQL Server ワークロードをテストし、このプレビュー版の限界を見極めようと取り組みを始めました。Windows Azure インフラストラクチャ サービスは企業の皆様に多くのメリットを提供します。1 つは、さまざまな SQL Server ワークロードが稼働する仮想マシンを迅速かつ低コストで展開することが可能なことで、ハードウェアを設置したり管理したりする必要がありません。これは幅広い企業の皆様にとって魅力的な利点です。また、仮想ネットワーク内で複数の仮想マシンの複雑な展開が可能で、Active Directory や SharePoint がサポートされます。仮想プライベート ネットワーク (VPN) ゲートウェイを使用して、仮想ネットワークをオンプレミス ネットワークやリモート マシンと接続することも可能で、IT 部門や開発者にとって非常に魅力的なオフプレミス ホスティング環境が提供されます。さらに、仕様に変更を加えることなく現状のままで Windows Azure の最新の「Platform-as-a-Service」機能をハイブリッドで利用できるため、Windows Azure インフラストラクチャ サービスの利用は、既存のワークロードをクラウドに移行する足掛かりとなります。企業の皆様は既に、シンプルな SQL Server の開発ワークロードやテスト ワークロードから、複雑な分散型ミッション クリティカルなワークロードに至るまで、さまざまな場面でこのサービスを活用しています。ここでは、こうした企業の皆様の経験から得られたヒントをご紹介していきます。

  1. SLA の内容を確認する:
    SQL Server ワークロードをサーバーから Windows Azure に移行する前に、該当するサービス レベル アグリーメント (SLA) の内容を把握しておくことが重要です。注意が必要なのは、「インターネットに接続するすべての仮想マシンに同じ可用性セットにデプロイした 2 つ以上のインスタンスがある場合、外部接続を 99.95% 以上保証する」という点です。SQL Server の場合は、SLA の適用条件として SQL Server が稼働する 2 つ以上の仮想マシンをデプロイし、同じ可用性セットに追加することが必要になります。詳細については「仮想マシンの可用性を管理する (英語)」を参照してください。また、可用性セットに含まれているすべての仮想マシンでデータベースが同期されていることを確認したい場合は、SQL Server 高可用性ソリューションを実装しなければなりません。このように、クラウドで高可用性を確保するには、オンプレミスでワークロードを実行する場合と同様に、一定の作業が必要になります。可用性セットを適切に構成することで、アップグレードやハードウェアの交換などのメンテナンス時も SQL Server ワークロードを確実に稼働させることができます。
  2. サポート ポリシーについて知る:
    SQL Server を Windows Azure 仮想マシンで実行することの利点は、他の環境で実行しているのと同じように実行することができ、問題なく動作する点です。アプリケーションの変更が不要で、SQL Server の各種機能がサポートされているかを心配する必要もありません。Windows Azure インフラストラクチャ サービスでは重要な若干の例外を除き、SQL Server 機能の大半がフルサポートされています。では、サポートされている SQL Server のバージョンから見ていきましょう。Windows Azure インフラストラクチャ サービスでは、SQL Server 2008 以降のバージョンに対する技術サポートを提供しています。SQL Server 2005 以前のバージョンでワークロードを実行している場合は、新しいバージョンにアップグレードする必要があります。その際、SQL Server 2012  にアップグレードすることをお勧めします。SQL Server 2012 は「クラウド対応」ソリューションとして設計されており、管理ツール、開発ツール、および基盤となるデータベース エンジンが Windows Azure を標準サポートしています。 では、高可用性について説明します。Windows Azure インフラストラクチャ サービスに展開する SQL Server に高可用性ソリューションを実装する必要はないとお考えの場合は、その考えを改めていただく必要があります。前述のとおり、SLA が適用されるには、仮想マシンの可用性セットに何らかのデータベースの冗長化を実装する必要があります。ただし、SQL Server の高可用性機能に影響する制約がいくつかあります。1 つは SQL Server フェールオーバー クラスタリングがサポート対象外であることですが、心配はご無用です。AlwaysOn 可用性グループなど、SQL Server を高可用性構成で展開する選択肢は他にも多数あり、またデータベース ミラーリングやログ配付といったレガシー機能も使用できます。高可用性については SQL Server 2012 の AlwaysOn 可用性グループ機能の使用を推奨しますが、その場合に知っておくべき点がいくつかあります。可用性グループ リスナーは現在サポート対象外ですが、近い将来にサポートを追加する予定です。リスナーのサポートを待たずに AlwaysOn 可用性グループを使用したい場合は、代わりに "FailoverPartner" 接続文字列属性を使用できます。この場合、AlwaysOn 可用性グループのレプリカが 2 つ (プライマリとセカンダリが 1 つずつ) に制限され、読み取り可能なセカンダリはサポートされないので注意してください。詳細については「データベース ミラーリング セッションへのクライアントの接続」を参照してください。 次に、SQL Server データベースのストレージを構成する際に検討すべき重要な点を説明します。一般的には、単一のデータ ディスクを仮想マシンにアタッチして、すべてのデータとログ ファイルを保存することをお勧めします。データとログ ファイルを複数のデータ ディスクに分散保管してストレージ容量の増大やパフォーマンス向上を図りたい場合は、ジオレプリケーション (英語) を無効にしてください。複数のディスクを使用する構成では複数のディスクへの書き込み順の一貫性を保証できないため、ジオレプリケーションは使用できません。 最後は、SQL Server がサポートする各種「分散」機能 (レプリケーション、サービス ブローカー、分散トランザクション、分散クエリ、リンク サーバー) について見ていきます。これらは同一の仮想ネットワークに展開された SQL Server 仮想マシン全体で正しく機能するはずですが、その境界 (パブリック インターネットや仮想ネットワーク VPN ゲートウェイ) を越える場合は入念なテストが必要になります。これらの機能は、オンプレミス データ センター、LAN、WAN での使用を意図したものであり、パブリック インターネットでは使用できません。 詳細については「ハードウェア仮想化環境で実行している Microsoft SQL Server 製品のサポート ポリシー (機械翻訳)」を参照してください。
  3. ライセンスについて知る:
    Windows Azure インフラストラクチャ サービスに展開する SQL Server のライセンスを取得する 1 つ目の (そして最も簡単な) 方法は、イメージ ギャラリーにある既成の SQL Server プラットフォーム イメージを使用して、新しい仮想マシンを作成することです。この場合、選択した SQL Server のエディション (Enterprise/Standard/Web) に応じて時間単位で課金されます。プロダクト キーの入力やライセンス認証などの作業は不要で、新規にプロビジョニングされた SQL Server 仮想マシンをすぐにご利用になれます。課金は分刻みで行われるのでご注意ください。また、下限料金は設定されません。詳細については「Windows Azure で SQL Server 仮想マシンをプロビジョニングする (英語)」を参照してください。マイクロソフトが仮想マシンの内部までチェックすることはありません。プラットフォーム イメージを使用してプロビジョニングされた仮想マシンから SQL Server を削除しても、仮想マシンを削除しない限り SQL Server の使用料が発生します。 ライセンスを取得するもう 1 つの方法は「独自の仮想マシンを使用する」ことです。オンプレミスで Hyper-V 仮想マシンを作成し、SQL Server をインストールした後 Windows Azure にアップロードします。その方法については、「Windows Server オペレーティング システムを格納した仮想ハード ディスクを作成およびアップロードする (英語)」を参照してください。仮想マシンを自分で用意すれば、Windows Server オペレーティング システムのライセンス費用は時間単位のコンピューティング料金に含まれることになります。ただし、SQL Server などのサーバー製品の場合は、仮想マシンがマイクロソフトのライセンス ポリシーに適合しているかどうかをお客様ご自身に確認していただく必要があります。SQL Server などのサーバー製品は、既定で、仮想化構成や Windows Azure インフラストラクチャ サービスのようなホスティング環境で実行できないライセンスになっていますが、マイクロソフトは実稼働ワークロードや開発ワークロード、テスト ワークロードに対応したさまざまな SQL Server ライセンス オプションを提供しています。 実稼働の SQL Server ワークロードを実行するには、ソフトウェア メンテナンスの購入が必要になります。詳細については「Windows Azure でのソフトウェア アシュアランスによるライセンス モビリティ」を参照してください。ライセンスについては、オンプレミスと同じ SQL Server エディションとライセンス数が必要になります。たとえば、SQL Server の Standard エディションまたは Enterprise エディションのコア ベース ライセンスをオンプレミスで使用している場合は、ソフトウェア アシュアランス経由でコア ライセンスを Windows Azure に移行できます。仮想マシン 1 つにつき最低 4 つのコア ライセンスとなるため、適切なサイズの仮想マシンを選択してください。ライセンスをオンプレミスのサーバーに再割り当てする場合は 90 日間お待ちいただく必要ありますのでご注意ください。SQL Server の開発ワークロードおよびテスト ワークロードの実行については、MSDN Pro/Premium/Ultimate の各サブスクリプションの購入をご検討ください。MSDN サブスクリプションに含まれるソフトウェアの大半 (SQL Server を含む) は、追加費用なしで仮想マシンにインストールできます。詳細については「MSDN サブスクライバ―向けの Windows Azure の特典」を参照してください。 最近発表した SQL Server 2012 SP1 用の累積更新プログラムに含まれる機能強化によって、SysPrep ユーティリティを使用した SQL Server 仮想マシン イメージの作成が大幅に簡素化されました。独自に SQL Server 仮想マシンを作成する場合は、「SQL Server 2012 SP1 CU2 の SysPrep の拡張サポート (英語)」を参照して詳細をご確認ください。 また、SQL Server AlwaysOn 可用性グループの展開については、Windows Azure インフラストラクチャ サービス (およびその他のホスティング環境) に展開された SQL Server は、「無料のパッシブ フェールオーバー インスタンス」というライセンス特典の対象外となるのでご注意ください。この特典が適用されるのは、共有ホスティング環境を使用しないオンプレミスでの展開に限られます。つまり、すべてのレプリカで SQL Server Enterprise Edition のフル ライセンス版が必要になるということです。ライセンスに関するすべての情報を確認するには「SQL Server 2012 ライセンス ガイド (英語)」を参照してください。
  4. ハードウェアとストレージについて知る:
    ここでは、CPU、RAM、入出力 (I/O)、ネットワークにおける Windows Azure インフラストラクチャ サービスのパフォーマンス特性を見ていきます。マイクロソフトは Windows Azure インフラストラクチャ サービスを通じて手頃な料金で優れたコンピューティングおよびストレージを提供することをお約束してします (詳細については「仮想マシンの料金の詳細」を参照してください)。クラウドの中核的な価値とは何かといえば、高額投資によって専用環境のスケールアップを図るのではなく、共有のコンピューティング/ストレージ インフラストラクチャを使用して低コストでスケールアウトすることにあります。この点を理解していただくことが重要です。多くの大企業が既に自社のプライベート クラウド内ですべてまたは一部の SQL Server ワークロードを仮想化していますが、一部の筋金入りの SQL Server 支持者はそのパフォーマンスと信頼性に対して今も疑念を抱いています。SQL Server の仮想化は完全にサポートされており、今後もそれは変わりません。とはいえ、仮想マシンを使用する場合にも、高価な巨大サーバーとストレージ サブシステムにスケールアップした場合と同等のパフォーマンスを得られると考えることはできません。 Windows Azure 仮想マシンは共有クラスターの商用サーバー上にホスティングされており、Windows Azure ディスク (OS およびデータ ディスク) は冗長性を確保した共有ストレージ サービスである Windows Azure ストレージを使用して実装されています。CPU については仮想化という代償を、入出力については共有冗長化ストレージという代償を払うことになります。細かく調整したミッション クリティカルな SQL Server OLTP ワークロードを Windows Azure インフラストラクチャ サービスに移行する前に、パフォーマンス、スループット、待機時間について学習しておきましょう。入念な計画とテストを行うことで、一般的な SQL Server ワークロードの多くは Windows Azure 仮想マシンで問題なく動作させることができます。ただし、このような仮想環境には適さない、パフォーマンス重視のスケールアップ向きなワークロードも少なからず存在します。 CPU から見ていきましょう。クロック速度など、仮想コアの特性は、使用するホスト サーバーによって若干異なります。SQL Server は 4GB 程度の RAM が必要ですので、最低でも M サイズの仮想マシン インスタンス (A2) を使用してください。A2 以上の仮想マシンには専用の仮想コアが用意されているので、同一ホスト上の他の仮想マシンと仮想コアを共有せずに済みます。仮想コアの数は、選択した仮想マシンのサイズに応じて 2 つ (A2) ～ 8 つ (XL (A4) 仮想マシンまたはそれ以上) となります。 次に RAM です。ビッグ データを扱う読み取り処理の多い SQL Server ワークロードおよび Analysis Services ワークロードは、最適なパフォーマンスを得るためにメモリにデータをキャッシュするので大量の RAM が必要になります。SQL Server キャッシュのヒット率が低下傾向にある場合は、サイズの大きな仮想マシンに切り替えて RAM を増やす方がよいでしょう。3.5 GB RAM の M サイズ (A2) ～ 56 GB RAM (A7) まで選択できます。コストを抑えるには、小さめのサイズを選択します。まずは小さめの仮想マシンでワークロードをテストして、パフォーマンスが許容できるレベルかどうかを確認しましょう。仮想マシンのサイズは、必要に応じていつでも大きなものにアップグレードできます。 次に、ストレージのパフォーマンスについて見ていきます。前述したように、VHD (OS およびデータ ディスク) は Windows Azure ディスクを使用して実装されます。Windows Azure ディスクは特殊な Windows Azure ストレージ ページ BLOB で、共有ディスク サブシステムのホスト サーバー上にローカルにキャッシュされます。ローカルの冗長性が確保されており、任意で地理的な冗長性を追加できます。ローカルにキャッシュされた VHD を支えるページ BLOB は、共有ストレージ サービスにリモートで保管され、高速相互接続により REST API 経由でアクセスできます。詳細については「データ シリーズ: Windows Azure ドライブ、ディスク、イメージについて」を参照してください。ここまでの説明で、Windows Azure ディスクのパフォーマンス特性、構成および動作は、ローカルに接続されたストレージや SAN とは大きく異なるということをご理解いただけたのではないでしょうか。 次はストレージ容量についてです。まず、データベースはごく小規模の場合を除いて OS ドライブに保存しないでください。一時ドライブ (D:) をデータベース (tempdb を含む) 用に使用しないでください。このドライブにデータを保存すると、再起動によってデータが消えてしまう恐れがあります。また、一時ドライブの動作は予測ができません。単一のデータ ディスクを仮想マシンにアタッチして、そちらにユーザー データベースすべてを保存することをお勧めします。詳細については「データ ディスクを仮想マシンにアタッチする方法 (英語)」を参照してください。データ ディスクのサイズは最大 1 TB で、A4 以上の仮想マシンで最大 16 台のドライブを使用できます。データベースのサイズが 1 TB を上回る場合は、SQL Server ファイル グループを使用してデータベースを複数のデータ ディスクに分散することができます。また、Windows Server 2012 の記憶域スペース (英語) を使用して、複数のデータ ディスクを結合して大規模な単一のボリュームにすることもできます。記憶域スペースは、Windows Azure ストレージの追加書き込みのみという機能性にマッチしている点が、従来の OS ストライピング テクノロジよりも優れています。上記の 2 つ目の項目で説明したように、複数のデータ ディスクを使用する場合はジオレプリケーションを有効にしないでください。SQL Server ワークロードのディスク パフォーマンス測定においては、IOPS (Input/Output Operations per Second) という指標が重要になります。Windows Azure ディスクの IOPS は、入出力のサイズとアクセス パターンによって異なります。8 KB IO で読み取り/書き込みの割合が 60/40 のワークロードの場合、ディスク 1 台あたり最大 500 IOPS が目標ラインです。これを上回る数字が必要な場合は、データ ディスクを追加して、データベース ワークロードを分散してください。大規模なデータベースを作成または復元する際は、ファイルの瞬時初期化の機能を使用してパフォーマンスの向上を図ってください。 最後に、ネットワークの帯域幅と待機時間についてです。仮想マシンはサイズに応じて一定のネットワーク帯域幅が割り当てられます。帯域幅はデータの転送やバックアップのパフォーマンスに影響するので、大量のデータを転送する場合は仮想マシンのサイズを大きめにしてください。公開エンドポイントまたは VPN ゲートウェイ経由で仮想マシンに接続する際は、パブリック インターネット経由でインフラストラクチャにアクセスされる点に留意してください。仮想マシンは物理的に離れた場所にあるロード バランサーやゲートウェイなどの高度ネットワーク インフラストラクチャ内にあり、高度なセキュリティ対策が施されています。このため、ネットワーク待ち時間が発生します。待ち時間の少ないネットワークを必要とする各種処理には異なる対応が必要になります。たとえば、大規模なデータベースをクラウドに移行するには非常に長い時間がかかるため、クラウドのネットワーク待ち時間での使用を想定していないクライアント アプリケーションは正常に動作しない可能性があります。ネットワークについては次のセクションで詳説します。 仮想マシンのサイズおよびオプションの詳細については、「仮想マシンおよびクラウド サービスのサイズ (英語)」を参照してください。パフォーマンスのベスト プラクティスの詳細については、「Windows Azure 仮想マシンの SQL Server に関するパフォーマンス ガイダンス (英語)」を参照してください。
  5. 最初にネットワークを計画する
    Windows Azure インフラストラクチャ サービスには、仮想マシンの展開に使用できる幅広い種類のネットワーク接続オプションが用意されています。仮想マシンを作成する前にまずネットワーク構成を計画して、問題発生時に最初からやり直す必要がないようにしてください。リモート デスクトップを使用すれば、デスクトップから個別の仮想マシンに接続して管理することができます。詳細については「Windows Server を実行している仮想マシンへのログオン方法 (英語)」を参照してください。パブリック インターネットから仮想マシンへの接続を許可したい場合は、エンドポイントを使用してポートを開放する必要があります。詳細については「仮想マシンとの通信のセットアップ方法 (英語)」を参照してください。SQL Server をインターネット経由でリモート管理したい場合は、SQL Server 用の標準ポート 1433 経由での仮想マシンへのアクセスを許可するエンドポイントを作成します。このポートはハッカーによく知られているため、無作為に選んだパブリック ポートを SQL Server エンドポイントとして使用することを推奨します。エンドポイントへの着信接続は、仮想マシン全体に自動的に負荷分散できます。詳細については「仮想マシンの負荷分散 (英語)」を参照してください。この方法は、複数の仮想マシンによるフロントエンド Web サーバーのスケールアウトなどのシナリオで便利です。 仮想マシン間の完全な接続を確立するには、最初に Windows Azure 仮想ネットワーク (英語) を作成し、そのネットワーク内に仮想マシンを作成します。新しく作成した仮想マシンには仮想ネットワーク構成で指定した範囲の IP アドレスが自動的に割り当てられるので、独自の DHCP サービスを実装する必要はありません。仮想ネットワークはビルトイン DNS が用意されています。あるいは、独自の DNS サーバーを展開することも可能です。詳細については「Windows Azure 名前解決 (英語)」を参照してください。次の作業に進む前に、名前解決の検証を入念に行ってください。ネットワークにあまり詳しくない場合は、知識のある人物に構成を確認してもらいましょう。 そして、ここからがさらに重要です。セキュアな VPN ゲートウェイを使用すると、社内ネットワークと仮想ネットワークの間で拠点間接続を確立できます。これには、社内ネットワークに VPN 機器を設置する必要があります。VPN ゲートウェイを確立するには、専用の VPN 機器やソフトウェアベースのソリューションを使用できます。詳細については、「拠点間接続用の仮想ネットワークを作成する (英語)」を参照してください。また、コンピューターから仮想ネットワークに直接 VPN 接続するポイントツーサイト接続も確立できるので、遠く離れた場所から仮想ネットワークに接続したい開発者や管理者にとって便利です。詳細については「管理ポータルでポイントツーサイト VPN を構成する (英語)」を参照してください。 Windows Server の展開では、ID 管理やセキュリティを Active Directory (AD) に頼るのが一般的です。Windows Azure インフラストラクチャ サービスではさまざまな方法で Active Directory を展開できます。仮想ネットワーク内の仮想マシン専用のスタンドアロン Acrive Directory を展開したい場合は、「Windows Azure に新しい Active Directory フォレストをインストールする (英語)」を参照してください。VPN ゲートウェイを実装する場合は、仮想ネットワーク内の仮想マシンを社内の Active Directory にドメイン参加させることができます。読み取り専用の Active Directory ドメイン コントローラーを仮想ネットワークに展開することで、パフォーマンスと信頼性を向上できます。その実行方法については、「Windows Azure 仮想ネットワークでレプリカの Acrive Directory ドメイン コントローラーをインストールする (英語)」を参照してください。また、Active Directory フェデレーション サービスなどの強力な Active Directory 構成が多数サポートされており、仮想マシンや Windows Azure で稼働する他のクラウド サービスにまたがるハイブリッド型の ID 管理にも対応しています。詳しくは「Windows Azure Active Directory (英語)」を参照してください。
  6. 仮想マシンのタイム ゾーンを UTC に設定する
    仮想マシンのタイム ゾーンを UTC に設定してください。Windows Azure インフラストラクチャ サービスは、すべてのデータ センターと地域で UTC を使用しています。UTC に設定することで、サマータイムに関連した問題が生じても影響を受けずに済みます。クライアントについては従来どおり、ローカルのタイム ゾーンを使用します。
  7. データの圧縮とバックアップの圧縮を使用する
    SQL Server はデータの圧縮およびバックアップの圧縮をサポートしており、最小限の CPU オーバーヘッドで入出力のパフォーマンスを向上できます。データやバックアップを圧縮することで、Windows Azure ストレージに対する入出力処理が高速化し、容量も節減できます。
  8. バックアップはディスクではなく BLOB ストレージに保存する
    SQL Server 2012 Service Pack 1 用の累積更新プログラム 2 により、Windows Azure インフラストラクチャ サービスに展開した SQL Server を新しい方法で手軽にバックアップできるようになりました。データベースのバックアップや復元には、追加のデータ ディスクを用意する代わりに、Windows Azure BLOB ストレージを使用できます。BLOB ストレージは容量が無制限で、ローカルの冗長性が確保されているほか、任意で地理的な冗長性を持たせることができます。BLOB ストレージを使用することでデータ ディスクの貴重な空き容量が増え、データやログ ファイル専用として使用できるようになります。詳細については「Windows Azure BLOB ストレージ サービスを使用した SQL Server のバックアップと復元」を参照してください。また、さらなる利点として、複数のストレージ アカウントや地域を横断して非同期でバックアップ BLOB をコピー (英語) できるので、アップロードやダウンロードに時間をかけたり、帯域幅を無駄にしたりせずに済みます。
  9. ハッキング対策を講じる
    Windows Azure インフラストラクチャ サービスに展開している仮想マシンや SQL Server を不正なアクセスから保護するために、適切なセキュリティ対策を講じてください。ハッカーはインターネットに接続しているセキュリティの脆弱なマシンを乗っ取って思いどおりにしようと常に狙っています。Windows Azure インフラストラクチャ サービスに展開した SQL Server についても、オンプレミスのネットワーク DMZ 内に展開した SQL Server と同等のセキュリティ対策を施すことをお勧めします。RDP や TSQL のエンドポイントを公開することは避け、代わりにセキュアな VPN ゲートウェイを構築して、データベース サーバーを直接管理してください。また、ID 管理やアクセス管理には Windows 認証を使用してください。SQL 認証を使用する場合は、SQL Server ごとに異なるアカウントを作成して sysadmin ロールに追加し、強力なパスワードを設定して sa アカウントを無効化します。使用しないサービスは停止して無効化し、攻撃を受ける余地を最小限に抑えてください。また、データ、ログ、バック ファイルの保護には、SQL Server の透過的なデータ暗号化 (TDE) を使用することを検討してください。これらのファイルは、仮想マシンの外部にコピーされたとたん役に立たなくなってしまいます。
  10. PowerShell を習得する
    Windows Azure 管理ポータルでは、リッチなグラフィカル インターフェイスを使用して、Windows Azure インフラストラクチャ サービス内に展開した仮想マシンのプロビジョニングや管理を行うことができます。大量の仮想マシンを展開しなければならない場合には、時間をかけてでも PowerShell を習得すると非常に便利です。仮想マシンのプロビジョニングや仮想ネットワークの構成を実行する PowerShell スクリプトのライブラリを開発すれば、時間と手間を大幅に削減できます。詳細については「PowerShell を使用した Windows Azure インフラストラクチャ サービス (IaaS) 展開の自動化 (英語)」を参照してください。

これで、Windows Azure インフラストラクチャ サービスに移行可能な SQL Server ワークロードを判別するための情報がそろいました。まずは学習を兼ねて小規模なワークロードの移行から始めていただき、自信がついたら、より大規模なワークロードに着手してみてください。Windows Azure インフラストラクチャ サービスのメリットは、互換性の他に、SQL Server 展開の構成とメンテナンスを細かく制御できる (また、そうする必要がある) ことにあります。これは多くの IT 組織にとって魅力的な点ですが、サーバーの保守作業から解放され、技術革新にもっと時間を注ぎたいと考える人もいるでしょう。

Windows Azure SQL データベースは SQL Server テクノロジを基盤としており、サービスとして配信されます。サーバー ソフトウェアのインストールや管理が不要で、高可用性や災害復旧などの高度な機能があらかじめ搭載されています。さらに、既存のワークロードの移行においては Windows Azure インフラストラクチャ サービス上で稼働する SQL Server の互換性と細かな制御性、新しいワークロードにおいては Windows Azure SQL データベースのマネージド サービスによる俊敏性や利点という、いいとこ取りのハイブリッドな Windows Azure の使用も完全にサポートされており、他のパブリック クラウド プロバイダーとの大きな差別化要因の 1 つとなっています。これら機能の詳細については、「データ管理」を参照してください。

Roger Doherty シニア プログラム マネージャー マイクロソフト カスタマー アドバイザリー チーム