OSS パフォーマンスの最適化 - スループットとレイテンシーのベストプラクティス - Object Storage Service

Alibaba Cloud Object Storage Service (OSS) の分散アーキテクチャを活用して、OSS のデータ処理速度を向上させ、レイテンシーを削減し、アプリケーションの応答を高速化します。

順次プレフィックスからランダムプレフィックスへの変更

OSS は、高同時実行リクエストをサポートするために、オブジェクトキーの UTF-8 順序に基づいてデータをパーティションに分割します。順次プレフィックス (タイムスタンプまたは辞書順にソートされた文字列) は、ファイルを少数のパーティションに集中させ、過負荷を引き起こします。代わりにランダムプレフィックスを使用して、負荷を均等に分散してください。

リクエストレートが 1 秒あたり 2,000 リクエストを超えると、次の問題が発生する可能性があります。各ダウンロード、アップロード、削除、コピー、またはメタデータの取得は 1 回の操作としてカウントされます。N 個のファイルの一括削除または一覧表示は、N 回の操作としてカウントされます。

ホットスポットパーティションが形成されます：高頻度のリクエストが特定のパーティションに集中し、その I/O 容量を使い果たすか、自動的なスロットリングがトリガーされます。
リクエストレートが制限されます：ホットスポットパーティションは継続的なデータリバランスをトリガーし、リクエストの処理時間が増加します。

説明
データリバランスは、固定されたシャーディングルールではなく、リアルタイムのシステムステータスと処理能力の分析に基づいて行われます。順次プレフィックスを持つファイルは、データリバランス後もホットスポットパーティションに残る可能性があります。

これらの問題を解決するには、順次プレフィックスをランダムなものに変更してください。これにより、オブジェクトインデックスと I/O 負荷がパーティション間で均等に分散されます。

オブジェクトキーに 16 進数ハッシュプレフィックスを追加

日付と顧客 ID を使用してオブジェクトキーを生成する場合、オブジェクトキーには順次的なタイムスタンププレフィックスが含まれます：
```
sample-bucket-01/2024-07-19/customer-1/file1
sample-bucket-01/2024-07-19/customer-2/file2
sample-bucket-01/2024-07-19/customer-3/file3
...
sample-bucket-01/2024-07-20/customer-2/file4
sample-bucket-01/2024-07-20/customer-5/file5
sample-bucket-01/2024-07-20/customer-7/file6
...
```
顧客 ID のハッシュ (MD5 など) を計算し、数文字をオブジェクトキーのプレフィックスとして使用します。4 文字のハッシュプレフィックスを使用すると、キーは次のようになります：
```
sample-bucket-01/9b11/2024-07-19/customer-1/file1
sample-bucket-01/9fc2/2024-07-19/customer-2/file2
sample-bucket-01/d1b3/2024-07-19/customer-3/file3
...
sample-bucket-01/9fc2/2024-07-20/customer-2/file4
sample-bucket-01/f1ed/2024-07-20/customer-5/file5
sample-bucket-01/0ddc/2024-07-20/customer-7/file6
...
```
4 文字の 16 進数ハッシュは、16⁴ (65,536) 通りの組み合わせとなり、最大 65,536 個のパーティションに対応できます。この数が十分であるかどうかは、リクエストレートとパーティションあたり毎秒 2,000 操作の制限に基づいて判断してください。

日付別にオブジェクトを一覧表示する (たとえば、sample-bucket-01 内の 2024-07-19 のすべてのオブジェクト) には、ListObject API をバッチで呼び出してバケット内のすべてのオブジェクトを一覧表示し、次に、目的の日付に一致する結果をマージします。
オブジェクトキーの反転

ミリ秒精度の UNIX タイムスタンプをオブジェクトキーとして使用することも、順次プレフィックスになります：
```
sample-bucket-02/1513160001245.log
sample-bucket-02/1513160001722.log
sample-bucket-02/1513160001836.log
sample-bucket-02/1513160001956.log
...
sample-bucket-02/1513160002153.log
sample-bucket-02/1513160002556.log
sample-bucket-02/1513160002859.log
...
```
順次的な順序を避けるために、タイムスタンプを反転します。反転した結果は次のようになります：
```
sample-bucket-02/5421000613151.log
sample-bucket-02/2271000613151.log
sample-bucket-02/6381000613151.log
sample-bucket-02/6591000613151.log
...
sample-bucket-02/3512000613151.log
sample-bucket-02/6552000613151.log
sample-bucket-02/9582000613151.log
...
```
最初の 3 桁はミリ秒 (1,000 通りの値) を表し、4 桁目は 1 秒ごと、5 桁目は 10 秒ごとに変わります。反転によりプレフィックスのランダム性が大幅に向上し、負荷が均等に分散され、ボトルネックを回避できます。

多数の小さなファイルに対するリクエストの削減

多数の小さなファイルをアップロードする場合、ZIP、TAR、または Parquet ファイルにパッケージ化して、複数のリクエストを 1 つにまとめます。たとえば、1 KB のファイルを 100 個、単一の ZIP ファイルにパッケージ化すると、100 回の PUT リクエストが 1 回に削減されます。

多数のオブジェクトを一覧表示するには、ListObjects の代わりに バケットインベントリ を使用して、CSV または Parquet 形式でオブジェクトリストを生成してください。詳細については、「バケットインベントリ」をご参照ください。

