GCPのCloud ComposerからSSHトンネリングでAWSのDocumentDBへ接続する構成事例

こんにちは。cocone connectでインフラエンジニアを担当しているYです。

 

今回はGCPのCloud ComposerとAWSのDocumentDB間をSSHトンネリングで疎通させる構成を設計・構築した際の事例をご紹介いたします。
普段はAWSを触ることが多いのですが、今回初めてGCPを触ったため個人的にGCPの作業で気になった点などもまとめてみました。

構成について



 
弊社の開発中のプロダクトを参考事例として全体の構成図をご紹介いたします。
 
ゲームサーバーはAWS上に構築しておりまして、DBサーバーとしてDocumentDB(Mongo)を採用しております。
KPIデータの収集、集計、加工にはGCPのCloud ComposerとBigQueryを使用しております。それぞれのクラウドの得意分野を使い分けて運用している構成になります。
 
GCPからAWSへの通信の流れに着目すると以下になります。
 

Cloud Composer → Tunnelサーバー → Cloud NAT → AWS側踏み台(Bastion)サーバー → DocumentDB

 


 
DocumentDBはAWSのPrivate Subnet上にクラスターが生成されます。
VPNを張らない場合はPublic Subnet上に構築したBastionサーバーを跨いでSSHトンネリングで接続することになります。
 
GCP側にはTunnelサーバーというインスタンスが立っております。
このインスタンスにSSHトンネリングの設定を入れ、ComposerがTunnelサーバーを経由してDocumentDBに接続できるようにしています。
 
Composerに直接SSHトンネリング設定を入れることも出来たかもしれませんが、今回はインフラ側で対応してます。
(BigQueryとComposerの実装は別チームが担当しているためインフラ側で出来ることは設計でカバーしました)
 
補足として、TunnelサーバーにはグローバルIPの直接付与をしてません。
 
セキュリティ上のリスクを避ける観点から、GCPから外に出ていく通信は全てCloud NATを通過するようにし、AWS側ではCloud NATのグローバルIPのみ通信許可しております。

SSHトンネリング設定でハマった点について

AWSの公式ドキュメントを見つつ、DocumentDBに外部から接続するためのSSHトンネリング設定を構築していたのですが、記載されているコマンドがlocalhostからDocumentDBへ接続するケースのみでした。
 

#Tunnelサーバー上でSSHトンネリングを有効化
hoge@tunnel-server:~$ ssh -i "private key" -L 27018:{DocumentDB_endpoint_URI}:27017 {Bastion_username}@{Bastion_host} -N -f

上記設定後、Tunnelサーバー(自分自身)の27018ポートに対してアクセスすると、AWSのBastionサーバーを経由してDocumentDBにポートフォワーディングされ接続出来ます。
 

#プログラムから接続する場合
mongodb://{user}:{password}@localhost:27018/{DBname}
#mongo shellをインストールしている場合以下のコマンドでも接続可能
hoge@tunnel-server:~$ mongo --host localhost --port 27018 --username {user} --password {password}

上記の場合、localhostからしか接続が出来ません。
 
今回のケースでは別ホスト(composer)からTunnelサーバーを経由して接続するため、Listen IPアドレス(0.0.0.0:27018)を指定する必要がありました。
 

#tunnelサーバー上でListen IPアドレスを指定してSSHトンネリングを有効化
hoge@tunnel-server~$ ssh -i "private key" -L 0.0.0.0:27018:{DocumentDB_endpoint_URI}:27017 {Bastion_username}@{Bastion_host} -N -f

上記設定後、別ホストからTunnelサーバー経由で接続できるようになりました。
 

#プログラムから接続する場合
mongodb://{user}:{password}@{Tunnel_host}:27018/{DBname}
#mongo shellをインストールしている場合以下のコマンドでも接続可能(GCPのBastionサーバーから接続してみた例)
hoge@bastion-server:~$ mongo --host {Tunnel_host} --port 27018 --username {user} --password {password}

意外と事例が少なく苦戦しましたが、終わってみると初歩的なミスで悔しいところです。

GCPのVMインスタンス構築で印象に残った点について

若干本題から外れますが、今回初めてGCPでVMインスタンス構築をしてみて便利だなと思った点をまとめます。
 
GCPで作成したインスタンスにはデフォルトでgcloudコマンドが入っているため、gcloudコマンドで操作すると煩わしい設定などを自動で実行してくれます。
 
例えばBastionサーバーにはローカルPCから以下のようなコマンドを実行することでSSHログインできます。
(事前にローカルPCにgcloud cliをインストールして”gcloud auth login”しておく必要があります)
 

hoge@local-pc:~$ gcloud compute ssh --zone "asia-northeast1-b" "{Bastion-server-hostname}"  --project "tech-blog-project"

鍵ペアが自動で生成され、ゾーン、ホスト名、GCPプロジェクト名を指定するだけでログイン出来るので非常に楽でした。
 
しかもログイン時は自分のGoogleアカウントに紐づくため、ユーザーごとにアカウントを分ける運用が自然に出来るのが嬉しいところ。
 
 
BastionサーバーからTunnelサーバーに接続する際もgcloudコマンドが使えます。
(gcloudコマンドはデフォルトで入ってますが事前に”gcloud auth login”しておく必要があります)
 

hoge@bastion-server:~$ gcloud compute ssh {tunnel-server-hostname} --internal-ip --zone "asia-northeast1-b"

#tunnelサーバーにsshログイン出来る
hoge@tunnel-server:~$

このコマンドを実行すると自分のGoogleアカウントに紐づいたLinuxユーザーと鍵ペアを自動で作成してくれます。
useraddでユーザーを作成、鍵ペア生成、公開鍵を登録…などの手間が無くて楽でした。
 
ちなみに、今回はインフラメンバー共通で使用するLinuxユーザーも必要だったのでuseraddで作成しようとしましたが、GCP管理コンソールから公開鍵情報をインスタンスに登録するだけでユーザーを自動で生成してくれる機能もありGCP楽チンだなぁと思った次第。

以下簡易手順です。

① Bastionサーバーで鍵ペアを作成
 
② ユーザー名を指定して鍵ペアを作成

hoge@bastion-server:~$ ssh-keygen -t rsa -C tech-blog-user

 
③ 作成した公開鍵情報をGCP管理コンソールの
 

Compute Engine → VMインスタンス → Tunnelサーバー → インスタンスの編集

 
からSSH認証鍵の項目に鍵情報を追加して保存



 
④ ユーザーの生成と公開鍵の登録まで自動で完了するのでBastionサーバーからTunnelサーバーに鍵ペア作成時に指定したユーザーでSSHログイン
 

hoge@bastion-server:~$ ssh -i "private key" tech-blog-user@{Tunnnel_host}

#tech-blog-userでtunnelサーバーにログインが出来る
tech-blog-user@tunnel-server:~$

もちろん普通にLinuxコマンドも使えますので、gcloudコマンドが使用できないプログラム等でインスタンスを操作する場合は、通常のLinuxコマンドと併用して運用する形になります。

まとめ

省略した箇所も多いですが、弊社プロダクトのGCPとAWS間のデータ連携の構成についてご紹介しました。
 
構築中はなかなか苦戦しましたが、各サービスの繋ぎ込みが上手くいってcomposerでデータを取得できた瞬間は非常に嬉しかったです。
 
GCPを今回初めて触ってみて、AWSと似た要素もありますが、思想や概念は結構違うものがあると感じました。
 
GCPは必要最低限の設定と機能を有効化したら大部分の設定をクラウド側で巻き取ってくれるので、構築や運用の負荷が少なくシンプルに利用できる印象を受けました。
 
AWSはニーズに応えるためのマネージドサービスが大量にあり、設定も詳細に調整可能です。複数のサービスを組み合わせることで、さまざまなユースケースに対応できることが魅力に感じますが、その分インフラ運用が複雑化する可能性も考えられます。
 
どちらが優れているかは何とも言えないですが、複数のクラウドサービスを組み合わせることで要件に適したサービス運用やKPI分析を実現させることができますので、さまざまなインフラ技術に触れることで臨機応変に対応できるスキルが重要だなと感じました。
 
今回の記事がインフラ設計・構築をされる際の参考になれば幸いです。

 


ココネでは一緒に働く仲間を募集中です。

ご興味のある方は、ぜひこちらの採用特設サイトをご覧ください。

https://www.cocone.co.jp/recruit/contents/

Category

Tag

%d人のブロガーが「いいね」をつけました。