Cycloud 新基盤の全貌第三回: NW編 | CyberAgent Developers Blog

はじめに

はじめまして。CyberAgent group Infrastructure Unit（CIU）で、Cycloudのネットワーク設計・構築・運用を担当している疋田です。

Cycloudの現行リージョン（リージョン02）のネットワークにはいくつかの課題があり、日々の運用の足かせになっていました。新リージョンではそれらの課題を解決すべく、既存構成を踏襲せずネットワーク全体を再構築しました。

本記事では、このリージョン02の課題を新リージョンでどのように改善したかを紹介します！

Cycloud リージョン02のネットワーク構成

まずは、Cycloudのリージョン02のネットワークがどのような構成になっているかを解説します。

リージョン02は、インターネットや他拠点との接続点であるPoP（Point of Presence）と、サーバーを収容するリージョンネットワークで構成されています。リージョン02では、インターネット通信・VRF（VPC）間の通信がCore Firewallを経由するような構成になっていました。リージョン内の物理構成は、一般的なIP Clos構成で、EVPN/VXLANの境界となるborder leafと、VM・L4LBを収容するleafをspineで相互接続しています。

Cycloud リージョン02ネットワークの課題

前述のとおり、リージョン02はCore Firewallで各テナントのVRFを集約し、インターネット向け・VRF間通信を収容する構成でした。この構成には、次の課題がありました。

厳密なネットワーク分離が不可能
VRFを子会社ごとに作成し、サービス間の通信制御はSecurity Groupで行っていました。そのため、パブリッククラウドのVPCのように、プロジェクトやサービスごとにネットワークを分離するニーズには十分に応えられていませんでした。
プロジェクトごとにVRFを作成することは技術的には可能でしたが、パラメーターアサインが手動前提であることや自動化が十分できていないことから子会社単位でVRFを作成する運用になっていました。
Core Firewallの構成問題
インターネット向け・VRF間(L4LBの通信含む)のトラフィックがCore Firewallを経由するため、Core Firewallの最大性能にリージョンで受け入れ可能なトラフィック量が依存していました。（下図を参照）
L4LBとVMの折り返し通信もCore Firewallを経由することからトラフィックが増幅し、輻輳しやすい原因となっていました。
このような構成からCore Firewallの障害やメンテナンスによる影響範囲が大きくなっており、ハードウェアリプレースやOSバージョンアップの実施が難しくなっていました。
ベンダー固有技術によりリプレースが不可能
Leafスイッチで使用していたM-LAG、Firewallで使用していたChassis Cluster、Load Balancerで使用していたHAは、いずれもベンダーごとの実装であり、異機種間接続できないことが多く、機器を入れ替える際の制約になっていました。
増設時のコスト
増設時にはトラフィック単価の高いFirewallの増設（2台）が必須であることや、Load BalancerもHAの都合で2台ずつ増やす必要があり、スケールアウトする際にかかるコストが課題でした。
多くのネットワーク設定変更作業が手動
VRF / VLAN / IPアドレス / Firewallポリシーの追加・削除はすべて手動で、チケットでの依頼が必要でした。
利用者がチケットを作成してから設定が反映されるまで、早くても数時間であり、Public Cloudと比較すると長い時間がかかっていました。

Cycloud 新リージョンのネットワーク設計方針と構成

前章で挙げた課題を踏まえ、新リージョンでは次の4つを軸として設計を実施しました。

VPC機能
プロジェクト単位など厳密なネットワーク分離に対応する。VPC機能は標準化技術を活用し、FirewallがCentral Pointとならない構成を実現する。
標準化技術を活用した長期運用可能なネットワーク構成
M-LAGなどのベンダー固有の冗長化技術を標準化技術に置き換えて、長期運用可能なネットワーク構成を実現する。
L4 Load BalancerのN+1構成
コスト単価の高いL4LBを1台ずつ増減できるようにする。ベンダー固有の冗長化技術に頼らず、BGP + BFDによる経路制御でこれを実現する
ネットワーク機能のAPI化・コントローラー化
ユーザーにネットワークを高速に提供するために、gRPC APIと機器の役割ごとに分けたコントローラーでネットワーク設定を自動化する

設計途中の技術選定の経緯などは省きますが、最終的に新リージョンのネットワークは以下のような構成になりました。次の章より構成のポイントについて解説していきます。

