VKontakte のアーキテクチャと仕事に関する FAQ

VKontakte の作成の歴史は Wikipedia にあり、Pavel 自身によって語られています。 誰もが彼女のことをすでに知っているようです。 HighLoad++ Pavel のサイトの内部、アーキテクチャ、構造について 2010年に私に言った。 それ以来、多くのサーバーが漏洩しているため、情報を更新します。サーバーを解剖し、内部を取り出し、重量を測定し、技術的な観点から VK デバイスを調べます。

アレクセイ・アクロヴィッチ (アテルカッタス) VKontakte チームのバックエンド開発者。 このレポートの記録は、プラットフォーム、インフラストラクチャ、サーバー、およびそれらの間の相互作用の操作に関するよくある質問に対する回答をまとめたものですが、開発に関するものではありません。 鉄について。 それとは別に、データベースと VK が代わりに備えているものについて、ログの収集とプロジェクト全体の監視について説明します。 詳細はカットの下にあります。

XNUMX 年以上、私はバックエンドに関連するあらゆる種類のタスクに取り組んできました。

• メディアのアップロード、保存、処理、配布: ビデオ、ライブ ストリーミング、オーディオ、写真、ドキュメント。
• インフラストラクチャ、プラットフォーム、開発者の監視、ログ、地域キャッシュ、CDN、独自の RPC プロトコル。
• 外部サービスとの統合: プッシュ通知、外部リンク解析、RSS フィード。
• 同僚のさまざまな質問をサポートしますが、その答えを得るには未知のコードに飛び込む必要があります。

この間、私はサイトの多くのコンポーネントに携わりました。 この経験を共有したいと思います。

一般的なアーキテクチャ

いつものように、すべてはリクエストを受け入れるサーバーまたはサーバーのグループから始まります。

フロントサーバー

フロント サーバーは、HTTPS、RTMP、および WSS 経由でリクエストを受け入れます。

HTTPS - これらは、サイトのメインおよびモバイル Web バージョン (vk.com および m.vk.com)、および API のその他の公式および非公式クライアント (モバイル クライアント、メッセンジャー) に対するリクエストです。 受付を行っております RTMP- 個別のフロント サーバーを使用したライブ ブロードキャストのトラフィックと WSS- ストリーミング API の接続。

サーバー上の HTTPS と WSS の場合は価値があります nginx。 RTMP ブロードキャストについては、最近独自のソリューションに切り替えました。 カイブ、しかしそれはレポートの範囲を超えています。 フォールト トレランスを実現するために、これらのサーバーは共通の IP アドレスをアドバタイズし、グループで動作するため、いずれかのサーバーに問題が発生した場合でもユーザーのリクエストが失われないようにします。 HTTPS と WSS の場合、これらの同じサーバーは、CPU 負荷の一部を自分自身に負担させるためにトラフィックを暗号化します。

WSS と RTMP についてはこれ以上説明しません。通常、Web プロジェクトに関連付けられる標準の HTTPS リクエストについてのみ説明します。

バックエンド

通常、フロントの背後にはバックエンド サーバーがあります。 フロント サーバーがクライアントから受信したリクエストを処理します。

それ kPHPサーバーHTTPS はすでに復号化されているため、HTTP デーモンが実行されています。 kPHP は、上で実行されるサーバーです。 プリフォークモデル: マスタープロセスと多数の子プロセスを開始し、リスニングソケットをそれらに渡し、リクエストを処理します。 この場合、プロセスはユーザーからのリクエストごとに再起動されず、再起動するのではなく、単に元のゼロ値の状態にリセットされます (リクエストごとに)。

負荷分散

すべてのバックエンドは、あらゆるリクエストを処理できる巨大なマシンのプールではありません。 私たち彼ら 別々のグループに分けられる: 一般、モバイル、API、ビデオ、ステージング... マシンの別のグループでの問題は、他のすべてのマシンには影響しません。 ビデオに問題が発生した場合、音楽を聴くユーザーはその問題にさえ気づきません。 どのバックエンドにリクエストを送信するかは、設定​​に従ってフロントの nginx によって決定されます。

メトリクスの収集と再バランス

各グループに何台の車が必要かを理解するには、次のようにします。 QPSに依存しないでください。 バックエンドが異なり、異なるリクエストがあり、各リクエストの QPS 計算の複雑さが異なります。 だからこそ私たちは 私たちはサーバー全体、つまり CPU とパフォーマンスに対する負荷の概念を使用して動作します。.

当社にはそのようなサーバーが数千台あります。 各物理サーバーは kPHP グループを実行して、すべてのコアをリサイクルします (kPHP はシングルスレッドであるため)。

