乐胖代购免代理版

Chef Serverのバージョン10系では、バックエンドのデータベースとしてCouchDBが採用されていますが、このCouchDBは、ドキュメント更新時に古いものを上書きせず、常に新しいリビジョンとして登録しなおす特徴があります。

CouchDB は、ドキュメントを更新するときに元のドキュメントを上書きすることはせず、元のドキュメントと同一の _id を持ち、新しい _rev ID を持ったドキュメントをデータベース・ファイルの末尾に新しく作成します。この種のストレージ・システムはディスクスペースを消費するため、ディスクスペースを空けるためには定期的に圧縮を行う必要があります。
Document revisions - Couchdb Wiki

ということで、Chef Server(バージョン10系)を長く運用して使っていると、古いデータがどんどん蓄積されていくので、定期的にCompactionを行うのが良さそうです。

やり方

で、肝心のやり方ですが、以下のOpscodeのドキュメントにあります。

http://wiki.opscode.com/display/chef/CouchDB+Administration+for+Chef+Server

が、せっかくなので試して書いておきましょう。日本語でｗ

まずは、現状を確認してみます。

# ll -h /var/lib/couchdb/1.0.1
total 11G
drwxrwx--- 4 couchdb couchdb 4.0K 2013-07-04 14:17 ./
drwxrwx--- 3 couchdb couchdb 4.0K 2012-01-27 04:07 ../
-rw-rw-r-- 1 couchdb couchdb  11G 2013-07-04 14:11 chef.couch
drwxrwxr-x 2 couchdb couchdb 4.0K 2012-02-01 20:40 .chef_design/
-rw-rw-r-- 1 couchdb couchdb   23 2013-07-01 20:32 couch.uri
drwxrwxr-x 2 couchdb couchdb 4.0K 2012-01-27 04:07 .delete/
-rw-rw-r-- 1 couchdb couchdb 4.1K 2012-01-27 04:07 _users.couch

この中の"chef.couch"ってファイルがDBの実体ファイルですね。11GBほどあります。

CouchDBはRESTfulなHTTP APIが提供されているので。そちらを叩いてオペレーションします。

$ curl http://localhost:5984
{"couchdb":"Welcome","version":"1.0.1"}

例えば、これはDBのバージョン情報。

$ curl http://localhost:5984/chef
{"db_name":"chef","doc_count":25683,"doc_del_count":753,"update_seq":94233,"purge_seq":0,"compact_running":false,"disk_size":11334766699,"instance_start_time":"1372678339122342","disk_format_version":5,"committed_update_seq":94233}

こんな感じで、Chefで使われているDBの領域の情報が確認できます。

では、ここからが本題。
Compaction(圧縮)のオペレーションはとても簡単で、以下をコマンド実行する(APIをキックする)だけです。(API経由なので当然ですがオンラインで実行できます。)

$ curl -H "Content-Type: application/json" -X POST http://localhost:5984/chef/_compact
{"ok":true}

Compactionが始まると、↑な感じで「"ok":true」が返されます。

$ curl http://localhost:5984/chef
{"db_name":"chef","doc_count":25683,"doc_del_count":753,"update_seq":94233,"purge_seq":0,"compact_running":true,"disk_size":11334766699,"instance_start_time":"1372678339122342","disk_format_version":5,"committed_update_seq":94233}

さっきとは違って、「"compact_running":true」に変わっています。ここがtrueの間は、圧縮処理が走っていることを意味します。これがfalseになると処理が終了したってことになります。

$ curl http://localhost:5984/chef
{"db_name":"chef","doc_count":25683,"doc_del_count":753,"update_seq":94233,"purge_seq":0,"compact_running":false,"disk_size":232009829,"instance_start_time":"1372678339122342","disk_format_version":5,"committed_update_seq":94233}

終わったみたいですね。実行時間は↑の規模で1〜2分くらいだったでしょうか。さっきと比べて、"disk_size"がガクンと落ちています。

# ll -h /var/lib/couchdb/1.0.1
total 222M
drwxrwx--- 4 couchdb couchdb 4.0K 2013-07-04 14:27 ./
drwxrwx--- 3 couchdb couchdb 4.0K 2012-01-27 04:07 ../
-rw-rw-r-- 1 couchdb couchdb 222M 2013-07-04 14:25 chef.couch
drwxrwxr-x 2 couchdb couchdb 4.0K 2012-02-01 20:40 .chef_design/
-rw-rw-r-- 1 couchdb couchdb   23 2013-07-01 20:32 couch.uri
drwxrwxr-x 2 couchdb couchdb 4.0K 2013-07-04 14:25 .delete/
-rw-rw-r-- 1 couchdb couchdb 4.1K 2012-01-27 04:07 _users.couch

実体ファイルのサイズを確認すると、222MBになりました。
元が11GBだったので、およそ98%ほどカットされましたｗ
(ずっとCompactionを実行していなかったのがバレますね、これｗ)

書き込みの負荷がほぼ限界に達しているデータベース・ノードに対して圧縮を行うのは避けるべきです。なぜなら、もし書き込みがいつまでも終わらなければ、圧縮プロセスは書き込みに追い付くことができず、最後はディスクスペースを使い切ってしまうからです。
圧縮は、書き込み負荷が限界に達していないときに行う必要があります。なお、読み込み負荷は圧縮プロセスには影響しません。CouchDB のこのような動作はクライアントへの影響を最小限に抑えるためで、データベースをオンライン状態に保って読み取りと書き込みに対して完全に機能するようになっています。書き込み負荷が限界に達しているときにデータベースの圧縮を完了できないのは、設計上の制約です。したがって、オフピーク時に圧縮をスケジュールするのが妥当な解決策です。
クラスタ環境では、任意のノードで書き込み負荷を下げてから圧縮を実行し、レプリケーションが完了したら書き込み負荷を元どおりに戻すといった対応が可能です。
Compaction - Couchdb Wiki

CouchDBのWikiにも、こんな注意が書かれていますので、実行タイミングは計画的に。
というか、Chef Serverがここまで負荷的にシビアになることは、相当大規模な環境下でchef-clientをデーモン化している場合とかになるんでしょうね。

それでは！ =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́