Gunosy Tech Blog

Gunosy Tech Blogは株式会社Gunosyのエンジニアが知見を共有する技術ブログです。

グノシーにおける AWS Transit Gateway 活用事例

こんにちは。SRE 部でインフラ部分を主に担当している mgi166 です。
この記事は Gunosy Advent Calendar 2019 11日目の記事です。
昨日の記事は syouit523 さんの 気持ちいいアプリ体験を提供する for iOS でした。

はじめに

弊社のプロダクトは全て AWS で運用していて、各アカウントの VPC へプライベート接続を行うために、AWS Direct Connect を使用していました。

これまでは AWS Direct Connect(以後 Direct Connect と略称を使います) と AWS Transit Gateway(以後 Transit Gateway と略称使います) の接続が東京リージョンではサポートされてなかったのですが、2019 年の 9 月末にリリースがありました。

丁度この時期に弊社のオフィス移転があり、Direct Connect の設定をやり直すタイミングでもあったので、Transit Gateway への乗り換えを行いました。

AWS Transit Gateway とは

AWS Transit Gateway

AWS VPC へのネットワーク接続をシンプルにするソリューションです。

マルチアカウントでの運用が増えると、それに伴い沢山の VPC を管理することになります。VPC 同士のピアリング接続という要件があると更に経路は複雑化しますし、更には VPC 同士だけでなく VPN と接続する等のパターンもあるので、運用コストが跳ね上がってしまいます。

そこで Transit Gateway を利用すると、複雑化した接続を集約して管理することができます。

詳しくは公式のドキュメント を参照してください。

AWS Transit Gateway 以前で抱えていた課題

Transit Gateway 導入の話をする前に、弊社のネットワーク構成について説明しなければなりません。

グノシーではニュースアプリのグノシーの他、ニュースパスLUCRAグノシースポーツオトクル 等、多数のプロダクトを運営していますが、 この各プロダクト毎に AWS のアカウントを分けています。

AWSとGCP間でVPNを設定する方法 - Gunosy Tech Blog でも少し触れてますが、弊社の AWS アカウントは以下のような構成になっております。

各プロダクトは全て AWS アカウントを分けて運用しているので、以下のようなイメージになってます。

図中の Host アカウント側で Direct Connect と、それに紐付いた Virtual Private Interface と、各アカウント側に Virtual Private Gateway を作成していました。

この構成で課題となっていたのは、以下の 3 つです。

  • アカウント追加時の設定作業の多さ
    • 1 アカウント中に複数個の VPC を持っている場合がほとんどで、Virtual Private Gateway は VPC 1 つに付き、1 つしかアタッチできない
    • そのため実際は VPC の数だけ Virtual Private Gateway と Virtual Private Interface のセットを両アカウントに作成する必要がある
  • BGP のルートを厳密に設計しないといけない点
    • 闇のスプレッドシートを運用し、オフィスのIP と AWS のルーター IP の対応表を作成してました
      • ある程度は関数を使って、自動で IP を算出してました
    • アカウント数、VPC 数が増えていくに従って面倒になってくる
  • 都度発生するルーター管理業者の依頼とリードタイム
    • 社内 Router から Virtual Private Interface への経路を追加するのに毎回業者とやり取りする
    • 設定反映までに数日程度かかる

AWS Transit Gateway 導入の流れ

  • これらの課題を Transit Gateway で解決できそう
  • ネックだった Transit Gateway の東京リージョン Direct Connect サポートがタイミングよくきた
  • オフィス移転というタイミングなので、ダウンタイムを許容できる

ということもあり、このタイミングで AWS Transit Gateway に乗り換えを行いました。

オフィス移転が 10/12 ~ 14 の三連休で実施予定だったにも関わらず、Direct Connect の Transit Gateway サポートが 9/26 だったので、十分な検証を行う時間がありませんでした。

したがって、Transit Gateway を利用するプラン A とは別に、
プラン B として今まで通りの Direct Connect + Virtual Private Interface での接続も用意しておりました。

上記の図で言うところの赤色の部分がプラン A、黄色の部分がプラン B として、事前に準備した部分です。

当日の流れとしては、Transit Gateway を利用するプラン A で、各アカウントの VPC に接続できるか確認をします。

うまくいかなかったときのプラン B として、念の為今まで通りの構成を使う、という選択肢を残していました。
Virtual Private Gateway は VPC 1 つに付き、1 つしかアタッチできない という制約があるため、 引っ越し当日に VPC にアタッチされている Virtual Private Gateway を切り離し、黄色の Virtual Private Gateway をアタッチするという流れを想定していました。

なんとか無事 Transit Gateway での疎通が確認できたので、プラン A を採択することができました

AWS Transit Gateway 導入後

Transit Gateway 導入後、以下のような構成にすることができました。

沢山あった Virtual Private Interafce と Virtual Private Gateway がきれいに消えてます。
既存の Route Table に Route を追加するだけで、プライベートな接続を実現できているので、綺麗な構成に収まってます。
また、AWSとGCP間でVPNを設定する方法 - Gunosy Tech Blog でも紹介があったとおり、GCP との接続も Transit Gateway を経由して接続しています。

AWS アカウント追加時に行う作業も効率化しています。
VPC 作成、サブネット作成、Route Table はもちろん、Transit Gateway への接続を自動で行えるように、terraform module を作成しています。

アカウント作成した後に、これだけ書けば VPC 周りのセットができます。

module "main" {
  source     = "git@github.com:gunosy/terraform-modules.git//aws/network/base"
  project    = "hoge"
  cidr_block = "10.100.0.0/16"
}

引数を見てもらえれば分かる通り、最初に VPC の CIDR とプロジェクト名さえ決めてしまえば、後はよろしくやってくれます。(実際はもう少し細かいところまでチューニングできるよう実装しています)

おまけですが、いつでもこの module が動くことを担保したいので、 CI を回して awspec でテストを書いています。

require "spec_helper"

describe vpc("test-sandbox") do
  it { should exist }
  its(:cidr_block) { should eq "10.100.0.0/16" }

  it { should have_route_table("test-public") }
  it { should have_route_table("test-private-1a") }
  it { should have_route_table("test-private-1c") }
  it { should have_route_table("test-private-1d") }
end

describe subnet("test-public-1a") do
  it { should exist }
  its(:cidr_block) { should eq "10.100.0.0/20" }
  its(:map_public_ip_on_launch) { should eq true }
end

まとめ

AWS Transit Gateway を導入することで、

  • 設計がシンプルになり、新規追加時の作業、考慮する点が減った
  • GCP への接続も素直に実装できた
  • ルーター管理業者への依頼が不要になり、リードタイムがなくなった
    • コードを書いて実行するだけで、ほぼ作業完了(数日 -> 数分)

というメリットがありました。

AWS アカウント作成直後はモチベーションも上がるし、色々やりたいことも多いものです。真っ白な環境で新しい絵を描ける貴重な機会でもあります。

Transit Gateway を導入することで、避けられない事業者とのやり取りで数日時間取られる事が無くなり、やりたいことがすぐ実現できるという環境を作成できたので、非常に良かったです。

先日の re:Invent 2019 で、Inter-Regional Peering も発表された事により、 別リージョンとの接続が容易になりそうで、ますます目が離せません。

明日 takaiyuk さんの記事です。お楽しみに。

参考