リバースETLとプライベートクラウド: 概念的なサバイバルガイド

リバースETLとプライベートクラウド: 概念的なサバイバルガイド

「無敵の力」と「動かせない物体」の対決"

現代のデータアーキテクチャの多くは、「データウェアハウスのデータを、それを必要とするチームへ迅速に届けること」を共通の目標としています。しかし、厳格なネットワークセキュリティが障壁となり、行き詰ってしまうケースも少なくありません。

一方のSegmentリバースETLが機能するためには、公開HTTPSエンドポイントが必要です。これに対して、Databricks SQL Warehouseは、パブリックインターネットからはアクセスできないプライベートなAzure仮想ネットワーク（VNet）内に安全に配置されています。

そのため、以下の2つの重要な制約が発生しました:

• Segmentにはパブリックからアクセス可能なHTTPSエンドポイントが必要
• Databricks SQL Warehouseはパブリックからアクセス不可

これにより、接続要件とネットワーク隔離要件が対立し、直接的な統合は不可能となりました。部門は「パブリックからのアクセスは不可」と言い、Segmentは「接続先が見つからない」と言います。ここでは、ルールを破ることなく、両者の間に橋渡しを構築した方法をご紹介します。

SegmentリバースETLの動作: 失敗する3つの方法（そして成功する1つの方法）

この課題を解決するため、概念実証（PoC）の段階で複数のアプローチの評価を行いました。最初からすべてが順調に進んだわけではありません。このPoCを「接続経路における具体的なボトルネックを特定するための短期集中アプローチ」として位置付けました。試行錯誤を重ねた結果、実運用に耐えうるソリューションに必要な要件が明確になりました。

直接接続の検証

まずは、最もシンプルな「直接接続」です。SegmentリバースETLをDatabricks SQL Warehouseへ直接接続しようと試みました。

• 結果: 完全に応答なしでした。
• 教訓: 許可リスト（ゲストリスト）に登録されていないサーバーとは、「ハンドシェイク」できません。プライベートエンドポイントが「プライベート」なのは、それだけの理由があるのです。

この方法が成功しなかった理由は以下のとおりです:

• Databricksがパブリックアクセス不可であるため
• Segmentがプライベートエンドポイントに到達できなかったため

この検証により、プライベートネットワーク構成では直接接続が実現不可能であることが確認できました。

次のアプローチでは、SegmentのDatabricksコネクターを標準構成で使用することにしました。

標準コネクター構成

次に、SegmentのDatabricksコネクターを標準構成で使用してみました。すると、すぐに2つの壁に直面しました:

OAuthの不一致: Segmentは特定の認証フロー（基本認証やクライアント認証）を想定していたのに対し、Databricksは完全なOAuthハンドシェイクを要求しており、現在のコネクターではこれに対応できませんでした。

ホスト名フィルター: Databricksのドライバーは厳格です。strings.Containsチェックを使用して、ホスト名に「azuredatabricks.net」が含まれているかを確認します。この文字列が含まれていない場合、通信さえしようとしません。

迅速な対応を図るため、外部プロキシレイヤーを導入することが最も現実的なアプローチであると判断しました。

カスタムホスト名とDNSマッピング

コネクターの検証要件を満たすため、「azuredatabricks.net」を含むカスタムホスト名を採用しました。

パターンの例:

• dev.staging.azuredatabricks.net.<custom-domain>

このカスタムホスト名が、Azure Application GatewayのパブリックIPにマッピングされました。

このアプローチにより、以下が実現できました:

• 正常なDNS解決
• コネクターのホスト名検証との互換性確保

さらに、Databricks SQLドライバーの動作についても考慮しました:

• ドライバーは、ホスト名の照合を使用してクラウドプロバイダーのコンテキストを判別します。
• 部分文字列の照合（strings.Contains）を使用しているため、カスタムインフラストラクチャを経由しながらも、仕様を満たすホスト名を構成できます。

しかし、以下の理由から、このアプローチだけでは不十分でした:

• リクエストを処理するバックエンドロジックが存在しなかった
• 認証処理が実装されていなかった
• リクエストのルーティングや変換ロジックが存在しなかった

この結果から、検証にはDNSの整合性確保が必要であるものの、統合にはそれだけでは不十分であることが確認されました。

Application Gatewayのみのアプローチ

そこで、パブリックイングレスを処理するためにAzure Application Gatewayを追加しました。これにより「可視性」の問題はクリアできましたが、Gatewayには高度な機能はないため、Databricksが要求する複雑なトークン交換処理に対応することはできませんでした。

Application Gatewayは以下の機能を正常に提供しました:

• パブリックイングレス
• TLSターミネーション
• リクエストのルーティング

しかし、このアプローチは以下の理由により失敗しました:

• OAuthトークン交換を実行できなかった
• 認証エンドポイントを公開できなかった
• リクエストレベルの変換を処理できなかった

この検証により、単なるルーティング処理だけでは連携できないことが確認できました。

プロキシレイヤーによる認証とルーティング

SegmentとDatabricks間の認証および接続性の課題を解消するため、カスタムプロキシサービスを採用しました。

Segment側の要求仕様を満たしつつ、Databricksと安全に連携できるよう設計されたプロキシです。

認証レイヤー

• OIDC互換エンドポイントを公開:
• /oidc/v1/token
• /oidc/.well-known/oauth-authorization-server
• /oidc/jwks.json
• Segmentからの基本認証を受信
• 署名付きJWTトークンを発行（RS256）
• 公開鍵/秘密鍵ペアを用いて、受信したJWTトークンを検証
• 一意の識別子（jti）を活用し、トークンのライフサイクルを管理

Databricksとのトークン交換

• client_credentialsフローを使用して、Databricksからアクセストークンを取得
• トークンをキャッシュし、Databricksへの認証呼び出しの頻度を抑える
• プロキシが発行した受信トークンを、Databricksの有効なOAuthトークンに置換

転送レイヤーをリクエスト

• Databricksのエンドポイント（/api、/sql）へリクエストをルーティング
• リクエスト転送前にヘッダーを正規化し、競合する不要なヘッダーを削除
• Databricks SQL APIとの互換性を維持

運用機能

• 監視用のヘルスエンドポイント（/health）
• 安全なコミュニケーションのためのTLSサポート
• レイテンシーの可視化（プロキシとアップストリームの処理時間の比較）が可能なリクエストトレーシング

これにより、以下の問題が解決されました:

• コネクターの検証に関する問題
• 認証の非互換性
• クエリ実行の失敗

このプロキシは、認証情報を変換するレイヤーとルーティングを制御する仕組みとして効果的に機能しました。

ブレークスルー: 「アイデンティティ情報をスワップする」プロキシ

課題を克服するには、単なるデータの通り道（パイプ）だけでは不十分でした。プロトコルや認証を仲介する「通訳者役」が必要だったのです。そこで、GatewayとDatabricksの間に配置するカスタムプロキシサービスを構築しました。

秘訣

双方の要件を同時に満たすため、プロキシにちょっとした技術的な「魔法」を凝らしました。

• DNSマスク: プロキシに「dev.staging.azuredatabricks.net.custom-domain.com」のようなカスタムホスト名を割り当てました。このホスト名には、Databricksドライバーが要求する「特別な文字列」が含まれていたため、ドライバーはこの接続を受け入れました。
• トークン交換: プロキシはOIDC互換エンドポイントを公開しています。まずSegmentの認証情報を受け取り、それをもとにDatabricksにアクセスして「本物の」OAuthトークンを取得します。その後、スピード向上のためこのトークンをキャッシュし、リクエストに挿入します。
• ヘッダーのクリーンアップ: プロキシはヘッダーをその場で整理・正規化し、リクエストがDatabricksに到達するときには完全にネイティブなリクエストのように見える状態になっています。

最終アーキテクチャ

リクエストフロー: