Skip to main content

エージェントのデプロイ数を制限する

IAST(Contrast Assess)を使用してアプリケーションを監視するエージェントをデプロイする場合は、パフォーマンスへの影響を考慮する必要があります。Webトラフィックがサーバファーム間で負荷分散されている場合は、全てのサーバにエージェントをインストールする必要はありません。ロードバランサーがトラフィックを均等に分散し、全てのトラフィックをファーム内の全てのサーバにルーティングする場合は、エージェントを1つのサーバにデプロイするだけで、同じレベルの監視または脆弱性検出を実現できます。同様に、ロードバランシングのトポロジに基づいて、各バックエンドの宛先にサンプルポイントを設定できます。

本項では、エージェントのデプロイを制限してパフォーマンスを向上させる方法の例を紹介します。

エージェントのデプロイを制限する理由

  • パフォーマンスの最適化：全てのサーバにエージェントをデプロイすると、不要なオーバーヘッドが発生する可能性があります。特にアプリケーションがレイテンシ(遅延時間)の影響を受けやすい場合やリソースに制約がある場合、その可能性が高くなります。デプロイするエージェントの数を減らすことで、CPUとメモリの使用量を最小限に抑え、応答時間とアプリケーション全体のパフォーマンスを向上させることができます。

  • トラフィックの十分なカバレッジ：ロードバランサーは全てのサーバにトラフィックを均等に分散するため、1つのサーバ上のエージェントによって代表的なトラフィックを監視することができます。多くの場合、これにより、全てのインスタンスをインストゥルメント化する必要はがなく、セキュリティと監視の目的で十分なデータを取得できます。

Kubernetes(K8s)で選択的にエージェントをデプロイする

Kubernetes環境では、エージェントで実行されるレプリカの数を制御することで、デプロイ内のどのポッドがエージェントでインストゥルメント化されるかを管理できます。以下の方法を参考にして下さい。

  1. ノードテイント：ノードテイント(taint)と容認(toleration)を使用して、エージェントを持つポッド専用のノードを指定します。 1つのノードに特定のテイントでラベルを付け、そのノード上でエージェント対応のポッドを実行するようにスケジュールします。他のノードは影響を受けません。

  2. ポッドアフィニティポッドアフィニティ(affinity)とアンチアフィニティ(anti-affinity)を使用して、エージェント対応のポッドを実行する場所を制御します。エージェント対応のポッドを特定のノードまたはポッドにのみスケジュールするアフィニティルールを作成します。ファーム全体にエージェント対応ポッドが複製されないようにすることができます。

  3. デプロイのオーバーライド: 2つのデプロイを設定するカスタムデプロイマニフェストを使用します。1つは通常のアプリケーションポッド用、もう1つはエージェント対応のポッド用です。エージェント対応のデプロイでは、「replicas: on」を設定して、エージェントで 1つのインスタンスのみが実行されるようにすることができます。

例：K8sにおける選択的なエージェントのデプロイ

このYAMLの例では、アプリケーションの1つのレプリカのみがエージェントを有効にしています。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-with-agent
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: my-app
        agent: enabled
    spec:
      containers:
        - name: app-container
          image: my-app-image
          env:
            - name: ENABLE_AGENT
              value: "true"

Docker Swarmで選択的にエージェントをデプロイする

K8sで行えるのと同様に、以下の方法で説明するように、Docker Swarmでサービスのスケーリングと制約を使用できます。

  1. サービス制約：サービス制約を使用して、エージェント対応コンテナを特定のノードまたはノードセットにデプロイします。例えば、ノードにラベルを付けて、そのノードで1つのエージェント対応サービスだけが実行されるようにすることができます。

    Bashの例

    以下は、ラベルagent == trueのあるノードにエージェント対応インスタンスをデプロイする例です。他のノードは影響を受けません。

    docker service create \
  --replicas 1 \
  --constraint "node.labels.agent == true" \
  --env ENABLE_AGENT=true \
  my-app-image

  2. タスクのレプリケーション：Docker Swarmでは、通常のアプリケーションとエージェントの2つのサービスを使用できます。1つは通常のアプリケーション用で、もう1つはエージェント用です。通常のサービスは全てのノードにスケールし、エージェント対応のサービスは1つのレプリカのみにスケールします。

    Bashの例

    以下の例は、ほとんどのコンテナがエージェントなしで実行され、1つのインスタンスは監視のためにエージェントを含む設定をする方法を示しています。

    docker service create --replicas 5 my-app-image  # Regular service
docker service create --replicas 1 --env ENABLE_AGENT=true my-app-image # Agent-enabled service

トラブルシューティングとテストに関する推奨事項

Webファーム内の1つのサーバにのみエージェントをデプロイすると、トラフィックのルーティングに問題が発生する可能性があります。ロードバランサーは全てのサーバにトラフィックを分散するため、エージェントがインストールされたサーバにテストトラフィックが常に送られるとは限りません。一部のトラフィックは、エージェントを組み込んだサーバをバイパスする可能性があるため、結果の検証が難しくなる可能性があります。全てのトラフィックが正しいサーバにルーティングされるわけではないため、不完全なデータや監視のギャップが発生する場合があります。

そのような場合は、ロードバランサーの設定を調査する必要があります。次の点を考慮して下さい。

  • セッションアフィニティ(スティッキーセッション)：ロードバランサーがセッションアフィニティをサポートしていることを確認して下さい。セッションアフィニティは、同じクライアントからのリクエストを同じサーバに繰り返しルーティングできます。スティッキーセッションを有効にすると、特定のユーザまたはIPアドレスからの全てのテストトラフィックをエージェントが組み込まれているサーバに転送し、テスト中の一貫性を向上させることができます。

  • ターゲットを絞ったテスト：特定のトラフィックに対する特定のサーバの重み付けルーティングまたは手動ターゲット設定を可能にするロードバランサー機能を使用する必要があるかもしれません。この機能により、エージェントを使用してテストトラフィックをサーバに送信し、エージェントがテストトラフィックを処理できるようになります。

このセクションの内容: