非同期連携のための メッセージングサービスを考える

Transcript

1. 非同期連携のための メッセージングサービスを考える Shinnosuke Hirota (@shin_developer) 技術選定を突き詰める 2025 懇親会LT
2. Introduction Introduction
3. Introduction マイクロサービス開発（非同期連携） 業務 経験 Java / Spring Boot: ５年 Kotlin / Spring Boot : 3ヶ月 株式会社出前館 所属 廣田 新之典（＠shin_developer） 名前
4. Introduction 弊社出前館では、グループ会社であるLINEヤフー社と連携し、Yahoo!シ ョッピングと連動した、生鮮食品・日用品を最短20分で即時配送するサ ービス「クイックマート」を共同で運営しています。 バックエンドでは、Kafka を用いたマイクロサービス間の非同期連携を 採用することで、疎結合なサービス連携を実現しています。 近年、マイクロサービス設計においてイベント駆動アーキテクチャが注 目を集める中、メッセージングシステムの選定は非常に重要です。そこ で、この LT では、実運用経験から導き出した選定観点をシェアし、皆 さんが最適なメッセージング基盤を選ぶ際の参考にしていただければと 思います。
5. Evaluation Criteria Evaluation Criteria
6. Queue Pub/Sub 配信モデル PublisherとConsumerが１対１（一つのアプリケーションという意味）の 関係で紐づく。そのためPublilshされたイベントを複数のアプリケーショ ンで処理する構成にすることを単独では行えない。よってQueue型のAWS SQSではAWS SNSと組み合わせてPubSubを実現している。 PublisherとConsumerが１対Nの関係で紐づくモデル。システムの非同期 連携において一つのメッセージを複数のコンシューマーで処理するケース が多いので、基本的にこのモデルを採用したメッセージングシステムが採 用される。
7. exactly-once at-least-once 配信セマンティクス メッセージが正確に一回のみ配信されることが約束され、重複して配信さ れることがない。一方でスケーラビリティやスループットが劣る場合もあ る。 メッセージを少なくとも一回配信する。場合によっては同一のメッセージ が複数回配信されることもある。コンシューマー側で不整合が発生しない ように制御が必要。
8. Push Pull 受信モデル メッセージングサービス自体がコンシューマーに対してメッセージを送信するモデル。 リアルタイム性が高く、コンシューマーの実装がシンプルになる。一方コンシューマー がダウンしているときにも配信されるためメッセージロストしないかリトライ仕様を確 認する必要がある。複数のコンシューマーに対して配信するFan-out構成を実現するた めのルーターとして採用されるケース（SNS->複数のSQS）以外はイベント駆動で使わ れることはない印象 コンシューマー側がメッセージングサービスに対してポーリングを行い、メッセージを 取得するモデル。ダウン時にはメッセージが取得されないためロストが起こりづらく、 バックプレッシャーの制御もしやすい。基本的にマイクロサービスではこちらのモデル のメッセージングシステムが利用されることが多い印象。
9. レイテンシー スループット バッチ処理 パフォーマンス系 基本的に気にする必要はない。非同期連携を採用する時点でデータの生合成の多少のラグ は許容されるべきである。そのためメッセージングサービスによる数ms~数十ms程度の レイテンシーは無視して良いと考える。 長期にわたるメッセージ滞留はデータ不整合の原因になりかねないため、防ぐ必要があ る。メッセージブローカーのスループットがボトルネックになる可能性もあるので要求 値を満たせるのかの確認はした方が良い。 メッセージ滞留対策として、メッセージのバッチ取得はメジャーなアプローチの一つ と考えることができる。一度に取得できるメッセージの上限もパフォーマンスチュー ニングに寄与するので確認しておく必要がある。
10. コンシューマースケーリング パフォーマンス系 非同期連携にあたりコンシューマー側のスケーリングは性能維持に大いに役立つ。コンシ ューマー数を増減できなければ、負荷急増時に遅延や滞留が発生しサービス全体が不安定 になる可能性もある。メッセージングサービスではshardやpartitionのように分割してメ ッセージが保持されるが、１つのpartionに対して１つのconsumerしか接続できないよ うな制約がある場合（Kafkaなど）、運用に際してしっかり見通しを立てる位必要があ る。また特定のpartitionにメッセージが偏った場合にうまく調整がきかないケースもあ る。一方Consumerを並列スケールさせても順序保証をしてくれるメッセージングシステ ムであれば上記を気にすることなく運用することができる。
11. Comparison Comparison
12. 20% Kafka （AWS MSK） RabbitMQ （AWS MQ） Google Pub/Sub AWS Kinesis AWS SQS AWS SNS 配信モデル Pub/Sub (Topic) Pub/Sub (Exchange) Pub/Sub (Topic) Pub/Sub （ほぼTopic） Queue Pub/Sub (Topic) 配信 セマンティクス at-least-once /exactly-once at-least-once at-least-once /exactly-once at-least-once at-least-once /exactly-once at-least-once /excatly-once 受信モデル Pull Push/Pull Push/Pull Pull Pull Push 順序保証 パーティション 単位 キュー単位 Key単位 Key単位 FIFOのみKey単位 FIFOのみKey単位 再処理 可 不可 不可 S3併用で可 不可 不可 コンシューマー スケーリング パーティション数 により制限 可 可 可 (順序保証は壊れる) 可 可 スループット (チューニングにより変動) (チューニングにより変動) 4GB/s/account read: 200MB/s write: 400MB/s Standerd: 無制限 FIFO: 70000msg/s/Account Standerd: 30000msg/s/Account FIFO: 30000msg/s/Account バッチ取得 (チューニングにより変動) (チューニングにより変動) 10msg/call 1000msg or 1MB/call 10msg/Queue 10msg/Queue
13. Evaluation Evaluation
14. AWS SQS / GooglePubSub Kafka ユースケース別向き不向き パーティション数やConsmer数の見積もりなど複雑な運用が発生しない小〜中規模プロダク ト向き。リプレイができないため新規サービスを接続する際に、過去メッセージを利用した い場合はスクリプトを利用してメッセージを流す必要がある。 大規模サービス向け。チューニングによりパフォーマンスが大きく変動する（Serverless を利用すれば比較的簡単に利用できるが、性能を活かせない可能性もある）。リプレイ対 応のため過去のメッセージを遡って再読でき、KafkaStreamを利用しデータの加工も行え る。ただしConsumerスケーリングがパーティション数に制限されるので、運用難易度は Serverlessであったとしてもそれなりに高い。
15. Thank you
16. We are hiring!! エンジニア求人⼀覧