すべてのプロダクト
Search

このプロダクト

    Container Service for Kubernetes:オンラインサービスとビデオコード変換アプリケーションのColocate

    ドキュメントセンター

    Container Service for Kubernetes:オンラインサービスとビデオコード変換アプリケーションのColocate

    最終更新日:Nov 14, 2024

    Container Service for Kubernetes (ACK) は、ack-koordinatorコンポーネントに基づいて、サービスレベル目標 (SLO) 対応のワークロードスケジューリングを提供します。 SLO対応のワークロードスケジューリングを使用して、オンラインサービスアプリケーションとオフラインコンピューティングアプリケーションを同じ場所に配置できます。 このトピックでは、ack-koordinatorを使用してオンラインサービスとビデオコード変換アプリケーションを配置する方法について説明します。

    利用シナリオ

    オンラインNGINXサービスと、FFmpegを使用するビデオコード変換アプリケーションを同じ場所に配置できます。 これにより、ポッドに割り当てられているがノードで使用されていないリソースを利用できます。 ack-koordinatorのリソース分離機能を有効にして、オンラインNGINXサービスに割り当てられたリソースを、FFmpegを使用するビデオコード変換アプリケーションに割り当てられたリソースから分離できます。 このようにして、オンラインNGINXサービスのパフォーマンスを保証できます。

    配置アーキテクチャColocation deployment architecture

    この例では、オンラインNGINXサービスとFFmpegを使用するビデオコード変換アプリケーションがノード上に配置されています。 NGINXサービス用に作成されたポッドのサービス品質 (QoS) クラスは、レイテンシセンシティブ (LS) に設定されています。 ビデオトランスコードアプリケーション用に作成されたポッドのQoSクラスは、BE (best-effort) に設定されます。 このトピックでは、NGINXサービスのパフォーマンスをテストするために、さまざまなコロケーションモードでNGINXサービスを展開します。

    image

    以下の機能は、コロケーションで使用されます。

    • リソースの再利用: この機能により、BEワークロードは、LSワークロードに割り当てられているが使用されていないリソースをオーバーコミットできます。 これにより、クラスターのリソース使用率が向上します。 詳細については、「動的リソースのオーバーコミットメント」をご参照ください。

    • リソース分離: この機能では、さまざまな方法を使用して、BEワークロードで使用されるリソースを制限し、LSワークロードのリソース需要に優先順位を付けます。 詳細については、「CPU QoS」、「CPU抑制」、および「L3キャッシュとMBAに基づくリソース分離」をご参照ください。

    準備

    環境設定

    • ACK Proクラスターに2つのノードを追加します。 ノードの1つは、NGINX webサービスと、FFmpegを使用するビデオコード変換アプリケーションを実行し、テスト対象のマシンとして機能します。 他のノードにはwrkツールがインストールされており、NGINXサービスに要求を送信してストレステストを実行するために使用されます。 詳細については、「ACK Proクラスターの作成」をご参照ください。

    • ack-koordinatorのコロケーション機能によるメリットを最大限に活用するために、テスト済みのマシンをElastic Compute Service (ECS) Bare Metalインスタンスにデプロイし、Alibaba Cloud Linuxをノードのオペレーティングシステムとして使用することを推奨します。

    • ack-koordinator (ack-slo-manager) をインストールし、コロケーションポリシーを有効にします。 詳細については、「はじめに」をご参照ください。 この例では、ack-koordinator 0.8.0が使用されます。

    オンラインNGINXサービスのデプロイ

    オンラインNGINXサービスとwrkをデプロイします。

    1. ls-nginx. YAMLという名前のyamlファイルを作成し、次の内容をファイルにコピーします。

      YAMLファイルの内容を表示する

      ---