コンテンツサーバー

CS またはコンテンツ サーバーはストレージです。 CS は、ファイルを保存し、アップロードされたファイルや、メインの Web フロントエンドが割り当てるあらゆる種類のバックグラウンド同期タスクも処理するサーバーです。

ファイルを保存する物理サーバーが数万台あります。 ユーザーはファイルをアップロードするのが好きで、私たちもファイルを保存したり共有したりするのが好きです。 これらのサーバーの一部は、特別な pu/pp サーバーによって閉じられています。

プ/ップ

VK でネットワーク タブを開くと、pu/pp が表示されます。

pu/ppとは何ですか? サーバーを次々と閉じる場合、閉じられたサーバーにファイルをアップロードおよびダウンロードするには XNUMX つのオプションがあります。 直接 スルー http://cs100500.userapi.com/path または 中間サーバー経由 - http://pu.vk.com/c100500/path.

Pu は写真アップロードの歴史的な名前、pp は写真プロキシです。 つまり、XNUMX つのサーバーは写真のアップロード用であり、もう XNUMX つのサーバーはアップロード用です。 写真が読み込まれるだけでなく、名前も保持されるようになりました。

これらのサーバー HTTPSセッションを終了するストレージからプロセッサの負荷を軽減します。 また、ユーザー ファイルはこれらのサーバーで処理されるため、これらのマシンに保存される情報の機密性は低いほど優れています。 たとえば、HTTPS 暗号化キーなどです。

これらのマシンは他のマシンによって閉じられているため、それらに「ホワイト」外部 IP を付与しなくても済みます。 「灰色」を与える。 このようにして、IP プールを保存し、外部アクセスからマシンを保護することが保証されました。単にそこに入る IP が存在しないだけです。

共有IPを介した復元力。 フォールト トレランスの観点からは、このスキームは同じように機能します。複数の物理サーバーが共通の物理 IP を持ち、その前にあるハードウェアがリクエストの送信先を選択します。 他のオプションについては後ほど説明します。

物議を醸している点は、この場合、 クライアントが保持する接続が少なくなります。 同じホスト (pu.vk.com または pp.vk.com) を使用する複数のマシンに同じ IP がある場合、クライアント ブラウザには 2 つのホストに対する同時リクエストの数に制限があります。 しかし、HTTP/XNUMX がユビキタスになった時代には、これはもはやあまり意味がないと思います。

このスキームの明らかな欠点は、次のことです。 すべてのトラフィックをポンプする、別のサーバーを介してストレージに移動します。 マシンを介してトラフィックをポンプするため、同じスキームを使用してビデオなどの大量のトラフィックをポンプすることはまだできません。 私たちはそれを直接送信します - ビデオ専用の個別のストレージへの個別の直接接続。 軽いコンテンツはプロキシ経由で送信します。

少し前に、プロキシの改良版を入手しました。 ここでは、それらが通常のものとどのように異なるのか、そしてなぜこれが必要なのかを説明します。

日

2017 年 XNUMX 月、以前に Sun を買収した Oracle は、 膨大な数のSun従業員を解雇した。 この時点で会社は消滅したと言えるでしょう。 新しいシステムの名前を選ぶとき、当社の管理者はこの会社の記憶に敬意を表することを決め、新しいシステムを Sun と名付けました。 私たちの間では彼女を単に「太陽」と呼んでいます。

ppにはいくつかの問題がありました。 グループごとに XNUMX つの IP - 非効率的なキャッシュ。 複数の物理サーバーが共通の IP アドレスを共有しているため、リクエストがどのサーバーに送信されるかを制御する方法はありません。 したがって、異なるユーザーが同じファイルを取得する場合、これらのサーバーにキャッシュがある場合、ファイルは各サーバーのキャッシュに保存されます。 これは非常に非効率な計画ですが、何もすることができませんでした。

その結果 - コンテンツをシャーディングすることはできません、このグループに特定のサーバーを選択することはできないため、それらは共通の IP を持っています。 また、いくつかの内部的な理由により、 このようなサーバーをリージョンにインストールすることはできませんでした。 彼らはサンクトペテルブルクにのみ立っていた。

サンズでは選抜制度を変更しました。 今では、 エニーキャストルーティング: 動的ルーティング、エニーキャスト、セルフチェック デーモン。 各サーバーには独自の個別の IP がありますが、共通のサブネットがあります。 XNUMX つのサーバーに障害が発生した場合、トラフィックが同じグループの他のサーバーに自動的に分散されるように、すべてが構成されています。 特定のサーバーを選択できるようになりました。 冗長なキャッシュはありません、信頼性には影響しませんでした。

