【レポート】大規模環境をAWS Transit Gatewayで設計/移行する前に考える3つのポイントと移行への挑戦 #AWSSummit

こんにちは、崔です。

今回は、2020年9月8日から9月30日の間で開催されているAWS Summit Online のセッションで「大規模環境をAWS Transit Gatewayで設計/移行する前に考える3つのポイントと移行への挑戦」を視聴しましたので、レポートをお届けします。

セッション情報

スピーカー

株式会社リクルートテクノロジーズ
プロダクト統括本部プロダクト開発統括室
開発ディレクション室インフラソリューションユニット
サイトリライアビリティエンジニアリング部 クラウドグループ
宮崎 幸恵 氏

概要

弊社ではグループ会社含めて横断のクラウド基盤ならびにオンプレミス基盤を運用しています。
オンプレミス基盤とクラウド基盤の接続は DirectConnect と個別設計の VPN を運用してきましたが、VPN 接続については昨年約半年かけてすべて AWS Transit Gateway へ移行しました。
本セッションでは、200 を超える VPN 接続を AWS Transit Gateway へ移行して得た知見を共有します。

資料

アジェンダ

• AWS共通基盤について
• AWS Transit Gateway 検討の背景
• 既存の仕組みからの移行に向けての検討
• 移行時の検討ポイント
• まとめ

AWS共通基盤について

リクルートのクラウド基盤について

大きく2つのサービス向けインフラを運用している。

• オンプレミス基盤
• クラウド基盤

クラウド基盤におけるインフラチームの役割

• アプリサイド／サービスインフラサイド／基盤運用の役割がはっきり分かれているのが特徴
• 非機能要件（ID／認証等）に対応もインフラチームで行っている

ネットワークの共通機能

• ネットワークの共通機能として、オンプレミス環境との専用線／VPN接続を提供してきた

AWS Transit Gateway検討の背景

ネットワーク構成の課題

• オンプレミス環境との接続は、つぎはぎ構成となっており複雑化していた
• 用途に応じてVPN／専用線を使い分け
• AWSの機能で実現できない箇所は独自実装

VPN接続でトランジットしていた理由

• 接続VPCが初期段階から100近くあり、頻繁に追加／削除があった
• そのため、AWSの機能は使わずVPNルータを利用し、独自実装していた
  • AWSによる制限を受けずに、自由にNWを構成できる
  • ただし、ルータの独自管理は非常に負荷が高く、品質低下に苦しんでいた

AWS Transit Gateway への移行検討

• 2019年初から移行検討を開始
• 約1年をかけて移行完了した

既存の仕組みから移行に向けての検討

移行対象について

• 全て移行対象とするのではなく、一部のみ移行検討
  • 専用線については、対象外
  • オンプレミスとのVPN接続は全て移行対象
  • AWS基盤内の共通機能との接続については、一部移行対象

設計の検討

• オンプレミスのセグメントと接続があるか
• および、用途との掛け合わせで、Transit Gatewayを3つの構成とした

Transit Gatewayは、以下の3箇所で置き換えることとした。

• VPN 接続の箇所
• オンプレミス接続はないが、AWSの中で提供している共通機能との接続がある箇所
• 専用線での接続をしているセグメントかつ共通機能とも接続もある箇所

移行の検討

• 影響範囲と切り戻しのしやすさから、7回に分けて移行

移行時の検討ポイント

検討ポイント

設計時には、以下の3点をとくに判断ポイントとした

• 構成がシンプルになるか
• 拡張性があるか
• 他の接続方法が適していないか

移行時には、以下の3点を判断ポイントとした

• できるだけ同じ作業と影響が出る作業でまとめる
• 切り替え時の断時間が最短になる方法を検討する
• 既存の構成変更と移行は、同時に行わない

設計時／移行時の課題

設計時／移行時に後から発覚した課題

• 東京リージョン以外への対応
  • リージョンを跨いだアタッチメント付与ができず、途中で気づき、方式検討／検証を追加で実施
• AZ単位のアタッチメント付与
  • 2つ以上のAZがある場合、片方にしか付与していなかった
  • 移行時に気づき、アタッチメントを追加
• AWS Transit Gatewayでの監視とモニタリング
  • CloudWatchだけでは、疎通が正しくできているかまでの確認がとれないため、どのようにモニタリングするかは、今も課題として残っている

移行後の所感

• 大きな障害もなく非常に安定
• マネージドサービスのため、運用も容易に

まとめ

• ネットワーク関連の構成更改には、設計にも移行にも事前検討が他のサービスに比べると重要
• AWSの上限値を意識しつつ、今後の拡張も踏まえて設計する
• 全ての変更ではなく、より適した箇所にサービスを適用する

所感

複雑なネットワーク構成であったところを、3つのTransit Gatewayを利用し、およそ400のVPCをアタッチメントした構成に移行されていました。
また、Transit Gatewayを利用することで、無事に構成がシンプルになり、今後の拡張も検討しやすくなったということでした！