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

by Takaaki Tanizaki | April 14, 2020
network | #aws #infrastructure #network

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

前回の私の記事で、オンプレミスと GCP 間のネットワーク接続についてご紹介させていただきました。
今回は DeNA Techcon 2020 でご紹介する予定だった、AWS とのプライベート接続についてご紹介させていただきます。

従来の構成と運用課題

AWS との内部通信は下記のような構成で運用していました。

  • 各アカウントの VPC で Virtual Private Gateway、および Site-To-Site VPN トンネルを作成
  • オンプレ Firewall で各 Virtual Private Gateway と対になる IPsec VPN、および VPN トンネルを設定

しかしこの構成は下記の運用課題を抱えていました。

  1. 通信品質
    • IPsec VPN はインターネット通信のため通信品質が保証されない
  2. 設定管理の煩雑化・構成の複雑化
    • VPC と 1:1 で設定を追加する必要がある
  3. リードタイム
    • ネットワークグループでの作業に 3 日程度のリードタイムを要する

今回は我々ネットワークグループがこれらの課題をどのように解決して、現在どのような構成で運用しているのかご紹介します。

「1. 通信品質」の解消

まず我々はロスの許されない大容量なデータ移行にも耐えうる通信品質を担保するため、AWS Direct Connect を採択しました。
AWS Direct Connect とは AWS との専用線接続サービスで DeNA では 10G * 2 本の Direct Connect Connections で導入しました。
この導入により、オンプレミスとの接続は下記の構成となり、通信品質は担保される状態となりました。

  • データセンタと AWS 間を Direct Connect 接続
    • 10G x 2 Dicrect Connect Connections
  • Virtual Private Interface x Virtual Private Gateway 構成

これにより、「1. 通信品質」は解消されましたが、この構成も各アカウントの VPC とオンプレミス側で対になる接続設定が必要なため、 2, 3 の課題は残存しました。

  1. 通信品質
    • IPsec VPN はインターネット通信のため通信品質が保証されない
    • 専用線サービス AWS Direct Connect の導入によって解消
  2. 設定管理の煩雑化・構成の複雑化
    • VPC と 1:1 で設定を追加する必要がある
  3. リードタイム
    • ネットワークグループでの作業に 3 日程度のリードタイムを要する

「2. 設定管理の煩雑化・構成の複雑化」の解消

次に我々は AWS の利用拡大にも追従しうるシンプルかつスケーラブルな構成を求め、AWS Transit Gateway (以下、TGW) を採択しました。
TGW は VPC 間の通信をハブアンドスポーク型で実現できるマネージドなルータのサービスです。
この導入により、オンプレミス、および VPC 間の接続は下記のような構成になりました。

  • VPC 間の通信は TGW 折り返しでルーティング
  • オンプレとの通信は TGW と接続した AWS Direct Connect Gateway 経由でルーティング
  • オンプレミス、および各 VPC が TGW を中心としたハブアンドスポーク型の構成

これにより、「2. 設定管理の煩雑化・構成の複雑化」も解消解消されました。

  1. 通信品質
    • IPsec VPN はインターネット通信のため通信品質が保証されない
    • 専用線サービス AWS Direct Connect の導入によって解消
  2. 設定管理の煩雑化・構成の複雑化
    • VPC と 1:1 で設定を追加する必要がある
    • オンプレミス、および各 VPC 間の通信をハブアンドスポーク型で可能とする AWS Transit Gateway の導入で解消
  3. リードタイム
    • ネットワークグループでの作業に 3 日程度のリードタイムを要する

「3. リードタイム」の改善

先の TGW の導入により、オンプレミスとの接続が TGW での終端となったため従来のような各 VPC と対になる設定は不要となり、リードタイムに関しても大幅に改善されました。

しかし、TGW と各 VPC をアタッチする設定は必要で、設定はブラウザ上のコンソールから行なっていました。
そこで我々は TGW を含む関連リソースを全て Terraform によってコード化しました。
これにより、リードタイムの改善に付随して、コードレビューや DRY-RUN を介する事によるヒューマンエラーのリスクも減りました。

  1. 通信品質
    • IPsec VPN はインターネット通信のため通信品質が保証されない
    • 専用線サービス AWS Direct Connect の導入によって解消
  2. 設定管理の煩雑化・構成の複雑化
    • VPC と 1:1 で設定を追加する必要がある
    • オンプレミス、および各 VPC 間の通信をハブアンドスポーク型で可能とする AWS Transit Gateway の導入で解消
  3. リードタイム
    • ネットワークグループでの作業に 3 日程度のリードタイムを要する
    • TGW の導入によってオンプレミス側の設定は不要になり改善
    • Terraform によるコード化により改善

最終的な構成

これらを経て現在 DeNA では下記のような構成で AWS とのプライベート接続を運用しています。

終わりに

以上、オンプレ DC と AWS との内部通信をご紹介させていただきました。
本ブログの内容が少しでも皆様のお役に立ちましたら幸いです。

以上、最後までお読みいただき、ありがとうございました。