Test methods for improved availability and performance

• Fault Tolerance
• Availability
  • SPOF
  • 다중화
  • 성능에 대한 관점
• 부하
  • 사용자
  • TPS
  • Performance vs Scabaility
  • Time
• Smoke Test
• Load Test
• Stress Test
• 테스트 도구
• 주의할 점
• 테스트 계획하기
• Links

Fault Tolerance

• 서비스의 안정성이 완벽할 수 없으며, 일정 부분 장애를 허용할 수 밖에 없습니다. 다만, 심각한 문제에도 어느 정도의 장애내성을 가진 서비스를 운영하는냐가 관건입니다.
• 고가용성, 무중단 서비스를 지향하는데 있어 핵심은 사용자가 납득할만한 수준의 가용성을 유지하되, 배포 사이클을 유지하는 것입니다.
• 서비스를 배포하기에 앞서 예상되는 상황을 테스트하여, 현재 시스템이 어느 정도의 부하를 견딜 수 있는지 확인하고. 한계치에서 병목이 생기는 지점을 파악하고 장애 조치와 복구를 사전에 계획해둘 필요가 있습니다.

Availability

가용성이란 시스템이 서비스를 정상적으로 제공할 수 있는 상태를 말합니다. uptime 등의 지표로 측정되기도 하며, IDC / 네트워크 / 하드웨어 / 소프트웨어 등의 장애 혹은 점검기간, 그리고 높은 부하에 따른 타임아웃 등으로 서비스를 이용할 수 없을 경우 가용성이 낮아집니다.

가용성을 높이기 위해 단일 장애점(SPOF)를 없애고, 확장성 있는 서비스를 만들어야 합니다.

SPOF

• 서버 한대로 운영할 경우
  • 서버 장비가 장애날 경우, 애플리케이션 서버가 장애날 경우, DB 서버가 장애날 경우 등의 상황에 서비스가 중단됩니다.
• 이중화할 경우
  • 단순히 장비를 여러대 증설할 경우, DB 데이터가 분산되어 사용자가 어느 서버에 요청하는가에 따라 다른 결과를 응답받게 됩니다.
• DNS 를 이용한 트래픽을 분산할 경우
  • DNS 서버는 애플리케이션 서버의 상태를 확인하지 않으므로, 애플리케이션 서버가 장애가 날 경우에도 사용자는 장애가 발생한 서버로 요청할 수 있습니다. 또한 DNS 는 일반적으로 캐싱되므로 사용자가 직접 캐시를 날리지 않는 이상 장애가 유지됩니다.
• 애플리케이션 서버만 이중화한 경우
  • DB 서버 역시 단일장애점이 될 수 있으며, 데이터 백업가 되지 않을 경우 서비스 가치 및 신뢰에 큰 손해를 끼칠 수 있습니다.

따라서 모든 요소를 다중화해야 합니다.

다중화

다중화란, 장애가 발생해도 예비 운용장비로 시스템의 기능을 계속할 수 있도록 하는 것을 말합니다. (장애내성)

• 단일장애점(SPOF)을 없애고 무중단/고가용성 서비스를 위해 다중화가 필요합니다. 다만, 유휴장비 역시 비용이므로 ROI 에 따라 다중화 수준을 정합니다.
• 다중화의 대상은 Server, Load balancer, Network Device 등이 있을 수 있습니다.
• Failover 는 active-passive 관계를 의미하며, Replication 은 master-slave 를 의미합니다.

성능에 대한 관점

• 성능의 개선 및 저하는 수익에 직접적인 영향을 줍니다. 이에 우리는 화면 응답시간이 느리다고 판단되면, 어느 부분에서 지연현상이 발생하는지 파악해야 합니다.
  • why speed matters
• 우리는 서비스가 얼마나 빠른지(Time), 일정 시간 동안 얼마나 많이 처리할 수 있는지(TPS), 그리고 얼마나 많은 사람들이 동시에 사용할 수 있는지(Users)에 대해 이야기합니다.
• 성능 개선에는 한계가 생길 수밖에 없기에(암달의 법칙), 부하의 원인을 파악하여 이를 제거해야 합니다. 이때, 성능을 바라보는 관점은 각자 처한 상황에 따라 달라지게 됩니다.

부하

부하란, 처리를 실행하려고 해도 실행할 수 없어서 대기하고 있는 프로세스의 수를 의미합니다.

사용자

• 시스템 관리자의 관점에서는 등록된 사용자와 등록되지 않은 사용자만이 존재합니다.
• 서버의 관점에선 로그인한 사용자와 로그인하지 않은 사용자만이 존재합니다.
• 성능 테스터의 관점에선 사용자가 Concurrent User 인지 Active User 인지가 중요합니다. 여기서 Concurrent User 란, 웹 페이지를 띄어놓은 사용자처럼, 언제든지 부하를 줄 수 있는 사용자를 의미합니다. 반면, Active User 는 메뉴나 링크를 누르고 결과가 나오기를 기다리는 등 실제로 서버에 부하를 주고 있는 사용자를 의미합니다.
• Active User 와 Concurrent User 의 비율은 서비스의 성격에 따라 다르므로 이 점을 감안하고 성능테스트를 계획해야 합니다. (성능 테스트시에 VUser 는 Active User 와 유사합니다.) 가령 수강신청의 경우, 특정 시간대엔 그 비율이 90%에 육박할 수 있어, 전체 평균을 기준으로 테스트할 경우 잘못된 판단을 이끌어낼 수 있습니다.

TPS

처리량(TPS)를 계산하는 공식은 아래와 같습니다.

• 서비스 처리 건수 / 측정 시간
• 요청 사용자 수 / 평균 응답시간
• 동시 사용자 수 / 서비스 요청 간격

User 증가 시 TPS는 어느 정도 증가하다가 더 이상 증가하지 않게 되며, Time 은 일정하게 유지되다 점차적으로 증가합니다. 반면, 부하가 증가할 경우(TPS가 증가) 지연시간은 변곡점에 이르기도 하는데, 이 경우 시스템 리소스가 누수되고 있는 것은 아닌지 확인해봐야 합니다.

Time 과 달리, TPS (Transaction Per Seconds)는 Scale out 혹은 Scale up을 통해 증가시킬 수 있습니다. 보통 테스트 시에 단순히 응답시간을 기준으로 종료시키지 말고, TPS 나 DB Connection, CPU 등을 종합적으로 확인하고 중단시켜야 합니다.

Performance vs Scabaility

• 성능에 문제가 있는 경우엔, 단일 사용자에 대한 응답 속도가 느려집니다.
• 확장성에 문제가 있는 경우엔, 당장은 단일 사용자에게는 빠르지만 부하가 많아질 경우 속도가 느려질 수 있습니다.

Time

• 사용자에게 있어서 Time 은 응답시간만 존재합니다. 하지만 실제 시스템 입장에선, 사용자가 요청에 대해서 응답을 받은 후에 웹 페이지를 보는 등의 작업을 하는 시간(Think Time)이 존재합니다.
• 성능 테스트 시엔 실제 지연시간이 발생하는 구간을 파악하여야 합니다.
  • 브라우저와 웹 서버간 구간에서는 정적 파일 크기, Connection 관리, 네트워크 환경 등의 영향을 받을 수 있습니다.
  • Server 구간에서 발생한 경우, DB와 애플리케이션 간 연결의 문제, 프로그램 로직 상의 문제 혹은 서버의 리소스 부족 등을 의심해 볼 수 있습니다.
  • 네트워크 이슈의 경우 테스트하는 환경에 따라 달라질 수도 있습니다. 지연 현상은 사용자의 이탈과 매우 밀접하기에 개선되어야 하지만, 단순히 서버를 늘린다고(Scale out) 해결되는 것은 아닙니다. 이에 출시 전에 테스트를 하여 최대 응답시간을 파악하고 있어야 하며, 상위 5%의 화면이 95% 사용자 요청을 받는다는 점을 감안하고 튜닝의 대상을 선정 해가야 합니다.

Smoke Test

• 최소한의 부하로 구성된 테스트로, 테스트 시나리오에 오류가 없는지 확인할 수 있어요.
• 최소 부하 상태에서 시스템에 오류가 발생하지 않는지 확인할 수 있어요.
• VUser 를 1 ~ 2로 구성하여 테스트합니다.

Load Test

• 서비스의 평소 트래픽과 최대 트래픽 상황에서 성능이 어떤지 확인합니다. 이 때 기능이 정상 동작하는지도 확인합니다.
• 애플리케이션 배포 및 인프라 변경(scale out, DB failover 등)시에 성능 변화를 확인합니다.
• 외부 요인(결제 등)에 따른 예외 상황을 확인합니다.

Stress Test

• 서비스가 극한의 상황에서 어떻게 동작하는지 확인합니다.
• 장기간 부하 발생에 대한 한계치를 확인하고 기능이 정상 동작하는지 확인합니다.
• 최대 사용자 또는 최대 처리량을 확인합니다.
• 스트레스 테스트 이후 시스템이 수동 개입없이 복구되는지 확인합니다.

테스트 도구

부하 테스트 도구로는 Apache JMeter, nGrinder, Gatling, Locust, K6 등의 도구가 있습니다.

• 시나리오 기반의 테스트가 가능해야 합니다.
• 동시 접속자 수, 요청 간격, 최대 Throughput 등 부하를 조정할 수 있어야 합니다.
• 부하 테스트 서버 스케일 아웃을 지원하는 등 충분한 부하를 줄 수 있어야 합니다.

주의할 점

• 성능 테스트는 실제 사용자가 접속하는 환경에서 진행하여야 합니다. 내부 네트워크에서 부하를 발생시킬 경우 응답시간에 차이가 발생할 수 있습니다.
• 부하 테스트에서는 클라이언트 내부 처리시간이 배제되어 있음을 염두해두어야 합니다.
• 테스트 DB에 들어 있는 데이터의 양이 실제 운영 DB와 동일하여야 합니다. 통상 전체 성능의 70% 이상이 DB에 좌우되는데, 테스트 대상이 되는 테이블의 데이터 양이 다르면 쿼리의 실행계획이 달라져 성능이 다르게 나타날 수 있습니다. 또한 데이터가 소량이면 디스크 입출력이 일어나야 하는데 모두 메모리에 로드되어 성능이 빠른 것으로 착각할 수 있습니다.
• 운영환경의 경우, 서비스 요청 외에 별도로 수행되는 배치나 후속작업으로 인한 부하가 있을 수 있습니다. 서버에 일정하게 발생하는 부하가 있다면 성능 테스트 시나리오에도 포함해야 합니다.
• 외부 요인(결제 등)의 경우 시스템과 분리된 별도의 서버로 구성해야 합니다. 객체를 Mocking하는 경우 Http Connection Pool, Connection Thread 등을 미사용하게 되고 IO가 발생하지 않습니다. 같은 애플리케이션에 Dummy Controller를 구성하는 경우 테스트 시스템의 자원과 리소스를 같이 사용하므로 테스트의 신뢰성이 떨어집니다.

테스트 계획하기

• 전제 조건 정리
  • 테스트하려는 Target 시스템의 범위를 정해야 합니다.
  • 부하 테스트시에 저장될 데이터 건수와 크기를 결정하세요. 서비스 이용자 수, 사용자의 행동 패턴, 사용 기간 등을 고려하여 계산합니다.
  • 목푯값에 대한 성능 유지기간을 정해야 합니다.
  • 서버에 같이 동작하고 있는 다른 시스템, 제약 사항 등을 파악합니다.
• 목푯값 설정
  • 우선 예상 1일 사용자 수(DAU)를 정해봅니다.
  • 피크 시간대의 집중률을 예상해봅니다. (최대 트래픽 / 평소 트래픽)
  • 1명당 1일 평균 접속 혹은 요청수를 예상해봅니다.
  • 이를 바탕으로 Throughput 을 계산합니다.

Throughput : 1일 평균 rps ~ 1일 최대 rps

1일 사용자 수(DAU) x 1명당 1일 평균 접속 수 = 1일 총 접속 수
1일 총 접속 수 / 86,400 (초/일) = 1일 평균 rps
1일 평균 rps x (최대 트래픽 / 평소 트래픽) = 1일 최대 rps

Latency : 일반적으로 50~100ms 이하로 잡는 것이 좋습니다.

사용자가 검색하는 데이터의 양, 갱신하는 데이터의 양 등을 파악해둡니다

• 시나리오 대상
  • 접속 빈도가 높은 기능
    • 홈페이지 등
  • 서버 리소스 소비량이 높은 기능
    • CPU
      • 이미지, 동영상 변환, 인증, 파일 압축/해제
    • Network
      • 응답 컨텐츠 크기가 큰 페이지
      • 이미지, 동영상 업로드/다운로드
    • Disk
      • 로그가 많은 페이지
  • DB 를 사용하는 기능
    • 많은 리소스를 조합하여 결과를 보여주는 페이지
    • 여러 사용자가 같은 리소스를 갱신하는 페이지
  • 외부 시스템과 통신하는 기능
    • 결제 기능
    • 알림 기능
    • 인증/인가

Links

• 인프라 공방 - NextStep