VPC機能の実現

VPC機能には、次の要件がありました。

テナント間のネットワークアクセスをVPC単位で分離
- VPC PeeringによりVPC間の相互接続、旧リージョンとの相互接続に対応する
- データセンターをまたいだVPCの延伸・VPC Peeringに対応する
ネットワーク機器でL2延伸を実現する
- 新リージョンの開発期間を短縮するため、Subnetなどの機能はネットワーク機器で実現する
- データセンターをまたぐL2延伸はしない
  - L2はデータセンター内に閉じ、Availability Zoneに近い単位として扱う
OpenStackのライフサイクルに左右されず、継続的に機能を追加できるようにする

これらの要件より社内でも実績のあった標準化技術であるEVPN/VXLANを用いた設計を主軸としてVPC機能を実装する方針で進めました。

EVPN/VXLANを用いたVPC機能の実装

VPC間の相互接続（VPC Peering）、既存リージョンとの接続やデータセンターを跨いだVPC間の相互接続についてはEVPN Route Type-5（IP Prefix Route）によって実現しています。

具体的には各VRFを収容する機器(leaf / PE など)で接続したいVRFのroute-targetのついたType-5経路をvrf-importするような設定を投入することで実現しています。

上図の例だと、vrf-Aが広告したType-5経路は65001:10010を付与、vrf-Bが広告したType-5経路は65001:10020を付与しています。vrf-A/Bではimportルールにvrf-Aとvrf-BのRoute Targetが相互に書かれているお互いの経路をルーティングテーブルにimportすることができます。1つのVPCを複数のVPCと疎通させる場合は、import側に複数のRoute Targetを設定します。VPCごとにimportするRoute Targetを制御することでVPC Peeringといった機能を実装できます。

また、デフォルトルート（0.0.0.0/0）に関しては、PEルーターからType-5として広告しています。これにより、PoPに置いたNAT Gatewayをデフォルトゲートウェイとして扱っています。

この仕組みにより、サーバーを動かすリージョンネットワークを超えてVPC間を接続でき、リージョンネットワークにFirewall機器などを購入せずに拠点を増やせる構成になっています。

EVPN/VXLAN によるL2延伸

利用者のVMは複数のleafに分散して接続されており、これらのVM間をL2で相互接続する必要があります。これはEVPN Route Type-2（MAC/IP Advertisement Route）によって実現しています。

一方で、当初の設計思想としてデータセンターを跨いだL2通信は行わないため、Type-2経路はL2 Domainの境界となるborder leafで閉じる構成(EVPN Route Type-5以外の経路をrejectする構成)としています。

今回はEVPN Route Type-5によってVPCを実現するため、PoPまでEVPN経路を回していますが、border leafでの経路フィルタリングによってネットワーク全体の経路数を削減しています。

Firewall にトラフィックが集中する問題の解決

新リージョンではこれまで説明してきたネットワーク構成によってFirewallにトラフィックが集中する課題を改善しました。以下の4つのパターンのトラフィックフローに着目して解説します。

LB ⇔ インターネットの通信
VM ⇔ VMの通信
他拠点との通信
LB ⇔ VM間の折り返し通信

VMが発信するインターネット向け通信は、従来どおりFirewallを通過します。NAT GatewayはFirewallと同じ筐体で「NAT + Stateful Firewall」として動作します。インターネットからロードバランサーに入るパケットに関しては前述にあるVPC Peeringの技術とNAT技術を応用してFirewallを通らない通信を実現しています。
以下に、PEルーター内のVRF構成を含めたトラフィックフローと、インターネットからロードバランサーに入るトラフィックフローの概要図を記載しています。

標準化技術を活用した冗長化の実現

サーバーとの接続の冗長化はEVPN Multihomingにて実現しています。EVPN Multihomingは複数のEVPN デバイス(今回はleafスイッチ)とデバイス間(今回はCompute Node)のL2接続を冗長化することができる技術です。収容先のleafスイッチに同じEthernet Segment Identifier(ESI)を設定すると、EVPNでは同じEthernet Segmentとして認識されます。BUMトラフィックの重複を避けるDF Electionも自動で行われます。標準化技術であるEVPNを用いてコントロールプレーンを制御することでM-LAGのように機器間で専用の制御プロトコルをやり取りしなくてもL2接続の冗長化が実現できます。

