LavinMQ: Crystalで構築された高性能・オープンソース・メッセージブローカー

メッセージブローカーは、非同期通信を可能にし、サービス間の結合を解く現代の分散システムにおいて、極めて重要なコンポーネントです。しかし、従来のブローカーはリソースを大量に消費したり、診断や解決が困難な運用上の課題を抱えていたりすることがあります。LavinMQは、CloudAMQPの経験豊富なチームによって、まさにこれらの課題に対処するためにゼロから設計された、魅力的なオープンソースの代替案として登場しました。卓越したパフォーマンスとリソース効率を約束します。

この記事では、LavinMQの起源、独自のアーキテクチャの選択、そして達成された印象的なベンチマークを掘り下げ、Crystal言語で構築されたメッセージブローカーが、いかにスループットと運用の簡素化に対する期待を再定義できるかについての洞察を提供します。

LavinMQの誕生:現実世界のブローカーの課題を解決する

LavinMQの創設者であるCloudAMQPのチームは、14年間にわたりRabbitMQをホスティングしてきた経験から、メッセージブローカーに関連する運用の複雑さやペインポイントについて深い洞察を得てきました。LavinMQの創設者であるCarl Hoerbergは、広範な経験にもかかわらず、既存の外部ブローカーの制約内では完全に説明したり回避したりすることが困難な問題に、顧客が時折遭遇することがあると説明しています。

これが、独自のブローカーを構築するという野心的な決定につながりました。これにより、スタック全体を完全に制御でき、以前は不可能だったソリューションを提供できるようになります。その旅は、短期的な接続を処理して重いCPUの変動を軽減するために設計された、オープンソースのAMQPプロキシから始まりました。プロトコル実装として始まったものが、より大きな課題へと進化しました。それは、信頼性の高い永続化レイヤーの構築です。プロトコル自体は「簡単な部分」であることが判明しましたが、堅牢なディスクストレージ、確認応答(acknowledgment)の処理、およびレプリケーションを実現するには、長年の献身的な努力が必要でした。LavinMQの最初のリリースは2020年にあり、現在ではCloudAMQP上で5,000以上のプロダクションインスタンスで稼働しています。

技術アーキテクチャとパフォーマンスの卓越性

LavinMQは、速度と効率のために設計されており、いくつかの主要な設計上の選択によって特徴付けられます。

言語と並行処理モデル

LavinMQはCrystalで書かれています。Crystalは、Rubyのような構文と、LLVMコンパイル言語のパフォーマンス上の利点、およびGoのような並行処理を兼ね備えた言語として知られています。この組み合わせにより、ネイティブバイナリにコンパイルされる、非常に効率的で型安全なコードが可能になり、実行時のオーバーヘッドを最小限に抑えることができます。

"Impressive benchmarks. Reaching 1M msgs/sec on a 2 vCPU instance is a great showcase for Crystal. As a Crystal core member, I've always seen LavinMQ as a prime example of performance-oriented engineering, especially with how it handles I/O and minimizes syscalls to get the most out of the hardware. If you want to see Crystal's concurrency and type system in a serious production environment, this is the project to check out. Kudos to the LavinMQ team for their work since 2020." — @sdogruyol, Crystal core member

リソースの最適化

コアとなる設計思想は、メモリコピー、アロケーション、およびsyscallsの最小化を中心に展開されています。メッセージはメモリマップドファイル(memory-mapped files)を介してディスクに直接書き込まれ、インメモリキャッシュをバイパスします。メッセージと確認応答(acknowledgments)の両方が、ディスクI/Oを最適化し、クラッシュリカバリを簡素化するappend-only writesという戦略を利用しています。

サポートされているプロトコルとデプロイメント

LavinMQは、AMQP 0-9-1、MQTT、HTTP、およびstreamingを含む、一連の不可欠なメッセージングプロトコルをサポートしています。単一のバイナリとして配布されるため、デプロイメントが簡素化されます。迅速な評価のために、docker run -p 15672:15672 -p 5672:5672 cloudamqp/lavinmqという簡単なコマンドでDocker経由で実行できます。

ベンチマークのハイライト

パフォーマンスの数値は、その最適化された設計の証です。

  • ~580,000 messages/second on an AWS t4g.micro instance (2 vCPU, 1 GB RAM).
  • Over 1,000,000 messages/second on an AWS c8g.large instance (2 vCPU, 4 GB RAM).

これらの数値は、最小限のハードウェアで高いスループットを実現するLavinMQの能力をハイ活用、コストに敏感な環境や高性能な環境にとって魅力的な選択肢となります。

信頼性と耐久性に関する考慮事項

メッセージブローカーにとって、信頼性とメッセージの耐久性は極めて重要です。LavinMQを評価するユーザー、特に分散および耐故障構成において評価する場合、リーダーの失敗(leader failures)に関する挙動が重要な質問となります。具体的には、クラスター環境において、publisher confirmが少なくとも一つのフォロワーにメッセージの生存を保証するかどうかは、データ整合性と可用性を確保するための鍵となる側面です。

初期の発表では、信頼性の高いディスクストレージとレプリケーションに関する課題が強調されていますが、LavinMQがクラスター構成においてリーダーの失敗のようなシナリオをどのように処理するか、特にpublisher confirmsに関する詳細は、潜在的な導入検討者にとって価値のある情報となるでしょう。これは、強力な耐久性保証を求めるシステムにとって共通の懸念事項です。

結論

LavinMQは、高性能、リソース効率が高く、運用が透明なメッセージブローカーを構築するための、重要な取り組みを象 思しています。RabbitMQをホスティングしてきた長年の経験から生まれ、Crystal言語と細心の注意を払って最適化されたアーキテクチャにより、モデストなハードウェア上で印象的なスループットを実現します。パフォーマンス、効率、および制御の組み合わせが魅力的なオープンソース・メッセージブローカーを求める組織にとって、LavinMQは強力な候補となります。創設者たちは、コミュニティに対して、彼らのソリューションを探索し、現在のメッセージングプラクティスや、新しいブローカーへの移行を促す要因について洞察を共有することを求めています。

Sources