ネットワークノードのスケーリング

（セクション： エコシステムとネットワーク）

1）ノードの役割とトラフィックループ

検証/生産（コンセンサス/ブロック/ロールアップシーケンサー）：最終化の重要なパス。
Reader/Indexer（読み取り専用/API/アーカイブ）：アプリケーションおよび分析リクエストに対応します。
リレー/ブリッジ（クロスドメイン）：ドメイン間でメッセージ/アセットを転送します。
ゲートウェイ/エッジ（ingress/gRPC/WebSocket/QUIC）：クライアント要求の受信、レート制限、キャッシュ。
テレメトリック/オブザビリティ：メトリック/ログ/トレース、合成サンプルのコレクション。

各ロールには独自のSLO、エラー予算、スケーリングポリシーがあります。

2）モデルのスケーリング

2.1スケールアップ

CPU/RAM/SSD/NICを増やします。ピークのために高速ですが、鉄によって制限され、トラフィックの単位あたりのコストを増加させることができます。

2.2スケールアウト

バランサー/キューの後ろにレプリカを追加します。idempotence、 sticky policy、 quorumと一貫したキャッシュ（またはその障害）が必要です。

2.3機能的多様性

職務の分離：コンセンサスノードは分離されます。RPC/API-別途；indexer/archive-別途；bridge/relayer-別途。

2.4ジオスケール

地域クラスター（EU/US/AP）+anycast/GeoDNS/Latency Aware LB；ファイナライゼーション/レイテンシとローカルキャッシュによるレプリケーション

2.5シャーディング/パーティショニング

キー（chainId、 shard、 topic）で区切り、キュー/インデクサーと列ストレージを区切ります。

3）リクエストパス： バランシング、キャッシュ、QoS

L4/L7バランシング：健康チェック、トークン/トレースIDによる粘着性、サーキットブレーカー、アウトリアイジェクション。

• on edge（頻繁に読まれるRPCのための短いTTL）；
• プロセッサ内部（読み取り、インデックスの書き込み）；
• 負のキャッシュ（見つかりません）。
• QoSクラス：P0 （finalization/bridge/payment）、 P1 （product）、 P2 （bulk/archive）。
• Backpressure：トークン/クレジット、concurリクエストの制限、DLQのキュー。
• 入場料：事前フィルター（認証、制限、地理/制裁）、「高価な」要求の早期拒否。

4）状態管理： スナップショット、剪定、アーカイブ

Full/Pruned： RPC用のプルーンノード；アーカイブ-別のプールでの回顧クエリの場合。
スナップショット/高速同期：通常のスナップショット、新しいレプリカの高速ブートストラップ。
ホット/ウォーム/コールドストレージ：NVMe上のホット状態、履歴ブロック-インデックスとS3/objectします。
Garbadge-collect/compaction：ピーク時ではなく、スケジュールされたウィンドウ。
DA/バッチバッファ （L2/ブリッジ用）：証明書による配送保証とクリーニング期間。

5）キューとストリーミング

Ingress： Kafka/Pulsar/NATSパーティションキー='chainId' shard 'topic'。
消費者グループ：パーティー、idempotent handler （outbox/inbox）によるスケーリング。
DLQとレトライ：指数関数的バックオフ、毒メッセージ検疫。
合意された順序：決定主義のための当事者内。

6）輸送とネットワークの最適化

QUIC/HTTP/2：多重化、ヘッド・オブ・ライン補正。
TCPチューニング：BBR/CUBIC、バッファの増加、'SO_REUSEPORT'。
カーネル/eBPF：高速化されたネットワークスタック、バランシングのための一貫したハッシュ。
NIC オフロードpinning IRQ NUMA。
gRPC： keepalive/pingパラメータ、max-inflight制約。
WebSocket：接続プール、ping/pong、クライアントあたりの契約を制限します。

7）信頼性： クォラム、劣化、カオステスト

クォーラム（該当する場合）、リーダーフェンシングを読み書きします。
劣化モード：readonly、 「only finalized」、重いメソッドをオフにします。
カオスエンジニアリング：遅延/損失、再起動、ディスク/ネットワーク障害、「高速再構成」シナリオ。

8） SLI/SLOおよびターゲット

