OSSパフォーマンスのベストプラクティス - Object Storage Service

このトピックでは、Alibaba Cloud Object Storage Service (OSS) の分散アーキテクチャを使用して、データ処理を高速化し、データレイテンシを削減し、アプリケーションの応答時間を短縮する方法について説明します。このトピックは、OSSのパフォーマンスを最適化することを目的としています。

シーケンシャルプレフィックスをランダムプレフィックスに変更

データ分散を最適化し、処理効率を向上させるために、従来のシーケンシャルプレフィックスの代わりにランダムプレフィックスを使用してオブジェクトに名前を付けることを推奨します。 OSSは、オブジェクトのキーのUTF-8エンコード順序に基づいてデータを自動的にパーティション分割し、大規模なオブジェクト管理と同時実行性の高いリクエストをサポートします。ただし、タイムスタンプやアルファベット文字列などのシーケンシャルプレフィックスを使用すると、多数のオブジェクトがいくつかのパーティションに格納されます。

たとえば、1秒間に2,000回を超える操作を実行すると、次の問題が発生する可能性があります。オブジェクトのダウンロード、アップロード、削除、およびコピー、またはオブジェクトのメタデータの照会など、単一のオブジェクトに対して実行される操作は、要求としてカウントされ、複数のオブジェクトのダウンロードおよびリスト化など、複数のオブジェクトに対して実行される操作は、複数の要求としてカウントされる。

ホットスポットパーティションの生成: 特定のパーティション内のオブジェクトに対してリクエストが頻繁に開始され、これらのパーティションがホットスポットパーティションになります。その結果、パーティションのI/O容量が使い果たされるか、システムが自動的に要求レートを制限します。
限られたリクエストレート: OSSはホットスポットパーティション内のデータを継続的にパーティション分割し、パーティション間のデータの分散のバランスを取ります。このプロセスは、要求処理時間を増加させ得る。
説明
データの均等な分配は、システムの状態や処理能力の解析結果に基づいて行われる。キー内でシーケンシャルプレフィックスを使用するオブジェクトは、前の操作が実行された後にホットスポットパーティションに格納されてもよい。

これらの問題を解決するには、オブジェクトのキーのシーケンシャルプレフィックスをランダムプレフィックスに変更して、異なるパーティション間でオブジェクトインデックスと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ハッシュを使用できます。オブジェクト名のプレフィックスとして顧客IDの4文字のMD5ハッシュを使用すると、次の例に示すようにオブジェクトの名前が変更されます。
```
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
...
```
顧客IDの4文字の16進ハッシュをオブジェクト名のプレフィックスとして使用する場合、各文字は16の値 (0〜9およびa〜f) のいずれかになります。これにより、4文字の組み合わせの総数は65,536 (16 ⁴) となる。 OSSでは、最大65,536のパーティションにデータを継続的に配布できます。パフォーマンスのボトルネックに基づいて、各パーティションで1秒あたり最大2,000回の操作を実行できます。リクエストレートを使用して、オブジェクト名のプレフィックスとして使用する4文字のハッシュの数がビジネス要件を満たしているかどうかを判断できます。
sample-bucket-01という名前のバケットに2024-07-19文字列を含むオブジェクトなど、名前に特定の日付が含まれるオブジェクトをリストする場合は、ListObject操作を複数回呼び出してsample-bucket-01バケット内のオブジェクトをバッチでリストし、名前に指定された日付が含まれるオブジェクトをグループ化するだけです。
オブジェクト名のミリ秒を示す桁の順序を逆にする
ミリ秒単位の正確な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
...
```
この場合、UNIXタイムスタンプの数字の順序を逆にすることができます。このように、オブジェクト名は、シーケンシャルプレフィックスを含まない。数字の順序を逆にすると、次の例のようにオブジェクト名が表示されます。
```
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秒間隔で変化します。逆の操作は、プレフィックスのランダム性を増加させる。このようにして、要求は各パーティションに均等に分散され、パフォーマンスのボトルネックの問題を防ぎます。

HTTP Rangeリクエストを開始してオブジェクトの一部を取得

サイズが100 MBを超える大きなオブジェクトをOSSからダウンロードすると、ネットワーク環境が不安定なため、ダウンロード操作が失敗することがあります。オブジェクトの一部のみをダウンロードする場合は、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]

HTTPプロトコルの仕様に従って、Rangeリクエストヘッダーを設定して、ダウンロードするオブジェクトの範囲を指定できます。範囲は [0, content-length - 1] 以内である必要があります。詳細については、「HTTP範囲リクエストをセグメント化してOSSリソースを取得する方法」をご参照ください。

転送アクセラレーションの使用

転送アクセラレーションを有効にすると、バケット内のオブジェクトのアップロードとダウンロードを長距離で高速化できます。たとえば、中国本土にいる場合、中国本土の外部にあるバケットにオブジェクトをアップロードしたり、バケットからオブジェクトをダウンロードしたりするときに、転送アクセラレーションを有効にできます。このようにして、ギガバイトサイズおよびテラバイトサイズのオブジェクトのアップロードおよびダウンロードが加速される。転送アクセラレーション機能は、世界中に分散したデータセンターを備えた最適化されたエンドツーエンドのソリューションを提供し、インターネット経由のOSSへのアクセスを高速化します。この機能を有効にすると、バケット宛てのリクエストは、最適なネットワークパスとプロトコルを使用して、ユーザーに最も近いデータセンターにルーティングされます。詳細については、「転送アクセラレーション」をご参照ください。

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

OSSで頻繁にアクセスされるオブジェクトへのアクセスを高速化するには、Alibaba Cloud CDNの使用を推奨します。 Alibaba Cloud CDNは、世界中のPOP (Point of presence) に静的コンテンツをキャッシュします。最も近いPOPから静的コンテンツを取得できます。これにより、Webサイトのアクセス速度と安定性が向上します。

OSSでオブジェクトをリクエストすると、Alibaba Cloud CDNはまず、オブジェクトがPOPにキャッシュされているかどうかを確認します。オブジェクトがキャッシュされていないか、期限切れの場合、オブジェクトはOSSから要求され、近くのPOPにキャッシュされます。 OSSのオブジェクトが変更されると、Alibaba Cloud CDNはPOPのキャッシュを自動的に更新し、OSSとPOP間のデータの整合性を確保します。

上記のソリューションを使用すると、Alibaba Cloud CDNはOSSの負荷を効果的に軽減し、Webサイトのアクセス速度と安定性を向上させることができます。このソリューションは、ユーザーが世界中にいる企業に特に適しています。詳細については、「Alibaba Cloud CDNを使用したアクセスアクセラレーション」をご参照ください。

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

OSSとElastic Compute Service (ECS) を最大限に活用するには、ECSインスタンスとOSSバケットを同じリージョン内にデプロイすることを推奨します。この展開戦略は、データ送信のレイテンシを大幅に削減し、データ読み取り速度を向上させ、それによってアプリケーションの全体的なパフォーマンスを向上させることができます。 ECSインスタンスとOSSバケットが同じリージョンにあり、内部エンドポイントを使用して相互に通信する場合、内部ネットワークトラフィック料金は請求されません。この場合、ECSインスタンスとOSSバケット間で大量のデータを転送する場合、高いネットワーク帯域幅料金が請求されないため、全体的なコストが削減されます。詳細については、「OSSの内部エンドポイントを使用したECSインスタンスからのOSSリソースへのアクセス」をご参照ください。

タイムアウトリクエストを自動的に再試行するようにレイテンシに敏感なアプリケーションを設定する

OSSは、GetService (ListBuckets) 、PutBucket、GetBucketLifecycleなどの管理関連のAPI操作の1秒あたりのクエリ (QPS) を抑制します。アプリケーションが同時に多数のリクエストを開始した場合、リクエストスロットリングがトリガーされたことを示すHTTPステータスコード503が返される場合があります。この場合、数秒後にリクエストを再試行することをお勧めします。

