Container Service for Kubernetes:Kubernetesコンテナークラスターに基づくディザスターリカバリーアーキテクチャとソリューション

DRの目的

• 回復時間目標 (RTO): サービス中断と回復の間の最大許容期間。 RTOは、サービス中断の最大持続時間を表す。

• リカバリポイント目標 (RPO): 最後のデータリカバリポイントからの最大許容期間。 RPOは、損失または再構成されたデータの最大許容量を表す。

RTOまたはRPOが小さいほど、サービスのダウンタイムが短くなり、データの損失が少なくなりますが、リソースコストが高くなり、O&Mが複雑になります。したがって、予算に基づいて適切なRTOとRPOを作成する必要があります。

DR戦略

概要

前の図は、バックアップ-復元、アクティブ-スタンバイ、アクティブ-アクティブの3つの一般的なDR戦略を示しています。 戦略はコストとメリットが異なります。 ビジネスの重要性、データ損失耐性、および予算に基づいて戦略を選択できます。

バックアップ-復元

上の図に示すように、アプリケーションとデータはバックアップ-復元モードで定期的にバックアップされます。 バックアップデータは、災害時にビジネストラフィックが切り替わる別の場所のアプリケーションを復元するために使用できます。

データはリアルタイムでバックアップされないため、データ復元中に特定の量のデータが失われます。 これには長い時間が必要になる場合がありますが、復元されたデータのサイズによって異なります。

アクティブ-スタンバイ

前の図に示すように、プライマリロケーションはほとんどのビジネスを処理し、セカンダリロケーションはより少ないインスタンスを実行して、アクティブ-スタンバイモードのコストを節約します。 テストトラフィックは定期的に送信され、システムの有効性をチェックします。

障害または災害が発生した場合、プライマリ /セカンダリの切り替えが実行されます。 この場合、迂回トラフィックを処理するために、セカンダリロケーションでより多くのインスタンスが開始されます。

アクティブ-アクティブ

上の図に示すように、アクティブモードとアクティブモードの両方の場所で同じ量のトラフィックを同時に処理するために、同じ数のインスタンスが実行されています。

1つの場所で障害または災害が発生した場合、切り替えが実行され、正常に実行されている場所にビジネストラフィックが転送されます。

DRスコープ

クロスゾーン (マルチAZ)

Alibaba Cloudでは、リージョンには複数の可用性ゾーン (AZ) が含まれ、別々の電源リソースとネットワークリソースで実行されます。 クロスAZ DRソリューションを設計して、電力やネットワークの停止などの小規模な災害からビジネスを保護できます。 AZ間通信は短い待ち時間を伴う。 したがって、cross-AZ DRは、データベース、キャッシュ、メッセージプロセッサなどのアプリケーションに適しています。

リージョンとゾーンの詳細については、「リージョンとゾーン」をご参照ください。

リージョン (マルチリージョン)

特定の大規模な災害は、同じ地域の複数のAZに影響を及ぼします。 この場合、クロスリージョンDRソリューションを開発できます。 しかしながら、クロスリージョン通信は、高いレイテンシを有する。 これにより、DRソリューションは、クロスAZソリューションよりも複雑でコストがかかります。

デザイン原理

マルチAZまたはマルチリージョンDRソリューションを設計する場合、データベース、キャッシュ、メッセージ処理アプリケーションなどのステートフルアプリケーションと、依存するクラウドサービスがクロスAZまたはクロスリージョンDRをサポートするかどうかを判断する必要があります。

ソリューションと例

バックアップ-復元

解決策1: Alibaba CloudでのクロスAZおよびクロスリージョンバックアップとリカバリ

次の図は、ソリューションのアーキテクチャを示しています。

以下の項目は、ソリューションについて説明します。

• ACKのアプリケーションは、Distributed Cloud Container Platform for Kubernetesのバックアップセンター (ACK One) を使用してバックアップされます。 アプリケーションは、ステートレスおよびステートフルなアプリケーションを含む。 ステートフルアプリケーションの場合、アプリケーションのYAMLデータをバックアップするときに、関連するストレージデータをバックアップすることもできます。

