データ入出力と暗号化

オブジェクト・サイズは、 IBM Cloud® Object Storage のパフォーマンスに大きな影響を与える可能性があります。ワークロードに適したアプローチを選択します。

マルチパート転送

標準的な条件下では、マルチパート・アップロードおよびダウンロードは、転送を多数の並列トランザクションに分割するための非常に効率的な方法です。オブジェクト・サイズに応じて、通常は 100MB のパーツ・サイズが推奨されます。いずれの場合も、部品サイズを 4MiB の倍数に設定して、COS との間で送受信されるデータを最適化するのが最も効率的です。

AWS S3と同様に、マルチパート転送を使用すると、以下の利点があります。

スループットの向上-パートを並行してアップロードして、スループットを向上させることができます。
ネットワークの問題からのクイック・リカバリー-部品サイズを小さくすると、ネットワーク・エラーが原因で失敗したアップロードの再開による影響を最小限に抑えることができます。
オブジェクト・アップロードの一時停止と再開-時間の経過とともにオブジェクト・パーツをアップロードします。マルチパート・アップロードが開始されると、マルチパート・アップロードの有効期限はありません。明示的に完了するか、マルチパート・アップロードを中止する必要があります。
最終的なオブジェクト・サイズが認識される前にアップロードを開始します。オブジェクトは、作成中のときにアップロードできます。

マルチパート転送の複雑さが増すため、管理対象マルチパート転送のサポートを提供する適切な S3 ライブラリー、ツール、または SDK を使用することをお勧めします。

マルチパート・ダウンロード専用の API はありませんが、 GET 要求で Range ヘッダーを使用してオブジェクトの特定の部分のみを読み取ることができます。また、パーツをアップロードする場合と同様に、多くの範囲読み取りを並行して発行できます。すべてのパーツをダウンロードした後、それらを連結して、完全なオブジェクトの整合性を検査することができます。前述のように、これらの転送を手動で管理する複雑さを回避するために、SDK またはその他のツールを使用することをお勧めします。

多数の非常に小さいオブジェクトを保管する必要があるワークフローは、小さいファイルをより大きなデータ構造 ( [Parquet]など) に集約することで、より良いサービスを受けることができます。

サイズが 200mb より大きいオブジェクトの場合、特にネットワークの安定性が低い場合や、パケット・ロスが問題となる非常に長距離の場合、 Aspera High-Speed Transfer は優れたパフォーマンスを実現できます。 Aspera 転送では、ネストされたディレクトリー構造を単一の要求内で効率的にアップロードすることもできます。

バッチ削除のスロットル

S3 API は、単一のバッチ削除要求で最大 1,000 個のオブジェクトを削除するメカニズムを提供します。 COS システム内でのパフォーマンスが低下する可能性を最小限に抑えるために、これらの要求をクライアント・サイドでスロットルすることをお勧めします。発行された削除の数がシステムに対して多すぎる場合、クライアントは HTTP 503 エラーを受け取り、「スローダウン」を示すエラー・メッセージを受け取ります。

整合性の影響

IBM Cloud Object Storage System は、すべてのオブジェクト操作 (オブジェクト書き込み、上書き、削除、マルチパート操作、ACL 変更など) の即時整合性を保証します。バケットの作成も即時に一貫性があります。バケットのメタデータと構成は、他のオブジェクト・ストレージ・システムの場合と同様に、最終的に整合性が保たれます。つまり、高度に分散されたシステム間での変更は、短期間は同期化されない可能性があります。これは、パフォーマンス上の大きな利点を提供し、サービス妨害攻撃の可能性から保護するメタデータ・キャッシングが原因で発生します。

アプリケーションによっては、同じオブジェクトを上書きしたり、同じオブジェクトを短時間に繰り返し削除して再書き込みしたりすることがあります。これは、COS システム内の索引で競合を引き起こす可能性があるため、避ける必要があります。非常に高い頻度で、長期間にわたって同じオブジェクト・キー (名前) を使用してデータを上書きすることがアプリケーション設計の重要な側面であるというまれなケースでは、異なるストレージ・プラットフォーム (ファイル、ブロック、 noSQLなど) を選択することをお勧めします。

存在チェック

アプリケーションは、オブジェクトが存在するかどうか、またはオブジェクトに書き込む前にオブジェクトが変更されているかどうかを確認したい場合があります。多くの場合、これにより、PUT 要求または GET 要求が後に続く HEAD 要求を送信するアプリケーション・ロジックが非効率的になります。このアンチパターンは、ネットワークおよびサーバー・リソースの無駄をもたらすため、推奨されません。

