RabbitMQを準備する101の方法とパイプラインアーキテクチャについて少し

パベル・フィロノフ（彼がポジティブテクノロジーズで働いていたパフォーマンス中）

このレポートでは、RabbitMQとPipelineアーキテクチャの共通部分と、それが当社の業務にどのように関連しているかについてお話したいと思います。



まず、プロローグとして少し。 これは素晴らしい部分です。







オフィスで平日に展開するシーンは、非常に楽しい反射に私たちを導きます。 ゴージャスなタスク、新しいシステムに直面しています。 新しいシステムを開発する要求として、エンジニアの心をそれほど興奮させません。 古いものを修復したり、古いものを適応させたりするのではなく、ある意味で実質的にゼロから何かを作成すること。



このタスクには、一連の問題が伴います。





問題番号1。 スケッチを続けます。



これはあなたにもたらされます：







「要件はどこにありますか？」と尋ねます。



彼らはあなたに次のように示します：「さて、彼らはここにいる！」（スライドを参照）。



これは、新しいシステムの要件である場合があります。 ほとんどすべての人がそのような処方で作業しなければなりませんでした、あなたはこれに関連する問題を理解しています。 しかし、時にはあなたはこれから始めなければなりません。 始めましょう。



自然言語のNLP処理に関する素晴らしいレポートがありました。ここでは多くの助けになります。この一貫したテキストからシードを選択する必要があります。 私はこのようにしようとします：







何か重要なもの、正しい選択をするのに役立つものを強調し、求められているシステムを正しく構築します。



私が特に注目したいのは、「イベント」という言葉です。 ある意味では、違いを示すために、「リクエスト」という言葉とリクエストを対比したいと思います。 リクエストについて話すとき、反対側にいる人は常にリクエストに関連付けられています。リクエストを送信した人、非常に短気な人、ロボット、ブラウザ、プログラム、彼は私たちからの回答を待っています。 彼はすぐに私たちからの答えを待っています。 これが彼の最大の欲求です。答えを手に入れるには、すぐに手に入れましょう。 これはクエリについて話すときです。



イベント処理について話すときは、ここで少し異なるパターンが適切です。 このせっかちなロボット、つまりリクエストを送信した人はいません。 単にイベント、ログ、メトリック、統計を送信するシステムがあります-かなり大量のネットワークトラフィック...彼らは私たちからの質問に即座に答える必要はありません。 彼らは私たちに、それらをたくさん、そして迅速に処理し、それらを異なる方法で処理できるように頼みます。 これは最も苦痛な場所です-何が求められるかを事前に予測できない場合があります-何かを集約し、強度を計算し、何かを要約し、おそらく最終的にどこかに保存します。 しかし、最も興味深いのは、多くの人が問題の解決に着手し、積極的に開発しているという事実に直面していることです。



これが発生することをすぐに警告されたら、これを要件としてシステムのアーキテクチャに入れることをお勧めします。そうすることで、要求されることを柔軟に変更および更新できます。



「さまざまなソースから」は非常に微妙なため、さまざまな入力プロトコルをサポートできる必要があります。



「プロトタイプを作る」-彼らはそれをとても気に入っています。彼らはそれをとても気に入っているので、すぐに何かをして、すぐに何かを見せます。 プロトタイプを破棄することに同意する人はいますか？ そして、誰が生産にそれらを入れなければならなかったのですか？ これも問題であり、準備する必要があります。 そして、そのような機会があれば、この問題をすぐに解決することをお勧めします：プロトタイプを作成し、それを捨て始めますが、すぐにそれを行うことはできません-何かを取り、すべてをより完全なものにすばやく書き直すことは非常に困難です。 ほとんどの場合、それは部分的に交換する必要があります-少し無生物のシステムがあり、その一部を引き裂き、機能的に完全に同等であるがより完全な他のものと交換します...



「それはどこでもうまく機能するはずです」-私はそれを強調することさえしません、それは理解できます。 「どこでも」について-難しい瞬間。 異なるオペレーティングシステムの開発に直面したのは誰ですか？ これは大きな問題であり、意思決定の範囲を大幅に制限する可能性があります。また、設計時にすぐに考慮する必要があります。



