[Issuefy] Jmeter를 사용한 성능 테스트 및 스케일링 분석

Issuefy 아키텍처

Issuefy는 AWS의 오토 스케일링 그룹과 ECS를 활용하여 트래픽 변화에 유연하게 대응할 수 있는 아키텍처를 채택했습니다. CPU 사용량이 70%를 초과하면 자동으로 스케일 아웃되어 추가 트래픽을 처리하고, 3분 동안 30% 이하로 유지되면 불필요한 리소스 낭비를 방지하기 위해 스케일 인됩니다. 최대 3개의 인스턴스까지 확장 가능하도록 설정하여 급격한 트래픽 증가에도 대비하고 있습니다.

 

 

성능 측정과 트래픽 처리

그러던 중 하나의 의문이 생겼습니다.

우리 서버는 과연 초당 몇 개의 요청(TPS)을 감당할 수 있을까?

 

처음에는 정확한 데이터 없이 CPU 사용량이 70%를 넘으면 스케일 아웃이 트리거되도록 설정했지만, 실제로 몇 개의 요청이 발생해야 이 조건을 충족하는지는 명확하지 않았습니다.

또한, 3개의 인스턴스로 스케일 아웃되었을 때 얼마나 많은 TPS를 처리할 수 있을지도 확인되지 않았습니다.

 

이러한 이유로 보다 구체적인 성능 측정을 위해 테스트의 필요성을 느꼈고, 이에 다음과 같은 목표를 세웠습니다.

• CPU 사용량 70%는 몇 TPS일 때 발생하는가?
• t3a.small 단일 인스턴스로 처리할 수 있는 최대 TPS는 얼마인가?
• 스케일 아웃이 최대치에 도달했을 때, 얼마나 많은 TPS를 감당할 수 있는가?

 

테스트 계획

JMeter를 활용한 성능 테스트를 진행하며 몇 가지 주요 변수를 설정했습니다.

우선, 테스트할 API를 선정해야 했습니다. 모든 API를 테스트하는 것이 이상적이었으나, GitHub API에 요청을 보내는 로직이 포함된 부분이 많아 모든 API에 대해 테스트를 진행하기에는 무리가 있었습니다. 그래서 가장 기본적인 기능인 구독한 리포지토리를 가져오는 API를 대상으로 테스트를 진행하기로 했습니다.

• 스레드 수: 동시에 요청을 보낼 사용자의 수를 500개로 설정했습니다.
• 램프업 타임: 20초로 설정하여 스레드가 점진적으로 증가하면서 서버에 부하를 주도록 했습니다. 이는 실제 트래픽이 급격히 증가하기보다는 서서히 늘어나는 상황을 반영한 설정입니다.
• 루프 카운트: 각 스레드가 10번의 요청을 보내도록 설정했습니다. 이는 500명의 사용자가 Issuefy 서비스에 접속해 알림을 확인하고, 즐겨찾기 한 리포지토리를 방문해 이슈를 여러 개 본다는 시나리오를 기반으로 한 설정입니다.

이 설정에 따라 500개의 스레드가 20초 동안 분산 실행되며, 각 스레드는 총 10번의 요청을 보냅니다. 결과적으로 최대 초당 250개의 요청(TPS)이 발생할 것으로 예상했습니다. 서버가 이 부하를 견딜 수 있다면 TPS는 250에 근접할 것이고, 그렇지 않다면 예상보다 낮은 수치가 나올 것으로 보았습니다.

 

첫 번째 테스트 결과

첫 번째 테스트 결과, 서버는 초당 약 250회의 요청을 처리했고 CPU 사용량은 84%에 도달했습니다. TPS는 247로 예상한 250과 매우 근접한 결과를 얻었습니다. 그러나 테스트 시간이 20초로 짧아 스케일 아웃을 유발할 만큼의 시간이 충분하지 않았으며, 짧은 시간에 부하가 집중된 탓에 더 장기적인 부하 테스트가 필요하다는 결론을 내렸습니다.

두 번째 테스트 계획

첫 번째 테스트의 한계를 보완하기 위해 두 번째 테스트에서는 설정을 변경했습니다. 이번에는 더 긴 시간 동안 부하를 주며 점진적으로 스레드가 증가하는 방식으로 테스트를 구성했습니다.

• 스레드 수: 450개
• 램프업 타임: 300초
• 루프 카운트: 무한
• 스레드 지속시간: 420초

450개의 스레드를 300초 동안 분산 실행하여 초당 약 1.5개의 스레드가 점진적으로 시작되도록 설정했습니다. 각 스레드는 무한 루프 내에서 가능한 한 빠르게 요청을 전송하며, 대략 1초에 한 번씩 요청을 보낼 것이라 예상했습니다. 이 설정을 통해 부하를 천천히, 그러나 장시간 서버에 가해, 최대 TPS를 파악하고자 했습니다.

 

두 번째 테스트 결과

