オンプレとクラウドのネットワークの話

IT基盤部エンジニアブログリレー第4回目。
こんにちは、IT基盤部ネットワークG torigoe です。
オンプレとクラウドのネットワークをどう繋げるのか、クラウド内のネットワークをどうするのか考えた話を書きます。

多くの内部サービスを持っていて、オンプレからクラウドに移行を検討しているネットワークエンジニアの人に読んで頂ければと思います。

はじまり

2018年ある日、mtgに呼ばれて急に DeNAのインフラ全てをオンプレからパブリッククラウド(しかもマルチ)に変えようと思うがどうよ？ と言われました。正直その日まであまりパブリッククラウドサービスを触った事がありませんでしたが、説明された内容には納得できたのでそんな事は噯にも出さず同意し、次の日からオンプレ-クラウド移行の為に必要なネットワークの検討を開始する事になりました。(元々Openstackは触ってました)

まずはAWSを色々と触ってみました。ちらほらなんでこんな仕様なの？という疑問をいだきつつも、ドキュメント読んだり触ったりして大体使い方を把握しました。
AWSの次はGCPを触り、それぞれ次のような感想を持ちました。

AWSはユーザファーストの意識が高いように思える
GCPはアーキテクチャに拘っていて独自性が高い

要件を整理する

オンプレとクラウドを繋げるネットワークを設計するにあたって、まず要件を整理する事にしました。
ざっくり書き出すと、

最終的にクラウドをマルチ(AWS/GCP)に使いたい
DR化も踏まえて検討したい
DeNAは非常にサービス数が多い=VPC数が多くなる
各VPCとオンプレ間/VPC間はセキュリティを考慮しつつボトルネック無く通信したい
オンプレに多少サービスが残る可能性もケアしておく
オンプレネットワーク機器の保守期間の残りや延長可否について決める
ネットワーク運用にかかる工数を削減したい
ネットワークセキュリティも整理したい

といったところでした。
要件の中に一部弊社オンプレ環境の問題もありますので、今回のブログでは主にクラウドのネットワーク周りにフォーカスして書きます。

検討開始

現状のネットワークの課題整理、クラウド側のネットワーク仕様、最終形、という３つを意識しつつ検討を始めました。

オンプレ~クラウド間の接続

まずオンプレとパブリッククラウドの間を物理的にどうやって繋げるのか検討しました。経験上インターネットVPNでの通信は遅延や品質を考えると、サービスで使えるものでは無いと判断していました。ファイアウォールのスペック次第ですがVPN通信のスループットはそこまで大きな帯域を確保出来るものではありませんし、インターネット上をパケットが流れるので我々のコントロール外のネットワークで輻輳や障害が発生しパケロスが発生する事があります。

実際今までにAWS/GCPとのVPN接続を何本も張っていますが、運用中にそこそこの頻度でAWS/GCPとのVPNが落ちる事を経験していました。VPN接続も冗長化している為大きなロスにはならないですが、やはり多少のインパクトはあります。移行期間中はマスターDBがどちらかにある状態なので、VPNを介したサービスはレイテンシやパケロスにより遅延が発生する事が想定されます。という事で、本格的にサービス移行＆サービス利用用途としての通信手段はVPNでは無く専用線を引くしか無いだろうと考え、専用線の物理接続構成の検討を進めました。

2018年検討時点でのクラウド側(AWS/GCP)の10G専用線接続ポイント(データセンター)は下記の通りでした。

AWS Equinix TY2(Tokyo)
AWS @Tokyo(Tokyo)
AWS Equinix OS1(Osaka)
GCP Equinix TY2(Tokyo)
GCP ComSpace1(Tokyo)
GCP Equinix OS1(Osaka)
GCP NTT Dozima(Osaka)

※201906現在GCPは@Tokyo(Tokyo)も接続可能です

弊社のオンプレ環境は上記DCにはありませんので、AWS/GCPと直接通信する為には弊社DCと上記DCのどこかの区間に専用線を敷設する必要があります。検討を進めていく中で、オンプレに多少サービスが残る可能性がネックになってきました。というのも、万一最終的にオンプレにある程度のサービス・ラックが残るとなると，最善の最終DC構成がコスト見合いで変わってくる事がわかってきたからです。そこで一旦不透明な最終形は考えずに、とりあえず現状が使いやすいように専用線を引く方向で検討を進める事にしました。専用線は敷設までの納期や最低利用期間等を考えると引き直しのハードルがやや高いのですが、それは許容する事にしました。

