クラウドストレージ比較まとめ (Amazon S3・Azure Storage・Google Cloud Storage)

前へ << クラウド サーバレスコンピューティング比較まとめ (AWS Lambda・Azure Functions・Cloud Functions) クラウド リレーショナル・データベース比較 (Amazon RDS・Azure SQL Database・Google Cloud SQL) >> 次へ

目次

Amazon S3 と Azure Storage と Google Cloud Storage

そもそも、クラウド以前のホスティングサービスや VPS においては、 サーバ内部のハードディスクとしてストレージが用意されていました。

しかしながら複数サーバでのストレージ共有における性能や、 ストレージ障害時のフェイルオーバーやバックアップについて、簡単と言える方法はありませんでした。 単一障害点を作らないために、ディスクの冗長化はもちろん、スイッチ・監視の冗長化も必要であり、 真面目にやるならお高い機器を購入し、結構なお値段のベンダに設計・設定を依頼する必要があったのです。

2006年に Amazon より S3 がリリースされました。主な特徴は下記です。

  • 使った分だけ課金
  • 専用 SDK、専用 API にて操作する
  • 自動的にバックアップを生成
  • 容量無制限
現在では Azure・GCP 各社も似たような特徴を持つストレージサービスを展開しています。 3大クラウドサービスについて、下記のストレージを比較していきましょう。
  • Amazon S3 (Amazon Simple Storage Service)
  • Azure Blob Storage
  • Google Cloud Storage

オブジェクトストレージの特徴

Amazon S3・Azure Blob Storage・Google Cloud Storage などのストレージサービスを、 ここでは「オブジェクトストレージ」と呼ぶことにします。 これはオブジェクトという「ファイル的なモノ」を配置するのに特化したストレージです。

一方で「ファイルストレージ」というものがあります。 これはいわゆる Linux・Windows でよく使われる、 ext4 や NTFS などのファイルシステムを持ったストレージです。

「オブジェクトストレージ」と「ファイルストレージ」の違いは何か。 明確な定義があるわけではないので、全体的な傾向ではありますが、 下記のような制約・制限があると考えます。

  • 単純性。オブジェクト、つまりファイルしかない。ディレクトリ・シンボリックリンク・ハードリンク・デバイスファイル・名前付きパイプなどは存在しない。
  • 単純性。シンプルな操作。例えばオブジェクトへの追記ができない。できるのは GET・PUT・DELETE・RENAME 程度。
  • 単純性。ディレクトリ階層構造の排除。/usr や c:\windows といったディレクトリ・フォルダという概念がない。ぱっと見では /mybacket/dir/subdir/file.txt などと階層構造があるように見えるが、実際はオブジェクト名に "/" が使えるというだけ。
  • 低性能。基本的には遅い。

このような制約・制限をかけてでも欲しかったものは下記です。

  • 拡張性。サイズは無制限。ネットワークの向こう側には数万台・数十万台・数百万台のストレージがある。
  • 冗長性。二重・三重の冗長化。しかし RAID を使わず単純性は維持 (推測)
  • 安価。SSD は使わず HDD を使っている (推測)。

オブジェクトストレージサービス機能比較

オブジェクトストレージサービスの機能を比較します。

