ゾーン内優先機能の設定

マイクロサービスエンジン（MSE）が提供するゾーン内優先機能は、ロードバランシングポリシーとして機能します。その中核となるメカニズムは、コンシューマーとプロバイダーがデプロイされているゾーンの属性を動的に識別し、リクエストを同じゾーン内のプロバイダーに優先的にルーティングすることです。従来のポーリングアルゴリズムと比較して、この機能はゾーン間のトラフィック転送を削減するのに役立ちます。これにより、ネットワーク遅延を効果的に削減し、サービス応答速度を向上させ、システムのディザスタリカバリ機能を強化できます。このトピックでは、MSE コンソールでゾーン内優先機能を設定する方法について説明します。

前提条件

MSE のマイクロサービスガバナンスがアクティブ化されていること。詳細については、「マイクロサービスガバナンスのアクティブ化」をご参照ください。
MSE のマイクロサービスガバナンスは、対象のアプリケーションとそのコンシューマーに対して有効になっています。詳細については、「ACK または ACS クラスター内の Java マイクロサービスアプリケーションに対してマイクロサービスガバナンスを有効にする」および「ECS インスタンス上のマイクロサービスアプリケーションに対してマイクロサービスガバナンスを有効にする」をご参照ください。

重要

ゾーン内優先機能は、Dubbo および Spring Cloud サービスでサポートされています。この機能は Kubernetes サービスではサポートされていません。
MSE が提供するゾーン内優先機能を使用する前に、適切なセキュリティしきい値を設定する必要があります。この機能は、ゾーン内のプロバイダーの割合が指定されたセキュリティしきい値を超えた場合にのみ実装されます。

用語

ゾーン: ゾーンとは、同じリージョン内で独立した電源とネットワークを持つ物理的な領域です。たとえば、中国（北京）リージョンには、北京ゾーン A と北京ゾーン B を含む 12 のゾーンがあります。同じゾーンにデプロイされているアプリケーションインスタンス間のネットワーク遅延は、異なるゾーンにデプロイされているアプリケーションインスタンス間のネットワーク遅延よりも小さくなります。
コンシューマーとプロバイダー: マイクロサービスのシナリオでは、呼び出しを開始するアプリケーションインスタンスはコンシューマーと呼ばれ、サービスを提供するアプリケーションインスタンスはプロバイダーと呼ばれます。ほとんどの場合、アプリケーションは同時にプロバイダーとコンシューマーとして機能できます。
RT: リクエストの往復レイテンシ。クライアントがリクエストを開始してからサーバーから応答を受信するまでの期間です。
インスタンス: インスタンスは、口語表現ではノードと呼ばれます。Kubernetes のシナリオでは、アプリケーションワークロードのポッドはアプリケーションインスタンスと見なされます。Elastic Compute Service（ECS）のシナリオでは、ECS インスタンス上の単一のアプリケーションプロセスはアプリケーションインスタンスと見なされます。

メリット

ゾーン内優先機能は、マイクロサービスアーキテクチャにおけるトラフィックスケジューリングポリシーとして機能します。この機能は、ロードバランシングメカニズムを使用して、コンシューマーと同じゾーンにデプロイされているプロバイダーを優先的に選択します。マルチゾーンアーキテクチャでは、ゾーン内優先機能は、以下を含むがこれらに限定されない、幅広いメリットを提供します。

ゾーン間の呼び出しと比較して、ゾーン内の呼び出しはシステム全体の RT を削減します。
マイクロサービスの呼び出しは、同じゾーン内で行う必要があります。単一のゾーンで障害が発生した場合、影響はそのゾーンに限定されます。

説明

ゾーン内優先機能は必須ではありません。システム全体の RT を削減し、システム全体の可用性を向上させる場合は、この機能を有効にすることをお勧めします。

機能の説明

MSE のマイクロサービスガバナンスは、ゾーン内優先機能を提供します。アプリケーションに対してこの機能を有効にすると、そのコンシューマーは、同じゾーン内のアプリケーションのインスタンスへの呼び出しを優先的に開始します。たとえば、この機能はアプリケーション P に対して有効になっています。アプリケーション C1、C2、および C3 がアプリケーション P への呼び出しを開始する場合、アプリケーションは、アプリケーションがデプロイされているゾーン内のアプリケーション P のインスタンスを優先的に呼び出します。

次の図は、MSE が提供するゾーン内優先機能が有効になっていない場合に使用されるアプリケーション呼び出しモデルを示しています。

次の図は、MSE が提供するゾーン内優先機能が有効になっている場合に使用されるアプリケーション呼び出しモデルを示しています。

重要

MSE が提供するゾーン内優先機能は、単一のプロバイダーに対してのみ有効です。アプリケーションに対してゾーン内優先機能を有効にした場合、アプリケーションのすべてのコンシューマーは、コンシューマーがデプロイされているリージョン内のアプリケーションインスタンスを優先的に呼び出します。

セキュリティしきい値

MSE が提供するゾーン内優先機能を使用する場合、次の問題が発生する可能性があります。アプリケーションに対してゾーン内優先機能を有効にした後、すべてのコンシューマーが同じゾーン内のプロバイダーを呼び出します。ゾーン内のプロバイダーの数がコンシューマーの数よりも少ない場合、特定のコンシューマーからのリクエストが失敗する可能性があります。実際には、すべてのアプリケーションのすべてのノードがゾーン全体に均等に分散されているわけではありません。場合によっては、少数のプロバイダーがゾーンにデプロイされており、ゾーン内のコンシューマーによって開始されたトラフィック呼び出しを処理できない可能性があります。

次の図は、3 つのプロバイダーがゾーン A にデプロイされ、3 つのプロバイダーがゾーン B にデプロイされ、1 つのプロバイダーがゾーン C にデプロイされているシナリオを示しています。アプリケーションに対してゾーン内優先機能を有効にした場合、各ゾーンのコンシューマーの数が同じであると仮定すると、トラフィックの 3 分の 1 が各ゾーンで受信されます。ただし、このシナリオでは、ゾーン C で使用可能なプロバイダーは 1 つだけです。唯一のプロバイダーが処理する必要があるトラフィックは、他のリージョンの各プロバイダーが処理する必要があるトラフィックの 3 倍です。これは、安定性のリスクをもたらす可能性があります。

この場合、ゾーン C のコンシューマーは、ゾーン内優先機能のロジックを実装しないことが想定されます。この問題に対処するために、MSE ではセキュリティしきい値を設定できます。アプリケーションに対してゾーン内優先機能が有効になっている場合、ゾーンにデプロイされているアプリケーションインスタンスの割合が指定されたセキュリティしきい値未満の場合、ゾーン内のコンシューマーは、アプリケーションへの呼び出し中に機能のロジックを実装しません。代わりに、マイクロサービスフレームワークのデフォルトのランダムまたはラウンドロビンポリシーが適用されます。

たとえば、ゾーン A、B、および C にデプロイされているアプリケーションインスタンスの数は、それぞれ 2、2、および 1 であり、すべてのアプリケーションインスタンスの 40%、40%、および 20% を占めています。アプリケーションに対してゾーン内優先機能を有効にし、セキュリティしきい値を 30% に設定した場合、ゾーン C のコンシューマーは、同じゾーン内のプロバイダーを優先的に呼び出しません。ゾーン A および B のコンシューマーは、引き続き同じゾーン内のプロバイダーを優先的に呼び出すことができます。

前提条件

ゾーン内優先機能は、ゾーン全体にデプロイされているアプリケーションインスタンス間の呼び出しに適用されます。これは、リソースデプロイメントの環境に複数のゾーンがあり、アプリケーションインスタンスがこれらのゾーン全体にデプロイされているという仮定に基づいています。

重要

アプリケーションのインスタンスがゾーン全体に完全に均等にデプロイされていない場合は、ゾーン内優先機能を使用しないでください。

アプリケーションのインスタンスがゾーン全体に均等にデプロイされている場合は、ゾーン内優先機能を使用することをお勧めします。
異なるゾーンにデプロイされているアプリケーションインスタンスの数がわずかに異なる場合でも、ゾーン内優先機能を使用することをお勧めします。ただし、推定を実行し、セキュリティしきい値を設定する必要があります。推定を実行し、セキュリティしきい値を設定する方法の詳細については、このトピックのセキュリティしきい値の設定を参照してください。

ゾーン全体にアプリケーションインスタンスをデプロイする

Alibaba Cloud Container Service for Kubernetes（ACK）を使用してアプリケーションを管理およびデプロイする場合は、ノードプールのネットワーク構成に複数のゾーンの vSwitch が含まれていることを確認してください。これにより、ワークロードを異なるゾーンのノードにデプロイできます。さらに、アプリケーションインスタンスを複数のゾーンにデプロイすることをお勧めします。ワークロードの spec > template > spec にポッドトポロジスプレッド制約を追加できます。ゾーン全体にアプリケーションインスタンスをデプロイする方法の詳細については、「高可用性クラスタを作成するための推奨構成」をご参照ください。
```
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: "topology.kubernetes.io/zone"
    whenUnsatisfiable: ScheduleAnyway
```
アプリケーションが Elastic Compute Service（ECS）インスタンスにデプロイされている場合は、インスタンスの作成時に ECS インスタンスに対して異なるゾーンの vSwitch を選択する必要があります。アプリケーションをデプロイするときは、ゾーン全体にアプリケーションのインスタンスを手動でデプロイできます。