• ACK Oneのバックアップセンターは、Elastic Compute Service (ECS) (スナップショット) 、Apsara File Storage NAS (NAS) (ファイルシステム) 、Object Storage Service (OSS) (バケットとオブジェクト) 、cloud backupなどのクラウドサービスを統合しています。 これらのサービスは、アプリケーションYAMLデータ、クラウドディスクボリュームの永続ボリューム (PV) 、およびファイルシステムのPVのワンクリックバックアップをサポートします。

• アプリケーションとストレージのバックアップデータは、いつでも任意のリージョンとAZのACKクラスターに復元できます。

• ApsaraDB RDS for MySQLなどのAlibaba Cloudデータベースもバックアップおよび復元できます。 詳細については、「バックアップと復元」および「ApsaraDB RDSインスタンス間のデータ移行」をご参照ください。

解決策2: ハイブリッドクラウドのデータバックアップと復元

次の図は、ソリューションのアーキテクチャを示しています。

以下の項目は、ソリューションについて説明します。

• ACK Oneの登録済みクラスターを使用して、データセンターまたは他のクラウドプラットフォームにデプロイされたKubernetesクラスターをACKコンソールに接続できます。

• 次に、ACK Oneのバックアップセンターを使用して、登録済みクラスターのアプリケーションをバックアップできます。 アプリケーションは、ステートレスアプリケーションおよびステートフルアプリケーションを含む。 ステートフルアプリケーションの場合、YAML構成ファイルをバックアップするときに、関連するストレージデータをバックアップできます。

• バックアップアプリケーションデータ (Deployment/StatefulSet) とストレージデータ (PV/PVC) は、任意のリージョンとAZのACKクラスターに復元できます。

長所と短所

バックアップ /復元ソリューションは、他のソリューションよりも実装が簡単で低コストです。 しかしながら、RTOおよびRPOは高くなる可能性があり、アプリケーションを回復するための時間は、データの量およびアプリケーションの複雑さに応じて長くなる可能性がある。 RTOとRPOを下げるには、ACK Oneのバックアップセンターでサポートされている完全バックアップと増分バックアップの組み合わせを使用できます。

バックアップ復元ソリューションは通常、災害に対する最後の保護ラインとして使用されるため、これらのソリューションは重要です。 システム運用中は、データの定期的なバックアップとデータバックアップの使いやすさを確保する必要があります。

バックアップ /復元ソリューションは、クラスター間でアプリケーションを移行するためにも使用できます。 次の項目は、シナリオを説明します。

• データセンターからAlibaba Cloud ACKクラスターにアプリケーションを移行します。 詳細については、「外部KubernetesクラスターからACKクラスターへのアプリケーションの移行」をご参照ください。

• アプリケーションを新しいバージョンのクラスターに移行します。 このソリューションは、現在のクラスターバージョンが古く、バージョンの更新にリスクがある場合に適しています。 この場合、新しいバージョンのクラスターを作成してから、アプリケーションを移行できます。 詳細については、「バックアップセンターを使用して、古いKubernetesバージョンを実行するACKクラスターでアプリケーションを移行する」をご参照ください。

• アカウントの権限を調整するか、組織を再配置します。 詳細については、「ACK One Fleetインスタンスを使用してプラットフォーム間またはアカウント間で複数のクラスターを管理するためのベストプラクティス」および「異なるリージョンのクラスター間でアプリケーションを移行する」をご参照ください。

マルチクラスタサービス

アプリケーションの移行中に、多数のアプリケーションをバッチで移行する必要がある場合があります。 さらに、これらのアプリケーションは、互いに通信する必要があり得る。 この場合、[ACK One] のマルチラスターサービス (MCS) 機能を使用して、クラスターが相互接続されている限り、クラスター間アクセスを実装できます。

次の図に示すように、MCSは、アプリケーション2のKubernetesサービス (エンドポイントを含む) をクラスター1からクラスター2に挿入できます。 これにより、クラスター2のアプリケーション1は、クラスター1に属するアプリケーション2にアクセスできます。

専用回線とACK Oneの登録済みクラスター機能を使用して、データセンターまたは別のクラウドプラットフォームからACKを使用してKubernetesクラスターを登録し、登録済みクラスターに対してACK OneのMCS機能を有効にすることができます。

マルチアクティブDRソリューションで複数のAZを1つのリージョンで

複数のAZを含む単一のリージョンでマルチアクティブDRソリューションを使用できます。 アクティブスタンバイDRソリューションと比較して、マルチアクティブDRソリューションには次の利点があります。

• より高いリソース使用率と低コスト。

• より高いサービス品質とより強いフォールトトレランス: サービスレプリカの数が増えると、サービス品質と応答速度が向上します。 これにより、ピークトラフィックをより効率的に処理できます。 障害が発生した場合、トラフィック切り替えによるサービス中断が回避される。 サービスを中断することなく、システムの更新やメンテナンスを実行できます。

• 拡張スケーラビリティ: ゾーンにリソースが不足している場合、使用可能なリソースがある他のゾーンでアプリケーションをすばやくスケーリングできます。

マルチクラスターゲートウェイに基づくACK One

次の図は、ソリューションのアーキテクチャを示しています。

システムが期待どおりに実行されている場合:

災害が発生すると、AZ1は利用できなくなります。 プライマリ-セカンダリの切り替えが実行されます。 マルチクラスタゲートウェイ (クラウドネイティブMSEゲートウェイ) は、トラフィックをAZ2のACKクラスタ2に自動的に切り替えます。 アプリケーションインスタンスは、ACKクラスター2で自動的にスケールアウトされます。

以下の項目は、ソリューションについて説明します。

1. アプリケーションは、GitOpsを使用して2つのACKクラスターにデプロイされます。 継続的に一貫したデプロイは、Gitリポジトリに基づいて実装されます。

2. 標準のKubernetes Ingressルールは、ACK Oneのマルチクラスタゲートウェイを使用してYAML形式で定義されます。 これにより、レイヤ7トラフィックの分散が容易になる。 クロスAZ高可用性 (HA) は、マルチクラスタゲートウェイに実装されています。

3. クラスタ1またはクラスタ1内のアプリケーションが利用できなくなると、ACK Oneのマルチクラスタゲートウェイは、ビジネストラフィックをクラスタ2にシームレスかつ自動的に切り替えてフェイルオーバーを完了します。

4. トラフィックが増加すると、HPA機能はクラスター2のアプリケーションレプリカをスケールアウトします。これにより、自動スケーラーはクラスターノードをスケールアウトします。

5. Alibaba Cloud ApsaraDB RDSのcross-AZ DRの詳細については、「高可用性アーキテクチャの構築」をご参照ください。

長所と短所

シングルリージョンマルチAZソリューションはコスト効率が高いです。 Application Load Balancer (ALB) 、クラウドネイティブゲートウェイ、コンテナ、ミドルウェア、データベースサービスなどのクラウドサービスにマルチAZデプロイメントとHAを使用して、ビジネスの変化を最小限に抑え、迅速な切り替えを実行できます。

DNSトラフィック分散に基づく単一リージョン内の複数AZのDRソリューションと比較して、ACK Oneのマルチクラスタゲートウェイに基づいて実装されたソリューションには、次の利点があります。

• 地域レベルの負荷分散とマルチクラスタ南北レイヤー7トラフィックの集中管理により、ゲートウェイの数とコストを削減できます。 DNSベースのトラフィック分散は、特定のクラスター間ルーティング機能をサポートしていません。 例えば、セッション持続性は、クイックUDPインターネット接続 (QUIC) のゼロラウンドトリップタイム (0 − RTT) に対して要求される。

• ミリ秒レベルおよび第2レベルのフェイルオーバーにより、DNSキャッシュの問題が解消されます。

  • ACK 1に基づくマルチクラスターゲートウェイ: クラスター内のサービスに障害が発生した場合、トラフィックはミリ秒または秒単位で他のクラスターに再ルーティングできます。 フェイルオーバーは、DNSベースのトラフィック分散よりもスムーズです。

  • DNSベースのトラフィック分散: 障害時にIPアドレスが変更されます。 ほとんどの場合、クライアントキャッシュのため、サービスは一時的に (分レベルで) 利用できません。 キャッシュの問題を解決するために、TTL値が削減されるため、DNSアクセス要求の数が多くなり、使用コストが高くなります。

• 管理の簡略化: 1つのコントロールパネル (フリート) でIngressの構成とサービスを管理します。 これは、サービスまたはアプリケーションを拡張および維持するためのより簡単な方法を提供し、管理コストを削減します。

• クラスターの更新または再構築中の透過的なクラスター移行: トラフィックはルールに基づいて正常なクラスターに移行され、更新または再構築が完了した後に転送されます。

