Event Hubs × New Relic / サードパーティ SIEM 連携アーキテクチャ

山崎行政書士事務所
9月11日
読了時間: 9分

— 設計原理・実装指針・運用統制の総覧（SE 向け）—

著者：山崎行政書士事務所クラウド法務・アーキテクチャ支援チーム

発行日：2025-09-11

要旨（Abstract）

本稿は、Azure Event Hubs を中心に据えたログ／イベント集約中継レイヤの設計と、New Relicならびに Splunk / IBM QRadar / Elastic / Sumo Logic 等のサードパーティ SIEM への確実・安全・拡張的な連携方式を体系化する。Azure Monitor の Diagnostic settings と Data Collection Rules (DCR) を用いたプラットフォームログの Event Hubs ストリーミング、Event Hubs の スループット単位(TU) と パーティションによるスケーリング、Private Link／CMK／Geo-DR と Geo-Replication による可用性・秘匿性の確保、複数コンシューマ（New Relic＋複数 SIEM）をコンシューマグループで捌く多面給電を、リファレンス実装とともに提示する。Azure 側と受け側双方の最新公式ドキュメントに基づく設計根拠を付し、Wix ブログ記事としての可読性を担保した。

キーワード：Event Hubs, Diagnostic settings, DCR, Throughput Unit, Consumer Group, Private Link, CMK, Geo-DR, Geo-Replication, New Relic, Splunk, QRadar, Elastic, Sumo Logic

1. 背景と課題認識

クラウド横断で増大するプラットフォームログ（Activity Log, Resource Logs, Entra 監査/サインイン等）を、組織のツール群（APM・SIEM・データ基盤）へ重複なく・安全に・損失なく配信する中継層が必要。Azure Monitor は Diagnostic settings で各リソースのログ/メトリクスを Event Hubs 等へ送出でき、DCR も併用可能である。
Event Hubs は スループット単位 (TU) により容量を明確化し、1 TU あたり Ingress 1 MB/s or 1,000 events/s、Egress 2 MB/s or 4,096 events/s を提供する。これを基準に設計時点での上限誤差を排除できる。
複数ツールへの同時配信は、Event Hubs の コンシューマグループで分離するのが基本パターン（New Relic 用、Splunk 用、Elastic 用 …）。

2. 参照アーキテクチャ（概観）

[Azure Resources / Entra / Subscriptions]
            │  Diagnostic settings / DCR
            ▼
     ┌─────────────────────────┐
     │  Event Hubs Namespace   │  Private Link / FW / RBAC / CMK
     │   - Hub: platform-logs  │
     │   - Partitions: N       │
     │   - Consumer Groups:    │  ┌─────────────────────────────────┐
     │     $Default            │  │  Consumer Group: cg-newrelic    │
     │     cg-newrelic         ├─▶│  NR EH Consumer/Func → NR Logs  │
     │     cg-splunk           │  └─────────────────────────────────┘
     │     cg-qradar           │  ┌─────────────────────────────────┐
     │     cg-elastic          ├─▶│  Splunk/HEC or TA → Indexers    │
     │     cg-sumologic        │  └─────────────────────────────────┘
     └─────────────────────────┘  （※他 SIEM も同様に拡張）
            │
            └─(Option) Capture → ADLS（再処理/監査）

設計要点：Diagnostic settings / DCR → Event Hubs が統一入口。出力先ごとに Consumer Group を分け、再送/バックフィルは Capture → ADLS から再投入する設計とする。

3. 送出（Producer）設計：Azure Monitor から Event Hubs へ

3.1 診断設定 (Diagnostic settings)

各リソース単位で対象カテゴリ（例：allLogs / 特定カテゴリ）を選び、宛先に Event Hubs を指定する。スキーマは AzureDiagnostics 方式とリソース別テーブル方式がある（後続の解析要件で選択）。

3.2 DCR (Data Collection Rules)

DCR によりログ/メトリクスを Event Hubs / Log Analytics / Storage へ柔軟にストリーミング可能。Diagnostic settings と併用可。

3.3 Microsoft Entra (旧 Azure AD) ログ

監査ログ／サインイン等はテナント側の診断設定から Event Hubs へ直接ストリームでき、代表的な SIEM 連携例が公開されている。

実装メモ（CLI）：az monitor diagnostic-settings create と … subscription create を使えば、リソース単位／サブスクリプション Activity Log 双方を Event Hubs に流せる。

4. 中継（Event Hubs）設計：スケーリングとセキュリティ

4.1 スループット計画

TU 規定値：Ingress 1 MB/s、Egress 2 MB/s（上限イベント数あり）。Auto-inflate を有効化し、スパイクに追従させる。必要 TU（Ingress）= ⌈総入力量(MB/s) / 1⌉、必要 TU（Egress）= ⌈総出力量(MB/s) / 2⌉。
パーティションは同時並行コンシューマ数と再処理特性に影響。ログはシャッフルで偏りが小さいため、消費側の並列度から逆算。

