エクスポート (0) 印刷
すべて展開

Service Bus の料金に関する FAQ

更新日: 2014年10月

Microsoft Azure の Service Bus の料金体系についてご不明な点がある場合は、以下のセクションの FAQ を参照してください。 の料金全般に関する情報については、Azure Platform の料金に関する FAQ も参照してください。Service Bus の料金の詳細については、「Service Bus の料金詳細」を参照してください。

noteメモ
Service Bus Event Hub の料金については、「Event Hubs プレビューの可用性とサポート」に説明が記載されています。

以下のメーターに基づいて課金されます。

  1. メッセージ: Service Bus に送信されたメッセージと Service Bus から配信されたメッセージは、10,000 メッセージあたり $0.01 で課金されます。課金対象月に、Service Bus に送信されたメッセージと Service Bus から配信されたメッセージの数に基づいて料金が発生します。これには、空のキュー/サブスクリプションに対する受信要求への応答として配信される "null" メッセージも含まれます。サイズが 64 KB を超えるメッセージは、64 KB 分のデータごとに追加のメッセージとして課金されます (切り上げ)。このメーターは、リレーのほか、キュー、トピック、サブスクリプションにも適用されます。

  2. リレー時間: このメーターが適用されるのは、Service Bus のリレー機能を使用している場合だけです。使用しているのが Service Bus のキュー、トピック、サブスクリプションのみの場合、リレー時間の料金は発生しません。リレー時間は 100 リレー時間につき $0.10 が課金され、リレーを開いた (最初のリスナーが特定のリレー アドレスに接続した) 時刻からリレーを閉じた (最後のリスナーがリレーのアドレスから切断した) 時刻までが対象となります (1 時間単位で切り上げ)。

Service Bus の料金の詳細情報については、「Service Bus の料金詳細」を参照してください。既に説明した Service Bus の料金に加え、ご利用のアプリケーションがプロビジョニングされているデータ センターから外部に送信される関連データ転送の料金が発生します。詳細については、以下の「Service Bus でデータ転送の対象となる用途と対象外の用途を教えてください」を参照してください。

特定の リージョンの範囲内のデータ転送はすべて無料です。リージョンの範囲を超えるデータ転送は、北米リージョンと欧州リージョンからの送信は 1 GB につき $0.15、アジア太平洋リージョンからの送信は 1 GB につき $0.20 の送信料がかかります。受信データ転送はすべて無料です。

リレーは、クライアントと Web サービスとの間でメッセージを中継する Service Bus エンティティです。Web サービスはリレーを介して、永続性のある検出可能な Service Bus アドレスを確保すると共に、ファイアウォール/NATトラバーサル機能との信頼性の高い接続を利用したり、各種機能 (自動負荷分散など) を利用したりすることができます。リレー対応の WCF サービス (リレー リスナー) が特定の Service Bus アドレス (名前空間の URL) に初めて接続すると、都度そのアドレスでリレーが暗黙的にインスタンス化されて開かれます。リレー リスナーは、標準的な WCF バインドの、リレーに対応した特殊な形態である Service Bus .NET マネージ API を使用してアプリケーションが作成します。

特定の課金期間中、各 Service Bus リレーが "開いて" いた累積時間がリレー時間として課金されます。リレー対応の WCF サービス (リレー リスナー) が特定の Service Bus アドレス (サービスの名前空間の URL) に初めて接続するたびに、そのアドレスでリレーが暗黙的にインスタンス化されて開かれます。リレーが閉じられるのは、最後のリスナーがそのアドレスから切断されたときだけです。したがって課金の目的上、最初のリレー リスナーが接続した時刻から最後のリレー リスナーがそのリレーの Service Bus アドレスから切断した時刻まで、リレーは "開いた状態" と見なされます。言い換えると、Service Bus アドレスに接続されているリレー リスナーが 1 つでもあれば、リレーは "開いた状態" と見なされます。

場合によっては、Service Bus 内の 1 つのリレーに複数のリスナーが接続されることも考えられます。たとえば、netTCPRelay または *HttpRelay WCF バインドを使用する負荷分散サービスや、netEventRelay WCF バインドを使用するブロードキャスト イベント リスナーがこれに該当します。接続されているリレー リスナーが 1 つでもあれば、Service Bus のリレーは "開いた状態" と見なされます。開いているリレーにリスナーを追加しても、課金の目的上、そのリレーの状態は変化しません。リレーに接続されたリレー センダー (リレーを呼び出すクライアントまたはリレーにメッセージを送信するクライアント) の数がリレー時間の計算に影響することもありません。

