VKontakteの例に関する成長プロジェクトのアーキテクチャ

Alexey Akulovichは、負荷の高いPHPプロジェクトのライフパスについて説明します。 これはHighload ++ 2016の復号化です。



私の名前はレシャです。PHPで書いています。



幸いなことに、レポートはそれについてではありません。 レポートは、ネットワーク開発の回顧に関するものです-プロジェクトがどのように開発されたか。 どのソリューションがキャプテンであるか、または私たちの負荷に非常に特有であるか、私たちはストレスを経験している他のプロジェクトで使用できるものを使用しました。



始めましょう。

何について話そうか

1つのレポートですべてのことを話すことは不可能であるため、私にとって最も興味深いと思われるトピックを選択しました。 これは、データベースとそのストレージへのアクセスを開発すること、PHPを最適化することの問題、そしてその結果として私たちが何になったのか、という問題です。



小さなオフトピックとして：文字通り1か月前、VKontakteはIT専門家向けではなく10才になりましたが、Highloadも10才です。このような記念日にプログラムにレポートが受け入れられたという事実は非常に楽しいものです。

それがすべて始まった方法

これは元のスキームではありませんが、ネットワークはすぐに実現しました。 負荷と人気の増大に伴い、Nginxにフロントがあり、リクエストを処理し、Apacheに送信し、smod PHPを起動して、標準ランプであるMySQLまたはMemcachedにアクセスするときに、このような典型的なライムスタックを取得しました。 出発点として、彼から始めましょう。



そのため、負荷が増大しています。



繰り返しのユーザーリクエストがNginxと同じマシンに来ることを必要とするローカルデータを持たないNginxに負荷がかかっている場合は、十分な数がありませんでした。



Apacheの現在のクラスターサイズに対して負荷が十分でない場合、ローカルセッション、ローカルキャッシュ、同じApacheと同じPHRへのリクエストを必要とするデータを使用しないプロジェクトでは、さらに多くのマシンを配置し、すべてが機能します。 標準回路。



MySQLおよびMemcachedの場合、これはすべてのApacheが必要とする外部データウェアハウスなどであり、別のマシンを配信するだけでは機能しません。もっと巧妙で賢いことをする必要があります。



それでは、データベースの開発と一般的な拡張方法から始めましょう。 使用できる最初の、最も単純な、最も一般的な方法は垂直スケーリングです。より強力なハードウェア、より多くのプロセッサ、ディスクを使用し、ある時点でこれで十分です。 鉄片はいくつかの典型的な構成ですが、お金のために、鉄のためにそれを買う余裕があります。 無限に成長することは不可能です。



誰もがやってくるより正しいオプションは、水平スケーリングです。 より強力な鉄片を作ろうとせず、おそらく元の鉄片よりもさらに強力な鉄片を作ると、負荷が分散します。 これには、データが1つの場所ではなく1つのバスケットに保存されることを考慮に入れるために、コードの変更が必要ですが、何らかのアルゴリズムに基づいて何らかの方法で塗りつぶされます。



そのため、なんらかの方法で水平方向にスケーリングを試みるために、データの一貫性と、コードレベルでのストレージの場所と方法からの独立性を減らす必要があります。 最も簡単なことは、外部キー、結合、および1か所でストレージを必要とするその他のものの拒否です。



別のオプションとして、1つのサーバーに複数のタグを配置しない場合、それらを異なるサーバーに配布します-通常のソリューションです。 これは、サーバーごとに最大1つのテーブルの粒度で実行できます。



これで十分でない場合は、プレート自体をパーツに分割し、それらを分割して、各ピースを別々のマシンに保管します。 これにはコードのほとんどの処理が必要です。通常の選択プレートを実行することもできません。キーごとにこのテーブルのフラグメントから各シャードを選択し、どこか、中間層、またはコード内で保持する必要があります。



この時点で、さらなる成長の問題が重要になります。サーバーの数を一度増やした場合、おそらくそれを増やす必要があります。 たとえば、マシンの数を8から16に増やすたびに、これらのシャード内のデータのバランスを取り直すときに、エンジン間、MySQL間の膨大な数のデータ移行が発生する可能性が高くなります。 マシン間のこの巨大で波のようなデータの輸血を避けるために、仮想シャードをすぐに作成することをお勧めします。つまり、8個のシャードはないが、8000個あるとしましょう。最初の1,000個は最初のサーバーに保存され、 2番目のサーバーで数千など



シャードの数を増やす必要がある場合、1000個または500個のシャードをすぐには転送しませんが、1つの小さなシャードから開始できます。 彼らはシャードを動かしました、それだけです-それは新しいマシンで動作し、すでに少しロードされており、もう一方は少しアンロードされています。 この転送の粒度は、余裕があるため、プロジェクトによってすでに決定されています。 シャードの半分を一度に転送すると、通常の移行スキームに戻ります（これが許容される場合）。



エンジンをどのように分割しても、これはリレーショナルデータベースであり、普遍的でクールですが、パフォーマンスのピークがあり、より多くのパフォーマンスが必要なものがキャッシュされます。 通常のキャッシュについて：「キャッシュに行きませんでした、データベースに行きました」、私たちは話をしません。



ワークロード、特にキャッシングの問題に対処するのに役立つ、より興味深いものに移りましょう。



最初のオプションは、キャッシュを事前作成するタスクです。 いくつかの種類のコードが競合する場合や大量に存在する場合に、データベースにデータを同時に送信すると便利です。 ある人が自分の壁に投稿を投稿したとしましょう。これに関する情報はフィードで友人に送信されています。 これを行うと、テープを形成するすべてのコードがすぐにキャッシュに突入します。キャッシュにこの投稿はなく、コードはデータベースに送られますが、これはあまり良くありません。 多数のコードが同時にデータベースに忍び込みます。



何ができますか？ 投稿を作成した後-データベースで、投稿が表示されたフィードにメッセージを送信した後にのみ、すぐにキャッシュにエントリを作成できます。 テープ形成コードがキャッシュに格納されます-レコードがあります。 基地にはもう行きません。基地は使用されません。 キャッシュに十分なメモリがある場合、再起動しません。 読み取りのためにデータベースにアクセスすることは一切なく、すべてがキャッシュから取得されます。



データベースの負荷を減らすもう1つのオプションは、期限切れのキャッシュを使用することです。 これは、カウンターの同期処理であるか、より長く保存されるデータです。 ポイントは何ですか？ 場合によっては、ビジネスロジックは最新のデータを提供しないかもしれませんが、データベースへのこの旅行で保存します。 ユーザーのプロフィール写真を考えてみましょう-ユーザーがそれを更新した場合、すぐにキャッシュを受け取ることができます。データベースから更新されるか、数秒でバックグラウンドで更新できます。



3番目のオプションは、さらに大きな負荷に関連付けられています。 プロフィールに友人とのブロックがあると想像してください。 アバターと名前を取得したい場合は、データベースに6回アクセスし、それぞれのデータを取得する必要があります。この旅行の後、受信したデータをキャッシュに保存するだけであれば、ほぼ同時にデータが洗浄されます。



この負荷を何らかの方法で削減するために、プロファイルキャッシュにデータを同時に保存するのではなく、数秒プラスまたはマイナスすることができます。 同時に：私たちが再び来たとき、ほとんどの場合、データはまだキャッシュに残っています。 ストレージのランダム性の範囲で、TTL時間の負荷を分散します。



別の方法は、さらに大きな負荷がかかると、基地に到着したときですが、彼女はできませんでした。 2番目のリクエストが到着した場合-キャッシュにデータが存在しない場合、データベースに再度アクセスします。それまではできませんでしたが、 再びできません 。落下傘部隊の負荷により悪化し、消滅する可能性があります。



これを防ぐために、データベースにアクセスする必要のないフラグをキャッシュに保存することができます。 リクエストはキャッシュに到着し、キャッシュにエントリはありませんが、「データベースに移動しない」チェックボックスがあり、コードはデータベースに移動せず、コードブランチに沿ってすぐに実行され、不可能であるように、リクエストはデータベースに移動しません-いいえタイムアウト、期待、およびすべては、ビジネスロジックで許可されている場合は問題ありません。 落ちないでください。ただし、特定の負荷なしで少なくともいくつかの答えを与えてください。



いずれにせよ、システムにキャッシングが導入されている場合、このキャッシングは永続的なストレージシステム、つまりデータベースシステムに統合されません。 検証の問題があります-コードがうまく記述されていない場合、キャッシュから古いデータを取得するか、キャッシュに何か問題がある可能性があります。 これにはすべて、より正確なプログラミング手法が必要です。



負荷が増大したときに何をすべきか、そしてシャードできない



このプロジェクトには、MySQLがクラッシュに至るまで対処できなくなった状況がありました。 Memcachedは過負荷になっていたため、大量に再起動する必要がありました。 すべてがうまく機能せず、成長する場所がありませんでした。その時点で他のソリューションは存在していませんでした-それは2007-2008でした。

このような負荷でプロジェクトはどのように進みましたか？

動作しないMemcachedを、少なくともこのような負荷に耐えるソリューションに書き換えてから、オンとオフを繰り返すことが決定されました。 ターゲティングなどに関連するエンジンが登場しました。 汎用スーパーソリューションから負荷を転送しますが、汎用性があるため、機能はほとんどないが、ユニバーサルソリューションよりも優れた、狭く調整された小さなソリューションに非常に高速に動作しません。 さらに、これらのソリューションは、プロジェクトで使用される要求の負荷と種類に応じて、その用途に合わせて正確に調整されます。



これは現在使用されているエンジンの短いリストです。







実際には、それらの多くがあります。キュー、リスト、リボン、さまざまなエンジンで動作するエンジンがあります。 リストエンジンが何かのリストを処理しているとしましょう。 彼は他に何も知らず、リストに取り組んでいますが、うまくやっています。



どのように見えましたか？



その瞬間、外部データへの2つのコネクタがありました。 Memcachedへのコネクタがあり、MySQLへのコネクタがありました。 エンジンとの相互作用のプロトコルには、Memcachedプロトコルが選択され、エンジンはMemcachedのふりをしました。 同時に、すべてがすでにシャード化されており、同じタイプのシャードのグループがクラスターに結合されました。 コードのビジネスロジックのレベルでのクラスター全体へのアクセス。



次のようになりました。







つまり、「その名前のクラスターへの接続を許可します」とすると、リクエストの一部でその接続を使用するだけです。



反対に、通常はMemcachedのクラスターとエンジンのレベル、またはMemcachedのふりをする再設計されたエンジンの場合、リクエストは次のようになります。







標準ソリューション、通常のキャッシュ。



独自のプロトコルを必要とするより具体的なソリューションがある場合、そのような庭をフェンスする必要がありました。







単純なキーを作成するだけでなく、キーに追加のパラメーターを縫い付けます。エンジンはそのキーを解析し、追加の要求パラメーターとして使用できます。 これは、標準プロトコルをサポートし、何もやり直さないために必要でしたが、エンジンはいくつかの追加パラメーターを取ることができました。



多数のパラメーターを必要とするさらに複雑なエンジンの場合、クエリは次のようになります。







これはすでに複雑な要求です-特別な区切り文字、オプションのブロックがあります。 しかし、すべてうまくいきました。 これを自分の手ではなく、何らかの種類のラッパーを使用してそのようなリクエストを作成する場合、それはかなり良いことです。



どのように見えましたか？







コードはクラスターに直接移動しません。 トポロジをコードに保存する必要はありません。プロキシはこれを行いました-これらはコードを使用して各サーバーで動作する特別なエンジンでした。 つまり、すべてのコード接続はローカルエンジンに対して行われ、プロキシはクラスターストレージトポロジを考慮して管理者によって既に構成されているため、外出先で変更される可能性があります。 クラスターの場所、クラスター内にあるピースの数、クラスターでどのような作業が行われているかは気にしませんでしたが、それは問題ではありません。 プロキシに接続すると、プロキシが機能します。 同時に、外部データが必要な場合、1つのクラスターはプロキシを介して別のクラスターに移動できます。

クラスター内のシャードを選択する方法

2つのオプションがあります： ハッシュに基づいてキー全体を選択するか、数字ではなく最初の数字、つまりキー文字列の数字を探し、次の操作のキーとして使用します -剰余をモジュロします。 標準的な多かれ少なかれソリューション。



おおよその方法で動作する一般的なソリューションは、Twitterのtwemproxyです。 誰かが試したことはないが、MemcachedまたはRedisの大規模なインストールを使用している場合は、便利になるかどうかを確認できます。



これはすべて発展し、成長しましたが、ある時点で、私たちを押し込もうとする有限数のチームという形でプロトコルの制限が生じました。 パラメータが多数あるこれらの複雑なクエリ-かなり混雑しており、キーの長さには250バイトの制限があり、文字列、数値というパラメータがありました。 それはあまり快適ではなく、テキストプロトコルの制限もあり、バイナリプロトコルもありませんでした。 彼は、応答のサイズをメガバイト単位で制限し、スペース、改行、その他すべてのバイナリデータをエスケープする必要が生じました。



これにより、バイナリプロトコルへの移行が決定されました。



最も近い類似体はprotobufです。 これは、事前定義されたスキームを持つプロトコルです。 これらは、msgpackなどのようなスキーマレスプロトコルではありません。

事前にスキームに書き込まれ、プロキシのように構成に保存されます。 それに基づいてクエリを実行できます。 エンジンは、このスキームへの段階的な移行を開始しました。 Memcachedプロトコルの問題の解決に関連する問題に加えて。 これから有用な利点が得られました。たとえば、TCPプロトコルからUDPプロトコルに切り替えたため、サーバーへの接続数が大幅に節約されました。 エンジンが上昇し、30万の接続がエンジンをノックして絶えず保持する場合、エンジンはあまり冷たくありません。 これらがUDPパケットであり、すべてがはるかに優れている場合は、はるかに優れています。 マシン間の接続の暗号化。これは個人的には最も楽しいことです-非同期相互作用。



通常、同じPHPや他の多くの言語で通常のクエリはどのように機能しますか？



外部データベースにリクエストを送信して待機し、実装に応じてワーカー、スレッド、またはプロセスをブロックします。 この場合、ローカルプロキシにリクエストを送信します。これは非常に高速であり、動作します。 実行のスレッドはブロックされません。プロキシ自体は非同期で、コードが別のクラスターに移動し、応答を待って受信し、しばらくの間ローカルメモリに格納します。



コード内の応答構成への回答が必要な場合、すでに他の要求をいくつか作成し、それらも待機して完了しました。 プロキシに行きます。「ここでそのリクエストに対する答えをください」、ローカルメモリからコピーするだけで、すべてが迅速かつ非同期に動作します。 これにより、シングルスレッドPHPでかなり並列化されたコードを記述できます 。



エンジンに移行した後も、MySQLはまだありますか？ エンジンはすでに多くの異なっています。 いくつかの場所では、それらの多くがあります。それらは主に内部管理者に関連するもので使用され、外部からアクセスできない無負荷インターフェイスを備えています。 それは動作します-触れないでください、それは皆に合います。 壊れて大丈夫ではありません。



残念ながら、まだ書き直されていないものがあります-それらはストレスを経験しないので、時間があればいつか書き直します。 これは、次のようなプレート名につながります。







「 正直なところ、これが最後のタブレットになります。」 この年またはその年に作成されました。 彼女は負荷を感じません、彼女はそうです、私たちはそれに耐えて大丈夫です。 私はそのようなものを燃やし、それらを遺物として取り除きたいのですが、まだMySQLがあります。

では、PHPについて少し話しましょう。

説明されている特定のエンジンがあります。 さて、PHPでの生活方法について 。



PHPは遅いので、誰にも説明する必要はありません。動的な型付けが弱いからです。

また、彼は非常に人気があります。 この言語で作成されたプロジェクトは、コードを非常に迅速に記述できるため、PHPのプラスです。 コードベースのサイズはすでに書き換えがそれほど現実的ではないので、この言語で生きています。 私たちはその利点を活用し、マイナスを平準化しようとします。



各プロジェクトは独自の方法で、PHPの制限を回避しようとします。 誰かがPHPを書き直しており、誰かがPHP自体に苦労しています。

私たちの味方

PHPで毎秒100万のリクエストを処理する方法は？ 100500台のサーバーがない場合。 まさか。

鉄の量が無限でない場合、ほとんど不可能です。



VKontakteプロジェクトでは、ワークロードの開発が行われました。PHPからC ++へのトランスレーターが作成され、すべてのサイトコードがキャッシュされたコードに変換されます。 彼は何をしますか？ PHPのすべてのサポート、つまり、KPHPの登場時にプロジェクトで使用されていた言語のレベルは実装されていません。 それ以降、いくつかのことが登場しましたが、一般的には古いコードのレベルで機能しています。 それ以来、ほとんど登場していません。



何が行われていますか？ すべてのコードは彼にブロードキャストされます-静的アナライザーがあり、彼は型を推測しようとし、変数の使用を分析します。 変数が常に文字列として使用される場合は、コード内にstd文字列が含まれている可能性が高くなります。 数値の配列として使用される場合、intのベクトルになります。 これにより、システムコンパイラは結果のコードを非常に適切に最適化できます。



型推論からのささいな些細なこと：変数が非常に奇妙に使用されていることをトランスレーターが見ると（別の型が指定されている関数に渡されるか、別の型の配列に渡される）、警告をスローできます。新鮮なコードを収集する開発者は、ここに何らかの疑いがあることに気付くでしょう。正しいコードがそこにあるか、コンパイラにとっては単なる誤検知であるかどうかを確認する価値があります。



サイトがKPHPに翻訳されたとき、静的コード分析のために多数のエラーが見つかりました。



なに？ PHPコードからC ++コードを取得し、追加のライブラリでコンパイルし、通常のHTTPサーバーバイナリを用意しました。アップストリームとしてNginxの背後で実行されるだけで、追加のレイヤーやApacheなどのラッパーなしで動作します。



これはありません。車が必要で、たくさんのプロセスが始まり、分岐点がありますが、問題ではありません。



専用のエンジンがあり、KPHPエンジンに変換するPHPコードがあります。

私たちの生き方（人生の例）

• 通常のini、json、ymlなどのファイルで構成ストレージを使用するのは誰ですか？
• そして、誰がコードの構成を使用しますか？または、ソースコードに保存するレベルでコードを使用しますか？もう少ない。
• また、要求に応じて現在の構成を送信できる外部構成ストレージシステムを使用しているのは誰ですか？もっと。

私たちのオプションは3番目のオプションです。外部ストレージを使用すると、どのようになりますか？ Memcachedに似ています。Memcachedプロトコルが含まれていますが、マスターとスレーブに分かれています。



マスターは書き込みノードであり、スレーブはコードが使用される各サーバーでローカルに実行されるエンジンです。構成を受け取ると、コードは常にローカルレプリカに送られ、そこにコードがあります-マスターからすべてのスレーブに配布されます。同時に、スレーブにはデータの陳腐化に対する保護があります。データがすでに古い場合、コードは開始されず、設定で重要なことが変更される可能性があります。古い設定を行うよりも、やらないほうが良いでしょう。



これにより、構成の読み取りをほぼ無限にスケーリングできます。つまり、各サーバーで独自の個人構成を取得します。同時に、クエリ伝播の高速性は、動作するすべてのマシンで数秒のほんの一瞬です。



次のオプション。



誰がそのようなリクエストが何をもたらすことができるかを言うことができます：Memcachedへの定期的なリクエスト、それはサイトに対して実行され、定数キーを持ち、何らかの変数ではなく、同じことだとしましょう。本当に悪いことが起こる可能性はありますか？サイト全体を配置します。



重い負荷ですべてのヒットをヒットする1つの平凡なリクエストがすべてを壊すことができるのはなぜですか？シャーディングアルゴリズムに関係なく、定数キーはハッシュによって無効にされました-最初の番号を取得します。何らかの方法で、同じクラスターの同じシャードに落ち、リクエストのボリューム全体がそこに行きます。エンジンが悪くなり、転倒するか、減速し始めます。負荷はプロキシによって他のマシンに分散されますが、一般にこのシャードにとっては悪くなり、キューを蓄積するプロキシは悪くなります-タイムアウトがあり、このシャードのリクエストを処理するための追加のリソースがあり、プロキシはリンクであるため、プロキシが悪くなり、サイトがクラッシュしますサイト全体のリンク。これは難しいですが、非常に不快です。



これについて何ができますか？



最初に、そのようなコード、通常の解決策を書かないでください。



しかし、そのようなコードを書くことができないが、したいときはどうすればよいでしょうか？



このために、キーのシャーディングが使用されます-たとえば、出席のカウントに関連するもののために-いくつかのカウンターの増分を設定します。インクリメントを1つのカウンターではなく1万のキーで塗りつぶすことができます。カウンター値を取得する必要がある場合は、すべてのキーを複数取得してコードを追加するだけです。 N番目のシャードに負荷を分散しましたが、少なくとも落ちていません。



負荷がさらに大きく、キーをそれ以上スケーリングできない場合、または望んでいない場合-超正確な値は必要ありません。たとえば、1/10の確率でカウンタをインクリメントし、値を読み戻しながら、結果の値を単に乗算しますこの確率係数を計算し、個々のヒットをカウントした場合に得られる値に近い値を取得します。特定の台数の車に負荷を分散しました。



別のオプション-サイトの速度が低下し始めました。



一般的なMemcachedのクラスターの負荷が増加していることがわかります。これは、すべてを一列にキャッシュするシャードの集まりです。それをどうしますか？誰のせいですか？



この場合、一般的なクラスターで全体の負荷が増大しているため、不明です。明確ではありません。リバースエンジニアリングのコミットに対処する必要があります。変更の履歴を確認してください。



ここで何ができますか？ユニバーサルクラスターは、特定の小さな断片に分割できます。猫の友達の写真が欲しいので、相対的に言えば、小さなクラスターを1つにしてください。それだけを使用し、中央のクラスターには負荷をかけないでください。このクラスターの負荷が大きくなると、それが彼であることがわかります。どの機能がロードされたかを知っていると同時に、このクラスターの負荷は他の全員に影響しません。つまり、たとえ完全にクラスター全体に落ちたとしても、他のクラスターでは誰も気付かないでしょう。



別のオプション。



前の質問について-「落ちなかった」。たとえば、たとえばメッセージの一部が該当し、人がシール付きのビデオを見る場合。彼がこの猫を友人のPMに送らなければ、問題があることすら知りません。また、音楽の聴取、ニュースフィードの視聴などにも成功します。それはサイトのその部分で動作しますが、何が壊れているかに依存しません。



3番目のオプション。



PHPから500番目のエラーがあると仮定します。つまり、NginxのフロントがアップストリームのKPHPからエラーを取得するとします。テストされていない新しい機能を展開しました。どうする



サイト全体を処理する共通のKPHPクラスターがある場合-明確ではありません。



KPHPをクラスターに分割している場合：API用、壁用などに分けて考えてみてください。また、「これが問題です」ということもわかります。どのメソッドグループを監視し、誰が責任を負っているのかを把握しています。さらに、これが大規模な問題ではなく、すべてが本当に壊れており、1回限りのケースが単一の障害である場合、Nginxでは別のKPHPサーバーにリクエストを再度送信する機会があります。ほとんどの場合、これが1回限りの問題である場合、繰り返しリクエストが渡され、しばらく待機した後、その人は正しい適切に処理された応答を受け取ります。

結論

各プロジェクトは、成長とともに何らかの負荷を経験しており、現時点で適切と思われる決定を下しています。使用可能なソリューションから選択する必要がありますが、ソリューションがない場合は独自に実装する必要があります。これらのソリューションと戦うためにコミュニティで使用されている標準的な一般的なアプローチを超えてください。しかし、プロジェクト内ですべてがうまくいけば、すべてが十分である場合、コミュニティからのいくつかの既成のソリューション、テスト済み、テスト済みのアイデアを使用することをお勧めします。ない場合は、誰もが自分で決定します。



レポート全体のポイントは、レポートをプロジェクトのすべての部分に広げることです。



よろしくお願いします。







レポート：VKontakteの例に関する成長プロジェクトのアーキテクチャ。