メッセージキューベースのアーキテクチャが最近人気を失っているのはなぜですか？

xguru · 2024-06-21T11:03:01+09:00

2010年代初頭まではMQベースの分散システム構築の話題が多かったが、最近はあまり記事を見かけない思いつくいくつかの仮説は次のとおりだが、このどれかなのか、あるいは別の考えがあるのか気になる Redisがほとんどのケースとキャッシュまで処理するようになり、もはや別個のメッセージブローカーを運用する価値が薄れた。Kafkaは本当に大規模な領域に行ってしまった。 DB（広い意味で見れば）が大規模処理をはるかにうまくこなせるようになり、「一時的な」処理もメインのストアで扱うようになった MQベースのアーキテクチャは期待したほどうまく機能しないことが分かり、いまは別の方式を使っている実際にはMQ技術が成熟期に入り、人々がわざわざ記事を書くほど面白い題材ではなくなった。ただし今でも広く使われている hnthrowaway_99 2000年代後半から2010年代前半にかけての多くの「人気」アーキテクチャは、最終的に「あなたはGoogleではない。あなたの会社がGoogleになることも絶対にない」という現実に気づいて消えていった当時は「成功した大企業が構築したやり方で構築したい」という願望が強かったしかしその後、多くの人が99%の企業にはそんな複雑さは不要だと気づいたハードウェアと標準的なデータベースがはるかに進歩したことで、こうした「Scalability Trick」が必要な企業はますます減っている「これを全部Postgresでやってはいけない理由はあるだろうか？」という自分の基準は、10年前よりずっと高くなったこのコメントへの返信いまでは妥当なコストで使える、はるかに大きなシングルマシンがある。以前は小規模クラスターが必要だったが、いまは単一システムでも多様なワークロードをかなり処理できる正直に言うと、私はGoogleでキューを取り除く複数のプロジェクトに参加していた。だから、単に人気が落ちた以上の話かもしれない biglain 皮肉っぽく言えば、私の考えではMQアーキテクチャとそれに関するブログ記事は「Resume Driven Development」だった。実際にはモノリスを超えてスケールさせる必要もなく、単一のノートPCで動かせる程度のことをしていただけなのに。こういう人たちは、おそらく毎月何百万円もAWS費用を払う悪夢のようなマイクロサービス災害を作っていた人たちで「現実のビジネス課題を実用的に解決することより、技術的な実績を積むことをキャリアの優先事項にする人たち」が、最近はAIを煽ってブログを書いている tuckerconnelly 最近、マイクロサービスが複雑すぎて重複コードも多かったので、モノリスに戻した。マイクロサービスがなければメッセージキューの必要性も下がる非同期処理ではあるプロジェクトでRabbitMQを使ったが、古すぎて過剰設計に感じたそしてその周辺ツール（Celery）も、redis（bullmq）中心で作られた最近のツールほど良くなかった多段のDAGスタイルの処理については、できるなら1つの大きなジョブで全部処理するか、少数のジョブに分けて処理する方を好む本当にDAGが必要なら、そのために特化したツール（Airflow）がある。ただ、問題のデバッグが難しいと聞くので、できるだけ避けた方がよい私はRedisのマルチノードアーキテクチャが馬鹿げているほど複雑で、スケールにも問題があると思っているので、単一ノードを使い続けている。ただし手動シャーディングは自分にとって問題なく、うまく機能しているこの記事へのkyproのコメント私の経験では、モノリスは複雑さを減らすのではなく、複雑さを移すだけだモノリス最大の問題は、ドメイン間の関心事が明確かつ明示的に分離されていないため、時間が経つとコードベースが高度に結合したスパゲティコードの混沌に変わりやすいことだ特に多くの開発者と大規模プロジェクトを作る場合、自分が触るコードのドメイン複雑性を十分理解していない開発者が多いなら、なおさらそうだモノリスは開発者が少ない小規模プロジェクトには向いているが、そうでないなら数年以内にモノリスを作ったことをたいてい後悔するだろうまた、重複コードの指摘にも同意しない。同じ言語を使い、プロジェクト間でパッケージを共有している前提なら、なぜそれが大きな問題になるのか分からないいずれにせよ、マイクロサービスで作業していてこうした問題を経験したことはないまた、マイクロサービスが平均的にモノリスより複雑かどうかについても疑問があるマイクロサービスアーキテクチャで私が最も気に入っているのは、個々のマイクロサービスを理解して貢献することがどれだけ簡単かという点だアーキテクチャやプロビジョニングはより複雑になりうるが、実際にマイクロサービスに取り組む開発者の立場では、モノリスよりはるかに簡単に作業できる democracy この考えが正しいように思う。「MQ技術は成熟して、記事を書くほど面白くはないが、それでも広く使われている」メッセージングベースのアーキテクチャは非常に人気があるこの記事へのコメント casper14 : 同意する。単なる1つの道具になっただけだ。クラウド上で仮想マシンをどう使うかについて、いまや誰も記事を書かないのと同じ bwhaley : これがまさに正解。大規模に動いているほぼすべての分散システムは、何らかの形でメッセージキューを使っていると言ってよい ipsum2 : たぶんこれだ。昔はAngularをReactに書き換える投稿が人気だったが、いまではみんな普通にReactを使うか、ReactをVueに書き換える記事を書く busterarm 不人気な答えをしてみるキュー、ストリーム、Pub/Subは、ほとんどのエンジニアがきちんと理解していない概念だいつ必要なのか分からず、正しく使う方法も分からず、見当違いの用途に使ってしまう私は今でもこれら全部（SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub）を扱っている私は北米の上位3〜4校の出身で、最も「優秀な」エンジニアだけを採用する会社で働いており、ほぼ全員にとってここが初めての職場だうちのエンジニアたちは次のような狂ったことをしてきた: RabbitMQに100MBのメッセージを何万件も一気に積んで、なぜ爆発するのか不思議がるそうするなという警告が山ほどあるのに、RabbitMQで概してかなり大きなメッセージを送る 2024年時点の最新RabbitMQで新規プロジェクトを始めて、クラシックキューを使おうとするレプリケーションポリシーなしでクォーラムキューを作る、あるいは文字どおりHAのために何もしない管理ユーザーがguest/guestのまま、クラスターをインターネットに公開する組織で最上位のアーキテクトが新しいアーキテクチャパターンを宣言し、全社会議を開いてデモをするメッセージをキューに入れ、その後バックチャネルを作って、2番目のコンシューマがキュー内メッセージをオンデマンド処理できるようにするという新たな美徳／パターンを称賛する（そしてもはやそれはキューではない）しかも私以外は誰も「順番に処理すべきメッセージをなぜキューに入れるのか？」と言わず、その「パターン」が定着した Kafkaをデフォルトのメッセージキューとして使う中央データセンターから世界中に分散したデータセンターへデータを送り、各宛先データセンターが更新済みオブジェクトを受け取ったことを確認するまで、オブジェクトにグローバルロックをかけてすべての処理を行う。しかもデータはAJAXリクエストと一緒に送られていたので、このプロセスは非同期だと主張する結局のところ、人々はそれほど大したことをする必要もないのに、なおそれなりにうまくやれてしまう。だからツールは誤用され、乱用され、十分に活用されないこともあるうまく使われているところでは、おそらくそういう話は耳にしないだろう重要な事実: うちの組織では、エンジニア1人あたり30を超えるマイクロサービスがある。頼むから誰か私を殺してくれ。巨大なモノレポに数千のマイクロサービスがある別組織で働くくらいなら、本当にカート・コバーンになりたいこの記事へのコメント zug_zug : 実データでこの理論を裏づけるとニューヨークでAkka（Scalaのイベント駆動キューイング）を使うスタートアップで働いていたなぜそうしたのか？前職のマネージャーが「何もかも遅かった時代」にこの方法で会社を「救った」から、新しい職場でも必須にしたのだろうか？キューイングが必要だった業務は何だったのか？ Webサイトで従業員の401kを表示し、資産配分を調整させ、1日に数百通のメールを送る、それだけだった予想どおり、人々は401kのサイトにほとんどログインしなかったそこで1年ほど働いたあと、サーバーがずっと誤設定されていて、基本的にWebリクエストの同時実行性が0だったことに気づいた（本番サーバー2台で必要なトラフィックは常に処理できていたので、そのことに気づかなかった）結局、不要で無意味な複雑さを増すだけだとしてAkkaを撤去した先月この会社は現金回収オプション付きの追加資金調達ラウンドを実施したが、明らかに企業価値は上がっており、今でも順調そうだ scary-size : それって本当に「優秀な」エンジニアだけを雇っているようには見えないけど？ roncesvalles : 設計レビューのプロセスがないように見える。それに私なら有名大学卒より、無名大学出身で2〜5年目の開発者を採ると思う。ソフトウェアエンジニアがキャリア最初の5年で学び成長する量は膨大で、おそらく残りのキャリア全部を合わせたより多い。 burutthrow MQはかなりコモディティ化したと思う ConfluentやRedPanda、あるいはMSKをサービスとして買えば、Kafkaを自前で管理する必要はない変更データキャプチャ（CDC）も非常に優秀で、メインストリームになった。RDBMSにデータを書き、その変更データを捕捉して他システムへ伝搬するのは比較的容易だたとえば、メッセージキューはCDCシステムがメッセージ配送に使うバックボーンにすぎないので、この種のパターンでは人々がKafkaについて書かなくなるということだこうしたアーキテクチャは明らかに今でも存在し、大半の組織の制約条件を満たしている Kafkaのように一度書いて何度も読むキューがあるなら、組織内の別の部門にAPIを公開することになる。多くの会社がこのパターンを使って複数チーム間でデータを活用している多数のマイクロサービスを抱える小規模チームは履歴書主導の開発者っぽく感じるが、エンジニアが100人を超える会社ではこのパターンは理にかなっている angarg12 MQは分散システムの道具箱の中の1つの道具だ。適切な場面では非常によく機能するあなたの仮説の中で本当に当てはまるものがあるとすれば、私はこれだと思う。「人はたいてい、新しくてきらびやかなものについてブログを書く」私は個人的に、設計では常にキューを使う。特に結合度の低い異なるシステム間でデータを渡すときにキューを使う自分が経験した唯一の痛みは、上流システムから7日分のデータを再投入したことで、古いリクエストでキューが詰まったときだった普通に実行していたら、全データの処理に100時間以上かかり、新しいデータのレイテンシもとんでもなく増えていただろう解決策は、キューを手動で捨てて、欠けていた最新データを手動で再投入することだった無制限なキューサイズには注意すべきだが、それでも優れた道具だと思う rossdavidh MQはGartner Hype Cycle では '過度な期待のピーク(Peak of inflated expectations)'を過ぎ '幻滅の谷(trough of disillusionment)'を抜け '啓発の坂(Slope of Enlightenment)'、さらには '生産性の高原(plateau of productivity)'へ向かっている robertclaus 「もちろん私たちは皆、いまでもメッセージキューとワーカーを使っていて、ただそれについて書かなくなっただけだ」というコメントが、マイクロサービスや実際のスケーラビリティをめぐる議論のせいで埋もれてしまっているのは非常に興味深いこのコメントを読むジュニアエンジニアは、Webサーバー上の重い計算をワーカーに逃がしてはいけなくなったのだ、という誤った印象を受けかねない pm90 その技術が退屈なものになったので、関連ブログ記事が減ったこれは良いことだ。たとえばRabbitMQの公式ドキュメントはずっと良くなり、とても役に立つ人々はPostgres/MySQLを使うのと同じ感覚でこれを主力として使っているアーキテクチャなどを設計するのに驚くような技術も必要ない私は退屈なソフトウェアが大好きだ "I love boring software" slowmovintarget こうしたアーキテクチャの多くは企業のデータセンターで動いていたクラウドへ移行し、小さなステートレスサービスを作るようになり（SPAの登場もあって）、複雑な段階的イベント駆動システムの必要性が薄れたたとえばAWSでは、SQSと少しのSNS、あるいはいくつかの用途でKinesisを使えば十分だ。ここではMQはもはや設計の中心ではない MQベースのアーキテクチャはデータ処理には向いているが、対話型Webサイトには向かない。多くの人が作っているのが対話型Webサイトなら、選ばれにくいのは当然だろう私は今でもデータ処理向けのイベントシステムを設計している（特に、新しい事実はあるが「誤っている」か、以前の時点で別の情報を知っているべきだった、不変なビジネスデータの場合）しかし大半のアプリでは……必要ない mannyv うちのバックエンド全体はキューベースだ非同期で、速い応答時間が必要ないならキューを使う。簡単で安定しており、キューはLambdaを駆動できるまた、キューを使うとメトリクスや性能データの収集も容易になる。負荷が高いときには、キューに最大で数百万件のメッセージが膨らみ、時間とともに減っていくし、必要なら数百のLambdaを立ち上げて、すべてのメッセージを処理することもできる vishnugupta 私の経験では、MQは抽象化されただけで、消えたわけではないたとえばSQS + ポーリングのキューは、サーバーをあまり呼ばないプロセスへと変わった。どこかにメッセージキューはあるが、露出しなくなっただけだ SQSよりさらに一段抽象化されたAWS SNSは機能が非常に豊富になり、事実上SQSを置き換えられるようになったまた、ストリーミングが非常に安定した技術になったため、キューをストリーミングパイプとして使っていたユースケースは、ストリーミング専用へ移行した memset Lambda（クラウドファンクション）がより一般的になり、複数のプラットフォームでサポートされるようになったからかもしれない何かをキューに追加したら、最終的にはキューから取り出して処理しなければならない。Lambdaなら1回の呼び出しでそれができる。また、ワーカーを実行したりスケールさせたりする必要もない Kafkaは一時的なデータストアとして使われ、ストリームから取り込む大きなエコシステムがあるので、今でも人気を保っているのだと思う私は個人的にキューを多用しており、オープンソースのSQS代替を作っている。オープンソースのLambda代替も役に立つのではないかと思っている liampulles 「MQ技術は成熟期に入り、人々が記事を書くほど面白くはないが、それでも広く使われている」これが正しい。シンプルなPub/Subメッセージングを使った非同期通信の単純なユースケースは非常に有用で、使うのもそれほど難しくないと思う私たち（開発者コミュニティとして）は、イベントソーシングや複雑なネットワーク、不必要な大規模構築を乗り越えた。つまり、誇大宣伝のサイクルを過ぎたということだ私たちのチームは、非同期Pub/Subと同期Request/ResponseにNATSを使っているこれはコマンドベースのモデルで、送信したすべてのメッセージを含む巨大なログテーブルがあるスキーマとそれらのメッセージの利用はチーム内限定で、利用後はNATSから削除される私たちはat-least-once deliveryを採用しており、メッセージハンドラには冪等性があることを前提としている NATSの誤設定でメッセージ再生やメッセージ欠落の問題が1〜2件あったが、全体としては非常に成功しており、私たちは3人の開発チームだった私の考えではKubernetesのようなものだ。基本を守って、賢くやりすぎなければうまく機能する

(news.ycombinator.com)

49 ポイント投稿者 xguru 2024-06-21 | 11件のコメント | WhatsAppで共有

2010年代初頭まではMQベースの分散システム構築の話題が多かったが、最近はあまり記事を見かけない
思いつくいくつかの仮説は次のとおりだが、このどれかなのか、あるいは別の考えがあるのか気になる
- Redisがほとんどのケースとキャッシュまで処理するようになり、もはや別個のメッセージブローカーを運用する価値が薄れた。Kafkaは本当に大規模な領域に行ってしまった。
- DB（広い意味で見れば）が大規模処理をはるかにうまくこなせるようになり、「一時的な」処理もメインのストアで扱うようになった
- MQベースのアーキテクチャは期待したほどうまく機能しないことが分かり、いまは別の方式を使っている
- 実際にはMQ技術が成熟期に入り、人々がわざわざ記事を書くほど面白い題材ではなくなった。ただし今でも広く使われている

hnthrowaway_99

2000年代後半から2010年代前半にかけての多くの「人気」アーキテクチャは、最終的に「あなたはGoogleではない。あなたの会社がGoogleになることも絶対にない」という現実に気づいて消えていった
当時は「成功した大企業が構築したやり方で構築したい」という願望が強かった
しかしその後、多くの人が99%の企業にはそんな複雑さは不要だと気づいた
ハードウェアと標準的なデータベースがはるかに進歩したことで、こうした「Scalability Trick」が必要な企業はますます減っている
「これを全部Postgresでやってはいけない理由はあるだろうか？」という自分の基準は、10年前よりずっと高くなった
このコメントへの返信
- いまでは妥当なコストで使える、はるかに大きなシングルマシンがある。以前は小規模クラスターが必要だったが、いまは単一システムでも多様なワークロードをかなり処理できる
- 正直に言うと、私はGoogleでキューを取り除く複数のプロジェクトに参加していた。だから、単に人気が落ちた以上の話かもしれない

