Google Cloud Application Integrationからオンプレミスのシステムへ接続する方法
はじめに
皆様こんにちは。
Google Cloud で Apigee/Application Integration の Specialist CE(Customer Engneer)をしているMitchです。
Application Integration は小規模から大規模まで利用できるハイスケールな iPaaS サービスですので興味がある方はぜひ触ってみてください。(無料枠あります)
この記事では Application Integration からオンプレミスや他社クラウドのシステム/サービスへ接続する方法について紹介します。
TL;DR
- Application Integration & Integration Connector は Google テナントで動作している
- Google テナントと Customer VPC は PSC を経由して接続
- VPC から ILB -> NEG を通ってオンプレミスや他社クラウドのリソースへ接続可能
Application Integration における外部接続
Application Integration から統合対象となるシステムやサービスへ接続するにはいくつかの方法があります。対象が REST エンドポイントを持つ場合には REST エンドポイントの呼び出しタスク を利用して安価に行えますが、REST エンドポイントの呼び出しタスクは対象がパブリック(Public IP を持つ)な場合かつ、テキストベースでの HTTP 通信である場合にのみ利用可能です。
一部タスク化されている Google サービスを除き、通信にバイナリが含まれる場合や FTP や DB 接続など HTTP 以外のプロトコル、プライベートネットワークに接続しに行く場合などは Integration Connector による接続が必要となります。
今回特に「オンプレとか他社クラウドのプライベートリソースにはどうやって繋ぐのか?」という質問を受けることが多いので、その実現方法を見ていきます。
前提とステップ
Application Integration / Integration Connector は Google Cloud 上で動作するサービスのため、前提としてGoogle Cloud の VPC とオンプレミスなどのプライベートネットワークとの接続が確立していることが前提となります。
もし手元にプライベートネットワークがない場合は、Google Cloud 上に別 VPC を用意し、そことCloud VPN を介して繋ぐことで検証も可能です。
このあたりの詳細については Seiji さんが素敵な記事を書いているのでそちらを参照してください。
今回は用意した別のプライベートネットワーク上にある SFTP サーバに対して Application Integration から接続してみましょう。
具体的な手順としては以下になります。
STEP1. ハイブリッド接続 NEG の作成
STEP2. 内部ロードバランサの作成
STEP3. 公開サービスの作成
STEP4. エンドポイントアタッチメントの作成
STEP5. コネクタ接続の作成
それぞれの設定方法見ていきます。
STEP1. ハイブリッド接続 NEG の作成
Integration Connector は Google 管理の VPC 上で動作しており、Private Service Connect (PSC) を利用して Customer VPC の ILB へ接続します。そこから Cloud VPN や Interconnect の先にある別ネットワークのリソースへ接続しにいくので、 ロードバランサー及び ハイブリッド接続 NEG (Network Endpoint Group) が必要になります。
なのでまずは Google Cloud Console から Compute Engine -> ネットワークエンドポイントグループより新規でハイブリッド接続 NEG を作成します。
項目 | 値 |
---|---|
名前 | 適当な名称 |
ネットワーク エンドポイント グループの種類 | ハイブリッド接続 NEG (ゾーン) |
ネットワーク | 利用するVPCを選択 |
リージョン | VPC のリージョンを選択 |
ゾーン | ゾーンを選択 |
デフォルトポート | 22 |
処理が完了したら、作成した NEG のネットワークエンドポイントに SFTP サーバの Private IP アドレスを登録します。
項目 | 値 |
---|---|
IPアドレス | 接続対象のSFTPサーバのプライベートIPアドレス |
ポートタイプ | デフォルトを選択 |
STEP2. 内部ロードバランサの作成
STEP1 で作成した ハイブリッド接続 NEG への接続には アプリケーションロードバランサかネットワークロードバランサが必要となりますが、プライベートIPを持つ SFTP サーバへの通信となるので、ネットワークサービス -> ロードバランシング からリージョン内部プロキシネットワークロードバランサを作成します。
ロードバランサの構成
項目 | 値 |
---|---|
ロードバランサの名前 | 適当な名称 |
リージョン | VPCのリージョンを選択 |
ネットワーク | 利用するVPCを選択 |
まずバックエンドがら構成します。
バックエンドの構成
項目 | 値 |
---|---|
バックエンド タイプ | ハイブリッド接続ネットワーク エンドポイント グループ (ゾーン) |
プロトコル | そのまま |
タイムアウト | タイムアウト値を指定 |
ネットワーク エンドポイント グループ | STEP1で作成した Hybrid NEG を指定 |
最大接続数 | 任意の接続数 |
範囲 | 任意の範囲 |
容量 | 任意の容量 |
ヘルスチェック | ポート22番を使用するヘルスチェックを作成し選択 |
基本的に STEP1 で作成した ハイブリッド接続 NEG を構成するだけなので特段難しいことはないです。
次にフロントエンドを構成します。
フロントエンドの構成
項目 | 値 |
---|---|
名前 | 空白でOK |
サブネットワーク | リージョンのサブネットを選択 |
IPアドレス | エフェメラルでも固定でもどちらでも可 |
ポート番号 | 22 |
一通り設定ができたら、「作成」からロードバランサを作成します。
STEP3. 公開サービスの作成
SETP2 で作成されたロードバランサを PSC 経由で Integration Connector からアクセスできるようにするために、ネットワークサービス -> Private Service Connect から公開サービスを作成します。
項目 | 値 |
---|---|
ロードバランサの種類 | リージョン内部プロキシネットワークロードバランサ |
内部ロードバランサ | STEP2 で作成したものを選択 |
サービス名 | 任意の名前 |
サブネット | PSC用のサブネットを作成して選択 |
接続の設定 | Automatically accept all connections |
PSC 公開サービスを作成するには PSC が公開サービスへのリクエストを処理するためのサブネットが必要となるので、適当なレンジで作成してアサインします。
接続の設定は後で Integration Connnector 側から接続を行なった後にマニュアルで受け入れ許可も可能ですが、今回は自動で全ての接続を許可するようにします。
STEP4. エンドポイントアタッチメントの作成
ようやく接続の準備ができたので、今度は Integration Connector 側から STEP3 で作成した PSC の公開サービスに対して接続するために、インテグレーションコネクタ -> エンドポイントアタッチメント からエンドポイントアタッチメントを作成します。
項目 | 値 |
---|---|
name | 任意の名前 |
リージョン | VPCのリージョンを選択 |
Service Attachment | STEP3で作成した公開サービスの [サービスの接続] にある値 |
一度作成が完了するとエンドポイントアタッチメントに IP アドレスが振られていることが確認できます。
STEP5. コネクタ接続の作成
これでようやく Integration Connector から接続できるようになりました。
最後に Integration Connector の接続を設定すれば、Application Integration からアクセスできるようになります。
接続の設定を行う際、Destination は STEP4 のエンドポイントアタッチメントに振られた IP アドレスを指定するようにします。
接続確認とまとめ
実際に Application Integration から Connector タスクを用いて SFTP コネクタへ接続してみると、SFTP サーバ内のディレクトリを認識していることが確認できます。
慣れるまではロードバランサや NEG 、PSC など Google Cloud の色々な要素が関わってくるため少し混乱するかもしれません。
逆を言えばそれらが持っている機能を使ってより高度な構成を取ることも可能なため、プライベートネットワークへの接続も柔軟に行える iPaaS が必要な場合には良い選択肢になると思います。
Discussion