数年をかけて準備中のこれまでにない、まったく新しいアプローチであるためです。Honeycombは、アプリケーション拡張性を持つフレームワークを備えた最初のストレージシステムです。開発者はアプリケーション・サーバにある下位レベルの機能をストレージシステムにオフロードできます。例えば、メタデータ管理やクエリ、その他データサービスなどの機能です。

アプリケーションサーバからいくつかの機能をオフロードし、ストレージシステムにあるデータの近くに置くことによって、アプリケーションの全体的な価格/性能比が改善するとともに、信頼性及びスケーラビリティが改善します。

このプロジェクトの当初から、私たちの目的は、ストレージシステムにプログラマビリティをもたせて、本物のインテリジェンスを追加することにありました。Honeycombはアプリケーションを認識するプログラマブルなストレージを装備しており、大規模なデジタル資産リポジトリの管理及び操作を容易にする拡張可能なメタデータシステムです。このシステムは、スケーラビリティと信頼性の向上とともに、個別データベースの柔軟性をもたらします。メタデータフレームワークは、ファイルの種類に依存することなく、システム構造に組み込まれたネイティブな要素として動作します。

個人的には、第2レベルのプログラマビリティは非常にワクワクする機能で、インテリジェントなストレージシステムを実現しています。Honeycombは、データがシステムを出入りする過程でデータを操作できます。これは、多くの顧客やアプリケーションパートナにとって戦略上本当に重要になります。

以前は、ワイヤの上にあるものとワイヤの下にあるもの、あるいはアプリケーションサーバで実行するものとストレージシステムで実行するものとの間には非常に明確な区別がありました。Honeycombは、この区別を曖昧にします。

Honeycombには2つの要素があります。クラスタ化アーキテクチャに基づく信頼性の高いSerial ATAストレージシステムと、データアクセス及び管理のために豊富な拡張性を持つフレームワークです。クラスタには、ストレージシステムと非常に相性の良い、完全分散型の高性能データベース技術が埋め込まれています。

Honeycombのアーキテクチャは、旧来のアーキテクチャに存在している問題点や単一点障害を減らしたり、排除したりすることにあります。並列性を組み込むことで性能が向上し、データの入出力ばかりでなく、クエリについても突出した処理能力が達成されます。

Honeycombの開発目的は、大規模リポジトリ、つまりは、時間とともに増大する傾向がある、構造化されていない大量のデータの集まりの管理にずっと存在している問題を解決することにあります。この設計では、管理及びサービスコストの削減に重点が置かれています。私たちは、データセットが幾何級数的に増大しているにもかかわらず、IT予算が変わらない傾向があることを認識しており、私たちの目標は1人のシステム管理者がペタバイトのストレージを管理できるようにすることにあります。

安価なストレージハードウェアを見つけるのは簡単です。要は、システムの真のコスト要因になるデータの構成や修復、プロビジョニング、サービス、移行などの作業の必要性を減らすことです。

大規模リポジトリは障害回復力、すなわち、データの整合性を失うリスクなしに複数種の障害に耐える能力が必要です。並列性を通じて、Honeycombは、おそらくSAN環境で得られるレベルを超えた信頼性を提供できます。

そうした顧客にとって未解決の最大の課題は、メタデータ、すなわち、データを記述し、そのデータを即時に呼び出すことを可能にする豊富な属性群の管理です。

実際には、拡張可能なメタデータフレームワークは、プログラマビリティとアプリケーション認識の第1歩にすぎません。アプリケーションから素早くメタデータをオフロードできれば、より上位のアプリケーションタスクを管理できるようになることは分かり切ったことです。

それらリポジトリアプリケーション関係のメタデータは、データと同様に重要です。メタデータには、例えば医療分野なら、患者名やリテンション日などの属性があります。これは、データそのものサイズからすると、ほんのわずかなものですが、メタデータがなければ、データをナビゲートできません。

メタデータの管理の信頼性は卓越したものでなければなりません。データとメタデータは関連し合う形で増大しますから、時間の経過とともにデータの規模が変わるのと同様にメタデータの規模も変われなければなりません。Honeycombでは、メタデータ用の独立したデータベースはなく、全て同じシステムに格納されます。このため、信頼性、スケーラビリティ、及び費用効果の面で、ほかのストレージソリューションよりも優れた形でメタデータ格納ができます。

