オブジェクトベースのストレージシステム解剖メモ
はじめに
オブジェクトストレージシステムはデータをオブジェクトと呼ばれる単位で構築・保存する柔軟性の高いストレージクラスだ。オブジェクトには構造化データ、半構造化データ、非構造化データを格納できるため、クラウド環境におけるビッグデータに適している。このシステムは元々カーネギーメロン大学とカリフォルニア大学バークレー校で学術目的のために導入された。それまでは大規模ファイルシステムが検索エンジン用に使用されていた。組織で使用された最初のオブジェクトストレージの例はEMCのCenteraプラットフォーム（2001年）だ。
現在のストレージシステムの人気傾向をGoogle Trendsで見ると、オブジェクトストレージはクラウドやファイルストレージと比較して検索量は少ないものの、最近のクラウドストレージの多くはオブジェクトベースのストレージシステムに基づいていることは否定できない。2011年5月以降、クラウドは従来のファイルベースのストレージよりも人気を獲得し、ファイルベースのストレージの人気は低下している。2019年5月にも、クラウドストレージの人気が同様に潜在的に上昇している。
ストレージシステムの進化の過程で、オブジェクトストレージは人気のあるシステムとして登場した。ブロックストレージと従来のファイルストレージと比較すると、オブジェクトストレージには次のような特徴がある。
| ストレージタイプ | 主な特徴 | 長所 | 短所 |
|---|---|---|---|
| ブロック | ・固定サイズのコンテナを使用 ・ハードドライブとして機能し、OSと直接インターフェース ・ブロックレベルでデータアクセス |
・柔軟性が高い ・I/O操作の多い用途に適している ・少量のデータ要件に対応 |
・内部フラグメンテーションによるリソース損失 ・大容量データの耐久性に問題 |
| ファイル | ・階層的にデータを保存 ・ファイルとディレクトリに編成 ・実際のデータはファイルに保存 |
・使い慣れた構造 ・直感的な組織化 ・メタデータ管理が簡単 |
・分散システムでのファイル共有時の遅延 ・スケーラビリティに制限 |
| オブジェクト | ・柔軟なコンテナサイズ ・一意の識別子とメタデータを使用 ・フラットなアドレス空間 ・ストレージプールにオブジェクトを保存 |
・大容量データに適している ・スケーラビリティが高い ・メタデータがオブジェクト内に存在 ・クロスプラットフォーム対応 |
・バイトレベルアクセスが制限される ・トランザクション処理には不向き ・ファイルユーティリティコマンドが直接使用できない |
このテーブルはオブジェクトストレージと他の主要ストレージタイプの基本的な違いを示している。オブジェクトストレージの特徴がビッグデータ環境にどのように適合するかが理解できるだろう。
オブジェクトベースストレージの基礎
オブジェクト構造とタイプ
オブジェクトベースストレージ（OBS）のデータコンテナであるオブジェクトには、ファイル、医療画像、動画、音声など、アプリケーションに応じて様々なデータ構造が含まれる。そのため、コンテナのサイズは可変的だ。従来のファイルシステムでは、中央ストレージシステムがブロックとその属性に関する情報を保持する。一方、オブジェクトベースシステムでは、各オブジェクトが自身の属性に関する情報を持ち、アクセス、ストレージ、管理に関して中央ストレージと通信する。
各オブジェクトは96ビットの一意のオブジェクト識別子に関連付けられている。インターフェースは「<オブジェクト、オフセット、長さ>」という三重識別子に基づいてオブジェクトを識別する。オブジェクトには以下の3種類がある。
| オブジェクトタイプ | 役割 | 含まれる情報 |
|---|---|---|
| ルートオブジェクト | ストレージデバイスの一意の場所を提供 | デバイスの識別情報 |
| グループオブジェクト | ストレージ内のオブジェクトリストを維持 | オブジェクトリスト |
| ユーザーオブジェクト | 実際のデータコンテンツ | ・アプリケーションデータ：保存されるデータの様々な形式 ・ストレージ属性：データ割り当て管理に使用 ・ユーザー属性：オブジェクトに関する上位レベルの情報 |
核となるアーキテクチャコンポーネント
オブジェクトストレージの主要なアーキテクチャコンポーネントはメタデータサーバー（MDS）とストレージデバイスオブジェクト（SDO）だ。MDSはストレージデバイスへのアクセス制御とシステムの一貫性維持を担当する。MDSはSDOへのリクエストを変換する。SDOはGOS(General Object Storage)の基本単位であり、オブジェクトに関する情報を含む。SDOはCPU、メモリ、ストレージデバイスを含む。ストレージデバイスはRAID、NAS、テープ、またはオブジェクトストレージデバイス（OSD）などがある。
アクセスモデルと階層アーキテクチャ
デバイスに保存されたデータの操作と通信はアクセスモデルに基づいて構成されている。アクセスモデルは以下の3つの主要な層で構成される。
| 層 | 機能 | 特徴 |
|---|---|---|
| 上位 | ・クライアントからリクエストを受け取る ・オブジェクトテンプレートをクライアント取得可能な形式に変換 ・4つ組パラメータとしてリクエストを配置 |
・物理データは処理しない ・オブジェクトリクエストのみ操作 |
| 中間 | ・上位層と下位層間のリンカーとして機能 ・上位層からのリクエストを下位層向けのコマンドに変換 ・オブジェクトメソッドに関する情報をカプセル化 |
・翻訳者として機能 ・4つ組パラメータをオブジェクトコマンドに変換 |
| 下位 | ・アクセスモデルの中心部分 ・オブジェクトプロセッサ、オブジェクト管理コンポーネント、オブジェクトテンプレートで構成 ・中間層からのオブジェクトコマンドを検査 ・ドライバー用インターフェースを構築 |
・ストレージスペース割り当てに接続 ・物理ストレージデバイスのドライバーを含む ・オブジェクトサービス固有の機能を実行 |
ストレージインターフェースとAPI
オブジェクトベースのストレージインターフェース
従来のストレージインターフェースであるSCSI（Small Computer System Interface）やIDE/ATA（Integrated Drive Electronics/Advanced Technology Attachment）は、コンピュータが物理ストレージデバイスと通信するための標準規格だ。これらのインターフェースには特有の特徴と制限があり、それを基にした実装アーキテクチャには、次のような特徴と制限が見られる。
| 実装アーキテクチャ | 特徴 | 制限事項 |
|---|---|---|
| 直接接続ストレージ（DAS） | ・ブロックストレージデバイスをホストマシンのI/Oに直接接続 ・シンプルな構成 |
・接続性に制限 ・一度に1ユーザーのみアクセス可能 |
| ストレージエリアネットワーク（SAN） | ・ブロックレベルのデータストレージデバイスへのアクセスを提供 ・LAN経由でアクセス可能な自前のストレージネットワーク ・ブロックレベルのアクセスのみ提供 |
・信頼性に問題 ・デバイスが正常に機能しない場合、全データが失われる |
| ネットワーク接続ストレージ（NAS） | ・ファイルサーバーがファイルストレージ負荷を完全に担当 ・ファイルサーバーはネットワーク経由でクライアントに接続 |
・ネットワーク帯域幅に依存 ・処理に遅延が発生する可能性 |
これらの従来インターフェースとそのアーキテクチャは、それぞれの用途に応じた価値を持つものの、ビッグデータ環境では限界に直面することが多い。
一方、オブジェクトベースのストレージインターフェース（OSD）は従来の限界を克服するために設計されており、以下のような特徴とメリットを持っている。
| 主な特徴 | メリット |
|---|---|
| ・ストレージ管理をOSDコンポーネントにオフロード ・メタデータと実データの統合管理 ・オブジェクト識別子に基づくデータアクセス |
・優れたスケーラビリティ ・クロスプラットフォームデータ転送 ・効率的なパフォーマンス ・セキュリティの強化 |
REST API
オブジェクトストレージシステムとのデータ転送には、主にRESTful（Representational State Transfer）APIが使用される。RESTful APIはWebブラウザが理解する言語で、GoogleやFacebookなどの一般的なWebサービスが使用するアーキテクチャモデルだ。オブジェクトデータの操作には以下のHTTPメソッドが使用される。
| HTTPメソッド | 機能 |
|---|---|
| POST | オブジェクトデータの作成 |
| GET | オブジェクトデータの取得 |
| PUT | データの更新 |
| DELETE | オブジェクトデータの削除 |
このテーブルはRESTful APIが提供する基本的なHTTPメソッドを示している。データへのアクセスには上記のメソッドに加えてURLが使用される。
REST APIの標準の1つにCDMI（Cloud Data Management Interface）がある。これはSNIA（Storage Networking Industry Association）によって定義されたもので、POST、GETなどの機能を使用してデータを管理するインターフェースを提供する。Scality RING、NetApp StorageGRID、Web Object ScalarなどのオブジェクトストレージはCDMIと互換性のあるREST APIを提供している。Web技術とストレージ技術の融合は、クラウドコンピューティングの時代には当然の流れかもしれない。
ゲートウェイソリューション
RESTful APIを使用するように変更できない多くのネイティブファイルシステムがある。これらのシステムがオブジェクトストレージの利点を活用するには、ネイティブアプリケーションがオブジェクトストレージを従来のストレージと認識する必要がある。これはゲートウェイと呼ばれるソフトウェアによって実現される。利点はオブジェクトストレージを従来のストレージのように見せ、アプリケーションを変更する必要がないことだ。また、他のプロトコルを通じてデータにアクセスすることも可能になる。例えば、RESTful API経由で保存されたオブジェクトをファイルとして取得できる（その逆も可能）。ただし、このような場合は応答時間が長くなることがある。ゲートウェイを使用するストレージにはAmplidata's AmpliStore、Ceph、EMC Atmosなどがある。レガシーシステムとの互換性は実運用環境では重要な要素となる。
オブジェクトストレージシステムの分類
オブジェクトベースのストレージシステムは、インターフェースレベル（クラウドストレージ、ファイルストレージ）、デバイスレベル（オブジェクトベースのストレージデバイス）、または独立システム（オブジェクトストレージシステム）など、様々な方法で実装できる。例えば、IBMとSwiftはクラウドと非クラウド環境の両方でオブジェクトストレージを提供している。そのほかの例としてMinio、Azure Blob Storage、Facebook Haystack、EMC Ctera、Ceph RGW、Backblaze B2、Wasabiなどがある。
実装に基づくオブジェクトストレージの分類は以下の通りだ。
| 分類 | 説明 | 例 |
|---|---|---|
| オブジェクトベースのファイルシステム（OBFS） | ・オブジェクトベースのストレージに存在するファイルシステム ・メタデータサーバーがファイルメタデータを保存 ・実際のファイルコンテンツはオブジェクトサーバーに存在 |
・Ceph ・OASIS ・Panasas ・Lustre |
| クラウドストレージ | ・オブジェクトストレージアーキテクチャに基づいて実装されたバックエンドストレージを持つクラウドプラットフォーム ・動的性、効率性、分散、コスト効率、可用性、セキュリティ、信頼性、リソース共有機能を活用 |
・Amazon S3 ・Mezeo Cloud Storage ・EMC Atmos ・EMC ECS ・Eucalyptus Walrus |
| アーカイブストレージ | ・オブジェクトストレージの主な用途はアーカイブ目的 ・ほとんどが不変的な性質を持つストレージシステム ・ストレージのパフォーマンス効率を高めるためのコストがゼロ ・コールドストレージとして一般的に使用 |
・Hitachi HDS ・Storiant |
| オブジェクトストレージシステム（OSS） | ・多くのオブジェクトベースのストレージシステムがこのカテゴリに属する ・巨大なストレージ要件に対応するために企業が開発した独立したストレージシステムソフトウェアまたは統合された完全機能ソフトウェアとハードウェア ・必ずしもアーカイブプロセスには使用されない |
・Scality RING ・IBM Cleversafe ・DDN WOS ・Amplidata Himalaya ・Caringo Swarm ・StorageGRID ・Huawei UDS ・SwiftStack ・GridBank ・Lattus |
このテーブルはオブジェクトストレージの主要な実装タイプとその例を示している。各カテゴリは特定のユースケースとビジネス要件を対象としている。興味深いのは、同じ基本原理に基づいていても、用途によってこれだけ多様な実装形態があることだ。
オブジェクトストレージのアーキテクチャと特性の比較
以下の表は、オブジェクトストレージの各実装タイプにおけるアーキテクチャスタイルとプロパティを比較したものだ。
| 特性 | クラウドストレージ | アーカイブストレージ | オブジェクトストレージシステム |
|---|---|---|---|
| インターフェース | 主にRESTとSOAP | 主にREST | REST、一部はNFSやCIFSサポート |
| レプリケーション方法 | データコピーまたはスプリット | 主にコピー | 実装によって異なる |
| インデキシング | バケット+キー+バージョンID、オブジェクトID | コンテンツ+メタデータ | DHT、メタデータ、オブジェクトID |
| 論理ストア | バケット、コンテナ、テナント | コンテナ | バケット、コンテナ |
| 可用性メカニズム | 複数サーバーでのデータレプリケーション、Geo Mirrorと Geo Parity | レプリケーション | 分散リング、自己修復、ヒンテッドハンドオフ |
| アーキテクチャスタイル | ステートレス、ステージドイベント駆動（SEDA） | オープン | 分散リング、シェアードナッシング、P2P |
市場の主要オブジェクトストレージシステム
クラウドソリューション
| ソリューション | アーキテクチャの詳細 | 長所 | 短所 |
|---|---|---|---|
| Amazon S3 | ・バケット指向のオブジェクトベースクラウドストレージシステム ・RESTおよびSOAPインターフェース |
・高い耐久性とスケーラビリティ | ・各オブジェクトがファイルとして保存され、アクセス関連のジョブでサーバーに負荷 |
| EMC Atmos | ・オブジェクトクラウドストレージアーキテクチャ ・ステージドイベント駆動（SEDA）アーキテクチャ |
・グローバルに分散した非構造化データのストレージ、マルチテナンシー、スケーラビリティ、データ保護をサポート | ・NFSストレージアーキテクチャを使用するため、ネットワーク輻輳が発生 |
| EMC ECS | ・ソフトウェア定義のオブジェクトストレージプラットフォーム ・マルチサイト、アクティブアーキテクチャ |
・地理的に分散した非構造化データセット向けの高いスケーラビリティ、低コスト、シンプルさ | ・ボトルネックのトラブルシューティングが開発者にとって最も困難なタスク |
| Mezeo Cloud | ・ソフトウェア定義のオブジェクトストレージアーキテクチャ ・REST APIとCDMIをサポート |
・データバックアップ、シームレス、スケーラブル、安全で容易に展開可能なクラウドストレージサービスを提供 ・異なる場所の異なるサービスプラットフォームを持つ異なるクライアントとの高度なファイル共有、コラボレーション、コンテンツタグ付けをサポート |
・コスト最適化が必要 |
このテーブルは代表的なクラウドベースのオブジェクトストレージソリューションとその主な特徴を示している。Amazon S3が事実上の業界標準となっているが、各ベンダーが独自の強みを持っているのが面白いところだ。
アーカイブソリューション
| ソリューション | アーキテクチャの詳細 | 長所 | 短所 |
|---|---|---|---|
| Hitachi Data System (HDS) | ・3Dスケーリングストレージプラットフォーム ・単一のストレージプラットフォームでスケールイン、アウト、ディープを維持 |
・コスト効率が高く、スケーラブルなストレージシステム ・単一のプラットフォームの下でファイル、コンテンツ、ブロックストレージの統合をサポート |
・フォールトトレランスと冗長性に関する能力が低い |
| Storiant | ・コールドデータ用のディスクベースのストレージソリューション | ・構造化および非構造化データセット用のオブジェクトストレージを高いスケーラビリティでサポート ・低コスト、安全なデータサービスを提供 |
・Amazon S3などの他のストレージプラットフォームとの統合が困難 |
このテーブルはアーカイブ目的のオブジェクトストレージソリューションの特徴を示している。これらはコールドデータの長期保存に最適化されている。アーカイブストレージは低コスト、高密度が重視されるが、アクセス性能はそれほど重要視されないというトレードオフがある。
エンタープライズオブジェクトストレージ
| ソリューション | アーキテクチャの詳細 | 長所 | 短所 |
|---|---|---|---|
| Scality RING | ・ソフトウェア定義のオブジェクトストレージアーキテクチャ ・分散リングアーキテクチャ |
・単一のプラットフォームを通じて、分散ファイルシステムとオブジェクトストレージの両方に対応 | ・異なるプラットフォーム間のリソース共有サービスが不十分 ・特定のプラットフォーム用に別個のリソースを割り当て |
| IBM Cleversafe | ・ソフトウェア定義のオブジェクトストレージアーキテクチャ ・シェアードナッシングアーキテクチャ |
・オンプレミス、ハイブリッド、パブリック、プライベートクラウド展開プラットフォームに適している ・データバックアップとセキュリティで優れたパフォーマンス |
・サーバーのダウンタイムによるクライアントの費用の無駄 |
| Huawei UDS | ・ソフトウェア定義のオブジェクトベースのストレージアーキテクチャ ・スケールアウト分散化アーキテクチャ |
・スケーラビリティ、信頼性、最小コストでの最大ストレージをサポート ・データタイプ、成長率、データ容量、フォールトトレランス、コンピュートインフラストラクチャなどのデータ関連要素に基づいて、ビジネスソリューションを準備 |
・Amazon S3、Swiftなどの他の有名なクラウドストレージシステムとの統合が困難 |
このテーブルはエンタープライズレベルのオブジェクトストレージソリューションの特徴を示している。これらは大規模な組織のデータ管理ニーズに対応するよう設計されている。エンタープライズソリューションは特に信頼性とスケーラビリティが重視されるが、それぞれのベンダーがアーキテクチャにおいて独自の工夫を凝らしているのが見て取れる。
ハイブリッドシステム（オブジェクトベースファイルシステム）
オブジェクトベースのファイルシステム（OBFS）は、両方の世界の最良の利点を引き出すためにオブジェクトベースの実装と他のストレージシステムを組み合わせたソリューションだ。現在のファイルシステムはスケーラビリティとストレージ容量の要件を満たすために異なる構造で編成されている。構造的に、コンポーネントはストレージマネージャとファイルマネージャとして論理的に分割されている。ファイルマネージャはファイルの階層的な編成、アクセス許可を管理し、ストレージマネージャは実際のデータの保存場所だ。OBFSの場合、ストレージマネージャはオブジェクトベースのストレージデバイス（OSD）だ。OSDはファイルの詳細を隠す完全な抽象化層を提供する。ファイルマネージャ、または一般的にはこの場合のメタデータクラスタは、ファイルメタデータの管理を規制する。
OBFSは分散ファイルシステムとクラスタファイルシステムに分類される。
| OBFS分類 | インターフェース | ストレージ | メタデータ管理 | 割り当て | ストレージメカニズム |
|---|---|---|---|---|---|
| 分散ファイルシステム（Ceph） | POSIXファイルシステムに近似 | OSD | ファイルデータからのメタデータの分離 | CRUSH | パーティション |
| クラスタファイルシステム（OASIS, Panasas, Lustre） | POSIX、直接アクセスオブジェクトストレージ | OSD、ファイルリポジトリ | メタデータ制御システムが名前空間割り当てとファイルメタデータを管理 | MDS、クライアントが直接I/O | ストリップ |
このテーブルはOBFSの主な分類とそれらの実装特性を示している。分散ファイルシステムはOSDによる物理的なデータストレージを持つのに対し、クラスタファイルシステムはより複雑なメタデータ管理アプローチを採用している。ハイブリッドアプローチは、伝統的なファイルシステムのユーザビリティとオブジェクトストレージのスケーラビリティを組み合わせた良いバランスを提供していると言えるだろう。
課題と制限
オブジェクトストレージは将来的に多くの可能性を秘めているが、解決すべき課題や限界もある。
パフォーマンスの問題
オブジェクトストレージは一般的に不変的な性質を持つため、アーカイブ目的に最適だ。これはオブジェクトストレージシステムの主な欠点だ。「PUT」命令を使用して新しいオブジェクトを作成し、データをその中に入れることができる。しかし、データが入力されると、変更できない。このため、オブジェクトストアは主にコールドストレージとして使用され、トランザクション目的には使用されない。ただし、この欠点には利点もある。データは一度書き込まれ、何度も読み取られるため、ロックメカニズムは必要ない。
オブジェクトストレージはビッグデータやマルチメディア関連のアプリケーションに非常に有利な特性であるスケーラビリティ能力で知られている。クラウドで非常に大きなサイズにスケールできる。ただし、オンプレミスのオブジェクトストレージもある。これらは大量のデータを保持するための高度にスケーラブル、信頼性が高く、コスト効率の良い、安全で堅牢な事前フォーマット版のオブジェクトストレージを提供する。しかし、市場で利用可能なものよりも少ない容量のストレージが必要な場合、オンプレミスのオブジェクトデータストレージは簡単にスケールダウンできない。
インターフェースの複雑さ
オブジェクトストレージシステムの制限の1つはインターフェースだ。ストレージシステムのインターフェースはかなりの量で類似している場合があるが、ソリューションによって大幅に異なる可能性がある。そのため、ユーザーにとってはそれほどユーザーフレンドリーではなく、異なるソリューションに対して異なるインターフェースは、ユーザーの観点から広範なトレーニングを必要とする。また、クラウドや複数クラウド環境で実装されたオブジェクトストレージには、一定のパフォーマンス測定が必要だ。したがって、リソース使用率を最適化するには、リアルタイムで情報を測定して開発者に返すことができるベンチマークツールとして機能するAPIが必要となる。標準化の取り組みはあるものの、ベンダー間の互換性はまだ課題として残っているようだ。
アプリケーション互換性の懸念
アプリケーション互換性はオブジェクトストレージの普及における大きな課題だ。現代のアプリケーションはオブジェクトストレージに適しており、オブジェクトストレージを簡単に採用できるよう設計されている。しかし、オフィス管理システムやデータベースの古いバージョンなどの伝統的なアプリケーションは、オブジェクトストレージを簡単に採用できるようには設計されていない。別のアプリケーション層を上に配置することでオブジェクトストレージと互換性を持たせることができるが、不要な複雑さとオーバーヘッドも生じる。そのため、これらのアプリケーションは刷新するか、この課題に対処するための新しい方法を考える必要がある。レガシーシステムとの互換性は常に悩ましい問題だが、オブジェクトストレージとの統合ではさらに複雑になりそうだ。
まとめ
Erasure Coding についてもまとめたい。いつかやる。
Discussion