Azure Service Bus Relayは、インターネットに接続する消費者に対して内部ネットワーク上のWebサービスを公開する機能を備えているが、そこに魅力を感じた開発者がそのようなサービスを構築する方法は、最近までWindows Communication Foundation（WCF）ただ1つだけだった。 Azure Relayハイブリッド接続と呼ばれるパブリックプレビューになったばかりの機能を使用すると、開発者はWebSocketに親和性のあるプラットフォームなら何を使用していても、このクラウドベースのブローカーにローカルサービスを接続できるようになった。
Azure Relayは、Azureが提供するエンドポイントに送信された要求を、Azureに接続されているリモートサービスに双方向ソケットを介してリレーする。リレー接続はホスト側で開始され、トラフィックは従来のWebポート経由で流れるため、通常、ファイアウォールの変更や内部ネットワークインフラストラクチャの更新などは一切必要ない。これまでこの機能を利用できたのは、WCF、.NET、およびWindowsを使用する開発者だけだった。AzureメッセージングのリードアーキテクトであるClemens Vastersが、最近のブログ記事で、任意のプラットフォームでAzure Relayを使用できる、ハイブリッド接続と呼ばれる新しいオープンプロトコル機能を発表した。
Azure Relayの進化形であるハイブリッド接続は、HTTPSとWebSocketに完全に基づいており、オンプレミス環境のファイアウォール内にあるリソースとサービスを、クラウドのサービスや、どこに置かれたどんな資産に対してでも安全に接続できる。
WebSocketプロトコルに基いた、特定のフレームワークの特殊性に左右されない安全な双方向のバイナリ通信チャネルを提供したことで、Apache Thrift、Apache Avro、Microsoft Bondなど、さまざまな既存あるいは現代的なRPCフレームワークを容易に統合することが可能になった。
マイクロソフトの最新ドキュメントによると、Azure Relayを使用する開発者は、単なるパススルー・ブローカー以上のものを手に入れることができる。その他の機能には、“TCPのようなスロットル、エンドポイント検出、接続ステータス、およびオーバーレイ・エンドポイントセキュリティ”が含まれている。マイクロソフトの指摘によれば、Azure Relayは単一のアプリケーションエンドポイントを対象とすることができ、侵入型のネットワーク変更が必要ないという点で従来のVPNベースのソリューションとは異なっている。
WCF由来の機能を使っているユーザーはサポートや機能の変更が発生しない。言い換えれば、Azure Relayは従来のWCF Relayと呼ばれる機能とハイブリッド接続の両方をサポートするようになった。 製品ドキュメントにある比較表では、ハイブリッド接続とWCF Relayとの違いは、Javascript/Node.js、Java、標準ベースのオープンプロトコル、および複数のRPCプログラミングモデルをサポートしている点であるとMicrosoftは指摘している。プロトコル自体は、listen、accept、renew、およびpingという4種類の“受信側”インタラクションと、connectという1種類の“送信側”インタラクションで構成される。すべての通信はポート443上のWebソケットを使用して行われる。
WCF Relayまたはハイブリッド接続のどちらを使用しているかによって価格が異なる。ハイブリッド接続の場合、ユーザーはリスナーあたり、および（1か月に5GBを超えた場合）転送されたGBあたりの“接続料”を支払う。WCF Relayユーザーは、“リレー時間”（各リレーが開いている時間）および10,000メッセージあたりの料金を支払う。 Azure Relayは、特定のリレーに対する多数の同時リスナーのために設計されておらず、モバイルデバイスのブロードキャストのようなものに対する選択肢では必ずしもない。しかし、このサービスには、1つのリレーで25人の同時リスナー（リスナー間のトラフィック負荷分散を行う）、ひと月に50億メッセージ、ひと月に200万リレー時間などの正常性クォータがある。
このパブリックプレビューの一環として、Microsoftは一対のハイブリッド接続サンプルを共有した。.NETサンプルはNugetに配布されたプレビューパッケージ（Microsoft.Azure.Relay）を使用していた。 Node.jsサンプルは、Javascript開発者のための接続を簡素化する新しいnpmパッケージ（hyco-ws）を利用している。
このリリースの詳細について、InfoQはClemens Vastersに簡単なインタビューを行った。
InfoQ：Service Bus Relayの最初のバージョンは2010年に出荷された。WCFとWindowsの依存関係を取り除くのに時間がかかったのはなぜか。最近まで、クロスプラットフォームサービスの需要は高くなかったのか。
Vasters：最初のバージョンは2010年1月に出荷されたが、Relayはそのさらに3年前からインキュベーションされていた。 WCFに依存していた元々の理由は、WCFが出荷されようとしていたときに、WCFチームの2人によるサイドプロジェクトとしてRelayが開始されたためだった。 APIとプロトコル境界面は長年にわたってかなり安定していたが、最初のリリース以降、見えないところで多くの作業をした。このサービスは、さまざまな顧客のネットワーク環境で動作させるのが、外部の人が考えるよりもかなり難しい。プロトコル境界面は非常に安定しており、2010年に出荷されたオリジナルの1.0クライアントアセンブリをまだ使用していた顧客が最近見つかったほどだ。クロスプラットフォーム版Relayの需要は何年も継続的に増加していたが、それは今になって、私たちの忙しいバックログに場所を確保するところまで達した。一方、この同じチームは、キュー/トピック メッセージングブローカー、イベントハブ、通知ハブを作成して出荷し、IoTハブの初期作業を主導した。現在運用しているクラウドアセットは、1か月あたり数兆件ものメッセージ転送トランザクションと数ペタバイトもの転送量という負荷を記録した。私たちは忙しかった。
InfoQ：Azureリレーの理想的なユースケースは何と考えているか。
Vasters：Relayは、これまでもそして今なお、顧客が見出すユースケースの点で非常に驚かされる。Relayは、個別に解決するのが難しいネットワーク通信の問題の組み合わせに対する解決策を提供する。まず、インターネットへの（または単にAzureへの）アウトバウンドネットワーク接続を持つ任意のアプリケーションまたはマシンに対し、インバウンドアプリケーション層接続を提供する。つまり、ほとんどの場所で、たとえ自身が管理していないネットワーク環境であっても、接続を受け付けるサーバーをホストできる。第2に、Relayはそのサーバの位置を隠し、インターネット上には非公開のままにする。ホストをシャットダウンすれば、誰かが覚えておいて後で使うことができるIPアドレスやポートはなくなる。第3に、Relayは、エンドポイント単位のDNS管理を必要とせずに、そのサーバーの安定したネットワーク解決可能な名前を提供する。第4に、Relayを使用すると、既存のエンドポイントおよびARMの状態をプログラムで検出できる。第5に、Relayは接続された複数のサーバー間で自動負荷分散を提供する。そして最後に、Relayは追加のクライアント認可境界を提供し、証明書をやりとりするサーバーなしにすべての通信がTLSで保護されるようにする。
理想的なユースケースは何か？ ソケット上で実行されるトラフィックのポイント・トゥ・ポイント・ブリッジングが必要なすべてのシナリオだ。 データベース、リモートデスクトップ、シェル、RPC。サイト・トゥ・サイトで利用する場合は両者がファイアウォールの背後にあるかもしれないし、クラウド・トゥ・サイトで利用する場合はどちらか一方だけかもしれない。Relayを経由して印刷するビジネスプリンタもある。Relayを経由して接続されるPOSマシンもある。Relayを経由してクラウドに接続するオンプレミスデータベースとCRMシステムもある。今日では人々のやることはさまざまであり、新しいバージョンはその利用範囲を劇的に拡大することが期待される。
新たに登場するシナリオはコンテナワークロードの相互接続で、Relayは今挙げたすべての機能を提供するため、ほぼ完璧なネットワーキングツールとなる。
InfoQ：時間の経過とともにアーキテクチャはどのように変化したか。サービス自体の顧客側インターフェイスはかなり静的まま維持されているが、内部配管は長年にわたり進化しているのか。
Vasters：人々が部分的なデータから結論を導こうとするのがわかっているため、サービス内部について多くのことを話すつもりはない。しかしその通りで、最初の3年間で、サービスには非常に定期的な更新と少なくとも2つの実質的な書き換えが行われてきた。よく忘れられがちなのだが、ハイパースケールのクラウドプラットフォームサービスを構築することは新しい技能であり、パフォーマンス、最大の信頼性、およびコスト効率の最適なバランスを保って構築することは非常に難しい。我々が行った再構築が表面化しなかったのは、我々が特別なな労力、時には一カ月程度の開発時間をかけて、システムが負荷の下、SLAを維持しながらスムーズに次バージョンへアップグレードできるようにしたためだ。アップグレードと言うのが実際は異なるアーキテクチャをもつ全く異なるマシン群への移行を意味しているとしてもだ。
新しいRelayハイブリッド接続は、相当な追加機能ではあるが、既存の実績ある部品を多くベースにして構築されており、WCF Relayと併せてデプロイされている。つまり、ハイブリッド・コネクションはパブリックプレビューの初日から世界中のすべての場所でデプロイされているということだ。Relayの内部バックプレーンは、長い間、当社のコアAMQPスタックとサービスファブリックに基づいており、WCFへの依存が残っていない。WCF Relayとハイブリッド接続は、同じ基盤上に共存するようになった。
InfoQ：Azure Relayのような分散型メッセージングソリューションのユーザーは、チャネルの可用性やモニタリングなどにどうアプローチすればよいか。キュー/トピックのソリューションに切り替えることを顧客に奨励することがあるか。
Vasters：キューとトピックは、メッセージングの機能セットがRelayと比べて大きく異なる。Relayは、接続状態を可能にすることと、通信相手を見つけることに関するものだ。キューとトピックは疎結合に関するものであり、すべての通信相手が同時に利用可能である必要はなく、出版側は誰が購読しているのかを知ることもできない。これらの2つのサービスは通信スペクトルの異なる終点に対応しているが、Relayの領域は非常にエキサイティングで、掘り下げる余地が非常に大きいと感じている。
モニタリングに関しては、Azureポータルの中に継続して改良中のツールセットがあり、Relay、キュー/トピック、イベントハブの大幅な改良が追加されたばかりだ。これらのデータはすべてプログラムによるアクセスからも利用できる。Service Busのモニタリングに役立つサードパーティのソリューションでこの公開APIを使用しているものもある。
InfoQ：驚くべきことに、幾年かを経た今でも、Azure Relayは業界的に非常にユニークな製品だ。なぜだと考えるか。
Vasters：この領域には同様のソリューションがいくつかあるが、Azureはメジャーなクラウドとしてそのようなサービスを備えている本当に唯一の存在だ。ハイブリッド接続は純粋なWebSocket機能として提供されたため、WebSocketスタックを持っている任意のプラットフォームと任意のデバイスで簡単に動作させることができる。そしてハイブリッド接続は、瞬く間にこの種のサービス全体における最大規模のものとなった。なぜなら、世界中のすべてのAzureデータセンターに置かれ、すでに何百万もの接続を提供している既存のすべてのRelayクラスタで利用されるからである。
他の大きなクラウドにそのようなサービスがない理由については、私から答えを出すのは難しい。実際に一つ技術的な理由があるとすれば、HTTP上でステートフルな接続サービスを動かすというアーキテクチャ上の強力な賭けをすることは、一部の競合他社が持つインフラストラクチャ上では困難なのかもしれない。CloudFoundryは、今年はプレーンなTCPルーティング機能しか達成しなかった。我々は同様の強みをIoT製品やメッセージングでも持っていると見ている。我々はエンタープライズ級のマルチプロトコルAMQP/HTTPクラウドブローカーを最大規模で運用しているが、他社のサービスとは全く異なる。AWS SQSは機能のほんの一部しか備えておらず、サポートするHTTP接続は効率が大幅に低い。大規模下でも効率的なプロトコルを備えたメッセージングミドルウェアは難しいものだ。
InfoQ：このサービスがより多くのユーザーに開放されるようになった今、このサービスの使われ方について仮説はあるか。既存製品との統合で興味があるものはあるか。
Vasters：Relayのプロトコルは、基本的にはWebSocket上のわずか5つのプロトコルジェスチャーである。プロトコルをオープン化し、我々がしたように簡単にすることで、顧客とコミュニティにとって多くの機会が開かれると考えている。Relayの取り込みは、価格モデルがどのように進化し続けるかにも直接影響を与える。価格モデルは明らかに採用と統合の一要因である。WCF Relayについて言えば、ほんの2~3個の接続を運用しているが、その接続が可能にしている機能を構築するには莫大な金額を払う必要があっただろう顧客がおり、彼らは支払いの少なさに唖然としている。同時に、極端な数の接続やリスナーを必要とする顧客もおり、彼らが他の選択肢について相談しに来ることはめったにない。我々の想定では、プレミアムメッセージングや専用のイベントハブで提供されるものと同様に、専用のRelayサービスが提供される予定だ。
既存の製品との統合に関しては、ソケットやストリームに依存するものとの統合には何であれ興味がある。我々自身では、言語ランタイムとプロトコルスタックとの統合を提供するためのいくつかの作業をやっている。そこには、統合を素晴らしいものにするための、長い長いソフトウェアバックログがある。データベース、OpenSSH、リモートデスクトップ、RPCフレームワーク、センサーデータストリーミングなど、既存のフレームワークや製品にも、ネットワーク境界を無くすこの技術のシームレスな統合により大きな利益を得ることができるものがたくさんあるように思う。
前述の通り、コンテナ化されたワークロードは、複数のNAT層の背後にあることが多く、安全なネットワーク管理が急にとても複雑になることがある。それらの大きな痛みをRelayで緩和することができる。我々はその領域に多くの可能性を感じている。