付録では、Hyper Estraierの現在の開発状況と、今後どのような進化を目指していくのかについて説明します。
筆者が現在どういう活動をしていて、その中でHyper Estraier（以下H.E.）の開発をどのように進めているか紹介します。
筆者は現在、mixi※というSNSを運営する会社に在籍しつつH.E.の開発を継続しています。mixiは招待制のサービスですが、ユーザ数は今や660万人（2006年11月16日現在）を越える規模に成長しており、ユーザの皆さんからお預かりしているコンテンツのアクセシビリティを確保するには大規模な検索システムが不可欠となっています。しかし、ログインが必要なサイトであるために、Yahoo!やGoogle等のクローラにコンテンツを拾わせることができないので、専用の検索システムを用意しなければなりません。
従来mixi内の各種コンテンツの検索機能は外部の企業の検索システムを借用していましたが、筆者を中心に自社の検索プラットフォームに載せ替える作業を進めているところです。新しい検索プラットフォームのコアにはもちろんH.E.を採用しており、mixiのスケールに対応する分散処理のための様々な機能強化を施したり、mixi内の各種データベースと連携できるようにインターフェイスを拡充したりしています。
自前の検索プラットフォームを持つということには、開発・保守の工数やサーバやネットワーク機材にかかる大きな費用を伴いますが、それを補って余りある利点があります。mixiのサービス内容が追加されて新たな種類のコンテンツを持つようになったと同時にその検索機能を提供できますし、ユーザの声をフィードバックして検索方法の改善を柔軟に行っていけますし、万一障害が起きた場合にも迅速に対応できます。
現状の会員数は660万人ほどですが、毎日凄まじいペースで増えていて、その上限は当面見えそうにありません。運営事務局の一員としては多くの人に親しんでもらえるのは嬉しい限りですが、開発チーム一同にとってはそれは大変なチャレンジになります。特に全文検索のような計算量の多い機能を開発する身としては、累積的なコンテンツ増加量に対抗する新技術を惜しみなく投入していかないといけません。
スケーラビリティを向上させる戦略として、スケールアップとスケールアウトの2つが挙げられます。スケールアップとは、個々の機材の性能を上げることでシステムの性能を向上させる戦略です。典型的にはハイエンドのサーバ機や集中型のストレージを採用してシステムを組みます。この戦略はハードウェアのパワーにものを言わせて性能や信頼性を確保できるので、設計や実装や保守作業が比較的簡単になるという利点があります。しかし、最終的にどのくらいのサービス規模になるかを見積もって機材の選定をしなければならないという欠点があります。運用開始する前にそのサービスがどのくらい流行るかを予想するのは困難ですから、この戦略は非常にリスクが高いものと言えるでしょう。
一方でスケールアウト戦略は、多数の機材を使ってシステムの性能を向上させる戦略です。典型的には多数の廉価PCサーバを使ってシステムを組み、データは個々のサーバに分散させて保持します。この戦略はPC1台からサービス開始することができ、またサービス規模の増大に応じて台数を増やすことで無駄な投資を回避することができるという利点があります。反面、設計や実装に高度な技術とノウハウが求められるという難点もあります。どのデータがどのノードにあるかという情報を統括するマネージャが必要になりますし、分散トランザクション的な機構も求められますし、機材の数が多いので監視や障害対応を自動化するための管理システムも必要になります。
mixiはスケールアウト戦略を重視してシステム設計をしています。そしてH.E.もスケールアウト戦略に沿って利用できるように様々な機能を備えています。この組み合わせはとても相性のよいものと言えるでしょう。mixiのアーキテクチャや運用体制に合わせたシステムインテグレーションやカスタマイズは必要になりますが、分散処理も鑑みて柔軟にシステムが組めるのがH.E.の魅力のひとつです。
H.E.の分散処理機能としてはP2Pのモデルが広く知られていますが、それはインターネット上の不特定多数のユーザが連携することを想定したものです。それとは対象的に、mixiのようなコンテンツプロバイダでは古典的なクライアント/サーバのモデルか、その発展である多階層モデルが用いられるのが一般的です。
コンテンツプロバイダにおける検索モデルは大きく2つに分けて捉えることができます。ホリゾンタル（水平）検索とバーティカル（垂直）検索です（図XXX）。ホリゾンタル検索というのは、一般的なWeb検索サービスのように、多くのコンテンツを広く浅く検索するものです。そこでは規模や速度が最も大きな課題となり、その上で検索精度や機能性を付加価値として高めていくことになります。一方、バーティカル検索というのは、個人毎のメールボックスの検索サービスのように、比較的少ないコンテンツを狭く深く検索するものです。そこでは検索精度や機能性が最も大きな課題となり、その上で規模や速度を追求していくことになります。
mixiにおけるホリゾンタル検索の典型例は、ユーザ検索と日記検索です。ユーザ検索は全ユーザのプロフィールが対象となるので、つまり検索対象は約700万レコードにのぼります。そしてそのユーザ数は日々増え続けていきます。日記検索の対象は現状では最新1週間の記事に限定していますが、それでも検索対象は600万レコードにのぼります。日記投稿数もどんどん増え続けてきていますし、より長い期間の日記を検索対象にしたいという要求もあります。
ホリゾンタル検索においては、検索対象が多いので、検索クエリを複数のノードに投げて並列処理させて、その結果をマージして提示することになります。すなわち、単一のエントリからメタ検索をかけて、その結果の論理和を返すということです（図XXX）。結果をマージする際のオーバーヘッドをできるだけ小さくするためには、ノード数は比較的少なくして、個々のノードの性能を最大化することが求められます。したがって、検索系と更新系は分離します。インデクシング用のマシンで構築したインデックスを検索用のマシンにコピーするようにして、検索用マシンは検索処理に専念させるということです。
mixiで作ったホリゾンタル検索用のプラットフォーム※では、「親子インデックス」という手法を採用しています（図XXX）。子インデックスと呼ばれる頻繁に更新される小さいインデックスと、子インデックスを定期的にマージして作られる巨大な親インデックスに分けて転置インデックスを管理します。検索結果は親と子の検索結果をマージして生成します。子インデックスは小さいので効率的に更新処理が行えますし、計算量の大きい親インデックスの更新は頻度を抑えてアイドル時間に行うことで全体の性能を向上させることができます。
なお、次世代のホリゾンタル検索用プラットフォーム※の実装作業も進めています。単一のノード上でマルチスレッドで論理積のメタ検索（AND検索）を行い、複数のノードに対する論理和のメタ検索（OR検索）の結果をクライアントに提示するという多階層のモデルです。マルチコアのプロセッサやマルチCPUのサーバが一般化するなか、このようなスケールアウトとスケールアップの中間的なアプローチも検討する価値があるでしょう。
mixiにおけるバーティカル検索の典型例は、メッセージ検索です。mixiにおいては電子メールのように1対1で情報交換ができるmixiメッセージという仕組みがあるのですが、その通信履歴が検索の対象となります。やりとりされるメッセージの数は日記の2倍以上もあり、また受信者の「受信箱」と送信者の「送信済み」の双方に履歴を残すので、検索対象のデータ量はメッセージ検索がmixi内で最大と言えるでしょう。ただし、各ユーザにとってメッセージ検索の対象となるのは自分のメールだけですので、ユーザ毎にインデックスを割り当てれば個々のインデックスを小さくすることができます。一方でメッセージ検索の機能要求は日記検索などよりもリッチで、検索結果のソートや題名などによる属性検索も実装しなければなりません。ソートや属性検索を組み合わせた全文検索の計算量は単純な全文検索の計算量とは桁違いに大きくなります。
バーティカル検索においては、検索対象が少ないので、並列処理の必要はありません。ただし検索対象の括り毎にインデックスを用意する必要があるため、インデックスの数が膨大になります。すなわち、個々のマシンに多数のノードを配置して、クエリの種類に応じて適切なノードのインデックスに接続するということです（図XXX）。多数のノードを配置するオーバーヘッドをできるだけ小さくするためには、インデックスのフットプリント※を最少化するとともに、更新処理の負荷もできるだけ抑えることが求められます。したがって、検索系と更新系は同一にします。インデックスが細分化されていて個々のインデックスの検索と更新が同時に発生することはまれなので、ロックなどの排他制御による性能低下の心配はありません。
mixiで作ったバーティカル検索用のプラットフォーム※では、「疑似ノードサーバ」という機構を採用しています（図XXX）。H.E.のP2P機構のノードサーバはデーモンプロセスがインデックスとの接続を保持しつづけて応答速度を向上させていましたが、数千のプロセスを常駐させることは現実的ではないので、ノードサーバをそのままバーティカル検索で利用することはできません。そこで、ノードサーバのプロトコルをCGIスクリプトで実装して、オンデマンドで適切なノードに対応したプロセスを起動するようにします。
しかし、更新処理に関してはその都度プロセスを起動してファイルを開き直すという手法だと、更新用キャッシュの効果がなくなるので、計算量が大きくなってしまいます。その問題に対しては、疑似ノードサーバに「疑似インデックス」という機能を持たせて対処しています（図XXX）。疑似インデックスは通常の転置インデックスと同じAPIを持つモジュールですが、実体は登録文書を個別のファイルとして保存したものです。疑似インデックスに対する検索処理は個別のファイルの逐次探索を行うので効率がよくないのですが、更新処理は登録文書のデータをファイルとして保存するだけなのでとても効率的です。この仕組みによって、疑似インデックスが一定の規模になったら本当のインデックスにマージすることで、インデックスの更新頻度を抑えることができます。また、インデックスと疑似インデックスをメタ検索することで、通常のインデックスと同じ結果を少しのオーバヘッドで生成することができます。
本特集のまとめとして、今後のH.E.の進化の方向性について述べます。
全文検索のツールキットとしてのH.E.は既に安定期に入ったと思っていますが、導入実績としてはNamazuやLuceneやその他のライバルに比べて今ひとつの感が否めません。そこで、まずはmixiにおいて確たる導入実績を示した上で、多くのサイトやアプリケーションに採用していただけるように普及活動を行っていくつもりです。また、mixi以外でも自分でアプリケーションを開発して公開していきたいと考えています。趣味としては、デスクトップ検索とWebクローラも含めたWebサーチエンジンの開発に勤しんでいます。
H.E.が備えるP2P型の分散処理は、インターネットの不特定多数のユーザが連携するために作られたものです。しかし、ユーザ数が一定数に満たないと連携しようにも相手がいなくて面白くありません。ユーザ数を増やすためには面白くしなければいけないのに、面白くないとユーザ数が増えないというジレンマに取り組むことが必要となります。また、P2Pモデルではノード同士がリンクを張り合うためのコミュニケーションが不可欠ですが、現状ではその手段が提供されていません。そこで、ユーザ同士が協調してコンテンツのクローリングとインデクシングを行うためのポータルサイトを構築しようと考えています。
固定IPを保持してインターネットにサービスを提供できるユーザの割合はそれほど多くないので、サービスプロバイダとしてP2Pのノードを提供できるようにしたいとも考えています。つまり、一般のユーザがアカウントを作成してリモートのサイトにログインするだけで、自分専用のノードをインターネットに公開できるようにするのです。このような仕組みを「WikiFarm」に倣って「ノードファーム」と筆者は呼んでいます。各々のユーザが自分の好みの情報を集めて、そのインデックスを共有できるようにすれば素敵だと思いませんか？ノードファームを提供することでP2P検索モデルの普及を促進させるのが今後の野望のひとつです。
キーワードを指定してコンテンツを探す時代は当面続くとは思いますが、ユーザのニーズがそこだけに留まっているわけではないでしょう。わざわざ検索しなくても、ユーザが欲しいだろうコンテンツを先に提示してくれる「レコメンデーションシステム」の類が今後台頭してくると筆者は考えています。その前提として、ユーザが読み書きしたコンテンツからそのユーザの嗜好を学習する「ユーザプロファイリング」の機能の研究が必要となるでしょう。
H.E.のインデックスにはユーザ好みの情報が蓄積されているので、それを活用しない手はありません。筆者としては、インデックスのデータを分析して単なる検索結果よりも付加価値のある情報を提供するための機能の研究を進めていくつもりです。