オブジェクトストレージ 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 の記事はこちらからご覧いただけます。