Badoo で写真を保存および共有するためのアーキテクチャ

アルテム・デニソフ（ bo0rsh201, Badooメンバー中)

Badoo は世界最大の出会い系サイトです。 現在、世界中で約 330 億 3 万人の登録ユーザーがいます。 しかし、今日の会話の文脈においてはるかに重要なことは、私たちが約 3,5 ペタバイトのユーザー写真を保存しているということです。 毎日、ユーザーは約 XNUMX 万枚の新しい写真をアップロードし、読み取り負荷は約 80 秒あたり XNUMX リクエスト。 これはバックエンドにとってはかなりの量であり、これによって問題が発生する場合があります。

一般的に写真を保存して送信するこのシステムの設計について、開発者の観点から見ていきます。 どのように発展したかについて簡単に振り返り、主なマイルストーンについて概説しますが、現在使用しているソリューションについてのみ詳しく説明します。

さあ始めましょう。

先ほども言ったように、これは振り返りになりますが、どこかで始めるために、最も一般的な例を見てみましょう。

私たちには共通のタスクがあり、ユーザーの写真を受け入れ、保存し、送信する必要があります。 この形式では、タスクは一般的なものであり、何でも使用できます。

• 最新のクラウドストレージ、
• ボックス化されたソリューション。今ではこれもたくさんあります。
• データセンターに複数のマシンをセットアップし、それらに大容量のハードドライブを設置して、そこに写真を保存することができます。

Badoo は歴史的に、今も昔も (初期段階にあった頃も)、独自の DC 内の独自のサーバー上に存在しています。 したがって、このオプションは私たちにとって最適でした。

いくつかのマシンを「写真」と呼ぶだけで、写真を保存するクラスターが得られました。 しかし、何かが足りないようです。 これらすべてを機能させるには、どのマシンにどの写真を保存するかを何らかの方法で決定する必要があります。 そしてここでもアメリカを開く必要はない。

ユーザーに関する情報を含むフィールドをストレージに追加します。 これがシャーディングキーになります。 この例では、これを place_id と呼び、この場所 ID はユーザーの写真が保存されている場所を指します。 私たちは地図を作ります。

最初の段階では、これは手動で行うこともできます。そのような場所にいるこのユーザーの写真がそのようなサーバーに到達すると言います。 このマップのおかげで、ユーザーがいつ写真をアップロードするか、どこに保存するか、そしてどこから写真を提供するかを常に知ることができます。

これはまったく簡単なスキームですが、非常に重要な利点があります。 XNUMX つ目は、先ほども述べたようにシンプルであること、XNUMX つ目は、このアプローチを使用すると、新しい車を納入してマップに追加するだけで簡単に水平方向に拡張できることです。 他に何もする必要はありません。

しばらくの間、私たちもそうでした。

これは2009年頃のことでした。 彼らは車を配達し、配達しました...

そしてある時点から、この計画にはいくつかの欠点があることに気づき始めました。 デメリットは何ですか?

まず、容量に限りがあります。 XNUMX 台の物理サーバーに必要な数のハード ドライブを詰め込むことはできません。 そして、これは時間の経過とデータセットの増大に伴って、ある種の問題になってきました。

そしてXNUMX番目。 このようなマシンは他のクラスターで再利用するのが難しく、非常に特殊であるため、これはマシンの特殊な構成です。 パフォーマンスは低いはずですが、同時に大容量のハードドライブが必要です。

これはすべて 2009 年のものですが、原則として、これらの要件は現在でも当てはまります。 回顧展があるので、2009 年はこれですべてが完全に最悪でした。

そして最後のポイントは価格です。

当時は価格が非常に高かったため、代替品を探す必要がありました。 それらの。 データセンター内のスペースと、これらすべてが配置されている物理サーバーの両方を、何らかの方法でより有効に活用する必要がありました。 そして、当社のシステム エンジニアは、さまざまなオプションを検討する大規模な調査を開始しました。 また、PolyCeph や Lustre などのクラスター化ファイル システムも調査しました。 パフォーマンス上の問題があり、操作が非常に困難でした。 彼らは拒否した。 何とかスケールアップするために、NFS 経由でデータセット全体を各車にマウントしようとしました。 読み取りもうまくいかなかったので、さまざまなベンダーのさまざまなソリューションを試しました。

そして最終的には、いわゆるストレージ エリア ネットワークを使用することに落ち着きました。

これらは、大量のデータを保存するために特別に設計された大規模な SHD です。 これらは、最終的な光出力マシンに取り付けられるディスクを備えた棚です。 それ。 非常に小さい、ある種のマシンのプールと、送信ロジックに対して透過的なこれらの SHD があります。 私たちの nginx または他の誰かがこれらの写真のリクエストを処理できるようにします。

この決定には明らかな利点がありました。 SHDです。 写真の保存を目的としています。 これは、単にマシンにハードドライブを装備するよりも安く済みます。

