都市別および重量別、またはCDNノード間のバランス調整方法

ノードが大きくなりすぎてノードが異なる都市に出現すると、ノード間で負荷を分散するタスクが発生します。 このようなバランス調整のタスクは異なる場合がありますが、原則として目標は同じです。 私の手は、通常これを行う方法、およびivi.ruでそれを行う方法に達しました。

前の記事で 、詳細を慎重に避けながら、独自のCDNがあると述べました。 共有する時間です。 ストーリーは、ありとあらゆる解決策を見つけるスタイルになります。

アイデアを探しています

ジオバランスの基準は何ですか？ ここに私のリストがあります：
1）コンテンツのダウンロード時の遅延の削減
2）サーバーの負荷を分散する
3）チャンネルの負荷を塗りつける

さて、そもそも遅延の減少があるため、ユーザーを最も近いノードに送信する必要があります。 どうすればこれを達成できますか？ まあ、このあたりにはGeo-IPベースがあり、これを地域の広告バインディングに使用しています。 たぶんそれをケースに適応させるのでしょうか？ たとえば、中央のデータセンターにいるパスマンを作成し、彼にアクセスしたユーザーの地域を特定し、そのリダイレクトを最も近いノードに返すことができます。 機能しますか？ それはなりますが、悪いです！ なんで？
まあ、まず、ユーザーはすでにモスクワに来て、モスクワで必要のないものを見つけるだけです。 そして、彼は必要な映画ファイルのためにローカルサイトですでに2回目の呼び出しを行う必要があります。 そして、映画がチャンクに分割された場合（チャンク、これらは小さなフィルム片のような小さなファイルです）？ 次に、各チャンクに対して2つの要求があります。 ああ、ああ、ああ！ もちろん、すべてを最適化して、映画ごとに1回だけモスクワに行くコードをクライアントで作成することもできますが、これによりこのコードが重くなります。 そして、サポートされているすべてのタイプのデバイスで複製する必要があります。 余分なコードは悪いので、拒否してください！

私が観察した（テストしたとは言えませんが）かなり多くのCDNがリダイレクトバランシングを使用しています。 彼らがこれを行うもう一つの理由は請求だと思います。 結局のところ、彼らは商業的な人々であり、彼らと彼らに支払った人々だけに奉仕する必要があります。 そして、このようなバランサーのチェックには余分な時間がかかります。 前回述べた結果につながったのは、まさにこのアプローチであると確信しています。CDNを含むサイトの読み込みはより遅くなります。 そして、最初からこの方法を完全に無視しました。

名前でしたら？

モスクワにもう一度走る必要がなくなるように、どうすればジオバランシングを行うことができますか？ しかし、私に聞かせて！ とにかく、私たちは何らかの方法でモスクワに行きます-ドメイン名を破るために！ しかし、サーバーの応答にユーザーの場所が考慮されている場合はどうでしょうか？ はい、簡単に！ これをどのように行うことができますか？ もちろん、手動で：複数のビュー（ビュー）を作成し、同じドメイン名の異なるユーザーに異なるIPアドレスを返すことができます（専用のFQDNを作成します）。 オプション？ そして！ 手動でのみサポートする必要があります。 自動化することも可能です-たとえば、バインドの場合、同じMaxMindを操作するためのモジュールがあります。 他の選択肢もあると思います。

驚いたことに、現在ではDNSバランシングが最も一般的な方法です。 小規模企業がニーズに合わせてこの方法を使用するだけでなく、大手の大手メーカーもこの方法に基づいて複雑なハードウェアソリューションを提供しています。 したがって、たとえば、F5 Big IPは機能します。 繰り返しになりますが、彼らはこれがNetflixの仕組みだと言います。 なぜ驚きですか？ ユーザーからのDNSクエリのチェーンを精神的にトレースします。

パッケージはユーザーのPCからどこで取得しますか？ 原則として-プロバイダーのDNSサーバーへ。 この場合、このサーバーがユーザーの近くにあると仮定すると、ユーザーは自分に最も近いノードに移動します。 しかし、かなりの割合の場合（当社のオフィスでの単純なサンプルでも顕著な結果が得られます）、Google DNS、Yandex.DNS、またはその他のDNSのいずれかの普遍的な悪事になります。

