Amazon S3 のパフォーマンスのガイドライン
Amazon S3 に対してオブジェクトのアップロードや取得を行うアプリケーションを作成する場合は、ベストプラクティスガイドラインに従ってパフォーマンスを最適化してください。また、より詳細な「Amazon S3 のパフォーマンスの設計パターン 」も提供しています。
アプリケーションで Amazon S3 の最適なパフォーマンスを得るために、以下のガイドラインを推奨しています。
トピック
パフォーマンスを測定する
パフォーマンスを測定する際、ネットワークスループット、CPU、および DRAM の要件を確認してください。これらのさまざまなリソースの要件の組み合わせに応じて、さまざまな Amazon EC2 インスタンスタイプを評価することをお勧めします。インスタンスタイプの詳細については、「Amazon EC2 ユーザーガイド」の「インスタンスタイプ」を参照してください。
これは、パフォーマンスの測定時に HTTP 分析ツールを使用して DNS ルックアップ時間、レイテンシー、およびデータ転送速度を確認する際にも役立ちます。
パフォーマンス要件を理解し、アプリケーションのパフォーマンスを最適化するために、受け取った 503 エラーレスポンスをモニタリングすることもできます。特定のパフォーマンスメトリクスのモニタリングには、追加費用が発生する場合があります。詳細については、「Amazon S3 の料金
503 (Slow Down) ステータスエラーレスポンスの数のモニタリング
503 のステータスエラーレスポンス数をモニタリングするには、次のいずれかのオプションを使用できます。
Amazon S3 に対する Amazon CloudWatch リクエストメトリクスの使用 CloudWatch リクエストメトリクスには、5xx ステータスレスポンスのメトリクスが含まれています。CloudWatch リクエストメトリクスの詳細については、「Amazon CloudWatch によるメトリクスのモニタリング」を参照してください。
Amazon S3 ストレージレンズの [高度なメトリクス] セクションにある 503 (Service Unavailable) エラー数を使用してください。詳細については、「S3 ストレージレンズのメトリクスを使用してパフォーマンスを改善する」を参照してください。
Amazon S3 サーバーアクセスロギングの使用 サーバーアクセスログを使用すると、503 (Internal Error) レスポンスを受け取ったすべてのリクエストをフィルタリングして確認できます。Amazon Athena を使用して、ログを解析することもできます。サーバーアクセスログ記録の詳細については、「サーバーアクセスログによるリクエストのログ記録」を参照してください。
HTTP 503 ステータスエラーコードの数をモニタリングすることで、どのプレフィックス、キー、またはバケットが最もスロットリングリクエストを受け取っているかについて、貴重な分析情報を得られることがよくあります。
ストレージ接続を水平にスケールする
多くの接続間にリクエストを分散することが、パフォーマンスを水平にスケールする一般的な設計パターンです。パフォーマンスの高いアプリケーションを作成するには、Amazon S3 を従来のストレージサーバーのような 1 つのネットワークエンドポイントではなく、非常に大きな分散システムと考えます。最適なパフォーマンスは、複数の同時リクエストを Amazon S3 に発行することで実現できます。これらのリクエストを別々の接続に分散して、Amazon S3 の利用可能な帯域幅を最大化します。Amazon S3 には、バケットへの接続数に制限はありません。
バイト範囲のフェッチを使用する
GetObject リクエストで HTTP ヘッダーの Range
を使用すると、オブジェクトのバイト範囲をフェッチして指定した部分のみを転送できます。Amazon S3 への同時接続を使用して、同じオブジェクトのさまざまなバイト範囲をフェッチできます。これにより、単一のオブジェクト全体のリクエストに対して高い集約スループットを実現できます。大きなオブジェクトの小さい範囲をフェッチすると、リクエストの中断時にアプリケーションで再試行回数の向上が可能になります。詳細については、「オブジェクトのダウンロード」を参照してください。
バイト範囲リクエストの標準的なサイズは 8 MB または 16 MB です。マルチパートアップロードを使用してオブジェクトを PUT する場合、最適なパフォーマンスのために同じパートサイズで (少なくともパート境界に沿って整列されている) それらのオブジェクトを GET することをお勧めします。GET リクエストは、個々のパートを直接アドレス指定できます (例えば、GET ?partNumber=N.
)。
レイテンシーの影響を受けやすいアプリケーションのリクエストを再試行する
積極的なタイムアウトと再試行は、一定のレイテンシーの促進に役立ちます。Amazon S3 を大規模に利用している場合、最初のリクエストが遅くても、再試行のリクエストでは別のパスを選択してすぐに成功することがあります。AWS SDK には、特定のアプリケーションの許容値に調整できる設定可能なタイムアウト値と再試行値があります。
同じ AWS リージョンで Amazon S3 (ストレージ) と Amazon EC2 (コンピューティング) を組み合わせる
S3 のバケット名はグローバルに一意ですが、各バケットはバケットの作成時に選択したリージョンに保存されます。バケットの命名ガイドラインの詳細については、「バケットの概要」および「バケットの命名規則」を参照してください。パフォーマンスを最適化するには、可能であれば、同じ AWS リージョン の Amazon EC2 インスタンスからバケットにアクセスすることをお勧めします。これにより、ネットワークレイテンシーとデータ転送費用を低減できます。
データ転送費用の詳細については、「Amazon S3 の料金
Amazon S3 Transfer Acceleration を使用して距離によるレイテンシーを最小限に抑える
Amazon S3 Transfer Acceleration を使用した高速かつ安全なファイル転送の設定 は、クライアントと S3 のバケットの長距離間の高速、簡単、安全なファイル転送を管理します。Transfer Acceleration は、Amazon CloudFront の世界中に点在するエッジロケーションを利用します。エッジロケーションに到着したデータは、最適化されたネットワークパスで Amazon S3 にルーティングされます。Transfer Acceleration は、大陸間で定期的にギガバイトからテラバイト単位のデータを転送するのに最適です。また、中央のバケットに対して世界中のお客様からアップロードが行われるクライアントにも役立ちます。
Amazon S3 Transfer Acceleration の速度比較ツール
最新バージョンの AWS SDK を使用する
AWS SDK では、Amazon S3 のパフォーマンスの最適化のために推奨されている多くのガイドラインが組み込みでサポートされています。SDK では、アプリケーションから Amazon S3 を利用するためのシンプルな API が提供されており、最新のベストプラクティスに従うように定期的に更新されます。例えば、SDK には、HTTP 503 エラーでリクエストを自動的に再試行するロジックが含まれており、遅い接続に応答して適用するためにコードに投資しています。
また、SDK では Transfer Manager も提供されています。これは、接続の水平スケーリングを自動化し、必要に応じてバイト範囲のリクエストを使用して 1 秒あたりに数千ものリクエストを実現します。最新バージョンの AWS SDK を使用して最新のパフォーマンス最適化機能を取得することが重要です。
また、HTTP REST API リクエストを使用している場合は、パフォーマンスを最適化することもできます。REST API を使用する際、SDK の一部である同じベストプラクティスに従う必要があります。オブジェクトデータを同時フェッチできるように、リクエストが遅い場合のタイムアウトと再試行、および複数の接続を可能にしてください。REST API の使用については、Amazon Simple Storage Service API Reference を参照してください。