XNUMX番目のプラス。

これは容量が大幅に大きくなったということです。 はるかに小さな体積で、はるかに多くのストレージを収容できます。

しかし、すぐに現れる欠点もありました。 ユーザーの数とこのシステムの負荷が増加するにつれて、パフォーマンスの問題が発生し始めました。 そして、ここでの問題は非常に明白です。多くの写真を少量に保存するように設計された SHD は、原則として、集中的な読み取りに悩まされます。 これは実際、クラウド ストレージでもその他のものでも当てはまります。 現在、無限に拡張可能で、何でも詰め込むことができ、読み取りに非常に耐えられる理想的なストレージは存在しません。 特にカジュアルな読書。

写真の場合と同様、写真のリクエストには一貫性がなく、パフォーマンスに大きな影響を与えます。

現在の数字によれば、ストレージが接続されているマシン上の写真で 500 RPS を超えると、すでに問題が発生し始めています。 ユーザー数は増え続けており、状況はさらに悪化する一方なので、これは私たちにとって十分に悪いことでした。 これは何らかの方法で最適化する必要があります。

最適化するために、その時点で、負荷プロファイル、つまり一般に何が起こっているのか、何を最適化する必要があるのか​​を確認することにしました。

そしてここではすべてが私たちの手の中にあります。

最初のスライドですでに述べましたが、80 秒あたり 3,5 万件の読み取りリクエストがあり、XNUMX 日あたりのアップロードはわずか XNUMX 万件です。 つまり、これはXNUMX桁の差です。 読み取りを最適化する必要があることは明らかであり、その方法も事実上明らかです。

もう一つ小さな点があります。 サービスの詳細は、人が登録して写真をアップロードすると、他の人を積極的に見て「いいね」をし始め、積極的に他の人に見せられるというものです。 その後、相手が見つかるか見つからないかは結果次第で、しばらくサービスの使用を中止します。 現時点では、彼がそれを使用すると、彼の写真は非常に人気があり、多くの人がそれらを閲覧します。 これをやめるとすぐに、以前のように他の人にさらされることはなくなり、写真を要求されることもほとんどなくなりました。

それらの。 非常に小規模なホット データセットがあります。 しかし同時に、彼に対する多くの要求もあります。 ここでの完全に明白な解決策は、キャッシュを追加することです。

LRU を使用したキャッシュはすべての問題を解決します。 私たちは何をしているのでしょうか？

ストレージを備えた大きなクラスターの前に、フォトキャッシュと呼ばれる比較的小さなクラスターをもう XNUMX つ追加します。 これは本質的には単なるキャッシング プロキシです。

内部からはどのように機能するのでしょうか？ ここがユーザー、ここがストレージです。 すべては以前と同じです。 間に何を追加しますか?

これは、高速な物理ローカル ディスクを備えた単なるマシンです。 これは、たとえば SSD の場合です。 そして、ある種のローカル キャッシュがこのディスクに保存されます。

それはどのように見えますか？ ユーザーが写真のリクエストを送信します。 NGINX は、まずローカル キャッシュ内でそれを探します。 そうでない場合は、単純にストレージに proxy_pass し、そこから写真をダウンロードしてユーザーに渡します。

しかし、これは非常に平凡で、内部で何が起こっているのかは不明です。 それは次のように機能します。

キャッシュは論理的に XNUMX つの層に分割されます。 私が「三層」と言うとき、これはある種の複雑なシステムがあるという意味ではありません。 いいえ、これらは条件付きでファイル システム内の XNUMX つのディレクトリにすぎません。

1. これは、プロキシからダウンロードされたばかりの写真が保存されるバッファです。
2. これは、現在アクティブにリクエストされている写真を保存するホット キャッシュです。
3. また、コールド キャッシュでは、写真に対するリクエストが少なくなると、写真が徐々にホット キャッシュから追い出されます。

これを機能させるには、このキャッシュを何らかの方法で管理したり、キャッシュ内の写真を並べ替えたりする必要があります。 これも非常に原始的なプロセスです。

Nginx はリクエストごとに RAMDisk access.log に単純に書き込みます。このログには、現在提供されている写真へのパス (もちろん相対パス) と、どのパーティションが提供されているかが示されます。 それらの。 「写真 1」と表示され、次にバッファ、ホット キャッシュ、コールド キャッシュ、またはプロキシのいずれかが表示される場合があります。

これに応じて、写真をどうするかを何らかの方法で決定する必要があります。

各マシン上で実行される小さなデーモンが常にこのログを読み取り、特定の写真の使用に関する統計をメモリに保存します。

彼はただそこに集まり、カウンターを維持し、定期的に次のことを行います。 彼は、リクエストの多い積極的にリクエストされた写真を、その場所に関係なくホット キャッシュに移動します。

