Azure Web Sites

  • [アーティクル]

ハイブリッド接続: PortBridge を使用して Azure Web Sites を LOB アプリケーションに接続する

Tejaswi Redkar

コード サンプルのダウンロード

おおかたの予想とは裏腹に、すべてがクラウドに移行されることにはなりません。少なくとも、現時点ではまだすべてではありません。自動車がすべてハイブリッド車にならないように、すべての電化製品がエネルギー効率を求めるわけではないように、かなりの数のソフトウェアが今後もオンプレミスで実行されることになるでしょう。大掛かりな投資を中止するのは難しいため、ほとんどの企業は既存のアプリケーションを近代化するための業務上正当な理由を求めています。自宅にソーラー パネルを設置することを考えてみてください。歳月を掛ければエネルギーの節約になり、税も優遇されることがわかっていても、事前に設置費用がかかることを考えるとなかなか積極的にはなれません。組織にとってのクラウドへの移行も、この例と同じです。

ただし、さいわいなことにアプリケーションの場合はハイブリッド接続によって近代化が可能になります。つまり、データセンターでオンプレミスに実行されている既存のソフトウェア サービスに接続したまま、クラウドの能力を利用できるようになります。今回は、Azure 以外のデータセンターで運用されているソフトウェア サービスに接続する際に、Azure サービス バスを利用する Web サイトのビルド方法について説明します。ここではサービス バス API を直接使用するのではなく、Azure Web Sites をオンプレミスのサービスに接続するためによく使われている PortBridge というユーティリティを使用します。

Azure におけるハイブリッド接続

Azure には、ハイブリッド アプリケーションをビルドするためのサービスが数多く含まれています。ハイブリッド接続に最もよく使用されるのは Azure 仮想ネットワークと Azure サービス バスの 2 つのサービスです。Azure 仮想ネットワークを使用すると、オンプレミスのネットワークを Azure に拡張できるため、Azure とデータセンターを結ぶプライベート ハイブリッド ネットワークを構築できます。Azure とデータセンターを結ぶ拡張は、サービス バスのアプリケーション層ではなく、ネットワーク層で行われます。今回は、サービス バスを使用したアプリケーション接続について説明します。ここでは取り上げない Azure 仮想ネットワークの詳細については、bit.ly/QAODgX を参照してください。

サービス バス リレー サービスでは、ファイアウォールの内側にある 2 つのアプリケーションを接続できます。アプリケーションは、Azure 内にあっても、データセンター内にあっても、また両方にあってもかまいません。サービス バス リレーは、アプリケーションの Windows Communication Foundation (WCF) エンドポイントを、Azure データセンターのサービス バス レジストリに登録できるようにします。エンドポイント登録後は、サービス バス インフラストラクチャ内のクライアントとサーバーの間でメソッド呼び出しを安全に交換できるようになり、その結果、データセンターで実行している個別のアプリケーションと通信できるようになります。この手法は、たとえば、冷暖房空調設備や電力計にアクセスしてデータを収集したり、Azure で実行している中央サーバーから重要なイベントをこれらのデバイスに送信する必要がある電力会社に適しています。図 1 にこの例を示します。電力会社は、Azure で実行され、前処理を担うサーバーと、ビルに設置したデバイスを所有しています。

Service Bus Relay Scenario at a Utility Company
図 1 電力会社におけるサービス バス リレーのシナリオ

コントロール ゲートウェイは、ビル内で稼働するデバイスで、電気機器を制御しています。各コントロール ゲートウェイには、グローバル一意識別子を使ってサービス バス レジストリに登録される、WCF エンドポイントがあります。Azure コンピューティング サービスの 1 つで実行されている前処理サービスから特定のコントロール ゲートウェイと通信する場合、必ず、サービス バスでグローバルに一意識別されるエンドポイントへの接続を開き、そのコントロール ゲートウェイとメッセージの送受信を開始します。通常、コントロール ゲートウェイはビルのファイアウォールの内側に配置されます。では、Azure Web Sites から、オンプレミスで実行されている WCF 以外のサービス (SQL Server データベースなど) に接続する場合はどうすればよいでしょう。