手順

MSE コンソールにログインし、上部のナビゲーションバーでリージョンを選択します。
左側のナビゲーションウィンドウで、[マイクロサービスガバナンス] > [アプリケーションガバナンス] を選択します。表示されるページで、管理するアプリケーションのリソースカードをクリックします。
左側のナビゲーションウィンドウで、Traffic management をクリックします。表示されるページで、Intra-zone Provider First タブをクリックします。
[設定] [構成情報] の横にあるをクリックし、[有効化ステータス] スイッチをオンにし、[セキュリティしきい値] を指定して、[OK] をクリックします。
上記の手順を実行した後、コンシューマーがアプリケーションへの呼び出しを開始すると、コンシューマーは同じゾーン内のプロバイダーを優先的に選択します。[OK] をクリックすると、アプリケーションを再起動しなくても機能がすぐに有効になります。

セキュリティしきい値の設定

セキュリティしきい値を設定した後、単一ゾーン内のアプリケーションプロバイダーインスタンスの割合が指定されたセキュリティしきい値未満の場合、ゾーン内のコンシューマーは同じゾーン内のプロバイダーインスタンスを優先的に呼び出しません。代わりに、マイクロサービスフレームワークのデフォルトのランダムまたはラウンドロビン呼び出しポリシーが使用されます。詳細については、このトピックのセキュリティしきい値を参照してください。

ビジネスアプリケーションのデプロイステータスに基づいて、セキュリティしきい値を適切に設定する必要があります。主な目的は、ゾーン内の少数のアプリケーションインスタンスが過剰なリクエストによって過負荷にならないようにすることです。次のシナリオを参照して、セキュリティしきい値を設定できます。

シナリオ 1（共通）：アプリケーションインスタンスはゾーン全体に均等にデプロイされています。このシナリオでは、セキュリティしきい値を1 をゾーンの数で割った値よりも小さい値に設定することをお勧めします。たとえば、アプリケーションに 6 つのインスタンスがあり、そのうち 2 つのインスタンスがゾーン A にデプロイされ、2 つのインスタンスがゾーン B にデプロイされ、2 つのインスタンスがゾーン C にデプロイされているとします。各ゾーンのアプリケーションインスタンスは、すべてのアプリケーションインスタンスの 33.33% を占めています。この場合、セキュリティしきい値を 33% に設定できます。

シナリオ 2：アプリケーションインスタンスはゾーン全体に均等にデプロイされていません。この場合、各ゾーンのインスタンスの数に基づいてセキュリティしきい値を設定する必要があります。たとえば、アプリケーションの場合、2 つのアプリケーションインスタンスがゾーン A にデプロイされ、2 つのアプリケーションインスタンスがゾーン B にデプロイされ、1 つのアプリケーションインスタンスがゾーン C にデプロイされているとします。ゾーン C ではゾーン内優先機能が実装されていないことが想定されます。この場合、セキュリティしきい値を 30% に設定できます。ゾーン A のアプリケーションインスタンスは、すべてのアプリケーションインスタンスの 40% を占めています。この割合は、ゾーン B のアプリケーションインスタンスの割合と同じです。ゾーン C のアプリケーションインスタンスは、すべてのアプリケーションインスタンスの 20% を占めています。ゾーン内優先機能によって実装されるロジックの代わりに、ゾーン C ではデフォルトのランダムまたはラウンドロビンポリシーが適用されます。

重要

セキュリティしきい値のデフォルト値は 20% で、通常はテスト環境での検証と試用に使用されます。ゾーン内のアプリケーションインスタンスのデプロイステータスに基づいてセキュリティしきい値を設定することをお勧めします。

使用上の注意

