Badoo はどのようにして 200 秒あたり XNUMX 万枚の写真を送信できるようになったのか

現代の Web はメディア コンテンツなしではほとんど考えられません。ほとんどすべての祖母がスマートフォンを持ち、誰もがソーシャル ネットワークを利用しており、メンテナンスのダウンタイムは企業にとってコストがかかります。 同社のストーリーの転写は次のとおりです Badooメンバー中 彼女がハードウェア ソリューションを使用して写真の配信をどのように整理したか、その過程で遭遇したパフォーマンスの問題とその原因、およびすべてのレベルでフォールト トレランスを確保しながら、Nginx ベースのソフトウェア ソリューションを使用してこれらの問題をどのように解決したかについて (ビデオ）。 オレグの物語の著者に感謝します サニス カンファレンスでの経験を共有したエフィモワとアレクサンドラ・ディモワ 稼働時間 4 日目.

— 写真の保存とキャッシュの方法について少し紹介しましょう。 写真を保存するレイヤーと、写真をキャッシュするレイヤーがあります。 同時に、高いトリック レートを達成し、ストレージの負荷を軽減したい場合は、個々のユーザーの各写真が 99 つのキャッシュ サーバー上に存在することが重要です。 そうしないと、サーバーの数と同じくらい多くのディスクをインストールする必要があります。 当社のトリック率は約 100% です。つまり、ストレージの負荷を 10 分の 50 に削減しています。これを実現するために、50 年前、これらすべてを構築していたとき、サーバーは XNUMX 台ありました。 したがって、これらの写真を提供するには、これらのサーバーが提供する XNUMX の外部ドメインが基本的に必要でした。

当然のことながら、すぐに疑問が生じました。サーバーの 5 つがダウンして利用できなくなった場合、トラフィックのどの部分が失われるのでしょうか? 私たちは市場にあるものを検討し、すべての問題を解決できるハードウェアを購入することにしました。 選択は、FXNUMX ネットワーク会社 (ちなみに、最近 NGINX, Inc を買収した) のソリューションである BIG-IP Local Traffic Manager に決まりました。

このハードウェア (LTM) の機能: これは、外部ポートの冗長性を確保し、ネットワーク トポロジや一部の設定に基づいてトラフィックをルーティングし、ヘルス チェックを行うことができるアイアン ルーターです。 私たちにとって、このハードウェアがプログラムできることが重要でした。 したがって、特定のユーザーの写真が特定のキャッシュからどのように提供されるかのロジックを記述することができます。 それはどのように見えますか？ 80 つのドメイン、443 つの IP でインターネットを調べ、SSL オフロードを実行し、http リクエストを解析し、IRule からキャッシュ番号を選択し、どこに送信するかを決定し、そこにトラフィックを送信するハードウェアがあります。 同時にヘルスチェックも行い、一部のマシンが利用できなくなった場合には、トラフィックが35つのバックアップサーバーに流れるようにしました。 構成の観点からは、もちろんいくつかのニュアンスがありますが、一般的にはすべて非常に単純です。カードを登録し、ネットワーク上の IP に特定の番号を対応させ、ポート XNUMX でリッスンすると言います。 XNUMX では、サーバーが利用できない場合は、バックアップサーバー (この場合は XNUMX 番目) にトラフィックを送信する必要があることを示し、このアーキテクチャをどのように分解するかについての一連のロジックを説明します。 唯一の問題は、ハードウェアがプログラムされている言語が Tcl であったことです。 これを覚えている人がいるとしたら...この言語は、プログラミングに便利な言語というよりは書き込み専用です。

何が得られたでしょうか？ 私たちは、インフラストラクチャの高可用性を確保し、すべてのトラフィックをルーティングし、健康上の利点を提供し、適切に機能するハードウェアを受け取りました。 さらに、この機能は非常に長期間動作し、過去 10 年間、この機能に関する苦情はありません。 2018 年の初めまでに、すでに 80 秒あたり約 80 枚の写真を送信していました。 これは、両方のデータ センターからのトラフィックが約 XNUMX ギガビットに相当します。

しかし…

2018 年の初め、私たちはチャート上で醜い状況を目にしました。写真の送信にかかる時間が明らかに増加していたのです。 そしてそれは私たちには合わなくなりました。 問題は、この動作がトラフィックのピーク時にのみ発生したことです。当社の場合、これは日曜日から月曜日の夜です。 しかし、それ以外の時間ではシステムは通常どおり動作し、障害の兆候はありませんでした。

それにもかかわらず、問題は解決されなければなりませんでした。 私たちはボトルネックとなる可能性のあるものを特定し、それらの除去を開始しました。 もちろん、まず第一に、外部アップリンクを拡張し、内部アップリンクの完全な監査を実施し、考えられるすべてのボトルネックを発見しました。 しかし、これらすべては明らかな結果をもたらさず、問題は消えませんでした。

もう XNUMX つのボトルネックとして考えられるのは、写真キャッシュ自体のパフォーマンスです。 そして私たちは、おそらく問題は彼らにあると判断しました。 さて、私たちはパフォーマンスを拡張しました - 主に写真キャッシュのネットワーク ポートです。 しかし、やはり明らかな改善は見られませんでした。 最終的に、私たちは LTM 自体のパフォーマンスに細心の注意を払いましたが、ここでグラフに悲しい状況が見られました。すべての CPU の負荷が順調に進み始めますが、その後突然頭打ちになります。 同時に、LTM はヘルスチェックとアップリンクに適切に応答しなくなり、それらをランダムにオフにし始め、深刻なパフォーマンスの低下につながります。

つまり、問題の原因とボトルネックを特定しました。 私たちが何をするかを決めるのはまだ残っています。

まず、私たちができる最も明らかなことは、LTM 自体を何らかの方法で最新化することです。 ただし、ここにはいくつかのニュアンスがあります。このハードウェアは非常にユニークなので、最寄りのスーパーマーケットに行って購入することはできません。 これは別の契約、別のライセンス契約となり、非常に時間がかかります。 XNUMX 番目のオプションは、自分で考え始め、独自のコンポーネントを使用して、できればオープン アクセス プログラムを使用して、独自のソリューションを考え出すことです。 残っているのは、ユーザーが十分な写真を受け取っていないため、この問題に対して正確に何を選択するか、そしてこの問題の解決にどれだけの時間を費やすかを決定することだけです。 したがって、私たちはこれらすべてを非常に迅速に、昨日のように行う必要があるかもしれません。

このタスクは「手持ちのハードウェアを使用して、できるだけ早く何かを行う」ように聞こえたので、私たちが最初に考えたのは、あまり強力ではないマシンを前面から削除し、そこに Nginx を配置することでした。ハードウェアが行っていたのと同じロジックをすべて実装しようとします。 つまり、実際には、4 年前と同様に、ハードウェアを残し、さらに 10 台の設定が必要なサーバーをインストールし、それらのサーバー用に外部ドメインを作成しました。これらのマシンが故障すると可用性が少し失われますが、ましてや、ユーザーの問題をローカルで解決してくれたわけではありません。

したがって、ロジックは同じままです。Nginx をインストールし、SSL オフロードを実行でき、何らかの方法でルーティング ロジックをプログラムし、構成でヘルスチェックを実行し、以前のロジックを単純に複製することができます。

座って構成を書きましょう。 最初はすべてが非常に単純であるように見えましたが、残念なことに、すべてのタスクのマニュアルを見つけるのは非常に困難です。 したがって、「写真用に Nginx を構成する方法」を単にグーグルで検索することはお勧めしません。どの設定を変更する必要があるかを示す公式ドキュメントを参照することをお勧めします。 ただし、特定のパラメータを自分で選択することをお勧めします。 さて、すべては単純です。所有するサーバーについて説明し、証明書について説明します... しかし、最も興味深いのは、実際には、ルーティング ロジック自体です。

最初は、私たちは単に自分の位置を説明し、そこにある写真キャッシュの数を照合し、手やジェネレーターを使って必要なアップストリームの数を説明し、各アップストリームでトラフィックが送信されるサーバーを示しているだけのように見えました。メイン サーバーが利用できない場合は、バックアップ サーバーに移動します。

しかし、おそらく、すべてがそれほど単純であれば、私たちは何も言わずにただ家に帰るでしょう。 残念ながら、デフォルトの Nginx 設定では、一般に長年の開発を経て作成されており、このケースには完全には適していません... 構成は次のようになります: 上流のサーバーでリクエスト エラーまたはタイムアウトが発生した場合、Nginx は常にトラフィックを次のトラフィックに切り替えます。 さらに、最初の失敗の後、10 秒以内に、誤ってタイムアウトによってサーバーもオフになります。これはいかなる方法でも構成することさえできません。 つまり、アップストリーム ディレクティブのタイムアウト オプションを削除またはリセットすると、Nginx はこのリクエストを処理せず、あまり良くないエラーで応答しますが、サーバーはシャットダウンします。

これを回避するために、次の XNUMX つのことを行いました。

a) Nginx がこれを手動で行うことを禁止しています。そして残念なことに、これを行う唯一の方法は、単純に最大失敗回数を設定することです。

