オブジェクトストレージ vs ファイルストレージ: 何が違うのか?

ファイルストレージにおいて、ファイルはディレクトリとサブディレクトリで階層構造に整理されます。容量が増えるにつれて、ファイルモデルは2つの理由から厄介になります。まず、パフォーマンスが一定の容量を超えると低下します。 NASシステム自体の処理能力は限られているため、プロセッサがボトルネックになります。容量の増加に伴う大規模なデータベース(ファイルルックアップテーブル)もパフォーマンスに影響します。オブジェクトストレージは、基本的にメタデータ・タグと一意の識別子とともにデータ自体をバンドルします。メタデータはカスタマイズ可能です。つまり、データごとに多くの識別情報を入力できます。これらのオブジェクトは、フラットなアドレス空間に格納されているため、リージョン間でデータの検索と取得が容易になります。このフラットなアドレス空間はスケーラビリティにも役立ちます。ノードを追加するだけで、ペタバイトを越えて拡張できます。

オブジェクト ストレージは 90 年代半ばから存在していますが、比較的新しく、ブロック ストレージやファイル ストレージなどの他のストレージ タイプとの違いについて混乱することがあります。

ファイルストレージとは何ですか?

ファイル ストレージはオブジェクト ストレージよりもはるかに古く、ほとんどの人がよく知っています。ファイル/データに名前を付けてフォルダーに配置したり、多くのフォルダーを作成したり、パスを設定したりできます。このように、ファイルはディレクトリとサブディレクトリに階層的に編成されます。各ファイルには、ファイル名、作成日、最終更新日などのメタデータも関連付けられています。

これはある程度までは非常にうまく機能しますが、容量が大きくなると、2 つの理由でファイル モデルが厄介になります。
まず、特定の容量を超えるとパフォーマンスが低下します。
NAS システム自体の処理能力は限られているため、プロセッサがボトルネックになります。 容量が増加するにつれて大規模なデータベース (ファイル参照テーブル) もパフォーマンスに影響します。

 

オブジェクトストレージとは?

オブジェクト ストレージは基本的に、メタデータ タグと一意の識別子と共にデータ自体をバンドルします。メタデータはカスタマイズ可能です。これは、各データに対して多くの識別情報を入力できることを意味します。これらのオブジェクトはフラットなアドレス空間に格納されるため、リージョン間でのデータの検索と取得が容易になります。
このフラットなアドレス空間は、スケーラビリティにも役立ちます。ノードを追加するだけで、ペタバイトを超えて拡張できます。

 

オブジェクトストレージとファイルストレージの違いは何ですか?

オブジェクト ストレージとファイル ストレージの基本を理解したところで、主な違いをいくつか見ていきましょう。

まず、オブジェクト ストレージには、ファイル ストレージが直面する多くの制限がありません。ファイル ストレージを倉庫と考えてください。ファイルの箱を最初にそこに置くと、十分なスペースがあります。しかし、データの需要が高まるにつれて、倉庫がいっぱいになることに気付くでしょう。一方、オブジェクト ストレージは、屋外倉庫のようなものです。無期限にデータを追加し続けることができます。限界は空の大きさです。
小さなファイルや個別のファイルを主に読み取る場合、ファイル ストレージは適切に機能します (特に、データ量が比較的少ない場合)。しかし、規模が大きくなると、「必要なファイルをどのように検索すればよいか」と考えるようになります。
オブジェクト ストレージはバレット パーキングと考えることができますが、ファイル ストレージはセルフ パーキングに似ています。車を小さな駐車場に駐車すれば、自分の車がどこにあるか正確にわかります。しかし、駐車場が何千倍も大きいと想像してみてください。車を探すのは大変です。
オブジェクト ストレージにはカスタマイズ可能なメタデータがあり、すべてのオブジェクトはフラットなアドレス空間に存在するため、車のキーを係員に渡すようなものです。車はどこかに保管され、必要なときに係員が車を持ってきてくれます。車が到着するまで時間がかかる場合がありますが、周りを気にする必要はありません。

 

オブジェクト ストレージ メタデータ

X 線を撮影して、メタデータが役立つ実際の例を説明しましょう。 X 線の「ファイル」には、作成日、所有者、場所、サイズなど、関連するメタデータが限られています。一方、X 線の「オブジェクト」は、さまざまなメタデータ情報を持つことができます。
そのメタデータには、患者の名前、生年月日、怪我の詳細、ファイル内の同じタグ、さらに身体のどの領域が X 線で撮影されたかなどが含まれます。これは、医師が関連情報を参照するのに非常に便利です。

オブジェクトストレージ vs ブロックストレージ:何が違うのか?

ブロックストレージは、最も古い、最も簡単な形式のデータストレージです。データは「あなたが推測する」固定サイズのチャンク、すなわち「ブロック」に格納されます。それ自体では、ブロックは通常、データの一部を収容するだけです。オブジェクトストレージにおいて、データは、オブジェクトを形成する、カスタマイズ可能なメタデータ・タグと一意の識別子とともにバンドルされています。オブジェクトはフラットなアドレス空間に格納され、オブジェクトの格納数には制限なく、スケールアウトがはるかに簡単です。

ブロックストレージとは?

ブロックストレージは、最も古い、最も簡単な形式のデータストレージです。ここでは、データは「あなたが推測する」固定サイズのチャンク、すなわち「ブロック」に格納されます。それ自体では、ブロックは通常、データの一部を収容するだけです。アプリケーションは、SCSIコールを呼び出してブロックの正しいアドレスを見つけ、それらを整理して完全なファイルにします。データは断片的であるため、アドレスはブロックの唯一の識別部分です。ブロックに関連付けられたメタデータはありません。この構造は、アプリケーションとストレージがローカルの場合には、より高速なパフォーマンスを実現しますが、離れていくほど遅延が増える可能性があります。ブロックストレージが提供するきめ細かな制御は、トランザクショナルアプリケーションやデータベースアプリケーションなど、高性能を必要とするアプリケーションに適しています。

 

オブジェクトとブロックストレージの違い

ブロックストレージと比較して、オブジェクトストレージははるかに新しいものです。オブジェクトストレージにおいて、データはオブジェクトを形成するカスタマイズ可能なメタデータ・タグと一意の識別子とともにバンドルされています。オブジェクトはフラットなアドレス空間に格納され、オブジェクトの格納数には制限なく、スケールアウトが簡単です。メタデータ・タグは、オブジェクトストレージの重要なメリットであり、データの識別と分類という点に優れています。オブジェクトは、自己記述型であると考えることができます。オブジェクトを記述するユーザーまたはアプリケーションが割り当てる説明ラベルがあります。検索用アプリケーションを使用えば、データ自体を簡単に検索できない場合でも(画像、メディアクリップ、データセットなど)、特定のオブジェクトを簡単に探し出すことができます。

検索機能と無制限のスケールにより、オブジェクト・ストレージは、現在2020年までに44ゼタバイトに達すると予想されている非構造化データを扱ううえで理想的です。オブジェクト・ストレージは、このデータを効果的に大量に格納できる唯一のオプションです。

ここまで、オブジェクトストレージとブロックストレージの違いについての一般的な概要を述べてきました。現在、ブロックストレージは企業内で多く利用されていますが、オブジェクトストレージは非構造化データの爆発的な増加に対応するために最適なストレージです。

バケット単位でオブジェクトストレージを自動階層化

データの種類に応じて適切な処理できるよう、データストレージアーキテクチャ内でストレージを階層化をすることは大きな価値があります。ここでは、クラウディアンのHyperStoreがオブジェクトストレージの「自動階層化」を提供する方法について説明します。オブジェクトは、データ・ライフサイクル・ポリシーにより事前に定義されたスケジュールに基づいて、ローカルのHyperStoreストレージから移行先ストレージシステムに自動的に移動できます。

以前のブログ記事「データ階層化について知る」で説明したように、データの種類に応じて適切な処理できるよう、データストレージアーキテクチャ内でストレージを階層化をすることは大きなメリットがあります。ここでは、クラウディアンのHyperStoreがオブジェクトストレージの「自動階層化」を提供する方法について説明します。オブジェクトは、データ・ライフサイクル・ポリシーにより事前に定義されたスケジュールに基づいて、ローカルのHyperStoreストレージから移行先ストレージシステムに自動的に移動できます。