- Amazon S3 Azure Blob Storage Google Cloud Storage
ストレージ料金 (東京・1ヶ月あたり・2018/2 調査) $0.025/GB 2.24円/GB $0.023/GB
GET 料金 (東京・2018/2 調査) $0.0037/10,000リクエスト 0.45円/10,000リクエスト $0.004/10,000リクエスト
転送量 (東京・2018/2 調査) $0.14/GB 13.44円/GB $0.14/GB
上限・制限
- Amazon S3 Azure Blob Storage Google Cloud Storage
ストレージ全体容量上限 無制限 実質無制限? (200ストレージアカウント×500TB/ストレージアカウントだが、上限引き上げ申請可能) 無制限 (多分)
オブジェクト数上限 無制限 無制限 無制限
1オブジェクト容量上限 5TB 4.77TB 5TB
機能・管理
- Amazon S3 Azure Blob Storage Google Cloud Storage
リージョン 作成時に決定 作成時に決定 作成時に決定
レプリケーション クロスリージョンレプリケーション (CRR) ゾーン冗長ストレージ (ZRS), geo 冗長ストレージ (GRS), 読み取りアクセス geo 冗長ストレージ (RA-GRS) Regional, Multi-Regional
バージョニング ×
ライフサイクル管理 ×
アクセスログ
Web 公開
- Amazon S3 Azure Blob Storage Google Cloud Storage
Webでの公開
Webでの公開 - IP アドレス制限 ◯ Shared Access Signature (SAS)
Webでの公開 - 期限付き公開 ?
Webでの公開 - リダイレクト ? ?
Webでの公開 - 認証 × × ×
Webでの公開 - SSL
連携
- Amazon S3 Azure Blob Storage Google Cloud Storage
イベント駆動 ◯ (AWS Lambda) ◯ (Azure Functions) ◯ (Cloud Functions)
マウント FUSE (s3fs, goofys) FUSE FUSE
SQLでオブジェクト内部を検索 Amazon Athena, S3 Select, Glacier Select × ×
他ストレージとの連携 前述の クロスリージョンレプリケーション (CRR) なし S3・GCS・URL リスト から取得し、GCS に保存
DWH エンジンからの検索 ロード、Amazon Redshift Spectrum ロードのみ ロードのみ
アップロード
- Amazon S3 Azure Blob Storage Google Cloud Storage
高速アップロード S3 Transfer Acceleration, Tsunami UDP
大規模データアップロード AWS Snowball, AWS Snowball Edge, AWS Snowmobile Azure Data Box Google Transfer Appliance
操作
- Amazon S3 Azure Blob Storage Google Cloud Storage
管理画面からのオブジェクト操作 一覧・表示・ダウンロード・アップロード・フォルダアップロード 一覧・表示・ダウンロード・アップロード・フォルダアップロード
クライアント CloudBerry Explorer, WinSCP, Cyberduck Azure Storage Explorer, CloudBerry Explorer CloudBerry Explorer, Cyberduck, CrossFTP
注意点
- Amazon S3 Azure Blob Storage Google Cloud Storage
性能上の注意点 先頭ハッシュ推奨 先頭ハッシュ推奨 先頭ハッシュ推奨

詳細説明

ストレージ料金

- Amazon S3 Azure Blob Storage Google Cloud Storage
ストレージ料金 (東京・1ヶ月あたり・2018/2 調査) $0.025/GB 2.24円/GB $0.023/GB
GET 料金 (東京・2018/2 調査) $0.0037/10,000リクエスト 0.45円/10,000リクエスト $0.004/10,000リクエスト
転送量 (東京・2018/2 調査) $0.14/GB 13.44円/GB $0.14/GB

ストレージ料金は各サービスとも同じような考え方です。さらにおおむね同一の価格帯となっています。

  • ストレージ料金 … オブジェクトを置いておくと費用がかかる。10GB 置くと おおむね 22〜27円/月。
  • リクエスト料金 … GET や PUT をするたびにかかる費用。100万回の GET でおおむね 40〜45円。
  • データ転送料金 … クラウド外にデータを転送した際にかかる費用。100GB ダウンロードするとおおむね 1,304〜1,540円。

ストレージ全体容量上限

- Amazon S3 Azure Blob Storage Google Cloud Storage
ストレージ全体容量上限 無制限 実質無制限? (200ストレージアカウント×500TB/ストレージアカウントだが、上限引き上げ申請可能) 無制限 (多分)

ストレージ全体の容量制限について、Amazon S3 は「無制限」とうたっています。 Azure は制限がありますが、引き上げ申請が可能なので実質無制限と言っていいでしょう。 Google Cloud Storage は無制限とは書いてないのですが、制限があるとも書いてないので、おそらくは無制限です。