biglain

皮肉っぽく言えば、私の考えではMQアーキテクチャとそれに関するブログ記事は「Resume Driven Development」だった。実際にはモノリスを超えてスケールさせる必要もなく、単一のノートPCで動かせる程度のことをしていただけなのに。
こういう人たちは、おそらく毎月何百万円もAWS費用を払う悪夢のようなマイクロサービス災害を作っていた人たちで
「現実のビジネス課題を実用的に解決することより、技術的な実績を積むことをキャリアの優先事項にする人たち」が、最近はAIを煽ってブログを書いている

tuckerconnelly

最近、マイクロサービスが複雑すぎて重複コードも多かったので、モノリスに戻した。マイクロサービスがなければメッセージキューの必要性も下がる
非同期処理ではあるプロジェクトでRabbitMQを使ったが、古すぎて過剰設計に感じた
そしてその周辺ツール（Celery）も、redis（bullmq）中心で作られた最近のツールほど良くなかった
多段のDAGスタイルの処理については、できるなら1つの大きなジョブで全部処理するか、少数のジョブに分けて処理する方を好む
本当にDAGが必要なら、そのために特化したツール（Airflow）がある。ただ、問題のデバッグが難しいと聞くので、できるだけ避けた方がよい
私はRedisのマルチノードアーキテクチャが馬鹿げているほど複雑で、スケールにも問題があると思っているので、単一ノードを使い続けている。ただし手動シャーディングは自分にとって問題なく、うまく機能している
この記事へのkyproのコメント
- 私の経験では、モノリスは複雑さを減らすのではなく、複雑さを移すだけだ
- モノリス最大の問題は、ドメイン間の関心事が明確かつ明示的に分離されていないため、時間が経つとコードベースが高度に結合したスパゲティコードの混沌に変わりやすいことだ
- 特に多くの開発者と大規模プロジェクトを作る場合、自分が触るコードのドメイン複雑性を十分理解していない開発者が多いなら、なおさらそうだ
- モノリスは開発者が少ない小規模プロジェクトには向いているが、そうでないなら数年以内にモノリスを作ったことをたいてい後悔するだろう
- また、重複コードの指摘にも同意しない。同じ言語を使い、プロジェクト間でパッケージを共有している前提なら、なぜそれが大きな問題になるのか分からない
- いずれにせよ、マイクロサービスで作業していてこうした問題を経験したことはない
- また、マイクロサービスが平均的にモノリスより複雑かどうかについても疑問がある
- マイクロサービスアーキテクチャで私が最も気に入っているのは、個々のマイクロサービスを理解して貢献することがどれだけ簡単かという点だ
- アーキテクチャやプロビジョニングはより複雑になりうるが、実際にマイクロサービスに取り組む開発者の立場では、モノリスよりはるかに簡単に作業できる