めったにリクエストされず、あまり頻繁にリクエストされなくなった写真は、ホット キャッシュからコールド キャッシュに徐々に押し出されます。

そして、キャッシュ内のスペースが足りなくなると、コールド キャッシュからすべてを無差別に削除し始めます。 ちなみに、これはうまく機能します。

写真をバッファにプロキシするときにすぐに保存するには、proxy_store ディレクティブを使用し、バッファも RAMDisk にします。 ユーザーにとっては非常に迅速に機能します。 これは、キャッシュ サーバー自体の内部に関係します。

残りの問題は、これらのサーバー間でリクエストをどのように分散するかです。

XNUMX 台のストレージ マシンと XNUMX 台のキャッシュ サーバーからなるクラスターがあるとします (これが実際に起こった経緯です)。

どのリクエストがどの写真に対するもので、それをどこに送信するかを何らかの方法で判断する必要があります。

最も一般的なオプションはラウンド ロビンです。 それとも偶然ですか？

このような状況ではキャッシュを非常に非効率的に使用することになるため、これには明らかに多くの欠点があります。 リクエストはいくつかのランダムなマシンに到達します。ここではリクエストはキャッシュされていましたが、次のマシンではもう存在しません。 そして、これがすべてうまくいけば、それは非常に悪いことになります。 クラスター内のマシンの数が少ない場合でも。

どのサーバーにどのリクエストを送信するかを何らかの方法で明確に決定する必要があります。

平凡な方法があります。 URL からハッシュを取得するか、URL に含まれるシャーディング キーからハッシュを取得し、それをサーバーの数で割ります。 働くでしょう？ 意思。

それらの。 たとえば、一部の「example_url」については、リクエストは常にインデックス「2」でサーバーに到達し、キャッシュは常に可能な限り最適に破棄されます。

しかし、このようなスキームでのリシャーディングには問題があります。 リシャーディング - サーバーの数を変更することを意味します。

キャッシュ クラスターが対応できなくなったため、別のマシンを追加することにしたとします。

付け加えてみましょう。

これで、すべては XNUMX ではなく XNUMX で割り切れます。 したがって、私たちが以前持っていたほぼすべてのキー、ほぼすべての URL は現在、他のサーバー上に存在しています。 キャッシュ全体がほんの一瞬だけ無効になりました。 すべてのリクエストがストレージ クラスターに集中し、クラスターの状態が悪くなり、サービス障害が発生し、ユーザーは不満を抱きました。 そんなことはしたくない。

この選択肢も我々には合わない。

それ。 私たちは何をすべきか？ 何らかの方法でキャッシュを効率的に使用し、同じリクエストを同じサーバーに何度も送信する必要がありますが、リシャーディングには耐性を持たせる必要があります。 そして、そのような解決策はありますが、それはそれほど複雑ではありません。 それはコンシステントハッシュと呼ばれます。

それはどのように見えますか？

シャーディング キーから何らかの関数を取得し、そのすべての値をサークル上に展開します。 それらの。 点 0 では、その最小値と最大値は収束します。 次に、ほぼ次の方法ですべてのサーバーを同じ円上に配置します。

各サーバーは 2 つのポイントによって定義され、それに応じて時計回りに向かうセクターがこのホストによってサービスを受けます。 リクエストが届くと、たとえば、リクエスト A - そこにハッシュがあり、それがサーバー 3 によって処理されることがすぐにわかります。リクエスト B - サーバー XNUMX によって処理される、というようになります。

この状況でリシャーディング中に何が起こるでしょうか?

以前のようにキャッシュ全体を無効にしたり、すべてのキーをシフトしたりはしませんが、追加したい XNUMX 番目のサーバーが空きスペースに収まるように、各セクターを短い距離だけシフトします。そこに追加します。

もちろん、そのような状況ではキーも動きます。 しかし、彼らは以前よりもはるかに弱く動きます。 そして、最初の XNUMX つのキーはサーバー上に残り、キャッシュ サーバーは最後のキーについてのみ変更されたことがわかります。 これは非常に効率的に機能し、新しいホストを段階的に追加する場合、大きな問題はありません。 一度に少しずつ追加し、キャッシュが再びいっぱいになるまで待つと、すべてが正常に動作します。

拒否に関して唯一の疑問が残ります。 ある種の車が故障したと仮定しましょう。

また、たとえばマシンが再起動され、何らかの方法でリクエストに対応する必要がある場合、現時点ではこのマップを再生成したり、キャッシュの一部を無効にしたりすることは実際には望ましくありません。 各サイトに XNUMX つのバックアップ写真キャッシュを保持するだけで、現在ダウンしているマシンの代替として機能します。 そして、サーバーの XNUMX つが突然利用できなくなると、トラフィックはそこに流れます。 当然のことながら、そこにはキャッシュはありません。 寒いですが、少なくともユーザーのリクエストは処理されています。 これが短い間隔であれば、私たちはそれを完全に穏やかに経験します。 ストレージの負荷が増えるだけです。 この間隔が長い場合は、このサーバーをマップから削除するかどうか、あるいは別のサーバーに置き換えるかどうかをすでに決定できます。

