- 가용성과 확장성을 염두하여 시스템을 설계하는 것이 중요하다.
- 다수의 노드를 가진 분산 시스템, 또한 서버리스 아키텍처 등을 통해 가용성과 확장성 확보가 가능하다.
가용성(Availability)이란?
가용성이란
- 시스템이 정상적으로 사용 가능한 정도
- uptime / (uptime + downtime)
=> 정상가동시간(uptime), 사용 불가 시간(downtime), 합친 전체 사용 시간 (uptime + downtime)
- ex) 가용성 99.95% = 약 1년에 4시간 22분의 다운타임을 갖는다.
* 단일 장애점 (Single Point of Failure)을 없애야 한다.
** 어떤 한 노드에서 장애가 발생해도, 동일한 처리 능력을 가진 다른 노드로 대체 될 수 있어야 한다.
=> 시스템 확장이 필요!
확장성이란?
확장 가능한 시스템 이란
- 요구되는 시스템의 성능에 따라 동적으로 서버 구성이 변경되고
시스템 처리 능력을 최적화 할 수 있는 시스템
시스템 처리 능력 확장 하는 법
- 하나의 머신에서 메모리나 CPU를 늘리는 수직확장(Scale Up), 머신의 인스턴스 수를 늘리는 수평확장 (Scale Out)
- 수직 확장은 한계가 있으므로 수평 확장이 가능할 때 확장성이 좋다고 평가할 수 있음
- AWS와 같은 클라우드 사업자가 확장성을 보증하는 경우도 있음
- 서버리스 서비스들은 확장성이 좋음
* 수직확장을 고려할 경우 다운타임이 발생하여 가용성이 떨어지고 성능 제한이 있으므로 반드시 한계를 이해해야 함
부하 테스트의 목적
- 시스템 확장성을 가졌는지 확인
- 성능을 개선하기 위해 확장해야 하는 시스템이 무엇인지 파악
- 부하가 많이 발생할 때 문제 상황 개선
- 각 시스템의 병목 지점을 예측하고 진단 및 개선
확장성에 대한 특징
Throughput 이란
시간 당 처리량을 뜻하며 시스템의 성능 지표는 RPS(Request per second), TPS(Transaction per second) 와 같은 단위로 표현된다.
RPS : 서버가 초당 처리할 수 있는 요청 수 (1초 동안 100개의 요청을 처리한다면 RPS = 100)
TPS : 데이터 베이스나 트랜잭션 처리 시스템에서 초당처리할 수 있는 거래 수 (1초에 50개의 트랜잭션을 처리한다면 TPS = 50)
IOPS (Input/Output per second) 란
볼륨의 성능을 측정하는 단위
인프라 내의 구성요소(티어) 로 구분된 각 요소를 구분하지 않고 통합해서 특정 작업이 얼마만큼의 Throughtput을 갖는지 측정
Q1. 1000rps에서 2000rps로 성능을 두 배 개선하기 위해서는, 웹서버를 확장해야 할까? DB 서버를 확장해야 할까?
=> 웹서버를 확장해야한다고 생각함. 수직확장(CPU, 메모리 등) 또는 수평 확장(로드밸런스 사용 등)을 통해 병렬 처리가 가능하도록 하는 것이 좋을 것으로 생각됨
Q2.시스템 구성 변경 시 다운타임은 얼마나 허용되는가? 서비스 정지 없이 가능한가?
=> 다운타임을 허용할 수 있는 시간은 시스템의 중요도, 사용자 기대 수준, 시스템 규모, 특성 등에 따라 다르다.
다운타임에 대한 영향이 큰 경우 (금융이나 의료 서비스 등) 다운타임 허용 시간이 매우 짧을 것이고, 커머스 웹사이트 블로그 등 심각한 결과가 발생하지 않는 경우는 다운타임 허용 시간이 좀 더 허용 될것이다.
서비스 정지 없이 시스템 구성을 변경하기 위해선 고 가용성 아키텍처와 같은 시스템 구축이 필요하다.
로드 밸런스 등의 기술을 사용하여 여러대의 서버 구성이 필요함.
Q3. 현재 시스템에서 낼 수 있는 최대 성능(limit)은 어디까지인가?
=> 하드웨어 성능 (CPU, 메모리 등), 소프트웨어 성능 (어플리케이션 코드 최적화, 데이터베이스 쿼리 최적화 등), 네트워크 대역폭이나 지연시간 등 네트워크 성능도 시스템 성능에 영향을 미치며 또한 시스템 구조 및 아키텍처에 따라 성능이 제한 될 수 있다.
이러한 것들을 고려하여 최적의 구성을 하여 최대 성능을 달성할 수 있다.
부하가 많이 발생할 때의 문제
- 응답 속도 (Latency) 저하
=> 캐시 사용, 로드밸런싱, 데이터베이스 최적화, 코드 최적화, 네트워크 최적화 - 시스템 잠금 (Lock) 경합
=> 여러 프로세스나 스레드가 동시에 하나의 공유 리소스에 접근하려고 할 때 발생하는 현상
=> Lock이 걸려있는 경우, 다른 프로세스나 스레드는 해당 리소스에 접근할 수 없고 대기 상태로 들어가게 됨
=> 대기 상태로 들어간 프로세스나 스레드가 많아질수록 시스템 성능이 저하될 가능성이 있음
=> 비관적 잠금(pessimistic locking), 낙관적 잠금(optimistic locking)을 사용하여 시스템의 성능을 개선할 수 있음
- 비관적 잠금 = 다른 프로세스나 스레드가 데이터나 자원을 변경하지 않도록 락을 걸고 기다리는 방식
= 락이 걸려있는 동안 해당 데이터나 자원에 접근할 수 없음 -> 락 시간이 길어지면 시스템 성능에 영향을 미침
- 낙관적 잠금 = 락을 걸지 않고 변경 요청이 있을 때, 실제 데이터가 변경되었는지 검사
= 다른 프로세스나 스레드가 데이터를 변경하는 경우를 감지하고 변경되지 않았을 경우에만 데이터를 업데이트함
= 락이 없으므로 시스템 성능이 향상될 수 있지만 충돌이 일어날 수 있음 - 부하 발생 시 어플리케이션 또는 서버 에러 발생
- 데이터 일관성 문제 또는 손실
용어 정리
* Troughput
시간 당 처리량을 의미함
ex) 1초에 처리하는 HTTP 요청 수 (RPS)
네트워크로 전송외는 데이터 전송 속도 (동영상 스트리밍 서비스와 같이 대역폭이 중요한 경우)
* Latency
처리 시간을 의미함
인터넷 환경, 브라우저 등의 개별 환경에 대한 변수가 존재
시스템이 요청을 받고 응답을 줄 때까지의 시간 (네트워크 상황을 고려해야 할 수 도 있음)
- 대기시간을 포함한 각 하위 시스템 처리 시간의 총합으로 계산
-> 서울-부산 간 Latency : 각 구간의 소요 시간 합계인 5시간
-> 서울-부산 간 Throughput : 각 구간에 도달하는 차량 대수 중 최소값인 800대/시간
* CDN
콘텐츠 전송 네트워크
데이터 사용량이 많은 어플리케이션의 웹 페이지 로드 속도를 높이는 상호 연결된 서버 네트워크
* Race Condition
두 개 이상의 프로세스나 스레드가 공유 자원에 동시에 접근하고 조작하려고 할 때 발생하는 소프트웨어 문제
1. 첫번째 스레드는 변수를 읽음
2. 두번째 스레드는 변수에서 동일한 값을 읽음
3. 두 스레드가 같은 값으로 작업을 수행하고 공용 변수에 마지막으로 값을 쓸 수 있는 스레드 확인
-> Race (경쟁)
4. 증상 : 덮어쓰기 반복
네트워크 최대 전송 용량 -> 전송 용량이 대역폭 보다 클 수 없다.
'DevOps > 성능 테스트' 카테고리의 다른 글
| 부하 테스트 계획 및 도구 (3) | 2023.03.03 |
|---|---|
| 병목현상이란? (원인과 대책) (0) | 2023.03.03 |