続・数 GB のファイルを HTTP で POST できるか? - 2020年 ASP.NET Core 版

10GB 超でも POST できた、けど、効率はよくない

前回のブログ記事にて、何の工夫もない input type=file な form から、これまた何の工夫もない ASP.NET Core コントローラーへ、10GB を超えるファイルを HTTP POST 送信し、ファイル保存できたことを記した。

その仕掛けとしては、POST されてきた内容をいったんサーバー側一時ファイルとして保存したうえで、サーバー側コントローラーへ、その一時ファイルからのストリームを引き渡すことで実現されていた。

これはこれでよくできた仕掛けではある。しかし効率の観点からは、ASP.NET Core ランタイムによって一時ファイルにいったん保存されるのは無駄が多い。

つまり、クライアント (ブラウザ) からネットワーク越しに送信されてきた要求内容が、サーバー側でいったん一時ファイルに保存されたあと、その一時ファイルを再びサーバー側内で読み直して、同じサーバー上の別のファイルに複製している格好となるからだ。

クライアントから送信されたファイルを、サーバー上のファイルシステムではなく、例えば Azure Storage Blob などに保存する場合も考えても、クライアントからの要求をそのまま Blob に注ぎ込めば良さそうなところを、いったんサーバー側一時ファイルに保存する処理が挟まるのでやはり非効率だ。

当然、いったん一時ファイルに保存し終えるまでの時間が余計にかかることになる。

ということで、HTTP POST 要求をストリーム処理してみよう

幸い、この非効率さを回避することはそんなに難しくない。

前回記事と同じく API コントローラー方式で実装する場合であっても、実はそのものズバリの解説が、下記、公式ドキュメントに掲載されている。

要点としては、以下の二点だろう。

• メモリや一時ファイルにバッファリングさせずに自前で要求ストリームを読み取るため、モデルバインディングをしないようにする
  (そのためのフィルタ属性を自前で実装し、コントローラーのアクションメソッドに付記する)
  　
• multipart/form-data な HTTP 要求ストリームをパースし、同要求中のセクションごとの Stream を得る
  (ASP.NET Core 提供の MultipartReader クラスが使える。但しバウンダリ検出などの一部機能は自前でゴリゴリと実装する必要はある)
  

多少は自前でコードを書かないといけないが、幸い、上記公式ドキュメントに掲載のコードをコピー & ペーストで済ませることができる。

実際に、前回のブログ記事で作成したサンプルプログラムを、上記ストリーム方式に改造してみた結果を、streming-edition ブランチとして公開してある。

以上のとおり、公式ドキュメントに掲載の手順に従うだけで、一時ファイル方式ではなく、要求ストリームを直接読み取る方式に改善できた。

Azure App Services に配置し、1.6GB のアップロードに成功

前回のブログ記事を含め、ここまではローカル開発環境での話だ。

ではこのような ASP.NET Core アプリを、クラウド上の PaaS に配置したらどうなるだろうか。

今回はパブリッククラウドサービスのひとつ、Microsoft Azure の、App Services という PaaS に配置してみた。

Azure App Services への配置にあたり、アップロードされたファイルの保存先として、当該 PaaS の OS インスタンス内のファイルシステムではなく、同じく Microsoft Azure の Blob Storage サービスに保存するようにプログラムを変更した。(azure-blob-edition ブランチとして公開)

また、配置先 App Services の OS プラットフォームは (今回は Linux ではなく) Windows を選択した。

こうして Azure App Services 上に配置したこのサンプルプログラムを稼働させ、実際にインターネット越しに、まずは 1.6 GB 程の適当なファイルをアップロードしてみた。

結果、無事アップロード成功。

アップロードしたファイルは期待どおり Blob ストレージに格納されたことも確認できた。

3GB は失敗、サイズよりも時間が問題?

これに気をよくして、では、3GB 少々のファイルのアップロードを試してみることにした。

なお、Windows 版の Azure App Services であれば、ASP.NET Core Web アプリの前段に IIS が居るはず。  

で、前回のブログ記事でも触れたように IIS 側での要求サイズの制限があり、今のところ自分の知る範囲では 4GB までしか拡張できないっぽい。

とはいえ、今試そうとしているのは、その IIS の限界である 4GB より小さい、3GB ほどのファイルなので、アップロードは成功するはずだ。

ということで、実際にやってみたのであるが...

まず、自分が利用しているインターネット接続サービス回線上の問題なのか、なかなかアップロードが完了しない。

そして待つこと 40 分 (!) にして、TCP 接続が絶たれてしまうというエラーになってしまった。
HTTP ステータス 5xx が返るのでもなく、ERR_CONNECTION_RESET なのである。

回線上の問題かと思い、もう一度実行。

再び待つこと 40 分 (!)。

今度は IIS による HTTP 502 エラーページが表示されてしまった。

結局、4GB 未満であるにもかかわらず 3GB 少々のファイルアップロードに失敗してしまう原因・理由は掴み切れていない。

ただ、どうにも、IIS による 4GB 制限ではなく、もっと別の理由がありそうな雰囲気である。
とりわけ自分が使っている回線ではずいぶんと時間がかかってしまっている点が気になるところである。

まとめ

コントローラー方式による HTTP POST 要求処理実装であっても、要求をメモリや一時ファイルにバッファリングさせることなく、自前のコードで要求ストリームを読み取り、そのままファイルシステムや外部ストレージに書き出すことができることがわかった。

もちろん、コントローラー方式ではなく、要求ハンドラ (Startup クラスの Configure メソッド内で、app.Map(...) みたいに登録するやつ) を実装することでも実現可能なことだろう。

なお、そのような巨大な HTTP POST 要求を処理可能な ASP.NET Core Web アプリであっても、Microsoft Azure などのパブリッククラウド上に配置する場合は、それらクラウドサービスのプラットフォーム上の制約を受けることにる。

例えば IIS による 4GB 制限や、処理時間の上限 (Azure App Services だと 230秒) といった制約があることだろう。

そのようなプラットフォーム由来の制約があったり、それほど巨大な HTTP POST 要求には時間もかかり、実際問題として送信失敗した実績を考えると、実際上としては、こんな HTTP POST 要求 x 1発の Web フォーム送信はあまり現実的ではないことだろう。

どうしても巨大な何かをサーバーに送り込まなくてはならない場合は、クライアント側スクリプトを駆使してチャンクに小分けしながら送信するべきだろう。
できることなら、チャンク送信失敗時には再送信もできるようにまで作り込みするのが、より現実的なアプリケーションだと思われる。

ということで、では前回・今回のブログ記事はなんだったんだ、意味がないのかというと、そうでもないだろう。

まぁ、GB 級の要求送信となれば上記のとおりしっかり作り込むべきと思う。

そのいっぽうで、数百 MB 程度のファイルアップロード的な案件であれば、本ブログ記事のとおりの HTTP POST x 1 発の実装でも充分なこともあるだろう。

相変わらずニッチなテーマ、シナリオであるが、以上共有までに。