体重サポート。 現在では、必要に応じてさまざまな出力の機械を設置する余裕があり、また、一時的な問題が発生した場合には、稼働中の「太陽」の重さを変更して負荷を軽減し、太陽が「休んで」再び働き始めるようにすることもできます。

コンテンツIDによるシャーディング。 シャーディングに関する面白い点は、通常、異なるユーザーが同じ「太陽」を通じて同じファイルにアクセスし、共通のキャッシュを持てるようにコンテンツをシャーディングすることです。

このたび「Clover」アプリをリリースしました。 これは生放送でのオンライン クイズで、ホストが質問し、ユーザーはオプションを選択してリアルタイムで回答します。 アプリにはユーザーがチャットできるチャットがあります。 ブロードキャストに同時に接続できます 100万人以上。 彼らは全員、参加者全員に送信されるメッセージを書き、アバターがメッセージと一緒にやって来ます。 100 回の「太陽」に XNUMX 万人が XNUMX つのアバターを求めてやって来ると、雲に隠れてしまうこともあります。

同じファイルに対するリクエストのバーストに耐えるために、特定の種類のコンテンツに対しては、その地域で利用可能なすべての「太陽」にファイルを分散させる愚かな計画を有効にしています。

内側からの太陽

nginx 上のリバース プロキシ、RAM または高速 Optane/NVMe ディスクのいずれかにキャッシュします。 例： http://sun4-2.userapi.com/c100500/path — 100500 番目の地域、XNUMX 番目のサーバー グループにある「太陽」へのリンク。 物理的にサーバー XNUMX にあるパス ファイルを閉じます。

キャッシュ

アーキテクチャスキームにもう XNUMX つのノード、つまりキャッシュ環境を追加します。

以下はレイアウト図です 地域キャッシュ、20個ほどあります。 これらは、キャッシュと「サン」が配置され、それ自体を介してトラフィックをキャッシュできる場所です。

これはマルチメディア コンテンツのキャッシュです。ここにはユーザー データは保存されず、音楽、ビデオ、写真のみが保存されます。

ユーザーの地域を特定するために、 リージョンで発表された BGP ネットワーク プレフィックスを収集します。 フォールバックの場合、プレフィックスで IP が見つからなかった場合は、geoip データベースも解析する必要があります。 ユーザーのIPによって地域を決定します。 コードでは、ユーザーの XNUMX つ以上の地域、つまりユーザーが地理的に最も近い地点を調べることができます。

それはどのように動作しますか？

ファイルの人気を地域ごとにカウントします。 ユーザーがいる地域キャッシュの番号とファイル識別子があり、このペアを取得して、ダウンロードごとに評価を増分します。

同時に、デーモン (リージョン内のサービス) が時々 API にやって来て、こう言います。 」 API は評価別に分類された多数のファイルを配信し、デーモンはそれらをダウンロードしてリージョンに取り込み、そこからファイルを配信します。 これが、キャッシュからの pu/pp と Sun の根本的な違いです。キャッシュにファイルが存在しない場合でも、キャッシュはすぐにファイルを自分自身に渡し、キャッシュは最初にファイルを自分自身にダウンロードしてから、そのファイルを返し始めます。

この場合、次のようになります。 ユーザーに近いコンテンツ そしてネットワーク負荷を分散します。 たとえば、モスクワ キャッシュからのみ、ピーク時に 1 Tbit/s 以上を配布します。

しかし、問題もあります - キャッシュサーバーはゴムではありません。 非常に人気のあるコンテンツの場合、別のサーバーを設置するのに十分なネットワークがない場合があります。 当社のキャッシュ サーバーは 40 ～ 50 Gbit/s ですが、そのようなチャネルを完全に詰まらせるコンテンツがあります。 私たちは、この地域で人気のあるファイルの複数のコピーのストレージの実装に向けて取り組んでいます。 年末までに実装できることを願っています。

一般的なアーキテクチャを見ていきました。

• リクエストを受け入れるフロントサーバー。
• リクエストを処理するバックエンド。
• XNUMX 種類のプロキシによって閉じられるストレージ。
• 地域キャッシュ。

この図には何が欠けていますか? もちろん、データを保存するデータベースです。

データベースまたはエンジン

一般に受け入れられている意味でのデータベースが実際には存在しないため、私たちはそれらをデータベースではなくエンジンと呼びます。

これは必要な手段です。。 これは、VK の人気が爆発的に高まった 2008 年から 2009 年に、プロジェクトが完全に MySQL と Memcache 上で動作し、問題が発生したために起こりました。 MySQL は頻繁にクラッシュしてファイルが破損し、その後回復できなくなり、Memcache のパフォーマンスが徐々に低下して再起動する必要がありました。

