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

Yahooの技術者が書いたブログ techblog.yahoo.co.jp が悪い方向に期待を裏切ってくれたのに対し、 @kuenishi さんがまとまった文章 kuenishi.hatenadiary.jp を書いていたので、僕も2番煎じぐらいでまとまった文章を書く。 始めに断っておくと、分散システムというのはまだまだ事例を集めていくフェーズを抜けきっておらず、体系立った大統一理論的な分類法は確立していない。ここに書くのは、これまでの分散システム事例やこれからの分散システム事例を分類していく際にその性質をカテゴライズする一助となれば良いな、程度の文章なのであまり真に受けないで欲しい。 なぜYahooの記事が期待はずれなのか 人によって意見はあるとは思うが、個人的に感じたのは以下の３つ。 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじ

[takc923]

h

[you21979]

「小さなシステムでは達成不能なパフォーマンスを実現するため（性能） 個々のコンピュータで故障が発生しても動き続けて欲しいため（耐故障）」

[NineGates]

分散プログラミングモデルおよびデザインパターンの考察 その1 が悪い方向に期待を裏切ってくれたのに対し、 @kuenishi さんがまとまった文章 Tags: from Pocket February 23, 2016 at 12:24PM via IFTTT

[takezaki]

おお

[t-wada]

"人間が分散システムをわざわざ構成する理由 1. 小さなシステムでは達成不能なパフォーマンスを実現するため（性能） 2. 個々のコンピュータで故障が発生しても動き続けて欲しいため（耐故障）"

[toyama0919]

“「部分的に故障しても動くシステム」”

[vanbraam]

プログラミング・モデルを論じるのであれば"ソフトウェア側からの一方的な眺め"でOKな気もする.どの部分までを"as code"とみなすのかという議論もありそうだが;NUMAはGoogle内では普通に使われてると想像.cf.b:id:entry:263935395

[somemo]

“始めに断っておくと、分散システムというのはまだまだ事例を集めていくフェーズを抜けきっておらず、体系立った大統一理論的な分類法は確立していない”