EVPN Multihoming（leaf の L2 冗長）と Anycast Gateway（Active-Active な Default Gateway）

また、VMのデフォルトゲートウェイの冗長化には、Anycast Gatewayを用いています。Anycast Gatewayは、VLANを収容するleafスイッチのIRBインターフェースに同じIPアドレスと仮想MACアドレスを設定します。VMからは同一のデフォルトゲートウェイに見えるため、VRRPのようにスイッチ側のステータスを意識する必要がありません。EVPN Multihoming と Anycast Gatewayによって、leafスイッチのこれまでの課題であった「M-LAGは同一ベンダー同士でしか組めない」という制約を解決し、標準プロトコルによって機器の更新が難しい問題を解消しました。

L4 Load BalancerのN+1構成の実現

L4 Load Balancer(L4LB)は、BGPと自作コントローラーによるN+1構成を採用しました。設計する上で、次の2つの実現を目指しました。

VPC上のアドレスを使ってVIPをデプロイできること
BGP・BFDのみに依存し、ベンダーを問わず組み込めること

Active機へのトラフィックは、BGP + BFDによって制御しています。また、VIPごとに待ち受けするL4LBを切り替えられるようにコントローラーでVIPをスケジューリングしています。

Standby機には全Active機のVIPをあらかじめ作成しておくことでActive機が故障したときにトラフィックが受け入れられるようにしています。各L4LBは2台のborder leafにBGPでVIPを広報しています。またBGPの経路切替を高速化するためにBFDでBGPセッションの死活監視を実施しています。Activeを増やすときは新しいL4LBを1台追加すればよく、Activeごとに専用のStandbyを用意する必要はありません。

まとめると各機器は通常時以下のような役割で動作しています。

Active L4LB
- 担当するVIPの経路をBGPでborder leafへ広告
Standby L4LB
- あらかじめすべてのL4LB Active機のVIPを作成して経路を広告
- AS-Path Prependを設定してborder leafに経路を広告
border leaf
- L4LBから受け取った経路をEVPN Route Type-5としてネットワーク全体へ広告
- 通常時はActive L4LBの経路のAS-Pathが短いので優先選択

L4LBフェイルオーバー時の挙動

L4LB フェイルオーバー時には以下のような流れで経路が切り替わります。

なんらかの原因で2台のborder leafとActive L4LBのBGPセッションが切断される（BFDによるfast failover）
border leafで受け取っていたActive L4LBのBGP経路が撤回される
border leafでStandby L4LBから受け取っていた経路がベストパスとなり、border leafから見たL4LBが切り替わる

今回のN+1構成はBGPで実現しているため、これまでのHA機能のようにLB間のセッション同期機能がありません。フェイルオーバー時には既存のTCPセッションが一度リセットされます。

L4 Load Balancer の N+1 構成（EVPN/BGP ポリシーの設定イメージ）

前述のとおり、L4LBは2台のborder leafとBGPセッションを持つため、1台のリンクやセッションが切れてもベストパスは変わりません。そのため、両方のborder leafへの経路広告が止まったときに、初めてL4LBが切り替わります。

L4 Load Balancer N+1 構成の動作イメージ（通常時と障害時の VIP 経路切替）

L4LB VIPとVPCの相互接続

「VPC上のアドレスを使ってVIPをデプロイできること」という要件を満たすため、VIPのアドレスはユーザーのSubnetから/32でアドレスを切り出してアサインしています。ユーザーSubnet内でL4LBを動作しているように見せるため、以下のような工夫でVPCとの相互接続を実装しています。

border leafはL4LBから受け取った経路をRoute Type-5としてファブリック内に経路広告
- アドレスを照合し、ユーザーVPCのRoute Targetを付与
VPCを収容するleafなどの機器でRoute Targetを判別してルーティングテーブルにimport
Subnetを収容しているleafスイッチなどに設定されたIRB インターフェースに設定したProxy ARPによってVMからみると同一のセグメント上で動作しているように見える

このような工夫によってユーザーVPCのセグメントからVIPを払い出し、EVPNの複雑さをL4LBに持ち込まない設計を実現しています。

ネットワーク機能のAPI化・コントローラー化

