カスタムソリューションがネットワークインフラストラクチャを節約する方法

CDNインフラストラクチャの構築には、多くの技術的な問題が伴います。機器の選択からデータセンターへのインストール、ネットワーク機能とのやり取りのためのユーザーインターフェイスまで。 Fastlyブログの記事の翻訳を提供します。このブログでは、チームがネットワークを操作するための非常に興味深いカスタムソリューションについて説明しています（その大部分はAiryインフラストラクチャで独立して使用されていました）。



インフラストラクチャの最適化の結果、ノードに障害が発生した場合のダウンタイムを最小限に抑え、システムの拡張性を高めることができました。

スケーリング

CDNを徐々に開発するのは簡単ではありません。サービスの本質は、要求の広範な地理的範囲を持つ顧客に関係しているためです。 そのため、Fastlyは当初、業界で不足しているものに焦点を当てました。つまり、最大限の透明性と「フロンティア」でのコンテンツ配信方法の制御です。



私たちが最初に始めたとき、ネットワーク技術の経験の不足はほとんど効果がありませんでした。 典型的な存在点（POP）は、BGP（ボーダーゲートウェイプロトコル）を介してプロバイダーに直接接続された2つのホストで構成されていました。 2013年の初めまでに、私たちは非常に成長し、この数のホストではもはや十分ではなくなりました。



図に示すように、さらに多くのキャッシュをプロバイダーに直接接続することにより、トポロジを拡張します。 1（a）、不可能でした。 プロバイダーは、ポートのコストと追加のBGPセッションを設定するのが難しいため、このように動作することを望みません。





図 1.スケーラブルなネットワークトポロジの影響



明らかな解決策は、図2に示すようなネットワークデバイスです。 1（b）。 これは許容できる妥協案となる可能性がありますが、CDNの性質上、地理的なカバレッジとトラフィックの継続的な増加を意味します。



現在、図1に示すように、最小のプレゼンスポイントには2つのネットワークデバイスが含まれています。 1©。 仕組みを図に示します。 2.ルーターは、BGPを介してプロバイダーからルートを直接受信し、FIB（Forwarding Information Base）に挿入します。 ルートを選択するために、ハードウェアに実装されたルックアップテーブルが使用されます。 ホストは、デバイスのFIBでの検索に応じて、ネットワークの最も適切な次のセクションにパケットをリダイレクトするルーターにトラフィックを転送します。





図 2.ルーターを使用したネットワークトポロジ



FIBが大きいほど、デバイスが保存できるルートが多くなります。 境界ルーターは、インターネット全体のルーティングテーブルを格納できる必要があります。これは現在、600,000エントリを超えています。 このようなFIBを保存するために必要なハードウェアは、ルーターのコストの大部分を形成します。

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

従来のクラウド環境では、大量のサーバーとスイッチがサービスを提供している中で、エッジルーターのコストはすぐに無視できます。 ただし、CDNには、コンテンツを配信する場所から収益性の高い多数のポイントが必要です。 したがって、ネットワークデバイスは、CDNインフラストラクチャコストのかなりの部分を占めることができます。



私たちは、非常に高価なネットワークハードウェアに数百万ドルを費やすという考えを好まなかった。 このお金を、コンテンツの配信効率に直接関与する通常のサーバーに投資したいのです。



スイッチを使用することもできますが、非常に限られたFIBがあります-約数万のルートで、必要なものよりはるかに少ないです。 2013年までに、Aristaなどのベンダーは、この制限に対処するのに役立つ機能の実装を開始しました。 ベンダーは、スイッチ上で独自のソフトウェアを実行できるようにしました。



ネットワークデバイスのFIBに依存する代わりに、トラフィックをホストに転送できます。 プロバイダーからのBGPセッションは引き続きスイッチで終了しますが、ルートはホストに到達します。





図 3. BGPルートの反映



外部BGPセッション（eBGP）は、スイッチで実行されているBIRDなどのBGPデーモンで終了します。 結果のルートは、内部BGPセッション（iBGP）を介してホスト上で実行されているBIRDに送信され、ホストコアにルートが直接挿入されます。



これにより、スイッチ上のFIBをバイパスする問題は解決されますが、インターネットにパケットを送り返す方法の問題は解決されません。 FIBのエントリは、宛先のプレフィックスと次のネットワークセクションのアドレスで構成されます。 次のセクションにパケットを送信するには、デバイスはネットワーク上の物理アドレスを知っている必要があります。 このデータは、アドレス解決プロトコルプロトコル（ARP）テーブルに格納されます。



図 図3は、スイッチがプロバイダーに直接接続されているため、スイッチがプロバイダーの正しいARP情報を持っていることを示しています。 ホストはそれを所有していないため、BGPを介して送信されたものの次のネットワークセクションを判別できません。





図 4. SilvertonによるARPの配布

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

これにより、プレゼンスポイントでルーティングを制御する独自のネットワークコントローラーSilvertonが登場しました。 AristaデバイスのAPIを介してARPテーブルの変更について学習するスイッチでデーモンを実行するだけでよいことに気付きました。 プロバイダーの物理MACアドレスの変更について学習すると、Silvertonはこの情報をネットワーク経由で配信し、ホスト上のクライアントはプロバイダーに直接到達する方法に関する情報に基づいてサーバーを再構成します。



プロバイダーのIPアドレスとMACアドレスを取得したら、クライアント側のSilvertonの最初のステップは、ホストを「だまして」、このIPアドレスがインターフェースまたはローカルリンクを介して直接アクセス可能であると「信じる」ことです。 これは、プロバイダーのIPアドレスをiproute経由のインターフェイスで「ピア」として設定することで実現できます。

$ ip addr add <localip> peer 10.0.0.1 dev eth0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ホストがプロバイダーIPアドレスをローカルリンクと見なす場合、ARPテーブルでそのMACアドレスを探します。 これも修正できます。

 $ 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アドレステーブルを調べることにより、フレームを送信するインターフェイスを決定できます。



説明されているプロセスは非常に複雑に見えるかもしれませんが、Silvertonの最初のバージョンには200行未満のコードしか含まれていません。 そして、これにより、展開したすべての拠点で数十万ドルを節約できました。 時間が経つにつれて、Silvertonは「成長」し、動的なネットワーク構成全体の提供を開始しました。つまり、説明フィールドの命名からルーティングアナウンスメントの操作、BGPセッションの空化まで。



さらに、シルバートンは貴重な抽象化レベルを提供しました。 彼は、各ホストが各プロバイダーに直接接続されているという幻想を維持しました。これが出発点でした（図1-オプションA）。 カーネルで複数のルーティングテーブルをサポートし、各パッケージに使用するルーティングテーブルを選択することで、Silvertonの上にツールとアプリケーションを作成することができました。 例として、接続されているすべてのプロバイダーの宛先にpingを送信するst-pingユーティリティがあります。





図 5.プレゼンスポイントでのすべてのトランジットプロバイダーのPing

失敗の前提条件

従来のネットワークデバイスを削除することで資本コストを大幅に削減できることがすでにわかっているため、ロードバランサーに注意を払いました。



従来、負荷はバランサーまたはECMPルーターのみを使用して分散されていました。 最近、反対のアプローチが強まり始めています。特に、MagLevやGLBなどのサービスは、ホストで実行されているソフトウェアを使用してバランスを取っています。



Failedの開発は、従来のスイッチで可能な限りハードウェア処理を使用し、必要に応じてホストに処理を転送する2つのアプローチの統合です。 このアプローチの結果は、分散バランサーです。

顧客の要求のバランスをとる：綱渡り

図に示すように、多数のクライアントにサービスを提供するサーバーのセットを想像してください。 6.クライアントの観点から、どのサーバーがリクエストを処理したかは、応答が十分迅速に受信されるまで重要ではありません。 これにより、どのリクエストがどのリソースによって処理されるかを柔軟に照合できます。 これは負荷分散と呼ばれ、ネットワークスタックのほぼすべてのレベルで実行されます。 ここでは、CDNのコンテキストで着信クライアント要求のバランスを取ることに焦点を当てています。





図 6.バランスを取る場合、クライアント要求は存在する場所でキャッシュサーバーにマップされます



http要求のバランスをとる場合の主な問題は避けられない制限です。確立されたTCP接続からのパケットが間違ったサーバーにリダイレクトされると、対応するTCPストリームがドロップされます。





図 7.バランサー（a）および対応するパケットストリーム（b）を使用するネットワークのトポロジ



バランサーは通常、プロキシとして機能し、クライアントからの接続を終了し、図に示すようにトラフィックをバックエンドサーバーに転送します。 7（a）。



バランサーは、バックエンドサーバーのステータスを監視して、着信ストリームをどこに送るかを決定できます。 正しく実装されている場合、バックエンドサーバー間での要求の分散は最適に近いものですが、非常に高価です。 バランサーは各ネットワーク接続のステータスを監視しますが、これは難しいタスクであり、専用のハードウェアがよく使用されます。



