• [アーティクル]

August 2010

Volume 25 Number 08

Windows Azure - アプリケーションをクラウドに移行するためのヒント

George Huey | August 2010

テクノロジの良いところは、絶えず進化し、常に変わっていくため、いつも学ぶことがたくさんある点です。クラウド コンピューティングについて学んだり、クラウド コンピューティングを支持している人々は、Windows Azure プラットフォームにとても興奮しました。私たちは、マイクロソフトのテクニカル エバンジェリストとして、お客様と一緒に新しいテクノロジの導入に取り組むという、すばらしい幸運に恵まれました。その結果、Windows Azure を適用するにあたって、多種多様な方法があることがわかりました。

George には、早くから、Windows Azure を使用したいと考える個人的な理由がありました。George は、多くのコミュニティ活動に携わっていたため、一時的に必要なアプリケーションをすばやく使用し不要になったら使用を中止する、という機能が非常に便利だとわかっていたからです。Microsoft .NET Framework コードを記述した経験がある開発者であれば、テクノロジを習得する手間をほとんどかけずに、アプリケーションを作成、配置、および実行できます。

法人のお客様の多くが Windows Azure に関心を示されたことから、Microsoft Technology Center に、一連の Windows Azure Migration Lab (Windows Azure 移行ラボ) を設置することにしました。このラボの目的は、お客様がアプリケーションをラボに持ち込み、実際に Windows Azure に移行することです。このプロセスを通じて、すべてのお客様がそれぞれ、Web アプリケーションと SQL データベースを Windows Azure プラットフォームに正常に移行することができました。

私たちにとっては、これは驚くことではありませんでした。私たちには、既に Windows Azure に関する豊富な経験があったので、お客様の移行がうまくいくと確信していました。しかし、ラボにご参加いただくお客様のさまざまなアプリケーションの移行をお手伝いしているうちに、移行をスムーズに進めるのに役立つ多数のテクニックを習得しました。今回の記事では、お客様と一緒に実際の移行に取り組んだ際に習得したヒントとテクニックをいくつか紹介します。

移行の基礎

社内設置型からクラウドへのアプリケーションの移行 (またはクラウド サービスへの新しいアプリケーションの作成) を決定するときは、アプリケーション アーキテクチャのいくつかの側面について考慮する必要があります。

  • アプリケーションの管理
  • アプリケーションのセキュリティ
  • アプリケーションの互換性
  • データベースの互換性

移行ラボで最もよく耳にした疑問点と問題点の多くは、上記の 4 つの領域が中心となっていました。そこで、これらのトピックに重点を置いて説明します。

クラウドにアプリケーションを移行したり、作成したりする際によく耳にしたことは、Windows Azure を使用すれば、開発者は可用性、スケーラビリティ、信頼性、セキュリティなどの問題に関連して共通のアーキテクチャ パターンについて懸念する必要がない、という誤解でした。実際のところ、分散コンピューティングのコンテキストでのアーキテクチャ パターンは、社内設置型用に設計されたアプリケーションでも、Windows Azure 配置用に設計されたアプリケーションでも、等しく妥当性があります。

アプリケーションの管理

アプリケーションが社内設置型で実行されていても、クラウドで実行されていても、運用管理チームが効果的な決断を下すには、それを可能にするデータが必要です。考慮すべき問題には、サービス レベル契約、容量計画、顧客への請求、監査、アプリケーションの監視、トラフィック分析、コスト管理 (スケール アップやスケール ダウンのタイミングの把握) などがあります。これらの問題は、アプリケーションを運用環境に配置する前に解決しておく必要があり、最高の結果を得るためには、アプリケーションを作成する前に解決しておかなければならないことがほとんどです。

こうした問題は、Windows Azure 移行ラボ中に考慮した問題のほんの一部にすぎません。Windows Azure SDK で提供されている Windows Azure の診断 API (Microsoft.WindowsAzure.Diagnostics) を使用することにより、アプリケーションのクラッシュ ダンプ、失敗した要求のトレース、Windows イベント ログ、IIS ログ、Windows Azure ログ、およびパフォーマンス カウンターを明らかにすることができました。

これは、おそらく皆さんが想像しているよりもはるかに簡単です。収集する診断情報の種類を診断モニターに指定し (例については図 1 参照)、データ転送のスケジュールを設定して、Windows Azure ストレージがある中央の場所に情報が転送されるようにします。

