2016年4月18日のブックマーク (8件)

  • imgix - Pricing - Start Free

    Flexible plans that fit your needs. Free transformations, unlimited possibilities.

    imgix - Pricing - Start Free
    kakerukaeru
    kakerukaeru 2016/04/18
    やっす
  • 分散システムについて語るときに我々の語ること ― 分散システムにまつわる重要な概念について | POSTD

    分散システムについては、もう随分と前から学びたいと思っていました。ただ、それは一度首を突っ込んだら最後、ゴールのない迷路に迷い込むようなものなのです。どこまでも続いているウサギの穴のようなものです。分散システムに関する文献は星の数ほど存在します。様々な大学からたくさんの論文が発表されているばかりでなく、膨大な数の書籍もあるのです。私のような全くの初心者には、どの論文を読んだらいいのか、どの書籍を買ったらいいのか、見当もつきません。 そんなとき、一部のブロガーが、 分散システムエンジニア (それがどういう意味であれ)になるなら知っておくべき論文というものを推奨しているのを見つけました。その一部を紹介しましょう。 FLP , Zab , Time, Clocks and the Ordering of Events in a Distributed Systems , Viewstamped

    分散システムについて語るときに我々の語ること ― 分散システムにまつわる重要な概念について | POSTD
  • 分散プログラミングモデルおよびデザインパターン - kuenishi's blog

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

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

    引き続き分散システムのデザインパターンの話をしていく。例によって適切な名前を見つけられなかった場合にはその場で適当に名づけているので、ここに書いてある名称が技術レベルでの正式名称だとは思わず、正式名称を見つけたらそっとコメント欄で教えてください。 Application Level Ack リクエストを受け取った際にAcknowledgment(Ack) を返却するのは重要であるというのは異論の余地はない。だが、どのレベルで返却すべきかというのはデザインスペースの一部である。 ご存知の通り、TCPはそもそもSYN → SYN-ACK →ACKの3方向ハンドシェイクを行い、それぞれの通信ペイロードにシーケンス番号を付けて送達を確認している。SO_LINGERを使えばclose時に未送信パケットが残っていればそれを送り終わるまでclose()をブロッキングする事もできる。TCPのトランスポート

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

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

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

    前回の記事では 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじつける事を「分散システム」と呼んだ事。 システム全体を決定づけるわけでもない通信パターン上の選択肢の一部を切り出してシステムの質のように呼んだ事。 プログラミングモデルと言いながらプログラミングモデルの話が一切出なかった事。 のうち一番上についてしか書かなかったので次に真ん中の項目についての話をする。物事を分類する際の一般論としては MECE であることが好まれるがYahoo!の記事はレイヤーも目的も様々な物を一緒くたに語っており、取り繕おうにも議論の空間があやふやなので何に対して網羅的なのかも議論ができない。「マスターやワーカーというのは役割の議論であり通信パターンの議論ではない」「Producer-Consumerはデータフローの一種と呼べないのか?」「データフローは

    分散プログラミングモデルおよびデザインパターンの考察 その2 - Software Transactional Memo
  • マルチコアCPUのキャッシュで問題となるコヒーレンシと解決策 (1/3)

    キャッシュの仕組み解説編最後のテーマは、「コヒーレンシ」(Coherency)である。あまり耳にしない単語だが、直訳すると「首尾一貫性」といったところか。キャッシュの場合、この単語は「データの一貫性」「データの整合性」といった意味合いで利用される。これは、前回触れた複数レベルのキャッシュで問題となる場合もあるが、一番大きな問題が起きるのは、マルチプロセッサー/マルチコアCPUの環境である。 マルチプロセッサー環境でキャッシュの整合性を保つ スヌーピングとその方式 例えば図1のような、懐かしいデュアルCPU構造を例にとって見る。ここで「CPU #1」があるデータを書き換えたとする。 すると、図2のように1次/2次キャッシュの更新を経て、最終的にメモリーにそれを反映して終わる。ここまではいい。問題は「CPU #2」である。もしCPU #2が同じアドレスのデータをすでにキャッシュしていたとすると

    マルチコアCPUのキャッシュで問題となるコヒーレンシと解決策 (1/3)
  • 分散プログラミングモデルおよびデザインパターンの考察 その1 - Software Transactional Memo

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

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