次の図は、DNSベースのトラフィック分散のアーキテクチャを示しています。

クラウド + IDC DRソリューションの単一リージョン

このソリューションのアーキテクチャは、単一リージョンマルチAZ DRソリューションのアーキテクチャと同様です。 以下の項目は、このソリューションを説明します。

• VPCとデータセンターの間に専用回線接続が確立され、管理チャネルとデータチャネルが提供されます。

• データセンターからのクラスターは、登録済みクラスター機能を使用してACK Oneに接続されます。 これにより、Alibaba Cloudの可観測性とセキュリティ機能を使用して、オンプレミスクラスターとACKクラスターを一元管理できます。

• アプリケーションは、ACK One GitOpsを使用して両方のクラスターにデプロイされます。 継続的に一貫したデプロイは、Gitリポジトリに基づいて実装されます。

ACKに基づくソリューションOneマルチクラスタゲートウェイ (単一リージョンのオンプレミスおよびオフプレミスアクティブ-アクティブ)

次の図は、ソリューションのアーキテクチャを示しています。

マルチリージョンDRソリューション

ビジネスの規模が大きく、多くのリージョンから多数のユーザーがいる場合、単一リージョンのDRソリューションではビジネスのHAを確保できません。 この場合、マルチリージョンDRソリューションが必要になる場合があります。 ビジネスシステムは複数のリージョンに個別に展開され、各リージョンが独立して運用およびサービスを提供できるようにします。 マルチリージョンDRシナリオでは、ACK Oneのマルチクラスターゲートウェイに基づくDRソリューション、またはDNSトラフィック分散に基づくDRソリューションを選択できます。 これらのソリューションは、さまざまなシナリオに適しています。

解決策1: ACK Oneに基づくマルチクラスターゲートウェイ

ACK Oneでは、ALBマルチクラスタゲートウェイを使用してマルチリージョンDRソリューションを実装できます。 このソリューションは、次のシナリオに適しています。

• オンプレミスリージョンのクロスリージョンHAと不十分なリソース。 たとえば、現在のAIブームのため、GPUリソースは非常に不足しています。

• クライアントアプリケーションは、待ち時間にわずかに敏感であるが、強力なマルチクラスタトラフィック管理機能を必要とする。

次のセクションでは、ACK Oneマルチクラスタゲートウェイに基づくクロスリージョンDRソリューションの利点について説明します。

1. リージョン1のALBマルチクラスタゲートウェイは、QUICの0〜RTTやヘッダベースの転送など、リージョン間でレイヤ7トラフィックを転送するために使用されます。 リージョン2は、シングルクラスタALBインスタンスをコールドスタンバイとして設定し、リージョン1が使用できなくなった後にトラフィックをクラスタ2に分散します。

2. DNS解決と負荷分散はGTMに基づいて実装されます。シングルクラスターおよびマルチクラスターALBインスタンスのヘルスステータスが監視され、災害が発生したときにDRを自動的にトリガーできます。

3. リージョン1全体またはそのALBインスタンスに障害が発生した場合、GTMはサービスドメイン名のDNS解決をリージョン2のALBインスタンスに切り替えてDRを実装します。 リージョン1のクラスターまたはサービスのみに問題が発生した場合、またはリージョン2が使用できなくなった場合、ALBマルチクラスタゲートウェイは、GTMを使用してよりスムーズなフェールオーバーを実装する必要なく、トラフィックを正常なクラスターに自動的に再ルーティングします。

4. クラスター1とクラスター2がCENまたはVPCピアリング接続を使用して接続された後、信頼性を確保するために専用回線を使用してクロスリージョントラフィックが転送されます。

5. キャッシュにはマルチリージョンHAソリューションが使用されます。 詳細については、「[お知らせ] ApsaraDB for RedisとTairがマージされました」をご参照ください。

6. データベースには、クロスリージョンHAソリューションが使用されます。 詳細については、「マルチゾーン展開のアーキテクチャ」をご参照ください。

次のセクションでは、ACK Oneマルチクラスタゲートウェイに基づくクロスリージョンDRソリューションの利点について説明します。

• より強力なマルチクラスター転送機能: 従来のGTMよりも高度なコンテンツベースのルーティング機能と柔軟なヘルスチェックメカニズムを提供し、より複雑なアプリケーションシナリオに適応します。