democracy

この考えが正しいように思う。「MQ技術は成熟して、記事を書くほど面白くはないが、それでも広く使われている」
メッセージングベースのアーキテクチャは非常に人気がある
この記事へのコメント
- casper14 : 同意する。単なる1つの道具になっただけだ。クラウド上で仮想マシンをどう使うかについて、いまや誰も記事を書かないのと同じ
- bwhaley : これがまさに正解。大規模に動いているほぼすべての分散システムは、何らかの形でメッセージキューを使っていると言ってよい
- ipsum2 : たぶんこれだ。昔はAngularをReactに書き換える投稿が人気だったが、いまではみんな普通にReactを使うか、ReactをVueに書き換える記事を書く

busterarm

不人気な答えをしてみる
キュー、ストリーム、Pub/Subは、ほとんどのエンジニアがきちんと理解していない概念だ
- いつ必要なのか分からず、正しく使う方法も分からず、見当違いの用途に使ってしまう
- 私は今でもこれら全部（SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub）を扱っている
私は北米の上位3〜4校の出身で、最も「優秀な」エンジニアだけを採用する会社で働いており、ほぼ全員にとってここが初めての職場だ
うちのエンジニアたちは次のような狂ったことをしてきた:
- RabbitMQに100MBのメッセージを何万件も一気に積んで、なぜ爆発するのか不思議がる
- そうするなという警告が山ほどあるのに、RabbitMQで概してかなり大きなメッセージを送る
- 2024年時点の最新RabbitMQで新規プロジェクトを始めて、クラシックキューを使おうとする
- レプリケーションポリシーなしでクォーラムキューを作る、あるいは文字どおりHAのために何もしない
- 管理ユーザーがguest/guestのまま、クラスターをインターネットに公開する
- 組織で最上位のアーキテクトが新しいアーキテクチャパターンを宣言し、全社会議を開いてデモをする
  - メッセージをキューに入れ、その後バックチャネルを作って、2番目のコンシューマがキュー内メッセージをオンデマンド処理できるようにするという新たな美徳／パターンを称賛する（そしてもはやそれはキューではない）
  - しかも私以外は誰も「順番に処理すべきメッセージをなぜキューに入れるのか？」と言わず、その「パターン」が定着した
