コンテンツにスキップ

Wallarm NGINXノードのためのリソース割当

Wallarm NGINXノードに割り当てるメモリおよびCPUリソースの量は、リクエスト処理の品質および速度を決定します。本手順書ではセルフホスト型NGINXノードへのメモリ割当の推奨事項について説明します。

フィルタリングノードには、主に次の2つのメモリおよびCPUリソースを消費するコンポーネントがあります。

  • Tarantool（postanalyticsモジュールとも呼ばれます）。これはローカルデータ分析バックエンドであり、フィルタリングノードにおける主要なメモリ消費コンポーネントです。

  • NGINXは、主要なフィルタリングノードでありリバースプロキシコンポーネントです。

NGINXのCPU使用率は、RPSレベル、リクエストおよびレスポンスの平均サイズ、ノードで処理されるカスタムルールセットのルール数、Base64などのデータエンコーディングやデータ圧縮などの種類やレイヤにより大きく影響されます。

平均的に、1つのCPUコアは約500 RPSを処理できます。プロダクションモードで運用する場合、NGINXプロセスには少なくとも1つのCPUコア、Tarantoolプロセスには1つのコアを割り当てることを推奨します。多くの場合、初めはフィルタリングノードに対してリソースを多めに割当し、実際のプロダクショントラフィックレベルにおけるCPUおよびメモリ使用率を確認の上、リソース割当を適正なレベルに段階的に削減することを推奨します（トラフィックスパイクおよびノード冗長性に対して少なくとも2倍のヘッドルームが必要です）。

Tarantool

Postanalytics uses the in-memory storage Tarantool. The Tarantool database is used to keep in a circular buffer a local copy of the data stream processed by a filtering node, including request/response headers and request bodies (but not response bodies).

To make a filtering node efficient, the database should keep at least 15 minutes of transmitted data with about 2x overhead for data serialization. Following these points, the amount of memory can be estimated by the formula:

Speed of request processing per minute in bytes * 15 * 2

For example, if a filtering node is handling at peak 50 Mbps of end user requests, the required Tarantool database memory consumption can be estimated as the following:

50 Mbps / 8 (bits in a byte) * 60 (seconds in a minute) * 15 * 2 = 11,250 MB (or ~ 11 GB)

Kubernetes Ingress Controllerにおけるリソース割当

Tarantool memory is configured for the ingress-controller-wallarm-tarantool pod using the following sections in the values.yaml file:

  • To set up memory in GB:

    controller:
  wallarm:
    tarantool:
      arena: "1.0"

  • To set up memory in CPU:

    controller:
  wallarm:
    tarantool:
      resources:
        limits:
          cpu: 400m
          memory: 3280Mi
        requests:
          cpu: 200m
          memory: 1640Mi

Listed parameters are set by using the --set option of the commands helm install and helm upgrade, for example:

helm install --set controller.wallarm.tarantool.arena='1.0' <INGRESS_CONTROLLER_RELEASE_NAME> wallarm/wallarm-ingress -n <KUBERNETES_NAMESPACE>

There are also other parameters required for correct Ingress controller installation. Please pass them in the --set option too.

helm upgrade --reuse-values --set controller.wallarm.tarantool.arena='0.4' <INGRESS_CONTROLLER_RELEASE_NAME> wallarm/wallarm-ingress -n <KUBERNETES_NAMESPACE>

All-in-One Installerを使用している場合のリソース割当

Tarantoolのメモリサイズは、/opt/wallarm/env.list設定ファイルのSLAB_ALLOC_ARENA属性で制御されています。メモリを割当するには、以下の手順に従ってください。

  1. /opt/wallarm/env.listファイルを編集のために開きます:

    sudo vim /opt/wallarm/env.list

  2. SLAB_ALLOC_ARENA属性にメモリサイズを設定します。値は整数または浮動小数点数で指定可能です（小数点はピリオド . を使用します）。例:

    SLAB_ALLOC_ARENA=1.0

  3. Wallarmサービスを再起動します:

    sudo systemctl restart wallarm.service

その他のデプロイメントオプションにおけるリソース割当

Tarantoolのメモリサイズは、/etc/default/wallarm-tarantool設定ファイルのSLAB_ALLOC_ARENA属性で制御されています。メモリを割当するには、以下の手順に従ってください。

  1. Tarantoolの設定ファイルを編集のために開きます:
sudo vim /etc/default/wallarm-tarantool

sudo vim /etc/default/wallarm-tarantool

sudo vim /etc/default/wallarm-tarantool

sudo vim /etc/default/wallarm-tarantool

sudo vim /etc/default/wallarm-tarantool

sudo vim /etc/sysconfig/wallarm-tarantool

sudo vim /etc/sysconfig/wallarm-tarantool

sudo vim /etc/sysconfig/wallarm-tarantool

sudo vim /etc/sysconfig/wallarm-tarantool
  1. SLAB_ALLOC_ARENA属性にメモリサイズを設定します。値は整数または浮動小数点数で指定可能です（小数点は.を使用します）。例:
SLAB_ALLOC_ARENA=1.0
  1. Tarantoolを再起動します:
sudo systemctl restart wallarm-tarantool

sudo systemctl restart wallarm-tarantool

sudo service wallarm-tarantool restart

sudo service wallarm-tarantool restart

sudo service wallarm-tarantool restart

sudo systemctl restart wallarm-tarantool

sudo systemctl restart wallarm-tarantool

sudo systemctl restart wallarm-tarantool

sudo systemctl restart wallarm-tarantool

NGINX

NGINXのメモリ消費は様々な要因に左右されます。平均的な消費量は、おおよそ以下のように見積もることができます:

同時接続リクエスト数 * 平均リクエストサイズ * 3

例:

  • フィルタリングノードがピーク時に10000の同時リクエストを処理し、

  • 平均リクエストサイズが5 kBの場合、

NGINXのメモリ消費は次のように見積もることができます:

10000 * 5 kB * 3 = 150000 kB (約150 MB)

メモリ割当を行うには:

  • NGINX Ingress controller pod（ingress-controller）の場合、values.yamlファイルの以下のセクションをhelm installまたはhelm upgradeの--setオプションを使用して設定します:

    controller:
  resources:
    limits:
      cpu: 400m
      memory: 3280Mi
    requests:
      cpu: 200m
      memory: 1640Mi

    パラメータを変更するコマンド例:

    helm install --set controller.resources.limits.cpu='2000m',controller.resources.limits.memory='3280Mi' <INGRESS_CONTROLLER_RELEASE_NAME> wallarm/wallarm-ingress -n <KUBERNETES_NAMESPACE>

    また、正しいIngress controllerのインストールには他のパラメータも必要です。これらも--setオプションで渡してください。

    helm upgrade --reuse-values --set controller.resources.limits.cpu='2000m',controller.resources.limits.memory='3280Mi' <INGRESS_CONTROLLER_RELEASE_NAME> wallarm/wallarm-ingress -n <KUBERNETES_NAMESPACE>

  • その他のデプロイメントオプションの場合、NGINXの設定ファイルを使用してください。

トラブルシューティング

Wallarmノードが予想以上に多くのメモリおよびCPUリソースを消費している場合、リソース使用量を削減するため、CPU高使用率のトラブルシューティングの記事をご確認の上、記載された手順に従ってください。