今回はキャッシングシステムについてです。 結果を見てみましょう。

ここには何も複雑なことはないようです。 しかし、このキャッシュ管理方法により、約 98% のトリック率が得られました。 それらの。 毎秒 80 件のリクエストのうち、ストレージに到達するのは 1600 件だけです。これは完全に通常の負荷であり、彼らは静かに耐えます。私たちは常に予備を持っています。

これらのサーバーを XNUMX つの DC に配置し、プラハ、マイアミ、香港の XNUMX つの拠点を受け取りました。

それ。 彼らは多かれ少なかれ、私たちのターゲット市場のそれぞれにローカルに位置しています。

そして嬉しいおまけとして、このキャッシュ プロキシを入手しました。このキャッシュ プロキシでは、コンテンツの提供にはそれほど必要がないため、CPU は実際にはアイドル状態になっています。 そこで、NGINX+ Lua を使用して、多くの実用的なロジックを実装しました。

たとえば、webp またはプログレッシブ jpeg (これらは効果的な最新形式です) を試し、それがトラフィックにどのように影響するかを確認し、何らかの決定を下し、特定の国で有効にするなどできます。 写真を動的にサイズ変更したり、その場でトリミングしたりできます。

これは、たとえば、写真を表示するモバイル アプリケーションがあり、そのモバイル アプリケーションが大きな写真をリクエストし、それをプッシュするために特定のサイズにサイズ変更することでクライアントの CPU を浪費したくない場合に、これは良い使用例です。景色。 UPort 条件付き URL でいくつかのパラメーターを動的に指定するだけで、写真キャッシュによって写真自体のサイズが変更されます。 原則として、要求されたサイズにできるだけ近い、ディスク上に物理的に存在するサイズが選択され、特定の座標でダウンセルされます。

ちなみに、過去XNUMX年間の高負荷システム開発者会議の録画映像を公開しています。 HighLoad ++。 見て、学び、共有し、購読する YouTubeチャンネル.

そこに多くの製品ロジックを追加することもできます。 たとえば、URL パラメーターを使用してさまざまな透かしを追加したり、写真をぼかしたり、ぼかしたり、ピクセル化したりできます。 これは、人の写真を表示したいが、顔は表示したくないときです。これはうまく機能し、すべてここで実装されています。

何が得られたでしょうか？ XNUMX つのプレゼンス ポイントと良好なトリック率を獲得し、同時にこれらのマシンにはアイドル状態の CPU がありません。 もちろん、彼は今では以前よりも重要になっています。 私たちはより強力な車を自分たちに提供する必要がありますが、それだけの価値はあります。

写真の返却についてです。 ここにあるものはすべて非常に明確で明白です。 私はアメリカを発見しなかったと思います。ほとんどすべての CDN がこのように機能します。

そして、おそらく、洗練されたリスナーは「なぜすべてを CDN に変更すればよいのでしょうか?」という疑問を持つかもしれません。 これはほぼ同じであり、最新の CDN はすべてこれを実行できます。 理由はいくつかあります。

一つ目は写真です。

これはインフラストラクチャの重要なポイントの XNUMX つであり、これを可能な限り制御する必要があります。 これがサードパーティ ベンダーによる何らかのソリューションであり、それを制御する権限がない場合、大規模なデータセットがあり、非常に大規模なフローがある場合、それを使用するのは非常に困難になります。ユーザーリクエストの数。

例を挙げてみましょう。 現在、私たちのインフラストラクチャのおかげで、たとえば、何らかの問題が発生したり、地下でのノックが発生したりした場合に、比較的言えば、機械のところに行ってそこで混乱を起こすことができます。 必要なだけのメトリクスのコレクションを追加したり、何らかの方法で実験したり、これがグラフにどのような影響を与えるかを確認したりできます。 現在、このキャッシュ クラスターで多くの統計が収集されています。 そして私たちは定期的にそれを調べ、いくつかの異常を調査するために長い時間を費やしています。 CDN 側にある場合は、制御がはるかに困難になるでしょう。 あるいは、たとえば、ある種の事故が発生した場合、私たちは何が起こったのかを知っており、それをどのように受け止め、どのように克服するかを知っています。 これが第一の結論です。

XNUMX 番目の結論もかなり歴史的なものです。システムは長い間開発されており、さまざまな段階で多くの異なるビジネス要件があり、それらは必ずしも CDN の概念に適合するとは限りません。

そして、前回から続くポイントは、

これは、写真キャッシュには多くの特定のロジックがあり、リクエストに応じて常に追加できるわけではないためです。 CDN がユーザーの要求に応じてカスタム機能を追加する可能性はほとんどありません。 たとえば、クライアントが何かを変更できないようにする場合は、URL を暗号化します。 サーバー上の URL を変更して暗号化し、ここでいくつかの動的パラメーターを送信しますか。

これはどのような結論を示唆していますか? 私たちの場合、CDN はあまり良い代替手段ではありません。

そしてあなたの場合、特定のビジネス要件がある場合は、私が示したものを自分で簡単に実装できます。 これは、同様の負荷プロファイルでも完全に機能します。

ただし、何らかの一般的な解決策があり、タスクがそれほど具体的ではない場合は、絶対に安全に CDN を使用できます。 または、時間とリソースがコントロールよりも重要である場合。

そして、最新の CDN には、今説明したほとんどすべての機能が含まれています。 プラスまたはマイナスの一部の機能を除きます。

写真のプレゼントについてです。

ここで振り返りを少し進めて、ストレージについて話しましょう。

2013年が過ぎていきました。

キャッシュ サーバーが追加され、パフォーマンスの問題は解消されました。 すべて順調。 データセットは増加しています。 2013 年の時点で、約 80 台のサーバーがストレージに接続されており、各 DC には約 40 台のキャッシュ サーバーがありました。 これは、各 DC 上の 560 テラバイトのデータです。 合計で約ペタバイト。

そして、データセットの増大に伴い、運用コストが大幅に上昇し始めました。 これはどういう意味でしょうか？

SAN とそれに接続されたマシンとキャッシュを使用して描かれたこの図には、多くの障害点があります。 以前にキャッシュサーバーの障害にすでに対処していれば、すべてが多かれ少なかれ予測可能で理解可能でしたが、ストレージ側ではすべてがさらに悪化しました。

まず、ストレージ エリア ネットワーク (SAN) 自体に障害が発生する可能性があります。

次に、光学系を介してエンドマシンに接続されます。 光カードと点火プラグに問題がある可能性があります。

もちろん、それらの数は SAN 自体ほど多くはありませんが、それでも、これらは障害点でもあります。

次に、ストレージに接続されているマシン自体です。 失敗することもあります。

合計で XNUMX つの障害点があります。

さらに、障害点に加えて、ストレージ自体にも多大なメンテナンスが必要になります。

これは複雑な複数のコンポーネントからなるシステムであり、システム エンジニアはこれを扱うのが難しい場合があります。

そして最後の、最も重要な点です。 これら XNUMX つのポイントのいずれかで障害が発生した場合、ファイル システムがクラッシュする可能性があるため、ユーザー データが失われる可能性がゼロではありません。

ファイルシステムが壊れたとしましょう。 まず、回復には時間がかかります。大量のデータの場合は XNUMX 週間かかる場合もあります。 そして第二に、最終的には理解できないファイルの束ができあがり、何らかの方法でユーザーの写真に結合する必要があることになります。 そしてデータを失う危険もあります。 リスクはかなり高いです。 そして、そのような状況が頻繁に起こるほど、そしてこの連鎖全体でより多くの問題が発生するほど、このリスクは高まります。

これについては何かをしなければなりませんでした。 そして、データをバックアップするだけで十分だと判断しました。 これは実際には明白な解決策であり、良い解決策です。 私たちが何をしてしまったのでしょうか？

これは、以前にサーバーがストレージに接続されていたときの様子です。 これは主要なセクションの XNUMX つであり、実際には光を介したリモート ストレージのマウントを表す単なるブロック デバイスです。

XNUMX 番目のセクションを追加しました。

私たちはその隣に XNUMX 番目のストレージを配置し (幸いなことに、金額的にはそれほど高価ではありません)、それをバックアップ パーティションと呼びました。 これも光学系を介して接続されており、同じマシン上にあります。 ただし、何らかの方法でそれらの間でデータを同期する必要があります。

ここでは、近くに非同期キューを作成するだけです。

彼女はあまり忙しくありません。 十分な記録がないことは承知しています。 キューとは、「この写真をバックアップする必要があります」のような行が書き込まれる MySQL の単なるテーブルです。 変更またはアップロードを行うと、メイン パーティションからバックアップに非同期的に、または単にある種のバックグラウンド ワーカーによってコピーされます。

したがって、常に XNUMX つの一貫したセクションが存在します。 このシステムの一部に障害が発生した場合でも、バックアップを使用してメイン パーティションをいつでも変更でき、すべてが引き続き動作します。

しかし、そのせいで読み込み負荷が大幅に増加してしまうのです…。 メインセクションから読むクライアントに加えて、最初にそこにある写真を見て（より新しいものです）、見つからなかった場合はバックアップから探します（ただし、NGINX がこれを行うだけです）。私たちのシステムは、バックアップもメイン パーティションから読み取るようになりました。 それがボトルネックだったというわけではないのですが、本質的には負荷を増やしたくなかったので。