# Example of the NGINX configuration.
apiVersion: v1
data:
  config: |-
    user  nginx;
    worker_processes  80; # The number of worker processes that run in the NGINX service. This parameter specifies the number of requests that the NGINX server can concurrently process. 

    events {
        worker_connections  1024;  # The number of worker connections. Default value: 1024. 
    }

    http {
        server {
            listen  8000;

            gzip off;
            gzip_min_length 32;
            gzip_http_version 1.0;
            gzip_comp_level 3;
            gzip_types *;
        }
    }

    #daemon off;
kind: ConfigMap
metadata:
  name: nginx-conf

---
# The pod that runs the online NGINX service. 
apiVersion: v1
kind: Pod
metadata:
  labels:
    koordinator.sh/qosClass: LS
    app: nginx
  name: nginx
spec:
  containers:
    - image: 'koordinatorsh/nginx:v1.18-koord-exmaple'
      imagePullPolicy: IfNotPresent
      name: nginx
      ports:
        - containerPort: 8000
          hostPort: 8000 # The port that is used to perform stress tests. 
          protocol: TCP
      resources:
        limits:
          cpu: '80'
          memory: 10Gi
        requests:
          cpu: '80'
          memory: 10Gi
      volumeMounts:
        - mountPath: /apps/nginx/conf
          name: config
  hostNetwork: true
  restartPolicy: Never
  volumes:
    - configMap:
        items:
          - key: config
            path: nginx.conf
        name: nginx-conf
      name: config
  nodeName: cn-beijing.192.168.2.93  # Replace the value with the node name of the tested machine.

    2. 次のコマンドを実行してNGINXサービスをデプロイします。 

      kubectl apply -f ls-nginx.yaml

    3. 次のコマンドを実行して、NGINXサービスを実行するポッドの名前を照会します。 

      kubectl get pod -l app=nginx -o wide

      期待される出力:

      NAME    READY   STATUS    RESTARTS   AGE    IP               NODE                      NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          43s    11.162.XXX.XXX   cn-beijing.192.168.2.93   <none>           <none>

      出力は、ポッドが実行中の状態であることを示しています。 これは、NGINXサービスがテスト対象のマシンで期待どおりに実行されることを示します。

    4. 他のノードで次のコマンドを実行してwrkをデプロイします。 

      wget -O wrk-4.2.0.tar.gz https://github.com/wg/wrk/archive/refs/tags/4.2.0.tar.gz && tar -xvf wrk-4.2.0.tar.gz
cd wrk-4.2.0 && make && chmod +x ./wrk

    オフラインビデオトランスコードアプリケーションのデプロイ

    FFmpegを使用するオフラインビデオトランスコーディングアプリケーションをデプロイします。

    1. be-ffmpeg. YAMLという名前のyamlファイルを作成し、次のコンテンツをファイルにコピーします。

      YAMLファイルの内容を表示する

      # The pod that runs the offline video transcoding application that uses FFmpeg. 
apiVersion: v1
kind: Pod
metadata:
  name: be-ffmpeg
  labels:
    app: ffmpeg
  # 1. Use the default colocation mode of Kubernetes to deploy the application: Delete the koordinator.sh/qosClass=BE label. 
  # 2. Use the SLO-aware colocation mode of ACK to deploy the application: Retain the koordinator.sh/qosClass=BE label. 
    koordinator.sh/qosClass: BE