PortBridge の導入

PortBridge とは、サービス バス API を基盤としてビルドされたユーティリティです。サービス バス API は、オンプレミスと Azure 上でそれぞれ実行されている TCP ベースのサービス エンドポイントどうしの通信を可能にします。PortBridge の核となる考え方とプロトタイプは、Clemens Vasters によって考案されました (bit.ly/SI93GM、英語)。今回は PortBridge をこの記事用に少し変更して、サービス バス SDK の最新バージョンでコンパイルしています。サービス バス リレー用にアプリケーションをビルドするときは、クラウドで公開するすべての関連エンドポイントに対して、WCF インターフェイスをビルドしなければなりません。これは、データベースや検索エンジンなど、多数のエンドポイントや汎用プラットフォームのエンドポイントがある場合に、不便で面倒な作業になります。これらのサービスの上位に、別の WCF 抽象化を追加しても意味はありません。代わりに、PortBridge を使用して、サービス バス リレー接続用に WCF 以外の TCP エンドポイントを公開することができます。これにより、Azure Web Sites のようなフロントエンド アプリケーションは、データセンターのファイアウォールの内側にある任意の TCP データ ソースへの接続を利用することができるようになります。概念的には、PortBridge は図 2 に示すようなジェネリック WCF インターフェイスを作成します。

図 2 PortBridge のジェネリック WCF インターフェイス

namespace Microsoft.Samples.ServiceBus.Connections
{
  using System;
  using System.ServiceModel;
  [ServiceContract(Namespace="n:",
    Name="idx", CallbackContract=typeof(IDataExchange),
    SessionMode=SessionMode.Required)]
  public interface IDataExchange
  {
    [OperationContract(Action="c", 
      IsOneWay = true, IsInitiating=true)]
    void Connect(string i);
    [OperationContract(Action = "w", IsOneWay = true)]
    void Write(TransferBuffer d);
    [OperationContract(Action = "d", 
      IsOneWay = true, IsTerminating = true)]
    void Disconnect();
  }
  public interface IDataExchangeChannel : 
    IDataExchange, IClientChannel { }
}

3 つのジェネリック メソッドを用意するだけで、PortBridge はクライアントとサーバーのエンドポイント間にあるプロキシとして機能し、サービス バス リレーを経由するすべての TCP 呼び出しを指定したサーバーに転送します。PortBridge を使用する最大のメリットは、ハイブリッド接続で有効にするオンプレミスのエンドポイントごとに WCF インターフェイスをビルドする必要がなくなることです。

PortBridge は次の 2 つのコンポーネントで構成されています。

  1. クライアント アプリケーションの近くで実行されるエージェント、つまり、Azure IaaS (サービスとしてのインフラストラクチャ) の仮想マシン (VM) で実行されるエージェント。
  2. オンプレミスで実行され、同じ環境内で実行されているサービス エンドポイントのプロキシとして機能する Windows サービス (コンソール アプリケーション)。

PortBridg の一般的なユース ケースには次のようなものがあります。

  • オンプレミスの TCP ベースのデータ ストアに接続する
  • Azure に移行できないサードパーティの Web サービスに接続する
  • リモート デスクトップ接続

今回は、Azure Web Sites とローカル コンピューターで実行している SQL Server データベースとの間で通信を可能にするために、PortBridge を配置および構成する方法について説明します。

ハイブリッド ソリューション

Azure Web Sites は、通常、アプリケーション層の Web フロント エンドまたは Web サービスを形成します。ただし、Web サイトで利用しているデータ ソースの一部を Azure に移行できないことがよくあります。このような場合に理想的なソリューションが PortBridge で、Azure Web Sites をオンプレミスで実行しているデータベースに接続します。Azure Web Sites は PortBridge エージェントと通信します。つまり、サービス バスを介して PortBridge サービスと通信します。PortBridge サービスは、呼び出しを指定したデータベースに転送します。図 3 は、今回ビルドするハイブリッド Web サイトのアーキテクチャと、PortBridge (サービス バス リレー) 環境で通常行われるメッセージ交換の流れを示しています。

