次の方法で共有

高可用性とディザスター リカバリーのベスト プラクティス

  • [アーティクル]

Azure Managed Instance for Apache Cassandra は、純粋なオープンソースの Apache Cassandra クラスター用のフル マネージド サービスです。 このサービスでは、各ワークロードの特定のニーズに応じて構成をオーバーライドすることもできます。これにより、必要に応じて最大限の柔軟性と制御が可能になります。

Apache Cassandra は、Cassandra の堅牢性と回復性に寄与する、データベース内のどのノードも他のノードとまったく同じ機能を提供できるという分散型の性質とマスターレス アーキテクチャのため、回復性の高いアプリケーションを構築する場合の最適な選択肢です。 この記事では、高可用性を最適化する方法と、ディザスター リカバリーに取り組む方法に関するヒントを提供します。

RPO と RTO

RPO (目標復旧ポイント) と RTO (目標復旧時点) は共に、通常、次の場合に限り Apache Cassandra に対して低くなります (ゼロに近い)。

クラスターはゾーンとリージョンの両方で回復性があり、さらに Apache Cassandra 自体が既定で高度にフォールト トレラントなマスターレス システム (すべてのノードが書き込み可能) であるため、RTO ("停止時の停止時間") が低くなります。 すべてのノードとデータ センター間でデータが同期され、停止時のデータ損失が最小限に抑えられるため、RPO ("停止時に失われる可能性のあるデータの量") が低くなります。

Note

CAP 定理によると、RTO=0 と RPO=0 の両方を達成することは理論的に不可能です。 一貫性と可用性および最適なパフォーマンスとのトレードオフを評価する必要があります。これはアプリケーションごとに異なるように見えます。 たとえば、アプリケーションの読み取り負荷が高い場合は、データ損失を回避する (一貫性を優先する) ためにリージョン間書き込みの待機時間の増加に対処することをお勧めします。 アプリケーションの書き込み負荷が高く、待機時間の予算が厳しい場合は、重大なリージョンの停止で最新の書き込みの一部を失うリスクを許容できる (可用性を優先する) ことがあります。

可用性ゾーン

Cassandra のマスターレス アーキテクチャによって、根本からフォールト トレランスがもたらされ、Azure Managed Instance for Apache Cassandra では、選択したリージョンで可用性ゾーンのサポートが提供され、インフラストラクチャ レベルでの回復性が増強されます。 レプリケーション ファクターが 3 とすると、可用性ゾーンのサポートにより、各レプリカが確実に異なる可用性ゾーンに存在するため、ゾーンの停止がデータベースやアプリケーションに影響を及ぼすことを防ぐことができます。 可能であれば、可用性ゾーンを有効にすることをお勧めします。

複数リージョンの冗長性

Cassandra のアーキテクチャは、Azure 可用性ゾーンのサポートと組み合わせることで、ある程度のフォールト トレランスと回復性が得られます。 ただし、アプリケーションへのリージョンの停止の影響を考慮することが重要です。 リージョン レベルの障害から保護するために、マルチリージョン クラスターをデプロイすることを強くお勧めします。 そのようなことはまれですが、潜在的な影響は重大です。

ビジネス継続性のためには、データベースをマルチリージョンにするだけでは不十分です。 アプリケーションの他の部分も、分散するか、またはフェールオーバーのための適切なメカニズムを使用して、同じようにデプロイする必要があります。 ユーザーが多くの地理的な場所に分散している場合、データベースのマルチリージョン データ センター デプロイでは、クラスター全体のすべてのデータ センター内のすべてのノードが、最も近いリージョンからの読み取りと書き込みの両方を処理できるため、待機時間を短縮する利点が追加されます。 ただし、アプリケーションが "アクティブ/アクティブ" として構成されている場合は、CAP 定理をレプリカ (ノード) 間のデータの一貫性と、高可用性の提供に必要なトレードオフにどのように適用するかを検討することが重要です。

CAP 定理の条件では、Cassandra は既定で高度に調整可能な整合性を備えた AP (可用性の高い分断耐性がある) データベース システムです。 ほとんどのユース ケースでは、読み取りに local_quorum を使用することをお勧めします。

  • 書き込みのアクティブ/パッシブでは、信頼性とパフォーマンスとの間にトレードオフがあります。信頼性のためには QUORUM_EACH をお勧めしますが、ほとんどのユーザーには LOCAL_QUORUM または QUORUM が適切な妥協策です。 ただし、リージョンの停止が発生した場合は、LOCAL_QUORUM で一部の書き込みが失われる可能性があることに注意してください。
  • アプリケーションを並列で実行する場合は、ほとんどのケースで、2 つのデータ センター間の整合性を確保するために、QUORUM_EACH 書き込みが推奨されます。
  • 目標が待機時間や可用性 (RTO の低減) ではなく整合性 (RPO の低減) を優先することである場合は、整合性設定とレプリケーション ファクターでそれを反映させる必要があります。 経験則として、読み取りに必要なクォーラム ノードの数と、書き込みに必要なクォーラム ノードの数を足した数は、レプリケーション ファクターより大きくする必要があります。 たとえば、レプリケーション ファクターが 3 で、読み取りで quorum_one を使用する (1 ノード) 場合、書き込みで quorum_all を実行して (3 ノード)、合計の 4 がレプリケーション ファクター 3 を超えるようにする必要があります。