人気が高まっているプロジェクトには、データを破損する永続ストレージと、速度を低下させるキャッシュが存在していたことが判明しました。 このような状況では、成長するプロジェクトを開発することは困難です。 このプロジェクトが焦点を当てていた重要なことを自分たちの自転車に書き換えてみることにしました。

解決策は成功しました。 当時は他のスケーリング方法が存在していなかったので、これを行う機会があったと同時に、非常に必要でした。 データベースはそれほど多くはなく、NoSQL もまだ存在せず、MySQL、Memcache、PostrgreSQL しかありませんでした。それだけでした。

ユニバーサル操作。 開発は C 開発者のチームによって主導され、すべてが一貫した方法で行われました。 エンジンに関係なく、それらはすべてほぼ同じファイル形式でディスクに書き込まれ、同じ起動パラメータを持ち、同じ方法で信号を処理し、エッジの状況や問題が発生した場合にほぼ同じように動作しました。 エンジンの成長に伴い、管理者はシステムを操作するのが便利になりました。管理する必要のある動物園がなくなり、新しいサードパーティ データベースごとに操作方法を再学習する必要があるため、迅速かつ便利にデータベースを増やすことが可能になりました。彼らの番号。

エンジンの種類

チームはかなりの数のエンジンを作成しました。 以下にそれらのほんの一部を示します: 友人、ヒント、画像、ipdb、手紙、リスト、ログ、memcached、meowdb、ニュース、ノストラダムス、写真、プレイリスト、pmemcached、サンドボックス、検索、ストレージ、いいね、タスクなど。

特定のデータ構造を必要とするタスクや、特殊なリクエストを処理するタスクごとに、C チームは新しいエンジンを作成します。 なぜだめですか。

独立したエンジンを搭載しています memcached、通常のものと似ていますが、たくさんの特典があり、速度が低下することはありません。 ClickHouse ではありませんが、これも機能します。 別途購入可能 pmemcached - です 永続的なmemcachedさらに、再起動時にデータが失われないように、RAM に収まるよりもディスクにデータを保存することもできます。 個々のタスクにはさまざまなエンジンがあります: キュー、リスト、セットなど、プロジェクトに必要なものすべてです。

クラスター

コードの観点から見ると、エンジンやデータベースをプロセス、エンティティ、またはインスタンスとして考える必要はありません。 このコードは、特にクラスターやエンジンのグループで動作します。 クラスターごとに XNUMX つのタイプ。 memcached クラスターがあるとします。これは単なるマシンのグループです。

コードはサーバーの物理的な場所、サイズ、数を知る必要はまったくありません。 彼は特定の識別子を使用してクラスターにアクセスします。

これを機能させるには、コードとエンジンの間にエンティティをもう XNUMX つ追加する必要があります。 代理.

RPC プロキシ

プロキシ 連絡バス、サイトのほぼ全体がこの上で実行されます。 同時に、私たちは サービス検出がありません — 代わりに、このプロキシの構成があり、このプロキシは、すべてのクラスターとこのクラスターのすべてのシャードの場所を認識しています。 これは管理者が行うことです。

プログラマーは、どこにどれくらいの費用がかかるかなどまったく気にせず、ただクラスターにアクセスするだけです。 これにより、多くのことが可能になります。 リクエストを受信すると、プロキシはどこにあるかを認識してリクエストをリダイレクトします。これはプロキシ自身が決定します。

この場合、プロキシはサービス障害に対する保護点となります。 一部のエンジンが遅くなったりクラッシュしたりすると、プロキシはこれを理解し、クライアント側に応じて応答します。 これにより、タイムアウトを削除できます。コードはエンジンの応答を待機しませんが、エンジンが機能しておらず、何らかの方法で別の動作をする必要があることを理解します。 データベースが常に機能するとは限らないという事実に備えて、コードを準備する必要があります。

具体的な実装

場合によっては、エンジンとして何らかの非標準的なソリューションが必要になることがあります。 同時に、エンジン専用に作成された既製の rpc プロキシを使用せず、タスク用に別のプロキシを作成することが決定されました。

MySQL にはまだあちこちにありますが、db-proxy を使用し、ClickHouse には - 子猫の家.

大体こんな感じで動作します。 特定のサーバーがあり、kPHP、Go、Python、つまり RPC プロトコルを使用できるあらゆるコードを実行します。 コードは RPC プロキシ上でローカルに実行されます。コードが配置されている各サーバーは独自のローカル プロキシを実行します。 要求に応じて、代理人はどこに行くべきかを理解します。

