FJCT Tech blog

富士通クラウドテクノロジーズ公式エンジニアブログです

富士通クラウドテクノロジーズ

FJCT/Tech blog

データセンタ間ネットワーク接続技術:EVPN-VXLANのActive-Active構成を試しました

この記事は富士通クラウドテクノロジーズ Advent Calendar 2018 14日目です。

目次

はじめに

インフラデザイン部で主にネットワークの企画/設計/運用を担当している、 入社1年目の id:foobaron です。

今回は、 EVPN-VXLAN による拠点間の接続を試してみました。

想定する読み手

本記事は次の読者を想定しています。

  • クラウドの閉域網接続に利用される技術を知りたい方
  • JunosでEVPNを動かしてみたい方

EVPN登場の背景と課題

EVPNの登場以前からVPLS (Virtual Private LAN Service) といった従来のL2 VPN技術があります。 こうした技術と比べ、EVPN導入のメリットとして、次のようなものが挙げられます。

  • EVPN網のエッジに存在する機器でのAll-Active Multihomingによる帯域利用効率向上
  • Control planeによるBUM (Broadcast, Unknown unicast, Multicast) トラフィックの フラッディング抑制と最適化
  • 高速な経路収束

従来は、MC-LAG (Multi-Chassis Link Aggregation Group) などのベンダー独自実装 によって、Multihomingを実現していました。 EVPNでのMultihomingはRFC 7432で標準化されており、 マルチベンダーで実現可能です。

またVXLANなどでは、BUMトラフィックに対しARP requestやNeighblor soliitationで フラッディングが発生しますが、EVPNではIngress ReplicationやSplit Horizonという仕組みにより BUMトラフィックの抑制と最適化をします。

従来のL2VPNでは、障害発生により多数のMACアドレスへの到達性に影響がある場合、 経路収束が長期化する恐れがありますが、EVPNではこの問題に対処しています。

EVPNの概要

f:id:foobaron:20181213230721p:plain
EVPNのControl plane/Data plane

EVPNでは図のように、Control planeとData planeが分離されています。 VPLSなどがData planeでMACアドレスを学習するのに対し、 MPLSではControl planeでMACアドレスの学習を実現します。 Control planeにはEVPN MP-BGPを、Data planeにMPLS (Multi-Protocol Label Switching) や PBB (Provider Backbone Bridge)、NVO (Network Virtualization Overlay) (VXLAN等) を利用します。

EVPN-VXLANの構成要素と用語

まずはEVPN-VXLANの構成要素と用語について確認しておきます。 EVPN-VXLANの構成要素は図のとおりです。

f:id:foobaron:20181213230844p:plain
EVPNの構成要素と用語

EVPN-VXLANの構成要素

  • Customer Edge (CE) device :EVPN網のエッジに存在する機器です。 例:データセンタ内の物理/仮想マシン、ルータ、スイッチ等。
  • Provider Edge (PE) Router:コアネットワークのエッジルータです。 VXLANトンネルのエンドポイント(VTEP:VXLAN Tunnel End Point)となります。
  • Provider Router (P Router):コアネットワークのコアルータです。 PE Routerでカプセル化されたVXLANパケットをPE Routerまで中継します。

EVPN-VXLANの用語

  • EVPN Virtual Instance (EVI) :PE Router内に作成され、特定のEVPNに紐づくインスタンスです。 CE deviceを分離させたい単位でインスタンスを分けることもできます。
  • MAC-VRF:PE Router上のEVIごとに持つ、MACアドレスのVRF (Virtual Routing and Forwarding) テーブルです。CE deviceのMACアドレス情報を保持します。
  • Route Distinguisher (RD) :MAC-VRFごとに一意の識別子です。CEに対して適切なMAC-VRFを選択するために使用します。
  • Route Target (RT) :EVI上のMAC-VRFが、必要なMP-BGPの経路情報のみを受け取るために使用する属性値です。複数のRT値を付与して経路広告することができます。
  • Ethernet Segment (ES) :CEがPEに接続するL2セグメントです。CEがMultihomingで複数のPEに接続している場合にも、ESは1つなのでESIも1つです。
  • Ethernet Segment Identifier (ESI) : CEがPEに接続するL2セグメントの、一意の識別子です。CE deviceがMultihomingをする際に、接続先のPEのインタフェースに対して同一の値を設定しておきます。

MP-BGP

ノードの種類と用語について整理したので、次はData planeを司るMP-BGPについて見ていきます。

f:id:foobaron:20181213230944p:plain
MP-BGPのMAC-VRF

EVPNではControl planeとしてMP-BGPを利用します。 PE RouterはMP-BGP (Multi Protocol BGP) によりCE間の到達性を実現します。 EVPN-VXLANでは、CEからのトラフィックはVXLANでカプセル化されて、 対向のCEが接続されているPE Routerまで転送されます。

EVPNでは、PE Router上にEVPNの仮想インスタンス(EVI)を作成し、その中にMAC-VRFを保持します。 上の図では2つのEVIが作成されているという想定です。

テナント(CE)ごとにMAC-VRFがありますが、PE Routerではそれをテナントごとに 区別して使う必要があります。 そのためテナントごとに、利用しているIPアドレスプレフィックスにRDを付与した VPNプレフィックスを用いることで、 PE RouterがMP-BGPテーブル上で参照すべきMAC-VRFを決定します(図)。 重複するIPアドレスプレフィックスを利用しているCustomerであっても、 PE Routerは、RD値を参照することでMAC-VRFを一意に識別 できます。

これにより、PE Routerは、CEに対して適切なMAC-VRFを選択してアドレス解決できます。

f:id:foobaron:20181213231019p:plain
MP-BGPのVPNプレフィックス

ですがRDは、あくまでCustomerごとにMAC-VRFを選択するための識別子です。 経路を受信するローカルのPE Routerでは、どのローカルMAC-VRFに経路情報を追加すべきか、 RD値からは判断できません。

そこで、経路情報の送信側であるリモートPE Routerでは、Route Target (RT) を付与して、 VPNプレフィックスを広報します。 受信側のローカルPE Roouterでは、RT値とMAC-VRFを対応付けています。 広報されたVPNプレフィックスのRT値を見て、 一致するRT値に対応付けられているローカルMAC-VRFを更新します。 なお、広告するVPNプレフィックスに対して、複数のRT値を付与することもできます。

f:id:foobaron:20181213231045p:plain
MP-BGPでMAC-VRFの経路情報を学習

EVPN-VXLAN

EVPN-VXLANにおけるVXLANは、Data planeにおけるカプセル化に利用されます。 VXLANでは、エッジとなるVTEPの間で、VXLANヘッダによりカプセル化したパケットをやり取りします。 L2のフレームはVXLANヘッダでカプセル化され、IP/UDPによって転送されます。 VXLANでは、24ビットのVNI (Virtual Network Identifier) という識別子を用いて、L2ネットワークを分離します。

VNIとVLAN

VXLANのVNIは、一般的にはVLAN IDに1:1でマッピングされて使われます。 本記事でも、EVPN-VXLANを動かして、CEに割り当てたVLANをVXLANで延伸します。 VNIとVLANのマッピングをPE Router上のEVIで利用するため、EVIとVNIを対応付けておく必要があります。 CE <-> VLAN <-> VNI <-> EVI という対応関係があるため、EVIとVNIマッピングさえわかれば 問題ありません。

これまで見てきたMP-BGPの経路広告・学習の動作では一例として CustomerごとにMAC-VRF(すなわちMAC-VRFを持つEVI)を分けていました。 図のTenant-A、Tenant-Bそれぞれに異なるVLANを割り当て、 EVIは共通で1つのものを使用し、VLANでCustomerを一意に識別することも可能です。

EVPNのData planeとしてVXLANを使う場合、VNIとEVIのマッピング方法は次の2通りです。

  1. EVI:VNI = 1:1

1つ目の方法では、EVIにつき1つのVNI(で表される1つのサブネット)がマッピングされます。 そのため、特定のEVIのMAC-VRFのみに、経路広報先を絞ることができます。 また、MAC-VRFは、RTとVNIの組み合わせによって一意に識別できます。 なお、EVIにつきRD/RTを割り当てる必要があるため、 自動化しない限り、その管理が煩雑になってしまいます。

  1. EVI: VNI = 1:多

2つ目の方法では、EVIに対して複数のVNI(で表されるサブネット)がマッピングされます。 この方法では、特定のVNIを利用しないPE Routerにも経路情報が学習されてしまいます。 MAC-VRFはRTによって一意に識別可能です。 そして、MAC-VRFにおける特定のブリッジテーブルは、VNIによって一意に識別できます。

EVIごとにVNIを割り当てる必要性はないので、今回は2番目のマッピング方法を使い、 VNIはそれぞれのPEで1つだけ作成することにします。

EVPN-VXLANを動かしてみる

f:id:foobaron:20181213231123p:plain
EVPN-VXLANの検証環境

PE Router, P RouterとしてJuniper NetworksのvMX仮想ルータを使用し、 CE deviceとしてLinuxマシンを使用して、検証環境を図のとおりに構築しました。

  • AS 65000 :拠点間を接続する閉域網 (VXLAN網)
  • AS 65001 :CEを収容する拠点

P Routerが属するVXLAN網でAS 65000、複数拠点に存在するPE Routerは同一でAS 65001を使ってみます。 VXLANを構築するアンダーレイネットワークとして、 CEに対するエッジルータであるPE Routerが同一ASに所属する構成を取ることにします。

CEがActive-Activeのmulihomingを使えるよう、CEに対して2台のPEを接続しています。

全てのノードを、仮想マシンとして1台のVMWare ESXiホスト上で稼働させました。

CEとPEの間はVLANによって分けられています。 両端のCE deviceが使うVLANは異なっていても構いませんが、 VLANを延伸するVXLANのVNIは共通のものを使用します。

今回EVPN-VXLANを動かすために使った技術

  • VLAN
  • OSPF
  • iBGP
  • eBGP
  • MP-iBGP
  • VXLAN

今回は、拠点AS 65001にあるPE Router同士でMP-iBGPのピアを確立しました。 なお、PEごとにAS番号を分け、MP-eBGPのピアを確立することも可能です。 構築が容易であることを踏まえ、今回はMP-iBGPを採用しました。

MP-iBGPのアンダーレイでの到達性を確保

このAS 65000を中継してAS 65001のPE Router同士がMP-iBGPのピアを確立する必要があります。 Customer Edgeの経路情報の広報には、前述のとおりMP-iBGPを利用します。 MP-iBGPのピアを確立するために、まずはアンダーレイネットワークで到達性を確保します。

AS 65000内

AS 65000の閉域網では、AS内での各P Router間の到達性を確保するためにOSPFを動かしています。 この後、AS 65000内のP RouterはiBGPのピアを確立する必要があります (iBGPの必要性については後述します)。 iBGPでは、BGPセッションにてloopbackインタフェースのIPアドレスを利用する必要があるため、 そこへの到達性も、このOSPFで確保します。

P RouterのOSPFの設定は次のとおりです。

P-Router# show protocols ospf

