クラウドストレージ比較解説まとめ

最終更新 2019-04-21

Amazon S3・Azure Storage・Google Cloud Storage について、機能・料金などから比較を行います。

2019/04/21: 大規模データアップロードに Azure Data Box Disk、Azure Data Box Heavy を追加。

オブジェクトストレージとは

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

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

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

• 使った分だけ課金
• 専用 SDK、専用 API にて操作する
• 自動的にバックアップを生成
• 容量無制限

その後 S3 のような形態のサービスが一般的となり、現在では 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 といったディレクトリ・フォルダという概念がない。ぱっと見では /mybucket/dir/subdir/file.txt などと階層構造があるように見えるが、実際はオブジェクト名に “/” が使えるというだけ。
• 低性能。基本的には遅い。

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

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

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

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

以下、詳細解説です。

料金 詳細説明

ストレージ料金

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

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

上限・制限 詳細説明

ストレージ全体容量上限

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

オブジェクト数上限

オブジェクト (≒ファイル) 数の上限はありません。何百万・何千万・何億個のオブジェクトでも配置可能です。ちなみに Amazon S3 全体では 2013年時点でオブジェクト数が2兆個を突破したそうです。

1オブジェクト容量上限

1つのオブジェクト (≒ファイル) の容量上限は、各サービスともおおむね 5TB 前後です。 とはいえテラバイトクラスのファイルは、例えばアップロード・ダウンロード時を考えると 大変扱いづらいため、可能ならアプリケーション側で GB 程度に分割しておいた方がよいと思います。例えば「2019年2月のログファイル」ではなく、「2019年2月1日のログファイル」「2019年2月2日のログファイル」と日付別に分割して保存するなど。

ちなみに、Amazon S3 は 2010年にオブジェクトサイズ上限を 5GB から 5TB に引き上げました。 Azure Blob Storage は 2017年に 195GB から 4.77TB に引き上げました。

機能・管理 詳細説明

リージョン

オブジェクトを作成する際、どのリージョンに置くかを決める必要があります。作成時に決めたリージョンは変更はできません。どうしても変更したい場合は、「別リージョンにコピー&旧オブジェクトを削除」とする必要があります。

将来的にどうなるかわかりませんが、2019/02 現在ではオブジェクトストレージはリージョン依存なサービスということです。

レプリケーション

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

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 と 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 と Google Cloud Storage には、「ライフサイクル管理」という機能があります。例えば、下記のようなことができます。

• 一定期間が経過したら、オブジェクトを削除する。
• 一定期間が経過したら、オブジェクトを S3 Glacier や Cloud Storage の Coleline クラスなど、より安価な長期保存用クラスに移す
• バージョニングで、N世代前のオブジェクトを削除する。
• バージョニングで、N世代前のオブジェクトを、より安価な長期保存用クラスに移す

Amazon S3 と Google Cloud Storage のライフサイクル機能を比較すると、S3 の方が高機能です。例えば下記は Amazon S3 では実現可能ですが、Google Cloud Storage ではできません。

• バケット内の、特定のパスのみライフサイクル機能を対象とする
  (logs/ のみ、など) 。
• バケット内の、特定のタグが付いているオブジェクトのみ、ライフサイクル機能を対象とする。

アクセスログ

ストレージ側での一括処理

タグ付け・ACL (権限) 設定・メタ情報設定・オブジェクトコピーなどの処理は、オブジェクトが1個であればすぐに終わりますが、オブジェクト数が数百万・数千万・数億個となると何日もかかる場合があります。

2018/11 に S3 Batch Operation という機能が発表されました。これはあらかじめ処理対象リストと作業内容を登録し、S3 側で一括してジョブとして実行してもらうという機能です。できることは タグ付け・ACL (権限) 設定・メタ情報設定・オブジェクトコピーですのでそれほど多くはありませんが、AWS Lambda 呼び出しもできるので、例えばオブジェクト削除などは Lambda にまかせるとよいでしょう。

更新・削除不可

IPアドレスでの接続制限

Web での公開 詳細説明

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 アドレス制限

Webでの公開 – CDN からのみ接続

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

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

Webでの公開 – 認証

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

ただ、下記のようなことを頑張れば可能です。特に例2・3 は、AWS・Azure・GCP いずれも適用可能です。

• 例1：Amazon S3 で、CloudFront → S3 と連携させ、その際に Lambda を実行するようにする。Lambda で認証し、認証OK の場合のみ S3 連携を成功させる。
• 例2：Google Cloud Storage で、GAE で認証し、認証OKなら Cloud Storage から取得したオブジェクトをクライアントに返す →参考
• 例3：EC2 等の仮想マシンを立て、nginx などの Web サーバにて認証設定した上で、S3 などにリバースプロキシ設定を行う。直接S3を読めないよう、IPアドレス等で設定する。 →参考

