고객이 Classic Load Balancer에 등록된 Amazon EC2(Amazon Elastic Compute Cloud) 인스턴스에서 실행되는 웹 애플리케이션에 연결할 때 지연 시간이 길어집니다. 이 ELB(Elastic Load Balancing) 지연 시간 문제를 해결하려면 어떻게 해야 합니까?

Classic Load Balancer에서 지연 시간이 길어질 수 있는 이유는 다음과 같습니다.

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

1.    Classic Load Balancer의 네트워크 연결 문제를 해결합니다.  

2.    사용 사례에 맞게 Classic Load Balancer를 올바르게 구성했는지 확인합니다.

3.    Classic Load Balancer에 대한 액세스 로그를 확인하여 지연 시간이 긴 백엔드 인스턴스를 파악합니다. backend_processing_time을 살펴보고 지연 시간 문제가 있는 백엔드 인스턴스를 찾습니다.

백엔드 인스턴스의 웹 애플리케이션 서버의 지연 시간이 길어졌는지 확인하려면 curl을 사용하여 첫 번째 바이트 응답을 측정합니다. 예:

[ec2-user@ip-192.0.2.0 ~]$ for X in `seq 6`; do curl -Ik -w "HTTPCode=%{http_code} TotalTime=%{time_total}\n" http://www.example.com/ -so /dev/null; done

High Latency sample output:
HTTPCode=200 TotalTime=2.452
HTTPCode=200 TotalTime=1.035

Low latency sample output:
HTTPCode=200 TotalTime=0.515
HTTPCode=200 TotalTime=0.013

4.    Classic Load Balancer에 대한 CloudWatch Latency 지표Average 통계를 확인합니다. 값이 높으면 일반적으로 ELB 대신 백엔드 인스턴스 또는 애플리케이션 종속성 서버에 문제가 있는 것입니다. 

5.    Latency 지표의 Maximum 통계를 확인합니다. 값이 유휴 제한 시간 값과 일치하거나 초과할 경우 요청이 시간 초과되는 것일 수 있습니다. 이 문제로 인해 클라이언트에 HTTP 504 오류가 발생합니다.

6.    Latency 지표에서 패턴을 확인합니다. 지표가 일정한 간격으로 또는 패턴으로 급증하는 경우, 이는 백엔드 인스턴스의 성능 문제를 나타내는 것일 수 있습니다. 이 문제는 예약된 작업의 오버헤드로 인해 발생할 수 있습니다.

7.    ELB의 CloudWatch SurgeQueueLength 지표를 확인합니다. Classic Load Balancer에 대한 요청이 최대값(1024)을 초과하면 요청이 거부되고 로드 밸런서에서 HTTP 503 오류가 생성됩니다. SpilloverCount 지표의 합계 통계는 거부된 총 요청 수를 측정합니다. 자세한 내용은 Elastic Load Balancing 용량 문제는 어떻게 해결합니까?를 참조하십시오.

8.    백엔드 인스턴스의 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

9.    백엔드 인스턴스의 CloudWatch CPUUtilization 지표를 확인합니다. CPU 사용률이 높거나 CPU 사용률이 급증한 부분이 있는지 살펴봅니다. CPU 사용률이 높으면 인스턴스를 더 큰 인스턴스 유형으로 업그레이드할 것을 고려합니다.

10.    백엔드 인스턴스의 웹 서버에 대한 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>

11.    지연 시간 문제를 일으킬 수 있는 백엔드 인스턴스의 종속성을 확인합니다. 여기에는 공유 데이터베이스, 외부 리소스(예: S3 버킷), NAT(네트워크 주소 변환) 인스턴스와 같은 외부 리소스 연결, 원격 웹 서비스 및 프록시 서버가 포함되지만 이에 국한되지 않습니다.


페이지 내용이 도움이 되었습니까? | 아니요

AWS 지원 지식 센터로 돌아가기

도움이 필요하십니까? AWS 지원 센터를 방문하십시오.

게시 날짜: 2017년 10월 10일

업데이트 날짜: 2018년 12월 18일