私たちは穀物を隔離しようとしましたが、今では非常に積極的に依存しています。 次の問題が発生するからです。







彼らはしばしば私に駆け寄って来て、尋ねます：「教えて、どうやってこれを思いついたの？」 私は質問者を見て、次のように言います。「ご存じのとおり、私はごくわずかなことを思いつきます。実際に彼らが私にもたらすどんな仕事でも、すぐにたくさんの解決策があります。 私の主な問題は、解決策を考え出すことではなく、このタスクに最適なものを選択することです。 私は通常、私たちのためにすべてがすでに発明されているというジョークで返信します。エンジニアとして、私の意見では、現代のエンジニアは、正しい情報に基づいた選択をする必要があり、それは非常に最初のステップでも遭遇します。



システムを作りたい。 彼女は建築が必要です。 いい言葉。 通常は写真で表現されるため、ここでは、さまざまなシステムが構築される最も標準的なアーキテクチャパターンのいくつかの写真を提示しようとしました。







皆さんそれぞれが、このスキームの一部に自分自身を送ると思います。 誰かが言う：私たちは左上隅にあり、私たちは右上隅で働いており、誰かが中央で働いており、誰もが自分自身を1つまたは別の写真に関連付けています。







特にこのレポートでは、イベント処理の興味深い方法およびアプローチとしてパイプラインアーキテクチャについて説明します。 リクエストへの回答に対する他の欲求がなければ、非常に抽象的な意味で、取る必要があるのは、一連の処理を通してデータを実行し、最終的にどこかに保存することだけです。 そして、できるだけ早くこれを行うことをお勧めします。 ここでは、「できるだけ早く」詳細な分析が必要です。



通常、どこで減速しますか？ 通常、ボトルネックはどこにありますか？ 最も基本的な基準は2つあります-CPUバウンドプロセッサとI / Oバウンド出力です。 そして、驚くべきことに、私たちはしばしばネットワーク上で休まないことがあります。時にはギガビット、時には10ギガビットでさえも休みません。 これは、「リクエスト/レスポンス」ベースで構築されたアーキテクチャで特に顕著です。リクエストを送信し、答えを待っています。 悪い場合-良い方法で休んでいるだけです-どういうわけか別のタスクに切り替えて、それを実行してから、戻ろうとしています。 今、あなたが待つ必要がなければ、それは素晴らしいことです-あなたは別のタスクに切り替える必要さえありません、あなたはあなたの仕事の一部をして、それを渡しただけです。 これに関連する期待も遅延もありません。すでにプロセッサにできるだけ多くの休息を試みて、スクランブルエッグを調理するためのフライパンに変えてください。



それがどこから来たのかを思い出せば...たとえば、同じ考えが存在する自動車業界からです。 各セクションはその役割を実行し、結果を渡します。 あなたがそのような選択をしたと仮定して、私たちは問題を解決し、アーキテクチャを構築するために、このテンプレートが最も適していると考えました。



質問2：このアーキテクチャをどのように実装しますか？ どういう意味ですか？ 異種プロセッサをバンドルするには、どのミドルウェアが必要ですか。







ここで選択がロールオーバーします。 これだけではありません。スライドに収まるのはそれだけです。



今、これらのシステムのそれぞれの長所と短所について話し、RabbitMQの方向で具体的に選択された理由を具体的に正当化する時間がありそうにありません。 さまざまなオプション、最も面白いもの、左上のものも考慮しました-すべてを手動で取得し、ソケットだけで書く-そのような実験もありました。 しかし、最終的には、すべての実験中に、このメッセージブローカーに特化した選択が行われました。







メモリー内データベースを比較したDmitryのレポートがとても気に入りました。 彼は正しい工学的アプローチについて話した-測定、広告を信じない、あなたはそれを測定しなければならない。 彼は別の重要な事実に言及しました。測定する前に、まずそれを絞り込み、自分の中から測定するデータベースを選択する必要があります。最初に検索を絞り込む必要があります。 通常、彼らは機能に基づいて、誰が何を知っているかを反発します。



