Goldstine研究所

mosuke5's tech blog

ブログ移転しました。5秒後にリダイレクトします。

万能じゃない。オブジェクトストレージの仕組みと利用を正しく理解する

1.はじめに

Amazon S3をはじめとして、オブジェクトストレージが身近になってきています。
クラウドベンダーはオブジェクトストレージサービスを提供しています。

ですが、オブジェクトストレージをストレージの魔法として理解されているケースも多いように感じます。
原点に振り返ってそもそもオブジェクトストレージとはなんなのか。
どんな特徴を持っているストレージなのか。
気になってまとめました。

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

オブジェクトストレージとは一言で言うと、
「オブジェクト単位(ファイル単位)で出し入れのできる、ネットワークストレージ」です。

オブジェクトストレージでは直接にストレージ上のファイルをRead/Writeすることはできません。
いうなれば、FTPサーバに近い存在と言えます。

今やクラウド上のストレージの代名詞として扱われるオブジェクトストレージですが、
実はファイルの出し入れしかできないストレージなのです!?!?

3.特徴

では、そんな出し入れしかできないFTPサーバに似たオブジェクトストレージですが、
その本当の特徴はどこにあるのでしょうか。

特徴1: ディレクリ構造の排除

1つ目の特徴としては、ディレクトリ構造でファイルを管理しないことです。
ディレクトリ構造は、もしストレージサーバのハードディスク容量がいっぱいになり、
ファイルを別のディスクに移動する場合、そのディレクトリパスも変更しなければいけません。
クラウドサービスのようなたくさんのユーザが利用し拡張性の求められる場面では、ディレクトリ構造は適さないのです。

そこで、オブジェクトストレージではディレクトリ構造ではなく、階層のないフラットな関係でファイルが保存されます。
すべてのファイルにIDが付与され、そのIDがどこに保管されているか別で管理する仕組みとなっています。

特徴2: 分散保存

2つ目の特徴は「分散保存」です。
オブジェクトストレージでは、ファイルを分散保存するアーキテクチャによって、
ファイルの冗長化と大量のファイルへのアクセスさばくことを可能にしています。
詳しくは次の「オブジェクトストレージのアーキテクチャ」の項目でご紹介します。

特徴3: アプリケーションからの利用を意識

3つ目の特徴はアプリケーションでの利用を強く意識していることです。
この項目は製品によって異なる部分もありますが、主な点を3つあげます。

(1)メタ情報管理

従来のファイルシステムでのファイルへのメタ情報は、ファイルのサイズや更新日付などが一般的でした。
オブジェクトストレージでは更にファイルの有効期限などを設定することができ、インフラ管理を容易にします。

(2)HTTPプロトコルを使ったインターフェイス

オブジェクトストレージでは、ファイルのアップロード、ダウンロードなどすべての操作はHTTPプロトコルを利用します。
HTTPのような汎用的なプロトコルを採用することにより、サーバからはもちろん、モバイル端末など幅広いデバイスから利用が可能です。

(3)Web公開機能

更には、保存したオブジェクトに対してURLを割り当てて公開することもできます。
静的なWebサイトの公開や、cssJavaScript、画像ファイルなどを直接オブジェクトストレージへ取得しにいくこともできます。

4.オブジェクトストレージのアーキテクチャ

オブジェクトストレージとひとまとめにいっても、製品によってその実現方法は様々で異なります。
しかし、ここでは一例として利用されるアーキテクチャについて紹介します。

※ここで紹介するアーキテクチャがオブジェクトストレージのすべてのアーキテクチャを表すものではありません。また、わかりやすくするためかなり簡略化して記載しています。

アーキテクチャ

大きく分けて、プロキシノードとストレージノードの2つによって構成されています。
ファイルをアップロードする時(保存する時)、プロキシノードは受け取ったファイルを、
バックエンドにあるストレージノードに保存するのですが、この際に複数のストレージノードに対してファイルを保存します。
これによって、冗長化を実現しています。
実は、各ストレージノードではRAIDは行わず、複数のノードに対して保存することで冗長化をはかっています。

一方、ファイルをダウンロードときは、複数のノードに保存されているファイルのうちどれか1つを選びます。
これによって大量のファイルへのアクセスの負荷分散も実現しています。

ファイルアップロード

f:id:mosuke5:20170318164020j:plain:w600

ファイルダウンロード

f:id:mosuke5:20170318164028j:plain:w600

オブジェクトの配置情報の管理

ファイルをアップロードする際に、プロキシノードは複数のノードに保存すると説明しました。
例えば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 のデータ整合性モデル

Erasure Coding

Erasure Codingとはデータの保存方法のことだ。
上の例ではレプリケーション的なデータの複製保存をしている。
3箇所に分散して保存すると、単純にストレージの利用効率は1/3です。
その効率をあげるためにErasure Codingを採用することがある。

ここで詳細を説明するには重たすぎるので、ぐぐってほしい。

www.jdsf.gr.jp

5.オブジェクトストレージの向き不向き

上記にみてきた特徴を持つオブジェクトストレージですが、その最適な利用用途はなんだろうか。
IDCFのサイトにいい感じにまとまった用途が図式されていたので、スキップしちゃいます笑

www.idcf.jp

6.オブジェクトストレージの勘違いしがちなユースケース

(1)ログのオブジェクトストレージへの保存するケース

よくFluentdを使ってS3へのログの保存が紹介されます。
この利用方法はとてもまっとうであり、正しい使い方といえます。

blog.serverworks.co.jp

ですが、たまにリアルタイムでのログ保存と勘違いしている話をききます。
上で紹介してきたように、オブジェクトストレージはファイルの出し入れしかできません。
リアルタイムのログを1行ずつオブジェクトストレージに書き込むには、その都度ファイルを入れ替えるしかありません。

そのため、オブジェクトストレージを利用したログ管理はリアルタイムなものではなく、
例えばログファイルがローテーションされるたびにアップロードするなどの利用になる点は抑えておきましょう。

また、クラウド環境ではサーバは負荷に応じて増えたり減ったりすることが日常的です。
Fluentdではサーバのシャットダウンシグナルを受け取った時に、ログを出力する機能があるので、
クラウド環境でもオブジェクトストレージを使ってログ管理を行うことは可能です。

(2)サーバにオブジェクトストレージをマウントするケース

オブジェクトストレージをサーバにマウントして利用するケースも多く見受けられます。

qiita.com

オブジェクトストレージでは階層構造はなく、フラットなファイル管理を行います。
またファイルの操作はすべてHTTPで行います。
サーバにマウントすると、一見通常のファイルシステムのように見えてしまいますが、見せかけだけです。
その点を理解して利用するようにしましょう。

追記メモ (2017/03/28)

  • FTPにも近いが、今は忘れられつつあるWebDavが似たような実装
  • 突き詰めれば、従来ファイルシステムもR/Wしかできないのは同じ。ブロックサイズの違い。
  • いつになってもR/Wしかできないのです。

test