私の考えたマルチクラウドネットワーク+オンプレのロケーションの理想は、 AWS/GCP両方が同一DCで構内接続可能なEquinix or @Tokyoにラックを借りてルータを置き、両パブリッククラウドと構内接続する、サービスラックはそのDCに置くです。そうすれば全て構内配線で接続出来るので、回線周りのコスト・納期やレイテンシ等で優位性があります。

オンプレ-クラウド間のネットワークの繋ぎ方

次にオンプレ-クラウド間のネットワークをどうやって接続するのかを考えてみました。
要件でも挙げた通り、DeNAの特徴として サービス数(アカウント数/VPC数)が非常に多い ので専用線経由で多VPC接続という事を考慮する必要があり、 AWSの専用線ネットワークについて調査を進める中で、AWS DirectConnectのある制限に引っかかる事がわかりました。2018年検討当時、DirectConnect経由でVPCに接続できるのは50本までという制限がありました。(※今も制限ありますが、今はDirectConnectGatewayの仕様変更により50以上接続できます) DeNAのアカウント数は余裕で200を超える事が想定されていたので、この制限数の50に引っ掛かります。世の中のワークアラウンドを調べても、VPC内にルータインスタンスを立ててルーティングさせる、という非常にクラウドっぽく無いノウハウが散見されました。せっかくのクラウドなのでオンプレのようなネットワーク運用はしたくありません。

AWSの場合

DeNAではAWS Office Hourという毎週AWSの人が来社して気軽に相談出来るSpecialなmeeting timeが提供されていたので、早速AWSの人にカジュアルに相談を開始しました。タイミングが良かったのか、相談開始して程無くAWS Transit Gateway(以下TGW)という新ネットワークサービスが始まる、という事をUnderNDAで教えてもらいました。

※201907現在TGWはGAですが、東京リージョンのDirect Connectではまだ利用できません

TGWの仕様を細かく調べると多少課題は見つかったものの、概ね我々のやりたい事は出来そうでした。簡単に説明するとTGW=マネージドルータで、オンプレからTGWに接続すればTGWが各VPCにルーティングしてくれます。

AWS TGWの特徴は下記の通りです。

AWSサービスのマネジメントルータ
(TGWの)冗長性を気にする必要は無い
ルータなので経路情報を持つ事が出来る
TGWから他AWSアカウントのVPCに対して接続可能
TGWはデフォルトルートを持つことが可能
AWS Internet Gateway (IGW)と接続可能
AWS Direct Connect Gateway (DXGW)経由でオンプレと接続可能
ip addressの重複は不可
IPv6利用可能
TGWの帯域等はかなり大きく、ボトルネックにならなそう

TGWが無い場合のオンプレ-多VPC間の接続は大変だと思います。 VPC間通信のみを考えてもVPCピアリングやPrivateLinkというVPC間を繋ぐサービスもありますが、どちらも弱点があり今回の設計ではスコープから外しました。各VPC内のインスタンス上にルータをにたててルーティングさせるという前述の方法を採用すれば目的は達成できそうですが、そのルータの冗長化やネットワーク運用を考えると辛いです。

TGWの仕様を調べる中で課題がいくつか見つかったので、課題について**EBC (Executive Briefing Center)**というAWSのサービス開発チームの人との個別セッションの場をAWSの方にセッティング頂き、DeNAの要望をAWSの開発の人に余す事無く伝えきる事が出来ました。まだ一部要望した機能は実装されておりませんが、サービス開発のロードマップには乗っています。

DeNAでは、AWSとオンプレのネットワーク接続にTGWを採用する事を決めています。

GCPの場合

