大規模サービスを支える仮想ネットワーク | サイバーエージェント 公式エンジニアブログ
エンジニアブログをご覧の皆さんこんにちは、インフラエンジニアのすとーです。

僕はインフラの中でもネットワークチームで長らく働いてきたため、
今回はAmebaのネットワークまわりのお話をさせていただこうかと思います。
そこで、「ネットワーク基盤の変遷の歴史」を一歩踏み込んで、
その時々でポイントになった(と思っている)技術を、簡単な設定例と共に紹介していきます。
前提として、弊社ではルーティングはスタティックに行っており、
機器についてはCiscoとH3Cを7:3の割合ぐらいで利用しています。(ざっくり)


其の一 「VRF」


VRF(Virtual Routing and Forwarding)とは、ひとつのルータ内で仮想的に
複数のルーター(ルーティングテーブル)を作れる機能です。(ざっくり)

主な目的は、初期アメーバの余剰なネットワークリソースを、
マルチレイヤスイッチの導入で解消するというものでしたが、
弊社ではサービスごとにVLANを割り当てているため、
アクセス層(VLAN)とディストリビューション層(VRF)を対にすることによって、
管理上もわかりやすいといったメリットもありました。

設定例

# VRFの定義
ip vrf vrf100
# ルート識別子の定義
rd 100:1

# サーバ側のVLAN
interface Vlan100
# VRF vrf100のインターフェースとする
ip vrf forwarding vrf100
ip address 192.168.100.1 255.255.255.0

# LB側のVLAN
interface Vlan110
# VRF vrf100のインターフェースとする
ip vrf forwarding vrf100
ip address 10.100.100.1 255.255.255.0

# VRF vrf100のルーティングテーブルを設定
ip route vrf vrf100 0.0.0.0 0.0.0.0 10.100.100.254
ip route vrf vrf100 192.168.200.200 255.255.255.255 10.100.100.244


其のニ 「PBR」



PBR(Policy-Based Routing)とは通常、宛先でルーティングするところを、
プロトコルや送信元IPアドレスなどを条件にルーティングさせることを言います。

VRFを使っていると管理しやすいのですが、サービスの連携が頻繁に行われる頃になると、
横への展開ができない(ホップが多くなる)構成は逆に障壁となってしまいました。
さらに高トラフィックなサービスが増え、インターネット回線やロードバランサーを
分離せざるを得なくなったりと、柔軟な対応が求められたことから、
VRFを外してPBRに切り替え始めました。

設定例
# アクセスリストの設定
access-list 100 192.168.100.0 0.0.0.255
access-list 200 192.168.200.0 0.0.0.255

# route-map route100作成
route-map route100 permit 5
# 送信元IPアドレスがアクセスリスト100とマッチしたら
match ip address 100
# next-hopは10.100.100.254(LB1)
set ip next-hop 10.100.100.254
route-map route100 permit 10
# 送信元IPアドレスがアクセスリスト200とマッチしたら
match ip address 200
# next-hopは10.100.100.244(LB2)
set ip next-hop 10.100.100.244

interface Vlan100
ip address 192.168.100.1 255.255.255.0
# route-mapを適用
ip policy route-map route100

interface Vlan200
ip address 192.168.200.1 255.255.255.0
# route-mapを適用
ip policy route-map route100


其の三 「VRF + PBR」



そして次が現在のスタンダードな構成です。
PBRに切り替えることによって、だいたいどんなルーティングも可能になりました。
ただ、できることが多いと煩雑になっていくというのはネットワークも同じであり、
アクセスリストやroute-mapがとんでもない行数になってしまいます。
このままではヒューマンエラーを起こしかねない、ということで改善案を考えました。
ロードバランサーごとにVRFを紐付け、サービスごとのroute-mapを作って
ルーティングさせるという混合案です。

設定例

# VRFの設定
ip vrf lb100
ip vrf lb200

# アクセスリストの設定
access-list 100 192.168.100.0 0.0.0.255
access-list 200 192.168.200.0 0.0.0.255

# VRF lb100のルーティング設定
ip route vrf lb100 0.0.0.0 0.0.0.0 10.100.100.254
# VRF lb200のルーティング設定
ip route vrf lb200 0.0.0.0 0.0.0.0 10.100.100.244

# route-map Ameba1作成
route-map Ameba1 permit 10
# 送信元IPアドレスがアクセスリスト100とマッチしたら
match ip address 100
# VRF lb100を適用
set vrf lb100

# route-map Ameba2作成
route-map Ameba2 permit 10
# 送信元IPアドレスがアクセスリスト200とマッチしたら
match ip address 200
# VRF lb200を適用
set vrf lb200

interface Vlan100
ip address 192.168.100.1 255.255.255.0
# route-map Ameba1を適用
ip policy route-map Ameba1

interface Vlan100
ip address 192.168.100.1 255.255.255.0
# route-map Ameba2を適用
ip policy route-map Ameba2


こう書いてみると良さがうまく伝わらないかもしれませんが、
ACLやVRFを再帰的に扱うことによって大事なルーティング部分がとても見やすく、
またroute-map名もサービス名に紐付けているので感覚的にわかるようになっています。
実際にこの何倍もあるコンフィグを見ると一目瞭然です!

おわりに



ほんのごく一部ですが、弊社のネットワーク管理について紹介させていただきました。
変化の多いシステムに対応させるため、スタティックルートを使ってきましたが、
たまに動的ルーティングに憧れたりもします、、、。
正解のないネットワーク構成、これからもより良い環境を作っていけるよう精進していきたいです。

今回はルーティングに絞って書きましたが、現在では他にもVSS(Virtual Switching System)や
FEX(Fabric Extender)、vPC(virtual Port Channel)などの技術も取り入れています。
その話は機会があればまた。