b) 他のプロジェクトでは、バックグラウンドでヘルス チェックを実行できるモジュールを使用していることを思い出しました。したがって、事故時のダウンタイムを最小限に抑えるために、かなり頻繁にヘルス チェックを実行しました。

残念ながら、これがすべてではありません。文字通り、このスキームの運用の最初の 200 週間で、TCP ヘルスチェックも信頼できないことが示されたからです。アップストリーム サーバーでは、Nginx または D ステートの Nginx ではない可能性があります。この場合、カーネルは接続を受け入れ、ヘルスチェックはパスしますが、機能しません。 したがって、すぐにこれを health-check http に置き換え、特定のものを作成しました。これが XNUMX を返した場合、このスクリプトではすべてが機能します。 追加のロジックを実行できます。たとえば、キャッシュ サーバーの場合は、ファイル システムが正しくマウントされていることを確認します。

そして、これは私たちに適していますが、現時点では回路がハードウェアの動作を完全に繰り返している点が異なります。 しかし、私たちはより良いものを作りたかったのです。 以前はバックアップ サーバーが XNUMX 台ありましたが、これはおそらくあまり良くありません。サーバーが XNUMX 台ある場合、複数のサーバーで同時に障害が発生すると、XNUMX 台のバックアップ サーバーでは負荷に対処できない可能性が高いからです。 したがって、すべてのサーバーに予約を分散することにしました。単純に別の別個のアップストリームを作成し、そこにすべてのサーバーに、処理できる負荷に応じた特定のパラメーターを書き込み、以前と同じヘルスチェックを追加しました。

