OCI Connector Hub

解決する課題

ログやメトリクスを別の保管先・分析基盤へ運ぶために、毎回スクリプトや Functions を自作してポーリングする運用から脱却できます。

• Logging に集めたログを長期保管したいので Object Storage や外部 SIEM へ流したい
• Monitoring のメトリクスを別リージョン／別システムへ転送してまとめて可視化したい
• 監査・コンプライアンスのためにログを書き換え不能なストレージへ恒久退避したい
• セキュリティイベントを条件で絞り込んでから通知や自動対処へつなぎたい
• これらをコードをほとんど書かずに、マネージドかつ宣言的に構成したい

主要概念と用語

• サービスコネクタ（Service Connector）: 1 本のデータ移動パイプライン。ソース・タスク・ターゲットの組で定義する設定単位
• ソース（Source）: データの取り出し元。Logging（ログ）／Monitoring（メトリクス）／Streaming／Queue などを選べる
• ターゲット（Target）: データの送り先。Object Storage／Logging Analytics／Monitoring／Streaming／Notifications（ONS）／Functions などに対応
• タスク（Task）: ソースとターゲットの間で行う任意の中間処理。Functions タスク（任意の変換・整形をコードで実行）と、ログを絞り込む Logging Query タスクがある。タスクは省略可能
• ログ／メトリクス／イベントのフロー: ソースが継続的に発生させるデータをコネクタが取り込み、タスクで整形・絞り込みし、ターゲットへ届ける一方向のストリーム
• ライフサイクル状態: コネクタは作成後 ACTIVE になり転送を続ける。一時停止すると転送が止まる
• IAM ポリシー連携: コネクタが各ソース／ターゲットへアクセスするには、コネクタ自身に対応する権限ポリシーが必要

仕様・制限・クォータ

• ソースとターゲットの組み合わせには対応マトリクスがある。すべてのソースが任意のターゲットへ送れるわけではないため、構成前に対応関係を確認する
• タスクは原則 1 段。複雑な多段変換が必要なら Functions タスク内で処理を完結させるか、コネクタを連鎖させる設計にする
• リージョン単位のサービス。クロスリージョン転送は、ターゲットに別リージョンの Streaming 等を指定するなどの構成で実現する（標準では同一リージョン内の連携が基本）
• Functions タスクのスループットは Functions 側の同時実行・タイムアウトに律速される。大量データを 1 件ずつ処理させると詰まりやすい
• Logging ソースは対象ログを明示選択する。コンパートメント／ロググループ／ログ単位で取り込み範囲を指定し、不要なログまで運ばないようにする
• カスタムな変換結果のスキーマやサイズには上限があり、テナンシ単位でコネクタ数などにサービスリミットが掛かる（上限引き上げはサービスリクエストで申請）

内部の仕組み

サービスコネクタは、選択したソースが発生させるデータを継続的にプル／受信し、タスクがあればそこを通し、ターゲットの API へバッチで書き込むマネージドなパイプラインとして動作します。コネクタ自体はサーバーレスで、スケーリングや再試行は OCI 側が管理します。

• Logging をソースにした場合、選択したログのストリームをコネクタが購読し、ターゲット（例 Object Storage）へ書き出します。これが「Logging のログを長期保管へ流す」定番経路です。
• Monitoring をソースにした場合、指定した名前空間のメトリクスを取り込み、別の Monitoring 名前空間や Streaming などへ転送します。
• タスク段では、Functions タスクが各データ項目（またはバッチ）を受け取り、整形・マスキング・付加情報の追加などを行って返します。Logging Query タスクは MQL ではなくログ検索式でフィルタし、条件に合うログだけを通します。
• コネクタはターゲット書き込みの失敗時に再試行します。恒久的に失敗するデータの扱いやエラー可視化は、コネクタのメトリクス・ログで監視します。

設計パターン / ベストプラクティス

• ログ長期保管パイプライン: Logging をソース、Object Storage をターゲットにして、保持期間を超えるログを書き換え不能なバケットへ恒久退避する。コンプライアンス要件の基本形
• SIEM／外部分析への転送: Logging または Monitoring を Streaming へ流し、外部 SIEM や分析基盤（Splunk、Datadog など）が Streaming から取り込む構成にする
• Functions タスクで整形・マスキング: PII を含むログは Functions タスクでマスキングしてから外部へ送る。スキーマ変換や項目の絞り込みもここで行う
• Logging Query で先に絞る: 全ログを運ぶのではなく、Logging Query タスクで必要なログだけに絞ってからターゲットへ送り、転送量とコストを抑える
• メトリクスの集約・転送: 複数コンパートメントのメトリクスを 1 つの分析用名前空間へ集めるなど、Monitoring 間の転送で可視化を一本化する
• イベント駆動の自動対処: ソースで拾ったログ・イベントを Functions タスクや Notifications ターゲットへつなぎ、条件成立時の自動対応を起動する

運用・監視

• 転送されない: まずコネクタのライフサイクル状態が ACTIVE か、ソースのログ／メトリクスが実際に発生しているかを確認する
• IAM ポリシー不足: コネクタがソースを読み、ターゲットへ書くにはそれぞれに対応するポリシーが必要。Object Storage への書き込み、Functions の呼び出し、Streaming への put など、ターゲットごとに権限を付与する
• Functions タスクで詰まる: タスクのエラー率・実行時間を Functions のメトリクスで確認。タイムアウトや同時実行上限で再試行が滞っていないかを点検する
• コネクタ自身の監視: サービスコネクタは自身のメトリクス（処理件数・エラー数など）を発行するので、これを Monitoring のアラームで監視し、転送停止を検知する
• 取りこぼし: Logging Query タスクのフィルタ式が厳しすぎて意図したログを落としていないか、対象ログの選択範囲が正しいかを確認する

コスト

Connector Hub の課金は概ねコネクタが処理したデータ量に対して発生します。あわせて、ソース／ターゲットの各サービス（Object Storage の保管・リクエスト、Functions の実行、Streaming の取り込みなど）でもそれぞれ課金される点に注意します。不要なログまで広く運ばず、Logging Query タスクで先に絞ることが転送量とコストの最適化につながります。

セキュリティ

• IAM ポリシーで権限を最小化: コネクタにはソース読み取りとターゲット書き込みに必要な権限だけを付与する。広すぎる権限を避け、対象コンパートメント／バケットを限定する
• 書き込み先の保護: ログを退避する Object Storage バケットは、バージョニングや保持ルールで改ざん・削除から守る。監査ログは特に書き換え不能性を担保する
• 転送経路のマスキング: 外部へ送る前に Functions タスクで機密情報をマスキング／除去し、PII や認証情報がそのまま外部基盤へ流れないようにする
• 役割分担の整理: 「ログを集める」のは Logging、「監視・アラーム」は Monitoring、「データを別サービスへ運ぶ」のが Connector Hub。横断連携の責務はここに集約すると整理しやすい

関連サービス・比較

Connector Hub は単独で機能するのではなく、ソースの Logging／Monitoring とターゲットの Object Storage／Streaming／Functions をつなぐ結合層として働きます。AWS では同じ役割を EventBridge Pipes や Kinesis Data Firehose が担います。

ハンズオン / CLI例

# 1) Logging をソース、Object Storage をターゲットにするサービスコネクタを作成
#    （ログを長期保管バケットへ流す定番パイプライン）
#    source / target はサービス種別ごとに JSON で指定する
oci sch service-connector create \
  --display-name "logs-to-archive" \
  --compartment-id "$COMPARTMENT_OCID" \
  --description "Forward audit logs to Object Storage for retention" \
  --source '{
    "kind": "logging",
    "logSources": [
      {
        "compartmentId": "'"$COMPARTMENT_OCID"'",
        "logGroupId": "'"$LOG_GROUP_OCID"'"
      }
    ]
  }' \
  --target '{
    "kind": "objectStorage",
    "bucketName": "log-archive",
    "namespace": "'"$OS_NAMESPACE"'"
  }'

# 2) 作成済みコネクタの一覧を確認（ライフサイクル状態をチェック）
oci sch service-connector list \
  --compartment-id "$COMPARTMENT_OCID"

# 3) 特定コネクタの詳細を取得（ソース／タスク／ターゲットの設定確認）
oci sch service-connector get \
  --service-connector-id "$CONNECTOR_OCID"

# 4) 一時停止と再開（メンテナンス時に転送を止める）
oci sch service-connector deactivate \
  --service-connector-id "$CONNECTOR_OCID"

oci sch service-connector activate \
  --service-connector-id "$CONNECTOR_OCID"