1. 導入
アプリのプロトタイプ開発時、複数のサービスを組み合わせてリアルタイムにアウトプットを生成する機能を作成したが、実装難易度を下げて開発スピードを優先した結果、保守・運用面で課題が生じました。
この機能はアプリのコア機能であり、将来的な拡張を考えると現状のままでは問題があります。そこで、以下の課題を解決できるようにアーキテクチャを見直し、より柔軟で拡張性のある構成を目指しました。
- 機能拡張性の担保
- スケーラビリティの確保
- サービスとの疎結合
今回の改修検討では、これらの課題に対してメッセージングサービスを活用することで解決できないかを検討しました。
本記事では、メッセージングサービスの基礎知識や実際のメッセージングサービスや検討結果を元にと考えていますので参考になったら幸いです。
2. メッセージングサービスとは？
そもそもメッセージングサービスとは何なんだろうと思う方もいらっしゃると思います。簡単に説明すると、データを一時的に格納してアプリやプロセス間でデータをやり取りする仕組みです。
エンジニアの方なら「あれ、キューイングも同じようなものでは？」と気づく方もいらっしゃると思います。大きな観点では同じような機能であると分類できます。
「じゃあ同じもんなのに何がどう違うんだよ」という疑問が解消できるよう、実際にどんな場面で使うのか、何がどう違うのか、その点を説明できればと思います。
先ほど「同じような」と表現しましたがメッセージングサービスの中にキューイングが含まれていることが多いです。
メッセージングとは広い意味で「システム間でのデータ連動を非同期に実施する仕組み」のことを指します。データの連動し方を2つのパターンに分類することができます。
- キューイング（Point-to-Point型）
キューイングとは送信側と受信側が1対1の関係になるモデルです。1つのメッセージは複数の受信者のうち“「誰か1人」”にしか配信されません。- 特徴
- 誰かがメッセージ取得するとメッセージは消費される
- ワーカーを増やすことでスケールアウトができる。
- 主な用途
- 動画変換やバッチ処理などの「非同期処理の実行」
- スパイクアクセス時の「流量制御」
- 特徴
- メッセージング（Publish/Subscribe型）
メッセージングとは送信側と受信側が1対多の関係になるモデルです。送信者がトピックにメッセージを投げると、それを購読している“「全員」”に同じメッセージが複製されて届きます。- 特徴
- 同じメッセージを複数システムに同時に配信できる。
- 送信側が受信側を意識しなくてもよい「疎結合」にできる。
- 主な用途
- 1つのイベントから、複数のアクションを同時に実行したいとき
- 特徴
つまり、「メッセージングサービスを使用したい」と思ったときに、目的に合わせて「キューイング方式」にするか「メッセージング方式」にするかを選択することが重要となります。
3. メッセージングサービスの代表的なサービス
ここまでメッセージングサービスに関して説明させていただきました。今回の検討にて調査した代表的なメッセージングサービス（メッセージブローカー）を紹介します。
| No. | サービス名 | サービス概要 | 強み | 弱み | 種別 |
|---|---|---|---|---|---|
| 1 | Azure Service Bus | Microsoft Azureが提供する、信頼性の高いエンタープライズ向けクラウドメッセージングサービス。 高度なメッセージング機能を有しているサービス。 |
・トランザクション処理や重複メッセージの検出など多彩なエンタープライズ機能を保持 ・単純なキューだけではなくPub/Subにも対応 ・Microsoft製のため.NETを利用した開発との親和性が高い |
・多機能な分、複雑で利用するための学習コストが高くなる。また他と比較するとサービス利用料も高くなる ・kafka等と比較するとスループットに見劣りがある。 |
クラウドサービス |
| 2 | Amazon MQ | AWS上でオープンソースのメッセージブローカー(Apache ActiveMQ,RabbitMQ)を簡単にセットアップして、運用できるマネージドサービス。 | ・ActiveMQやRabbitMQなどをすでに導入している場合、以降が比較的容易にできる。 ・独自のAPIではなくAMQPなどの標準のプロトコルを利用することができ、ベンダーロックインになりづらい ・RabbitMQなどの柔軟なルーティング機能をマネージドで利用できる |
・SQSと異なりインスタンスを管理する必要。パッチは自動だがスケーリングは自動ではない ・インスタンスの起動時間がコストとなるためトラフィックに波がある場合は割高になる ・サイジングや設定など運用上の考慮が必要 |
クラウドサービス |
| 3 | Active MQ | Apache Software Foundationが開発するオープンソースのメッセージブローカー。Javaで作成されておりJMSの標準仕様が実装されている。システム間での信頼性の高い非同期メッセージ通信を実行。 | ・既存のJavaシステムやJMSを利用しているアプリケーションの場合連携が容易 ・対応しているプロトコルが豊富で多様なクライアントとの接続ハブに優れている ・トランザクション処理や複雑なメッセージパターンなど多彩なエンタープライズ機能を保持 |
・kafkaとRabbitMQと比較して大量のメッセージを行う際のパフォーマンスが見劣る。 ・コミュニティの活発さが他ブローカーに比べて見劣りする。 ・多機能であるため設定やチューニングが複雑。 |
OSS |
| 4 | Rabbit MQ | オープンソースのメッセージブローカ―(メッセージ思考ミドルウェア)。AMQPプロトコルを実装しており、柔軟なメッセージルーティングが可能 | ・非常に柔軟なルーティング設定が可能で複座ルナメッセージングパターンに対応できる。 ・歴史が長く情報も集めやすい。またWebベースの管理画面があり運用がしやすい。 ・OSSであるため任意のクラウドオンプレとベンダーロックインにならない。 |
・監視や運用を自前で実施する必要があるため学習と運用コストがかかる ・kafkaと比較して大量のストリーミングデータのパフォーマンスに劣っている傾向がある。 ・高い可用性の実現のためにはクラスタリングなどの高度の設定が必要で難易度が高い |
OSS |
| 5 | Apache Kafka | 大量のデータをリアルタイムに処理するために設計された、高スループットな分散メッセージングシステム。イベントストリーミングプラットフォームとも呼ばれている。 | ・大量のデータをリアルタイムに処理するユースケースにおいて他の追随を許さないパフォーマンスを発揮 ・受信したメッセージをディスクに永続化するため、再実行やほかのコンシューマが同一メッセージを参照することができる。 ・kafkaStreamsなどのライブラリを使用することで高度なリアルタイムデータ処理基盤の構築ができる。 |
・RabbitMQと比べて構成が複雑になりがちかつ柔軟なメッセージ制御が不得手 ・高パフォーマンスを実現するために層のメモリやディスクI/Oを持つサーバーが必要 |
OSS |
4. 採用方針と選定結果
今回の検討では、クラウドサービスの利用を見送り、OSSの「Apache Kafka」をベースで構成する方針を採用しました。
その理由は以下の通りです。
-
コスト面
調査したクラウドサービスは処理量に応じた従量課金が主であったため、今回のユースケースでは大量のデータを取り扱うため、費用面でマッチしなかった。 -
互換性と柔軟性
ベンダーロックインへの警戒とOSSを用いることで、既存のシステムやライブラリとの互換性を確保しやすく、将来的な構成変更やスケーリングにも柔軟に対応できると考えたためです。 -
優れたリアルタイム性
Apache Kafkaは大量のストリーミングデータをリアルタイムに処理をすることに優れており、今回のユースケースに適していた。
5. 今後の展望と今回の感想
メッセージングサービスは、非同期処理の課題を解決するための強力な選択肢です。しかし、一言で「メッセージングサービス」といっても、その種類や特徴はさまざま。利用するシステムや要件をしっかり想定し、適切なパターンを選択することが重要であると感じました。
今後は、Kafkaを活用したレスポンス性能の向上方法についても調査し、現状設計した構成がベストプラクティスなのかも含め、精査していきたいと考えています。