R&Dトレンドレポート

第5回 分散環境でTokyoCabinetを動かす─2

この記事を読むのに必要な時間:およそ 3 分

前回はkumofsを用いて分散環境を構築し,単純に動作させるところまで書きましたが,今回はkumofsのスケーラビリティ,アベイラビリティという視点で操作してみます。

kumofsのスケーラビリティ

前回,3台の構成でkumofsを動かしました。おさらいしておくと,以下のような構成となっています。

kumofsは3種類のデーモンで構成されます。

kumo-server実際にデータを保存するノード。少なくとも1台必要です。後から追加できます。
kumo-managerkumo-server群を管理するノード。1台または2台で動かします。
kumo-gatewayアプリケーションからのリクエストをkumo-serverに中継するプロキシ。アプリケーションを動かすホスト上で,1つずつ起動しておきます。

ここでもドキュメントのチュートリアルに従って,進めたいと思います。私の環境でも同様に3台のサーバを用いて環境を構築します。

サーバkumo-managerkumo-serverkumo-gateway
serv1
serv2
serv3

この構成に新規にserv4を追加してみたいと思います。また,追加時にどのようなオペレーションが必要となるか,データの損失が無いかを確認してみましょう。

serv4に前回と同様に環境をセットアップします。こういうときに仮想マシンは便利ですね。コピペ感覚で新規マシンを立ち上げられるんですから。ここでも前回と同様にこちらを参考に手順を進めてみます。

今回新たにserv4を作成しました。これを用いて下記のような構成をとってみます。

サーバkumo-managerkumo-serverkumo-gateway
serv1
serv2
serv3
serv4

その前に,前回の構築状態を確認してみたいと思います。kumofsには便利なユーティリティが付属しており,サーバの状態を把握することができます。

分散環境のどのサーバにデータが格納されているかを確認してみたいと思います。現在の構成は3台がkumo-serverです。さらにレプリケーション数も3となっていますので,1つのデータが3台のサーバに分散されることになります。

確認のコマンドはkumohashを使用します。

[waki@serv1 $ kumohash -m serv1 assign name
ca2d0d2a5599e96a name
0: 192.168.47.101:19800
1: 192.168.47.102:19800
2: 192.168.47.103:19800

nameというキーのデータはserv1, serv2, serv3に分散されていることがわかります。レプリケーション数とあっていますね。問題なさそうです。

それではサーバの追加です。serv4でkumo-serverを起動し,serv1でattachするという順序です。

# kumo-server -v -l serv4 -m serv1 -p serv2 -s /var/kumodb.tch

serv1でステータスを確認します。

$ kumoctl serv1  attach

新たにサーバが追加されました。非常に簡単ですね。

[waki@serv1$ kumoctl serv1 status
hash space timestamp:
  Fri Aug 13 19:57:04 -0400 2010 clock 43217
attached node:
  192.168.47.101:19800  (active)
  192.168.47.102:19800  (active)
  192.168.47.103:19800  (active)
  192.168.47.200:19800  (active)
not attached node:

ageというキーでデータを登録してみて,データがどのサーバに保存されたか確認してみます。

[waki@serv1 $ kumohash -m serv1 assign age
728661ab9a6bc55d  age
  0: 192.168.47.200:19800
  1: 192.168.47.102:19800
  2: 192.168.47.101:19800

新たに追加したサーバにデータが分散して登録されているようです。レプリケーション数3もそのまま有効ですね。

また既存のキーであるnameも調べてみるとデータを保持するサーバの構成が変わっていました。新規サーバ追加など構成変更が発生した場合は,データの再分散が行われるようです。これは後で出てきますが,consistent-hashingというアルゴリズムが使用されています。

kumofsのアベイラビリティ

それでは今度は障害が発生した想定で,サーバの数を減らしてみましょう。レプリケーション数が3ですので,2台までのサーバがいなくなっても正常に動作するはずです。

まずは現状の確認です。

[waki@serv1$ kumoctl serv1 status
hash space timestamp:
  Fri Aug 13 19:57:04 -0400 2010 clock 43217
attached node:
  192.168.47.101:19800  (active)
  192.168.47.102:19800  (active)
  192.168.47.103:19800  (active)
  192.168.47.200:19800  (active)
not attached node:

4台とも正常に動作しています。

それでは,以下の構成からserv2, serv4を順番に停止させて様子を見てみます。

サーバkumo-managerkumo-serverkumo-gateway
serv1
serv2→停止→停止
serv3
serv4→停止

まずserv2を停止させました。statusを確認すると,serv2がfault状態になります。

[waki@serv1 $ kumoctl serv1 status
hash space timestamp:
  Sat Aug 14 00:23:30 -0400 2010 clock 51211
attached node:
  192.168.47.101:19800  (active)
  192.168.47.102:19800  (fault)
  192.168.47.103:19800  (active)
  192.168.47.200:19800  (active)
not attached node:

新たにキー:hoge,バリュー:fugaでデータを登録,取得してみます。問題なく動作しているようです。

続けてserv4も停止させます。

[waki@serv1$ kumoctl serv1 status
hash space timestamp:
  Sat Aug 14 00:41:05 -0400 2010 clock 51746
attached node:
  192.168.47.101:19800  (active)
  192.168.47.102:19800  (fault)
  192.168.47.103:19800  (active)
  192.168.47.200:19800  (fault)
not attached node:

2台いなくなってもデータの登録,取得に問題ありません。

次に,レプリケーションでどのサーバに分散されたか確認してみます。

[waki@hadoop1 $ kumohash -m hadoop1 assign hoge
44f81bcbdb0df331  hoge
  0: 192.168.47.102:19800
  1: 192.168.47.103:19800
  2: 192.168.47.200:19800

serv2が落ちいてるはずなのに,serv2にレプリカが作成されたことになっていますね?

kumofsの分散ロジックにはconsistent hashingというロジックが使われており,サーバIPのハッシュ値とキーのハッシュ値の比較によりどのサーバにどのキーが格納されるかが決定されるようになっています。ここでの表示はconsistent hashingの計算結果が表示されているということだと思われます(実際にはserv2にデータのレプリカは存在しないので)⁠

それでは元の4台構成に戻してみましょう。serv2, serv4のデータベースファイルを削除し,kumo-serverを起動,attachし直します。

[waki@serv1$ kumoctl serv1 status
hash space timestamp:
  Sat Aug 14 01:54:43 -0400 2010 clock 53970
attached node:
  192.168.47.101:19800  (active)
  192.168.47.102:19800  (active)
  192.168.47.103:19800  (active)
  192.168.47.200:19800  (active)
not attached node:

無事復活しました。データの登録,取得も問題ありません。

このような感じで使ってみましたが,スケーラビリティ,アベイラビリティともに必要最小限のオペレーションで実現できている感じがします。いわゆるRDBMSではこのように簡単にサーバを追加したり,レプリケーションの復旧はできません。

これがシンプルなNoSQLと分散環境のなしえる妙ということでしょう。

著者プロフィール

脇本武士(わきもとたけし)

都内中小IT企業(メイサンソフト(株))に所属。某大手自動車会社でのシステム開発,運用を経て,現在は研究開発部署に席をお借りしています。DB周りの保守サポート,ウェブ技術開発を主に手がけてきました。現在は大規模計算フレームワークの活用とKVSに注目しています。普段はOS Xを使用していますが一番よく使うアプリはTerminalです(笑)。

R&Dトレンドレポート(てくらぼ)

コメント

コメントの記入