area 0.0.0.0 {
    interface ge-0/0/0.0;
    interface ge-0/0/1.0;
    interface lo0.0;
}

AS内のリンクを結ぶインタフェースおよびloopbackインタフェースを OSPFのエリアに所属させます。

その上でiBGPを動かしておきます。 iBGPの設定は次のとおりです。

P-Router# show protocols bgp group ibgp-core

type internal;
local-address <OWN_LOOPBACK_IP_ADDR>;
family inet-vpn {
    any;
}
neighbor <NEIGHBOR-P_LOOPBACK_IP_ADDR_0>;
neighbor <NEIGHBOR-P_LOOPBACK_IP_ADDR_1>;

AS 65000内ではiBGPを走らせていますが、 VXLANオーバレイではiBGPによるベストパスが採用されます。 そのため、閉域網内でTraffic Engineering (TE) を実現するには、 OSPFの上でMPLSやSegment Routingを動かすとよいでしょう。

AS 65001間

MP-iBGPのピアを確立するために、PE RouterはBGPセッションでloopbackインタフェースのIPアドレスを利用します。 アンダーレイでは、PE Routerが他のPE RouterのloopbackインタフェースのIPアドレスに対して 疎通できるようにしておきます。 AS 65001 <- eBGP -> AS 650000 <- eBGP -> AS 65001 という形で対向の同一AS番号のAS 65001に対して loopbackインタフェースの経路情報を学習させます。 AS 65000が、一方のAS 65001からの経路広告をAS 65001に伝搬するためにiBGPを使います。 先ほど、AS 65000内でiBGPを走らせたのはこのためです。

f:id:foobaron:20181213231304p:plain
PE Routerの拠点同士で同一ASとなる構成

通常は、 AS_PATH に自身のAS番号が含まれている経路広告は、ループ防止のために学習しません。 PE Routerが所属するASが同一になるため、ルーティングのループを防止しつつ通信できるように設定をします。 同一のAS番号を持つAS間の到達性をeBGPで確保する方法は、 Juniperのドキュメント を参考にしました。

各PE Routerに設定する、自身と同一のAS番号から広告された経路を学習するための設定は次のとおりです。

PE-Router# show protocols bgp group ebgp-underlay

group ebgp-underlay {
    type external;
    family inet {
        unicast {
            loops 2;
        }
    }
}

参考:loops (BGP Address Family) - TechLibrary - Juniper Networks

loops 2 により、 AS_PATH で自身と同じAS番号を2回以上検出した場合のみ経路を破棄します。 同じAS番号のASからの経路情報には、自身と同じAS番号は1つしか含まれていないため、その経路は学習されます。

今回、PEルータ間でMP-iBGPのために到達性を確保したいのはloopbackインタフェースのみです。 ですので、loopbackインタフェースのIPアドレスのみを広告することにします。 loopbackインタフェースには /32 のIPプレフィックスが割り当てられるので、 /32 の経路だけをPEルータが広告するようにします。

PE-Router# show policy-statement policy-export-loopback

