NaviPlus Engineers' Blog

NaviPlusのインフラ概要

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

サービスについて

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

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

サービス規模について

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

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

ファシリティ関連

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

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

ネットワーク構成

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

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

サーバ構成

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

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

OS/MW構成

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

レコメンドの構成

簡単な構成図

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

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

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

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

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

検索の構成

簡単な構成図

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

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

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

まとめ

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

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

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