- Kafkaをデフォルトのメッセージキューとして使う
- 中央データセンターから世界中に分散したデータセンターへデータを送り、各宛先データセンターが更新済みオブジェクトを受け取ったことを確認するまで、オブジェクトにグローバルロックをかけてすべての処理を行う。しかもデータはAJAXリクエストと一緒に送られていたので、このプロセスは非同期だと主張する
結局のところ、人々はそれほど大したことをする必要もないのに、なおそれなりにうまくやれてしまう。だからツールは誤用され、乱用され、十分に活用されないこともある
うまく使われているところでは、おそらくそういう話は耳にしないだろう
重要な事実: うちの組織では、エンジニア1人あたり30を超えるマイクロサービスがある。頼むから誰か私を殺してくれ。巨大なモノレポに数千のマイクロサービスがある別組織で働くくらいなら、本当にカート・コバーンになりたい
この記事へのコメント
- zug_zug : 実データでこの理論を裏づけると
  - ニューヨークでAkka（Scalaのイベント駆動キューイング）を使うスタートアップで働いていた
  - なぜそうしたのか？前職のマネージャーが「何もかも遅かった時代」にこの方法で会社を「救った」から、新しい職場でも必須にしたのだろうか？
  - キューイングが必要だった業務は何だったのか？ Webサイトで従業員の401kを表示し、資産配分を調整させ、1日に数百通のメールを送る、それだけだった
  - 予想どおり、人々は401kのサイトにほとんどログインしなかった
  - そこで1年ほど働いたあと、サーバーがずっと誤設定されていて、基本的にWebリクエストの同時実行性が0だったことに気づいた
  - （本番サーバー2台で必要なトラフィックは常に処理できていたので、そのことに気づかなかった）
  - 結局、不要で無意味な複雑さを増すだけだとしてAkkaを撤去した
  - 先月この会社は現金回収オプション付きの追加資金調達ラウンドを実施したが、明らかに企業価値は上がっており、今でも順調そうだ