並行してGCPも調査していましたが、やはりGCPもAWS同様専用線経由のProjectとの接続数制限がありました。 GCPもAWS同様GCP Office Hourという素晴らし(ｒｙ、GCPの人に相談したところ、GCP Shared VPCというサービスがある事がわかりました。
AWSのTGWとはかなり毛色が違い、ある1Project(Host Project)から他のProjectに対してVPCをシェアする、というネットワークサービスです。既に利用出来る状態だったので早速調査＆検証を開始しました。

特徴は下記の通りです。

(TGWのような)ルータサービスでは無い
Host Project によって作成された1つの VPC を複数の Project で共有するサービス
Route, Firewall, Subnet, VPN を Host Project から一元管理できる
Organization 内で SharedVPC が有効化された Project が Host Project となる
Host Project に Attach した Project（Service Project）が共有されたリソース内でGCPサービスが利用できる(GCP全サービスではない)
Service Project 固有のスタンドアローンな VPC やその他のサービスも今で通り利用可能

大体やりたい事が出来る事はわかりましたが、TGWと違ってややイレギュラーな思想の為、TGWとは全く違う課題がいくつか見つかったのでGCP Office Hourの場で改善希望を伝えました。

DeNAでは、GCPとオンプレのネットワーク接続にShared VPCを採用する事を決めて、既に利用を開始しています。

その他考慮するポイント

ネットワークアドレスの管理、ネットワークセキュリティを考慮する必要があります。

ネットワークアドレス設計

当たり前の話ですが、オンプレ-クラウド間・VPC間でNATを介さずに自由に通信させたい場合は、オンプレ・クラウド全てでプライベートIPアドレスを重複しないように管理する必要があります。クラウドだからと自由にアドレス採番をされてしまうと、オンプレとネットワークを繋げる事が出来ないケースが出てきます。

※アドレスの設計詳細はセキュリティの都合上お伝えできませんが、書ける範囲で書きます

例えば10.0.0.0/8のプライベートアドレスがすべてクラウドで使えるとしても、前述の通りDeNAはサービス数が非常に多いので、全サービスが/16を使いたいと言い出した場合、本当にあっという間にアドレスが枯渇します。また、そもそもDeNAはオフィス・社員数が多いので、オフィス用のプライベートアドレス空間は大きめに確保しています。また、データセンターにも数千台規模のサーバ群があるので、こちらもvlan毎に大きめにアドレス空間を確保しています。なので、プライベートアドレスは決して潤沢とは言えません。クラウド側にフルにプライベートアドレスを割り当てられるという事はありませんし、今後AWS/GCP以外にも利用クラウドが増えていく事を考えると、プライベートアドレスの管理はしっかりと運用していく必要があります。クラウド側は耐障害性を考えてAZを分ける等の対応を取る必要があるので、/24ではほぼ足りず、規模に応じて/22-/20の間で各サービスに採番する事にしました。

その他にも細かいアドレス採番ルールもあるので、プライベートアドレスはIT基盤部で採番管理する事にしています。

ネットワークセキュリティ

実はネットワークセキュリティの検討については一番時間を使ったかもしれません。現在オンプレ環境ではオフィス-DC間、DC内のvlan間でフィルタを設定していますが、このセキュリティ設定管理が非常に煩雑なのでここをどうにかしたいと考えていました。

その中でも、社内の人間のサービスリソースへのアクセス制限の管理が特に煩雑なポイントでした。机上で考えるとただ決められたセキュリティルールに基づき初期設定すれば良いだけと思えますが、実際はかなりのイレギュラーケースが発生し、毎日のようにフィルタ設定の変更をする必要が出てきます。開発環境-本番環境間のフィルタも同様で、恒常的にフィルタ設定の変更をする必要があります。

vlanベースでのフィルタの設定にも限界がありました。具体的には、例えばサービスを複数跨ってアクセスするような人がいる場合、vlanベースだと人はvlan Aかvlan Bのどちらかにしか所属してしないのでどちらかにかアクセス出来ません。必要であれば最悪その人の為だけにわざわざ新しいvlanを作成する必要があり、vlanベースの通信制御は破綻していきます。また、サービス=部署単位では無いので、部署単位でvlanを作ってもその通りにアクセス制御をする事も出来ません。

つまり、やりたい事としては、

サービス単位のグループで通信制御
人はグループを跨ってもOK
そのグループのメンバーはサービス側で管理する

です。
DeNAではGSuiteを利用している為、GoogleGroupでグループ作成する事が一般的でAD連携が出来る仕組みもあったので、GoogleGroupを活用したアクセスの仕組みを考えました。色々と考えましたが、オフィスからもリモート(自宅)からも同一のセキュリティポリシーでアクセスさせたい事を考えるとVPNで制御するしかないかな、という結論に至りました。いくつかのVPN製品を調べていく中で、これも2018年検討当時に AWS ClientVPN がリリースされるという情報をAWS OHで教えて貰いました。（UnderNDA)
既にリリースもされているのでご存知の方も多いと思いますが、特筆すべきはADのSIDベースで制御できるという部分で、ここがマッチしそうでした。リリースされてから色々と触った所、いくつかの課題が見つかりました。

フィルタの順序が変えられない（順序を変えるには全消しして入れ直さないといけない…）
SIDを同時に複数指定出来ない
denyが書けない
クライアントのデバイスが固定出来ない

実際に使ってみて頂くとわかると思いますが、通信制御周りが使いづらいです。上記に挙げたものは全て重要で、改善要望をあげています。

その他にもネットワークセキュリティ設計として、ネットワークセキュリティポリシーの設計をしました。ここの詳細はセキュリティの都合上割愛します。ポイントとしては、クラウド側のVPCのセキュリティポリシーを誰がどうやって制御するのか、具体的にどういうセキュリティポリシーにするのかといった内容で、セキュリティ部の人達と議論を重ねて大枠を決めていきました。