先日、アプリケーションからのRedis呼び出しの計測を行う記事を公開しました。Redisデータベースそのもののパフォーマンスモニタリングも重要です。Redisデータベースをどのようにモニタリングできるのか、抄訳記事にてお届けします。
Redis は非常に高速な分散型のインメモリキーバリューデータベースです。通常、Redisはプライマリデータストアとしては使用されませんが、パフォーマンスが最も重要なアプリケーションの領域では、高速なキャッシュとして使用されることがよくあります。インメモリキーバリューデータベースとして、Redisは従来のデータベースシステムよりもはるかに高速です。また、軽量な分散キューとしても一般的に使用されています。Redis の分散 pub/sub 機能を使用して、自分でその機能を構築することなく、さまざまな受信者にメッセージをディスパッチすることができます。
このようなユースケースでは、Redisはどのようなアプリにも不可欠な要素となるため、最高のパフォーマンスを発揮できるようにすることが重要です。そうしないとアプリのパフォーマンスが低下します。その結果、ユーザーエクスペリエンスの低下をまねき、最悪の場合、アプリケーションは全く動作しなくなります。
Redisの導入は、単一のインメモリノードからマルチノードクラスタ、あるいはRedis on Flashを介したインメモリ/オンディスクのハイブリッド導入まで、複雑になることもあります。Redisクラスタのノード数が多ければ多いほど、障害の可能性が高くなります。
そのため、Redisの監視は非常に重要です。また、Redisは非常に多くの異なるシナリオで使用されるため、ユースケースに応じた適切なメトリクスを監視していることを確認することが重要です。Redisが健全であることを確認することで、最高のユーザーエクスペリエンスを実現し、トランザクションデータベースの負担を軽減することができます。
Redisの主要なメトリクス
Redis ベースのアプリケーションアーキテクチャは非常に複雑になる可能性があるため、関係するコンポーネントやデータの相互作用は、リアルタイムで監視すべき多くの異なるメトリクスを生成します。すべてのメトリクスが同じ重みを持っているわけではありません。監視する価値のある重要な Redis のメトリクスをいくつか見てみましょう。
ヒント: 利用可能なすべてのメトリクスを確認するには、Redis Integrationドキュメントをチェックしてください (以下で設定方法を説明する際に参照するものです)。
状態メトリクス
software.uptimeMilliseconds: Redis サーバが起動してからのミリ秒数。ここの値が予想外に低い場合は、Redisが最近クラッシュしたことを意味しているかもしれません。サービスが再起動していないことを確認したいので、アップタイムは単調増加しているべきです。
system.totalSystemMemoryBytes: これはRedisが実行されているインスタンスで利用可能なメモリのバイト数です。このメトリックを監視することは重要です。Redisのインストールがスケールアウトできず、ホストマシンがメモリを使い果たした場合、オペレーティングシステムがRedisサーバプロセスを終了させる可能性があります。需要の増加に対応するためにストレージ容量を追加することで、数を改善することができます。
パフォーマンスメトリクス
net.connectedClients: これはクライアントの接続数(レプリカからの接続を除く)です。Redis はシングルスレッドなので、1つのプロセスがすべてのクライアントのリクエストを処理します。接続されているクライアントの数が増えると、サーバは各リクエストを処理するためのリソース時間が減るので、クライアントは応答をより長く待つ必要があります。クライアントの数を監視することで、予期せぬクライアント接続を作成していたり、使用後にクライアント接続を閉じるのに失敗したりしているアプリケーションを明らかにすることもできます。
net.commandsProcessedPerSecond: このメトリックを監視することは、Redisが高い基準でパフォーマンスを発揮していることを確認するために非常に重要です。遅延の大きい接続や低いスループットの両方に気づいた場合、これらの問題の原因を調査し、根本的な問題を特定して取り除くことができます。
- 数値が一定であれば、原因は計算量の多いコマンドではありません。
- 数値が急激に低下した場合は、遅延問題の原因となっている遅いコマンドがあります。
- 数値の異常な低下は、コマンド量が少ないか、コマンドが遅いことを示している可能性があります。
db.keyspaceHitsPerSecondとdb.keyspaceMissesPerSecond: これは、メイン辞書内のキーの検索に成功した数と、メイン辞書内の検索に失敗した数を1秒あたりで表したものです。
キャッシュヒット率と呼ばれる新しいメトリックと組み合わせることで、これら2つのメトリックはRedisキャッシュが有効に使用されているかどうかを示すことができます。キャッシュヒット率は、keyspaceヒット数をkeyspaceヒットとkeyspaceミスの合計で割ったものです。言い換えれば、Redisデータベースの1秒あたりの全読み取り操作のうち、1秒あたりの読み取りが成功した割合です。
キャッシュヒット率が低い状況は、期限切れのデータやRedisへのメモリ割り当てが不十分なことなど、いくつかの要因によって引き起こされる可能性があります。ヒット率が低いということは、アプリがより遅いデータベースからデータを取得しなければならないため、アプリのレイテンシが高いことを意味します。
エラーメトリクス
net.rejectedConnectionsPerSecond: クライアントの制限により1秒あたりに拒否された接続数です。拒否された接続数が増加すると、以下のシナリオのいずれかを示す可能性があるため、この重要なメトリックを継続的に監視する必要があります。
- 不正なクライアントが新しい接続を要求しています。この場合、これらの接続を要求しているアプリケーションを特定し、そのプロセスを修正する必要があります。
- 正当だが予期せぬクライアントが接続を確立しようとしているが、maxclientsの値が過小評価されている。Redisでは、maxclientsの設定を増やすことでこの問題を修正することができます。
適切な総接続数を維持することで、Redisのパフォーマンスを最適化することができます。
db.syncPartialErr: これは、部分的な同期の完了に失敗した回数です。マスターとレプリカ間のレプリケーションは、マスターによって定義された特定のレプリケーションIDに基づいて行われます。レプリカが新しいマスターとして選出されると、そのレプリケーションIDも変更されます。この場合でも、レプリカと旧マスター間の部分的な再同期は可能です。
New RelicによるRedisの監視
New RelicのRedis Integrationは、New Relic Infrastructureエージェントを使用して、Redisインスタンスからパフォーマンスメトリクスを収集し、New Relicプラットフォームに送信します。
New Relicインフラストラクチャエージェントは、Redisノードと同じマシン上に配置され、Redisサーバから重要なパフォーマンスデータを収集し、New Relicプラットフォームに送信します。事前に構築されたダッシュボードを使って環境を監視したり、アラートポリシーやカスタムクエリ、カスタムチャートを作成したりすることができます。
ここでは、Linux（この場合はUbuntuサーバー）でRedisを監視するために必要なセットアップ手順を見てみましょう。
注: KubernetesのサービスやAmazon ECSで実行されているRedisを監視することもできます。
AgentとIntegrationをUbuntuサーバーにインストールする
- New Relic Oneから、（右上隅にある）アカウントのドロップダウンに移動し、「Add more data」を選択します。
- オペレーティングシステム（この場合はUbuntu）を選択し、プロンプトに従ってライセンスキーを取得し、Ubuntuのバージョンを選択します。
- Infrastructure エージェントと Redis Integrationをデプロイするには、サーバ上で以下のコマンドを実行します。
- Infrastructure agent のGPG 鍵をインポートします
curl -s https://download.newrelic.com/infrastructure_agent/gpg/newrelic-infra.gpg | sudo apt-key add -
- New Relic Repository を追加します。すべてのディストリビューションについてはこちら。
printf "deb [arch=amd64] https://download.newrelic.com/infrastructure_agent/linux/apt bionic main" | sudo tee -a /etc/apt/sources.list.d/newrelic-infra.list
- Infrastructure Agent(
newrelic-infra)とRedis Integration(nri-redis)をインストールします。
sudo apt-get update && sudo apt-get install -y newrelic-infra nri-redis
- Infrastructure agent のGPG 鍵をインポートします
Redis Integration を設定する
- Integration の設定ディレクトリに移動します。
cd /etc/newrelic-infra/integrations.d
- サンプルの設定ファイルをコピーします。
sudo cp redis-config.yml.sample redis-config.yml
- Redisサーバーへの接続方法に応じて
redis-config.ymlを編集します。- Unix Socketによる接続: Unix Socketを使って接続する場合は、設定ファイルで
unix_socket_pathを指定してください。複数のRedisインスタンスが Unix ソケットを使用している場合は、必ずuse_unix_socketを true に設定してください。Redis Integrationを実行するユーザが Unix Socketにアクセスできるように正しいパーミッションを持っていることを確認してください。Unixソケットのパーミッションは(unixsocketpermの値を通して)Redisの設定で設定されます。 - TCPによる接続: TCP 経由で接続する場合、設定ファイルはデフォルトで
localhostと port6379に設定されています。これを変更するためには、hostnameまたはport引数を指定します。この方法を使用した場合、unix_socket_pathパラメータは設定できません。
- Unix Socketによる接続: Unix Socketを使って接続する場合は、設定ファイルで
- 必要に応じて、Redisの構成にあわせて設定を追加で行います。
- Infrastructure Agentを再起動します。
systemctl restart newrelic-infra
New RelicでRedisデータを見る
まずRedisのモニタリングを始めるには、Infrastructure > Third-party Services > Redis Dashboardに移動します。
先に述べた重要なメトリクスのいくつかに焦点を当てて、いくつかの例を見てみましょう。まずはステータスメトリクスから見ていきましょう。
Uptime millisecondsチャートはRedisの可用性を追跡します。アップタイムが高ければ高いほど、サーバがより長くノンストップで利用可能であることを意味します。
Total system memory bytesを使用して、需要の増加に対応するためにストレージ容量を追加する必要があるかどうかを予測します。
Connected clientsチャートで、Redisデプロイメントがクライアントのプロセスやアプリケーションに対応しているかどうかを調べられます。
Commands processed per secondチャートに注目して、コマンドが急激に減少していないかどうかを確認してください。
Keyspace hits per secondと Keyspace misses per secondのチャートは、キャッシュヒット率、つまりクライアントがRedisをどれだけ効率的に使用しているかを表示します。
Rejected connections per secondチャートでは、不正なクライアントが新しい接続を要求しているか、または最大接続数を過小評価している可能性があるどうかを、その数のスパイクから視覚化することができます。
Number of sync errorsチャートで予期せぬ急増が見られた場合、マスターインスタンスが頻繁に障害を起こしている可能性があります。
最後に
高速かつスケーラブルでフォールトトレラントなRedisデータベースを実現するためにモニタリングが不可欠である理由と、Redisマスターとレプリカインスタンスが最高の状態で稼働していることを確認するためにモニタリングすべき主要なメトリクスについてご理解いただけたと思います。
New RelicのIntegrationは、Redisインスタンスの健全性を維持するために利用できる貴重なツールです。重要な指標を早期に警告することで、New Relicはアプリのユーザーエクスペリエンスの低下、トランザクションデータベースへの負担の増大、クライアント接続の拒否などの原因となるデータベースの障害を防ぐことができます。
Redis Integrationはオープンソースのソフトウェアです。つまり、ソースコードを閲覧して改善点を送信したり、独自のフォークを作成してビルドしたりすることができます。
詳細については、On-Host Integrationのすべてのリストをチェックしてください。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
