大量ファイル転送

ファイル転送

膨大な数のファイルを、1つの転送として高速に処理する。

データの総量が同じであっても、ファイル数が増えると転送の性質は大きく変わります。100GBのファイル1つと、100KBのファイル100万個はほぼ同量のデータを含みますが、小さいファイルが多数ある場合、ネットワークのスループットだけでなく、ファイルの検出、オープン/クローズ操作、メタデータ、ディレクトリ処理、キュー処理、ファイルシステムのI/O、個々の転送結果が、全体の処理時間に大きく影響します。

ファイル転送

ファイル数が増えるほど、ネットワーク速度だけでなくファイル処理全体が重要になる。

大容量ファイル転送と大量ファイル転送は異なる課題を扱います。1つの大容量ファイルは、長いデータストリームにおけるスループットと、中断時点からのレジュームに大きく依存します。一方、小さいファイルが多数ある場合、システムは個々のファイルごとに検出、オープン、読み取り、転送、ターゲット側での作成、クローズ、結果の記録を繰り返します。ファイル数が増えるほど、これらの小さな操作の積み重ねが総転送時間を左右するようになります。

そのため大量転送においては、単純にGbpsを上げることよりも、ソース側のファイルシステム、ディレクトリとメタデータの処理、転送キュー、ターゲットへの書き込み、ファイル結果を含むファイル処理パイプライン全体の持続的な処理能力を高めることの方が重要です。INNORIXはネットワーク転送とファイル処理を別々に扱うのではなく、1つの大量転送ジョブとして運用します。

ファイル転送

検出から最終結果まで、すべてを1つの大量処理パイプラインとして処理する。

大量ファイル転送は、最初の1バイトが送信される前から始まっています。システムはソース側にどのファイルが存在するかを検出し、ジョブに必要なファイルセットを選択し、ディレクトリとメタデータ情報を処理し、実際のデータ移動が始まる前に作業をキューに入れる必要があります。ターゲット側でも、ファイルの作成、書き込み、クローズ、結果の記録がファイルごとに繰り返されます。

INNORIXはこれらのステップを転送前、転送後の別々の作業として残しません。検出 → フィルタ/選択 → キュー → 転送 → 検証 → ファイル結果という一連のパイプラインを運用します。これにより運用担当者は、ネットワークの進行状況だけでなく、Dataset全体のうちどれだけが検出、処理されたか、どのファイルが完了し、どのファイルが残っているかを、1つの転送の中で把握できます。

ファイル転送

元のファイルとディレクトリ構造を保ちながら、ファイルを並列処理する。

多数の小さいファイルを1つのアーカイブにまとめることで、転送そのものを単純化できる場合があります。しかしアーカイブ化が転送に追加のステップとなる場合、ファイルはまずソース側でパッケージ化または圧縮され、ターゲット側で展開され、その後結果の検証が行われる必要があります。研究、マシンビジョン、メディア、ソフトウェアパッケージのように、ディレクトリ構造自体がDataset内で意味を持つ場合、これは別の運用タスクになってしまいます。

INNORIXは元のファイルとディレクトリの関係を保ちながら、キュー管理と動的な同時実行数によって複数のファイルを並列処理します。ファイルを1つずつ順番に送ることで発生する累積的な遅延を減らす一方で、常に可能な限り多くのファイルを同時に開くことが最善であるという前提も避けます。代わりに、Dataset全体を確実に完了させるために同時実行数を調整します。

ファイル転送

ソースとターゲットのキャパシティの範囲内で、持続的な処理を維持する。

同時実行数を増やし続けることが、必ずしも大量転送を高速化するわけではありません。ソース側のファイルシステムの読み取りやメタデータ処理、ターゲット側ストレージの同時書き込み、ディスクI/O、ネットワークリソースは、他のワークロードと共有されている場合があります。過剰な同時実行数は、むしろキューとストレージへの負荷を集中させる可能性があります。

INNORIXはキューと同時実行数の制御によってジョブ全体を運用し、ソース、ターゲット、ネットワークの状況に応じて並列処理を調整します。目的は、ある瞬間に可能な限り多くのファイルを処理することではなく、現在のインフラのキャパシティの範囲内で持続可能なファイル処理速度を維持しながら、Dataset全体を完了させることです。

ファイル転送

数百万のファイルにわたって個々の結果を保持し、必要な部分だけをリカバリする。

大量転送では、全体の進行状況や平均成功率だけでは、実際にジョブが完了したかどうかが分からない場合があります。1,284,392件のうち1,284,389件のファイルが配信された場合、成功率は非常に高く見えますが、運用上はどの3件のファイルが失敗したのか、そして再処理できるのかを知ることの方が重要です。

INNORIXは全体のRunと合わせて個々のFile Statusを保持します。完了した結果はそのまま保持され、中断された転送はレジュームされ、失敗または一部完了の状態にある必要なファイルだけが選択的にリトライされます。これによりリカバリは、Dataset全体を再実行するのではなく、まだ完了していないファイルを特定して最終的なDatasetを完成させるプロセスになります。

ファイル転送

高い成功率だけでなく、必要なDatasetが完全に配信されたことを確認する。

ファイル数が少ない場合、99.99%と100%の差はほとんど意味を持たないように見えるかもしれません。しかし大規模になると、わずかな割合でも実際には相当な数のファイルを意味します。100万ファイルの0.01%は100ファイルであり、1億ファイルの0.01%は1万ファイルです。そのため大量転送では、平均成功率だけではジョブが完了したと判断するには不十分です。

INNORIXはRunで全体の進行状況を示し、File Statusで失敗した範囲を特定し、リトライとリカバリの後にReceiptで最終結果を確認します。大量転送における完了の基準は、単に高い成功率というだけではなく、業務に必要なファイルセットが実際にエンドツーエンドで完了し、その結果を確認できるかどうかです。

ファイル転送

必要なファイルセットを、ディレクトリ構造とフィルタを保ったまま配信する。

大量のDatasetは、単なるファイルのリストにとどまらないことが多くあります。ディレクトリ構造自体がデータの一部であることもあります。研究用Dataset、マシンビジョン、メディアプロジェクト、ソフトウェアパッケージでは、後続のシステムがすぐにデータを使用できるよう、ソース側のディレクトリ関係をターゲット側でそのまま保つ必要がある場合があります。

同時に、ソース側に数百万のファイルがあるからといって、すべてのファイルを常に移動させる必要があるわけではありません。INNORIXはファイル名、拡張子、ディレクトリ、必要な条件によって転送対象を選択しながら、元のファイルとディレクトリの関係を保持します。これにより、ソース全体を複製するのではなく、Datasetレベルでジョブに実際に必要なファイルセットを選択し、元の構造のまま配信することができます。

ファイル転送

一度限りのDatasetを継続的なデータフローへと拡張する。

大量のデータは、一度だけではなく継続的に生成されることが多くあります。マシンビジョンの画像、ログ、センサーデータ、研究結果、メディアアセットは毎日、あるいは継続的に新しいファイルを生成するため、最初のマイグレーション以降に生成されたデータは、同じ転送経路を通じて繰り返し配信する必要がある場合があります。

INNORIXは一度限りのDatasetから始め、スケジュール転送、ファイルイベント、API、外部からのリクエストを同じFlowモデルに接続します。新しいファイルはフィルタリングされ、大量転送によって処理され、完了結果は次のFlowやコールバックに渡されます。これにより同じ転送が、一度限りの一括移動から継続的なデータ配信へと拡張されます。

ファイル転送

同じ大量転送を、複数ソースからの収集と複数ターゲットへの配信に適用する。

大量のファイルは、必ずしも1台のサーバーで生成されるわけではありません。データは工場、拠点、デバイス、処理サーバーにわたって同時に生成されることがあります。逆に、1つの画像Dataset、ソフトウェアパッケージ、メディアアセットを複数のサーバーやコンピュート環境に配信する必要がある場合もあります。

INNORIXは大量転送をN:1の収集と1:Nの配信に接続します。収集では、各ソースのファイルとパスの関係を保持しながら、各ソースからどれだけ収集されたか、どのファイルが残っているかを示します。配信では、各ターゲットごとの進行状況とファイル結果を管理します。これにより、ファイル単位での大量処理と、配信、収集におけるエンドポイント単位での完了基準を両立させることができます。