オブジェクト数上限

- Amazon S3 Azure Blob Storage Google Cloud Storage
オブジェクト数上限 無制限 無制限 無制限

オブジェクト (≒ファイル) 数の上限はありません。

1オブジェクト容量上限

- Amazon S3 Azure Blob Storage Google Cloud Storage
1オブジェクト容量上限 5TB 4.77TB 5TB

1つのオブジェクト (≒ファイル) の容量上限は、各サービスともおおむね 5TB 前後です。 とはいえテラバイトクラスのファイルは、例えばアップロード・ダウンロード時を考えると 大変扱いづらいでしょうから、アプリケーション側で GB 程度に分割しておいた方がよい気がします。

ちなみに、Amazon S3 は 2010年に 5GB → 5TB の引き上げました。 Azure Blob Storage は 2017年に 195GB → 4.77TB に引き上げました。

機能・管理

リージョン

- Amazon S3 Azure Blob Storage Google Cloud Storage
リージョン 作成時に決定 作成時に決定 作成時に決定

オブジェクトを作成する際、どのリージョンに置くかを決める必要があります。 将来的にどうなるかわかりませんが、2018/05 現在ではオブジェクトストレージはリージョン依存なサービスということです。

レプリケーション

- Amazon S3 Azure Blob Storage Google Cloud Storage
レプリケーション クロスリージョンレプリケーション (CRR) ゾーン冗長ストレージ (ZRS), geo 冗長ストレージ (GRS), 読み取りアクセス geo 冗長ストレージ (RA-GRS) Regional, Multi-Regional

ややこしいのでひとつずつ見ていきましょう。

Amazon S3 の クロスリージョンレプリケーション (CRR) について。 これはバケット A に行われた操作を、バケット B にて同じことをする、というレプリケーションです。 同期設定がなされているものの、バケット B は普通の S3 なので、バケット B に対して直接操作することは可能です。 つまり、バケット A・B は疎結合です。

また、バケット A が機能停止した場合、AWS が自動的にバケット B につないでくれる、ということはありません。 災害対策時に向き先を変えるのはアプリケーション側の仕事です。

Azure の geo 冗長ストレージ (GRS) は、データセンタやリージョン (東日本など) が機能停止しても、 データが失われないということです。東日本を使っている場合、Azure にて西日本にデータを同期しています (東日本は西日本に同期、西日本は東日本に同期、というのがあらかじめ決まっています)。 通常運用時はデータ同期先にアクセスすることはできません。 天災などによりデータセンタやリージョンがアクセス不能となり、 同期先に切り替えるとなった場合、マイクロソフトが切り替え作業を行います。 アプリケーション側は、接続先を変更する必要はありません、 同期先への切り替えは全てマイクロソフトが行うため、災害時に備えたフェイルオーバーなどの試験がしづらいのが欠点です。

読み取りアクセス geo 冗長ストレージ (RA-GRS) は、GRS に加えて、同期先へのアクセスを許すものですが、ただし読み取り専用です。 また、障害発生時にマイクロソフトが同期先へ切り替え作業を行う際、一時的に同期先へのアクセスもできなくなります。

GCP の「Regional Storage」は、リージョン内 (例えば東京リージョン) でデータを複製するものです。 ラックやデータセンタという単位での障害には耐性がありますが、東京リージョン全体がつぶれたらアクセス不可となります。

一方、GCP の「Multi-Regional Storage」は、複数リージョンでの複製を可能とするもので、 例えばシンガポールと香港、といった感じでデータが同期されます。

GCP の場合、「Regional Storage」「Multi-Regional Storage」いずれも、同期先へのアクセスは一切不可で、障害発生時の対応も公開されていないようです。 当ページ管理人の推測ですが、「すべて Google がよきにはからうので、アプリケーション側は何もしなくてよい」という世界を目指しているのではと感じます。

