AWSKRUG 33번째모임에서 첫번째 세션으로 발표를 한 내용입니다.

1. 1
33번째 (2022년 6월 30일)
세션1. 인프라 벤치마크 테스트 잘 해보기
윤서율(SK C&C Cloud Transformation Group)

2. 2
목차
1. 벤치마크란?
2. EKS로 테스트 진행해보기
3. AWS 인스턴스 타입 비교하기

3. 3
벤치마크?
벤치마크(benchmark)는 컴퓨팅에서 특정 오브젝트(하드웨어 또는 소프트웨어 등)에 대해
일반적으로 수많은 표준 테스트와 시도를 수행함으로써 오브젝트의 상대적인 성능 측정을
목적으로 컴퓨터 프로그램을 실행하는 행위이다. - 위키백과
3대 500
1. 벤치마크란?

4. 4
왜?
2Core 4Gib 에서 트래픽이 몰려
장애가 났습니다.
4Core 8Gib로 증설해주세요.
16Core 32Gib로 증설해주세요.
1. 벤치마크란?

5. 5
벤치마크의 주의점
- 충분히 반복 수행 하라
- 환경을 통제하라
- 결과를 맹신하지 마라
1. 벤치마크란?

6. 6
EKS를 사용한 이유
2. EKS로 테스트 진행해보기
EKS의 클러스터 관리는 AWS가 제공하는 eksctl 명령어를 이용해서 간편
구글 검색어: Amazon EKS 시작하기 - eksctl
https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/getting-started-eksctl.html
구글 검색어: AWS CloudFormation이란
https://docs.aws.amazon.com/ko_kr/AWSCloudFormation/latest/UserGuide/Welcome.html
eksctl create cluster, eksctl create nodegroup, eksctl delete nodegroup 등

7. 7
테스트 방법
요청 서버, 응답 서버, 테스트 대상 게이트웨이 서버 각 1개씩 인스턴스를
띄우고 변인의 대상 서버의 노드 Limits을 이용해서 리소스를 제한한다.
ex)
Kubernetes node Limits: cpu 500m memory: 500Mi
Kubernetes node Limits: cpu 1000m memory: 1000Mi
2. EKS로 테스트 진행해보기

8. 8
테스트 환경 – 요청서버와 응답서버
요청 서버: 부하테스터, 오픈 소스 vegeta 커스텀
응답 서버: Go echo web 프레임워크
한 개의 클러스터 안에 두 개의 노드
c5.4xlarge 인스턴스 타입 16Core, 32Gb
Vegeta github: https://github.com/tsenart/vegeta
EC2
요청
EC2
응답
LB
LB
2. EKS로 테스트 진행해보기

9. 9
테스트 환경 – 테스트 대상 게이트 웨이 서버
Kong: https://konghq.com/kong
테스트 대상 gateway 서버: 오픈소스 Kong
한 개의 클러스터 안에 두 개의 노드
테스트 대상: c5.2xlarge 인스턴스 타입 8Core, 16Gb
모니터링 서버: c5.xlarge 인스턴스 타입 4Core, 8Gb
테스트 대상 EC2
2. EKS로 테스트 진행해보기

10. 10
테스트 환경 – 고려하지 않는 부분
Kong: https://konghq.com/kong
아래의 부분들은 항상 동일하거나 영향이 없다고 판단되어 고려하지 않은 부분입니다.
- 테스트에 관련된 모든 서버는 ingress-nginx를 통해 proxy되며 이는 각 서버와 다른 노드에서
동작하고 있는 controller에 의존합니다.
- http 통신에 있어 rate-limiting 등 트래픽 정책은 적용하지 않습니다. 각 트랜잭션을 구분할
수 있는 xid를 가진 post를 사용합니다.
- 모니터링 서버의 처리속도는 충분하다고 간주합니다.
2. EKS로 테스트 진행해보기

11. 11
테스트 결과를 읽는 방법 - 그래프
그래프가 예쁜 상승과 하강 곡선을 보인다면 부하 처리량에 따라 잘 그려진 그래프 입니다.
2. EKS로 테스트 진행해보기

12. 12
테스트 결과를 읽는 방법 - 수치
테스트 지표를 읽기 위하여 필요로 하는 용어는 다음과 같습니다.
- TPS(Transaction Per Second): 초당 트랜잭션의 수
- duration: 요청 시간
- total: 테스트 총 소요시간
- success: 테스트 성공률
2. EKS로 테스트 진행해보기

13. 13
2. EKS로 테스트 진행해보기
테스트1. 500cpu, 500Mi
1000 cpu = 1.0vCPU , 1000 Mi = 1g 를 의미
TPS 1000 - 성공

14. 14
2. EKS로 테스트 진행해보기
테스트1. 500cpu, 500Mi
1000 cpu = 1.0vCPU , 1000 Mi = 1g 를 의미
TPS 2000 - 실패

15. 15
2. EKS로 테스트 진행해보기
테스트2. 1000cpu, 1000Mi
1000 cpu = 1.0vCPU , 1000 Mi = 1g 를 의미
TPS 2000 - 성공

16. 16
2. EKS로 테스트 진행해보기
테스트2. 1000cpu, 1000Mi
1000 cpu = 1.0vCPU , 1000 Mi = 1g 를 의미
TPS 3000 - 실패

17. 17
2. EKS로 테스트 진행해보기
테스트3. 1500cpu, 1500Mi
1000 cpu = 1.0vCPU , 1000 Mi = 1g 를 의미
TPS 3000 - 실패

18. 18
2. EKS로 테스트 진행해보기
테스트3. 1500cpu, 1500Mi
1000 cpu = 1.0vCPU , 1000 Mi = 1g 를 의미
TPS 2500 - 실패