リージョン02では手動設定によって設定反映に時間がかかる課題がありました。この問題を改善するために新リージョンでは設定の自動化に取り組みました。

また、ネットワーク機器の設定に必要なアドレスの払い出しやRoute TargetなどのアサインなどをAPI化しました。独自のAPIを作成することでOpenStackのDBに依存しないネットワークの管理やマルチベンダー対応などを実現する余地を作成しました。

内部的には機能ごとに異なるコントローラーを作成しています。Networking APIは、機器の役割に合わせて以下の2つのコントローラーを作成しました。spineなどNetworking APIの操作による設定変更がない機器はAnsible Playbookによって構成管理しています。

PE Controller：自作コントローラー。NETCONFでPEルーターを制御し、VRF・Floating IPを作成・削除
Apstra Provisioner：商用のネットワーク構成管理ツールであるApstraをREST APIで操作し、leaf / border leafを自動設定(Interface、VRFやEVPN/VXLANの設定など)

機器のロール別に開発したネットワークコントローラー（PE Controller / Apstra Provisioner / Ansible）

Apstraは「Reference Design」モードではなく、あえて「Freeform」モードで運用しています。Reference Designモードでは、トポロジやネットワークパラメータの割り当てをApstra自身が決定します。一方でFreeformモードでは、こうした設計判断をApstraに委ねません。Apstraの役割は、Apstra Provisionerがproperty-setとして払い出したパラメータを、あらかじめ用意したJinja2テンプレートに流し込んでJunos設定へ変換し、配信することに限定しています。設定投入も、commit check（事前検証）→ diff確認 → deploy という、Junosならではの安全な手順を踏みます。投入前に内容を確認でき、必要であればロールバックも可能です。

このようにApstraを活用することでJunosの操作ロジックを開発することなく迅速にVPC管理機能を開発することができました。新リージョンでは、これらの自作APIとコントローラーによってユーザーのVPC・Subnetを数十秒で作成できるようになりました。これまでのリージョンと比較すると大きな改善です。

ネットワーク自動化コントローラの設計・開発のより詳しい内容は、過去の記事「Cycloud の VPC を実現するネットワーク自動化コントローラの設計と開発」もあわせてご覧ください。

まとめ

Cycloudの新リージョンでは、次の4つの取り組みを軸に、以下のネットワーク技術を実現しました。

VPC 機能の実現：EVPN Route Type-5 と Route Target の import/export により、Firewall を経由しない VPC 間 Peering・インバウンド通信を実現
標準化技術を活用した冗長化の実現：EVPN Multihoming と Anycast Gateway により、ベンダー独自技術に頼らない標準化されたネットワーク冗長化も実現
L4 Load Balancer の N+1 構成化：BGP + BFD による経路制御と AS-Path Prepend で、L4LB を1台単位で増減可能に
ネットワーク機能の API 化：gRPC による抽象化と、API のカテゴリ・機器のロールごとに分けたコントローラーによるネットワーク自動化

これらによって、既存リージョンの課題を解決しつつ、半永久的に提供し続けられるプライベートクラウドのネットワーク基盤を実現しました。

このネットワークチームでの取り組みは2026年7月に開催されたJANOG58で発表していますので、興味のある方はこちらも見ていただければと思います！

次回は「Cycloud 新基盤の全貌」第4回として、IaaS基盤を紹介します。

連載記事一覧

本シリーズでは、各チームが新基盤構築における技術的挑戦を公開しています。他のレイヤーの知見については、ぜひ連載の他の記事も併せてご覧ください。

Cycloud 新基盤の全貌第一回新リージョン基盤の全体像
 Cycloud 新基盤の全貌第二回 HW 編
 Cycloud 新基盤の全貌第三回 NW 編
 Cycloud 新基盤の全貌第四回 IaaS 編
Cycloud 新基盤の全貌第五回 ComputeController 編
Cycloud 新基盤の全貌第六回 LB 編
Cycloud 新基盤の全貌第七回 KaaS 編
Cycloud 新基盤の全貌第八回 FrontEnd 編

各レイヤの Cycloud の新基盤に関して、より詳細な仕様や設計思想を知りたい方は、上記各チームの Developers Blog 記事をぜひご一読ください。

Cycloud 新基盤の全貌第二回: HW 編

Cycloud 新基盤の全貌第四回: IaaS 編