Object Storage 比較

1. Upload (PUT) 性能

PUTはMiB/s単位で持続的なupload throughputを測定します。以下のセクションでは、順次動作と同時実行によるスケーリングを分け、妥当なサンプル数と平均値を示します。

1.1 1 Thread PUT Throughput

IDrive^® e2は1 threadで4つすべてのobjectサイズカテゴリをリードしました。平均は256 KiBで9,37 MiB/sから100 MiBで307,30 MiB/sまででした。

1.2 5 Thread PUT Throughput

IDrive^® e2は5 threadで4つすべてのobjectサイズカテゴリをリードしました。平均は256KiBで47,71 MiB/sから100MiBで1.400,18 MiB/sまででした。

5-threadテストはclient側の中程度の並列性を表し、複数の同時転送を使うバックアップ、同期、移行アプリケーションに関連する場合があります。

1 threadで見られた順位は、concurrencyが増えても同じでした。つまり、最高性能のプロバイダーは単一転送だけでなく、すべてのobjectサイズでより多くの同時uploadを処理できたということです。

1.3 10 Thread PUT Throughput

IDrive^® e2は10 threadで4つすべてのobjectサイズカテゴリをリードしました。平均は256 KiBで93,00 MiB/sから100 MiBで1.879,48 MiB/sまででした。

10-threadの結果は、このテストマトリクスにおける総合upload容量の最も強い指標です。大きなobjectのPUT throughputはすべてのプロバイダーで大きく伸びましたが、スケーリングの度合いは異なりました。これらの値は、1つのobjectが終わるのを待ってから次を送るのではなく、複数のactive uploadを維持する並列バックアップ、レプリケーション、移行、メディア取り込みワークフローに最も適しています。

1.4 PUT Concurrencyのスケーリング

スケーリング曲線は、workerを1から10へ増やしたときにthroughputが上がるかどうかを示します。大きなobjectほど、接続やリクエストのoverheadが相対的に小さくなるため、一般により大きな改善が見られます。小さなobjectでは、スケーリングは主にリクエスト処理のoverheadに左右されますが、100MiB objectでは持続的な転送速度と同時streamの活用度を反映します。

2. Download (GET) 性能

GETは、時間の経過とともにMiB/sでどれだけデータをダウンロードできるかを測定します。PUTと比べると、単一threadのGETはプロバイダー間でより似ていますが、thread数を増やすと違いがより明確になります。

2.1 1 Thread GET Throughput

カテゴリ別リーダー: 256KiB: IDrive^® e2, 5MiB: Backblaze B2; 50MiB: Backblaze B2; 100MiB: IDrive^®e2.

単一threadのGETは、このテストで最も競争が激しい部分でした。Backblaze B2は5MiBと50MiBで首位、IDrive^® e2は256KiBと100MiBで首位でした。5MiBの結果は近接しており、Backblaze B2は平均64,87 MiB/s、AWS S3は63,36 MiB/s、IDrive^® e2は63,13 MiB/sでした。

2.2 5 Thread GET Throughput

カテゴリ別リーダー: 100MiB: IDrive^® e2, 256KiB: IDrive^® e2, 50MiB: IDrive^® e2, 5MiB: Backblaze B2.

5 threadでは、Backblaze B2が5MiB GETで399,49 MiB/sを記録して首位となり、IDrive^® e2は256KiB、50MiB、100MiBで首位でした。これらの混在した結果は、アプリケーションに合うworkloadカテゴリを比較することの重要性を示しています。

2.3 10 Thread GET Throughput

カテゴリ別リーダー: 100MiB: IDrive^® e2, 256KiB: IDrive^® e2, 50MiB: IDrive^® e2, 5MiB: IDrive^® e2.

10 threadでは、IDrive^® e2が256KiBの171,43 MiB/sから100MiBの1.034,81 MiB/sまで、4つすべてのGETサイズカテゴリをリードしました。これは、concurrencyが増えるにつれてその優位性が大きくなったことを示しています。

2.4 GET Concurrencyのスケーリング

256KiB objectでは、リクエスト処理のoverheadが主な要因です。100MiB objectでは、持続的な転送速度と並列性がより重要です。この2つのケースは、全体結果の解釈に役立ちます。より高いconcurrencyでの明確な差は、多数のアクティブな読み取りリクエストを伴うrestore、content delivery、分析workloadに特に関連します。

3. リクエスト遅延

LatencyはWarpで測定した、1つのリクエストを完了するまでの平均時間です。latencyが低いほど応答が速いことを意味します。プロバイダーは全体のthroughputが高くても、各リクエストに時間がかかる場合があるため、throughputとlatencyの両方を見ることが重要です。

Latencyチャートは各objectサイズを別々のパネルで示すため、より大きい50MiBや100MiBの値が小さいobject結果を見づらくしません。プロバイダー名は縦軸に固定され、各バーには値がラベル付けされています。この構成により、色やバーの長さから推測することなく、結果を直接比較できます。