ただし、接続ステータス情報を維持することは、さらに複雑です。 ご存知のように、送信者は接続を追跡するために受信者よりも接続を作成する方が簡単であり、TCPのこの非対称性はDOS攻撃中に定期的に使用されます。 ほとんどのバランサーには、SYNフラッドを防ぐための追加ツールが含まれていますが、それでもネットワークのボトルネックです。 Google MagLevなどの一般的なハードウェアで実行される仮想化されたバランサーでさえ、ストリームのステータスを監視する必要があるため、DOS攻撃も危険です。

DNS：バイパスオプション

DNSは名前をアドレスに変換します。これは、正常に機能しているサーバーのIPアドレスのみが返される場合に、サーバー間で負荷を分散するために使用できます。





図 8. DNS経由のサーバー選択のアーキテクチャ（a）および対応するパケットフロー（b）



このアプローチでは、スレッドのステータスを監視する必要がないため、拡張性に優れています。 ただし、フェイルオーバーに関しては基本的な制限があります。 DNS応答は、ダウンストリームリゾルバーによって数分、場合によっては数時間キャッシュされることもあります。 応答キャッシュ期間は応答のTTLフィールドを介して渡されますが、これはリゾルバーによって常に考慮されるとは限りません。 したがって、変更の伝播にはかなりの時間がかかり、その間、クライアントはアイドル状態のサーバーに接続されます。



SpotifyやNetflixなどの企業は、エンドユーザーアプリケーションと境界のサーバーの両方を制御できます。したがって、アプリケーションにサーバーの選択肢を組み込むことで、DNSでこの問題を回避できます。 FastlyのようなCDNは、ビデオストリーミングからAPI呼び出しまで、多くのオプションを使用する必要があるため、これを行うことができません。 確かに知られている唯一のものは、リクエストがHTTP経由で行われることです。

ECMP：小悪

もう1つのよく知られた代替手段はECMP（Equal Cost Multi-Path）です。 ECMPは、次のネットワークセクションを同じ宛先プレフィックスにマップします。このセクションの選択は、転送されたパケットのヘッダーのフィールドをハッシュすることによって決定されます。 ストリームの存続期間中に変化しないフィールド（ソースアドレス、宛先、ポート）からハッシュを計算することにより、ストリームのすべてのパケットがネットワークの同じ次のセクションに送信されることを確認できます。



サーバーは、パケットをハッシュする接続スイッチへの可用性についてBGPを介して信号を送ることができます。





図 9：再ハッシュ時にECMPスイッチと対応するパケットストリームを介したバランス。



このアプローチの欠点は、最近まで、メーカーがECMPのハッシュの恒常性を維持していなかったことです。 サーバーの追加または除外によりルートが変更された場合、ハッシュ結果が変更される可能性があり、そのためにパケットが別のサーバーに送信される可能性があります。 この状況は図に示されています。 9（b）。



それにもかかわらず、ECMPはCDN業界で一般的なアプローチのままです。 状態の監視を拒否すると、ECMPはサーバーの安定した動作とうまく機能し、代わりに状態を変更するときに接続に問題が発生します。

Elastic ECMP：最初のアプローチ

再キャッシュは、ルート情報（次のネットワークセクション）が変更されると発生します。 可能な代替策は、回避策としてARPテーブルを使用することです。 ルーティングテーブルでネットワークの次の静的セクションを示すことにより、スイッチに強制的にARPテーブルを検索させることができます。 ARPテーブルを再構成して、パケット転送に影響を与えることもできます。



2つの問題があります。

1. BGPやOSPFなどのルーティングプロトコルを使用して、トラフィックをサーバーに転送することはできなくなりました。 従来のルーティングプロトコルは、ルーティングテーブルを変更することでアクセス可能性を提供しますが、このアプローチでは接続層へのトラフィック制御を行います。 図10に示すように、スイッチのARPテーブルを直接変更するコントローラーを作成する必要があります。コントローラーは、接続されたキャッシュで実行されているエージェントと情報を交換します。 各エージェントは、エンドクライアントからのhttp要求を処理するローカルワニスエンティティのステータスをチェックします。
   
   
   
   
   
   図 10. ARPテーブルの変更に基づいたカスタムルーティングプロトコル。 ルーティングテーブルは一定のままであり、ARPテーブルは使用可能なサーバーを示すために変更されます
   
   
2. トラフィックのバランスを取ることができる詳細の深さは、ルーティングテーブル内の次のネットワークセクションの数に直接関連しています。 図に示すように。 10、トラフィックを処理するサーバーを削除する場合、ARPレコードを書き換えて、使用可能なサーバーを指すようにし、別のサーバーへのトラフィックを2倍にする必要があります。 これを回避するために、図に示すように、ネットワークの次のいくつかのセクションを作成できます。 11.各サーバーにネットワークの次の2つの仮想セクションがある場合、サーバーBが動作を停止すると、利用可能なサーバーはそれらを指す同じ数のARPレコードを持ちます。
   
   
   
   
   
   図 11.追加の次のネットワークセクションは、サーバーBが動作を停止したときにトラフィックを均等に分散します

失敗：レイヤーをバイパス

「弾力性のある」ECMRは、依然として多数のワーカーからサーバーの正確な出力を提供できません。 図に戻る 11.ホストBに障害が発生すると、残りのすべてのサーバーにトラフィックが送られます。 すべての既存の接続がリセットされます。



これは避けられないと考えられており、ハードウェア障害またはソフトウェア問題のまれな現象が原因であるため、受け入れる価値があります。 ただし、実際には、ソフトウェアをアップグレードするためにサーバーが実稼働環境から頻繁に削除されます。 このために接続をドロップすると、一時的なトラフィックの問題が発生するだけではありません。 これにより、アップグレードするたびに問題が発生するため、新しいソフトウェアを迅速に導入することが難しくなります。



正しい障害処理は、特定の時点でどのフローがアクティブであるかを「認識」しないため、スイッチにのみ実装できません。 解決策は、コントローラーとホスト間で状態追跡を分散することでした。 このために、独自の失敗したソリューションを開発しました。



サーバーを本番環境から片付けるための最初のステップは、シグナルを送ることです。 前の例では、ホストインターフェイスにMACアドレスが1つしかないことを示しましたが、実際にはそのような制限はありません。 スイッチのARPテーブルには、以前に動作していたホストに関する情報だけでなく、新しいホストに関する情報も入力できます（図12）。





図 12.アイドル状態のMACアドレスを置き換えるホストエンコーディング



可用性情報をスイッチに渡したので、バランシングの決定をサーバーに委任できます。 これにより、ネットワーク内のストリームのステータスを監視する必要がなくなるだけではありません。 また、スイッチよりも存在点にあるサーバーに計算負荷を転送します。



この計算の負担は、受信側で個別のカーネルモジュールとして処理を実装することで軽減されます。 宛先MACアドレスに従って着信パケットを効率的に処理します（図13を参照）。





図 13.トラフィックがホストBからホストAに転送されるときの受信側でのパケット処理の例。パケットはホストAでフィルタリングされ、新しい接続に属するかローカルTCPソケットに対応する場合にのみ受信されます。



受信ホストのカーネルモジュールは、最初に以前の宛先がこのホストに一致するかどうかを判断する必要があります。 その場合、処理はローカルネットワークスタックに渡されます。 そうでない場合は、パケットが新しい接続（TCPヘッダーのSYNフラグを介して-ステップ2）に属しているか、既存の接続に属していることを確認する必要があります。



これらの条件のいずれも満たされない場合、パケットはMACヘッダーを書き換えて前の宛先にリダイレクトされます。



同じロジックがホストBに適用されます（ステップ5）。 この場合、以前の宛先として示されたホストがホストに対応するため、パケットは受け入れられます。





図 14.順次カーネルアップグレード中にサーバークラスターにグラフ（1秒あたりの要求数）を読み込みます。 ホストは、サービスに影響を与えることなく「プロダクション」に出て戻ります



過去3年間のFaildの実装は、トラフィックだけでなく影響も受けています。 サーバーで必要な作業のマイナスの影響を減らすことにより、Faildを使用すると、クライアントに影響を与えることなく、新しいソフトウェアをより迅速に展開でき、脆弱性検出への反応も加速しました。

まとめ

2013年にFailedソリューションが導入されて以来、Fastlyは1秒あたり数百万件のリクエストに達しました。 これに大きく貢献したのは、ユーザーに損失を与えることなくネットワーク再構成のコストを削減する「弾性」バランス調整です。



ECMPの組み合わせ、ARPの書き換え、およびカーネルの操作を通じて、この成長は、従来のスイッチよりも複雑なものを取得することなく、カスタムソリューションによってサポートされました。