プライベート接続

概要

プライベート接続は、Virtual Private Cloud（VPC）ネットワークと Datastream のプライベートネットワーク間の接続であり、データストリームは内部 IP アドレスを使用してリソースと通信できます。プライベート接続を使用すると、Datastream ネットワーク上に、他のお客様と共有しない専用接続が確立されます。

プライベート接続を使用して、Datastream を任意のソースに接続できます。ただし、互いに直接通信できるのは、直接ピアリングされた VPC ネットワークだけです。

推移的ピアリングはサポートされていません。Datastream がピアリングされているネットワークが、ソースがホストされているネットワークでない場合は、リバースプロキシが必要です。ソースが Cloud SQL の場合と、ソースが別の VPC または Google ネットワークの外部でホストされている場合、リバースプロキシが必要になります。

このページでは、プロキシを使用して Datastream と Cloud SQL の間、または Datastream と別の VPC または Google ネットワークの外でホストされているソースとの間でプライベート接続を確立する方法について説明します。

Cloud SQL にリバースプロキシが必要な理由

プライベート IP アドレスを使用するように Cloud SQL for MySQL または Cloud SQL for PostgreSQL インスタンスを構成する場合は、VPC ネットワークと、Cloud SQL インスタンスが存在する基盤となる Google サービスの VPC ネットワーク間の VPC ピアリング接続を使用します。

Datastream のネットワークは Cloud SQL のプライベートサービスネットワークと直接ピアリングできません。また、VPC ピアリングが推移的ではないため、Datastream から Cloud SQL インスタンスに接続するための Cloud SQL のリバースプロキシが必要です。

次の図は、リバースプロキシを使用して Datastream と Cloud SQL 間のプライベート接続を確立する方法を示しています。

Datastream のユーザーフロー図

別の VPC でホストされているソースに対してリバースプロキシが必要なのはなぜですか？

Datastream の VPC ネットワークが VPC ネットワーク（「Network1」）とピアリングされており、ソースが別の VPC ネットワーク（「Network2」）からアクセスできる場合、Datastream はソースとの通信に VPC ネットワークピアリングのみを使用できません。また、Datastream とソースの間の接続をブリッジするため、リバースプロキシも必要です。

次の図は、リバースプロキシを使用して、Datastream と Google ネットワークの外部でホストされるソースとの間にプライベート接続を確立する方法を示しています。

Datastream のユーザーフロー図

リバースプロキシを設定する

Datastream がソースに接続する VPC ネットワークを特定します。
この VPC ネットワークで、基本的な Debian または Ubuntu イメージを使用して新しい仮想マシン（VM）を作成します。この VM はリバースプロキシをホストします。
サブネットが Datastream と同じリージョンにあり、リバースプロキシがソースからではなくソースに転送されていることを確認します。
SSH を使用して VM に接続します。SSH 接続の詳細については、SSH 接続についてをご覧ください。
プロキシ VM がソースと通信できることを確認するには、VM からソースの内部 IP アドレスとポートに ping または telnet コマンドを実行します。
プロキシ VM で、次のコードを使用して起動スクリプトを作成します。起動スクリプトの詳細については、Linux VM で起動スクリプトを使用するをご覧ください。
```
#! /bin/bash

export DB_ADDR=[IP]
export DB_PORT=[PORT]

export ETH_NAME=$(ip -o link show | awk -F': ' '{print $2}' | grep -v lo)

export LOCAL_IP_ADDR=$(ip -4 addr show $ETH_NAME | grep -Po 'inet \K[\d.]+')

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p tcp -m tcp --dport $DB_PORT -j DNAT \
--to-destination $DB_ADDR:$DB_PORT
iptables -t nat -A POSTROUTING -j SNAT --to-source $LOCAL_IP_ADDR
```
とプレースホルダ　[IP]　および　[PORT]　をソースの内部 IP アドレスとポート番号に置き換えます。このスクリプトでは、ソースの IP アドレスを指定する必要があります。ホスト名が IP アドレスに解決されることはありません。
このスクリプトは、VM が再起動するたびに実行されます。
Datastream でプライベート接続構成を作成して、VPC とDatastream の VPC との間に VPC ピアリングを確立します。
プライベート接続用に選択した IP アドレス範囲からのトラフィックがファイアウォールルールで許可されていることを確認します。
Datastream で接続プロファイルを作成します。

重要: 接続の詳細には、プロキシをホストする VM の内部 IP アドレスとポートを入力します。
注: Datastream で MySQL ソースと宛先の間のプロキシとして ProxySQL を使用する場合は、mysql_users テーブルで fast_forward フラグを 1 に設定する必要があります。詳細については、ProxySQL のドキュメントをご覧ください。

リバースプロキシの設定に関するベストプラクティス

このセクションでは、ゲートウェイとプロキシ VM を設定するときに使用するベストプラクティスについて説明します。

マシンタイプ

最適なマシンタイプを判断するには、簡単な設定から始めて、負荷とスループットを測定します。使用量が少なく、スループットのピークが問題なく処理される場合は、CPU 数とメモリ量を減らすことを検討してください。たとえば、スループットが最大 2 GBps の場合は、n1-standard-1 マシンタイプを選択します。スループットが 2 GBps を超える場合は、e2-standard-2 マシンタイプを選択します。e2-standard-2 は、効率性を重視する費用対効果の高い構成です。

アーキテクチャの種類

非高可用性（HA 以外の）インスタンス

任意のオペレーティングシステムを備えた単一の VM をデプロイします。復元力を高めるには、単一の VM でマネージドインスタンスグループ（MIG）を使用します。VM がクラッシュした場合、MIG では失敗したインスタンスが再作成されて自動的に修復されます。詳しくは、インスタンスグループをご覧ください。

高可用性（HA）インスタンス

それぞれが別のリージョン（該当する場合）または別のゾーンにある 2 つの VM を使用して MIG を設定します。MIG を作成するには、グループで使用できるインスタンステンプレートが必要です。MIG は、内部のネクストホップ IP アドレスを使用して、内部のレイヤ 4 ロードバランサの背後に作成されます。

次のステップ

プライベート接続構成を作成する方法を学習する。