Service Bus では、接続に対する課金は廃止されました。ただし、1 つの Service Bus エンティティに対して開くことのできる同時接続数を制限するクォータは存在します。以下の「Service Bus に使用量クォータはありますか」を参照してください。

Service Bus に送信された各メッセージと Service Bus から配信された各メッセージが課金対象のメッセージとしてカウントされます。これは、キュー、トピック/サブスクリプション、リレーなど、Service Bus のすべてのエンティティ タイプに適用されます。

メッセージの定義は、サイズ 64 KB 以下のデータのまとまりです。仲介型のエンティティ (キューおよびトピック/サブスクリプション) の場合、サイズ 64 KB 以下のメッセージが、1 つの課金対象メッセージと見なされます。サイズが 64 KB を超えるメッセージについては、64 KB の倍数単位で課金対象メッセージの数が計算されます。たとえば、Service Bus に送信された 8 KB のメッセージは 1 つのメッセージとして課金されます。一方、Service Bus に送信された 96 KB のメッセージは、2 つのメッセージとして課金されます。ほとんどの場合、リレーにも、課金対象メッセージの判別に同じ方法が適用されます。リレーの例外の詳細については、「リレーの場合、メッセージ数メーターはどのようにして計算されるのですか」を参照してください。

同じメッセージが複数回配信されるケース (複数のリスナーに対するメッセージのいっせい配信や、破棄、延期、配信不能レタリング後のメッセージ取得など) は、それぞれ独立したメッセージとしてカウントされます。たとえば、3 つのサブスクリプションを持つトピックにおいて、64 KB の単一のメッセージを送信し、その後、受信した場合、課金対象のメッセージは 4 つです (すべてのメッセージがすべてのサブスクリプションに配信されたと仮定すると、"受信" が 1 回、"送信" が 3 回となります)。

一般に、管理操作と "制御メッセージ" (Complete、Defer など) は課金対象とは見なされません。ただし、これには 2 つの例外があります。

  1. 空のキューまたはサブスクリプションに対する要求への応答として Service Bus によって配信される null メッセージは課金対象となります。したがって、Service Bus エンティティに対してポーリングするアプリケーションは、実質的にポーリングごとに 1 メッセージ分が課金されます。

  2. MessageSession に対する状態の設定と取得も課金対象メッセージと見なされ、先ほど説明したメッセージ サイズに基づく同じ計算が適用されます。

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

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

  2. NetTCPRelay WCF バインドを使って開いたリレーは、メッセージを個別にではなく、システムを流れるデータのストリームとして扱います。つまり、このバインドを使って送受信された各メッセージを 1 つのまとまりとして見ることができるのはセンダーとリスナーだけです。したがって、netTCPRelay バインドを使ったリレーの場合、すべてのデータをストリームとして扱ったうえで、課金対象のメッセージ数が計算されます。この場合、Service Bus は、個々のリレーを介して 5 分間に送受信されたデータの合計サイズを計算してその合計を 64 KB で除算することで、その期間における当該リレーの課金対象のメッセージ数を特定します。

一般に、管理操作 (トピック上のサブスクリプションの列挙、キューの深さの判定など) と "制御メッセージ" (Complete、Defer など) は課金対象メッセージとは見なされません。ただし、これには 2 つの例外があります。

  1. 空のキューまたはサブスクリプションに対する要求への応答として Service Bus によって配信される "null" メッセージは課金対象となります。したがって、Service Bus エンティティに対してポーリングするアプリケーションは、実質的にポーリングごとに 1 メッセージ分が課金されます。

  2. MessageSession に対する状態の設定と取得も課金対象メッセージと見なされ、先ほど説明したメッセージ サイズに基づく同じ計算が適用されます。