HyperStoreは、階層型データの保存先として、次のクラウドストレージプラットフォームのいずれかを移行先として利用できます。

  • Amazon S3
  • Amazon Glacier
  • Google Cloud Platform
  • S3 APIと互換性のあるクラウドサービス
  • 遠隔拠点にあるCloudian HyperStore クラスタ

 

HyperStoreを使い、きめ細かな制御

データ・ストレージ・システムでは、制御と管理のきめ細かさが非常に重要です。データセットには、データの価値に応じて異なるSLA(サービス・レベル・アグリーメント)を適用する必要があることから、管理要件はさまざまです。

HyperStoreはバケットレベルでデータを管理する機能があります(注:「バケット」は、ブロックストレージ内のLUNやファイルシステム内のNASシステム)。 HyperStoreは、バケットレベルで以下の制御パラメータを提供します。

  • データ保護 – データ複製またはイレジャーコーディング、単一または複数サイトのデータ配信から選択
  • 整合性レベル – 複製方法の制御 (同期 vs 非同期)
  • アクセス許諾 – データにアクセスするユーザーとグループ制御
  • 災害復旧 – パブリッククラウドへのデータ複製
  • 暗号化 – セキュリティ条件に合ったデータ保護
  • データ圧縮 – データを保存するために使われる実容量の効率的な削減
  • データサイズ閾値 – データのサイズにより保管場所を変更
  • ライフサイクルポリシー  – 階層化とデータ有効期限に関するデータ管理ルール

HyperStoreは、以下のイメージでライフサイクルポリシーを使いデータ階層化を管理します。

自動階層化は、バケットごとに設定可能で、各バケットはルールに基づいてライフサイクルポリシーが異なります。これらの例には、

1.ライフサイクルルールを適用するデータオブジェクト例

  • バケットにある全オブジェクト
  • 特定のプレフィックスで始まるオブジェクト (例: “Meetings/2015/”)

2. 階層化のスケジュール方法

  • 作成後x日のオブジェクトを移動
  • x日間アクセスのないオブジェクトを移動
  • 固定日にオブジェクトを移動 — 例:December 31, 2016

あるデータオブジェクトが階層化の候補になると、小さなスタブをHyperStoreクラスタ内に持ちます。スタブは実際のデータオブジェクトへのポインタとして機能するため、データオブジェクトはローカルクラスタに格納されているかのように表示されます。エンドユーザーには、データアクセスの操作に変更はありませんが、オブジェクトには、データオブジェクトが移動されたことを示す特別なアイコンが表示されます。

AmazonやGoogleなどのクラウドプロバイダへの自動階層化には、関連するアカウントにアクセスするクリデンシャル(資格情報)とともにアカウントが必要です。

 

自動階層化後のデータアクセス

パブリッククラウドサービスに自動階層化されたオブジェクトにアクセスするには、パブリッククラウド(該当するアカウントと資格情報を使用)を介して直接アクセスするか、ローカルのHyperStoreシステム経由でオブジェクトにアクセスします。階層化されたデータを取得するには、次の3つのオプションがあります。

1.オブジェクトのリストア –ユーザーがデータファイルにアクセスすると、HyperStoreに保持されているローカルスタブファイルに転送され、ユーザー要求がデータオブジェクトの実際の場所(階層化された宛先のプラットフォーム)にリダイレクトされます。

データオブジェクトの複製は、階層型ストレージからローカルのHyperStoreバケットに復元され、一度複製されたデータオブジェクトに対してユーザー要求が実行されます。セカンダリ層に戻る前に、検索されたオブジェクトをローカルに保持する期間制限を設定できます。

このことは、比較的頻繁にデータにアクセスするときに使用するための最良の選択肢と考えており、インターネット経由による性能への影響、およびデータアクセス/検索のためにサービスプロバイダが行うアクセス時間を発生させないためです。オブジェクトの取得に十分な「キャッシュ」があることを確認するには、ローカルのHyperStoreクラスタでストレージ容量を管理する必要があります

2.オブジェクトのストリーミング – 最初にローカルのHyperStoreクラスタにデータをリストアせずに、クライアントに直接データをストリームします。ファイルが閉じられると、階層化された場所でオブジェクトに変更が加えられます。メタデータの変更は、ローカルのHyperStoreデータベースと階層化されたプラットフォームの両方で更新されます。

