ブログ一覧

AWS・Google Cloud・Azureのストレージ比較：S3・Cloud Storage・Blobを特性から選ぶ

· 約10分で読めます

オブジェクト・共有ファイル・ブロックの違いから、S3・Cloud Storage・Azure Blob Storageの整合性、冗長化、アーカイブ、復旧、暗号鍵を比較。保存単価に加えて、取り出しと転送を含む費用を考えます。

まずオブジェクト・ファイル・ブロックを使い分ける

商品画像、既存の共有ファイルを使うバッチ、VM上のDBでは、同じ容量でも必要な操作が異なります。商品画像をキーで保存・取得するならオブジェクト、複数のクライアントが共有パスを読むならファイル、OSからディスクとして扱うならブロックが比較の出発点です。

アクセス方式AWSの例Google Cloudの例Azureの例
オブジェクトAPIAmazon S3Cloud StorageAzure Blob Storage
共有ファイルAmazon EFS（NFS）、FSxの各方式Filestore（NFS）Azure Files（対応するSMB・NFS構成）
永続ブロックAmazon EBSHyperdisk / Persistent DiskAzure Managed Disks

オブジェクトをマウントできても、ロック・部分更新・rename・同時書き込みが既存のファイルシステムと同じとは限りません。NFS共有を無改修で使う要件なら、共有ファイルの候補で実際の操作を試します。ブロックを複数VMへ接続する場合も、対応構成とファイルシステム側の調停が必要です。

S3・Cloud Storage・Blob Storageの比較で固定する条件

候補先に選ぶ設定判断への影響
Amazon S3バケットの方式、リージョン、保存クラス、必要な複製単一ゾーン向け等のクラスもあるため、S3という名前だけで耐障害性を決めない
Cloud Storageバケットの配置、保存クラス、保持と復旧の設定配置とクラスを分けて確認し、マルチリージョンという名称だけでRPOを保証しない
Azure Blob Storageストレージアカウントの種類、冗長化、アクセス階層LRS・ZRS・GRS・GZRS等の設定で、障害の範囲と副リージョンへのアクセスが変わる

以降は、商品画像の配信と過去の原本保存を考えます。オブジェクトのサイズ、保存期間、読み取り回数、リージョンをまたぐ通信、削除後に戻したい期間を固定します。各社で同じ容量だけを指定しても、アクセス方法と障害条件が違えば公平な比較になりません。

更新の整合性と、キャッシュ・複製先の見え方を分ける

S3はオブジェクトのPUT・DELETEに対する強いread-after-write整合性を提供し、Cloud Storageもオブジェクトの書き込み後の読み取りや一覧で強い整合性を提供します。ただし、公開画像をブラウザーやCDNがキャッシュしていれば、元のオブジェクトの更新後も古い版を返す経路が残ります。保存側の整合性と配信側のキャッシュ期間を別に設計します。

AzureのGRS・GZRSは副リージョンへの複製が非同期です。副リージョンを読み取るにはRA-GRS・RA-GZRS等の設定も確認し、主リージョンへの書き込み完了を、そのまま副リージョンでの最新読み取りとみなしません。これは通常の主エンドポイントの読み取りと、非同期コピーの話を分けるための比較です。

低頻度アクセスの比較：Archiveでも待ち時間は同じではない

方式の例取り出すときの特性費用・運用で見る点
S3 Glacier Instant Retrieval即時アクセス向けのアーカイブクラス低頻度アクセスの条件、最低保存期間、取り出し等の料金
S3 Glacier Flexible Retrieval / Deep Archive復元要求と待ち時間を伴うクラス復元方式、待てる時間、一時コピーと取り出し費
Cloud Storage Archiveオフライン復元の待ちを設けずアクセス最低保存期間とデータ取り出し等の料金
Azure Blob Archiveオンライン階層へのrehydrationが必要取り出しまでの時間、優先度、最低保存期間と料金

過去の原本を画面操作からすぐダウンロードする要件と、翌日までに調査担当へ渡せればよい要件では、選べる階層が変わります。「古いデータだからArchive」と決めず、問い合わせから取得可能になるまでの時間を復旧目標へ含めます。保存クラスの変更後に、利用者の導線が実際に成立するかも試します。

冗長化・版の保護・暗号鍵を復旧の条件として扱う

ディスク故障、ゾーン障害、リージョン障害、誤削除は異なる故障です。AzureのLRSは単一データセンター内、ZRSは主リージョンの複数ゾーンへコピーします。GRS・GZRSの副リージョンへの複製は非同期なので、リージョン切り替えではデータ損失の可能性とアプリの再開手順を確認します。DBのHAとDRを分けるのと同じ考え方です。

最新状態を複製しているだけでは、正規の認証情報で実行された誤削除や上書きから戻せるとは限りません。版管理、削除からの保護、保持規則、必要な独立コピーを組み合わせます。復元時はオブジェクト単体だけでなく、その版を参照するDBの整合も確認します。

顧客管理の暗号鍵を使う場合、復旧にはデータだけでなく復号権限と鍵も必要です。たとえばCloud StorageのCMEKでは、新しい鍵バージョンへローテーションしても、既存オブジェクトは古い版へ依存したままです。依存を調べ、必要なrewriteと読み取り確認を終える前に旧鍵を破棄しないようにします。各社の鍵管理へこの製品固有の手順をそのまま流用せず、対象サービスの挙動を確認します。

復旧試験の範囲：データのコピーに加え、版・参照先・鍵・公開経路も確認する

故障の範囲とRTO・RPOを決める → 必要な版・コピーを取り出す → 復号とDBの参照を照合する → 配信・認可を確認して業務へ戻す

保存単価以外を数える：取り出し・転送・操作・旧版

仮に100万個の原本があり、1個10 MB、MBは10の6乗バイトとします。現行版は10,000 GB、月に10%を1回ずつ取り出すなら1,000 GBと10万回の読み取りです。旧版を平均2つ残す仮定なら、単純化した合計保存量は現行版の3倍の30,000 GBです。実際には版ごとのサイズと保持期間で変わります。

見積もり項目の式。各社の課金単位へ合わせるための整理で、価格計算済みの式ではない
total = storage(current_versions + retained_versions + replicas)
      + requests(reads + writes + list + transitions)
      + retrieval + restore + transfer
      + early_deletion_or_minimum_duration_charges
      + key_management + operations

ここでreplicasは別途保存料が発生する構成上のコピーです。サービスの単価に含まれる内部の冗長コピーを、利用者が本数分だけ掛け直すものではありません。読み取りの1,000 GBも、そのままインターネット送信量になるとは限らず、アプリ内利用やCDNのキャッシュを経路ごとに分けます。最低保存期間より早く消すデータ、監査用の旧版、障害時の一括復元を含め、代表的な一か月と復旧時を見積もります。

採用前に試す3つのケース

  1. 商品画像：アップロード途中の停止、公開前の検査、更新直後の表示、期限付きアクセスの失効後を確認する。
  2. 原本の保管：低頻度階層へ移した実データを取り出し、待ち時間・請求項目・利用者への案内を確認する。
  3. 復旧：誤削除した版、リージョンが使えない場合、鍵へのアクセスが失われた場合を分け、復旧できる条件と担当を記録する。

操作・冗長化・取り出しを確認する一次資料

この記事で深掘りしたTips