阿部　慎一朗 著

ApacheCon

ApacheConは、さまざまなApacheプロジェクトのカンファレンスです。今回アメリカのデンバーで4/7-4/11に開催されました。Apacheのビッグデータ関連のプロジェクト(Hadoop,HBase,またその関連ソリューションのプロジェクト)、Tomcatプロジェクト、CloudStackのプロジェクト、Apache Traffic ServerなどたくさんのApacheプロジェクトのセッションがあり、私は、Lucene/Solrのセッションを見に行きました。

スケジュール:http://events.linuxfoundation.org/events/apachecon-north-america/program/schedule

Apacheコミッタだと参加費割引がききますので、私はApache ManifoldCFのコミッタということで参加登録しました。今回ManifoldCFのセッションはなく、コミッタメンバは私だけの参加となりました。

基調講演

基調講演では、Apacheプロジェクトは、昨今のビッグデータ関連・ソーシャルコーディングという観点で非常に盛況という話がありました。基調講演の聴講者は多く、コミッタと一般参加者を含めて200人前後集まっていました(なお、各プロジェクトのセッションでは10-30人の幅で集まっていました。)。日本人参加者を確認したところでは、Tomcatのコミッタ、CloudStackのコントリビュータやユーザの方がいらっしゃいました。全部で６−７人ぐらいだったと思います。私は前半の３日(月曜日〜水曜日)の参加ですが、サミットやミートアップで５日参加の方や、後半２日の参加の方がいらっしゃいました。

基調講演の内容としては、ビッグデータがあり、これを利用してさまざまな分析するには、数学をつかってコードを書いて、インフラを整備し、最後にスケールやスピードアップを考慮するという流れで進めていくのがよいでしょうという話や、OSSを活用する企業は、2007年の57%から2014年の80%に成長しており、OSSの有効活用という流れを受け、企業がOSSコミュニティをバックアップしていく体制ができつつあるという話がありました。ソリューションに対して同じ目的や用途をもっているならば、企業側がApacheのOSSに貢献することで、成長や最適化ができるだろうというのが最近の傾向になっています。

以下、今回見聞きしたLucene/Solr/Tikaに関するnewなトピックおよびASFの体制に関するトピックをご報告いたします。

Lucene/Solr

コミッタメンバやヘビーユーザの方からの発表がありました。コミッタメンバとしては、Solrの生みの親であるYonik Seeleyさん、いろんな機能をコントリビュートしたりユーザメーリングリストでいつも活躍されているChris Hostetterさん、SolrCloudで多大な活躍をされているMark Millerさんらがいました。私は、これらの３人に、昨年出版された「[改訂新版] Apache Solr入門」の本をお渡しておきました。Solrにはいつも感謝しています、弊社ロンウイット-Koji Sekiguchiも監修していて、私は６章を書きました、もしよかったら読んでください、と話しました。みなさんともに、「日本語は読めないけど、クール！サンキュー！」という反応でした。HossさんはSolr Wiki(GijutsuHyohronBook2013)のことを覚えていてくれたので、本をお渡したときすぐにわかったようでした。

さて、Solrの話ですが、Hossさんからは最新のSolr 4.7までの主な追加機能のアップデートがありました。4.0以降リリース間隔が早くなっていて、スキーマレスモードやSchema REST APIなど機能が随時追加されています(こちらは弊社トレーニングコースでご紹介しています)。私は確認していなかったのですが、親子ドキュメントの検索（子ドキュメントを検索して、それに紐づく親ドキュメントを返す、またはその逆）は、BlockJoinQparserで対応できますという紹介がありました。Luceneが持っている親子検索機能のSolr実装です。 fq={!parent 〜}、fq={!child 〜} のリクエスト表現で実行できます。このクエリパーサは分散環境でも使えるので、joinパーサと比べて比較的有意義に使えると私は思いました。joinパーサの場合は、分散環境ではできない制限がありますが、インデックスをまたいだりできます。また、親子ドキュメントをばらして登録できます。一方parent/childパーサの方は、親子をネストさせてドキュメントを作り、これをインデクシングするものです。要件にあわせてどちらが最適かを検討する必要があると思います。参考URL:BlockJoinQueryParsers。 それから、ページネーション(Deep Paging)の紹介です。通常は検索結果画面にてページ送りの実装をしますが、ある単語で検索リクエストをして、たくさんヒットしてこれを一度に全部見たいという要件があるときは、cursorMarkパラメータを使います。これは、通常のページ送りがページ数が増えるに従って実行時間が遅くなるのに対して、cursorMarkでリクエストするとページ数が多くても実行時間が遅くならないという効果があります。参考URL:Pagination。 また、docValuesの紹介がありました。sortやfacetをリクエストをするとき、通常は内部ではfieldCacheを使ってメモリ上で管理しますが、docValuesを使うとインデクシング時にfieldCacheのような構造を構築しとくので、sortやfacetが早くなりメモリも少なくて十分という話でした。 SolrCloud関連のアップデートとしては、カスタムシャーディング、シャードスプリッティング、Hadoopインテグレーションが最近の新しい機能のまとめとしてあがりました。 UpdateRequestProcessorについてはドキュメントを時間管理するプロセッサの紹介がありました。参考URL:DocExpirationUpdateProcessorFactory。 最後には、Apache Solr Reference Guideをwebだけでなくpdfでも活用してくださいとのことです。