XNUMX つのアップストリーム内で別のアップストリームに移動することは不可能であるため、正しく必要な写真キャッシュを記録するだけのメイン アップストリームが利用できない場合は、単純に error_page を通過してフォールバックするようにする必要がありました。アップストリームのバックアップに移動した場所:

そして、文字通り 40 台のサーバーを追加することで、これが得られました。負荷の一部を置き換えました。LTM からこれらのサーバーに負荷を削除し、標準のハードウェアとソフトウェアを使用して同じロジックを実装し、これらのサーバーができるというボーナスをすぐに受け取りました。必要なだけ供給できるため、拡張することができます。 そうですね、唯一のマイナス点は、外部ユーザーにとって高可用性が失われたことです。 しかし、その時点では問題をすぐに解決する必要があったため、これを犠牲にしなければなりませんでした。 そこで、負荷の一部を削除しました。当時は約 45% でしたが、LTM の感触は良好で、問題が発生してから文字通り 55 週間後には、20 秒あたり XNUMX リクエストではなく、XNUMX リクエストを送信し始めました。 実際、XNUMX% 増加しました。これは明らかに、ユーザーに提供しなかったトラフィックです。 そしてその後、彼らは残りの問題を解決する方法、つまり外部からの高いアクセス性を確保する方法について考え始めました。

私たちは少し休憩し、その間にこれにどのようなソリューションを使用するかを話し合いました。 DNS、独自スクリプト、動的ルーティング プロトコルを使用して信頼性を確保するという提案がありました...多くのオプションがありましたが、本当に信頼性の高い写真配信のためには、これを監視する別のレイヤーを導入する必要があることがすでに明らかになりました。 。 私たちはこれらの機械をフォトディレクターと呼びました。 私たちが依存したソフトウェアは Keepalived でした。

そもそも Keepalived とは何で構成されているのでしょうか? XNUMX つ目は、ネットワーカーに広く知られている VRRP プロトコルで、クライアントが接続する外部 IP アドレスにフォールト トレランスを提供するネットワーク機器上にあります。 XNUMX 番目の部分は、フォト ルーター間のバランスをとり、このレベルでのフォールト トレランスを確保するための IPVS (IP 仮想サーバー) です。 そしてXNUMX番目は健康診断です。