Note

Azure Managed Instance for Apache Cassandra のコントロール プレーン演算子は、1 つのリージョン (最初のデータ センターを最初にデプロイするときに選択されたリージョン) にのみデプロイされます。 万が一リージョン全体が停止した場合、コントロール プレーンを別のリージョンにフェールオーバーするため、3 時間の復旧時間がかかります。 データセンターは引き続き機能するため、可用性 SLA はこの影響を受けません。 ただし、この期間中は、ポータルまたはリソース プロバイダー ツールからはデータベース構成を変更できない可能性があります。

レプリケーション

データ センター間で必要なレプリケーションが確実に構成されるようにするため、keyspaces とそれらのレプリケーション設定を時々監査することをお勧めします。 開発の初期段階では、cqlsh を使用して簡単なテストを行うことで、すべてが期待どおりに動作することをテストすることをお勧めします。 たとえば、1 つのデータ センターに接続しているときに値を挿入し、もう一方のデータ センターから値を読み取ります。

特に、既存のデータ センターに既にデータが存在する場合に、2 つ目のデータ センターを設定する場合は、すべてのデータがレプリケートされ、システムの準備ができていることを確認することが重要です。 nodetool netstats を使用した DBA コマンドによってレプリケーションの進行状況を監視することをお勧めします。 別の方法は、各テーブルの行をカウントすることですが、ビッグ データ サイズでは、Cassandra の分散型の性質のため、大まかな見積もりしか得られないことに注意してください。

ディザスター リカバリーのコストのバランス

アプリケーションが "アクティブ/パッシブ" の場合でも概して、アプリケーションがセカンダリ リージョンの "ホット スタンバイ" データ センターにすぐにフェールオーバーできるように、各リージョンに同じ容量をデプロイすることをお勧めします。 これにより、リージョンの停止が発生した場合にパフォーマンスが低下しません。 ほとんどの Cassandra クライアント ドライバーには、アプリケーション レベルのフェールオーバーを開始するためのオプションが用意されています。 既定で、リージョンの停止はアプリケーションもダウンしていると仮定し、その場合、フェールオーバーはロード バランサー レベルで行われる必要があることを前提としています。

ただし、2 つ目のデータ センターをプロビジョニングするコストを削減するために、セカンダリ リージョンにデプロイする SKU を小さくし、ノード数を減らしたい場合があります。 停止が発生した場合、Azure Managed Instance for Apache Cassandra では、ターンキーの垂直および水平スケーリングによって、スケールアップが容易になります。 アプリケーションがセカンダリ リージョンにフェールオーバーする場合に、手動でセカンダリ データ センター内のノードをスケールアウトおよびスケールアップできます。 この場合、セカンダリ データ センターは、低コストのウォーム スタンバイとして機能します。 このアプローチを採用する場合は、停止の発生時にシステムを完全な容量まで復元するために必要な時間とのバランスを取る必要があります。 リージョンが失われた場合に何が起こるかをテストして実践することが重要です。

Note

ノードのスケールアップは、スケールアウトよりもはるかに高速です。垂直スケールと水平スケールのバランスと、クラスターにデプロイするノードの数を考慮する場合は、この点に留意してください。

バックアップ スケジュール

Azure Managed Instance for Apache Cassandra ではバックアップが自動的に行われますが、毎日のバックアップに独自のスケジュールを選択できます。 負荷の少ない時間を選択することをお勧めします。 バックアップはアイドル状態の CPU のみを使用するように構成されていますが、状況によっては Cassandra で圧縮がトリガーされ、それにより、CPU 使用率が増加する可能性があります。 圧縮は Cassandra でいつでも行われる可能性があり、ワークロードと選択した圧縮戦略に依存します。

重要

バックアップの目的は単に、偶発的なデータ損失やデータの破損を軽減することです。 バックアップを、ディザスター リカバリー戦略として推奨しているのではありません。 バックアップは geo 冗長ではなく、たとえそうであっても、バックアップからデータベースを復旧するには著しく長い時間がかかる可能性があります。 そのため、マルチリージョンのデプロイに加えて、可能な限り可用性ゾーンを有効にし、障害シナリオを軽減し、それらから効率的に復旧できるようにすることを強くお勧めします。 これは、障害が発生したリージョンをカバーできないまれなシナリオで特に重要です。マルチリージョン レプリケーションを使用していないと、すべてのデータが失われる可能性があります。

バックアップ スケジュールの構成ページのスクリーンショット。

次のステップ

この記事では、Cassandra を使用して回復性があるアプリケーションを構築するためのベスト プラクティスをいくつか説明しました。

Azure portal を使用してクラスターを作成する