Save 37% off PRO during our Black Friday Sale! »

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

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

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

8a84268593355816432ceaf78777d585?s=128

DeNA_Tech

March 03, 2021
Tweet

Transcript

  1. 谷崎 貴章

  2. (Tanizaki Takaaki) 所属 • システム本部 IT統括部 IT基盤部 ネットワークグループ 経歴 •

    2016 年 DeNA に中途入社 ネットワークグループの業務 • データセンタ/クラウドネットワーク • 本社/拠点オフィスネットワーク • CDN (Content Delivery Network) 2
  3. • 背景 • オンプレミスと AWS のネットワーク接続 • オンプレミスと GCP のネットワーク接続

    • まとめ 3
  4. 2018年6月、DeNA のほぼ全てのサービスを運用し てきたオンプレミスデータセンタを捨て、パブリッ ククラウドに移行する全社方針が決定 4

  5. 5

  6. データセンタや本社オフィスなどのオンプレミスと パブリッククラウド間のプライベートネットワーク 環境の提供 6

  7. プライベートネットワークとは • インターネットから隔離されたネットワーク • プライベート IP アドレスを用いた LAN 通信 •

    例えば、自宅やオフィス内、データセンタ内の ネットワーク 7
  8. 8 ネットワークグループが提供する プライベートネットワークは...

  9. ヒカリエ本社や拠点オフィス、データセンタ、 AWS、GCP などの全ネットワークをプライベート ネットワークとして LAN 通信を実現 9 プライベートネットワーク

  10. 10 なぜプライベートネットワークが必要か...

  11. 大規模なデータ移行をセキュアでロスの無い 安定したネットワークで実現するため 11 プライベートネットワークの必要性

  12. 12

  13. 13

  14. 14

  15. VPC とインターネット経由の Site-to-Site VPN で オンプレミスと接続 15

  16. • 通信品質 ◦ Site-to-Site VPN はインターネット経由の通信の ため通信品質が保証されない ◦ AWS 側の頻繁な通信影響を伴うメンテナンス

    • 設定やネットワーク構成の複雑化 ◦ VPC と 1:1 でオンプレミス側も VPN 設定を追加 する必要がある 16
  17. 17 ネットワークグループが提供したい プライベートネットワーク

  18. • 広帯域で安定した通信品質 ◦ 大規模かつミッションクリティカルな用途 • スケーラブル ◦ VPC の急速な利用拡大に追従 18

  19. 19

  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 の導入 • ハブアンドスポーク型の構成
  28. 28

  29. 29

  30. • Transit Gateway に接続した VPC 宛ての経路を Transit Gateway の Route

    Table に自動追加す る機能 • デフォルトで有効化 30
  31. 31

  32. 32

  33. 33

  34. 34

  35. • 管理アカウントで作成した共通の Security Group を利用アカウントに対して適用するサービ ス 35

  36. 36

  37. 37

  38. 38

  39. 39 VPC とインターネット経由の Site-to-Site VPN で オンプレミスと接続

  40. • 通信品質 ◦ Site-to-Site VPN はインターネット経由の通 信のため通信品質が保証されない • 設定やネットワーク構成の複雑化 ◦

    VPC と 1:1 でオンプレミス側も VPN 設定を追加 する必要がある 40
  41. • 広帯域で安定した通信品質 ◦ 大規模かつミッションクリティカルな用途 • スケーラブル ◦ VPC の急速な利用拡大に追従 41

  42. 42

  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 関連リソースを一元管理
  46. 46

  47. 47

  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 を用いて擬似 的に権限分離を実現

  51. 51

  52. • 急速なクラウド利用拡大に追従する ◦ AWS: Transit Gateway ◦ GCP: Shared VPC

    • スケーラブルかつ低運用コストで管理できる構成を採 択 52
  53. 53