確実です。このようなシステムでTCOを削減する方法は3つあり、私たちは、その全ての方法を追求しました。1つは、安価なコンポーネントを利用することです。実際、安価なサーバ、安価なEthernet、安価なSATAディスクを組み込みました。もう1つの方法は、管理運用面の複雑さを軽減することです。Honeycombには、ボリューム管理もホストバスアダプタもRAID構成もありません。管理するマウントポイントもありません。

3番目の方法は、サービスに関係するコストを削減または排除することです。Honeycombは、緊急サービスの必要性をなくす方法で透過的に障害を検出し、自己回復します。動作不能になった部品は、4ないし6ヶ月に1回、据え置きサービスモデルで交換できるため、ポケットベルは不要になります。

短期的には、最適なのは、メディアやエンタテイメント、ライフサイエンス分野のサービスプロバイダか企業、あるいは政府機関になるでしょう。社内アプリケーションを使い、構造化されていないデータの大きな集まりを管理する仕事をしているのであれば、ほぼどこでもHoneycombからの恩恵を得られます。

Honeycombプロジェクトは、Sun Labsで2003年春に始まり、現代の検索技術分野の専門家数人が参加しました。ストレージに対するこれまでのアプローチでは、依然、大規模データの管理の問題が解決されていないという確信があり、新しい種類のストレージシステムを策定するために、優秀な人材を集めてチームを作りました。このチームに集まったのは、Bill JoyやGreg Papadopoulos、ストレージ専門家、低価格ハードウェアの設計に注力していた技術者、新しく立ち上がった並列ストレージグループの新しい優秀な人材などです。

プロジェクトは2、3のテーマを中心に構成されました。バラバラの大量の情報を整理する方法を探し、もっと協力的な編成でサーバとストレージを結合する方法が必要、という思いがありました。2つの層を併合することで、より効率的なソリューションが実現されるのではないかと考え、その考えは正しかったのです。

絶対にそうです。サンはシステムベンダであり、アプリケーション展開の全体を見渡すことができます。人的クライアントからテープアーカイブまでの連鎖全体を見渡すことができ、問題や非効率さがどこにあるのかが分かります。このシステムを構築するために必要だった専門知識や技術、知的財産の多くは、すでにサン社内にありました。Honeycombでは、Solaris 10やJava、内部データベース技術、クラスタ化、インテリジェントネットワーク、自己回復、負荷均衡技術が利用されています。

似たようなレベルの能力を持つベンダはほかにありません。従来のストレージベンダで、すぐにもこの水準のストレージに達する能力を持つベンダはないでしょう。

Honeycombストレージとの代表的な対話例として、ローカルのPicture Archiving and Communications System（PACS）ワークステーションで医療画像を研究する臨床学者の例を紹介しましょう。例えば、この臨床学者が、放射線学の研究室から20のサムネイル画像を見ようとしていると仮定します。最初に、Honeycombにクエリを発行します。日付範囲を限定し、特定の担当医師を条件に、特定の患者IDを持つ、データベース内の全ての画像を要求します。

Honeycombは画像を探し、ワークステーションでサムネイル画像に分解される数ギガバイトのデータをLANで送信する代わりに、その場で直接、データを変更し、すでにサムネイル形式で存在する100Kバイトの情報を送信します。Honeycombが単独でデータを検索、操作するため、アプリケーションサーバが追加処理を行ったり、同量のデータを送信したりする必要はありません。

PACSソフトウェアベンダがこれら豊富なデータサービスを呼び出せるよう、開発者はアプリケーションプログラムインタフェース（API）を開発する必要があります。APIによって、メタデータ属性の格納や情報の検索、読み出しコマンドの発行、データの操作を行えるようにします。

世界規模の発売キャンペーンを実施する前にサポートエコシステムの開発に取り組んでいるところです。今現在は、OEM数社とISVコミュニティに焦点を絞っています。また、社内にアプリケーションと開発者を抱える一握りの顧客企業に直接協力してもらっています。

Honeycombについての詳しい情報をご希望の方は次のアドレスにメールをお送りください。（申し訳ありませんが、英語でお願いします。）
honeycomb@sun.com