Boostは最近、ストレージプロバイダーがbooster-httpでHTTP検索（フルピース検索とレンジリクエスト）を提供できるようにする機能をリリースしました。Filecoinエバーグリーン、永久保存構想、ストレージディールレプリケーションに取り組むエコシステムパートナーは、これらの取り組みを効率的に進めるためにフルピースの検索が有益であることを共有しています。さらに、範囲リクエストを実行するオプションがあり、これは、クライアントがフルピース内のコンテンツの範囲を選択して取得することができることを意味します。
Booster-httpの負荷テストを実施し、その結果を共有することで、ストレージプロバイダーがBoostを使ったHTTP検索の仕組みを理解する一助になればと考えています。負荷テストツールはどなたでもダウンロードできますので、ご自身の負荷テストにご活用ください。
環境
今回のHTTP負荷テストでは、ペタバイト規模のストレージプロバイダーであるfilcollinsでテストを実施しました。以下は、filcollinsのハードウェアの詳細で、4つのインスタンス（2つのCPUインスタンスと2つのGPUインスタンス）が含まれています。
CPUインスタンスタイプ
CPU
モデル名：AMD EPYC 7F32 8コア・プロセッサー
ストレージ
1.8TBHDD×5台、ストライプアレイで動作、スクラッチエリアに指定
2 x NVMeがストリップド・アレイとして動作、スクラッチ領域に指定される
メモリ
1 TB RAM
GPUインスタンスタイプ
CPU
モデル名：インテル® Xeon® Gold 6242 CPU @ 2.80GHz
メモリ
502 GB RAM
GPU
4 x NVIDIA Quadro RTX 6000 (24 GB GDDR6)
ストレージ
封印/非封印セクターの長期保存に指定された500 TB Cephシステム
900GBHDD×3台、ストライプアレイで動作、スクラッチ領域として指定可能
負荷試験プロセス
HTTPベンチマークテストの設定方法ですが、10GBitと1GBitの接続をシミュレートするために、アウトバウンド接続に人工的な制限を設けました。また、双方とも片道遅延を40msと人工的に設定しました。ダウンロードのシミュレーションは、K6という負荷テストフレームワークを使用して行いました。
並行性を変化させてテストしたシナリオは、生の検索とBoostの検索の2つです。
- Raw：NGinxがディスクから直接ファイルを提供し、BoostやFilecoinは関係ありません。
- Boost: booster-httpを介して行われます。
これらのプロトコルは、フルフェッチとレンジリクエストの2つの主要なモードでテストされました。
- full-fetchとは、Filecoin piece全体を取得することを指します。
- range requestsは、Filecoinピース全体の中で特定の範囲のコンテンツを取得することを指します。今回の負荷テストでは、1MiB、10MiB、100MiBという複数の範囲でテストしました。
結果
フルピースリトリーブ
1GBと10GBの接続でフルピース検索を行った負荷テストの結果はほぼ同じです。レイテンシーにはわずかな差がありますが、大きな差ではありません（すべて1秒未満）。
レンジのリクエスト
1GBと10GBの接続で範囲リクエストの負荷テストを行った結果、より低い同時接続数でも同様の結果が得られました。生の検索とbooster-httpの差はそれほど顕著ではありません（1秒未満）。
しかし、同時実行数が1000になると、ブーストの範囲リクエストの取得が非常に遅くなり（10GB接続の場合、大きなデータ範囲では最大10分）、成功率もHTTPS取得（成功率40%から60%）と比較して低下することがわかります。特に同時接続数が多いリクエストでは、Boostがリクエストへの応答を開始する能力が低下しています。
チームはこの問題を調査し、なぜそうなるのかを解明することに全力を注いでいます。この速度低下は、高い並行性レベルの場合にのみ発生します。もし、ストレージプロバイダーが同様の挙動を観察したり、このレベル以上の並行性を必要とするユースケースをお持ちであれば、ぜひとも教えていただきたいと思います。また、テストを手伝ってほしい作業負荷がある場合は、チームに連絡してください。GithubまたはFilecoinのslackの#boost-helpで私たちを見つけることができます。
コメント