あるエンジンが別のエンジンにアクセスしたい場合、それが隣接エンジンであっても、隣接エンジンが別のデータ センターに存在する可能性があるため、プロキシを経由します。 エンジンは、それ自体以外の場所を知ることに依存すべきではありません。これが私たちの標準ソリューションです。 しかし、もちろん例外もあります:)

すべてのエンジンが動作する TL スキームの例。

memcache.not_found                                = memcache.Value;
memcache.strvalue	value:string flags:int = memcache.Value;
memcache.addOrIncr key:string flags:int delay:int value:long = memcache.Value;

tasks.task
    fields_mask:#
    flags:int
    tag:%(Vector int)
    data:string
    id:fields_mask.0?long
    retries:fields_mask.1?int
    scheduled_time:fields_mask.2?int
    deadline:fields_mask.3?int
    = tasks.Task;
 
tasks.addTask type_name:string queue_id:%(Vector int) task:%tasks.Task = Long;

これはバイナリ プロトコルであり、これに最も近いものは次のとおりです。 プロトブフ。 スキーマは、オプションのフィールド、複合型 (組み込みスカラーの拡張)、およびクエリを事前に記述します。 すべてはこのプロトコルに従って動作します。

RPC over TL over TCP/UDP…UDP?

TL スキーム上で実行されるエンジン リクエストを実行するための RPC プロトコルがあります。 これはすべて TCP/UDP 接続経由で機能します。 TCP は理解できますが、なぜ頻繁に UDP が必要になるのでしょうか?

UDP が役立ちます サーバー間の膨大な数の接続の問題を回避する。 各サーバーに RPC プロキシがあり、一般に任意のエンジンに接続できる場合、サーバーごとに数万の TCP 接続が存在します。 負荷はありますが、役に立ちません。 UDP の場合、この問題は存在しません。

冗長な TCP ハンドシェイクなし。 これは典型的な問題です。新しいエンジンまたは新しいサーバーが起動されると、一度に多数の TCP 接続が確立されます。 UDP ペイロードなどの小規模で軽量なリクエストの場合、コードとエンジン間のすべての通信は XNUMX つの UDP パケット: XNUMX 機は一方向に飛行し、XNUMX 機目は別の方向に飛行します。 XNUMX 往復で、コードはハンドシェイクなしでエンジンから応答を受け取りました。

はい、すべてうまくいきます パケット損失の割合が非常に小さい。 このプロトコルは再送信とタイムアウトをサポートしていますが、大量に失われるとほぼ TCP を取得することになり、有益ではありません。 私たちは UDP を海を越えて推進するわけではありません。

当社にはそのようなサーバーが何千台もあり、スキームは同じです。エンジンのパックが各物理サーバーにインストールされます。 これらはブロックすることなくできるだけ早く実行できるようにほとんどがシングルスレッドであり、シングルスレッド ソリューションとしてシャード化されています。 同時に、これらのエンジンほど信頼できるものはなく、永続的なデータ ストレージには細心の注意が払われています。

永続的なデータストレージ

エンジンはバイナリログを書き込みます。 バイナリログは、状態またはデータの変更に関するイベントが末尾に追加されるファイルです。 ソリューションによっては、バイナリ ログ、バイナリ ログなど、呼び方が異なります。 WAL, AOF, しかし原理は同じです。

再起動時にエンジンが何年にもわたってバイナリ全体を再読み取りするのを防ぐために、エンジンは次のように書き込みます。 スナップショット - 現在の状態。 必要に応じて、最初にバイナリログから読み取り、次にバイナリログからの読み取りを終了します。 すべてのバイナリログは、TL スキームに従って同じバイナリ形式で書き込まれるため、管理者はツールを使用してバイナリログを同等に管理できます。 スナップショットなどは必要ありません。 スナップショットが int であること、エンジンの魔法であること、および誰にとっても重要ではない本体を示す一般的なヘッダーがあります。 これは、スナップショットを記録したエンジンに問題があります。

動作原理を簡単に説明します。 エンジンが動作するサーバーがあります。 彼は書き込み用に新しい空のバイナリログを開き、それに変更を加えるイベントを書き込みます。

ある時点で、彼は自分でスナップショットを撮ることを決定するか、信号を受信します。 サーバーは新しいファイルを作成し、ファイルの状態全体をそのファイルに書き込み、現在のバイナリ ログ サイズ (オフセット) をファイルの末尾に追加して、さらに書き込みを続けます。 新しいバイナリログは作成されません。

