Application Load Balancer의 높은 대기 시간 문제를 해결하려면 어떻게 해야 합니까?

4분 분량
0

Application Load Balancer 뒤에 등록된 대상을 통해 실행되는 웹 애플리케이션에 액세스하려고 하면 대기 시간이 길어지고 시간 초과가 발생합니다. 이러한 문제를 해결하려면 어떻게 해야 합니까?

간략한 설명

Application Load Balancer에서 지연 시간이 길어질 수 있는 원인은 다음과 같습니다.

  • 네트워크 연결 문제
  • 백엔드 인스턴스의 메모리(RAM) 사용량 과다
  • 백엔드 인스턴스의 높은 CPU 사용률
  • 백엔드 인스턴스의 부적절한 웹 서버 구성
  • 외부 데이터베이스 또는 Amazon Simple Storage Service(Amazon S3) 버킷 같은 백엔드 인스턴스에서 실행되는 웹 애플리케이션의 종속성 문제

해결 방법

1.    Application Load Balancer 문제 해결의 문제 해결 단계를 참조하여 네트워크 연결 문제를 확인합니다.

2.    curl 도구를 사용하여 첫 번째 바이트 응답을 측정하고 느린 DNS 확인이 대기 시간에 영향을 주는지 확인합니다.

curl -kso /dev/null https://www.example.com -w "==============\n\n 
| dnslookup: %{time_namelookup}\n 
| connect: %{time_connect}\n 
| appconnect: %{time_appconnect}\n 
| pretransfer: %{time_pretransfer}\n 
| starttransfer: %{time_starttransfer}\n 
| total: %{time_total}\n 
| size: %{size_download}\n 
| HTTPCode=%{http_code}\n\n"

출력 예시:

 | dnslookup: 0.005330
 | connect: 0.006682
 | appconnect: 0.026540
 | pretransfer: 0.026636
 | starttransfer: 0.076980
 | total: 0.077111
 | size: 12130
 | HTTPCode=200

Application Load Balancer를 통해 이러한 테스트를 수행합니다. 그런 다음, Application Load Balancer를 대상으로 우회하면서 테스트를 수행합니다. 이 방법은 지연 시간을 유발하는 구성 요소를 격리하는 데 도움이 됩니다. curl 기능에 대한 자세한 내용은 curl 기능 사용 방법을 참조하십시오.

3.    Application Load Balancer에 대한 Amazon CloudWatch TargetResponseTime 지표의 평균 통계를 확인합니다. 이 값이 크면 백엔드 인스턴스 또는 애플리케이션 종속 서버에 문제가 있는 것입니다.

4.    Application Load Balancer의 액세스 로그 항목을 확인하여 지연 시간이 긴 백엔드 인스턴스를 결정합니다. target_processing_time을 살펴보면서 지연 시간 문제가 있는 백엔드 인스턴스를 찾습니다. 또한 request_processing_timeresponse_processing_time 필드를 검토하여 Application Load Balancer에 문제가 있는지 확인합니다.

5.    백엔드 인스턴스의 CloudWatch CPU 사용률 지표를 확인합니다. CPU 사용률이 높거나 CPU 사용률이 급증하는 지점을 찾아봅니다. CPU 사용률이 높은 경우, 인스턴스를 더 큰 인스턴스 유형으로 업그레이드해 보십시오.

6.    백엔드 인스턴스의 Apache 프로세스를 검토하여 메모리 문제가 있는지 확인합니다.

명령 예:

watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"

출력 예:

Every 1.0s: echo –n 'Apache Processes: ' && ps –C apache2 –no-
headers | wc -1 && free –m
Apache Processes: 27
          total     used     free     shared     buffers     cached
Mem:      8204      7445     758      0          385         4567
-/+ buffers/cache:  2402     5801
Swap:     16383     189      16194

7.    백엔드 인스턴스의 웹 서버에 대한 MaxClient 설정을 확인합니다. 이 설정은 인스턴스가 처리할 수 있는 동시 요청 수를 정의합니다. 메모리 및 CPU 사용률이 적절한데 지연 시간이 긴 인스턴스의 경우, MaxClient 값을 늘려 보십시오.