4. 一貫性

変動係数、またはCVは、benchmark結果が平均に対して実行ごとにどれだけ変化したかを示します。CVが低いほど性能は安定して予測しやすく、CVが高いほど実行間のばらつきが大きいことを意味します。

5. Workloadの解釈

5.1 小さなobject workload

256KiBテストは、プロバイダーがリクエストをどのように処理し、接続を再利用し、metadataを処理し、API overheadを管理するかに焦点を当てています。これらの結果は、backupインデックス、thumbnail、小さなアプリ資産、多数の小さなobjectを含むworkloadに最も関連します。

5.2 中サイズworkload

5MiBと50MiBのテストは、一般的なbackupファイル、media segment、アプリバンドル、分析ファイルを表します。結果は、各プロバイダーが単一uploadでどれだけ効率的か、また並列uploadが全体速度をどれだけ押し上げるかを示します。

5.3 大きなobject workload

100MiBテストは、より持続的なネットワークおよびサービスのデータ転送に焦点を当てています。10 threadの結果は、並列backup、restore、複製、データ移動に有用で、1 threadの結果は単一転送で何を期待すべきかを示します。

5.4 適切な解釈

これらのテストはUS Eastにおける単一clientの結果に基づいています。すべての地域、client位置、ネットワーク経路、時間帯、SDK、アプリパターンを網羅しているわけではありません。読者は、自分のobjectサイズとconcurrencyに合うテストケースに最も注目すべきです。

6. 1日LIST, HEAD, DELETE benchmark

LIST, HEAD, DELETEは別々の1日運用benchmarkとして実行されました。PUTとGETのセクションとは異なり、これらの数値は7サイクル平均ではありません。各テストは同じUS Eastテスト起点と10同時workerを使用しました。LISTとDELETEは準備済みの100.000 objectセットを使用し、HEADはリクエスト対象として50.000 objectを使用しました。LISTとHEADはおよそ5分間実行されました。DELETEは固定objectセットが処理されるまで継続しました。

6.1 テスト構成

HEADの「50,000 objects」は、metadataリクエストに利用できるobjectセットを表します。Warpは時間ベースのテストが継続してリクエストを送り続けたため、ユニークなobject数よりも多くのHEADリクエストを完了しました。

6.2 LIST性能

IDrive^® e2は71,467.78 object/sで最高の平均LIST throughputを持ち、1,409.9 msで最も低い平均LIST request latencyを記録しました。平均TTFBは14 msでした。これらの数値は1日分のものであり、長期平均として扱うべきではありません。

LIST性能は、pagination、key traversal、response構成、そしてclientが各ページを処理する能力に依存します。throughput (1秒あたりのobject数) はobjectエントリがどれだけ速く返されたかを示し、平均request latencyは各LISTリクエストにかかる時間です。TTFBは最初の応答データがどれだけ早く届いたかを示します。テストがdurationベースであるため、rangeチャートは実行中の短期的な変動も示します。

6.3 HEAD性能

IDrive^® e2は1,017.80 object/sで最高の平均HEAD throughputと、9,8 msで最も低い平均request latencyを記録しました。Backblaze B2は770.76 object/sで2位、続いてWasabiが691.42 object/s、AWS S3が475.95 object/s、Cloudflare R2が98.24 object/sでした。5つのプロバイダーすべてが報告されたエラーなしでテストを完了しました。

6.4 DELETE性能

IDrive^® e2は、比較可能なDELETE throughputで3,475.88 object/sと最も高く、平均request latencyは290,43 msで最も低い値でした。Cloudflare R2は平均throughput 2,022.16 object/s、latency 495,89 msで2位、続いてAWS S3 1,032.09 object/s、Wasabi 815.72 object/sでした。

注: Backblaze B2は、B2 bucketが本質的にversionedであり、従来のnon-versionedモードをサポートしないため、DELETE比較から除外されました。Warpの標準DELETE benchmarkは、個別のversion IDを列挙して削除するのではなく、名前ベースのDELETEリクエストを送信します。B2ではこのようなリクエストは保存されたobject versionを恒久的に削除するのではなくdelete markerを作成するため、non-versioned DELETE操作との直接比較には適しません。

6.5 LIST/HEAD/DELETEの注意点

• これは1日分の比較であり、日ごとの一貫性を示すものではありません。
• LISTとHEADはdurationベースのテストで、DELETEは固定objectセットの処理後に完了します。そのため、throughputと完了挙動は別々に解釈すべきです。
• プロバイダー側のpagination、listing実装、delete batching、throttling、bucket構成は結果に大きく影響する可能性があります。
• これらの数値はテストした構成の運用スナップショットであり、7サイクルPUT/GET結果とは別です。

7. 方法論と品質管理

7.1 7サイクルPUTおよびGET benchmark