ここで別の問題を提起し、注意を払う価値があると言いたいと思います-この技術はどれくらいの期間存続しますか？ 現代のテクノロジー市場がどのように発展しているのかを見ると、ちょっと怖い気がします。ある朝、ニュースフィードを開き、「今週学ぶべき7つの新しいSQLデータベース」という記事を見るのが怖いです。 彼らは非常に速く表示される場合、彼らはほぼ同じ速度で死に始めます。 したがって、選択する際に、ある程度の確率で、ある程度の自信を持って、もう少し長生きする技術に依存したいという要望があります。 この観点から、RabbitMQは製品としてではなく、AMQPプロトコルに依存するテクノロジーとして興味深いものです。AMQPプロトコルは、既に十分に活用されている下位層です。







AMQPプロトコルの公式Webサイトの公式ユーザーを以下に示します。 ここでMicrosoft Azure Service BusとGoogleを見るのは非常に興味深いです。



一般に、Googleは、RabbitMQに基づいてSQSデータベースサービスを単純​​に構築するという公式発表をリリースします。



Microsoft AzureはAMQPプロトコルを実装するだけで、明らかに独自の実装があるようです。



VMwareはAMQPプロトコルとRabbitMQシステムの創設者の1人であり、ソリューション内で非常に積極的に使用しています。



つまり これはそのような広告スライドです。 彼がいつ手伝うか知っていますか？ 私も舞台に立って、あなたは利害関係者であり、あなたは会社の所有者であり、投資家であり、あなたは今それのためにお金を与えようとしている、そしてあなたはお金を与えると確信する必要があると想像してください。 これらのスライドは大いに役立ち、すぐに使い慣れた名前が表示され、気に入っています。 したがって、広告目的で正確に使用できます。



基本的な定義と用語として、次に必要になるいくつかの写真。







最初の図は、AMQPプロトコル内およびRabbitMQシステム内の基本的なエンティティを初めて使用するユーザー向けです。 左-パブリッシャー-ライター-このキューに何かを書き込むシステム。 RabbitMQ内では2つの別個のエンティティが区別されます。最初の-円-交換機-交換-エントリポイント。通常、すべてのシステムメッセージがそこに発行されます。 2番目の重要な要素は、これらのメッセージが格納されるキューであり、それらの間のリンクはバインディングです。これにより、さまざまなキュー間でメッセージをかなり柔軟で興味深い方法でルーティングできます。



将来的には、そこにどのようなルーティング方法があり、どの方法がどのような場合に使用できるかについてもう少しお話しします。 とりあえず、このようなリンクが存在するという事実にのみ目を向けてください。 この観点から、パブリッシャーは自分がどのキューに書き込むかを常に把握しているわけではありません。イベントを書き込み、統計を書き込み、メトリックを書き込み、ログに実際に存在するキューの数を書き込みます。彼は本当に知る必要はありません。 作家の観点からすると、非常に便利です。



一方、読者は、どこから具体的に読むかを知りたいので、特定のラインナップに執着します。



そして、これらのQキューを異なるハンドラーを相互に接続するバッファーとして使用すると、スライドの下部に画像が表示されます。 これは、パイプラインアーキテクチャ、パイプラインタイプのアーキテクチャを表す非常に簡単な方法です。異なるプロセッサを通過する生データのストリームがあり、各プロセッサ間で実際にこのキューがあり、各作業を実行して、データを実行します。 、データベース。 この写真とその表記に、私は将来戻ります。



簡単に歩いてみましょう。 何が得られますか：

• 非同期処理-何も期待する必要はありません-ジョブを実行し、結果をさらに送信しました-非常に素晴らしい。
• その場でハンドラを簡単に追加できます。 はい、実際には、その場で。 その場でシステムを再構成するのは非常に簡単です。 挿入する必要があります
  
  パイプラインの途中に何か新しいものがあります。 再起動せずにこれを行います;さらに、時々、ライターもリーダーもこれに気付かないことがあります。 ライター缶
  
  彼が別の場所で書き始めたことに注意してください。
