BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル LinkedIn Signal: Scala, JRuby と Voldemortのケーススタディ

LinkedIn Signal: Scala, JRuby と Voldemortのケーススタディ

ブックマーク

原文(投稿日:2010/10/11)へのリンク

9月29日に、LinkedIn Signal がアナウンスされた。これはLinkedIn の共有情報と つぶやき用のソーシャル検索アプリケーションで、 LinkedIn-Twitter の限定されたアカウントに提供する。この記事では、 Scala, JRuby と Voldemortをこのような規模で組み合わせた、その動機と技術的な挑戦について深い知見を提供するつもりである。

John Wang氏は、 LinkedInの Search Architectで全システムのアーキテクチャ概要を公開した。

Scalatraのバックエンド は、Sinatraフレームワーク上のScalaで書かれたRESTfulサービスである。速いイテレーションのために、 REST/JSON RPCモデルを使って、高速にアドホックなデータ操作ができる。

Rubyのフロントエンド を選んだ理由も速いイテレーションのためである。

ファセット装飾に使われるデータは、かなりが静的で小さく、サービス抽象の裏側にBDBインスタンスを置くだけである。

保存検索とフォロー機能は、開発の後半で考えた機能で、我々は、確実にスケーラブルで、弾力的なものをすぐに走らせたいと思っていた。我々のクエリ アクセス パターンがキーと値の保存に完全に合うので、 Voldemort が明白な選択肢となった、さらに Voldemortのデータ-再バランスと弾力的なフィーチャは、予想されるデータの増大に、適したものだった。

データ ストリームは、 LinkedInの情報共有、限定アカウントからのつぶやき、LinkedIn のプロファイル、そしてメンバーによる情報の集合である。

実際の検索システムの実装は、新しいサービスの最もやりがいのある部分だった。そこで、チームは、LinkedInの検索、ネットワークと分析チームの部分である、いくつかの製品を利用しなければならなかった。以下のものを利用した。

  • Apache Lucene をテキスト検索に
  • Zoie をリアルタイムなインデックス付けに
  • Bobo をファセットの検索に
  • Sensei を動的にクラスタリングできる、分散型リアルタイム検索可能なデータベースに

これらの製品がどのように構成され、統合され、そしてカスタム ソフトウェア用に拡張されたかを詳細に示すことに加えて、John氏は、記事のランク付けアルゴリズムがどのように動くかを説明している。

数イテレーションして、システムは負荷があっても非常によく維持できているように見えたのですが、我々は、つぶやきストリームをスパムしている人たちの影響を受けていることに気がつきました。簡単な例が、個人で、あるurlを何千回も上流へ「共有する」ことで、自分で昇格することをやっているわけです。「共有」カウントを余りに重要視する点数スキームを使っていたので、これは単純に我々のシステムに影響してました。簡単に言うと、純粋に共有に基づいた人気測定は、ランク付けには、充分なものではありませんでした。

共有へのスパムに対して、すぐ思いついた解決は、ある記事の全共有データ中にユニークな個人が、何人なのかを測定しようという試みでした。一面では、このアルゴリズムは、記事を共有しているユニークな個人の数も考慮して、記事をランク上で昇格し、一人の人間が露骨に多数共有しているような記事は、降格する、というものです。今や結果は、素晴らしいものになりました。

InfoQは、 LinkedIn Signalのデプロイを担当している人達にプロジェクトについて聞いた。

InfoQ: フロントエンドでどのようにJRubyを使っているのですか?何か特別なフレームワークを使ってますか?

Alejandro Crosa (JRuby/Scala expert @ LinkedIn): 現在、フロントエンド層は、非常に薄くて、セッション状態、バックエンドのサービスへのテンプレート化と、よりハイレベルな抽象化、そしてREST APIを提供しています。JRubyを選んだ主な理由は、速く開発、テストでき、そして柔軟に表現できるコード、簡単にJavaと統合できること、そして両方の世界のライブラリを活用できる能力の3つの重要なことからですね。我々が使っているwebフレームワークは、Sinatraです。我々がやりたいのは、アプリケーション用に、非常に単純で最小限のRESTインターフェースを持つことです。

InfoQ: フロントエンドのどのくらいがScalatraで、どのくらいがJRubyなのですか?なぜ片方だけ使うより両方組み合わせた方が有益だと考えたのですか?

Alejandro Crosa: JRubyは、公開APIとフロントエンドのフィーチャにしか使ってません。一方、Scalatraは、きれいなRESTfulのやり方で、バックエンドのAPIを見せるために使っています。これは、我々がアプリケーションで繰り返しやってきたパターンで、最高のツールを使って、特定の仕事をするためのサービスを作り、それらをきれいなRESTful APIでラップします。

また、バックエンドは、パフォーマンスが全てですから、インタープリットされたコードによる代償を払いたくありませんでした。フロントエンドのようにイテレーションを繰り返していません。バックエンド サービスを作るときには、Scalaの型システムを使うのが最高ですね。一般に、ドメインの問題(業界の汚点)にかかわらず同じツールを使わずに、我々は特定の要求に最高のツールと考えられるものを選びます。

InfoQ: LinkedInでScalaの経験をすごく積んできて、それを採用しようと考えているチームに何かアドバイスがありますか?どんな共通の落とし穴があり、既存のJavaのインフラとどのようにいっしょにすればいいですか?

