当ブログをご覧のみなさまこんにちは。さくらインターネット研究所の大久保です。

以前お知らせしました通り、2010/7/1より当研究所にて「KVSアルファテストサービス」を開始しました。今回はこのサービスのシステム構成について解説してみます。

▽ 参考: KVSアルファテストサービス https://research.sakura.ad.jp/kvs-alpha/

システム概要

上記のURLにもありますように、このサービスは弊社が運用するKVSクラウドへインターネット経由でmemcachedプロトコルにてアクセスできるデータベースサービスです。

このKVSクラウドが実際どのようになっているかといいますと、以下のように6台のサーバから構成されています。(ストレージサーバの数は負荷やデータ容量見合いで増設することとなっています)

KVSのソフトウェアは、これまで解説してきたグリーさんのFlareを用いています。 ルータ配下の同一ネットワーク上に、インデックスサーバ1台とストレージサーバ(兼プロキシサーバ)4台、それからロードバランサ1台の計6台のサーバを設置しています。

ストレージサーバ群は2つのPartitionに分割しており、各パーティションにマスターとスレーブの2台で計4台となります。

※ ストレージサーバとプロキシサーバは分けたかったのですが、サーバの都合上兼用することになりました。

お客様からのアクセスは一旦ロードバランサで受け、ストレージサーバ4台に負荷分散します。ストレージサーバはロードバランサにて死活監視されており、いずれかがダウンすると、別のサーバに振り分けられます。

お客様がアクセスするサービス用のIPアドレスは、ロードバランサだけでなく、ストレージサーバのループバックインターフェイスにも設定しており、DSR方式で負荷分散されます。

表にまとめるとサーバ構成は以下の通りとなります。

マルチテナント化の実現

2010/9/27現在で、12ユーザのFlareインスタンス(テスト用も含む)がこの6台上で稼動しています。

同一のサーバ上で複数のユーザを収容するためには、データの分離やアクセス制御を適切に行う必要があります。これには、以前ご紹介したポート番号を分けて複数デーモンを起動する方式と、お客様に提供するポート番号毎に接続元のIPアドレスを制限する方式を組み合わせることで実現しています。詳しくは以下のブログをご覧ください。

▽ Flareを使う(マルチテナント化編) https://research.sakura.ad.jp/2010/08/10/flare-multi/

Flareの設定

Flareのインデックスサーバ、ストレージサーバはそれぞれ以下のような設定を行っています。

• インデックスサーバの設定例(flarei.conf)

  data-dir = /home/flare/user**
  log-facility = local0
  server-name = 192.168.12.232
  server-port = *****
  
  monitor-threshold=3
  monitor-interval=1
  monitor-read-timeout=1000

• ストレージサーバの設定例(flared.conf)

  data-dir = /home/flare/user**
  log-facility = local0
  storage-bucket-size = 16777216
  storage-large = true
  index-server-name = 192.168.12.232
  index-server-port = *****
  server-name = 192.168.12.**
  server-port = *****

特別な設定は何もありませんが、ユーザ毎に別のディレクトリ、ポート番号を割り当てています。ストレージサーバの”storage-large”はこれまで説明していませんでしたが、TokyoCabinetのオプションで64GB以上のデータファイルを扱うために必要となるものです。

なお、上記の設定とFlareデーモンの起動、それから役割設定は、新規ユーザ設定のコマンドを1行叩くだけで自動的になされるようなシステムを別途組んでいます。

ロードバランサの設定

ロードバランサはLinuxで標準的に用いられるIPVSとkeepalivedを使用しており、アクセス制御はiptablesを使用しています。設定例を以下に示します。

• keepalivedの設定例(keepalived.conf) ※ 下記をユーザ数分設定しています。

  # flare user1 configuration
  virtual_server 61.211.**.** 13*** {
  delay_loop 10
  lb_algo rr
  lb_kind DR
  protocol TCP
  
  real_server 192.168.12.233 13*** {
  weight 1
  inhibit_on_failure
  TCP_CHECK {
  connect_timeout 3
  delay_before_retry 5
  }
  }
  
  real_server 192.168.12.234 13*** {
  weight 1
  inhibit_on_failure
  TCP_CHECK {
  connect_timeout 3
  delay_before_retry 5
  }
  }
  
  real_server 192.168.12.235 13*** {
  weight 1
  inhibit_on_failure
  TCP_CHECK {
  connect_timeout 3
  delay_before_retry 5
  }
  }
  
  real_server 192.168.12.236 13*** {
  weight 1
  inhibit_on_failure
  TCP_CHECK {
  connect_timeout 3
  delay_before_retry 5
  }
  }
  }

  virtual_serverはお客様に見せているサービス用のIPアドレスとポート番号を、real_serverはストレージサーバ4台を指定しています。また、今回はDSR方式を使用しますので、lb_kindはDRを指定しています。

• iptablesの設定例

  -A INPUT -s **.**.**.** -i eth0 -p tcp -m tcp --dport 13*** -j ACCEPT
  -A INPUT -s **.**.**.** -i eth0 -p tcp -m tcp --dport 13*** -j ACCEPT
  -A INPUT -s **.**.**.** -i eth0 -p tcp -m tcp --dport 13*** -j ACCEPT
  -A INPUT -i eth0 -p tcp -m tcp --dport 13*** -j DROP

  アクセス元のIPアドレスの数だけACCEPTの行を書き、最後にDROPでそれ以外のIPアドレスからのアクセスを拒否しています。ポート番号毎(ユーザ毎)に上記を設定しています。

Flareの設定と同様、上記の設定も自動的に生成されるようになっています。

コントロールパネルの提供

このサービスでは、格納しているレコード数やデータ容量を確認したり、キーの一覧を取得したり、接続元IPアドレスを変更したりするためのWebインターフェイス(コントロールパネル)を提供しています。画面イメージは以下のようになっています。

まだプロトタイプですが、レコード数、データ容量は過去3日間表示され、接続元のIPアドレスを変更すると、即時にロードバランサのiptablesのルールに反映されるようになっています。

利用例の紹介

弊社社長の田中がこのサービスの1ユーザで、以下のサイトで生成された画像をKVSに保存しているとのことでした。

▽ とある櫻花の画像生成（ジェネレーター） http://to-a.ru/

まとめ

今回はKVSアルファテストサービスの詳細について説明しました。 こちら、まだ申し込み受付をしておりますので、試してみたいと思われる方は是非ご利用ください。