AWS 부하 테스트 목적 - 1

부하 테스트의 목적은 무엇인가?

온프라미스 환경에서 부하 테스트 목적은 여러 케이스를 바탕으로 각 시스템의 응답 성능을 예측하고, 부하가 많이 발생할 때는 성능을 개선, 원하는 성능을 도달하는데 필요한 하드웨어를 선정하는데 목적이 있다.

* 하드웨어 구매는 클라우드 환경에서는 사실상 의미가 없어졌다고 볼 수 있다.

 

클라우드 환경에서는 부하가 많이 발생했을 때 시스템 구성을 변경해도 성능이 향상되지 않는 경우가 대부분이다. 그러므로 확장성을 확인하기 위해 부하 테스트를 진행한다.

클라우드 환경에서의 부하 테스트는

• 시스템 확장성 확인
• 시스템 확장성 특성 파악

에 있다고 볼 수 있다. 테스트 전에는 아래 사항들을 확인해 두면 좋다.

• Throughput 레벨: 100rps, 500rps, 1000rps, 2000rps, 5000rps 등 을 처리하기 위한 최적 인프라 구성
• 웹 시스템은 목표치를 넘어 최대 어디까지 Throughput을 처리할 수 있는지에 대한 기준

다시 말하면, Throughput을 지금 보다 높게 하고 싶을 때, 웹 서버만 추가로 올리면 되는지, DB 서버도 같이 올려야 하는지, 반대로 Throughput을 낮추고 싶을 때 어떤 서버를 낮춰야 효과가 있을지 등에 대한 내용을 미리 숙지해 두어야 한다. 또한 시스템 구성 변경이 서비스 중단 없이 가능 한지 유무와 어느 정도 시간이 걸리는지에 대한 부분도 필요하다. 이 부분에 대한 경우는 성능 한계 파악을 위해 꼭 숙지해야 할 부분은 아니다. 하지만 향후 현재 성능 목표 이상의 서비스를 제공해야 할 때 아키텍처 설계를 다시 해야 하는지 아주 중요한 정보가 된다.

5000rps 처리가 가능한 시스템이 애플리케이션 변경에 따라 3000rps로 떨어지는 일은 빈번하게 발생한다. 또한 현재 아키텍처의 한계 성능을 확인하는 도중에 다른 개선 사항을 발견하거나 예상보다 한계가 빨리 나올 수 있다.

 

Throughput?

웹 시스템 각 하위 시스켐이 순차적으로 작업을 처리해 가는 시스템이다. 해당 작업 중 Throughput이 가장 낮은 하위 시스템에 의해 전체 Throughput에 영향을 주게 된다. 이 Throughput이 가장 낮은 하위 시스템을 '병목 구간'이라고 한다. 다시 말하면, 바로 이 병목 구간을 개선하면 치대 Throughput을 높일 수 있다. 추가적으로, 병목 구간  하나를 개선하면 다른 쪽에서 병목 현상이 발견될 수 있다. 병목 구간은 각 하위 시스템 지료를 확인하며 진행하겠지만, 매우 어려운 작업이다.

 

하위 시스템으로 구성된 환경의 Throughput?

* 총 소요 시간(Latency)은 각 구간 시간의 합인 7시간, 시간당 처리량은 (Throughput)는 각 구간의 도착 대수 중 최솟값인 100이라고 볼 수 있다.

시스템 전체 Throughput은 각 하위 시스템 Throughput 중 최솟값이고, latency는 각 하위 시스템의 Latency 합계이다.

 

Latency를 개선?

Latency란 대기 시간을 포함하여 각 하위 시스템 처리 시간의 총합이라고 정의할 수 있다. Latency를 개선하기 위해서는 긴 처리 시간이 필요한 부분에서 순서대로 개선 사항이 없는지 확인해 나가는 방법이 유용하다. 애플리케이션에서 많은 시간이 소요된다면 불필요한 I/O, 데이터베이스 튜닝 부분이 없는지 확인이 필요하다. 처리 시간은 프로파일러 도구를 사용해서 쉽게 파악할 수 있다. Throughput이 한계에 도달하면 대기 시간이 길어지고 Latency도 더불어 길어진다. 예로, 처리 시간이 긴 하위 시스템이 원인처럼 보일지라도, 그 위에 있는 시스템의 Throughput이 원인인 케이스도 많다. Throughput과 Latency는 서로 긴밀한 관계에 있으면, Throughput이 개선되면 Latency도 개선되는 경우가 많다.

 

부하 테스트 유의 사항?

• 부하 테스트 중 특정 하드웨어 리소스가 과부하 상태가 되는 사항은 잘못 돼가고 있는 것이 아니라 좋은 흐름으로 테스트가 진행 중임을 암시한다.
• 많은 요청을 보낸 테스트일 경우 일반적으로 시스템 어느 한 부분이 과부하 상태가 되어 이 부분이 전체 Throughput을 결정하게 된다.

결론은?

• 부하 테스트는 가용성과 확장성이 높은 시스템을 구축하기 위해 수행하는 테스트라고 볼 수 있다.
• 온프라미스는 가용성과 확장성이 높은 시스템을 구축하기 대단히 어렵다.
• 클라우드 디자인 패턴을 활용하면 가용성과 확장성이 높은 시스템을 비교적 간단하게 구축할 수 있다.

* 참고: 가용성이란 시스템이 정상적으로 서비스를 제공할 수 있는 상태를 의미한다. 항상 서비스를 사용할 수 있는 시스템을 가용성이 높은 시스템이라고 말하며 반대로 서비스가 정지되는 시간은 가용성이 낮은 시스템이라고 할 수 있다.

확장성이란 서비스나 여러 프로그램들이 증가하는 요구에 맞게 성능이 향상될 수 있는 정도를 나타낸다. 확장성은 스케일 업과 스케일 아웃이라는 두 가지 형태로 나눌 수 있다. 스케인 업은 단일 하드웨어에 대해 시스템 리소스(CPU, 메모리, 디스크, 네트워크 등)를 추가하거나 기존 하드웨어를 더욱 향상된 것으로 교체하는 작업이다. 스케일 아웃은 서버를 여러 대 추가하여 분산된 환경에서 처리 능력을 향상하는 방법이라고 볼 수 있다.