💡 はじめに
HULFTでS3（クラウドストレージ）へファイルを送信する際、「間欠転送」という設定があります。
この機能は通信の安定化を目的としたものですが、実際には設定値によって転送が失敗したり、タイムアウトを引き起こすケースもあります。
この記事では、「間欠転送あり」と「間欠転送なし」で何がどう変わるのか、そしてS3送信でエラーが起こる原因と具体的な対策を整理します。
🔹 間欠転送とは？
間欠転送は、大きなファイルを一定サイズごとに区切って、間隔を空けながら送信する仕組みです。
通常転送が「連続的なデータストリーム」なのに対し、間欠転送は次のような動きになります。
この「16KB」は、転送ブロック長（4KB）×ブロック数（4） の場合の動作例です。
🔹 通常転送との違い
| 項目 | 通常転送（間欠なし） | 間欠転送（あり） |
|---|---|---|
| 仕組み | ファイルを連続して送信 | 小分けして間隔ごとに送信 |
| メリット | 高速・設定不要 | 通信の途切れを防げる（S3Timeout対策） |
| デメリット | 長時間通信で切断される可能性あり | 設定次第で速度低下・不安定化する |
| 想定環境 | LAN・オンプレ間など安定回線 | WAN・VPN・S3などクラウド宛て |
🔹 なぜS3で間欠転送が重要なのか
S3ストレージオプションは、HULFT内部で HTTP(S)通信 を使用しています。
この通信は、一定時間データの送受信が行われないと「タイムアウト扱い」となり、セッションが切断されます。
そのため、定期的に通信を行う間欠転送を使うことで、S3側が「接続が生きている」と判断しやすくなり、転送が安定します。
⚠ S3送信でエラーになる原因
間欠転送なしで送信してエラーになる場合、間欠転送にすることでエラー解消する場合もあります。
ところが、実際には「間欠転送をONにしたら逆に転送が失敗した」という報告も少なくありません。
主な原因は以下の通りです。
| 原因 | 内容 | 対応策 |
|---|---|---|
| ① 設定値が極端（間隔0msやブロック1など） | 通信制御が細かすぎて不安定になる | ブロック長4KB／ブロック数4／間隔20〜30msへ修正 |
| ② S3Timeoutが短い | デフォルトの60秒では間欠の待機中に切断される | hulft_s3.confに S3Timeout=120 以上を設定 |
| ③ 送信側と受信側の間欠設定が不一致 | 双方で動作パターンが異なりセッションが破綻 | 同一設定で統一する |
| ④ ファイルサイズと設定バランスが悪い | 大容量（数百MB）で間隔が長いと時間切れ | 間隔を短く・ブロックを大きく調整 |
| ⑤ ウイルス対策やVPN干渉 | 小刻み通信が検査対象になり応答が遅延 | 除外設定または専用ポート経由に変更 |
🧭 S3送信における安定化の推奨設定
| 設定項目 | 推奨値 | 解説 |
|---|---|---|
| 転送ブロック長 | 4096 bytes（4KB） | 標準的でメモリ効率が良い |
| 転送ブロック数 | 4 | 16KB単位で通信制御が安定 |
| 転送間隔 | 20〜30ms | 応答を維持しながら速度低下を抑制 |
| S3Timeout | 120〜180秒 | デフォルト60秒では短すぎる |
| 終了コード（RC） | RC=0が正常、RC=8以上は異常 | メッセージではなくRCで結果を判定 |
この設定であれば、150〜350MBクラスのファイルを3〜9分程度で安定して送信できます。
🧱 間欠転送が逆効果になるケース
LAN内やオンプレ同士など、もともと通信が安定している環境では、間欠転送を入れることで逆にCPU待ちや余計な遅延を生むことがあります。
そのため、以下のように使い分けるのがベストです。
| 環境 | 推奨設定 |
|---|---|
| 社内LAN・閉域網 | 間欠転送なし（高速重視） |
| S3・WAN・VPN | 間欠転送あり（安定性重視） |
🧩 トラブルシューティングの手順
-
間欠転送をOFFに戻して再送信
→ 正常に送信できるか確認して比較ベースを作る。 -
ONにした状態でログを確認
→ 通信エラー・再送メッセージなどを確認。 -
設定を微調整（間隔20→30msなど）
→ エラー頻度が下がるかを検証。 -
S3Timeoutを延長
→hulft_s3.confにS3Timeout=180を追記。 -
VPN・FW・ウイルス対策干渉をチェック
→ 小刻み通信の検査を除外する設定を追加。
🧠 まとめ
-
間欠転送は「S3など不安定回線向けの安定化機能」。
-
ただし設定値を誤ると、通常転送より不安定になる。
-
4KB×4ブロック・20〜30ms間隔・S3Timeout120秒以上が実運用で最も安定。
-
ジョブの成否は**終了コード（RC）**で判定し、メッセージ内容は原因分析に利用する。