NaviPlusのインフラ概要

投稿者: | 2014年1月31日

インフラ担当の池田(@mikeda)です。
今回はNaviPlusのインフラの概要的な話をします。

サービスについて

まず提供しているサービスについてです。
他にもいろいろあるのですが、メインはレコメンド(NaviPlusレコメンド)検索(NaviPlusサーチ)です。
どちらも主にECサイト向けのASPサービスです。

  • レコメンド:顧客のアイテム情報、ユーザの行動履歴からオススメ商品/ランキングなどを生成する
  • 検索:顧客のアイテム情報を検索できるようにする

システムはレコメンドと検索で大きく異なっています。
なぜかというと、検索系のシステムは1年前にコトハコという会社を買収して吸収したものだからです。
なので以降の話はそれぞれ別々の説明になること多しです。

サービス規模について

まずアクセス数と物理サーバ台数についてザックリと(2013年12月現在)。

  • レコメンド
    • アクセス数:10億/月〜
    • 物理サーバ台数:100台〜
    • ピークトラフィック:50Mbps〜
  • 検索
    • アクセス数:3億/月〜
    • 物理サーバ台数:30台〜
    • ピークトラフィック:60Mbps〜

テキストメインのサービスなのでトラフィックは少なめですね。

ファシリティ関連

都内のDCでラック借りしてます。

ネットワーク周りは基本的にDCまかせ、サーバ周りは購入から監視まで全て自社運用です。
※とはいえNW機器についても各種ログイン権限はもらってますし、NaviPlus側からSNMP/syslogを使った簡単な監視もやってます。

ネットワーク構成

いろいろ端折った構成図を。

diagram_network

細かい説明は今回は割愛します。

サーバ構成

サーバ筐体はDELL/HPの1Uサーバがメインで、特に変わったことはしてないです。
最近、SSDを導入しようと検証中です。

VMWare、KVMを使った仮想化も実施してます。検索系は基本仮想化、レコメンド系は状況に応じて使い分けです。

OS/MW構成

新規導入するサーバについては基本的にOSはCentOS 6.4、DatabaseはMySQL 5.5を使っています。
※古いサーバについてはCentOS 5.xやMySQL 5.0/5.1系も結構残っています。

レコメンドの構成

簡単な構成図
diagram_reco

この構成をベースとしたクラスタが複数個あります。
図では省略しましたが、他にも内部検索用のSolr、クロール用のHeritrix、冗長化のためのkeepalivedなども使っています。

App/BatchはRubyで記述されています。
ただバッチで特に計算量の多い部分はJava、Appの一部の重たい処理はC言語(RubyのExtension)を使うことでコーディング速度と処理速度のバランスを取っています。

データストアはけっこういろいろあって、用途に応じて使い分けています。

  • MySQL(管理用):各アカウントの基本情報と設定値を格納
  • MySQL(サービス用):アイテム情報、レコメンド/ランキングなどの集計結果を格納。アカウントごとに別の論理DBを分割。必要に応じて台数の増減、論理DBの移動ができる
  • Cassandra:ユーザの行動履歴など、頻繁に更新される情報を格納
  • Solr:アイテム情報の検索などに使う。内部向け
  • memcached:各種計算、他のデータストアの参照結果をキャッシュする

MySQLはActive/Standby構成です。
少し変わったこととしては、フロントのAppサーバからは基本的にMySQLを更新しません(Appはログを出力するのみで、別途バッチ処理で更新しています)。
その目的の1つは無停止でDBメンテナンスを行うことです。
リアルタイム更新が無いため、DBサーバの入れ替えやデータの移動は、以下の手順で無停止に実行できます。

  1. バッチを停止
  2. Slaveからダンプ取得し、移行先DBサーバにリストア
  3. DBの接続先を変更

検索の構成

簡単な構成図
diagram_search

こちらも同じ構成のクラスタが多数存在します。

App/Batchは基本的にPHP(フレームワークは独自開発)で記述されています。
サービスのコアであるSolrに近い部分についてはJavaも使われており、一部モジュールを独自に追加開発しています。

こちらもフロント系のAppからは基本的にデータの更新はなく、顧客アカウントのクラスタ移動などは無停止でできるようになっています。

まとめ

レコメンド、検索と2つの異なるシステムがあるものの、どちらも基本的にはよくあるWEBサービスです。
ASPという特性からくる特徴はこのあたりです。

  • テキストメインで、画像などの静的ファイルがほぼない
  • 無停止運用を前提に作られている

『困ったらサービス止めて深夜メンテナンス』という手が使えないので、運用設計にはとても気を使っています。

というわけで今回はここまでです。
サーバ構築、監視など運用系の話はこれからちょっとずつ書いていこうと思いますので、お楽しみに!

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA