<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Distributed System on Ingenboy.inc</title>
    <link>https://blog.ingenboy.com/categories/distributed-system/</link>
    <description>Recent content in Distributed System on Ingenboy.inc</description>
    <image>
      <title>Ingenboy.inc</title>
      <url>https://blog.ingenboy.com/%3Clink%20or%20path%20of%20image%20for%20opengraph,%20twitter-cards%3E</url>
      <link>https://blog.ingenboy.com/%3Clink%20or%20path%20of%20image%20for%20opengraph,%20twitter-cards%3E</link>
    </image>
    <generator>Hugo -- 0.152.2</generator>
    <language>en</language>
    <lastBuildDate>Wed, 17 Jul 2024 16:01:42 +0900</lastBuildDate>
    <atom:link href="https://blog.ingenboy.com/categories/distributed-system/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Raft</title>
      <link>https://blog.ingenboy.com/post/raft/</link>
      <pubDate>Wed, 17 Jul 2024 16:01:42 +0900</pubDate>
      <guid>https://blog.ingenboy.com/post/raft/</guid>
      <description>&lt;h1 id=&#34;raftについて&#34;&gt;Raftについて&lt;/h1&gt;
&lt;p&gt;分散システムを勉強するのであれば、必ず必要となる。これだけ覚えておこう。
Replicate And Fault Tolerant&lt;/p&gt;
&lt;h1 id=&#34;raftの目的&#34;&gt;Raftの目的&lt;/h1&gt;
&lt;p&gt;Raftアルゴリズムの目的は、分散システムにおける信頼性の高いリーダー選出とログレプリケーションを通じて、一貫性のある状態を維持することです。具体的には、複数のノードが協調して動作し、一つのノードが故障してもシステム全体としての一貫性と可用性を保つことを目指します。&lt;/p&gt;
&lt;h1 id=&#34;raft-demo-site&#34;&gt;raft demo site&lt;/h1&gt;
&lt;p&gt;&lt;a href=&#34;https://raft.github.io/&#34;&gt;このサイト&lt;/a&gt;を見ると、ラフトの動作が詳細までわかることでしょう。&lt;/p&gt;
&lt;h1 id=&#34;参考文献&#34;&gt;参考文献&lt;/h1&gt;
&lt;p&gt;&lt;a href=&#34;https://www.youtube.com/watch?v=vYp4LYbnnW8&#34;&gt;youtube&lt;/a&gt;&lt;/p&gt;
&lt;h1 id=&#34;目的を達成する手段&#34;&gt;目的を達成する手段&lt;/h1&gt;
&lt;p&gt;Raftアルゴリズムは、以下の手段を用いて目的を達成します：(これはそのまま、ラフトを開発した研究者のプレゼン（youtubeで見られる）で発表されていたものと同じ)&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;
&lt;p&gt;リーダー選出：
クラスタ内の一つのノードがリーダーとして選ばれ、他のフォロワーノードに対して命令を発行します。リーダーはクライアントからのリクエストを受け取り、ログにエントリを追加します。
リーダが死んだ際には新たにリーダを選出するようにプロトコルが組まれています&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;ログレプリケーション：
リーダーがクライアントからのリクエストを受け取ると、そのリクエストをログに記録し、そのログエントリをフォロワーノードに複製します。フォロワーはリーダーからの指示に従い、同じログを持つことで一貫性を保ちます。
ここは結構大事だけど、クライアントからデータを受け取るのはリーダだけです&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;安全性の確保：
特定の条件下でのみリーダーが選出されるようにし、ログのコミットが保証されることで、システムの安全性と一貫性を確保します。
例えば、フォロワーの過半数がログエントリを受け取った場合にのみ、そのエントリをコミットと見なします。
また、最新のログ状態を持っているサーバしかリーダになれないようになっています。&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;リーダーの失敗処理：リーダーが失敗した場合、残りのノードのうち一つが新しいリーダーとして選出されます。この選出プロセスは、タイムアウトと投票を用いて実現されます。&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;まとめるとこうです。&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Leader election&lt;/li&gt;
&lt;li&gt;Log replication&lt;/li&gt;
&lt;li&gt;safety&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;では、ここから詳細に写っていこうと思います。&lt;/p&gt;
&lt;h1 id=&#34;前提知識&#34;&gt;前提知識&lt;/h1&gt;
&lt;h2 id=&#34;エージェント各サーバの役割&#34;&gt;エージェント（各サーバの役割）&lt;/h2&gt;
&lt;p&gt;サーバは３つの状態のうちのどれか&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;follower : completely passive. Does no action. But if he doesn&amp;rsquo;t get heart beat from leader he gets anxious and try to become a leader. He tries to . They expect to get heart beat from leader.&lt;/li&gt;
&lt;li&gt;candidate: Sends RequestVotes RPCs to get elected as leader.&lt;/li&gt;
&lt;li&gt;leader: Replicate its log to the followers. Heart beats to maintain its leadershop&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;If candidate or leader discovers higher terms RPC it gets back to follower.&lt;/p&gt;</description>
    </item>
    <item>
      <title>分散システム学習再始動</title>
      <link>https://blog.ingenboy.com/post/distributed_system/</link>
      <pubDate>Tue, 16 Jul 2024 23:32:39 +0900</pubDate>
      <guid>https://blog.ingenboy.com/post/distributed_system/</guid>
      <description>&lt;h1 id=&#34;出会いに感謝&#34;&gt;出会いに感謝&lt;/h1&gt;
