☰

HAProxy Config - 何か間違っているのでしょうか?

tag-icon • tag-icon load-balancing linux-networking haproxy
HAProxy Config - 何か間違っているのでしょうか?

負荷がかかった状態でアプリに問題が発生し、いくつかの負荷テストを実行した後、httpポート経由でアプリ サーバーを直接負荷テストすると8080、アプリ サーバーがかなり速く応答することに気付きました。

ドメイン名を入力して （httpsつまり、入力したエンド ポイントが ）を使用して負荷テストを実行するとhttps://load.api.example.in、応答時間が約 5 倍に増加します。

このことから、中間の haproxy がボトルネックであるという結論に至りました。

haproxy のサーバー サイズを増やしましたが、負荷が高い場合、CPU 使用率が急上昇しますが、サーバーが大きいため、約 50% にとどまります。(AWS モニタリングによる)

この問題を解決するには、haproxy 設定 (または他の場所) で何を変更する必要がありますか?

私の現在の haproxy 設定 (匿名)

global
        ulimit-n 99999
        maxconn 99999
        maxpipes 99999
        log 127.0.0.1 local0
        log 127.0.0.1 local1 notice
        maxconn 4096
        tune.ssl.default-dh-param 2048
        chroot /var/lib/haproxy
        user haproxy
        group haproxy
        daemon

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        option forwardfor
        option http-server-close
        retries 3
        option redispatch
        maxconn 2000
        timeout connect 5000
        timeout client  50000
        timeout server  50000
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http

frontend mqtt
        bind *:1883
        bind *:1884
        mode tcp
        option clitcpka # TCP Keep-alive
        timeout client 3h
        timeout server 3h
        option tcplog

        acl host_mqtt_staging hdr(host) -i staging.mqtt.example.in
        acl host_mqtt_staging hdr(host) -i staging.mqtt.example.com
        acl host_mqtt hdr(host) -i mqtt.example.in
        acl host_mqtt hdr(host) -i mqtt.example.com
        use_backend mqtt_staging if host_mqtt_staging
        use_backend mqtt if host_mqtt

frontend http
        bind *:80
        mode http
        reqadd X-Forwarded-Proto:\ http
        redirect scheme https code 301 if !{ ssl_fc }

frontend https
        bind *:443 ssl crt /etc/haproxy/certs/staging.myservice.example-2.com.pem
        mode http
        reqadd X-Forwarded-Proto:\ https

        acl letsencrypt-acl path_beg /.well-known/acme-challenge/
        acl host_myservice_staging hdr(host) -i staging.api.example.in
        acl host_myservice_staging hdr(host) -i staging.api.example.com
        acl host_myservice_load hdr(host) -i load.api.example.in

        use_backend letsencrypt-backend if letsencrypt-acl
        use_backend myservice_staging if host_myservice_staging
        use_backend myservice_load if host_myservice_load
        default_backend api

backend letsencrypt-backend
        server letsencrypt 127.0.0.1:54321

backend api
        balance roundrobin
        option httpclose
        option forwardfor
        server web00 app00.staging.internal.example-2.com:8080 check

backend myservice_staging
        balance roundrobin
        option httpclose
        option forwardfor
        server myservice00 myservice00.staging.internal.example-2.com:8080 check weight 1

backend myservice_load
        balance roundrobin
        option httpclose
        option forwardfor
        server myserviceload00 load00.staging.internal.example-2.com:8080 check weight 1

backend mqtt_staging
        balance leastconn
        server mqttdev00 mqtt00.internal.example-2.com:1883 check

backend mqtt
        balance leastconn
        server prodmqttdev00 prodmqtt00.internal.example-2.com:1883 check

応答時間

  • haproxy 使用時: 平均 3 秒以上
  • haproxyなし: 平均500～600ミリ秒

アップデート： テスト中に、haproxy 構成を更新して、https で既に構成されているのと同じバックエンドに http を転送するようにしました。この変更により、負荷テスト (http 上の haproxy 経由) は、すべてのリクエストをサーバーに直接送信した負荷テストと同様に実行されました。
したがって、問題 (またはいくつかの問題のうち最大の問題) は haproxy の ssl 構成であると確信しています。パフォーマンスを向上させるために何を変更すればよいかについて、何かアドバイスはありますか?

答え1

すでに AWS を使用している場合は、ELB + AWS Certificate Manager を使用して SSL を実行します。Haproxy を http モードで実行し、問題を無視します。

または、次の Haproxy オプションを試してみましょう。

tune.ssl.cachesize
tune.ssl.lifetime
ciphers
defer-accept
force-tlsv12

また、できれば同じホスト上のバックエンドで静的ページを使用するようにしてください。テスト中のアプリケーションへの影響を制限するためです。

関連情報