図 1 診断の設定

public class WebRole : RoleEntryPoint {
  public override bool OnStart() {
    DiagnosticMonitorConfiguration config = 
      DiagnosticMonitor.GetDefaultInitialConfiguration();

    // To see which counters you can capture, type
    // "typeperf.exe /q" in a command window.

    // Capture CPU utilization.
    PerformanceCounterConfiguration procUtilization = 
      new PerformanceCounterConfiguration();
    procUtilization.CounterSpecifier = 
      @"Processor(*)\% Processor Time";
    procUtilization.SampleRate = 
      System.TimeSpan.FromSeconds(30.0);  
    config.PerformanceCounters.DataSources.Add(procUtilization);

    // Monitor available memory.
    PerformanceCounterConfiguration procAvailMemory = 
      new PerformanceCounterConfiguration();
    procAvailMemory.CounterSpecifier = @"\Memory\Avail MBytes";
    procAvailMemory.SampleRate = 
      System.TimeSpan.FromSeconds(30.0);  
    config.PerformanceCounters.DataSources.Add(procAvailMemory);

    // Add event collection from Windows Event Log 
    // (System and Application event logs).
    config.WindowsEventLog.DataSources.Add("System!*");
    config.WindowsEventLog.DataSources.Add("Application!*");

    // All of the information monitored so far is being stored locally. 
    // Tell diagnostic monitor what schedule period should be used when 
    // transfering the events. 
    config.Directories.ScheduledTransferPeriod = 
      TimeSpan.FromMinutes(1);
    config.Logs.ScheduledTransferPeriod = 
      TimeSpan.FromMinutes(1);

    // Start the diagnostics monitor.
    DiagnosticMonitor.Start("DiagnosticsConnectionString", config);

    // True gives full crash dumps. False gives small crash dumps.
    CrashDumps.EnableCollection(false); 

    System.Diagnostics.Trace.TraceInformation("OnStart Completed");

    RoleEnvironment.Changing += RoleEnvironmentChanging;

    return base.OnStart();
  }
...

Windows Azure 診断の詳細については、Mike Kelley が執筆した MSDN Magazine の 2010 年 6 月号の記事「クラウドの診断: Windows Azure でログ記録とトレースを制御する」(msdn.microsoft.com/magazine/ff714589) を参照してください。

アプリケーションのセキュリティ

アプリケーションをクラウドに移行するあらゆる組織にとっての最大の懸念事項はセキュリティです。多くの企業が、膨大な時間をかけ、資金を投入し、エンジニアリングを行ってセキュリティ モデルを設計および開発しているため、既存の投資 (ID ストア、シングル サインオン ソリューション、ファイアウォールなど) を活用できることが重要です。

企業がクラウドベースのアプリケーションのセキュリティを確保する方法はいくつかありますが、一般的になりつつあるパターンはクレームベースの手法です。

このプロセスを図 2 に示します。セキュリティ トークン サービス (STS) から発行されたセキュリティ トークンをアプリケーションが処理できるようにするには、STS とアプリケーションの間に信頼関係を確立する必要があります。

アプリケーションに関連するクレームベースの ID

図 2 アプリケーションに関連するクレームベースの ID

「誰がアプリケーションにログインできるか」といったビジネスの要件を満たすように、アクセス制御の規則を定義します (手順 1)。こうした規則が STS によって格納されます。ユーザーがアプリケーションにアクセスを試みると、STS にリダイレクトされ、そのユーザーは有効なトークンを受け取ることができます (手順 2)。トークンを受け取ったユーザーは、一連の入力クレーム (Live ID やドメイン アカウントなど) を STS に提示して認証を求めます。ユーザーが認証されたら、STS はこれらのクレームを一連の出力クレームにマップします (手順 3)。出力クレームが Security Assertions Markup Language (SAML) トークンにパッケージ化され、STS によって署名されます (手順 4)。その後、このトークンがユーザーに返され、アプリケーション (証明書利用者) に転送されます (手順 5)。アプリケーションは、SAML トークンが有効で、信頼関係のある STS から転送されたものであることを確認します (手順 6)。トークンが検証されたら、アプリケーションはトークン内のクレームをチェックして、適切な応答を返信します (手順 7)。とても簡単ですね。この手法のすばらしい点は、ASP.NET プロバイダー モデル内に実にうまく適合するところです。ASP.NET アプリケーションをクレーム対応にするプロセスは、きわめて簡単です。

開発者の作業をより簡単にするために、マイクロソフトは Windows Identity Foundation (WIF) SDK を導入しました。これにより、SAML 2.0 のトークンを解析する際のすべての単純作業が実行されるため、開発者は、基になるセキュリティ テクノロジについて懸念する必要なく、アプリケーションに集中できます。

まず、WIF と WIF SDK をダウンロードします。インストールが完了したら、アプリケーションをクレーム対応にするのに必要なツールが揃います。

ASP.NET Web アプリケーションが含まれる Visual Studio ソリューションを右クリックして、[追加] をポイントし、[新しい Web サイト] をクリックします。[ASP.NET Security Token Service Web Site] (ASP.NET セキュリティ トークン サービス Web サイト) テンプレートをクリックします。これで、ユーザーの開発環境用に STS を設定できます。

開発用に STS を作成したら、アプリケーションを右クリックして、[Add STS reference] (STS 参照の追加) をクリックすることで、STS に参照を追加できます。ウィザードが起動するので、これを使用して、アプリケーションと STS の間に信頼関係を確立するプロセスを実行します。サイトのアプリケーションの web.config ファイルを指定し、[Application URI] (アプリケーション URI) を指定します (図 3 参照)。

Federation Utility (フェデレーション ユーティリティ) ウィザード

図 3 Federation Utility (フェデレーション ユーティリティ) ウィザード

次に、[Use an existing STS] (既存の STS を使用する) をクリックして、STS プロジェクトの FederationMetadata.xml ファイルの場所を指定します (図 4 参照)。このプロセスの残りは、既定値を選択します。

STS の構成

図 4 STS の構成

web.config ファイルを見てみましょう。FedUtil.exe のウィザードで大量のコードが変更されていることがわかります。最も重要な変更は、web.config ファイルの microsoft.identityModel ノードに対して行われています。このノードには、STS プロジェクトへの参照と、アプリケーションが想定するクレームの種類が表示されます。アプリケーションが STS から返信されたクレームを適切に受け取っていることを確認するには、default.aspx ページに以下のコードを追加します (WIF SDK から、Microsoft.IdentityModel への参照を追加する必要があることに注意してください)。

IClaimsIdentity ici = 
  (IClaimsIdentity)Thread.CurrentPrincipal.Identity;

foreach (Claim c in ici.Claims) {
  Response.Write(c.ClaimType + " - " + c.Value + "<br/>");
}

次回アプリケーションを実行したときに、自動的に STS にリダイレクトされます。既定では、STS によって "Adam Carter" として認証されます。[Login] をクリックします (パスワードは不要です)。

STS がログインを認証したら、認証に必要な SAML トークンと共に、Web アプリケーションにリダイレクトされます。アプリケーションがトークンを受け取り、default.aspx ページの実行を許可します。WIF のモジュールがセキュリティ資格情報をインターセプトするため、ID プリンシパルを IClaimsIdentity としてキャストし、その結果として、クレームの種類と値を ID オブジェクトから抽出できます (図 5 参照)。

ID オブジェクトのクレームの種類と値

図 5 ID オブジェクトのクレームの種類と値

これで Web アプリケーションがクレーム対応になったので、既存の ID モデルに適合させるのは簡単です。運用 STS を指すように構成ファイルを更新して、アプリケーションが証明書利用者として構成されていることを確認するだけです。また、この情報を使用して、カスタム ロール プロバイダーを作成して、クレームの種類をロールに変換できます。

これは非常に強力な技法です。この技法を使用すると、アプリケーションをほとんどすべての環境 (社内、クラウド、またはパートナーのデータセンター) に移行し、パブリックに公開される STS を通じて ID ストアに対する検証を引き続き実行できます。

アプリケーションの互換性

Windows Azure はアプリケーション プラットフォームなので、Windows Azure プラットフォームに合うアプリケーションの種類を理解することが重要です。ネイティブ コードを実行したり、アプリケーションを完全な信頼で実行したりできますが、アプリケーションはパッケージ化してからクラウドに配置する必要があります。つまり、アプリケーションを評価して、アプリケーションが適合するかどうかを確認することが重要です。

例を挙げて説明しましょう。Windows Azure 移行ラボを利用したあるお客様のアプリケーションは、バックエンドに SQL Server 2005、データ アクセス層に LINQ to SQL、フロントエンドに MVC Framework 1.0 と ASP.NET 3.5 SP1 の両方を使用する構成の、IIS で実行するアプリケーションでした。

このアプリケーションは、トラフィックをルーティングするロード バランサーを備えた Web ファームに含まれています。アプリケーション自体はステートレスなので、ユーザーが最終的にどのサーバーにリダイレクトされるかは重要ではありませんでした。

このアプリケーションについて興味深い点は、MVC アプリケーションが 220 を上回る Web サイトを管理していることでした。この企業では、MVC ルーティングと SQL Server データベースに格納された情報を組み合わせて、各 Web サイトに読み込まれるコンテンツを特定しています。ロード バランサーの背後には 5 台の Web サーバーがあり、Web サイトのコレクションに対して、1 か月に 400 万回を上回るページ アクセスにサービスを提供しています。

この企業が直面している主な課題は、企業の環境に合った新しい Web サーバーの準備にかかる時間です。なんと、数か月もかかるのです。この企業が Windows Azure へのアプリケーションの移行を検討した一番の動機は、この膨大な時間を短縮することでした。Windows Azure では、スケールアウトは 3 か月間も続く悪夢ではなく、1 つ 1 つの細かい構成になります。

実際には、Windows Azure への移行のプロセスはかなりわかりやすものです。この移行時に使用した汎用的なプロセスを次に示します。

  1. 開発環境でアプリケーションが正常に実行されていることを確認します。
  2. SQL Azure Migration (SQL Azure 移行) ウィザードを使用して、バックエンドの SQL Server を SQL Azure に移行します (これについては、この記事の後半で詳しく説明します)。
  3. SQL Azure データベースを操作するように、ローカル アプリケーションを更新します。この手順は、単に接続文字列を変更するだけです。
  4. アプリケーションを Web ロール プロジェクトに変換します。
  5. アプリケーションがローカルの開発ファブリックで実行されることを検証します。
  6. Web ロールをパッケージ化して、Windows Azure に配置します。
  7. Windows Azure からアプリケーションが実行されることを検証します。

Web ロールのパッケージ サイズを減らすために、最終的に、コンテンツ フォルダーからすべての画像と CSS ファイルを取り出して、Windows Azure ブロブ ストレージに配置することにしました。

すべてのコンテンツが Windows Azure ブロブ ストレージにあったため、GGP は Windows Azure のコンテンツ配信ネットワーク (CDN) を使用することができました。そのため、データのキャッシュをエンド ユーザーにより近い場所に配置することが可能になります。

Windows Azure の開発、テスト、および配置の詳細については、2010 年 4 月号の MSDN Magazine の記事「Windows Azure: Visual Studio 2010 での Windows Azure アプリケーションの開発と配置」を参照してください。ストレージの問題の詳細については、2010 年 1 月号の記事「クラウド ストレージ: Windows Azure ストレージによるアプリケーション エンジンの強化」を参照してください。

データベースの互換性

SQL Azure が最初にリリースされたときに、SQL Server データベースをいくつか SQL Azure に移行しました。Windows Azure 移行ラボを設置する経験に加えて、移行プロセスに加わる前にも考慮すべきいくつかの重要な点を学んでいました。

まず、データベースのサイズを確認し、データベースを SQL Azure で使用する際の許容範囲内にそのサイズを収める方法を確認することが重要です。現時点では、SQL Azure の Web Edition では 1 GB と 5 GB のサイズが提供され、Business Edition では 10、20、30、40、および 50 GB のサイズが提供されています。使用するデータベースのサイズを確認して、50 GB を超えないようにします。データベースが 50 GB より大きい場合はデータベースを調べて、より小さい複数のデータベースに分割 (つまり、シャーディング) できるかどうかや、大規模なデータをブロブ ストレージに移動できるかどうかを検討する必要があります。

SQL Azure では、SQL 認証しかサポートされないため、アプリケーションで使用する認証方式を変更する必要があるかどうかを考慮する必要があります。そのうえ、SQL Azure には、接続時間を制限するリソース スロットルがあります。これらの 2 つの問題については、後ほど詳しく説明します。

データベースを SQL Azure に移行する前に考慮すべきもう 1 つの点は、SQL Server データベースのバージョンです。SQL Azure は SQL Server 2008 を基盤として構築されています。つまり、SQL Server 2000 や SQL Server 2005 のデータベースを SQL Azure に移行する場合は、データベースに SQL Server 2008 との互換性があることを確認しなければなりません。たとえば、以前のバージョンの SQL Server では、旧形式の TSQL 結合構文 (WHERE 句の *= 演算子や =* 演算子など) がサポートされていますが、SQL Server 2008 では ANSI 形式の結合のみがサポートされます。たとえば、次のような形式です。

SELECT ProcessClassTypeName
       , bpa.PropertyMetadata AS PropertyMetadataOverride
       , act.PropertyMetadata AS PropertyMetadataDefault
  FROM dbo.BusinessProcessActivities bpa
  LEFT JOIN dbo.Activities act ON act.Activity_ID = bpa.Activity_ID

データベースの互換性レベルが SQL Server 2005 または SQL Server 2008 に設定されている場合、旧形式の TSQL の結合構文 (*= と =*) はサポートされません。これは、SQL Server 2008 に移行する際に気が付く互換性の問題のほんの一例です。

SQL Server 2008 への移行の詳細は、この記事で扱う範囲を超えているので触れませんが、データベース移行のベスト プラクティスに興味がある方は、「SQL Server 2008 アップグレードに関するテクニカル リファレンス ガイド」(英語) を参照してください。また、MSDN の SQL Server デベロッパー センターでは、豊富なリソースを参照できます。

SQL Server 2008 と互換性があるデータベースを SQL Azure に移行するのが最適な方法だとわかります。つまり、SQL Server 2000 または SQL Server 2005 のデータベースを SQL Azure に移行する場合は、社内で SQL Server 2008 へのアップグレードを実行してから、SQL Azure に移行します。

マイクロソフトでは、Microsoft SQL Server 2008 アップグレード アドバイザーという優れたツールを用意しています。このツールを使用して、SQL Server 2000 および SQL Server 2005 のインスタンスを分析し、アップグレードに影響する可能性がある機能と構成の変更を特定できます。また、特定されたそれぞれの問題と、それらの問題を解決する方法について説明しているドキュメントへのリンクも提供されます。データベースに SQL Server 2008 との互換性があることを確認したら、すぐにデータベースを SQL Azure に移行できます。

とはいえ、SQL Azure でも新しい SQL Server 2008 機能が完全にサポートされているわけではないため、注意が必要です。たとえば、現時点では、ファイルストリームが SQL Azure でサポートされていません。SQL Azure に移行する場合の互換性の問題を確認する方法はいくつかあります。

率直で強引なアプローチでは、単純に荒っぽい方法を実行します。つまり、SQL Azure に対して TSQL スクリプトを実行し、エラーを探します。発生したエラーを修正して、スクリプトを再度実行します。成功するまで、この処理を繰り返します。最適な時間の使い方ではないかもしれませんので、実行するかどうかは皆さんにお任せします。

SQL Server Management Studio の script generator (スクリプト ジェネレーター) ウィザードを使用して、TSQL スクリプトを生成できます。ウィザードに従って操作する場合は、高度なスクリプト オプションを選択し、SQL Azure データベースに対して [データベース エンジンの種類に対応したスクリプト] を選択します。この手順を実行しないと、SQL Server は SQL Azure と互換性のない TSQL を生成します。

もう 1 つの方法として、sqlazuremw.codeplex.com (英語) からSQL Azure 移行ウィザード (SQLAzureMW) をダウンロードします。SQLAzureMW は、互換性の問題を特定し、(可能な場合は) これらの問題を修正して、認識しているすべての問題をユーザーに通知します。

SQL Azure の一般的なガイドラインと制限事項について理解を深めるには、msdn.microsoft.com/library/ee336245 (英語) を参照してください。

SQL Azure でデータベース スキーマ (テーブル、ビュー、ストアド プロシージャなど) を作成したら、データをアップロードする必要があります。次に、最も一般的な方法を示します。

