1. Home
2. Next-Gen WAF
3. セットアップと設定
4. Kubernetes

sigsci-agent をサイドカーとして Pod にインストールした場合、エージェントは Pod 内のアプリケーションのスケーリング方法に従ってスケーリングされます。この方法は、アプリケーションを別途スケーリングする必要がないため、エージェントのインストール方法としておすすめです。ただし、環境によっては、エージェントをアプリケーションとは異なる比率でスケーリングさせる必要がある場合があります。このような場合、エージェントをサイドカーではなく、アプリケーション Pod から利用される Service としてインストールできます。ただし、エージェントを Service としてインストールする場合には制限があります。

制約事項

• sigsci-agent は単一のサイト (ワークスペースとも呼ばれます) に対してのみ設定できます。つまり、Service としてデプロイされたエージェントは単一のサイト (ワークスペース) にしかデータを送信できません。また、その Service 内のすべてのエージェントは同一の設定を共有します。

• sigsci-agent はレスポンスを処理する際に、一部のリクエスト状態を保持します。これは、リクエストデータを処理したエージェントと、レスポンスデータを処理するエージェントが同一である必要があることを意味します。そのため、エージェントをロードバランシングする場合には Affinity が必要となり、Service のスケーリングがより複雑になります。

• sigsci-agent を Service として使用する場合、通信チャネルを Unix ドメインソケットではなく TCP として設定する必要があり、わずかに効率が低下します。

Next-Gen WAF エージェントを Service としてインストールする

sigsci-agent は Service としてインストールできますが、上記の制限事項があるため、Service の設定には注意が必要です。Service は単一のサイト (ワークスペース) に紐づけられます。複数のサイト (ワークスペース) を使用する場合は、サイト (ワークスペース) 名に基づいてサービス名を付ける必要があります。Service をスケーリングするには、同じエージェントが1つのトランザクションのリクエストデータとレスポンスデータの両方を処理するように設定する必要があります。そのためには、エージェントにデータを送信している Pod に基づいた Affinity を使用するように Service を設定する必要があります。これは、クライアント IP を使用するように Affinity を設定することで実現します。

以下は、クライアント IP Affinity を使用して、my-site-name というサイト (ワークスペース) に紐づけられた Service の例です。

apiVersion: v1
kind: Service
metadata:
  name: sigsci-agent-my-site-name
  labels:
    app: sigsci-agent-my-site-name
spec:
  ports:
  # Port names and numbers are arbitrary
  #  737 is the default RPC port
  #  8000 may be more appropriate for gRPC used with Envoy
  - name: rpc
    port: 737
    targetPort: 737
  selector:
    app: sigsci-agent-my-site-name
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 60

Service は、任意の数のレプリカを持つ Deployment で構成されている必要があります。sigsci-agent コンテナは、一般的なサイドカーインストールと同様に設定する必要がありますが、共有の Unix ドメインソケットではなく TCP を使用する必要があります。これは、SIGSCI_RPC_ADDRESS 設定オプションを指定することで行われます。Envoy と組み合わせて使用する場合は、代わりに SIGSCI_ENVOY_GRPC_ADDRESS を使用する必要がある点に注意してください。

上記の Service に対応する Deployment の例を以下に示します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sigsci-agent-my-site-name
  labels:
    app: sigsci-agent-my-site-name
spec:
  replicas: 2
  selector:
    matchLabels:
      app: sigsci-agent-my-site-name
  template:
    metadata:
      labels:
        app: sigsci-agent-my-site-name
    spec:
      containers:
      - name: sigsci-agent
        image: signalsciences/sigsci-agent:latest
        imagePullPolicy: IfNotPresent
        env:
        - name: SIGSCI_ACCESSKEYID
          valueFrom:
            secretKeyRef:
              name: sigsci.my-site-name
              key: accesskeyid
        - name: SIGSCI_SECRETACCESSKEY
          valueFrom:
            secretKeyRef:
              name: sigsci.my-site-name
              key: secretaccesskey
        # Use RPC via TCP instead of default Unix Domain Socket
        - name: SIGSCI_RPC_ADDRESS
          value: "0.0.0.0:737"
        # Use all available resources.limits.cpu cores
        - name: SIGSCI_MAX_PROCS
          value: "100%"
        securityContext:
          readOnlyRootFilesystem: true
        volumeMounts:
        - name: sigsci-tmp
          mountPath: /sigsci/tmp
        # Set CPU resource limits (required for autoscaling)
        resources:
          limits:
            cpu: 4
          requests:
            cpu: 1
      volumes:
      - name: sigsci-tmp
        emptyDir: {}

