Azure Relay に関する FAQ

この記事では、Azure Relay についてよく寄せられる質問とその回答を紹介します。 Azure の価格およびサポートに関する一般的な情報については、「Azure サポートに関する FAQ」を参照してください。

注意

Azure を操作するには、Azure Az PowerShell モジュールを使用することをお勧めします。 作業を開始するには、Azure PowerShell のインストールに関する記事を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。

一般的な質問

Azure Relay とは

ハイブリッド アプリケーションに Azure Relay サービスを使用すると、企業のエンタープライズ ネットワーク内部にあるサービスをパブリック クラウドに安全に公開することができます。 サービスを公開するにあたって、ファイアウォール接続を開いたり、企業ネットワークのインフラストラクチャへの大幅な変更を要求したりする必要はありません。

Relay 名前空間とは何ですか?

名前空間とは、アプリケーション内で Relay リソースをアドレス指定するために使用できるスコープ コンテナーです。 Relay を使用するには、名前空間を作成する必要があります。 これは、最初に実行する手順の 1 つです。

Service Bus Relay サービスはどうなりましたか?

以前は Service Bus Relay サービスという名称でしたが、現在では Azure Relay と呼ばれています。 このサービスは、これまでと同じように引き続き使用できます。 ハイブリッド接続機能は、Azure BizTalk Services から移植されたサービスの更新バージョンです。 WCF リレーとハイブリッド接続はどちらもサポートが継続されます。

価格

このセクションでは、Relay の価格体系についてよく寄せられる質問とその回答を紹介します。 Azure の価格に関する一般的な情報については、「Azure サポートに関する FAQ」も参照してください。 Relay の価格の詳細については、Service Bus の価格の詳細に関するページを参照してください。

ハイブリッド接続と WCF リレーの課金方法を教えてください。

Relay の価格の詳細については、Service Bus の価格の詳細ページで、ハイブリッド接続と WCF リレーの表をご覧ください。 このページで説明されている価格に加え、ご利用のアプリケーションがプロビジョニングされているデータ センターから外部に送信される関連データ転送にも料金が発生します。

Relay では、時間はどのように計算されますか?

WCF リレーは、Standard レベルの名前空間でのみ使用できます。 それ以外については、リレーの価格と接続クォータは変更されていません。 つまり、リレーは、引き続き (操作ではなく) メッセージの数およびリレー時間に基づいて課金されます。 詳細については、価格の詳細に関するページで "ハイブリッド接続と WCF Relay" の表をご覧ください。

特定のリレーに複数のリスナーを接続した場合はどうなりますか?

場合によっては、1 つのリレーに多数のリスナーが接続されます。 リレーは、接続されているリレー リスナーが 1 つでもあれば、開いていると見なされます。 開いているリレーにリスナーを追加すると、追加のリレー時間が発生します。 また、リレーに接続されたリレー センダー (リレーに対するメッセージの呼び出しまたは送信を実行するクライアント) の数は、リレー時間の計算には影響しません。

WCF Relay の場合、メッセージのメーターはどのようにして計算されますか?

(これは、WCF リレーにのみ該当します。メッセージはハイブリッド接続では課金されません。)

一般に、リレーの場合も、前述した仲介型エンティティ (キュー、トピック、サブスクリプション) と同じ方法で、課金対象のメッセージが計算されます。 ただし、注目すべき違いがいくつかあります。

Azure Relay へのメッセージ送信は、そのメッセージを受信するリレー リスナーに対する "直接の" 送信として扱われます。 リレー リスナーに配信する前に行われる Azure Relay への送信操作のようには扱われません。 リレー リスナーに対する (最大 64 KB の) 要求/応答形式のサービス呼び出しの場合、課金対象のメッセージは、要求の課金対象メッセージと応答の課金対象メッセージ (応答も 64 KB 以下を想定) の 2 つになります。 これは、クライアントとサービスの間の仲介にキューを使用した場合とは異なります。 クライアントとサービスの間の仲介にキューを使用する場合は、同じ要求/応答パターンでも、キューに対する要求の送信、そのキューからサービスへのデキュー/配信の順番で実行する必要があります。 この後さらに、別のキューへの応答の送信、そのキューからクライアントへのデキュー/配信の順番で実行する必要があります。 メッセージのサイズが最初から最後まで同じ (64 KB 以下) であると仮定した場合、仲介型キュー パターンでは課金対象のメッセージは 4 つとなります。 Relay を使って同じパターンを実装した場合と比べてメッセージ数が 2 倍となり、それに対する料金が課金されることになります。 もちろん、キューを使用してこのパターンを実現すれば、持続性や負荷平準化などの利点が生まれます。 これらは追加費用に見合う可能性のある利点です。

netTCPRelay WCF バインドを使って開いたリレーでは、メッセージは個別のメッセージではなく、システムを流れるデータ ストリームとして扱われます。 このバインドを使用すると、センダーとリスナーだけが、送受信された個々のメッセージを 1 つのまとまりとして認識できます。 netTCPRelay バインドを使ったリレーの場合、課金対象のメッセージ数を計算するために、すべてのデータがストリームとして扱われます。 この場合、Service Bus は、個々のリレーを介して送受信されたデータ量の合計を 5 分ごとに計算します。 次に、データ量の合計を 64 KB で除算して、その期間内でのリレーについて、課金対象のメッセージ数を決定します。

