アプリケーションをスケールアウトする必要がある場合、新しいバージョンがデプロイされる場合、またはトラフィックバーストが予想される場合、Service Mesh（ASM）のウォームアップ機能を使用して、カスタムの時間枠内でリクエストトラフィックを徐々に増やすことができます。 これにより、スムーズな移行が保証され、サービスの中断、リクエストのタイムアウト、および負荷の急激なバーストによって引き起こされる潜在的なデータ損失のリスクが軽減されます。 このように、アプリケーションのスケーリングと更新中に安定したパフォーマンスと高可用性が保証されます。
前提条件
Enterprise Edition または Ultimate Edition の ASM インスタンスが作成されており、ASM インスタンスのバージョンが 1.14.3 以降です。 詳細については、「ASM インスタンスの作成」をご参照ください。
クラスターが ASM インスタンスに追加されています。 詳細については、「ASM インスタンスへのクラスターの追加」をご参照ください。
kubectl を使用して Container Service for Kubernetes（ACK）クラスターが接続されています。 詳細については、「クラスターの kubeconfig ファイルを取得し、kubectl を使用してクラスターに接続する」をご参照ください。
イングレス ゲートウェイが作成されています。 詳細については、「イングレス ゲートウェイの作成」をご参照ください。
Bookinfo という名前のサンプル アプリケーションがデプロイされています。 この例では、reviews サービスが使用されます。 詳細については、「ASM インスタンスへのアプリケーションのデプロイ」をご参照ください。
背景情報
ウォームアップ機能が無効になっている場合、ポッドが追加されると、新しいポッドに比例配分されたトラフィックが送信されます。 ただし、一部のサービスは、割り当てられたすべてのリクエストを処理できるようになる前にウォームアップするのに時間がかかります。 この場合、リクエストのタイムアウトやデータ損失が発生し、ユーザー エクスペリエンスが損なわれる可能性があります。 たとえば、Java 仮想マシン（JVM）で実行されている Web アプリケーションは、水平ポッド自動スケーリング機能を使用します。 ポッドが追加されると、ポッドには大量のリクエストが殺到します。 その後、ポッドがウォームアップしているため、リクエストへの応答が遅くなったり、タイムアウトしたりします。 ウォームアップ機能の動作原理は、新しいポッドが徐々にトラフィックを受信できるようにすることです。
ウォームアップ機能の使用
ウォームアップ機能を使用すると、サービスの期間を指定できます。 ウォームアップ機能が有効になっている場合、新しいインスタンスは起動時に少数のリクエストのみを受信します。 リクエストの数は、指定された期間中に徐々に増加します。 指定された期間が終了すると、インスタンスはウォームアップ モードを終了します。
ウォームアップ モードでは、新しいポッドが大量のリクエストによってノックダウンされるのを防ぎます。 新しいポッドは、指定された負荷分散ポリシーに基づいて分散されたリクエストを処理する前にウォームアップする時間があります。
この機能は、キャッシュに依存し、最適なパフォーマンスを提供するためにウォームアップする必要があるアプリケーションに役立ちます。 サービスでこの機能を有効にするには、DestinationRule の YAML ファイルで trafficPolicy.loadBalancer フィールドを設定します。 次のフィールドに注意してください。
loadBalancer: 負荷分散ポリシーのタイプを指定します。 有効な値: ROUND_ROBIN および LEAST_REQUEST。
warmupDurationSecs: サービスのウォームアップ期間を指定します。 サービスの新しく作成されたエンドポイントは、作成されてから指定された期間、ウォームアップ モードのままになります。 この期間中、Istio は比例配分されたトラフィックを送信する代わりに、エンドポイントのトラフィック量を徐々に増加させます。
ウォームアップ機能では、現在のゾーンにあるアプリケーションのポッド レプリカの数がゼロ以外である必要があります。 以下に 2 つのシナリオを示します。
データ プレーン上の ACK クラスターはゾーン A にのみデプロイされています: アプリケーションにゾーン A に 1 つのポッド レプリカがある場合、2 つ目のポッド レプリカを起動するとウォームアップ機能が有効になります。
データ プレーン上の ACK クラスターはゾーン A と B にデプロイされています: アプリケーションにゾーン A に 1 つのポッド レプリカしかない場合、ゾーン B に 2 つ目のポッド レプリカを起動してもウォームアップ機能は有効になりません。 デフォルトでは、スケジューラーはゾーン全体にデプロイされます。 この場合、3 つ目のポッド レプリカを起動するとウォームアップ機能が有効になります。
DestinationRule の YAML ファイルの例:
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: mocka
spec:
host: mocka
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
warmupDurationSecs: 100s
ステップ 1: ルーティングルールを設定してイングレスゲートウェイにアクセスする
この例では、ACK クラスタの reviews-v3 デプロイメントのレプリケートされたポッドの数が最初にゼロにスケーリングされます。
イングレスゲートウェイを定義します。
次の内容を含む bookinfo-gateway.yaml という名前のファイルを作成します。
次のコマンドを実行して、bookinfo-gateway をデプロイします。
kubectl apply -f bookinfo-gateway.yaml
reviews という名前のサービスを作成します。
次の内容を含む reviews.yaml という名前のファイルを作成します。
次のコマンドを実行して、reviews サービスをデプロイします。
kubectl apply -f reviews.yaml
イングレスゲートウェイの IP アドレスに継続的にアクセスし、サービスメッシュのトポロジを表示します。
この例では、hey コマンドを使用して 10 秒間リクエストを送信し、ストレスシナリオをシミュレートします。 hey のダウンロードとインストール方法の詳細については、hey をご参照ください。 ASM の可観測性機能を有効にしてトポロジを表示する方法の詳細については、「メッシュトポロジを使用してアプリケーションのトポロジを表示する」をご参照ください。
hey -z 10s -q 100 -c 4 http://${IP address of the ingress gateway}/reviews/0次の図は、呼び出しトポロジを示しています。
ステップ 2: 新しい Pod に送信されたリクエスト数を確認する
ASM コンソール にログインします。
左側のナビゲーションペインで、 を選択します。
[メッシュ管理] ページで、構成する ASM インスタンスを見つけます。[管理] 列の ASM インスタンス名をクリックするか、[アクション] をクリックします。
左側のナビゲーションペインで、 を選択します。
ASM インスタンスのバージョンが 1.17.2.35 より前の場合、[監視指標] ページの [監視ツール] タブをクリックします。[監視ツール] タブで、[cloud ASM Istio サービス] タブをクリックし、reviews サービスを選択します。
ASM インスタンスのバージョンが 1.17.2.35 以降の場合、[監視指標] ページの [cloud ASM Istio ワークロード] タブをクリックし、[ワークロード] ドロップダウンリストから reviews-v3 を選択し、[レポーター] ドロップダウンリストから source を選択します。
ストレステストのリクエストを送信し、監視データを観察します。
ウォームアップ機能が無効になっていることを確認します。ACK クラスタの reviews-v3 デプロイメントのレプリケート Pod の数を 0 から 1 にスケールします。
次のコマンドを実行して、ストレステスト用のリクエストをイングレスゲートウェイに送信します。
この例では、ストレステストは 120 秒間続きます。
hey -z 120s -q 100 -c 4 http://${IP address of the ingress gateway}/reviews/0Prometheus Monitoring ページのダッシュボードを観察します。
ストレステスト開始後約 45 秒で、reviews-v3 の Pod が安定したレートでリクエストを受信し始めます。必要な時間は、ストレステスト環境によって異なります。
ACK クラスタの reviews-v3 デプロイメントのレプリケート Pod の数を 0 にスケールします。
手順 3：ウォームアップ機能を有効にする
reviews.yaml ファイルを更新して、次の内容を含めます。
warmupDurationSecsフィールドを追加し、値を120sに設定します。apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: reviews spec: host: reviews trafficPolicy: loadBalancer: simple: ROUND_ROBIN # ウォームアップ期間を 120 秒に設定します。 warmupDurationSecs: 120s次のコマンドを実行して、reviews サービスを更新します。
kubectl apply -f reviews.yaml
手順 4: ウォームアップ機能の効果を確認する
ACK クラスタの reviews-v3 デプロイメントのレプリケート ポッド数を 0 から 1 にスケーリングします。
次のコマンドを実行して、ストレステストのためにイングレスゲートウェイにリクエストを送信します。
この例では、ストレステストは 150 秒間続きます。
hey -z 150s -q 100 -c 4 http://${IP address of the ingress gateway}/reviews/0[cloud ASM Istio サービス] タブで、サービスメッシュのダッシュボードを表示します。
reviews-v3 のポッドは、ストレステスト開始後約 120 秒で安定したレートでリクエストを受信し始めます。必要な時間は、ストレステスト環境によって異なります。
この曲線は、メトリックが一定の間隔で収集されるため、滑らかではありません。実際には、reviews-v3 ポッドへのトラフィックはスムーズに増加します。サイドカープロキシのログ収集を有効にしている場合は、Simple Log Service コンソールでサイドカープロキシのログを検索できます。過去 5 分間のログが表示されます。
ウォームアップ機能が有効になっている場合、新しいインスタンスは起動時に少量のリクエストのみを受信します。リクエスト数は、指定された期間中に徐々に増加します。指定された期間が終了すると、インスタンスはウォームアップモードを終了します。ウォームアップ機能が有効になっている場合、トラフィックが reviews-v1、reviews-v2、および reviews-v3 に均等に分散されるまで約 150 秒かかります。
参考文献
ローカルスロットリングまたはグローバルスロットリングを設定して、トラフィックを設定済みのしき値内に維持し、サービスの継続的な可用性と安定したパフォーマンスを確保できます。詳細については、「Traffic Management Center でローカルスロットリングを設定する」および「ASMGlobalRateLimiter を使用して、サイドカープロキシが挿入されたサービスへのインバウンドトラフィックのグローバルスロットリングを設定する」をご参照ください。
ASMAdaptiveConcurrency を使用して、サンプリングされたリクエストデータに基づいて、サービスで許可される最大同時リクエスト数を動的に調整できます。同時リクエスト数がサービスでサポートされる最大値を超えると、サービスを保護するために超過リクエストは拒否されます。詳細については、「ASMAdaptiveConcurrency を使用してアダプティブ同時実行制御を実装する」をご参照ください。
サーキットブレーカーは、システム障害または過負荷が発生した場合に、システムがさらに損傷するのを防ぐために使用されるトラフィック管理メカニズムです。詳細については、「connectionPool フィールドを設定してサーキットブレーカーを実装する」をご参照ください。