以下、まとめです。

  • 単にバックアップを保持するというだけなら簡単なのですが、災害時のサービス継続まで行くと考えなくてはならないことが増えてきます。
  • Amazon S3 は、単純な同期機能であり、サービス継続にあたっての接続先変更はアプリケーション側の仕事です。これはこれである意味単純であり、障害時の試験もやりやすいでしょう。
  • GCP の Cloud Storage は、(おそらく) 全部 Google におまかせであり、障害時の試験はできないものの、「Google さんあとはよろしく」という単純さがあります。
  • 微妙なのは Azure Blob Storage で、リージョン切り替えのタイミングはマイクロソフトまかせであり、過去 Storage 障害があったときもリージョン切り替えが行われたことは一度もないはず。 そして事前の試験もできない。RA-GRS は読み取りしかできず、障害時のサービス継続という意味では機能不足。となると、アプリケーションレベルで定期的に別ストレージにコピーした方がよいのでは? と思ってしまいます。

バージョニング

- Amazon S3 Azure Blob Storage Google Cloud Storage
バージョニング ×

Amazon S3 と Google Cloud Storage にはバージョニングという機能があります。 バージョニングとは、削除または上書き更新したオブジェクト (≒ファイル) にアクセスできるようにする、いわば自動バックアップ機能です。

オブジェクトの更新や削除をするたびに id=1111111, id=11222222 などのバージョン値が自動的に割り振られます。 このバージョン値を指定してオブジェクトを取り出すことで、古いオブジェクトや削除前のオブジェクトを取得することができます。 バージョンを指定せずにオブジェクトを取得した場合は最新版が取得できますので、 アプリケーション側では特に注意することはありません。

注意点としては、それぞれのバージョンごとにストレージ費用がかかることです。 1MB のオブジェクトを更新し続けて 10バージョンになったら、10MB 分の請求ということです。 ただし Amazon S3・Google Cloud Storage いずれもデフォルトではバージョニングが無効化されており、 バケットやオブジェクトを指定してバージョニングを有効化する必要がありますので、知らぬ間に費用がかさんでいたということはそれほど心配する必要はないでしょう。 さらに、Amazon S3・Google Cloud Storage いずれもライフサイクル設定により、N世代前のバージョンを削除といった定義もできます。

Azure Blob Storage にはバージョンニング機能はないようですので、バックアップ用途としてはスナップショットを使うことになるでしょう。

ライフサイクル管理

- Amazon S3 Azure Blob Storage Google Cloud Storage
ライフサイクル管理 ×

アクセスログ

- Amazon S3 Azure Blob Storage Google Cloud Storage
アクセスログ

Web での公開

Webでの公開

- Amazon S3 Azure Blob Storage Google Cloud Storage
Webでの公開

ストレージに配置したファイルは、 Web で公開することができます (公開しないこともできます)。 例えば Amazon S3 であれば、

  • http://mybucket.s3.amazonaws.com/hoge.html のような URL で HTML ファイル
  • http://mybucket.s3.amazonaws.com/hoge.png のような URL で画像ファイル

を配置できます。動的な Web システムは無理ですが、静的 Web コンテンツであればだいたいは大丈夫です。

Webでの公開 - IP アドレス制限

- Amazon S3 Azure Blob Storage Google Cloud Storage
Webでの公開 - IP アドレス制限 ◯ Shared Access Signature (SAS)

Webでの公開 - 期限付き公開

- Amazon S3 Azure Blob Storage Google Cloud Storage
Webでの公開 - 期限付き公開 ?

Webでの公開 - リダイレクト

- Amazon S3 Azure Blob Storage Google Cloud Storage
Webでの公開 - リダイレクト ? ?

Webでの公開 - 認証

- Amazon S3 Azure Blob Storage Google Cloud Storage
Webでの公開 - 認証 × × ×

