Devops Day 64 (6.7) 성능 테스트_병목 찾기

Throughput 개선
고속도로의 예를 다시 빌려, 다음과 같이 세 도시를 연결하는 두 개의 고속도로 중 대구-부산 간 고속도로가 병목을 일으키고 있다고 가정합시다.

서울-부산 사이의 Throughput은 최소값인, 200대/시간에 불과합니다. 이런 경우에는 도로 확장 공사를 통해 병목을 해결합니다. 확장 공사를 마친 대구-부산 간 고속도로의 Throughput이 800대/시간으로 개선되었습니다.

병목이 아닌 구간(서울-대구)을 개선하는 것은, 전체의 Throughput을 개선하는 데에 전혀 도움이 되지 않습니다. 도리어 대구-부산 간의 정체가 늘어나 Throughput이 감소할 수도 있습니다. 따라서, Throughput 개선을 위해서는 병목 구간이 어디인가를 먼저 파악하는 것이 가장 중요합니다.

Latency 개선
애플리케이션 개선
Latency의 개선은 개발된 애플리케이션을 개선하는 것으로 시작합니다. 애플리케이션 성능 최적화는 현상을 파악(APM, Application Performance Monitoring)하는 것으로 시작하며, 알고리즘 개선, I/O 최소화 등의 개선 방안이 뒤따릅니다.

(애플리케이션 성능 향상을 위한) 하위 시스템의 확장
한편 앞서 고속도로의 예를 살펴보면, Throughput의 개선이 Latency의 개선으로 이어진 것을 확인할 수 있습니다. 이는 곧 "대기 시간"에 문제가 있다는 의미입니다. 만일 애플리케이션이 실행 환경(하위 시스템)의 성능을 최대한 활용할 수 있다면, 하위 시스템의 확장에 따라 Throughput도 개선되며, 대기 시간도 줄어듭니다.

 

응답 성능의 병목 원인과 대책
서비스를 시작한 후 발생할 수 있는 문제 시나리오는 다양합니다. 이러한 문제는 응답 성능의 병목을 가져다줍니다. 아래 제시된 시나리오는 매우 일반적이며, 부하 테스트를 통해 응답 성능을 예측할 수 있습니다. 애플리케이션 수준에서의 대책을 온전히 이해하기는 어렵지만, 주요 키워드를 학습하여 개발자에게 솔루션을 제공할 수는 있어야 합니다.

1. 많은 사용자의 서비스 등록

2. 많은 데이터의 저장

- 1,2번과 같은 경우 DB에 데이터가 증가합니다. secondary 복제본 등을 이용해 읽기/쓰기를 분리하거나, 검색에 최적화된 인덱스 사용을 고려할 수 있습니다.

3. 단기간 동안의 사용자 요청 증가(peak traffic)

- Auto Scaling이 해결책이 될 수 있습니다. 다만 버스트 성능에 대해 이해해야 합니다.

4. 배치 작업을 진행하는 데이터베이스

- DB가 주기적으로 스냅샷을 만들거나, 데이터 일관성을 위해 레플리카와의 sync 과정을 진행하는 등의 배치 작업이 이루어질 경우, primary DB는 성능 저하가 발생할 수 있습니다. 이때 사용자들의 요청과 맞물려 서비스 수준을 맞추기 어려울 수 있습니다.

5. 많은 양의 로그 수집 처리

- 애플리케이션이 잘 작동할 때에는 로그를 많이 남기지 않지만, 애플리케이션에 문제가 발생하면 추적을 위해 많은 로그를 남깁니다. 다만 이러한 상황이 반복적으로 진행될 경우, 에러 로그 수집 그 자체가 애플리케이션 병목을 일으킬 수 있습니다.

6. 시스템 재시작 후의 캐시 초기화

- 큰 문제를 발생시키는 것은 아니지만, 캐시가 초기화되면서 시스템으로 직접적인 요청 횟수가 증가할 수 있습니다.

 

주요 병목 구간과 부하 테스트 시 고려해야 할 부분
병목 구간을 확인하는 것은 부하 테스트의 주요 목적이면서, 또한 좋은 부하 테스트를 만드는 기본입니다. 시스템에서 문제가 발생할 수 있는 부분을 다이어그램으로 표현하면 다음과 같습니다.

 

발표 :
AWS에서는 인스턴스나 볼륨에 대해서 버스트 기능을 제공합니다. 이는 평소에 사용하지 않을 때의 성능을 모아두고, 부하가 발생할 경우 일시적으로 성능을 올리는 기능입니다. 이것이 어떤 메커니즘으로 작동하는지 연구하세요.

기존 Amazon EC2 인스턴스 유형은 고정된 CPU 리소스를 제공하는 반면, 성능 순간 확장 가능 인스턴스는 기본 수준의 CPU 사용률을 제공하면서 기본 수준 이상으로 CPU 사용률을 버스트하는 기능을 제공합니다. 이렇게 하면 기준 CPU와 추가 버스트 CPU 사용량에 대해서만 비용을 지불하면 되므로 컴퓨팅 비용이 절감됩니다. 기준 사용률과 버스트 기능은 CPU 크레딧에 의해 좌우됩니다. 성능 순간 확장 가능 인스턴스는 CPU 사용량에 대해 크레딧을 사용하는 유일한 인스턴스 유형입니다.