単一のAlibaba Cloudアカウントの合計QPSは10,000です。より高いQPSが必要な場合は、お問い合わせくださいテクニカルサポート全体のQPSが10,000を超えず、要求が特定のパーティションに送信された場合、パーティションのI/O容量が使い果たされているため、サーバーは自動的に要求レートを制限し、HTTPステータスコード503を返す可能性があります。オブジェクト名のランダムなプレフィックスを使用して、オブジェクトインデックスとI/Oロードを異なるパーティション間で均等に分散する場合、OSSは自動的にパーティションの数を増やし、より高いQPSをサポートします。プロセスが完了するまで待つだけです。詳細については、「OSSパフォーマンスとスケーラビリティのベストプラクティス」をご参照ください。

サイズが128 MBを超えるオブジェクトなど、さまざまなサイズのオブジェクトに対して多数のリクエストを開始する場合は、スループットを測定して最も遅い5% のリクエストを再試行することを推奨します。ほとんどの場合、サイズが512 KB未満のオブジェクトの要求に対する応答は、数十ミリ秒以内に返されます。 GETまたはPUTリクエストを再試行する必要がある場合は、リクエストが送信されてから2秒後にリクエストを再試行することを推奨します。リクエストが複数回失敗した場合は、プログラムを閉じてリクエストを再試行することを推奨します。たとえば、リクエストが送信されてから2秒後にリクエストを再試行し、4秒後にリクエストを再試行できます。

同じサイズのオブジェクトに対してアプリケーションからリクエストが送信され、すべてのリクエストの応答時間を一致させたい場合は、最も遅い1% リクエストを特定して再試行することをお勧めします。この場合、リクエストのリトライ時にリクエストの応答時間を短縮することができる。

高スループットのために分散型で同時にリクエストを送信する

OSSは大規模な分散ストレージシステムです。 OSSのスループットを十分に活用するには、OSSに同時リクエストを送信し、複数のOSSサービスノードにリクエストを分散することを推奨します。これにより、複数のネットワークパスを使用してワークロードを分散できます。

データ送信中のスループットを向上させるために、複数のスレッドまたはインスタンスを作成し、スレッドまたはインスタンスで複数のリクエストを開始して、データを同時にアップロードおよびダウンロードすることを推奨します。特定のアプリケーションでは、異なるスレッドまたはインスタンスで複数のリクエストを開始して、同時にOSSにアクセスできます。アプリケーションのアーキテクチャとアクセスするオブジェクトの構造に基づいて、リクエストの配布方法を決定できます。

同時リクエスト数を変更する前に、パフォーマンスメトリックを確認する必要があります。 1回のリクエストで消費される帯域幅使用量やその他のリソースを最初に確認することをお勧めします。これにより、使用率が最も高いリソースを特定し、リソースの上限に基づいて処理できる同時リクエストの最大数を決定できます。たとえば、リクエストの処理に10% のCPUリソースが必要な場合、最大10個の同時リクエストを送信できます。

複数の接続にリクエストを配布する

アプリケーションの設計における高性能のために、要求を複数の接続に分配することが一般的である。高性能アプリケーションを開発する場合、従来のストレージサーバーなどの単一のストレージノードではなく、大規模な分散ストレージシステムとしてOSSを使用できます。アプリケーションのパフォーマンスを向上させるために、複数の同時リクエストをOSSに送信できます。リクエストを複数の接続に分散して、OSSが提供する帯域幅を完全に使用できます。 OSSでは、バケットへの接続数に制限はありません。

再試行の回数を増やす

最初にリクエストが送信されると、OSSはその規模が大きいため、リクエストに応答するのに長時間を要する場合があります。この場合、リクエストを再送信できます。 OSS SDKを使用して、業務要件に基づいてタイムアウト期間とリクエストの再試行許可回数を設定できます。

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