これは、比較的頻繁にデータにアクセスし、ローカルのHyperStoreクラスタのストレージ容量に関する懸念がある際に最適なオプションと考えられますが、データ要求がインターネットを経由するため性能は低下し、このファイルが読み込まれるたびにプロバイダにアクセスコストを課金されます。

3.ダイレクトアクセス – パブリッククラウドサービスに自動階層化されたオブジェクトには、別のアプリケーションやAWS管理コンソールなどの標準パブリッククラウドインタフェースを介して直接アクセスできます。この方法は、HyperStoreクラスタを完全にバイパスします。オブジェクトは標準S3 APIを使用してクラウドに書き込まれ、オブジェクトのメタデータのコピーが含まれているため、直接参照することができます。

このオープンにアクセス可能な方法でオブジェクトを格納すると(リッチなメタデータを同じ場所に配置)、次のような場合に便利です。

  1. HyperStoreクラスタが利用できない災害復旧
  2. 別のプラットフォームへのデータ移行を容易にする
  3. コンテンツ配信など、別のクラウドベースのアプリケーションからのアクセスを有効にする
  4. 索引付けを提供するために別のデータベースに依存することなく、データにオープンなアクセスを提供する

HyperStoreは、ハイブリッドクラウドの展開を活用するための柔軟性を提供し、パブリッククラウドまたはプライベートクラウドにデータを格納するポリシーを設定できます。 

データ階層化について知る

データ階層化は異なるストレージ階層間でのデータの移動を可能にすることです。これにより、適切なデータが適切なストレージ技術にあることを担保できます。現代のストレージアーキテクチャでは、このデータ移動はエンドユーザアプリケーションには見えず、ストレージポリシーにより制御され、自動化されるのが一般的です

あらゆるデータは、アクセスの頻度、セキュリティに対するニーズ、コストといった要因のせいで、同じものはありません。そのため、データストレージアーキテクチャでは、さまざまな要件に対応するために異なるストレージ層を提供する必要があります。ストレージ層は、ディスク・ドライブ・タイプ、RAID構成というように、ストレージ・サブシステムによって異なるため、異なるIPプロファイルとコストに影響があります。

データ階層化は異なるストレージ階層間でのデータの移動を可能にすることです。これにより、適切なデータが適切なストレージ技術にあることを担保できます。現代のストレージアーキテクチャでは、このデータ移動はエンドユーザアプリケーションには見えず、ストレージポリシーにより制御され、自動化されるのが一般的です。典型的なデータ階層の例は、以下のとおりです。

  • フラッシュストレージ – 高価値、高性能要件、通常はデータセットは小さく、コストはサービスレベルアグリーメント(SLA)で要求される性能に比較し重要度が低い
  • 伝統的なSAN/NASアレイ – 中程度の価値、中程度の性能と中程度のコスト感
  • オブジェクトストレージ – 大きなデータセットでアクセス頻度が低い、コストが重要な考慮要件
  • パブリッククラウド – アクセスのない長期間アーカイブデータ

通常、OLTPデータベース、CRM、電子メールシステム、仮想マシンなどのアプリケーション/データソースに属する構造化データセットは、上記のようにデータ層1および2に格納されます。構造化されていないデータは、一般的に、パフォーマンスは重要ではなく、管理および購入決定においてコストがより重要な要素となる非常に大きなデータセットであるため、第3層および第4層に移行します。

 

パブリッククラウドへのデータ階層化における課題

パブリッククラウドサービスは、特に非構造化データの魅力的なデータ階層化ソリューションになっていますが、パブリッククラウドの使用において考慮すべき点があります。

  • 性能 – 公衆ネットワークからのアクセスは、パブリッククラウドにデータを読み書きする際のボトルネックとなります(クラウドサービスが提供するSLAによる)。特にバックアップデータの場合、バックアップとリカバリのウィンドウは非常に重要です。最もアクセス頻度の高いバックアップセットはオンサイトに保持し、古いバックアップデータのみをクラウドにアーカイブすることを検討する価値があります
  • セキュリティ – 特定のデータの種類や業界では、データをクラウドに格納してはならないという規定があります。クラウドに送信されるデータを制御できることが重要です
  • アクセスパターン – 頻繁に再読み込みされるデータは、パブリッククラウドサービス事業者により、追加のネットワーク利用料を課される可能性があります。データダウンロードに関連するコストを管理するには、データの利用方法を理解することが不可欠です
  • コスト – データを読む際に伴うネットワーク費用と同じく、大量のデータをクラウドに格納することは、特に社内のクラウドストレージの経済性と比較して経済的に見合わないことがあります。評価を行う必要があります

 

バランスのとれたデータ階層戦略にハイブリッドクラウドを使う

非構造化データの場合、データ管理に対するハイブリッドなアプローチは、オートメーション・エンジン、データ分類、およびデータのきめ細かな制御にとっての鍵となります

ハイブリッドクラウドのアプローチでは、オンプレミスストレージ側で制御しながらパブリッククラウドに任意のデータをプッシュすることができます。あらゆるデータストレージシステムにとって、異なるデータセットが異なる管理要件を持ち、データの価値に応じて異なるSLAを適用する必要があるため、制御と管理の粒度は非常に重要です。

Cloudian HyperStoreは、このブログの前半にリストしたデータ層3と4を簡単に移動できる柔軟性を提供するソリューションです。データセンターからコントロールしセキュリティを確保できるだけでなく、Amazon S3 / Glacier、Google Cloud Platform、S3 API接続を提供する他のクラウドサービスなど、さまざまな宛先クラウドストレージプラットフォームにHyperStoreを統合することができます。

Cloudianはバックアップの先に向かう

先日、「Storage Switzerland」というストレージ専門メディアがHyperStoreの製品分析記事を掲載し、たいへんに高い評価をいただきました。Cloudianが「バックアップとアーカイブの理想的な保存先」であり「あらゆるストレージニーズに対して検討すべきシステム」である理由がよくわかり

先日、「Storage Switzerland」というストレージ専門メディアがHyperStoreの製品分析記事を掲載し、たいへんに高い評価をいただきました。Cloudianが「バックアップとアーカイブの理想的な保存先」であり「あらゆるストレージニーズに対して検討すべきシステム」である理由がよくわかります。 

 

効果的なバックアップとアーカイブ

データ保護アプリケーションのなかでは、Cloudianはバックアップの保存先です。この役割を強化するため、システムには拡張性があり、速く、経済性が求められるのは当然です。しかし、もっとも重要なのは、データが絶対に破損したり、喪失しないことが保証されていることです。幸いなことに、データの堅牢性はCloudian HyperStoreが1番に重視した設計ゴールでした。HyperStorageオブジェクトソリューションは、ドライブ障害、ノード障害、また、もし望むのであればデータセンター全体障害といった、あらゆる事故からデータを守ることができる、堅牢なデータ保護機能を備えています。

私たちのフォーティーン・ナイン(14 nines)のデータ堅牢性を実現する機能群は以下のとおりです

  • イレジャーコーディング(Erasure coding)
  • 複数ノードと拠点間データ複製
  • パブリッククラウドにデータ転送するハイブリッドクラウド
  • プロアクティブリペア(Proactive repair)
  • オブジェクトの保存場所探しを手伝うデータGPS(Data GPS)
  • 欠損や古い複製を自動的に見つけ更新するリペア-オン-リード(Repair-on-Read)
  • Amazon S3 copyと同時にローカルキャッシュにも複製するスマートリダイレクト(Smart Redirect)

Cloudian HyperStoreはバックアップアプリケーションに留まりません。お客様のデータセンター内で、複数の別の役割も行います。

 

複数アプリケーション、ひとつのストレージプール

他のCloudianのユースケースとしては、

  • NAS ファイルサーバーの負荷軽減(オフロード)
  • メディアアーカイブ管理
  • ファイル同期共有ストレージ

Cloudianはスケールアウト型のクラスターなので、これらすべてが単一で無制限に拡張できる名前空間に共存できるのです。

私たちは、小規模(数十テラバイト)からスタートし、数PB超にまで拡張できるソフトウェアソリューションと複数のハードウェアアプライアンスの両製品を提供しています。

 

AI とマシンラーニング:オブジェクトストレージの将来

これからすぐに、オブジェクトストレージが大きく活用される領域として、AIと機械学習のためのデータプールであることがわかることでしょう。オブジェクトは拡張性とメタデータ対応という点で理想的だからです。

Storage Switzerland の記事はこちらからご覧いただけます。