👀 성능 평가? 왜 하게 되었나?
9월에는 제가 속한 신규 플랫폼 팀에 큰 이벤트가 있었습니다. 바로 이름부터 무시무시한 플랫폼 성능 평가죠.
성능..뭐시기요..?
성능 평가… TPS… 전부 해 본적이 없는 것들이라 막막했지만 또 한편으로는 굉장히 설랬습니다. 새로운 도전이라는 생각에 말이죠. ㅎㅎ
결과적으로 무사히 통과하였고 성대한(?) 파티까지 즐겼기에 후기를 남겨보려고 합니다.
🧐 성능 평가 준비!
요구사항
저희 신규 플랫폼은 거래 데이터를 블록체인 원장에 기록하고 조회하는 기능을 제공하고 있습니다. 성능 평가에서는 다양한 기준이 있었지만, 제가 주로 담당한 부분은 아래 2개의 과제였습니다.
- 블록체인 입력 처리 성능 40TPS 이상
- 블록체인 조회 처리 성능 200TPS 이상
TPS가 엄청나게 높진 않지만 DB 읽기/쓰기와 요청 값 검증, 블록체인 서버 연동 등 다양한 과정을 거치기 때문에 이를 만족시키기 위해서는 갈 길이 멀어 보였죠.
사전 데이터 준비
여기서 입력과 조회 모두 사전에 데이터를 준비해야 했기 때문에, 이를 위한 작업이 필요했습니다. 특히 입력의 경우 API 호출 개수만큼 세금계산서 데이터를 준비해야 했죠.
따라서 저는 개수가 몇개 안되는 유저나 회사 같은 데이터들은 쿼리문으로, 천 단위의 개수를 가진 세금계산서 데이터는 procedure 코드를 작성해 DB에 넣어주었습니다.
인프라 아키텍처
저희는 AWS를 사용하고 있기 때문에, ALB와 인스턴스 그룹을 사용하여 Scale Out을 통해 성능을 개선하기로 했습니다. 물리적인 서버의 개수로 TPS 수치를 점진적으로 올릴 수 있기 때문이었죠.
오토 스케일링은 오버 엔지니어링이라고 판단하여 적용하지 않았습니다.
대략적인 인프라 구조도
위의 구조도는 블록체인 입력을 예를 들어 설명한 것입니다. 블록체인 입력 요청이 들어오면 플랫폼 서버는 DB에서 조회한 값과 요청 값을 통해 권한 검증 등의 비즈니스 로직을 수행합니다. 이후 블록체인 서버에 입력을 요청한 후 응답을 받아 다시 DB에 저장합니다. 꽤나 무거운 작업이죠.
블록체인 조회 요청은 위 구조도에서 4번과 5번 과정인 Set을 제외한 구조라고 생각하시면 됩니다.
성능 측정 툴과 첫 측정 값
TPS를 측정하기 위해서 다양한 툴이 있지만, 저희는 JMeter를 사용했습니다. 가장 많이 사용되고 그 만큼 자료도 많았기 때문이죠.
JMeter를 사용하여 EC2 하나와 RDS 하나를 생성하여 성능을 측정했을 때 아래와 같은 결과를 얻었습니다.
- 블록체인 입력: 26.5 TPS
- 블록체인 조회: 44.4 TPS
입력은 기준 값을 통과했지만 조회 성능은 예상했던 것 보다 턱없이 부족했습니다.
흐으음… 이제 작업 시작이죠!
💪 성능 개선
EC2 Scale Out 결과
AWS Load Balancer로 Scale Out을 구축해 놓았기 때문에 EC2를 간단히 늘리면서 성능을 측정해 보았습니다.
EC2를 두개로 올렸을 때 약 2배, 3개로 올렸을 때 약 3배의 성능 향상을 보여줬죠.
따라서 EC2를 총 5개 이상으로 올리면(45 x 5 = 225) 될 거라는 안일한 생각을 하게 되었습니다. (슬픈 예감은 틀린적이 없..ㄷr..)
EC2 성능 올리기
Scale Out의 희소식을 팀에 공유하고 저는 EC2 하나의 TPS를 올리는 방법을 고민해 보았습니다. 찾아보니 Thread Pool과 Connection Pool을 적절히 설정해 주면 성능을 올릴 수 있다는 글을 보게 되었죠.
해당 작업과 RDS의 Scale Up 등을 통해서 EC2 하나, RDS 하나의 성능을 아래와 같이 끌어올릴 수 있었습니다.
- 블록체인 입력: 26.5 TPS -> 43.0 TPS
- 블록체인 조회: 44.4 TPS -> 109.5 TPS
자세한건 다음 포스트에서 다루도록 하겠습니다 :)
🤯 이제 마무리만 지으면 될…줄 알았지?
준비는 끝났다고 생각하고 리허설 전에 EC2 Scale Out을 통해 TPS 성능을 충족시키려고 했습니다.
그러나… EC2를 3개, 5개, …, 8개까지.. 아무리 올려도 200TPS 근처에서 올라가질 않았습니다. 조회 성능 기준인 200TPS를 안정적으로 넘어서지 못하는 것이죠.
으아아아악
로드 밸런서도 확인해 보고, RDS나 EC2의 로그도 확인해 봤지만 도저히 원인을 찾을 수 없었습니다.
찾았다! 병목 현상의 원인
다양한 삽질 끝에 혹시..? 라는 생각에 블록체인 서버의 TPS를 확인해 보았고 200TPS가 나왔습니다. 블록체인 서버에서 병목현상이 발생하고 있었던 것이죠. (분명 블록체인 서버 문서에는 훨씬 높은 TPS를 지원한다고 했었는데 말입니다?)
병목 현상 구조도
블록체인과의 통신 과정이 동기식으로 동작하고 있었기 때문에 블록체인 서버의 TPS가 낮아지면 플랫폼 서버의 TPS도 낮아지게 되었던 것이죠.
이를 해결하기 위해서 블록체인 서버에 대한 조회 응답값을 캐싱하는 방법이 있었고 팀장님과 얘기한 후 이를 적용하기로 했습니다.
캐싱을 적용하니 당연히 TPS는 기존 값을 훌쩍 넘어서게 되었고, 덕분에 성능 평가를 성공적으로 마칠 수 있었습니다.
🥳 후기
성능 평가 결과를 받고 아웃백에서 축하 파티를 했습니다. 점심 회식은 못 참지..
Jmeter도 처음 해보고 Thread Pool 등등 다양한 공부와 삽질도 많이 해서 덕분에 크게 성장을 했다고 생각합니다.
다음 포스팅에서는 위에서 예고했던 대로 EC2의 성능을 올리기 위해 적용한 방법들에 대해 다루도록 하겠습니다. :)
To Be Continued…