[セッションレポート]Maximizing Amazon S3 Performance #reinvent

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

re:Inventのセッション「Maximizing Amazon S3 Performance」を聞いてきたので、そのセッションレポートを書きました。

内容

リージョンの選択

  • どのリージョンでS3を作成するか、の検討基準
    • ユーザになるべく近いリージョン
    • その他のAWSリソースと近いリージョン
    • 保存されるデータがsensitiveなものの場合は法律上の規則も確認しておく必要がある

オブジェクトの命名

  • オブジェクトへのアクセスが100TPS(Transaction per Second)を超えるかどうか、がS3のアーキテクチャ上重要になる
  • S3のキーの先頭部分が同じだと、S3上で同一のパーティション上に保存されるアーキテクチャとなる。つまり、大量のファイルのキーの先頭部分が同じ場合は同じパーティションへのアクセスが集中するためパフォーマンスが落ちる。(例: 2014-01-01-photo.jpg, 2014-01-02-photo.jpg ...)
  • 回避策として、ランダムな文字列(4〜6文字)をキーにprefixとして付与するとよい。(例: 0aac-2014-01-01photo.jpg 39b3-2014-01-02.jpg ...)
  • またはepoch timeをprependしてもよい。ただしその場合はepoch timeを逆順にすること。(そうしないと同じパーティションに保持されてしまうため)
  • 100TPSを越える場合は上記の対策をしないとパフォーマンスが保証されない。
  • 詳細はドキュメントを参考にすること。

アップロード(PUT)の高速化

  • アップロード高速化のためには並列アップロードを検討すること。そうすることでボトルネックをS3からローカル部分に変えることができる。
  • 一般的には、アップロードマシンが広いN/W帯域を持っている場合は25MB-50MB、そうでない場合は10MB程度が分割の目安
  • SSLを利用する場合はCPUへの負荷が中心になりCPUがボトルネックになりがちなことにも注意する。
  • CPUへの負荷を軽減するため、要件次第ではSSLをOFFにし、SSE(AES-256)で暗号化するのを検討するのも選択肢の一つとしてあり。
  • アップロードするファイルのサイズ、マシンスペック、N/W帯域によって処理性能は大きく変わるので、必ず自身の環境でベンチマークを実施し、最適な分割数を見つけることが重要。

ダウンロード(GET,LIST)の高速化

  • 単純ダウンロードの場合はCloudFrontの利用も検討する
  • LIST処理を頻繁に利用する場合は、メタデータをDynamoに保存する方が効率的。ファイルの存在確認のためにLISTを流すのは結構コストが高いため。
  • ダウンロードもRange Accessを利用して並列化することが可能。こちらもダウンロードと同じく、必ず自身の環境、対象のデータオブジェクトに対してのベンチマークを実施すること。

まとめ

S3のprefixを分散させるという話はドキュメントにも記載されていますが、あまり知られていないTIPSなのではないかと思います。分散DownloadやSSLの話など、S3のパフォーマンス向上させるために打てる手は様々あります。ただセッション内でも「自分の環境でテストすること」という点をかなり強調していたので、自身の環境でS3が遅い、ということを感じている方は、セッションで触れられているTIPS一度試されてはいかがでしょうか。