売上予算

クォータ名 Scope メモ
Azure サブスクリプションごとのリレーの名前空間 Azure サブスクリプション - 1000
リレーの同時リスナー エンティティ (ハイブリッド接続または WCF リレー) 追加の接続に関する後続の要求は拒否され、呼び出し元のコードが例外を受け取ります。 25
あるサービス名前空間に含まれるリレー エンドポイント全部の同時リレー接続 名前空間 - 5,000
サービス名前空間ごとのリレー エンドポイント 名前空間 - 10,000
NetOnewayRelayBindingNetEventRelayBinding リレーのメッセージ サイズ 名前空間 これらのクォータを超える受信メッセージは拒否され、呼び出し元のコードが例外を受け取ります。 64 KB
HttpRelayTransportBindingElementNetTcpRelayBinding リレーのメッセージ サイズ 名前空間 メッセージ サイズに制限はありません。 無制限

Relay に使用量クォータはありますか?

既定では、Microsoft はすべてのクラウド サービスに関し、お客様のサブスクリプション全体で算出する月単位の総使用量クォータを設定しています。 Microsoft では、実際のニーズがこれらの制限を上回る可能性があることを認識しています。 お気軽にカスタマー サービスまでお問い合わせください。お客様のニーズを確認のうえ、適宜制限を調整させていただきます。 Service Bus の総使用量クォータは次のとおりです。

  • 50 億メッセージ
  • 200 万リレー時間

Microsoft は、月ごとの使用量クォータを超えた場合にお客様のアカウントを無効にする権利を保有しています。ただし、その場合は電子メールでお客様にその旨をお知らせし、何度かお客様に連絡を試みたうえで、措置を講じることといたします。 そのクォータを超えたお客様についても、超過分は課金の対象となります。

名前に関する制限

Relay 名前空間名の長さは 6 ~ 50 文字である必要があります。

サブスクリプションと名前空間の管理

別の Azure サブスクリプションに名前空間を移行する方法を教えてください

ある Azure サブスクリプションから別のサブスクリプションに名前空間を移行する場合は、Azure Portal または PowerShell コマンドを使用することができます。 名前空間を別のサブスクリプションに移行するには、名前空間が既にアクティブになっている必要があります。 コマンドを実行するユーザーは、ソースとターゲットの両方のサブスクリプションの管理者ユーザーである必要があります。

Azure Portal

Azure Portal を使用して、あるサブスクリプションから別のサブスクリプションに Azure Relay 名前空間を移行する方法については、新しいリソース グループまたはサブスクリプションへのリソースの移動に関する記事を参照してください。

PowerShell

PowerShell を使用して、ある Azure サブスクリプションから別のサブスクリプションに名前空間を移行するには、次の一連のコマンドを使用します。 この操作を実行するには、名前空間が既にアクティブになっており、PowerShell コマンドを実行するユーザーが、ソースとターゲットの両方のサブスクリプションの管理者である必要があります。

# Create a new resource group in the target subscription.
Select-AzSubscription -SubscriptionId 'ffffffff-ffff-ffff-ffff-ffffffffffff'
New-AzResourceGroup -Name 'targetRG' -Location 'East US'

# Move the namespace from the source subscription to the target subscription.
Select-AzSubscription -SubscriptionId 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa'
$res = Find-AzResource -ResourceNameContains <NAMESPACE NAME> -ResourceType 'Microsoft.ServiceBus/namespaces'
Move-AzResource -DestinationResourceGroupName 'targetRG' -DestinationSubscriptionId 'ffffffff-ffff-ffff-ffff-ffffffffffff' -ResourceId $res.ResourceId

トラブルシューティング

Azure Relay API によって生成されるいくつかの例外と、それを解決するための推奨されるアクションを教えてください。

一般的な例外と、それを解決するための推奨されるアクションの説明については、Relay の例外に関する記事を参照してください。

Shared Access Signature とは何ですか? また、どの言語で署名を生成できますか?

Shared Access Signature (SAS) は、SHA-256 セキュア ハッシュまたは URI に基づいた認証メカニズムです。 Node.js、PHP、Python、Java、C、C# で独自の署名を生成する方法については、「Shared Access Signature による Service Bus の認証」を参照してください。

一部のリレー エンドポイントのみを許可することはできますか?

はい。 リレー クライアントは、完全修飾ドメイン名を使用して Azure Relay サービスへの接続を確立します。 お客様は、DNS 承認一覧をサポートするファイアウォールで、*.servicebus.windows.net のエントリを追加できます。 また、your-namespace-name.servicebus.windows.net を使用して、特定の名前空間を許可リストに登録することもできます。 この場合、名前空間のゲートウェイも許可リストに登録する必要があります。これは、この PowerShell スクリプトを使用すると見つかります。