そして、XNUMX 番目のディスク (小型 SSD) を追加し、それをバッファーと呼びました。

現在の仕組み。

ユーザーが写真をバッファにアップロードすると、写真を XNUMX つのセクションにコピーする必要があることを示すイベントがキューにスローされます。 写真はコピーされ、しばらくの間 (たとえば XNUMX 日) バッファ上に存在し、その後、そこから削除されます。 これにより、ユーザーが写真をアップロードすると、原則としてリクエストがすぐに開始されたり、ユーザー自身がページを更新して更新したりするため、ユーザー エクスペリエンスが大幅に向上します。 ただし、それはすべてアップロードを行うアプリケーションによって異なります。

または、たとえば、彼が自分自身を見せ始めた他の人が、この写真の後にすぐにリクエストを送信します。 まだキャッシュにないため、最初のリクエストはすぐに発生します。 基本的には写真キャッシュからの場合と同じです。 低速ストレージはこれにはまったく関係ありません。 そして XNUMX 日後にデータが消去されると、そのデータはすでにキャッシュ レイヤーにキャッシュされているか、おそらく誰も必要としなくなっています。 それらの。 このような簡単な操作により、ユーザー エクスペリエンスは非常に向上しました。

そして最も重要なことは、データの損失がなくなったことです。

やめたとしましょう 潜在的に 実際にデータを失ったわけではないので、データは失われます。 しかし、危険もあった。 もちろん、この解決策が優れていることはわかりますが、問題を完全に解決するのではなく、問題の症状を和らげるようなものです。 そしてここにはいくつかの問題が残っています。

まず、これはすべての機械が動作する物理ホスト自体の障害点であり、まだ解消されていません。

第 XNUMX に、SAN には依然として問題があり、その重労働なメンテナンスなどが残っています。 それが決定的な要素だったわけではありませんが、なんとかそれなしで生きていきたいと思いました。

そして私たちは XNUMX 番目のバージョン (実際には XNUMX 番目)、つまり予約バージョンを作成しました。 それはどのように見えましたか？

それはこういうことだった -

私たちの主な問題は、これが物理ホストであるという事実にあります。

まず、実験したいため、ローカル ハード ドライブだけを試したいので、SAN を削除しています。

これはすでに 2014 年から 2015 年にかけてのことであり、その時点で、XNUMX つのホスト内のディスクとその容量の状況ははるかに改善されました。 私たちはそれを試してみることにしました。

そして、バックアップ パーティションを取得し、それを別のマシンに物理的に転送するだけです。

したがって、この図が得られます。 同じデータセットを保存する XNUMX 台の車があります。 これらは相互に完全にバックアップし、同じ MySQL 内の非同期キューを介してネットワーク上でデータを同期します。

なぜこれがうまくいくかというと、記録が少ないからです。 それらの。 もし書き込みが読み取りと同等であれば、おそらく何らかのネットワークのオーバーヘッドや問題が発生するでしょう。 書くことはほとんどなく、読むことはたくさんあります - この方法はうまく機能します。 これら XNUMX つのサーバー間で写真をコピーすることはほとんどありません。

もう少し詳しく見てみると、これはどのように機能するのでしょうか。

アップロード。 バランサーは、ペアを持つランダムなホストを選択し、そこにアップロードするだけです。 同時に健康診断も当然行い、車が落ちていないか確認する。 それらの。 彼はライブサーバーにのみ写真をアップロードし、非同期キューを介してすべての写真を隣人にコピーします。 アップロードを使用すると、すべてが非常に簡単になります。

タスクは少し難しくなります。

バニラの NGINX ではそのようなロジックを作成するのは難しい場合があるため、ここでは Lua が役に立ちました。 まず最初のサーバーにリクエストを出し、そこに写真があるかどうかを確認します。これは、写真がたとえば近隣にアップロードされる可能性があるためですが、まだここには到着していません。 写真があれば大丈夫です。 それをすぐにクライアントに渡し、場合によってはキャッシュします。

そこにない場合は、隣人にリクエストを行うだけで、そこから確実に受け取ることができます。

それ。 もう一度言えます。往復が絶え間なく行われるため、パフォーマンスに問題がある可能性があります。写真はアップロードされましたが、ここにはありません。XNUMX つではなく XNUMX つのリクエストを行っています。これはゆっくりと動作するはずです。

私たちの状況では、これはゆっくりと機能しません。

私たちはこのシステムで大量のメトリクスを収集しており、このようなメカニズムの条件付きスマート率は約 95% です。 それらの。 このバックアップの遅延は小さく、このため、写真がアップロードされた後、ほぼ確実に最初にバックアップを取得し、どこにも XNUMX 回移動する必要はありません。

では、本当にクールなものは他に何があるでしょうか?

以前は、メインのバックアップ パーティションがあり、そこから順次読み取りを行っていました。 それらの。 私たちは常に最初にメインのファイルを検索し、次にバックアップを検索しました。 それは一つの動きだった。