benchmarkはUS EastのVultr Linux VM 1台からWarpを使用して実施しました。各プロバイダーには、同じ操作、objectサイズ、concurrency、durationの組み合わせを与えました。マトリクスには、プロバイダーごと・サイクルごとに24のworkload構成が含まれました。つまり、2つの操作、4つのobjectサイズ、3つのthreadレベルです。各workloadは5分間実行されました。

各テストサイクルは同じworkload条件を維持し、日ごとの結果を同一条件で集約できるようにしました。PUTとGETは、256KiB、5MiB、50MiB、100MiBで1、5、10の同時workerを使って個別に評価されました。各workloadは5分間実行されました。この設計により、本質的に異なるobjectサイズやconcurrencyレベルを1つのスコアにまとめることなく、順次観測と並列観測の両方が得られます。

7.2 有効結果の基準

Warpが有効な数値throughput測定を含む完全な最終レポートを生成した場合、そのrunレベルの結果を含めました。Warpがすでにbenchmarkを完了し、利用可能な最終統計を生成していた場合、wrapperのゼロ以外の終了コードやwrapper timeoutは自動的に結果を無効化しませんでした。テスト準備中の失敗、サービス利用不可エラー、benchmark実行を妨げるDNSまたはnetwork timeoutなど、完全な最終数値結果が得られない場合はrunを除外しました。

7.3 集計

各プロバイダー-workloadセルについて、レポートは有効なrunレベルのthroughput値の算術平均を計算します。結果が除外された場合、サンプル数は変動します。latency値は同じworkloadセルの有効な結果から導出されます。

欠損結果をゼロに変換しないのは、性能とテスト完了を混同し、平均を人為的に下げてしまうためです。代わりに、除外された結果はサンプル数と可用性レポートにそのまま表示されます。付録の7サイクルマトリクスはrunレベルのビューを保持し、要約表と図の背後にある個々の観測を読者が確認できるようにします。

WasabiとBackblaze B2で9件の不完全なrunが確認されました。WasabiのPUTテスト3件はWarp timeoutに達し、Backblaze B2のGETテスト5件はテスト準備中にサービスが利用不可だったため失敗し、Backblaze B2のPUTテスト1件はDNS lookup/I/O timeoutのため失敗しました。

7.4 1日LIST,HEAD,DELETE benchmark

LIST, HEAD, DELETEは同じプロバイダーセット、US Eastテスト起点、10-worker concurrencyレベルを使用しましたが、実行設計は異なりました。LISTとHEADは約5分間のdurationベーステストでした。DELETEは固定objectセットを処理し、そのセットが完了すると終了しました。結果は独立して提示され、7サイクルのPUTおよびGET平均と結合されたり、総合的なプロバイダー評価に使われたりすることはありません。

7.5 単位

• PUTおよびGET throughput: MiB/s。
• LIST, HEAD, DELETE throughput: object/s。
• Request latencyとTTFB: ミリ秒。

7.6 完全なBenchmarkログ

再現性と独立レビューのため、完全なWarp実行ログと補助benchmark成果物は以下の公開リポジトリで参照されています:

Warp完全benchmarkログ: https://github.com/e2-idrive/s3-benchmark-logs

このリポジトリは、報告された集計を検証し、除外されたrunや失敗したrunを調査し、このレポートで説明した計算を再現するために使われたrunレベルの資料を提供します。

8. 制限事項

• 単一のclient locationとnetwork path。結果は地域、ISP、cloud、企業ネットワークによって異なる場合があります。
• 合成workload: Warpは再現性を提供しますが、すべてのアプリケーションのrequest mix、SDK動作、retry、object-key分布を再現するものではありません。
• 観測期間が限定的です: PUTとGETは7サイクル、LIST, HEAD, DELETEは1日スナップショットです。
• コスト、durability、機能、サポート、egress分析はありません。このレポートは性能に焦点を当てています。
• すべてのチャートでpercentile latencyの比較はありません。見やすさのため平均値を表示しています。tail latencyに敏感なアプリケーションはworkload固有のP95/P99テストを実施してください。
• 除外された結果: 平均値は有効サンプルに基づいており、プロバイダーやworkloadセル間でサンプル数が不均一な場合があります。

結果が示すこと

このUS Eastテストでは、IDrive^® e2が平均PUT workloadと12の平均GET workloadのうち9つで首位でした。Backblaze B2は5MiBと50MiBの1-thread GET、そして5MiBの5-thread GETで首位でした。1日運用テストはこれらの7サイクル結果とは別です。

このレポートは、各プロバイダーに単一のスコアを付けるものではありません。アプリケーションごとに重視する点は異なり、upload、download、listing、削除、objectサイズ、concurrency、latency、一貫性、場所、コストなどが含まれます。これらの結果を使う最善の方法は、要件に合うoperationとworkloadを選び、平均値と詳細なrunレベルデータの両方を比較することです。