Alibaba Cloud Service Mesh:ASM と GTM を組み合わせてリージョンレベルのディザスタリカバリを実装する

アーキテクチャ

このセクションでは、ディザスタリカバリのアーキテクチャについて説明します。この例では、デュアルリージョンとデュアルクラスターをデプロイして、リージョンレベルのディザスタリカバリを実装するアーキテクチャの機能を検証します。

1. 2 つのリージョンのそれぞれに Kubernetes クラスターをデプロイし、2 つのクラスターのそれぞれに同一のクラウドネイティブサービスをデプロイすることにより、マルチマスターコントロールプレーンアーキテクチャを構築します。サービスは、Kubernetes クラスターのドメイン名を使用して相互に呼び出します。

   説明

   マルチマスターコントロールプレーンを使用すると、各リージョンにプッシュされるメッシュプロキシのレイテンシを制御可能にし、リージョンでエラーが発生した場合にサービスの高可用性とコントロールプレーンのディザスタリカバリを確保できます。

2. 2 つのクラスターのそれぞれに ASM ゲートウェイをデプロイし、ゲートウェイの IP アドレスまたはドメイン名を設定して、インターネットに接続する Classic Load Balancer (CLB) または Network Load Balancer (NLB) インスタンスを介してインターネット経由のアクセスを公開します。次に、Alibaba Cloud DNS と Global Traffic Manager (GTM) を組み合わせて、ドメイン名を 2 つの IP アドレスに解決します。

3. リージョンで障害が発生した場合、別のリージョンのサービスは影響を受けません。この場合、GTM は障害が発生したリージョンにデプロイされたサービスの IP アドレスを解決プールから自動的に削除し、関連するトラフィックは正常なリージョンの ASM ゲートウェイにリダイレクトされます。

トラフィックの急増が発生した場合、次の機能を有効にして、トラフィックのリダイレクトをさらに最適化できます。

1. [HPA] を ASM ゲートウェイに対して有効にして、ASM ゲートウェイインスタンスを追加します。

   説明

   [HPA] 機能は、Enterprise Edition または Ultimate Edition の ASM インスタンスにのみ適用されます。

2. ASM ゲートウェイまたはクラスター内の重要なサービスにスロットリングポリシーを設定します。これにより、クラスターサービスの指定された機能内でトラフィックを制限し、ユーザーの大規模で突然の流入による正常なリージョンでのサーバークラッシュを防ぐことができます。

3. (オプション) ASM コンソールでローカルスロットリングのメトリック収集とアラートを設定します。このようにして、トラフィックをリアルタイムで監視し、障害を特定し、正常なリージョンで [HPA] 機能をできるだけ早く有効にすることができます。

プロセス

クロスリージョンのディザスタリカバリは、すべてのタイプのクラスターでサポートされています。次のサンプルは、ACK クラスターと ASM インスタンスを作成し、ディザスタリカバリを設定し、障害訓練を実施する方法に関するプロセス全体を示しています。

手順

このセクションでは、イングレスゲートウェイに関連付けられた CLB インスタンスを例として使用して、ディザスタリカバリの設定方法について説明します。イングレスゲートウェイに関連付けられた NLB インスタンスと GTM を統合する方法の詳細については、「GTM 設定プロセス」をご参照ください。

障害訓練

訓練では、外部ユーザーからのアプリケーションへのアクセスをシミュレートするために、fortio ツールを使用してサンプルアプリケーションでストレステストを実行します。テスト中に、イングレスゲートウェイワークロードを意図的に削除することにより、リージョン障害をシミュレートして、ディザスタリカバリプロセスを監視します。

1. 次のコマンドのドメイン名を GTM で設定された実際のドメイン名に置き換え、コマンドを実行してアプリケーションを 5 分間テストします。

   fortio load -jitter=False  -c 1 -qps 100 -t 300s -keepalive=False -a http://{ドメイン名}/productpage

2. テスト中に、cluster-2 を障害が発生したクラスターとしてリージョン障害をシミュレートします。

   1. ACK コンソール にログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。

   2. [クラスター] ページで、管理するクラスターを見つけ、その名前をクリックします。左側のウィンドウで、[ワークロード] > [デプロイメント] を選択します。

   3. [名前空間] ドロップダウンリストから [istio-system] を選択します。

   4. ワークロードリストで [istio-ingressgateway] を見つけ、[詳細] > [削除][アクション] 列の をクリックします。

