ベストプラクティス Databases for Redis
Databases for Redisを使用している場合は、時間をかけて以下のベスト・プラクティスを確認してください。
Databases for Redisとは何ですか?
Databases for Redis は、 IBM Cloudで提供される管理対象 Redis OSS サービスです。 これは、データベース、キャッシュ、メッセージ・ブローカー、およびストリーミング・エンジンとして使用されるメモリー内の データ構造ストア です。 ディスクにデータを保管する従来のデータベースとは異なり、 Redis では、データをメモリー (RAM) に保管するため、待ち時間を短くすることができます。 データは _ephemeral_です。これにより、 Databases for Redis は最高のパフォーマンスと高いスループットを提供できます。 また、データ可用性とのトレードオフ・パフォーマンスによってデータをディスク上に永続的に保管するように Redis を構成することもできます。これは、RBD スナップショットとの AOF (ファイルのみ追加) 同期を有効にすることによって実現されるためです。
RBD スナップショットは、永続性が無効になっている場合でも、バックアップおよび高可用性のために有効になります。
インスタンス・キャパシティー・プランニングのベスト・プラクティス
アプリケーションおよびアーキテクチャーの設計に基づいて Databases for Redis インスタンスの容量を計画し、ハードウェア要件を理解し、需要の増減に備える必要があります。 以下の推奨事項は、インスタンスのサイズを最適化するのに役立ちます。
- データの理解
- データのデータ・タイプ、サイズ、および存続時間を把握しておく必要があります。 これは、メモリー内で使用可能なデータが削除または移動されるまでの所要時間を理解するのに役立ちます。
- メモリー所要量の見積もり
- メモリー所要量を計算することが重要です。 データだけでなく、複製、クライアント接続、最大メモリー・バッファー、および Redis メタデータに必要なメモリーも考慮に入れることを忘れないでください。
- 読み取り/書き込みロードの理解
- 読み取り/書き込みロードを識別することにより、自動スケーリングのニーズに備え、アプリケーション要求の時間を調整し、マスター/フォロワーの同期を維持することができます。
- IOPS のニーズを理解する
- 1 秒当たりの入出力操作は、インスタンス・キャパシティー・プランニングで考慮する必要がある重要な要因です。 Databases for Redis は、デフォルトの Redis 構成に従って定期的に RDB スナップショットを取得します。これにより、インスタンスがキャッシュ用にセットアップされている場合でもディスクが使用されます。 非常に負荷の高いデータベースでは、ディスクサイズのIOPSを超えることがあり、ディスクサイズを大きくすることでパフォーマンスのボトルネックを緩和できることがあります。
- 冗長性および再接続の計画
- クラウド計算に関係する複数のコンポーネントがあり、これが原因で一時的な障害が発生する可能性があります。 ただし、 IBM® Cloud Databasesでは、 99.99% の高可用性が提供されており、再試行と再接続のロジックを使用してアプリケーション設計の接続ブリップを計画することをお勧めします。
- ネットワーク帯域幅の検討
- ネットワーク帯域幅は、 Databases for Redis のパフォーマンスに大きな影響を与える可能性があります。 データベースの負荷を処理するために十分なネットワーク帯域幅があることを確認します。
- モニターと調整
- Databases for Redis インスタンスのパフォーマンスと使用状況を IBM Cloud® Monitoring で監視し、データベースインスタンスの使用状況の変化を把握し、必要に応じてサイズを変更することをお勧めします。
パフォーマンスのベスト・プラクティス
- パーシスタンスを無効にする
- デフォルトでは、 Databases for Redis で永続性が有効になっています。 これにより、AOF 同期が書き込まれ、IOPS の負荷が増加します。 アプリケーションでデータを永続化する必要がない場合は、コマンド
Set appendonly = no
を使用してこれを無効にします。 詳しくは、以下を参照してください
お手本となるキャッシュの設定 - RAM とコアの比較
- Redis は、単一スレッドのメモリー内データベースです。 本質的に、他の永続データベースとは異なり、CORES よりも多くの RAM を必要とします。 単一スレッドであっても、「多重化」を使用して要求を処理しますが、すべての要求はスレッドによって処理されます。 ただし、内部プロセスのデータベースの整合性と安定性を維持するには、他のコアが必要です。 Databases for Redisの RAM とディスク (IOPS 用) にさらに集中することをお勧めします。 詳しくは、 インスタンス・キャパシティー・プランニングのベスト・プラクティス を参照してください。
- メモリーのダウンサイジング
- Databases for Redis インスタンスのメモリーを削減する際には注意することをお勧めします。 Redis はメモリー内のデータベースであるため、そのメモリーには、保管、処理、および取得の目的でデータが保持されます。 メモリーを大幅に削減すると、操作を完了するために使用できる十分なスペースがないため、インスタンスがエラーを返すのを一時的に停止する可能性があります。 例えば、15 GB のメモリーに 20 GB のデータをロードしようとしているとします。この場合、エラーが返されます。
- コストのかかるコマンドを避ける
- Redis のコマンドの中には、実行にコストがかかるものがあります。 例えば、KEYS コマンドは頻繁に使用されますが、避ける必要があります。 代わりに、SCAN コマンドを使用してください。これにより、反復が多数の呼び出しに分散され、サーバー全体が一度に占有されることはありません。
- 排除ポリシーの選択
- アプリケーションで機能する排除ポリシーを選択する必要があります。 デフォルトでは、デプロイメントは
noeviction
ポリシーを使用して構成されています。 Use eviction policies likeallkeys-lru
,volatile-lru
,allkeys-random
,volatile-random
,volatile-ttl
. For more information, see メモリーポリシー. - maxmemory 値の設定
maxmemory
値を調整できます。 ただし、妥当な制限を設定してください。そうしないと、データがすべての使用可能メモリーを消費する可能性があり、デプロイメントでリソースが不足する可能性があります。 デフォルトでは、データ・ノードの使用可能メモリーの 80% に設定されています。- TTL (Time-To-Live) ポリシーの設定
- TTL は、定義された時間の後にキーがデータベースから削除されるという優れた機能です。 これは、 Redis キャッシュを使用している場合に非常に役立ちます。 ただし、非常に短い値または非常に長い値を設定する場合は注意してください。非常に短い値を設定すると、値の再計算が行われる可能性があり、非常に長い値を設定すると、不要なメモリー使用が発生する可能性があるためです。 詳細は TTLコマンドを参照。
高可用性のためのベストプラクティス
- 再試行および再接続のロジック
- システムが中断する傾向があります。 中断を回避するために、再試行および再接続のロジックをアプリケーション・アーキテクチャーに実装することを強くお勧めします。 IOREDIS、NODEREDIS、またはその他の任意のパッケージを使用して、アプリケーションの継続性を確保します。
詳しくは、Redisによるエラー検出と処理をご覧ください。
モニターのベスト・プラクティス
LogDNA で以下の一般的なエラーをモニターし、修正措置を取る必要があります。
- AOF 同期
- 読み取り専用が使用可能
- マスターへの接続が失われました
- エラーの防止に関するガイダンスについては、 一般的な Databases for Redis のエラーを回避するにはどうすればよいですか? を参照してください。
一般的なベスト・プラクティス
- 接続プーリング
- 接続の作成またはクローズにはコストがかかります。 接続を効率的に管理することは重要です。接続プールは、接続のオープンとクローズに関連するオーバーヘッドを最小限に抑えるために役立ちます。 詳細は、 コネクションプーリング を参照してください。
- 接続制限
- 接続を効率的に使用します。 Databases for Redis に過剰な接続を行うとエラーが発生し、アプリケーションが中断されることがあります。 いくつかの接続は、データベースの状態と保全性を維持するために内部的に予約されているため、使用可能なままにしておいてください。 接続プールを使用することをお勧めします。 詳細は、 接続数制限 をご覧ください。
- 接続タイムアウト
- リソースが無限に拘束されないようにするために、接続に適切なタイムアウト値を設定することも重要です。 ただし、短いタイムアウトを設定すると、接続チャーンが発生し、待ち時間が長くなる可能性があるため、注意してください。 アプリケーションの運用上の期待に合わせてタイムアウトを調整します。
- Redis パイプライン機能の使用
- Redis パイプラインは、個々のコマンドに対する応答を待たずに複数のコマンドを同時に発行することによってパフォーマンスを向上させる手法です。 詳しくは、 Redis pipelining を参照してください。
- Redis Streams 機能の使用
- Redis Streams は、付加専用ログの超高速メモリー内抽象化を提供するデータ・タイプです。
- 大容量データの分割
- 大きなデータ・セットは、より多くのキーを持つ小さいチャンクに分割することをお勧めします。つまり、データを複数のキーに分割することをお勧めします。
- バッチ・スケジュール
- Databases for Redis は、スケジュールされた時刻に毎日自動バックアップを作成するようにスケジュールされています。 この間、データベース IOPS が使用されます。 この時点では、独自のバッチ・ジョブを実行しないことをお勧めします。
- 通知チャネルのセットアップ
- Databases for Redis では、 IBM アカウントに E メール ID をセットアップして、バージョンの変更、寿命の終わり、または保守スケジュールに関する定期的な更新を受け取ることをお勧めします。 IBM アカウント通知アイコンをモニターして、これらの更新を受け取ることもできます。
詳細については、IBM Cloudの Redisのベスト・プラクティスをご覧ください。