https://www.m1ke.org/tags/p2p/Recent content in P2p on M1KE BL0GHugo -- gohugo.ioja-jpmikeThu, 30 Apr 2026 23:12:00 +0900https://www.m1ke.org/p/%E3%81%A8%E3%81%82%E3%82%8B%E5%88%86%E6%95%A3%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%AE%E8%A8%AD%E8%A8%88%E3%81%A7%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%9F%E6%A6%82%E5%BF%B5%E3%81%AE%E6%A3%9A%E5%8D%B8%E3%81%97/Thu, 30 Apr 2026 23:12:00 +0900https://www.m1ke.org/p/%E3%81%A8%E3%81%82%E3%82%8B%E5%88%86%E6%95%A3%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%AE%E8%A8%AD%E8%A8%88%E3%81%A7%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%9F%E6%A6%82%E5%BF%B5%E3%81%AE%E6%A3%9A%E5%8D%B8%E3%81%97/<img src="https://www.m1ke.org/p/%E3%81%A8%E3%81%82%E3%82%8B%E5%88%86%E6%95%A3%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%81%AE%E8%A8%AD%E8%A8%88%E3%81%A7%E4%BD%BF%E3%81%A3%E3%81%A6%E3%81%9F%E6%A6%82%E5%BF%B5%E3%81%AE%E6%A3%9A%E5%8D%B8%E3%81%97/system.jpeg" alt="Featured image of post とある分散システムの設計で使ってた概念の棚卸し" /><h2 id="背景">背景</h2> <ul> <li>とある分散システム上で売買を行うシステムの、UML設計をする仕事をしていた</li> <li>そのシステム上で、売買は平等なノード間で行われ、設計が大事だった</li> <li>その時にSLAやTX性能など色々検証していたので、そのメモの一部を残す</li> </ul> <h2 id="ネット取引の本質">ネット取引の本質</h2> <p>インターネット上の売買システムについて考える機会があった。結論以下になった。</p> <ul> <li>ネット上の売買ではtxをアトミックにしなければならない</li> <li>つまり、仲介者が本質的に必要だという事 <ul> <li>理由は相対取引が不可能だから（例えば、直接物々交換するなど）</li> <li>なので、物とお金の交換で、どちらかが先にお金や物をgiveすることになる</li> <li>その結果、あとでgiveする方が有利になり、逃げる事＝カウンターパーティリスクが発生するから</li> <li>以下みたいな感じ <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code><span class="lnt">1 </span><span class="lnt">2 </span></code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-fallback" data-lang="fallback"><span class="line"><span class="cl">Alice → Bob に送金 </span></span><span class="line"><span class="cl">Bob → Alice に送金する保証なし </span></span></code></pre></td></tr></table> </div> </div></li> </ul> </li> <li>仲介者抜きではネットの売買は成り立たないという事 <ul> <li>三方良しにしないとこのメカニズムは成り立たない。</li> <li>二人だけだと利益相反であり、３人だともう一人に利益を渡してインセンティブが無いと、持ち逃げされるから</li> <li>ブロックチェーンだって、OpenSeaみたいな仲介者がいないと本質的に成り立たない</li> <li>エスクロー取引が必要という事</li> </ul> </li> </ul> <h2 id="要件定義">要件定義</h2> <h3 id="ノックアウトファクター">ノックアウトファクター</h3> <ul> <li>他の条件がどれほど優れていても、その要素を満たさない（または満たしてしまう）場合に即座に不採用・却下となる致命的な要因・要件のこと</li> <li>これじゃぁ無理と言われる要項</li> </ul> <h3 id="非機能要件">非機能要件</h3> <ul> <li>セキュリティ要件</li> <li>法的要件</li> <li>ネットワークのアクセス要件</li> </ul> <h2 id="システム検証">システム検証</h2> <h3 id="検証の5要素">検証の5要素</h3> <ol> <li>運用</li> <li>パフォーマンス</li> <li>開発コスト</li> <li>ランニングコスト</li> <li>セキュリティ</li> </ol> <h3 id="検証結果の共有の三要素">検証結果の共有の三要素</h3> <p>検証・実験・試験は次の三つがミニマムで必要。</p> <ol> <li>前提</li> <li>結果</li> <li>結論</li> </ol> <h2 id="用語">用語</h2> <h3 id="信頼性可用性の観点">信頼性・可用性の観点</h3> <h4 id="rasis-ras">RASIS, RAS</h4> <p>コンピュータシステムの信頼性を評価する5つの指標。</p> <ul> <li>Reliability（信頼性）</li> <li>Availability（可用性）</li> <li>Serviceability（保守性）</li> <li>Integrity（完全性）</li> <li>Security（機密性）</li> </ul> <h4 id="セキュリティの三要素-cia">セキュリティの三要素 (CIA)</h4> <ul> <li>C: 「機密性」（Confidentiality）</li> <li>I: 「完全性」（Integrity）</li> <li>A: 「可用性」（Availability）</li> </ul> <h4 id="sli-slo-sla">SLI, SLO, SLA</h4> <ul> <li>Service Level Indicator</li> <li>Service Level Objective</li> <li>Service Level Agreement</li> </ul> <p>別の言い方をすると</p> <ul> <li>SLI → 何を測るか</li> <li>SLO → どの水準を目標にするか</li> <li>SLA → どの水準を契約・合意として扱うか</li> </ul> <h4 id="slo-service-level-objective">SLO (Service Level Objective)</h4> <ul> <li>レイテンシ <ul> <li>予測値 <ul> <li>100ms (TTFB; 99.9パーセンタイル)</li> </ul> </li> <li>通信してから帰ってくるまで</li> <li>curlでいう、time_starttransferのTTFB (Time To First Byte)</li> <li>単一リクエストに対する応答遅延</li> <li>API呼び出し、DBアクセス、ネットワーク往復などの単位で見る</li> </ul> </li> <li>スループット <ul> <li>予測値 <ul> <li>xxx req/s (書き込みで)</li> </ul> </li> <li>秒間に書き込めるTXの数</li> <li>apache benchmarkなどで実施する</li> </ul> </li> <li>コスト <ul> <li>予測値 <ul> <li>TBD 円/s</li> </ul> </li> <li>インスタンス費用とスループットから算出</li> </ul> </li> <li>ターンアラウンドタイム <ul> <li>予測値 <ul> <li>xxx ms</li> </ul> </li> <li>リクエストを送ってから帰ってくるまで</li> <li>実際にAPIを実行して何秒で返ってくるか</li> <li>業務処理やジョブ全体が完了するまでの時間</li> <li>例: 注文作成から確定まで、審査開始から完了まで</li> </ul> </li> <li>同時接続数 <ul> <li>予測値</li> <li>同時に接続できる数</li> </ul> </li> </ul> <h4 id="rams規格">RAMS規格</h4> <p>システムの安全性と信頼性のための規格</p> <ul> <li>信頼性 (reliability)</li> <li>アベイラビリティ (availability)</li> <li>保守性 (maintainability)</li> <li>安全性 (safety)</li> </ul> <h3 id="整合性可用性の観点">整合性・可用性の観点</h3> <h4 id="txのacid特性">TxのACID特性</h4> <p>特にアトミック性と一貫性が大切。結果整合性もある。</p> <ul> <li>Atomicity（原子性）</li> <li>Consistency（一貫性）</li> <li>Isolation（独立性）</li> <li>Durability（永続性）</li> </ul> <h4 id="分散システムのcapの定理">分散システムのCAPの定理</h4> <p>単一障害点（spof）をなくすことはここの可用性と関連。</p> <ul> <li>一貫性 (Consistency)</li> <li>可用性 (Availability)</li> <li>分断耐性 (Partition-tolerance)</li> </ul> <h4 id="base基準">BASE基準</h4> <p>高可用性を実現するための「システムの特性」のこと。</p> <ul> <li>BA (Basically Available | 基本的に利用可能)</li> <li>S (Soft state | 厳密ではない状態遷移)</li> <li>E (Eventual consistency | 結果整合性)</li> </ul> <h3 id="キャパシティ">キャパシティ</h3> <h4 id="キャパシティプランニングの3つの観点">キャパシティプランニングの3つの観点</h4> <ol> <li>latency</li> <li>throughput</li> <li>turnaround time</li> </ol> <h4 id="キャパシティ-1">キャパシティ</h4> <ul> <li>バックプレッシャー</li> <li>サーキットブレーカーパターン</li> </ul> <h3 id="分散システム">分散システム</h3> <h4 id="分散システムのtxパターン">分散システムのTXパターン</h4> <ul> <li>2 Phase Commit <ul> <li>全ノードがコミットするか、それとも全ノードがコミットしないかのどちらかの状態になることを保障するプロトコル</li> </ul> </li> <li>3 Phase Commit <ul> <li>コミットリクエスト、コミット準備、コミットの3段階でメッセージをやり取りするモデル</li> </ul> </li> <li>Sagaパターン <ul> <li>複数の状態変更を調整できリソースを長時間ロックすることがないよう設計されたアーキテクチャパターン</li> <li>Choreography (コレオグラフィ)と、Orchestrationパターンがある</li> <li>補償トランザクションの設計も必要</li> </ul> </li> <li>Try-Confirm/Cancelパターン</li> </ul> <h4 id="ノードのコンセンサスアルゴ">ノードのコンセンサスアルゴ</h4> <ul> <li>Paxos</li> <li>Raft</li> <li>BFT（Byzantine Fault Tolerance）</li> </ul> <h4 id="二重実行冪等性">二重実行・冪等性</h4> <ul> <li>二重決済の問題</li> <li>二重注文の問題</li> <li>リトライ時に二重実行</li> <li>idempotency key</li> </ul> <h3 id="運用">運用</h3> <h4 id="障害モデル">障害モデル</h4> <ul> <li>Fail-Stop障害モデル</li> <li>Fail-Recover障害モデル</li> <li>Byzantine障害</li> </ul> <h4 id="運用設計">運用設計</h4> <ul> <li>定期実施作業</li> <li>インシデント対応</li> <li>セキュリティ対応</li> <li>キャパシティプランニング</li> </ul> <h4 id="業務フローシステムフロー">業務フロー・システムフロー</h4> <ul> <li>アカウントの発行</li> <li>アカウントの審査</li> </ul> <h3 id="設計">設計</h3> <h4 id="全体設計">全体設計</h4> <p>誰が何をやるで全体的な設計をする。</p> <ul> <li>アクター・システム <ul> <li>エンドユーザー</li> <li>オペレーター</li> <li>アドミン</li> </ul> </li> <li>ユースケース分類 <ul> <li>エンドユーザー機能</li> <li>オペレーター機能</li> <li>アドミン機能</li> </ul> </li> </ul> <h4 id="2つの詳細設計の方法">2つの詳細設計の方法</h4> <ol> <li>個別設計</li> <li>横断設計</li> </ol> <h3 id="usecase">Usecase</h3> <h4 id="usecaseの必須項目">Usecaseの必須項目</h4> <ul> <li>ユースケースID</li> <li>ユースケース名</li> <li>アクター</li> <li>目的</li> <li>パラメーター</li> <li>備考</li> </ul> <h4 id="3つのフローとパラメーター">3つのフローとパラメーター</h4> <ul> <li>メインフロー = 期待通りに進む流れ</li> <li>代替フロー = 期待通りではないが、正常な別パターン</li> <li>例外フロー = エラー・失敗時の流れ</li> </ul> <h4 id="フローを進むための条件">フローを進むための条件</h4> <ul> <li>開始条件 = きっかけ</li> <li>事前条件 = 始める前の前提</li> <li>事後条件 = 終わった後の結果</li> </ul> <h4 id="確認項目">確認項目</h4> <ul> <li>シナリオテスト</li> <li>リーガルチェック</li> </ul> <h2 id="結論">結論</h2> <ul> <li>分散システムの設計は難しい</li> <li>特に障害点が無い代わりにスループットが上げにくい</li> <li>コンソーシアム型にしてもノード間のコンセンサスを取るのは大変</li> </ul>