blogこの広告は、90日以上更新していないブログに表示しています。P.26)ここ数年のraftの寵児っぷりはすごい。2014年に発表されてから、四半世紀に渡って合意形成アルゴリズム界隈の長だったPaxosに取って代わろうとしている。主要言語ではライブラリの実装が出揃っていて、各所で採用されつつある。https://raft.github.io/#implementationsもともとRaftは、理解しやすく実用的なアルゴリズムになるようにデザインされている。背景としてPaxosのアルゴリズムが難解で、加えて細かい部分のスケッチがないため実装難易度が高かったということがあって、それがRaftのモチベーションになっている。Lamportの論文を読んだことがあるけど、証明まで確認するのは結構大変だった。暇のなせる業だと思う。個人的には文書のクセも理解を妨げてきて辛さ倍増だった。https://lamport.azurewebsites.net/pubs/lamport-paxos.pdfhttps://lamport.azurewebsites.net/pubs/paxos-simple.pdfというのでRaftの論文を読んでみたのだけど、Paxosに比べたら格段に簡便化されていた。Tolerant」の頭文字だそう。hashicorp/raftあたりが有名所で、dockerでもetcd/raftがswarmクラスタのManagerノードのFTに使われている。以下は、そのログとスナップショットの動きを観察したメモ。環境6台のVMを用意して、01-03をManager、04,05をWorkerとして投下。06はあとでManagerとして追加する。STATUS」でraftのサーバ状態が確認できる。Leaderはレプリケーションの調停役で、最初に追加したswarm-node01がLeaderになっている。ReachableはraftでいうところのFollowerで、Leaderからのレプリケーション要求を受け付ける。Followerの方向で行われる。raftのサーバ状態にはもう一つ、投票を開始したFollowerが遷移するCandidateがあるが、これもReachableに入る。パラメータraft関連のパラメータは以下の4つ。Dispatcher:リーダ選出のトリガは、LeaderからFollowerに一定間隔で送られるHBの途絶で、タイムアウト値はFollowerがそれぞれセットする。2T-1]のランダム値で、サーバ状態の遷移時にセットされる。GitHubそれからraftではクラスタ内の状態変更をログに記録していく。それが肥大化するのでcompactionのために、定期的にスナップショットを取ってそれ以前のログを削除している。ログとスナップショットraftのログは以下のディレクトリにある。/var/lib/docker/swarm/raft/wal-v3-encryptedログは暗号化されているので、swarmkit/swarm-rafttoolで復号化して確認する。各エントリのヘッダにraftのログ・インデックスとターム番号が記録されていて、swarmクラスタ内の状態変更が記録されている。タームというのはリーダの選出を区切りとするraftクラスタの動作期間のこと。眺めてみると、この時点ではサーバの追加に伴うコマンドが発行されていた。間でレプリケーションされる。672a8f26525b288897d0f90aabb37f63スナップショットは、以下のディレクトリにある。/var/lib/docker/swarm/raft/snap-v3-encryptedスナップショットのインターバルがデフォルトの10000では、遊んでいる分にはなかなか到達しないので10回に下げる。10この時点で一回スナップショットが作成されて、ログもローテートされる。swarm-node01_03.wal試しにサービスをデプロイしてログを進めると、指定したインターバルで更新される。Type=EntryNormal:スナップショットもログと同じツールでダンプすることができて、クラスタで管理しているオブジェクトの状態が記録されている。しているFollowerや新規に追加されたFollowerには、Leaderからログとスナップショットが送信される。試しにManagerノードを新しく追加してみる。最初にインターバルを変更しているのはノードの追加でスナップショットが更新されないようにするためで、現在のログ・インデックスより大きいとスナップショットの転送は不要と判断されてしまうため50にしている。ログ分が追加したFollowerのスナップショットに入っている。53という感じである程度は観察できるけど、まともにログを吐いてくれないしメッセージをダンプしようにもprotobufなので、あとは実装を見た方が楽。おまけswarmkit/swarm-rafttoolでは、特定のオブジェクトをログとスナップショットからダンプすることもできる。<その他のtypeは以下が指定できる。単行本(ソフトカバー)この商品を含むブログを見る最近、分散トレーシングの導入を目論んでUberのJaegerを触っていて、分散トレーシングはマイクロサービスの文脈で語られることも多いので無関係ではないということで読んだ。著者がUberのSREということもある。本番対応」なサービス水準に押し上げて維持していくためのエッセンス集のようなもの。Fowlerのブログを読んでおいた方が良い。マイクロサービスアーキテクチャの適否については散々語り尽くされてきて通念化してるものがあって、プロダクトのライフサイクルとか組織が受ける制約とか種々の要因で適するものは限られるけど、この本に書かれている殆どのことはアーキテクチャに依らず有益だと思う。マイクロサービスアーキテクチャを採るとより一層必要性が高まるというだけ。考えずに部分的に取り入れると崩壊しそうなものもあるので注意が必要だけど、可能な限り実践していきたい。達成度を測定するチェックリストが各章末に付いていて、それが良く纏まっているので使えそう。ここ一ヶ月くらいがっつり手を動かす時間が取れなかったので、隙間時間で読める本として選んで通勤時間とか使って読んだ。この本はプロトコルの解説書ではないし、ITエンジニア向けのHowTo本でもなく、HTTPの変遷を軸とする歴史書、というのがしっくりくる。HTTP/0.9からHTTP/2.0に至るまでを、クライアントの多様化やアプリケーションのリッチ化といった環境変化に対して、障壁を乗り越えながらそれを実現してきたWeb技術、そしてそれを支えるように進化してきたHTTPという形で構成されている。World"感がある。個々の技術については、その詳細は他に譲っていて、Webの発展の過程を伝えるのに必要十分な解説がなされていると思う。それによって、自分の中の知識を体系立てて整理できる。いう位置付けの書籍は他にないか、アップデートされていないので、今後も加筆を続けてほしい。「HTTPはインフラ」という表現が途中で何度か出てきて、最初は腑に落ちないが読み終えると意図することが伝わってくる。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。