Amazon S3・Azure Blob Storage・Google Cloud Storage とも、 Web で公開する際に、Basic 認証や Digest 認証は使用できないようです。

Webでの公開 - SSL

- Amazon S3 Azure Blob Storage Google Cloud Storage
Webでの公開 - SSL

連携

イベント駆動

- Amazon S3 Azure Blob Storage Google Cloud Storage
イベント駆動 ◯ (AWS Lambda) ◯ (Azure Functions) ◯ (Cloud Functions)

ストレージ上のオブジェクトを更新したら、何かしらの処理を行いたい場合があります。 例として「画像ファイルをアップロードするとサムネイル画像を生成する」があげられます。 その他、Slack 等のチャットツールにメッセージを投げたり (例えば「バックアップファイル配置完了!」とか)、別サーバにコピーしたり、もありがちかもしれません。 そういう場合、下記のサーバレスコンピューティングなサービスを使うことで実現が可能です。

マウント

- Amazon S3 Azure Blob Storage Google Cloud Storage
マウント FUSE (s3fs, goofys) FUSE FUSE

オブジェクトストレージはマウントして使うものではありませんが、 それでもどうしてもマウントしたい場合もあります。 そのような場合に使える、マウントするツールがあります。

まず基礎知識として、UNIX/Linux には FUSE (Filesystem in Userspace) というオープンソースのソフトウェアがあります。 以前は root 権限が必要であったマウントを一般ユーザにて行えるようにするというものです。 アダプタというものを開発するだけで、さまざまなファイルシステムに対応できます。 FUSE は Linux・FreeBSD・macOS 等で利用可能です。

AWS の場合、2008年より s3fs というオープンソースソフトウェアがありましたが、 2013年に FUSE ベースのアダプタ s3fs-fuse に移行しました。 s3fs-fuse はどうやら速度が遅いらしく、goofys というこちらも FUSE ベースのアダプタが存在します。 操作内容にもよりますが、goofys は s3fs-fuse の 10〜100倍速いとのこと。

Azure Blob Storage をマウントするものとして、FUSE のアダプタ blobfuse があります。

Google Cloud Storage をマウントするものとして、FUSE のアダプタ gcsfuse があります。 これは Google にて開発されたものですが、コミュニティベースでオープンソースとして開発が続けられています。

SQLでオブジェクト内部を検索

- Amazon S3 Azure Blob Storage Google Cloud Storage
SQLでオブジェクト内部を検索 Amazon Athena, S3 Select, Glacier Select × ×

他ストレージとの連携

- Amazon S3 Azure Blob Storage Google Cloud Storage
他ストレージとの連携 前述の クロスリージョンレプリケーション (CRR) なし S3・GCS・URL リスト から取得し、GCS に保存

他ストレージとの連携機能についてです。

Amazon S3 では前述の「クロスリージョンレプリケーション (CRR)」が使えます。

Google Cloud Storage では、"Storage Transfer Service" という名称で、 他のストレージからの一括取得・定期取得ができるようになっています (他ストレージからの取得であって、他ストレージへの送信ではありません)。 転送元は GCS・Amazon S3・URL リスト から選択可能ですが、 転送先は GCS のみです。

なお、URL リストとは、下記のように各ファイルの URL・ファイルサイズ・MD5 チェックサム (を BASE64 化したもの) からなる TSV ファイルです。

TsvHttpData-1.0
https://example.com/buckets/obj1      1357      RbZHOOIY2a1CnPuc8ZOY0Q==
https://example.com/buckets/obj2      2468      xSe8XGGbDbSChLw6VU7

"Storage Transfer Service" には下記のような便利機能があります (無効にすることもできます)。

  • N 時間以内に配置されたファイルのみを対象とする (つまり古いファイルは転送しない)
  • 転送完了したら転送元から削除する
  • 転送元にないファイルは転送先からも削除する

実行方法はその場限りの一度実行か、毎日N時M分に実行、という 2パターンです。

