Capordiaアプリケーションに必要なやり取りを設計する
各フローについて、起点、保存先、それを必要とする担当者を記録してください。採用するプロトコル、接続の開始方向、頻度、想定される容量も加えます。初回のインポート、管理接続、継続的に呼び出されるサービスは、同じ基準では準備できません。不明な保存先は、一般的な許可を開くのではなく、解決すべき課題として扱います。
このリストは、チームが何をアクセス可能にし、何を非公開のままにするかを判断するのに役立ちます。また、変更を誰が承認するかも明確にします。接続性の特性は GPU モデルから推測できるものではありません。帯域幅、アドレス、ポート、アクセス方法は、実際に提供される環境ごとに確認する必要があります。以下のマトリクスは架空のプロジェクトを表すものであり、含まれるサービスとして告知されているものではありません。
| フロー | 明確化する基準 | 責任者 |
|---|---|---|
| 管理用端末から環境へ | プロトコル、接続先、許可されたアクセス | アクセス責任者 |
| データ保管場所から GPU 処理へ | 初期容量、頻度、再開 | データ所有者 |
| アプリケーションから外部依存先へ | 接続先、認証方法、許容できる遅延 | アプリケーション責任者 |
| 結果から保存先へ | 最終容量と受領確認 | 成果物責任者 |
計画に関わる転送を測定する
予定している作業に近い数とサイズのファイルを含む、代表的なサンプルを用意してください。単一のアーカイブと数千の小さなファイルでは、手順にかかる負荷が異なります。インポートとエクスポートを別々に、実際に選択した接続先へ向けて測定します。有効容量、所要時間、使用ツール、パラメータ、テスト条件を記録し、2 回目の測定と比較できるようにしてください。
iperf3 などのツールは、クライアントとテストサーバー間のネットワークフローを測定します。そのドキュメントでは特に、通常方向と逆方向が区別されています。このような試験には両端の許可が必要であり、それだけではファイルコピーの速度を証明できません。速度はストレージ、処理、プロトコルにも依存します。まず、実際にスケジュールが左右されるアプリケーションの転送から始めてください。
測定値を転送可能な時間枠に変換する
完全に架空の例：600 GB をエクスポートする必要があります。ここでは 1 GB は 1,000 MB とし、速度は MB/秒で表します。有効 120 MB/秒の場合、600,000 ÷ 120 は 5,000 秒、つまり 1 時間 23 分 20 秒となります。より慎重な仮定である 70 MB/秒の場合、約 8,571 秒、つまり 2 時間 22 分 51 秒となります。これらの速度はいずれも Capordia の提供内容を表すものではありません。
チームがパッケージの仕上げと受信確認に45分を追加する場合、2番目の想定には約3時間8分かかります。チームは3時間10分の枠を確保し、その後、必要と判断した予備時間を別途追加できます。この枠はあくまで条件付きです。データ量、ファイル数、転送条件が変われば、計算をやり直す必要があります。この見積もりを、インターフェースの理論上の転送速度で置き換えないでください。
| 仮定 | 転送のみの所要時間 | 準備と確認に 45 分を加えた場合 |
|---|---|---|
| 実効 120 MB/秒 | 1 時間 23 分 20 秒 | 2時間08分20秒 |
| 実効 70 MB/秒 | 約 2 時間 22 分 51 秒 | 約3時間07分51秒 |
必要以上に開放せずにアクセスと再開を準備する
まず、想定される情報に基づいて接続先とホストの身元を確認し、次に権限と作業パスを確認してください。アクセス拒否は、運用アカウントのパスワードを共有ドキュメントで配布することで解決するものではありません。環境へのアクセスと Capordia アカウントへの接続は別の機能です。それぞれの責任者を記録し、シークレットはコピーしないでください。
手順で OpenSSH SFTP を採用する場合、転送は SSH 経由で行われます。そのドキュメントでは、部分的な再開は既に存在する断片がソースファイルと一致していることを前提とするとも記載されています。ソースファイルが変更されている場合、盲目的に再開すると不正なコピーが生成される可能性があります。したがって、転送するバージョンを固定し、部分ファイルを特定し、配信完了と宣言する前に結果を確認してください。
観察可能な段階ごとに待機を診断する
ファイルは届いているのにアプリケーションが応答しない場合は、設定全体を変更するのではなく、アプリケーションのフローを調べてください。名前解決、接続の確立、認証、最初のデータの読み取り、転送完了を区別します。時刻、方向、有用な正確なメッセージを記録してください。サポートと共有する内容から、認証情報、トークン、データを除外してください。
コピーが開始後に速度低下する場合は、同じ条件でもう一度実行して比較し、隣接する工程（転送元の読み取り、アーカイブの準備、転送先への書き込み）を観察してください。「GPUの使用率が低い」という事実だけでは、ネットワークが原因だと結論づけることはできません。診断資料には、何が何を待っているのか、そしてどの観察結果があれば考えられる原因を切り分けられるのかを記載する必要があります。
外部からのアクセスとGPU間の通信を切り分ける
アプリケーションへの接続に使うネットワークと、マルチカード計算の内部通信は、それぞれ異なる要件に応えるものです。CUDAのガイドでは、デバイス間でのデータと計算の明示的な配分が説明されており、そのアクセスの可否はシステムに依存します。カードの枚数や、手元の端末からのファイルコピーがうまくいくことは、分散処理が機能している証拠にはなりません。
そこで、想定されるシナリオを記述してください。各カードに独立したタスクを割り当てるのか、それともカード間でデータをやり取りする処理なのか。次に、お使いのソフトウェアが実際に使用する経路を確認します。必要なストリームが機能し、チェックが記録され、中断した転送を再開できる担当者がいれば、受け入れは完了です。こうして確定した条件は、そのままデプロイ記録に加えられます。
判断のための質問
計画でMB/sとMb/sを区別するのはなぜですか？
1バイトは8ビットです。例の10進単位では、70 MB/sは560 Mb/sに相当します。両者を混同すると、見積もりが8倍になったり8分の1になったりします。各測定値には単位を明記し、転送の実効スループットから計算してください。
転送は両方向ともテストすべきですか？
はい、プロジェクトでデータを取り込んでから結果を書き出す場合は必要です。経路、転送先、条件が異なることがあります。取り込みの測定が良好でも、最終的な取得が同じ時間枠に収まるとは限りません。各締め切りが依存する方向をテストしてください。
暗号化された転送はファイルの確認を不要にしますか？
いいえ。転送とパッケージの検証は別の問題に答えるものです。期待されるファイル、その完全性、転送先からの開封も確認してください。ファイルの選択を誤っても、正しく転送されたまま使えない状態になり得ます。