なぜこれが悪いのですか？ さらに調べてみましょう。そのようなリクエストが許可されたDNSに到着すると、そのソースIPは誰になりますか？ サーバー！ 顧客なし！ したがって、バランシングDNSは、実際にはユーザーではなくサーバーのバランスを取ります。 ユーザーが自分の地域でサーバーを使用できない場合、この情報に基づくノードの選択は最適ではありません。 そしてさらに悪いことです。 このようなGoogleキャッシュは、バランシングサーバーの応答をキャッシュし、リージョンを考慮せずにすべてのクライアントにそれを返します（ビューは構成されていません）。 つまり 失態。 ところで、そのような機器の製造業者自身は、個人的な会議で、DNSバランスに関するこれらの基本的な問題の存在を完全に確認しました。

実を言うと、CDNの構築の夜明けにこの方法を使用しました。 結局のところ、私たちは独自のノードの経験がありませんでした。 システムインテグレーターは、そのようなタスクのために、多数のゼロを含む量の機器の多くの車をすぐに販売しようとしました。 DNSベースのソリューションは、原則として、理解可能で実用的です。 営業経験から、これらのすべてのマイナス面が浮上しています。 さらに、予防保守に対するノードの結論は非常に複雑です。すべてのデバイスのキャッシュがユーザーに届くまで待つ必要があります（ところで、膨大な数のホームルーターがDNSレコードのTTLを完全に無視し、電源が切れるまでキャッシュを保存します）。 そして、ノードが突然シャットダウンしたらどうなるでしょう-考えるのはとても怖いです！ そしてもう1つ、問題があるときにサブスクライバーがどのノードからサービスを受けているかを理解することは非常に困難です。 結局のところ、それはいくつかの要因に依存します。どの地域にあるか、どのDNSを使用するかです。 一般に、多くのあいまいさがあります。

pingするかしないか

そして、ここに「2番目」があります（誰かが私が最初に始めた理由に疑問を抱く場合）：インターネットでは、地理的に近い要素はトラフィックフローの観点から非常に遠い場合があります（前回から「モスクワからモスクワへ」 -アムステルダム経由 "？）。 つまり 特定のノードへのユーザーの方向を決定するには、geo-IPデータベースでは不十分です。 また、CDNが接続されているプロバイダーとユーザー間の接続を考慮する必要があります。 私の意見では、ここハブで、プロバイダー間の接続に関するデータベースの手動メンテナンスについて言及した記事に出会いました。 もちろん、それはかなりの時間にわたって機能しますが、そのようなソリューションの合理性は明らかに存在しません。 プロバイダー間のチャネルが落ちたり、詰まったり、関係の切断により切断されたりする場合があります。 したがって、サイトからユーザーへの品質監視を自動化する必要があります。

ユーザーに対するチャネルの品質をどのように評価できますか？ もちろん、pingで！ そして、最適なオプションを選択する必要があるため、すべてのノードからユーザーにpingを実行します。 次回に結果をどこかに保存します。すべてのユーザーノードがpingされるまで待つと、映画を待たないからです。 そのため、最初にユーザーが常に中央サイトから提供されます。 そして、チュコトカからモスクワへの悪いチャネルがある場合-それは、二度目がないことを意味します。 ちなみに、ユーザーは常に応答するわけではありません。新しいホームルーターやあらゆる種類のWindows 7は、デフォルトではエコー要求に応答しません。 したがって、これらは常にモスクワからも提供されます。 これらの問題を隠すために、サブネット上でユーザーを集約することで最適なノードを計算するアルゴリズムを複雑にしましょう。 次に、特許を取得してSkolkovoに進みます。そのようなシステムは、その深刻さと非効率性のために他に必要な場所はありません。

そして奇妙なことに、「産業用」ソリューションでは、特定のユーザーのPingといった接続マップを決定するこのような方法を使用しています。 端末デバイスがICMP pingに応答しないという事実を完全に無視し、多くのプロバイダー（特に西側）がすべてのICMPをルートに切り取ります（私自身はそれをうまくフィルタリングしたい）。 そして、これらすべての産業用ソリューションは、無意味なpingでインターネットを満たし、プロバイダーにICMPのフィルタリングを強制します。 私たちの選択ではありません！

この時点で、私はとても悲しく感じました。 結局のところ、インターネットで見つけたジオバランシング手法は、私たちの目標や目的にはあまり適していませんでした。 そして、それらはその時点ですでに次のように定式化できました。

1.サブスクライバーは、最初に最も近いサイトに連絡する必要があります。必要なコンテンツがない場合にのみ、次に大きいサイトに連絡する必要があります
2.ソリューションは、特定のユーザーの設定に依存しないようにする必要があります
3.ソリューションでは、ユーザーからCDNへの現在の接続を考慮する必要があります
4.このソリューションは、ivi技術者に、ユーザーがサービスを提供しているノードを理解する機会を提供する必要があります。

啓発

そして、私はエニキャストという言葉に出会いました。 私は彼を知りませんでした。 どういうわけか、ユニキャスト、ブロードキャスト、そしてお気に入りのマルチキャストを思い出しました。 私はグーグル検索を開始し、これが私たちの選択であることがすぐに明らかになりました。

エニーキャストを簡単に説明すると、「ハック、インターネット上のIPアドレスの一意性の原則に違反する」のようになります。 同じサブネットが自律システムの相互作用を考慮してインターネット上のさまざまな場所からアナウンスされるという事実により、IGPメトリックまたは同等のものにより、異なるノードが同じプロバイダーの自律ネットワークと接触した場合、最も近いノードが選択されます。 組み立てられたシステム（自律番号は例として示されていますが、同僚への敬意を払うわけではありません）が実際にどのように見えるかをご覧ください。



また、BGPルーティングの観点からはどのように見えますか。 一意ではないIPアドレスはないが、さまざまな都市にいくつかの通信チャネルがあるかのように：



そして、プロバイダーのネットワークに最適な方法を選択させます。 すべての通信事業者が独自のネットワークの敵ではないため、ユーザーが最も近いCDNに到達することを確認できます。

もちろん、現在のインカネーションのBGPには、輻輳チャネルに関する情報は含まれていません。 しかし、そのような情報はプロバイダーのネットワークエンジニアによって提供されます。 また、トラフィックを特定のチャネルに送信する場合、その理由があります。 エニーキャストの特性により、トラフィックはパケットを送信した方向から送信されます。

最終的な図は次のようになります。

1.ユーザーが専用FQDNにアクセスします
2.この名前は、エニーキャスト範囲のアドレスに解決されます
3.ユーザーは最も近い（ネットワークの観点から）CDNに到達します。
4.ノードにそのようなコンテンツがある場合、ユーザーはノードからコンテンツを受信します（つまり、1つのリクエスト!!!）。
5.ホストにそのようなコンテンツがない場合、ユーザーはモスクワへのHTTPリダイレクトを受け取ります

ノード上のコンテンツのローカライズが高いという事実に基づいて（単一サーバーノードはカウントされません）、ほとんどのユーザーリクエストは最も近いノードから処理されます。 最小限の遅延で。 そして、これはユーザーにとって重要ではありませんが（プロバイダーにとっては非常に重要です）-非トランク通信チャネルを介して。

エニーキャストとその制限は、 RFC4786で非常によく説明されています 。 これが最初で最後のRFCであり、最後まで読みました。 主な制限は、ルートを再構築する機能です。 実際、TCPセッションの途中からのパケットが突然別のホストに送られた場合、RSTはそこから戻ってきます。 また、TCPセッションが長いほど、この可能性が高くなります。 映画を見るには、これは非常に重要です。 どうやってこれを回避しましたか？ いくつかの方向で：

1.コンテンツの一部は、チャンクの形式で利用可能です。 したがって、TCPセッション時間はごくわずかです
2.セッションの中断によりプレーヤーが映画の一部をダウンロードできなかった場合、プレーヤーはエラーを表示しませんが、もう一度試みます。 大きなバッファ（10〜15秒）が与えられた場合、ユーザーはまったく何も気付きません。

別の（そして、時には非常に不快な制限）は、エニーキャストに基づくCDNオペレーターは、ユーザーがどのノードからサービスを受けているかを直接制御できないことです。 ほとんどの場合、これは私たちにとって良いことです（オペレーターに自分のチャンネルが厚い場所を決定させてください）。 しかし、時には別の方向にプッシュする必要があります。 そして、最良の部分はそれが可能であるということです！

