徹底解説：オブジェクトストレージが複雑なファイル構造をシンプルにできる理由

オブジェクトストレージアーキテクチャは大量の非構造化データを保存するのに理想的なファイル構造を提供する。この記事では2回に分けてオブジェクトストレージの特徴とメリットを解説する。

公開 2017年06月27日 05時00分

著者

Scott Lowe

[TechTarget]

印刷する

階層構造で管理する従来のファイルシステムは規模拡大に伴い複雑になりがちだ。オブジェクトストレージは“フラットな関係”でシンプルな管理を可能にする

　データは加速度的に増え続けている。そのような状況から、企業では以前にも増して、より多くのストレージ容量を迅速かつ定期的に必要としているのが実情だ。

　こうした傾向が2つの難題を生み出している。1つは、稼働状態を維持したままストレージ容量を増やすのが困難な場合があること。もう1つは、従来型のストレージシステムでは、一定レベルを超えると多くの場合でストレージの拡張が困難になることだ。オブジェクトストレージアーキテクチャでは、この2つの問題に対処できる。

　ストレージの追加では、拡張作業中にプライマリーストレージを取り外さなければならないことが多く、それが稼働しているシステムを停止する原因になる。また大抵の場合、ストレージを追加すると、システムを支える他のリソースに負荷が掛かる。例えばCPUやネットワークなどだ。こうしたリソースを利用することで、ストレージは許容できるパフォーマンスを維持している。

　従来型のストレージには、可用性に影響を及ぼす恐れのある制約が他にも内在している。最も重要なのはデータをバックアップする必要があることだろう。ストレージが停止した場合には、ストレージを復旧する手段が必要になる。

　しかし、このように問題発生後のデータ保護を用意する必要がある場合、データセットが大規模になるにつれて、そのニーズへの対応は途方もなく複雑になり、コストも高額になる恐れがある。データセットが増えると、バックアップウィンドウ中に無理なく対応できる量よりも取得されるデータの方が多くなる。データ保護に対処するには、リアルタイム性の高いアプローチが必要になる。そこで役に立つのがオブジェクトストレージテクノロジーだ。

併せて読みたいお薦め記事

オブジェクトストレージ最新動向

知っておきたいオブジェクトストレージ概論

オブジェクトストレージの基礎

　オブジェクトストレージアーキテクチャは、増加の一途をたどる非構造化データの問題に対処して、企業の複雑なストレージシステムをシンプルにできる。

　ファイルまたはブロックで構成するストレージは多くのユーザーが長い期間利用してきた。こうしたストレージは、NFS、ファイバーチャネル、iSCSI、SMBといったストレージプロトコルを通じてアクセスする。だが、オブジェクトストレージでは、データ構造の理由により、こうしたプロトコルを使用する必要性がない。引き続きプロトコルを使用できる場合もあるが、オブジェクトストレージでは、複雑なディレクトリ階層を作成してオブジェクトを分類しなくてもいい。代わりに、オブジェクトストレージではオブジェクトに直接アクセスできる。

　オブジェクトは単一のファイル、画像、ビデオと同じくらいシンプルな場合もある。複数の要素で構成する場合もあるが、それでも単一のオブジェクトとしてアクセス可能だ。全てのオブジェクトには、メタデータと固有のオブジェクト識別子を関連付けている。このオブジェクト識別子を使うことで、そのオブジェクトを後から取得できる。また、このカスタマイズ可能なメタデータには、各オブジェクトに関連付けられたさまざまな属性を含む。

　メタデータ要素には共通するオブジェクトの特徴を必ず含んでいるが、アプリケーション固有の特徴を含めるような拡張もできる。写真のライブラリを例にすると、ファイルベースのストレージでは、ファイル名、作成日、変更日、ファイルサイズ、ファイル所有者に関する情報を格納する。場合によってはOS固有の識別子を含むこともあるだろう。

　ここで、写真素材提供サービス企業について考えてみたい。そのような企業のオブジェクトストレージシステムは、メタデータを拡張して要素を追加できる。例えば、イラストか写真かといった画像の種類、ピクセルで示す画像のサイズ、画像の中で最も多く使用している色など、多種多様な情報がある。この全ての情報をオブジェクトに格納することで、素早く簡単にユーザーの画像を取得できる。大規模なSQLデータベースで全ての情報を追跡する必要はない。

　医療分野では、メタデータに患者名、処置データ、医師名を格納して、X線写真などのオブジェクトに追加できる。メタデータは、単にオブジェクトについて記述するだけでなく、セキュリティや可用性も確保する。それには、オブジェクトへのアクセスを許可したユーザーやオブジェクトでどれだけの冗長性を確保するかなどを記述する。

オブジェクト、ファイル、ブロックの比較

　一見すると、オブジェクトストレージアーキテクチャはブロックベースのストレージと似ているかもしれない。突き詰めれば、ブロックベースのストレージにも階層がない。ただし、データブロックの取得には、ブロックベースのストレージに階層を強制するためファイルシステムで高度なアプリケーションが必要になる。加えて、ブロックベースのストレージはメタデータを持たないという点でもオブジェクトストレージと異なる。

　ファイルベースのストレージでは、ファイルシステムによって階層を提供する。また、一部のメタデータも利用できる。そのため、コンテンツベンダーにはブロックベースのストレージよりもファイルベースのストレージが適している。ただし、内部では、個々のファイルを小さな要素に分解し、ストレージのランダムな場所に分散している。その全ての要素を取得するためにどこを確認すべきかについてはファイルシステムが把握している。そのため、ユーザーがファイルを要求すると、ファイルシステムによって即座に全てのデータを取得する仕組みだ。

　次の表でオブジェクトストレージと従来型ストレージの違いをまとめた。

オブジェクトストレージと従来型ストレージの対象比較	オブジェクトストレージ	ファイルベースのストレージ	ブロックベースのストレージ
トランザクション単位	オブジェクト（カスタムメタデータを伴うファイル）	ファイル	ブロック
対応している更新の種類	インプレース更新非対応（更新により新しいバージョンのオブジェクトが作成される）	インプレース更新対応	インプレース更新対応
プロトコル	REST、SOAP over HTTP	CIFS/SMB	SCSI、ファイバーチャネル、SATA
メタデータの対応	カスタムメタデータ	ファイルシステムの固定属性	システムの固定属性
最適なもの	比較的静的なファイルデータ、クラウドストレージとして	共有ファイルデータ	トランザクションデータ、更新頻度の高いデータ
メリット	スケーラビリティ、分散アクセス	共有ファイルのアクセスと管理のしやすさ	高パフォーマンス
デメリット	更新頻度の高いデータに向いていない、ロックメカニズムのある共有プロトコルが提供されない	データセンターを超えて拡張するのが難しい	データセンターを超えて拡張するのが難しい

　オブジェクトストレージシステムは、ファイルを単一の実体（エンティティ）として保存する。アプリケーションでオブジェクトID指定してストレージを呼び出すことで目的のデータを取得する。全てのオブジェクトには固有のオブジェクトIDがあるため、上位層の構造を管理してデータを整理する必要はない。また、全てのメタデータに対して検索を実行できるため、簡単にアイテムを取得できる。

　後編ではオブジェクトストレージの可用性とデータ保護に関する解説と、オブジェクトストレージが適した利用場面について紹介する。

印刷する