HOME > ストレージ管理ソリューション部会 > Storage Magazine翻訳記事

巨大ファイル用ストレージを考察する

Eric Slack
Storage Magazine 2013年12月号より

一口にビッグデータと言っても、実際は二つタイプがある。我々になじみが深いのは、膨大な数の小さいファイルを解析用データとして使うビッグデータだ。もうひとつは、極めて大きなファイルを処理するもので、これには専用のストレージ・ソリューションが必要になる。

ビッグデータ解析を巡っての議論の大半は、一般的にWebトラフィックやトランザクショナル・データベース、あるいは機械センサー出力のような情報源から収集した、何千または何百万という小さなデータオブジェクトから構成される膨大なデータセットを扱うことについてのものだ。しかし、ビッグデータの議論にはもう一つのテーマがある。膨大な数の小さいデータを使う分析に焦点を置くものではなく、それらよりもはるかに大きなファイルを取り扱ったり操作したりする時に必要な様々な処理についての議論だ。これらの事例としては「ビッグデータアーカイブ」やそれと同種類のアプリケーションなどがある。そして、ストレージシステムの設計を行う際には、ビッグファイル独自の特性に対して特別に配慮する必要がある。

ビッグファイルデータの定義

ビッグファイルデータには通常、何らかのイメージやビデオが関与する。最も一般的な例としては、映画やテレビのコンテンツが挙げられる。これらの作品を生成する製作過程においては、大抵いくつかの非常に大きなファイルが作られる。しかし、大量のストレージを消費するのは、最終作品だけではない。異なる機器での映像再生や、消費者市場のために、複数の撮影映像が作られるのが普通だ。HD、3D、4Kなどの新しい技術が映像の解像度を増すのにつれ、これらのファイルのサイズは大きくなる一方だ。ビデオ監視は、Webカメラや安価なビデオ処理機器が入手できるようになってから、急激に使用するところが増えた。また動画に関しては、これらのビデオのファイルサイズは映像の長さと直接関係しており、ビデオ監視の場合、録画が数時間、さらには数日にわたって行われる事もある。これら多くのカメラの解像度が、さらに事態を厄介なものにする。ファイルサイズが大幅に増大することで、メガピクセルのスマートフォン・カメラが個人のデータストレージに与えたのと同様の影響が現れているのだ。

何個かの巨大なファイルを生成するアプリケーションは、今次々と出てきており、上記以外の例としては、人工衛星を利用したリモートセンシング（遠隔探査）や航空写真があげられる。これらのアプリケーションは、視覚画像、マルチスペクトル画像の両方を同時に生成する。衛星の世代が代わるたびに、解像度は増加の一途をたどり、ファイルサイズの増大を招いている。同様の例として、巨大なセンサーアレイと電波望遠鏡による科学的データがある。数マイル四方に展開した電波望遠鏡を使用するプロジェクト、スクエア・キロメートル・アレイ(Square Kilometer Array, SKA)が今後10年以内に稼働し始めれば、1日１PBの新規データが作成されるだろうと予想されている。

ビッグファイルデータはそんなに大変なものなのか？

動かない物体：ストレージシステムがこれ以上拡張できない地点に達した時、あるいはボトルネックによってアクセス時間が遅くなり、スループットがこれ以上我慢できないところまで来た時というのは、通常新しいシステムに移行するタイミングである。ところが、ビッグファイルデータ・アプリケーションの場合は、移行はほぼ不可能かもしれない。数PBのデータを移行するために必要なダウンタイムを確保できる企業、団体はまれだ。新規のデータが絶えず流れ込んでいるようなシステムであればなおさらだ。「動かない物体」（訳註：「矛盾」の矛と盾の故事のように、「絶対止まらない物体と絶対動かない物体がぶつかったらどうなる？」というパラドックスがあり、ここではあまりにも巨大になってしまい移行が不可能になっているアーカイブを冗談めかしてこう呼んでいる）、巨大なファイルのアーカイブは従来の基盤では管理不能なほど大きくなることがある。

建物の土台と同じように、一度基盤が構築されて運用が始まってしまうと、後から何かを変えようと思っても、たいていの場合もう遅い。このため、ビッグファイルデータのストレージ基盤は、データを今あるところに置いたまま、できるだけ無停止でアップグレードできる機能を備えた、最大限の柔軟性を目指して設計されねばならない。

長期保管：データを長期間保存するのは、ビッグファイルデータ・アプリケーションに限った話ではないが、追加される個々のファイルが今より10GB（あるいは100GB、あるいはそれ以上）大きかったら、たちまち保管の問題が起きる。データの保管は直接ファイルサイズと関連しているわけではないが、しかし人間や企業が保存したいと思うファイルの多くは（サイズの大きい）画像ベースだ。動画や音声のようなデジタルコンテンツはその良い例で、具体的にはデジタルスナップショット（Shutterflyは100PB近い写真データを保持している）やビデオ監視システムファイルなどがある。

