負荷テストレポート

INTMAX ネットワークの負荷テスト結果とスケーラビリティの評価

本レポートの目的は、CPU やメモリリソースの高負荷状態における INTMAX ネットワークの運用安定性を評価し、高負荷時のパフォーマンス課題を明確にすることです。

テスト方針

INTMAX のノードが大量のトランザクションを効率的に処理できるかどうかの判断に重点を置いています。特に、データベースの肥大化や ZKP（Zero-Knowledge Proof）生成時間の増加がシステムに与える影響に注目しています。

テスト手法

本番環境に近い負荷テスト環境を以下の条件で構築しました：

• 複数ユーザーが同時にトランザクションをリクエスト

• ユーザーが並行して残高証明（Balance Proof）を生成

• ユーザー数を段階的に増加させ、長時間にわたり持続的な負荷を維持

• ノードのスペックを段階的に調整し、処理能力の限界を検証

監視メトリクス

同時ユーザー数を変化させながらトランザクションを繰り返しシミュレーションするスクリプトを実行し、以下のメトリクスをサーバーログを通じて計測・監視しました：

• ノード

  • 1 秒あたりのリクエスト数

  • レスポンスタイム

  • CPU 使用率

  • メモリ使用量

• Postgres

  • アクティブ接続数

  • メモリ使用量

  • CPU 使用率

  • 1 秒あたりのデータ読み書き速度

• Redis

  • メモリ使用量

  • キャッシュヒット率

評価対象ノード

本テストでは以下のノードを対象としました：

• Block Builder

  • INTMAX ネットワークのブロック生成ノード

• Store Vault Server

  • トランザクションの暗号化と保存を担うノード

• Withdrawal Server

  • ZKP の検証とスマートコントラクトへの送信を担うノード

• Validity Prover

  • ブロックの有効性を検証するノード

  • CPU: 32 コア、メモリ: 64Gi

  • 4 台

• Balance Prover

  • 残高証明（Balance Proof）の ZKP を生成するノード

  • CPU: 32 コア、メモリ: 64Gi

  • 4 台

テスト結果

• DB コネクションプールの最適化

  暗号化されたトランザクションへの高負荷な同時アクセスを伴うストレステストにおいて、デフォルトのプールサイズの上限を超過する事象が発生しました。プールサイズの拡大と関連パラメータのチューニングにより、速やかに問題を解決しました。

• ノードレベルのスケーラビリティ評価

  ユーザー数を段階的に増加させた結果、最初に処理能力の限界に達したのは ZKP 生成モジュールでした。CPU リソースの追加によりブロック生成間隔を安定的に維持できるため、水平スケーリングで必要なキャパシティを確保できます。

• 現時点のプルーフ生成時間と改善余地

  現在の構成では、各ワーカーがブロック有効性プルーフを生成するのに約 65 秒を要します。水平スケーリングにより、この数値をブロックあたり約 20 秒まで短縮できると見込んでいます。

• 残高証明のレスポンスタイム

  残高証明（Balance Proof）の生成には現在約 5 秒かかり、同時リクエストが集中した場合は待ち時間が 5 分を超えるケースが確認されました。スケールアウトによるスループット向上で、このキュー待ちを短縮します。

• 高並列アクセス時の同期処理

  トランザクション直前に必須となる残高の同期処理はセキュリティ上不可欠です。極度の並列アクセス下では、全体のスループットを一時的に低下させることがあります。

まとめ

これらの結果から、トラフィック増加時に最も効果が大きいのは、Validity Prover および Balance Prover のコンピューティングリソースの拡充と、負荷分散戦略の強化であることが明らかになりました。スケールアウトアーキテクチャの構築と最適化作業はすでに進行中であり、段階的なアップグレードにより、ネットワーク全体のパフォーマンスとユーザー体験をさらに向上させていきます。