本文は、初めてTencent Cloud Distributed Cache（Redis互換）を使用するユーザーを対象に、製品理解からサービス開始までの完全な学習パスを提供します。目的が明確な場合は、該当する段階に直接進むことができます。初めてDistributed Cacheに触れる場合は、順番に読むことをお勧めします。各段階が終了してから次の段階に進んでください。
導入ロードマップ
アカウント登録からサービスの安定稼働まで、通常は以下の6つの段階を経ます。最初の3つの段階はインスタンスの形態とコストを決定し、後の3つの段階はサービスの安定性と保守性を決定します。
|
| この製品は私のどのような問題を解決できますか。 |
| どのエンジン、アーキテクチャ、およびスペックを選択すればよいですか。 |
| 利用可能なインスタンスを作成する方法を教えてください。 |
| インスタンスにアクセスできることを確認する方法を教えてください。 |
| コード内でキャッシュを使用する方法を教えてください。 |
| 障害とデータ損失を回避する方法を教えてください。 |
注意すべき点として、第6段階は初心者にスキップされがちですが、バックアップルールとアラートポリシーこそが、障害発生時に損失の大きさを左右する重要な設定です。サービスを正式に接続する前に完了することをお勧めします。
ステップ1：製品を理解する
1.1 製品の機能と適用シーン
Distributed Cache（Redis互換）は、データをメモリに保存してミリ秒単位の読み書き応答を提供するインメモリデータベースサービスであり、Redisプロトコルと互換性があります。以下の順序で3つの製品概要をお読みになることをお勧めします。それぞれ「とは何か」、「なぜ選ぶのか」、「どこで使うのか」という3つの質問に回答します。
|
1 | | 製品の位置づけ、コア機能、およびサービス形態 |
2 | | 自社構築Redisとの違いとして、高可用性、AS、運用保守不要が挙げられます。 |
3 | | キャッシュ高速化、ランキング、セッションストレージ、メッセージキューなどの実用シーン。 |
この3つを読み終えると、ご自身のビジネスが分散キャッシュデータベースの利用に適しているかどうか、またどの部分のトラフィックをそれで引き受ける予定かを判断できるようになります。
1.2 まず用語の理解を確立する
分散キャッシュデータベースのドキュメントには、シャード、レプリカ、マスターノード、Proxy、アベイラビリティーゾーンなどの用語が頻繁に登場します。これらの概念に不慣れな場合、後続の選定時に誤った判断を下しやすくなります。まず用語解説をご覧になることをお勧めします。不明な表現があれば、いつでも用語集を参照してください。 ステップ2：選定を完了する
選定は初心者が最も間違いやすい段階です。インスタンス作成後、エンジンタイプとリージョンは変更できません。スペックとアーキテクチャは調整可能ですが、変更コストが発生します。そのため、購入前に以下の4つの決定を完了することをお勧めします。
2.1 ストレージエンジンの選択
製品は3種類のストレージエンジンを提供しており、それぞれ異なる互換性と機能要件に対応しています。3つの位置付けの違いは以下の通りです。詳細な機能比較については、ストレージエンジン、Redis版、Valkey版をご覧ください。 |
Redis版 | 4.0、5.0、6.2、7.0 | 汎用的な選択肢であり、機能が完全にカバーされ、大規模な本番環境で検証済みです。 |
Valkey版 | 8.0、9.0 | Redisの後継ブランチとして、I/O処理においてパフォーマンス最適化が施されています。 |
Memcached版 | 1.6 | シンプルなキーバリューキャッシュのみが必要で、かつビジネスがすでにMemcachedプロトコルに基づいて開発されている場合に適しています。 |
バージョン番号の選択については、完全なデータ構造とコマンドサポートを得るために、より新しい安定版を優先的に選択することをお勧めします。具体的な違いについては、メジャーバージョン機能一覧をご覧ください。また、バージョンライフサイクル計画に注意し、まもなくサポートが終了するバージョンの選択を避けてください。 2.2 アーキテクチャの選択
アーキテクチャはインスタンスの容量上限と拡張方式を決定し、選定において最も影響が大きい要素です。2つのアーキテクチャの違いは以下の通りです。
|
メモリ仕様 | 256MB - 64GB | 1シャードあたり1GB～64GB |
シャード数 | 対象外 | 1～128個、総容量は最大8TBです。 |
データ分散 | 単一シャードに全量データを保存します。 | データはハッシュスロットに基づいて各シャードに分散されます。 |
拡張方式 | 単一分片のメモリ容量を向上させます。 | シャード数を増やし、容量とスループットを水平に拡張します。 |
同時実行性能 | 8万～10万 QPS | （8万～10万）/シャード、最大千万級QPSです。 |
コマンド互換性 | 完全対応 | クロススロットコマンドには互換性の制限があります。 |
選択の判断基準はデータ量とコマンドの使用方式です：データ量が64GB以内で、かつ業務でLuaスクリプトやKeyをまたぐ操作を多く使用する場合は、標準アーキテクチャを選択します。データ量が64GBを超える見込みの場合や、より高いスループットが必要な場合は、クラスタアーキテクチャを選択しますが、事前に業務コマンドの互換性を確認する必要があります。アーキテクチャの原理については標準アーキテクチャとクラスタアーキテクチャを、コマンドの違いについてはProxyアーキテクチャとダイレクト接続モードの使用上の違いをご覧ください。 説明：
256MB规格は入门体験规格であり、テスト环境での検証にのみ适しており、本番环境での使用は推奨されず、対応するアベイラビリティーゾーンも限られています。上表のデータは一般的な参考値であり、実際に選択可能な规格は購入ページの表示を基準としてください。標準アーキテクチャは後からクラスタアーキテクチャへアップグレードできますが、アップグレードにはデータの再分散が伴うため、事前に互換性評価を行う必要があります。データ量の増加傾向が明確な場合は、初期段階でクラスタアーキテクチャを選択することをお勧めします。
2.3 仕様とデプロイ場所の確定
スペックには、メモリ容量、レプリカ数、シャード数の3つの次元が含まれます。これらはインスタンスの容量、パフォーマンス、可用性レベルを決定します。各スペックに対応する接続数とスループットの上限については、スペックとパフォーマンスをご覧ください。 レプリカ数の選択可能範囲は1～5個です。その役割は2つの側面に現れます。1つ目は可用性の向上です。すべてのレプリカノードが高可用性切り替えに参加し、マスターノードに障害が発生した場合、システムは自動的にそのうちの1つのレプリカを新しいマスターノードに昇格させます。レプリカ数が多いほど可用性が高くなります。2つ目は読み取り性能の拡張です。レプリカ数が1以上の場合、読み書き分離を有効にして、読み取りリクエストをレプリカノードに分散できます。可用性に対する要件が高い本番業務では、2個以上のレプリカを構成することをお勧めします。 シャード数はクラスタアーキテクチャ特有のスペック次元であり、標準アーキテクチャには関係ありません。クラスタアーキテクチャのシャード数は1～128個から選択できます（選択可能な値は1、3、5、8、12、16、24、32、40、48、64、80、96、128です）。単一シャードのメモリスペックは1GB～64GBで、インスタンスの総容量は単一シャード容量とシャード数の積であり、最大8TBに達します。シャード数は同時にスループット上限を決定し、単一シャードあたり8万～10万QPSで線形に見積もることができます。後で標準アーキテクチャからクラスタアーキテクチャにアップグレードする場合、アップグレード時にシャード数を再決定する必要があります。
接続数について、各スペックのデフォルト上限は10000（クラスタアーキテクチャではシャードごとに10000）で、最大40000まで調整できます。業務の接続数要件がデフォルト値を超える場合は、接続数の調整を通じてクォータを追加できます。 リージョンとアベイラビリティーゾーンの選択原則は近接デプロイです：インスタンスはそれにアクセスするCVMと同じリージョンに配置する必要があります。リージョンをまたぐアクセスはネットワーク遅延を著しく増加させます。可用性に対してより高い要件を持つ業務では、マルチアベイラビリティーゾーンデプロイを選択し、ノードを異なるデータセンターに分散してデータセンターレベルの障害に耐えることができます。選択可能な範囲については、リージョンとアベイラビリティーゾーンをご覧ください。 注意：
リージョンはインスタンス作成後に変更できません。リージョンを誤って選択した場合は、新しいインスタンスを作成し、データを移行する方法でしか調整できません。
2.4 課金モードの選択
課金モードは年額・月額課金と従量課金の2種類に分けられます。違いは支払い時点と単位コストにあります。
|
サブスクリプション(月額・年額) | 先に支払い、購入期間に基づいて課金されます。 | 業務が長期的に安定して稼働し、単位コストがより低くなります。 |
従量課金 | 後払い、実際の利用時間に基づいて決済されます。 | 短期テスト、一時的な拡張、または使用量が不確定なシーン。 |
スペック変更、継続支払い、返金、未払いに関する処理ルールは、購入前にあわせて確認することをお勧めします。これにより、後で予期しない費用やサービス中断が発生することを避けられます：
|
スペック調整時の課金方法について | |
期限切れ後の継続支払い方法 | |
利用を停止した場合の返金方法 | |
アカウントの未払いが発生した場合の影響について | |
ステップ3：インスタンスの作成
選定が完了したら、インスタンスを作成できます。作成前に、Tencent Cloudアカウントの登録と実名認証が完了していることを確認し、アカウント残高が十分であることを確認してください。購入ページの各設定項目の入力説明についてはインスタンスの購入をご覧ください。初回のクイック体験の作成手順についてはインスタンスのクイック作成をご覧ください。 説明：
作成プロセスには、特に注意すべき設定が2つあります。1つ目はパスワードです。パスワードはインスタンスの第一のアクセス防御線であり、直接強力なパスワードに設定することをお勧めします。また、パスワード複雑度の設定を通じてルールを統一的に制約できます。2つ目はVPCとサブネットです。インスタンスは業務サーバーと同じVPCに配置する必要があります。そうでない場合、アクセスするためにネットワーク相互接続を追加で設定する必要があります。 ステップ4：接続と検証
4.1 接続前の準備
接続失敗は初心者が最も多く遭遇する問題です。その原因は通常、ネットワーク不通、セキュリティグループの未開放、パスワード形式の誤りという3種類に集中しています。まず接続準備を読んで、以下の条件がすべて満たされていることを確認することをお勧めします。 |
ネットワーク接続 | クライアントとインスタンスが同一のVPCに存在するか、Peering Connection、CCNなどの相互接続方式が設定されています。 |
セキュリティグループ | インスタンスにバインドされているセキュリティグループで、クライアントのソースIPとアクセスポート（デフォルト6379）が許可されています。 |
接続アドレス | インスタンス詳細ページのネットワーク情報エリアからVIPアドレスとポートを取得済みです。 |
パスワード形式 | デフォルトアカウントを使用する場合の形式はインスタンスID：パスワードで、カスタムアカウントを使用する場合の形式はユーザー名@パスワードです。 |
特にパスワード形式は初心者が見落としやすい点です。デフォルトアカウントでは、インスタンスIDをパスワードの前につなげる必要があります。パスワードだけを直接入力すると認証に失敗します。セキュリティグループの設定方法については、セキュリティグループの設定をご覧ください。 4.2 接続の確立と検証
接続が成功したら、基本的な検証として2つのコマンドを実行することをお勧めします。PINGコマンドを実行し、PONGが返されれば、リンクは正常です。次にSETとGETを一度実行し、データが正常に読み書きできることを確認します。両方とも成功すれば、インスタンスは正式に使用可能です。
説明：
本章および後続の内容におけるパスワード認証と接続方式は、Redis版とValkey版に適用されます。Memcached版はパスワード不要のアクセスのみをサポートしており、DMCおよびredis-cliを介した接続には対応していません。telnet方式を使用する必要があります。詳細については、ストレージエンジンをご覧ください。 ステップ5：業務コードの導入
5.1 クライアントの選択と接続コードの作成
業務コードは標準のRedisクライアントを通じてインスタンスに接続します。使用方式は自建Redisへの接続と同様です。開発言語に応じて対応する接続例を選択してください。
|
Java | |
Python | |
Go | |
Node.js | |
PHP | |
C | |
.Net | |
業務で転送セキュリティに要件がある場合は、SSL暗号化を有効にし、リンクデータを暗号化してから転送できます。 5.2 コマンド互換性の事前確認
すべてのRedisコマンドがクラウド上のインスタンスで使用できるわけではありません。一部のコマンドは、クラスタ管理に関わる、またはデータリスクが存在するという理由で制限されています。また、バージョン間でもコマンドに差異があります。コードを作成する前に、使用するコマンドのサポート状況を確認し、リリース後に非互換性を発見することを避けることをお勧めします。
|
コマンド全体のサポート範囲 | |
制限されるコマンド | |
メジャーバージョンごとのコマンドの違い | |
クラスタアーキテクチャにおける走査方法 | |
Memcached版の互換性 | |
5.3 開発ガイドラインに従い典型的な問題を回避する
キャッシュ設計の不備によって引き起こされる性能問題は、その多くが運用保守段階ではなく設計段階に起因します。大きいKeyは単一操作の所要時間を急増させ、ホットKeyは単一ノードの負荷偏りを引き起こし、不適切な淘汰ポリシーはキャッシュヒット率の継続的な低下をもたらします。これらの問題は一度本番環境に入ると、設計段階で回避するよりもはるかに高い改修コストが発生します。
したがって、業務をリリースする前に、開発ガイドラインをすべて読むことをお勧めします：
|
| 命名の混乱により、後期の保守・トラブルシューティングが困難になります。 |
| 大規模なKeyが発生し、操作のブロッキングを引き起こします。 |
| 削除ポリシーが不適切な場合、ヒット率の低下やデータの予期しない消失を引き起こします。 |
| 高複雑度コマンドの誤用により、全体の応答が遅延します。 |
| 接続プールの設定不備により、接続の枯渇や負荷の偏りが発生します。 |
| 単一ノードに負荷が集中し、パフォーマンスが不安定になります。 |
Springエコシステムを使用して開発している場合は、実践チュートリアルの完全な接続例を参照できます。この例には、コンポーネントの設定、サービスの構築、パフォーマンスデータの収集という完全なフローが含まれています。 ステップ6：運用保守体制の確立
ビジネスの接続が完了しても、リリース準備が整ったことを意味しません。以下の3つの設定は、データ損失、パフォーマンス劣化、セキュリティリスクに対応するためのものです。正式にトラフィックを承载する前にすべて完了することをお勧めします。
6.1 データバックアップの設定
バックアップはデータセキュリティの最後の砦です。システムは自動バックアップ機能を提供しますが、保持期間と実行時間は、ビジネスのデータ重要度に応じてお客様自身で設定する必要があります。バックアップ時間はビジネスの低ピーク時に設定し、データが許容できる損失ウィンドウに基づいてバックアップ頻度を決定することをお勧めします。
|
バックアップの種類と復旧能力を理解します。 | |
バックアップ時間と保持日数を設定します。 | |
バックアップデータを使用して検証インスタンスを作成します。 | |
6.2 監視とアラートの設定
初心者にとって、以下の4つの指標には優先的にアラートを設定することをお勧めします。これらの指標は容量と負荷が上限に近いかどうかを直接反映します：
|
メモリ使用率 | 容量がまもなく上限に達し、データ淘汰が発生する可能性があります。 | |
CPU使用率 | 高複雑度のコマンドが存在するか、またはリクエスト量が過大です。 | |
接続使用率 | 接続数が仕様の上限に近づいており、新しい接続が拒否される可能性があります。 | |
アウトバウンドトラフィック | 帯域幅が上限に近づいており、リクエストのキューイングが発生する可能性があります。 | |
アラートの具体的な設定方法については、アラートの設定を参照してください。また、メンテナンス時間枠の設定を同時に行い、システム側の運用保守操作をビジネスの低ピーク時間帯に集中して実行することをお勧めします。 6.3 アクセスセキュリティの強化
インスタンスのセキュリティ保護は、ネットワーク分離と認証の2層で構成されています。ネットワーク層はセキュリティグループを通じて、どの送信元がインスタンスにアクセスできるかを制限し、認証層はアカウントとパスワードを通じてアクセス者の権限範囲を制限します。セキュリティグループは最小権限の原則に従い、ビジネスで実際に必要な送信元IPとポートのみを許可し、利便性のためにすべての送信元を許可することを避ける必要があります。アカウントについては、異なる用途ごとに独立したアカウントを作成し、対応する権限を割り当てることをお勧めします。例えば、データ分析系の業務では読み取り専用権限のみで十分です。
|
アクセス元を制限します。 | |
アカウントを作成し、権限を割り当てます。 | |
パスワード強度を制限します。 | |
伝送リンクを暗号化します。 | |
高リスクコマンドをブロックします。 | |
説明：
製品はパスワードなしアクセスをサポートしていますが、この方式はアクセスハードルを下げるため、ネットワーク分離が十分なテスト環境でのみ使用することをお勧めします。本番環境ではパスワード認証を有効にしてください。 よくある質問のクイック参照
初心者段階の問題は、接続、タイプ選択、費用の3種類に集中しています。以下ではシーン別に分類して示しますので、すばやく特定できます。
接続とネットワーク
|
インスタンスへの接続方法 | |
接続失敗のトラブルシューティング方法 | |
接続アドレスの確認方法 | |
公網からアクセスできるかどうか。 | |
その他の接続およびネットワークの問題 | |
インスタンスの管理と使用
|
パスワードを忘れた場合の対処方法を教えてください。 | |
容量が不足している場合、どのように拡張しますか。 | |
インスタンスを誤って削除した場合、復元できますか。 | |
性能が期待に達しない場合の分析方法を教えてください。 | |
その他のインスタンス管理に関する問題 | |
選定と費用
|
どのようにスペックとアーキテクチャを選択するか | |
誤って購入した場合の返金方法 | |
アカウントの未払いが発生した場合、サービスに影響があるかどうかについて | |
サービス可用性のコミットメント | |
その他の機能および使用に関する問題 | |
応用学習
上記の6つの段階を完了すると、分散キャッシュデータベースを使用してビジネスを支える基礎能力をすでに備えています。可用性や可観測性をさらに向上させる場合、またはデータ移行を完了する場合は、以下の方向を参照できます。
|
すべての運用保守操作 | コンソールの全機能を体系的に理解する必要があります。 | |
データのクラウド移行 | 既存の自社構築またはサードパーティクラウド上のインスタンスを移行する必要があります。 | |
性能診断最適化 | スロークエリ、大Key、ホットKeyを特定する必要があります。 | |
クロスリージョン災害対策 | ビジネスが複数のリージョンにまたがる場合、最寄りでの読み取りまたはリージョンレベルの災害対策が必要です。 | |
自動化運用保守 | インターフェースを通じてインスタンスを一括管理する必要があります。 | |
バージョンと機能の更新 | 製品の新機能をフォローアップする必要があります。 | |
ヘルプの取得
使用中に問題が発生した場合や改善のご提案がある場合は、以下の方法でフィードバックできます。担当者が追跡して対応します。
ドキュメントの問題：ドキュメント内のリンク切れ、内容の誤り、または説明が不明瞭な点を発見した場合は、該当する内容を選択してからドキュメントフィードバックをクリックし、ポップアップページで送信できます。