4.2 ネットワークと認可

Private Link で名前空間をプライベート化し、**Azure Monitor 送信やアラート（Action Groups）**の Event Hubs 連携も設計上考慮できる。RBAC は Data Sender/Receiver を最小権限付与。
プロトコル/ポート：データプレーンは AMQP over TLS (5671)。特にオンプレ／SIEM 連携時に開放要件として明示。

4.3 暗号化と鍵管理

既定で保管時暗号化。Customer-Managed Key (CMK/BYOK) を名前空間に設定可能（Premium/Dedicated でのユースケースが中心）。

4.4 可用性・災害復旧

Geo-DR（メタデータ複製）：別リージョンへ名前空間設定を継続複製し、別名（Alias）でフェイルオーバできる（データは複製対象外）。
Geo-Replication（データ複製）：2025/7 に 一般提供 (GA)。リージョン跨ぎのデータ可用性を高め、フェイルオーバ時の継続性を向上。要件に応じ Geo-DR と使い分ける。

4.5 監査と再処理

Capture で ADLS へ原本保管（準リアルタイム・ロールアップ）し、検証／再投入／監査証跡を保障。

5. 受け側（New Relic / SIEM）パターン

5.1 New Relic

推奨：Event Hubs コンシューマ（ARM テンプレート）既存/新規 Event Hub に New Relic のコンシューマを接続してログを自動転送。Activity Log も同テンプレートで簡便に構成できる（エージェントレス）。
代替：Azure Native New Relic ServiceAzure Portal から Azure Native New Relic を作成し、サブスクリプション／リソースログを一体管理で取り込むアプローチ。Event Hubs 中継と併用/使い分け可能。
関数ブリッジEvent Hubs トリガの Azure Functions で New Relic Logs API へ転送する軽量ブリッジも実務で利用される。

5.2 Splunk

アドオン/直接取り込みまたは、プロキシ・クラウド制約時は Azure Function → Splunk HEC ブリッジ。

5.3 IBM QRadar

Event Hubs からの受信要件として、5671/TLS や Storage 443 のネットワーク条件等が提示される。Consumer Group を専用化する。

5.4 Elastic

Filebeat の azure-eventhub input / Elastic Integration の Azure Event Hub を使用し、EH からダイレクト購読する。

5.5 Sumo Logic

Azure Event Hubs Source for Logs を使用（2025 年の最新移行案内あり）。診断設定→Event Hub が前提。

6. 実装ステップ（最小実例）

6.1 Event Hubs 名前空間と Hub 作成（CLI）

# 変数
RG=rg-obs
LOC=japaneast
NS=eh-obs-prd
HUB=platform-logs

# Namespace（Auto-inflate 有効、Standard/Premium 選択）
az group create -n $RG -l $LOC
az eventhubs namespace create \
  --resource-group $RG --name $NS --location $LOC \
  --sku Standard --enable-auto-inflate true --maximum-throughput-units 20

# Event Hub（パーティションは消費側の並列度から逆算）
az eventhubs eventhub create \
  --resource-group $RG --namespace-name $NS --name $HUB --partition-count 8

6.2 診断設定 → Event Hubs（CLI）

# 例：任意リソースのログ/メトリクスを EH へ
az monitor diagnostic-settings create \
  --name send-to-eh \
  --resource <RESOURCE_ID> \
  --event-hub-name $HUB \
  --event-hub-authorization-rule-id <EH_AUTH_RULE_RESOURCE_ID> \
  --logs '[{"categoryGroup":"allLogs","enabled":true}]' \
  --metrics '[{"category":"AllMetrics","enabled":true}]'

※ サブスクリプション Activity Log は az monitor diagnostic-settings subscription 系コマンドを使用。

6.3 New Relic 側の受信

ARM テンプレートで EH のコンシューマをデプロイし、ログを New Relic に自動転送。Activity Log の取り込みも同時に設定可能。
代替として Azure Native New Relic（Portal から New Relic リソースを作成）で、Azure 連携全体を一元化。

7. スキーマ／形式の扱い

Resource-specific vs AzureDiagnostics：ダッシュボード／クエリ最適化か、横断集約を優先するかで選択。SIEM 側のパーサの対応状況も要確認。
大規模組織や厳格な契約環境では Schema Registry を用いた Avro/JSON Schema 運用で互換性管理とペイロード最適化を推奨。

8. セキュリティ・コンプライアンス設計

Private Link ＋ FW 制御で EH を閉域化／最小権限 RBAC（Data Sender/Receiver）。
CMK（BYOK）適用により鍵ライフサイクル（ローテーション・失効）を組織側統制下に。Premium/Dedicated での運用事例が多い。
監査可能性：Capture→ADLS による原本保管と、Consumer Group ごとのオフセット管理で再現性を確保。

9. 可用性設計（DR / 継続運用）

