みなさん、データベースの監視はバッチリですか!? Couchbase Serverのモニタリングベストプラクティスについての記事を和訳してみました。 原文はこちら: Couchbase Monitoring

• Couchbase モニタリング
• モニタリングのベストプラクティス
• ノードのモニタリング
• バケットのモニタリング
• コマンドライン

Couchbase モニタリング

Couchbaseは分散型の、高性能な、キャッシュとNoSQLデータベースを一つのクラスタアーキテクチャに統合しています。 名前が似ていて、遺産を共有してはいるものの、CouchDBやその他のNoSQLとはまったく異なるプロダクトです。 アプリケーションのメトリックと合わせてCouchbaseの性能をモニタリングしプロファイルできることは非常に重要です。 いかなるミッションクリティカルなシステムにおいても、モニタリングは運用を成功させる重要な要素の一つです。 これは当たり前ではありますが、特に分散コンピューティング環境ではより重要になります。 長期間の運用を成功させる唯一の方法です。

この記事では、モニタリングに焦点を当てていますが、アプリケーションのトラブルシューティングにはCouchbaseの詳細なログも利用可能です。 ログは ‘/opt/couchbase/var/lib/couchbase/logs’ に保存されています。 ログに関するより詳細な情報はCouchbaseフライトレコーダを参照してください。

Couchbaseは豊富な情報を閲覧できる管理コンソールを提供し、コンソールで表示されるすべての情報はコマンドラインツールと、RESTインタフェースからも利用できます。 必要な統計情報を提供するだけでなく、サードパーティツールでミッションクリティカルなプロダクションクラスタのモニタリングも可能としています。 クラスタは過去の情報を保存しつつ、容量を削減するため時間が経つにつれてデータを集約しますが、サードパーティツールを利用して一定間隔で過去の記録をそのまま保存することができます。

モニタリングのベストプラクティス

さらに詳しく解説しましょう …

Couchbaseを効率的にモニタリングするためには二つの視点が必要です。 クラスタは個々のノード、サーバから構成されます。 各ノードの処理能力を分散データベースのクラスタを通してアプリケーションから利用することができます。 このため、ノード単位のリソース利用状況と処理能力を監視することが大切です。

どのようなアプリケーションでも、クラスタがどの程度のリクエストをキャッシュから処理しているのか、ディスクが即座にデータを永続化できているのかも知りたいでしょう。 各メトリックを解説していきますが、クラスタがどのように振る舞うべきかはアプリケーション要件次第ということに注意してください。 インメモリのワーキングセットを管理し、早期にクラスタに新しいノードを追加する必要があることを示す警告イベントを検知することがゴールです。

ノードのモニタリング