バランシング！

ノード間で要求の望ましい分散を実現するには、いくつかの方法があります。

1.ネットワーク作成者に連絡する-連絡先の長時間の苦痛な検索（RIPE DBの誰もが何らかの形で維持したくない）のために、それらをいらいらさせ、あなたはエニーキャストについてたくさん話さなければなりません。 しかし、場合によっては-唯一の方法
2.アナウンスにプリペンドを追加します（プリペンド、これは「BGPのルートを視覚的に拡張する」ときです）。 重砲。 直接のジャンクションでのみ適用され、トラフィック交換ポイントでは決して適用されません（IX）
3.統治コミュニティ、私のお気に入り。 すべてのまともなプロバイダーはそれらを持っています（はい、反対は本当です：それを持っていない人は下品です）。 おおよそプリペンドとして機能しますが、きめ細かく、ジョイントを介してすべてのクライアントにプリペンドを追加するのではなく、アナウンスが終了するまで特定の方向にのみ追加します。

当然、このブラックボックスシステム全体を使用することは不可能ですが、Looking Glass（LG、私は翻訳しません。すべての翻訳が悪いため）はありません。 LGでは、機器にアクセスせずにプロバイダーのルーティングテーブルを確認できます。 すべてのきちんとした演算子には、そのようなものがあります（私たちは演算子ではありませんが、1つもあります）。 そして、このような些細なことにより、非常に多くの場合に通信事業者のネットワーク事業者への電話を避けることができます。 だから私は自分の間違いと見知らぬ人を見つけました。

エニーキャストベースのバランスCDNの3年間の運用すべてについて、モスクワに集中ルートリフレクタ（RR）を備えた全国のネットワークという1つの困難なケースのみが浮上しています。 実際、このようなアーキテクチャにより、プロバイダーにとって分散接続は役に立たなくなります。結局、RRはそれに最も近い最適なルートを選択します。 そして彼は皆に発表されます。 ただし、このようなアーキテクチャの欠点のため、このネットワークはすでに再構築されています。

私たちの機器と他の人の機器の両方での事故は、CDNの非常に良好な安定性を示しました。1つのノードが故障するとすぐに、クライアントはそこから他のノードに移動します。 そして、すべてではありません。これも非常に便利です。 これには人間の心の介入は必要ありません。 メンテナンス作業用のサイトの結論も簡単です。エニーキャストプレフィックスのアナウンスを停止し、ユーザーはすぐに他のサイトに切り替えます。

おそらくもう1つのアドバイスをします（ただし、これは前述のRFCにも記載されています）：エニーキャストに基づいて分散ネットワークノードを構築している場合は、FullViewでない場合は必ずこのノードを取得してください（地域にあるシスコでは500キロプレフィックス）適合しない）、デフォルトのルートは必須です！ インターネット上の非対称ルーティングのケースは非常に一般的であり、ルーティングにブラックホールがあるため、ユーザーをブラックスクリーンの前に置いたままにしたくありません。

だから、ノードへのユーザーの「固着」を決定する可能性についての要件でまだ言及しているようです。 これも実装されています。 :)プロバイダーが送信する（またはユーザーを送信できる）ノードを決定するために、すべてのノードからのアナウンスメントにコミュニティマーキングが付けられます。 そして、それらの意味はRIPE DBのIRRレコードに記述されています。 したがって、57629：101というラベルの付いたプレフィックスを受け入れた場合、モスクワに行くことを知ってください。

使用する別の方法があります：エニーキャストネットワーク上のソースから問題のIPアドレスにpingを送信します。 パケットが返された場合（pingへの応答を受信した場合）、クライアントはこのノードからサービスを受けます。 理論的には、これはすべてのノードをソートする必要があることを意味しますが、実際には、サブスクライバーがサービスを受ける場所を正確に予測できます。 そして、ユーザーがまったく応答しない場合（上で自分で書きましたよね？） 問題ありません！ 原則として、同じサブネット内に応答するルーターがあります。 これで十分です。

さて、サイトに来ました。 しかし、結局のところ、1つのノードにサーバーが1つしかないと考える人はいないでしょうか。 もしそうなら、どうにかしてそれらの間でリクエストを分配する必要があります。 しかし、このトピックは、もちろん興味がない限り、別の記事を対象としています。