Apache(httpd)에 의해 생성되는 프로세스 수와 MaxClient 설정의 프로세스 수를 비교해 봅니다. Apache 프로세스 수가 MaxClient 값에 도달하는 경우가 많다면 이 값을 늘려 보십시오.

[root@ip-192.0.2.0 conf]# ps aux | grep httpd | wc -l 15
<IfModule prefork.c>
StartServers         10
MinSpareServers      5
MaxSpareServers      10
ServerLimit          15
MaxClients           15
MaxRequestsPerChild  4000
</IfModule>

8.    지연 시간 문제를 유발하는 것으로 생각되는 백엔드 인스턴스의 종속성을 점검합니다. 종속성에는 공유 데이터베이스 또는 외부 리소스(예: Amazon S3 버킷)가 포함될 수 있습니다. 종속성에는 NAT(네트워크 주소 변환) 인스턴스, 원격 웹 서비스 또는 프록시 서버와 같은 외부 리소스 연결도 포함될 수 있습니다.

9.    다음 Linux 도구를 사용하여 서버의 성능 병목 현상을 식별합니다.

uptime - 실행 대기 중인 태스크(프로세스) 수를 결정하는 데 도움이 되는 로드 평균을 표시합니다. Linux 시스템에서 이 수치에는 CPU에서 실행되기를 기다리는 프로세스와 중단 불가능한 I/O(일반적으로 디스크 I/O)에서 차단된 프로세스가 포함됩니다. 이 데이터는 다른 도구를 사용하여 해석해야 하는 리소스 로드(또는 수요)에 대한 높은 수준의 정보를 제공합니다. 간략히 보여줍니다. Linux 로드 평균이 증가하면 리소스 수요가 높아집니다. 수요가 많은 리소스를 확인하려면 다른 지표를 사용해야 합니다. 예를 들어 CPU의 경우 mpstat -P ALL 1을 사용하여 CPU별 사용률을 측정하거나 top 또는 pidstat 1을 사용하여 프로세스별 CPU 사용률을 측정할 수 있습니다.

mpstat -P ALL 1 - 불균형을 확인하는 데 사용할 수 있는 CPU당 CPU 시간 분석을 표시합니다. 단일 핫 CPU는 단일 스레드 애플리케이션의 증거일 수 있습니다.

pidstat 1 - 프로세스별 CPU 사용률을 표시하고 시간에 따른 패턴을 보는 데 유용한 롤링 요약을 인쇄합니다.

dmesg | tail - 마지막 10개의 시스템 메시지(있는 경우)를 표시합니다. 성능 문제를 일으킬 수 있는 오류를 찾습니다.

iostat -xz 1 - 블록 디바이스(디스크)에 적용된 워크로드와 결과 성능을 표시합니다.

free -m - 사용 가능한 메모리의 양을 표시합니다. 이 숫자의 크기가 0에 가까워지지 않아 디스크 I/O가 높아지고(iostat를사용하여 확인) 성능이 저하될 수 있습니다.

sar -n DEV 1 - 네트워크 인터페이스 처리량(rxkB/s 및 txkB/s)을 워크로드 측정값으로 표시합니다. 한계에 도달했는지 확인하십시오.

sar -n TCP,ETCP 1 - active/s(로컬에서 시작된 TCP 연결 수), passive/s(초당 원격으로 시작된 TCP 연결 수) 및 retrans/s(초당 TCP 재전송 횟수)를 포함한 주요 TCP 지표를 표시합니다.

iftop - 서버와 가장 많은 대역폭을 소비하는 원격 IP 주소 간의 연결을 표시합니다. n iftop는 Red Hat 및 Debian 기반 배포에서 같은 이름의 패키지로 제공됩니다. 그러나 Red Hat에 기반한 배포의 경우 서드 파티 저장소에서 n iftop를 찾을 수 있습니다.


AWS 공식
AWS 공식업데이트됨 2년 전