HighLoad ++で1秒あたり70千のリクエストを分散

レポートライブラリ

これは単なる記事ではなく、さまざまな大規模で負荷の高いプロジェクトの内部構造に関するレポートのライブラリ全体です。 これらのレポートはすべて、過去数年にわたってHighLoad ++およびRIT ++カンファレンスで聞いていました。







そしてまた：

セクション「アーキテクチャ」

モスクワで2週間後に開催される高負荷システムHighLoad ++の開発者会議の重要なセクションは、もちろん建築です。 このセクションのレポートは変更されています。3、4年前にFacebookにあるサーバーの数とVKontakteでのファイルの保存場所に関する一般的な言葉を聞いた場合、そのようなレポートはプログラムに送られません。 今こそ、詳細、マイクロサービス、1つまたは別のアーキテクチャパターンの詳細な分析の時です。



だから、建築パターン。 今回の会議では、それらのいくつかを詳細に分析します。最初のものは、もちろんマイクロサービスです。



単一のアプリケーションは、それぞれが独自のプロセスで動作する一連の小さなマイクロサービスとして構築され、他のマイクロサービスから可能な限り独立しており、原則として、1つのビジネス機能を実装し、同じHTTPの軽量メカニズムを使用して残りと通信します。



Anton ReznikovとVladimir Perepelitsa は 、Cloud.ruのマイクロサービスアーキテクチャだけでなく 、Tarantool NoSQLデータベースでのパターンの具体的な実装についても説明します。 はい、Tarantoolは別のNoSQLデータベースですが、完全なアプリケーションサーバーでもあります。 データの隣にあるアプリケーション！







Denis Ivanov（2Gis）は、彼の講演「PHPのモノリスからScalaのマイクロサービスへの道」でトピックを続けます。 「デニス、あなたがしていることをやめなさい、どうして？！」 そして、Denisはこの質問に単純に答えます。18個ではなく6個のアプリケーションを持つノードです。答えはまともです。会議で詳細を聞くことを望んでいます。



負荷の高いプロジェクトでよく使用される別のパターンはキューです。 このトピックは、Pavel Filonov（Positive Technologies）のレポート「RabbitMQを準備する101の方法とパイプラインアーキテクチャについて少し」で開示されています 。

このレポートでは、パイプラインアーキテクチャを構築するためのミドルウェアとしてRabbitMQメッセージングシステムを使用するためのオプションについて説明します。 ステートレスフィルターとステートフルフィルターの両方のパフォーマンスとスケーリングの問題が考慮されます。

レポートはトレーニングレポートに似ていますが、トピックはあまりにも優れています！









BadooのYuri Nasretdinovからの次のバランスレポートは、勝つための重大な入札です。 この機会を利用して、会議で予想される最も刺激的なレポートの1つに光を当てるために、ユーリにいくつかの質問をしようとしました。

-由良、1秒あたり70kリクエストの負荷レベルにどのようにアプローチしましたか？

このレベルの負荷にほぼ10年間ほぼ順調に近づきました。 近年、モバイルデバイスのユーザー数も急速に増加し始め、1秒あたりのリクエスト数も増加しました。モバイルアプリケーションは、Webサイトよりも小さなリクエストをサーバーに送信します。 1秒あたり70kのリクエストがPHP-FPMに該当することに注意してください。サイトへのHTTPリクエストの総数は1秒あたり250kまでです。

-そのような荷物を保持するには、卵以外に何が必要ですか？

一般に、1秒あたり250,000のHTTP要求を処理するのに問題はありません。 このような負荷は、通常のnginxとラウンドロビンDNSで提供できます。 着信トラフィックを処理するために「ハードウェア」ソリューションを使用します-GT5およびF5からのLTM。 これにより、すべてのリクエストを同じIPアドレスで、つまりラウンドロビンDNSを使用せずに処理できます。 入力ルーターでは、どのリクエストが1つまたは別のクラスターに到達するかに従ってルールが設定され、必要に応じてマシンの重みが設定され、残りはこの鉄片（またはモバイルクラスターへのリクエストをプロキシするために使用するnginx）によって行われます。



大まかに言って、サーバー間で要求を分散することは困難な作業ではなく、PHPのスケーリングは単に適切な重みでサーバーをバックエンドに追加することです。



