こんにちは、@mosuke5です。
Amazon S3をはじめとして、オブジェクトストレージが身近になってきています。
各クラウドベンダーはオブジェクトストレージサービスを提供しています。
注目をあびているオブジェクトストレージですが、その性質や特性をあまり理解しておらずを魔法のストレージとして理解されているケースも多いように感じます。クラウドプロバイダーとして働く身としては非常にもどかしい思いでいます！ なので原点に振り返ってそもそもオブジェクトストレージとはなんなのか。どんな特徴を持っているストレージなのか、まとめてみました。
1.オブジェクトストレージとは
オブジェクトストレージとは一言で言うと、「オブジェクト単位（ファイル単位）で出し入れのできる、ネットワークストレージ」です。 オブジェクトストレージでは直接にストレージ上のファイルをRead/Writeすることはできません。 いうなれば、FTPサーバに近い存在とも言えます。
今やクラウド上のストレージの代名詞として扱われるオブジェクトストレージですが、 実はファイルの出し入れしかできないストレージなのです！？！？
2.特徴
では、そんなファイル単位での出し入れしかできないFTPサーバに似たオブジェクトストレージですが、その本当の特徴はどこにあるのでしょうか。
特徴1: ディレクリ構造の排除
1つ目の特徴としては、ディレクトリ構造でファイルを管理しないことです。 ディレクトリ構造は、もしストレージサーバのハードディスク容量がいっぱいになり、 ファイルを別のディスクに移動する場合、そのディレクトリパスも変更しなければいけません。 クラウドサービスのようなたくさんのユーザが利用し拡張性の求められる場面では、ディレクトリ構造は適さないのです。
そこで、オブジェクトストレージはディレクトリ構造ではなく、階層のないフラットな関係でファイルが保存されます。 すべてのファイルにIDが付与され、そのIDがどこに保管されているか別で管理する仕組みとなっています。
とはいってもS3の管理コンソール上では、フォルダを作ったり階層にできるではないか？とも思うかもしれません。これは、人間がファイルを構造的に管理しやすいよう、インターフェイスとしてそうしているけれど、中身の実装はディレクトリ構造にはなっていないです。
特徴2: 分散保存
2つ目の特徴は「分散保存」です。 オブジェクトストレージでは、ファイルを分散保存するアーキテクチャによって、 ファイルの冗長化と大量のファイルへのアクセスさばくことを可能にしています。 詳しくは次の「オブジェクトストレージのアーキテクチャ」の項目でご紹介します。
特徴3: アプリケーションからの利用を意識
3つ目の特徴はアプリケーションでの利用を強く意識していることです。 この項目は製品によって異なる部分もありますが、主な3点を紹介します。
(1)メタ情報管理
従来のファイルシステムでのファイルへのメタデータは、ファイルのサイズや更新日付などが一般的でした。 オブジェクトストレージではファイルの有効期限などの付加情報を設定することができ、インフラ管理を容易にします。 上の「ディレクトリ構造の排除」でもふれたように、ファイルはIDを持っており、そのファイルの名前も含めてメタデータとして別に管理されます。
(2)HTTPプロトコルを使ったインターフェイス
オブジェクトストレージでは、ファイルのアップロード、ダウンロードなどすべての操作はHTTPプロトコルを利用します。 HTTPのような汎用的なプロトコルを採用することにより、サーバからはもちろん、モバイル端末など幅広いデバイスから利用が可能です。
(3)Web公開機能
さらには、保存したオブジェクトに対してURLを割り当てて公開することもできます。 静的なWebサイトの公開や、cssやJavaScript、画像ファイルなどを直接オブジェクトストレージへ取得しにいくこともできます。
4.オブジェクトストレージのアーキテクチャ
オブジェクトストレージとひとまとめにいっても、製品によってその実現方法はさまざまで異なります。 ここでは一例として利用されるアーキテクチャについて紹介します。
※ここで紹介するアーキテクチャがオブジェクトストレージのすべてのアーキテクチャを表すものではありません。また、わかりやすくするためかなり簡略化して記載しています。
アーキテクチャ
大きく分けて、プロキシノードとストレージノードの2つによって構成されています。
ファイルをアップロードする時（保存する時）、プロキシノードは受け取ったファイルを、
バックエンドのストレージノードに保存する必要がありますが、この際に複数のストレージノードに対してファイルを保存します。これによって、ファイルの冗長化（三重保存）を実現しています。
各ストレージノードではRAIDは行わず、複数のノードに対して保存することで冗長化をはかっています。
一方、ファイルをダウンロードときは、複数のノードに保存されているファイルのうちどれか1つを選びます。 これによって大量のファイルへのアクセスの負荷分散も実現しています。
ファイルアップロード
ファイルダウンロード
オブジェクトの配置情報の管理
ファイルをアップロードする際に、プロキシノードは複数のノードに保存すると説明しました。 たとえば10台のストレージノードがあり、そのうち3台に保存したとします。 ファイルを取得する際に、対象のファイルがどのノードにあるかわからなくなってしまうので、ファイルとノードの対応付けの管理が必要です。
そのため、すごく簡略化すると下記のような対応表を作って管理します。 あるファイルがどこに保存されているのか記述された対応表です。
| ファイル名1 | ファイル名2 | ファイル名3 | |
|---|---|---|---|
| 保存場所1 | 1 | 2 | 5 |
| 保存場所2 | 5 | 3 | 8 |
| 保存場所3 | 9 | 10 | 10 |
また、オブジェクトストレージは拡張が優れている点が特徴と述べました。 ストレージノードが追加されることは頻繁に行われます。 その際には、リバランスと呼ばれる処理が行われ、追加されたノードを含めてオブジェクトの再配置が行われるようです。
Eventual Consistency（結果整合性）
複数のストレージノードに対してファイルを保存しているわけですが、ファイルの更新をした場合どうなるのでしょうか？ 実装にもよるかと思いますが、あるノードのオブジェクトが更新されてから、他のノードのオブジェクトに同期が行われます。同期の間、にファイルを取得しに行くとタイミングによっては古いファイルを取得してしまうことがあります。しかし、最終的には同期が終わりすべてのノードで同じファイルが格納されます。このことを「Eventual Consistency（結果整合性）」と呼びます。 直訳で考えると「最終的には整合性があるよ」といったことろでしょうか。
このシナリオはストレージノードの障害時にファイルが更新されたときも同じです。 障害があったストレージノードの復旧後、そのノードだけファイルが古い状態となります。 この状態でファイルの取得を行うと、古いファイルを取得してしまう可能性があります。 オブジェクトストレージでは定期的に同期の処理が行われ、正しい状態へもどす機能があります。 この機能によりしばらく時間が立つと全体の整合性がとれた状態となります。
Amazon S3でもデータの整合性について記述されています。
Amazon S3 のデータ整合性モデル
S3の「強い一貫性」のサポート
2020年12月のre:Inventの中で、S3がいままでの結果整合性モデルではなく、「強い一貫性」のサポートをすることを発表しました。
もともとのオブジェクトストレージの仕組みでは上で述べたような結果整合性のモデルになることが普通ですが、テクノロジーの進化によってクラウドプロバイダーの製品は進化を遂げているようです。具体的な実現方法については明記がありませんでした。
Amazon S3 Update – Strong Read-After-Write Consistency
Erasure Coding
Erasure Codingとはデータの保存方法のことです。 上の例ではレプリケーション的なデータの複製保存をしていることを書きました。 3箇所に分散して保存すると、単純にストレージの利用効率は1/3になります。 その効率をあげるためにErasure Codingを採用することがあります。 ここで詳細を説明するには重たすぎるので、下記を参照してください。
www.jdsf.gr.jp5.オブジェクトストレージの向き不向き
上記にみてきた特徴を持つオブジェクトストレージですが、その最適な利用用途はなんでしょうか。
その特性上、Read/Writeはブロックレベルではなく、オブジェクトレベルとなります。
更新頻度の高いDBのバックエンドストレージとしては当然不向きでしょう。比較的更新頻度の低く、古いデータを読み出すことがあっても影響の少ないたぐいのものが最適と考えられます。よく利用される用途としては、HTMLやCSS、画像、動画などのスタティックなファイル。そして、バッチ処理の計算結果の置き場などでしょうか。
また、AWSなどのパブリッククラウドを利用していると、Lambdaを代表としたFunctionなコンピューティングがあるがゆえにその利用用途も拡大していると考えます。Lambdaであれば、S3のイベントをトリガーに処理を実行できるためその点は大きいです。
6.オブジェクトストレージの勘違いしがちなユースケース
(1)ログのリアルタイムでの保存
よくFluentdを使ってS3へのログの保存が紹介されます。 この利用方法はとてもまっとうであり、正しい使い方といえます。
ですが、たまにリアルタイムでのログ保存と勘違いしている話をききます。 上で紹介してきたように、オブジェクトストレージはファイルの出し入れしかできません。 リアルタイムのログを1行ずつオブジェクトストレージに書き込むには、その都度ファイルを入れ替えるしかありません。
そのため、オブジェクトストレージを利用したログ管理はリアルタイムなものでなく、 ログファイルがローテーションされるたびにアップロードするなどの利用になる点は抑えておきましょう。 更新頻度をしっかり考慮することが大事です。
また、クラウド環境ではサーバは負荷に応じて増減することが日常的です。 Fluentdではサーバのシャットダウンシグナルを受け取った時に、ログを出力する機能があるので、 クラウド環境でもオブジェクトストレージを使ってログ管理を行うことは可能です。
(2)サーバにオブジェクトストレージをマウントするケース
オブジェクトストレージをサーバにマウントして利用するケースも多く見受けられます。
qiita.comオブジェクトストレージでは階層構造はなく、フラットなファイル管理を行います。 またファイルの操作はすべてHTTPで行います。 サーバにマウントすると、一見通常のファイルシステムのように見えてしまいますが、見せかけだけです。 その点を理解して利用するようにしましょう。
参考
結果整合性などの話は、データ指向のアプリケーションを考える上では欠かせない観点です。 内容としては難しいものではあるのですが、下記の書籍はデータストレージの特性などを理解するには非常に有益です。 書籍の最終章のまとめについて動画で解説もしましたので興味ある方みてみてください。
追記メモ (2017/03/28)
- FTPにも近いが、今は忘れられつつあるWebDavが似たような実装
- 突き詰めれば、従来ファイルシステムもR/Wしかできないのは同じ。ブロックサイズの違い。
- いつになってもR/Wしかできないのです。