PortBridge Sample Architecture
図 3 PortBridge サンプル アーキテクチャ

  1. オンプレミスの PortBridge コンソール アプリケーション (Windows サービス) は、データベースの TCP エンドポイント (SQL Server の場合は 1433) をサービス バスの名前付けレジストリに一意 URI を使って登録します。サービス バス リレーは、コンソール アプリケーションとの双方向発信接続を開きます。
  2. HTTP 要求または HTTPS 要求が Azure Web Sites に送信されると、Web サイトは通常どおりデータベース接続を開きますが、このとき代わりに PortBridge エージェント VM の IP アドレスを使用します。
  3. PortBridge エージェント VM は、クラウドのデータベース プロキシとして機能し、TCP 要求を受け取る通信インターフェイスと、PortBridge コンソールのサービス バス リレー エンドポイントに接続する通信インターフェイスの 2 つを備えています。
  4. PortBridge エージェントは、データベース要求をサービス バス リレー サービスにルーティングします。このソリューションが優れている点は、この動作が Azure Web Sites にとって通常の動作であることです。データベースに対する API に変わりはありません。IP アドレスのみが異なります。
  5. サービス バス リレーは、localhost (データセンター) で実行されている PortBridge アプリケーションに呼び出しをルーティングします。
  6. 最終的には呼び出しがデータベースに到達し、データが同じ接続を使用して取得されます。

PortBridge を介した通信にはさまざまなコンポーネントが関与するため、サービス バスを直接使用する場合には必要のない VM が余分に必要になります。既に説明したように、この方法で得られるメリットは、TCP エンドポイントの公開の汎用化です。同じ PortBridge エージェント VM を再利用して、別の場所で実行されている複数のデータ ソースに接続できます。これでソリューションのシステム アーキテクチャの紹介は終わりです。ここからは構築の方法について説明します。

RESTful Web サービスを作成する

説明を簡単にするために、SQL Server データベースのテーブルからすべての国の一覧を取得する、Countries という RESTful ASP.NET Web API サービスを設計します。開発プロセスでは、常に、ローカルにビルドおよびテストしてからクラウドに配置することをお勧めします。図 4 は、Countries Web サービスのコードです。

図 4 Countries Web サービス

public class CountriesController : ApiController
{
  private string DatabaseConnectionString { get; set; }
  public CountriesController()
  {
    try
    {
      DatabaseConnectionString =
        ConfigurationManager.
        ConnectionStrings["DatabaseConnectionString"].
        ConnectionString;
      }catch(Exception ex)
      {
        Trace.TraceError(ex.Message);
      }
  }
  // GET: api/Countries
  public IEnumerable<Country> Get()
  {
    return CountryService.GetCountries(DatabaseConnectionString);
  }
  // GET: api/Countries/AD
  public Country Get(string id)
  {
    return CountryService.GetCountry(DatabaseConnectionString, id);
  }
}

この Web サービスにあるメソッドは、Get メソッドと Get(string id) メソッドの 2 つだけです。Get メソッドはデータベースのテーブルからすべての国を取得し、Get(id) メソッドは国コードを指定して Country オブジェクトを 1 つ取得します。図 5 は、ローカルの SQL Server データベースにある Country データベース テーブルを示しています。

Countries Database Table
図 5 Countries データベース テーブル

図 6 に、データベースからデータを取得し Country オブジェクトを返す、CountryService クラスを示します。

データベースと Web サービスの用意したら、F5 キーを押して Visual Studio から Web サービスをローカルにテストします。テストがすべて順調に完了すれば、Web サービスはローカルで機能します。ここで、この Web サービスをクラウドに移行します。ただし、データベースはオンプレミスで実行される他のアプリケーションと共有されているため、このデータベースをクラウドに移行することはできません。このようなシナリオに最適なのが PortBridge です。Web サービスのコード変更を最小限に抑えられ、コードを変更しないで済むこともあります。

図 6 CountryService クラス