現在、XNUMX 台のマシンからの読み取りを同時に利用しています。 ラウンドロビンを使用してリクエストを分散します。 ごく一部のケースでは、XNUMX つのリクエストが行われます。 しかし、全体としては、以前の XNUMX 倍の読書ストックがあるようになりました。 また、送信マシンと、当時私たちが使用していたストレージ マシンの両方の負荷が大幅に軽減されました。

フォールトトレランスに関しては。 実際、これが私たちが主に戦った目的です。 耐障害性により、ここではすべてがうまくいきました。

一台の車が故障する。

問題ない！ システムエンジニアは夜にさえ起きないかもしれませんが、朝まで待っても何も悪いことは起こりません。

このマシンに障害が発生しても、キューが故障していても問題はありません。ログは、最初に生きているマシンに蓄積され、次にキューに追加され、次に再起動される車両に追加されます。しばらくしてから運用開始。

メンテナンスも同様です。 マシンの XNUMX 台の電源を切り、すべてのプールから手動で引き出します。トラフィックの受信を停止し、何らかのメンテナンスを行い、何かを編集してからサービスに戻すと、このバックアップは非常に早く追いつきます。 それらの。 XNUMX 日あたり XNUMX 台の車のダウンタイムは数分以内に追いつきます。 これは本当にごくわずかです。 フォールト トレランスでは、ここではすべてが優れています。

この冗長性スキームからどのような結論が得られるでしょうか?

フォールトトレランスを実現しました。

使いやすい。 マシンにはローカル ハード ドライブがあるため、操作するエンジニアにとって、これは操作の観点から非常に便利です。

二重読書手当をいただきました。

これは耐障害性に加えて非常に優れた利点です。

しかし、問題もあります。 現在、システムは 100% の最終整合性を備えているため、これに関連するいくつかの機能をさらに複雑に開発する必要があります。

たとえば、私たちはバックグラウンド ジョブで、「今どのサーバーで実行しているのか?」、「本当にここに現在の写真があるのか​​?」を常に考えなければなりません。 等もちろん、これはすべてまとめられており、ビジネス ロジックを作成するプログラマーにとっては透過的です。 しかし、それにもかかわらず、この大きな複雑な層が出現しました。 しかし、私たちはそこから得た恩恵と引き換えに、これを我慢する用意があります。

そしてここでもまた葛藤が生じます。

冒頭で、すべてをローカルのハードドライブに保存するのは良くないと言いました。 そして今、私たちはそれが気に入ったと言いました。

はい、確かに、時間の経過とともに状況は大きく変化し、現在ではこのアプローチには多くの利点があります。 まず、操作がはるかに簡単になります。

第二に、自動コントローラーやディスク シェルフへの接続がないため、生産性が向上します。

そこには膨大な量の機械があり、これらはここの機械上でレイドとして組み立てられる数枚のディスクにすぎません。

しかし欠点があります。

これは、現在の価格でも SAN を使用するよりも約 1,5 倍高価です。 したがって、私たちは大規模なクラスター全体をローカル ハード ドライブを備えた自動車に大胆に変換せず、ハイブリッド ソリューションを残すことにしました。

当社のマシンの半分はハードドライブで動作します (半分ではなく、おそらく 30 パーセント)。 そして残りは、かつて最初の予約制度があった古い車両です。 新しいデータなどは必要なかったため、マウントを XNUMX つの物理ホストから XNUMX つの物理ホストに移動しただけです。

そして今では大量の読書のストックがあり、それを拡張しました。 以前は XNUMX つのマシンに XNUMX つのストレージをマウントしていましたが、今回は、たとえば XNUMX つのペアに XNUMX つのストレージをマウントします。 そしてそれはうまくいきます。

私たちが何を達成したのか、何のために戦ったのか、成功したかどうかを簡単にまとめてみましょう。

結果

当社には 33 万人ものユーザーがいます。

私たちはプラハ、マイアミ、香港の XNUMX つの拠点を持っています。

これらには、高速ローカル ディスク (SSD) を搭載した車両で構成されるキャッシュ レイヤーが含まれており、その上で NGINX の単純な機構、その access.log および Python デーモンが実行され、これらすべてが処理され、キャッシュが管理されます。

ご希望であれば、あなたはプロジェクトに参加しており、写真があなたにとって私たちにとってほど重要ではない場合、または開発速度とリソースコストに対するトレードオフの制御があなたにとって別の方向にある場合は、安全に置き換えることができますCDN を使用すると、最新の CDN はうまく機能します。

次にストレージ層が登場します。この層には、相互にバックアップするマシンのペアのクラスターがあり、ファイルが変更されるたびに、あるファイルから別のファイルに非同期的にコピーされます。

さらに、これらのマシンの一部はローカル ハード ドライブで動作します。

