Pwrake: Distributed Workflow Engine based on RakePresentation for RubyKaigi2016@Kyoto http://rubykaigi.org/2016/presentations/masa16tanaka.html
歌舞伎座.tech#9でPonyについて発表しました - だいたいよくわからないブログ
歌舞伎座.tech#9「異種プログラミング言語格闘勉強会」 - connpass で発表しました。 オープンな勉強会で発表したのは初めてだったので胃に穴が空きそうでしたが、なんとか乗り越えられました・・死にそう・・・(◞‸◟) ponyの知名度がちょっとでも上がれば幸いです。 Pony concurrency built into the type system from matsu_chara www.slideshare.net erlangのメッセージパッシングは全てデータコピーが発生すると表現したところがありましたが、誤りでした。 http://www.ponylang.org/papers/fast-cheap.pdfのイントロから引用したのですが、もう少し調べたほうが良かったですね。（論文に書いてあるからといって安心してはいけない的な教訓・・）*1 erlangでは特定のバイト
最近よく聞くQuorumは過半数(多数決)よりも一般的でパワフルな概念だった - Qiita
最近では珍しくもなくなった"Quorum"という言葉。Zookeeper, etcd, Serfといったクラスタ中でデータのレプリケーションを行ってくれるようなツールや、Cassandra, Riakといった分散データベース(NoSQL系)のようなツールにおいても、データの複製に一貫性を持たせる仕組みとしてよく聞かれます。 しかしながら、多くのスライドやWebの記事を読んでも、"Quorum"という語が意味するところは要するに「過半数ノードによる多数決」というような説明が多いように感じていました。 にも関わらず、"Quorum"と呼ばれているのはなぜか？そんな疑問を持っていたので、この機会に調べてみました。 そうしたら、"Quorum"は過半数/多数決という概念を一般化した非常に抽象でパワフルな概念だということがわかりましたのでここにまとめておきたいと思います。 分散システムにおけるデータ
A Distributed Systems Seminar Reading List… | the morning paper
the morning paper a random walk through Computer Science research, by Adrian Colyer Made delightfully fast by strattic I stumbled upon Murat Demirbas’ ‘Distributed Systems Seminar’s Reading List for Spring 2016.’ If you’re taking part in those seminars, you’re in for some very interesting papers! I was pleased to discover I’ve read (and written up) most of them – but there are a few that I haven’t
Automated Failure Testing
At Netflix, we have found that proactive failure testing is a great way to ensure that we have a reliable product for our members by helping us prepare our systems, and our teams, for the problems that arise in our production environment. Our various efforts in this space, some of which are manual, have helped us make it through the holiday season without incident (which is great if you’re on-call
Version Vectors are not Vector Clocks
Most people still confuse Version Vectors and Vector Clocks. Well, I did confuse them for several years. In fact they look the same and the update rules are almost the same. Both of these mechanisms are practical ways of capturing causality in distributed systems. Causality (in distributed systems) is an abstract concept, can was formalized in 1978 by Leslie Lamport in one of the most cited artic
Riak Core の紹介 - kuenishi's blog
Erlang アドベントカレンダー 2014の23日目の記事です。 Erlang/OTPでアプリケーションを書いていると、システムを冗長化するために複数ノードでうまく協調動作するようにさせるために、Distributed Erlangの上に構築されたFailoverやTakeoverを使う場面がいずれ出てくる。しかし、これらの仕組みは、Riakのようにシステムをスケールアウトさせたい場合には不十分だ。スケールアウトするシステムの本質は アクセスしたいモノの物理的な位置を隠蔽して論理的な位置でアクセスできるようにする 物理的な位置が故障やスケールアウトのために変化しても常に追跡できて同じ論理的な位置でアクセスする アクセスしたいモノが偏らず、ほぼ均等に分散されている の3点がサポートされていることだ。これだけだといろんなものが該当するが、 Riak風に翻訳すると アクセスしたいデータがどのノ
モバイル通信プロトコル授業資料
お知らせ(1/19更新:最終レポートの出題範囲を訂正しました) 第3回(最終)レポート課題を出題しています。 詳細は下記を参照してください。 一月以降の授業予定はは1月12日(木)2限および1月19日(木)2限のみと します。1月26日(木)2限およびそれ以降は休講とします。 成績は計3回のレポート(70%)および出席状況(30%)から評価します。 第3回(最終)レポート課題(1月19日(木)出題) 第10回〜第11回授業まで（教科書7章、8章）の授業スライド末尾の演習問題を、 各2問以上(全部で3問以下しか無い場合は1問以上)選択して回答すること 提出〆切：2月3日（金） 提出方法：前回までと同様 提出ファイル名は、"(学籍番号)-report3.(拡張子)"の形式にすること(例： N3501234-report3.pdf) 第2回レポート課題(12月22日(木)出題) 第6回〜第9回授
エラー率わずか0.00000625％、驚異のインド式昼食配達システム「ダッバーワーラー」
日本の物流システムのものすごさはよく知られたところ。徹底的なコンピューター化による管理と、そして日本の道路・通信インフラの優秀さによって高速かつ精密な輸送を可能にしているわけですが、これにまさるとも劣らないシステムがインドにもありました。社会的なインフラがまだまだ未整備なのにも関わらず、伝票もPOS端末も携帯電話も一切なんにも使わずに毎日20万食の昼食を時間通りに届ける「ダッバワーラー」という驚異のシステムが存在しているのです。一体どんな人達なのでしょうか。 目次 ダッバーワーラーとは ミスは1600万回に1回、驚異の低エラー率 超複雑なネットワークを人力で運営するダッバーワーラー達 なぜダッバーワーラーは超低料金で超優良サービスを提供できるのか？ ダッバーワーラーと組織の社会貢献 ダッバーワーラーとは インドの人達には、3食きちんと調理した温かい物を食べる、という食文化があります。これは
みんなで力を合わせるんだー！ スマホの処理能力をスパコン級にするHTCの新技術とは？｜タブロイド｜オトコをアゲるグッズニュース
べ、べつにトップ画像に深い意味はないんだからねっ！ 台湾の端末メーカーHTCが、スマホ充電中に余っている処理能力を難病の研究や地球外生命体の探索などに活用する仕組み『パワー・トゥー・ギブ（Power To Give）』を発表しました。 仕組みとしては、専用アプリをインストールした世界中のスマホ端末から処理能力を間借りすることで、スーパーコンピューター級の演算処理を可能にするというもの。HTCからは公式のコンセプト動画も発表されています。
ビザンチン将軍問題 - Wikipedia
ビザンチン将軍問題（ビザンチンしょうぐんもんだい、英語: Byzantine Generals Problem）とは、相互に通信しあう何らかのオブジェクト群において、通信および個々のオブジェクトが故障または故意によって偽の情報を伝達する可能性がある場合に、全体として正しい合意を形成できるかを問う問題である[1]。フォールトトレラントシステムでの多数決の妥当性や分散コンピューティングの処理の妥当性に関わる問題と言え、二人の将軍問題を一般化したものと言える。 ビザンチン将軍問題に帰結される故障や障害をビザンチン故障（Byzantine Failure、あるいはビザンチン障害）と呼ぶ。また、ビザンチン将軍問題が発生しても全体として正しく動作するシステムをビザンチン・フォールトトレラント性（Byzantine Fault Tolerance）があるという。 問題[編集] ビザンチン将軍問題は、東ロ
http://dspace.info.gscc.osaka-cu.ac.jp/~fujita/RESEARCH/KANSAIP2P/chubby.txt
The Chubby lock service for loosely-coupled distributed systems ○ 背景 ・Chubby の概要 - 高信頼ストレージから構成される疎結合型分散システム - 荒い粒度 (coarse-grained) のロッキングを提供する - 設計上の課題はパフォーマンスを阻害する有効性と信頼度 ・ロック・サービスの目的 → クライアントのアクティビティを同期し環境に関わる情報を一致させる ・Chubby の目標 - 多くのクライアントに信頼性を有効性を提供する - 分かり易いセマンティックスに基づく - スループットと記憶容量は２次的な目標 ・Chubby のクライアントインターフェース → シンプルなファイルシステム・インタフェースと似ている - ファイル全体に対するリード・ライト - アドバイザリ・ロック - イベント通知（ファイル更
A Distributed Systems Conference for Developers - RICON
What was it? Basho Technologies, along with our sponsors, proudly presented RICON 2012, a two day conference dedicated to Riak, developers, and the future of distributed systems in production. This page is dedicated to post-conference consumption. Here you will find slide decks, resources, photos, and much more. When was it? October 10 and Thursday, October 11, 2012 at the W Hotel in downtown San
12年後のCAP定理: "法則"はどのように変わったか
設計者は分割が発生したとき一貫性と可用性のどちらかを選ぶ必要がありますが、分割の扱い方と分割の復旧には柔軟な対処方法があります。現在のCAPの目的は特定のアプリケーションが必要とする一貫性と可用性を最適化することでしょう。このような方法には分割発生中の計画や分割の復旧計画が組み込まれています。したがって、設計者はこのような方法を採用することで、従来受け取られてきたCAPの限界を超えてCAPについて考えることができます。 なぜ"3つのうち2つ"がミスリーディングなのか CAPを理解する最も簡単な方法は分割の両側にひとつずつノードがある場合を考えることです。片方のノードだけ状態を更新できるようにすると、2つのノードに一貫性がなくなります。つまり、Cが失われます。一貫性を維持しようとすれば、一方のノードは利用できない状態であるかのように動作しなければなりません。この場合、Aが失われます。一貫性と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Cloudera Standard のご案内 ~ 無償版 大幅機能強化のお知らせ | Cloudera Japan
TwitterがMapReduceストリーミングフレームワークSummingbirdをオープンソースに
Building a Consistent Hashing Ring - Greg.Brim.Net
Raft: The Understandable Distributed Consensus Protocol
RICON: A conference series dedicated to Riak and distributed systems in production.
Google Code Archive - Long-term storage for Google Code Project Hosting.