最初の部分から始めましょう: VRRP - それはどのようなものですか? 特定の仮想 IP があり、クライアントが接続する DNS badoocdn.com にエントリがあります。 ある時点で、XNUMX つのサーバー上に IP アドレスが存在します。 キープアライブ パケットは VRRP プロトコルを使用してサーバー間で実行され、マスターがレーダーから消えた場合 (サーバーが再起動されたかその他の理由で)、バックアップ サーバーが自動的にこの IP アドレスを取得します。手動によるアクションは必要ありません。 マスターとバックアップの違いは主に優先順位です。優先順位が高いほど、マシンがマスターになる可能性が高くなります。 非常に大きな利点は、サーバー自体に IP アドレスを設定する必要がないことです。設定に IP アドレスを記述するだけで十分です。また、IP アドレスにカスタム ルーティング ルールが必要な場合は、次のコマンドを使用して、設定に直接記述されます。 VRRP パッケージで説明されているものと同じ構文です。 未知のものに遭遇することはありません。

これは実際にはどのように見えるのでしょうか? いずれかのサーバーに障害が発生した場合はどうなりますか? マスターが消えるとすぐに、バックアップはアドバタイズメントの受信を停止し、自動的にマスターになります。 しばらくして、マスターを修復し、再起動し、Keepalived を起動しました。アドバタイズメントはバックアップよりも高い優先順位で到着し、バックアップは自動的に元に戻り、IP アドレスが削除されるため、手動でのアクションを行う必要はありません。

これにより、外部 IP アドレスの耐障害性が確保されました。 次の部分は、外部 IP アドレスから、すでに終端しているフォト ルーターへのトラフィックのバランスを何らかの方法で調整することです。 バランシングプロトコルを使用すると、すべてが非常に明確になります。 これは単純なラウンドロビンか、もう少し複雑なもの (wrr、リスト接続など) です。 これは基本的にドキュメントに記載されており、特別なことは何もありません。 しかし、配送方法は... ここでは、そのうちの 100 つを選んだ理由を詳しく見ていきます。 これらは、NAT、ダイレクト ルーティング、および TUN です。 実際、私たちはすぐにサイトから 10 ギガビットのトラフィックを配信する計画を立てました。 計算するとギガビットカードが10枚必要になりますよね？ XNUMX 台のサーバーに XNUMX ギガビット カードを搭載することは、少なくとも当社の「標準装備」の概念の範囲をすでに超えています。 そして、私たちはトラフィックを提供するだけではなく、写真も提供していることを思い出しました。

何が特別ですか？ — 受信トラフィックと送信トラフィックの間に大きな違いがあります。 受信トラフィックは非常に小さく、送信トラフィックは非常に大きくなります。

これらのグラフを見ると、現時点でディレクターが 200 秒あたり約 4,500 MB を受信して​​いることがわかりますが、これはごく普通の日です。 1 秒あたり 22 MB を返します。比率は約 22/XNUMX です。 XNUMX 個のワーカー サーバーに送信トラフィックを完全に提供するには、この接続を受け入れる XNUMX 台だけが必要であることはすでに明らかです。 ここで、ダイレクト ルーティング アルゴリズムが役に立ちます。

それはどのように見えますか？ 私たちのフォト ディレクターは、彼のテーブルに従って、接続をフォト ルーターに送信します。 しかし、フォト ルーターはリターン トラフィックをインターネットに直接送信し、クライアントに送信します。トラフィックはフォト ディレクターを経由せずに戻されるため、最小限のマシン数で完全​​なフォールト トレランスとすべてのトラフィックのポンピングを保証します。 設定では次のようになります。アルゴリズムを指定し、この場合は単純な rr で、直接ルーティング方法を提供し、すべての実サーバーとその数のリストを開始します。 これがこのトラフィックを決定します。 さらに XNUMX つまたは XNUMX つ、または複数のサーバーがある場合、そのような必要性が生じます。このセクションを構成に追加するだけで、あまり心配する必要はありません。 実サーバー側、フォトルーター側から見ると、この方法には最小限の構成が必要であり、ドキュメントに完全に説明されており、落とし穴はありません。