いいえ。Service Bus では、ストレージに対する料金は発生しません。ただし、キュー/トピックごとに保存できる最大データ量を制限するクォータはあります。以下の「Service Bus に使用量クォータはありますか」を参照してください。

  • 各キュー内のメッセージはいずれも 1 回だけ配信されるものとします。

  • 128 KB のメッセージ 1 つにつき課金対象のメッセージは 2 つです (128 KB/64 KB)。

  • 1 分間に受け取る課金対象のメッセージが 2 つで、1 分間に配信される課金対象メッセージが 2 つであるため、キューごとの課金対象のメッセージは毎分 4 つになります。

  • 4 (キューごとの 1 分間あたりのメッセージ数) * 1,440 (1 日は 1,440 分) = 5,760 (キューごとの 1 日あたりのメッセージ数)

  • 1 日に Service Bus に送信される課金対象メッセージ数と Service Bus から配信される課金対象メッセージ数の合計 = 5,760 (1 日あたりのキューごとのメッセージ数) * 100 (キューの数) = 576,000 (1 日あたりのメッセージ数)

  • 576,000 個の Service Bus メッセージに対して発生するコストは、$0.58/日 (576,000/10,000 * $0.01 = 58 * $0.01) となります。

  • すべてのサブスクリプションがすべてのメッセージを受信し、なおかつ個々のサブスクリプション内のメッセージがいずれも 1 回だけ配信されるものとします。

  • 48 KB のメッセージ 1 つにつき課金対象のメッセージは 1 つです。

  • 1 (課金対象の毎秒メッセージ数) * 86,400 (1 日は 86,400 秒) = 86,400 (トピックに送信される 1 日あたりの課金対象メッセージ数)

  • 86,400 (1 日あたりのメッセージ数) * 4 (サブスクリプション数) = 345,600 (サブスクリプション クライアントに配信される 1 日あたりのメッセージ数)

  • 1 日に Service Bus に送信される課金対象メッセージ数と Service Bus から配信される課金対象メッセージ数の合計 = 86,400 + 345,600 = 432,000 (1 日あたりのメッセージ数)

  • 432,000 個の Service Bus メッセージに対して発生するコストは、$0.44/日 (432,000/10,000 * $0.01 = 44 * $0.01) となります。

  • 要求/応答パターンで、いずれの要求も、返される応答のサイズが 64 KB 以下であるものとします。

  • 8 KB のメッセージ 1 つにつき課金対象のメッセージは 1 つです。

  • 1 (課金対象の毎秒メッセージ数) * 86,400 (1 日は 86,400 秒) = 86,400 (各リレーを介して送信される要求の 1 日あたりの課金対象メッセージ数)

  • すべての要求で応答が返されるため、各リレーを介して送信される応答メッセージについて、1 日につき、さらに 86,400 個の課金対象メッセージが上乗せされます。

  • リレーごとの 1 日あたりの課金対象メッセージ数の合計 = 86,400 * 2 = 172,800

  • Service Bus に送信される課金対象メッセージ数と Service Bus が受信する課金対象メッセージ数の合計 = 172,800 * 10 (リレーの数) = 1,728,000

  • 1,728,000 個の Service Bus メッセージに対して発生するコストは、$1.73 (1,728,000/10,000 * $0.01 = 173 * $0.01) となります。

  • 10 個のリレーが 24 時間オープン = 240 リレー時間

  • 240 リレー時間に対して発生するコストは、$0.30 (240/100 * $0.10 = 3 * $0.10) となります。

  • 合計コスト = $1.73 + $0.30 = $2.03/日

  • 要求/応答パターンで、いずれの要求も、返される応答のサイズが 64 KB 以下であるものとします。

  • 8 KB (1 秒間に処理されるメッセージ) * 3,600 (1 時間あたりの秒数) = 28,800 KB (各リレーを介して 1 時間に送信される要求メッセージ)

  • すべての要求で応答が返されるため、各リレーを介して送信される応答メッセージについて、1 時間につき、さらに 28,800 KB が上乗せされます。

  • リレーごとの 1 時間あたりのメッセージ データの合計 = 57,600 KB.

  • 57,600 KB = 57,600/64 (リレーごとの 1 時間あたりの課金対象メッセージは 900 個) = 900 * 24 (リレーごとの 1 日あたりの課金対象メッセージは 21,600 個)

  • Service Bus に送信される課金対象メッセージ数と Service Bus が受信する課金対象メッセージ数の合計 = 21,600 (メッセージ数) * 10 (リレーの数) = 216,000

  • 216,000 個の Service Bus メッセージに対して発生するコストは、$0.22 (216,000/10,000 * $0.01 = 22 * $0.01) となります。

  • 10 個のリレーが 24 時間オープン = 240 リレー時間

  • 240 リレー時間に対して発生するコストは、$0.30 (240/100 * $0.10 = 3 * $0.10) となります。

  • 合計コスト = $0.22 + $0.30 = $0.52/日

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

  • 50 億メッセージ

  • 200 万リレー時間

マイクロソフトは、月間の使用量クォータを超えた場合にお客様のアカウントを無効にする権利を有します。ただし、その場合、電子メールでお客様にその旨をお知らせします。何度かお客様に連絡を試みたうえで、措置を講じることといたします。クォータを超えた分についても料金が課金されます。

リソースが公平に使用されるように、Service Bus は、 の他のサービスと同様、一連のクォータを適用します。このサービスで適用される使用量クォータは以下のとおりです。

  • キュー/トピック サイズ: キューまたはトピックの最大サイズは、その作成時にお客様が指定します。このクォータには、1 GB、2 GB、3 GB、4 GB、5 GB のいずれかを指定できます。最大サイズに達すると、それ以上の受信メッセージは拒否され、呼び出し元のコードで例外が発生します。

  • 同時接続数

    • キュー/トピック/サブスクリプション: キュー/ トピック/サブスクリプションに対する同時 TCP 接続数は 100 に制限されています。このクォータに達すると、その後の接続要求は拒否され、呼び出し元のコードで例外が発生します。Service Bus は、メッセージング ファクトリによって作成されたいずれかのクライアントでアクティブな操作が保留状態になっている場合や、操作が完了してからの経過時間が 60 秒未満である場合、メッセージング ファクトリごとに 1 つの TCP 接続を維持します。REST 操作は、TCP 同時接続数に加算されません。

  • リレーの同時リスナー数: リレーに対する NetTcpRelay および NetHttpRelay の同時リスナー数は 25 (NetOneway リレーの場合は 1 つ) に制限されます。

  • サービスの名前空間あたりの同時リレー リスナー数: Service Bus では、サービスの名前空間あたりの同時リレー リスナー数が 2000 に制限されます。このクォータに達すると、その後のリレー リスナーのオープン要求は拒否され、呼び出し元のコードで例外が発生します。

  • サービスの名前空間あたりのトピック/キュー数: サービスの名前空間上のトピック/キュー (永続的なストレージを利用したエンティティ) の最大数は 10,000 に制限されます。このクォータに達すると、以後、サービスの名前空間に対する新しいトピック/キューの作成要求は拒否されます。この場合、管理ポータルにエラー メッセージが表示されるか、または呼び出し元のクライアント コードで例外が発生します。そのどちらになるかは、作成要求をポータルで行ったか、クライアント コードから行ったかによって異なります。

  • メッセージ サイズ クォータ

    • キュー/トピック/サブスクリプション

      • メッセージ サイズ: メッセージ ヘッダーを含む合計サイズは、各メッセージにつき 256 KB に制限されます。

      • メッセージ ヘッダー サイズ: 各メッセージ ヘッダーは 64 KB に制限されます。

    • NetOneway および NetEvent リレー: メッセージ ヘッダーを含む合計サイズは、各メッセージにつき 64 KB に制限されます。

    • Http および NetTcp リレー: これらのメッセージのサイズに関して、Service Bus は上限を設けていません。

    以上のサイズ クォータを超えるメッセージは拒否され、呼び出し元のコードで例外が発生します。

  • トピックごとのサブスクリプション数: トピックごとの最大サブスクリプション数は 2,000 に制限されます。このクォータに達すると、以後、そのトピックへの新しいサブスクリプションの作成要求は拒否されます。この場合、管理ポータルにエラー メッセージが表示されるか、または呼び出し元のクライアント コードで例外が発生します。そのどちらになるかは、作成要求をポータルで行ったか、クライアント コードから行ったかによって異なります。

  • トピックごとの SQL フィルター数: トピックごとの最大 SQL フィルター数は 2,000 に制限されます。このクォータに達すると、以後そのトピックに新しくフィルターを作成する要求は拒否され、呼び出し元のコードで例外が発生します。

  • トピックごとの相関フィルター数: トピックごとの相関フィルターの最大数は 100,000 に制限されます。このクォータに達すると、以後そのトピックに新しくフィルターを作成する要求は拒否され、呼び出し元のコードで例外が発生します。

クォータの詳細については、「Windows Azure Service Bus のクォータ」を参照してください。

表示:
© 2014 Microsoft