Webでの公開 – SSL

Webでの公開 – デフォルトページ設定

ここで言う「デフォルトページ」とは、http://xxxxxxxx/yyyyy/ にアクセスした際、実際は http://xxxxxxx/yyyyy/index.html の内容が表示される、というアレです。Apache で言うところの DirectoryIndex です。この機能は Amazon S3・Azure Blob Storage・Google Cloud Storage いずれにも実装されています。

Webでの公開 – エラーページ設定

連携 詳細説明

イベント駆動

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

• Amazon S3 の場合は AWS Lambda
• Azure Blob Storage の場合は Azure Functions
• Google Cloud Storage の場合は Cloud Functions

マウント

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

まず基礎知識として、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でオブジェクト内部を検索

ストレージに置いてあるオブジェクトを、SQL を使って検索する機能があります。

AWS では、S3 Select・Amazon Athena・Redshift Spectrum の 3つの方法があります。

• S3 Select
  • 対象フォーマットは CSV・JSON・Parquet
  • JSON は、JSONL (1行1レコード形式) と、トップがオブジェクトの形式に対応 (トップが配列は不可)
  • gzip・bzip2 圧縮ファイルに対応
  • SQL はかなり簡易的。
  • 対象にできるのは 1オブジェクトのみ。複数オブジェクトを対象にするには、オブジェクト一覧を取得して、それぞれに S3 Select を投げるなどの工夫が必要。
    • SELECT・FROM・WHERE・LIKE・LIMIT が使える。GROUP BY・ORDER BY・結合・サブクエリは不可。
    • 集計関数は MIN/MAX/COUNT/SUM/AVG のみ
    • 条件関数は COALESCE・NULLIF のみ
  • マネジメントコンソール・SDK から利用可能。

他ストレージとの連携

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

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   bZHOOIY2a1CnPuc8ZOY0Q==
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 エンジンからの検索

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

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

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

SFTP での接続

2018/11、AWS Tranfer for SFTP というサービスがリリースされました。これは SFTP で接続してファイルのアップロードやダウンロードを行うが、ファイルを保存するバックエンドは S3 を使うというものです。SFTP サーバが別途立ち上がって定期的に S3 との転送を行うとか、既存 SFTP サーバと S3 間の転送を行うのではなく、SFTP と S3 を中継するインタフェースを立ち上げることができるというイメージです。これにより、クラウドに明るくない作業者が WinSCP などの使い慣れたツールを使用できたり、SFTP 連携機能しか持たないシステムとの連携が行いやすくなるなどのメリットがあります。

なお、この機能を有効にして接続可能にしておくだけで $0.30/時間 ですので、1ヶ月では $220 程度になります (東京リージョンの場合)。別途アップロード・ダウンロードのデータ量に応じて料金がかかります。

Azure Blob Storage や Google Cloud Storage ではこのような機能はリリースされていません。

アップロード 詳細説明

高速アップロード

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

ローカルにあるファイルサーバや既存データセンタにファイルがあるとして、クラウドにアップロードする場合、データ量がテラバイト・ペタバイトになると、 アップロードにかかる時間が大問題になってきます。

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

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

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

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

• AWS Snowball: 容量 80TB。タワー型。東京で利用可。
• AWS Snowball Edge: 容量 100TB。タワー型。Snowball はディスクのみであるが、Snowball Edge はディスク + コンピュータであるため、 NFS 接続・Lambda 実行・Snowball Edge 複数台でのクラスタリング等、より賢いことが行える。東京で利用可。
• AWS Snowmobile: 最大容量 100PB。東京で利用可。
• Azure Data Box
  • Azure Data Box：容量 100TB。タワー型。東日本・西日本では 2019/4 現在利用不可だが、2019 2Q に GA 見込みとのこと。
  • Azure Data Box Disk：容量 40TB (8TB の SSD を最大5枚)。SSD は SATA で接続。東日本・西日本で利用可能。
  • Azure Data Box Heavy：容量 1PB。66cm x 72cm x 122cm の筐体。230kg。2019/4 現在プレビュー。東日本・西日本では利用不可。
• Google Transfer Appliance: 容量 100TB または 480TB。2U または 4U のラックマウント型。2019/4 現在、米国・カナダで GA。欧州はプレビュー。日本は利用不可。

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

例えば下記はよくない例。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: リクエスト率およびリクエストパフォーマンスに関する留意事項
• Azure: Microsoft Azure Storage のパフォーマンスとスケーラビリティに対するチェック リスト