19. 19
2. EKS로 테스트 진행해보기
테스트4. 2000cpu, 2000Mi
1000 cpu = 1.0vCPU , 1000 Mi = 1g 를 의미
TPS 3000 - 성공

20. 20
2. EKS로 테스트 진행해보기
테스트4. 2000cpu, 2000Mi
1000 cpu = 1.0vCPU , 1000 Mi = 1g 를 의미
TPS 4000 - 실패

21. 21
2. EKS로 테스트 진행해보기
결론
테스트를 시작하게된 계기인 리소스에 따른 처리 성능은 비례하면서 증가할까에 대한
의문은 해소되었다.
리소스가 증가함에 따라 성능은 정비례하여 상승되지 않는다.
그리고 결과를 정리하며 발견한점은 가성비 스펙의 구간이 2vCPU 2 GiB 메모리 라는
것을 직접 확인하였다.
하지만..

22. 22
3. AWS 인스턴스 타입 비교하기
다시 해보는 테스트
혹시.. 쿠버네티스가 리소스 제어를 제대로 하지 못하는게 아닐까?
혹시.. 인그레스 컨트롤러가 병목현상을 만들지는 않았을까?
의문이 아직 너무 많다!

23. 23
3. AWS 인스턴스 타입 비교하기
자원에 따른 성능 비교
쿠버네티스를 이용한 리소스 제한으로는 정비례한 상승을 보이지 않았다.
인스턴스 자체의 스펙을 바꿔준다면 어떻게 될까?

24. 24
3. AWS 인스턴스 타입 비교하기
테스트 방법
지난 테스트와 동일한 부하 발생 애플리케이션을 사용하지만,
게이트 웨이 서버 없이 하나의 클러스터 안에서 두 개의 노드를 사용한다.
단순한 테스트이기 때문에 부하가 몰리고 처리되는 딜레이를 재연하기
위해서 각 아래와 같은 상황을 연출한다.
- 요청 보내는 시간 600s(10분)
- 요청 바디사이즈 100Kb
- 응답 바디사이즈 100Kb
- 응답서버에서 딜레이 되는 지연시간 1000ms(1초)

25. 25
3. AWS 인스턴스 타입 비교하기
테스트 환경
요청 서버
지난번과 같이 Go로 작성된 부하테스트 애플리케이션을 이용한다.
사용자로부터 TPS, 테스트시간, 지연시간, 요청 바디사이즈, 응답 바디사이즈
설정값을 받아 테스트를 시작한다.
c5.4xlarge를 사용하여 16vCPU, 32GiB 메모리를 가진다.
응답서버 서버
Go Web 프레임워크로 웹 서버를 올려서 요청을 받는다.
요청 받은 내용의 지연시간을 바탕으로 강제적으로 지연을 발생하고 응답한다.
인스턴스 타입을 테스트마다 변경하여 컴퓨팅 자원에 변화를 주며 진행한다.
특이 사항
순수한 요청서버와 응답서버이기 때문에 모니터링이 불가능하다.

26. 26
3. AWS 인스턴스 타입 비교하기
테스트 결과를 읽는 법
- tps: Transaction Per Second(초당 트랜잭션의 수)
- duration(s): 총 요청 시간
- delay(ms): 지연시간
- bytes size: 요청 바디 사이즈
- Requests total: 총 요청 수 (tps*duration)
- Bytes In: 응답에서 들어온 바디 바이트
- Bytes Out: 요청으로 나간 바디 바이트
- Success: 성공률

27. 27
3. AWS 인스턴스 타입 비교하기
1#. c5.xlarge 4vCPU 8GiB 메모리

28. 28
3. AWS 인스턴스 타입 비교하기
테스트 중반 kubectl top:
결과: 성공
1. c5.xlarge 4vCPU 8GiB 메모리
1-1. TPS 800

29. 29
3. AWS 인스턴스 타입 비교하기
테스트 중반 kubectl top:
결과: 실패
1. c5.xlarge 4vCPU 8GiB 메모리
1-2. TPS 1000

30. 30
3. AWS 인스턴스 타입 비교하기
2#. c5.2xlarge 8vCPU 16GiB 메모리

31. 31
3. AWS 인스턴스 타입 비교하기
테스트 중반 kubectl top:
결과: 성공
2. c5.2xlarge 8vCPU 16GiB 메모리
2-1. TPS 1500

32. 32
3. AWS 인스턴스 타입 비교하기
테스트 중반 kubectl top:
결과: 실패
1. c5.xlarge 4vCPU 8GiB 메모리
2-2. TPS 2000

33. 33
3. AWS 인스턴스 타입 비교하기
3#. c5.4xlarge 16vCPU 32 GiB 메모리

34. 34
3. AWS 인스턴스 타입 비교하기
테스트 중반 kubectl top:
결과: 성공
1. c5.xlarge 4vCPU 8GiB 메모리
3-1. TPS 2000

35. 35
3. AWS 인스턴스 타입 비교하기
테스트 중반 kubectl top:
1. c5.xlarge 4vCPU 8GiB 메모리
3-2. TPS 3000
결과: 대실패 ㅎㅎ..

36. 36
마무리..
3. AWS 인스턴스 타입 비교하기
첫 번째 테스트와 같이 어느정도 예상된 테스트 결과가 보였다.
하지만, 막연히 스펙이 높으면 성능이 좋겠지 하는 추측에서 어느정도 스펙에 따른
성능을 유추할 수 있을 정도가 되었다.

37. 37
감사합니다.
세션 내용 블로그 포스팅
https://cloudev.tistory.com/9
https://cloudev.tistory.com/8
링크드인
https://www.linkedin.com/in/yoon-seoyul/