このガイドでは、Tair (Redis OSS-compatible) インスタンスをスケールアップまたはスケールダウンする方法を説明します。トラフィックの増加に対応するためにアップグレードしたり、使用量が少ない期間にコストを削減するためにダウングレードしたりできます。
課金
課金は、課金方法によって異なります。
| 課金方法 | 内容 |
|---|---|
| サブスクリプション | アップグレードの場合は差額を支払い、ダウングレードの場合は返金を受けます。 |
| 従量課金 | 新しい仕様に基づいて課金されます。 |
料金の詳細については、「設定変更」をご参照ください。
制限事項
開始する前に、次の制限事項を確認してください。
| 制約 | 詳細 |
|---|---|
| ダウングレード時のメモリ下限 | ダウングレード後、使用済みメモリは新しいメモリ容量の 80% を超えることはできません。例えば、DRAM ベースのインスタンスで現在 2 GB を使用している場合、2.5 GB 未満にダウングレードすることはできません。 |
| 分散インスタンス | 分散インスタンス内のすべての子インスタンスは、同一の仕様である必要があります。異なる仕様を混在させることはできません。 |
| ESSDベースのインスタンス | ストレージ容量は 10 GB 単位でのみ増加できます。ストレージ容量を減らすことはできません。 |
| CPUのみのアップグレード | CPU を単独でアップグレードすることはできません。利用可能な CPU コア数を増やすには、クラスターアーキテクチャへの切り替え、読み書き分離の有効化、読み取り専用ノードの追加、またはシャードの追加を行います。 |
インスタンス仕様の変更
変更されない項目
仕様を変更する際、次の項目は変更されません。アプリケーションコードの変更は不要です。
-
エンドポイント
-
データベースアカウントとパスワード
-
ホワイトリスト設定
インスタンスデータは保持されます。まれにプライマリノードが切り替え中に障害が発生した場合、少量の未同期データが失われる可能性があります。予防措置として、仕様を変更する前に手動バックアップを作成することを推奨します。
仕様の変更 (スケールアップまたはスケールダウン) は、CPU 使用率、クライアント接続数、スループット、キャッシュヒット率に直接影響しません。これらのメトリクスは、仕様階層ではなく、実際のワークロードによって決まります。
サービスへの影響
スケールアップ (アップグレード) とスケールダウン (ダウングレード、ノードメモリのみを削減するダウングレードを含む) の両方で、現在のホストが対象仕様に対応できない場合、ホスト移行が発生することがあります。移行を伴う切り替えはシームレスではありません。1〜2 回の瞬断と、約 1 分間の読み取り専用状態が発生します。十分なリソースを持つホスト上のクラウドネイティブクラスターインスタンスとクラウドネイティブスタンダードインスタンスのみ、ダウンタイムなしでインプレースで変更が完了します。
| シナリオ | サービスの中断 |
|---|---|
| クラウドネイティブクラスターインスタンス、または十分なリソースを持つホスト上のクラウドネイティブスタンダードインスタンス | なし。シームレスなインプレース更新により、ダウンタイムは発生しません。 |
| リソースが不足しているホスト上のクラウドネイティブスタンダードインスタンス、またはすべてのクラシックインスタンス | 1〜2 回の瞬断 (各 30 秒未満) と、約 1 分間の読み取り専用状態が発生します。アプリケーションが自動的に再接続することを確認してください。 |
切り替えが発生すると、高速なデータ同期を確保し、DNS キャッシュによる二重書き込みの問題を防ぐため、インスタンスは約 1 分間読み取り専用状態になります。書き込み量が多いインスタンスの場合、この期間が長くなる可能性があります。
変更中、インスタンスのマイナーバージョンは自動的に最新版にアップグレードされます。マイナーバージョンには下位互換性があります。
設定変更の所要時間
設定変更全体の所要時間は、2 つの段階で構成されます。
-
バックエンドの準備：システムは対象仕様の新しいノードをプロビジョニングし、データを同期します。データ量に応じて、数十分から数時間かかる場合があります。この段階では、インスタンスは通常どおりリクエストを処理し続け、サービスへの影響はありません。
-
切り替え：準備が完了すると、トラフィックが新しいノードに切り替わります。クラウドネイティブクラスターインスタンスおよび十分なリソースを持つクラウドネイティブスタンダードインスタンスは透過的に切り替わります。それ以外の場合、各 30 秒未満の瞬断が 1〜2 回発生します。
したがって、設定変更の合計所要時間 (数十分から数時間) とサービスへの影響時間 (30 秒未満、または影響なし) は、2 つの異なる概念です。コンソールの [タスクセンター] で進捗状況を追跡できます。
手順
-
インスタンスページにログインします。上部メニューで、インスタンスが存在するリージョンを選択し、インスタンス ID をクリックします。
-
右上隅の[仕様変更]をクリックし、適切なオプションを選択します：
-
サブスクリプションインスタンス: [仕様アップグレード] または [仕様ダウングレード] を選択します。
-
従量課金インスタンス: [仕様のアップグレード/ダウングレード] を選択します。
-
-
表示されるページで、対象仕様を選択します。
-
[切り替え時間] を設定します:
-
[今すぐ作成] をクリックし、支払いを完了します。
送信後、インスタンスのステータスが [設定変更中] に変わります。システムはバックグラウンドでリソースをリクエストし、データを同期します。この段階では、サービスへの影響はありません。瞬断は、新しいノードへの切り替え時にのみ発生します。
仕様変更の仕組み
基盤となるプロセスを理解することで、中断が発生する可能性のあるタイミングを予測できます。
クラウドネイティブインスタンス
-
インスタンスは [設定変更中] 状態になります。
-
システムは、現在のホストに対象仕様に十分なリソースがあるかどうかを確認します。
-
利用可能なリソースに基づいて、システムは次の 2 つのパスのいずれかを選択します。
-
十分なリソースがある場合：仕様変更は中断なしでインプレースで完了します。
-
リソースが不足している場合：システムは新しいホストノードをプロビジョニングし、インスタンスデータを事前に同期してから、メンテナンスウィンドウ内 (または即座に) に新しいノードにトラフィックを切り替えます。これにより、短い瞬断が発生します。
-
-
インスタンスは [実行中] 状態に戻ります。
クラシックインスタンス
-
インスタンスは [設定変更中] 状態になります。
-
システムは新しいホストノードをプロビジョニングし、インスタンスデータを事前に同期します。
-
システムは、メンテナンスウィンドウ内 (または即座に) に新しいノードにトラフィックを切り替えます。これにより、短い瞬断が発生します。
-
インスタンスは [実行中] 状態に戻ります。
よくある質問
メモリを変更せずにCPUのみをアップグレードできますか?
いいえ。Tair (Redis OSS-compatible) では、CPU を単独でアップグレードすることはできません。利用可能な CPU コア数を増やすには、次のいずれかの方法を使用します。
-
スタンダードアーキテクチャからクラスターアーキテクチャに切り替えるか、読み書き分離を有効にします。
-
読み取り専用ノードを追加します (読み書き分離が有効なインスタンスの場合)。
-
シャードを追加します (クラスターインスタンスの場合)。
詳細については、「インスタンスのCPU仕様をアップグレードする方法」および「インスタンスタイプとFAQ」をご参照ください。
メモリ使用率が高い場合、仕様変更前に何を考慮する必要がありますか?
スケールダウンを計画していて、現在のメモリ使用率が高い場合は、まず対象仕様が次の制限事項を満たしていることを確認してください：新しいメモリ容量 × 0.8 > 現在使用中のメモリ。この条件が満たされない場合、スケールダウンは失敗し、元の設定が保持されます。データは失われません。
メモリ使用率が継続的に高いことに対処するためにスケールアップを計画している場合は、まず根本原因を調査することを検討してください。不要なデータを削減すること (例えば、未使用のキーのクリーンアップ、TTL ポリシーの設定、削除ポリシーの調整など) により、メモリ消費量を削減でき、アップグレードを延期または回避できる可能性があります。体系的なトラブルシューティングアプローチについては、「高メモリ使用率のトラブルシューティング」をご参照ください。