最近、DDoS-Guard ネットワーク上の正規のトラフィックが 50 ギガビット/秒を超えました。 現在、全トラフィックの XNUMX% はクライアント Web サービスによって生成されています。 これらは何万ものドメインであり、非常に異なっており、ほとんどの場合、個別のアプローチが必要です。
その下には、フロント ノードを管理し、数十万のサイトに SSL 証明書を発行する方法が示されています。
XNUMX つのサイト (非常に大きなサイトであっても) のフロントをセットアップするのは簡単です。 nginx、haproxy、または lighttpd を使用し、ガイドに従って設定し、それを忘れます。 何かを変更する必要がある場合は、リロードして再度忘れます。
大量のトラフィックをオンザフライで処理し、リクエストの正当性を評価し、ユーザー コンテンツを圧縮してキャッシュし、同時にパラメータを XNUMX 秒間に数回変更すると、すべてが変わります。 ユーザーは、個人アカウントの設定を変更した直後に、すべての外部ノードで結果を確認したいと考えています。 ユーザーは、API 経由で個別のトラフィック処理パラメータを含む数千 (場合によっては数万) のドメインをダウンロードすることもできます。 これらすべては、アメリカ、ヨーロッパ、アジアでもすぐに機能するはずです。モスクワだけでも物理的に分離されたいくつかの濾過ノードがあることを考えると、この作業はそれほど簡単なものではありません。
世界中に大規模で信頼性の高いノードがたくさんあるのはなぜですか?
-
クライアント トラフィックのサービス品質 - 米国からのリクエストは米国で処理される必要があり (攻撃、解析、その他の異常を含む)、モスクワやヨーロッパにプルされないため、処理遅延が予想外に増加します。
-
攻撃トラフィックは局地化する必要があります。攻撃中に交通事業者のパフォーマンスが低下する可能性があり、その量は多くの場合 1Tbps を超えます。 大西洋横断リンクまたはアジア横断リンクを介して攻撃トラフィックを転送することは得策ではありません。 実際に、Tier 1 オペレーターが「あなたが受ける攻撃の量は、私たちにとって危険です」と言ったケースがありました。 そのため、私たちはできるだけソースに近い受信ストリームを受け入れます。
-
サービスの継続性に対する厳格な要件 - 急速に変化する世界において、清掃センターは相互に依存したり、地域の出来事に依存したりしてはなりません。 MMTS-11 の 9 フロアすべての電源を XNUMX 週間遮断しましたか? - 問題ない。 この特定の場所に物理的な接続がないクライアントは XNUMX つも影響を受けず、Web サービスはいかなる状況でも影響を受けません。
これらすべてを管理するにはどうすればよいでしょうか?
サービス設定は、すべてのフロント ノードにできるだけ早く (理想的には即時に) 配布される必要があります。 単にテキスト設定を取得して再構築し、変更のたびにデーモンを再起動することはできません。同じ nginx がさらに数分間 (WebSocket セッションが長い場合は数時間も) プロセスをシャットダウン (ワーカーがシャットダウン) し続けます。
nginx 構成をリロードすると、次の図はまったく正常です。
メモリ使用率について:
古いワーカーは、接続数に線形的に依存しないメモリも含めてメモリを消費します。これは正常です。 クライアント接続が閉じられると、このメモリは解放されます。
nginx が始まったばかりのときに、なぜこれが問題にならなかったのでしょうか? HTTP/2 も WebSocket も、大規模で長時間のキープアライブ接続もありませんでした。 Web トラフィックの 70% は HTTP/2 であり、これは非常に長い接続を意味します。
解決策は簡単です。nginx を使用せず、テキスト ファイルに基づいてフロントを管理せず、圧縮されたテキスト設定を太平洋チャネル経由で送信しないでください。 もちろんチャンネルは保証され、予約されていますが、だからといって大陸横断感が薄れるわけではありません。
当社には独自のフロント サーバー バランサーがあり、その内部については次の記事で説明します。 主に実行できることは、再起動、リロード、メモリ消費量の突然の増加などを行わずに、XNUMX 秒あたり数千件の構成変更をその場で適用することです。 これは、Erlang などのホット コード リロードに非常に似ています。 データは地理的に分散されたキーと値のデータベースに保存され、フロント アクチュエーターによって即座に読み取られます。 それらの。 モスクワの Web インターフェイスまたは API を介して SSL 証明書をアップロードすると、数秒でロサンゼルスのクリーニング センターに送られる準備が整います。 世界大戦が突然起こり、世界中でインターネットが消滅しても、私たちのノードは自律的に動作し続け、ロサンゼルス - アムステルダム - モスクワ、モスクワ - アムステルダム - 香港の専用チャネルの XNUMX つが確立されるとすぐにスプリット ブレインを修復します。 Los-Los が利用可能になります。アンヘレスまたは少なくとも XNUMX つの GRE バックアップ オーバーレイ。
これと同じメカニズムにより、Let's Encrypt 証明書を即座に発行および更新できます。 非常に簡単に言うと、次のように動作します。
-
クライアントのドメインに対する証明書なし (または期限切れの証明書あり) の HTTPS リクエストが少なくとも XNUMX つ確認されると、リクエストを受け入れた外部ノードがこれを内部証明機関に報告します。
-
ユーザーが Let's Encrypt の発行を禁止していない場合、認証局は CSR を生成し、LE から確認トークンを受け取り、暗号化されたチャネルを通じてすべてのフロントに送信します。 これで、どのノードも LE からの検証リクエストを確認できるようになります。
-
しばらくすると、正しい証明書と秘密鍵を受け取り、同様の方法で前線に送信されます。 もう一度、デーモンを再起動せずに
-
有効期限の7日前から証明書の再受領手続きが開始されます
現在、ユーザーに対して完全に透過的に 350 個の証明書をリアルタイムでローテーションしています。
このシリーズの次の記事では、大規模な Web トラフィックのリアルタイム処理の他の機能について説明します。たとえば、不完全なデータを使用して RTT を分析してトランジット クライアントのサービス品質を向上させることや、一般的にトランジット トラフィックを外部から保護することについて説明します。テラビット攻撃、トラフィック情報の配信と集約、WAF、ほぼ無制限の CDN、コンテンツ配信を最適化するための多くのメカニズムについてです。
登録ユーザーのみがアンケートに参加できます。 お願いします。
まず何を知りたいですか?
-
視聴者の３８%がWeb トラフィックの品質をクラスタリングおよび分析するためのアルゴリズム<3
-
視聴者の３８%がDDoS-Guard7 バランサーの内部
-
視聴者の３８%がトランジット L3/L4 トラフィックの保護2
-
視聴者の３８%が交通トラフィック上の Web サイトの保護0
-
視聴者の３８%がWeb アプリケーション ファイアウォール3
-
視聴者の３８%が解析とクリックに対する保護6
21 人のユーザーが投票しました。 6名のユーザーが棄権した。
出所： habr.com