バックエンド開発者向けのトップ 6 キューイング システム

待ち行列システムをお探しですか? それとも、より良いものを探していますか？ 必要な情報はすべてここにあります！

キューイング システムは、バックエンド開発の最高の秘密です。

キューイング システムを称賛する詩を書き出すつもりはありませんが、ジュニア バックエンド開発者は、キューをシステムに統合する方法を学べば、中級レベルのバックエンド開発者になると言えます。 キューは、カスタマー エクスペリエンスを向上させ (方法は後で説明します)、複雑さを軽減し、システムの信頼性を向上させます。

確かに、トラフィックがゼロに近い非常に単純な Web アプリやパンフレット Web サイトの場合、キューは全体的なものになる可能性があります (または、一般的な共有ホスティング環境にいる場合はインストールが不可能になることさえあります)。システム、および大規模なアプリは、キューイングを伴わないと不可能です。

開始する前に、免責事項: キューイング システムに慣れていて、さまざまなオプションを比較したい場合は、次のいくつかの導入セクションでかなり眠くなります。 ですから、遠慮なく前にジャンプしてください。 入門セクションは、待ち行列システムについてぼんやりとした考えしか持っていないか、名前を聞いただけの人を対象としています。

待ち行列システムとは何ですか?

キューとは何かを理解することから始めましょう。

キューは、コンピュータ サイエンスにおけるデータ構造であり、私たちの身の回りにある現実世界のキューを模倣しています。 たとえば、チケットカウンターに行くと、キューの最後に立つ必要があり、キューの最初の人が最初にチケットを取得することに気付くでしょう. これは、「先着順」現象とも呼ばれます。 コンピューター サイエンスでは、このようなタスクをキューに格納し、同じ先着順で 1 つずつ処理するプログラムを作成できます。

キュー自体は実際の処理を行わないことに注意してください。 それは、タスクが何かによってピックアップされるまで待機する、一種の一時的なストレージです。 これが少し抽象的すぎるように聞こえる場合でも、心配しないでください。 これは抽象的な概念ですが、次のセクションで明確な例を見ていきます。

なぜ待ち行列システムが必要なのですか?

非常に長い説明は省きますが、キューイング システムの主な必要性は、バックグラウンド処理、並列実行、および障害からの回復のためだと言えます。 例を使用してこれらを見てみましょう。

バックグラウンド処理

時間が最も重要な e コマース マーケティング キャンペーンを実行していて、顧客が支払いを完了して「ありがとう」ページが表示される直前に確認メールを送信するようにアプリケーションが構築されているとします。 接続しているメール サーバーがダウンしている場合、Web ページは機能しなくなり、ユーザー エクスペリエンスが損なわれます。

膨大な数のサポート リクエストが寄せられることを想像してみてください。 この場合、この電子メール送信タスクをジョブ キューにプッシュし、顧客に成功ページを表示することをお勧めします。

並列実行

多くの開発者、特に単純でトラフィックの少ないアプリをコーディングする開発者は、バックグラウンド処理に cron ジョブを使用する習慣があります。 これは、入力のサイズが大きくなりすぎてクリアできなくなるまで問題ありません。 たとえば、分析レポートをコンパイルしてユーザーに電子メールで送信する cron ジョブがあり、システムが 1 分あたり 100 件のレポートを処理できるとします。

アプリが成長し、1 分間に平均 100 を超えるリクエストを受け取るようになるとすぐに、アプリはますます遅れを取り始め、すべてのジョブを完了することはできなくなります。

待ち行列システムでは、複数のワーカーを設定することでこの状況を回避できます。それぞれのワーカーがジョブ (それぞれ実行される 100 件のレポートを含む) を選択し、並行して作業してタスクをはるかに早く終了できます。

障害からの回復

私たちは通常、Web 開発者として失敗を考えません。 私たちは、使用するサーバーと API が常にオンラインであることを当然のことと考えています。 しかし、現実は異なります。ネットワークの停止はあまりにも一般的であり、インフラストラクチャの問題により、信頼できる優れた API がダウンしている可能性があります (「私ではない!」と言う前に、Amazon S3 の大規模な停止を忘れないでください)。 レポートの例に戻ると、レポート生成の一部で支払い API に接続する必要があり、その接続が 2 分間ダウンした場合、失敗した 200 件のレポートはどうなるでしょうか?

ただし、キューイング システムにはかなりのオーバーヘッドが伴います。 まったく新しいドメインに足を踏み入れているため、学習曲線は非常に急勾配であり、アプリケーションと展開の複雑さが増し、キューに入れられたジョブを常に 100% の精度で制御できるとは限りません。 とはいえ、キューなしでアプリケーションを構築することが不可能な場合もあります。

それはさておき、今日のバックエンド/システムのキューに共通するオプションのいくつかを見てみましょう。

レディス

Redis は、データの構造を知らずにデータの文字列を格納、更新、および取得するだけのキー値ストアとして知られています。 以前はそうであったかもしれませんが、今日の Redis には、リスト、ソート済みセット、さらには Pub-Sub システムなどの効率的で非常に有用なデータ構造があり、キューの実装に非常に望ましいものになっています。

Redis の利点は次のとおりです。

• 完全なインメモリ データベースで、読み取り/書き込みが高速化されます。
• 高効率: 1 秒あたり 100,000 回を超える読み取り/書き込み操作を簡単にサポートできます。
• 柔軟性の高い持続性スキーム。 障害が発生した場合のデータ損失の可能性を犠牲にして最大のパフォーマンスを実現するか、完全に保守的なモードでセットアップして一貫性のためにパフォーマンスを犠牲にすることができます。
• 追加設定なしでサポートされるクラスター

Redis にはメッセージング/キューイング/リカバリの抽象化がないため、パッケージを使用するか、自分で軽量システムを構築する必要があることに注意してください。 一例として、Redis は Laravel PHP フレームワークのデフォルトのキュー バックエンドであり、フレームワークの作成者によってスケジューラが実装されています。

Redis を学ぶのは簡単です。

RabbitMQ

Redis と RabbitMQ の間にはいくつかの微妙な違いがあるため、まずそれらを理解しておきましょう。

まず第一に、RabbitMQ はより専門的で明確に定義された役割を持っているため、それを反映するように構築されています — メッセージングです。 言い換えれば、2 つのシステム間の仲介者として機能することがそのスイート スポットであり、データベースとして機能する Redis には当てはまりません。 その結果、RabbitMQ は、Redis にはないいくつかの機能を提供します: メッセージ ルーティング、再試行、負荷分散など。

考えてみれば、タスク キューはメッセージング システムと考えることができます。スケジューラ、ワーカー、およびジョブの「サブミッター」は、メッセージ パッシングに参加するエンティティと考えることができます。

RabbitMQ には次の利点があります。

• メッセージ パッシングの抽象化が向上し、メッセージング パッシングが必要な場合にアプリケーション レベルの作業が削減されます。
• 停電や停止に対する回復力が高い (少なくともデフォルトでは Redis より)。
• 分散展開のためのクラスターとフェデレーションのサポート。
• 展開を管理および監視するための便利なツール。
• 事実上すべての重要なプログラミング言語をサポートします。
• 選択したツール (Docker、Chef、Puppet など) でデプロイします。

RabbitMQ をいつ使用するか? 非同期メッセージ パッシングを使用する必要があることはわかっているが、このリストにある他のいくつかのキューイング オプションの非常に複雑な処理に取り組む準備ができていない場合は、これが最適な選択であると言えます (以下を参照)。

アクティブMQ

エンタープライズ スペース (または高度に分散された大規模なアプリの構築) に取り組んでいて、常に車輪を再発明する必要がない (そして途中で間違いを犯したくない) 場合は、ActiveMQ を検討する価値があります。 .

ActiveMQ が優れている点は次のとおりです。

• これは Java で実装されているため、非常にきちんとした Java 統合を備えています (JMS 標準に従います)。
• サポートされている複数のプロトコル: AMQP、MQTT、STOMP、OpenWire など。
• セキュリティ、ルーティング、メッセージの有効期限、分析などをすぐに処理します。
• 一般的な分散メッセージング パターンのサポートが組み込まれているため、時間とコストのかかるミスを節約できます。

これは、ActiveMQ が Java でしか利用できないと言っているわけではありません。 Python、C/C++、Node、.Net、およびその他のエコシステム用のクライアントがあるため、将来的に崩壊する可能性はありません。 さらに、ActiveMQ は完全にオープンな標準に基づいて構築されているため、独自の軽量クライアントを簡単に構築できます。

