メッセージブローカーの選定
通信タイプ
マイクロサービスは複数の小さなサービスをAPIによって連携させるアーキテクチャのことです。
単位ごとの修正や変更が容易でスピーディな運用展開がメリットになります。
マイクロサービスが通信する方法には、同期通信と非同期通信の2つのタイプがあります。
同期通信
呼び出し側は次のメッセージを送信する前に、前回の応答を待ちます。
実装が簡単な通信ですが、スケーラビリティーがありません。
HTTPプロトコルを利用したREST APIを使用します。
非同期通信
呼び出し側は前回の応答を待たずにメッセージを送信します。
分散システムに適した通信で、スケーラビリティーが高くなりますが実装が複雑になります。
通常は、メッセージを管理するために、メッセージブローカーを必要とします。
この２つの通信タイプを選定するときは、マイクロサービスの構造、配置しているインフラストラクチャ、遅延、スケール、依存関係、通信目的など、さまざまな要素を考慮します。
非同期通信の利点
非同期通信は確立が複雑で、ソフトウェアスタックにメッセージブローカーを追加する必要がありますが、ノンブロッキングな通信でスケーラビリティーが高くなります。
マイクロサービスに非同期通信を使用することにより得られるメリットは、充分に投資価値があるものです。
また、メッセージブローカーを利用したときは、次の項目が保証されます。
異なるマイクロサービス間の通信が信頼性が高く安定している
システム内でメッセージが管理および監視されている
メッセージが失われない
メッセージブローカーの選択
非同期通信はPython3 の aysncio などで実装する方法もありますが、通常はメッセージブローカーにより管理されます。 無料で利用できるオープンソースのメッセージブローカーは選択肢が少なく限られています。
メッセージブローカーを選択するときは、次の項目について検討する必要があります。
スケール：システム内で1秒間に送信されるメッセージの数
データの永続性：メッセージを回復する機能の有無
コンシューマー機能：ブローカーが1対1または1対多のコンシューマーを管理できるか
RabbitMQ
スケール：1秒あたり約5万メッセージ
データの永続性：可能 永続メッセージと一時メッセージの両方をサポート
コンシューマー機能：1対1と1対多
RabbitMQは2007年にリリースされた、最初の一般的なメッセージブローカーです。
RabbitMQは、高度なメッセージキュープロトコル（AMQP）を実装することにより、
1対1(Point-to-Point)と1対多(pub-sub)の両方の方法でメッセージを配信することができます。複雑なルーティングロジックをサポートするように設計されています。
RabbitMQは、Python、Java、.NET、PHP、Ruby、JavaScript、Go、Swiftなど、ほぼすべての主要言語をサポートしています。
永続モードでは、パフォーマンスの問題が発生する可能性があります。
Kafka
スケール：1秒あたり最大数百万のメッセージ
データの永続性：可能
コンシューマー機能：1対多のみ
Kafkaは、2011年にLinkedin により、自社の膨大なデータを、高スループット、低いレイテンシー（遅延）で処理するために開発されました。
分散ストリーミング・プラットフォームとして、Kafkaはパブリッシュ/サブスクライブサービスを複製します。 データの永続性を提供し、高品質のメッセージを交換できるようにするレコードのストリームを格納します。
Kafkaは、Python、Java、C / C ++、Clojure、.NET、PHP、Ruby、JavaScript、Go、Swiftなど、ほぼすべての主要言語をサポートしています。
Redis
スケール：1秒あたり最大100万
データの永続性：Redis 自身では不可、スナップショットのダンプ/リストアで対応
コンシューマー機能：1対1と1対多
RedisはREmote DIctionary Serverの略で、名前から想像できるように高性能のKVS(Key-Value-Store)システムでメッセージブローカーとしても使用できるクラスタ・インメモリデータストアです。 他のメッセージブローカーとは少し異なり、Redis 自体には永続性がなく、メモリのスナップショットをディスクやDBMSにダンプし、リストアすることで永続性を提供します。メモリにデータを保存するため非常に高速で、リアルタイムのデータ処理にも最適です。
Redis 5.0でpub-subが導入されたことにより、1対多のコンシューマ機能が強化されました。
Redis 自身でクラスタを構成することができるため、冗長構成なども設定管理が簡単で運用コストが低くなります。
タスクキューとの関係
システムのタスクキューに Celery を使用するような場合、通常はメッセージブローカーとしては RabbitMQ もしくは Redis を導入することになります。こうしたシステムに、Celeryがサポートしないメッセージブローカーである Kafka を導入することは、まずありえません。
マネージドSaaS
RabbitMQ
RabbitMQ をSaaSとして提供しいるサービスには次のものがあります。
最大キューサイズ1万、最大キュー数100、月間最大メッセージ１万、最大接続数20までは無料
Kafka
KafkaをSaaSとして提供しいるサービスは、Azure、AWS、Confluent などで提供されています。これらのクラウドベンダーはすべてKafkaプロジェクトの作成者であり、主要なコントリビュータです。しかし、残念ながら完全に無料で使用できるSaaSは見つけられませんでした。
Redis
Redis をSaaSとして提供しいるサービスには次のものがあります。
残念ながら完全に無料で使用できるSaaSは見つけられませんでした。
速度は期待せずに30MBメモリのデータベース１つだけ、接続IPも１つのみであれば無料
AWS、Azure、GCPのインスタンスを使用するため別途クラウドコストが必要。
256MBメモリまでであれば無料。ただし、AWS Lambda を使用して提供するため別途AWSのコストが必要。
1999円/月もしくは2.78円/時間
MySQL, PostgreSQL, MongoDB, Redis をクラウド上に提供。
RabiitMQ をSaaSとして提供する CloudAMQP は唯一無料で使用できることは開発や個人的な利用では有用ではないでしょうか。 仮想環境にメッセージブローカーを構築
仮想化技術である Docker を使うことでLinux系マシンやMacに簡単にメッセージブローカー(RabbitMQ、 Kafka、Redis)を利用できる環境をつくれます。 参考：
Oracle から無料で利用できる仮想環境ソフトウェア VirtualBox を利用すれば、ディスクとメモリの消費は大きくなりますが、簡単に環境を整えることができます。 メッセージブローカーをインストール済みの仮想ディスクイメージを Bitnami が無料で配布しています。 仮想環境については本筋から外れるため、別の資料とするようにします。
まとめ
ここで、紹介したメッセージブローカーは、それぞれ長所短所があり、それぞれが向いている適用範囲で使用することが大事です。