ある時点で、エンジンが再起動すると、ディスク上にバイナリログとスナップショットの両方が作成されます。 エンジンはスナップショット全体を読み取り、特定の時点でその状態を引き上げます。

スナップショットの作成時の位置とバイナリログのサイズを読み取ります。

バイナリログの末尾を読んで現在の状態を取得し、さらにイベントの書き込みを続けます。 これは単純なスキームであり、すべてのエンジンはこれに従って動作します。

データ複製

その結果、当社のデータレプリケーションは ステートメントベースの — binlog にはページ変更を書きませんが、つまり 変更リクエスト。 ネットワーク経由で送信されるものと非常に似ていますが、わずかに変更されているだけです。

同じスキームはレプリケーションだけでなく、 バックアップを作成するには。 バイナリログに書き込む書き込みマスターというエンジンがあります。 管理者がセットアップした他の場所では、このバイナリログがコピーされ、それだけでバックアップが作成されます。

必要に応じて リーディングレプリカCPU の読み取り負荷を軽減するために、読み取りエンジンが起動されるだけで、バイナリの末尾を読み取り、これらのコマンドをローカルで実行します。

ここでの遅れは非常に小さく、レプリカがマスターからどれだけ遅れているかを知ることができます。

RPC プロキシでのデータ シャーディング

シャーディングはどのように機能しますか? プロキシはどのクラスター シャードに送信するかをどのように理解するのでしょうか? コードには「15 個のシャードを送ってください!」とは書かれていません。 - いいえ、これはプロキシによって行われます。

最も単純なスキームは firstint です — リクエストの最初の番号。

get(photo100_500) => 100 % N.

これは単純な memcached テキスト プロトコルの例ですが、もちろん、クエリは複雑で構造化される可能性があります。 この例では、クエリの最初の数値を取得し、クラスター サイズで割った残りを取得します。

これは、単一エンティティのデータ局所性が必要な場合に便利です。 100 がユーザーまたはグループ ID で、複雑なクエリのために XNUMX つのエンティティのすべてのデータを XNUMX つのシャード上に置きたいとします。

リクエストがクラスター全体にどのように分散されるかを気にしない場合は、別のオプションがあります。 シャード全体をハッシュする.

hash(photo100_500) => 3539886280 % N

ハッシュ、除算の余り、シャード番号も取得します。

これらのオプションは両方とも、クラスターのサイズを増やすときに分割するか、複数倍にするという事実を覚悟している場合にのみ機能します。 たとえば、16 個のシャードがありましたが、十分ではないので、もっと欲しい場合は、ダウンタイムなしで安全に 32 個を取得できます。 倍数ではなく増やしたい場合は、損失なくすべてを正確に分割することができないため、ダウンタイムが発生します。 これらのオプションは便利ですが、常に役立つわけではありません。

任意の数のサーバーを追加または削除する必要がある場合は、次を使用します。 Ketama のようなリング上の一貫したハッシュ。 しかし同時に、データの局所性が完全に失われます。各部分が独自の小さな応答を返すようにリクエストをクラスターにマージし、その応答をプロキシにマージする必要があります。

超具体的な要望もあります。 次のようになります。RPC プロキシがリクエストを受信し、どのクラスターに移動するかを決定し、シャードを決定します。 次に、書き込みマスターが存在するか、クラスターにレプリカがサポートされている場合は、オンデマンドでレプリカに送信します。 プロキシがこれらすべてを行います。

ログ

私たちはいくつかの方法でログを書き込みます。 最も明白で単純なものは、 ログをmemcacheに書き込む.

ring-buffer: prefix.idx = line

キーのプレフィックス、つまりログの名前、行があり、このログのサイズ、つまり行数があります。 0 から行数から 1 を引いた値までの乱数を取得します。memcache のキーは、この乱数と連結されたプレフィックスです。 ログ行と現在の時刻を値に保存します。

ログの読み込みが必要な場合に実施します。 マルチゲット すべてのキーを時間順に並べ替えて、リアルタイムで運用ログを取得します。 このスキームは、実稼働環境で何かをリアルタイムで、何も壊さず、他のマシンへのトラフィックを停止したり許可したりすることなくデバッグする必要がある場合に使用されますが、このログは長く保存されません。

ログを確実に保管するためのエンジンがあります ログエンジン。 これがまさにこれが作成され、膨大な数のクラスターで広く使用されている理由です。 私が知っている最大のクラスターには、600 TB の圧縮されたログが保存されています。

エンジンは非常に古く、すでに 6 ～ 7 年前のクラスターもあります。 それには解決しようとしている問題があり、たとえば、ログを保存するために ClickHouse を積極的に使用し始めました。

ClickHouse でのログの収集

この図は、私たちがどのようにエンジンに入るのかを示しています。

RPC を介してローカルで RPC プロキシに送信されるコードがあり、エンジンのどこに送信するかを認識します。 ClickHouse にログを書き込みたい場合は、このスキームの XNUMX つの部分を変更する必要があります。

• 一部のエンジンを ClickHouse に置き換えます。
• ClickHouse にアクセスできない RPC プロキシを、RPC 経由でアクセスできるソリューションに置き換えます。

エンジンはシンプルです。ClickHouse を使用してサーバーまたはサーバーのクラスターに置き換えます。

そして、ClickHouseに行くために、私たちはそうしました 子猫ハウス。 KittenHouse から ClickHouse に直接移動すると、対応できません。 リクエストがなくても、膨大な数のマシンの HTTP 接続が加算されます。 スキームが機能するには、ClickHouse を備えたサーバー上で ローカル リバース プロキシが起動される、必要な接続量に耐えられるように書かれています。 また、比較的確実にデータを内部にバッファリングすることもできます。

場合によっては、nginx などの非標準ソリューションに RPC スキームを実装したくない場合があります。 したがって、KittenHouse には UDP 経由でログを受信する機能があります。

ログの送信者と受信者が同じマシン上で作業している場合、ローカル ホスト内で UDP パケットが失われる可能性は非常に低くなります。 サードパーティ ソリューションで RPC を実装する必要性と信頼性の間の妥協策として、単純に UDP 送信を使用します。 この計画については後ほど説明します。

監視

ログには XNUMX 種類あります。管理者がサーバー上で収集したログと、開発者がコードから書き込んだログです。 これらは、次の XNUMX 種類のメトリクスに対応します。 システムと製品.

システムメトリクス

すべてのサーバーで動作します ネットデータ、統計を収集して送信します。 グラファイトカーボン。 したがって、ストレージ システムとしては、たとえば Whisper ではなく、ClickHouse が使用されます。 必要に応じて、ClickHouse から直接読み取ることも、次を使用することもできます。 グラファナ メトリクス、グラフ、レポート用。 開発者として、私たちは Netdata と Grafana に十分にアクセスできます。

製品の指標

便宜上、いろいろなことを書きました。 たとえば、Counts や UniqueCounts の値を統計に書き込んで、どこかに送信できる一連の通常の関数があります。

statlogsCountEvent   ( ‘stat_name’,            $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid,    $key1, $key2, …)
statlogsValuetEvent  ( ‘stat_name’, $value, $key1, $key2, …)

$stats = statlogsStatData($params)

その後、並べ替えフィルターとグループ化フィルターを使用して、グラフの構築、ウォッチドッグの構成など、統計から必要なことをすべて実行できるようになります。

とても書きます 多くの指標 イベントの数は 600 日あたり 1 億から XNUMX 兆です。 しかし、私たちはそれらを保持したいと考えています 少なくとも数年は指標の傾向を理解するため。 これらをすべてまとめるのは大きな問題であり、まだ解決されていません。 ここ数年の成果をお話します。

これらのメトリクスを書き込む関数があります ローカルのメモリキャッシュへエントリー数を減らすため。 短期間にローカルで起動される 統計デーモン すべての記録を収集します。 次に、デーモンはメトリクスを XNUMX つのサーバー層にマージします。 ログコレクター、背後の層が死なないように、多数のマシンからの統計を集約します。

必要に応じて、ログコレクターに直接書き込むことができます。

ただし、stas-daemom をバイパスしてコードからコレクターに直接書き込むことは、コレクターの負荷が増加するため、スケーラビリティに乏しいソリューションです。 この解決策は、何らかの理由でマシン上で memcache stats-daemon を起動できない場合、またはクラッシュして直接実行した場合にのみ適しています。

次に、ログコレクターが統計をマージします。 ニャーDB - これは私たちのデータベースであり、メトリクスも保存できます。

次に、コードからバイナリの「SQL に近い」選択を行うことができます。

実験

2018 年の夏に社内ハッカソンを開催し、図の赤い部分を ClickHouse のメトリクスを保存できるものに置き換えてみるというアイデアが生まれました。 ClickHouse にログがあります - 試してみてはいかがでしょうか?

KittenHouse を通じてログを書き込むスキームがありました。

我々は決めました 別の「*House」を図に追加しますこれは、コードが UDP 経由でメトリクスを書き込むときの形式でメトリクスを正確に受け取ります。 次に、この *House はそれらを丸太のようなインサートに変換し、KittenHouse はそれを理解します。 彼はこれらのログを ClickHouse に完全に送信でき、ClickHouse はそれらを読み取ることができるはずです。

