-- 追記-- > termの説明で「今のリーダーが何代目のリーダーかを表す」と書かれていますが、あるterm内でリーダーが1人も選出されないことがあるので、termで何代目のリーダーかは表せなくないですか？ https://x.com/11Takanori/status/1801212885…
Content-Length: 313765 | pFad | http://b.hatena.ne.jp/paulownia/%E5%88%86%E6%95%A3%E5%87%A6%E7%90%86/
Raftとは？ 仕組みから考える得意なこと苦手なこと/What is Raft? Strengths and Weaknesses Based on Its Mechanism
-- 追記-- > termの説明で「今のリーダーが何代目のリーダーかを表す」と書かれていますが、あるterm内でリーダーが1人も選出されないことがあるので、termで何代目のリーダーかは表せなくないですか？ https://x.com/11Takanori/status/1801212885…
Redis Labs、強い一貫性を保ちつつRedisを高可用クラスタ化する「RedisRaft」発表
インメモリキーバリューストアのRedisを開発するRedis Labsは、複数のRedisをクラスタ化することで高い可用性を実現しつつ、クラスタ内で強い一貫性の保持を実現するクラスタ化ソフトウェア「RedisRaft」を発表しました。 Introducing RedisRaft, a new strong-consistency deployment option for Redis in beyond-cache scenarios requiring a high level of reliability and consistency. #RedisRaft https://t.co/2l5dmiVFpk — Redis Labs (@RedisLabs) June 23, 2020 Redisはメモリ上でキーバリューデータを扱うインメモリデータベースで、その高速性が大きな特長です。
Googleが作った分散アプリケーション基盤、Borgの論文を読み解く -その1- - inductor's blog
このエントリーについて このエントリーを書き始めた経緯は下記にあります。 inductor.hatenablog.com 上記の理由の通り、目的は論文を翻訳することだけではなく、最終的にこれを踏まえて自分の見解をつらつらと書いていくところにもあります。 おそらく一番時間がかかるのはそれなので、一旦は翻訳を一通り終えた上で更に頑張っていきます。ゆっくりお待ちいただければと思います＞＜ 1. Introduction(まえがき) Borgが内部的に呼び出すクラスター管理システムは、Googleが実行するすべてのアプリケーションを許可、スケジュール、起動、再起動、および監視します。この論文ではその方法を説明します。 Borgには3つの主な利点があります。 リソース管理と障害処理の詳細を隠すため、ユーザーは代わりにアプリケーション開発に集中できます。 非常に高い信頼性と可用性で動作し、同じことを行
分散合意アルゴリズム Raft を理解する - Qiita
Raft は Byzantine 障害に対する耐性がなく、論文を一見して恒久的なリーダーの乗っ取りからのログの改ざん、リーダー選挙の妨害などが可能であるところを見ても、P2P ではなく完全に管理されたネットワーク向けの合意アルゴリズム (CFT; Crash Fault-Tolerance) です。Byzantine 障害耐性が必要であれば Raft ではなくパフォーマンスを犠牲にして pBFT などを使う必要があるでしょう。 論文では Crash-Recovery より深刻な障害耐性には言及していないが (論説の範囲を外れるため当然だが)、もし実際に Raft を実装するなら現実的に想定される障害に対して工夫できる余地もいくつか存在します。例えば「テスト環境で使用していたノードの 1 つが事故で本番クラスタに『も』参加してしまった」といったような運用事故で起きうる障害は (大抵そのような
分散システムの限界について知ろう
↓↓↓↓訂正あります。↓↓↓↓ 2018/07/02に株式会社エフコード社内で行われた勉強会のスライドです。 訂正版(随時更新中): https://docs.google.com/presentation/d/15HOMfAbtdWwO48njcB8IdkN3kVAMu3wsmZo0O3S-f_4/edit?usp=sharing 専門家による資料・専門家向けの資料ではありません。自分自身で学習し、論文・文献等を読解してまとめた内容となります。間違い等あるかもしれませんが、あれば是非コメント頂ければと思います。 【訂正事項】 スライド16: 誤：たった一つのプロセスが故障しただけでも有限時間で合意できない 正：たった一つのプロセスが故障しうるだけでも有限時間で合意できない スライド20: 誤: 重要: あるschedule σ1, σ2 がdisjoint (nodeが被ってない) なら
分散キューという名の苦しみ - Software Transactional Memo
TL;DR 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 システムの抽象 コンピュータの世界は、本来は0と1の信号の羅列が飛び交う無機質なものである。でも人類は信号だけですべてを語らず、様々な喩えを定義してきた。それはデスクトップ・ウィンドウ・マウスカーソルといったグラフィカルな表現に留まらず、パケットやカプセル化といった用語にロック・キュー・リスト・木などのアルゴリズムやデータ構造の世界にも自然に溶け込んでいる。これらはすべて人間の理解を助けるための喩え話に過ぎず、この喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた。 人間が大きなシステムを作るときも何らかの喩えを用いてシステム全体を整理する。アーキテクチャの「ポンチ絵」を描いて情報共有をするのは企業に勤めていれば経験した人も多いだろう。パワーポイン
分散ロックという名の過ち - Software Transactional Memo
 TL;DR; 「分散ロック」が分散システムの設計図に登場した時 だいたいその設計は間違っていて本当に必要なものはトランザクションだ 並行システムを実装する際にロックを用いるのはとても自然なことだ。 僕も普段はロックフリー系のアルゴリズムに詳しいと言われがちだが知識量でいったら実はロック系の方が多く蓄えているかも知れない。 分散システムは並行システムであることが多いので、その中にロックが登場するのはとても自然な発想である。 よく「分散」「並行」「並列」の言葉の定義がごっちゃになっているケースがあり、この記事の主題にしたいわけではないので深くは言及しないが、分散システムは環境などの要因で突如として参加者が音信不通になったり復活したりする点で並行システムと大きく異なる。 並行システムと同じノリで分散システムを設計しようとした際に陥る頻出の過ちが「分散ロック」である。そのアイデアはとても簡単で
Paxos, Raftなど分散合意プロトコルを概観する(1) - 備忘録 blog
tl;dr 分散合意プロトコルについてサーベイしたので、メモを残す。 2PC 3PC Paxos Raft(次回) Proof of Work(次回) Proof of Stake(次回) 分散システムについては素人の筆者が書いたため誤りが多いと思うので、できれば確認のため元論文を参照してもらいたいです。 introduction 基本的な定理, 用語 CAP定理: 分散システムは、一貫性 (Consistency)、可用性 (Availability)、分断耐性 (Partition-tolerance)のうち最大でもいずれか2つしか満たすことはできない。 レプリケーション: 一貫性を保ちながら、リソース間で情報を共有すること。 RPC: プログラムであるノードから別のノード上の関数を呼び出すこと。ここでは、ノードから別のノードにメッセージを送ることという理解でもたぶん大丈夫だと思う。
Formalization and Proof of Distributed Systems (ja)
分散システムの形式化と証明について ＠情報システム特別講義D 2016年度筑波大学
GitHub - clohfink/RendezvousHash: Rendezvous or Highest Random Weight (HRW) hashing algorithm
An alternative to the ring based, consistent hashing. This is a fast thread safe implementation of Rendezvous (Highest Random Weight, HRW) hashing. An algorithm that allows clients to achieve distributed agreement on which node (or proxy) a given key is to be placed in. This implementation has the following properties. Non-blocking reads : Determining which node a key belongs to is always non-bloc
リアルタイム分散処理の常識をApache S4で身につける
リアルタイム分散処理の常識をApache S4で身につける：ビッグデータ処理の常識をJavaで身につける（6）（1/2 ページ） Hadoopをはじめ、Java言語を使って構築されることが多い「ビッグデータ」処理のためのフレームワーク／ライブラリを紹介しながら、大量データを活用するための技術の常識を身に付けていく連載 Hadoopの弱点「リアルタイム分散処理」とは 「ビッグデータ」処理のためにHadoopを用いると、「複数のマシンに大量データ処理を分散して飛躍的に性能を向上する」ことが容易にできます。 ところがHadoopの弱点として、ビッグデータをいったん蓄積し、バッチで一括処理する形態で処理するので、処理データが発生してから、それに対する処理結果が得られるまで、必ずタイムラグが発生します。このため、クレジットカードの不正アクセス検知、センサデータなどでの異常値検出のようなリアルタイムな
NHKがネット経由でムービー編集できる「フレキシブル制作システム」のソースコードを無料公開開始
NHK技研がウェブ上のどこからでも、編集作業用パソコン一台で高度な番組編集・制作ができるシステムを開発し、なんとそのソースコードを無料で公開開始しました。 今回公開されたのは「フレキシブル制作システム（ウェブ編集システム）」「分散ファイルシステム」「挿入削除機能付きファイルシステム」「高速ファイル転送システム」「素材作成用MXFライブラリ」で、単純にソースコードが置いてあるだけでなく、コンパイル方法・Apacheの設定・各種コマンドの解説などのドキュメントも提供されており、いわゆるクラウドとして動作させることが可能です。 詳細とダウンロードは以下から。 ◆ファイルベースシステムが快適に、大きく進化！ ～ ウェブブラウザを用いて快適な編集環境を提供～ （平成２３年５月２４日） http://www.nhk.or.jp/pr/marukaji/m-giju305.html フレキシブル制作シス
リアルタイムなHadoop？ 「Real-Time MapReduce」を実現するS4、オープンソースとしてYahoo!が公開 － Publickey
米Yahoo!は、大規模データの分散処理を実現するMapReduceをリアルタイムに行うソフトウェア「S4」を、オープンソースとして公開しました。 MapReduceを実行するソフトウェアとして、オープンソースの「Hadoop」がありますが、Hadoopはあらかじめジョブを定義して投入するバッチ処理を前提としていました。 S4は、データをキーとバリューのペアで構成されるストリームデータとして非同期に受け取ることができ、処理結果もキーバリューのペアで構成されたストリームデータとして出力するようになっているとのこと。 この非同期なストリームデータによる入出力が、リアルタイムなMapReduceを実現するフレームワークとしてのS4の特徴といえます。 リアルタイムなMapReduceで何ができる？ リアルタイムなMapReduceにはどのような用途が考えられるのでしょうか？ S4の公開を表明したY
140行で作る分散リアルタイム検索エンジン（Twitter Streaming API対応） - 古橋貞之の日記
マトモに使えるRPCライブラリ MessagePack-RPC for Ruby のバージョン 0.2.0 をリリースしました！ 新たにコネクションプーリングの機能を追加しました。一度接続したコネクションを共有して使い回すことができます。コネクションを何度も張り直す負荷と遅延を削減でき、リソースの消費も抑えられます。 また、不意に切断されたコネクションを自動的に再接続する機能を導入し、信頼性を向上させています。 これを使って何か作ってみようと言うことで、twitterのリアルタイム検索エンジンを作ってみました。日本語を検索できないなど機能は貧弱ですが、プログラム全体がわずか140行に収まっています（クローラ27行、インデクサ48行、クラスタ管理ノード37行、検索クライアント28行）。 新しいつぶやきを受信するたびに、リアルタイムで転置インデックスを作成していきます。インデックスを作成するノ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: http://b.hatena.ne.jp/paulownia/%E5%88%86%E6%95%A3%E5%87%A6%E7%90%86/
Alternative Proxies:
Apache ArrowとJava: ライトニングスピードのビッグデータ転送
分散アプリケーションの異常の原因を即時に診断するための手法の構想 / Causality Tracing in Distributed Applications
Raft(分散合意アルゴリズム)について
本当は恐ろしい分散システムの話
分散システムについて語らせてくれ
Charming Python: Functional programming in Python, Part 3
