こんにちは。株式会社FOLIOでインフラ担当をしている横井と申します。
この記事はFOLIO Advent Calendar 2日目の記事です。昨日は弊社よこなによる証券会社のエンジニア・デザイナーが社外でも最大限活躍するためにFOLIOで取り組んでいることでした。
FOLIOは新興ながらも証券会社であり、新興のため攻めるべき部分と証券会社のため守るべき部分が存在するところに面白みを感じて日々業務を行っております。
今回は主にインフラの守りの部分でFOLIOでのAWS Direct Connect(以降DXと記載)の利用に関して記載します。DX接続サービスの選定ポイントとネットワーク障害がサービス影響に直結するため耐障害性で考慮したポイントについて記載したいと思います。
DX利用の背景
FOLIOでは現在サービスを構成するインフラの一部にてAWSのサービスを利用していますが、証券業という業種上の制約にて一部のサーバやマーケット接続、金融サービス協力会社などへの接続ルーターに関してはオンプレミス環境にて動作しています。
AWS上のインスタンスがこれらのオンプレミス環境のサーバやルーター経由で通信することから、DXを利用してAWS VPCとオンプレミス環境を接続する必要があったため利用を開始しました。
DXに利用するサービスの検討
利用を開始するにあたって、DX接続形態に関して下記の２つの選択肢からどちらにするのかを検討しました。
注:以下に記載する内容がこれからDXを検討するかたの一助になれば幸いですが、
あくまでFOLIOでの利用構成検討時の参考情報ですので詳しくはAWSまたはAPNパートナーの方々に相談をしてから意思決定することをお薦めします。またDX接続形態にはいくつかの種別が存在するのでDX検討時にまずはこちらの記載を一読することをお薦めします。
https://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-tech-aws-direct-connect
- EquinixデータセンターにDX接続用のラック、ルーターおよびオンプレミス環境との接続回線を手配して独自でDX接続をする
- APNパートナーの接続サービスを利用してオンプレミス環境のルータからDX接続する
1に関してはネットワーク構成の自由度は上がるものの、下記の観点から2を選択することにしました。
- 2に比べると大きな初期コストがかかる
- スピード感重視のプロジェクトだったこと
- ハードウェアの運用コストと故障時のメンテナンスコスト
また**「2. APNパートナーの接続サービスを利用してオンプレミス環境のルータからDX接続する」**の中でも
APNパートナーのサービスに依存しますが、下記の2パターンのサービスが存在します。
- DX専有型（DX connectionはユーザー側でAWS Management Consoleから設定。VIの設定もユーザーが行う)
- DX共有型（DX connectionはAPNパートナーで設定。VIもリクエストベースでユーザーがAPNパートナーに作成を依頼)
上記のDX専有型と共有型を比較しましたが、共有型のほうがコストを抑えることができるものの以下の懸念点がでてきました。
- ベンチャーならではのスピード間で働いているので、急ぎのVPC追加などを考えると共有型のAPNパートナー側でのVI作成のリードタイムが心配
- APNパートナーのサービスによっては帯域のアップグレードはできてもダウングレードに対応しておらず、自由度に疑問点が残った
- 共有型にはベストエフォート型と帯域確保型があるが、帯域保証型だと専有型と比べてあまりコストメリットが感じられなかった
FOLIOの業種上、ベストエフォート型というサービスは選び辛かったため、DX専有型とDX共有型の帯域保証型との比較検討を最終的に行いましたが、共有型と比べてコストは若干上がるが自由度の高いDX専有型の利用を意思決定して、自分たちでVIやVIに紐づくVLAN IDの払い出しを行える構成にすることになりました。
耐障害性の考慮
上記でDX専有型のAPNパートナーサービスを利用することとなりましたが、バックアップ回線についても同時に考慮を行っていました。
DXの接続形態としてプライベート接続(今回はAPNパートナーの提供するDX専有型を利用)とパブリック接続（インターネットVPN)があります。障害時に切り替わった際にも安定したパフォーマンスを出せること、SLAがあることなどを考慮にいれた結果、バックアップ回線に関してもコストはかかりますがDX専有型を選択しました。
物理的な構成図としては下図のようなかたちとなっています。キャリア網単位でDX Connectionを1つずつ作成しています。
キャリア網Aおよびキャリア網Bですがリンクパススルー(LPT)に対応しているものを選定し、DX側およびオンプレミス側でリンクダウンが発生すると対向側でもリンクダウンし経路の切り替えを素早くできるかたちになっています。
続いて下図は論理的な構成です。現在FOLIOでは複数のVPCを利用していますが、AWSの仕様上1つのVPCに割り当てられる仮想プライベートゲートウェイ(以降vGWと記載)は現在1つだけとなっています。冗長性を考慮してこのvGWは2つあるDX Connectionに紐づくVIを1つずつ作成し紐付けしています。紐付きは下記の通りです。
- 物理図のDX connection A - 論理図のvGW A VI#1, vGW B VI#1
- 物理図のDX connection B - 論理図のvGW A VI#2, vGW B VI#2
つまり論理図の二つの赤の線に関してはキャリア網Aの接続、二つの青の線に関してはキャリア網Bの接続となっています。
注：図のアドレッシングは解説のためのものとなっており、実環境のものとは異なります。
同時にDX接続ルーターAではvGW A VI#1向けとvGW B BI#1向けのBGP Peer設定を、
DX接続ルーターBではvGW A VI#2向けとvGW B BI#2向けのBGP Peer設定を行っていますが、
通常はキャリア網AをVPC Aへのトラフィック、VPC Bへのトラフィック双方とも通るようにしています。
つまり完全にキャリア網Bはスタンバイ回線にしているかたちとなっています。
経路制御に関してですが、BGPのパス属性でVPC向けについてはLocal Preferenceの重み付けで、
VPCからの経路に関してはAS Path Prependを利用することで実施しています。
VPC B向けはキャリア網Bを通すように経路設定することも可能ですが、DX接続のネットワーク構築時に
既存ネットワークに影響を与えないかたちで接続するために敢えてDX接続ルーターと既存ネットワークルーターの間でルーティングプロトコルによる経路交換は実施しないかたちとし、FHRPのVIPに対してスタティックルートを切る構成にしました。
そのためDX接続ルーターのFHRPのVIPの所在によってはVPCへの行きと戻りの経路が非対称となってしまい、障害時のトラブルシューティングが煩雑になってしまうため二つあるキャリア網の使い方もシンプルな形のActive/Standby構成としました。
またDX接続ルーターとvGWのBGP peerに関してですが、公式FAQにもあるように非同期BFDの設定を実施し、回線障害時などにBGP holdtimeを待たずに素早く経路を切り替えられる構成を取っています。
BFDに関してですが、もう一つの用途で利用しています。
通常FHRPを利用している場合、障害時の経路の最適化を図るためにWAN側のリンクダウン時にはActive側のルーターのVIP設定のpriorityを下げてVIPを遷移させるインターフェースtrack設定が一般的かと思います。
ただしWAN回線ですと必ずしもリンクダウンを伴う障害が発生してくれるとは限らないため、この場合は下図のような経路を辿ると想像できます。
この構成でも通信はできるのですが、障害時も不要な渡り通信によるネットワークのレイテンシーを抑えたいためDX接続ルーターでダミーのスタティックルート(たとえば169.254.255.1宛は169.254.1.2というような設定をDX接続ルーターAで設定)を設定し、そのダミールートのstatus pollingを169.254.1.2に対してBFDで設定し、リンクダウン時および網障害などで169.254.1.2に対してBFD疎通が出来なくなった場合はFHRPのpriorityを下げる設定をしています。これによりキャリア網A経由で疎通できない場合は下図のように必ずDX接続ルータB - キャリア網B - VPCに経路を対称にさせることが可能になりました。
その他の考慮点
VPCのCIDR拡張が可能になったため、意図しない経路の広報がVPC側からされてトラフィックの吸い込み等を防ぐためにDX接続ルータで経路受信および広報のフィルタリングも行っています。
まとめ
昨今、金融事業者のクラウド利用の攻めの事例も増えてきています。ベンチャー企業と言えどFOLIOは証券会社なため、証券会社としてAWSを利用するという攻めの部分を担保するための足回りを確保するためにDX導入時には十数パターンのネットワーク障害試験を実施し、証券会社として利用に耐えうるサービスレベルを確保できるのかを検証いたしました。
上記の試験の結果、障害時にも全てのパターンで数秒でネットワーク接続が回復することを確認しており、TCPやアプリケーションの再接続の機構で問題なくサービスに影響を及ぼさないことが確認できました。
※ 障害試験中に困った点としては、ユーザーサイドでvGWのBGPテーブルやルーティングテーブルを参照する手立てが今のところないので、こちらに関してはAWS CLI等で情報が取れるようにAWSさんにお願いしたくはあります。
今後は先月発表されたDX Gatewayの利用に関してですが、DX部分の構成をシンプルにしたり既存のDXを用いてオンプレミス環境を別のリージョンのVPCに繋いだりといったことも検討していきたいと思います。
http://docs.aws.amazon.com/directconnect/latest/UserGuide/direct-connect-gateways.html
今回はインフラの守りの部分の記事でしたがいかがでしたでしょうか。
現在FOLIOでは攻めと守り両方のインフラ部分を担当するSREを募集しております。
SRE以外にも一緒に働いていただけるかたを募集しておりますので、ご興味が有りましたらご連絡いただけると幸いです。以上、最後までお付き合い頂きありがとうございました。明日は弊社 大西による 「Apple 製品の法人での取扱について」になります。