このREST APIを活用しましょう ( http://<ip>:8091/pools/default ) コンピューティングリソースの利用状況をノード単位に取得できます。

1. ノードステータス - (クラスタのメンバシップ) nodeStatusesエンドポイントの結果JSONには、clusterMembershipとしてノードのステータスが含まれています。 この”active”をノード単位で監視し、ノードがクラスタに参加しているかを確認する仕組みを構築できます。致命的なイベントは”inactiveFailed”として示され、ノードがダウンし、管理者の操作が必要であることを示します。

2. システム統計情報 (systemStats) - さらにこのエンドポイントではCPU (cpu_utilization)、SWAP (swap_used)、空きメモリ (mem_free)といった基本的なキャパシティの情報が参照できます。クラスタ内のすべてのノードにおいて、これらのリソースが圧迫されている様子が見られたら、そのノードを特定し、ノードの追加が必要か検討すべきでしょう。

3. Couchbaseに特化した情報 (interestingStats) - このセクションは各ノードのリソース利用に関するさらなる洞察を提供します。個々のノードにおけるCouchbaseのディスク利用量はcouch_docs_actual_disk_size、ノードでの物理メモリ利用量はmem_usedで示され、バックグラウンドでのフェッチ数(データがキャッシュされていない場合にディスクから読み込む)はep_bg_fetchedとして計測されます。

バケットのモニタリング

このREST APIを活用しましょう ( http://<ip>:8091/pools/default/buckets/<bucket_name>/stats ) バケットの状態を取得できます。

個々のノードの処理能力に余裕があっても、バケットが制限となっている場合があります。 このため、バケットの統計情報を監視することで、アプリケーションの状態に対するより深い洞察が可能となります。

1. 秒間オペレーション数 (ops) - これはバケット単位のget、set、increment、decrement操作の合計数を計測する重要な数値です。このメトリックにはViewは含まれませんが、アプリケーションからの負荷を迅速に計測することができます。すべてのリソースはクラスタに割り当てられていますが、この情報から各アプリケーションが与える負荷を調査することができます。

2. キャッシュミス (ep_cache_miss_rate) - これはアプリケーション要件によって問題となるかならないかが分かれる好例です。このメトリックはリクエストされたオブジェクトがキャッシュ内で見つかった件数と、ディスクからフェッチしなければならなかった件数の割合を集計しています。例えば、データベースへ10回リクエストを行ったとき、1つのリクエストがディスクから取得する必要があった場合、ミスの割合は10%となります。これは問題になるでしょうか … ? 何をメモリ上に保持するのかに大きく依存し、可能な限り0に近づけることでクラスタのベストな性能を得られます。

3. フラグメンテーション (couch_docs_fragmentation) - Couchbaseは追記型のフォーマットでディスクにデータを保存します。このため、クラスタ内で発生するフラグメンテーションに注意を払う必要があります。これは特にauto-compactionのスケジュール実行をどのように利用すべきかを判断するために重要となります。データベースを健全な状態に保つために、スケジュール間隔が適度に長く、また適切な頻度で実行されているかを判断する材料となります。

4. ワーキングセット (ep_bg_fetched、vb_active_resident_item_ratio) - 前述のep_cache_miss_ratioを、メモリ内に存在するアイテム数の割合(resident_item_ratio)、空きメモリ容量と組み合わせて、バケットに頻繁にリクエストされるオブジェクトをメモリに保持するために十分な容量があるかどうかを確認することができます。さらに重要なこととして、クラスタのメモリ容量を拡張するためにノードを追加する必要があるかを予測することができます。

5. ディスクドレイン (ep_queue_size) - ドレイン率はどのようなアプリケーションかにかかわらず、もっとも重要なメトリックの一つです。キュー内に滞留しているデータ変更の量を注意深く監視してください。詳細な情報は後述するコマンドラインツールでも取得できます。RESTを利用すると、キューへの登録 (ep_diskqueue_fill) と、どれだけ高速にキューを処理できているか (ep_diskqueue_drain) をモニタリングし、トレンドを調査することができます。

詳細な情報は全てRESTインタフェースで監視できます。ここではAPIで利用可能なすべての項目を説明できませんが、クラスタを健全な状態に保つための主要な統計情報に絞って解説します。RESTに加えて、couchbase-cliによる監視スクリプトを実行することで、クラスタ内の各ノードで発生しているオペレーションをキャプチャすることができます。

コマンドライン

CBSTATSは ‘/opt/couchbase/bin’ にあり、クラスタ内で何が起こっているのかを確認することができます。 以下にいくつかの主要なメトリックと、それが何を意味するのかを示します:

1. オープンなコネクションとリジェクトされた接続の数を示すcurr_connectionsとrejected_connsの統計情報をトラッキングすることで、このノードで接続がリジェクトされたかどうかを確認できます。

2. アプリケーションからリクエストされたオブジェクトがキャッシュに存在しない場合、Couchbaseはディスクからオブジェクトを取得します。このキャッシュミスはバックグラウンドでのフェッチが必要となり、ep_bg_fetchedでディスクからフェッチされたアイテム数が計測されています。もしワーキングセットを100%に管理したいのであれば、この数値はクラスタに過度な負荷がかかっていることを示唆します、ワーキングセットがこれより小さな場合は問題にならないかもしれません。どちらのシナリオでも、環境の特徴を理解することは非常に大切で、この数値が極端に増加する場合、早期に発見することが重要です。

3. 永続化キュー内に滞留しているアイテム数は、アプリケーションに対する適切なI/Oリソースがあるかを理解するためにモニタリングすべき重要な項目です。アプリケーションへは常にキャッシュ層からデータを提供する一方、データをディスクにも永続化できる機能は、Couchbaseの利点の一つです。この非同期の操作が過度の負荷を受けた場合、アプリケーションの性能に影響を与えることがあります。これは特にデータ書き込みを頻繁に行うシステムで注意が必要です。ep_queue_sizeと、ep_flusher_todoは特に注意して監視してください。 100万のアイテムが滞留するようなことは発生してほしくないので、50万から80万の間で警告を出すようにするとよいでしょう、特にアイテム数に上昇傾向が見られる場合注意してください。

4. vb_num_eject_replicasの統計情報はCouchbaseがreplicaデータをメモリから除去した回数を示します。 これはそのバケットが低水位に達したことを示唆します。 クラスタは単にメモリの空き容量を確保しただけなので、この閾値に達したこと自体は大きな問題ではありませんが、継続してこの振る舞いが見られる場合や増加傾向にある場合、問題となる可能性があります。 より重要なのは、これがOutOfMemory発生時 (ep_oom_errors/ep_tmp_oom_errors) にメモリを確保する方法でもあるということです。プロダクションクラスタでは絶対に発生してほしくありませんね。

5. Couchbaseはノードのスタートアップ中に’warmup’処理を実行することで、キャッシュの鮮度を保つように設計されています。 ウォームアップはディスクからオブジェクトを読み込み、キャッシュに事前にロードする処理です。 ウォームアップのモニタリングはCouchbaseノードがスタートアッププロセスをどの程度の時間で完了するのか、そしてクラスタへのリクエスト処理を開始できるかを監視できます。 ep_warmup_value_countがvb_active_curr_itemsと一致するとウォームアップが完了します。また、ep_warmup_stateでよりきめ細かな情報を得ることができます。 以下は7つのウォームアップ状態です。 ノードはステータスが’done’になるまで完了しません。

   1. Initial - ウォームアップ処理開始時点です。
   2. EstimateDatabaseItemCount - データベースのアイテム数を見積もっています。
   3. KeyDump - キーとメタデータをRAMにロードしています、しかしまだドキュメントはロードしていません。
   4. CheckForAccessLog - アクセスログが利用可能か判断します。 このログはどのキーが頻繁に読み書きされているのかを示す情報です。
   5. LoadingAccessLog - アクセスログから情報を読み込みます。
   6. LoadingData - サーバはアクセスログに含まれるキーのデータをまずロードします、ログが利用できない場合、’Key Dump’フェーズで見つかったキーを利用します。
   7. Done - サーバは参照、更新のリクエストを受け付ける準備ができました。

6. Couchbaseは永続化するNoSQLだけではなく、キャッシュエンジンでもあるため、Couchbase Serverのep_engineがどのようにメモリを使うのか理解することが大切です。 これは mem_usedで監視できます。

7. 前述のcbstatsによる統計情報はRESTインタフェースでも利用可能です ( http://<ip>:8091/pools/default/buckets/<bucket_name>/stats )

   ops, ep_cache_miss_rate, couch_docs_fragmentation, ep_queue_size, vb_active_resident_items_ratio, curr_connections, curr_items_tot, ep_bg_fetched, ep_diskqueue_drain, ep_diskqueue_fill, vb_replica_eject, ep_oom_errors, ep_queue_size, ep_tmp_oom_errors, mem_used, etc

この記事ではCouchbaseモニタリング戦略を考えるためにいくつかのガイダンスを紹介しました。 これは実際にCouchbaseのお客様が採用しているベストプラクティスのサマリです。 Couchbaseを利用するアプリケーションに応じて、ここで述べた以外のメトリックが必要になる場合もあります。