spec:
  containers:
    # You can increase the number of processes in the pod to improve the resource utilization of the offline video transcoding application. The default number is 25. Each process contains two threads that run in parallel. 
    - command:
        - start-ffmpeg.sh
        - '25'
        - '2'
        - /apps/ffmpeg/input/HD2-h264.ts
        - /apps/ffmpeg/
      image: 'registry.cn-zhangjiakou.aliyuncs.com/acs/ffmpeg-4-4-1-for-slo-test:v0.1'
      imagePullPolicy: Always
      name: ffmpeg
      resources:
      # 1. Use the default colocation mode of Kubernetes to deploy the application: Delete the following extended resources: kubernetes.io/batch-cpu and kubernetes.io/batch-memory. 
      # 2. Use the SLO-aware colocation mode of ACK to deploy the application: Retain the following extended resources: kubernetes.io/batch-cpu and kubernetes.io/batch-memory. 
      # Specify resource requests based on the resource specifications of the node. 
        limits:
          kubernetes.io/batch-cpu: 70k
          kubernetes.io/batch-memory: 22Gi
        requests:
          kubernetes.io/batch-cpu: 70k
          kubernetes.io/batch-memory: 22Gi
  hostNetwork: true
  restartPolicy: Never
  nodeName: cn-beijing.192.168.2.93  # Replace the value with the node name of the tested machine.

    2. 次のコマンドを実行して、FFmpegを使用するビデオトランスコードアプリケーションをデプロイします。 

      kubectl apply -f be-ffmpeg.yaml

    3. 次のコマンドを実行して、FFmpegを使用するビデオトランスコードアプリケーションが実行されているポッドのステータスを照会します。 

      kubectl get pod -l app=ffmpeg -o wide

      期待される出力:

      NAME        READY   STATUS    RESTARTS   AGE    IP               NODE                      NOMINATED NODE   READINESS GATES