ファイル転送

サーバー、ファイルストレージ、オブジェクトストレージに、同じ大量転送の運用モデルを適用する。

膨大な数のファイルは、1台のサーバーやファイルシステムに限定されません。大量のデータは、共有ファイルストレージ、オブジェクトストレージ、クラウド、データセンター、拠点、工場にわたって存在することがあります。オブジェクトストレージでは、大量のオブジェクトがファイルシステムのファイルとして扱われるのではなく、リスト化、フィルタリングされた後にキューと並列転送によって処理されます。

検出とアクセスの方法はストレージの種類によって異なりますが、運用上は、ジョブ全体、個々のファイルやオブジェクトの結果、リトライ、最終的な完了状態に同じ大量処理モデルを適用できます。データがどこに存在していても、検出、キュー、並列処理、リカバリ、結果は1つの転送アーキテクチャによってつながっています。

ファイル転送

AIとマシン生成データのための継続的な大量データ移動をつなぐ。

AIとマシン生成データは、大量転送を代表する環境です。マシンビジョンは膨大な数の画像ファイルを生成し、AIトレーニング用のDatasetには大量の画像とラベルが含まれることがあり、自律システム、センサー、研究、デジタルパソロジーでは、ファイルの生成速度と総数の両方が転送アーキテクチャに直接影響します。

INNORIXはこれらのデータプロファイルに大量転送を適用し、必要に応じてAIデータ配信、収集、自動転送に接続します。大量転送自体は、結果が完了するまで多数のファイルを検出、処理、リカバリすることに重点を置き、コンピュートへのデータ配信、複数エンドポイントにわたる収集、配信、実行の自動化は、それぞれに対応する転送機能を通じて組み合わされます。

ファイル転送

Dataset全体から個々のファイルまで、1つのRunで確認する。

ファイル数が増えると、個々のサーバーのログを直接確認するだけでは、ジョブ全体を把握するのに十分ではなくなります。運用担当者は、まずDataset全体のどれだけが処理されたかを確認し、必要に応じてキューや失敗したファイルまで掘り下げ、リカバリ後に最終的な完了状態を判断する必要があります。

INNORIXはRunで転送全体の状態と処理済みファイル数を示し、File Statusで個々の結果を提供し、キューとリトライによって残りの作業を処理し、Receiptで最終結果を確認します。これにより、数百万のファイルを1つのジョブとして扱いながらも、必要な場合には個々のファイルレベルまで掘り下げられる運用構造が実現します。

ファイル転送

1億ファイルは「大量」の定義ではなく、スケール検証の1つの指標である。

大量転送が必要になる基準は、特定のファイル数で決まるものではありません。既存のワークフローは、わずか数千のファイルでも遅くなることがある一方、Datasetやマシンデータは数百万、数千万にまで増えることがあります。重要なのは、何件のファイルから「大量」と呼べるかではなく、ファイル数が増えても検出、転送、リカバリ、結果を同じ方法で処理、運用し続けられるかどうかです。

1億ファイルという数字は、すべての顧客がその規模で運用する必要があることを意味するものではありません。これは、INNORIXの大量転送アーキテクチャが実際のファイル数の増加に対応できるかを検証するためのスケールテストの1つの指標です。この製品の価値は、数字そのものではなく、小規模なバッチから継続的に生成される大規模なDatasetまで、同じ転送モデルを維持できることにあります。

ファイル転送

数千から1億ファイルまでを、1つの大量転送として運用する。

多数のファイルを転送のためだけに別のアーカイブ処理にまとめるのではなく、元のファイルとディレクトリ構造を保ったまま検出、キュー、並列処理によって処理します。ソースとターゲットの容量に応じて持続的なスループットを維持し、個々のファイルで問題が発生した場合は、ファイル単位の結果に基づいて必要な範囲だけを再処理します。

一度限りのDatasetから始め、同じ大容量転送モデルを、繰り返されるデータFlow、収集と配布、オブジェクトストレージ、AIおよびマシンデータにも適用します。全体のRunから個々のファイル、最終的な受領結果まで、すべてを一貫した構造の中で運用します。