続いて、SolrCloudのAWSでの構築に関するセッションがありました。ApacheConの開催中にコミッタになったTimothy Potterさん(Solr in Actionの著者)が、Pythonベースのコマンドソリューション(Fablic)でのデプロイデモをやっていました。(スクリプトはこちらのURLを参照:https://github.com/LucidWorks/solr-scale-tk) ZooKeeperとSolrのインスタンスを起動後、Solr付属のzkcli.shでコンフィグをアップし、Collections APIのCREATEアクションでSolrCloudのクラスタを構成する流れですが、上記スクリプトを順に叩くだけで自動でAWS上に構築できるというもので、使いやすくできていました。

またSolrCloudの全体の概要説明もあり、私としては復習に役立ちました。 Tipsとして役に立ちそうなものを次にあげます。１つ目は、リクエストパラメータにdebug=trackをつけることです。各シャードにどんなリクエストが発行されたかが見れます。２つ目は、コンフィグに変更があったらCollections APIのRELOADアクションはしなければならないということです。各ノードに最新の設定を反映させるアクションとなります。３つ目は、シャードスプリッティングの現状の仕様です。シャードスプリッティングは同一サーバ内でしか分割できないという制限があります。シャードスプリッティングする基準はドキュメント数、ドキュメントサイズ、インデクシングと検索の並行処理の考慮、シャード数変更やカスタムシャーディング変更のときです。私はシャードスプリッティングの効果が不明確でした。というのも同一サーバ内でインデックスを分割しても、結局そのサーバ内でCPUやメモリやハードディスクなどのスケールアップをしなければ、検索応答などで効果がないと思ったからです。それなので、開発に関わっているMarkさんに直接聞いてみました。今のところ、シャードスプリッティングしてこれを活かしてQPSをあげるようにするにはどうしたらよいでしょうという質問には、自分で別サーバにインデックスをムーブしてクラスタ再構築する、または単純にスプリット後にレプリカサーバを増やせばよいという回答でした。４つ目は、ALIASアクションの用途です。このアクションの用途はどこにもドキュメント化されていなかったのですが、今回わかったことは次の通りです。インデクシングのクラスタと、検索用のクラスタをわけて管理している状態があるとします。インデクシング側のクラスタは、シャード数の変更に伴うインデクシングや単純な再インデクシングをしている状態と仮定します。インデクシングが終わったら、インデクシングのクラスタと、検索用のクラスタをALIASアクションを使ってスワップさせます。クラスタを止めることなく、安全に最新のインデックスが検索用クラスタに反映できるというのが、このアクションの効果となります。

続いて、Markさんから現状のSolrCloudに関するセッションがありました。Solrはシングルサーバで開発をスタートしましたが、distributed Searchの実装がされ、distributedな書き込みもできるようになり、SolrCloudモードが発展してきたという歴史の説明がありました。一方、最新の追加機能の紹介がありました。最初はカスタムシャーディングです。マルチテナント対応で使え、ユニークキーで3レベルまで対応しています(tenant1!user2!test3!doc1のようにidを構成するとtenant1!user2!test3!のレベルで配送先シャードが決まるという機能です)。それから、HDFS上にインデックスを配置して、MapReduceを使うというHadoopインテグレーションです。まだ一部開発中なので詳細は明らかではありませんでした(別のセッションではHDFS対応してSolrCloudを実現する事例の紹介がありました)。また、Solrの機能ですが、SSLのサポートができるようになっています。SolrCloudの今後の対応としては、Collections APIの機能強化、シャードスプリッティングの機能強化、テスト強化、カスタムロギング対応、デバッグ強化などの対応があがっていました。私としては、SolrCloudは書き込み時、ZooKeeperのような２層コミットを実装していないから、レプリカでのインデクシングで失敗した場合(めったにないし、自動リカバリで復元されますが)、詳細なログ出力が必要だと思われ、その強化が期待されます。 そんななか、失礼だとは思ったのですがSolr 5.0の目玉機能はなんなのかとぶしつけな質問をしてみたところ、Markさんからはよくしらないと答えられてしまいました(質問が悪かったと思います)。とりいそぎテスト強化とかデバッグ強化とかいろいろタスクはあるので、継続的な改良が続くものと思われます。蛇足ですが、最近のメーリングリストではSolr WikiとReference Guideの統合のアイディアが議論されています。それから、SolrのWebサーバ化(Jettyをやめてwarファイルを提供しない)というSolr 5.0の仮ロードマップもあります。しかし、今後どうなるかはだれもわからないようです(Solr 4.x Deep Diveの著者で、メーリングリストで活発に活動されているJack Krupanskyさん談)。

続いて、ヘビーユーザの方から、ランキングカスタマイズのやり方のセッションがありました。シンプルな方法はboostクエリパーサを駆使して、ユーザ別にカテゴリ表示を変えたりするアイディアがありました。これでうまくいかない場合は、Luceneのクラスをラップして独自のスコアリングをするというアイディアおよび事例が提示されました。例では、LuceneQueryにスコアを問い合わせるときに、CustomScoreQuery(独自スコア計算)とCustomScoreProvider(ドキュメントを保持)を追加して、そこを通すという例がありました。また、LuceneQueryの中をカスタマイズしてそこに別途独自のスコア算出を書くという例もありました。インターフェイスは簡単に見えましたが、複数の各種メソッドの実装を満たさないといけないので、注意が必要とのことです。

続いて、LuceneをメインにコミットしているRobert MuirさんからLuceneに関するセッションがありました。Luceneはパッケージごとの概要説明、単語辞書の図(termとpostinglistの図)をいつものように使用して説明していました。私が知らなかったパッケージでmemoryというのがありました。クエリドリブンでドキュメント(ストリームも可能のようです)をメモリにインデクシングするという機能です。Elasticsearchのパーコレーターに微妙に似ているような、しかし違うような機能でした。Solrではこの機能を使った提案がされています。参考Jira:SOLR-4587。このセッションは全体の概要説明がメインで詳細には触れませんでしたので、目新しい機能は見受けられませんでした。

最後に、YonikさんからheliosearchのSolrディストリビューションのセッションがありました。目玉機能は、キャッシュのオフヒープ対応とfacetの機能強化です。キャッシュに関しては、最近の傾向としていろんなJavaライブラリがオフヒープ対応していること、GCチューニングはパラメータが多すぎるので管理しづらい、などの理由から、オフヒープによる実装が生まれたそうです。FieldCacheの機能は、ネイティブコードでかかれたnativeCacheが代用されます。その結果、ソートや関数クエリのあるリクエストに関して、QPSが現状のSolrより出るグラフを確認できました。効果がよければ、将来現状のSolrにポーティングすることは考えているようです。会場の質問でdocValuesの方がいいのではないかのという話もでましたが、docValuesはいったんLuceneでヒープにのっけているので、それよりいいはず、今度比較テストしてみたいというような回答でした。私は事前にYonikさんにオフヒープの場合、メモリはどう見積もればいいのかと聞いていたのですが、セッションでやるから見てほしいと回答されました。実際セッションであきらかになったのは、オフヒープ対応しているnativeCacheで、Admin UIのstats情報で、実際に使用しているバイトサイズが確認できるということでした。それなので、負荷試験をやれば、オフヒープメモリ量を見積もることができます。それからfacetの機能強化ですが、現状のSolrにあるStatsComponentを組み合わせた仕組みになった実装になっていました。本の売上の月次推移表(カテゴリ別)がfacetのリクエストを一回発行するだけで実現できます。これまでのfacetはドキュメントのカウント数を提示するだけですが、sumやavgなどの計算ができるようになっていて、非常に使いやすいものになっていると思いました。

Tika

1-2日目はSolr/Luceneのセッションが集中しており、3日目はTika/Nutchのセッションでした。私はTikaのセッションとTikaのハッカソンに参加しました。

Tikaはコミッタメンバの方から、一般的な概要説明と最新の機能に関する発表がありました。最新のTikaは、テキスト抽出に、スタンドアロンサーバで抽出するだけでなく、リモートサーバーを立ててそこで処理する機能が追加されています。バイナリファイルのテキスト抽出には、ファイルの種類によって各種パーサが専用ライブラリを使います。この時、OOMが発生するほどメモリを消費する場合があり、スタンドアロンを使う場合では他のアプリケーションに影響が出てしまいます。したがって別サーバで処理して返すという仕組みが実装されているとのことです。それから、バイナリファイルのエンベデッドなドキュメントの抽出ができるようになっています。PDFに他のバイナリファイルをアタッチしたり、エクセルに画像を付加したりできますが、このエンベデッドなオブジェクトを抽出できるという仕組みが実装されました。余談ですが、zipファイルも中身のドキュメントを抜き出ししてテキスト抽出ができます。最新のTikaではかなり充実した機能が実装されていることが理解できました。

その後、私はTikaのハッカソンに参加しました。専用の部屋があり、数人のコミッタや参加者がいて、仕様に関する雑談やらテスト・デバッグをしていました。私は、事前にコミッタのJukka Zittingさん(jackrabbit/PDFBox/Tikaなどのコミッタで、インキュベータ時代からManifoldCFのメンターをやっている方)との立ち話でお薦めされた経緯があったので、参加にいたりました。私が話したのは、言語判別機能-CJK言語の課題です。Tikaは言語判別機能を持っています。与えられたドキュメントが何語で書かれているかを判別してくれる機能です。Solrではこれを応用した実装があります。UpdateRequestProcessorなのですが、２つの別実装があります。ひとつはSolr本でご紹介しているもので、サイボウズ・ラボ社の言語判別OSSを使用したものであり、もうひとつは、Tikaの言語判別を使用したものです。日本では前者を使っています。理由はTikaの方がCJK言語の言語判別に未対応だからです。それなので、Tikaの方でもCJK言語をサポートしないかと相談しました。言語判別のための、コーパスから抽出した言語別リソースファイルが必要なのですが、現状Tikaではアジア圏のリソースファイルを持っていません。話を聞いたところ、単純にそのリソースファイルを作っていない、作れば判別できるはずという回答でした。そこで、その対応方法について教わりました。今後の過程で試してコントリビュートしたいと思いました。

私はまた、エンベデッドなイメージの抽出の方法を教わりました。PDFなどのバイナリファイルに貼ってあるイメージを抽出できないかという相談をしたところ、最新のTikaのEmbeddedExtractorで実現可能ということを教わりました。Tikaはテキスト抽出しかできないと思い込んでいたのですが、できるようになっていまして目からうろこが落ちました。私が現在取り組んでいる課題で、ManifoldCFを使ってさまざまなリポジトリからバイナリファイルを取得して、これをTikaを使って画像抽出し、弊社関口が開発したApache alikeを使って画像の特徴量抽出・ベクトル量子化・クラスタリングを行い、ここでできたデータをSolrに取り込んで画像類似検索を実現するというものがあります。画像抽出にTikaが利用できないと思っていたところでしたので大変すばらしいアイディアを教わった次第です。

そこでTikaのやり方を一緒に見てもらっていたところ、画像抽出が動きました。PPTファイルにある画像を抽出できました。よかったよかったといっていたら、今度はPDFでイメージが抜けないことが発覚しました。そこからペアプログラミングのようなスタイルで、コードを一緒に見ながら、ソース修正やデバッグテストしたりしました。私はコミッタの隣にいて、oh!とかgreat!とかいっていただけですが、コミッタの集中力を垣間見ることができました。そして解決に至りました(trunkにコミットされました)。参考URL:TIKA-1268。

一方、SolrではバイナリファイルからのインデクシングでTikaを使っています(aka Solr Cell)。これに関連して、2年前に弊社のお客様からあがってきて私がJiraに報告したチケット(zipファイルでencoding指定が正しくないと文字化けする、WindowsでつくったzipはSJISでないときれいに展開できない問題)があり、これは実際どうなのか、プッシュできるか伺ったところ、I/Fが大きく変更になる、UTF-8ベースなので、すぐ対応できないという話でした。こちらは再考の余地があります。参考URL:TIKA-936。　それから雑談でPDFBoxはAdobeのメンバでメンテをやっているそうなのですが、ときどきPDF側が仕様がかわるのでその対応であちこち直すことが多いといっていました。PDFBoxはたまにリグレッションが発生します。バージョンアップしたときに、特にCJK言語は一部文字化けしてしまう問題があります。ユニットテストでCJK言語をサポートしていないので、リグレッションの発見を見落とすのですが、これは今後の課題と考えることにしました。

今回のTikaハッカソンは、コミッタと話ができてソースを一緒にデバッグしたりしてとてもエキサイティングでした。セッションよりもコミッタと直接やりとりできるので、ハッカソンはぜひ今後も出たいと思わせる経験をしました。課題をもっているひとは、セッションを聞くよりもずっといいと考えます。結果私は、午後のセッションは全部スキップして、ハッカソンだけ参加ということになりました。

ASFの体制

現状、149 projects + 32 incubatorです。管理メンバは501 member /9board memberです。みんな基本ボランティアです。

ボランティアがコミュニティを強くしていく形をとり、ビジネス(企業/スポンサー)がバックアップする体制です。

コミュニティ内の仕組みとしては、PL-PG-Testerみたいなヒエラルキー構造でなくて、サークル構造で、最小限のルールを使ってバランスするのが望ましいということです。

パッチや仕様方針に関する決定に関しては、イシュートラッカー(Jira)やメーリングリストで十分な議論をしつつも、lazyなコンセンサス（コミット前レビュー&コミット後レビュー）も必要という心持ちで取り組みます。

Apacheのブランディングに関してですが、ApacheのOSSを利用したプログラムを提供する場合は、命名規則があります。「XXX tools Powered By Apache Solr」や「XXX plugin for Apache Solr」などのように命名する必要があります。重要なのは先頭の「Apache」を省略してはいけないということです。トレーニングやコンサルティングなどで使用するときは、省略できません(弊社ではトレーニングテキストでApache SolrやApache ManifoldCFと書いてあるので問題ありません)。イベントに関しては「Apache」を省略してよいとのことです。例:Lucene/Solr Revolution。

githubにApache Projectのミラーがありますが、基本的にはパッチは、pull requestでなく、Jiraにパッチを送るのがよいということです。Jiraではパッチをアップすると、コントリビュータとして認識がされるからです。 一部のプロジェクト(jackrabbit)では、githubからTravis CIを使って、パッチ適用:ビルド&テストを実行（jenkinsが設定が複雑だという理由でTravisを採用）し、Jiraにpull requestをコメントとして自動でアップロードしてパッチ適用する流れを試みています。

まとめ

以上、長文になりましたが、現状のLucene/Solr/Tikaを俯瞰でき、非常に有意義なセッションを聞けました。弊社トレーニングやコンサルティングで活かしていきたいと考えております。もし何か不明点がございましたら、弊社にお問い合わせください。