[B! 分散] wyukawaのブックマーク

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

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

wyukawa 2018/06/18

分散
queue

リンク

分散プログラミングモデルおよびデザインパターンの考察その3 - Software Transactional Memo

昨日に引き続いて分散システムのデザインパターンについて書いていきたい。だがそれ以前に故障モデルに関する前提を忘れてはならない。人によって様々な方針があるが、個人的には分散システムの世界において意識しなくてはならない故障モデルは4つだと考えている。僕は前回のブログに書いた Replication の本をベースに書いており、少し言葉遣いや定義が他とやや違う点は許して欲しい。また、通信の脱落・遅延とはレイヤーが異なる議論である。故障モデルの分類故障が起きないモデルこれは故障が起きない世界を仮定するモデルである。これ自体はプロダクションにそのまま投入できるものではない。だがこの故障モデルを想定しても解けない問題は故障が発生する状況では絶対解けない事が断言できたり、合意プロトコルが正しいかを議論する土台となったり、様々な実用的なアルゴリズムや分散システムの土台となるアルゴリズムが生まれる土壌

wyukawa 2016/02/23

リンク

分散プログラミングモデルおよびデザインパターン - kuenishi's blog

同名の某記事について。僕がタイトルから想像する期待を、なんだか意外な方向に裏切ってくれた記事であった。批判するだけではよくないので、同じタイトルで僕ならどういう話になるか…という話をしよう。絵のない長文だ覚悟して読め(ΦωΦ)ﾌﾌﾌ…。分散プログラミングモデルプログラミングモデルとはなんであろうか。 …CもJavaもMPIも登場していない1972年の論文を持ってこられてそれがオリジナルだみたいなこと言われてもえー…って感じで、Flynnの1972年の論文は並列計算やHPCの方面へ非常に大きな影響を与えていると思う。ただしそれはCPU内の話であって、時代が進むと共にたとえば牧野先生の日記「並列計算機のプログラミングモデル」で書かれているような議論につながるといえば繋がるには繋がるが、このレベルで計算を並列化する議論にしか応用できない。せいぜい、プログラミングモデルとひとくちにいっても様々

wyukawa 2016/02/19

リンク

シンプルな分散ジョブスケジューラを作ってみた #appkoyomi - weblog of key_amb

github.com 掲題の通り、軽量動作する分散ジョブスケジューラを作ってみました。名前は Koyomi としました。 Perl で書きました。CPAN にもアップしています。*1 Motivation 出発点となった課題感としては、だいたい cron の冗長化法について調べてみた #cron - weblog of key_amb という記事に書いた通りです: バッチサーバの冗長化は割と見過ごされやすいやろうとするとちょっと面倒上の記事では cron を冗長化するやり方をいくつか紹介したのですが、NFS は SPOF になりやすいし、keepalived を使ったやり方もなんだかトリッキーで少し複雑な気がしないでもないです。そこで、もっとシンプルに高可用性を達成するやり方はないかなと考えて、実装してみました。動作原理仕掛けは割と単純で、スケジュールのデータストアをスケジュー

wyukawa 2015/05/30

cron
分散

リンク

CAP定理を見直す。“CAPの3つから2つを選ぶ”という説明はミスリーディングだった

分散システムにおいては以下の3つの要素のうち2つしか同時に満たすことができない、というCAP定理を提唱したのは、Eric Brewer氏でした。 C：Consistency（一貫性） A：Availability（可用性） P：Tolerance to network Paritions（ネットワーク分断への耐性）一般にリレーショナルデータベースでは、一貫性（C）と可用性（A）をできるだけ保証する代わりに、ネットワーク分断への耐性（P）を犠牲にしています。ネットワークが途中で切れたり大きく遅延した場合、動作が保証されなくなってしまうわけです。一方でNoSQLでは一貫性（C）よりも可用性（A）とネットワーク分断への耐性（P）を優先させるものが多く、分散システムでの動作に向いていると説明されます。このようにNoSQLの説明にこのCAP定理がしばしば引用されることになり、NoSQLの普及とと