RabbitMQはSidekiqと同等以上だと思う: 中編(翻訳)

概要

原著者の許諾を得て翻訳・公開いたします。

原文が長いため、3本に分割します。後編は今後公開いたします。

RabbitMQはSidekiqと同等以上だと思う: 中編(翻訳)

Sidekiqのメモリ問題

有償のフォールトトレーランスにしたとしても、SidekiqではジョブキューにRedisを使うため、メモリ消費の問題があります。Redisは前述のようにデータストアがメモリ上に配置され、かつ、使われなくなったデータをディスクに逃がすしくみがありません。つまりキューのジョブはすべてメモリ上にまとめて保持されていることになります

ピーク利用時間前後のRedisメモリ使用量の推移

この問題解決に最もよく使われるのは、ジョブキューの値ではなくデータベースレコードのIDを渡すという方法です。これによってRedisのメモリ消費は抑えられますが、SidekiqやRubyのメモリ使用量は逆に増加します。メモリ使用量が増加するのは、Sidekiqの各インスタンスでモデルアクセスのためにアプリを初期化する必要があるためです。これは、軽量なRubyプロセスとして独自のワーカーを自作することで解決できる可能性がありますが、私たちの場合、2つの異なるアプリ(ワーカーと、メインのアプリ)でモデルやデータベースアクセスの情報を管理するときに問題になります。別の解決方法は、メインアプリのAPIを消費することですが、その結果私たちのところではアプリの負荷を下げるどころか増加しています。

RabbitMQはこれらの問題をどう解決するか

RabbitMQは汎用のメッセージキューです。RabbitMQを「バックグラウンドワーカー方式」のバックエンドシナリオで利用するには、RabbitMQのライブラリにアクセスする必要があります。これはSneakersで行うことを強くおすすめします。Sneakersはワーカープロセスの作成/管理、キューの作成/キューの送信などSidekiqでできることはすべて行え、Sidekiqとよく似た構文が使えます(Gist)。

# SneakersとSidekiqワーカーの実装例
class SneakersLogger
  include Sneakers::Worker

  # キューとそのオプションを定義
  from_queue 'loggings'

  def work(log_message)
    Logger.log(log_message)
    # ここで繰り広げられるマジックは次のセクションで解説
    ack!
  end
end

# ---

class SidekiqLogger
  include Sidekiq::Worker

  def perform(log_message)
    Logger.log(log_message)
  end
end

SidekiqとRabbitMQの実装における最大の違いは、10行目のack!です。これを書くことでSneakersとRabbitMSにジョブの実行を保証させられるようになります。これはRabbitMQのコミュニケーションプロトコルであるAMQPの機能です。AMQPのメッセージを取り出すときのモードは、ackモードとno-ackモードの2種類があります。

ACKモード失敗/成功時のconsumerの様子

ackモードの場合、コンシューマー(consumer)はメッセージが処理されたことをackする(=応答を返す)タイムウィンドウを1つ指定しなければなりません。言い換えると、ackモードではコンシューマーがメッセージ処理の最大所要時間を指定しなければなりません。コンシューマーがキューからメッセージを1件取り出すと、キュー内のメッセージは事実上削除されますが、RabbitMQはそのコピーを保持し続けます。コンシューマーがack信号を指定の時間内に返せなかった場合は、メッセージがキューの先頭に戻されます。コンシューマーがack信号を指定の時間内に無事返せた場合、メッセージはRabbitMQから完全に削除されます。no-ackモードの場合は保証がないので、タイムウィンドウの指定もありませんし”ack”信号を返す義務もありません。

他にも、メモリ消費に違いがあります。デフォルトのRabbitMQは可能な限り多くのメモリを確保します。設定可能な基準点に達した時点で、適切なメッセージをすべてディスクに逃します。ただしすべてのキューがこのように処理されるわけではありません。RabbitMQは、可能な場合にすべてのメッセージをディスクに保持する「遅延キュー」(lazy queue)機能もサポートします。これは巨大なメッセージを渡す場合に便利です。

通常時と遅延キューでのRabbitMQリソースアロケーションの様子(メッセージ単位)

これらの機能によって、巨大なペイロードを扱える信頼性の高いジョブキューを作成できるようになります。データベースにアクセスしない軽量Rubyプロセスでワーカーを自作できます。高性能やメモリ消費を要求されずに、ジョブをキューで処理するのに必要なデータをこれですべて受けることができます。

