[Oracle Cloud] Object Storageのマルチパートアップロード機能を試してみた

本記事の目的

前回の記事では、OCI CLIを利用したObject Storage の基本的な操作手順について紹介しました。

マニュアルに記載の通り、Object Storageではマルチパート・アップロード機能が提供されており、サイズの大きなファイルを分割して処理することで、アップロードに費やす時間を短縮できます。

The Oracle Cloud Infrastructure Object Storage service supports multipart uploads for more efficient and resilient uploads, especially for large objects. You can perform multipart uploads using the API, the Java SDK, or the Command Line Interface (CLI), but not the Console. With multipart uploads, individual parts of an object can be uploaded in parallel to reduce the amount of time you spend uploading. Multipart uploads performed through the API can also minimize the impact of network failures by letting you retry a failed part upload instead of requiring you to retry an entire object upload.

目安として、100MiB以上のファイルではマルチパート・アップロードで処理すると良いようです。

Multipart uploads can accommodate objects that are too large for a single upload operation. Oracle recommends that you perform a multipart upload to upload objects larger than 100 MiB. The maximum size for an uploaded object is 10 TiB. Object parts must be no larger than 50 GiB. For very large uploads performed through the API, you have the flexibility of pausing between the uploads of individual parts, and resuming the upload as your schedule and resources allow.

というわけで、本記事では該当機能の利用手順や、処理時間への影響について確認してみます。

 

 

検証結果

基本操作

OCI CLI Command Referenceに記載の通り、オブジェクトサイズが分割サイズ(デフォルト:128MiB)以上の場合には、自動的にマルチパート・アップロードで処理されます。

If the object is larger than –part-size, it will be uploaded as multiple parts (the default part size is 128 MiB)

つまり、例えば1GBのファイルを用意して、前回の記事と同様にアップロードするだけで、自動的に8分割のマルチパート・アップロードがされるはずです。

実際に試してみます。

 

・検証用ファイル(1GB)作成

 

・oci os object putでアップロード

参考までに時間も計測してみました。

⇒「Split file into 8 parts for upload.」で分かる通り、デフォルトの128MiBで分割されてアップロードされた模様。

念のため、3回ほど同じコマンドで処理時間を計測(–forceで上書き)。

— 2回目
real 0m21.618s
user 0m11.917s
sys 0m3.391s

— 3回目
real 0m20.461s
user 0m12.475s
sys 0m4.446s

 

・アップロード結果確認

 

・ダウンロード確認

⇒アップロードよりも若干遅い?

 

・ファイル一致確認

⇒ファイルサイズ一致

⇒MDハッシュでも一致を確認

 

マルチパート・アップロード処理の無効化

–no-mulipartオプションを指定することで、マルチパート・アップロードの無効化が可能

If the –no-multipart flag is specified, the object will be uploaded as a single part regardless of size (specifying –no-multipart when uploading from STDIN will result in an error)

先ほどと同じファイルを、–no-mulipartオプション付で実行して処理時間の差異を確認してみます。

⇒マルチパート処理と比べて、10秒ほど遅くなった。

念のため、3回ほど同じコマンドで処理時間を計測(–forceで上書き)。

— 2回目
real 0m27.479s
user 0m12.005s
sys 0m1.731s

— 3回目
real 0m27.934s
user 0m12.329s
sys 0m1.819s

⇒平均して遅い。

 

 

マルチパート・アップロード効果検証

最後に、ファイルサイズを10GBに増やして、いくつかのオプションパターンでマルチパート・アップロードによる処理時間の差異を確認してみます。

 

・検証用の10GBファイル作成

 

・マルチパート・アップロード無効化した場合(–no-multipartを指定)

 

・デフォルトでの実行(128MiB分割でのマルチパートアップロード)

⇒マルチパート・アップロード無効化時に比べて1分以上も早い

 

・分割単位を1000MBとしてアップロード

⇒デフォルト実行よりも遅くなった。

 

・分割単位を1000MB、かつ、パラレル度を10としてアップロード(parallel-upload-count=10を指定)

⇒デフォルト実行と同程度まで改善

 

参考)この処理実行中のvmstat

⇒負荷高すぎ。ocpuを増やしたら、もっと早くなるかも?(検証環境のOCPUは1個だけ)

 

・ダウンロード時間も確認(まずはデフォルト)

 

・マルチパートダウンロード

OCI CLI Command Referenceの記載より、getの場合はデフォルトではマルチパート・ダウンロードにはならない模様。

–multipart-download-threshold [integer range]
Objects larger than this size (in MiB) will be downloaded in multiple parts. The minimum allowable threshold is 128 MiB.

–part-size [integer range]
Part size (in MiB) to use when downloading an object in multiple parts. The minimum allowable size is 128 MiB.

multipart-download-threshold=128(MiB)とpart-size=128(MiB)を指定して、マルチパートダウンロードを試してみる。

⇒デフォルト実行の場合よりも、40秒ほど早くなった。

 

おまけ:検証用バケット削除

・バケットの削除

 

 

サマリー

  • OCI CLIでのObject Storage操作では、マルチパートアップロード機能が利用可能
  • アップロード(put)の場合、デフォルトで128MiB単位のマルチパートアップロードが有効
  • ダウンロード(get)の場合、–part-size オプションなどを利用して有効化が必要
    –part-size オプションで、分割サイズ単位を指定する

環境によるが、マルチパート・アップロード/ダウンロード機能は処理時間の改善に有効。

 

参考情報

・マニュアル「Managing Buckets」
https://docs.cloud.oracle.com/iaas/Content/Object/Tasks/managingbuckets.htm

・マニュアル「OCI CLI Command Reference」
https://docs.cloud.oracle.com/iaas/tools/oci-cli/latest/oci_cli_docs/cmdref/os.html

スポンサードリンク

Be the first to comment

Leave a Reply

Your email address will not be published.


*