このような負荷を維持するだけでなく、数百テラバイト、さらにはペタバイトの写真やテキストデータを保存および提供できるユーザーデータを保存するアーキテクチャを作成することははるかに困難です。 2012年にDevConfで開催されたAlexei Rybakのマスタークラスや、 2015年に写真を保存するためのアーキテクチャに関する私のレポートなど、アーキテクチャに関する多くのレポートがありました。 残念ながら、インタビューでアーキテクチャについて簡単に話すことはできないため、プレゼンテーションで詳細を確認することをお勧めします。

-アーキテクチャのこのようなスループットはどのように達成されますか、いくつかの興味深い場所は何ですか？

繰り返しますが、そのような帯域幅は目立ったものではなく、同じLTMは追加の「バックアップ」がなくても負荷に対処できます。



ユーザーデータを格納するアーキテクチャについて説明すると、すべてが少し興味深いものになります。 各ユーザーのデータを1つのサーバーに保存します。つまり、IDやその他の合成値ではなく、ユーザーごとにデータを分割します。 これにより、ユーザーデータを操作するときにかなり複雑な選択を行い、JOINと複雑な並べ替えを使用できます。 同時に、ユーザーはサーバーを「ネイル」しませんが、必要に応じてクラスター内を移動できます。 これは、ユーザーの "spot_id"および "place_id"（サーバー上のサーバー名とテーブル名を決定できる識別子）を "authorizer"と呼ばれる中央サービスに保存するという事実により達成されます。 ユーザーデータベースへの接続を確立する必要があるたびに、このサービスに対して要求が行われます。 サービスは1秒あたり約40kの読み取り要求を占め、単一のMySQLインスタンスでHandlerSocketプロトコルを使用して処理されます。 このサービスは、おそらく1つのサーバーにサービスを提供する最も負荷の高い内部サービスであり、現時点では少なくとも2倍のパフォーマンスのマージンがあります。 MySQL + handlersocketのスケーラビリティに遭遇した場合でも、たとえば、このタスクにTarantoolをいつでも試すことができます-このデーモンは、_kernel_に100,000リクエスト/秒を発行できます（MySQL + handlersocketの場合、_server_への10万リクエストと比較できます）。

-そして、HighLoad ++のレポートに関するいくつかの言葉

レポートでは、バランサーのサーバーの重みを設定するシステムについて説明します（Web負荷の場合はLTM、モバイルクラスターの場合はnginx）。 クラスタは、手作業で行うよりもはるかに均一な負荷分散を実現するためにシステムが必要です。 負荷とリクエストの数が増えるにつれて、必要なサーバーの数が増え始め、新しいサーバーを追加することに加えて、既存のサーバーをより均等にロードできるように努力することにしました。 処理を開始する前は、最も負荷の高いサーバーと最も負荷の低いサーバーのCPU使用率の差は約20〜30％でしたが、その後はわずか2.5％でした。 私たちのボリュームでは、これにより何百台ものサーバーを保存することができ、確かに価値がありました。



機械のスケールの自動配布に対する既存のアプローチ、どのアプローチを試みたのか、そしてその結果として確立されたものについてお話します。 必要に応じてプロジェクトで使用できるように、私たちが書いたソリューションはオープンソースで公開されます。

そして最後に、RuNet-Avito.ruの広告の非常に大規模で最大のサービスについてですが、主要なプロジェクトのアーキテクチャに関する古典的なレポート。 AvitoのチーフシステムアーキテクトであるMikhail Tyurinは、 「広告はどこに掲載されていますか」と語っています。

同一の高負荷プロジェクトは存在せず、特定の機能の作業の微妙な違い、特定のデータブロックの保存と使用に悪魔がいます。 MIPTの高負荷システムに関する講義コースを、高負荷プロジェクトでの作業の分析部分の重要性についてのストーリーとデモンストレーションから始める理由です。 そしてそれが、私がマイケルのレポートに行くことをお勧めする理由です-マイケル-ヨーロッパで最大の分類、6億広告-それはすべてどのように機能しますか？

会議で会いましょう！

PSチュートリアル

ところで、ここ数週間、負荷の高いシステムの設計に関する新しい教科書を作成しています。 これはロシアの最高の専門家の講義に基づいて作成された一連の手紙です。 どこかで講義をデコードし、どこかでビデオを提供しますが、次のことが重要です。各資料は私たちによって二重にチェックされ、HighLoad ++会議品質の印が付いています。



興味があれば、サインアップして、無料です： http : //highload.guide/

最後に 、Habrahabrユーザーの場合、カンファレンスでは15％の特別割引が提供されます。チケットの予約時にIAmHabrコードを使用するだけです。