be-ffmpeg   1/1     Running   0          15s    11.162.XXX.XXX   cn-beijing.192.168.2.93   <none>           <none>

      出力は、ポッドが実行中の状態であることを示しています。 これは、FFmpegを使用するビデオコード変換アプリケーションがテスト対象のマシンで期待どおりに実行されることを示します。

    手順

    このトピックでは、オンラインサービスとオフラインアプリケーションを3つのコロケーションモードでデプロイし、これらのモードでアプリケーションのパフォーマンスとノードのリソース使用率をテストします。 次の表は、アプリケーションのパフォーマンスとノードのリソース使用率の観点から、これらのモードを比較しています。

    展開モード

    説明

    オンラインサービスの排他的展開モード (ベースライングループ)

    このモードでは、オンラインNGINXサービスのみがテスト対象のマシンにデプロイされます。 FFmpegを使用するビデオコード変換アプリケーションは、テスト対象のマシンにはデプロイされません。 wrkを使用してNGINXサービスにリクエストを送信し、このモードでノードのパフォーマンスとリソース使用率をテストします。

    Kubernetesのデフォルトのコロケーションモード (制御グループ)

    オンラインNGINXサービスと、FFmpegを使用するオフラインビデオトランスコードアプリケーションをテスト対象のマシンにデプロイします。 次に、wrkを使用してNGINXサービスにリクエストを送信します。 この例では、FFmpegを使用する動画トランスコードアプリケーションのQoSクラスはBEに設定されており、動画トランスコードアプリケーションのポッド構成ではリソース要求と制限が指定されていません。 プロセス数を変更して、ノードのCPU使用率を制御できます。 この例では、ノードのCPU使用率は65% です。 NGINXサービスのパフォーマンスと、このモードのノードのリソース使用率をテストします。

    ACKのSLO対応コロケーションモード (実験グループ)

    このモードでは、オンラインNGINXサービスとFFmpegを使用するオフラインビデオトランスコードアプリケーションがテスト対象のマシンにデプロイされます。 wrkを使用してNGINXサービスにリクエストを送信し、このモードでノードのパフォーマンスとリソース使用率をテストします。 この例では、FFmpegを使用するビデオトランスコーディングアプリケーションのQoSクラスはBEに設定され、拡張リソースはビデオトランスコーディングアプリケーションのポッドによって要求されます。 詳細については、「動的リソースのオーバーコミットメント」をご参照ください。 CPU抑制、CPU QoS、およびL3キャッシュおよびMBA機能は、テストされたマシンに対して有効になります。 NGINXサービスのパフォーマンスと、このモードのノードのリソース使用率をテストします。

    テスト結果

    さまざまなコロケーションモードでのNGINXサービスのパフォーマンスとノードのリソース使用率を評価するには、次のメトリックを使用します。

    • 応答時間 (RT)-パーセンタイル: RTは、オンラインアプリケーションのパフォーマンスを評価するために一般的に使用されます。 より低いRT値は、より高い性能を示す。 wrkの出力でRT値を取得できます。 RT値は、NGINXサービスがwrkからの要求を処理するのに必要な時間を示します。 たとえば、RT-P50は、NGINXサービスがwrkからの50% の要求を処理するのに必要な最大時間を示します。 RT-P90は、NGINXサービスがwrkからの90% の要求を処理するのに必要な最大時間を示します。

    • ノードの平均CPU使用率: このメトリックは、期間内のノード上のアプリケーションのCPU使用率を示します。 kubectl top nodeコマンドを実行して、さまざまなコロケーションモードのノードの平均CPU使用率を照会できます。

    次の表に、さまざまなモードのメトリックを示します。

    メトリック

    ベースライングループ (排他的展開モード)

    制御グループ (デフォルトのコロケーションモード)

    実験グループ (SLO対応コロケーションモード)

    NGINX RT-P90 (ms)

    0.533

    0.574 (+ 7.7%)

    0.548 (2.8%)

    NGINX RT-P99 (ms)

    0.93

    1.07 (+ 16%)

    0.96 (+ 3.2%)

    ノードの平均CPU使用率

    29.6%

    65.1%

    64.8%

    • コントロールグループのメトリックとベースライングループのメトリックの比較: ノードの平均CPU使用率が29.6% から65.1% に増加します。 NGINX RT-P90とNGINX RT-P99の値は大幅に増加します。 RT曲線はロングテールを有する。

    • 実験グループのメトリックとベースライングループのメトリックを比較する: ノードの平均CPU使用率が28.5% から64.8% に増加します。 NGINX RT-P90とNGINX RT-P99の値はわずかに増加します。

    • 実験グループのメトリックと対照グループのメトリックを比較する: ノードの平均CPU使用率は似ています。 NGINX RT-P90およびNGINX RT-P99の値は大幅に減少し、ベースライン群のNGINX RT-P90およびNGINX RT-P99の値に近い。

    上記の結果は、オンラインNGINXサービスとオフラインビデオトランスコーディングアプリケーションが同じノードにデプロイされている場合、SLO対応のACKコロケーションモードでノードのCPU使用率を効果的に向上させ、パフォーマンスの干渉を軽減できることを示しています。

    アプリケーションのデプロイ

    オンラインサービスの排他的展開モード

    テスト対象のマシンにオンラインサービスのみをデプロイします。

    1. を参照してください。オンラインNGINXサービスのデプロイこのトピックのセクションでは、テスト対象のマシンにオンラインNGINXサービスを展開します。

    2. wrkを使用してNGINXサービスにリクエストを送信します。 

      # Replace node_ip with the IP address of the tested machine. Port 8000 of the NGINX service is exposed to the tested machine. 
./wrk -t6 -c54 -d60s --latency http://${node_ip}:8000/

    3. 次のコマンドを実行して、テストされたマシンの平均CPU使用率を照会します。 

      kubectl top node

      期待される出力:

      NAME                      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
cn-beijing.192.168.2.93   29593m       29%    xxxx            xxxx
cn-beijing.192.168.2.94   6874m        7%     xxxx            xxxx

      出力は、テストされたマシンの平均CPU使用率が約29% であることを示しています。

    4. ストレステストが完了したら、次のコマンドを実行してwrkからテスト結果を照会します。

      正確なテスト結果を得るには、複数のストレステストを実行することを推奨します。 

      Running 1m test @ http://192.168.2.94:8000/

      期待される出力:

        6 threads and 54 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   402.18us    1.07ms  59.56ms   99.83%
    Req/Sec    24.22k     1.12k   30.58k    74.15%
  Latency Distribution
     50%  343.00us
     75%  402.00us
     90%  523.00us
     99%  786.00us
  8686569 requests in 1.00m, 6.88GB read
