オンプレミスとパブリッククラウドのネットワーク接続【DeNA TechCon 2021】/techcon2021-7

DeNA ではオフィスやデータセンタなどのオンプレミスネットワークは全てネットワークチームが管理しています。
私達はオンプレミスのデータセンタで大規模なインフラを長年運用してきましたが、ほぼ全てのサービスをクラウドに移行する全社方針が決定しました。
DeNA の事業は多岐にわたり、またサービス毎に複数のクラウドアカウントを利用するため、非常に多くのクラウドアカウントが必要となります。大規模なクラウドの移行にあたり、多数のクラウドアカウント、データセンタ、オフィス間のベストなネットワークを設計する必要がありました。
そこで私達は AWS TransitGateway、および GCP SharedVPC の利用を選択しました。
本セッションではこれらを用いた DeNA のハイブリッドネットワーク設計や導入による効果、運用ノウハウなどを紹介いたします。

Transcript

1. 谷崎 貴章
2. (Tanizaki Takaaki) 所属 • システム本部 IT統括部 IT基盤部 ネットワークグループ 経歴 • 2016 年 DeNA に中途入社 ネットワークグループの業務 • データセンタ/クラウドネットワーク • 本社/拠点オフィスネットワーク • CDN (Content Delivery Network) 2
3. • 背景 • オンプレミスと AWS のネットワーク接続 • オンプレミスと GCP のネットワーク接続 • まとめ 3
4. 2018年6月、DeNA のほぼ全てのサービスを運用し てきたオンプレミスデータセンタを捨て、パブリッ ククラウドに移行する全社方針が決定 4
6. データセンタや本社オフィスなどのオンプレミスと パブリッククラウド間のプライベートネットワーク 環境の提供 6
7. プライベートネットワークとは • インターネットから隔離されたネットワーク • プライベート IP アドレスを用いた LAN 通信 • 例えば、自宅やオフィス内、データセンタ内の ネットワーク 7
8. 8 ネットワークグループが提供する プライベートネットワークは...
9. ヒカリエ本社や拠点オフィス、データセンタ、 AWS、GCP などの全ネットワークをプライベート ネットワークとして LAN 通信を実現 9 プライベートネットワーク
10. 10 なぜプライベートネットワークが必要か...
11. 大規模なデータ移行をセキュアでロスの無い 安定したネットワークで実現するため 11 プライベートネットワークの必要性
15. VPC とインターネット経由の Site-to-Site VPN で オンプレミスと接続 15
16. • 通信品質 ◦ Site-to-Site VPN はインターネット経由の通信の ため通信品質が保証されない ◦ AWS 側の頻繁な通信影響を伴うメンテナンス • 設定やネットワーク構成の複雑化 ◦ VPC と 1:1 でオンプレミス側も VPN 設定を追加 する必要がある 16
17. 17 ネットワークグループが提供したい プライベートネットワーク
18. • 広帯域で安定した通信品質 ◦ 大規模かつミッションクリティカルな用途 • スケーラブル ◦ VPC の急速な利用拡大に追従 18
20. • AWS の専用線接続サービス • オンプレミスデータセンタと AWS 間を接続 ◦ 10Gbps x 2 本 Direct Connect Connections 20
21. 21 • 広帯域で安定した通信品質 ◦ 大規模かつミッションクリティカルな用途 ▪ AWS Direct Connect の導入 • 10Gbps x 2 本の専用線接続 • スケーラブル ◦ VPC の急速な利用拡大に追従
22. • Virtual Private Interface x Virtual Private Gateway 構成 22
23. 23 2019/9 Direct Connect Gateway が Transit Gateway をサポート
24. • VPC 間をハブアンドスポーク型で接続すること が可能なマネージドルータサービス • Direct Connect Gateway へのアタッチが可能 ◦ Direct Connect 経由で Transit Gateway を 利用可能 24
25. • VPC 間の通信には 1:1 の VPC Peering が必要 • 多量の VPC を利用する DeNA 環境ではフルメッ シュ構成は実現不可能 25
26. • Transit Gateway を中心としたハブアンドス ポーク型の構成になる • 非常にシンプルかつスケーラブル 26
27. 27 • 広帯域で安定した通信品質 ◦ 大規模かつミッションクリティカルな用途 ▪ AWS Direct Connect の導入 • 10Gbps x 2 本の専用線接続 • スケーラブル ◦ VPC の急速な利用拡大に追従 ▪ AWS Transit Gateway の導入 • ハブアンドスポーク型の構成
30. • Transit Gateway に接続した VPC 宛ての経路を Transit Gateway の Route Table に自動追加す る機能 • デフォルトで有効化 30
35. • 管理アカウントで作成した共通の Security Group を利用アカウントに対して適用するサービ ス 35
39. 39 VPC とインターネット経由の Site-to-Site VPN で オンプレミスと接続
40. • 通信品質 ◦ Site-to-Site VPN はインターネット経由の通 信のため通信品質が保証されない • 設定やネットワーク構成の複雑化 ◦ VPC と 1:1 でオンプレミス側も VPN 設定を追加 する必要がある 40
41. • 広帯域で安定した通信品質 ◦ 大規模かつミッションクリティカルな用途 • スケーラブル ◦ VPC の急速な利用拡大に追従 41
43. • VPC 内の Subnet を異なるプロジェクトで利用す ることができる 43
44. • 管理者は VPC や Firewall Rule, Cloud VPN を一 元管理できる • 利用者は管理された VPC 内で GCE や GKE を利 用できる 44
45. 45 • 広帯域で安定した通信品質 ◦ 大規模かつミッションクリティカルな用途 • スケーラブル ◦ VPC の急速な利用拡大に追従 ▪ Shared VPC の導入 • VPC, Firewall Rule, Cloud VPN などの VPC 関連リソースを一元管理
48. • Shared VPC 環境においては Firewall Rule は一 元管理できる • 一方で Firewall Rule は 1 箇所になるため、利用 者にその変更権限を付与すると全ての Firewall Rule を変更できてしまう • 結果的に変更権限が管理者に依存する 48
49. 49 • ほぼ全てのリソースを Terraform コード化 • Terraform コードを Github リポジトリで管理 • Subnet に紐付く Firewall Rule を git submodule 化 • Submodule リポジトリの権限を利用者に付与
50. 50 • Terraform + Github + git submodule を用いて擬似 的に権限分離を実現
52. • 急速なクラウド利用拡大に追従する ◦ AWS: Transit Gateway ◦ GCP: Shared VPC • スケーラブルかつ低運用コストで管理できる構成を採 択 52