from {
    family inet;
    protocol direct;
    route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
then accept;

作成したポリシーをPE RouterのeBGPの設定に適用します。

PE-Router# show protocols bgp group ebgp-underlay export

export policy-export-loopback;

以上の設定により、MP-iBGPを使うのに必要なPE Router同士の到達性を確保できるようになりました。 これから、MP-iBGPの設定をして、PE同士が各拠点にあるCEのMACアドレスを学習できるようにします。

MP-iBGPの設定

MP-iBGP ではEVPN-VXLAN網内のP Router (AS 65000) は、 VTEPであるPEルータでVXLAN化されたパケットを伝送していくだけです。 PE Router間のみでMP-iBGPのピアを確立すれば問題ありません。 これにより、 P RouterがCEの経路を保持することなく 、 CE間のEnd-to-Endで到達性のあるネットワークを構築できます。

PE RouterのMP-iBGPの設定は次のとおりです。

PE-Router# show protocols bgp group mp-ibgp-overlay

group mp-ibgp-overlay {
    type internal;
    <OWN_LOOPBACK_IP_ADDR>;
    family evpn {
        signaling;
    }
    neighbor <<NEIGHBOR-PE_LOOPBACK_IP_ADDR_0>;
    neighbor <<NEIGHBOR-PE_LOOPBACK_IP_ADDR_1>;
}

EVIの設定

EVPNでは、PE RouterのEVIがMAC-VRFと対応付けられます。 そのために、PE Router上でEVIを作成します。

PE-Router# show routing-instances evpn

vtep-source-interface lo0.0;
instance-type virtual-switch;
interface ae0.0;
route-distinguisher 65001:1;
vrf-target target:65001:1;
protocols {
    evpn {
        encapsulation vxlan;
        extended-vni-list all;
        multicast-mode ingress-replication;
    }
}
bridge-domains {
    <VNI_NAME> {
        domain-type bridge;
        vlan-id <VLAN_ID>;
        vxlan {
            vni <VNI>;
        }
    }
}

Junosでは、 virtual-switchrouting-instance としてEVIを作成します。 同一のRT値を設定したEVIからの経路を、対向のEVIのMAC-VRFでも学習します。 今回はVLANをVXLANで延伸するため、VLAN <-> VNIマッピングを定義しておきます。

Multihomingの設定

最後に、Multihomingの設定をしておきます。 PE RouterおよびCE deviceでLACP (Link Aggregation Control Protocol:IEEE 802.3ad) を使うことで、 CEが複数のPEでリンクアグリゲーションすることができます。 EVPNでは、LACPを設定したいPE Routerのインタフェース同士で同じESIを設定しておくことで、 PE Router同士が直接接続されていない場合でも互いを識別しMultihomingを実現します。

PE Routerの設定

LACPを組むPE Routerそれぞれに対して同じESIを設定します。 PE Routerの設定は次のとおりです。

PE-Router# show interfaces

ge-0/0/0 {
    gigether-options {
        802.3ad ae0;
    }
}
ae0 {
    flexible-vlan-tagging;
    esi {
        <OWN_ESI>;
        all-active;
    }
    aggregated-ether-options {
        lacp {
            active;
            periodic fast;
        }
    }
    unit 0 {
        family bridge {
            interface-mode trunk;
            vlan-id-list <VLAN_ID>;
        }
    }
}

JunosでLACPを使うために、まずは使用するインタフェース ge-0/0/0 に対して Aggregated Ethernet Interface ae0 を対応付け、 ae0lacp active を設定します。 また、作成したLACP用のインタフェースにESIを割り当て、Active-ActiveでMultihomingするために、 esi all-active を設定しておきます。 この設定を、LACPを組みたいPE Router全てに対して行います。

#### CE deviceの設定 今回はCE deviceとしてUbuntu 18.04を利用しました。 2台のPE Routerの接続するため、2つのインタフェースを用意し、 それらでbondingインタフェースを作成しました。 束ねた2つのインタフェースをCEに接続しています。

netplanの設定は次のとおりです。

cat /etc/netplan/50-cloud-init.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    ens192:
      optional: true
    ens224:
      optional: true
  bonds:
    bond0:
      interfaces:
      - ens192
      - ens224
      parameters:
        mode: 802.3ad
        mii-monitor-interval: 1
        transmit-hash-policy: layer2+3
      optional: true
  vlans:
    bond0.<VLAN_ID>:
      id: <VLAN_ID>
      link: bond0
      addresses:
      - <OWN_IP_ADDR>/24
      optional: true

長かった設定もこれで完了です。 これにより、EVPN-VXLANでCE間のVLANを延伸することができました。 最後に、疎通確認の結果を見てみましょう。

疎通と経路情報の確認

f:id:foobaron:20181213231331p:plain
EVPN-VXLAN検証環境の詳細

CE間の疎通確認

まずはじめに、CE間で疎通確認をしてみます。 CE-01, CE-02のIPアドレスは次のとおりです。

CE-01:# ip address show dev bond0.901
6: bond0.901@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 52:9a:d7:de:97:8c brd ff:ff:ff:ff:ff:ff
    inet 10.255.1.1/24 brd 10.255.1.255 scope global bond0.901
       valid_lft forever preferred_lft forever
    inet6 fe80::509a:d7ff:fede:978c/64 scope link
       valid_lft forever preferred_lft forever
CE-02:# ip address show dev bond0.907
6: bond0.907@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ae:bc:7b:16:a8:dc brd ff:ff:ff:ff:ff:ff
    inet 10.255.1.2/24 brd 10.255.1.255 scope global bond0.907
       valid_lft forever preferred_lft forever
    inet6 fe80::acbc:7bff:fe16:a8dc/64 scope link
       valid_lft forever preferred_lft forever

なお、LACPにより束ねたインタフェースのMACアドレスは同じになっています。

CE-01:# ip link show
3: ens192: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether 52:9a:d7:de:97:8c brd ff:ff:ff:ff:ff:ff
4: ens224: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether 52:9a:d7:de:97:8c brd ff:ff:ff:ff:ff:ff
5: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:9a:d7:de:97:8c brd ff:ff:ff:ff:ff:ff
6: bond0.901@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 52:9a:d7:de:97:8c brd ff:ff:ff:ff:ff:ff

ひとまず、 CE-01からCE-02に pingtraceroute してみます。

CE-01:# ping 10.255.1.2
PING 10.255.1.2 (10.255.1.2) 56(84) bytes of data.
64 bytes from 10.255.1.2: icmp_seq=1 ttl=64 time=5.37 ms
CE-01:# traceroute 10.255.1.2
traceroute to 10.255.1.2 (10.255.1.2), 30 hops max, 60 byte packets
 1  10.255.1.2 (10.255.1.2)  5.921 ms  5.800 ms  5.751 ms

VXLANによってL2を VLAN 901 <-> VNI 10901 <-> VLAN 907 間で延伸し、 L3では1hopで対向のCEに到達することを確認できました。

EVPNの経路情報

PE-01# run show route advertising-protocol bgp 10.1.4.1 table vtep.evpn.0 detail により、PE-03 ( 10.1.4.1 ) へ広告した経路情報を確認します。

Route Type-2 (MAC)

* 2:10.1.1.1:1::10901::52:9a:d7:de:97:8c/304 MAC/IP (1 entry, 1 announced)
 BGP group overlay type Internal
     Route Distinguisher: 10.1.1.1:1
     Route Label: 10901
     ESI: 00:00:00:00:00:00:00:01:00:64
     Nexthop: Self
     Localpref: 100
     AS path: [65001] I
     Communities: target:65001:1 encapsulation:vxlan(0x8)

Route Type-2 (MAC/IP)

* 2:10.1.1.1:1::10901::52:9a:d7:de:97:8c::10.255.1.1/304 MAC/IP (1 entry, 1 announced)
 BGP group overlay type Internal
     Route Distinguisher: 10.1.1.1:1
     Route Label: 10901
     ESI: 00:00:00:00:00:00:00:01:00:64
     Nexthop: Self
     Localpref: 100
     AS path: [65001] I
     Communities: target:65001:1 encapsulation:vxlan(0x8)

Route Type-3

* 3:10.1.1.1:1::10901::10.1.1.1/248 IM (1 entry, 1 announced)
 BGP group overlay type Internal
     Route Distinguisher: 10.1.1.1:1
     Route Label: 10901
     PMSI: Flags 0x0: Label 10901: Type INGRESS-REPLICATION 10.1.1.1
     Nexthop: Self
     Localpref: 100
     AS path: [65001] I
     Communities: target:65001:1 encapsulation:vxlan(0x8)
     PMSI: Flags 0x0: Label 681: Type INGRESS-REPLICATION 10.1.1.1

PE-01にて show route table vtep で、PE-01, PE-03に対する経路情報を確認すると、MP-iBGPによる経路情報が載っていることがわかります。

2:10.1.1.1:1::10901::52:9a:d7:de:97:8c::10.255.1.1/304 MAC/IP
                   *[EVPN/170] 00:00:30
                      Indirect
2:10.1.4.1:1::10901::ae:bc:7b:16:a8:dc::10.255.1.2/304 MAC/IP
                   *[BGP/170] 00:21:53, localpref 100, from 10.1.4.1
                      AS path: I, validation-state: unverified
                    > to 192.168.0.7 via ge-0/0/1.0

MAC-VRFのimportポリシー

PE-01のMAC-VRFのimportポリシーを確認してみます。

PE-01> run show policy __vrf-import-evpn-internal__
Policy __vrf-import-evpn-internal__:
    Term unnamed:
        from community __vrf-community-vtep-common-internal__ [target:65001:1 ]
        then accept
    Term unnamed:
        then reject

vrf-target target:65001:1 のみを設定しておくと、デフォルトで、 指定したコミュニティで経路を受け入れるようになります。 対向のCEでも同様です。

ブリッジテーブル

PE-01のブリッジテーブルを確認してみます。

PE-01# run show bridge mac-table

MAC flags       (S -static MAC, D -dynamic MAC, L -locally learned, C -Control MAC
    O -OVSDB MAC, SE -Statistics enabled, NM -Non configured MAC, R -Remote PE MAC)

Routing instance : vtep
 Bridging domain : vni10901, VLAN : 901
   MAC                 MAC      Logical                Active
   address             flags    interface              source
   52:9a:d7:de:97:8c   DR       ae0.0
   ae:bc:7b:16:a8:dc   DR       esi.605                00:00:00:00:00:00:00:02:00:64

PE-01がCE-01のMACアドレス 52:9a:d7:de:97:8c および CE-02のMACアドレス ae:bc:7b:16:a8:dc を学習しています。 また、CE-02が接続するPE-03, PE-04のESIが 00:00:00:00:00:00:00:02:00:64 であることも学習しています。

終わりに

今回は、JuniperのvMX仮想ルータとOSPFやiBGP、eBGP、MP-iBGP、VXLANといった様々な技術を組み合わせることで、 EVPN-VXLANによりVLANをVXLANで延伸できることを検証しました。

富士通クラウドテクノロジーズでは、ニフクラのデータセンター間/内ネットワークを支えるため、 こうした新しいネットワーク技術の導入を進めています。

必要なデータの量は?90%の精度を出すためには?データサイエンスあるあるQ&A

今日は、アドベントカレンダー8日目

必要なデータの量は?90%の精度を出すためには?データサイエンスあるあるQ&A」です。

FJCTのデータサイエンス事業をやっている吉田です。

 

7日目(12/7)は、「クラウドストレージからオブジェクトストレージに移行した話」でした。
いわゆる数GB-TB単位のデータを扱う際我々にとっては、オブスト(オブジェクトストレージ)は必須です。
モデルや画像などの純粋に巨大なバイナリデータは、gitでは管理しづらいためです。(git LFSとかはありますが)

自分の過去の遺産も移行せねば。


さて、FJCTでは、クラウド事業の他に、データサイエンス事業をやっています。
需要予測画像認識故障予知レコメンドetc...直接取引させて頂いたり、富士通本体の大きな商流を使ったり、おかげさまでさまざまな規模のデータ活用プロジェクトを推進させて頂いています。

今回はそんな数々のデータサイエンスプロジェクトを回している際の、
お客さんのよくある質問と私の回答をまとめてみました。

アジェンダ
1.どれだけデータを集めればAI活用できるの?大体でもいいから教えて!
2.前処理が工程の8~9割なんて言われるけれど、なにがそんなにかかるのか?
3.90%くらいの精度を出すためには?

(*業界・データによって回答は大きく異なることがあります!ご了承ください)


 

過去にも「データ活用プロジェクト」の記事やポイントをまとめている記事に出ているので、こちらもあわせてご覧ください!

ライオン様と口臭判定アルゴリズムを作った話。

「口臭リスクをスマートフォン見える化!」
https://japan.cnet.com/extra/fjct_201808/35123825/

 

ainowさんでのインタビュー。

ビジネス・技術の両面での躓きポイントを解説しています。
「データ・AI活用のつまづきポイント」
http://ainow.ai/2018/12/03/156285/

 


1.「どれだけデータを集めればAI活用できるの?大体でもいいから教えて!」

エンジニア的に答えると「データによりけりなので、答えられない」になってしまうのですが、ある程度の考え方はあります。


AI活用のためのデータ資源の考え方には、「オーギュメンテーション可能性」があると考えています。
これらの要素について、要件を満たしたものが活用できるデータとなります。

 

「量」とは、たとえば、X人、X日、X枚のような取得するデータの数を指します。

たとえば、小売店の需要予測をするのであれば、最低2年分のデータが必要になります。
なぜなら、一年を通した季節性(周期性)が学習に大切となるからです。
たとえばこの年末であればおせち需要で、黒豆が良く売れたり・・・。
この季節性を学習するための一年分、学習済みモデルを検証するための一年分で計2年以上はほしいと考える訳です。
このように、パターンによっては最低いくつはほしいと決まっているものもあります。

 

「質」とは、データの中身が活用に耐えうるものかということです。
Excelで見るような表データであれば、セルが欠けていたり住所の表記がゆれているケースが問題となります。
画像データであれば、ボケていたり霞んでいるケースが問題となります。
このようなケースでは「前処理」による補正が必要なデータとなり、AI活用のために避けて通れない作業となります。
これらは、基幹データベースのリプレースを経たデータやコンシューマーによる入力データに多く見られます。
他にも、たとえばアンケートで1~5と回答するところを、4と回答した人が全体の80%で、2と回答した人が3%だとするとデータに偏りが生じた状態となり、2と回答する人がどんな人かをほとんど分析できないことに繋がります。

 

「オーギュメンテーション可能性」とは、そのデータを何パターンに水増しできるかです。
たとえば、1枚の画像があるとします。
これを反転したり、一部を切り取ることで1枚の画像から複数枚の画像ができるわけです。
ほかにも一部の時系列データなどで有効な手段となっています。
純粋にデータが2倍、3倍となるので強力な手段なのですが、元々同じような画像ばかりであるケースなどでは特に注意が必要で、やり過ぎるとモデルの精度が落ちてしまう問題もあります。

 

他にもいろいろありますが、個人的には大体この3つを軸にできる・できないを判断することが多いです。



2.「前処理が工程の8~9割なんて言われるけれど、なにがそんなにかかるのか?」


*前処理というのは、さまざまなデータベースに散らばっているデータを収集統合調整し、AIが読める形に直すことです。


データの「質」の部分では「欠損・表記ゆれ」にも触れていますが、本質的に時間を食うのはこれらのデータ修正にかかるコミュニケーションです。
なぜ欠損したのか?この専門用語の意味はなんだろうか?他にこんなデータはないだろうか?・・・等々多くのコミュニケーションが日々行き交います。
データ活用の行き着く先が業務を改善することである以上、AIベンダーorAIチームが業務を知り、企業がデータ活用について知る工数が必要となります。
データを正しく処理するためには、これらの知識を双方が認識することが必須となります。このため、連絡を気軽に・蜜にやり取りできる環境が整っているプロジェクトの進みは格段に早くなります。


3.「90%くらいの精度を出すためには?」


どれくらい高度なものなのかAIに期待を寄せながら質問してくださる方が多いです。
正直なところ、(学習に使っていないデータで)いきなり90%の正答率を出すことは非常に難しいです。
この理由には、データの限界の要素が関わっています。

「データの限界」とは、データの取り方が一定でなかったり、同じデータから違う結果がでたりすることで、そのデータから導き出せる予測に限度があることです。
たとえば、アンケートでの5段階評価などは個人ごとに評価基準が異なるので、同じ条件でも違う結果が出てきたりします。

他にも、今あるデータ以外の要素が結果に影響を及ぼしていると、精度が上がらない原因となります。
その日の天気・その人の気分・その部屋の気温、等々外部のデータを拾う必要があるケースもあります。
また、業務ヒアリングを進めると他部署の方が重要なデータを握っているパターンもあります。

これらの問題から、理論的に不可能なケースと、十分なデータ取得に時間・コミュニケーションが必要なケースが多いです。

 

このため、ビジネス的な視点では、90%の精度を持って初めて製品を出すということはあまりなく、データ収集・調整・予測を繰り返す実験的なPoCを実施し、90%はあくまで理想的な目標として、運用しながら目指していくことが一般的です。
また、こうして運用していくと、本来のKPIに即した精度というのが明らかになっていきます。
運営の中では、例えば全体的に正答率が90%なくても、特定のケースで正答率が良ければ満足度が高いといったようなことが分かってきます。
このように、「ベストな精度の定義」は、「用意できるデータにかけられるコスト」x「ビジネスのゴール」によって変わっていき、必要で達成可能な部分に向かって精度を上げていくというのが基本的な考え方です。


いかがでしたでしょうか。
色々書き連ねましたが、データ活用プロジェクトは不確実性の塊であり、「やってみないとわからない」部分があるからこそ、大体でもいいから勘をつかみたいというニーズが強まるのだと考えています。
ある程度の型としての考え方はこの記事を含め様々なサイトに乗っていますので、是非調べてみてください!
そして、一度トライしていただきたいと考えています。

さまざまな企業様を見ていますが、AI導入を検討することの本質は、会社の業務フローを刷新する機会なのだと考えています。
なぜなら、検討やPoCを通して会社の業務フローやデータを洗い出すことは、本質として会社としての戦略の現在の状況を可視化し、将来について考えるための作業となるからです。

FJCTのようなAIベンダーと一緒でもいいですし、是非一度チャレンジしてみてください!

 

明日、9日目(12/9)は、@khamanakaさんによる ”エンジニアリングマネージャーとして1 on 1で使ってきた「好き/嫌い/得意/苦手のマトリクス分析」”です。
当社敏腕マネージャーの分析手法、すごい気になります。

クラウドストレージからオブジェクトストレージに移行した話

この記事は 富士通クラウドテクノロジーズ Advent Calendar 2018 の7日目の記事です。
こんにちは。FJCTでインフラエンジニアをしています id:tunakyonn です。
ニフクラには2018年12月7日現在、クラウドストレージ(旧)オブジェクトストレージ という2種類のストレージサービスがあります。 この2種類のうち、クラウドストレージ(旧)は2019年1月25日で終了となります。
そこで今回は、自分がクラウドストレージ(旧)からオブジェクトストレージにファイルを移行した時のお話をしたいと思います。

どのように移行するのか

クラウドストレージ(旧)からオブジェクトストレージにファイルを移行する際、移行用にサーバーを用意する必要があります。 以下の画像のようにクラウドストレージ(旧)のデータを移行用のサーバーに一時持ってきて、そのデータをオブジェクトストレージにアップロードするのが基本的な流れになります。

f:id:tunakyonn:20181207094154p:plain

この移行用のサーバーにツールなどを入れることによって、ストレージのバケットにあるファイルを移行することができます。
今回はこのファイルの移行方法について、自分が検証した2種類の方法をご紹介いたします。

s3fsとaws cliを使う場合

こちらはニフクラブログの ストレージサービス間でデータの移行を行う方法 でも紹介されている方法になります。 そのため、詳しい導入手順や実行例については省略いたします。
ここではこの手順を実行する際の注意点やTipsについて、記載いたします。

s3fsのマウントについて

s3fsのマウントのコマンドがブログ内にありますが、たまにファイルの権限のためかaws cliのsyncコマンドを実行するとs3fs内のファイルが読み込めずにエラーになることがあります。その際は以下のコマンドのようにumaskオプションを使用することでファイルが読み込める場合があります。

s3fs -f srcbucket  /src_dir -o umask=0000,sigv2,url=https://ncss.nifty.com

移行速度について

s3fsでの読み込みの速度やaws cliによるアップロードの速度がボトルネックとなってしまい、最高でも200KB/sしか出なかったりクラウドストレージからデータが読み込めなくなってエラーが出たりします。
そのため、大容量・大多数のファイルが上がっているバケットへの移行には向かないと思います。

Tips: ストレージのバケットにある全ファイル数と全ファイルサイズを取得する方法

ここではストレージを移行する前に、バケットにある全ファイル数と全ファイルサイズを取得するコマンドについて紹介します。
この情報を取得するにはaws cliを用いて、以下のようなコマンドを流すとstorage_result.txtに各ファイル名とサイズが出力されていき、最後にバケット全体のファイル数とファイルサイズが出力されます。

aws --endpoint-url https://ncss.nifty.com s3 ls s3://test-bucket/ --recursive --human --sum > storage_result.txt

githubにあるmigrate_storage_toolを使う場合

こちらはgithubに上がっている migrate_storage_tool を用いる方法です。 実行環境やインストール方法、実行方法についてはリポジトリのREADME.mdに記載されてあるので割愛いたします。
ここでは、config.ymlに設定する値について、2つのケースを例にして説明します。

1ファイルの容量が大きくないが、ファイル数が多い場合

この場合は、並列で移行した方が移行速度が上がります。そのため、cpu_numberをできるだけ大きな値にすることを推奨します。 ですが、cpu_numberは最大でも移行用のサーバーのCPUコア数にしてください。

ファイル数は少ないが、1ファイルあたりの容量が大きい場合

この場合は、ファイル数が少ないので無理にcpu_numberを大きな値にする必要はありません。 逆に色んな値を大きくした状態で実行するとメモリが足らなくなったりする場合があります。 オススメの設定としてはgc_execution_intervalの値を一桁台にすると良いと思います。 また、コード内にアップロードのリトライ回数である retry_maxもコードを直接修正することで変更することができます。 こちらの値も小さくすることでサーバー側の負荷を減らすことができます。

※2018/12/7から、migrate_storage_toolはマルチアップロードにも対応しました。2GB以上のファイルを移行する場合はmultipartの設定をしてください。

最後に

私はストレージからファイルを移行する際、基本的には後者のmigrate_storage_toolを使っていました。
このツールを使ってクラウドストレージ(旧)に全ファイルで30TBあるファイルを移行するのに約1ヶ月もかかりました。このように、ファイル数やファイルサイズが大きいと移行に時間がかかってしまいます。まだクラウドストレージ(旧)を使用している方は早めの移行をお勧めいたします。

8日目は、 id:tymob さんの必要なデータの量は?90%の精度を出すためには?データサイエンスあるあるQ&Aです。

2018年度新人技術研修の取り組みについて

はじめに

この記事はFJCTアドベントカレンダー2018 4日目の記事です。 こんにちは。今年の新人の id:o108minmin です。 今回は、2018年度の新人技術研修がどのように行われたか時系列順で紹介します。

時系列順技術研修

4月 基礎知識

4月は基本的な知識に関して5日間集中して学習していきました。

  • 公開鍵認証によるSSH接続 / 作業を行うにあたってのセキュリティ / Linuxの基礎
  • Gitによるバージョン管理
  • Pythonの文法 / Webアプリケーションの作り方
  • 単体テストの書き方 / テストファーストの考え方
  • デプロイの準備 / エラーログの読み方 / エンジニア的ドキュメントの書き方

このあと始まる職場体験にて、困らない程度には学習を進めていきます。

5月~8月 座学

ここからは部署へ職場体験という形で業務に参加しつつ、週1回の座学をしていきました。 内容は、通信プロトコルなどのネットワークの基礎的な知識から始まり、トラブルシューティングなどの応用的な部分、最近のトレンドを追うための知識まで網羅されています。

今年の技術研修は社内の先輩方から直接講義を受ける形式になっており、学ぶコマンド群も普段利用しているtips付きで解説がされました。 そのため、学んですぐ業務に活かすという良いサイクルが築けていました。 他にも、サービスに関して過去にどんなことがあったか? などの社内ならではの質問や議論も活発でした。これによって、経緯などが分かった上で業務に参加できる、他部署の事情も理解できるというメリットがありました。

特にセキュリティの講義はレベルが高く、隔離された安全な領域内で実際の攻撃を再現し、脆弱なソフトウェアの危険性を学ぶことができました。こういった普段の業務だけでは体験できないような講義もあり、今後の開発や運用への意識が変わりました。

f:id:nifcloud-developers:20181203154014p:plain

9月 開発演習

9月の終わりには、今までのまとめとして1週間の開発演習を行いました。 今回の開発演習は、 社内で今必要とされているものをフルスクラッチで作る というテーマで進行しました。 テーマとして挙がったのは、既存のドキュメント資産の移行や、誤字検知などです。

この演習で作成したものは、これから実際に運用されるものです。 そのため、最初はヒアリングをし、「どのように改善するのか?」「今後改修がしやすいか?」という視点からスタートしました。 そうした中で、「どうやったら作業する人が楽になるか?」「限られた開発時間で、どこまで理想に近づけるか?」「自分たちがどのように開発したいか?」といったところで、楽しみながら熱心に開発をしていました。 私のチームはNifcLounge*1の申請フローの自動化を行いました。 既存の手続きの問題点は手作業が多いことでした。それを解決するため、Slack上で使えるチャットbotを作成し、申請に必要な文章作成を効率化することにしました。その際、技術研修の内容を思い出しながら以下のように工夫しました。

  • 分担作業をする時、「メソッドのインターフェースだけは、きちんと設計しよう」と決め開発
  • 小規模なアプリのため、「データフローは一方向にし、アプリ側でデータを保持しない」と徹底する

そうして内部的にも満足できるものが仕上がり、効率よく作業が進むと、誇らしい気分になります。*2

10月以降 本配属

本配属となり、今年の新人は助けてもらいながらも最前線で活躍しています。 既に、新規OSのリリース作業や、ネットワーク設計、アプリケーション運用などの重要な業務で成果をあげつつあります。 私はIaaS開発チームにて、CI/CDの改善やテストの改善を通じてチームに貢献しています。 特に作業の自動化やテストの設計運用に関して、技術研修の内容が活かせました。 そのため、今年の新人研修のカリキュラムはとても役立ったと新人の私は感じています。

また、今回は技術職志望の研修の内容でしたが、総合職志望の新人もアプリケーション開発やデータ解析などの研修をしています。このような背景もあり、営業やマーケティング部門の新人でも積極的にデータ解析やプログラミングの知識をつけていこうという空気が強いです。こうした同期のためにも、今回のカリキュラムの教材は社内で参照できる場所にあります。

最後に

富士通クラウドテクノロジーズでは以下のページで2020年卒向けのインターンや新卒採用に関する情報を発信しています。今は公開できる情報は少ないですが、チェックしてみてください。

富士通クラウドテクノロジーズ(株)のインターンシップ・会社概要 | マイナビ2020

12/05追記 冬のインターンの情報が追加されました。 学生の方々はぜひご参加ください!!

富士通クラウドテクノロジーズ(株)のインターンシップ一覧 | マイナビ2020

*1:注釈: 勉強会の会場を提供する企画です

https://fjct.fujitsu.com/press-release/20180725.html

*2:注釈: 改善案もいろいろ思いついてしまうが、作業量の線引きをするのも大事

富士通らしくない富士通グループ「富士通クラウドテクノロジーズ株式会社」で使っている技術の話

投稿が遅くなってしまい申し訳ありません。
この記事は 富士通の非公式Advent Calendar 2018 の2日目の記事です。

富士通クラウドテクノロジーズ株式会社(略称:FJCT)で、クラウドサービスの企画・設計・開発・運営を担当するエンジニアの五月女です。

タイトルについては記事内で言及しますが、よく富士通の人に「富士通っぽくない会社だよね」と言われる所から付けてみました。
自分がこの記事を書こうと思ったきっかけは「この会社で使われている技術について把握出来なくなってきてるんじゃないか?」と感じたからです。
折角の機会なので、どんな技術が使われているのか纏めて行きたいと思います。(そして社内外からの突っ込みを貰って補完していきたいです。)
※公開記事や採用サイト等に記載されている内容を中心に、自分の主観も交えて纏めていますので、事実と異なる部分があったら申し訳ありません。

非公式と謳っているアドベントカレンダーなのですが、この機会に「富士通らしくない富士通グループ」会社について知って貰えたらと思います。

続きを読む

ニフクラの高品質クラウドへの取り組み

この記事は 富士通クラウドテクノロジーズ Advent Calendar 2018 の1日目の記事です。

ニフクラの開発の部門長をやっている @ichikk です。

1日目ということで、富士通クラウドテクノロジーズ(FJCT)が提供しているクラウドサービス「ニフクラ」の取り組みの紹介からスタートしたいと思います。

このエントリーではニフクラの高品質クラウドへの取り組みと題して、ニフクラで2018年に取り組んできた品質、セキュリティ、運用の強化施策についてその一部をご紹介したいと思います。

続きを読む

社内LT大会を開催しました

こんにちは!ニフクラ エンジニア ミートアップの事務局の鮫島です。
去る10月11日に、社内LT大会を開催しました。

f:id:sameshima_fjct:20181018162702j:plain

この、「LT大会」はエンジニアタスクフォースの活動の一環として定期的に開催しているもので、


 ・気軽さを重視しつつ、情報共有する文化を作る・育む
 ・社内の属人化を改善する
 ・気軽にできるアウトプットの場を提供する

といったことを目的としています。 続きを読む