OCIキャッシュ・クライアントのベスト・プラクティス
次のベスト・プラクティスは、ターゲット・クラスタが非シャード・モードでもシャード・モードでも、すべてのOCIキャッシュ・クライアント相互作用に適用されます。これらのガイドラインに従うことで、一貫した行動が保証され、一般的な運用リスクが軽減されます。これらの推奨事項は、一般的なガイダンスを提供し、完全なドキュメントではありません。特定のライブラリおよびRedisまたはValkeyユース・ケースの詳細は、該当するリソースを参照してください。
クラスタのサイズ設定および構成に関する推奨事項
クラスタに適切なキャッシュ・サイズを選択すると、パフォーマンスとリソース使用率を最適化できます。キャッシュ・サイズは、予想されるアプリケーション・ワークロードを反映し、ビジネスピーク時の変化に合わせて調整する必要があります。OCIキャッシュを使用すると、ニーズに合せてクラスタをスケール・アップまたはスケール・ダウンできます。
キャッシュ・クラスタのサイズを設定する前に、アプリケーションのワークロード・パターンと将来の成長期待を考慮してください。
- アプリケーションは読取りが多いか、書込みが多いか。
- 読取り量: データ・サイズが500 GBを超えない場合は、非シャード・クラスタを使用し、トラフィックを分散するのに十分な読取りレプリカを追加します。
- 書込み量が多い: 大量のデータをキャッシュに格納する場合は、シャード・クラスタを検討してください。シャーディングでは、書込みトラフィックがノード全体に分散されるため、スループットが向上し、ボトルネックが回避されます。
- 読取りと書込みの両方: シャードごとに読取りレプリカを含むシャード・クラスタを使用します。この設定により、両方のワークロードの高可用性とスケーラビリティが提供されます。
- 適切なキャッシュ・サイズはどのように選択しますか。
キャッシュ・サイズを現在のデータ・サイズより少なくとも50%大きく設定します。このバッファは、クラスタのサイズを変更するまで、ワークロードの予期しないスパイクを処理します。
- ストレージ容量または書込み容量の将来的な増加を計画するにはどうすればよいですか。
柔軟性のためにシャード・クラスタを作成します。シャード・クラスタにより、要件の拡大に応じてストレージおよび書込み容量のスケーリングが容易になります。
- キャッシュ内で複数のデータベースを使用する必要があるのはいつですか。
キャッシュやセッション管理など、アプリケーションで異なる目的で同じキャッシュ内のデータを分離する必要がある場合は、非シャード・クラスタを選択し、必要に応じてデータベース・パラメータを調整します。複数のデータベースのサポートは、非シャード・クラスタでのみ使用できます。
- シャード・クラスタでLuaスクリプトを実行できますか。
はい、シャード・クラスタでLuaスクリプトを実行できます。ただし、Luaスクリプトには非シャード・クラスタを使用することをお薦めします。Luaスクリプトでは、参照されるすべてのキーが同じスロットに存在する必要があるため、非シャード・クラスタでの管理が容易になります。
クライアントライブラリの互換性
OCIキャッシュと完全に互換性のあるクライアント・ライブラリを使用します。推奨される最小バージョンには、Lettuce (6.x以降、特にシャード・クラスタのサポート用)およびRedisson (3.36.0以降)が含まれます。このバージョンでは、Transport Layer Security (TLS)やOCIキャッシュに必要な認証メカニズムなどの機能がサポートされます。本番環境にデプロイする前に、常に新しいライブラリ・バージョンをステージング環境でテストして、互換性と安定性を確保してください。
次の表に、OCIキャッシュのクラスタ・モード(シャーディング)をサポートする様々なプログラミング言語のクライアント・ライブラリの最小互換性バージョンと、クラスタ・サポート機能に関する関連ノートを示します。
| ライブラリ(言語) | GitHubリンク | 最小互換性バージョン | クラスタ・サポート・ノート |
|---|---|---|---|
| redis-py (Python) | redis/redis-py | 5.0.0+ | ネイティブ・クラスタ・モードのサポート(5.0.0以降) |
| Lettuce (Java) | レタス | 6.3.0 | 完全なクラスタのサポート |
| Jedis(Java) | ジェダイ | 3.1 | JedisClusterを介してサポートされているクラスタ |
| Redisson(Java) | レディソン | 3.36.0 | Redisクラスタを完全にサポート |
| redis-rb (Ruby) | アカスグリ | 5.3.0 | 再分散クラスタ化宝石が必要 |
| redis-rs (錆) | redis-rs | 0.26.1 | 部分的なサポート。クラスタ・モードはユースケースによって異なります。 |
| phpredis (PHP) | フランベジア | 6.0.0+ | RedisClusterを介したクラスタ・サポート |
| Go-Redis (実行) | フランベジア | v9.6.1 | クラスタ・モードを完全にサポート |
| StackExchange.Redis(C#) | StackExchange.Redis | 未サポート | AllowAdmin=trueが必要です。完全なクラスタ互換性がありません。ホスト名通信はサポートされていません |
| ServiceStack.Redis(C#) | ServiceStack.Redis | 未サポート | クラスタ・モードのサポートなし |
| hiredisクラスタ(C) | hiredis-cluster | 未サポート | ホスト名通信はサポートされていません |
接続の最適化
次のヒントは、アプリケーション・コードで実行できるアクションを示しています。指数関数的なバックオフを実装することもできます。
- 接続プーリングの有効化: 既存の接続を再利用して、リクエストごとに新しい接続を確立するオーバーヘッドを削減します。このアプローチにより、リソースの枯渇が防止され、アプリケーションのパフォーマンスが向上します。アプリケーションの同時実行性およびクラスタ容量に基づいてプール・サイズをチューニングします。最小または最大アイドル接続、接続タイムアウト、接続の最大待機時間などのパラメータを設定します。
- 同時接続の最適化: 各OCIキャッシュ・ノードは、最大40,000個のクライアント接続をサポートします。ワークロード、コマンド・パターンおよびクライアント動作に基づいて接続プールのサイズを設定し、必要以上の接続を維持しないようにします。過剰な同時接続により、プロセスのロードおよびレスポンス・レイテンシが増加する可能性があります。
- 適切なタイムアウトの設定: ネットワークの中断またはサーバーの遅延時の遅延を回避するために、コマンドおよび接続に適切なタイムアウト値(通常は2000 msから5000 ms)を定義します。
- 再試行メカニズムの構成: ネットワークの中断などの一時的な障害を処理するための再試行ポリシーを確立します。たとえば、3回の再試行を1000ミリ秒間隔で構成すると、リカバリに役立ちます。
- アイドル接続の管理: 未使用の接続をクローズして、リークを回避し、リソースを解放することで、キャッシュ・ノードが接続制限を超えないようにします。
セキュリティおよびTLSコンプライアンス
- OCIキャッシュでは、すべてのクライアント接続に対してデフォルトでTLSが義務付けられます。TLSは、ポート6379で常に有効になっています。必要に応じて、ポート7379で追加のTCPアクセスを許可できます。クライアント・ライブラリがTLSバージョン1.2以降をサポートしていることを確認し、現在の暗号スイートを使用してセキュアな通信チャネルを維持します。
- パフォーマンスが重要な場合は、OCIサポートおよびセキュリティ・チームと協力して、TLSオーバーヘッドの影響を評価します。本番環境でのTLSの無効化は、セキュリティの脆弱性のためにお薦めしません。
セキュリティのベストプラクティス
OCIキャッシュを最初から保護して、不正アクセスや脆弱性を防止します。OCIキャッシュでは、デフォルトですべてのクライアント接続にTLSが義務付けられていますが、本番環境では追加のセキュリティ対策が重要です。
- アクセスの制限: ネットワーク・ポリシーを構成して、信頼できるネットワークまたはlocalhostからの接続のみを許可します。OCIキャッシュ・エンドポイントをパブリック・インターネットに公開しないでください。
- 厳密認証の設定: 不正アクセスを防止するために、OCIのセキュリティ・ガイドラインに従って堅牢なパスワードまたは認証メカニズムが整備されていることを確認します。また、サービスでZero Trust Packet Routingおよびネットワーク・セキュリティ・グループ(NSG)サポートを使用して、OCIキャッシュ・インスタンスへのポリシーベースのアクセスを実施します。このアプローチでは、認可されたエンティティのみへのアクセスを制限することで、セキュリティをさらに強化します。
- 危険なコマンドの無効化: Redisでの偶発的または悪意のあるデータ損失を防ぐために、
FLUSHALLやCONFIGなどの有害なコマンドへのアクセスを制限します。 - 保護された構成の活用: OCI Cacheの組込みセキュリティ機能を使用し、アクセス制御を定期的に確認してセキュアな環境を維持します。
鍵の管理と期限切れ
すべてのキーに存続時間(TTL)を設定する必要はありません。一部のキーは無期限に保持される場合があります。ただし、ほとんどのキーに適切なTTL値を設定することをお薦めします。TTLを設定すると、失効したデータや孤立したデータがキャッシュに残らないようにできます。このアプローチにより、データの鮮度と効率的なメモリー使用量が保証されます。
キャッシュがそのメモリー制限に達すると、選択した削除ポリシーに従ってキーを自動的に削除するようにmaxmemory-policyパラメータを構成できます。この構成は、メモリー管理の最適化に役立ちます。
モニタリングおよびアラート構成
- メモリー使用率などの主要なメトリックを監視し、しきい値のアラート(使用率が30分間80%を超えた場合など)を設定して、メモリー不足状態およびクラスタの障害を防止します。ワークロードの進化に伴ってOCIキャッシュのパフォーマンスを維持するには、継続的な監視が不可欠です。
- 詳細ロギングの有効化:
SLOWLOGなどのツールを使用して、パフォーマンスに影響を与える前に低速なコマンドを特定します。 - ログを定期的に確認: OCIキャッシュ・ログ内の警告、エラーまたは異常なパターンをチェックして、問題を回避します。
- メモリーおよびエビクション率の監視: キー・エビクション頻度と、メモリー使用率(たとえば、30分間80%以上)などの既存のメトリックを追跡して、メモリー制限またはポリシーを事前に調整します。
- 詳細ロギングの有効化:
- 接続されたクライアント、拒否された接続、コマンド・レイテンシなどのメトリックを追跡して、ボトルネックや異常を特定して解決します。キャッシュ・ヒット率およびミス率を監視して、非効率的な使用を検出し、必要に応じてキー・ポリシーまたはエビクション・ポリシーを調整します。
- クラスタの健全性を維持するために、削除イベントや接続数などの他のメトリックにアラームを設定します。
- メモリー使用率が常に制限に違反している場合、またはCPU使用率が高い書込み操作を示している場合は、クラスタのサイズを変更します。
最適化されたコマンド使用法
KEYSなどのO(n)コマンドの使用を最小限に抑えます。かわりに、SCAN、HSCANまたはSSCANを使用します。- Redis操作をフリーズできるため、大規模なデータセットに対して
KEYSやSMEMBERSなどのコマンドを使用しないでください。かわりに、SCAN、SSCAN、HSCANなどの反復コマンドを使用して、システムをロックせずにデータをトラバースします。 - シャード・クラスタの互換性要件に準拠していることを確認するには、OCIキャッシュのドキュメントでサポートされていないコマンドのリストを参照してください。
- 関連するデータを複数のキーではなくハッシュに格納して、メモリを節約し、Redis環境で検索を迅速化します。
- パイプラインを利用して複数のコマンドを一度に送信することで往復時間を短縮し、接続プーリングを設定してレスポンス時間を短縮し、オーバーヘッドを最小限に抑えます
バックアップとリストアのベストプラクティス
特に本番ワークロード向けの堅牢なバックアップおよびリストア戦略を実装することで、OCIキャッシュのデータ耐久性と最小限のダウンタイムを実現します。
バックアップ
- 管理対象バックアップは、増分またはプログレッシブ・スナップショットではなく、完全なRDBスナップショットとして扱います。
- バックアップをスケジュールするには、
cronジョブまたは別の外部スケジューラを使用して、バックアップ作成APIをコールします。 - バックアップを環境または日付別にタグ付けして編成し、特定のバックアップの管理および取得を容易にします。
- 書込みトラフィックが少ない期間にバックアップを作成して、スナップショット・プロセスの操作への影響を減らします。OCIキャッシュ・バックアップでは、RedisまたはValkey RDBスナップショットの仕組みが使用されます。バックアップを作成すると、一時的にCPU使用率、ディスクI/O、レイテンシおよびメモリーのオーバーヘッドが増加する可能性があります。
- レプリカを含む本番クラスタの場合は、可能な場合はレプリカからバックアップを取ることをお勧めします。特に、書き込み量が多い、待機時間に依存する、または大きいデータセットの場合です。この方法では、データセットのほぼ現在のスナップショットを取得しながら、プライマリ・ノードへの影響を減らします。新鮮度が優先され、ワークロードが追加の書込みパス影響を許容できる場合は、プライマリ・バックアップを使用します。
- シャード・クラスタの場合、バックアップの一貫性はシャードごとであり、グローバルにアトミックではありません。アプリケーションでクロスシャードの一貫性が必要な場合は、バックアップを取得する前に、書込みを休止するか、アプリケーション・レベルのカットオーバー・プロセスを使用します。
- 保持ポリシーを監視して、クリティカルなバックアップの自動削除を回避し、組織またはコンプライアンスのニーズに応じて必要な期間データが保持されるようにします。保存期間は1~35日です。
- ソース・クラスタに対して一度に実行できるバックアップ作成は1つのみです。削除や更新などの一部のクラスタ操作は、バックアップの進行中にブロックされます。
リストア
- ACTIVE状態のまま保持されているバックアップからのみデータをリストアできます。
- ターゲット・クラスタが、クラスタ・モード、シャード数(シャード・クラスタの場合)、およびノード当たりのメモリーを含むソース・クラスタ構成と一致していることを確認します。
- リストアは、同じキャッシュ・エンジンの互換性のあるバージョン間でのみサポートされます。クロスエンジン復元(Redis to Valkey or Valkey to Redis)とサポートされていないバージョンの組み合わせはサポートされていません。
- 非本番環境でリストアをテストしてバックアップの整合性を検証し、チームが本番データのリスクを冒すことなくリカバリ・プロセスに精通できるようにします。
- バックアップを新しいクラスタにリストアする場合は、カットオーバーの前にリストアされた環境を検証します。接続性、エンドポイント、関連するOCIキャッシュ・ユーザー、ネットワーク・セキュリティ制御(NSGやセキュリティ・リストなど)、およびアプリケーションの動作を確認します。スモークテストを実行し、代表的な読み取りまたは書き込みテストを実行します。検証が完了するまで、ソース・クラスタを使用可能にします。
インポート/エクスポート
インポートおよびエクスポート・ワークフローでは、完全なRDBファイル(非シャード・クラスタの場合は単一のRDBオブジェクト、シャード・クラスタの場合はシャードごとに1つのRDBオブジェクト)を使用します。
非シャード・クラスタのクライアント・ベスト・プラクティス
OCIキャッシュ内の非シャード・クラスタは、プライマリ・ノードおよびオプションのレプリカ・ノードで動作し、すべてのノード間でデータをレプリケートして高可用性を確保します。これらの演習を使用して、可用性とパフォーマンスを最大化します。
高可用性の構成
- 高可用性を確保するために、少なくとも3つのノード(1つのプライマリと2つのレプリカ)を持つクラスタをデプロイします。OCI Cacheは、ノードをフォルト・ドメインおよび可用性ドメインに分散して、ローカライズされた障害に対する耐障害性を高めます。
- プライマリ・エンドポイントへの直接書込み操作と、読取り操作にレプリカ・エンドポイントを使用して負荷を分散し、冗長性を向上させます。
- フェイルオーバーまたはスケーリング・イベントが原因でクラスタの変更をサポートするように構成ファイルにエンドポイントを指定することで、アプリケーションを柔軟にします。
シャード・クラスタのクライアント・ベスト・プラクティス
OCIキャッシュ内のシャード・クラスタは、複数のシャードにデータをパーティション化し、それぞれにプライマリ・ノードとオプションのレプリカを使用してスケーラビリティとパフォーマンスを実現します。次の演習は、シャード・クラスタとインタフェースするクライアントに固有であり、分散データ管理の固有の課題に対処します。
クラスタ互換クライアントの選択
最適なパフォーマンスとスケーラビリティーを得るには、クラスタモードとホスト名の解決をサポートするクライアントライブラリを使用します。クライアントを選択する場合は、Lettuce (バージョン6.x以降)やRedisson (バージョン3.36.0以降)など、Redisクラスタ・モードおよびホスト名解決を明示的にサポートするライブラリに優先順位を付けます。
Lettuce (バージョン6.x以降)やRedisson (バージョン3.36.0以降)など、互換性マトリックスに記載されているライブラリに加えて、シャード・クラスタをサポートできる様々なプログラミング言語で他のライブラリを使用できます。互換性のあるクライアントライブラリの包括的なリストについては、Valkeyのドキュメントを参照してください。
選択したクライアントが、手動操作なしでトポロジ変更およびスロット・マッピングを動的に管理できることを確認します。この機能は、シームレスなクラスタ操作に不可欠です。
レジリエンスのためのエンドポイント構成
- シャードまたはノードが使用できない場合に接続性を確保するために、少なくとも3つの個別のシャード(たとえば、ホスト名が
-1-1、-2-1および-3-1で終わるノード)にプライマリ・エンドポイントを指定するようにアプリケーションを構成します。 - 構成ファイルにエンドポイントを指定することで、アプリケーションを柔軟にします。このアプローチにより、アプリケーションはフェイルオーバーまたはスケーリング・イベントによって発生するクラスタの変更に適応できます。
- クラスタの存続期間中は変更されない検出エンドポイントを使用します。
トポロジの自動検出
- クライアント・ライブラリが起動時または実行時にクラスタ・トポロジ情報を取得して定期的にリフレッシュできるようにします。このアプローチにより、クライアントは構成を更新せずに、ノード・フェイルオーバーまたはクラスタ・サイズ変更に適応できます。
- 検出エンドポイントを使用します。このエンドポイントは、クラスタの存続期間中も同じです。
スケーラビリティと高可用性のサポート
- 自動再接続および再シャーディングをサポートするクライアント・ライブラリを使用して、クラスタのサイズ変更中(シャードの追加または削除中など)にアプリケーションの実行を維持します。
- フェイルオーバーおよび高可用性をサポートするように、各シャードを少なくとも2つおよび最大4つのレプリカで構成します。OCI Cacheは、可用性ドメインおよびフォルト・ドメインにシャードを分散して、自己回復性を向上させます。
シャード・クラスタ・メトリック・モニタリング
- メモリー使用率(たとえば、30分間80%以上)やノードの可用性などのクリティカル・メトリックのアラートを設定します。
- メモリー使用量など、各シャードのノード・レベルのメトリックを監視して、シャード間の最適なデータ分散を決定し、クラスタ・パフォーマンスのバランスがとれていることを確認します。