Event Hubs のよく寄せられる質問

名前空間は、イベント ハブまたは Kafka トピックのスコープを指定するコンテナーです。 これにより、一意の [FQDN](https://en.wikipedia.org/wiki/Fully_qualified_domain_name) が提供されます。 名前空間は、複数のイベント ハブまたは Kafka トピックを収容できるアプリケーション コンテナーとして機能します。

その必要はありません。 デプロイの後で、たとえば Standard レベルから Premium レベルに変更するには、新しいリソースをデプロイする必要があります。

容量の割り当て (スループット ユニット (TU) または処理ユニット (PU)) は、名前空間レベルで課金されます。 名前空間は、リージョンにも関連付けられています。

次のいずれかのシナリオでは、既存の名前空間を使うのではなく、新しい名前空間を作ることをお勧めします。

• イベント ハブを新しいリージョンに関連付ける必要がある。
• イベント ハブを別のサブスクリプションに関連付ける必要がある。
• 異なる容量が割り当てられたイベント ハブが必要である (つまり、追加されたイベント ハブを含む名前空間に必要な容量が 40 TU のしきい値を超え、専用のクラスターを使いたくない)。

Azure Event Hubs の Standard レベルは、Basic レベルでは使用できない機能を提供します。 Standard レベルには次の機能が含まれています。

• 長いイベント保有期間
• 追加の仲介型接続。提供される数を超える場合は超過料金が適用されます
• 複数の[コンシューマー グループ](event-hubs-features.md#consumer-groups)
• [キャプチャ](event-hubs-capture-overview.md)
• [Kafka 統合](event-hubs-for-kafka-ecosystem-overview.md)

専用の Event Hubs を含む価格レベルの詳細については、「[Event Hubs の価格](https://azure.microsoft.com/pricing/details/event-hubs/)」を参照してください。

Azure Event Hubs は、サポートされているすべての Azure リージョンで利用できます。 一覧については、「[Azure リージョン](https://azure.microsoft.com/regions/)」ページを参照してください。

はい。すべてのイベント ハブが同じ名前空間にある限り可能です。

現在、Event Hubs の Standard レベルでサポートされる最大保持期間は 7 日ですが、Premium と Dedicated レベルではこの制限は 90 日です。 イベント ハブは、永続的なデータ ストアとしては考慮されていません。 保持期間が 24 時間を超えるのは、同じシステムへのイベントのストリームを再生すると便利なシナリオに対応するためです。 たとえば、既存データで新しい機械学習モデルのトレーニングや検証を行う場合です。 7 日間を超えるメッセージの保有期間が必要な場合は、イベント ハブで [Event Hubs Capture](event-hubs-capture-overview.md) を有効にすると、イベント ハブのデータが、選択したストレージ アカウントまたは Azure Data Lake サービス アカウントにプルされます。 Capture を有効にすると、購入済みのスループット ユニットに基づく料金が発生します。

ストレージアカウントでキャプチャされたデータの保有期間を構成できます。 Azure Storage の **ライフサイクル管理** 機能には、汎用 v2 アカウントと BLOB ストレージ アカウントのためのルール ベースのポリシーが豊富に用意されています。 このポリシーを使用して、適切なアクセス層にデータを移行します。または、データのライフサイクルの終了時に期限切れにします。 詳細については、「[Azure Blob Storage のライフサイクルの管理](../storage/blobs/storage-lifecycle-management-concepts.md)」を参照してください。

Event Hubs は、リソースの状態を示す網羅的なメトリックを [Azure Monitor](../azure-monitor/overview.md) に出力します。 また、Event Hubs サービスの全体的な正常性を名前空間レベルだけでなく、エンティティ レベルでも評価することができます。 どのような監視が提供されるかについては、[Azure Event Hubs](monitor-event-hubs.md) に関するページを参照してください。

Azure Event Hubs の Standard、Premium、Dedicated の各レベルでは、ユーザーが Event Hubs 名前空間の作成時に選んだリージョンに、発行されたデータが格納されて処理されます。 既定では、お客様のデータはそのリージョン内に留まります。 Azure Event Hubs 名前空間に対して geo ディザスター リカバリーを設定すると、メタデータは、選択されたセカンダリ リージョンにコピーされます。 したがって、このサービスによって、[トラスト センター](https://azuredatacentermap.azurewebsites.net/)に指定されているものも含めて、リージョンのデータ所在地の要件が自動的に満たされます。

ファイアウォールで開く必要があるのはどのポートですか。

Azure Event Hubs でイベントを送受信するために、次のプロトコルを使用できます。

• Advanced Message Queuing Protocol 1.0 (AMQP)
• トランスポート層セキュリティ を使用したハイパーテキスト転送プロトコル 1.1 (HTTPS)
• Apache Kafka

これらのプロトコルを使用して Azure Event Hubs と通信するために開く必要がある送信ポートについては、次の表を参照してください。

クライアント SDK によって実行されるいくつかの管理操作と Microsoft Entra ID からのトークンの取得 (使用時) が HTTPS 経由で実行されるため、AMQP がポート 5671 経由で使用される場合も、送信通信には HTTPS ポートが必要です。

公式の Azure SDK では、通常、Event Hubs に対するイベントの送受信で AMQP プロトコルが使用されます。 WebSocket 経由の AMQP プロトコル オプションは、HTTP API と同様に、ポート TCP 443 で実行されますが、それ以外については通常の AMQP と機能的に同じです。 このオプションでは、HTTPS ポートを共有するためのトレードオフとして、追加のハンドシェイクのラウンドトリップが発生し、若干のオーバーヘッドが生じるため、初期接続の待機時間が長くなります。 このモードが選択されている場合は、通信のためには TCP ポート 443 で十分です。 次のオプションでは、通常の AMQP または AMQP WebSocket モードを選択できます。

どのような IP アドレスを許可する必要がありますか。

Azure を使用している場合、使用している、または使用しようとしているすべての Azure サービスにアクセスするために、企業のファイアウォールまたはプロキシで特定の IP アドレス範囲または URL を許可することが必要になる場合があります。 Event Hubs によって使用される IP アドレスでトラフィックが許可されていることを確認します。 Azure Event Hubs によって使用される IP アドレスについては、「Azure の IP 範囲とサービス タグ - パブリック クラウド」を参照してください。

また、名前空間の IP アドレスが許可されていることを確認します。 接続を許可する適切な IP アドレスを検索するには、次の手順を実行します。

1. コマンド プロンプトで、次のコマンドを実行します。

   nslookup <YourNamespaceName>.servicebus.windows.net
   

2. Non-authoritative answer で返された IP アドレスをメモします。

名前空間にゾーン冗長性を使用している場合は、次の追加手順を実行する必要があります。

1. まず、名前空間に対して nslookup を実行します。

   nslookup <yournamespace>.servicebus.windows.net
   

2. non-authoritative answer セクションの名前をメモします。これは、次のいずれかの形式になります。

   <name>-s1.cloudapp.net
   <name>-s2.cloudapp.net
   <name>-s3.cloudapp.net
   

3. s1、s2、s3 のサフィックスが付いているそれぞれについて nslookup を実行し、3 つの可用性ゾーンで実行されている 3 つのインスタンスすべての IP アドレスを取得します。

   注意

   nslookup コマンドによって返された IP アドレスは、静的 IP アドレスではありません。 ただし、基になるデプロイが削除されるか別のクラスターに移動されるまでは変わりません。

どのクライアント IP によって名前空間からイベントの送信または受信が行われているか

まず、名前空間で IP フィルターを有効にします。

次に、「診断ログを有効にする」の手順に従って、Event Hubs 仮想ネットワーク接続イベントの診断ログを有効にします。 接続が拒否された IP アドレスが表示されます。

{
    "SubscriptionId": "0000000-0000-0000-0000-000000000000",
    "NamespaceName": "namespace-name",
    "IPAddress": "1.2.3.4",
    "Action": "Deny Connection",
    "Reason": "IPAddress doesn't belong to a subnet with Service Endpoint enabled.",
    "Count": "65",
    "ResourceId": "/subscriptions/0000000-0000-0000-0000-000000000000/resourcegroups/testrg/providers/microsoft.eventhub/namespaces/namespace-name",
    "Category": "EventHubVNetConnectionEvent"
}

Event Hubs は、既存の Apache Kafka ベースのアプリケーションが使用できる Kafka エンドポイントを提供します。 構成変更が、PaaS Kafka エクスペリエンスを得るために必要なすべてのことです。 これにより、独自の Kafka クラスターを実行するための代替手段が提供されます。 Event Hubs は Apache Kafka 1.0 以降のクライアント バージョンをサポートし、既存の Kafka アプリケーション、ツール、およびフレームワークと連携して動作します。 詳細については、[Kafka リポジトリ用の Event Hubs](https://github.com/Azure/azure-event-hubs-for-kafka) に関するページを参照してください。

イベント ハブに接続するには、Kafka クライアントの構成を更新する必要があります。 これは、Event Hubs 名前空間を作成し、[接続文字列](event-hubs-get-connection-string.md)を取得することによって実行されます。 Event Hubs の FQDN を指すように bootstrap.servers を変更し、ポートを 9093 に変更します。 以下に示す正しい認証を使用し、sasl.jaas.config を更新して、Kafka クライアントを Event Hubs エンドポイント (取得した接続文字列) に転送します。

bootstrap.servers={YOUR.EVENTHUBS.FQDN}:9093
request.timeout.ms=60000
security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="$ConnectionString" password="{YOUR.EVENTHUBS.CONNECTION.STRING}";

例:

bootstrap.servers=dummynamespace.servicebus.windows.net:9093
request.timeout.ms=60000
security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="$ConnectionString" password="Endpoint=sb://dummynamespace.servicebus.windows.net/;SharedAccessKeyName=DummyAccessKeyName;SharedAccessKey=XXXXXXXXXXXXXXXXXXXXX";

Event Hubs に許可されている最大メッセージ サイズは 1 MB です。

Event Hubs でのスループットは、Event Hubs 経由で入出力されるデータ量 (MB 単位) または 1 KB のイベントの個数 (千個単位) を定義します。 このスループットは、スループット ユニット (TU) で測定されます。 Event Hubs サービスの使用を開始するには、その前に TU を購入します。 Event Hubs の TU は、ポータルまたは Event Hubs Resource Manager テンプレートのどちらかを使用して明示的に選択できます。

はい。スループット ユニット (TU) は、Event Hubs 名前空間内のすべてのイベント ハブに適用されます。 つまり、TU は名前空間レベルで購入され、その名前空間の下のイベント ハブ間で共有されます。 各 TU により、名前空間に次の機能が与えられます。

• 最大 1 MB/秒のイングレス イベント (イベント ハブに送信されるイベント)。ただし、イングレス イベント、管理操作、または制御 API 呼び出しの数は 1 秒あたり 1,000 以下。
• 最大 2 MB/秒のエグレス イベント (イベント ハブから使用されるイベント)。ただし、エグレス イベントの数は 4,096 以下。
• 最大 84 GB のイベント ストレージ (既定の 1 時間の保有期間に十分な量)。

スループット ユニット (TU) は、時間単位で課金されます。 課金は、特定の 1 時間内に選択されたユニットの最大数に基づきます。

最低 1 スループット ユニット (TU) から始めて、自動インフレを有効にすることができます。 自動インフレ機能を使うと、トラフィックやペイロードの増加に合わせて TU を増やすことができます。 また、TU の数に上限を設定することもできます。

自動インフレ機能を使うと、スループット ユニット (TU) をスケールアップできます。 つまり、少ない TU 購入量で始めて、イングレスが増えたら自動インフレで TU をスケールアップできます。 これにより、コスト効率に優れたオプションと、管理する TU の数の完全な制御が提供されます。 この機能は**スケールアップのみ**の機能であり、それを更新することによって TU の数のスケールダウンを完全に制御できます。

少ないスループット ユニット (TU) (2 TU など) で始めることをお勧めします。 トラフィックが 15 TU まで増える可能性があると予測される場合は、名前空間で自動インフレ機能を有効にして、上限を 15 TU に設定します。 これで、トラフィックの増加に従って TU を自動的に増やすことができます。

この機能に関連して生じる**コストはありません**。

古い Event Hubs 名前空間は異なるクラスター内にあり、新しい Event Hubs 名前空間の作成時にゾーン冗長が自動的に有効になる新しいクラスターにそれを移行する方法がないため、現在は、これを行うことはできません。

名前空間内のすべてのイベント ハブの合計**イングレス** スループットまたは合計イングレス イベント レートがスループット ユニットの上限の総計を超過した場合は、送信側が調整され、受信クォータを超えたことを示すエラーを受信します。

名前空間内のすべてのイベント ハブの合計**エグレス** スループットまたは合計イベント エグレス レートがスループット ユニットの上限の総計を超過した場合は、受信側が調整されますが、調整エラーは生成されません。

送信側でイベントの使用速度が低下しないようにするため、また受信側でイベント ハブにイベントを送信できなくなることを避けるために、イングレス クォータとエグレス クォータは別々に適用されます。

Azure portal で Basic または Standard レベルの名前空間を作成する場合、名前空間に対して最大 40 個の TU を選択できます。 40 TU を超える場合、Event Hubs には、Event Hubs Premium や Event Hubs Dedicated クラスターなど、リソースまたは容量ベースのモデルが用意されています。 詳細については、[Event Hubs Premium の概要](event-hubs-premium-overview.md)ページと [Event Hubs Dedicated の概要](event-hubs-dedicated-overview.md)ページを参照してください。

Event Hubs Dedicated クラスターは、最も要求の厳しい要件を持つ顧客にシングルテナント デプロイを提供します。 このオファリングでは、スループット ユニットによって制約されない容量ベースのクラスターが作成されます。 つまり、このクラスターを利用すると、クラスターの CPU とメモリの使用量に応じてデータを取り込み、ストリーミングできます。 詳細については、[Event Hubs Dedicated クラスター](event-hubs-dedicated-overview.md)に関するページを参照してください。

詳細な手順と Event Hubs Dedicated クラスターの設定の詳細については、「[クイックスタート: Azure portal を使用して専用の Event Hubs クラスターを作成する](event-hubs-dedicated-cluster-create-portal.md)」を参照してください。

クラスターでは何ができますか?

Event Hubs クラスターの場合、どれだけの容量を取り込んでストリーミングできるかは、プロデューサー、コンシューマー、取り込みや処理の速度などのさまざまな要因によって異なります。

次の表は、弊社でのレガシ専用クラスターのテスト中に実現したベンチマーク結果を示しています。

このテストでは、次の条件が使用されました。

• 4 容量ユニット (CU) を持つ専用レベルの Event Hubs クラスターが使用されました。
• 取り込みに使用されたイベント ハブには 200 パーティションが存在しました。
• 取り込まれたデータは、すべてのパーティションから受信している 2 つの受信側アプリケーションによって受信されました。

クラスターをスケールアップ/ダウンできますか?

[Support Scaling](スケーリングのサポート) オプション セットを使用してクラスターを作成した場合、セルフサービスの手順を使用して、必要に応じたスケールアウトとスケールインを行うことができます。 セルフサービスによるスケーリングが可能なクラスターでは、最大 10 CU にまでスケールアップできます。 セルフサービス スケーラブル専用クラスターは新しいインフラストラクチャをベースにしているため、セルフサービスのスケーリングをサポートしていない専用クラスターよりもパフォーマンス面で有利です。 専用クラスターのパフォーマンスは、リソースの割り当て、パーティション数、ストレージなどのさまざまな要因に依存するため、実際のワークロードでテストした後に必要な CU 数を決定することをお勧めします。

次のような場合に専用クラスターをスケールアウトまたはスケールインするには、サポート リクエストを送信してください。

• セルフサービスによるスケーリングが可能な専用クラスター ([スケーリングのサポート] オプション セットを使用して作成したクラスター) に、10 を超える CU が必要である
• [スケーリングのサポート] オプションを選択せずに作成したクラスターをスケールアウトまたはスケールインする必要がある
• セルフサービス機能のリリース前に作成した専用クラスターをスケールアウトまたはスケールインする必要がある

レガシ クラスターからセルフサービス スケーラブル クラスターに移行できますか?

基盤となるハードウェアおよびソフトウェア インフラストラクチャの違いにより、セルフサービスのスケーリングをサポートしていないクラスターからセルフサービス スケーラブル専用クラスターへの移行は、現在サポートされていません。 セルフサービスのスケーリングの利用をご希望の場合は、クラスターを作成し直す必要があります。 スケーラブルなクラスターの作成方法については、Event Hubs 専用クラスターの作成に関するページを参照してください。

専用クラスターをスケーリングする場合

CPU 消費量は、専用クラスターのリソース消費量の主要インジケーターです。 全体的な CPU 消費量が 70% に達している場合 (サーバー エラーの数が多い、要求が少ないなど、異常な状態を観察せずに)、クラスターが最大容量に移行しています。 そのため、これをインジケーターとして使用して、専用クラスターをスケールアップする必要があるかどうかを検討できます。

専用クラスターの CPU 使用率を監視するには、次の手順に従う必要があります。

• Event Hubs Dedicated クラスターのメトリック ページで、[メトリックの追加] を選択します。

• メトリックとして CPU を選択し、集計として Max を使用します。

  

• 次に、[フィルターを追加する] を選択し、プロパティの型 Role のフィルターを追加します。等号演算子を使用し、ドロップダウンから 3 つの値 (Backend、Gateway) すべてを選択します。

  

  その後、このメトリックを監視して、専用クラスターをスケーリングする必要がある場合を判断できます。 また、CPU 使用率が設定したしきい値に達したときに通知を受け取るアラートをこのメトリックに対して設定することもできます。

geo DR はクラスターでどのように機能しますか?

専用レベルのクラスターの名前空間を、専用レベルのクラスターの別の名前空間と geo ペアリングすることができます。 Dedicated レベルの名前空間と Standard オファリングの名前空間のペアリングは、スループットの制限に互換性がないためエラーが発生するので、お勧めしません。

Standard または Premium の名前空間を Dedicated レベルのクラスターに移行できますか?

現在、Standard または Premium の名前空間から Dedicated にイベント ハブ データを移行するための自動移行プロセスはサポートされていません。

ゾーン冗長専用クラスターに最低 8 つの CU があるのはなぜですか?

専用サービスにゾーン冗長性をもたらすため、すべてのコンピューティング リソースには、同じリージョン内の 3 つのデータセンターにわたる 3 つのレプリカが必要です。 これは、(2 つのゾーン/データセンターがダウンしてもサービスを引き続き機能できるように) ゾーン冗長性をサポートするための最小要件であり、8 つの CU に相当するコンピューティング容量が得られます。

そのため、これは変更できるクォータではなく、専用レベルでの現在のアーキテクチャの制限です。

パーティションは、データの発行と使用を並列して行うことができるデータ編成メカニズムです。 最適なスケールを実現するには、スケーリング ユニット (Standard レベルの場合はスループット ユニット、Premium レベルの場合は処理ユニット、または Dedicated レベルの場合は容量ユニット) とパーティションのバランスを取ることをお勧めします。 一般に、パーティションあたり最大スループットは 1 MB/s にすることをお勧めします。 したがって、パーティションの数を計算するための経験則は、予想される最大スループットを 1 MB/s で除算することです。 たとえば、ユース ケースで 20 MB/s が必要な場合は、最適なスループットを実現するために、少なくとも 20 個のパーティションを選ぶことをお勧めします。

ただし、アプリケーションで特定のパーティションに対してアフィニティが設定されているモデルがある場合、パーティション数を増やすことは有効ではありません。 詳細については、[可用性と一貫性](event-hubs-availability-and-consistency.md)に関するページを参照してください。

Event Hubs 料金の詳細については、「 [Event Hubs 料金](https://azure.microsoft.com/pricing/details/event-hubs/)」を参照してください。

Event Hubs Standard レベルでは、24 時間より長いメッセージ保有期間 (最大 7 日間) が許可されます。 保存されたイベントの合計数が選択したスループット ユニット数のストレージの上限 (スループット ユニットあたり 84 GB) 上限を超えるサイズには公開された Azure Blob Storage レートの料金が発生します。 各スループット ユニットのストレージの上限は、スループット ユニットが受信の上限まで使用された場合でも、24 時間の保持期間に対するすべてのストレージ コストをカバーします。

保存されたすべてのイベントの合計サイズは、すべてのイベント ハブのイベント ヘッダーまたはディスク ストレージ構造の内部オーバーヘッドを含めて、1 日中測定されます。 1 日の終わりに、ピーク ストレージ サイズが計算されます。 1 日あたりのストレージの上限は、その日に選択されたスループット ユニットの最小数に基づいて計算されます (それぞれのスループット ユニットには 84 GB の上限が与えらえます)。 合計サイズが計算された 1 日あたりのストレージの上限を超過した場合は、超過したストレージが、Azure Blob ストレージ レート ( **Locally Redundant Storage (LRS)** ) を使用して課金されます。

イベント ハブに送信されたイベントは、それぞれが課金対象メッセージとしてカウントされます。 1 つの *イングレス イベント* は64 KB 以下の単位のデータと定義されます。 サイズが 64 KB 以下のイベントは、1 つの課金対象イベントとみなされます。 イベントが 64 KB よりも大きい場合、課金対象イベントの数はイベント サイズに従って計算され、64 KB の倍数になります。 たとえば、イベント ハブに送信された 8 KB のイベントは 1 つのイベントとして課金されますが、イベント ハブに送信された 96 KB のメッセージは 2 つのイベントとして課金されます。

イベント ハブや管理操作、チェックポイントなどの制御呼び出しで使用されるイベントは、課金対象イングレス イベントとしてはカウントされませんが、スループット ユニットの上限まで蓄積されます。

接続料金は AMQP プロトコルが使用されている場合にのみ適用されます。 送信側システムまたはデバイスの数に関係なく、HTTP を使用したベントの送信には接続料金は発生しません。 AMQP を使用する場合 (たとえば、イベント ストリーミングの効率を高めたり、IoT のコマンドと制御のシナリオで双方向通信を可能にする場合) は、[Event Hubs の価格情報](https://azure.microsoft.com/pricing/details/event-hubs/)に関するページで各サービスレベルに含まれる接続数に関する詳細を参照してください。

Capture が有効になるのは、名前空間内のいずれかのイベント ハブで Capture オプションが有効になっている場合です。 Event Hubs Capture は購入済みのスループット ユニットごとに月単位で課金されます。 スループット ユニット数が増減すると、Event Hubs Capture の課金についても、全体の時間の増分にスループット ユニット数の変化が反映されます。 Event Hubs Capture の課金の詳細については、[Event Hubs の価格情報](https://azure.microsoft.com/pricing/details/event-hubs/)に関するページを参照してください。

Event Hub で有効にされた場合、Capture はお客様の指定したストレージ アカウントを使用します。 これはお客様のストレージ アカウントであるため、この構成に関する変更はすべてお客様の Azure サブスクリプションに課金されます。

Event Hubs のすべてのクォータの一覧については、[クォータ](event-hubs-quotas.md)に関するページを参照してください。

サブスクリプションから名前空間を削除した場合、別のサブスクリプションで同じ名前を使用して再作成するには、4 時間ほど時間を空けてから行ってください。 そうしないと、次のエラー メッセージが表示される場合があります: Namespace already exists。

発生する可能性がある Event Hubs 例外の一覧については、[例外の概要](event-hubs-messaging-exceptions.md)に関するページを参照してください。

Event Hubs では、Capture エラー ログと運用ログの 2 種類の[診断ログ](monitor-event-hubs-reference.md#resource-logs)がサポートされており、両方とも JSON で表されます。この診断ログは Azure Portal で有効にできます。

Event Hubs のテクニカル サポートについては、Microsoft Q&A の Azure Service Bus に関する質問ページを参照してください。 課金とサブスクリプション管理のサポートは無料で提供されます。

SLA の詳細については、「 [サービス レベル アグリーメント](https://azure.microsoft.com/support/legal/sla/) 」ページを参照してください。

このコードを Azure Stack Hub で実行すると、特定の Storage API バージョンを対象としている場合を除き、実行時エラーが発生します。 これは、Event Hubs SDK では、Azure で利用できる最新の Azure Storage API が使われますが、Azure Stack Hub プラットフォームではそれを利用できない可能性があるためです。 Azure Stack Hub でサポートされる Storage Blob SDK のバージョンは、Azure で一般的に利用できるものと異なる場合があります。 チェックポイント ストアとして Azure Blob Storage を使用している場合は、[Azure Stack Hub ビルドでサポートされている Azure Storage API バージョン](/azure-stack/user/azure-stack-acs-differences?#api-version)を確認し、コード内でそのバージョンを対象にします。

たとえば、Azure Stack Hub バージョン 2005 上で実行している場合、Storage サービスで利用できる最も高いバージョンは 2019-02-02 となります。 既定では、Event Hubs SDK クライアント ライブラリでは、Azure で利用できる最も高いバージョン (SDK のリリース時点では 2019-07-07) が使用されます。 この場合は、このセクションの手順に従うことに加え、Storage サービス API バージョン 2019-02-02 を対象とするコードを追加する必要もあります。 特定の Storage API バージョンを対象にする方法の例については、次の C#、Java、Python、JavaScript または TypeScript 用のサンプルを参照してください。

コードから特定の Storage API バージョンを対象にする方法の例については、次の GitHub 上のサンプルを参照してください。

• .NET
• Java
• Python - 同期、非同期
• JavaScript および TypeScript

次のステップ

Event Hubs の詳細については、次のリンク先を参照してください:

• Event Hubs の概要
• Event Hub を作成する
• [Event Hubs の自動インフレ](event-hubs-auto-inflate.md)