本当に移動させる必要のあるものを数える
2つの棚卸しをしましょう。作業のために送るものと、最後に受け取るものです。ソース、ソフトウェアに必要なリソース、採用された結果は、必ずしも同じ容量とは限りません。また、レンタル前に準備できるファイルと、計算後にしか存在しないファイルも分けておきましょう。
ツールが提供する場合は、ファイル数と合計サイズをバイト単位で記録しておきましょう。データのサイズとディスク上の占有領域は区別してください。アーカイブを用意する場合は、そのアーカイブの転送には実際のサイズを使ってください。圧縮と展開には時間がかかり、追加の容量が必要になることもあります。圧縮による削減を前提とせず、別々に確認しましょう。
不要なコピーは、その役割を確認したうえで整理しましょう。再取得可能な公開キャッシュは、唯一のオリジナルやプロジェクト設定と常に同じ優先度とは限りません。残すべき要素の選別については、バックアップガイドで詳しく説明しています。
容量と速度は同じ単位でそろえましょう
このガイドでは、1バイトは8ビットです。10進接頭辞では1 MB = 1,000,000バイト、1 GB = 1,000,000,000バイトとなります。2進接頭辞では1 MiB = 1,048,576バイト、1 GiB = 1,073,741,824バイトとなります。対応する英語表記はMB、GB、MiB、GiBで、NISTがこれらの区別を文書化しています。
したがってMbit/sとMB/sは同じ量を指すわけではありません。80 Mbit/sの速度は算術的には10 MB/sに相当します。この換算は、アプリケーションが実際に毎秒10メガバイトのファイルをコピーすることを約束するものではありません。常に表示されている単位、特にビットとバイトの違いに注意しましょう。
| 元の値 | 計算に役立つ換算 |
|---|---|
| 6 GB | 6,000 MB、つまり6,000,000,000バイト |
| 6 GiB | 6,442,450,944バイト、およそ6.44 GB |
| 8 MB/s | 64 Mbit/s |
| 8 MiB/s | 8,388,608バイト/秒、およそ8.39 MB/s |
大きなフォルダーの前に小さく往復してみましょう
環境と転送方法が整ったら、許可された小さなファイルを送信し、別の場所で取得してそのコピーを開いてみましょう。この最初の確認で、経路、アクセス権限、保存先が正しいかを検証できます。ただし、大きなフォルダーの所要時間をまだ適切に測れるものではありません。
次に、転送の開始以降の様子を観察できる程度に十分な、代表的なまとまりを選びましょう。同じツール、同じ保存先を使い、実際のフォルダーに近い構成にしてください。小さなファイルが多い場合は、大きな動画1つだけでなく、そうしたファイルのまとまりでテストしましょう。実際にコピーされた容量と、一覧取得や一時停止も含めて転送完了までの経過時間を記録します。
容量÷時間で平均を計算しましょう。結果が大きく変動する場合は別の時間帯に再試行し、両方の観測を残しておきます。送信と取得は別々に測定してください。片方向の観測は、もう片方向の測定値にはなりません。別の保存先へのネットワークテストも、あなたのファイル転送ではありません。ESnetは、ネットワーク速度のテストと、それが実際の転送に与える上限とを区別しています。
所要時間を計算し、それが何を対象としているか確認しましょう
単位を揃えれば、時間(秒)= 容量(バイト)÷ 速度(バイト/秒)です。10進の容量がGBで速度がMB/sの場合、時間(秒)= GB × 1,000 ÷ MB/sとなります。次に60で割って分に換算します。速度は厳密に正でなければなりません。有効な測定値がない場合、時間は不明のままにしておきましょう。
たとえば、800 MBのまとまりを100秒でコピーした場合、平均は8 MB/sとなります。この数値はあくまでこの観測を表すものです。計測時間に一時停止や起動時間がすでに含まれている場合は、同じ工程に対して追加の余裕を二重に見積もらないようにしましょう。むしろ、測定していない作業(アーカイブの準備、コピーを開く、転送の一部をやり直すなど)には別の行を用意しましょう。
慎重なシナリオでは、代表的な複数の平均値のうち最も低い値を使うこともできます。どれを使い、どのような条件だったかを記録しておきましょう。低い値を選ぶのは計画上の仮定であり、速度がそれを上回り続ける保証ではありません。
計算例:6 GBを送信し、1.2 GBを取得する
合計6 GBのファイルを送信し、その後1.2 GBの結果を受け取るプロジェクトを仮定します。この完全に仮定の例では、送信テストで8 MB/s、受信テストで3 MB/sが出ています。すべての容量は10進です。これらの値はBriefGPUのレンタルでの試行から得られたものではありません。
送信には6,000 ÷ 8 = 750秒、つまり12分30秒かかります。受信には1,200 ÷ 3 = 400秒、つまり6分40秒かかります。したがって、採用した平均速度が維持されれば、2つの転送で19分10秒となります。表には、プロジェクトのために決めた確認と予備の仮定も加えています。
| この例のステップ | 入力または計算 | 予想時間 |
|---|---|---|
| 送信 | 6,000 MB ÷ 8 MB/s | 12分30秒 |
| 取得 | 1,200 MB ÷ 3 MB/s | 6分40秒 |
| コピーの確認 | 別途の人的前提 | 20分 |
| 不測の事態への予備 | 別途のスケジュール前提 | 30分 |
| これらのステップに確保した合計 | 750 + 400 + 1,200 + 1,800秒 | 1時間9分10秒 |
別の前提の影響を試してみる
この例で受信速度が1.5 MB/sに落ちると、1,200 MBには800秒、つまり13分20秒かかります。このステップの時間は2倍になります。他の仮定を変えなければ、合計は1時間15分50秒になります。こうして、スケジュールのどの部分がネットワークに依存し、どの部分が自分の確認作業に依存するかがわかります。
表示された容量が6 GBではなく6 GiBだった場合、8 MB/sでの送信には約805秒、つまり13分25秒かかります。ここでの違いは単位によるもので、ネットワークは変わりません。正確に計算するには、ファイルマネージャーが表示する丸めた値ではなく、バイト数をもとにしてください。
最後に、実際のフォルダーがサンプルと同じ構成でない場合は、もう一度測定してください。単純な掛け算では、コピー方法を代表していないテストを補えません。
転送をスケジュールの正しい位置に記録する
提供開始後に行う送信は、レンタル上の準備に含まれます。取得と最終確認はエクスポートに属します。あらかじめご自身のパソコンで完了した準備は別枠です。転送と別の作業が並行して進む場合、同じ時間帯を二重に数えないでください。
この例の合計には、インストール、計算、クライアントからの返信待ちは含まれていません。3日、7日、30日のプランを比較する前に、これらを完全なスケジュールに加えてください。この方法は、サーバーの提供までの時間、ストレージ容量、ネットワーク特性について何も断言するものではありません。
すべての取得を最後の瞬間まで先延ばしにしないでください。中間コピーと、保存先から最初のファイルを開くことで、障害を早い段階で発見できます。転送終了のメッセージは、期待したファイルの確認に代わるものではありません。