ゾーン内のプロバイダーの割合が指定されたセキュリティしきい値よりも厳密に大きい場合、ゾーン内優先機能が有効になります。ゾーン内のプロバイダーの割合がセキュリティしきい値と等しい場合、ゾーン内優先機能は有効になりません。
理想的には、プロバイダーとコンシューマーはゾーン全体に均等にデプロイされます。プロバイダーとコンシューマーが均等にデプロイされていないが、特定のゾーンに集中してデプロイされている場合、ゾーン内優先機能を有効にした後、異なるゾーンのトラフィック負荷のバランスが崩れる可能性があります。
サービスがリリースされると、各ゾーンのアプリケーションインスタンスの数は短期間で変化する可能性があり、特に Kubernetes でのローリングアップデート中はそうです。この場合、一部のゾーンのアプリケーションインスタンスの割合がセキュリティしきい値に達しない可能性があり、短期間でゾーン間のプロバイダー呼び出しが発生する可能性があります。
ゾーン内優先機能は、トラフィックレベルでの分離にのみ適しており、ビジネスレベルでの分離には使用しないでください。この機能を使用する場合は、ゾーン間のプロバイダー呼び出しが許可されていることを確認する必要があります。
セキュリティしきい値が有効な場合、システムはゾーン内の使用可能なアプリケーションインスタンスの割合がセキュリティしきい値に達しているかどうかを確認します。使用可能なアプリケーションインスタンスの数とアプリケーションインスタンスの総数は、エンドツーエンドカナリアリリースの論理フィルタリング結果に基づいて計算されます。（ほとんどの場合、業務システムは、ビジネスバージョンがリリースされた場合にのみエンドツーエンドカナリアリリース機能を使用します。この項目に注意する必要はありません。システムがバージョンリリースに加えて通常のルートフィルタリングにエンドツーエンドカナリアリリース機能を使用している場合は、この項目に注意する必要があります。）

説明

たとえば、アプリケーションに 5 つのインスタンスがあり、そのうち 2 つのインスタンスがゾーン A にデプロイされ、2 つのインスタンスがゾーン B にデプロイされ、1 つのインスタンスがゾーン C にデプロイされているとします。ゾーン A と B では、1 つのカナリアインスタンスが使用可能です。ゾーン A で公式バージョンを使用するコンシューマーの場合、各ゾーンのアプリケーションの 1 つのインスタンスのみを呼び出すことができます。セキュリティしきい値が 35%（40% 未満）に設定されている場合、ゾーン内優先機能は、公式バージョンを使用するコンシューマーのゾーン A と B では有効になりません。ゾーン A でカナリアバージョンを使用するコンシューマーの場合、ゾーン A と B のアプリケーションの 1 つのインスタンスを呼び出すことができます。ゾーン C ではアプリケーションインスタンスを呼び出すことができません。ゾーン内優先機能は、カナリアバージョンを使用するコンシューマーに対して有効になります。

ゾーンの観点からのトラフィック観測

ゾーン内のノードとトラフィックの分布

ゾーン内優先機能は、観測機能を提供します。アプリケーションに対して MSE マイクロサービスガバナンスを有効にした後、ゾーン内優先タブで現在のアプリケーションのインスタンスデプロイメント分布と各ゾーンのトラフィック負荷を表示できます。

アプリケーションに対してゾーン内優先機能が有効になっていない場合でも、上記の情報を表示できます。

重要

マイクロサービスガバナンスプロフェッショナルエディションを使用している場合、または名前空間がプロフェッショナルエディションの名前空間である場合、上記の情報を表示することはできません。次の方法を使用して名前空間をアップグレードします。

名前空間を Professional Edition から Enterprise Edition にアップグレードします。詳細については、「マイクロサービス名前空間の管理」をご参照ください。

重要な注意点

ゾーン内優先タブの「トラフィック観測」セクションでは、全体データに各ゾーンにデプロイされているアプリケーションインスタンスの数を表示できます。視覚データは、異なるゾーンのアプリケーションインスタンスの不均衡な分布を示すことができます。システムの可用性を向上させるために、アプリケーションのインスタンスをゾーン全体に均等にデプロイすることをお勧めします。

アプリケーションに対してゾーン内優先機能が有効になっている場合は、ゾーンのトラフィック量、各ゾーンで処理されるトラフィック量、および各ゾーンにデプロイされているアプリケーションインスタンスの数を確認する必要があります。たとえば、多数のアプリケーションインスタンスがゾーンにデプロイされていますが、ゾーンで処理されるトラフィック量は少ないです。別の例として、少数のアプリケーションインスタンスがゾーンにデプロイされていますが、ゾーンで処理されるトラフィック量は多いです。2 つの例では、トラフィック分布の不均衡によって引き起こされる安定性の問題を防ぐために、セキュリティしきい値を調整する必要があります。

RT の削減

ゾーン内優先機能を有効にしない場合、マイクロサービス呼び出しにはデフォルトのランダムまたはラウンドロビンポリシーが使用されます。これにより、ゾーン全体で多数のマイクロサービス呼び出しが発生します。次の図は、ゾーン内優先機能が有効になっていないアプリケーションのデータを示しています。表示されているデータは、過去 5 分間の平均 RT が 7.88 ミリ秒であることを示しています。

異なるゾーンのアプリケーションのすべてのインスタンスに対してゾーン内優先機能を有効にした後、次の図に表示されているデータは、平均 RT が 6.85 ミリ秒に変化することを示しています。