ガジェット通信

見たことのないものを見に行こう

リクルート全社基盤アーキテクチャ、最適検索スコア導出、Ansible vs Chef-Solo、Node.js Stream─リクルートテクノロジーズ社内勉強会

DATE:
  • ガジェット通信を≫

偽陽性判定のアルゴリズム「Bloom Filter」を検索基盤に活用

最初に登壇したのは、守谷純之介さん。リクルート全社検索基盤の開発に携わっており、「検索、検索、検索」の日々を送っている。

▲株式会社リクルートテクノロジーズ アプリケーション・ソリューショングループ 守谷純之介さん

全社基盤アーキテクチャに採用されている技術については、『リクルート 全社検索基盤アーキテクチャ』で検索してみてほしい。

今回の発表テーマは「Bloom Filter」。Bloom Filterとは要素が集合に含まれるか否かを判定するためのデータ構造であり、偽陽性(False Positive)のアルゴリズムである。

偽陽性とは図を見ればわかるとおり、「『H9K4H9』はある?」という問い合わせに、「あります」という回答の場合はあやしいという判断となり、「ないです」という回答だと本当にないので、正しいという判定になる。

Bloom Filterは、Akamai、Google BigTable、Google Chrome、Apache Lucene、Apache Hadoop、Oracleなどいろいろなところで使われている。

原理は次の通りだ。Bloom Filterはm個のビットからなるビット配列で、初期状態では全て0となっている。次にk個のハッシュ関数を定義する(k個のハッシュ関数を準備する必要はなく、異なるk個の初期値でもよい)。

1つの要素を追加するとk個の1が登録される。そして要素が含まれているかどうかは、k個のビットが1であるかどうかを検索することで判定する。

例えば、図のように「ア」と「イ」を登録する。

この状態で「ウ」はあるかというと、図を見ればわかるとおり、「ない」という判定が返される(正しい)。

一方、「T」はあるかと問い合わせると、「ある」と判定され、正しくないという結果になるというわけだ。

ハッシュ関数としてはMurmurやFVN、Jenkins Hash、MD5などがあるが、これらの初期値をk個準備して、値をmで割ればよい。

また実際にどのようなフローになるかについては、2つのパラメータを用意するだけで簡単に実装できる。

実際の誤り確率については、次の式で表されるため、登録する件数が増えれば増えるほど、誤りは大きくなるが、ビット配列長が1MByteでハッシュ関数が8個、要素数が100万個の場合、誤り確率は1.7%となる。ないときはないと正しく言ってくれる。実装工数もかからないので、使える技術だ。

ユーザーに最適な検索スコアを返す仕組みはどうつくる?

続いて登壇したのは、リクルートテクノロジーズで検索改善を担当する大杉直也さん。テーマは「最適な検索スコア導出のためのアイデアとその実装」。

▲株式会社リクルートテクノロジーズ アプリケーション・ソリューショングループ 大杉直也さん

最適な検索スコアとは、当たり前と言ってしまえば当たり前だが、ユーザーが欲しい情報を出すこと。つまり結果はユーザーによって変えることが求められる。

ではそれをどうやって実装するか。実装の方法には、バッチで計算すべき計算スコアと、リアルタイムで計算すべき検索スコアがある。ここではECサイトの商品を例に、検索スコアの考え方が紹介された。

バッチで計算すべきものとは、定数項となるような値、複雑なモデルで導出する場合、性能の劣化が許されない場合などに使われる。

一方多種多様なユーザー属性に応じたスコアや検索行動(絞り込みやフリーワード検索など)に応じたスコア、更新頻度が高い情報に基づくスコアなどは、リアルタイムで計算すべきだという。

リクルートテクノロジーズでも、現在、ユーザーに応じたアイテムを返す検索インフラを構築している。それが「QASS」だ。これは図を見ればわかるとおり、クエリに応じて計算式を変える仕組みとなっている。

一番大切になるのが、書き換えルール集である。無停止・高速リリースを実現するため、「書き換えルール集は外部化している」という。書き換えルール集については引数(検索行動やユーザー属性)、出力(Function Queryのモデルを計算)で、現在実験をしているそうだ。

Function Queryそのものを出力する計算は非現実的なので、Function Queryのテンプレートを作ることで、各パラメータ最適化問題に帰着した。

検索インデックス内の情報の重み付き線形和として、この思いを検索行動、ユーザー属性に応じて最適化する方向で考えているという。あとはテンプレートをどうするかということ、どう最適化することだ。

テンプレートの作成については既存のアイテムインデックス内で使えそうな情報を探し出すことを行っているという。例えばECサイトの場合であれば、送料無料か否か、翌日の配送が可能か否か、レビューの件数、価格帯などを洗い出し、これに既存のコンバージョン(CV)予測値+フリーワード紐付けジャンルの線形重み付けでテンプレートを作成する。

そして、このテンプレートの値を変更することでコンバージョンレートの増減を確認し、最適化すべき対象を決定していくというわけだ。最適化については、検索結果画面に表示された商品のうちでのクリック予測という問題に置き換えた。

つまりその商品がクリックされたか、されなかったかというターゲット変数を機械学習のテクニックを使って予測させるというわけだ。

最適化の計算はPythonのChainerを使ってDeep Learningのネットワークを工夫し、実装しているという。

構成管理ツール「AnsibleとChef-solo。どちらが使える?」

三番目に登壇したのは、北野太郎さん。セッションタイトルは「実録 Ansible vs Chef-Solo」。

▲株式会社リクルートテクノロジーズ ITソリューション統括部インフラソリューション部 北野太郎さん

北野さんは、Qassインフラやリクルート共通インフラの自動化、新規導入ミドルウェアの検証などを担当している。インフラ構成管理ツールとしてAnsibleとChefの使用感を実際に利用した立場の紹介から、セッションがスタートした。

構成管理ツールとは、主に次の2つの目的をするためのツールだ。1つはサーバ構築の自動化、そしてもう一つがサーバ状態のコード化である。

利用するメリットも、コードがそのまま構築手順になる、誰が何度やっても同じ状態(環境)に収束する、環境の履歴を管理できる、今の設定を、実機を見ることなく確認できる、テストに応用できるなどたくさんある。

Python製の構成管理ツールであるAnsibleは2012年2月20日に初回リリースされ、最新バージョンは2.0.0。特徴は中央集約型でYAML形式の設定ファイルが用意されており、人による質のバラツキがなくなること、設定ファイルがない、導入が容易、などが挙げられる。

一方のchefはRuby製の構成管理ツールで2009年1月15日初回リリースされた。最新バージョンは12.5.1(クライアント)、12.2.0(サーバー)となっている。

Chef-soloは最新版では存在せず、Chef-clientのlocalモード(Chef-Zero)が後継扱いになっている。また「元はてなのCTO伊藤直也さんなどが使えるのではといったことで爆発的に広がった」と北野さん。

Chef-soloの特徴はスタンドアロン型、Ruby形式の設定ファイル、豊富な文献などと一般的に言われている。

導入および実行の容易性については、Ansibleはプロビジョニング対象サーバにクライアントの導入が不要というメリットはあるため導入は容易になる。

設計については、複数サイト/複数サーバ導入を踏まえた設計の柔軟性については、いずれも同じ思想にいきつくため、いずれを選んでも構成は同じようになるという。

ただ複数サーバ導入を踏まえたスケーラビリティについては、Ansibleは多重度が設定可能となる。これらを総括するとAnsibleの方がメリットはある。

利用者から見た導入のしやすさについては、Ansibleの方が最小限の構成で動作するので、手軽に始めやすいが、実運用を見据えた場合は結局同じような構成が必要になる。

利用者から見た設計のしやすさについては、Ansibleはディレクトリ構成、Chefは中の実装が人依存になりがちだ。

その他、Ansibleは定義済みのホスト一覧を外部から取得し、プロビジョニングの対象にすることができる、各タスクにタグを付け、タグで絞り込んだものだけ実行可能できるという柔軟性も持っている。

また運用への応用として、ホストの一覧情報を持っており、タスクの一斉実行が可能という特徴も持つ。

実際に利用した感想としては、中央管理型で複数サーバにプロビジョニングできるAnsibleが便利だ。特に便利だったのが、中央管理でサーバ群に対してプロビジョニングをAnsibleだけで実現できる点だという。

ミドルウェアの再起動など他の運用にも使えるということでちゃんとできることや、タグやダイナミックインベントリとか追加で便利な機能が多いことも挙げられた。

現在、リクルート基盤のインフラではAnsibleを使って自動化を推進中で、機会があれば大規模インフラにおける自動化のノウハウを共有していくとのことだ。

Node.js Streamはどう使える?

最後に登壇したのは、伊藤瑛さん。「Node.js Streamについて」というタイトルで5分間のLTを展開した。

▲株式会社リクルートテクノロジーズ アプリケーションソリューショングループ 伊藤瑛さん

伊藤さんは15年度の新卒入社で、Node.js歴は6カ月。現在、Node製の大規模Push基盤Pusna-RSの運用開発に携わっている。

Stream APIとは、データの流れをキレイに扱うためのAPIで、データを一括で読み込むのではなく、破片ごとに読み処理することができる。また、各Streamをpipe()で連結することも可能だ。

活用例としては、現在、Push通知基盤Pusna-RSではDBから大量のデータの読み込み配信依頼を行う一連の処理をStreamで実装している。

Streamの良い点はたくさんあるが、あまり知られていない活用法として、非同期処理をStreamでラップすることができることだという。

ちょっとしたTipsとして、データベースにクエリを投げる際のリトライ処理に使うと便利ということも紹介された。

ブラウザにもStreamが実装されている(ただ、Node.jsのStreamとは仕様が違うとのこと)とのこと。「今後も注目してきたい技術」と語り、LTは終了した。

関連ページ

リクルートテクノロジーズが「IT総合職」を募集!
リクルートテクノロジーズ エンジニアブログ

カテゴリー : デジタル・IT タグ :
CodeIQ MAGAZINEの記事一覧をみる ▶
  • 誤字を発見した方はこちらからご連絡ください。
  • ガジェット通信編集部への情報提供はこちらから
  • 記事内の筆者見解は明示のない限りガジェット通信を代表するものではありません。

TOP