特に優れているのは、このようなソリューションがローカル ネットワークの根本的な再設計を意味しないことです。これは私たちにとって重要でした。最小限のコストでこれを解決する必要がありました。 見てみると IPVS 管理コマンドの出力, 次に、それがどのようになるかを見てみましょう。 ここでは、特定の仮想サーバーがポート 443 上でリッスンし、接続を受け入れます。動作中のサーバーがすべてリストされており、接続が多少なりとも同じであることがわかります。 同じ仮想サーバーの統計を見ると、受信パケットや受信接続はありますが、送信パケットはまったくありません。 発信接続はクライアントに直接送信されます。 さて、バランスを崩すことができました。 さて、フォト ルーターの XNUMX つが故障したらどうなるでしょうか? やっぱり鉄は鉄ですね。 カーネルパニックに陥ったり、壊れたり、電源が切れたりする可能性があります。 何でも。 だからこそ健康診断が必要なのです。 ポートがどのように開いているかを確認するなどの単純なものもあれば、ビジネス ロジックをチェックする独自のスクリプトに至るまでのより複雑なものもあります。

私たちは途中で停止しました。特定の場所への https リクエストがあり、スクリプトが呼び出され、200 番目のレスポンスで応答した場合、このサーバーはすべて正常であり、生きていて完全にオンにできると考えられます。簡単に。

これも実際にはどうなるでしょうか? BIOS のフラッシュなど、メンテナンスのためにサーバーの電源を切りましょう。 ログではすぐにタイムアウトが発生し、最初の行が表示されます。その後、XNUMX 回の試行後に「失敗」とマークされ、単純にリストから削除されます。

VS を単純にゼロに設定する XNUMX 番目の動作オプションも可能ですが、写真が返された場合、これはうまく機能しません。 サーバーが起動すると、Nginx が起動し、ヘルスチェックは接続が機能していること、すべてが正常であることをすぐに認識し、サーバーがリストに表示され、すぐに負荷が適用され始めます。 職務管理者による手動のアクションは必要ありません。 サーバーが夜間に再起動されました。監視部門からは夜間にこの件について電話がありません。 彼らは、これが起こった、すべてが順調であることをあなたに知らせます。

そこで、少数のサーバーを利用する非常に簡単な方法で、外部フォールト トレランスの問題を解決しました。

ここで言えることは、もちろん、これらすべてを監視する必要があるということだけです。 これとは別に、Keepalivede はずっと前に書かれたソフトウェアであり、DBus、SMTP、SNMP、および標準の Zabbix によるチェックを使用して、それを監視するための多くの方法を備えていることに注意する必要があります。 さらに、彼自身、ほぼすべてのくしゃみに対して手紙を書く方法を知っています。正直に言うと、ある時点で私たちはそれをオフにしようとさえ考えました。なぜなら、彼はあらゆるトラフィックの切り替え、スイッチのオン、すべての IP 接続、等々 。 もちろん、サーバーの数が多い場合は、これらの文字で圧倒されてしまう可能性があります。 私たちは標準的な方法を使用してフォトルーター上のnginxを監視していますが、ハードウェア監視がなくなったわけではありません。 もちろん、さらに XNUMX つのことをお勧めします。XNUMX つ目は、外部のヘルスチェックと可用性です。すべてが機能したとしても、実際には、外部プロバイダーの問題や、より複雑な何かが原因でユーザーが写真を受信できない可能性があるためです。 別のネットワーク、Amazon などのどこかに、外部からサーバーに ping できる別個のマシンを置いておく価値は常にあります。また、難しい機械学習の方法を知っている人向けの異常検出や、単純な監視を使用する価値もあります。少なくとも、リクエストが急激に減少したか、あるいは逆に増加したかを追跡するために。 役に立つこともあります。

要約しましょう。実際、私たちは、ある時点で私たちに合わなくなった鉄壁のソリューションを、すべて同じことを行う非常にシンプルなシステムに置き換えました。つまり、HTTPS トラフィックの終端と、必要な健康診断。 このシステムの安定性が向上しました。つまり、各レイヤーの高可用性が維持されています。さらに、標準のハードウェアと標準のソフトウェアが使用されているため、各レイヤーですべてを拡張するのが非常に簡単であるという利点もあります。 、考えられる問題の診断を簡素化しました。

結局私たちはどうなったのでしょうか？ 2018年の40月の連休中に問題が発生しました。 このスキームを運用し始めた最初の 60 か月間で、LTM からすべてのトラフィックを削除するために、すべてのトラフィックに拡張しました。2018 つのデータ センターのトラフィックのみが XNUMX ギガビットから XNUMX ギガビットに増加しました。 XNUMX 年全体では、XNUMX 秒あたりほぼ XNUMX 倍の写真を送信できました。

出所： habr.com