ここで、本記事でまだ触れていなかったSidekiqの機能がひとつあります。UIです。Sidekiqは、ジョブの健全性や一般的なスループットの監視に役立つ便利なUIを備えています。

SidekiqのUI

RabbitMQにはさらに強力なUIがあり、失敗/成功件数の洞察の他にも、ディスクやRAMといったシステムリソースの使用量をグローバルおよびキューごとに表示したり、メッセージをUIから直接コンシューム(consume)およびパブリッシュしたり、コンシューマーやユーザーの管理機能、ログイン画面といったさまざまな機能があります。こうした機能はSidekiqではプレミアム版(1950ドル/年)の機能で使えます(さらにワーカー数は価格単位あたり100個までとなります)。

RabbitMQの管理コンソール

「exchange」

AMQPでは「exchange」という概念が定義されています。exchangeは一種のルーターと見なせます。メッセージがexchangeにパブリッシュされると、exchangeは配信すべきメッセージを決定します。ここで、メッセージを直接キューに入れることは不可能になっている点が重要です。仮にメッセージをキューに直接パブリッシュしたとしても、臨時のexchangeを作成してキューに配信するようになっています。

RabbitMQでサポートされるexchangeには4種類あります

最もよく利用されているのはdirect exchangeで、すべてのメッセージを1つのキューに配信します。exchangeとキューは1対1対応します。direct exchangeをチャットアプリに応用した場合、メッセージはチャットルームから1人のユーザーに配信されます。

チャットアプリでdirect exchangeが使われている様子

他にfan-out exchangeというものもあります。これはメッセージを自分に紐付けられたすべてのキューに配信するもので、1つのexchangeと複数のキューが1対多になっています。チャットアプリを例に取ると、fan-out exchangeは1件のメッセージを全ユーザーに送信するときに使われます。

チャットアプリでfan-out exchangeが使われている様子

次はtopic exchangesです。これはメッセージのタグやトピックに紐付けられたキュー、およびキューに紐付けられたトピックを元にメッセージをそれらに配信します。チャットアプリを例に取ると、topic exchangeは対応するユーザーにダイレクトメッセージを送信するときに使われます。

チャットアプリでtopic exchangeが使われている様子

最後はheader exchangesです。これはtopic exchangeをさらに推し進めたもので、トピックを参照するのではなく、ルーティングキーも呼び出して、メッセージのヘッダーを参照して配信すべきメッセージを決定します。RabbitMQのメッセージにはこれらに関連付けられた属性(ヘッダー)を追加でき、これによってメッセージの扱いを変えられます。たとえば”x-match”ヘッダーは、値がそれにマッチするexchangeを指定して、キューにルーティングされるようにします。”reply-to”ヘッダーは、メッセージの処理結果をどこにパブリッシュすべきかを指定します。

exchangeを利用することで、1回こっきりの配信、パフォーマンス向上、サービスの廃止処理(deprecation)が容易など、さまざまなメリットが得られます。exchangeによるメッセージ配信は、同等のロジックを扱うRubyに比べてかなり高速かつ高信頼性です。メンテするコードを持たないことには実用的な理由もあります。ロジックはRabbitMQが引き受けるので、設定だけで使えます(設定はコードで行います)。exchange〜exchange間やexchange〜キュー間の紐付けは任意のクライアントからその場で変更できるので、あるアプリが別のサービスの振る舞いを変えられるようになります。exchangeは個人的に、サービスを別のサービスに(一時的に)切り替える必要なしに、ダウンタイムを極小またはゼロにとどめてデプロイしたり、サービスを廃止処理(deprecation)するのに役立ちました


関連記事

Rails: RedisキャッシュとRackミドルウェアでパフォーマンスを改善(翻訳)

RailsのPostgreSQL上でマルチテナントのジョブキューシステムを独自構築する(翻訳)

Ruby on RailsによるWEBシステム開発、Android/iPhoneアプリ開発、電子書籍配信のことならお任せください この記事を書いた人と働こう! Ruby on Rails の開発なら実績豊富なBPS

この記事の著者

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833 コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。 これまでにRuby on Rails チュートリアル第2版の半分ほど、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れてそれぞれ一部を翻訳。 かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。 実は最近Go言語が好き。 仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。

hachi8833の書いた記事

週刊Railsウォッチ

インフラ

BigBinary記事より

ActiveSupport探訪シリーズ