• 柔軟なルーティング。 実際、作家は自分がどこに書いているのか実際にはわからないので、次のように1ターンで、一度に2つずつ書くように設定できます。
  
  これらのキュー間のシャーディング戦略のある種のスケーリングのある種の。 私たちは間違いなくいくつかの戦略について話します。
• 便利なデバッグは非常に重要な要素です。 あなたが建築家である場合、コードを書いている間、システムを設計するとき、あなたは何を考慮しようとします
  
  ユーザーはこれをプログラムする必要があります。つまり、デバッグする必要があるため、便利で既製のツールを提供する必要があります。 最も
  
  便利なツール-キューからすべてのメッセージを即座に取得してコピーできます。コピーを取得するだけです。 これにより、非常に簡単になります。
  
  便利なデバッグの例として、ほとんどすべての状況を再現します。
• リーダーとライターのスケーラビリティ-キューから複数を読み取り、キューに複数を書き込むことができ、ほとんど常にオンザフライで追加できます。
  
  特にロードされたシステムの場合、非常に快適で重要な事実です。
• 有用な作業に加えて、追加の負荷がかかることを忘れないでください-異なるハンドラー間でデータを転送する必要があります
  
  キューブローカー自身が負荷に対処し始めるという事実に遭遇する可能性があります。 重要な要因は、彼が少なくとも自分で
  
  このRabbitMQは非常にうまく機能します。
• 別の良い点は、再起動と障害に対する抵抗です。 特定の期間でキューの内容全体をディスクに書き込むモードがあるため、
  
  たとえば、ノードが誤って再起動したり、システムに大量のデータがあり、それを求められるなどの不快な状況から身を守ることができます。
  
  何らかの種類のmantainesの理由で再起動します。 同時にデータを失わないという事実は非常に楽しい瞬間です。

あなたが利害関係者であれば、おそらくこれが私の報告書の終わりになるでしょう。 私はすべてを話し、私たちが何をするかを言ったので、数人年、無制限の量のコーヒー、クッキーをお願いしたいと思います。私たちはあなたのためにそれを作ります。 しかし、ここで、結局のところ、わずかに異なるタイプの会議。 まず第一に、エンジニアがここに集まり、前に言った言葉を注意深く聞いて考えます。 問題はどこにありますか？ 問題なくしてはいけません。」



これらがユーザーにとって本当に機能する負荷の高いシステムである場合、問題があるはずなので、レポートの2番目の部分に進む準備ができています。



彼らが問題を持ってあなたのところに来たとき、何をすべきか。 思いついたのはナンセンスです！」



まず、パニックにならないでください。 あなたが選択した場合、それは最初に認識され、最後までそれを維持します。 お気に入りのコーヒーを飲みながら、エンジニアを見て、問題を解決し始める必要があります。







もちろん、すべての問題ではないいくつかの問題について、私たちが調べて、どの特定のソリューションを選択したかを説明したいと思います。



最初の問題は帯域幅です。 システムのスループットはその構成に依存することがわかりました。 異なるルーティングを提供する交換タイプ：







サブスクライブをパブリッシュするだけで、すべてのキューに分散できるものもあります。 それらのいくつかは、ルーティングキーに応じて、単に行で、「だから、赤-このキューに、緑-このキューに、デバッグログ-このキューに、警告ログ-​​このキューに」などと言うことができます。 これは、たとえばDirectです。



トピック-より柔軟なルーティング、より複雑な、マスクによるルーティングを可能にします。たとえば、アスタリスク、ラティスを使用します。 機能面では非常にうまく機能します。 帯域幅の面ではあまり良くありません。 内部には、より複雑なデータ構造が存在します。



RabbitMQの作成者による興味深い記事があります。これは、プレフィクスツリーまたは非決定的な有限状態マシンを選択した期間です。 彼らは最良と考えたものを選択しましたが、とにかく、そのような柔軟なルーティングに焦点を当てると、必要な特性に到達できないため、これを考慮する必要があります。



