재밌는 코딩세상

부하 테스트 계획 부하 테스트를 진행하기 앞서, 서비스 수준 목표(SLO)를 설정하는 것이 좋습니다. 먼저 척도를 표준화하고, 다음과 같은 목표를 설정합니다. Latency에 중점을 둔 SLO 예시 GET 호출의 90%는 1ms 이내에 완료해야 합니다. GET 호출의 99%는 10ms 이내에 완료해야 합니다. GET 호출의 99.9%는 100ms 이내에 완료해야 합니다. Throughput에 중점을 둔 SLO 예시 결국 Throughput은 순간적으로 요청이 치솟는 피크(peak) 트래픽에서의 처리량을 바탕으로 합니다. 1일 기준으로 RPS를 계산하고자 할 때, 다음과 같은 시나리오를 생각해 볼 수 있습니다. DAU(Daily Active User: 1일 접속자 수): 5만 명 1명당 평균 접속 횟수: ..

시스템 성능 지표인 Throughut과 Latency를 바탕으로 개선할 경우, 어떤 부분을 먼저 개선해야 하는지 사례를 통해 알아봅니다. Throughput 개선 고속도로의 예를 다시 빌려, 다음과 같이 세 도시를 연결하는 두 개의 고속도로 중 대구-부산 간 고속도로가 병목을 일으키고 있다고 가정합시다. 이때, 서울-부산 사이의 Throughput은 최소값인, 200대/시간에 불과합니다. 이런 경우에는 도로 확장 공사를 통해 병목을 해결합니다. 확장 공사를 마친 대구-부산 간 고속도로의 Throughput이 800대/시간으로 개선되었습니다. 병목이 아닌 구간(서울-대구)을 개선하는 것은, 전체의 Throughput을 개선하는 데에 전혀 도움이 되지 않습니다. 도리어 대구-부산 간의 정체가 늘어나 Thro..

부하 테스트의 목적 클라우드 환경에서의 부하 테스트 목적 시스템 확장성을 가졌는지 확인 성능을 개선하기 위해 확장해야 하는 시스템이 무엇인지 파악 부하가 많이 발생할 때 문제 상황 개선 각 시스템의 병목 지점을 예측하고 진단 및 개선 어떤 부분을 확장할 것인가?: 확장성에 대한 특징 파악 어떤 부분을 확장해야 성능이 높아질지를 고민하기에 앞서, Throughput과 관련한 지표를 먼저 이해할 필요가 있습니다. Throughput: 시간당 처리량으로, 시스템의 성능 지표는 RPS(request per second), TPS(transaction per second)와 같은 단위로 표현됩니다. Throughput은 데이터 전송량에 포커스를 맞춘 성능 지표입니다. 한편 볼륨의 성능을 측정할 경우에는 IOPS(..

가용성과 확장성 평가 가용성 시스템이 정상적으로 사용 가능한 정도를 말합니다. 정상적인 사용시간(Uptime)을 정상사용시간과 사용불가 시간을 합친 전체사용시간(Uptime + Downtime)으로 나눈 값을 표현하며, 예를 들어 가용성 99.95%는 약 1년에 4시간 22분의 다운타임이 됩니다. -> 위의 수식에 따라서 서비스 사용 불가능 시간을 최소로 만들어야 가용성이 올라갑니다. 가용성의 핵심은 바로 단일 장애점(Single Point of Failure)을 없애는 것 즉, 어떤 한 노드가 장애가 발생해도, 동일한 처리 능력을 가진 다른 노드로 대체될 수 있어야 합니다. -> 이를 위해 필요한 것이 바로 시스템 확장임 확장성 확장 가능한 시스템: 요구되는 시스템의 성능에 따라 동적으로 서버 구성이 ..

AWS에서는 인스턴스나 볼륨에 대해서 버스트 기능을 제공합니다. 이는 평소에 사용하지 않을 때의 성능을 모아두고, 부하가 발생할 경우 일시적으로 성능을 올리는 기능입니다. 이것이 어떤 메커니즘으로 작동하는지 연구하세요. 기존 Amazon EC2 인스턴스 유형은 고정된 CPU 리소스를 제공하는 반면, 성능 순간 확장 가능 인스턴스는 기본 수준의 CPU 사용률을 제공하면서 기본 수준 이상으로 CPU 사용률을 버스트 하는 기능을 제공합니다 -> 이렇게 하면 기준 CPU와 추가 버스트 CPU 사용량에 대해서만 비용을 지불하면 되므로 컴퓨팅 비용이 절감됨 기준 사용률과 버스트 기능은 CPU 크레딧에 의해 좌우됩니다 성능 순간 확장 가능 인스턴스는 CPU 사용량에 대해 크레딧을 사용하는 유일한 인스턴스 유형입니다 ..