로드 중인 앱에서 문제가 발생했으며 일부 로드 테스트를 실행한 후 http
port 에서 앱 서버를 직접 로드 테스트할 때 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~600ms 사이
업데이트:
테스트하는 동안 https에 이미 구성된 것과 동일한 백엔드로 http를 전달하도록 haproxy 구성을 업데이트했습니다. 이 변경으로 인해 내 부하 테스트(http의 haproxy를 통해)가 수행되었으며 모든 요청을 서버에 직접 보내는 부하 테스트도 수행되었습니다.
따라서 나는 문제(또는 여러 문제 중 가장 큰 문제)가 haproxy의 SSL 구성이라고 확신합니다. 성능 향상을 위해 변경해야 할 사항에 대한 제안 사항이 있습니까?
답변1
이미 AWS를 사용하고 있으므로 ELB+AWS Certificate Manager를 사용하여 SSL을 수행하십시오. http 모드에서 Haproxy를 실행하고 문제를 무시하십시오.
또는 다음 Haproxy 옵션을 사용하여 게임을 시작하세요.
tune.ssl.cachesize
tune.ssl.lifetime
ciphers
defer-accept
force-tlsv12
또한 백엔드, 바람직하게는 동일한 호스트에서 정적 페이지를 사용해 보십시오. 테스트 중에 애플리케이션에 미치는 영향을 제한합니다.