オンプレミスと GCP 間のネットワーク接続

こんにちは、IT 基盤部ネットワークグループの谷崎です。

DeNA のインフラは現在オンプレミスデータセンタ（以下、オンプレ DC）からパブリッククラウド（以下、クラウド）へ移行の過渡期にあります。
そこで我々ネットワークグループはオンプレ DC とクラウド間のセキュアな通信を提供すべく、プライベートネットワークを設計、実装しました。
今回はその中でも GCP とのプライベートネットワーク（以下、内部通信）についてご紹介いたします。

なお、3 月開催の DeNA TechCon 2020 にて AWS との内部通信を含めたセッション内容で登壇いたします。
興味のある方は足をお運びいただけますと幸いです。

従来の構成

全社的なクラウドへの移行方針が決定する以前から小規模にはクラウドを利用しており、GCP との内部通信は下記のような構成で運用していました。

各プロジェクトの VPC で Cloud VPN、および VPN トンネルを作成
オンプレ Firewall で各プロジェクトの VPC と対になる IPsec VPN、および VPN トンネルを設定

従来の運用課題

上記の構成は内部通信する VPC 分、IPsec VPN を追加設定する設計であるため、下記の運用課題を抱えていました。

ネットワークグループの作業に 3 日程度のリードタイム
IPsec VPN 設定管理の煩雑化
ネットワーク構成の複雑化

DeNA では多様に存在するサービス毎に複数のプロジェクトを利用するため、これらの課題は GCP の利用拡大に伴いより顕著になることが想定されました。
そこで我々はこれらの課題解決のために GCP Shared VPC (以下、Shared VPC) を導入しました。

Shared VPC の概要

Shared VPC は Shared VPC 内に作成した Subnet の利用権限を別プロジェクトに付与することができます。
これにより Cloud VPN を含む VPC 関連のリソースは Shared VPC によって一元管理でき、利用者は管理された VPC 内で GCE や GKE を利用することができます。

Shared VPC を用いた構成

下記のような構成で Shared VPC を運用しています。

Shared VPC で Cloud VPN、および VPN トンネルを作成
オンプレ Firewall で Shared VPC と対になる IPsec VPN、および VPN トンネルを設定
Shared VPC で利用者用の Subnet を作成、および権限付与

Shared VPC の導入効果

Shared VPC の導入により、複雑な IPsec VPN の設定や管理から解放されたため、先に挙げた課題はいずれも下記の通り解消されました。

ネットワークグループの作業に 3 日程度のリードタイム

必要な作業は Shared VPC での Subnet 作成、および利用者への権限付与のみとなったため、10 分程度で利用者に内部通信環境を提供することが可能になった

IPsec VPN 設定管理の煩雑化、ネットワーク構成の複雑化

オンプレ DC と GCP 間は Shared VPC が繋がる IPsec VPN のみの非常にシンプルな構成になった

Shared VPC の運用課題

Shared VPC の導入により、従来の構成と比べて大幅に運用負荷が軽減しましたが、Shared VPC ならではの課題もあります。
以下はその一例です。

未サポートのサービス

執筆時点では GAE Standard など Shared VPC でサポートされていないサービスもあります。
ただし、未サポートのサービスも徐々にサポートされる傾向にあるため、今後のサポートサービス拡大に期待します。

Firewall rule 管理

VPC を一元管理しているため Firewall Rule も Shared VPC で一元管理されます。
これは共通の Firewall Rule を全ての Subnet に適用できる（セキュリティホールを未然に防ぐ）メリットがある一方で、プロジェクトによって異なる通信要件を Shared VPC で全て管理する必要があるため、煩雑化します。