HEAD 要求を何らかの関数内の存在検査として使用する代わりに、条件付き要求ヘッダーを使用します。これらの標準 HTTP ヘッダーは、 MD5 ハッシュまたはタイム・スタンプを比較して、データ操作を続行するかどうかを決定します。詳しくは、「条件付き要求」を参照してください。

条件付き要求の使用

データの読み取りまたは書き込み要求を行う場合、その要求に条件を設定して、不要な操作を回避することができます。これは、事前条件 HTTP ヘッダー If-Match、 If-None-Match、 If-Modified-Since、および If-Unmodified-Since を使用して行われます。

通常は If-Match を使用することをお勧めします。これは、 Last-Modified 値の細分度が秒単位のみであり、一部のアプリケーションで競合状態を回避するには不十分な場合があるためです。

If-Match の使用

オブジェクト PUT、 HEAD、または GET 要求では、 If-Match ヘッダーは、指定された Etag (オブジェクト・コンテンツのMD5 ハッシュ) が指定された Etag 値と一致するかどうかを検査します。この値が一致すると、操作が続行されます。マッチングが失敗すると、システムは 412 Precondition Failed エラーを返します。

If-Match は、状態変更メソッド (例えば、POST、PUT、DELETE) で最もよく使用されます。これは、複数のユーザー・エージェントが同じリソースに対して並行して動作している可能性がある場合 (つまり、「更新が失われた」問題を回避するため) に、偶発的に上書きされないようにするためです。

If-None-Match の使用

オブジェクト PUT、 HEAD、または GET 要求では、 If-None-Match ヘッダーは、指定された Etag (オブジェクト・コンテンツのMD5 ハッシュ) が指定された Etag 値と一致するかどうかを検査します。この値が一致しない場合、操作は続行されます。一致が成功すると、システムは PUT では 412 Precondition Failed エラーを返し、 GET または HEAD では 304 Not Modified を返します。

If-None-Match は、条件付き GET 要求で主に使用され、キャッシュされた情報を最小限のトランザクション・オーバーヘッドで効率的に更新できるようにします。クライアントが、エンティティー・タグを持つ 1 つ以上の保管済み応答を更新する必要がある場合、クライアントは、GET 要求を行うときに、それらのエンティティー・タグのリストを含む If-None-Match ヘッダー・フィールドを生成する必要があります。これにより、受信側サーバーは 304 (未変更) 応答を送信して、それらの保管応答の 1 つが選択表現と一致することを示すことができます。

If-Modified-Since の使用

オブジェクト HEAD または GET 要求では、 If-Modified-Since ヘッダーは、オブジェクトの Last-Modified 値 (例えば、 Sat, 14 March 2020 19:43:31 GMT) が指定された値より新しいかどうかを検査します。オブジェクトが変更されている場合には, 操作は続行されます。オブジェクトが変更されていない場合、システムは 304 Not Modified を返します。

If-Modified-Since は通常、2 つの異なる目的で使用されます。1 つは、 Etag を持たないキャッシュ表現を効率的に更新できるようにすること、もう 1 つは、Web トラバーサルの有効範囲を最近変更されたリソースに制限することです。

If-Unmodified-Since の使用

オブジェクト PUT、 HEAD、または GET 要求では、 If-Unmodified-Since ヘッダーは、オブジェクトの Last-Modified 値 (例えば、 Sat, 14 March 2020 19:43:31 GMT) が指定された値と等しいかそれより前であるかを検査します。オブジェクトが変更されていない場合、操作は続行されます。 Last-Modified 値の方が新しい場合、システムは PUT では 412 Precondition Failed エラーを返し、 GET または HEAD では 304 Not Modified エラーを返します。

If-Unmodified-これは、ほとんどの場合、状態変更メソッド (POST、PUT、DELETE など) で使用されます。これは、複数のユーザー・エージェントが、エンティティー・タグにその表記を提供しないリソースに対して並行して動作している可能性がある場合に、偶発的に上書きされるのを防ぐためです (つまり、「更新なし」の問題を回避するためです)。また、選択された表現が、前の要求で既に保管されている (または部分的に保管されている) 表現と一致しない場合に、安全な方法で要求を中止することもできます。

再試行戦略

ほとんどのライブラリーおよび SDK は再試行ロジックを自動的に処理しますが、一時エラーを適切に処理するために API を直接使用するソフトウェアを作成する際には注意する必要があります。最も重要なことは、503 エラーを受け取ったときに指数バックオフを実装する適切な再試行ロジックを提供することです。

Cypher チューニング

IBM COS は、転送中のデータを暗号化するためのさまざまな暗号設定をサポートしています。すべての暗号設定で同じレベルのパフォーマンスが得られるわけではありません。一般に、TLS を使用すると、パフォーマンスの低下が小さくなります。以下の暗号設定が推奨されます (優先順位の降順)。

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA