ブロックチェーンの遅延とスループットを理解する

著者：Lefteris Kokoris-Kogias

出典：paradigm.xyz

翻訳：ETH中文

皆さんは（ブロックチェーン）システムを正しく測定する方法についてあまり言及しませんが、それはシステム設計と評価プロセスにおいて最も重要なステップです。システムには多くのコンセンサスプロトコル、さまざまなパフォーマンスの変数、そしてスケーラビリティに関するトレードオフがあります。

しかし、これまでのところ、誰もが認める信頼できる方法は存在せず、同じカテゴリ内での合理的な比較を行うことは難しい状況です。本稿では、データセンター化システムの測定メカニズムに触発された方法を概説し、ブロックチェーンシステムを評価する際に避けるべき一般的な誤りについて考察します。

重要な指標とその相互作用

ブロックチェーンシステムを開発する際には、2つの重要な指標を考慮する必要があります：遅延とスループットです。

ユーザーが最も気にするのは取引の遅延、つまり取引を開始したり支払いを行ったりしてから、取引の有効性に関する確認情報（例えば、取引の発起者に十分な資金があることの確認）を受け取るまでの時間です。

従来のBFTシステム（PBFT、Terdermint、Tusk、Narwhalなど）では、取引が確認されると確定されますが、最長チェーンコンセンサスメカニズム（Nakamoto Consensus、Solana/Ethereum PoSなど）では、取引がブロックにパッケージ化され、その後再構成される可能性があります。その結果、取引が「kブロック深さ」に達するまで待たなければならず、これにより遅延時間が単一の確認時間を大幅に超えることになります。

次に、システムのスループットは一般的にシステム設計者にとって非常に重要です。これは、システムが単位時間あたりに処理する総負荷であり、通常は毎秒取引量（TPS）として表現されます。

一見すると、これら2つの重要な指標は完全に反対のものであるように見えます。しかし、スループットは毎秒の取引量から導出され、遅延は秒単位で測定されます。自然に、私たちはスループット = 負荷/遅延と考えるでしょう。

しかし、実際にはそうではありません。多くのシステムは、y軸にスループットまたは遅延を表示し、x軸にノード数を表示するグラフを生成する傾向があるため、この計算方法の実現は不可能です。逆に、スループット/遅延指標を含むより良いグラフを生成でき、それは非線形の方法でグラフを明確に読みやすく表示します。

競争がない場合、遅延は一定であり、システムの負荷を変更することでスループットを変更できます。このような状況が発生するのは、低競争の状況では取引を送信するための最小コストが固定されており、キューの遅延が0であるため、「何が入っても直接出ていく」からです。

競争が激しい場合、スループットは一定ですが、負荷を変更することで遅延が変化します。

これは、システムがすでに過負荷になっており、さらに負荷を増やすと待機キューが無限に長くなるためです。さらに異常なのは、遅延が実験の長さに応じて変化するように見えることで、これは無限に増加するキューの人工的な結果です。

これらの現象は、典型的な「ホッケーグラフ」または「L型グラフ」で見ることができ、到達間隔の分布に依存します（後述します）。したがって、この記事の重要なポイントは、私たちはホットスポットで測定を行うべきであり、ここではスループットと遅延が私たちのベンチマークに影響を与えることです；エッジ領域を測定する必要はありません。ここではスループットと遅延のうちの1つだけが重要です。

測定方法論

実験を行う際、実験者には3つの主要な設計オプションがあります：

1、オープンループ vs. クローズドループ

現在、ターゲットにリクエストフローを送信するための2つの主要な制御方法があります。オープンループシステムは、n = ∞のクライアントに基づいてモデル化され、これらのクライアントはレートλと到達間隔分布（例えば、ポアソン）に基づいてターゲットにリクエストを送信します。クローズドループシステムは、任意の時点で未完了のリクエストの数を制限します。オープンループシステムとクローズドループシステムの違いは、特定のデプロイメントの特徴であり、同じシステムが異なるシナリオでデプロイされることがあります。

例えば、キー・バリューストレージは、オープンループデプロイメントで数千のアプリケーションサーバーにサービスを提供することができますが、クローズドループデプロイメントでは数個のブロッキングクライアントにのみサービスを提供します。

正しいデプロイメントシナリオをテストすることは不可欠です。なぜなら、クローズドループシステムの遅延は通常、潜在的な未完了リクエストの数に制約されるのに対し、オープンループシステムは大量の待機キューを生成する可能性があるため、遅延が長くなるからです。一般的に、ブロックチェーンプロトコルは任意の数のクライアントによって使用できるため、オープンループ環境での評価がより正確です。

2、合成ベンチマークの到達間隔分布

合成ワークロードを作成する際、私たちは必然的に「システムにリクエストをどのように送信するか？」という問いを持ちます。多くのシステムは測定の前にトランザクションを事前にロードしますが、これは測定に偏りを生じさせます。なぜなら、システムは異常状態0から実行を開始するからです。さらに、事前にロードされたリクエストは主記憶装置にあり、そのためネットワークスタックをバイパスします。

より良い方法は、一定のレートでリクエストを送信すること（例えば、1000 TPS）です。これにより、システムの容量が最適に使用されるため、L型のグラフ（オレンジ線）が現れます。

しかし、オープンシステムは予測可能な方法で動作することは少ないです。逆に、それらは高負荷と低負荷の時間帯を持っています。これをモデル化するために、ポアソン分布に基づく確率間隔分布を採用できます。これにより、「ホッケー」グラフ（青線）が生成されます。なぜなら、平均レートが最適値を下回っていても、ポアソンの爆発がいくつかの待機遅延（最大容量）を引き起こすからです。しかし、これは私たちにとって非常に有利です。なぜなら、システムが高負荷をどのように処理し、負荷が正常に戻ったときにシステムがどれだけ早く回復するかを見ることができるからです。

3、ウォームアップフェーズ

最後に考慮すべき点は、測定を開始するタイミングです。私たちは、パイプラインが開始前にトランザクションで満たされることを望みます。そうでなければ、ウォームアップ遅延を測定する必要があります。理想的には、ウォームアップ遅延の測定は、測定結果が期待される分布に従うまで、ウォームアップフェーズ中の遅延測定を通じて行われるべきです。

比較を行う方法

最後の難題は、システムのさまざまなデプロイメントを合理的に比較することです。同様に、遅延とスループットが相互依存しているため、公平なスループット/ノード数グラフを生成するのが難しいかもしれません。

最良の方法は、サービスレベル目標（SLO）を定義し、その時点でのスループットを測定することです。単に各システムをその最高スループットに押し上げるのではなく（この場合、遅延は無意味です）。スループット/遅延グラフにおいて、遅延軸と交差するSLOの水平線を描き、交差点をサンプリングすることは、視覚化の良い方法です。

しかし、私は5秒のSLOを設定しましたが、それはわずか2秒で済みます。

ここでの負荷を増やして、飽和点を超えたわずかに高い可用スループットを利用したいと思うかもしれません。しかし、これは非常に危険です。システムの操作が不十分な場合、予期しないリクエストの爆発がシステムを完全に飽和させ、遅延が急増し、すぐにSLOに違反することになります。実質的に、飽和点を超えて運用することは、不安定なバランスを引き起こします。

したがって、考慮すべき2つの点があります：

過剰に構成されたシステム。基本的に、システムは飽和点以下で運用されるべきであり、到達間隔分布内の爆発を吸収し、待機遅延の増加を引き起こさないようにする必要があります。

SLOの下にスペースがある場合、バッチのサイズを増やしてください。これにより、システムの重要な経路上の負荷が増加し、待機遅延が増加することなく、より高いスループットを提供し、より高い遅延トレードオフを得ることができます。

私は巨大な負荷を生成していますが、遅延をどのように測定すればよいですか？

システムの負荷が非常に高い場合、ローカルクロックにアクセスし、システムに到達する各トランザクションにタイムスタンプを追加しようとすると、結果に偏りが生じる可能性があります。

逆に、2つのより実行可能な選択肢があります。最初の方法は最も簡単で、トランザクションをサンプリングすることです。例えば、特定のトランザクションにはマジックナンバーが存在し、これらのトランザクションはクライアントがタイマーを保持するトランザクションです。提出時間の後、誰でもブロックチェーンをチェックしてこれらのトランザクションがいつ提出されたかを確認し、遅延を計算できます。この方法の主な利点は、到達間隔分布に干渉しないことです。しかし、特定のトランザクションを変更する必要があるため、「ハッキー」と見なされる可能性があります。

より体系的な方法は、2つの負荷生成器を使用することです。最初のものは主要な負荷生成器で、ポアソン分布に従います。2番目のリクエスト生成器は遅延を測定するために使用され、その負荷ははるかに低くなります；システムの残りの部分と比較して、このリクエスト生成器は単一のクライアントと見なすことができます。システムが各リクエストに応答を送信しても（例えば、あるキー・バリューストレージのように）、私たちはすべての応答を負荷生成器に簡単に集め、リクエスト生成器からの遅延のみを測定できます。

唯一厄介な部分は、実際の到達間隔分布が2つのランダム変数の合計であることです；しかし、2つのポアソン分布の合計は依然としてポアソン分布であるため、数学的には難しくありません : )。

まとめ

大規模分散システムの測定は、ボトルネックを特定し、ストレス下での期待される動作を分析するために不可欠です。上記の方法を使用することで、私たちは共通の言語に向けて第一歩を踏み出し、最終的にはブロックチェーンシステムがその作業により適したものとなり、エンドユーザーへの約束を果たすことができることを願っています。

今後の作業では、この方法を既存のコンセンサスメカニズムに適用する予定ですので、興味があればTwitterでご連絡ください！