Alejandro Crosa: 私は、Rubyの世界から来て、言語的に似たようなフィーチャをたくさん目にします。あるフィーチャは、本当に魅力的です。最近、Scalaは、余りに複雑だ、と考えられていますが、言語のコアは、非常に単純で、自分が使いたいフィーチャは、どれで、使いたくないのがどれだ、と選ぶことができます。非常に単純で最小限のコードも書けますし、極めて読みにくいコードも書けます。それは、開発者の決断次第です。開発者レベルで非常に変わります。

共通の落とし穴はですね。Scalaを大々的に使うのは間違いだと思います。特にもしJavaのレガシー コードがたくさんある場合、それを移行する切実な理由を見つけるのではなく、Scalaが優れている特定のドメイン問題に適用するのです。もしScalaをただJavaを使うように使うだけなら、ただコード量減るだけです。不変性、関数型データ構造、パターン マッチング、Actorなどを使ってください。もう前には戻れなくなりますから。

Chris Conrad (Scala expert @ LinkedIn, Creator of Norbert): ほとんどの点で、私は完全に Alejandroの意見に賛成します。Scalaは、仕事をするのに、素晴らしいプログラミング言語ですし、非常に強力な能力を提供しています。しかしもし単にJavaをScalaのシンタックスで書くなら、無駄な投資になりますね。

Norbert は、私にとってScalaが使えるいいプロジェクトでした。それは、かなり小さく、自分でコントロールできるプロジェクトでしたので、私は時間を使って、Scalaの色々なフィーチャを試して、自分が求めている最善のAPIの表現方法を検討できました。そしてScalaはJavaと緊密に、きれいに統合しているので、Javaの開発者が Norbertを使えるように、きれいなJava固有のAPIを提供することができました。

Scalaを使い始めようとしている人への私のアドバイスは、小さくて自分がコントロールできるような機能を探して、プロジェクトの中で実験することです。Scalaをいかに効果的に使うかを学ぶには時間がかかりますし、学習を完全に終えるまでは、重要な部分をScalaで実装して、プロジェクトを不安定に、したくないでしょう。ScalaとJavaの統合を活用して、Scalaでそのような部分を実装できます。Scalaを学ぶ必要のある組織の他の人々が学習を終えるのを待つ必要はありません。

落とし穴について言えば、一番共通しているのは、Scalaのオブジェクト指向と関数型が混在した性質に関することですね。プログラマは、いつプログラムをオブジェクトを使ってモデル化すべきか、いつプログラムを関数型を使ってモデル化すべきか、そしていかに2つ一緒に組み合わせるかを時間をかけて学ぶ必要があります。個人的には、 Norbertを書いている時には、あるコードを何度も行きつ戻りつして、Scalaを使うことに慣れていきました。

InfoQ: 同様に、キーと値の保存を考えているチームへのアドバイスがありますか? Voldemortは、かなり新しいシステムであり、荒削りのところもあるかもしれませんから、採用する前に考えるべきことはなんですか?

Jay Kreps (author of Voldemort): 成熟するのに5~10年かかっている標準のデータベースに比べれば確かに新しいですね。私はインフラのどの部分の信頼性も、ソフトウェア、それをプログラムするエンジニア、それとそれを走らせる運用専門家の組合せで決まる、と本当に思っています。新しいインフラのいくつかの問題は、ソフトウェアの問題ですが、多くの(私はほとんど、と言いたい)問題は、ユーザやオペレータの知識不足です。MySQLの強みは、問題がない、ということではありません。そうではなくて、問題が使っている人達によって理解されている(そして回避されている)、ということです。

この点では、 Voldemortは、 LinkedInではそう新しくはないのです。2008年の終り頃から製品で使ってきています。

それでもなお、Oracleでは変更が起きた場合に実施するQAサイクルは、非常に徹底して、厳格なので、どのようなオープンソース技術もソフトウェアの信頼性では、本質的に太刀打ちできません。新参者は、パフォーマンス、スケーラビリティ、そして値段で競争できるだけです。しかしスケーリングについての共通のソリューションは、データベース(MySQL、Oracleあるいは何であれ)の上にカスタムな sharding層を設けることです。一度こうしてしまえば、カスタムなソフトウェアをいくら混在しても、全く同じリスク領域にいることになります。そしてカスタムなsharding層の実装を比較すれば、私は、 Voldemortが一番良く設計され、テストされ、そして全体で安定している、と思います。

Alejandro Crosa: Jayが非常によく答えてくれました。

私は、ユーザ視点で付け加えましょう。あらゆるオプションの中で(そのほとんどがかなり新しいですが)私はVoldemortは、安定性とフィーチャ セットの点で最も堅牢です。私が思う唯一の問題は、導入ですね。そのフィーチャ リストにあるものが本当に高機能だからです。例えば、ストレージ層は、プラグイン可能ですから、現在使っているMySQLのストレージとこれまでの投資を使い続けられます。そして Voldemortの提供するすべてのフィーチャも使えるのです。

JRuby, Scala, Voldemort そして Scalatra についてもっと知りたければ、まさにこのInfoQを読んでください。

この記事に星をつける

おすすめ度
スタイル

BT