これらのマシンの一部は SAN に接続されています。

そして、一方では、より使いやすく、生産性も少し高くなりますが、他方では、配置密度とギガバイトあたりの価格の点で便利です。

これは、私たちが得たもののアーキテクチャと、それがどのように発展したかについての簡単な概要です。

船長からのヒントがいくつかあります。非常に簡単なものです。

まず、写真インフラストラクチャのすべてを緊急に改善する必要があると突然判断した場合は、おそらく何も改善する必要がないため、最初に測定してください。

例を挙げてみましょう。 チャットの添付ファイルから写真を送信するマシンのクラスターがあり、このスキームは 2009 年から機能しており、誰も被害を受けていません。 みんな元気で、みんな何でも好きです。

測定するには、まず大量の指標をぶら下げてそれらを観察し、次に何が不満で、何を改善する必要があるかを判断します。 これを測定するために、Pinba という優れたツールがあります。

これにより、NGINX から各リクエスト コードとレスポンス コード、時間の分布など、必要に応じて非常に詳細な統計を収集できます。 あらゆる種類のさまざまな分析システムとバインディングがあり、すべてを美しく見ることができます。

まずそれを測定し、それから改善しました。

さらに遠く。 キャッシュによる読み取り、シャーディングによる書き込みを最適化しますが、これは明らかな点です。

さらに遠く。 システムの構築を始めたばかりの場合は、写真を不変ファイルとして作成することをお勧めします。 なぜなら、キャッシュの無効化、ロジックが写真の正しいバージョンを見つける方法など、一連の問題が即座に失われるからです。

XNUMX 個をアップロードし、それを回転して、物理的に異なるファイルにしたとします。 それらの。 考える必要はありません。ここで少しスペースを節約し、同じファイルに書き込み、バージョンを変更します。 これは常にうまく機能せず、後で多くの頭痛の種を引き起こします。

次のポイント。 その場でのサイズ変更について。

以前は、ユーザーが写真をアップロードすると、あらゆる機会やさまざまなクライアントに合わせて大量のサイズが即座にカットされ、それらはすべてディスク上に保存されていました。 今ではこれを放棄しました。

主要なサイズは小、中、大の XNUMX つだけになりました。 Uport で要求されたサイズよりも後ろのサイズから他のものをすべてダウンスケールし、ダウンスケールを実行してユーザーに提供するだけです。

ここでのキャッシュ層の CPU は、各ストレージでこれらのサイズを常に再生成する場合よりもはるかに安価であることがわかります。 新しいものを追加したいとします。これには XNUMX か月かかります。クラスターを破壊することなく、これらすべてを適切に実行するスクリプトをどこでも実行します。 それらの。 今選択する機会がある場合は、物理的なサイズをできる限り少なくすることをお勧めしますが、少なくともある程度の分布が、たとえば XNUMX になるようにします。 他のものはすべて、既製のモジュールを使用してその場で簡単にサイズ変更できます。 すべてとても簡単でアクセスしやすくなりました。

増分非同期バックアップも優れています。

私たちの実践が示しているように、このスキームは変更されたファイルの遅延コピーにうまく機能します。

最後の点も明らかです。 今はインフラにそういった問題がなくても、壊れる可能性のあるものがあれば、もう少し大きくなると必ず壊れてしまいます。 したがって、これについては事前に検討し、問題が発生しないようにすることをお勧めします。 私が言いたかったのはそれだけです。

コンタクト

» bo0rsh201
» Badoo ブログ

このレポートは、高負荷システムの開発者のカンファレンスでの最も優れたスピーチの XNUMX つを書き起こしたものです。 HighLoad ++。 HighLoad++ 2017 カンファレンスまで残り XNUMX か月を切りました。

すでに準備ができています 会議プログラム、現在、スケジュールが積極的に作成されています。

今年も引き続きアーキテクチャとスケーリングのトピックを探求します。

• XNUMX億人のユーザーにサービスを提供し、テラビットのトラフィックを提供する方法 /イーゴリ・ワシリエフ
• VKontakte パーソナル メッセージ データベースを最初から書き直し、ダウンタイムなしで移行する方法 / ドミトリー・エゴロフ
• 販売による死亡: Yandex.Money がどのようにしてブラック フライデーに加速し、生き残ろうとしたか / アナトリー・プラスコフスキー
• 銀行のフロントエンド システムのフォールト トレラント アーキテクチャ / ロマン・シェホフツォフ、アレクセイ・グロマチコフ
• 決済システムのアーキテクチャ: ほぼエンタープライズ向け / フィリップ・デルガド

これらの資料の一部は、高負荷システムの開発に関するオンライン トレーニング コースでも使用します。 高負荷ガイド は、特別に選ばれた手紙、記事、資料、ビデオのチェーンです。 私たちの教科書にはすでに 30 以上のユニークな教材が含まれています。 接続する！

出所： habr.com