前回はkumofsを用いて分散環境を構築し、単純に動作させるところまで書きましたが、今回はkumofsのスケーラビリティ、アベイラビリティという視点で操作してみます。
kumofsのスケーラビリティ
前回、3台の構成でkumofsを動かしました。おさらいしておくと、以下のような構成となっています。
kumofsは3種類のデーモンで構成されます。
kumo-server | 実際にデータを保存するノード。少なくとも1台必要です。後から追加できます。 |
kumo-manager | kumo-server群を管理するノード。1台または2台で動かします。 |
kumo-gateway | アプリケーションからのリクエストをkumo-serverに中継するプロキシ。アプリケーションを動かすホスト上で、1つずつ起動しておきます。 |
ここでもドキュメントのチュートリアルに従って、進めたいと思います。私の環境でも同様に3台のサーバを用いて環境を構築します。
サーバ | kumo-manager | kumo-server | kumo-gateway |
serv1 | ○ | ○ | - |
serv2 | ○ | ○ | - |
serv3 | - | ○ | ○ |
この構成に新規にserv4を追加してみたいと思います。また、追加時にどのようなオペレーションが必要となるか、データの損失が無いかを確認してみましょう。
serv4に前回と同様に環境をセットアップします。こういうときに仮想マシンは便利ですね。コピペ感覚で新規マシンを立ち上げられるんですから。ここでも前回と同様にこちらを参考に手順を進めてみます。
今回新たにserv4を作成しました。これを用いて下記のような構成をとってみます。
サーバ | kumo-manager | kumo-server | kumo-gateway |
serv1 | ○ | ○ | - |
serv2 | ○ | ○ | - |
serv3 | - | ○ | ○ |
serv4 | - | ○ | - |
その前に、前回の構築状態を確認してみたいと思います。kumofsには便利なユーティリティが付属しており、サーバの状態を把握することができます。
分散環境のどのサーバにデータが格納されているかを確認してみたいと思います。現在の構成は3台がkumo-serverです。さらにレプリケーション数も3となっていますので、1つのデータが3台のサーバに分散されることになります。
確認のコマンドはkumohashを使用します。
nameというキーのデータはserv1, serv2, serv3に分散されていることがわかります。レプリケーション数とあっていますね。問題なさそうです。
それではサーバの追加です。serv4でkumo-serverを起動し、serv1でattachするという順序です。
serv1でステータスを確認します。
新たにサーバが追加されました。非常に簡単ですね。
ageというキーでデータを登録してみて、データがどのサーバに保存されたか確認してみます。
新たに追加したサーバにデータが分散して登録されているようです。レプリケーション数3もそのまま有効ですね。
また既存のキーであるnameも調べてみるとデータを保持するサーバの構成が変わっていました。新規サーバ追加など構成変更が発生した場合は、データの再分散が行われるようです。これは後で出てきますが、consistent-hashingというアルゴリズムが使用されています。
kumofsのアベイラビリティ
それでは今度は障害が発生した想定で、サーバの数を減らしてみましょう。レプリケーション数が3ですので、2台までのサーバがいなくなっても正常に動作するはずです。
まずは現状の確認です。
4台とも正常に動作しています。
それでは、以下の構成からserv2, serv4を順番に停止させて様子を見てみます。
サーバ | kumo-manager | kumo-server | kumo-gateway |
serv1 | ○ | ○ | - |
serv2 | →停止 | →停止 | - |
serv3 | - | ○ | ○ |
serv4 | - | →停止 | - |
まずserv2を停止させました。statusを確認すると、serv2がfault状態になります。
新たにキー:hoge、バリュー:fugaでデータを登録、取得してみます。問題なく動作しているようです。
続けてserv4も停止させます。
2台いなくなってもデータの登録、取得に問題ありません。
次に、レプリケーションでどのサーバに分散されたか確認してみます。
serv2が落ちいてるはずなのに、serv2にレプリカが作成されたことになっていますね?
kumofsの分散ロジックにはconsistent hashingというロジックが使われており、サーバIPのハッシュ値とキーのハッシュ値の比較によりどのサーバにどのキーが格納されるかが決定されるようになっています。ここでの表示はconsistent hashingの計算結果が表示されているということだと思われます(実際にはserv2にデータのレプリカは存在しないので)。
それでは元の4台構成に戻してみましょう。serv2, serv4のデータベースファイルを削除し、kumo-serverを起動、attachし直します。
無事復活しました。データの登録、取得も問題ありません。
このような感じで使ってみましたが、スケーラビリティ、アベイラビリティともに必要最小限のオペレーションで実現できている感じがします。いわゆるRDBMSではこのように簡単にサーバを追加したり、レプリケーションの復旧はできません。
これがシンプルなNoSQLと分散環境のなしえる妙ということでしょう。