&lt;p&gt;類は友を呼ぶとは言ったものだが、やはり部署が同じ人というのは興味も似てくる。
とはいっても、まさかTiDBやcockroachDBのコントリビュータとお友達になれるとは思わないわけで。&lt;/p&gt;
&lt;p&gt;尊敬しかない。自分はあきらめてしまった道を一人で突き進んでいったのだろう。
自分の弱さがふがいない。せっかく先陣を切ってくれた先人がいるのだから、これは後に続こうと思える。
ロールモデルがあると自分も頑張ろうと思えるわけで。こんなところで師匠に出会えるとは、、、最高すぎる。
ということで、もう一度、分散システムに挑んでみようと思う。&lt;/p&gt;
&lt;h1 id=&#34;とりあえず今日話したことをメモ&#34;&gt;とりあえず今日話したことをメモ&lt;/h1&gt;
&lt;p&gt;今のデータベース、MySQLとかはレプリケーションという技術を使って、一つのデータベースのテーブルを複数のノードにレプリケーションしている。レプリケーションされたデータが存在するノードが読み取り専用になる。マスターと呼ばれるノードは一台で、書き込みはここにだけ行われる。
しかし、これでは書き込み速度がスケールしないという問題点が生じる。そこで、noSQLというやつが出てきたんだよね。しかし、noSQLは整合性を保つのが難しいという課題があったんだよね。
そこで出てきたのがnewSQLというやつだね。tidb等。これを使うとwriteを容易にスケールすることができる。という話だ。
ほほう。なるほど。
ちなみに、俺が大好きなandrew pavloがこんな論文を出している
&lt;a href=&#34;https://db.cs.cmu.edu/papers/2016/pavlo-newsql-sigmodrec2016.pdf&#34;&gt;andrew pavlo&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;これによるとnewSQLの必要十分条件は、&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;NewSQL system’s implementation has to use (1) a
lock-free concurrency control scheme and (2) a shared-nothing
distributed architecture&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;まじか、これだけでいいのか。
&lt;a href=&#34;https://qiita.com/dulao5/items/cffdcba0669507a26e8b&#34;&gt;この記事&lt;/a&gt;がすごくいい感じに論文をまとめてくれている。&lt;/p&gt;
&lt;h1 id=&#34;データベースの種類&#34;&gt;データベースの種類&lt;/h1&gt;
&lt;ol&gt;
&lt;li&gt;RDBMS: mysql, postgresqlなど&lt;/li&gt;
&lt;li&gt;noSQL: cassandra, dynamodb&lt;/li&gt;
&lt;li&gt;newSQL: TiDB, cochroachDB&lt;/li&gt;
&lt;/ol&gt;
&lt;h1 id=&#34;自分が過去に書いたデータベース関係の記事を見返したい&#34;&gt;自分が過去に書いたデータベース関係の記事を見返したい&lt;/h1&gt;
&lt;p&gt;&lt;a href=&#34;https://blog.ingenboy.com/post/tidb/&#34;&gt;TiDBについて調べていた時期もありましたねー&lt;/a&gt;&lt;/p&gt;
&lt;h1 id=&#34;流れ&#34;&gt;流れ&lt;/h1&gt;
&lt;ul&gt;
&lt;li&gt;&lt;input disabled=&#34;&#34; type=&#34;checkbox&#34;&gt; まずはraftについてちゃんと理解するのが大事だと思う。実は完全に理解したとはいいがたい。&lt;/li&gt;
&lt;li&gt;&lt;input disabled=&#34;&#34; type=&#34;checkbox&#34;&gt; 分散データベースを作るならまずは分散してないデータベースを作れないといけない。ということで、CMUのbustubの講義は受けなおした方がいい。&lt;/li&gt;
&lt;li&gt;&lt;input disabled=&#34;&#34; type=&#34;checkbox&#34;&gt; 分散システムを理化するためにデータ志向アプリケーションを読もう。頼んだ。&lt;/li&gt;
&lt;li&gt;&lt;input disabled=&#34;&#34; type=&#34;checkbox&#34;&gt; いきなりだが、TiDBを読み込もう。cochroachDBでもいいと思う。この時にdesign Docsを読むのがいいらしい。&lt;/li&gt;
&lt;/ul&gt;
&lt;h1 id=&#34;その他の疑問&#34;&gt;その他の疑問&lt;/h1&gt;
&lt;p&gt;シャーティングという技術がある。
これは、データを複数のノードに分散して格納することで、検索速度を上げる方法。
RAID0（ストライピング）とはまた別なのね？&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;シャーディング（Sharding）
目的：データを分割して、複数のデータベースサーバに分散させ、スケーラビリティを向上させることです。

特徴：

データベース全体を論理的に分割し、それぞれの部分を「シャード」と呼ばれる個別のデータベースに保存します。
各シャードは独立したデータベースとして動作し、特定のデータサブセットを保持します。
シャードは水平分割とも呼ばれ、特定のキー（例：ユーザーID、地域、日時など）に基づいてデータを分割します。
データの分割によって、単一のデータベースサーバにかかる負荷を分散させ、スケーラビリティとパフォーマンスを向上させます。
例：

ユーザーIDに基づいて、ユーザーデータをシャードA、シャードB、シャードCに分割する。
ストライピング（Striping）
目的：データを分散してストレージパフォーマンスを向上させることです。主にデータの読み書き速度を向上させるために使用されます。

特徴：

単一のファイルやデータセットを複数のストレージデバイスに均等に分割して保存します。
各ストライプは連続したデータブロックを含み、ストライプ単位で並行して読み書きが行われます。
RAID（Redundant Array of Independent Disks）のコンセプトの一つであり、特にRAID 0が代表的です。
ストライピングは、ディスクI/O性能を向上させるために使用されますが、冗長性やフェールオーバーの機能はありません（特にRAID 0では）。
例：

1GBのファイルを4つのディスクに分割し、各ディスクに256MBずつ書き込む。
まとめ
シャーディングは、データベース全体を複数のシャードに分割し、各シャードを異なるサーバに分散させることで、スケーラビリティとパフォーマンスを向上させる手法です。
ストライピングは、データを複数のストレージデバイスに均等に分割して並行して読み書きすることで、ストレージのパフォーマンスを向上させる手法です。
&lt;/code&gt;&lt;/pre&gt;&lt;h1 id=&#34;ストライピングとシャーティングの両方を使うことはできますか&#34;&gt;ストライピングとシャーティングの両方を使うことはできますか？&lt;/h1&gt;</description>
    </item>
  </channel>
</rss>
