問題インデックス
インスタンスの稼働状態をどのように監視しますか？
分散キャッシュデータベースは30項目以上の監視指標を提供し、最小収集粒度は5秒で、以下の次元をカバーします：
リソース監視：CPU使用率、メモリ使用率、接続数使用率、帯域幅使用率。
性能監視：QPS（毎秒クエリ数）、コマンド実行遅延、スロークエリ数。
トラフィック監視：受信トラフィック、送信トラフィック、毎秒読み取り/書き込み回数。
キーバリュー監視：Key総数、期限切れKey数、削除されたKey数。
同時にアラートポリシーの設定をサポートし、指標がしきい値に達すると自動的にSMS、メール、またはWeChatで通知をプッシュします。少なくとも以下のアラートを設定することを推奨します：メモリ使用率 greater than 80%、CPU使用率 greater than 90%、接続数使用率 greater than 80%。
さらに、DBbrainのインテリジェント診断機能は、大きなKeyやホットKeyなどのパフォーマンスボトルネックを自動的に検出し、最適化の提案を提供します。
インスタンスのCPU使用率が100%に達した場合の対処方法は？
CPU使用率の継続的な急上昇は、ユーザーが最も頻繁に遭遇するパフォーマンス問題の一つであり、通常は以下の原因によって引き起こされます：
高複雑度コマンド
時間計算量の高いコマンド（KEYS *、SORT、SUNION、大規模セットのSMEMBERSなど）を実行すると、CPUを長時間占有します。コンソールのスロークエリログで時間のかかるコマンドを調査し、低複雑度のソリューションに置き換えることを推奨します：
SCANを使用してKEYS *の代わりに走査してください。
SSCANを使用して大規模セットのSMEMBERSを置き換えてください。
超大セットに対するSORTの実行を避け、ビジネス層でのソートに変更してください。
ホットキー集中アクセス
大量のリクエストが少数のKey（ホットKey）に集中してアクセスし、単一データノードのCPU過負荷を引き起こします。DBbrainのホットKey分析機能を使用してホットKeyを特定できます。処理方法は以下の通りです：
ホットKeyに対してローカルキャッシュ（Local Cache）を実施し、Redisへのアクセス頻度を低減します。
ホットKeyを複数のサブKeyに分割し、異なるノードに分散させてください。
クラスタアーキテクチャでは、読み書き分離を有効にすると、読み取りリクエストがレプリカノードに分散されます。
短時間に大量のキーが集中期限切れ
大量のKeyが同時期に集中して期限切れになると、Redisの期限切れクリーンアップメカニズムが追加のCPUリソースを消費します。Keyの有効期限にランダムなオフセット（例：TTL + random(0, 300)）を追加し、集中期限切れを回避することをお勧めします。
接続数過多
過剰なクライアント接続数もCPUオーバーヘッドを増加させます。コンソールで接続数使用率を監視し、接続数が異常に高い場合は、クライアントが接続プールを使用しているか、接続リークが存在するかを確認してください。
調査の推奨事項：
1. コンソールでCPU使用率の監視曲線を確認し、急上昇した時間帯を特定してください。
2. 該当時間帯のスロークエリログを確認し、時間のかかるコマンドを特定してください。
3. DBbrainのインテリジェント診断機能を使用すると、システムがCPU異常の原因を自動的に分析し、最適化の提案を提供します。
インスタンスデータが誤って削除された後の復旧方法は？
インスタンスデータが誤って削除された場合（例：FLUSHALLまたはDELコマンドを誤って実行した場合）、以下の方法で復旧できます：
1. バックアップから復旧：コンソールのバックアップリストで、誤って削除する前のバックアップセットを選択し、データを新しいインスタンスに復元します。データの完全性を確認した後、アプリケーションを新しいインスタンスに切り替えることができます。
2. ロールバック復旧（有効な場合）：データロールバック機能を有効にしている場合、インスタンスデータを指定時点までロールバックでき、復旧精度は秒単位です。
予防の推奨事項：
コンソールでFLUSHALL、FLUSHDBなどの危険コマンドを無効化してください。
マルチアカウント権限制御を構成し、一般業務アカウントのコマンド実行範囲を制限してください。
自動バックアップポリシーが正常に動作していることを確認し、重要な変更の前に手動でバックアップを一度実行してください。
クライアント接続情報と統計データを取得する方法は？
CLIENT LISTコマンドを使用すると、インスタンスに接続しているすべてのクライアント情報と統計データを確認できます。接続リークの調査や、業務停止前の接続確認によく使用されます。返される主なフィールドは以下の通りです：
|
id | 一意の64ビットクライアントID |
addr | クライアントのアドレスとポート |
name | クライアントがCLIENT SETNAMEで設定した名前 |
age | 秒単位で計算した接続時間 |
idle | 秒単位で計算したアイドル時間 |
cmd | 最後に実行されたコマンド |
説明：
高負荷かつ大規模なデプロイ環境では、CLIENT LISTコマンドが特定のシャードに大きなメモリ負荷をかける可能性があるため、業務の低ピーク時に実行することをお勧めします。
レプリカノードとプライマリノードのデータが同期していない場合の対処方法は？
Redisは非同期レプリケーション技術を採用しているため、スレーブノードのデータ更新がマスターノードよりわずかに遅延する場合がありますが、これは正常な現象です。遅延が継続的に大きい場合、考えられる原因は以下の通りです：
マスターノードのI/O書き込み量がスレーブノードの同期速度を上回っています。
マスターノードとスレーブノードの間にネットワーク遅延が存在します。
以下の方法で調査することをお勧めします：
1. コンソールでマスタースレーブ同期遅延の監視指標を確認します。
2. 大きなKeyの頻繁な書き込みが存在し、同期バッファのオーバーフローを引き起こしていないか確認してください。
3. マスターノードとスレーブノードのネットワーク帯域幅が十分かどうかを確認してください。
同期遅延が継続的に大きい場合は、コンソールでマスタースレーブ切り替えまたはスレーブノードの再起動を実行して同期を回復できます。
スロークエリログとProxyスローログの違いは何ですか？
分散キャッシュデータベースは、Proxy層スローログとRedisエンジン層スロークエリログの2層のスローログを提供します。両者は記録する次元が異なるため、問題を調査する際には組み合わせて使用する必要があります。詳細については、スロークエリを参照してください。 |
記録位置 | Redisデータノード | Proxyプロキシ層 |
計測範囲 | コマンド実行時間のみ | キュー待機、ネットワーク転送、コマンド実行を含む全リンクの所要時間 |
適用シーン | 単一の低速コマンドを特定します | 全リンクの遅延問題を特定します。 |
一般的な調査シナリオ：
Proxyスローログには記録がありますが、Redisエンジンのスロークエリには記録がありません：遅延がキューイングまたはネットワーク層で発生していることを示しており、接続数が多すぎるか帯域幅が不足してリクエストがキューイングされている可能性があります。
両方の層に記録がある場合：コマンド自体の実行に時間がかかりすぎていることを示しており、コマンドの複雑さを最適化するか、大きなKeyを処理する必要があります。
Redisエンジンのスロークエリには記録がありますが、Proxyスローログには記録がありません：通常この状況は発生しません。発生した場合はテクニカルサポートに連絡してください。
プライマリ・レプリカノードのメモリ使用率が一致しない場合の対処方法は？
マスターノードとスレーブノードでメモリ使用率に差が生じることは比較的一般的な現象です。一般的な原因と対処方法は以下の通りです：
出力バッファ（output buffer）の使用
スレーブノードが全量データを同期する際、またはクライアントが大量のデータを読み取る際に、出力バッファは一時的に追加のメモリを占有します。これは正常な動作であり、同期が完了するとバッファは解放されます。
期限切れKeyの遅延削除
Redisの期限切れKeyの削除には「遅延削除＋定期スキャン」というメカニズムが採用されています。スレーブノード上の期限切れKeyは、マスターノードがDEL命令を送信するまで削除されないため、スレーブノードは期限切れだがまだクリーンアップされていないKeyを一時的に保持する可能性があり、メモリ使用量が高くなることがあります。
データ構造の断片化
マスターノードとスレーブノードのメモリ断片化率は異なる場合があります。スレーブノードの断片化率がマスターノードより明らかに高い場合は、コンソールでメモリデフラグ（activedefragパラメータ）の実行を試すことができます。
対処方法
1. コンソールでマスターノードとスレーブノードのメモリ使用率と断片化率の監視データを比較します。
2. 差異が10%以内で安定している場合は正常範囲内であり、対処は不要です。
3. 差異が継続的に拡大する場合は、大量のKeyが集中的に期限切れになっているか、または大きなKeyの書き込みが存在していないか確認してください。
4. 必要に応じてマスタースレーブ切り替えまたはスレーブノードの再起動を実行し、データを再同期できます。
インスタンスで主系・待機系の切り替えが発生する原因は何ですか？業務への影響は？
マスタースレーブ切り替え（マスタースレーブフェイルオーバー、HA切り替えとも呼ばれます）とは、インスタンスのマスターノードが故障または運用保守操作によりスレーブノードに切り替わり、サービスを継続して提供することを指します。これは分散キャッシュデータベースの高可用性保障メカニズムであり、マスターノードに異常が発生した際にインスタンスが自動的にサービスを復旧することを保証します。
主系・待機系切り替えの一般的な発生原因
|
メインノード障害 | マスターノードのプロセスが異常終了、ダウン、またはハートビートがタイムアウトした場合、システムが自動的に切り替えをトリガーします。 |
運用保守操作 | バージョンアップグレード、パラメータ変更（一部のパラメータは再起動後に有効になります）、スケールアウト/スケールイン、アベイラビリティーゾーン間の移行 |
手動トリガー | ユーザーはコンソールで手動によるマスター/スレーブ切り替えを実行します（災害復旧訓練または計画移行に使用します）。 |
リソース異常 | マスターノードのメモリまたはCPU使用率が高すぎる場合、システム保護切り替えがトリガーされます。 |
業務への影響
接続断絶：切り替えプロセス中に秒単位の接続中断が発生し、クライアントは接続切断またはタイムアウトエラーを受信します。
短時間読み取り専用：切り替えプロセス中に最長1分間の読み取り専用状態が発生する可能性があります（データ同期の完了を待つため）。
データ整合性：計画内切り替え（バージョンアップ、拡張・縮小などの運用保守操作）では、切り替え実行前に全量および増分データ同期が完了するため、データ損失は発生しません。非計画フェイルオーバー（マスターノードのダウン）の場合のみ、Redisは非同期レプリケーションを採用しているため、スレーブノードにまだ同期されていない少量の書き込みが失われる可能性があります。
業務適合の推奨事項
1. クライアントに自動再接続メカニズムを設定し、合理的な再試行ポリシーを設定します（例：再試行3回、間隔200ms）。
2. 書き込み操作に対して冪等性を考慮した設計を行い、再試行によるデータ重複を回避してください。
3. コンソールからインスタンスイベントアラートをサブスクライブし、マスタースレーブ切り替え通知をタイムリーに把握できます。
4. 接続プールを使用し、ハートビート検出を設定して、接続切断後の迅速な復旧を確保してください。
帯域幅使用率が100%を超える原因は何ですか？
コンソールの監視において、帯域幅使用率が100%を超えて表示されることがありますが、これはシステム異常ではなく、統計方法に起因する正常な現象です。
原因の説明
分散キャッシュデータベースの帯域幅使用率統計には、2つのトラフィックが含まれます：
業務トラフィック：クライアントの読み書きによって発生する受信トラフィックと送信トラフィック。
マスタースレーブ同期トラフィック：マスターノードがスレーブノードにデータを同期する際に発生する内部トラフィック。
コンソールに表示される帯域幅制限の閾値は業務トラフィックのみを対象としていますが、監視曲線にはマスタースレーブ同期トラフィックが加算されている可能性があります。そのため、マスタースレーブ全量同期や大量書き込みのシナリオでは、監視値が100%を超える場合があります。
帯域幅超過後の影響
業務トラフィックが実際にインスタンスの帯域幅制限を超えた場合、フロー制御メカニズムがトリガーされます：
入方向の超過：クライアントの書き込みリクエストは速度制限され、応答遅延の増加またはタイムアウトとして現れます。
出方向の超過：クライアントの読み取りリクエストは速度制限され、大きなValueの読み取りはタイムアウトする可能性があります。
対処方法
1. コンソールで受信帯域幅と送信帯域幅のそれぞれの監視を確認し、どちらの方向が超過しているかを確認してください。
2. 大きなKeyの読み書きによって瞬間的な帯域幅の急上昇が発生していないか確認してください。
3. 業務帯域幅の需要が現在の仕様制限を確実に超えている場合は、コンソールで帯域幅を調整するか（現在は無料）、またはインスタンスの仕様をアップグレードできます。
4. クラスタアーキテクチャは、シャードを追加することでトラフィックを分散できます。
クラスタアーキテクチャでデータスキューが発生した場合の対処方法は？
データの偏りとは、クラスタ内の各シャード間でメモリ使用量またはリクエスト量の分布が不均一になり、特定のシャードの負荷が高くなる一方で、他のシャードのリソースが遊休状態になることを指します。
データスキューの判別
コンソールのノード管理ページで、各シャードのメモリ使用率とQPSを確認します：
メモリの偏り：特定のシャードのメモリ使用率が他のシャードより明らかに高い状態です（例えば20%以上高い場合）。
リクエストの偏り：特定のシャードのQPSが他のシャードよりはるかに高い状態です。
一般的な原因
|
大Keyの集中 | 複数の大きなKeyがハッシュアルゴリズムによって同じシャードに割り当てられます。 |
Hash Tagの不適切な使用 | 業務で{tag}を使用して、大量のKeyを同一のSlotに強制的にルーティングします。 |
ホットKey | ホットKeyが特定のシャードに集中し、リクエストの偏りを引き起こします。 |
Slotの分布が不均一です。 | 少数のシナリオでは、Slotのデータ量が元々不均一です。 |
対処方法
1. 偏りのあるシャードの特定：コンソールのノード監視を通じて、メモリまたはQPSが高いシャードを見つけます。
2. 大きなKeyの調査：偏りのあるシャードに対して大きなKey分析を実行し、大きなKeyを分割またはクリーンアップします。
3. Hash Tagの最適化：大量の無関係なKeyを同じHash Tagで同一Slotに強制的にルーティングすることを避けてください。
4. ホットKeyの分散：ランダムなサフィックスを追加してホットKeyを異なるシャードに分割します。
5. シャードの拡張：シャード数を増やすと、システムが自動的にSlotの再分散を行い、データの均衡を改善します。
監視データにスパイクや急変が発生した場合の調査方法は？
監視曲線に突発的な上昇や下降（スパイク）が発生する場合、通常は以下の原因が考えられます：
メモリ使用率の急増
大量の新しいKeyの書き込み、または大きなKeyの作成。
マスタースレーブ全量同期時の一時バッファ占有。
大量のKeyが集中して期限切れになった後、定期的にスキャンされクリーンアップされます（先に上昇し、その後下降する形で現れます）。
CPU使用率の急増
高負荷なコマンドを実行しました（スロークエリログで確認できます）。
大量のKeyが集中して期限切れになると、クリーンアップがトリガーされます。
短時間の高同時実行リクエスト。
接続数の急増
ビジネス側のリリースに伴い、大量のクライアントが同時に接続を確立します。
接続プールの設定が不適切なため、クライアントが頻繁に新しい接続を作成します。
ネットワークのジッターにより、古い接続が切断された後に再接続されます。
QPSの急減
クライアント側のネットワーク異常またはサービス中断。
インスタンスがフロー制御をトリガーします（帯域幅または接続数が制限を超えた場合）。
主系切替中は一時的に利用できません。
調査方法
1. 毛刺が発生した正確な時間帯を特定します（5秒粒度の監視を確認することをお勧めします）。
2. 該当時間帯のスロークエリログ、イベントアラート、運用保守操作記録を照合してください。
3. クライアントログに対応する異常エラーがあるかどうかを確認してください。
4. 毛刺が周期的に発生する場合は、タイマータスク（フルスキャンやデータ同期など）がトリガーしていないか調査してください。