Azure Managed Instance for Apache Cassandra は、純粋なオープンソースの Apache Cassandra クラスター用のフル マネージド サービスです。 このサービスでは、各ワークロードのニーズに応じて構成をオーバーライドできるため、必要に応じて最大限の柔軟性と制御が可能になります。
Apache Cassandra は、分散された性質とピアツーピア アーキテクチャにより、回復性の高いアプリケーションを構築するための優れた選択肢です。 データベース内の任意のノードは、他のノードと同じ機能を提供できます。 この設計は、Cassandra の堅牢性と回復性に寄与します。 この記事では、高可用性を最適化する方法と、ディザスター リカバリーに取り組む方法に関するヒントを提供します。
目標復旧時点と目標復旧時間
次の要素がある限り、目標復旧ポイント (RPO) と目標復旧時間 (RTO) は、通常、低く、ゼロに近くなります。
- 複数リージョンデプロイメントで、リージョン間レプリケーションとレプリケーション係数が3。
- 可用性ゾーンを有効にしました。 このオプションは、 Azure portal で、または Azure CLI を使用してクラスターを作成するときに構成します。
- クライアント ドライバーで負荷分散ポリシーを使用してアプリケーション レベルのフェールオーバーを構成するか、Azure Traffic Manager または Azure Front Door を使用した負荷分散レベルのフェールオーバーを構成しました。
RTO は、"停止におけるダウン タイムの長さ" です。 クラスターはゾーンとリージョンの両方で回復力があるため、低くなります。 また、Apache Cassandra 自体は、すべてのノードが既定で書き込むことができる、フォールト トレラントなピア ツー ピア システムです。
RPO は、 障害が発生した場合に失われる可能性のあるデータの量です。 データはすべてのノードとデータ センターの間で同期されるため、低くなります。 停止時のデータ損失は最小限に抑えられます。
注
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書き込みを優先します。
待機時間や可用性ではなく、一貫性を優先するか、RPO を低くするか、RTO を低くすることが目的の場合は、整合性設定とレプリケーション係数がこの目標を反映している必要があります。
一般に、読み取りに必要なクォーラム ノードの数と、書き込みに必要なクォーラム ノードの数は、レプリケーション係数を超える必要があります。 たとえば、レプリケーション ファクターが 3 で、読み取りで quorum_one を使用する (1 ノード) 場合、書き込みで quorum_all を実行して (3 ノード)、合計の 4 がレプリケーション ファクター 3 を超えるようにする必要があります。
注
Azure Managed Instance for Apache Cassandra のコントロール プレーン オペレーターは、1 つのリージョンにのみデプロイされます。 リージョンは、最初のデータ センターをデプロイするときに選択したリージョンです。 万が一リージョン全体が停止した場合、コントロール プレーンを別のリージョンにフェールオーバーするため、3 時間の復旧時間がかかります。
データ センターは引き続き機能する必要があるため、この問題はサービスの 可用性 SLA には影響しません。 この期間中は、Azure portal またはリソース プロバイダー ツールからデータベース構成を変更できない場合があります。
レプリケーション
データ センター間で必要なレプリケーションが構成されるように、 keyspaces とそのレプリケーション設定を随時監査することをお勧めします。 開発の初期段階では、 cqlshを使用して簡単なテストを行うことをお勧めします。 たとえば、1 つのデータ センターに接続しているときに値を挿入し、もう一方のデータ センターから値を読み取るとします。
特に、既存のデータ センターに既にデータがある 2 つ目のデータ センターを設定する場合は、すべてのデータをレプリケートし、システムの準備ができていることを確認します。 nodetool netstatsを使用して DBA コマンドを使用してレプリケーションの進行状況を監視することをお勧めします。 別の方法として、各テーブルの行をカウントします。 ビッグ データ サイズでは、Cassandra の分散特性により、このアプローチでは大まかな見積もりしか得ないように注意してください。
ディザスター リカバリーのコストのバランス
アプリケーションが アクティブ/パッシブの場合でも、通常はリージョンごとに同じ容量をデプロイすることをお勧めします。 この方法は、アプリケーションをセカンダリ リージョンの ホット スタンバイ データ センターに即座にフェールオーバーするのに役立ちます。 リージョンの障害が発生した場合、この方法ではパフォーマンスが低下しません。 ほとんどの Cassandra クライアント ドライバーには、アプリケーション レベルのフェールオーバーを開始するためのオプションが用意されています。 既定では、リージョンの停止はアプリケーションもダウンしていることを意味するため、フェールオーバーはロード バランサー レベルで行われる必要があります。
2 つ目のデータ センターをプロビジョニングするコストを削減するために、セカンダリ リージョンにデプロイする SKU を小さくし、ノード数を減らしたい場合があります。 停止が発生した際に、Azure Managed Instance for Apache Cassandra のターンキー垂直および水平スケーリングにより、スケールアップがさらに容易になります。 アプリケーションがセカンダリ リージョンにフェールオーバーする間は、セカンダリ データ センター内のノードを手動で スケールアウト して スケールアップ できます。 セカンダリ データ センターは、低コストのウォーム スタンバイとして機能します。 このアプローチを使用するには、障害が発生した場合にシステムを完全な容量に復元するために必要な時間とバランスを取る必要があります。 リージョンが失われた場合に何が起こるかをテストして実践することが重要です。
注
ノードのスケールアップは、スケールアウトよりもはるかに高速です。垂直方向と水平方向のスケールのバランスと、クラスターにデプロイするノードの数を考慮する場合は、この点に注意してください。
バックアップ スケジュール
Azure Managed Instance for Apache Cassandra ではバックアップが自動的に実行されます。 毎日のバックアップの独自のスケジュールを選択できます。 負荷の少ない時間を選択することをお勧めします。 バックアップはアイドル状態の CPU のみを使用するように構成されていますが、状況によっては Cassandra で圧縮がトリガーされ、それにより、CPU 使用率が増加する可能性があります。 圧縮は Cassandra でいつでも行うことができます。 これらはワークロードと選択された圧縮戦略に依存します。
重要
バックアップの目的は、偶発的なデータ損失やデータの破損を軽減するためです。 バックアップを、ディザスター リカバリー戦略として推奨しているのではありません。
バックアップには地理的な冗長性がありません。 その場合でも、バックアップからデータベースを復旧するのに長い時間がかかる場合があります。 そのため、複数のリージョンのデプロイと、可能な限り可用性ゾーンを有効にし、障害シナリオを軽減し、それらのリージョンから効果的に復旧できるようにすることを強くお勧めします。 この方法は、障害が発生したリージョンを復旧できないまれなシナリオで特に重要です。 複数リージョンのレプリケーションがないと、すべてのデータが失われる可能性があります。