  • SQL Server Integration Services
  • 一括コピー プログラム (BCP)
  • SqlBulkCopy によるデータ移行
  • SQL Azure 移行ウィザード (バックグランドで BCP を使用)

SQLAzureMW の使用

SQLAzureMW は、お客様の SQL データベースの移行プロセスをお手伝いするために George が作成しました。図 6 に、実行中の SQLAzureMW を示します。

SQLAzureMW の使用

図 6 SQLAzureMW の使用

SQLAzureMW は、SQL Server データベースを分析して、SQL Azure の互換性の問題を特定します。また、データベース オブジェクトとデータを、ソース データベースから SQL Azure に移行できます。

SQLAzureMW を使用することで、データベース開発者は、データベースを SQL Azure に移行するのに必要となる作業量を把握できます。SQLAzureMW によって、SQL Server 2000 または SQL Server 2005 のデータベースに関連する多くの互換性の問題が通知される場合は、最初に SQL Server 2008 にアップグレードしてから、SQL Azure に移行することをお勧めします。SQL Server 2008 への移行のプロセスは適切に文書化され、活用可能な多くのガイダンスと専門知識が記載されています。SQL Server 2008 への移行の詳細については、「SQL Server 2008 アップグレードに関するテクニカル リファレンス ガイド」(microsoft.com/­downloads/details.aspx?FamilyID=66d3e6f5-6902-4fdd-af75-9975aea5bea7、英語) を参照してください。また、MSDN の SQL Server デベロッパー センター (msdn.microsoft.com/sqlserver) では、豊富なリソースを参照できます。

SQL Server 2008 R2 をインストールしていない場合は、アップグレード プロセスを実行することをお勧めします。SQL Server 2008 R2 Express Edition をダウンロードして、アップグレード プロセスを同時に実行できます。

データベース開発者が SQL Server と SQL Azure の違い (互換性の有無、一般的なガイダンスと制限事項など) について理解するのに適しているその他のソースに、「Transact-SQL リファレンス (SQL Azure データベース)」(msdn.microsoft.com/library/ee336281、英語) と「一般的なガイドラインと制限事項 (SQL Azure データベース)」(msdn.microsoft.com/library/ee336245、英語) があります。

最初に SQL Server 2008 にアップグレードする場合でも、SQL Server 2000 や SQL Server2005 のデータベースを直接移行する場合でも、データベースの互換性の問題を分析して、SQL Azure と互換性のある SQL を生成するための方法が必要です。このような場合にこそ SQLAzureMW が役立ちます。互換性の問題を特定するために動的 SQL をチェックするときに、SQLAzureMW では、データベースを分析できるだけでなく、SQL Server Profiler トレース ファイルを分析することもできます。

移行ラボでは、すべての SQL データベース (SQL Server 2000 および SQL Server 2005) を、ほとんどまたはまったく変更することなく SQL Azure に移行できました。対処する必要があった残りの 2 つの問題は、認証と SQL Azure のリソース スロットリングでした。

認証の問題が発生するのは、SQL Azure では、Windows 認証ではなく SQL 認証しかサポートされないことが原因です。あるお客様のケースでは、接続文字列を変更して、セキュリティ接続ではなく、ユーザー名とパスワードが反映されるようにする必要がありました。たとえば、次のように作業に着手します。

<add key="ConStr" 
  value="server=DbSvr;database=CRMDB;Trusted_Connection=yes" />

この接続文字列を単純に次のように変更します。

<add key="ConStr" 
  value="Server=avl6qnn22s.database.windows.net;Database=CRMDB;User ID=WebSvrAdmin@avl6qnn22s;Password=password;Trusted_Connection=False;" />

ADO.NET を使用して SQL Azure に接続することに関する詳細については、msdn.microsoft.com/library/ee336243 (英語) を参照してください。

リソース スロットリング

一部のアプリケーションでは、SQL Azure リソース スロットリングへの対処に若干時間が必要です。必要なときだけ SQL データベースに接続して、最後の最後にすべてのトランザクションを迅速かつ効率的に実行し、接続をできるだけ早く切断するというベスト プラクティスに従っているアプリケーションでは、SQL Azure のスロットリングは問題になりませんでした。それに対して、起動時に SQL データベースへの接続を確立し、プログラムの実行中は長時間にわたって接続を保持するアプリケーションは、再試行ロジックを実装するようコードを変更するか、ベスト プラクティスに従ってリソースを保持しないようにコードをリファクタリングする必要があります。

ラボでよく耳にしたのは、接続が 5 分間アイドル状態になる場合のみ、SQL Azure が接続を切断するという誤解です。 SQL Azure では、アプリケーションの接続を切断するタイミングを決定する際に、いくつかの要因 (リソースの過剰な使用、実行時間が長いクエリ、実行時間が長い単一トランザクション、接続のアイドル状態など) を考慮します。

SQL Azure チームは、引き続きリソース スロットリングのパラメーターを微調整する予定ですが、いずれにせよ、SQL Azure は、リソース使用率のパラメーター値を上回るすべてのアプリケーション接続を強制的に切断するため、アプリケーションには再試行ロジックを組み込む必要があります。

一般に、SQL Azure では、接続をスロットリング (調整) するときに、固有のエラー メッセージが表示されます。エラーの完全な一覧については、msdn.microsoft.com/library/ff394106 (英語) を参照してください。

小さなトランザクションが大量にある場合は、次のパターンを使用します。

