いよいよ今回が最終回です。これまではKaiの動作原理やインストールの説明でしたが、今回は実際の運用に役立つポイントなどを説明します。

Kaiの利用事例紹介

まずは、実際にKaiを利用しているサービスをご紹介したいと思います。その後で、運用に当たってのノウハウをご紹介していきます。

筆者が所属しているgooではgooホームというSNSサービスを提供しています。OpenSocialにいち早く対応するなど、積極的に新しい技術を取り入れています。プロフィールやソーシャルグラフなどの主要なデータはMySQLで管理していますが、アクティビティと呼んでいるユーザの更新情報をKaiに格納しています。

Kaiの構成は至ってシンプルで、CentOS 5.1で動作するノードが3台あるクラスタです。このクラスターに約150万件のデータと約3Gバイトのデータを格納しています。ストレージにはdetsを使用しています。ロードバランサーと組み合わせて、アプリケーションからは単一のノードにしか見えないようになっています。バランシングは単純なラウンドロビンで十分です。

MySQLなどのRDBにmemcachedを組み合わせて、SQLの発行回数を劇的に抑える手法はかなり普及したと思いますが、Kaiも同様にmemcachedと組み合わせて利用しています。detsを利用していますのでこのようになっていますが、etsを利用した場合はmemcachedは不要かもしれません。もちろん事前に十分なサイジングが必要です。

動作状況をレポートするstatsコマンド

それでは運用に用いるKaiの機能をみていきましょう。memcachedではstatsコマンドを送るとオブジェクトの数などが取得できましたが、Kaiでも同様にstatsコマンドが使えます。statsコマンドで得られる情報は以下の通りです。

Kaiにtelnetで接続してstatsコマンドを送っても値を確認できますが、ここではPHPのmemcached実装を使ってみましょう。リスト1のような簡単なPHPスクリプトを実行すると以下のような結果が得られます。

<?php

$host = "localhost";
$port = 14013;

$memcache = new Memcache;
$memcache->connect($host, $port) or die ("Could not connect");
$status = $memcache->getStats();
print_r($status);

?>

$ php kai_stats.php
Array
(
    [uptime] => 1077608
    [time] => 1246117054
    [version] => 0.3.0
    [bytes] => 2116619959
    [curr_items] => 1039170
    [cmd_get] => 1977438
    [cmd_set] => 100357
    [bytes_read] => 3350521698
    [bytes_write] => 257731220
    [kai_node] => 172.20.200.40:14012
    [kai_quorum] => 3,2,2
    [kai_number_of_buckets] => 1024
    [kai_number_of_virtual_nodes] => 128
    [kai_store] => dets
    [kai_curr_nodes] => 172.20.200.40:14012 172.20.200.41:14012 172.20.200.42:14012
    [erlang_procs] => 2699
    [erlang_version] => 5.6.5
)

このように、memcachedと全く同様にKaiのstatsを取得することができます。これにより多くのプログラミング言語のmemcached実装を用いてKaiのstatsの値が取得できると思います。正しい現状把握が安定運用の第一歩ですのでこれらの情報を活用してチューニングや設備増強の判断などに役立ててみてください。

statsをグラフにする

statsについてみてきましたが、この情報を便利かつ簡単に把握できるようにしなければシステム運用とは言えません。多くの現場ではMRTGやrrdtoolを使ってグラフにすることが行われていると思います。この分野で著名なオープンソースのソフトウェアにcactiがあります。Kaiのversion 0.4.0からcactiのプラグインが同梱されています。格納場所はcontrib/cactiです。具体的なインストール方法はプラグイン本体にドキュメントがありますのでそちらを参考にしてください。

このプラグインが描画の対象としている項目はbytes,curr_items,cmd_get,cmd_set,bytes_read,bytes_writeになります。実際にこのプラグインを使って作成したグラフを紹介します。

監視について

statsの値をcactiを使って統計的に利用する方法について紹介しましたが、ここでは監視について説明します。

