가용성
시스템이 정상적으로 사용가능한 정도. 정상적인 사용시간(Uptime)을 정상사용시간과 사용불가 시간을 합친 전체사용시간(Uptime + Downtime)으로 나눈 값을 표현. (가용성 99.95%는 약 1년에 4시간 22분의 다운타임)
가용성의 핵심은 바로 단일 장애점(Single Point of Failure)을 없애는 것이어야 한다. 즉, 어떤 한 노드가 장애가 발생해도, 동일한 처리 능력을 가진 다른 노드로 대체될 수 있어야 한다. 이를 위해 필요한 것이 바로 시스템 확장.
확장성
확장 가능한 시스템: 요구되는 시스템의 성능에 따라 동적으로 서버 구성이 변경되고, 시스템 처리 능력을 최적화할 수 있는 시스템을 의미.
- 시스템의 처리 능력을 확장하는 방법: 하나의 머신에서 메모리나 CPU를 늘리는 수직 확장(Scale Up), 머신의 인스턴스 수를 늘리는 수평 확장(Scale Out)
- 수직 확장은 한계가 있으므로, 수평 확장이 가능할 때 확장성이 좋다고 평가할 수 있다.
- AWS와 같은 클라우드 사업자가 확장성을 보증하는 경우도 존재. 기본적으로 AWS 등에서 제공하는 서버리스 서비스들은 확장성이 좋다.
수직 확장을 고려할 경우 다운타임이 발생하여 가용성이 떨어지며, 성능 제한이 있으므로 반드시 한계를 이해해야 한다.
Throughput
Throughput은 시간당 처리량으로, 시스템의 성능 지표는 RPS(request per second), TPS(transaction per second)와 같은 단위로 표현됩니다. Throughput은 데이터 전송량에 포커스를 맞춘 성능 지표입니다. 한편 볼륨의 성능을 측정할 경우에는 IOPS(Input/Output per second)라는 단위를 사용한다. 성능을 측정할 때는, 인프라 내의 구성요소(티어)로 구분된 각 요소를 구분하지 않고 통합해서, 특정 작업이 얼마만큼의 Throughput을 갖는지를 측정한다.
Throughput 예시)
- 1초에 처리하는 HTTP 요청 수 (rps)
- (동영상 스트리밍 서비스와 같이 대역폭이 중요한 경우) 네트워크로 전송되는 데이터 전송 속도
하위 시스템으로 구성된 경우에서의 Throughput은 하위 시스템 Throughput 중 최소값을 전체 시스템의 Throughput으로 계산.
Latency
처리 시간을 의미. 사용자가 어떤 웹페이지를 보기 위한 Latency는 사용자의 인터넷 환경, 브라우저 등의 개별 환경에 대한 변수가 존재한다. 즉, "네트워크를 통한 데이터 왕복 시간"도 포함. 그러나 성능 테스트를 진행할 때에는, 사용자 환경에 따른 변인을 통제하거나, 애초에 네트워크 상황을 고려하지 않고 테스트를 진행한다. 결국 Latency는 네트워크 상황을 고려하지 않은 시스템이 요청을 받고 응답을 줄 때까지의 시간을 의미.
하위 시스템으로 구성된 경우에서의 Latency는 대기 시간을 포함한, 각 하위 시스템 처리 시간의 총합으로 계산.
📌 사용자 요청이 많아지는 경우, 즉 부하가 많이 발생하면 실제로 시스템에 일어나는 문제들
- 응답 속도(Latency) 저하
- 시스템 잠금(Lock) 경합
- 부하 발생 시 애플리케이션 또는 서버 에러 발생
- 데이터 일관성 문제와 손실
응답 성능의 병목 원인과 대책
- 많은 사용자의 서비스 등록
- 많은 데이터의 저장
- 1, 2번과 같은 경우 DB에 데이터가 증가한다. secondary 복제본 등을 이용해 읽기/쓰기를 분리하거나, 검색에 최적화된 인덱스 사용을 고려할 수 있다.
- 단기간 동안의 사용자 요청 증가(peak traffic)
- Auto Scaling이 해결책이 될 수 있다. 다만 버스트 성능에 대해 이해가 필요하다.
- 배치 작업을 진행하는 데이터베이스
- DB가 주기적으로 스냅샷을 만들거나, 데이터 일관성을 위해 레플리카와의 sync 과정을 진행하는 등의 배치 작업이 이루어질 경우, primary DB는 성능 저하가 발생할 수 있다. 이때 사용자들의 요청과 맞물려 서비스 수준을 맞추기 어려울 수 있다.
- 많은 양의 로그 수집 처리
- 애플리케이션이 잘 작동할 때에는 로그를 많이 남기지 않지만, 애플리케이션에 문제가 발생하면 추적을 위해 많은 로그를 남긴다. 다만 이러한 상황이 반복적으로 진행될 경우, 에러 로그 수집 그 자체가 애플리케이션 병목을 일으킬 수 있다.
- 시스템 재시작 후의 캐시 초기화
- 큰 문제를 발생시키는 것은 아니지만, 캐시가 초기화되면서 시스템으로 직접적인 요청 횟수가 증가할 수 있다.
발표 과제
AWS에서는 인스턴스나 볼륨에 대해서 버스트 기능을 제공합니다. 이는 평소에 사용하지 않을 때의 성능을 모아두고, 부하가 발생할 경우 일시적으로 성능을 올리는 기능입니다. 이것이 어떤 메커니즘으로 작동하는지 연구하세요.
https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/burstable-performance-instances.html 버스트 기능이 사용가능한 인스턴스 목록(T타입 인스턴스들)
T타입 인스턴스들은 기본 성능을 제공하다가, 유저들이 몰리거나 하는 등 기준 이상의 성능이 필요할 경우 버스트 기능이 동작한다. 인스턴스 사양마다 제공되는 크레딧이 다르고 그 크레딧이 남아있는 동안 버스트 기능을 사용할 수 있다.
CPU 사용률은 인스턴스에서 현재 사용 중인 할당된 EC2 컴퓨팅 유닛의 비율(%)이고, 기준 사용률은 획득하는 CPU 크레딧 수가 사용 중인 CPU 크레딧 수와 일치할 때 순 크레딧 밸런스 0에서 CPU를 사용할 수 있는 수준이다.
기준 이하 성능 사용을 지속할 경우 크레듯이 쌓이고(한계치 있음), 그 이상의 성능을 사용할 경우 크레딧을 소모시킨다.
크레딧이 다 소모되면, 기준 이상의 성능을 발휘하지 못하고 성능은 급격히 떨어진다. 이러한 특성은 평소에는 CPU 사용률이 저조하다가 특정 시간대에 높은 사용률을 사용해야 할 경우 효율적이다.
크레딧의 상태는 CloudWatch에서 확인 할 수 있다.
무제한 모드는 크레딧을 모두 소모하고 난 후에도 기준 이상의 성능을 사용할 때 비용을 추가하여 기준 이상의 성능을 사용할 수 있는 모드이다.
https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html