  1. 接続プールを使用します。接続プール マネージャによって接続が開いたままになるため、アプリケーションで接続を開いたり閉じたりすることによるパフォーマンスへの影響がほとんど、またはまったくなくなります。
  2. 接続時間を可能な限り短くします。接続を開き、トランザクションを実行して、接続を閉じます。
  3. データベース操作で try-catch パターンを使用します。
  4. 適切であれば、例外をキャッチして、トランザクションを再試行します。
  5. エラーと例外をログに記録して、問題の解決に役立てます。UTC タイムスタンプ、接続コンテキストの ID、および例外番号を取得するようにします (または、UTC タイムスタンプを取得する代わりに時刻とタイム ゾーンを指定します)。

SQLAzureMW は、SQL Azure のリソース スロットリングに対処しなければならなかったアプリケーションの良い例です。既に説明したように、SQLAzureMW では、社内設置型の SQL データベースを SQL Azure に移行できます。1,000 個以上のテーブル、1,500 個以上のストアド プロシージャ、および数百万行以上のデータを移行すると、アップロードする必要がある実際のデータ量によっては、移行が完了するのに優に 5 時間以上かかることがあります。

このようなシナリオでは、SQLAzureMW は 2,500 をはるかに上回る TSQL ステートメントを SQL Azure に対して実行するだけでなく、BCP 経由でデータを移行することになります。2,500 を超える TSQL ステートメントを 1 つのステートメント (またはトランザクション) で実行すると、おそらく、SQL Azure リソース スロットリングのパラメーターを超えるため、接続は強制終了されます。

1 つの解決策として、SQLAzureMW では、トランザクションを小さく分割して、SQL Azure から接続が強制終了されるまで分割したトランザクションを実行します。接続エラーが発生すると、SQL Azure との新しい接続を再度確立し、最後に正常実行されたコマンドに続く処理を選択します。同様に、BCP を使用して SQL Azure にデータをアップロードするときは、SQLAzureMW ではデータをより小さなセクションに分割し、再試行ロジックを使用して、接続が閉じられる直前に正常にアップロードされたレコードを特定します。その後、BCP に、その次のレコード セットを指定してデータのアップロードを再開させます。

SQL Azure 製品チームは、SQL Azure を最初にリリースしてから、多くの改良を加えてきました。たとえば、移行ラボで判明したスロットリングに関連する多くの問題を解決しました。ただし、アプリケーションでは、再試行ロジックを使用して、接続の強制終了に適切に対処することをお勧めします。

次のステップ

このように、Windows Azure へのスムーズな移行を計画するには、考慮すべき問題がたくさんありますが、アプリケーションを社内設置型から Windows Azure に移行するのに必要な実際の作業量は最小限で済むことがわかりました。もちろん、これはアプリケーションごとに異なります。

データベースを独自に分析して、Windows Azure への移行が理にかなっているかどうかを判断し、解決すべき問題を特定する必要があります。 Windows Azure 移行ラボを利用したお客様には、アプリケーションをほとんど、またはまったく変更することなく移行できること、および知識の習得や資金の投資をほとんど行うことなく、Windows Azure プラットフォームを使用できることをご理解いただきました。ここに記載した情報と、SQLAzureMW のようなツールを併用すれば、同じように移行を成功させることができます。

George Huey は、マイクロソフトの Developer & Platform Evangelism グループの主席アーキテクトです。企業が新しいテクノロジについて理解し、それらのテクノロジを適用してビジネス上の問題を解決できる方法を理解できるように、企業と共に取り組んでいます。 彼は SQL Azure 移行ウィザード (SQLAzureMW) の作成者でもあります。

Wade Wegner は、マイクロソフトに勤務している、Windows Azure プラットフォームのテクニカル エバンジェリストです。彼の連絡先は、ブログ (blog.wade­wegner.com、英語) または Twitter (twitter.com/wadewegner、英語) です。

この記事のレビューに協力してくれた技術スタッフの Jim Nakashimi に心より感謝いたします。