とは言っても、ActiveMQ は単なるブローカーであり、バックエンドは含まれていないことに注意してください。 メッセージを保存するには、サポートされているバックエンドのいずれかを使用する必要があります。 特定のプログラミング言語 (Celery、Sidekiq などの他の一般的なソリューションと同様) に関連付けられていないため、ここに含めました。

アマゾン MQ

ここで、Amazon MQ について簡単に説明しますが、重要です。 ActiveMQ がニーズに最適なソリューションであると考えているが、インフラストラクチャの構築と保守を自分で行いたくない場合、Amazon MQ はそれを行うためのマネージド サービスを提供します。 ActiveMQ が実行するすべてのプロトコルをサポートします — 機能の違いはまったくありません — ActiveMQ 自体を表面下で使用するためです。

メリットは、マネージドサービスなので利用すること以外は気にする必要がないことです。 デプロイ内から他のサービスや製品を直接活用できるため (たとえば、より高速なデータ転送)、AWS 上のデプロイではさらに理にかなっています。

アマゾン SQS

重要なインフラストラクチャの部分に関しては、Amazon が黙って座っているとは期待できませんよね?

そして、よく知られている巨大な AWS による完全にホストされた単純なキュー サービス (文字通り) である Amazon SQS があります。 繰り返しますが、微妙な違いが重要なので、SQS にはメッセージ パッシングの概念がないことに注意してください。 Redis と同様に、キュー内のジョブを受け入れて分散するためのシンプルなバックエンドです。

では、いつ Amazon SQS を使用したいと思いますか? いくつかの理由を次に示します。

• あなたは AWS のファンであり、他のことには触れません (正直なところ、そのような人はたくさんいますが、それは何も悪いことではないと思います)。
• ホステッド ソリューションが必要なため、失敗率がゼロであり、ジョブが失われないことを確認してください。
• クラスターを構築したくないので、自分で監視する必要があります。 さらに悪いことに、その時間を生産的な開発に使用できるときに、監視ツールを構築する必要があります。
• すでに AWS プラットフォームに多額の投資を行っており、その状態を維持することはビジネス上意味があります。
• メッセージの受け渡し、プロトコルなどに関連する綿毛のない、焦点を絞った単純なキューイング システムが必要です。

全体として、Amazon SQS は、システムにジョブ キューを組み込み、自分でインストール/監視することを心配する必要がない人にとっては堅実な選択肢です。

豆の木

Beanstalkd は長い間存在しており、戦闘でテスト済みの、高速で簡単なジョブ キューイング用のバックエンドです。 Beanstalkd には、Redis と大きく異なるいくつかの特徴があります。

• これは厳密にはジョブ キューイング システムであり、他には何もありません。 そこにジョブをプッシュし、後でジョブ ワーカーによってプルされます。 したがって、アプリケーションでメッセージ パッシングが少しでも必要な場合は、Beanstalkd を避けた方がよいでしょう。
• セット、プライオリティ キューなどの高度なデータ構造はありません。
• Beanstalkd は、先入れ先出し (FIFO) キューと呼ばれるものです。 仕事を優先順位で並べる方法はありません。
• クラスタリングのオプションはありません。

以上のことから、Beanstalkd は、単一のサーバー上に存在する単純なプロジェクトのための滑らかで高速なキュー システムを実現します。 多くの人にとって、Redis よりも高速で安定しています。 したがって、何があっても解決できないように見える Redis の問題があり、ニーズが単純な場合は、Beanstalkd を試してみる価値があります。

結論

ここまで読んだ (またはここまで読んだ) 場合は、キューイング システムに興味があるか、キューイング システムが必要である可能性が非常に高いです。 その場合、言語/フレームワーク固有のキュー システムを探している場合を除き、このページのリストが役に立ちます。

キューイングはシンプルで 100% 信頼できると言えたらいいのですが、そうではありません。 これは厄介で、すべてがバックグラウンドで非常に高速に行われるためです (間違いは見過ごされ、非常にコストがかかる可能性があります)。 それでも、キューは一定の範囲を超えて非常に必要であり、武器庫の中で強力な (おそらく最も強力な) 武器であることがわかるでしょう。 幸運を！