分散キューという名の苦しみ - Software Transactional Memo
TL;DR 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 システムの抽象 コンピュータの世界は、本来は0と1の信号の羅列が飛び交う無機質なものである。でも人類は信号だけですべてを語らず、様々な喩えを定義してきた。それはデスクトップ・ウィンドウ・マウスカーソルといったグラフィカルな表現に留まらず、パケットやカプセル化といった用語にロック・キュー・リスト・木などのアルゴリズムやデータ構造の世界にも自然に溶け込んでいる。これらはすべて人間の理解を助けるための喩え話に過ぎず、この喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた。 人間が大きなシステムを作るときも何らかの喩えを用いてシステム全体を整理する。アーキテクチャの「ポンチ絵」を描いて情報共有をするのは企業に勤めていれば経験した人も多いだろう。パワーポイン
分散ロックという名の過ち - Software Transactional Memo
 TL;DR; 「分散ロック」が分散システムの設計図に登場した時 だいたいその設計は間違っていて本当に必要なものはトランザクションだ 並行システムを実装する際にロックを用いるのはとても自然なことだ。 僕も普段はロックフリー系のアルゴリズムに詳しいと言われがちだが知識量でいったら実はロック系の方が多く蓄えているかも知れない。 分散システムは並行システムであることが多いので、その中にロックが登場するのはとても自然な発想である。 よく「分散」「並行」「並列」の言葉の定義がごっちゃになっているケースがあり、この記事の主題にしたいわけではないので深くは言及しないが、分散システムは環境などの要因で突如として参加者が音信不通になったり復活したりする点で並行システムと大きく異なる。 並行システムと同じノリで分散システムを設計しようとした際に陥る頻出の過ちが「分散ロック」である。そのアイデアはとても簡単で
分散システムについて語らせてくれ。顛末と反省。 - Software Transactional Memo
8/10のNTT Tech Conference #2 にて発表の時間をもらってこのタイトルで喋ってきた ntt-developers.github.io 発表が決まるまで これはNTTグループ内のソフトウェア・ネットワーク系技術者が集まるコミュニティで、誰が発表者になれるかは投稿されたProposalに対するコミュニティ内での投票によって選考される。 何を話したいか自分の中でも固まりきっていなかった上に、主催者の話をロクに聞いていなかった自分は小さい部屋で僕のことを知る人しか集まらない不人気セッションを勝手に想像しており、abstractを書く欄に「実世界で使われている分散システムを構成する際に理解してほしい議論についてkumagiが一人で滔々と語る。」という漠然とした説明を書いた。初心者にこそ聴いて欲しいという身勝手な理由でレベル設定をBeginnerにし、自己紹介欄に至っては本当は経
『夢のデータベース？「Cloud Spanner」の実力は？』について - Software Transactional Memo
こんな記事が目に入った。 www.itmedia.co.jp 大雑把に完全に間違ったことを言っているわけでもないが、読んでいくといろいろ鼻につくところがあり、どのあたりから間違っているのかと自分に問いただすのは現時点での自分の知識を棚卸しするためにも有用かも知れないと思ったので一言一句漏らさず思うところを書いていこうと思う。 中には枝葉末節な難癖もあるので全部を真に受けない感じで読んで欲しい。 Cloud Spannerの特徴は、これまでリレーショナルデータベースで不可能とされていた「トランザクション処理の大規模分散処理」を実現したところにあります。 単一のトランザクション処理を分散して実行しているかというと、Spannerはトランザクションごとに担当のトランザクションマネージャがそのトランザクション処理全体を取り仕切って行う仕組みになっている。なので「トランザクション処理の大規模分散処理
分散プログラミングモデルおよびデザインパターンの考察 その5 - Software Transactional Memo
これまでプログラミングモデルのプの字もなかったので申し訳程度にプログラミングモデルの話をする。 分散して特定のアプリを動かしたいだけなら、例えばbitcoinをマイニングするASICクラスタに対して特定のプログラミングモデルは必要とされない。そのように、行いたいタスク抜きにプログラミングモデルを語る事はできない。 HPC（ハイパフォーマンスコンピューティング）系のワークロードは古くからMPIがデファクトとなっている。 MPIでのプログラミング MPIというのは「Message Passing Interface」の略でSmalltalkなどの文脈で語るいわゆるメッセージパッシングとは哲学というかレイヤーが違う。こいつは 配列を引数に取る関数の形で1:1, 1:N, N:Nの通信の典型的なパターン(1:Nなら例えば `MPI_Broadcast` とか)をインタフェースとして定義しており、ユ
分散プログラミングモデルおよびデザインパターンの考察 その3 - Software Transactional Memo
昨日に引き続いて分散システムのデザインパターンについて書いていきたい。 だがそれ以前に故障モデルに関する前提を忘れてはならない。人によって様々な方針があるが、個人的には分散システムの世界において意識しなくてはならない故障モデルは4つだと考えている。僕は前回のブログに書いた Replication の本をベースに書いており、少し言葉遣いや定義が他とやや違う点は許して欲しい。また、通信の脱落・遅延とはレイヤーが異なる議論である。 故障モデルの分類 故障が起きないモデル これは故障が起きない世界を仮定するモデルである。これ自体はプロダクションにそのまま投入できるものではない。だがこの故障モデルを想定しても解けない問題は故障が発生する状況では絶対解けない事が断言できたり、合意プロトコルが正しいかを議論する土台となったり、様々な実用的なアルゴリズムや分散システムの土台となるアルゴリズムが生まれる土壌
分散プログラミングモデルおよびデザインパターンの考察 その2 - Software Transactional Memo
前回の記事では 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじつける事を「分散システム」と呼んだ事。 システム全体を決定づけるわけでもない通信パターン上の選択肢の一部を切り出してシステムの本質のように呼んだ事。 プログラミングモデルと言いながらプログラミングモデルの話が一切出なかった事。 のうち一番上についてしか書かなかったので次に真ん中の項目についての話をする。物事を分類する際の一般論としては MECE であることが好まれるがYahoo!の記事はレイヤーも目的も様々な物を一緒くたに語っており、取り繕おうにも議論の空間があやふやなので何に対して網羅的なのかも議論ができない。「マスターやワーカーというのは役割の議論であり通信パターンの議論ではない」「Producer-Consumerはデータフローの一種と呼べないのか？」「データフローは
分散プログラミングモデルおよびデザインパターンの考察 その1 - Software Transactional Memo
Yahooの技術者が書いたブログ techblog.yahoo.co.jp が悪い方向に期待を裏切ってくれたのに対し、 @kuenishi さんがまとまった文章 kuenishi.hatenadiary.jp を書いていたので、僕も2番煎じぐらいでまとまった文章を書く。 始めに断っておくと、分散システムというのはまだまだ事例を集めていくフェーズを抜けきっておらず、体系立った大統一理論的な分類法は確立していない。ここに書くのは、これまでの分散システム事例やこれからの分散システム事例を分類していく際にその性質をカテゴライズする一助となれば良いな、程度の文章なのであまり真に受けないで欲しい。 なぜYahooの記事が期待はずれなのか 人によって意見はあるとは思うが、個人的に感じたのは以下の３つ。 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