定期的にstatsコマンドを送信して正常に値が取得できるかを確認することでノードの死活監視は十分に行えます。Kaiを使われる方はクラスタを構成することがほとんどだと思いますが、この場合はクラスタ構成が正常であるかどうかを監視する必要があります。それには理由があります。

一部のノードがダウンしてクラスタから脱落してもデータが失われることはないと、これまでの連載で説明してきました。ノードがダウンしたら再起動するだけでいい場合もありますが、実際の運用ではもう少し配慮が必要です。

クラスタを構成した場合、クライアントからのリクエストを適切に全ノードで分散して処理するためにロードバランサを用いたり、またはクライアント側でリクエストを分散するなどの対応を行います。このような状況で、あるノードがクラスタから脱落してしまったが、完全にダウンした状態ではなくgetやsetなどの応答は返すケースを考えてみましょう。

5台のノードでdetsを用いてクラスタを構成していたとして、ノードが1台、クラスタから脱落すると4台＋1台の状態になります。ノードの死活監視しか行っていない場合はこの状態でも正常に見えます。正常ですのでクラスタを利用しているクライアント側は4台の側か、1台の側か区別なく5台の全ノードにgetやsetを行います。あるキー名をもつデータを頻繁にsetしていると、4台の側と、1台の側で同じキー名を持つデータをそれぞれで持ってしまう可能性があります。この状態を以下に示します。

このまま脱落していたノードを4台の側に復帰させると問題が発生します。同じキー名のデータを持ったノードが存在してしまうことになります。つまり、第3回で説明したWrite/Write Conflictが発生することになります。このデータに対してgetするとデータは得られますが、2つのデータが返ってきてしまいます。

多くのmemcachedクライアントの実装はこのような事態を想定していませんので、エラーを返したり、どちらかのデータが返ってきたりする状態になります。クラスタとして正常に動作しているように見えますが、クライアント側ではデータの取得時にエラーが多発したり、異なる値を取得したりするように見えてしまいます。こうなると状態を切り分けて原因を特定するのが難しくなります。この問題については、開発ブランチ branches/shino_data_in_bag/ で取り組んでいます。

etsを使用している場合は再起動する際にノード上のデータは消えますのでこのような事態は発生しません。detsを使用している場合、データが重複する恐れがある場合は一度ノード上のデータを消去してからクラスタに復帰させましょう。

消去の方法はconfigファイルのdets_dirで指定されたディレクトリ以下のファイルをすべて消去することで行えます。

ノードが脱落していたことに気づかずに運用していると、いつか必ずこのような事態に遭遇します。ノードが脱落したことを素早く検知して、クラスタに復帰させるか一時的にクライアントからアクセスしないような仕組みにする必要があります。

導入事例で紹介したgooホームではKaiの監視にオープンソースの監視ソフトウェア「Nagios」を使っています。Perlなどで簡単に監視プラグインを作成できるのが特徴です。memcachedの監視プラグインに改良を加え、Kaiの監視プラグインとしています。それぞれのノードが認識しているクラスタのメンバ数を数えて、メンバ数が変わることがあったら即座にアラートを発するようにしています。

課題

実際に導入して、課題となる点を上げておきたいと思います。

KaiはaptやRPMなどのパッケージングがまだされていません。多数のノードを構築するのにキックスタートインストールを行って自動的に行いところですが、現状では簡単ではありません。また、ディストリビューションが備える標準的なプロセス起動のコマンドも備えていませんのでこちらも管理上問題になります。現状では第2回で説明されたErlang VMのコンソールをDetacheするしかありません。

これらの運用上の課題は近日中に取り組んでフィードバックできればと考えています。

最後に

5回に渡ってKaiのコンセプトから運用までをご紹介してきました。memcachedが登場し多くの現場で採用された今、シンプルなKey/Valueストアが特にWebサイトの構築現場で注目を集めています。この分野は発展途上で様々なエンジニアがそれぞれの課題を解決すべく奮闘を続けています。本連載がKey/Valueストアを考えているエンジニアの参考になれば幸いです。