Fastly ネットワークの構築と拡張 第1回 : FIB への対処

この記事は、Fastly でのネットワークソフトウェアの進化について詳しく説明するシリーズの1つ目です。Fastly は同業他社の中で独特です。創業当初からネットワーキングをコストセンターではなく製品に欠かせない部分と見てきました。しかしながら、さらに広いネットワーキングコミュニティでは私たちがやることはめったに共有されません。これは部分的には、現代のネットワーキングプラクティスではなく古典的なシステム理論からはるかに多くを取り入れているからでもあります。

抽象化の構築

さらに掘り下げる前に、私たちがネットワークのためのソフトウェアを記述する一方で、ソフトウェア定義ネットワーキング (SDN) という言葉を使用して私たちがやっていることを説明するのを敬遠することについて、曖昧さをなくしておくことが重要です。

1つには、SDN によってコンピューターネットワーキングがソフトウェア以外の何物かであるという誤解が永続化されるためです。「ランニングコードとラフコンセンサス」はネットワーキングベンダーがサウンドバイトに縮小するずっと前から、IETF のマントラでした。この言葉自体は、ネットワーク管理への具体的なアプローチを正当化するために採用され再解釈されています。この過程で、SDN は最も印象的な流行語へと進化してしまい、問題について自分が理解できているかを疑うこともできなくなっています。

現代のネットワークの巨大な規模を考慮すると、幅広いネットワーキング業界がソフトウェアの関連性を再発見しているという事実も避けられません。仮想化とその後のコンテナー化が連続して押し寄せた中で、データセンターの1つのラックに一意にアドレス可能なエンドポイントが、わずか30年前のインターネット全体よりも多く含まれることは珍しくはありません。多くのデバイスを管理する複雑さから、インフラストラクチャの運用で悪循環に陥っているコストを減らすために、コミュニティの注目の大半が自動化のニーズに移行したのはよく理解できます。

これは重要な開発ですが、自動化は私たちの最終目標ではありません。私たちが最優先する焦点は、ネットワークアプリケーションを構築するために効果的な抽象化を明らかにすることです。

それぞれの描写がわかりづらいのであれば、ホスト名とアドレスの間のマッピングをネットワーク内のすべてのノードに伝播するという課題を検討してください。cron ジョブのような単純なものから、更新を含む電子メールノードまで、このプロセスを自動化する方法は無数にあります¹。また、インターネットの初期の先駆者が採用したソリューションは、階層型分散命名システムであるドメイン名システム (DNS) でした。時間が経過するうちに、DNS によって提供される間接的な層が、コンテンツ配信ネットワークのような付加価値サービスの開発の命運を左右するものとなりました。自動化では時間を節約することができ、抽象化では時間を働かせることができます。

スケールアウト

Fastly 創業時の中心的なチームの専門知識は、主に高パフォーマンスシステムにありました。つまり、低レイテンシの分散キャッシングをサービスとして提供するために不可欠であることが分かります。しかし、コンテンツ配信ネットワーク事業に乗り出すのは、既存の事業者がより広大な地理的範囲から開始していることを考えても、一筋縄ではいきません。したがって、初期のサービスは、業界が提供できないものに焦点を当てました。エッジにコンテンツを配信する方法に関する前例のない可視性とコントロールです。

Fastly の創成期において、ネットワーキングでの経験の欠如はほとんど関係ありませんでした。自社の典型的な配信拠点 (POP) は、ボーダーゲートウェイプロトコル (BGP) を介してプロバイダーに直接接続された2つのホストで構成されていました。2013年初頭にはFastly は成長し、このホスト数ではもはや十分ではなくなりました。図1の a に示したように、プロバイダーに直接接続するキャッシュを増やしてトポロジをスケーリングすることは、選択肢にはありませんでした。ポートのコストや追加の BGP セッションを設定する構成の複雑さのために、プロバイダーはこれをサポートすることに消極的でした。

図1: ネットワークトポロジのスケーリングの影響

この問題の明白な解決策は、図1の b のようにネットワークデバイスを設置することです。これによって、デバイスの増加とプロバイダーの増加をきちんと切り離すことができます。このネットワークデバイスは通常はルーターです。これは照合のための価格タグを付けてトラフィックを転送するための高度に専門的なデバイスです。デバイスの全体ボリュームが小さい場合には、これが許容できる妥協点になりますが、コンテンツ配信ネットワークの性質は、地理的範囲とトラフィックボリュームの両方で常に拡張を続けることにあります。現在、自社の一番小さい POP にも少なくとも2つのネットワークデバイスがあります(図1 c)。