Requests/sec: 144537.08
Transfer/sec:    117.16MB

      RTは、さまざまなシナリオでオンラインNGINXサービスのパフォーマンスを評価するための重要な指標です。 出力の [レイテンシ分布] セクションには、RTパーセンタイル値の分布が表示されます。 例えば、90% 523.00usは、要求の90% を処理するためのRTが523.00マイクロ秒であることを示す。 オンラインNGINXサービスのみがデプロイされている場合、RT-P50は343マイクロ秒、RT-P90は523マイクロ秒、RT-P99は786マイクロ秒です。

    Kubernetesのデフォルトのコロケーションモード

    テスト対象のマシンで、オンラインNGINXサービスとFFmpegを使用するオフラインビデオトランスコードアプリケーションを連携させます。 次に、wrkを使用してNGINXサービスにリクエストを送信します。 アプリケーションのコロケートについては、このトピックのSLO対応コロケーションモードを参照してください。 YAMLテンプレートの要件に基づいて、パラメーターとアノテーションを設定する必要があります。

    SLO対応コロケーションモードのACK

    FFmpegを使用するビデオコード変換アプリケーションのQoSクラスをBEに設定します。

    1. を参照してください。始めるSLO対応のコロケーションを有効にするには、

      次のリストでは、SLO対応のコロケーションに関連する機能について説明します。

      • 動的リソースのオーバーコミットメント: この機能を有効にした後、デフォルトの設定を使用します。 この機能により、ポッドに割り当てられているがノードで使用されていないリソースをシステムがオーバーコミットし、オーバーコミットされたリソースをBEポッドにスケジュールできます。

      • CPU抑制: この機能を有効にした後、cpuSuppressThresholdPercentパラメーターを65に設定し、残りの構成のデフォルト設定を使用します。 この機能は、ノードのCPU使用率が65% を超えると、BEポッドのCPU使用率を制限できます。 これにより、LSポッドのパフォーマンスが保証されます。

      • CPU QoS: この機能を有効にした後、デフォルトの設定を使用します。 この機能により、Alibaba Cloud LinuxのCPU Identity機能を有効にできます。 このように、CPUスケジューリング中にLSポッドがBEポッドよりも優先されます。 これにより、同時マルチスレッド (SMT) を使用して両方のポッドのスレッドを同時に実行する場合に、BEポッドがLSポッドに影響を与えるのを防ぎます。

      • L3キャッシュとMBAに基づくリソースの分離: この機能を有効にした後、デフォルトの設定を使用します。 この機能により、ECS Bare MetalインスタンスのL3キャッシュ (ラストレベルキャッシュ) とメモリ帯域幅を分離できます。 このように、LSポッドはL3キャッシュとメモリ帯域幅を使用するように優先されます。

      重要

      • CPU QoS機能は、Alibaba Cloud LinuxがノードOSとして使用されている場合にのみ有効にできます。

      • ノードがECS Bare Metalインスタンスにデプロイされている場合にのみ、L3キャッシュとメモリ帯域幅の分離を有効にできます。

    2. を参照してください。オンラインNGINXサービスのデプロイこのトピックのセクションでは、テスト対象のマシンにオンラインNGINXアプリケーションをデプロイします。

    3. be-ffmpeg. YAMLという名前のyamlファイルを作成し、次のコンテンツをファイルにコピーします。

      YAMLファイルの内容を表示する

      # The pod that runs the offline video transcoding application that uses FFmpeg. 
apiVersion: v1
kind: Pod
metadata:
  name: be-ffmpeg
  labels:
    app: ffmpeg
  labels:
    # Set the QoS class of the video transcoding application that uses FFmpeg to BE. 
    koordinator.sh/qosClass: BE