長期保存は、これまで法規制に従う事で普及が促進されてきた。しかし、今やデータは将来あるかもしれない再利用やセキュリティのために保管される傾向にある。その好例が監視ビデオだ。これまで法的な理由でアーカイブされてきたこれらのファイルは、今や顧客の購買行動の分析を補助するために使われている。この種のデータを長期間、多くの場合無期限で保存すると、運用コストの問題が発生する。数10TB、数百TBのデータを数年間保存するためのディスクスペースを保持するのも、決して些細な問題ではない。しかし、数PBのデータをサポートするための電力やフロアースペースとなると、たとえ最も安価なディスク上であっても、問題の程度は前者と比べ物にならない。

人間が分析するデータ：多くのデータ解析アプリでは、コンピューターが解析を行うため、データはデータベースサーバーが置かれているのと同じデータセンターに保存されているか、もしくはHadoopクラスターのようにサーバーそれ自身に置かれている。しかし、ビッグファイルデータの使用事例では、多くの場合データは人間によって解析される。ところが、データセンターは人間の住むところではない。処理エンジン（訳註：ここでは人間の事）が自宅のタブレットで、あるいは路上からスマートフォンでデータを処理したいと思った場合、ストレージ基盤は適切にそのデータを届けなければならない。

ほとんどのファイルは順番に処理されるため、これらをストリーム化（多くの場合、低帯域の接続を通して）する必要があり、ぶつ切りしてデータ到着時に組み立て直すという方法は使えない。このような種類の処理パターンをサポートするには、ビッグファイルデータ・レポジトリー（データを貯めているところ）に、ストリーミング処理を開始するのに十分なコンテンツを迅速に送信し、次にファイルの残りをバッファーできるランダムアクセス・ストレージティアを設ける必要がある。しかし、ディスクストレージティアは非常に大きくかつ拡張性が高くなければならない。なぜならば、このティアは非常に巨大なアーカイブのファイル群の出だし部分を収容しなければならず、アーカイブが大きくなればそれに追随していかなければならないからだ。

ビッグファイルデータ・ストレージシステムを設計する

ビッグファイルデータの特殊な課題に取り組むためには、ストレージ基盤は慎重に設計されなければならない。例えば、動かない物体の課題からは、設計時に最大限の柔軟性を考慮しなければならない、という教訓が導かれる。しかしそれ以上に重要なのは、ストレージシステムが、モジュール型の積み上げ方式を使うことにより、データを今ある場所に置いたままで拡張できるアーキテクチャーであることだ。単なるスケールアウト・ストレージと違って、これらのシステムには一般的に、グローバルファイルシステムとともに様々な複数のストレージが異なるモジュールやノードに入っている。これらのシステムにおいては、最も保管期間の長いデータはテープに保存され、必要に応じてディスクストレージ・ノードや処理ノードを追加し、アプリケーションにとって最適な「姿」になるようにシステムを拡張していく。ストレージの混合体には、高いパフォーマンスディスク、大容量ディスク、半導体ストレージが様々な組み合わせパターンで入っている。

一例として、Silicon Graphics International（SGI）CorpのDMFは、水平方向にも垂直方向にも拡張可能だ。つまり、より高いパフォーマンスをサポートするためには、より多くの処理ノードを並行に（水平方向：スケールアウト）追加すればよいし、容量を増やすには、より密度の高いデバイス（垂直方向：スケールアップ）を追加すればよく、コスト低減も維持できる。このモジュールアーキテクチャーにはバックエンドも含まれており、パラレルデータムーバー・ノードが、レポジトリーに高速ファイルアクセスを付けたりはずしたりできるようになっている。出来上がったストレージ基盤は、それを導入した会社ごとに違ったものに見えるかもしれない。しかしこの基盤に共通するのは、業務の流れを止めず、データセットの物理的移動も不要で、ハードウェアのアップグレードや、新世代のストレージメディアをサポートするための変更にも対応できることだ。

気象解析を行うある大手政府機関は、この20年間、絶え間なくシステム内のデータ増加を経験してきた。このシステムは現在60PB以上のデータを管理しており、バックエンドでは日々300TB以上のデータを移動し、NFSに接続したクライアントには100GBpsを超えるファイルアクセスを提供している。システムがDMFをベースとしていたおかげで、52台の1Uエッジサーバーノードが、それぞれフロントエンドで2GBpsのNFSスループットを提供する現在の構成まで、段階的に拡張することができた。バックエンドの6台の1Uパラレルムーバーは、複数ティアのストレージ間のデータ移行を管理するためにファイバーチャネル経由で60GBpsの通信を提供している。この方法により、当機関の基盤はコスト削減のために最適化されており、長期間にわたって増え続けるパフォーマンスに対する要求を満たすための拡張にも対応可能になっている。

ビッグファイルデータでテープの出番がやってきた

ビッグファイルデータ・レポジトリーの途方もない大きさと、保管するデータのほとんどが保管期限をもたない（永久保管の）データであるという事実から導き出される解決策は、テープの使用である。理由は簡単で、これだけの凄まじくでかいデータを長期に渡って経済的に保存する方法が他にないからだ。ビッグファイルデータが常駐する数PBの環境で、日々かかる電気、空調、フロアスペースの費用を考えると、低電力のディスクストレージでさえもまったく割に合わない。