두 번째 테스트 결과, 총 약 19,000개의 요청이 발생했습니다. 그러나 램프업 시간이 끝나기도 전에 스레드 수가 100을 넘자 CPU 사용량이 93%에 도달했고, 이 시점에서 TPS는 277까지 증가했습니다. CPU 사용량이 한계에 도달한 것을 확인한 후 테스트를 중단했습니다. 이를 통해 단일 인스턴스의 성능 한계에 거의 도달했으며, 이론적으로 TPS가 300에 가까워질 가능성은 있지만, 과부하로 인해 그전에 인스턴스가 문제가 발생할 수 있다고 판단했습니다.

 

최종 테스트

최종 테스트는 다음과 같이 설정했습니다.

• 스레드 수: 60개
• 램프업 타임: 300초
• 루프 카운트: 무한
• 스레드 지속시간: 1500초

60개의 스레드를 300초 동안 점진적으로 실행하고, 각 스레드는 무한 루프에서 지속적으로 요청을 보내도록 했습니다. 최대 부하에 도달한 후 1500초 동안 트래픽을 지속적으로 발생시키며, 스케일 아웃 기능을 테스트했습니다. 오토스케일링은 정상적으로 이루어졌고, 각 인스턴스의 워밍업 시간과 함께 300초 동안 모니터링 후 스케일 인과 아웃이 자동으로 이루어졌습니다.

 

 

첫 번째 스케일 아웃은 TPS가 230에 도달했을 때 시작되었고, TPS 420에서 두 번째 스케일 아웃이 발생했습니다. 추가적인 스케일 아웃 용량이 있고, 더 많은 부하가 있었다면 TPS 620에서 추가 스케일 아웃이 발생했을 것으로 예상됩니다. 따라서 CPU 사용량 70%는 대략 초당 200~230개의 요청에서 발생하는 것으로 확인되었습니다.

 

 

이론적으로 인스턴스 하나당 TPS는 약 280이며, 최대 300까지 도달할 수 있습니다. 3개의 인스턴스가 스케일 아웃되면 TPS는 900에 근접해야 했으나, 실제로는 최대 TPS 374가 기록되었습니다. 이는 스케일 아웃 상황에서 충분한 부하를 주지 못했기 때문으로 보입니다. 스케일 아웃된 인스턴스들의 능력을 최대한 활용할 만큼의 추가적인 부하를 주었다면, 더 높은 TPS를 기록했을 것입니다. 즉, 3개의 인스턴스가 모두 최대 성능으로 작동할 만큼의 트래픽을 생성하지 못한 것이 TPS가 예상보다 낮게 나온 원인으로 판단됩니다. 실제 부하 테스트 종료 직전에도 TPS가 지속적으로 상승하고 있었는데, 더 많은 부하와 테스트 시간을 부여했다면 TPS 800까지는 충분히 달성할 수 있었을 것이라고 생각합니다.

 

인스턴스 최대 스케일 아웃 시 RDS의 CPU 사용량이 77%까지 증가했습니다. 이러한 부분이 현재 TPS에도 영향을 미치거나 병목 지점일 수도 있다는 생각을 했습니다. 따라서 더 많은 부하가 발생할 경우 RDS의 샤딩을 고려하거나, 캐싱을 적용할 필요가 있다고 판단했습니다.

결론

 

• CPU 사용량 70%는 약 200~230 TPS에서 발생하는 것으로 측정되었습니다.
• t3a.small 단일 인스턴스의 최대 처리 가능 TPS는 280~300 사이로 측정되었습니다.
• 최대 스케일 아웃(3개 인스턴스) 시 이론상 900 TPS까지 처리 가능할 것으로 예상되었습니다. 그러나 실제 테스트에서는 부하를 최대로 주지 못해 최대 374 TPS를 기록했습니다. 더 많은 부하와 테스트 시간을 부여했다면 더 높은 TPS를 달성했을 것으로 생각됩니다. 다만 RDS 부하도 고려한다면 실제 최대 TPS는 500 정도로 예상됩니다.

 

현재 상태에서 3개의 인스턴스로 스케일 아웃을 했을 때, 각 인스턴스의 CPU 부하가 50~60%에 머물러 있습니다. 이는 스케일 아웃의 결과가 효율적이지 않다는 것을 보여줍니다.

 

이러한 상황에서는 스케일 아웃보다는 스케일 업을 통해서 단일 인스턴스에서 더 많은 트래픽을 처리할 수 있게 하는 게 더 효율적이라고 생각합니다. 하지만 이는 실제로 인스턴스를 변경해 성능 테스트와 비용 분석을 통해 최적의 인스턴스 유형을 찾아야 하므로 시간이 필요할 것 같습니다.

 

또한, 부하 테스트중 메모리 사용량은 크게 증가하지 않았는데, 이는 현재 테스트한 API가 주로 단순 쿼리 조회 및 응답을 다루기 때문입니다. 향후 다양한 API를 추가하여 테스트하면서 메모리 사용량도 지속적으로 모니터링할 예정입니다.