memcache、stats-daemon、logs-collectors データベースを使用したスキームは、これに置き換えられます。

memcache、stats-daemon、logs-collectors データベースを使用したスキームは、これに置き換えられます。

• ここには、StatsHouse でローカルに書かれたコードからのディスパッチがあります。
• StatsHouse は、すでに SQL 挿入に変換されている UDP メトリクスをバッチで KittenHouse に書き込みます。
• KittenHouse はそれらを ClickHouse に送ります。
• それらを読み取りたい場合は、StatsHouse をバイパスして、通常の SQL を使用して ClickHouse から直接読み取ります。

まだですか 実験、しかし、結果は気に入っています。 この制度の問題点が解決すれば、おそらく完全に切り替えることになるでしょう。 個人的にはそう願っています。

スキーム 鉄分を節約しない。 必要なサーバーは少なくて済み、ローカルの統計デーモンやログコレクターは必要ありませんが、ClickHouse には現在のスキームよりも大きなサーバーが必要です。 必要なサーバーの数は少なくなりますが、より高価でより強力なものでなければなりません.

展開する

まず、PHP のデプロイメントを見てみましょう。 私たちはで開発しています git： 使用 GitLab и TeamCity 展開用に。 開発ブランチはマスター ブランチにマージされ、テスト用のマスターからステージングにマージされ、ステージングから実稼働にマージされます。

デプロイメントの前に、現在の運用ブランチと以前の運用ブランチが取得され、それらの差分ファイルの変更 (作成、削除、変更) が考慮されます。 この変更は特別なコピーファスト エンジンのバイナリログに記録され、サーバー フリート全体に変更を迅速に複製できます。 ここで使用しているのは直接コピーするわけではありませんが、 ゴシップのレプリケーションXNUMX つのサーバーが変更を最も近いサーバーに送信するとき、そのサーバーの変更をそのサーバーの近隣に送信するときなどです。 これにより、フリート全体でコードを数十秒単位で更新できるようになります。 変更がローカル レプリカに到達すると、これらのパッチがローカル レプリカに適用されます。 ローカルファイルシステム。 ロールバックも同じスキームに従って実行されます。

私たちは kPHP も頻繁に導入しており、独自の開発も行っています。 git 上の図によると。 これから HTTPサーバーバイナリ場合、差分を生成できません。リリース バイナリの重さは数百 MB です。 したがって、ここには別のオプションがあります - バージョンは次のように書き込まれます ビンログコピーファスト。 ビルドするたびに増加し、ロールバック中にも増加します。 バージョン サーバーに複製される。 ローカルのコピーファストは、新しいバージョンがバイナリログに入ったことを確認し、同じゴシップレプリケーションによって、マスターサーバーを疲れさせることなく、ネットワーク全体に負荷を慎重に分散しながら、バイナリの最新バージョンを自分たちで取得します。 次に続くこと 優雅な再起動 新しいバージョン用。

私たちのエンジンも本質的にバイナリですが、スキームは非常に似ています。

• gitマスターブランチ;
• バイナリ入力 debファイル;
• バージョンは binlog copyfast に書き込まれます。
• サーバーにレプリケートされます。
• サーバーは新しい .dep を取り出します。
• dpkg-i;
• 新しいバージョンへの正常な再起動。

違いは、バイナリがアーカイブにパッケージ化されていることです。 debファイルそして、それらを汲み出すとき、 dpkg-i システム上に配置されます。 kPHP はバイナリとしてデプロイされ、エンジンは dpkg としてデプロイされるのはなぜですか? それはそのように起こりました。 動作しますので、触らないでください。

便利なリンク：

• アントン・キリシュキンによるレポート 「フコンタクテのシステム管理者です。 どうやって？" コピーファストとゴシップについて詳しく説明します。
• ユーリ・ナスレディノフによるレポート 「VK が数万台のサーバーからデータを CLIckHouse に挿入する方法」.
• 私の報告書 「VKontakte の例を使用した成長プロジェクトのアーキテクチャ」、ただしハードウェアではなく開発の観点からです。

Alexey Akulovich は、プログラム委員会の一員として、 PHP ロシア 17 月 XNUMX 日に開催されるこのイベントは、PHP 開発者にとっては近年最大のイベントとなるでしょう。 見てください、私たちが持っている素晴らしい PC は何ですか？ スピーカー (そのうちの XNUMX 人は PHP コアを開発しています!) - PHP を書くなら欠かせないもののようです。

出所： habr.com