テープはその経済性の他にも、他のメディアがうらやむようなパフォーマンス特性を持っており、特にビッグファイルを扱う時やレポジトリーからデータを出し入れするときにその威力を発揮する。例えばLTO-6は、ネイティブで160 MB/秒のファイル・スループットを提供する。フロントエンドに適切なランダムアクセス用ストレージ（ディスクや半導体ストレージ）を配置して正しく管理すれば、テープはビッグファイルデータ用の非常に効率のよいストレージ媒体になりうる。

従来、テープをベースとしたアーカイブはどこかしら複雑なところがあった。ビッグファイルはファイルシステムの管理下でディスクに保存される。しかし、テープドライブは「ファイル識別」機能を持っていない。そのためこれらの基盤では、フロントエンドでファイルベースのインターフェースをユーザーとアプリケーションに提供しつつ、バックエンドではテープとテープドライブの面倒を見る専用のアーカイブソフトウェアが必要になる。そこに登場したのが、オープンシステム・インターフェースのリニアテープファイルシステム（LTFS）だ。LTFSはテープのアクセスを単純化し、より高い柔軟性を提供する。

Spectra Logicは最近、Amazon Simple Storage Service（S3）インターフェースをベースとし、そこにシーケンシャルデータ移行とリムーバブルメディアをサポートするためのコマンドを付け加えたDeep Simple Storage Service（DS3）と呼ばれるインターフェースをリリースした。その結果、テープにRESTベースのインターフェースが備わり、インターネット経由で通信するように設計されたアプリケーションとAmazon S3 APIをベースに設計されたシステムに直接アクセスできるようになった。DS3は、REST APIを同じように使っているオブジェクト・ストレージシステムとテープを簡単に接続することもできる。

Spectra LogicのBlack Pearlは、DS3に対応したアプライアンスで、フロントエンドのクライアントには半導体ストレージのキャッシュを提供し、バックエンドではテープドライブへの直の接続を処理する。このアプライアンスは、テープ上のデータのセキュリティと長期のインテグリティ、さらにはLTFSフォーマットへの変換も管理してくれる。

しかし、ビッグファイルデータの中には、テープライブラリーとディスクキャッシュでは収まらないものもある。これらの巨大ファイルへのアクセス要求を考慮すると、オブジェクト・ストレージシステムが有力候補として浮上して来る。オブジェクト・ストレージシステムは、従来のRAIDベースのストレージシステムより効率良く、PBまでの拡張を行えるからだ。

強みをアピールするオブジェクトストレージ

今日のビッグファイルデータ・ストレージは、リアルタイム分析と高速アクセスに対応するため、複数のディスクティアで、また長期アーカイブはテープティアで構築されている。Quantam社のLattusのようなオブジェクト・ストレージシステムは、テープベースの非常に大きなビッグファイルのレポジトリーに対しても、手ごろな価格のディスクスペースをフロントエンドとして提供し、映画や放送の業界での使い方として一般的な、地球規模で展開する可用性を提供している。これらの業界のユーザーは、Lattusの高度な分析機能を使って、アクセスが集中するファイルを「様々な地域に分散」でき、それらのファイルが呼び出される前であっても、適切なストレージティアに「バッチ移行」できる。

Quantum社の StorNextファイルシステムとデータ管理システムは、ストレージ空間から独立してメタデータ処理による拡張が可能なモジュラー型のアーキテクチャーにより構築されている。これによりユーザーは、テープ上のデータやオブジェクトストレージにより速くアクセスするために、バックエンドにメタデータエンジンを追加したり、ユーザーを増やしたり異なるプラットフォームをサポートするためにフロントエンドのファイルシステムを拡張したりすることができる。

結論：ビッグファイルデータ

ビッグファイルデータは、いくつかの特殊な課題を生みだした。山のようなデータを抱えるストレージシステムを維持し、しかも適度なスループットとアクセスパフォーマンスを提供する事は、既存の基盤を使用する限りとても不可能だ。求められているシステムは極めて柔軟で、ランダムアクセス用の様々な種類のストレージとテープをサポートする事が出来、データを今ある場所に置いたまま、ユーザーがシステムのアップグレードや変更が可能なものでなければならない。これらのシステムはまた、巨大なファイルを小さな機器に細い回線を使ってストリーミングができるように、オブジェクトストレージのような拡張性が高く経済的なディスクティアを持っていなければならない。

ビッグファイルアーカイブにはテープが不可欠だが、異なるプラットフォーム上の様々なユーザーが関与するコンテンツ処理の作業フローをサポートするために、LTFSのようなオープンフォーマットでデータが書けなければならない。テープは、過去の独自アーカイブ・ソフトウェアレイヤーの代わりにREST対応のインターフェースを備えていなければならない。これによってテープは、アプリ、オブジェクトストレージさらには、もっとも多くのビッグファイルデータのレポジトリーが置かれることになるインターネットにまで直接接続できるようになるだろう。

著者略歴：Eric Slack はストレージと仮想化を専門とするITアナリスト会社Storage Switzerlandのアナリスト。