Shopzillaにおける大量データのスケーリング (Oracle Coherence事例)
This blog entry is a Japanese translation of a blog entory "Data scaling at Shopzilla volumes" from Shopzilla Tech Blog.
このブログ・エントリは、Shopzilla開発チームのブログ「Shopzilla Tech Blog」のエントリ「Data scaling at Shopzilla volume」の日本語訳です。Shopzillaは、ショッピング検索エンジンです。
- Shopzilla
- Shopzilla Tech Blog > Data scaling at Shopzilla volumes (2010/01/06)
Shopzillaにおける大量データのスケーリング
他の大規模Webサイトと同様に、Shopzillaは、どのように大量データをスケールさせるか、そして、どのように高速にそれを行うか、というジレンマに苦しんでいます。最近では、これを行う多くの異なる方法がインターネットで広まっています。Cassandra、memcached、Hadoop、Oracle Coherenceなどです。我々は、ShopzillaでOracle Coherenceを選択しました。
我々のCoherence実装の素晴らしい例は、我々のサーチ・エンジンのためのドキュメント・サーバーです。我々は、これらのドキュメントのためにかなり単純なスキーマを持っています。それは、ドキュメントIDを表現する整数と、ドキュメントを表現する文字列です。これは簡単に聞こえますが、我々は各データ・センターで、1億2000万ドキュメントをほぼ即座の応答時間で処理する必要があります。サーチ・エンジンはドキュメントの要求をバッチ型で並列に発行します。そして、(サーチ・エンジンによる解析を含む) 単一の検索に対する全ドキュメント要求に25ミリ秒以上かからないように、ドキュメント・サーバーは、2.5〜3.5ミリ秒以内で各バッチ要求に応答します。これには、Apache Tomcat上で動作するJavaベースのWebサービス、ドキュメントや (シリアル化プロトコルのための) Cベースのパック・データ構造を格納するOracle Coherenceが含まれます。
我々は、このCoherenceグリッドのために、14台の2プロセッサ、デュアル・コアのサーバーを使っています。サーバー内のコアとRAMの利用率を最大化するために、各サーバーでは4つのJVM (コアあたり1つ) を実行しています。このグリッドは、フェイルセーフのままでいるために、「バックアップ・カウント」(訳注: 各データがいくつのバックアップを持つかを指定する、Coherenceの設定項目) を維持します。そして、このグリッドは、2台のマシンが停止してもデータ損失が起こらないために、余分なキャパシティを持っています。もしグリッドのリカバリ中にマシンが停止したら、もちろん小さなパフォーマンス劣化を招きます。しかし、トラフィック処理は継続され、グリッドは自動的にリカバリを行います。
我々は、1日に数回、検索インデックスを構築しています。以前は、ドキュメント・サーバーのインデックスを更新するために、検索クラスタをオフラインにする必要がありました。我々は今やCoherenceを使っているので、中断なしに、そしてパフォーマンス劣化なしに、グリッドにデータを配置できます。
旧システムでは、インデックス更新の間に、応答時間に明らかなスパイクが見られました。
図: インデックス更新の間の応答時間
新システムでは、パフォーマンス劣化なしにデータのロードと処理が可能です。次のグラフにおける応答時間を見れば、これは明らかです。(訳注: 2つの図の縦軸のスケールの違いに注意)
図: データ・ロード中の応答時間
Coherenceは、我々のWebサービスのプロトタイプを利用して、レガシーのSSDベースのSANとレガシーのドキュメント・サーバー・コードを、短期間で新しいアーキテクチャで置き換えることを可能にしました。我々は、2週間のイテレーション1回で、本番環境のトラフィックを処理しながら置き換えをオンラインで完了しました。
オラクルのサポート・スタッフは、我々の問題に対して非常によく対応してました。我々はこの新興技術を受け入れ、我々の継続的な拡大と将来のための素晴らしいパートナーを得ました。
我々は、このテクノロジー・プラットフォームへの投資を継続します。Oracle Coherenceは、我々の設計とアーキテクチャの中でメジャー・プレイヤーであり続けることは確実です。