3. 予期される出力：

   # range, mid point, percentile, count
   >= -261.054 <= -0.0693516 , -130.561 , 100.00, 3899
   # target 50% -130.595
   WARNING 100.00% of sleep were falling behind
   Aggregated Function Time : count 3899 avg 0.076910055 +/- 0.02867 min 0.062074583 max 1.079674 sum 299.872304
   # range, mid point, percentile, count
   >= 0.0620746 <= 0.07 , 0.0660373 , 19.34, 754
   > 0.07 <= 0.08 , 0.075 , 71.94, 2051
   > 0.08 <= 0.09 , 0.085 , 96.08, 941
   > 0.09 <= 0.1 , 0.095 , 99.23, 123
   > 0.1 <= 0.12 , 0.11 , 99.62, 15
   > 0.12 <= 0.14 , 0.13 , 99.82, 8
   > 0.14 <= 0.16 , 0.15 , 99.92, 4
   > 1 <= 1.07967 , 1.03984 , 100.00, 3
   # target 50% 0.0758289
   # target 75% 0.0812673
   # target 90% 0.0874825
   # target 99% 0.0992691
   # target 99.9% 0.155505
   Error cases : count 527 avg 0.074144883 +/- 0.07572 min 0.062074583 max 1.079674 sum 39.0743532
   # range, mid point, percentile, count
   >= 0.0620746 <= 0.07 , 0.0660373 , 82.54, 435
   > 0.07 <= 0.08 , 0.075 , 96.58, 74
   > 0.08 <= 0.09 , 0.085 , 99.05, 13
   > 0.09 <= 0.1 , 0.095 , 99.24, 1
   > 0.12 <= 0.14 , 0.13 , 99.43, 1
   > 1 <= 1.07967 , 1.03984 , 100.00, 3
   # target 50% 0.0668682
   # target 75% 0.0692741
   # target 90% 0.0753108
   # target 99% 0.0897923
   # target 99.9% 1.06568
   # Socket and IP used for each connection:
   [0] 3900 socket used, resolved to [39.XXX.XXX.160:80 (3373), 106.XXX.XXX.73:80 (527)], connection timing : count 3900 avg 0.038202153 +/- 0.03097 min 0.027057 max 1.07747175 sum 148.988395
   Connection time histogram (s) : count 3900 avg 0.038202153 +/- 0.03097 min 0.027057 max 1.07747175 sum 148.988395
   # range, mid point, percentile, count
   >= 0.027057 <= 0.03 , 0.0285285 , 13.28, 518
   > 0.03 <= 0.035 , 0.0325 , 62.79, 1931
   > 0.035 <= 0.04 , 0.0375 , 83.95, 825
   > 0.04 <= 0.045 , 0.0425 , 86.13, 85
   > 0.045 <= 0.05 , 0.0475 , 86.18, 2
   > 0.05 <= 0.06 , 0.055 , 86.28, 4
   > 0.06 <= 0.07 , 0.065 , 98.03, 458
   > 0.07 <= 0.08 , 0.075 , 99.77, 68
   > 0.08 <= 0.09 , 0.085 , 99.92, 6
   > 1 <= 1.07747 , 1.03874 , 100.00, 3
   # target 50% 0.0337079
   # target 75% 0.0378848
   # target 90% 0.0631659
   # target 99% 0.0755882
   # target 99.9% 0.0885
   Sockets used: 3900 (for perfect keepalive, would be 1)
   Uniform: false, Jitter: false, Catchup allowed: true
   IP addresses distribution:
   39.XXX.XXX.160:80: 3373
   106.XXX.XXX.73:80: 527
   Code  -1 : 527 (13.5 %)
   Code 200 : 3372 (86.5 %)
   Response Header Sizes : count 3899 avg 178.19851 +/- 70.45 min 0 max 207 sum 694796
   Response Body/Total Sizes : count 3899 avg 4477.7081 +/- 1822 min 0 max 5501 sum 17458584
   All done 3899 calls (plus 1 warmup) 76.910 ms avg, 13.0 qps

   結果は、クライアントからの少数のリクエストがアプリケーションへの接続を確立できないことを示しています。これは、ASM と GTM を組み合わせることでリージョンレベルのディザスタリカバリが実現されていることを示しています。

4. Global Traffic Manager ページに移動し、ドメイン名のアクセスステータスを表示します。 cluster-2 の IP アドレスがリストされていないことがわかります。

   

   アドレスが使用できない場合にアラート通知を受信し、使用できないアドレスを手動で削除するには、アラートルールを設定する必要があります。詳細については、「アラート設定を構成する」をご参照ください。