• 集中型マルチクラスタトラフィック管理Ingress: 1つのコントロールプレーン (フリート) を使用して、Ingressの構成とサービスを管理します。 これにより、サービスとアプリケーションの拡張と保守が容易になり、管理コストが削減されます。

• DNSキャッシュの問題の軽減: DRシナリオでは、頻繁なサービス例外やクラスター障害が発生した場合に、DNS解決のIPアドレス切り替えが不要であることが示されています。 シームレスなフェイルオーバーは数秒で実現できます。

解決策2: DNSベースのトラフィック分散と単一のACK One Fleetインスタンス

DNSトラフィック分散に基づくマルチリージョンDRソリューションは、グローバルなGTMを提供し、近くのアクセスを伴うシナリオに適しています。 次の図は、ソリューションのアーキテクチャを示しています。

以下の項目は、ソリューションについて説明します。

1. Anti-DDoS ProxyとWeb Application Firewall (WAF) を使用して、SQLインジェクション、クロスサイトスクリプティング (XSS) 、コマンドインジェクション攻撃などのボリュームおよびwebアプリケーション攻撃からサービスを保護します。 詳細については、「GTMがWAF、GA、およびSLBで動作する」および「Anti-DDoS ProまたはAnti-DDoS PremiumおよびWAFを使用してWebサイトサービスを保護する」をご参照ください。

2. ユーザーリクエストは、GTMを使用して近くのリージョンにルーティングされます。

3. アプリケーションは、GitOpsを使用して2つのACKクラスターにデプロイされます。 継続的に一貫したデプロイは、Gitリポジトリに基づいて実装されます。

4. キャッシュにはマルチリージョンHAソリューションが使用されます。 詳細については、「[お知らせ] ApsaraDB for RedisとTairがマージされました」をご参照ください。

5. データベースには、クロスリージョンHAソリューションが使用されます。 詳細については、「マルチゾーン展開のアーキテクチャ」をご参照ください。

6. マルチAZ DRソリューションは、各リージョンで使用できます。

解決策3: DNSベースのトラフィック分散と複数のACK One Fleetインスタンス

次の図は、ソリューションのアーキテクチャを示しています。

以下の項目は、ソリューションについて説明します。

1. Anti-DDoS ProxyとWAFを使用して、SQLインジェクション、クロスサイトスクリプティング (XSS) 、コマンドインジェクション攻撃などのボリュームおよびwebアプリケーション攻撃からサービスを保護します。 詳細については、「GTMがWAF、GA、およびSLBで動作する」および「Anti-DDoS ProまたはAnti-DDoS PremiumおよびWAFを使用してWebサイトサービスを保護する」をご参照ください。

2. ユーザーリクエストは、GTMを使用して近くのリージョンにルーティングされます。

3. アプリケーションは、GitOpsを使用して2つのACKクラスターにデプロイされます。 継続的に一貫したデプロイは、Gitリポジトリに基づいて実装されます。

4. キャッシュにはマルチリージョンHAソリューションが使用されます。 詳細については、「[お知らせ] ApsaraDB for RedisとTairがマージされました」をご参照ください。

5. データベースには、クロスリージョンHAソリューションが使用されます。 詳細については、「マルチゾーン展開のアーキテクチャ」をご参照ください。

6. マルチAZ DRソリューションは、各リージョンで使用できます。

クロスリージョンユニットベースのマルチアクティブなソリューション

前述のクロスリージョンDRソリューションと比較して、このソリューションでは、アプリケーションとデータをシャードするルールを設定する必要があります。 これにより、ユニットはデータシャードに基づいて完全なサービスを提供できます。 このソリューションでは、ビジネスを安全に分離し、さまざまな単位でビジネスを個別にスケールアウトして、大規模なユーザーグループにサービスを提供できます。

このソリューションでは、ビジネスはサブユニットと中央ユニットに分類されます。 ユーザデータを有する中央ユニットは、データを共有した複数のサブユニットを管理する。 このソリューションでは、ビジネスシステムがカスタムトラフィック分散、データ分割、およびユニットインタラクションをサポートする必要があり、実装は非常に複雑です。

次の図は、ソリューションのアーキテクチャを示しています。