Databases for Redis の高可用性と災害復旧について
高可用性サービスまたは作業負荷が障害に耐え、事前に定義されたサービスレベルに従って処理能力を提供し続ける能力。 サービスについては、可用性はサービスレベル契約で定義されています。 可用性には、計画されたイベントと計画外のイベントの両方が含まれます。計画外のイベントには、メンテナンス、故障、災害などが含まれます。 (HA) とは、予期しない障害が発生した場合でもサービスが稼働し続け、アクセス可能になる能力です。 ディザスタリカバリとはサービスの中断などの稀な重大なインシデントや広範囲にわたる障害から、サービスや作業負荷が回復する能力。 これには、地域全体に影響を及ぼす物理的な災害、データベースの破損、作業負荷に寄与するサービスの損失などが含まれます。 その影響は、高可用性設計の処理能力を超えている。、サービスインスタンスを稼動状態に回復させるプロセスである。
Databases for Redis は、標準プランで定義された サービスレベル目標(SLO )を満たす地域サービスである。
Databases for Redis で利用可能な IBM Cloud リージョンとデータセンターの詳細については、 ロケーション別のサービスとインフラの可用性を 参照してください。
高可用性アーキテクチャ

Databases for Redis は、レプリケーション、フェイルオーバー、および高可用性機能を提供し、インフラストラクチャのメンテナンス、アップグレード、および一部の障害からデータベースとデータを保護します。 デプロイメントには、プライマリとレプリカの構成で2つのデータ・メンバーを持つクラスタが含まれます。 レプリカは非同期レプリケーションを使って最新の状態に保たれる。 高可用性は、3つの Redis センチネルで監視・管理される
デフォルトでは、すべてのデプロイメントでデータの永続性が有効になっており、データはディスクに書き込まれます。 Databases for Redis、 RDBスナップショットとAOF(Append Only File )の組み合わせを使用して、データをディスクに永続化します。 Databases for Redis、ディスクへの書き込み(fsync)の間隔は、耐久性とパフォーマンスのバランスをとるため、 1秒に1回に設定されている。
データ永続性はオフにすることができます。これは、Redis をキャッシュとして構成する場合に役立ちます。
高可用性機能
Databases for Redis は以下の高可用性機能をサポートしている:
特長 | 説明 | 考慮事項 |
---|---|---|
自動フェイルオーバー | すべてのクラスタに標準装備され、ゾーンや単一メンバーの障害に強い | |
メンバー数 | 最少催行人数:2名 デフォルトは、プライマリおよびレプリカ構成の標準2メンバクラスタです。 2つのメンバーで構成されるクラスタは、単一のインスタンスまたはゾーンの障害から自動的に回復します(ラグしきい値までのデータ損失があります)。 | クラスタの健全性を監視し、フェイルオーバーを調整する3台のSentinelノード。 |
非同期複製 | 書き込みパスをブロックすることなく、プライマリからレプリカへのレプリケーションを可能にし、低レイテンシーで高可用性を確保します。 以下の 非同期レプリケーションを参照。 | レプリケーションの遅延(RPO > 0)により、フェイルオーバー時にデータが失われる可能性がある。 厳密なデータ耐久性が要求される場合には適さない。 |
非同期レプリケーション Databases for Redis
デフォルトでは、 Databases for Redis は非同期レプリケーションを使用し、プライマリノードはレプリカが書き込みを確認するのを待たない。 これにより、低レイテンシーと高スループットが保証され、 Databases for Redis、キャッシュやパフォーマンス重視のワークロードに最適です。 しかし、プライマリに障害が発生した場合、レプリカが最新の書き込みを受信していない可能性があるため、レプリケーションの遅延がデータ損失につながる可能性がある。
Databases for Redis レプリケーションは高可用性のために設計されているのであって、厳密な耐久性のために設計されているのではない。 プライマリが到達不能になると自動的にフェイルオーバーが発生し、レプリカがリーダーに昇格する。 レプリケーションは非同期であるため、コミットされた書き込みの一部がこの過程で失われる可能性がある。 このレプリケーション・ラグは、 Databases for Redis デプロイメントのRPO(Recovery Point Objective)を定義する。
データ損失のリスクを軽減するため、 Databases for Redis、 RDBスナップショットやAOF(Append Only File )といった永続化メカニズムをサポートしている。これは、レプリケーション・プロセスとは無関係にデータをディスクに書き込む。 これらは、作業負荷の要件に基づいて慎重に設定されるべきである。
Databases for Redis、非同期レプリケーションは高速なパフォーマンスを保証するが、フェイルオーバー時にデータが失われる可能性を排除するものではない。 スピードと可用性が厳密なデータ一貫性よりも優先されるワークロードに推奨される。
災害復旧アーキテクチャ
災害復旧の一般的な戦略は、以下の Restore
データベースのように、新しいデータベースを作成することです。 新しいデータベースの内容は、災害前に作成されたソース・データベースのバックアップでもよい。
災害復旧機能
Databases for Redis は、以下のディザスタリカバリ機能をサポートしている:
特長 | 説明 | 考慮事項 |
---|---|---|
バックアップ・リストア | Cloud Databases バックアップの管理 を参照してください。 | 復元されたデータベースの新しい接続文字列は、ワークロード全体で参照されなければならない。 |
災害復旧の計画
災害復旧の手順は、定期的に実践されなければならない。 計画を立てる際には、次のような失敗のシナリオと解決策を検討してください。
失敗 | 解決方法 |
---|---|
ハードウェア障害(シングルポイント) | (例) IBM は、ゾーン内の単一ハードウェア障害に強いデータベースを提供する。 お客様による設定は不要です。 |
ゾーン障害 | 自動フェイルオーバー。 データベースのメンバーはゾーン間で分散される。 |
データ破損 | バックアップ・リストア。 リストアしたデータベースを本番環境またはソース・データで使用し、リストアしたデータベースの破損を修正する。 |
アプリケーション・レベルの高可用性
ネットワークとクラウド・サービスを介して通信するアプリケーションは、一時的な接続障害の影響を受けます。 アプリケーションを設計する際には、デプロイメントまたは IBM Cloud への接続が一時的に失われてエラーが発生した場合に接続を再試行するように設計することができます。
Databases for Redis はマネージド・サービスであるため、定期的な更新とデータベースのメンテナンスは通常業務の一環として行われる。 これにより、データベースを使用できなくなる、短時間の中断が発生することがあります。 また、データベースが正常なフェイルオーバー、再試行、および再接続をトリガーする場合もあります。 レプリカであるメンバーとリーダーであるメンバーをデータベースが判別するのに短い時間がかかるため、短い接続の中断が発生する可能性があります。 フェイルオーバーにかかる時間は通常、30 秒未満です。
アプリケーションは、データベースへの一時的な中断を処理し、失敗したデータベース・コマンドのエラー処理を実装し、一時的な interruption.Use IOREDIS、NODEREDIS、またはその他のお好みのパッケージから回復するための再試行ロジックを実装するように設計されている必要があります。 application.For 詳細については、 Redis ブログポストでエラー検出と処理を 参照してください。
データベースを使用できない状態や接続の中断が数分に及ぶことは想定されていません。 接続できない時間が1分以上ある場合は、詳細を添えて サポート・ケースを 作成してください。
接続制限
Databases for Redis は、1つの配置につき最大10,000の同時接続を設定します。 この制限により、 Redis 環境内のパフォーマンスの安定性とリソース管理が保証されます。 しかし、10,000の接続すべてがクライアントに提供されるわけではなく、一部は配備の状態と完全性を維持するためのオペレーション用に内部的に確保されている。 接続制限に達した後、新しい接続を開始しようとするとエラーになる。 詳しくは、 Redis 接続の管理を 参照。
HAとDRの責任
以下の情報は、HAとDRのプランを作成し、継続的に実践するのに役立つ。
バックアップからデータベースをリストアする場合、またはポイントインタイム・リストアを使用する場合、新しい接続文字列で新しいデータベースが作成されます。 既存のワークロードとプロセスは、新しい接続文字列を消費するように調整されなければならない。
復旧したデータベースも、災害データベースと同じように、顧客が作成した依存関係を必要とする場合がある。 これらのサービスやその他のサービスが復興地域に存在することを確認する:
- IBM® Key Protect for IBM Cloud®
- Hyper Protect Crypto Services
データベースを削除すると、関連するバックアップも削除されることを忘れないでください。 しかし、削除されたデータベースは、限られた時間枠内であれば復元できる可能性がある。 詳しくは、 バックアップFAQを ご覧ください。
IBM Cloud、バックアップをコピーすることはできないため、追加のバックアップにはデータベース固有のツールを使用することを検討してください。 悪意のあるデータベースの削除に続き、データベースの再削除からの復旧が必要になる場合があります。 データベースへのIAMアクセスを注意深く管理することで、この問題にさらされる機会を減らすことができる。
各特徴に関連する以下のチェックリストは、プランの作成と実践に役立つ。
- バックアップ・リストア
- RPO要件を満たすために、望ましい頻度でバックアップが利用可能であることを確認する。 Cloud Databases バックアップの管理は、バックアップの頻度を文書化する。
- データベースのリストア領域にはいくつかの制限があります。 Cloud Databases バックアップの管理を 参照して、リストア目標を達成できるかどうかを確認してください。
- バックアップの保存期間が要件を満たしていることを確認する。
- テストリストアを定期的にスケジュールし、実際のリストア時間が定義されたRTOを満たしていることを検証する。 データベースのサイズはリストア時間に大きく影響することを忘れないでください。 大規模なデータベースをより小さく管理しやすい単位に分割し、未使用のデータを消去するなど、リストア時間を最短化する戦略を検討する。
- Key Protect サービスを確認する。
Databases for Redis を使用する際の顧客と IBM Cloud との間の責任分担については、 Cloud Databases の責任分担を 参照のこと。
最新情報: IBM
顧客のワークロードに影響を与えるアップデートは、 IBM Cloud の通知を通じて知らされる。 本サービスに関連する計画的なメンテナンス、アナウンスメント、リリースノートに関する情報は、 モニタリングの通知とステータスの ページをご参照ください。 さらに、 バージョン・ポリシーの ページを定期的に確認し、End-of-Lifeのバージョンと日付に関する最新のアップデートを確認してください。