なお、以下のように機能面・運用面いずれも欠点があります。

  • s3://frombucket/dir/file.txt を gs:///tobucket/from-s3/dir/file.txt に、などとパスを変更 (この例では先頭に from-s3 を追加) したり、ファイル名をいじったりはできない。
  • 取得したファイルの保存時に Content-Type などのメタデータ設定などはできない。
  • 取得したファイルの保存時に Nearline・Coldline 設定などはできない。
  • 一度実行した転送設定を再実行することはできない。
  • 毎日実行は文字通り「毎日N時M分」実行であり、毎分とか毎時の設定はできない。
  • 毎日実行で登録した「N時M分」は変更できない。
  • 毎日実行で登録した場合、即時実行ができない (設定後にお試しで一度動かすということができない)。

上記の機能不足の点は、オブジェクト配置後に Cloud Functions を実行してパス名変換をするなどの手もあります。 しかし運用面の欠点はいかんともしがたいので、GCE・GAE などから gsutil rsync などを呼んだ方がよいかもしれません。 なお、本機能を使うとことで、コピーする際のコンピューティング (GCE など) のリソースが不要というのがメリットです。

DWH エンジンからの検索

- Amazon S3 Azure Blob Storage Google Cloud Storage
DWH エンジンからの検索 ロード、Amazon Redshift Spectrum ロードのみ ロードのみ

データウェアハウス (DWH) からストレージに置いてあるオブジェクトを利用する方法についてです。

Amazon Redshift・Azure SQL Data Warehouse・Google BigQuery いずれも、ストレージに置いてあるオブジェクトをロードする (取り込む) ことは簡単にできます。

さらに Amazon Redshift には Amazon Redshift Spectrum という機能があり、 該当テーブルをリクエストすると、定義されているストレージを読みに行く、という処理ができます。 クラウド データウェアハウス比較まとめ を参照してください。

アップロード

高速アップロード

- Amazon S3 Azure Blob Storage Google Cloud Storage
高速アップロード S3 Transfer Acceleration, Tsunami UDP

大規模データアップロード

- Amazon S3 Azure Blob Storage Google Cloud Storage
大規模データアップロード AWS Snowball, AWS Snowball Edge, AWS Snowmobile Azure Data Box Google Transfer Appliance

ローカルにあるファイルサーバや既存データセンタにファイルがあるとして、クラウドにアップロードする場合、 ギガバイトクラスであれば何ら問題ありませんが、テラバイト・ペタバイトになると、 アップロードに何日かかるのかというのが大問題になってきます。

仮にデータセンタにて 100Mbps の帯域を契約している場合、100Mbps が文字通り「秒間 100メガビット」であったとしても、 月間で 30TB 程度です。実際は秒間 100メガビットなんて出ませんし、上位回線は共用回線であったり、 既存システムのネットワークに影響が出るから全速力で転送可能なのは深夜〜早朝のみにしてほしいとか、 いろいろな制約があります。

特に過去の膨大なログ・画像ファイル・動画ファイルなどをオンプレミスからクラウドに持っていこうとする場合、 この手の問題が発生しがちです。

そこでクラウド各社は、物理的なハードディスクを送りつけて、利用者にデータをコピーしてもらい、 利用者がクラウド各社に返送し、クラウド各社がストレージにアップロードする、というサービスを展開しています。 もちろん物理的な往復がありますのでその分時間はかかりますが、それでもトータルとしては早い、ということですね。

各社が展開しているサービスは以下のとおりです。

  • AWS Snowball: 容量 80TB。タワー型。東京で利用可。
  • AWS Snowball Edge: 容量 100TB。タワー型。Snowball はディスクのみであるが、Snowball Edge はディスク + コンピュータであるため、 NFS 接続・Lambda 実行・Snowball Edge 複数台でのクラスタリング等、より賢いことが行える。東京で利用可。
  • AWS Snowmobile: 最大容量 100PB。東京で利用可。
  • Azure Data Box: 容量 100TB。タワー型。2018/5 現在ベータで、東日本・西日本では利用不可。
  • Google Transfer Appliance: 容量 100TB または 480TB。2U または 4U のラックマウント型。2018/5 現在ベータで、米国のみ利用可。

2018/5 現在では、AWS の Snowball・Snowball Edge・Snowmobile 3兄弟は AWS 東京リージョンで対応していますが、 Azure Data Box・Google Transfer Appliance は日本ではまだ使えないようです。 なお、AWS Snowmobile は、長さ 13m、高さ 3m のコンテナが大型トラックで運ばれてくるという豪快なサービスなのですが、 いつの間にか日本でも利用可能となっています。ほんとにトラックが来るんでしょうか。

AWS Snowball・Snowball Edge の体験談は下記にありますが、あまりうまくいった感がないところが興味深いです。 「どんなトラブルにめぐりあえるか楽しみ!」という気持ちで立ち向かうのがいいのかもしれません。

AWS Snowball Edgeが我が家にやってきた。
個人利用目的で Snowball Edge を使用。マルチバイト文字に対応しておらず、目的を達成できないまま返品というオチ。
AWS Snowballことはじめ パート1〜5
クラスメソッド社によるレポート。Snowball が届いたところまでで、その後続報なし。 トラブルがあって続報が書けなくなったのか、単に飽きただけなのか。

操作

管理画面からのオブジェクト操作

- Amazon S3 Azure Blob Storage Google Cloud Storage
管理画面からのオブジェクト操作 一覧・表示・ダウンロード・アップロード・フォルダアップロード 一覧・表示・ダウンロード・アップロード・フォルダアップロード

クライアント

- Amazon S3 Azure Blob Storage Google Cloud Storage
クライアント CloudBerry Explorer, WinSCP, Cyberduck Azure Storage Explorer, CloudBerry Explorer CloudBerry Explorer, Cyberduck, CrossFTP

注意点

性能上の注意点

- Amazon S3 Azure Blob Storage Google Cloud Storage
性能上の注意点 先頭ハッシュ推奨 先頭ハッシュ推奨 先頭ハッシュ推奨

Amazon S3 ではオブジェクト (≒ファイル) の名前によりパーティションが決まるため、 先頭部分が似通ったオブジェクトを大量に使用するとパフォーマンスに影響が出ると説明しています。

例えば下記はよくない例。2013-26-05-15-00-00 という同じ文字列で始まるオブエジェクトが大量にあります。

examplebucket/2013-26-05-15-00-00/cust1234234/photo1.jpg
examplebucket/2013-26-05-15-00-00/cust3857422/photo2.jpg
examplebucket/2013-26-05-15-00-00/cust1248473/photo2.jpg
examplebucket/2013-26-05-15-00-00/cust8474937/photo2.jpg

下記は先頭に4桁16進数のハッシュ値を設定したおすすめの例。ハッシュの生成には CRC32 や MD5 などの軽量なチェックサム関数やハッシュ関数を使うとよいでしょう。

examplebucket/232a-2013-26-05-15-00-00/cust1234234/photo1.jpg
examplebucket/7b54-2013-26-05-15-00-00/cust3857422/photo2.jpg
examplebucket/921c-2013-26-05-15-00-00/cust1248473/photo2.jpg
examplebucket/ba65-2013-26-05-15-00-00/cust8474937/photo2.jpg

Azure Blob Storage・Google Cloud Storage も、全く同じで、先頭にハッシュ値設定を勧めています。

前へ << クラウド サーバレスコンピューティング比較まとめ (AWS Lambda・Azure Functions・Cloud Functions) クラウド リレーショナル・データベース比較 (Amazon RDS・Azure SQL Database・Google Cloud SQL) >> 次へ

ご意見・ご指摘は Twitter: @68user までお願いします。