각 버스트 가능 성능 인스턴스는 CPU 기준 미만으로 유지되면 지속적으로 크레딧을 얻고, 기준선 이상으로 버스트될 때 크레딧을 지속적으로 소비합니다. 적립되거나 소비되는 크레딧 금액은 인스턴스의 CPU 사용률에 따라 달라집니다.

 

- CPU 사용률이 기준 미만인 경우 적립되는 크레딧은 소비되는 크레딧보다 많습니다.

- CPU 사용률이 기준과 같을 경우 적립되는 크레딧은 소비되는 크레딧과 같습니다.

- CPU 사용률이 기준을 초과할 경우 소비되는 크레딧이 적립되는 크레딧보다 많습니다.

 

적립되는 크레딧이 소비되는 크레딧보다 많을 경우의 차액을 획득한 크레딧이라고 하며, 이를 나중에 기준 CPU 사용률 이상으로 버스트하는 데 사용할 수 있습니다.

CPU 사용률

CPU 사용률은 인스턴스에서 현재 사용 중인 할당된 EC2 컴퓨팅 유닛의 비율(%)입니다. 이 지표는 인스턴스에서 사용되고 있는 할당된 CPU 사이클의 비율을 측정합니다. CPU 사용률 CloudWatch 지표는 코어당 CPU 사용량이 아니라 인스턴스당 CPU 사용량을 나타냅니다.

CPU 크레딧

vCPU 시간의 단위입니다.

CPU 크레딧 1개 = vCPU 1개 * 100% 사용률 * 1분

CPU 크레딧 1개 = vCPU 1개 * 50% 사용률 * 2분

CPU 크레딧 1개 = vCPU 2개 * 25% 사용률 * 2분

기준 사용률

기준 사용률은 획득하는 CPU 크레딧 수가 사용 중인 CPU 크레딧 수와 일치할 때 순 크레딧 밸런스 0에서 CPU를 사용할 수 있는 수준입니다.

획득 크레딧

인스턴스가 실행 중일 때 지속적으로 적립되는 크레딧입니다.

시간당 적립되는 크레딧 수 = 기준 사용률(%) * vCPU 수 * 60분

소비 또는 사용되는 크레딧

인스턴스가 실행 중일 때 지속적으로 소비되는 크레딧입니다.

분당 소비되는 CPU 크레딧 = vCPU 수 * CPU 사용률 * 1분

크레딧 누적 한도

인스턴스 크기에 따라 다르지만 일반적으로 24시간 동안 적립되는 최대 크레딧 수와 같습니다.

스탠다드 모드

크레딧 구성 모드로, 크레딧 잔액에 적립된 크레딧을 사용하여 인스턴스를 기준 이상으로 버스트할 수 있습니다.

 

무제한 모드

크레딧 구성 모드로, 필요할 때마다 원하는 기간 동안 높은 CPU 사용률을 유지하여 인스턴스를 기준 이상으로 버스트할 수 있습니다.

EC2 인스턴스 유형별로 CPU 크렛딧 획득률이 다릅니다.

CPU 크레딧 누적 한도

실행 중인 인스턴스에서 획득한 크레딧은 만료되지 않습니다. 하지만 인스턴스가 누적할 수 있는 획득 크레딧 수에는 한도가 있습니다. 한도는 CPU 크레딧 밸런스 한도에 따라 결정됩니다. 한도에 도달한 후에 새로 획득하는 크레딧은 다음 이미지와 같이 모두 삭제됩니다.

기준 사용률

기준 사용률은 획득하는 CPU 크레딧 수가 사용 중인 CPU 크레딧 수와 일치할 때 순 크레딧 밸런스 0에서 CPU를 사용할 수 있는 수준입니다. 기준 사용률을 기준이라고도 합니다.

 

기준 사용률은 vCPU 사용률의 백분율로 표시되며 다음과 같이 계산됩니다.

(number of credits earned/number of vCPUs)/60 minutes = % baseline utilization

EBS는 gp2/sc1/st1 타입에 대해 버스팅 모드를 지원한다. EBS의 경우에는 성능 기준이 각각 gp2는 IOPS, sc1/st1는 처리량에 따라 결정된다. gp2는 생성된 볼륨 크기에 비례하여 IOPS가 결정되고 부족한 부분은 크레딧을 사용하므로, 만약 볼륨의 크기는 작은데 IOPS는 높다면 크레딧이 소진될 수 있으므로, IOPS를 프로비저닝하여 사용하는 io1방식을 사용하는 것이 좋다.

 

출처 : https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html
출처 : https://sarc.io/index.php/aws/2028-aws-bursting-credit

버스트 가능 성능 인스턴스에 대한 주요 개념 및 정의 - Amazon Elastic Compute Cloud

AWS Bursting과 Credit에 대한 이해