RedisのlistとpubsubとRabbitMQを使い分けを考える

2017年1月現在、ビッグデータ処理プロジェクトoceanusは下記のようなデータの流れをしています。

GEK上でDockerを使ってアプリケーションを構成していますが、Redisのリスト型、pubsub型に加えて、最近RabbitMQも使い始めたので、どう使い分けしているかを整理してみる。

Redis list型

順番を持ったリストで、左から入れたり、右から入れたり、逆に取り出したりすることができる。

リスト型 — redis 2.0.3 documentation

用途

データを失いたくない1対1のデータ処理。

oceanusでは、armsでHTTPリスエストをバリデーション等をした後にlistに保存し、r2bq（Redis to BigQueryの略）が取り出して、BigQueryに保存している。

BigQueryに保存したらもう必要がなくなり消えるので、基本的にRedisに保存されているデータは少ない。

BigQueryが落ちているなど保存できない場合は、再度listに戻す処理を行っている。

Redis PubSub

情報発信側publisherに対して、複数の受信側subcriberが登録することができる。

Sub側は登録以前のものや接続が遮断されてる間のデータは失われる。送受信が失敗してもリトライは無い。

GoogleのCloud PubSub
Google Cloud Pub/Sub Documentation  |  Cloud Pub/Sub  |  Google Cloud Platform
は、データの再送、保持などもしており信頼性は高いけど、実際に使ってみた所、認証や通信でレスポンスが悪くWEBサーバーが遅くなるため、自分でRedis立てて使いました。

用途

1対多のデータ処理。一つのデータをいろいろな所で使いたい時、かつ多少データがなくなっても問題がないもの。

流れてきたデータにフィルターをかけて、条件Aに合致したらメール、条件Bに合致したらスプレッドシートに保存するとか。

oceanusでは、データはBigQueryにすべて保存されるので、データが失われてもいいような通知用途などに使っています。

RabbitMQ

メッセージキューイングのミドルウェア。

メッセージといってもメールやチャットのような人が読むものではなく、シリアライズ化したコードなど機械同士のやりとりが基本です。

銀行などでも実績があり、貯めたタスクを処理するワーカーを別プロセスで走らせることができ、耐障害、非同期、分散、スケールなどを用意に実現できます。

AWSでは、似たようなSQSがあります。
aws.amazon.com

GoogleでもApp Engine用にTask Queue

Task Queue Overview  |  App Engine standard environment for Python  |  Google Cloud Platform

があるけど、App Engine以外から使いにくそうなので使いませんでした。

用途

タスクの非同期処理。リクエストに対して処理時間が長い時、リクエストの数分後など時間差で実行したい時など。

PythonでCeleryから使っており、送りたいタスクを関数にし、デコレータを付けるだけで使用できます。

CeleryはブローカーとしてRedisも使うことができますが信頼性、対応する機能などからRabbitMQが推奨されてるようです。

公式Dockerイメージを使えば、特に難しい設定もなく使うことができました。

現在は、特定の条件（エラーを意味するものとか）で、Googleスプレッドシートに保存したり、コンバージョン通知からそのユーザーの履歴をBigQueryから取ってきてメールに付けて送るなどのタスクをどんどん投げて処理させています。

ワーカーはデフォルトでは10と多くなっており、スプレッドシートにアクセスしすぎて、繋がらなくなるなどもあるので、1秒に1回などリミットを掛ける必要がありました。

リトライ、オートスケーリングなど多数の機能がありまだ使いこなせていない感。

逆にこれを使っておけばあとで困ることはなさそう。

昔はDBに保存してcronで処理などもあったと思いますが、そのロジックを自分で書くのは大変だし、スケーリングや多重起動の防止などいろいろ面倒なので、こういうミドルウェアを積極的に使った方が昔の自分に勝てます。

まとめ

最初はRedisとBigQueryだけでしたが、間にPubSub、RabbitMQを入れることにより、リアルタイム処理や、重い処理の非同期処理などさまざまな形でデータを利用することができるようになりました。

また疎結合を保てるので、listを使う部分の開発、pubsubを使う部分の開発をお互いにあまり影響せずに進めることで出来て安心して、本番テスト等も行えます。

プログラマとして、使える道具はどんどん増やしていくべき。

Redis入門 インメモリKVSによる高速データ管理

Mastering RabbitMQ