上記の例では、my-site-name サイト (ワークスペース) 用に、sigsci-agent-my-site-name Service が使用する sigsci-agent Pod を2つデプロイしています。各エージェントは最大4つの CPU コアを認識し、少なくとも1コア分のリソースを必要とします。

その後、各アプリケーション Pod では、Service で定義されたサービス名およびポートに対して sigsci-agent に送信するよう、モジュールを設定する必要があります。この例では、モジュールはホスト sigsci-agent-my-site-name、ポート737に送信するよう設定されます。これらの値は、Service および SIGSCI_RPC_ADDRESS 設定オプション (Envoy を使用している場合は SIGSCI_ENVOY_GRPC_ADDRESS) によって定義されます。

スケーリングに関しては、この Service に接続する各 Pod に対して、Service 内で稼働している sigsci-agent が1つ割り当てられ、そのエージェントに対して Affinity が固定されます。その後、そのエージェントが更新されたり、自動スケーリングによるスケールダウンなどで Service から削除されたりした場合、クライアントのアプリケーション Pod は別のエージェントに再割り当てされます。Affinity によってエージェントが Pod に割り当てられる仕組みのため、アクティブなエージェントの最大数は、Service に接続している Pod の数を超えることはありません。これは、レプリカ数や自動スケーリングのパラメータを決定する際に考慮すべき点です。

Deployment は自動スケーリング可能です。たとえば、kubectl autoscale を介して Horizontal Pod Autoscaler を使用した自動スケーリングが可能です。以下の例では、Deployment は最小で2エージェントを使用し、全体の CPU 使用率が60%に達した場合に最大で6エージェントまでスケールアップします。ただし、これらのエージェントはすべて単一のサイト (ワークスペース) のみを処理する点に注意してください。

$ kubectl autoscale deployment sigsci-agent-my-site-name --cpu-percent=60 --min=2 --max=6

Horizontal Pod Autoscaler の状態は、kubectl get hpa コマンドで確認できます。

$ kubectl get hpa

このコマンドは次のような出力を生成します。

NAME                      REFERENCE                            TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
sigsci-agent-my-site-name Deployment/sigsci-agent-my-site-name 42%/60%   2         6         2          53m42s

このタイプのスケーリングにはいくつかの制限があります。レプリカ数を手動で設定してスケーリングした場合や自動スケーリングを行った場合、Service に紐づく sigsci-agent Pod の数が変化します。エージェントが追加されると、Service への新しい接続に対して、新しいエージェント Pod への Affinity が割り当てられる可能性があります。しかし、すでに特定のエージェント Pod への Affinity が設定されているアプリケーション Pod は、Service の Affinity タイムアウト設定 (sessionAffinityConfig.clientIP.timeoutSeconds) に到達しない限り、リバランスされません。そのため、このスケーリング方式は、アプリケーション Pod も併せてスケーリングされ、新しいアプリケーション Pod が新しいエージェント Pod にバランスされる運用の場合に最も効果的です。同様に、スケールダウンによってエージェント Pod が Service から削除された場合、そのエージェントに割り当てられていたアプリケーション Pod は別のエージェントに再割り当てされ、新たに Affinity が設定されます。しかし、その後再びスケールアップしても、これらはリバランスされません。このような状況が頻繁に発生する場合は、Affinity タイムアウト (sessionAffinityConfig.clientIP.timeoutSeconds) を短く設定し、通信のない時間があればリバランスされるようにすることを検討してください。

関連コンテンツ

• Kubernetes インストール概要