Geo-DR（メタデータのみ）：名前空間エイリアスでフェイルオーバ、接続文字列の切替を不要化。ただしデータは複製されない。
Geo-Replication（データ複製）：2025/7 に GA。データを含めたリージョン間冗長で事業継続を強化。要件に応じて使い分け。
AZ 冗長やパフォーマンス監視を合わせ、**設計—検証—演習（DR Drills）**を定常化。

10. 規模見積り・チューニング（実務式）

入口（Ingress）見積：TU_in = ceil( Σ(各ソースの平均MBps) / 1 )
出口（Egress）見積：TU_out = ceil( Σ(各コンシューマ合計MBps) / 2 )※ 1 TU あたり Ingress 1MB/s、Egress 2MB/s。スパイク対策に Auto-inflate を併用。
パーティション：コンシューマの最大並列数（New Relic 転送ジョブ + 各 SIEM 取り込み）と再処理要件から逆算。

11. 代表的な連携レシピ（要点）

New Relic：ARM テンプレで EH コンシューマ → NR Logs（推奨）。Azure Native New Relic で一元化の選択肢も。
Splunk：アドオン直／クラウド制約時は EH → Azure Function → HEC。
QRadar：ポート/プロトコル要件と EH/Storage 到達性を満たす。
Elastic：Filebeat azure-eventhub input もしくは Elastic Integration を使用。
Sumo Logic：Azure Event Hubs Source for Logs（最新ガイドに更新）。

12. 運用・SRE 観点のチェックリスト

Diagnostic settings / DCR の継続適用（Azure Policy でスケール適用）
TU・Egress 監視（ServerBusy 兆候／Lag）と Auto-inflate 上限の整備
Consumer Group の分離（ツール単位）とチェックポイント健全性
Private Link / NSG / FW と RBAC（Data Sender/Receiver）の最小化
CMK キーライフサイクルとキーバックアップ方針
Capture 原本保管と再処理 Runbook
Geo-DR と Geo-Replication の使い分け／演習計画
スキーマ運用（Resource-specific / AzureDiagnostics、必要に応じ Schema Registry）

13. 付録：カテゴリ別のログ例（設計に効く最小カタログ）

Event Hubs RuntimeAuditLogs / ApplicationMetricsLogs（Premium/Dedicated）：クライアント接続・ラグ等。容量管理や不正検出に有用。
サブスクリプション Activity Log：ポリシー・RBAC・リソース操作の監査主軸。**診断設定（サブスクリプション単位）**で EH へ。
Entra 監査/サインイン：ID レイヤの横断可視化。多くの SIEM 連携ガイドがある。

14. 山崎行政書士事務所のご支援（PR）

クラウド法務 × 技術設計の「両利き」で、

監査適合（ISMS/ISO27001, NIS2, GDPR など）と、実装可能な技術設計書を同じチームで作り切ります。
契約・DPA・TIA・データ越境の条項整理から、Diagnostic settings / DCR / Event Hubs / Private Link / CMK / DR 設計のエビデンス化まで、運用で回る成果物に落とし込みます。
既存の New Relic / Splunk / QRadar / Elastic / Sumo 運用に最小摺合で接続するマイグレーション計画と、**指標設計（SLO / Error Budget）**まで伴走。

ご相談の初回論点例・どのログを Resource-specific で出す？受け側パーサは？（誤差最小の方式選定）・Geo-DR と Geo-Replication、どちらが要件に適合？フェイルオーバ演習は？・CMK の鍵責任区分（委託・管理・復旧）と SLA 合意は？・Event Hubs の TU/Partition、Capture、再処理手順書の構成証跡は十分か？

結語

Event Hubs を中核とした多面給電アーキテクチャは、取り込み（Diagnostic settings/DCR）→ 中継（EH/TU/Partition/PL）→ 受信（New Relic / SIEM）→ 監査（Capture）→ 継続運用（Geo-DR/Geo-Replication）の鎖を切らさない設計が肝要である。設計根拠が明確で検証・再現性の高い実装は、SRE 運用のコストを確実に下げる。

参照リンク集

Azure Monitor（診断設定／DCR／データエクスポート）

https://learn.microsoft.com/en-us/azure/azure-monitor/platform/stream-monitoring-data-event-hubs

https://learn.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings

https://learn.microsoft.com/en-us/azure/azure-monitor/data-collection/data-collection-rule-overview

https://learn.microsoft.com/en-us/azure/azure-monitor/logs/logs-data-export

https://learn.microsoft.com/en-us/cli/azure/monitor/diagnostic-settings?view=azure-cli-latest

https://learn.microsoft.com/en-us/cli/azure/monitor/diagnostic-settings/subscription?view=azure-cli-latest

Azure Event Hubs（基礎／スケーリング／機能）

https://learn.microsoft.com/en-us/azure/event-hubs/event-hubs-quotas

https://learn.microsoft.com/en-us/azure/event-hubs/event-hubs-scalability

https://learn.microsoft.com/en-us/azure/event-hubs/event-hubs-features