- scary-size : それって本当に「優秀な」エンジニアだけを雇っているようには見えないけど？
- roncesvalles : 設計レビューのプロセスがないように見える。それに私なら有名大学卒より、無名大学出身で2〜5年目の開発者を採ると思う。ソフトウェアエンジニアがキャリア最初の5年で学び成長する量は膨大で、おそらく残りのキャリア全部を合わせたより多い。

burutthrow

MQはかなりコモディティ化したと思う
ConfluentやRedPanda、あるいはMSKをサービスとして買えば、Kafkaを自前で管理する必要はない
変更データキャプチャ（CDC）も非常に優秀で、メインストリームになった。RDBMSにデータを書き、その変更データを捕捉して他システムへ伝搬するのは比較的容易だ
たとえば、メッセージキューはCDCシステムがメッセージ配送に使うバックボーンにすぎないので、この種のパターンでは人々がKafkaについて書かなくなるということだ
こうしたアーキテクチャは明らかに今でも存在し、大半の組織の制約条件を満たしている
Kafkaのように一度書いて何度も読むキューがあるなら、組織内の別の部門にAPIを公開することになる。多くの会社がこのパターンを使って複数チーム間でデータを活用している
多数のマイクロサービスを抱える小規模チームは履歴書主導の開発者っぽく感じるが、エンジニアが100人を超える会社ではこのパターンは理にかなっている

angarg12

MQは分散システムの道具箱の中の1つの道具だ。適切な場面では非常によく機能する
あなたの仮説の中で本当に当てはまるものがあるとすれば、私はこれだと思う。「人はたいてい、新しくてきらびやかなものについてブログを書く」
私は個人的に、設計では常にキューを使う。特に結合度の低い異なるシステム間でデータを渡すときにキューを使う
自分が経験した唯一の痛みは、上流システムから7日分のデータを再投入したことで、古いリクエストでキューが詰まったときだった
- 普通に実行していたら、全データの処理に100時間以上かかり、新しいデータのレイテンシもとんでもなく増えていただろう
- 解決策は、キューを手動で捨てて、欠けていた最新データを手動で再投入することだった
無制限なキューサイズには注意すべきだが、それでも優れた道具だと思う

rossdavidh

MQはGartner Hype Cycle では
- '過度な期待のピーク(Peak of inflated expectations)'を過ぎ
- '幻滅の谷(trough of disillusionment)'を抜け
- '啓発の坂(Slope of Enlightenment)'、さらには '生産性の高原(plateau of productivity)'へ向かっている

robertclaus

「もちろん私たちは皆、いまでもメッセージキューとワーカーを使っていて、ただそれについて書かなくなっただけだ」というコメントが、マイクロサービスや実際のスケーラビリティをめぐる議論のせいで埋もれてしまっているのは非常に興味深い
このコメントを読むジュニアエンジニアは、Webサーバー上の重い計算をワーカーに逃がしてはいけなくなったのだ、という誤った印象を受けかねない

pm90

その技術が退屈なものになったので、関連ブログ記事が減った
これは良いことだ。たとえばRabbitMQの公式ドキュメントはずっと良くなり、とても役に立つ
人々はPostgres/MySQLを使うのと同じ感覚でこれを主力として使っている
アーキテクチャなどを設計するのに驚くような技術も必要ない
私は退屈なソフトウェアが大好きだ "I love boring software"

slowmovintarget

こうしたアーキテクチャの多くは企業のデータセンターで動いていた
クラウドへ移行し、小さなステートレスサービスを作るようになり（SPAの登場もあって）、複雑な段階的イベント駆動システムの必要性が薄れた
たとえばAWSでは、SQSと少しのSNS、あるいはいくつかの用途でKinesisを使えば十分だ。ここではMQはもはや設計の中心ではない
MQベースのアーキテクチャはデータ処理には向いているが、対話型Webサイトには向かない。多くの人が作っているのが対話型Webサイトなら、選ばれにくいのは当然だろう
私は今でもデータ処理向けのイベントシステムを設計している（特に、新しい事実はあるが「誤っている」か、以前の時点で別の情報を知っているべきだった、不変なビジネスデータの場合）
しかし大半のアプリでは……必要ない

mannyv

うちのバックエンド全体はキューベースだ
非同期で、速い応答時間が必要ないならキューを使う。簡単で安定しており、キューはLambdaを駆動できる
また、キューを使うとメトリクスや性能データの収集も容易になる。
- 負荷が高いときには、キューに最大で数百万件のメッセージが膨らみ、時間とともに減っていくし、
- 必要なら数百のLambdaを立ち上げて、すべてのメッセージを処理することもできる

vishnugupta

私の経験では、MQは抽象化されただけで、消えたわけではない
たとえばSQS + ポーリングのキューは、サーバーをあまり呼ばないプロセスへと変わった。どこかにメッセージキューはあるが、露出しなくなっただけだ
SQSよりさらに一段抽象化されたAWS SNSは機能が非常に豊富になり、事実上SQSを置き換えられるようになった
また、ストリーミングが非常に安定した技術になったため、キューをストリーミングパイプとして使っていたユースケースは、ストリーミング専用へ移行した

memset

Lambda（クラウドファンクション）がより一般的になり、複数のプラットフォームでサポートされるようになったからかもしれない
何かをキューに追加したら、最終的にはキューから取り出して処理しなければならない。Lambdaなら1回の呼び出しでそれができる。また、ワーカーを実行したりスケールさせたりする必要もない
Kafkaは一時的なデータストアとして使われ、ストリームから取り込む大きなエコシステムがあるので、今でも人気を保っているのだと思う
私は個人的にキューを多用しており、オープンソースのSQS代替を作っている。オープンソースのLambda代替も役に立つのではないかと思っている

liampulles

「MQ技術は成熟期に入り、人々が記事を書くほど面白くはないが、それでも広く使われている」
- これが正しい。シンプルなPub/Subメッセージングを使った非同期通信の単純なユースケースは非常に有用で、使うのもそれほど難しくないと思う
私たち（開発者コミュニティとして）は、イベントソーシングや複雑なネットワーク、不必要な大規模構築を乗り越えた。つまり、誇大宣伝のサイクルを過ぎたということだ
私たちのチームは、非同期Pub/Subと同期Request/ResponseにNATSを使っている
- これはコマンドベースのモデルで、送信したすべてのメッセージを含む巨大なログテーブルがある
- スキーマとそれらのメッセージの利用はチーム内限定で、利用後はNATSから削除される
- 私たちはat-least-once deliveryを採用しており、メッセージハンドラには冪等性があることを前提としている
NATSの誤設定でメッセージ再生やメッセージ欠落の問題が1〜2件あったが、全体としては非常に成功しており、私たちは3人の開発チームだった
私の考えではKubernetesのようなものだ。基本を守って、賢くやりすぎなければうまく機能する

11件のコメント

finnchoi 2024-06-25

キューが必要な適切な場面はあります。しかし、ほとんどの規模や利用形態では、キューを使ったりクラスタを構成して動かしたりすることが、複雑性を高める一方で、性能面では大きな利点がない場合が多いです。拡張性や大規模データを考慮して構成された大企業自慢の複雑な構造が、自分のシステムに適切になる時点は来ないかもしれません。

技術的に魅力の高い新技術や格好いい構造であっても、現実的な問題を踏まえて適切なソリューションを選ぶことが必要です。ほとんどの場合、処理すべき大きなデータはなく、PostgreSQLで処理できるケースも多いです。

私たちはこうした問題を認識し、シンプルな構成でTB単位のデータを単一ノードで処理可能なDBを開発しています。少し慎重ではありますが、別の選択肢として検討してみることをお勧めします。
判例データを高速に検索可能な状態にする

dakbutfly 2024-06-24

一般的に、手続き指向は理解しやすい一方で、MQ 方式はすぐにはピンと来なかったり、構造を理解するのが難しかったりするのだと思います。会社では一般的に知識レベルが同じではないことも多いですが、そのとき誤った知識で MQ を使うと地獄になるように思います。

これは MQ だけでなく、ある程度の知識を必要とする技術の多くが、十分な教育なしに適用されたときに常に起こる問題だと思います.

nemorize 2024-06-21

PHPでは、MQは事実上必須です...

halfenif 2024-06-21

グサッ！

今ちょうど、Toy Projectで Quee という名前の入ったものを進めているところなんですが。

kandk 2024-06-21

正直、国内でしかサービスしない 99% のケースなら、全部必要ないと思います..

superwoou 2024-06-21

サービスの範囲よりも、サービスの性質や、どれだけコスト効率を重視すべきかを見極めることのほうが重要ではないでしょうか?

2024-06-21

[このコメントは非表示になっています。]

bus710 2024-06-22

意思決定のプロセスがどうしても垂直的になりがちなので、「手続き指向」のほうが好まれたり、適していると考えられているからなのでしょうか?
もし各部門やチームが疎結合に組織されているなら、手続き指向ではないアーキテクチャのほうがより円滑に動作し、その結果こうしたキューの応用もよりうまく機能するのではないかと気になります。

savvykang 2024-06-21

履歴書主導の開発が、こうした流行現象を貫くキーワードのようですね

hyeonseokoh94 2024-06-22

いや、名言ですね。履歴書主導開発とは……

savvykang 2024-06-23

姉妹編として煽り主導開発もあります