• メソッドクラスによるp95 RPC遅延；
• 成功率；キューラグp95；
• Time-to-finality p95（レール/ブリッジ用）；
• スナップショットブートストラップ時間；
• 州の成長/日；CPU/IO飽和。

• P0 RPC p95 ≤ 400ミリ秒；空室状況≥ 99。95%;
• Finalityリレーp95 ≤ 3分；
• Queue-lag P0 p95 ≤ 2インチ；
• ブートストラップの新しいリーダー≤ 30ミリ（高速同期+スナップショット）；
• 2時間のウィンドウ≤ 2 ×でエラー予算が燃えます。

9）観察可能性および警報

メトリクス：レイテンシー（ヒストグラム）、RPS、エラー（クラス別）、キューラグ、GC/ヒープ、 ディスクio、 p2pピア、ゴシップレート。
トレース：エッジ→RPC→indeksator→khraneniye→mostを介したエンドツーエンドの'trace_id'。
ログ：構造化、'request_id'による相関。
アラート：burn-rate P0、 queue-lag、 threshold以下のピアカウント、reorg-spikes、 snapshot-drift。

10）オートスケーリングパターン

HPA/VPA （K8s）： CPU/レイテンシ/RPS/キューラグ；トピアリーの長さによるKEDA。
ステップスケーリング：日のピークプロファイル；ML/季節性による予測。
ウォームスペア：トラフィックのないウォームアップレプリカ（優雅なプロモート）。
安全なロールアウト：canary+outlier-ejection+SLO-° C。

11）安全および分離

mTLS/キーのピン留め；方法ごとのRBAC/ABAC；組織/テナントごとのQoS制限。
Rate-limitとDoS-shield：トークン、パブリックRPC用のキャプチャ、異常検出。
秘密管理：短命のトークン、回転。
サンドボックス：アーカイブ/パブリッククライアント用の個別のプール。

12）参照構成

12.1 K8s： RPCゲートウェイ（スケールアウト）

yaml apiVersion: apps/v1 kind: Deployment metadata: { name: rpc-gateway }
spec:
replicas: 6 strategy: { type: RollingUpdate, rollingUpdate: { maxSurge: 2, maxUnavailable: 0 } }
selector: { matchLabels: { app: rpc-gateway } }
template:
metadata: { labels: { app: rpc-gateway, qos: P0 } }
spec:
containers:
- name: gateway image: org/rpc-gateway:2. 4. 1 ports: [{ containerPort: 443 }]
resources:
requests: { cpu: "1", memory: "2Gi" }
limits:  { cpu: "4", memory: "6Gi" }
env:
- { name: MAX_CONCURRENCY, value: "400" }
- { name: CACHE_TTL_MS, value: "200" }
readinessProbe: { httpGet: { path: /healthz, port: 443 }, initialDelaySeconds: 5, periodSeconds: 5 }
livenessProbe: { httpGet: { path: /livez, port: 443 }, initialDelaySeconds: 10, periodSeconds: 10 }
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: { name: rpc-gateway-hpa }
spec:
scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: rpc-gateway }
minReplicas: 6 maxReplicas: 36 metrics:
- type: Pods pods:
metric:
name: request_latency_p95_ms target:
type: AverageValue averageValue: 350m  # 350 мс

12.2 Envoy：優先順位付けとアウトリアイジェクション

yaml clusters:
- name: readers type: EDS lb_policy: LEAST_REQUEST outlier_detection:
consecutive_5xx: 5 interval: 2s base_ejection_time: 30s circuit_breakers:
thresholds:
- priority: DEFAULT max_connections: 20000 max_pending_requests: 5000 max_requests: 20000 health_checks:
- timeout: 1s interval: 3s http_health_check: { path: /healthz }
route_config:
request_headers_to_add:
- header: { key: x-trace-id, value: "%REQ(X-TRACE-ID)%" }
weighted_clusters:
clusters:
- name: readers weight: 100

12.3 Kafka：ドメイン別の分割

yaml topic: "rpc. events"
partitions: 48 replicationFactor: 3 config:
retention. ms:  604800000 # 7 days max. message. bytes: 1048576 min. insync. replicas: 2 cleanup. policy: delete

12.4 QoSと制限ポリシー