そのようなネットワークがルーターとどのように連携するかを概要として図2に示します。ルーターはプロバイダーから BGP を介してルートを直接受け取って、ルート選択に使用されるハードウェアに実装されたルックアップテーブルである転送情報ベース (FIB) に挿入します。次に、ホストがトラフィックをルーターに転送し、ルーターがデバイス FIB で得られたルックアップに基づいてパケットを次の適切なホップに転送します。

図2: ルーターを使用するネットワークトポロジ

FIB が大きいほど、1つのデバイスで保持できるルートが多くなります。残念ながら、FIB のサイズとコストの間に比例関係はありません。ボーダールーターは完全なインターネットルーティングテーブルを保持できる必要がありますが、現在のエントリー数は60万を超えています²。このスペースをサポートするために必要なハードウェアが、ルーターに関連する主なコストです。

ルーターなしのルーティング

従来のクラウドコンピューティング環境では、サービスの提供対象であるサーバーやスイッチが膨大な数であるため、ボーダールーターのコストが小さく霞んでしまいます。ただし、CDN にとって、このコストは単なる不都合をはるかに超えています。コンテンツをエンドユーザーの近くに配置するために、CDN にはコンテンツの提供に使用する多数のポイントが必要です。結果として、ネットワークデバイスがインフラストラクチャの総コストの大部分を占める可能性があります。

あまりにも高価なネットワーキングハードウェアに数百万ドルをかけるという考えは、私たちにとって特に魅力的とはいえません。システムエンジニアとしては、むしろコモディティサーバーハードウェアに投資します。これはコンテンツを配信する効率性に直接影響します。

私たちの最初の見解は、ルーターによって提供される機能のほとんどは必要ないということでした。すぐに電話会社に転身する計画があるわけではないからです。スイッチはかなり魅力的な提案のように思われましたが、そもそもルーターを活用していた理由である1つの機能が欠けていました。それは FIB のスペースです。当時、スイッチは一般的に FIB に数万のルーターしか保持できませんでした。これは必要な数に比べて何桁も少ない数です。2013年までには、Arista などのハードウェアベンダーがこの物理的な制約を克服する機能を提供し始めました。これにより、独自のソフトウェアをスイッチ上で実行できるようになります。

良識的なネットワーク設計のしきたりに従うべきという束縛から解放され、私たちの対処方法は比較的迅速に具体化されました。ネットワークデバイスの FIB スペースに依存する代わりに、ルートをホストそのものにプッシュすることができます。プロバイダーからの BGP セッションはスイッチで終了しますが、そこから、ルートはホストに反映されます。

図3: BGP ルート反射

このアプローチを図3に示します。外部 BGP (eBGP) セッションは、自社のスイッチ上で実行する BIRD のようなユーザースペース BGP デーモンで終了します。その後、受け取ったルートは、内部 BGP (iBGP) セッションを介して、ホスト上で実行する BIRD インスタンスにプッシュされます。さらに、ホストがルートをホストカーネルに直接挿入します。

これによって、スイッチの FIB を完全に迂回するという当面の問題が解決されますが、パケットをインターネットに送り返す方法に関する問題はすべて解消しません。FIB エントリーは、宛先プレフィックス (パケットの送信先) とネクストホップアドレス (通過点) で構成されます。パケットをネクストホップに転送するためには、デバイスがネットワーク上のネクストホップの物理アドレスを知る必要があります。このマッピングは、アドレス解決プロトコル (ARP) テーブルに格納されます。

図3では、スイッチがプロバイダーに直接接続していることから、スイッチが適切な ARP 情報を持っていることがわかります。ただし、ホストにはないため、BGP を介して提供されたネクストホップを解決することができません。

図4: Silverton を使用した ARP 伝播

Silverton: 分散ルーティングエージェント

これが、POP との間でルート設定を調整するカスタムネットワーク制御機能 Silverton の出発点でした。スイッチ上でただデーモンを実行すれば、Arista デバイス上に提供されている API を介して ARP テーブルの変更箇所をサブスクライブできることに気が付きました。プロバイダーの物理 MAC アドレスへの変更を検出した時点で、Silverton はネットワーク上にその情報を拡散できます。すると、ホスト上のクライアントが、プロバイダーに直接接続する方法に関する情報を使用してサーバーを再設定します。

特定のプロバイダー IP と MAC アドレスの場合、クライアント側エージェント Silverton によって実行される最初のステップは、その IP にインターフェイスで直接アクセスできる、またはそれがリンクローカルであるとホストに信じさせることです。これは、プロバイダー IP をインターフェイス上でピアとして設定することで実現でき、iproute を使用すると簡単に Linux でレプリケートできます。

$ ip addr add <localip> peer 10.0.0.1 dev eth0

プロバイダー IP がリンクローカルであると信じたホストは、その IP の MAC アドレスを ARP テーブルで検索せざるを得なくなります。これも次のように操作できます。

$ ip neigh replace 10.0.0.1 lladdr aa:aa:aa:aa:aa:aa nud permanent dev eth0

これで、宛先のルート検索では常にネクストホップ 10.0.0.1 が返され、トラフィックを aa:aa:aa:aa:aa:aa に直接送信することになります。スイッチは、直接接続されていると認識されている物理 MAC アドレスに対するデータ_フレーム_をホストから受け取ります。スイッチは、このフレームの転送先のインターフェイスを調べるために、宛先 MAC アドレスと発信の間のマッピングが含まれるローカル MAC アドレステーブルを調べることができます。

単に POP からパケットを転送するにはこのプロセス全体は複雑に見えるかもしれませんが、Silverton の最初のバージョンにはコードは200行もありませんでした。それでも、このおかげで、デプロイした POP ごとに数十万ドルを即座に節約することができたのです。重要な点は、ハードウェアとは異なり、ソフトウェアは段階的に洗練できることです。時間経過とともに、Silverton は、説明フィールドのラベル付けから、ルーティングアナウンスの操作や、BGP セッションの排出まで、Fastly の動的ネットワーク設定のすべてを包含するように成長しました。

しかし、お金を節約できたことよりも、Silverton によって抽象化を実現できたことが重要です。これによって、私たちの出発点だった、すべてのホストが直接すべてのプロバイダーに接続しているという錯覚が維持されています (図1の a)。カーネルで複数のルーティングテーブルを維持し、パケットごとに検索するテーブルを選択することで、ルート選択を上書きできるツールやアプリケーションを Silverton 上に構築することができました。たとえば、st-ping と呼ばれる内部ユーティリティでは、接続しているすべてのプロバイダーを介して宛先に ping を実行します。

図5: POP でのすべてのトランジットプロバイダーを介した ping。1つの宛先 IP で遅延が表示されても、プロバイダーの全体的なパフォーマンスを表すものではありません。

パスの選択をアプリケーションのレベルまで下げることで、ネットワーク動作に対してより高度なイントロスペクションを開発できるようになりました。これを使用して、エッジでのコンテンツ配信パフォーマンスを高めることができました。

これから : 他に省くことができるのは何か

Silverton は、タイミングに合ったアイデアほど強いものはないことを思い出させてくれました。

Silverton を実装しようとしたのが2年前であれば、壁に突き当たっていたことでしょう。私たちが必要としていたコアネットワーキングコンポーネントにプログラミングによるアクセスを提供してくれるベンダーは市場にいなかったはずです。スイッチに目を向けたときに、ちょうど Arista がデバイス上での内部 API へのアクセスを形にし始めていたのが幸運でした。

もしも、今、Silverton を実装しようとしているのであれば、ルーティングするためにはルーターが必要だという集団妄想をずっと前に受け入れていたことでしょう。結局のところ、ルーターを排除するのはルーターを購入するのと同じくらい高くつきます。その設定のために雇う人は、管理するハードウェアと同様に専門的であるためです。私たちは、ルーターを完全に回避することにより、ネットワークの運用方法について異なる考え方を持つネットワーキングチームを作り上げることができました。それ以来、メリットを享受しています。

2013年初めに Silverton の最初の概念実証を検証したとき、自然な疑問が浮上しました。_他に省くことができるのは何でしょうか？_このシリーズの次の記事では、インバウンドトラフィックを処理しシームレスなロードバランシングを実行するために、同様の策略の原則をどのように適用したかを説明します。

¹RFC849: 改良されたホストテーブルディストリビューションの提案 (https://tools.ietf.org/html/rfc849)

²BGP テーブルの拡張 (http://bgp.potaroo.net/)