クラウド間接続の現状と望む未来 2017/8/24 Junpei Yoshino XFLAG STUDIO

⾃⼰紹介 • 吉野純平 • 2008年⼊社 • いままでの活動領域範囲 • 物理インフラのエンジニア • サーバラッキング • ケーブリング • NW設計、構築、運用 • アプリケーション運用 • 広く全般 • バックオフィス • 契約、予算、見積もり、税金やらなんやらの調整

私の⽬指す世界 • 設備運⽤視点でのSite Reliabilityとは • 安全に安心に進化できること（たとえば手段としてN+m構成） • 古いものを適切に確実に捨てること • Site Reliabilityを実現する効率的な⽅法は「選択権」 • 選択できる状況を作る技術で何かを得ること • 強い立場で調達し続けること • 選択できることの価値 • 障害影響の回避ができる場合もある • 競争がうまれる

設備規模（物理帯域） • インターネット接続帯域 • 秘密 • クラウド接続帯域（132Gbps) • AWS DirectConnect 50Gbps • BBIX経由 20Gbps • 国内クラウド1直接 40Gbps （9月に80Gbpsになる予定） • 国内クラウド2直接 10Gbps （BBIX経由で冗長） • 国内クラウド3直接 10Gbps （BBIX経由で冗長） • ECX 2Gbps • オンプレサーバ • DCは2つ。10数ラック規模に調整中。1つ移動中。

SREっぽいツールを使った話 • ネットワークも全部github管理 • コンフィグをPullreqすると⾃動テストが⾛る

いちど歴史の振り返り

歴史的経緯1(monst⽇本） • AWSを利⽤してサービススタート • ELBが最初は辛かった。オンプレLBからインターネット経由でバランシングした • AWSとオンプレを接続。DBからオンプレに移⾏ • 2013年末ごろから2014年年初から • iodrive/SSD/intel nicを集めながら対応 • 新しいラックが必要だと思ってから半日では用意してた • CDNの利⽤開始 • アプリ改修の依頼 • ルーティングの分離 • SNSとルーティングテーブルレベルで分離した（全プロダクトで分離した） • 停止10分くらい？だったけか。2014年末くらい • ToRの⼊れ替え

歴史的経緯2(monst⽇本） • スイッチクラッシュ事故 • 停止10分くらいかな・・・。生放送中だった。2014 • スイッチASICのテーブルレイアウト変更メンテ • 停止10分くらい • クラウド間の接続実施 • 2015年の前半に複数事業者で研究してた • データセンター冗⻑ • 2015年の春に検討開始。夏に運用開始。 • カバーする範囲 • 回復目標時間 • 普段の運用に乗る仕組み • アプリケーション周りの改修 • BCPみたいなやつ

歴史的経緯3(monst⽇本） • AWS以外のクラウドも活⽤開始 • サーバの確保手段の柔軟化 • 高性能ストレージのサービス利用 • ルータモジュールの半死 • 半死の疑いは勝手に電源切れるようにした • 30分くらい、一部影響あり • クラウドのロケーション分散(Now!!） • でもレイテンシを低く。目指せ1msec未満。

デザイン • サーバのIPとstatic route • グローバルアドレスの付与 • ロードバランシング • ステート数とupdate要因の設計 • メンテナンス設計

サーバのIPとroute サーバにはdefault routeのみ ⾃動スクリプトでroute設定とかもやらず に済む構成にする 昔はvlan⾜して複数の接続を持っていた PXEできるように、LACPはtimeoutして dhcpが受け取れるようにしてある 何より楽！！ pxeブート中にも他のサーバと同じ環境 サーバ ToR NIC1 NIC2 LACP タイム アウト 付き

グローバルIPの付与 NATでstaticな1:1変換 マッピング情報以外はステートレスにする ロードバランスが容易(詳細は後ほど) サーバ ToR NIC1 NIC2 LACP NAT インターネット

ロードバランシング(ProxyProtocol版） LB ToR NIC1 NIC2 LACP NAT 5 6 2 1 インターネット サーバ ToR NIC1 NIC2 LACP 3 4

ロードバランシング(DSR版） クラウドへの ロードバランス ができない LB ToR NIC1 NIC2 LACP NAT 5 6 2 1 インターネット サーバ ToR NIC1 NIC2 LACP 3

クラウド事業者またぎでDSRができない理由 LB ToR NIC1 NIC2 LACP NAT 6 2 1 インターネット インスタンス ToR NIC1 NIC2 LACP 3 5 defaultがインターネットに向いている 環境がダメ 弊社に戻してくれる環境ならOK AWSならroute tableでDXに向ければ OKだが、 DXはVPCのアドレス以外を送信してく れないフィルタが付いている？ 結果不可能。 6

ステート数とupdate要因の設計 サーバ ToR NIC1 NIC2 LACP NAT インターネット NAT NAT 自社バックボーン 分散配置してどこのNATでも常に使える 経路が変動しても関係ない IGPコスト/BGPコストで迂回

実際どう⾒えるか 0.0.0.0/0 @[BGP/170] 1w0d 23:49:31, localpref 100, from xxxx AS path: I, validation-state: unverified > to x.x.x.x via ae53.0, Push 16, Push 300032(top) [BGP/170] 6w1d 01:52:21, localpref 100, from xxx AS path: I, validation-state: unverified > to x.x.x.x via ae51.0, Push 16, Push 300000(top) [BGP/170] 1w0d 23:49:31, localpref 100, from xxx AS path: I, validation-state: unverified > to x.x.x.x via ae53.0, Push 16, Push 300016(top) #[Multipath/255] 1w0d 23:49:31, metric2 201 > to x.x.x.x via ae53.0, Push 16, Push 300032(top) to x.x.x.x via ae51.0, Push 16, Push 300000(top) NAT候補1 NAT候補2 NAT候補3 今使っているのは候補1と2

故障時やメンテナンス時の扱い NAT インターネットのルーティングテーブル プロダクトのルーティングテーブル 仮想 インターフェイス デフォルトを staticで 向けておく インターネット 自社バックボーン（MPLS) mapされたグローバ ルアドレスを staticで向けておく staticアドレスをiBGPに広報する static > BGPなADなので LPに関わらずbestpath 広報が止まらないのでLPを変えて も周りで経路収束にインパクトが ない LPを下げれば綺麗に迂回する static routeは消えないのでマイク ロループしない

不具合時 juniper > set chassis fpc 0 error major action offline メジャーなエラーが出たらラインカードを勝⼿に即オフライン （よくあるログ取りは諦める！！） =>ラインカード停⽌に伴い、仮装インターフェイスが⽌まる =>仮装インターフェイスが⽌まるとstatic routeが無効に =>static routeが無効になることでBGPへの広報が⽌まる =>他のどこかのルータに吸い込まれるので通信が継続できる メジャーエラーや故障を検知したら1,2秒でおそらく収束できている

全体像 自社バックボーン NAT ToR w/ サーバ クラウドA クラウドB クラウドC クラウドX インターネット インターネット インターネット ToR w/ サーバ NAT NAT

余談（LBのプラクティス） IPを複数持つ機材を扱う時には、arpの速度を考えて、周辺機器の設計をする スイッチ LB 192.0.2.1/24 VIP: 198.51.100.0/24 NAT-POOL: 203.0.113.0/24 192.0.2.2/24 LBへのVIPとNAT poolはstaticで書く 192.0.2.0/24はLBに広報させるのがベター ヘルスチェックのソースIP指定ができれば、それを使う HA等の切り替え時に どれだけ周辺のarp等 テーブルを書き換えるか に注意する

No content