問題インデックス
分散キャッシュデータベースはデータ永続化をサポートしていますか？
RedisエンジンとValkeyエンジンはどちらもデータ永続化をサポートしており、システムはデフォルトでRDB + AOFハイブリッド永続化戦略を有効にします：
RDB（Redis Database Backup）：定期的にメモリデータのスナップショットを生成してディスクに書き込み、占有スペースが小さく、復旧速度が速いです。
AOF（Append Only File）：各書き込みコマンドを記録し、データの安全性がより高くなります。システムはデフォルトで毎秒1回ディスクにフラッシュし（appendfsync everysec）、パフォーマンスとデータ安全性のバランスを取ります。
さらに、分散キャッシュデータベースは自動バックアップと手動バックアップの機能も提供します。システムは毎日自動的に1回フルバックアップを実行し、バックアップデータはデフォルトで7日間保持されます（1～30日に設定可能です）。ユーザーはいつでもコンソールで手動バックアップをトリガーでき、変更前のデータ保護に利用できます。
説明：
Memcachedエンジンは純粋なメモリキャッシュであり、データ永続化をサポートしません。
購入したばかりのインスタンスのストレージ容量が2M占有されていますが、これは正常ですか？
正常です。これはシステムが自身のデータ構造を維持するために使用するスペースであり、正常な現象に属し、業務の利用に影響しません。
インスタンスがサポートする最大接続数はいくつですか？
インスタンスの最大接続数は、アーキテクチャタイプとインスタンス仕様によって異なります：
|
標準アーキテクチャ | 10,000 - 40,000（仕様に応じて増加） |
クラスタアーキテクチャ | 10,000 × シャード数 |
接続数が上限に近づいた場合、以下の方法で最適化できます：
クライアントが接続プールを使用しているかどうかを確認し、接続の頻繁な作成と破棄を避けてください。
接続リーク（長時間アイドル状態の接続が解放されていない）が存在するかどうかを調査してください。
業務で確かにより多くの接続が必要な場合は、インスタンス仕様のアップグレードまたはシャード数の追加によって接続数の上限を引き上げることができます。
インスタンスのメモリ使用率が高すぎる問題にどう対処すればよいですか？
インスタンスのメモリ使用率が継続的に80%を超えた場合、以下の対策を講じることをお勧めします：
大規模Keyの調査
コンソールにログインし、大規模Key分析機能を使用してインスタンス内の大規模Keyをスキャンしてください。大規模Keyは大量のメモリを占有するだけでなく、リクエスト遅延の増加やマスター/スレーブ同期の中断を引き起こす可能性があります。10MBを超えるKeyは複数の小さなKeyに分割するか、Hash構造を使用して単一の大きなStringを置き換えることをお勧めします。
有効期限ポリシーを確認してください
業務データに適切な有効期限（TTL）が設定されているかどうかを確認してください。TTLが設定されていないKeyが大量に存在する場合、メモリは継続的に増加します。OBJECT IDLETIMEコマンドでKeyのアイドル時間を確認し、長期間アクセスされていないデータに対して有効期限ポリシーを設定するか、手動でクリーンアップしてください。
インスタンスを拡張します
最適化後もメモリ使用率が依然として高い場合、現在の仕様ではビジネス要件を満たせなくなっています。コンソールでオンライン拡張を実行できます。標準アーキテクチャは垂直拡張（メモリ仕様の向上）をサポートし、クラスタアーキテクチャは水平拡張（シャード数の追加）をサポートします。拡張プロセスは通常数分で完了し、その間もインスタンスは正常に読み書きできます。
拡張と縮小は業務を中断しますか？
拡張および縮小が業務に与える影響は操作タイプによって異なります：
|
垂直スケールアップ（メモリ拡張） | 秒単位の瞬断が発生する可能性があります。 | 単一マシンの残り容量を超えた場合、ノード移行が行われ、秒単位の瞬断が発生します。超えなかった場合は影響ありません。 |
垂直スケールダウン（メモリ縮小） | 中断しません。 | 秒単位の瞬断は発生しません。 |
水平スケールアウト（シャード追加） | 秒単位の瞬断が発生します。 | ノードを追加するとデータ移行がトリガーされます。 |
水平スケールイン（シャード削減） | 秒単位の瞬断が発生します。 | ノードを回収するとデータ移行がトリガーされます。 |
業務の低ピーク時またはメンテナンス時間枠内に拡張・縮小操作を実行し、業務への影響を低減することをお勧めします。
インスタンスはバージョンアップグレードをサポートしていますか？
サポートされています。分散キャッシュデータベースは、メジャーバージョンとマイナーバージョンの2種類のアップグレード方式をサポートしています：
メジャーバージョンアップグレード：クロスバージョンアップグレード（Redis 5.0からRedis 6.2または7.0へのアップグレードなど）をサポートしています。アップグレード後は新バージョンの機能とコマンドを使用できます。アップグレード中は短時間の接続断（通常秒単位）が発生します。メンテナンス時間枠内での実行をお勧めします。
マイナーバージョンアップグレード：システムは定期的にマイナーバージョン更新をリリースします。これにはパフォーマンス最適化とセキュリティ修正が含まれます。手動トリガーまたはメンテナンス時間枠内での自動更新設定をサポートしています。
Proxyバージョンアップグレード：エンジンバージョンとProxyバージョンは独立してアップグレードでき、互いに影響しません。
説明：
バージョンアップグレードは不可逆な操作です。アップグレード前に業務コードがターゲットバージョンと互換性があることを確認してください。まずテスト環境で検証してから、本番環境でアップグレードを実行することをお勧めします。
インスタンスは標準アーキテクチャからクラスタアーキテクチャへのアップグレードをサポートしていますか？
サポートされています。コンソールのインスタンス詳細ページでアーキテクチャをアップグレードし、標準アーキテクチャのインスタンスをクラスタアーキテクチャにアップグレードできます。アップグレード中は短時間の接続断が発生します。メンテナンス時間枠内での実行をお勧めします。
利用可能なメモリが購入した仕様より少ないのはなぜですか？
これは、システムがマスタースレーブ同期と内部管理操作のために一部のメモリを予約し、インスタンスの安定した動作を確保するためです。
予約済みメモリの用途：
マスタースレーブレプリケーションバッファ：マスターノードがスレーブノードにデータを同期する際、バッファ（replication backlog）を使用する必要があります。デフォルトで一定のメモリを占有します。
システムプロセスオーバーヘッド：Redisプロセス自体の実行には少量のメモリ消費が必要です。
Copy-On-Write予約：RDBバックアップまたはAOF書き換えを実行する際、fork子プロセスによってメモリが倍増する可能性があります（Copy-On-Write）。OOMによるシステム強制終了を避けるためにスペースを予約します。
出力バッファ：クライアントおよびマスタースレーブ同期の出力バッファは追加のメモリを占有する必要があります。
各仕様の実際に利用可能なメモリ：
実際に利用可能なメモリ = 購入した仕様のメモリ - システム予約済みメモリ。システム予約済みメモリは通常、仕様総量の15% - 20%です。例えば、4GB仕様のインスタンスを購入した場合、実際に書き込み可能なデータ量は約3.2GB - 3.4GBです。
推奨事項：
容量計画時は実際に利用可能なメモリに基づいて見積もり、20%の余裕を確保してください。
メモリ使用率のアラートしきい値を65% - 75%に設定し、事前に拡張評価をトリガーしてください。
頻繁にメモリ上限に近づく場合は、淘汰ポリシーに依存するのではなく、仕様のアップグレードを推奨します。