[Azure][GCP]PSCエンドポイントでインターネットを通らないBigQuery環境を実現する！[BigQuery]

Azure

Azureからインターネットを通さずにBigQueryにリクエストを投げたくてVPNトンネル経由でGCPのエンドポイントを叩ける環境を構築した。
(PSC:Private Service Connect)

AWSのDirect Connect、GCPのCloud Interconnect,Azure Express Routeに代表される閉域網でも同様の構成を実現可能だ。

  1. 試したこと
  2. Azure vNetからの名前解決
    1. PSCエンドポイント名前解決の流れ
    2. *.p.googleapis.comゾーンの自動更新
    3. プライベートDNSゾーン自動構成に必要となるAPI
  3. BigQueryとアプリケーション間の通信
    1. データアクセスパス
  4. PSCエンドポイント経由のBigQueryアクセス
    1. AzureでBQコマンドの実行
    2. BigQueryのログ
  5. あとがき

試したこと

  • Azureからインターネットを通さずVPN経由でBigQueryにアクセスする
  • AzureからCloud DNSでGCP PSCエンドポイントのゾーンを解決する

Azure vNetからの名前解決

PSCを作成すると、*.p.googleapis.comに対応するプライベートゾーンがCloud DNSに作成される。このゾーンはPSCに紐づけるサービスディレクトリにより管理され、PSCに対応するGCPサービスのサブドメインとPSCエンドポイント名を結合したレコードセットが自動的に登録される。平たく言うとstorage-psc.p.googleapis.comだったり、bigquery-psc.p.gogleapis.comといったサブドメインがゾーンに自動作成され、VPC外のホストはその名前をPSCの内部IPアドレスに解決することでインターネットに出ずにGCPのマネージドサービスを使える仕組みだ。
また、新しいサービスがGCPに追加されたときもプライベートゾーンへ対応するサブドメインが自動追加され、ユーザーはなにもせずともプライベートサービスコネクト経由で新しいサービスにアクセスできるようになる。

PSCエンドポイント名前解決の流れ

  1. Azure vNetのアプリケーションからBigQueryにリクエスト(REST API)を実行
  2. アプリケーションからAzure vNetに構成されたDNSサーバーへbigquery-psc.p.googleapis.comの名前を問い合わせ
  3. DNSサーバーは自身のForwarding Ruleに基づきCloud DNSの受信ポリシーエンドポイント(10.128.0.3)にDNSクエリを転送
  4. GCP上のCloud DNSの受信ポリシーエンドポイント(10.128.0.3)がバックエンドの*.googleapis.comゾーンのレコードセットを参照
  5. bigquery-psc.p.googleapis.comに対応するPSCエンドポイントのIPアドレス(10.128.0.2)をAzure上のIaaS DNSサーバーに回答
  6. Azure上のIaaS DNSサーバーがアプリケーションにPSCエンドポイントのIPアドレス(10.128.0.2)を回答
  7. アプリケーションがPSCエンドポイント(10.128.0.2)経由でBigQueryにリクエストを送信

*.p.googleapis.comゾーンの自動更新

新しいGCPサービスがリリースされたり、既存のサービスがリタイアした場合でも利用者が明示的に*.p.googleapis.comゾーンに対応するDNSレコードセットをメンテナンスする必要はない。

  1. Google Cloud Platformにサービスのアップデートが発生(例えば新サービスのリリース)
  2. Service DirectoryがGCPからアップデートを受け取る
  3. Service Directoryの紐づくCloud DNSプライベートゾーン(*.p.googleapis.com)に新サービスのエントリが自動で追加される
Cloud DNSプライベートゾーン(*.p.googleapis.com)はPSCエンドポイント作成時にそのPSCと同じService Directoryに紐づく形で自動で作成される。

プライベートDNSゾーン自動構成に必要となるAPI

PSCエンドポイント作成の前にCloud DNS APIを先に有効化しておく必要がある。有効化よりも前にPSCを作成するとプライベートDNSゾーンは構成されなかった
file

BigQueryとアプリケーション間の通信

この構成ではBigQueryへのアクセスはPSCエンドポイントを通じてインターネットに出ずに完結する。

データアクセスパス

file

  1. アプリケーションがBigQueryに対応するPSCエンドポイント(bigquery-psc.p.googleapis.com)のIPを得る
  2. アプリケーションがPSCエンドポイントにREST APIを投げる
  3. REST APIがPSCでアドレス変換(NAT)されBigQueryに到達する

PSCエンドポイント経由のBigQueryアクセス

AzureでBQコマンドの実行

Azure VMからBigQueryの編集者ロールを持つサービスアカウントでクエリを実行するとPSCエンドポイント経由でデータセットからレコードが得られた。

$ bq  --api https://bigquery-psc.p.googleapis.com query --nouse_legacy_sql "SELECT timestamp,vacancy from cloudibledotjp.test.room_vacancy"

+---------------------+---------+
|      timestamp      | vacancy |
+---------------------+---------+
| 2019-05-02 12:48:35 |    true |
| 2019-05-03 12:49:31 |    true |
+---------------------+---------+
bqコマンドでは--apiオプションによりBigQuery APIのエンドポイントをPSCエンドポイントの名前にオーバーライドしてある。

BigQueryのログ

GCPのCloud Loggingを確認すると、たしかにAzure vNetの範囲からBigQueryへアクセスがあったことがわかる。

送信元 クエリ
"callerIp": "172.16.0.2" "query": "SELECT timestamp,vacancy from cloudibledotjp.test.room_vacancy" 
{
//リクエスト ぺイロード
    "requestMetadata": {
      "callerIp": "172.16.0.2",
      "callerSuppliedUserAgent": "(gzip),gzip(gfe)",
//////////////
          "jobConfiguration": {
            "query": {
              "query": "SELECT timestamp,vacancy from cloudibledotjp.test.room_vacancy",
//////////////
}

あとがき

GCPではPSCエンドポイントを名前解決するためのCloud DNS受信エンドポイントをIaaS不要で構成できるので気軽に別のクラウドやオンプレミスサイトからプライベートにGCPのマネージドサービスへアクセスさせることができる。
なお、PSCエンドポイントはグローバルリソースであり、VPC上のすべてのリージョンから共有できるメリットがありつつも、AzureやAWSと異なりエンドポイントを既存VPCサブネットの範囲に収めることができずはみ出てしまう点については従来の感覚でIPを割り当てる組織では知っておいて損はないだろう。

タイトルとURLをコピーしました