分散キューという名の苦しみ - Software Transactional Memo

TL;DR 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 システムの抽象 コンピュータの世界は、本来は0と1の信号の羅列が飛び交う無機質なものである。でも人類は信号だけですべてを語らず、様々な喩えを定義してきた。それはデスクトップ・ウィンドウ・マウスカーソルといったグラフィカルな表現に留まらず、パケットやカプセル化といった用語にロック・キュー・リスト・木などのアルゴリズムやデータ構造の世界にも自然に溶け込んでいる。これらはすべて人間の理解を助けるための喩え話に過ぎず、この喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた。 人間が大きなシステムを作るときも何らかの喩えを用いてシステム全体を整理する。アーキテクチャの「ポンチ絵」を描いて情報共有をするのは企業に勤めていれば経験した人も多いだろう。パワーポイン

[koba789]

引用してコメントしようと思ったら id:gfx さんが全く同じ箇所を引用していた。Exactly Once にするために俺は引用をやめました

[gfx]

"Exactly Onceな実行というのは何か特定のミドルウェアを使えば魔法のようにいつのまにか解決されるものではなく、アプリ層まで深く食い込んで設計されて初めてなし得る物である"

[taruhachi]

RDBじゃスケールしないし辛い。→分散キューに入れようぜ→分散キュー辛い→おすすめはRDBに入れること→→以下ループ。

[terurou]

開発対象にもよるんだけど、RDBで収まるようなのはRDB使えばいいし、それを超えるようなのはEventual Consistencyでやるしかないかなぁというのが過去の経験値。キューの話でもあるし、トランザクションの話でもあるやつ。

[teppeis]

「キューを用いたパターンはパワポの絵から実体化して運用に乗せるとびっくりするほど多くの地雷を踏むことになる」exactly once, at least once とかは簡単ではないよという話

[kuenishi]

よい実装の有無は別にしてAMQPの仕様を読んでみることをおすすめしたい

[youhey]

その地雷を承知でDBでどうにもならんからキュー使ってるんじゃないのかな？

[wata88]

exactly at once カジュアルに崩壊するなーって印象なので考えたくない

[lombriz]

いくつか踏み抜いた覚えのあるものがあがっていて、思い出してしまって胃が…

[naqtn]

頭の中に押し込むための便利な抽象化モデルが、実装レベルのあれやこれやに必ずしも対応できるわけではない、と。分かっちゃいるけど忘れがち。

[kagehiens]

RDBのキュー管理で速度が十分でない奴を組んだことがないのだが、ブコメで書かれている話はそれ本当に順番で処理する必要がある奴なのか…?単一障害点…まぁなるけどリトライ系統あれば…まぁケースバイケースかな。

[areyoukicking]

“結局欲しいのは永続化されてて入力速度と出力速度の緩衝装置に過ぎない順序付きのストレージ”

[juve534]

イベント駆動の提案をするけど、難しいのも知っているから躊躇しちゃうんだなー

[als_uz]

あーーーたしかに。結局DBに置いちゃうのが正解だったりする

[efcl]

分散キューの有限リソースによるキューが詰まる問題、リトライの難しさやPush通知とPollingの話。 DBにStateを入れて管理する話

[KeithYokoma]

Push通知の話めっちゃわかる

[T-miura]

ちょうど、キュー系の案件やってるので

[fake-jizo]

TL;DR; 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 Tags: facebook, ifttt via Pocket

[joker1007]

タブに紛れて読むの忘れていた。

[ledsun]

良かった。RDBでなくてドキュメントDB使ったらどうなるだろうか？ジョブのログ（=状態）をドキュメントの属性として追記していくの。

[kitokitoki]

“分散キューという名の苦しみ”

[takuya_1st]

RDBに入れても「失敗」のステータスが無いので、問題は解決してなくね？RDBだとredisみたいに行かないのでポーリングが必要だし。うーん

[nanoha3]

“喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた”

[Kiske]

わかる

[reitanigawa]

キューをポーリングすればいいんじゃないか（えっ）

[Hash]

驚くほど良い記事… キューの代替案として RDBMS 使って状態を持つレコードをロック取って進めていく, てのは納得感ある

[progrhyme]

キューを使ったシステムのペインポイント

[ikaro1192]

「分散システムにおいてキューという抽象化で設計を行うと、一気にいろんな問題を解決したように見える一方、発生する大量の問題を無意識の内に都合の良い架空の無限で壊れないキューの中にしわ寄せしたに過ぎない」

[masayuki5160]

たしかに分散キューはすべて解決してくれそうにはじめはみえた。

[somemo]

“Exactly OnceとかAtleast Once対応なんて喧伝されていることはよくあるが、仮にそのような信頼性をミドルウェアのレイヤーだけで解決しているとしたら、そのミドルウェア自体がSPoF(単一障害点)となるだろう。”

[kitaj]

それな

[infobloga]

キューを使おうと思ったら、結局、RDBになってしまうというのは良くあることだけれど、それをうまく言語化してくれた記事。

[sonots]

わいわい

[utisam]

パワポの絵から実体化すると死ぬやつ、他にもたくさんありそう。

[dkfj]

システムの境界としてキューを使うケースが多いかな。同一システム内であれば、キューでないソリューションを使う事が多い。もちろん例外もある

[t-tanaka]

究極的にExactly Onceを実現しようとすると，メッセージングミドルウェア自体をトランザクションマネージャーにするしかない。が，IBM MQ以外にTMになれるMOMは見たことない。

[baronhorse]

あふれたらどうすんねんまで考えとかないと運用できないよね

[uehaj]

「結局欲しいのは永続化され入力速度と出力速度の緩衝装置に過ぎない順序付きのストレージに過ぎない事も良くある。信頼できるストレージに放り込んで順序に関しては別手段で解決するほうが困難を分割して対処できる

[hiyuzawa]

“Exactly Onceな実行というのは何か特定のミドルウェアを使えば魔法のようにいつのまにか解決されるものではなく、アプリ層まで深く食い込んで設計されて初めてなし得る物である。 他にも、結局欲しいのは永続化されて