Redis Pub/Sub徹底解説:パブリッシュ/サブスクライブ型メッセージングでアプリのスケーラビリティを高める

保守性が高く、スケーラブルで、高いパフォーマンスが求められるアプリケーションを開発する際には、パブリッシュ/サブスクライブ(Pub/Sub)メッセージングパターンが有力な選択肢となります。

このパターンの背後にある考え方はシンプルでありながら、非常に強力です。まず、パブリッシャー(発行者)と呼ばれる送信者が存在します。彼らの役割はメッセージを送信(パブリッシュ)することだけです。誰がそのメッセージを受け取るのか、そもそも受け取る人がいるのかどうかは気にしません。ただ送って忘れる、いわゆる「ファイア・アンド・フォーゲット」方式で、チャンネルを通じてメッセージを発信します。

チャンネルは、テレビのチャンネルにたとえると分かりやすいでしょう。スポーツチャンネル、天気予報チャンネル、料理チャンネルなどがありますよね。各パブリッシャーは特定のチャンネルに向けてメッセージを送り、そのチャンネルを購読(subscribe)している人だけがメッセージを受け取れる仕組みです。

ここで登場するのがサブスクライバー(購読者)です。サブスクライバーは1つ以上のチャンネルを購読することで、そこで配信されるメッセージを受信し始めます。

前述のとおり、メッセージは「送ったら忘れる」ものです。つまり、あるサブスクライバーが後からチャンネルを購読し始めても、それ以前に送られたメッセージを受け取ることはできません。

このアーキテクチャの特性により、コンポーネント間の疎結合(低い結合度)を容易に実現でき、堅牢で保守しやすいアプリケーションを構築するための確固たる基盤となります。

例えば、システムのパブリッシュ側を置き換えたり改善したりする場面を想像してみてください。パブリッシャーやチャンネルを追加したい場合でも、両者は互いに独立しているため(パブリッシャーはサブスクライバーのことを気にせず、その逆も同様)、システムの他の部分を壊す心配なく簡単に変更できます。新しいパブリッシャーを追加すれば、後からサブスクライバーが該当するチャンネルを購読した時点で、自動的に利用が始まるのです。

Redisとは?

Redisは当初、先駆けであるMemcachedの代替として、インメモリキャッシュソリューションとして開発されました。

しかし現在のRedisは、インメモリデータ構造ストア、キーバリュー型データベース、メッセージブローカーなどを兼ね備えた「オールインワン」的なソリューションへと進化しています。そのため、高速なキャッシュに加えて上記のような機能も必要とするアプリケーション開発において、最適な候補となります。特に、アプリのパフォーマンスが日常的な利用において重要な要素である場合には有力です。

Redisのパフォーマンス比較(出典:Google)

Redisを使う最大のメリットの一つは、オンラインで入手できる巨大なコミュニティと技術リソースです。その多くは無料で利用でき、無料枠を提供しているクラウドプラットフォームも存在します。

さらにRedisはクラウドソリューション(Redis Enterprise Cloud)も提供しています。実際に試してみたい場合は、公式サイトで無料アカウントを登録するか、初回クーポンを活用するとよいでしょう。

Redis Enterprise Cloudのサインアップ/サインイン画面

Pub/Subとは何か?

Redisにおけるパブリッシュ/サブスクライブチャンネルは、最近のバージョンに含まれている機能の一つです。これはPub/SubメッセージングパターンのRedisによる実装であり、パブリッシャーとサブスクライバーがチャンネルを介してメッセージをやり取りします。

以下ではその概要を簡単に説明し、その後、筆者が用意した小さなデモアプリで実際の動作を確認していきます。

RedisのPub/Subはどのように動作するのか?

RedisのPub/Subには、パブリッシャー(メッセージの送信者)、チャンネル(メッセージが流れる経路)、サブスクライバー(メッセージの受信者)という3つの要素があります。誰が何を受け取るかは、純粋に「どのチャンネルを購読しているか」によって決まります。

具体例で見てみましょう:

3つのパブリッシャーが、それぞれ異なる3つのチャンネル(チャンネル1、2、3)にメッセージを配信しているとします。また、サブスクライバーA、B、Cの3人がいるとしましょう。

ここで、サブスクライバーAが3つのチャンネルすべてを購読しており、サブスクライバーBとCはチャンネル2と3のみを購読しているとします。この場合、3つのパブリッシャーのいずれかがメッセージを送信すると、必ずサブスクライバーAがそれを受け取ります。一方、BとCはチャンネル2と3しか購読していないため、パブリッシャー2と3が送信したメッセージのみを受け取ることになります。

注目すべきは、チャンネルを利用する2つのエンティティ(送信側と受信側)が完全に独立している点です。また、送信されたメッセージは永続化されません。パブリッシャーが送信した瞬間に破棄され、その時点で購読中だったエンティティだけがメッセージを受け取れます。

RedisでPub/Subを使う方法

Redisで使用できるクライアントライブラリは非常に豊富にあります。専用のページが用意されており、プロジェクトの要件や好みのプログラミング言語に応じて選択できます。

また、Redisチームが一部のリポジトリを「推奨(recommended)」としてマークしているため、初心者でも選びやすくなっています。

本記事のデモでは、Node.js向けのフル機能Redisクライアントであるioredisを使用しました。デモアプリのUIがReactとNode.jsで構築されており、サーバー側のコードとの相性が良いためです。

Redis Pub/Subデモ

Redis Pub/Subビジュアライザーアプリ

それでは実演の時間です!

このデモアプリの目的は、Pub/Subパターンの動きを視覚的に理解できるようにすることです。

初めて開くと、「Weather(天気)」「Sports(スポーツ)」「Music(音楽)」という3つの架空のテレビチャンネルに向けて、シンプルなメッセージ(ニュース)を配信するための3つのボタンが表示されます。

配信ボタンの下にあるカードがサブスクライバーです。カードの上にマウスカーソルを合わせると裏面に反転し、3つのボタンが現れます。これらのボタンを使って、それぞれ該当するチャンネルを購読できます。

サブスクライバーがあるチャンネルを購読した状態で、そのチャンネルのアイコンまたは配信ボタンをクリックすると、カードの表面にサンプルニュースが表示されます。

さまざまなパブリッシャー/サブスクライバーの組み合わせを試して、結果を確認してみてください。前述の解説の理解が深まるはずです。

デモアプリをローカルで実行する方法

デモアプリケーションをローカル環境にインストールして実行するには、以下の手順に従ってください(すべてのコマンドはプロジェクトのルートディレクトリから実行する前提です)。

フロントエンドの起動:

cd client && yarn && yarn dev

バックエンドの起動:

cd server && yarn && yarn start

最後に、ローカルにインストール済みのDocker(Dockerがない場合は公式サイトから入手できます)を使って、次のコマンドを実行します。

docker run -p 6379:6379 redislabs/redismod:preview

これがおそらく、ローカルでRedisを動かす最も簡単な方法です。もう一つの選択肢としては、Redis Cloudを直接利用してアプリケーションをオンラインにデプロイする方法もあります。こちらは現在調査中であり、実現できればアプリ全体をデプロイして改めてご紹介する予定です。

まとめ

本記事では、Pub/Subメッセージングパターンの基礎をご紹介しました。高いパフォーマンスと疎結合なアーキテクチャ、リアルタイム性のあるメッセージング機能を持つアプリケーションを構築したい場合は、Pub/Subパターン、特にRedisの採用を検討する価値があります。

実際、Redisを活用している多くの実務アプリケーションはダッシュボード型です。つまり、さまざまなデータを表示し、頻繁にリアルタイム更新されるダッシュボード画面が存在するケースが多いのです。

例えば、特定地域の交通状況を表示するシステムを想像してみてください。こうしたソフトウェアはPub/Subの利点を活かすのに理想的な題材であり、多くの場合、Redisによって実現されています。

いずれにせよ、開発者やエンジニアとして常に意識すべきは、取り組んでいるプロジェクト固有のニーズです。新しいパターンや技術を導入する際は慎重に判断し、十分な調査に基づいて決定することが重要です。