分散システムについて語らせてくれNTT Tech Conference #2 にて話した資料 時間が足りなかったので全部は話せなかった。
Paxos-based replicationはEventually consistentではなくstrongly consistentである - kuenishi's blog
ちょっと発言力のありそうな方がテクニカルに誤りを書かれていたので、ここでひっそりと訂正しておきたい。 このスライドの43ページ目に、 The problem with Paxos-based algorithm is that replications are eventual consistent. と、色付き文字で協調されて書かれている。このスライドで主張したいことの本筋ではないが、Spannerの性能がよいこととは関係がなく、Paxosなどのレプリケーションと、トランザクションとの関係で誤解を広めそうなので指摘しておきたい。辻マサカリと言って差し支えないだろう。 PaxosはStrongly consistentであることがMade Simpleの論文で証明されている（Strongly consistentが何かはまた別の機会にここに書こうと思う）。ちょっと長いが引用しておこう。 T
Raft Consensus Algorithm
What is Raft? Raft is a consensus algorithm that is designed to be easy to understand. It's equivalent to Paxos in fault-tolerance and performance. The difference is that it's decomposed into relatively independent subproblems, and it cleanly addresses all major pieces needed for practical systems. We hope Raft will make consensus available to a wider audience, and that this wider audience will be
Paxos, Raftなど分散合意プロトコルを概観する(1) - 備忘録 blog
tl;dr 分散合意プロトコルについてサーベイしたので、メモを残す。 2PC 3PC Paxos Raft(次回) Proof of Work(次回) Proof of Stake(次回) 分散システムについては素人の筆者が書いたため誤りが多いと思うので、できれば確認のため元論文を参照してもらいたいです。 introduction 基本的な定理, 用語 CAP定理: 分散システムは、一貫性 (Consistency)、可用性 (Availability)、分断耐性 (Partition-tolerance)のうち最大でもいずれか2つしか満たすことはできない。 レプリケーション: 一貫性を保ちながら、リソース間で情報を共有すること。 RPC: プログラムであるノードから別のノード上の関数を呼び出すこと。ここでは、ノードから別のノードにメッセージを送ることという理解でもたぶん大丈夫だと思う。
Understanding Consensus and Paxos in Distributed Systems
A distributed auction Take 1: Auction! Correctness properties Take 2: Auction! Take 3: Auction! Agreement: Why it works Termination: Why it doesn’t (always) work. FLP Ghost The Paxos Algorithm Phase 1- Prepare Phase Phase 2 - Accept Phase Computers can sometimes be unexpectedly tricky. Having them accomplish seemingly rudimentary tasks can be a lot more complicated than we would expect. One exampl
【デブサミ2016】18-A-6レポート Yahoo! JAPANを支えるデータテクノロジー ～ 機械学習、クラウド分散システム処理モデル
本セッションでは、Yahoo! JAPANを支える2つの代表的なデータテクノロジーが紹介された。前半はヤフーのサービスの機能改善を行っている機械学習について、ヤフオク!カンパニー ヤフオク!開発本部 サイエンス部の山下勝司氏が説明。常時3900万個の出品があるヤフオクでは、深層学習を利用した画像処理や分散表現を用いて機能改善を実施しているという。その実例を紹介した。後半はクラウド分散システム処理モデルについて、データ＆サイエンスソリューション統括本部 データインフラ本部 開発3部の今野賢氏が説明。データ分散モデルの現状と課題、そしてそれらを解決する理想のデザインモデルの実装例を紹介した。 ヤフー ヤフオク!カンパニー ヤフオク!開発本部 サイエンス部 山下勝司氏 同社 データ＆サイエンスソリューション統括本部 データインフラ本部 開発3部 今野賢氏 講演資料（山下氏）：ヤフオク!における機
mixi Engineers’ Blog » スマートな分散で快適キャッシュライフ
今日は以前のエントリーで書くと述べたConsistent Hashingに関して語らせて頂こうかと思います。ただしConsistent Hashingはセミナーやカンファレンスなどでかなり語られていると思いますので、コンセプトに関しては深入りせず、実用性に着目したいと思います。 問題定義 分散されたキャッシュ環境において、典型的なレコードを適切なノードに格納するソリューションはkeyのハッシュ値に対しmodulo演算を行い、その結果を基にノードを選出する事です。ただし、このソリューションはいうまでもなく、ノード数が変わるとキャッシュミスの嵐が生じます。つまり実世界のソリューションとしては力不足です。 ウェブサイトのキャッシュシステムの基本はキャッシュがヒットしなかったらデータベースにリクエストを発行し、レコードが存在したらキャッシュしてクライエントに返すという流れです。ここで問題なのが一瞬
Consistent Hashing を試す
Consistent Hashing は、 複数のノードにレコードを分散させる方法として、 Amazon Dynamo や Cache::Memcached::Fast などで使われているアルゴリズムです。 この文章では、Perl で実際に Consistent Hashing を実装し、 その特徴を理解することを目的とします。 更新履歴 2008-06-01: 公開 サーバー台数で割った余り (mod) を使用する まず Consistent Hashing と比較するために、レコードに対して整数のハッシュ値を求め、 ハッシュ値をノード数で割った余り (mod) で、ノードを選択するという方法を書いてみます。 ここでは、ハッシュ値の算出に CRC (Cyclic Redundancy Check) を使用しています。 use strict; use String::CRC; use Pe
分散プログラミングモデルおよびデザインパターンの考察 その1 - Software Transactional Memo
Yahooの技術者が書いたブログ techblog.yahoo.co.jp が悪い方向に期待を裏切ってくれたのに対し、 @kuenishi さんがまとまった文章 kuenishi.hatenadiary.jp を書いていたので、僕も2番煎じぐらいでまとまった文章を書く。 始めに断っておくと、分散システムというのはまだまだ事例を集めていくフェーズを抜けきっておらず、体系立った大統一理論的な分類法は確立していない。ここに書くのは、これまでの分散システム事例やこれからの分散システム事例を分類していく際にその性質をカテゴライズする一助となれば良いな、程度の文章なのであまり真に受けないで欲しい。 なぜYahooの記事が期待はずれなのか 人によって意見はあるとは思うが、個人的に感じたのは以下の３つ。 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじ
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年5月時点の調査。
Paxos
PostgreSQLをKubernetes上で活用するためのOperator紹介！（Cloud Native Database Meetup #3 発表資料）
Non-blocking Transactional Atomicity | Peter Bailis
Peter Bailis :: Highly Available, Seldom Consistent Data management, distributed systems, and beyond Non-blocking Transactional Atomicity 28 May 2013 tl;dr: You can perform non-blocking multi-object atomic reads and writes across arbitrary data partitions via some simple multi-versioning and by storing metadata regarding related items. N.B. This is a long post, but it’s comprehensive. Reading the
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Deeplearning 4 j のクイックスタートガイド - Deeplearning4j: Open-source, Distributed Deep Learning for the JVM
Consulはなめらかか？
Raft(分散合意アルゴリズム)について
GitHub - streed/simpleRaft: A implementation of Raft in pure Python
Raft