spec:
  containers:
    - command:
        - start-ffmpeg.sh
        - '30'
        - '2'
        - /apps/ffmpeg/input/HD2-h264.ts
        - /apps/ffmpeg/
      image: 'registry.cn-zhangjiakou.aliyuncs.com/acs/ffmpeg-4-4-1-for-slo-test:v0.1'
      imagePullPolicy: Always
      name: ffmpeg
      resources:
      # Apply for the following dynamically overcommitted resources: kubernetes.io/batch-cpu and kubernetes.io/batch-memory. 
        limits:
          kubernetes.io/batch-cpu: 70k
          kubernetes.io/batch-memory: 22Gi
        requests:
          kubernetes.io/batch-cpu: 70k
          kubernetes.io/batch-memory: 22Gi
  hostNetwork: true
  restartPolicy: Never
  nodeName: cn-beijing.192.168.2.93  # Replace the value with the node name of the tested machine.

    4. 次のコマンドを実行して、FFmpegを使用するビデオトランスコードアプリケーションをデプロイします。 

      kubectl apply -f besteffort-ffmpeg.yaml

    5. 次のコマンドを実行して、cert-manager用に作成されたポッドのステータスを照会します。 

      kubectl get pod -l app=ffmpeg -o wide

      期待される出力:

      NAME                READY   STATUS    RESTARTS   AGE    IP               NODE                      NOMINATED NODE   READINESS GATES
besteffort-ffmpeg   1/1     Running   0          15s    11.162.XXX.XXX   cn-beijing.192.168.2.93   <none>           <none>

    6. 次のコマンドを実行して、wrkを使用してNGINXサービスにリクエストを送信します。 

      # Replace node_ip with the IP address of the tested machine. Port 8000 of the NGINX service is exposed to the tested machine. 
./wrk -t6 -c54 -d60s --latency http://${node_ip}:8000/

    7. 次のコマンドを実行して、テスト対象のマシンのCPU使用率を照会します。 

      kubectl top node

      期待される出力:

      NAME                      CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
cn-beijing.192.168.2.93   65424m       63%    xxxx            xxxx
cn-beijing.192.168.2.94   7040m        7%     xxxx            xxxx

      出力は、テストされたマシンのCPU使用率が約63% であることを示しています。

    8. ストレステストが完了したら、次のコマンドを実行してwrkからテスト結果を出力します。

      テスト結果の詳細については、このトピックの「テスト結果」をご参照ください。

    さまざまなタイプのワークロードのコロケーションの詳細については、次のトピックを参照してください。

    よくある質問

    wrkによって返されたストレステストの結果に「ソケットエラー: 接続54」と表示された場合はどうすればよいですか?

    問題の説明

    wrkによって返されるストレステストの結果には、Socket errors: connect 54、が表示されます。 wrkクライアントとNGINXサーバー間の接続の作成に失敗しました。 その結果、ストレステストは失敗しました。

    原因

    このエラーは、クライアント接続数が上限を超えた場合に発生します。 その結果、クライアントはNGINXサーバーへの接続を作成できません。

    解決策

    このエラーを防ぐには、ストレステストマシンのTCP接続設定を確認し、TCP接続の再利用機能を有効にします。

    1. ストレステストマシンにログインし、次のコマンドを実行して、TCP接続の再利用が有効かどうかを確認します。 

      sudo sysctl -n net.ipv4.tcp_tw_reuse

      0または2が返された場合、TCP接続の再利用機能は無効になります。

    2. 次のコマンドを実行して、TCP接続の再利用機能を有効にします。 

      sudo sysctl -w net.ipv4.tcp_tw_reuse=1

    3. wrkを使用して別のストレステストを開始します。

      ストレステストの結果にソケットエラー: connect 54、... が表示されない場合、ストレステストは成功です。

    説明

    上記のコマンドは、ストレステストマシンでのみ実行します。 テスト済みのマシンを設定する必要はありません。 テストが完了したら、sysctl -w net.ipv4.tcp_tw_reuseコマンドを実行して、サービスがTCP接続の再利用機能の影響を受けた場合に備えて、TCP接続の再利用機能を無効にします。