Original paper
Response Time Evaluation of Tohoku University Research Data Lake IZUMI
2025 Volume 29 Issue 1 Pages 141-148
Details
2025 Volume 29 Issue 1 Pages 141-148
学術研究機関では，オープン＆クローズ戦略に基づいて研究データの管理・利活用を推進するための環境構築が求められている．東北大学では，研究者が日々の研究活動で生じる研究データを一元管理し，研究分野の特性を踏まえてデータの共有やオープンアクセス化を実施できるようにするため，2025年6月から研究データレイクIZUMIの運用を開始した．IZUMIはWebブラウザによるストレージサービスを中心に，オブジェクトストレージ，ファイル共有の3つのデータサービスをユーザに提供する．本稿では，ユーザによる適切なデータサービスの選択を支援するために実施した，エンド・ツー・エンドのシステム応答時間評価の結果について報告する．
公的資金を受けた研究の成果やその基礎データを広く公開するオープンサイエンスの促進が国際的な合意事項[1, 2]となる中，研究者らは研究活動で生じた研究データを競争力の源泉となる独自の知的財産として扱うことと，広く社会に公開して新たなイノベーション創出に資することの両方が求められている[3]．こうした状況のもと，大学をはじめとする学術研究機関では，データマネジメントプラン（以下「DMP」という）で定めたオープン＆クローズ戦略に基づく研究データの管理と，研究成果や基礎データの即時オープンアクセス化を組織として推進する動きが高まっている．
東北大学（以下「本学」という）では，2018年に東北大学オープンアクセス方針[4]，および2021年に東北大学研究データ管理・公開ポリシー[5]を定め，研究分野の特性を踏まえた研究データ管理と学術論文の機関リポジトリでの公開を進めてきた．しかし，日々の研究活動におけるポリシーの具体的な実践については各研究者に委ねられており，データの保存や公開／非公開を管理する仕組みの構築・運用に時間がとられていた．そのため，教職員が生産性高く研究関連業務に注力できるよう，研究データを一元管理しつつ，競争力の維持・共同研究者との協調・社会での利活用の各段階に応じたデータ公開レベルの調整をサポートできる情報ストレージ基盤の整備が必要とされていた．
そこで本学では，2024年度に東北大学研究データレイクIZUMI（以下「IZUMI」という）を構築し，運用準備期間を経て2025年6月から本学教職員向けにデータサービスの提供を開始した．IZUMIは，データダイレクト・ネットワークス・ジャパン（以下「DDN」という）製のファイルストレージを中核とし，Web UIベースのストレージサービスであるNextcloudと，オブジェクトストレージサービスであるDDN S3 Data Service（S3DS）（以下「S3サービス」という），ファイル共有サービスであるDDN NFS/CIFS Gateway（以下「NFSサービス」という）の3つのデータサービスから構成される．Nextcloudは全利用者に提供されるサービスであり，データを一元管理しながら非公開から共有，限定公開，公開までの多様な公開レベルを設定できる機能を基に，研究者らがDMPで定めたオープン＆クローズ戦略に基づく研究データ管理の効率的な実施を支援する．
また，ユーザはデータ管理ニーズ（研究室内で非公開データを共有したい等）や格納方法（端末から手動で格納，計測機器やプログラムから直接格納），データサイズ（大規模データを格納）など様々な観点を検討した上で，NextcloudにS3サービスやNFSサービスを組み合わせて使用することができる．
本稿では，IZUMIの運用開始に先立ち，ユーザによる適切なデータサービスの選択を支援することを目的として，保存される研究データのサイズに着目したエンド・ツー・エンドのシステム応答時間評価を実施した．Nextcloudは公的機関で比較的多く採用されているソフトウェアであることや[6, 7]，バックエンドストレージ上で複数のデータサービスを同時に提供する事例[8]があることを踏まえ，大学を中心に今後も類似のデータサービス基盤が構築・運用される際の参考となるよう，応答時間評価の結果を報告する．
IZUMIはオンプレミスの研究データレイクとして構築され，システムを構成するストレージやサーバ，およびそれらを接続するネットワーク機器はすべて本学のサイバーサイエンスセンター内に設置されている．
IZUMIのシステム構成概要を図1に示す．ストレージはDDN製のEXAScalerで，2つのノードによるHA構成（アクティブ／アクティブ）となっている．ノードのディスク装置に20 TB／本のHDDを330本搭載し，RAID6構成で実効容量は5 PBである．Lustreファイルシステムを採用し，提供する3つのデータサービスでLustreの領域を分けて使用する．また，ストレージはデータサービス用のネットワーク向けに1ノードあたり10 GbEのインタフェース2つを接続している．
Nextcloudサーバは，ユーザがアクセスするWebユーザインタフェース部と，バックエンドのデータベース部に分かれている．Webユーザインタフェース部は，NEC製Express5800が2台からなる2ノード構成（アクティブ／アクティブ）をとる．各ノードはデータサービス用のネットワーク向けにそれぞれ10 GbEのインタフェース2つを接続している．なお，運用開始時点でインストールされているNextcloudのバージョンは，Nextcloud Hub 9（30.0.5 Enterprise）である．
データベース部もExpress5800が2台からなる2ノード構成（アクティブ／スタンバイ）をとる．こちらもデータサービス用のネットワーク向けにノードあたり10 GbEのインタフェース2つを接続している．また，データベース部はLDAPサーバを兼ねている．Nextcloudのユーザ認証は本学のシングルサインオンシステム（以下「SSOシステム」という）と連携した多要素認証を利用しているが，SSOシステムのID保持者全員が本サービスを利用するわけではないため，Nextcloudの利用可否の判断にLDAPを用いている．
S3DSサーバはDDN製の1UサーバにS3ゲートウェイソフトウェアをインストールしたもので，ストレージと同様2台のノードによるHA構成（アクティブ／アクティブ）をとる．S3DSはLustre上のファイルにAWS S3互換のREST APIによるアクセスを提供する．S3DSサーバはデータサービス用のネットワークに1ノードあたり10 GbEのインタフェース2つを接続している．
NFSサーバもDDN製の1UサーバにNFSゲートウェイソフトウェアをインストールしたもので，1台のノードで構成される．NFSはLustreファイルシステムの一部をエクスポートして，許可したクライアントから接続できる機能を提供する．NFSサーバは，NextcloudやS3サービスとは異なるNFSサービス用ネットワークに10 GbEのインタフェース2つを接続している．
エンド・ツー・エンドのシステム応答時間に特に影響するネットワーク機器としては，ロードバランサとL3スイッチがある．ロードバランサは，NEC製Express5800サーバにHAProxyをインストールしたソフトウェアロードバランサとして構築している．ノード2台で冗長構成（アクティブ／アクティブ）をとる．ロードバランサの役割は，ユーザからのNextcloudまたはS3サービスへのアクセスを受け付け，2台あるサーバの一方に要求を転送して負荷を分散することである．ロードバランサはノードごとにデータサービス用のネットワーク向けに10 GbEのインタフェース2つを接続している．
L3スイッチは，NEC製QX-S4814XT-2Xが2台のスタック構成（アクティブ／アクティブ）となっており，本学の学内ネットワークシステムTAINS（以下「TAINS」という），およびロードバランサとそれぞれ10 GbEのインタフェース4つで接続する．ただし，そのうち2つはバックアップ回線のため，通常の運用で使用できるのは2つである．また，L3スイッチはNFSサービス用ネットワークと10 GbEのインタフェース2つで接続する．
ユーザである本学の教職員は，Nextcloud，S3サービス，NFSサービスのどのデータサービスにアクセスする場合でもTAINSを経由する．従って，現状の構成ではTAINSとL3スイッチ間，L3スイッチとロードバランサ間，L3スイッチとNFSサーバ間はどれも20 Gbpsのデータ転送速度となり，ユーザから認識されるIZUMIの最大スループットはデータサービスに依らず20 Gbpsである．NextcloudサーバやS3DSサーバなどアクティブ／アクティブ構成をとるコンポーネントは，各サーバのスループットが20 Gpbsであることから並列稼働時には理論上40 Gbpsのスループットとなる．
IZUMIはユーザに対してNextcloud，S3サービス，NFSサービスの3つのデータサービスを提供する．IZUMIでは，標準提供のNextcloudにより研究データの一元管理と公開レベルの柔軟な設定を可能とし，研究者のオープン＆クローズ戦略に沿った研究データ管理をシステム的にサポートする．S3サービスやNFSサービスは，複数ユーザ間で研究データを共有するための多様な手段を提供する付加サービスである．特にS3サービスはNextcloudとシームレスに連携できるため，S3サービス経由で保存されたデータをNextcloudで一元管理するデータとして扱うこともできる．提供サービスの概要とデータ公開レベル設定の対応状況について表1に示す．
| データサービス | Nextcloud（標準提供） | S3サービス | NFSサービス | ||
|---|---|---|---|---|---|
| プライマリストレージ | 外部ストレージ | オブジェクトストレージ | ファイルシステム | ||
| アクセス方法 | Web UI | REST API | NFS | ||
| ユーザ認証 | 本学のSSOシステムによる多要素認証 | アクセスキー／シークレットキーによるリクエスト認証 | マウント時にIDとパスワードで認証 | ||
| 主用途 | ユーザ個人の研究データ保存 | 複数ユーザ間の研究データ共有 | 複数ユーザ間の研究データ共有（大規模データの場合） | 研究室メンバ間でのデータ共有（学内限定） | |
| 研究データの公開レベル設定 | 非公開 | 〇 | △ | △ | 〇 |
| 共有 | 〇 | 〇 | 〇 | 〇 | |
| 限定公開 | 〇 | 〇 | ― | ― | |
| 一般公開 | 〇 | △ | ― | ― | |
〇：実行可能，△：実行可能であるが，運用上の制限あり，―：実行不可
NextcloudにはLustreファイルシステムに各ユーザのデータを直接保存するプライマリストレージと，S3DSのバケットをNextcloudに接続する外部ストレージの2種類のサービスがある．プライマリストレージはユーザ個人のストレージ領域であり，保存したデータはデフォルトで非公開となる．ただし，共有用URLを発行して学内外の共同研究者等に通知することで，データを共有することができる．また，発行したURLにパスワードや有効期間を設定することで，範囲を限定した公開や期間を限定した公開も可能である．さらに，URLを機関リポジトリに登録することで，保存データを一般公開（オープンアクセス化）することもできる．一方，外部ストレージは複数ユーザからなるグループ内でのデータ共有を前提としたストレージ領域であり，保存したデータはグループに属するユーザからのみアクセスできる．しかし，外部ストレージに保存されたデータであっても，データ共有用URLを用いたグループ内外の第三者との共有や限定公開などの公開レベル設定は可能である．一般公開も可能であるが，グループが削除された場合のURL変更等の運用が難しいため，オープンアクセス化用のURLとしては使用に適さない．
S3サービスはNextcloudの外部ストレージと同様に複数ユーザからなるグループ内でのデータ共有を前提としたストレージ領域である．バケット作成時に払い出されるアクセスキーとシークレットキーをグループに属するユーザ間で共有し，REST APIを用いてバケットへのデータ保存や取得を実行する．本サービスは，Nextcloud経由では保存できない大規模データを扱う場合，データ計測機器やプログラムから直接IZUMIにデータを転送する場合などに利用することを想定している．S3サービスには静的ホスティング機能がないためURLによるデータ公開はできないが，オブジェクトストレージとして利用しているバケットをNextcloudの外部ストレージに接続すれば，Nextcloud経由で保存データの公開レベルを設定することも可能である．また，S3サービスは国立情報学研究所の研究データ管理サービスGakuNin RDMの拡張ストレージとして連携することができるため，学認に参加する他組織の共同研究者とデータを共有する場合にも使用することができる．
ファイル共有を提供するNFSサービスは，研究室メンバなどローカルに限定された範囲でデータ共有することを前提としたストレージ領域である．NFSでエクスポートしたLustreファイルシステムを研究室のサーバ等からマウントし，学生を含む研究室メンバがマウントしたディレクトリ配下でデータを共有する．ただし，Lustreと研究室サーバの間でユーザの名前空間を一致させる設定を利用者側で実施する必要がある，研究室サーバのグローバルIPアドレスを運用側で把握する必要がある等，運用上の課題を解決する必要があり，サービス開始時点ではNFSサービスの提供は調整中である．
システム性能を評価するための代表的な指標にはスループット，ターンアラウンドタイム（Webシステムでは応答時間），可用性の3つが知られている[9]．研究データ管理で用いるデータレイクとしては，以下がユーザにとって有用な情報の一つとなると考えた．
・データのアップロード／ダウンロードに要する時間はどの程度か．
・どの程度のサイズまでデータを保存できるか．
そこで本稿では，ユーザが日々の研究で保存するデータのサイズや保存の方法に応じて適切なデータサービスを選択できるように，データサイズに着目したシステムの応答時間を評価する．
4.1 測定環境および前提条件応答時間の測定環境を図2に示す．最も多い利用形態と想定される，学内にある研究室のクライアント端末からIZUMIに対してデータをアップロード／ダウンロードする状況で評価した．NextcloudとS3サービスは個人の端末から，NFSサービスは研究室サーバ等からそれぞれ利用されるものとして，クライアントを別の端末にしている．研究室からTAINSへのアクセス回線はともに1 Gbps（有線）である．クライアントとサーバのマシンスペック，およびクライアントで使用した前提ソフトウェアの情報を表2に示す．
| 端末／サーバ | Nextcloud/S3DS Client | NFS Client | Nextcloud Server | S3DS Server | NFS Server |
|---|---|---|---|---|---|
| CPU | 13th Gen IntelTM CoreTM i9-13900KF 16コア |
IntelTM XeonTM E5-2420 12コア |
IntelTM XeonTM Silver 4410Y 12コア |
IntelTM XeonTM Silver 4514Y 16コア |
IntelTM XeonTM Silver 4416+ 20コア |
| RAM | 64 GB | 12 GB | 32 GB | 512 GB | 512 GB |
| ソフトウェア | Python v3.12.0 | fio v3.28 | ― | ― | ― |
まず，クライアントと各サーバの間で所定サイズのファイルを1つアップロード／ダウンロード（リード／ライト）したときの応答時間を評価した．NextcloudとS3サービスについては，クライアントでPythonプログラムを実行し，データのアップロード／ダウンロードを要求してからサーバ応答を受信するまでの時間を計測した．Nextcloudのデータ保存先はプライマリストレージである．また，NFSサービスについてはfio（Flexible I/O tester）ツールを実行し，マウントポイントでのシーケンシャルリード／シーケンシャルライトの実行時間を計測した．計測はデータサービスごとに10回行い，その平均値を応答時間の評価値とした．
対象とするデータサイズについては，IZUMI構築の前に実施した研究データ管理に関する学内アンケートを参考にした．アンケートでは，個人で保有する研究データ量について237件の回答のうち約8割が5 TB以下であった．1年間で5 TBのデータが蓄積されると仮定すると，月に20日間の研究活動が行われる場合に20.8 GB／日のデータが保存される．そこで本評価では20 GBまでの範囲のデータサイズで計測した．
図3にデータサービスごとのアップロード／シーケンシャルライトの応答時間を示す．データサイズと応答時間の関係を分かりやすくするため，データサイズを応答時間で割って求めたスループットも合わせて示した．Nextcloudにはファイルアップロード時にチャンク分割する仕組み[10]があり，Pythonプログラムでそれを利用した場合をNextcloud chunked upload，利用しない場合をNextcloud putと表示した．チャンクサイズはデフォルトの10 MBとし，各チャンクの送信は並列に実行される．また，参考値としてWeb UI（ブラウザ）経由でファイルを手動アップロードしたときのストップウォッチによる計測値（こちらは5回計測の平均値）をNextcloud Web UIとして表示している．Nextcloudの仕様として，Web UIによるアップロード時もチャンク分割は実行される．
S3サービスにもマルチパートアップロードと呼ばれるチャンク分割の仕組みがあり，Pythonプログラムでそれを利用した場合をS3 service multipart upload，利用しない場合をS3 service putと表示している．なお，チャンクサイズは64 MB[11]とし，各チャンクの送信は並列実行される．
図3では，データサイズが5 GBを超えるとNextcloud chunked uploadの応答時間が他のデータサービスと比較して2倍以上になっている．スループットも 0.5 GBや1 GBの場合と比較して40%程度低下した．実際にチャンク分割が行われるNextcloud Web UIでも同様の結果となっており，Pythonプログラムの要因とは考えにくい．Nextcloudのチャンク分割アップロードは以下のWEVDAVメソッドを順に呼び出して実行する仕様になっている．
・MKCOL：アップロード用の一時フォルダを作成
・PUT：チャンクの一時フォルダへの送信
・MOVE：チャンクを結合し，一時フォルダから保存先となるフォルダへのファイル移動
MKCOLとMOVEは1回，PUTはチャンクの数だけ並列実行される．図4にNextcloud chunked uploadの応答時間に占める各メソッドの割合を示す．どのデータサイズでもMOVEの実行時間が全体の3割以上を占めており，サイズが5 GBで約40秒，10 GBで約90秒，20 GBで約160秒もかかっている．Nextcloudで応答時間を短縮させるためには，サーバ側でのファイル移動の処理コストをどのようにして下げるかが課題となる．また，MOVEの実行時間はロードバランサのパラメータに影響を与える．ロードバランサとNextcloudサーバ間のセッションタイムアウト設定値よりもMOVE実行時間が長くなると，セッションが切れてデータ保存に失敗する．そのため，実際のデータ保存の状況に基づき適切なタイムアウトを設定することが重要となる．なお，IZUMIではサービス開始時点で60分としている．
一方，Nextcloud putはNextcloud chunked uploadよりも応答時間が短く，S3サービスやNFSサービスと比べても同等か少し良い結果となっている．スループットもデータサイズによらず100 MB/s～110 MB/s程度の高い値である．これは1クライアントから1ファイルをアップロードする条件下での計測であることが要因と考えられる．実際の運用で想定される多数のクライアントから同時にアップロードがある状況では，チャンク分割によりサーバ側で効率的に要求を処理することができるようになるため，システムのスループットが向上する．従って，そのような条件の下では，Nextcloud chunked uploadやS3 service multipart uploadの方がNextcloud putよりも応答時間が良くなる可能性はある．なお，ユーザが実際に利用するNextcloud Web UIではチャンク分割が適用されるため，10 MBを超えるデータではNextcloud putは実行されない．
その他のサービスについては，S3 service multipart uploadがNextcloud putやNFSサービスと比較して10%程度応答に時間がかかっているものの，大サイズデータではNextcloud chunked uploadよりもかなり短時間でデータを保存できる．また，スループットもサイズによらず90 MB/s程度で安定している．少なくとも5 GB以上のデータのアップロードについては，S3 service multipart uploadを選択する方がアップロード時間の点では良いと言える．なお，S3 service putではAWS S3と同様5 GB以上のデータをアップロードすることができない仕様となっており，10 GBと20 GBの計測値はない．1 GB以下のデータについては，NextcloudとS3サービスどちらを選択しても大差はないが，公開レベルを管理していくことを踏まえれば，Nextcloudを選択した方が効率的であると考えられる．
図5にデータサービスごとのダウンロード／シーケンシャルリードの応答時間を示す．図3と同様に，データサイズを応答時間で割って求めたスループットも合わせて示した．ダウンロードではチャンク分割は行われない．参考値としてWeb UI経由でファイルを手動ダウンロードしたときのストップウォッチによる計測値（こちらも5回計測の平均値）をNextcloud Web UIとして表示している．
データのダウンロードについては，データサービスによる応答時間の大きな差はなかった．スループットもデータサイズによらず100 MB/s以上の安定した高い値となっている．データサイズよりも利用方法（実験プログラムや連携システムから直接データを取得する等）に応じてNextcloud，S3サービス，またはNFSサービスを選択することができる．
なお，1ファイルをアップロードおよびダウンロードしたときの詳細な結果として，応答時間の平均値と標準偏差の数値をそれぞれ付録の表4，表5に示す．
4.3 アップロード可能なデータサイズ上限次に，IZUMIの標準サービスであるNextcloudで，データサイズを増やしながらどこまでのサイズのファイルをアップロード可能か検証した．AIにおける大規模言語モデルのように，シリアライズするとTB級のサイズになるデータも近年多く見られるようになっている．従って，データレイクシステムの性能限界の1つとして，アップロードサイズの上限について確認することには意味がある．検証では，Nextcloud Web UIでクライアントからサーバに100 GBから1 TBまでのファイルを手動アップロードし，成功の場合はアップロード完了までの時間を，失敗の場合はエラー発生までの時間をそれぞれ計測した．試行回数は1回である．そのため，今回の結果は任意の条件下でシステムとして上限サイズまでアップロードが成功することを保証するものではなく，あくまで目安として活用されることを想定している．
データサイズごとのアップロード成否を表3に示す．Nextcloud Web UIによるアップロードサイズの上限は600 GBであった．700 GBでは約3時間でエラーログがNextcloudサーバに記録された．ログにはMOVE実行時のエラーを示す記述があったため，ロードバランサとNextcloudサーバ間のセッションがタイムアウトしたと考えられる．図4の結果を踏まえてアップロード時間の35%程度をMOVEが占めていたと仮定すると，176 × 0.35 = 61.6（分）となるため，タイムアウト設定値の60分を超えていた蓋然性は高い．タイムアウトの設定値をより大きくすれば，さらに大サイズのデータをアップロードできる可能性はあるが，セッションタイムアウト時間を大きくしすぎることは，サーバリソースを無駄に消費し続けて逼迫させてしまうリスクもあるため，運用に合わせた設定が不可欠である．
| データサイズ（GB） | 100 | 200 | 400 | 600 | 700 | 800 | 1000 |
|---|---|---|---|---|---|---|---|
| Nextcloud Web UI | 〇 約44分 |
〇 約54分 |
〇 約90分 |
〇 約145分 |
× 約176分 |
× 約181分 |
× 約212分 |
| S3サービス（S3 Browser） | 〇 約23分 |
〇 約43分 |
〇 約81分 |
〇 約122分 |
〇 約140分 |
〇 約158分 |
〇 約187分 |
〇：成功，×：失敗
また，表3には参考情報としてS3 Browserを用いたS3サービスによるファイルの手動アップロードの結果も載せている．S3DSはAWS S3と異なり仕様上のアップロードサイズの上限はない（AWS S3のマルチパートアップロードは5 TBが上限）．しかし，バックエンドのLustreでは1オブジェクトのサイズの上限があり，デフォルトでは16 TBとなっている．従って，IZUMIでは16 TBがS3サービスの事実上の上限サイズとなる．
以上を踏まえると，システムパラメータに依存する部分ではあるが，Nextcloud Web UI経由であっても数百GBのデータアップロードは可能と言える．S3サービス経由では，学習済みAIモデルのようなTB級のデータであっても問題なくアップロードすることができる．
東北大学では，オープン＆クローズ戦略に基づく研究データの効率的な管理をサポートするため，研究データレイクIZUMIを構築し，2025年6月に運用を開始した．IZUMIでは，Web UIベースのストレージであるNextcloud，オブジェクトストレージのS3サービス，ファイル共有ストレージのNFSサービスからなる3つのデータサービスを本学教職員向けに提供する．Nextcloudは標準サービスであり，URL共有機能を通してユーザは保存する研究データの公開レベルを容易にコントロールできるようになる．S3サービスやNFSサービスは，データ共有の仕組みを拡張するオプションサービスであり，大規模データの共有や研究室内に限定した共有などデータ管理上のニーズを満たすために利用することができる．
本稿では，研究の過程で保存されるデータのサイズや保存の方法に応じて適切なデータサービスを選択できるように，データサイズに着目したシステム応答時間の評価と，アップロード可能なデータサイズ上限の検証を行った．その結果以下のことが分かった．
・Nextcloudではチャンク分割アップロードで実行されるWEVDAVのMOVEメソッドが応答時間の3割以上を占め，他のサービスよりも応答が長くなる，または応答がタイムアウトする要因になっている．
・5 GB以上のデータをアップロードする際には，S3サービス（マルチパートアップロード）の使用が応答時間の点で適当である．
・ロードバランサのタイムアウト時間の設定により，Nextcloudでも数百GBのデータをアップロードすることは可能である．
今後の課題としては，応答時間以外の代表的なシステム性能指標であるスループットと可用性の評価が残されている．IZUMIのサービス開始後はユーザからの様々な意見や要望を参考にして，研究者らが研究業務に専念しながらも適切な研究データ管理を実施できるよう，サービスの拡充に努めていきたい．
IZUMIの構築では，本学のデータシナジー創生機構および情報部デジタル基盤整備課のスタッフに大変お世話になりました．この場を借りてお礼申し上げます．
| 0.5 GB | 1.0 GB | 5.0 GB | 10.0 GB | 20.0 GB | |
|---|---|---|---|---|---|
| Nextcloud put | 5.31 (0.93) | 10.03 (0.92) | 46.31 (0.64) | 92.71 (0.06) | 184.52 (0.33) |
| Nextcloud chunked upload | 7.24 (0.39) | 14.50 (0.12) | 117.26 (10.76) | 238.08 (34.97) | 510.63 (59.96) |
| Nextcloud Web UI | 7.58 (0.74) | 15.39 (0.91) | 111.28 (6.30) | 235.50 (16.67) | 479.18 (34.92) |
| S3 service put | 6.37 (0.36) | 12.70 (0.32) | 62.40 (0.40) | N/A | N/A |
| S3 service multipart upload | 5.64 (0.02) | 11.27 (0.07) | 54.32 (0.08) | 108.17 (0.18) | 215.72 (0.53) |
| NFS service | 4.58 (0.13) | 9.21 (0.10) | 45.73 (0.10) | 92.88 (1.79) | 187.55 (3.69) |
※単位は秒，カッコ内の数値は標準偏差
| 0.5 GB | 1.0 GB | 5.0 GB | 10.0 GB | 20.0 GB | |
|---|---|---|---|---|---|
| Nextcloud get | 4.78 (0.06) | 9.65 (0.10) | 46.91 (0.35) | 94.77 (0.85) | 188.98 (5.25) |
| Nextcloud Web UI | 5.16 (0.05) | 10.20 (0.13) | 50.50 (2.07) | 96.63 (1.13) | 196.80 (5.36) |
| S3 service get | 4.61 (0.06) | 9.52 (0.54) | 46.39 (0.40) | 91.32 (0.11) | 181.93 (0.04) |
| NFS service | 4.46 (0.00) | 9.13 (0.00) | 45.63 (0.00) | 91.26 (0.00) | 182.55 (0.07) |
※単位は秒，カッコ内の数値は標準偏差