public class CountryService
{
  public static IEnumerable<Country> GetCountries(string connectionString)
  {
    IList<Country> countries = new List<Country>();
    using (IDataReader reader = 
      SqlHelper.ExecuteReader(connectionString,
      System.Data.CommandType.Text, "SELECT CountryId, CountryName,
      CountryCode FROM Country"))
    {
      while(reader.Read())
      {
        Country c = new Country()
        {
          CountryId = Convert.ToInt32(reader["CountryId"]),
          CountryCode = Convert.ToString(reader["CountryCode"]),
          CountryName = Convert.ToString(reader["CountryName"]),
        };
        countries.Add(c);
      }
    }
    return countries;
  }
  public static Country GetCountry(string connectionString, 
    string countryCode)
  {
    Country c = new Country();
    using (IDataReader reader = 
      SqlHelper.ExecuteReader(connectionString,
      System.Data.CommandType.Text,
      "SELECT CountryId, CountryName, CountryCode FROM Country WHERE
      CountryCode=@countryCode",
      new SqlParameter("@countryCode", countryCode)))
    {
      if (reader.Read())
      {
        c.CountryId = Convert.ToInt32(reader["CountryId"]);
        c.CountryCode = Convert.ToString(reader["CountryCode"]);
        c.CountryName = Convert.ToString(reader["CountryName"]);
      }
    }
    return c;
  }
}
  [DataContract]
    public class Country
    {
      [DataMember]
      public int CountryId { get; set; }
      [DataMember]
      public string CountryName { get; set; }
      [DataMember]
      public string CountryCode { get; set; }
}

PortBridge をセットアップする

Web サービスをクラウドに移行する前に、PortBridge を構成およびテストする必要があります。アーキテクチャには複数の層が存在するため、最初にすべてのコンポーネントの構成を明確にしておくことが重要です。いつものように、各コンポーネントの入力エンドポイントと出力エンドポイントを一覧にした表を作成します (図 7 参照)。

図 7 エンドポイントと場所

ソリューションのコンポーネント 入力エンドポイント 出力エンドポイント 出力エンドポイント
Countries Web サービス 80   Azure Web Sites
PortBridge エージェント 1433 1433 Azure 仮想マシン
PortBridge 1433 1433 Azure 仮想マシン
SQL Server 1433   Azure 仮想マシン

今回の例ではこの表はそれほど重要ではないように思えるかもしれませんが、多数のエンドポイントを利用するアプリケーションの場合は、このような表があればサービスを適切に構成できます。先ほど説明したように、PortBridge エージェントは VM 内に常駐し、アプリケーションからの入力用と、サービス バス リレー エンドポイントへの出力用の 2 つのエンドポイント インターフェイスを持ちます。同様に、ローカル コンピューターで実行される PortBridge サービスにも、サービス バス リレーからの入力用と、SQL Server データベースへの出力用の 2 つのエンドポイントがあります。構成パラメーターを書き留めたら、配置プロセスを開始します。

サービス バス名前空間を作成する

このソリューションの通信にはサービス バス リレーが不可欠なので、まず、Azure ポータル (manage.windowsazure.com) からサービス バス名前空間を作成します (図 8 参照)。

Creating the Service Bus Namespace
図 8 サービス バス名前空間を作成する

図 8 の countries 名前空間はグローバルに一意な名前空間で、サービスのグローバル一意エンドポイントを作成するために使用します。名前空間を作成したら、ページ下部にある [接続情報] をクリックして、名前空間のアクセス情報を確認します。名前空間にアクセスするには、[既定の発行者] と [既定のキー] を指定する必要があります (図 9 参照)。これらの情報は書き留めておきます。

Service Bus Namespace Credentials
図 9 サービス バス名前空間の資格情報

PortBridge エージェントと PortBridge アプリケーションはどちらも、名前空間に接続するときにこれらの資格情報を必要とします。

PortBridge アプリケーションを構成する

PortBridge アプリケーションには独自の構成セクションがあります。

<portBridge serviceBusNamespace="countries" 
  serviceBusIssuerName="owner"
  serviceBusIssuerSecret="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX">
  <hostMappings>
   <!-- Open HTTP, SQL Server, RDP and ElasticSearch ports-->
     <add targetHost="TREDKAR-W530" allowedPorts="1433" />
  </hostMappings>
</portBridge>

先ほど作成したサービス バス リレー名前空間に接続するには、名前空間、発行者名、およびシークレットが必要です。hostMappings セクションには、ターゲット サービス ホストを一覧します。今回の場合は、ローカル コンピューターと 1433 ポートを指定します。同じホストの複数のエンドポイントを区別するため、ポートをコンマで区切って追加することもできます。PortBridge アプリケーションのコンピューターからアクセスできるのであれば、複数のターゲット ホストを追加することもできます。構成が完了したら、ローカル コンピューターで PortBridge アプリケーションを起動します。すべて想定どおりに進んでいれば、図 10 のような画面が表示されます。

PortBridge Application Running
図 10 実行中の PortBridge アプリケーション

PortBridge アプリケーションは、countries 名前空間のサービス バス リレー サービスへの発信接続を作成します。また、PortBridge/<ターゲット ホスト> という形式で一意名を作成します。<ターゲット ホスト> は、PortBridge アプリケーションの構成ファイルに指定した targetHost パラメーターです (図 11 参照)。

Service Bus Relay Connection
図 11 サービス バス リレー接続

この名前の PortBridge 部分はハードコードされていますが、ターゲット ホストは作成したホストの数に応じて変わります。名前空間内の名前を一意状態に保つには、構成ファイルの hostMappings セクションにターゲット ホストのエントリを 1 つだけ指定する必要があります。また、targetHost パラメーターを適切に構成しないと、作成したエンドポイントを目的のサービスに対応付けることができず、通信が失敗します。

サービス バス リレーのバインドに必要な発信ポートの詳細については、bit.ly/1l8lncx を参照してください。

PortBridge エージェントを構成する

PortBridge アプリケーションと同様、PortBridge エージェントにも独自の構成セクションがあります。

<portBridgeAgent serviceBusNamespace="countries" 
  serviceBusIssuerName="owner"
  serviceBusIssuerSecret=" XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ">
<portMappings>
<port localTcpPort="1433" targetHost="TREDKAR-W530" 
      remoteTcpPort="1433">
<firewallRules>
  <rule source="127.0.0.1"/>
  <rule sourceRangeBegin="208.0.0.0" 
        sourceRangeEnd="208.255.255.255"/>
...
</firewallRules>
</port>
</portMappings>

PortBridge エージェントには、portMappings セクションがあります。このセクションでは、各入力エンドポイントのポート (localTcpPort) をサービス バス リレーのエンドポイントのポート (remoteTcpPort) にマップします。ターゲット ホストの値は、先ほど PortBridge アプリケーション構成で作成したターゲット ホストの値に一致する必要があります。この値は、適切なサービス バス名前空間のエンドポイントに接続するために使用します。これら 2 つの値が一致しないと、アプリケーションは機能しません。

firewallRules セクションでは、PortBridge エージェントが要求を受け取るコンピューターの IP アドレスを明示的に一覧します。今回の PortBridge エージェントは Azure Web Sites から要求を受け取るため、Azure データセンターの IP アドレスの範囲をファイアウォールの規則に追加する必要があります。Azure データセンターの IP アドレスの範囲は、bit.ly/1l8yDxV (英語) からダウンロードできます。

PortBridge エージェントを Azure に配置するには、Azure ポータルに移動し、新しい Windows VM を作成して、PortBridge エージェント ファイルをコピーし、PortBridgeAgent.exe を実行します。VM の作成時には、Azure Web Sites で PortBridge エージェント VM のポートにアクセスできるように、1433 エンドポイントを外部アクセス用に開きます。

PortBridge エージェントを配置するもう 1 つの方法では、Apps for Azure を使用します。これにより、Windows ストア アプリを簡単に配置できます。Apps for Azure は、すぐに配置できるようにあらかじめパッケージ化された VM を含む、無料のアプリケーションです。また、Apps for Azure には、あらかじめパッケージ化された PortBridge VM も用意されています (図 12 参照)。Apps for Azure は appsforazure.com (英語) からインストールできます。

Apps for Azure for Deploying the PortBridge Agent
図 12 PortBridge エージェントを配置するための Apps for Azure

あらかじめパッケージ化された PortBridge エージェント VM は、既定で 1433 および 80 エンドポイント ポートを開いて通信します。PortBridge エージェントを独自に構成する場合は、C:\ddapplications フォルダーの PortBridgeAgent.exe.config ファイルを変更する必要があります。ファイルの構成後、Dynamic­DeployInitService Windows サービスを再起動します。

Countries Web サービスをテストおよび配置する

PortBridge コンポーネントをインストールして実行したら、Web サービスのデータベース接続文字列を変更して、PortBridge エージェント VM を指すようにします。

<add name="DatabaseConnectionString"
  connectionString=
  "Server=tejaswisvm1.cloudapp.net;
  Database=cf10292013;
  Trusted_Connection=True;"/>

ホスト名を除き、他のパラメーターはすべてそのままにします。この構成変更により、データベースを直接指定するのではなく、PortBridge エージェント VM を指定するようになります。次に、Countries Web API サービスを Azure Web Sites に公開し、次の URI に移動してサービスをテストします。

  1. http://<Azure Web Sites ホスト>/api/Countries (すべての国を取得する場合)。
  2. http://<Azure Web Sites ホスト>/api/Countries/<国コード> (国コードで特定の国を取得する場合)。

エンド ツー エンドの通信が機能していると、メソッドの呼び出しに対して両方の URI から JSON オブジェクトが返されます。これで、すべてのデバイスで Countries Web サービスを呼び出すことができるようになります。呼び出しは、Azure Web Sites から PortBridge エージェントに渡され、PortBridge アプリケーションを経由して SQL Server データベースが受け取ります。ローカル コンピューター (データセンター) で実行されているデータベースからデータが取得されます。

パフォーマンスに関する考慮事項

PortBridge は間接層なので、データベースへの直接通信や仮想ネットワークのハイブリッド接続などを含むアーキテクチャと比べて、遅延が生じる原因になります。そのため、PortBridge は、仮想ネットワークや直接通信を実現できないシナリオでのみ使用することをお勧めします。この記事の執筆時点では、Azure Web Sites が仮想ネットワークをサポートしていないため、ハイブリッド接続を構築するにはサービス バスを使用するしかありません。テスト中、Countries Web サービスで 50 ～ 300 ミリ秒の遅延が確認されました。シナリオによっては、クラウドでデータをキャッシュし、リモート データセンターで実行されているサービスには一定の間隔でアクセスするだけにとどめることをお勧めします。

セキュリティに関する考慮事項

PortBridge は、サービス バス リレーのセキュリティ機能に依存しています。PortBridge では既定で接続セキュリティを使用して、サービス バス名前空間に接続しますが、トランスポート機能やメッセージの暗号化機能は使用しません。PortBridge エージェントにはカスタム IP アドレスのフィルター メカニズムが用意されていますが、Azure サービス バスに組み込みのセキュリティ メカニズムほど堅牢ではないと考えられます。ソリューションを運用環境に配置する前に、詳細な脅威モデリングを実行することをお勧めします。

PortBridge をスケールアウトする

図 3 のアーキテクチャから、PortBridge エージェントが単一障害点になる可能性があることがわかります。ただし、負荷分散エンドポイントを VM に追加し、PortBridge エージェント VM の複数のインスタンスを作成することで、PortBridge エージェントをスケールアウトすることができます。これにより、Azure Web Sites からの呼び出しは、複数の PortBridge エージェント間で負荷分散されます。PortBridge エージェントをスケールアウトすることは可能ですが、最終的な送信先のエンドポイント (データベース) をこのスケールアウトに対応するように設計する必要があります。Web や中間層をスケールアウトしたくないかもしれませんが、これが原因でデータ層で問題が発生します。どのような状況でも柔軟に対応できる設計をお勧めします。

PortBridge の実例

過去数年の間に、お客様からのいくつかのご要望にお応えして、チームはクラウドにサードパーティのアプリケーションと Azure サービスを統合するためのメッセージング ハブをビルドしました。これは、異なるデータ ソースからデータを収集するための簡単なプラグ アンド プレイ モデルを作成し、集計されたデータをエンド ユーザーのさまざまなサイズのデバイスに表示することを目標としていました。チームは、このプラグ アンド プレイ モデルを作成するための基盤として、PortBridge を使用することにしました。PortBridge は、WCF 以外のサービスを Azure で実行しているアプリケーションに接続するために必要な抽象化を実現することができます。チームはより優れた診断機能、パフォーマンス、キャッシュを求めて、PortBridge コードを変更しました。実装に成功したシナリオをいくつか紹介します。

  1. Fortune 50 社の異なる 19 個のデータ ソースをまとめた統合メッセージング サービスを作成し、顧客の現場スタッフに業務に関するコンテキスト データのマッシュアップを提供しました。現場で必要な情報にすばやくアクセスできるようにすることが、このソリューションの主な目標でした。
  2. 商用車の在庫管理に使用する何千ものアプリケーション インスタンスからデータを取得し、クラウドの中央データ リポジトリにデータを格納しました。取得したデータは、メンテナンス時期の予測や購買者の行動調査に使用されました。サービス バス (PortBridge) を使用しないと、このようなアプリケーションには 10 倍ものコストと労力が費やされることになります。
  3. 何千人もの弁護士がどこでも自分のモバイル デバイスを使用して、訴訟に関する情報を確認したり、タイムシートを管理できるようにしました。このアプリケーションが提供される前、弁護士は裁判が終わった後、勤務時間を記録するために職場に戻る必要がありましたが、モバイル アプリケーションを使用して、裁判所で直接勤務時間を記録できるようになりました。

まとめ

Azure Web Sites とサービス バスは、ハイブリッド Web アプリケーションのビルドにおいて、相互に補完する関係にあります。PortBridge は、サービス バス リレーを基盤とする抽象層で、WCF 以外のエンドポイントをクラウドに効率的に公開します。これまで、異なる場所で実行されている複数の Web サービスからデータを取得する、集計マッシュアップ Web サイトのビルドを必要とするシナリオにいくつか携わってきました。PortBridge を使用すると、元のアプリケーション コードに大幅な変更を加えることなく、このようなアプリケーションを設計、テスト、およびビルドすることができました。最初の PortBridge 構成をテストしたら、サービス バスと Web サービスが利用できる限り、接続は常に機能します。PortBridge を使用するとハイブリッド アプリケーションを簡単に構築できますが、サービスの呼び出しに遅延が発生することに注意してください。すぐに応答が必要なアプリケーションの場合は、PortBridge の使用はお勧めしません。Azure 仮想ネットワークの使用を検討するか、オンプレミスのサービスをクラウドに移行してください。今回紹介したソリューションを理解すると、オンプレミスのエンドポイントを Azure に移行し、Azure Web Sites から呼び出す方法が簡単に感じられるでしょう。PortBridge と関連する Countries Web サービスのソース コードは、GitHub (github.com/dynamicdeploy/portbridge、英語) で入手できます。

Tejaswi Redkar は、執筆者兼ソフトウェア開発者です。現在は、マイクロソフトのアプリケーション プラットフォーム戦略およびコミュニティのディレクターとして働いています。彼の著書『Windows Azure Web Sites: Building Web Apps at a Rapid Pace』(Dynamic Deploy LLC、2013 年) は、このトピックに関する最も総合的な内容の書籍としてベストセラーになっています。Redkar は、appsforazure.com (英語) と dynamicdeploy.com (英語) の作成者でもあります。彼は、これらのページで、クラウドで運用中のアプリケーションを身をもって体験しています。連絡先は、tejaswi_redkar@hotmail.com (英語のみ) です。Twitter は twitter.com/tejaswiredkar (英語) でフォローできます。

この記事のレビューに協力してくれた Microsoft Azure 製品管理チームの技術スタッフに心より感謝いたします。