クラウド

オブジェクトストレージとは？ブロック・ファイルとの違いを例で解説

2026/10/14 シリーズ「クラウド入門」 第6回 / 全7回

🤖 AIを使用して執筆

データを計算の外に置く理由

クラウドの仮想マシンには、仮想マシンが動いている物理的な機械に直接付いたディスクを使える種類がある。AWS はこれをインスタンスストアと呼び、仮想マシンを再起動しても中身は残るが、停止したり削除したりするとデータは消えると書いている¹。一方、Amazon EBS のディスクは、仮想マシンの稼働とは独立して残る²。

機械が入れ替わることを前提にする考え方は、クラウドより前の大規模なシステムから来ている。Google の Ghemawat らは 2003 年、安い汎用の機械を大量に並べた分散ファイルシステム GFS を発表し、部品の故障は例外ではなく常に起きるものだとして、監視、誤りの検出、故障への耐性、自動の復旧を仕組みに組み込むべきだと書いた³。Amazon の DeCandia らも 2007 年、大小の部品が絶えず故障する規模では、故障の中で永続的なデータをどう管理するかが、システムの信頼性と拡張性を決めると書いている⁴。

ブロックストレージ：一台の機械のディスク

ブロックストレージは、データを同じ大きさのブロックに分けて保存する⁵。個々のブロックに直接読み書きできるので、データの全体を取り出さなくても、一部だけを書き換えられる⁵。

クラウドでは、仮想マシンに付けるディスクとして使う。AWS は 2008 年 8 月に Amazon EBS を公開し、動いている仮想マシンに付けて、ファイルシステムとして使える永続的なディスクと説明した⁶。EBS のディスクは、付ける先の仮想マシンと同じアベイラビリティーゾーン（リージョンと呼ぶ一つの地域の中で、電源などが独立したデータセンターの集まり）に置く必要がある²。

その代わり、基本は一台の機械に付けて使う。AWS は、機械とディスクが一対一の関係に限られるため、共有のファイルストレージのような拡張性や経済性を得にくいと書いている⁵。例外として、EBS の一部の種類は、同じアベイラビリティーゾーンの複数の仮想マシンに同時に付けられる⁷。

ファイルストレージ：フォルダの階層を共有する

ファイルストレージは、ファイルとフォルダの階層でデータを整理する⁸。ファイル名と、フォルダをたどる道筋（パス）が、ファイルを見分ける手がかりになる⁸。社内のファイルサーバーと同じ使い方で、NFS や SMB という、OS が標準で備えるファイル共有の方式で読み書きする。AWS は、ファイルごとに共有や権限を設定する一般的な方式を使えるのは、三つのうちファイルストレージだけだと書いている⁹。

AWS は 2016 年 6 月に Amazon EFS を本番の利用に提供し、一台以上の仮想マシンから NFS で同じファイルシステムを使えるようにした¹⁰。

オブジェクトストレージ：データを名前で丸ごと出し入れする

オブジェクトストレージは、データを、そのデータを説明する情報（メタデータ）と一緒に、オブジェクトという単位で保存する⁵。Amazon S3 では、オブジェクトはファイルとそのメタデータからなり、バケットというオブジェクトの入れ物に入れる。オブジェクトにはキーという名前があり、バケットの中で一つのオブジェクトを指す¹¹。通常のバケットはフォルダの階層を持たず、平らな名前の空間にオブジェクトを並べる⁵。キーに「/」を含めて、フォルダのように見せることはできる。ディレクトリバケットという種類のバケットは、本当の階層を持つ¹²。

基本の読み書きは、ファイル共有の方式ではなく、事業者の API（プログラムから操作するための窓口）を通して行う。そのため、既存のアプリから使うには、新しいコードを書く必要がある⁵。S3 には、ファイルシステムとして読み書きできるようにする S3 Files という仕組みも加わっている¹³。書き換えの単位も違う。ファイルシステムはファイルの一部の更新や追記ができるが、S3 はオブジェクトを丸ごと書き換えるように作られている¹³。例外として、ディレクトリバケットの中で S3 Express One Zone という保存の種類に置いたオブジェクトには、末尾にデータを足せる¹⁴。

その代わり、大量のデータを高い耐久性で置ける。AWS は、S3 を、1 年間に 99.999999999% のオブジェクトの耐久性を持つよう設計している。標準などの種類では、同じリージョンの最低三つのアベイラビリティーゾーンにまたがって複数の機器に冗長に保存し、1 ゾーンの種類では一つのゾーンの中に保存する¹⁵。この値は設計の目標で、失われた割合の実測ではない。年に一、二回しか読まないデータには、最も安い種類の保存（S3 Glacier Deep Archive）も用意されているが、取り出しには 12〜48 時間かかる¹⁶。

オブジェクトストレージは、クラウドの初期からある。AWS は 2006 年 3 月、開発者向けのストレージのサービスとして Amazon S3 を公開した¹⁷。

三つのストレージの選び方

三つのどれを使うかの手がかりは二つある。

• どの単位で読み書きするか：一部を細かく書き換えるならブロック（データベースがデータを置く先も、多くはこれである）、ファイルとして開いて保存するならファイル、丸ごと置いて丸ごと取り出すならオブジェクトである。
• 何台の機械から使うか：一台ならブロック、複数の機械で同じフォルダを使うならファイル、多数の機械や外部からプログラムで使うならオブジェクトである。

三社のサービスの名前でいえば、次のようになる。

• AWS：ブロックは Amazon EBS、ファイルは Amazon EFS、オブジェクトは Amazon S3。
• Azure：ブロックはマネージド ディスク（データの複製を三つ持つ）¹⁸、ファイルは SMB と NFS で使える Azure Files¹⁹、オブジェクトは Azure Blob Storage²⁰。
• Google Cloud：ブロックは Hyperdisk と Persistent Disk²¹、ファイルは Filestore²²、オブジェクトは Cloud Storage²³。

データベースとストレージの関係

データベースは、ストレージの上で動くソフトである。多くのデータベースは、データを表の形で整理し、何人もが同時に書き込んでも矛盾が出ないように更新をさばく。データベースは、遅れの小さい読み書きができるブロックストレージにデータを置くことが多い²⁴。

クラウドでは、データベースのソフトを仮想マシンに入れ、ブロックストレージのディスクを付けて自分で運用することもできる。事業者が運用するデータベースを借りることもできる。借りる場合は、下のストレージも事業者が用意する。たとえば Amazon RDS では、データベースのデータを Amazon EBS のディスクに置き、利用者はその容量と種類を指定する²⁵。三つのストレージのどれにするかを、利用者が選ぶことはない。

AWS は 2009 年 10 月、Amazon RDS をベータ版として公開した。表の形でデータを持つリレーショナルデータベースを、インフラの用意やソフトの保守、一般的な管理の作業を気にせずに使えると説明している²⁶。いまの RDS の文書は、バックアップ、ソフトの修正、障害の自動の検出と復旧を RDS が管理し、データベースへの命令（クエリ）を速く動くように直す作業は利用者の責任だと書いている²⁵。Azure では Azure SQL Database²⁷、Google Cloud では MySQL、PostgreSQL、SQL Server を扱う Cloud SQL が、同じ種類のサービスである²⁸。

データベースの下のストレージも変わってきた。AWS の Verbitski らは 2017 年、Aurora というデータベースの論文で、クラウドのサービスでは計算と保存を切り離すことで回復力と拡張性を得るようになっていると書いた²⁹。Aurora は、データベースの下に一台の機械用のディスクを置く代わりに、多くの機械にまたがる専用のストレージを置いた²⁹。データベースの層からネットワークを越えて書き込むのは変更の記録（ログ）だけで、データのページそのものは書かない²⁹。論文の結びは、従来のデータベースの一体の作りから離れ、保存を計算から切り離すことが中心の考えだったとまとめている²⁹。

整合性の考え方の変化

複数の場所にデータの複製を持つと、書き込んだ直後に読んだとき、どの複製から最新の値が返るかという問題が出る。これを整合性の問題と呼ぶ。

Amazon の Dynamo の論文（2007 年）は、この問題に一つの答えを示した。Dynamo は、Amazon の中心のサービスの一部が「いつでも使える」状態を保つための保存の仕組みで、そのために、一部の故障の場面では整合性を犠牲にすると書いている⁴。ディスクが壊れても、ネットワークが不安定でも、データセンターが竜巻で壊れても、客が買い物かごに商品を入れられることを目指した⁴。すべての更新は最終的にはすべての複製に届く、結果整合性という設計である⁴。Amazon の CTO の Vogels は 2008 年、結果整合性を、弱い整合性の一つの形と定義している。新しい更新がなければ、最終的にはすべての読み取りが最後に更新された値を返すことだけを保証する³⁰。

S3 も、公開のときから結果整合性を採っていた³¹。2020 年 5 月の時点の S3 の文書は、新しいオブジェクトの書き込みには、一つの例外を除いて書き込み直後の読み取りの整合性があるが、上書きと削除は結果整合性だと書いている³²。2020 年 12 月 1 日、AWS は、S3 がすべてのアプリに対して、書き込み直後の読み取りで最新の版を返す強い整合性を、追加の料金なしで自動で提供すると発表した³¹。Vogels は後に、追加の費用なしに、性能と可用性を犠牲にせずに強い整合性を実現したかったと説明している³³。

ただし、強い整合性になったのは、オブジェクトの書き込みと削除である。バケットの設定の変更は、今も結果整合性である¹¹。また、S3 の更新は一つのキーごとで、複数のオブジェクトをまとめて一度に更新する方法はない¹¹。何人もが同時に複数の記録を矛盾なく更新するには、やはりデータベースが要る。

切り離す設計の広がりと、その代償

計算から保存を切り離す設計は、オブジェクトストレージにもデータベースにも広がっている。ただし、切り離すと、計算と保存の間の通信が増える。Aurora の論文自身、大量の処理での一番の制約は、計算や保存からネットワークへ移ったと書いている²⁹。Aurora がネットワークを越えて書くのをログだけにしたのは、この制約への対処で、論文はネットワークの I/O の回数を一桁減らしたと書いている²⁹。

オブジェクトストレージが何にでも合うわけでもない。Google Cloud は、オブジェクトストレージは書き込みがやや遅いので、細かい更新が頻繁に起きるデータ（トランザクションのデータ）には適さないと説明している⁸。丸ごと書き換える作りなので、一部だけを頻繁に更新するデータには、ブロックストレージや、その上で動くデータベースのほうが合う。

ストレージのサービスによって、複製を置く範囲は違う。S3 の標準などの種類は複数のアベイラビリティーゾーンに複製を置くが、EBS のディスクは一つのゾーンの中にある。データの置き方が決まっても、計算の機械や、そのゾーン、さらにはリージョン全体が止まることはある。一つの建物や一つのリージョンが止まっても動き続けるには、どう備えればよいのかが、次の問いである。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。