バイト範囲フェッチの使用

OSS から大きなファイル (100 MB 超) をダウンロードする際、ネットワークが不安定だと転送が中断される可能性があります。HTTP Range リクエストを使用してファイルの特定の部分をフェッチしてください：

Get /ObjectName HTTP/1.1
Host:examplebucket.oss-cn-hangzhou.aliyuncs.com
Date:Fri, 19 Jul 2024 17:27:45 GMT
Authorization:SignatureValue
Range:bytes=[$ByteRange]

Range ヘッダーは、0 から content-length - 1 の範囲内のバイト範囲を指定します。HTTP Rangeリクエストを使用してOSSリソースをセグメント単位で取得する方法。

OSS Transfer Acceleration の使用

Transfer Acceleration は、ギガバイトまたはテラバイト規模のファイルの長距離データ転送や、中国本土と他のリージョン間のクロスリージョンリクエストを高速化します。スマートルーティングを通じてリクエストを最寄りのポイントオブプレゼンス (POP) にルーティングし、エンドツーエンドの高速化を提供します。Transfer Accelerationを使用したOSSへのアクセス。

頻繁にアクセスされるコンテンツのキャッシュ

Alibaba Cloud CDN は、世界中のポイントオブプレゼンス (POP) で静的コンテンツをキャッシュします。ユーザーは最寄りの POP からコンテンツを取得するため、アクセス速度が向上し、オリジンの負荷が軽減されます。

リクエストされたファイルが POP にないか期限切れの場合、CDN はオリジンの OSS バケットからそれを取得してキャッシュします。オリジンのコンテンツが変更されると、CDN は自動的に POP のキャッシュを更新します。

これは、グローバルなユーザーベースを持つビジネスに特に役立ちます。CDNを使用したOSSへのアクセスの高速化。

同じリージョンでの OSS と ECS の使用

Elastic Compute Service (ECS) インスタンスと OSS バケットを同じリージョンにデプロイすると、データ転送のレイテンシーが削減され、読み取り速度が向上します。同一リージョン内の通信では内部エンドポイントが使用され、トラフィック料金は発生しないため、帯域幅のコストをかけずに大規模なデータ転送が可能です。「内部ネットワーク経由でのECSインスタンスからOSSリソースへのアクセス」をご参照ください。

レイテンシーの影響を受けやすいアプリケーションのためのタイムアウトリトライの実装

OSS は、管理 API (GetService、PutBucket、GetBucketLifecycle など) の QPS を制限します。リクエストレートが高い場合、HTTP 503 の低速化レスポンスがトリガーされる可能性があります。この場合、数秒待ってからリトライしてください。

単一の Alibaba Cloud アカウントの合計 QPS は 10,000 です。より高い上限をリクエストするには、テクニカルサポートにお問い合わせください。このしきい値を下回っていても、リクエストが単一のパーティションに集中し、その容量を超えた場合、サーバーがスロットリングを行い、503 エラーを返すことがあります。リクエストのプレフィックスをランダム化している場合 (「OSSのパフォーマンスと拡張性に関するベストプラクティス」をご参照ください)、OSS は自動的にパーティションをスケーリングして、より高い QPS をサポートします。待機してリトライするだけで済みます。

大きなリクエスト (128 MB 超) の場合は、スループットを測定し、最も遅い 5% をリトライしてください。小さなリクエスト (512 KB 未満) で、通常のレイテンシーが数十ミリ秒の場合は、2 秒後に GET または PUT 操作をリトライしてください。後続のリトライにはエクスポネンシャルバックオフを使用してください (たとえば、2 秒後、次に 4 秒後)。

固定サイズのリクエストで応答時間が一貫している場合は、最も遅い 1% を特定してリトライしてください。1 回のリトライで、多くの場合、レイテンシーが効果的に削減されます。

水平スケーリングと並列リクエストによる高スループットの実現

OSS は大規模な分散システムです。並列リクエストを水平スケーリングして、負荷を複数のネットワークパスに分散させてください。

複数のスレッドまたはインスタンスにまたがって、データを並列にアップロードおよびダウンロードしてください。最適なスケーリング戦略は、アプリケーションとオブジェクト構造によって異なります。

まず単一のリクエストで帯域幅とリソース使用量を測定し、そこから最大の同時リクエスト数を決定してください。たとえば、1 つのリクエストが CPU の 10% を使用する場合、最大 10 の同時リクエストをサポートできます。

ストレージ接続の水平スケーリング

OSS を単一のエンドポイントではなく、分散システムとして扱ってください。利用可能な帯域幅を最大化するために、異なる接続で複数の同時リクエストを送信してください。OSS はバケットへの接続数に制限を設けていません。

多数の小さなファイルを一括でアップロードするには、ossutil を -j 100〜500 の同時実行パラメータとともに使用し、OSS SDK のエクスポネンシャルバックオフリトライ戦略を組み合わせてスロットリングに対処してください。

リトライ回数の増加

リクエストが遅い場合は、リトライを送信してください。アプリケーションのフォールトトレランス要件に基づいて、OSS SDK でタイムアウトとリトライの値を設定してください。

Object Storage Service:OSS のパフォーマンスに関するベストプラクティス