4番目の交換はConsistent-Hashです。 彼は他の人よりもさらに良い行動をします。 もっと複雑に思えますが。 明らかに、ある種のセグメンテーション、シャーディング、キューを選択するための複雑なアルゴリズムがあります...利点は、それが数値で機能することです。 最初の3つはルーティングキーとして文字列を使用し、最後の3つは数字を使用します。 これにより、彼はいくつかの余分なバーを獲得できます。



私はこれらの測定値を取得しました...それは平均的なマシンであると考えます。追加の設定はしませんでした。apt-getをインストールした後、そのように動作します。 一般的に言えば、あまり良くありません。 1秒あたり35,000メッセージ（1秒あたりのメッセージ数）、まあ、どういうわけか少し速くしたいと思います。



このような低い数字に関連するものは何ですか？ 実際、多くの人が知っているテクニックを使用していますが、何らかの理由で適用する人はほとんどいません。 バッチ処理。







同じ作業を何度も行う必要があることがわかったら、1つのイベントだけでなく、パケット全体、ブロック全体、パック全体を処理してみませんか？ たとえば、KafkaがZeroMQから行うように。 このために、彼らは笑います。 彼らは素晴らしいです、彼らは顧客のためにいつの間にかバッチ処理をします。 一度に1つずつメッセージを公開し、それらがデータバス上をどのように飛んでいるかを見ると、すでにバッチで飛んでいると思います。 したがって、すぐにスループットのかなり良い基準が得られます。



それは私たちの選択ではないため、反対方向のスマイリー。 私たちは彼らに満足していますが、それは何も与えてくれません。



自分でやってみましょう-今回はそれほど難しくありません。 2つ目は、パッケージの実装を独自に行ったため、パッケージの管理を開始します。パッケージに含めるメッセージの数、入力する時間です。 ZeroMQのKafkaの場合、これがドライバーの奥深くにあり、自分で実装することが常に可能であるとは限らない場合、独自の実装を行うことで、非常に柔軟かつ適切に管理できます。



そして非常に否定的な笑顔-私たちは私たちの遅延を増やします。 , , , , .



, , - . request response critical, 10 , , , , .



, – , , – , .







– , . 35 , , . , . , 256 , 1 , . .



, 30 , - . : , 10- . loopback-, , - . , – . . つまり 10 . - , , , . , , , .







. . . , , . ? , , . . , , , ? ? . – . , . , , . - . . , , - , , , , , .. – . , – .



, … , , , .. , ? つまり .







, :

• – . , , , .
• – . , , .
• – , ,
  
  , , .
• – . . ,
  
  . , , . , . ,
  
  , .

– ?

1. : ? . , ?
   
   , , - , … , ,
   
   . , . .
2. 第二の瞬間。 . , , ,
   
   . , , ? -
   
   2 , , , .
3. . RabbitMQ flow control. ,
   
   . «, !».

, , Filter A. . , , 10000 .



, --. 10 – , - - . RabbitMQ flow control . . , , , , , - .



, . . , . , - , . - , , , . , , – . , . UDP, – . TCP, . , – .



. .







2 . – , Stateless filters. Filters – , - . , , , . , – . , , , . , , , . – .



, – Stateful filters, , .



. . , – . , . Round-robin' – – . - , , , , , , , – . - , . -, . , 1 – , 2 – . - – Router, . . , , . . exchange' RabbitMQ , , .







Statefull filters. .



-, , , . - . - - . , . , , - , - , . , , .



, , . – , . , . , . , – . – . , , , , , , .







, (), ?



, , , , .



– m, hash-, N – . , , . . ? N – . . , - . , , , – hash-, hash-. , - , , , .



, . RabbitMQ 2 Sharding plugin'. – , . , , , , .



, – consistent-hash-exchange – , , , , , . , , .



, . 2 , , , :







, , , , . . -, , , .



, . , . , .

— HighLoad++ . 2016 — HighLoad++ , 7 8 .



, , :

• " ";
• " ".

もちろん、ニューラルネットワークはホットトピックですが、時系列を格納するための適切なDBMSの概要は非常に貴重です。



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