yaml qos:
P0:
rps_limit_per_org: 1500 queue_lag_p95_ms: 2000 retry: { attempts: 3, backoff_ms: [100,400,800] }
P1:
rps_limit_per_org: 800
P2:
rps_limit_per_org: 200 admissions:
denylist_methods: ["eth_getLogs(>10k blocks)"]
heavy_query_guard: { max_range_blocks: 5000, require_token: true }

13）データスキーマとサンプルクエリ

13.1ノードのメトリック（ディレクトリ）

sql
CREATE TABLE node_metrics (
ts TIMESTAMPTZ,
node_id TEXT, role TEXT, region TEXT,
rps INT, latency_p95_ms INT, errors_5xx INT,
queue_lag_ms INT, cpu NUMERIC, mem NUMERIC, io_wait NUMERIC
);

13.2 SLO制御および燃焼率

sql
SELECT date_trunc('hour', ts) AS h, role,
AVG(latency_p95_ms) AS p95,
100. 0 SUM(CASE WHEN latency_p95_ms <= 400 THEN 1 ELSE 0 END)/COUNT() AS slo_hit_pct
FROM node_metrics
WHERE ts >= now() - INTERVAL '24 hours'
GROUP BY 1,2;

13.3負荷計画

sql
SELECT region, role,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY rps) AS rps_p95,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY queue_lag_ms) AS lag_p95
FROM node_metrics
WHERE ts >= now() - INTERVAL '7 days'
GROUP BY region, role;

14）運営規程

毎日：SLOレポート、キャパシデルタ、スナップショットステータス、ピアヘルス。
毎週：制限/QoSの改訂、DRテスト（スナップショットからのブートストラップ）、剪定と圧縮をチェックします。
リリース前：カナリアロールアウト、SLOゲート、観測メトリクス、ロールバック計画。
コスト会計：1kリクエストあたりのCTS、 TPS_per_$ （1ドルあたりの効率）。

15） Playbookインシデント

A。 RPC p95レイテンシー爆発

1.P2-throttleおよびより低いサンプリングを可能にして下さい；2）ゲートウェイ/リーダーのレプリカを増やす。
2.一部のトラフィックをキャッシュにのみ転送します。4）必要に応じて、ホットメソッドの分析を開きます-deny-rules。

バスのB。 Queue-lag> SLO

1.Autoscaleの消費者（KEDA）、 2）締約国の再配布、3）一時的にバルクジョブを停止します。

C。バリデータ/リレーのピアカウントドロップ

1.p2pモジュールの再起動、2）座席の変更、3）チェックネットワークACL/NAT、 4）スイッチ保護。

D。 Longブートストラップ新しいレプリカ

1.新しいスナップショットに切り替える、2） IO帯域幅を上げる、3）一時的にアーカイブインデックスを削除する。

E。 Spike reorg/ブリッジの遅延

1.K-acknowledgements/window、 2） 「finalized-only」モードを有効にする、3）消費者に通知する。

16）実装チェックリスト

1.サイトロールとそのSLO/エラー予算を定義します。
2.機能を運ぶため：consensus/RPC/indexer/archive/bridge/edge。
3.DLQでバランシング、QoS、バックプレッシャー、キューを有効にします。
4.スナップショット/高速同期、剪定、階層化を設定します。
5.メトリック/トレイル/ログ、ダッシュボード、バーンレートアラートを接続します。
6.オートスケーリング（HPA/KEDA）とカナリアリリースを設定します。
7.カオステストと定期的なDR演習を実施します。
8.運用規程とコスト管理をご紹介します。

17）用語集

Backpressure-過負荷時の入力フローを制御するメカニズム。
DLQ-問題のメッセージの「デッドキュー」。
剪定-現在のウィンドウの外にある履歴状態を削除します。
高速同期/スナップショットは、新しいレプリカを同期するための加速された方法です。
Outlier-ejection-プールからの劣化したインスタンスの除外。
バーンレート-SLOに対するエラー予算消費率。

ボトムライン：ネットワークノードのスケーリングは「レプリカの追加」だけでなく、アーキテクチャ、QoS、状態管理、運用の厳密さのシステム規律です。このフレームワーク（ロール分離、キュー、キャッシュ、オートスケール、観測可能性、および明確なSLO）に従うことで、エコシステムは予測可能なパフォーマンス、ピークレジリエンス、およびトラフィック単位あたりの制御可能コストを獲得します。