Containerlab と Juniper の無償仮想イメージ vJunos を使用し、データセンターネットワーク（NW）の定番アーキテクチャ「Leaf-Spine 構成」をゼロから構築するハンズオン記事です。eBGP による Underlay 構成を皮切りに、EVPN/VXLAN によるテナント L2 拡張、ESI-LAG を用いた冗長化、VRF Route Leaking によるインターネット接続ゲートウェイ模擬まで、クラウド NW の中核技術をひと通り体験できます。ハードウェア不要・無償イメージのみで動く手順と全設定例を掲載しています。 はじめに 前提知識 全体像 構築するトポロジ ポイント 進め方 前提とする環境 vJunos イメージの準備（vrnetlab でコンテナ化） 1. 環境構築 — Containerlab で機器を起動 1.1 トポロジ定義（clos-network.clab.yml） 1.2 デプロイ ✅ 完成状態チェックリスト 2. Underlay の構築 — eBGP で Loopback 同士を疎通させる 2.1 IP アドレス設計 2.2 各ノードの IP / Loopback 設定 2.3 eBGP の設定 ポイント spine1 leaf1-1 2.4 動作確認 ✅ 完成状態チェックリスト 3. Overlay の構築 — EVPN/VXLAN 3.1 アーキテクチャの整理 3.2 C-Plane: iBGP EVPN ピア leaf2-1 rr1 hv1（FRR） 確認 3.3 D-Plane: VXLAN セグメントを作る hv1：Linux Kernel + FRR leaf2-1 bm1 動作確認 3.4 EVPN Multihoming（ESI-LAG）で BM の接続を冗長化 方針 leaf2-1（既存設定の置き換え） leaf2-2（新規） bm1（Linux Bond） 切断試験 ✅ 完成状態チェックリスト（Overlay全体） 4. Border Leaf と Internet Gateway 4.1 leaf3-1（Border Leaf として VTEP 化） 4.2 inet-gw1: 共通の下準備（I/F + ASN） 4.3 inet-gw1: VRF と Route Leaking 4.4 inet-gw1: 外部 ISP との eBGP 4.5 isp1 （外部 ISP 模擬） 4.6 bm1 （Global IP 付与とデフォルトゲートウェイ） 4.7 動作確認 ✅ 完成状態チェックリスト（Border GW） 全体の完成確認 おまけ: ハマったら見るところ（Troubleshooting） Junos 側で何が起きているか覗くコマンド FRR 側 まとめ はじめに こんにちは。NTTドコモビジネスのクラウド、 SDPFクラウド/サーバー （以降、SDPF クラウド）の内製開発に従事している堀岡勇杜と申します。 私が主に担当しているのは、ESI（Elastic Service Infrastructure）という名称の、クラウドのNWオーケストレータの開発です。ESI チームの業務内容については、 こちらの記事 で詳しく紹介しています。 ※ 本記事で出てくるEVPN Multihoming の関連用語であるESI（Ethernet Segment Identifier）とは全くの別物です。 突然ですが、データセンター NW の定番アーキテクチャである Leaf-Spine（CLOS） と、その上で動く EVPN/VXLAN は、クラウド NW の中核技術です。しかし実機やシミュレータがなければ、その挙動を肌で理解するのは大変難しいです。私自身も入社当時（2025年4月）はクラウド NW については完全な初学者だったのですが、この 1 年間で勉強させていただき、その全貌の一端が理解できるようになってきました。本記事を通じて、私が得た知見を共有できましたら幸いです。さまざまな用語が出てきますが、それらを全て解説するのは不可能であるため、気になる点は適宜調べながら進めていただければと思います。 用語解説 Leaf-Spine … サーバーを収容する「Leaf（葉）」スイッチと、Leaf 同士をつなぐ「Spine（背骨）」スイッチの 2 階層でネットワークを組む CLOS の定番設計。どのサーバー間も同じホップ数で通信でき、帯域を横に足しやすいのが特長です。SDPFクラウドでは、Spineのさらに上のSuper Spineが存在しており、3 階層の CLOS になっています。 EVPN/VXLAN … 物理的に離れたサーバー同士を「同じ LAN にいるかのように」つなぐ仮想ネットワーク技術です。EVPN が「誰がどこにいるか」の情報交換（制御プレーン）、VXLAN が実データのトンネル転送（データプレーン）を担います。 本記事では、OSS である Containerlab と Juniper Networks 社の vJunos （無償の仮想ルータ／スイッチイメージ）を使用し、典型的な Leaf-Spine 構成をゼロから組み立てます。最終的には以下を達成します。 eBGP による Underlay の経路交換 iBGP + EVPN Type-2/3 による MAC/IP 学習（C-Plane ＝ 制御プレーン） VXLAN によるテナント（利用者）トラフィックのカプセル化（D-Plane ＝ データプレーン） ESI-LAG による EVPN Multihoming（サーバーの複数スイッチへの冗長接続） Border Leaf + VRF Route Leaking （仮想ルーティングテーブル間の経路共有）によるインターネット接続ゲートウェイ模擬 「SDPFクラウドの SDN コントローラや NW オーケストレータが裏で何をしているのか」をハンズオンで体験し、クラウド NW の裏側を覗いていただける構成になっています。 ⚠️ 本記事は学習用ラボ構成を前提としています 動作させることを優先しているため、本番設計とは異なる選択をしている箇所が多々あります（例: MTU デフォルトのまま、BGP 認証なし、など） 前提知識 本記事の主な対象読者は、 BGP の基本概念（AS・ピアリング・経路広告）を理解している、データセンター NW の Overlay 技術を手を動かして学びたいインフラエンジニアや学生 です。以下の知識があるとスムーズに進められます。 分野 期待するレベルの目安 Linux 操作 コマンドライン操作（ ip , ping , tcpdump など）、Network Namespace の概念 TCP/IP 基礎 IP アドレス・サブネットマスク・ルーティングの仕組み、L2（Ethernet）と L3（IP）の違い BGP 基礎 AS（Autonomous System）・ASN・eBGP / iBGP の区別、経路広告・ピアリングの概念 Docker 基礎 docker ps / docker pull などの基本操作、コンテナとイメージの違い 各セクションに設けている「用語解説」や「Q&A」は補足情報です。すでにご存知の方は読み飛ばしてください。 全体像 構築するトポロジ 最終的なゴールは、 物理的に異なるラックに収容された HV1（ハイパーバイザー上の VM）と BM1（ベアメタルサーバー）が同一の L2 ネットワーク上で通信でき、さらにそこからインターネットへ抜けられる 状態を作ることです。これを実現するために、Underlay（物理 IP 転送の土台）→ Overlay（EVPN/VXLAN による L2 延伸）→ Internet GW（VRF Route Leaking による外部接続）の順に積み上げていきます。 主な登場人物は以下の通りです。 ノード 役割 ASN Loopback spine1 Spine #1 64512 10.255.255.1 spine2 Spine #2 64513 10.255.255.2 leaf1-1 Underlay Leaf（HV=ハイパーバイザー収容） 65000 10.255.255.11 leaf2-1 / leaf2-2 Overlay Leaf（BM=ベアメタルサーバー収容、ESI-LAG ペア検証） 65000 10.255.255.21 / .22 leaf3-1 Border Leaf（Internet GW 収容） 65000 10.255.255.31 rr1 Route Reflector（経路情報を集めて他に配る中継役） 65000 10.255.255.101 hv1 ハイパーバイザー模擬（Linux + FRR、VTEP＝VXLANトンネルの端点 を持つ） 65000 10.255.255.201 bm1 ベアメタルサーバー模擬（Linux） — — inet-gw1 Internet Gateway 模擬（vJunos-router） 65002 198.51.100.1 isp1 外部 ISP 模擬 65001 192.0.2.1 用語解説 Underlay（アンダーレイ） … 物理スイッチ・ルータが実際に IP パケットを転送する「土台」のネットワーク層です。本記事では Leaf-Spine 間の P2P リンクと eBGP がこれにあたります。 Overlay（オーバーレイ） … Underlay の上に「論理的に重ねた」仮想ネットワーク層です。本記事では VXLAN がデータのカプセル化（D-Plane）、EVPN が経路情報の交換（C-Plane）を担い、テナントの L2 セグメントを物理的に離れたノード間へ延伸します。Underlay が「道路」なら Overlay は「宅配便」のようなイメージです。 ポイント Spine ごとに ASN を分ける （64512 / 64513）。Leaf 側は multipath multiple-as で Spine 2 台への ECMP（Equal-Cost Multi-Path）を有効にしています。この設定により、障害発生時はベストパス再選定なしで残存パスに切り替わります。 Leaf は全て同じ ASN（65000） にして増設コストを下げています。詳細は以下を参照。 RR は Underlay にも参加 しますが、直接データを転送せず Overlay の経路反射（他のノードの経路情報をまとめて再配布する役割）を担当します。 HV 側は FRR で EVPN ピアリングを代用 し、RR と EVPN ピアを張ります（実際のクラウドでは SDN コントローラが HV 上の経路を収集し EVPN に変換します）。 Q. なぜ Leaf を全て同じ ASN にするのか？ RFC 7938 は「Leaf ごとに別 ASN」を推奨していますが、本構成では共通 ASN（65000）を採用しました。トレードオフは次の通り。 共通 ASN（本記事） 別 ASN（RFC 7938 推奨） 増設運用 ✅ Leaf テンプレ流用、Spine 側も peer-as 1 つ ❌ Leaf ごとに ASN 採番、Spine 側も増やすたび neighbor 別設定 AS-PATH ループ防止 ❌ as-override で無効化される ✅ そのまま効く トラブルシュート ❌ AS-PATH に Leaf 識別子が出ない ✅ どの Leaf 経由か AS-PATH で分かる 進め方 Containerlab で機器を起動 Underlay（IP / eBGP）構築 Overlay（iBGP EVPN / VXLAN / ESI-LAG）構築 Border Leaf + Internet GW 構築 各セクションの末尾には「動作確認」と「完成状態チェックリスト」を載せています。 前提とする環境 以下を準備してください。 項目 内容 マシンの推奨スペック メモリ 32GB 以上（vJunos は 1 ノードあたり 4GB ほど使います）、ディスク空き容量 20GB 以上 （vJunos の qcow2 は 1 イメージ約 5GB、Docker ビルド後は合計 10GB 超になります） ホスト OS Linux（Ubuntu 24.04 で検証）。Docker が動く環境ならOK Docker v29.2.0 で検証 Containerlab v0.75.0 で検証。 インストール手順 vJunos イメージ vJunos-switch-25.4R1.12 , vJunos-router-25.4R1.12 （手順は以下） ゲスト OS 軽量 Linux nicolaka/netshoot （HV / BM 用）。コンテナ内の FRR は v10.6.1 で検証 エディタ VS Code + Containerlab 拡張があると便利 vJunos イメージの準備（vrnetlab でコンテナ化） vJunos は Juniper が 無償で公開している仮想ルータ／スイッチイメージ です。ただし配布形式は qcow2（KVM 用）なので、Containerlab で使うには vrnetlab で Docker イメージに変換する必要があります。詳細は こちら を参照。 # 1. vrnetlab をクローン git clone https://github.com/srl-labs/vrnetlab && cd vrnetlab/juniper # 2. Juniper 公式サイトからダウンロードした qcow2 を vrnetlab 下に配置 # https://support.juniper.net/support/downloads で vjunos-switch (または vjunos-router) で検索 cp ~/Downloads/vJunos-router-25.4R1.12.qcow2 vjunosrouter/ cp ~/Downloads/vJunos-switch-25.4R1.12.qcow2 vjunosswitch/ # 3. Docker イメージをビルド（それぞれ数分かかる） cd vjunos-switch && make && cd .. cd vjunos-router && make && cd .. # 4. ビルド結果を確認 docker images | grep vjunos # vrnetlab/juniper_vjunos-switch 25.4R1.12 ... # vrnetlab/juniper_vjunos-router 25.4R1.12 ... # HV / BM 用イメージ docker pull nicolaka/netshoot:v0.15 ⚠️ vJunos のライセンスについて vJunos は 評価・検証・学習用途で無償利用可能 です（商用サポートなし）。以下の点に注意してください。 機能制限はほぼありませんが、 commit 時に warning: requires 'bgp' license 等の警告が出ます。 これはライセンスキーを投入していないだけで、BGP 自体は問題なく動作します （本記事の全手順はライセンスなしで完走できます） 本番環境や商用目的での利用には正規ライセンスが必要です。詳しくは Juniper vJunos ページ を参照してください 1. 環境構築 — Containerlab で機器を起動 この章では、下図のように Spine / Leaf / RR / サーバー模擬など全 11 ノードを Containerlab で一括起動し、SSH でログインできる状態を目指します。 1.1 トポロジ定義（clos-network.clab.yml） name : clos-network topology : nodes : # --- SPINE --- spine1 : kind : juniper_vjunosswitch image : vrnetlab/juniper_vjunos-switch:25.4R1.12 spine2 : kind : juniper_vjunosswitch image : vrnetlab/juniper_vjunos-switch:25.4R1.12 # --- LEAF --- leaf1-1 : kind : juniper_vjunosswitch image : vrnetlab/juniper_vjunos-switch:25.4R1.12 leaf2-1 : kind : juniper_vjunosswitch image : vrnetlab/juniper_vjunos-switch:25.4R1.12 leaf2-2 : kind : juniper_vjunosswitch image : vrnetlab/juniper_vjunos-switch:25.4R1.12 leaf3-1 : kind : juniper_vjunosswitch image : vrnetlab/juniper_vjunos-switch:25.4R1.12 # --- Route Reflector --- rr1 : kind : juniper_vjunosrouter image : vrnetlab/juniper_vjunos-router:25.4R1.12 # --- HV / BM 模擬 --- hv1 : kind : linux image : nicolaka/netshoot:v0.15 bm1 : kind : linux image : nicolaka/netshoot:v0.15 # --- Internet Gateway / 外部 ISP 模擬 --- inet-gw1 : kind : juniper_vjunosrouter image : vrnetlab/juniper_vjunos-router:25.4R1.12 isp1 : kind : juniper_vjunosrouter image : vrnetlab/juniper_vjunos-router:25.4R1.12 links : # Spine <-> Leaf - endpoints : [ "spine1:eth1" , "leaf1-1:eth1" ] - endpoints : [ "spine1:eth2" , "leaf2-1:eth1" ] - endpoints : [ "spine1:eth3" , "leaf2-2:eth1" ] - endpoints : [ "spine1:eth4" , "leaf3-1:eth1" ] - endpoints : [ "spine2:eth1" , "leaf1-1:eth2" ] - endpoints : [ "spine2:eth2" , "leaf2-1:eth2" ] - endpoints : [ "spine2:eth3" , "leaf2-2:eth2" ] - endpoints : [ "spine2:eth4" , "leaf3-1:eth2" ] # Spine <-> RR - endpoints : [ "spine1:eth10" , "rr1:eth1" ] - endpoints : [ "spine2:eth10" , "rr1:eth2" ] # Server / GW - endpoints : [ "leaf1-1:eth3" , "hv1:eth1" ] - endpoints : [ "leaf2-1:eth3" , "bm1:eth1" ] - endpoints : [ "leaf2-2:eth3" , "bm1:eth2" ] - endpoints : [ "leaf3-1:eth3" , "inet-gw1:eth1" ] - endpoints : [ "inet-gw1:eth2" , "isp1:eth1" ] 1.2 デプロイ clab deploy -t clos-network.clab.yml # トポロジを Web UI で確認（リモートサーバーの場合はポートフォワード） clab graph -t clos-network.clab.yml # 全部壊してやり直したくなった時は clab destroy -t clos-network.clab.yml ノードへの SSH は ssh admin@clab-clos-network-spine1 （初期パスワードは admin@123 ）。なお、Linux コンテナ（hv1 / bm1）は docker exec -it clab-clos-network-hv1 bash のように直接シェルに入る方が確実です。 ContainerlabのVS Code拡張を入れておくと、コンテナをまとめて管理できて便利です。 Spine・Leaf・RR・Inet-GW・ISPにおいて、あらかじめ以下の手順で root パスワードを設定して commit しておきます。これは以降の設定をコミットする上で必須の操作です。admin ユーザーのパスワード変更ではないことに留意。 configure set system root-authentication plain-text-password commit ✅ 完成状態チェックリスト clab deploy がエラーなく完了する docker ps で全 11 ノードが Up になっている ssh admin@clab-clos-network-spine1 でログインできる clab graph の Web UI でトポロジが想定通り表示される ここまでで、冒頭の図で示した全ノードが起動し、各機器へログインできる状態になりました。まだ NW 設定は入っていないので、次のセクションで Underlay から構築していきます。 2. Underlay の構築 — eBGP で Loopback 同士を疎通させる この章では、下図のように各ノードに IP アドレスを振り、Spine-Leaf 間で eBGP を張ることで、全ノードの Loopback 同士が疎通できる状態を目指します。この「下地」が後の Overlay（EVPN/VXLAN）の土台になります。 2.1 IP アドレス設計 P2P リンク（機器同士を 1対1 でつなぐリンク）は /30 （IP 2 個分）、Loopback は /32 （IP 1 個）。Spine 側を .1 、Leaf 側を .2 の規則で設計しています。 リンク Spine 側 Leaf 側 spine1 ↔ leaf1-1 10.1.11.1/30 10.1.11.2/30 spine1 ↔ leaf2-1 10.1.21.1/30 10.1.21.2/30 spine1 ↔ leaf2-2 10.1.22.1/30 10.1.22.2/30 spine1 ↔ leaf3-1 10.1.31.1/30 10.1.31.2/30 spine1 ↔ rr1 10.1.101.1/30 10.1.101.2/30 spine2 ↔ * 10.2.x.1/30 10.2.x.2/30（同様） leaf1-1 ↔ hv1 10.11.201.1/30 10.11.201.2/30 2.2 各ノードの IP / Loopback 設定 代表として spine1, hv1 を掲載します。他のノードも同じパターン（IP のみ差し替え）。 spine1 configure set routing-options router-id 10.255.255.1 set interfaces lo0 unit 0 family inet address 10.255.255.1/32 set interfaces ge-0/0/0 unit 0 family inet address 10.1.11.1/30 set interfaces ge-0/0/1 unit 0 family inet address 10.1.21.1/30 set interfaces ge-0/0/2 unit 0 family inet address 10.1.22.1/30 set interfaces ge-0/0/3 unit 0 family inet address 10.1.31.1/30 set interfaces ge-0/0/9 unit 0 family inet address 10.1.101.1/30 commit spine2 / leaf1-1 / leaf2-1 / leaf2-2 / leaf3-1 / rr1 のコマンドを開く spine2 configure set routing-options router-id 10.255.255.2 set interfaces lo0 unit 0 family inet address 10.255.255.2/32 set interfaces ge-0/0/0 unit 0 family inet address 10.2.11.1/30 set interfaces ge-0/0/1 unit 0 family inet address 10.2.21.1/30 set interfaces ge-0/0/2 unit 0 family inet address 10.2.22.1/30 set interfaces ge-0/0/3 unit 0 family inet address 10.2.31.1/30 set interfaces ge-0/0/9 unit 0 family inet address 10.2.101.1/30 commit leaf1-1 configure set routing-options router-id 10.255.255.11 set interfaces lo0 unit 0 family inet address 10.255.255.11/32 set interfaces ge-0/0/0 unit 0 family inet address 10.1.11.2/30 set interfaces ge-0/0/1 unit 0 family inet address 10.2.11.2/30 set interfaces ge-0/0/2 unit 0 family inet address 10.11.201.1/30 commit leaf2-1 configure set routing-options router-id 10.255.255.21 set interfaces lo0 unit 0 family inet address 10.255.255.21/32 set interfaces ge-0/0/0 unit 0 family inet address 10.1.21.2/30 set interfaces ge-0/0/1 unit 0 family inet address 10.2.21.2/30 commit leaf2-2 configure set routing-options router-id 10.255.255.22 set interfaces lo0 unit 0 family inet address 10.255.255.22/32 set interfaces ge-0/0/0 unit 0 family inet address 10.1.22.2/30 set interfaces ge-0/0/1 unit 0 family inet address 10.2.22.2/30 commit leaf3-1 configure set routing-options router-id 10.255.255.31 set interfaces lo0 unit 0 family inet address 10.255.255.31/32 set interfaces ge-0/0/0 unit 0 family inet address 10.1.31.2/30 set interfaces ge-0/0/1 unit 0 family inet address 10.2.31.2/30 commit rr1 configure set routing-options router-id 10.255.255.101 set interfaces lo0 unit 0 family inet address 10.255.255.101/32 set interfaces ge-0/0/0 unit 0 family inet address 10.1.101.2/30 set interfaces ge-0/0/1 unit 0 family inet address 10.2.101.2/30 commit hv1 （Linux なので別物） # FRR のインストール apk add frr sed -i 's/bgpd=no/bgpd=yes/' /etc/frr/daemons /usr/lib/frr/frrinit.sh start # IP 設定 ip addr add 10.255.255.201/32 dev lo ip addr add 10.11.201.2/30 dev eth1 ip link set eth1 up ip route del default ip route add default via 10.11.201.1 ⚠️ ip route del default を実行すると management NW 経由の SSH が切れます。以降 hv1 への操作は docker exec -it clab-clos-network-hv1 bash で入ってください。 直結リンクで ping が通れば OK です。 2.3 eBGP の設定 Underlay の目標は「全ノードの Loopback 同士を疎通させること」。これができれば、あとで Overlay （EVPN/VXLAN）がその「下地」の上に乗れます。Spine と Leaf で eBGP（異なる ASN 同士の BGP）を張り、Loopback 経路を広告します。 ポイント Spine ごとに ASN を分ける ： spine1=64512 , spine2=64513 Spine 側に as-override ：Leaf 共通 ASN 方式の代償として、BGP の「AS-PATH（経路が通ってきた ASN の履歴）に同じ ASN があるとループとみなして破棄する」ルールを回避するため、Spine 側で AS-PATH 上の Leaf ASN を Spine 自身の ASN に書き換えます Leaf 側に multipath multiple-as ：spine1/spine2 の ASN が異なるため、両方を ECMP として使うために必須 ECMP 有効化 ： load-balance per-packet という名前ですがこれは Junos のレガシーな仕様で、実態は 5-tuple（送信元/宛先 IP・ポート・プロトコル）のハッシュによるフロー単位の負荷分散 です 広告経路は Loopback のみ ： from interface lo0.0 で Loopback に絞ることで、リンク IP が広告されず経路がスッキリします commit 時に以下の警告が出ますが、無視して OK です（詳しくは「前提とする環境」のライセンス注記を参照）。 warning: requires 'bgp' license commit complete spine1 configure # ECMP 有効化 set policy-options policy-statement PFE-LB term 1 then load-balance per-packet set routing-options forwarding-table export PFE-LB # 経路広告ポリシー（Loopback + BGP 経路） set policy-options policy-statement EXPORT-UNDERLAY term ALLOW-BGP from protocol bgp set policy-options policy-statement EXPORT-UNDERLAY term ALLOW-BGP then accept set policy-options policy-statement EXPORT-UNDERLAY term ALLOW-DIRECT from interface lo0.0 set policy-options policy-statement EXPORT-UNDERLAY term ALLOW-DIRECT then accept # BGP（ASN 64512） set routing-options autonomous-system 64512 set protocols bgp group UNDERLAY type external set protocols bgp group UNDERLAY multipath set protocols bgp group UNDERLAY export EXPORT-UNDERLAY set protocols bgp group UNDERLAY peer-as 65000 set protocols bgp group UNDERLAY as-override # 各 Leaf / RR への neighbor set protocols bgp group UNDERLAY neighbor 10.1.11.2 set protocols bgp group UNDERLAY neighbor 10.1.21.2 set protocols bgp group UNDERLAY neighbor 10.1.22.2 set protocols bgp group UNDERLAY neighbor 10.1.31.2 set protocols bgp group UNDERLAY neighbor 10.1.101.2 commit spine2 のコマンドを開く configure set policy-options policy-statement PFE-LB term 1 then load-balance per-packet set routing-options forwarding-table export PFE-LB set policy-options policy-statement EXPORT-UNDERLAY term ALLOW-BGP from protocol bgp set policy-options policy-statement EXPORT-UNDERLAY term ALLOW-BGP then accept set policy-options policy-statement EXPORT-UNDERLAY term ALLOW-DIRECT from interface lo0.0 set policy-options policy-statement EXPORT-UNDERLAY term ALLOW-DIRECT then accept # BGP（ASN 64513） set routing-options autonomous-system 64513 set protocols bgp group UNDERLAY type external set protocols bgp group UNDERLAY multipath set protocols bgp group UNDERLAY export EXPORT-UNDERLAY set protocols bgp group UNDERLAY peer-as 65000 set protocols bgp group UNDERLAY as-override set protocols bgp group UNDERLAY neighbor 10.2.11.2 set protocols bgp group UNDERLAY neighbor 10.2.21.2 set protocols bgp group UNDERLAY neighbor 10.2.22.2 set protocols bgp group UNDERLAY neighbor 10.2.31.2 set protocols bgp group UNDERLAY neighbor 10.2.101.2 commit leaf1-1 leaf1-1 は HV1（FRR）が直接 BGP を喋らないため、HV1 Loopback 宛の static route を広告に含めます。 configure # ECMP set policy-options policy-statement PFE-LB term 1 then load-balance per-packet set routing-options forwarding-table export PFE-LB # Loopback + static を広告 set policy-options policy-statement EXPORT-UNDERLAY term ALL-DIRECT from interface lo0.0 set policy-options policy-statement EXPORT-UNDERLAY term ALL-DIRECT then accept set policy-options policy-statement EXPORT-UNDERLAY term ALL-STATIC from protocol static set policy-options policy-statement EXPORT-UNDERLAY term ALL-STATIC then accept # BGP（multiple-as は必須） set routing-options autonomous-system 65000 set protocols bgp group UNDERLAY type external set protocols bgp group UNDERLAY multipath multiple-as set protocols bgp group UNDERLAY export EXPORT-UNDERLAY set protocols bgp group UNDERLAY neighbor 10.1.11.1 peer-as 64512 set protocols bgp group UNDERLAY neighbor 10.2.11.1 peer-as 64513 # HV1 Loopback への static route set routing-options static route 10.255.255.201/32 next-hop 10.11.201.2 commit leaf2-1 / leaf2-2 / leaf3-1 / rr1 のコマンドを開く leaf2-1 configure set policy-options policy-statement PFE-LB term 1 then load-balance per-packet set routing-options forwarding-table export PFE-LB set policy-options policy-statement EXPORT-UNDERLAY term ALL-DIRECT from interface lo0.0 set policy-options policy-statement EXPORT-UNDERLAY term ALL-DIRECT then accept set routing-options autonomous-system 65000 set protocols bgp group UNDERLAY type external set protocols bgp group UNDERLAY multipath multiple-as set protocols bgp group UNDERLAY export EXPORT-UNDERLAY set protocols bgp group UNDERLAY neighbor 10.1.21.1 peer-as 64512 set protocols bgp group UNDERLAY neighbor 10.2.21.1 peer-as 64513 commit leaf2-2 configure set policy-options policy-statement PFE-LB term 1 then load-balance per-packet set routing-options forwarding-table export PFE-LB set policy-options policy-statement EXPORT-UNDERLAY term ALL-DIRECT from interface lo0.0 set policy-options policy-statement EXPORT-UNDERLAY term ALL-DIRECT then accept set routing-options autonomous-system 65000 set protocols bgp group UNDERLAY type external set protocols bgp group UNDERLAY multipath multiple-as set protocols bgp group UNDERLAY export EXPORT-UNDERLAY set protocols bgp group UNDERLAY neighbor 10.1.22.1 peer-as 64512 set protocols bgp group UNDERLAY neighbor 10.2.22.1 peer-as 64513 commit leaf3-1 configure set policy-options policy-statement PFE-LB term 1 then load-balance per-packet set routing-options forwarding-table export PFE-LB set policy-options policy-statement EXPORT-UNDERLAY term ALL-DIRECT from interface lo0.0 set policy-options policy-statement EXPORT-UNDERLAY term ALL-DIRECT then accept set routing-options autonomous-system 65000 set protocols bgp group UNDERLAY type external set protocols bgp group UNDERLAY multipath multiple-as set protocols bgp group UNDERLAY export EXPORT-UNDERLAY set protocols bgp group UNDERLAY neighbor 10.1.31.1 peer-as 64512 set protocols bgp group UNDERLAY neighbor 10.2.31.1 peer-as 64513 commit rr1 configure set policy-options policy-statement PFE-LB term 1 then load-balance per-packet set routing-options forwarding-table export PFE-LB set policy-options policy-statement EXPORT-UNDERLAY term ALL-DIRECT from interface lo0.0 set policy-options policy-statement EXPORT-UNDERLAY term ALL-DIRECT then accept set routing-options autonomous-system 65000 set protocols bgp group UNDERLAY type external set protocols bgp group UNDERLAY multipath multiple-as set protocols bgp group UNDERLAY export EXPORT-UNDERLAY set protocols bgp group UNDERLAY neighbor 10.1.101.1 peer-as 64512 set protocols bgp group UNDERLAY neighbor 10.2.101.1 peer-as 64513 commit 2.4 動作確認 admin@spine1# run show bgp summary ... Peer AS InPkt OutPkt ... State|#Active/Received/Accepted/Damped... 10.1.11.2 65000 6 8 ... 58 Establ 10.1.21.2 65000 5 7 ... 33 Establ 10.1.22.2 65000 4 7 ... 22 Establ 10.1.31.2 65000 4 7 ... 13 Establ 10.1.101.2 65000 4 7 ... 6 Establ Spine から各 Leaf / RR とのピアが Establ (Established) になっていれば OK です。最終的に Border Leaf (leaf3-1) から HV1 の Loopback まで疎通できます。 admin@leaf3-1# run ping 10.255.255.201 source 10.255.255.31 count 3 64 bytes from 10.255.255.201: icmp_seq=0 ttl=62 time=3.254 ms ... 3 packets transmitted, 3 packets received, 0% packet loss ✅ 完成状態チェックリスト Spine から見て、全 Leaf / RR の eBGP セッションが Establ show route 10.255.255.0/24 で全ノードの Loopback が学習されている 任意の Leaf から任意の Leaf の Loopback へ ping が通る HV1 の Loopback ( 10.255.255.201/32 ) が leaf3-1 から見える ここまでで Underlay が完成し、全ノードの Loopback 同士が IP で疎通できる「下地」が整いました。次のセクションで、この上に EVPN/VXLAN の Overlay を被せます。 3. Overlay の構築 — EVPN/VXLAN ここからが核心です。Underlay の上に EVPN（C-Plane） + VXLAN（D-Plane） を被せ、テナントの L2 セグメントを複数 Leaf 間で拡張します。 Q. なぜ VLAN ではダメなのか？ データセンターでは複数のテナント（利用者）が同じ物理スイッチを共有します。テナント同士のトラフィックを分離する最も基本的な手段が VLAN （Virtual LAN）です。しかし VLAN には以下の限界があります。 課題 VLAN の限界 EVPN/VXLAN での解決 ID 数 最大 4,094 個 → 大規模クラウドでは枯渇する VNI は最大約 1,600 万個（VNIについては後述） L2 の拡張 VLAN をラック間に伸ばすにはループ対策（STP）が必要になり、構成が複雑化する VXLAN で L3（IP Underlay）上にトンネルを張るため、STP 不要で任意のラック間へ L2 を延伸可能 MAC 学習のスケーラビリティ データプレーンのフラッディングで MAC を学習するため、規模拡大に伴い帯域を圧迫する EVPN が制御プレーンで MAC/IP を配布するため、不要なフラッディングを抑制できる つまり VLAN は「1 台のスイッチ内 or 隣接スイッチ間」の L2 分離 、 VXLAN は「DC 全体規模」の L2 分離 と役割が違います。本記事で構築するのは後者です。 テナントごとに L3（ルーティング）も分離 したい場合は VRF （Virtual Routing and Forwarding）を使います。VRF はスイッチ / ルータの中に「テナント専用の経路表」を作る技術で、テナント A とテナント B が同じ 192.168.1.0/24 を使っていてもルーティングが混ざりません。本記事のセクション 4 で VRF を使った外部接続を構築します。 3.1 アーキテクチャの整理 各ノードが Overlay において担う役割を整理します。 役割 C-Plane D-Plane Spine （単なる中継） （単なる IP 転送） RR (rr1) iBGP RR、EVPN 経路反射 — Underlay Leaf (leaf1-1) 参加しない 参加しない Overlay Leaf (leaf2-1/2-2/3-1) iBGP/EVPN ピア VTEP（VXLAN トンネルの出入口） HV1 (FRR) iBGP/EVPN ピア VTEP Q. なぜ leaf1-1 は EVPN に参加しないのか？ HV1 が VTEP を持つので、leaf1-1 は単なる IP ルータとして VXLAN パケットを Underlay 越しに転送するだけで済みます。実環境でも同様で、HV 上のソフトウェア VTEP（Contrail vRouter 等）が VTEP の役割を担います。本記事ではそれを FRR で代用しています。 3.2 C-Plane: iBGP EVPN ピア leaf2-1 configure # RR との iBGP（Overlay） set protocols bgp group OVERLAY type internal set protocols bgp group OVERLAY local-address 10.255.255.21 set protocols bgp group OVERLAY neighbor 10.255.255.101 set protocols bgp group OVERLAY family evpn signaling # EVPN/VXLAN 基本設定 set switch-options vtep-source-interface lo0.0 set switch-options route-distinguisher 10.255.255.21:1 set protocols evpn encapsulation vxlan # IRB（L3 ゲートウェイ）を使わない宣言。Type-2 ルートに default-gateway コミュニティを付けない set protocols evpn default-gateway no-gateway-community set protocols evpn extended-vni-list all # RT を明示指定。FRR の advertise-all-vni は AS:VNI 形式（65000:10010）で RT を生成するため、 # Junos 側も同じ値を使う（Junos の vrf-target auto は AS:(VNI+0x10000000) と計算式が異なり互換性がない） set switch-options vrf-target target:65000:10010 commit leaf2-2 / leaf3-1 のコマンドを開く leaf2-2 configure set protocols bgp group OVERLAY type internal set protocols bgp group OVERLAY local-address 10.255.255.22 set protocols bgp group OVERLAY neighbor 10.255.255.101 set protocols bgp group OVERLAY family evpn signaling set switch-options vtep-source-interface lo0.0 set switch-options route-distinguisher 10.255.255.22:1 set protocols evpn encapsulation vxlan set protocols evpn default-gateway no-gateway-community set protocols evpn extended-vni-list all set switch-options vrf-target target:65000:10010 commit leaf3-1 configure set protocols bgp group OVERLAY type internal set protocols bgp group OVERLAY local-address 10.255.255.31 set protocols bgp group OVERLAY neighbor 10.255.255.101 set protocols bgp group OVERLAY family evpn signaling set switch-options vtep-source-interface lo0.0 set switch-options route-distinguisher 10.255.255.31:1 set protocols evpn encapsulation vxlan set protocols evpn default-gateway no-gateway-community set protocols evpn extended-vni-list all set switch-options vrf-target target:65000:10010 commit rr1 configure set protocols bgp group OVERLAY type internal set protocols bgp group OVERLAY cluster 10.255.255.101 set protocols bgp group OVERLAY local-address 10.255.255.101 set protocols bgp group OVERLAY neighbor 10.255.255.21 set protocols bgp group OVERLAY neighbor 10.255.255.22 set protocols bgp group OVERLAY neighbor 10.255.255.31 set protocols bgp group OVERLAY neighbor 10.255.255.201 set protocols bgp group OVERLAY family evpn signaling commit hv1（FRR） vtysh configure terminal router bgp 65000 bgp router-id 10.255.255.201 no bgp ebgp-requires-policy neighbor 10.255.255.101 remote-as 65000 neighbor 10.255.255.101 update-source 10.255.255.201 address-family l2vpn evpn neighbor 10.255.255.101 activate exit-address-family exit end write exit 確認 admin@rr1# run show bgp summary group OVERLAY ... 10.255.255.21 65000 ... Establ bgp.evpn.0: 0/0/0/0 10.255.255.22 65000 ... Establ bgp.evpn.0: 0/0/0/0 10.255.255.31 65000 ... Establ bgp.evpn.0: 0/0/0/0 10.255.255.201 65000 ... Establ bgp.evpn.0: 0/0/0/0 全ピアが Establ (Established) になれば完成です。まだ VNI を作っていないので EVPN 経路は 0 件です。 3.3 D-Plane: VXLAN セグメントを作る VNI 10010 （VLAN 10）を用意し、 VM1（HV1 上、192.168.10.10） と BM1（leaf2-1 配下、192.168.10.101） が同じ L2（同一サブネット、つまり「同じ LAN」）で通信できるようにします。 Q. VNI とは? VXLAN Network Identifier の略。VLAN ID の「拡張版」のようなもので、最大約 1,600 万のセグメントを作れます（VLAN は 4,094 まで）。 ⚠️ 本番では MTU 設計が必須 VXLAN は外側に IP(20) + UDP(8) + VXLAN(8) + Inner Ethernet(14) = 50 バイトのオーバーヘッド が乗ります。テナントが MTU 1500 で通信したいなら、Underlay の物理 MTU を 9000（Jumbo Frame） にするのが定番です。 hv1：Linux Kernel + FRR # VM 模擬の Network Namespace 作成 ip netns add vm1 ip link add veth-host type veth peer name veth-vm ip link set veth-vm netns vm1 ip netns exec vm1 ip link set dev veth-vm address 02:00:00:00:01:10 ip netns exec vm1 ip addr add 192.168.10.10/24 dev veth-vm ip netns exec vm1 ip link set veth-vm up ip netns exec vm1 ip link set lo up # VTEP（VXLAN I/F）作成 ip link add vxlan10 type vxlan id 10010 local 10.255.255.201 dstport 4789 nolearning # Bridge 経由で VM 側と VXLAN を接続 ip link add br10 type bridge ip link set veth-host master br10 ip link set vxlan10 master br10 ip link set vxlan10 up ip link set veth-host up ip link set br10 up vtysh configure terminal router bgp 65000 address-family l2vpn evpn advertise-all-vni exit-address-family end write exit leaf2-1 configure set vlans v10 vlan-id 10 set vlans v10 vxlan vni 10010 set vlans v10 vxlan ingress-node-replication # BM1 接続ポート set interfaces ge-0/0/2 unit 0 family ethernet-switching interface-mode trunk set interfaces ge-0/0/2 unit 0 family ethernet-switching vlan members v10 commit Q. ingress-node-replication とは? SDPF クラウドでは、お客さまに自由な L2 ネットワークを構成していただけるよう、Overlay ネットワークになるべく制限を与えない形でサービスを提供します。そのため、BUM（Broadcast / Unknown unicast / Multicast）トラフィックも通す必要があります。 ingress-node-replication は、この BUM パケットをフラッドする際の方式を指定する設定です。これを有効にすると、Type-3（IM）ルートで学習した各リモート VTEP に対して ユニキャストで複製送信 します。 bm1 ip link set eth1 up ip link add link eth1 name eth1.10 type vlan id 10 ip link set eth1.10 up ip addr add 192.168.10.101/24 dev eth1.10 動作確認 VM1 ↔ BM1 で ping が通り、HV1 で tcpdump を取ると UDP/4789 の VXLAN にカプセル化 されているのが分かります。 # BM1で実行 ~ # ping 192.168.10.10 64 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=3.35 ms ... # HV1で実行 ~ # tcpdump -i eth1 -n -vv udp port 4789 tcpdump: listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes ... IP (tos 0x0, ttl 253, id 21304, offset 0, flags [none], proto UDP (17), length 134) 10.255.255.21.55534 > 10.255.255.201.4789: [no cksum] VXLAN, flags [I] (0x08), vni 10010 IP (tos 0x0, ttl 64, id 44875, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.10.101 > 192.168.10.10: ICMP echo request, id 102, seq 8, length 64 ... IP (tos 0x0, ttl 64, id 21000, offset 0, flags [none], proto UDP (17), length 134) 10.255.255.201.49139 > 10.255.255.21.4789: [udp sum ok] VXLAN, flags [I] (0x08), vni 10010 IP (tos 0x0, ttl 64, id 6907, offset 0, flags [none], proto ICMP (1), length 84) 192.168.10.10 > 192.168.10.101: ICMP echo reply, id 102, seq 8, length 64 leaf2-1 側でも EVPN Type-2（MAC/IP）と Type-3（IM）の経路がリモート VTEP 宛に学習されています。 admin@leaf2-1# run show route table bgp.evpn.0 bgp.evpn.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 2:10.255.255.21:1::10010::aa:c1:ab:0a:18:4a/304 MAC/IP *[EVPN/170] 00:01:12 Indirect 2:10.255.255.201:2::0::02:00:00:00:01:10/304 MAC/IP *[BGP/170] 00:03:21, localpref 100, from 10.255.255.101 AS path: I, validation-state: unverified to 10.1.21.1 via ge-0/0/0.0 > to 10.2.21.1 via ge-0/0/1.0 2:10.255.255.21:1::10010::aa:c1:ab:0a:18:4a::192.168.10.101/304 MAC/IP *[EVPN/170] 00:01:05 Indirect 3:10.255.255.21:1::10010::10.255.255.21/248 IM *[EVPN/170] 00:03:09 Indirect 3:10.255.255.201:2::0::10.255.255.201/248 IM *[BGP/170] 00:03:10, localpref 100, from 10.255.255.101 AS path: I, validation-state: unverified > to 10.1.21.1 via ge-0/0/0.0 to 10.2.21.1 via ge-0/0/1.0 確認のポイントを整理します。 [EVPN/170] Indirect のエントリ（RD 10.255.255.21:1 ）は leaf2-1 自身がローカルで生成した EVPN 経路（自分のポートに接続された BM1 の MAC/IP、および自分が属する VNI の IM ルート）。 [BGP/170] from 10.255.255.101 のエントリ（RD 10.255.255.201:2 ）は RR（rr1）経由で受け取ったリモート VTEP（HV1）からの経路。 to 10.1.21.1 / to 10.2.21.1 の 2 経路が並んでいるのは、spine1・spine2 の両方を経由した ECMP が有効になっているためです。 EVPN の経路情報は BGP によって制御プレーン上でやり取りされ、実際のパケット転送は VXLAN（UDP/4789）がデータプレーンとして担います。tcpdump で確認した通り、 vni 10010 のカプセル化で転送されていることが確認できます。 3.4 EVPN Multihoming（ESI-LAG）で BM の接続を冗長化 セクション 3.3 で VXLAN の疎通は確認できましたが、このままでは BM1 が leaf2-1 の 1 本だけでぶら下がっている状態です。クラウドサービスでは物理故障の単一障害点を排除することが基本要件であり、リンクやスイッチの障害でサーバーが孤立しないよう、複数 Leaf へ冗長接続します。 ここからは BM1 を leaf2-1 / leaf2-2 の両方に接続して冗長化します。BM1 のネットワーク設定をいったん削除して bond に組み直すため、一時的に BM1 ↔ VM1 間の通信が途絶えます。 EVPN Type-1 / Type-4 を活かす ESI-LAG（All-Active） で構成します。 EVPN Multihoming の商用導入事例として、SDPF クラウド開発メンバーが JANOG48 で発表した EVPN Anycast Gateway を商用導入した話 も大変参考になります。 Q. ESI-LAG とは？ 通常の LAG（Link Aggregation）は 1 台のスイッチへの束ねですが、ESI-LAG は 複数台のスイッチをまたいで LAG を組める技術です。サーバーから見ると 1 台のスイッチにつないでいるように見えます。 方針 2 台の Leaf で 同じ ESI と 同じ LACP System ID を設定 → BM1 から見ると単一の LAG 相手に見える BM1 側は Linux bond（mode=802.3ad） leaf2-1（既存設定の置き換え） configure delete interfaces ge-0/0/2 unit 0 set chassis aggregated-devices ethernet device-count 1 set interfaces ge-0/0/2 ether-options 802.3ad ae0 set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk set interfaces ae0 unit 0 family ethernet-switching vlan members v10 # ESI（leaf2-1/2-2 で完全一致させる） set interfaces ae0 esi 00:00:00:00:00:00:00:00:00:01 set interfaces ae0 esi all-active set interfaces ae0 aggregated-ether-options lacp active set interfaces ae0 aggregated-ether-options lacp periodic fast set interfaces ae0 aggregated-ether-options lacp system-id 00:00:00:00:00:01 commit leaf2-2（新規） leaf2-1 と完全に同じ ESI / LACP System ID を投入します。VLAN/VNI/RT もここで作成。 configure set vlans v10 vlan-id 10 set vlans v10 vxlan vni 10010 set vlans v10 vxlan ingress-node-replication set chassis aggregated-devices ethernet device-count 1 set interfaces ge-0/0/2 ether-options 802.3ad ae0 set interfaces ae0 unit 0 family ethernet-switching interface-mode trunk set interfaces ae0 unit 0 family ethernet-switching vlan members v10 set interfaces ae0 esi 00:00:00:00:00:00:00:00:00:01 set interfaces ae0 esi all-active set interfaces ae0 aggregated-ether-options lacp active set interfaces ae0 aggregated-ether-options lacp periodic fast set interfaces ae0 aggregated-ether-options lacp system-id 00:00:00:00:00:01 commit bm1（Linux Bond） ip addr flush dev eth1.10 ip link del eth1.10 ip link add bond0 type bond mode 802.3ad miimon 100 lacp_rate 1 xmit_hash_policy layer3+4 ip link set eth1 down ip link set eth2 down ip link set eth1 master bond0 ip link set eth2 master bond0 ip link set bond0 up ip link set eth1 up ip link set eth2 up ip link add link bond0 name bond0.10 type vlan id 10 ip link set bond0.10 up ip addr add 192.168.10.101/24 dev bond0.10 切断試験 BM1 から VM1 に ping を流したまま、leaf2-1 → leaf2-2 の順にリンクを落とすと、片方が生きている間は ping が継続することを確認できます。 # leaf2-1 で接続断 → ping 継続 configure set interfaces ge-0/0/2 disable commit # leaf2-2 でも接続断 → ping 停止 configure set interfaces ge-0/0/2 disable commit # leaf2-1 を復活 → ping 復活 configure delete interfaces ge-0/0/2 disable commit # leaf2-2 で実行 configure delete interfaces ge-0/0/2 disable commit HV1 から見ると、BM1 の bond0 MAC が leaf2-1 / leaf2-2 の両方から同じ ESI で広告 されています。 ~ # vtysh -c "show bgp l2vpn evpn" Route Distinguisher: 10.255.255.21:1 *>i [2]:[10010]:[48]:[xx:xx:xx:xx:xx:xx] ← bond0 の MAC 10.255.255.21 ESI:00:00:00:00:00:00:00:00:00:01 RT:65000:10010 Route Distinguisher: 10.255.255.22:1 *>i [2]:[10010]:[48]:[xx:xx:xx:xx:xx:xx] 10.255.255.22 ESI:00:00:00:00:00:00:00:00:00:01 RT:65000:10010 💡 bond0 の MAC はカーネルが自動付与します（通常 eth1 の MAC を継承）。実際の値は ip link show bond0 で確認してください。 ESI が両ノードで一致しているため、HV1 はこの 2 経路を Aliasing （ECMP 的にロードバランス）して扱います。つまり、「leaf2-1 および leaf2-2 のいずれを経由しても、BM1 に届く」状態が完成しています。これが ESI-LAG の本質です。 ✅ 完成状態チェックリスト（Overlay全体） RR の OVERLAY グループで全 Leaf / HV1 が Establ HV1 で show evpn vni に VNI 10010 が表示される BM1 → VM1（VXLAN 経由）の ping が通る HV1 の tcpdump -i eth1 udp port 4789 で VXLAN ヘッダ（vni 10010）が見える leaf2-1/2-2 のどちらかのリンクを落としても BM1 → VM1 の通信が継続する show bgp l2vpn evpn で BM1 の MAC が leaf2-1/2-2 の両方から同じ ESI で広告されている ここまでで、EVPN/VXLAN によるテナント L2 拡張と ESI-LAG による冗長接続が完成しました。VM1（HV1 上）と BM1 が物理的に離れていても同一 L2 で通信でき、かつ片方のリンクが落ちても通信が継続する状態です。 4. Border Leaf と Internet Gateway 最後に、テナント網（VRF ＝ 仮想ルーティングテーブル、「テナント専用の経路表」と考えてOK）と外部網（Global ＝ インターネット側）を接続します。 leaf3-1 を VTEP 化 して Overlay の VLAN10 を Internet GW まで延伸 inet-gw1 で VRF-User と Global を Route Leaking inet-gw1 ↔ isp1 で eBGP 、isp1 から default route を受け取る 以下の内容を構成します。 4.1 leaf3-1（Border Leaf として VTEP 化） configure set vlans v10 vlan-id 10 set vlans v10 vxlan vni 10010 set vlans v10 vxlan ingress-node-replication # inet-gw1 接続ポート set interfaces ge-0/0/2 unit 0 family ethernet-switching interface-mode trunk set interfaces ge-0/0/2 unit 0 family ethernet-switching vlan members v10 commit 4.2 inet-gw1: 共通の下準備（I/F + ASN） configure set routing-options router-id 198.51.100.1 set routing-options autonomous-system 65002 # I/F set interfaces ge-0/0/0 vlan-tagging set interfaces ge-0/0/0 unit 10 vlan-id 10 set interfaces ge-0/0/0 unit 10 family inet address 192.168.10.1/24 set interfaces ge-0/0/1 unit 0 family inet address 203.0.113.2/30 set interfaces lo0 unit 0 family inet address 198.51.100.1/32 commit ge-0/0/0.10 がテナント側（leaf3-1 経由で BM1 と同セグ）、 ge-0/0/1.0 が インターネット側（外部）です。 4.3 inet-gw1: VRF と Route Leaking ユーザーの VRF（ VRF-User ）と Global テーブル（ inet.0 ＝ Junos の通常の経路表）を分離しつつ、必要な経路だけ相互にリーク（漏らす）します。これが「Route Leaking」で、「テナント内部の経路をインターネット側に教える（またはその逆）」ことで、テナント内のサーバーがインターネットと通信できるようになります。 configure # Route Leaking ポリシー（双方向） # Global -> VRF: default route のみ VRF に流す set policy-options policy-statement LEAK-GLOBAL-TO-VRF term ALLOW-DEFAULT from instance master set policy-options policy-statement LEAK-GLOBAL-TO-VRF term ALLOW-DEFAULT from route-filter 0.0.0.0/0 exact set policy-options policy-statement LEAK-GLOBAL-TO-VRF term ALLOW-DEFAULT then accept set policy-options policy-statement LEAK-GLOBAL-TO-VRF term DENY-REST then reject # VRF -> Global: BM1 の Global IP（/32）のみ Global へ流す set policy-options policy-statement LEAK-VRF-TO-GLOBAL term ALLOW-BM1 from instance VRF-User set policy-options policy-statement LEAK-VRF-TO-GLOBAL term ALLOW-BM1 from route-filter 198.51.100.41/32 exact set policy-options policy-statement LEAK-VRF-TO-GLOBAL term ALLOW-BM1 then accept set policy-options policy-statement LEAK-VRF-TO-GLOBAL term DENY-REST then reject # VRF 本体 set routing-instances VRF-User instance-type virtual-router set routing-instances VRF-User interface ge-0/0/0.10 set routing-instances VRF-User routing-options instance-import LEAK-GLOBAL-TO-VRF # BM1 の Global IP への static set routing-instances VRF-User routing-options static route 198.51.100.41/32 next-hop 192.168.10.101 # Global 側にも VRF からの経路を取り込む set routing-options instance-import LEAK-VRF-TO-GLOBAL commit 4.4 inet-gw1: 外部 ISP との eBGP 最後に、上で Global にリークした経路を eBGP で 外部 ISP へ広告します。 configure # 外部 ISP へ広告するポリシー（static のみ → 198.51.100.41/32 が乗る） set policy-options policy-statement ADVERTISE-TO-ISP term 1 from protocol static set policy-options policy-statement ADVERTISE-TO-ISP term 1 then accept set protocols bgp group TO-ISP type external set protocols bgp group TO-ISP peer-as 65001 set protocols bgp group TO-ISP neighbor 203.0.113.1 set protocols bgp group TO-ISP export ADVERTISE-TO-ISP commit 4.5 isp1 （外部 ISP 模擬） configure set routing-options router-id 192.0.2.1 set routing-options autonomous-system 65001 set interfaces ge-0/0/0 unit 0 family inet address 203.0.113.1/30 set interfaces lo0 unit 0 family inet address 192.0.2.1/32 set protocols bgp group TO-GW type external set protocols bgp group TO-GW peer-as 65002 set protocols bgp group TO-GW neighbor 203.0.113.2 set policy-options policy-statement SEND-DEFAULT term 1 from protocol static set policy-options policy-statement SEND-DEFAULT term 1 from route-filter 0.0.0.0/0 exact set policy-options policy-statement SEND-DEFAULT term 1 then accept set protocols bgp group TO-GW export SEND-DEFAULT set routing-options static route 0.0.0.0/0 discard commit 4.6 bm1 （Global IP 付与とデフォルトゲートウェイ） ip addr add 198.51.100.41/32 dev bond0.10 ip route replace default via 192.168.10.1 Q. なぜ /32 で付与するのか BM1 が「自分は 198.51.100.41 である」とさえ名乗れれば十分です。戻りパケットのルーティングは inet-gw1 の VRF 内に 198.51.100.41/32 next-hop 192.168.10.101 の static route があるため、ISP → inet-gw1 → (VRF) → leaf3-1 → VXLAN → leaf2-1/2-2 → BM1 と正しく転送されます。 4.7 動作確認 inet-gw1 で Global の inet.0 にも 198.51.100.41/32 が現れます （＝ VRF からのリーク成功）。 admin@inet-gw1# run show route 198.51.100.41 inet.0: 198.51.100.41/32 *[Static/5] > to 192.168.10.101 via ge-0/0/0.10 VRF-User.inet.0: 198.51.100.41/32 *[Static/5] > to 192.168.10.101 via ge-0/0/0.10 そして BM1 → 外部 ISP（192.0.2.1）への ping 、および逆方向の 外部 ISP → BM1（198.51.100.41）への ping がともに通れば、End-to-End の経路が完成です。 ~ # ping -c 3 -I 198.51.100.41 192.0.2.1 64 bytes from 192.0.2.1: icmp_seq=1 ttl=63 time=5.87 ms ... 3 packets transmitted, 3 received, 0% packet loss admin@isp1# run ping 198.51.100.41 count 3 64 bytes from 198.51.100.41: icmp_seq=0 ttl=63 time=6.070 ms ... 3 packets transmitted, 3 packets received, 0% packet loss ✅ 完成状態チェックリスト（Border GW） inet-gw1 の inet.0 と VRF-User.inet.0 の両方に 198.51.100.41/32 が存在 inet-gw1 ↔ isp1 の eBGP が Establ 、isp1 から default route を受信 BM1 → 192.0.2.1 (外部 ISP) の ping が通る（ -I 198.51.100.41 で source 指定） 外部 ISP → 198.51.100.41 (BM1) の ping が通る ここまでで、テナント内の BM1 が VRF Route Leaking を経由して外部 ISP と双方向に通信できる End-to-End の経路が完成しました。本記事で目標としていた全構成の構築が完了です。 全体の完成確認 全セクションを通して構築した結果、冒頭で掲げたゴール — 物理的に離れた HV1 上の VM と BM1 が同一 L2 で通信でき、さらにインターネットへ抜けられる — が達成できています。完成した NW で実現できていることを整理します。 通信パス 経由するレイヤ VM1（HV1）↔ BM1 HV1 (VTEP) → VXLAN → Underlay (Spine経由) → leaf2-1/2-2 (VTEP) → BM1 BM1 → インターネット BM1 → leaf2-1/2-2 → VXLAN → leaf3-1 → inet-gw1 ( VRF Route Leaking ) → isp1 インターネット → BM1 isp1 → inet-gw1 (Global→VRF) → leaf3-1 → VXLAN → leaf2-1/2-2 → BM1 Underlay ：eBGP + ECMP により、どちらの Spine を経由しても全ノードの Loopback が到達可能 Overlay ：EVPN/VXLAN により、異なるラックの VM1 と BM1 が同一 L2（VNI 10010）で通信 冗長化 ：ESI-LAG により、leaf2-1 または leaf2-2 のどちらか一方が故障しても BM1 の通信が継続 外部接続 ：VRF Route Leaking により、テナント内部の経路とインターネット側の経路を相互にリークし、BM1 が外部と双方向に通信可能 これらが組み合わさることで、クラウド NW の基本構成 — マルチテナント対応の L2 延伸・物理冗長・外部接続 — が 1 つのラボ上で再現できています。 おまけ: ハマったら見るところ（Troubleshooting） 手順通りやってもうまくいかないとき、上から順に切り分けると早いです。 症状 確認ポイント BGP が Active から進まない 直結 ping → Loopback 間 ping → peer-as の値 → ポリシーで自分の経路を絞ってないか Underlay は OK だが Overlay iBGP が Active Loopback 間の ping、 local-address が自分の Loopback になっているか EVPN ピアは張れたが経路が来ない 両端の RT が一致しているか、 extended-vni-list の VNI 範囲 ESI-LAG で片側だけしか流れない 2 台の esi と lacp system-id が 完全に 一致しているか Junos 側で何が起きているか覗くコマンド run show bgp summary run show route table bgp.evpn.0 run show route advertising-protocol bgp <neighbor> run show route receive-protocol bgp <neighbor> run show ethernet-switching vxlan-tunnel-end-point remote run show evpn database FRR 側 vtysh -c "show bgp l2vpn evpn summary" vtysh -c "show evpn vni" vtysh -c "show evpn mac vni all" まとめ Containerlab + vJunos でクラウド NW の王道構成を一通り体験しました。しかし、本記事はあくまで学習用であり、実際の運用では次のような事項も検討が必要です。 IRB / Anycast Gateway （各 Leaf に同じ GW IP を持たせる分散 L3 ルーティング） MTU 設計 （Underlay 9000 / テナント 1500） BGP 認証 （MD5） マルチテナント運用 （VNI 数千規模の管理） セキュリティポリシー （マイクロセグメンテーション、ACL） 監視連携 本記事を通じてクラウド NW を少しでも知っていただき、「面白い！」と思っていただけましたら幸いです。 クラウド NW 開発に興味を持っていただけた学生の方は、ぜひインターンのポスト「 【B19】エンタープライズ向け大規模クラウド/ネットワークサービスを支えるコントローラ開発 」や「 【B25】エンタープライズ向け大規模クラウドサービスを支える仮想ネットワークソフトウェア開発 」にご応募ください。

みなさん、こんにちは。株式会社 APTO で Physical AI のデータ基盤を構築している田中です。 近年、ロボット向け VLA モデルの台頭により、AI 開発の成否は「学習データの品質」に強く依存するようになっています。 しかし、大容量かつ厳密な同期が求められるロボットの操作データを品質を落とさずに日々収集することは非常に困難であり、Physical AI 開発における最大のボトルネックとなっています。 このブログでは、同じ課題に直面するチームの参考となるよう、APTO 社がこの「データ収集」のハードルをどのように仕組み化して解決したのかを紹介します。 想定読者 Physical AI / ロボティクス分野でデータ基盤を設計している方 AWS 上で大量データのイベント駆動処理を構築しようとしている方 スタートアップで少人数チームの MLOps を運用している方 APTO が AWS 上に構築している双腕遠隔操作ロボット向けの Physical AI データ基盤について、下の図 1 でグリーンの  ① 収集 の部分 — エッジ側で完全性をどう確定させ、Amazon S3 へどう引き渡しているか — を 3 章シリーズの第 1 章として解説します。データ基盤の全体像は「収集 → キュレーション → 拡張 → 学習 → 評価」という MLOps ループで構成されており、第 2 章ではクラウド側の自動キュレーションパイプラインに相当する ② キュレーション 、第 3 章では ③ 拡張 および ④ 学習 への接続を扱う予定です。なお、本稿で扱う ① 収集ではエッジ側のチェックを「データの同期が取れているか」に絞っており、品質スコアリング・重複判定・PII検査・統計集計などのキュレーション工程はすべてクラウド側で実施する設計です。 図 1: MLOps ループ全体像 — 収集が本稿のスコープ   1. APTO と Physical AI APTO は 2020 年 1 月設立、東京都千代田区にある約 40 名のスタートアップです ( APTO 会社概要 2026時点)。「イノベーティブなアノテーションで AI 開発に変革を」を掲げ、AI データプラットフォーム harBest を軸に、画像・動画・3D (LiDAR)・自然言語・音声まで幅広い学習データ事業を展開するスタートアップです。近年は LLM 開発支援、RLHF、エージェント、RAG といった領域に加え、Physical AI のユースケースを増やしています。 その一環として、双腕の遠隔操作ロボット (bimanual teleoperation robot) からデータを集め、Vision-Language-Action (VLA) モデルのファインチューニングに供する自社基盤を AWS 上で開発しています。本基盤の中心は「収集 → 自動キュレーション → 学習」のループを効率よく回し続けるための仕組みであり、このブログではそのうち最も上流にあたる「収集」を扱います。 2. 背景と課題 Physical AI とデータ基盤の関係 Vision-Language-Action (VLA) モデルは、視覚と言語指示を統合してロボットの動作を生成する基盤モデルとして、研究と産業応用の両面で進展しています。Google DeepMind の RT-2 、Physical Intelligence の π0 など、大規模 VLA モデルが相次いで発表されており、ファインチューニング向けの高品質データセットへの需要は今後も拡大が見込まれます。 ファインチューニングの成否は、モデルアーキテクチャの良し悪し以上に「投入するデータが安定した品質で揃っているか」に依存します。LLM の RLHF データセットに対する経験則と同じく、Physical AI でもデータおよびそれを提供するデータ基盤の完成度がモデル品質の上限を決める構造になりつつあります。 データを利用する上で直面する 3 つの構造的課題 Physical AI のデータパイプラインを運用しようとすると、次の課題に必ず突き当たります。 収集現場の不安定性 : 双腕ロボットの遠隔操作中に PC が落ちる、USB が外れる、オペレータが途中で介入する、といった事象は日常的に発生します。1 件でも破損エピソードが混入すれば、その後の再現実験や学習指標の信頼性が損なわれます。 後段クラウドで品質判定するコスト : 1 エピソードが数百 MB〜数 GB に達するため、「ひとまず Amazon S3 にアップロードしてから品質判定する」設計では、転送・ストレージ・再ハッシュのコストが線形に積み上がります。 手動キュレーションの限界 : 収集 → キュレーション → 学習 のループを回すには、目視確認・品質ラベル付け・Snapshot 構成といった工程を機械化しなければ、収集にキュレーションが追いつきません。 本基盤が目指す状態 これらを踏まえ、APTO の Physical AI データ基盤は次の状態を実装目標としています。 不完全なエピソードは エッジ側で除外 し、Amazon S3 には「完成したエピソードだけ」が届く Amazon S3 への到着をイベント駆動で受け取り、人間の判断は Release 承認のみ に限定する レビュアーは、クラウド側のキュレーションパイプラインが算出する品質ゲート結果・データセット統計・lineage を見て承認 / 差し戻しを判断する (詳細は次回ブログで扱う) データの ID をハッシュから導出し、ingest を 冪等 にする (同じデータを何度取り込んでも結果が変わらない)   3. Physical AI のデータ収集が難しい理由 図 2: 収集からキュレーションまでのデータフロー全体像 模倣学習 (imitation learning) は、お手本となるデモンストレーションデータを再現するようにポリシーモデルを学習させる手法です。Physical AI の文脈では、教師データの候補として 人間のテレオペレーションで収集されたデータとシミュレーション環境で生成された合成データが挙げられます。現時点では動作や映像の自然さや接触の忠実度といった面でテレオペデータの方が品質が高いと考えられ、多くの場合は人間が遠隔操作したロボットの動作を再現するようにモデルを学習させます。VLA モデルのファインチューニングでは、この教師データとして用いる「人間のデモンストレーション」が一定品質で揃っていることが前提となります。 ところがロボットの生ログには、次の三つのノイズが必ず混入します。 アクションと状態の混在 : 双腕遠隔操作では、人間が操作するリーダーアームと追従するフォロワーアームを別ストリームとして残さないと、 action と state が同一テンソルに混ざってしまいます。これは学習側のラベル設計を破壊します。 同期ズレ : カメラフレームとモータサンプルのタイムスタンプ差分が一定値を超えると、視覚と動作の対応関係が崩れます。本実装では WARNING / CRITICAL（2ms / 5ms）の二段階閾値で逐次判定しています。 エピソードの欠損 : 書き込み中に PC が落ちた、人間が途中で介入した、といった理由で不完全なエピソードが混じります。1 件の混入で再現実験の信頼性が失われます。 図 3: 双腕遠隔操作の Leader / Follower 構成   これらを後段のクラウドで除去する設計は費用対効果が悪く、Amazon S3 にアップロードしてから「不完全だった」と判明する経路では、転送と再ハッシュのコストが線形に積み上がります。本基盤ではエッジ側で完全性を確定させ、不完全なエピソードは S3 に渡さないことを設計の出発点としました。 4. 設計を貫く 3 原則 本基盤を貫く設計原則は次の 3 つです。データ品質を担保するためのルールとして先に定義し、そのうえでルールに則って AWSのサービスや機能を選定しています。 Immutability : Episode / Snapshot / Batch は一度作ったら書き換えません。修正は新ハッシュで別エンティティを作り、 derived_from で系譜を残します。 Content-Addressed Storage : エピソードの ID はファイル群の決定論的ハッシュから導出します。同じデータを何度取り込んでも同じ ID になり、ingest が冪等になります。 Event-Driven : 完了したエピソードの到着を S3 イベントで検知し、自動処理を駆動します。人間の判断は Release 承認のみに限定します。   5. 収集エンジンの 3 プロセス構成 図 4: sync-engine の 3 プロセス分離   エッジ PC 側の収集エンジン (sync-engine) は、責務の異なる 3 つのプロセスを共有メモリ ( SharedRingBuffer ) で接続する構成を採っています。 Collector プロセス : センサーとカメラからの読み取り、H.264 と FFV1 (深度) の動画エンコードを担当します。 Sync プロセス : メタデータだけでタイムスタンプを照合し、同期品質を逐次判定します。 Storage プロセス : motor_state.bin / sync_log.bin / events.jsonl などのバイナリファイルをディスクに書き出します。 この 3 プロセス構成は、後述する異常停止時の安全装置 (QualityMonitor) と直接結びつきます。Sync プロセス内で品質劣化を検知した時点で multiprocessing.Event を立て、Collector / Sync / Storage の 3 つを同時にグレースフル停止し、エピソードに .failed センチネルを置く流れです。 6. raw フォーマットの設計 現状のフォーマット選定と今後の方向性 エッジで保存する原本 (raw) のフォーマットは、学習で使う LeRobot v3.0 への変換前データを格納するレイヤです。Physical AI / ロボティクスで一般に検討される候補と評価ポイントを並べると次のようになります。 候補 評価ポイント apto-raw-v5 (現行試行) 変換前の物理層を可逆に残せる。当面の運用には十分だが標準ではない MCAP (Foxglove + ROS 2) スキーマと可視化が強い。ロスレス深度動画 (FFV1) や CAN-FD 生ログを 1 階層に同居させる運用を確立できれば有力候補 HDF5 自己 記述型で扱いやすい一方、動画コーデックの選択肢が限定的、巨大単一ファイルが S3 のオブジェクト単位アップロード／部分取得と相性が悪いという課題 Apache Arrow IPC 列指向で学習側との親和性は高い。Stream Format で追記は可能だが、エピソード途中で異常終了した際の整合性保証が現時点のネック これらを踏まえ、現時点では自前の apto-raw-v5 を試行的に採用しています。標準フォーマット側で「ロスレス深度動画 + CAN-FD 生ログを 1 階層に同居させる」運用ノウハウが揃いきっていないため、まずは可逆性と運用容易性を優先した暫定解という位置づけです。 ただし、このレイヤのフォーマット選定は引き続き検討中で、Physical AI 周辺のフォーマット標準は流動的なため、将来的に MCAP などの標準フォーマットへ移行する可能性は残しています。いずれを採るにせよ、(1) 全タイムスタンプを int64 ナノ秒で統一する、(2) CAN-FD 生ログをそのまま保持する、(3) 深度動画をロスレスで保持する、という三点はフォーマット選定に依らず満たす方針です。これらは将来「キュレーションをやり直す」「別の特徴量を後付けで計算する」という要件に直接効いてきます。 クロック同期源 i64 ns で精度を確保しても、各センサーのクロック源が揃っていなければ同期判定そのものが意味を失います。本基盤では次の方針を取っています。 カメラ : PTP (IEEE 1588) 対応の GigE Vision カメラを採用し、PC ホストを PTP マスタとして全カメラを同期。フレームには PC 受信時刻ではなくカメラ側ハードウェアクロックのタイムスタンプを正として保存します。 モータ (CAN-FD) : CAN フレーム自体はタイムスタンプを持たないため、CAN コントローラの SOF 受信タイミングを PC ホストの CLOCK_MONOTONIC_RAW で打刻しています。CANコントローラのHWタイムスタンプを使う方法も考えられます。 WARNING / CRITICAL 閾値の根拠 : カメラフレーム間隔 33 ms (30 fps) に対し、サブフレーム精度を保つために WARNING 2 ms、CRITICAL 5 ms を設定。CRITICAL を超えるとフレーム内での視覚と動作の対応関係がずれ、模倣学習で扱えなくなります。 PTP 同期がない環境では NTP のミリ秒精度に劣化し、CRITICAL を超えるリスクが増えます。本基盤を別環境に適用する場合は、まずクロック同期源の選定が出発点になります。 7. 完全性をエッジで確定させる仕組み 収録中の電源断・プロセスクラッシュで、エピソードが「途中まで書かれた状態」になることは避けられません。問題はそれを後段が完成済みと誤認することです。誤認すると不完全なデータが学習データセットに混入します。エッジ側では「途中で壊れた状態のエピソードを下流に流さない」ことを最優先にしています。 エッジでは抽象度の異なる3つの層で完全性を担保します。 防ぐ失敗 仕組み 失敗時のマーカー レイヤ 1: ファイル単位 単一ファイルが書きかけのまま本来名で残る アトミック書き込み: .part 拡張子で書き出し → fsync → atomic rename 中間ファイルは .part のまま残る（本来名は存在しない） レイヤ 2: エピソード単位 個々のファイルは完全だが、エピソード全体としては途中で中断している .done センチネルによる完了判定。全ファイルが揃った後に .done センチネルを置く .done が存在しない レイヤ 3: 意味的品質 ファイルとしては完全だが、同期ズレで学習に使えない 同期品質劣化時の安全停止 (QualityMonitor): QualityMonitor が閾値超過を検知 .failed を置く 後段（クラウド ingest や Storage プロセス側のスキャナ）は、この3つのマーカーだけを見て「完了 / 未完了 / 失敗」を判定します。中身のパースや SHA-256 検証は後段の責務として明確に切り分けています。 ファイルの存在だけを完了条件にしている理由は、 復旧時の判断を静的検査だけで完結させたい ためです。「特定ファイルが存在するか否か」だけで判定できれば、復旧ロジック自体を実質的に ゼロにできます。後述する Amazon S3 Event Notifications のフィルタ設計も、この原則の延長線上にあります。 全体シーケンス まず初めに全体の流れを図示します。 各データファイルを .part で書き出し → fsync → atomic rename manifest.json を atomic write + 親ディレクトリ fsync 正常完了なら .done、異常停止なら .failed を touch RawUploadAgent が各ファイルを並列 PUT 後、manifest.json を最後に PUT して S3 Event を発火 ファイル単位のアトミック書き込み 個々のファイルは次の手順で書き出します。 .part 拡張子で書き出す（例: cam_front.mp4.part ） 書き終わったら fsync() でデータを物理デバイスに永続化する os.replace() で .part を本来名（例: cam_front.mp4 ）にアトミックに rename する 親ディレクトリに対して fsync() を呼び、ディレクトリエントリの変更も永続化する この手順を守ることで、電源断が起きても「古い完全なデータが残っている」「新しい完全なデータが置かれてい る」「 .part のまま残っている」のいずれかにしかならず、 本来名で半端なファイルが見える状態は発生しません 。 manifest.json も同じ手順で書き出します。 また、エッジストレージ は NVMe SSD + ext4 (data=ordered) を採用しています。ext4 の data=ordered モードでは、データブロックがジャーナル commit より先にディスクへ書き出されることが保証されます。このため、fsync() + os.replace() の組合せでクラッシュ後も「古い完全なデータ」または「新しい完全なデータ」のどち らかが必ず観測されます。これは アトミック書き込みが成立する前提条件です。NFS / FUSE 等にファイルシステムを変更する場合、アトミック書き込みが破綻する可能性があるため、必ず再評価が必要です。 エピソード単位の完了判定 すべてのファイルが揃った時点で、エピソードディレクトリ直下に .done を touch します。途中で中断した場合は .done を置かないか、QualityMonitor が .failed を置きます。 完了検知は、 .done と manifest.json の両方が揃っているかだけで判断します。中身のパースや整合性チェックはクラウド側 ingest の責務として後段に切り分けています。 意味的品質を守る安全装置 (QualityMonitor) ファイルが完全に書けても、収録中の同期品質が劣化していれば学習には使えません。Sync プロセスはカメラフレームと最近傍モータサンプルのタイムスタンプ差分（同期ズレ）を逐次監視しています。この差分の時系列は原本中の sync_log.bin に保存され、後段の品質ゲートでも参照できます。 QualityMonitor が .failed を置く判定条件は次の二つです。 CRITICAL レベルのドリフトが一定フレーム数連続する 観測ウィンドウ内で CRITICAL の割合が一定割合を超える いずれかを満たした時点で、3 プロセス全体（Sync / Storage / Camera）をグレースフル停止し、エピソードに .failed センチネルを置きます。これにより、品質が劣化したフレームが含まれるエピソードはクラウ ドに渡る前にエッジで除外されます。 8. Amazon S3 へのアップロード manifest.json を最後に PUT する設計 RawUploadAgent は完了したエピソードのディレクトリを 1 ファイルずつ Amazon S3 raw バケットにアップロードします。ここで重要なのは、 manifest.json を 最後に PUT することです。 理由はクラウド側の S3 Event Notifications との接続にあります。1 エピソードから 8 オブジェクト前後が生成されますが、すべてに対してイベントを発火させると下流の Amazon SQS キューが 8 倍に膨らみます。さらに、まだアップロード途中の状態で Worker が S3 を読みに行くと、ファイル不一致による偽の IntegrityError が DLQ に積まれてしまいます。 そこで、(1) S3 Event Notifications 側でフィルタを filter_suffix = "/manifest.json" に絞り、(2) manifest.json は他の全ファイルの PUT が完了してから最後に置く、という二段の制約で「完了したエピソード 1 つに対して SQS メッセージ 1 つ」を成立させています。 この設計が成立するのは、S3 Event Notifications がオブジェクトキーの prefix / suffix フィルタをネイティブにサポートしているからです。Terraform での設定はほぼ次の 1 ブロックに収まります。 resource "aws_s3_bucket_notification" "raw" { bucket = aws_s3_bucket.raw.id queue { queue_arn = aws_sqs_queue.s3_events.arn events = [ "s3:ObjectCreated:Put" ] filter_suffix = "/manifest.json" } depends_on = [aws_sqs_queue_policy.s3_events] } filter_suffix を /manifest.json に固定するだけで、エッジ側が manifest.json を最後に PUT した瞬間にのみ SQS メッセージが 1 件キューに入る関係が S3 側で完結します。 実装は concurrent.futures.ThreadPoolExecutor で並列 PUT し、 as_completed() で全 future の完了を待ってから manifest.json を PUT します。1 つでも失敗していれば例外を伝播させ、 .failed を残してエピソード全体を破棄します。 from concurrent.futures import ThreadPoolExecutor, as_completed def upload_episode (episode_dir: Path , bucket: str , key_prefix: str ) -> None : data_files = [f for f in episode_dir.iterdir() if f.name not in { "manifest.json" , ".done" }] with ThreadPoolExecutor(max_workers= 8 ) as pool: futures = [pool.submit(_put_with_checksum, f, bucket, f"{key_prefix}/{f.name}" ) for f in data_files] for fut in as_completed(futures): fut.result() # raise on failure → episode を破棄 # 全データファイル PUT 完了後に manifest.json を最後に PUT # → S3 Event Notifications の filter_suffix="/manifest.json"が発火 _put_with_checksum(episode_dir / "manifest.json" , bucket, f"{key_prefix}/manifest.json" ) _put_with_checksum は boto3 の put_object(ChecksumAlgorithm="SHA256") を呼び、S3 の Additional Checksum 機能でサーバ側でも SHA-256 を再計算させてオブジェクトメタデータに保存します。Worker 側の再計算検証と組み合わせ、データ整合性は二重に担保しています。 .tar でまとめない理由 今回はエピソードを .tar でまとめずに、ディレクトリ構造をそのまま Amazon S3 のキー階層に写し取る方針を採っています。tar 一括 PUT 案と個別 PUT 案を精査した結果、コスト差は小さく(現状 8 ファイル/エピソード規模で損益分岐は約 43 ファイル)、判断は技術観点で決まりました。個別 PUT を選んだ主な理由は次の通りです。 後段 Stage の非対称なアクセスパターン : CosmosStage(映像品質判定)は動画のみ、学習(DataLoader)は Parquet のみを必要とします。個別 PUT なら必要なファイルだけ GET できますが、tar 化すると毎回全体を GET して展開する必要があり、特に GPU ノードで I/O 待ちが発生するのは設計として不適切です。 CopyObject による stream-copy 最適化が崩れる : ColdConvertStage では動画を raw から cold へ CopyObject で転記し、ECS Worker の CPU・帯域コストをゼロに抑えています。これは個別ファイルが独立した S3 オブジェクトとして存在することが前提です。 tar の「全か無か」性質との不整合 : 部分破損で全体が読めなくなる、Range Request で部分読みできない、Glacier 復元で毎回全体を取り出すことになる、IAM / KMS 粒度がファイル単位で切れない、といった問題が積み重なります。 なお tar 形式そのものを否定しているわけではなく、学習配布用の WebDataset 形式や Glacier Deep Archive への長期アーカイブなど、raw アップロード経路とは別レイヤーで tar 化する価値がある用途は存在します。 9. まとめと次回予告 このブログでは、Physical AI のデータ基盤において「完成したエピソードだけを AWS に渡す」状態をエッジ側でどう作るかを解説しました。要点は次の三点です。 自前フォーマット apto-raw-v5 を採用 : i64 ns タイムスタンプ・CAN 生ログ・ロスレス深度を 1 階層で保持しています。MCAP / HDF5 / Apache Arrow IPC のいずれでもこの組合せを単独では満たせなかったためです。 完了判定をファイル存在のみに統一 : .done と manifest.json の両方が揃ったときだけ完了とみなす原則を採り、状態機械の複雑化を避けました。これがクラウド側のイベント駆動設計に直結します。 manifest.json を最後に PUT : Amazon S3 Event Notifications を「エピソード完了 = 1 通知」という対応関係に整理しました。 Physical AI のデータパイプラインを長く回し続けるには、「機械的にやれる工程は全部自動に寄せ、人間の判断を Release 承認だけに集中させる」ことが鍵となります。エッジ側で完全性を確定させる本稿の設計は、その自動化を成立させる土台です。 第 2 章では、この manifest.json 到着イベントを起点に動く AWS 側のキュレーションパイプラインを扱います。Amazon S3 → Amazon SQS → Amazon ECS Fargate Worker のイベント駆動 ingest、Episode / Snapshot / Batch の 3 層モデル、9 サブステップの構造化キュレーションと 2 階層品質ゲートが中心です。続く第 3 章では、データ拡張と VLA ファインチューニングへの接続、シミュレーション環境との統合、マルチロボット対応の方向性を予告編としてお届けします。 同じような課題に取り組まれているスタートアップの参考になれば幸いです。 We are hiring!! APTOは、AIやPhysical AI領域のデータに特化したサービスを提供しています。 技術の実装を進めたい方、研究開発に興味がある方などは、下記採用ページからエントリーください！ https://apto.co.jp/careers/ 著者プロフィール 田中 達也 (Tatsuya Tanaka) APTOにてPhysical AIやロボティクス領域のデータパイプライン開発、およびUI構築をメインに担当しているAIエンジニアです。データの同期やマルチモーダルデータ管理など、AI活用に向けたデータ基盤の設計・開発に従事しています。趣味は競技プログラミングと陸上観戦。学生時代は陸上一筋でしたが、現在はもっぱら見る専門です。 遠藤 俊策 (Shunsaku Endo) ポジション: Co-founder / AI Engineer バンタンゲームアカデミーで、学内の審査会で数々の賞を受賞。その後、AI開発にも興味を持ち2020年1月にAPTOを共同創業。現在は、APTOのCDOとして開発とビジネス双方を管理。 GitHubアカウント: synsax( https://github.com/synsax ) 黒澤 蓮 (Ren Kurosawa) は AWS Japan のソリューションアーキテクトで、Startup 業界のお客様を中心にアーキテクチャ設計や構築をサポートしています。データアナリティクスサービスや機械学習の領域を得意としています。将来の夢は宇宙でポエムを詠むことです。  

スタートアップとの仕事には、本当に刺激的な何かがあります。私は 2 年以上にわたって、このような仕事に精力的に取り組んできました。スタートアップは、他とは異なる周波数で活動しています。切迫感は切実で、制約は厳しく、背負っているリスクは個人的なものです。これらのスタートアップがビジネスモデルを証明するという課題を乗り越えるのをサポートするには、技術的な専門知識だけでなく、迅速に行動し、前提を疑い、まだ完璧なデータが存在していない時点から適切なアーキテクチャに賭ける意欲が必要です。 私が最も気に入っているのは、仕事が決して抽象的ではないことです。すなわち、スタートアップが下すのを私がサポートするあらゆる意思決定は、適時に製品を出荷できるか、予算内に収めることができるか、投資家から次のラウンドで信頼を得られるかに直接影響があるのです。 2026 年 5 月 25 日週の AWS ニュースを見ていきましょう。 ヘッドライン 新規開設 – トルコのイスタンブールにおける AWS ローカルゾーン – AWS はトルコのイスタンブールに新しいローカルゾーンを開設しました。これにより、欧州最大の都市圏の 1 つに AWS のコンピューティング、ストレージ、ネットワーキングサービスを提供できるようになりました。トルコでデータレジデンシーに関する要件を満たす必要がある組織にとって、このローカルゾーンは、AWS サービスのあらゆる機能をフル活用しながら、データを国内に保持することを可能にします。また、エンドユーザーの実際の所在地により近い場所で実行できるため、リアルタイムゲーム、メディア制作、ライブ動画ストリーミング、金融サービスなど、1 桁ミリ秒のレイテンシーを必要とするアプリケーションに、ローカルゾーンは大きなメリットをもたらします。 ローカルゾーンは、大規模なインフラストラクチャ投資です。すなわち、ハードウェア、電力、ネットワーキング、運用上の優秀性といった点で、リージョンと同じレベルのコミットメントが必要となります。また、これは、サービスが行き届いていない市場への継続的な拡大を反映する AWS の取り組みでもあります。 トルコのビルダーにとって、これは一連の新たなアーキテクチャの可能性を切り開くものです。データレジデンシーに関する要件を満たすのに役立つよう、トルコ内にデータを保存およびバックアップできるようになったほか、イスタンブールのローカルゾーンで低レイテンシーワークロードを実行し、AWS リージョンにシームレスに接続できるようになりました。そのため、独自のデータセンターインフラストラクチャを管理することなく、ハイブリッドアプリケーションを構築するための柔軟性が得られます。トルコにおける 10 年にわたる当社の取り組み、利用可能なサービス、お客様、パートナーに関する詳細については、 立ち上げに関するブログ記事 にアクセスしてください。 2026 年 5 月 18 日週のリリース 私が注目したいくつかのリリースや最新情報をいくつかご紹介します: Security Hub Extended が 9 つのカテゴリにわたる 21 の厳選されたパートナーソリューションに対応 – AWS Security Hub Extended は、エンドポイント保護、クラウドセキュリティ体制管理、脅威インテリジェンスなど、9 つのカテゴリにわたる 21 の厳選されたパートナーセキュリティソリューションと統合するようになりました。カスタム統合を必要とせずに、より広範なツールエコシステムから、統合され、優先順位付けされた、セキュリティに関する検出結果を Security Hub 内で直接取得できるようになりました。これは、AWS およびサードパーティーツール全体にわたるセキュリティ体制の統合ビューを求めているエンタープライズセキュリティチームにとって特に有益です。 Amazon SageMaker AI now supports OpenAI-compatible APIs for inference endpoints – OpenAI 互換 API を使用して、Amazon SageMaker AI の推論エンドポイントを呼び出せるようになりました。これにより、SDK の変更なく、AI ワークロードを OpenAI から SageMaker に移行したり、複数のプロバイダー間で機能するアプリケーションを構築したりすることが大幅に容易になります。これにより、OpenAI を使用してプロトタイピングを開始し、AWS 上の、よりスケーラブルでコスト管理されたインフラストラクチャへの移行を検討しているチームにとって、移行のハードルが下がります。既存のアプリケーションコードはそのまま使用できます。必要なのは、SageMaker エンドポイントをポイントすることだけです。 AWS Secrets Manager Agent のプリフェッチと IAM ロール引き受けの紹介 – AWS Secrets Manager Agent は、起動時にシークレットをプリフェッチし、IAM ロールを引き受けてそれらのシークレットを取得できるようになりました。これにより、レイテンシーが重要な要素となるアプリケーションでオンデマンドのシークレット取得に伴うコールドスタート時のレイテンシーが解消されます。エージェントを設定することで、アプリケーションがトラフィック処理を開始する前に必要なシークレットをプリロードできるため、本番におけるシークレット関連のレイテンシースパイクのリスクを軽減できます。また、IAM ロールの引き受けのサポートにより、アクセス許可の境界が異なるワークロード間でエージェントを共有することも容易になります。 AWS がオープンソースの DynamoDB 互換アダプター ExtendDB を発表 – AWS は、DynamoDB 互換アダプター ExtendDB をオープンソース化しました。これにより、代替バックエンドストレージシステム上で DynamoDB API とデータモデルを利用できます。これは、ローカル開発およびテストワークフローにおいて特に有用です。ライブ AWS 接続を必要とせずに DynamoDB API への書き込みが可能です。また、基盤となるストレージレイヤーをより詳細に制御しながら DynamoDB 互換のセマンティクスを必要とするシナリオにも役立ちます。これは、データアクセスレイヤーに移植性を組み込みたいチームにとって実用的なツールです。 AWS SAM CLI がローカルのサーバーレス開発を加速するために AWS CloudFormation Language Extensions のサポートを追加 – AWS SAM CLI が AWS CloudFormation Language Extensions をローカルでサポートするようになりました。これは、変換、動的参照、および他の CloudFormation 言語機能を、ローカルの開発およびテストワークフローで直接使用できることを意味します。これにより、ローカルでテストできるものと、本番で実行されるものの間に長年存在していたギャップが解消され、ローカルでのサーバーレス開発がより高速かつ信頼性の高いものになります。SAM を使用してサーバーレスアプリケーションを構築し、ローカルテストでエッジケースに遭遇した場合、このアップデートによってエクスペリエンスが大幅に改善されます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 興味深いと思われる追加の記事やリソースをいくつかご紹介します: Amazon Bedrock introduces new advanced prompt optimization and migration tool – この記事は、Amazon Bedrock で新たにリリースされた高度なプロンプト最適化および移行ツールをカバーしています。これらは、お客様がモデルのパフォーマンスを向上させるためにプロンプトを自動的にチューニングするのに役立ち、異なる基盤モデル間でプロンプトを移行するのを支援します。本番 AI ワークロードにおけるプロンプトの質のイテレーションに取り組んでいる場合は必読です。 Introducing Kiro Web – AWS の AI 利用開発環境である Kiro に、ウェブベースのインターフェイスが追加されました。Kiro Web を使用することで、デスクトップ IDE をインストールすることなく、ブラウザから直接、Kiro の仕様駆動型開発、AI チャット、エージェント機能にアクセスできます。これは、クイックレビュー、新しいマシンでのプロトタイピング、チームへの Kiro ワークフローの導入など、あらゆる場面において、AI 支援開発をより身近なものにするための大きな一歩です。 Announcing updated retry behavior for AWS SDKs and Tools – AWS は、SDK および CLI ツール全体のデフォルトのリトライ動作を更新しました。これにより、デベロッパーによる設定変更を必要とせずに、一時的なエラーに対する回復力が高まりました。更新された動作には、よりスマートなバックオフ戦略と、スロットリング応答のより適切な処理が含まれています。API レート制限や一時的な障害に時折遭遇する本番ワークロードを実行している場合、今回のアップデートにより、すぐに信頼性が高まります。変更内容とアプリケーションへの影響を理解するために、ぜひご一読ください。 Bitnami image removal from ECR Public – AWS は、Bitnami コンテナイメージが Amazon ECR Public から削除されることを発表しました。ワークロードが ECR Public から Bitnami イメージをプルしている場合は、この記事を確認して、タイムラインと移行パスを理解してください。Bitnami イメージは Bitnami の独自のレジストリから引き続き直接入手できます。この記事では、イメージ参照を更新して中断なくプルし続ける方法について説明しています。 今後の AWS イベント カレンダーを確認して、これらのイベントにサインアップしましょう: AWS Summit Amsterdam – 5 月 27 日にアムステルダムで開催され、クラウドと AI に関するセッション、ハンズオンラボ、欧州各地のビルダーや AWS エキスパートとのネットワーキングといった、盛りだくさんの 1 日をお過ごしいただけます。登録は無料です。 AWS Summit Bangkok – AWS Summit Bangkok は 5 月 28 日に開催されます。東南アジアのビルダーやお客様にとって、クラウドイノベーションの最新情報を詳しく知り、つながるための絶好の機会となります。 AWS Summit Milan – 同じく 5 月 28 日、AWS Summit Milan がイタリアで開催されます。AWS コミュニティが一堂に会します。南欧州にお住まいの方は、ぜひご参加ください。 AWS Summit Mumbai – 同じく 5 月 28 日、AWS Summit Mumbai が、クラウドと AI に関するコンテンツをインド全土のビルダーにお届けします。詳細なアジェンダと登録については、リンクをご確認ください。 AWS Summit Los Angeles – ロサンゼルスにおける 6 月 10 日のイベントをお見逃しなく。近日開催予定の AWS Summit LA は、西海岸のビルダーコミュニティとつながる絶好の機会です。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンス。ラテンアメリカにお住まいの方は、8 月 22 日に開催される AWS Community Day Belo Horizonte をお見逃しなく。登録は awscommunityday.com.br で受付中です。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 2026 年 5 月 25 日週のニュースは以上です。2026 年 6 月 1 日週の Weekly Roundup もお楽しみに! – Daniel Abib この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。