서비스 수준 관련 용어
서비스를 운영하는 데 있어서, 사용자에게 필요한 적정 수준을 정의하고 제공하기 위해, 서비스 제공자와 사용자는 서로 서비스 수준 협약(Service Level Agreements, SLA)을 맺는다. 하지만 고객과의 약속이라는 것은 "어느 정도의 서비스를 제공해야 제대로 제공했다고 말할 수 있는 것인지"를 정확하게 명시하지 않으면 안되며 따라서, SRE 엔지니어는 척도를 통한 목표를 이해하고, 실제로 목표를 세우는 방법을 알아야 한다.
SLI (서비스 수준 척도, Service Level Indicator)
서비스 수준을 판단할 수 있는 몇가지를 정량적으로 측정한 값으로, 주요 SLI는 다음과 같다.
- 응답 속도 : 요청에 대한 응답이 리턴되기까지의 시간
- 에러율 : 전체 요청 수 대비
- 처리량(throughput) : 초당 처리할 수 있는 요청 수
- 가용성 : 서비스가 사용 가능한 상태로 존재하는 시간의 비율
- 내구성 : 데이터 저장이 중요한 목적인 서비스의 경우 특히 중요
* Latency는 정보가 시스템을 통과하는데 걸리는 시간 즉, 요청을 처리하는 시간, 서버의 입장에서 본 것이며
응답시간(response time)은 요청이 클라이언트에 도달하는 시간 즉, 클라이언트 입장에서 본 것이며 서로 다르다.
SLO (서비스 수준 목표, Service Level Objectives)
SLI에 의해 측정된 서비스 수준의 목표 값, 또는 일정 범위의 값을 의미한다. 즉 SLO는 SLI + 목표 이며 다음과 같이 표현된다.
SLI ≤ 목표치
최소값 ≤ SLI ≤ 최댓값
SLA (서비스 수준 협약, Service Level Agreements)
"SLO를 달성하지 못하면 어떻게 되는지"를 적어놓은 약속이다. SRE가 직접 관여하지는 않는다.
지표 설정과 주요 목표 설정
지표 설정
서비스나 시스템에 있어 중요한 지표를 판단하는 근거가 있어야 하며 적절한 SLI의 선정은 시스템의 분류에 따라 달라질 수 있다.
- 사용자가 직접 대면하는 시스템
- 보통 프론트엔드에 해당하며, 이 경우 가용성, 응답 시간, 처리량이 중요하다.
- 저장소 시스템
- 응답 시간, 가용성, 내구성이 중요하다.
- 빅데이터 시스템
- 데이터 파이프라인이 이에 해당하며, 처리량, 그리고 엔드포인트 간 응답 시간이 중요하다.
척도 수집
측정 원본을 합산하거나, 평균을 내거나 하는 방법이 있겠지만, 대부분의 경우 분포가 중요하며 일부 요청이 빠르게 처리되어도, 나머지 요청이 균일하게 느리다면 실제로 서비스는 느린것으로 간주할 수 있으며 평균은 이러한 흐름의 변화를 감지하기 어렵다.
척도의 표준화
SLO를 설정할 때, 주요 SLI의 정의를 표준화시키면 편리하며 예를 들어 다음과 같다.
- 집계 간격: 1분
- 집계 범위: 하나의 클러스터에서 수행되는 모든 태스크
- 측정 빈도: 매 10분
- 집계에 포함할 요청: 전체 HTTP GET 요청
목표 설정하기
다음과 같은 목표를 설정할 수 있다. 다음은 성능에 중점을 둔 SLO이다.
- GET 호출의 90%는 1ms 이내에 수행되어야 한다.
- GET 호출의 99%는 10ms 이내에 수행되어야 한다.
- GET 호출의 99.9%는 100ms 이내에 수행되어야 한다.

가용성과 확장성 평가
가용성(Availability)
시스템이 정상적으로 사용 가능한 정도를 말하며 정상적인 사용시간(Uptime)을 정상사용시간과 사용불가 시간을 합친 전체사용시간(Uptime + Downtime)으로 나눈값을 표현하며, 예를 들어 가용성 99.95%는 약 1년에 4시간 22분의 다운타임이 된다. 위의 수식에 따라서 서비스 사용 불가능 시간을 최소로 만들어야 가용성이 올라갑니다.
가용성의 핵심은 바로 단일 장애점(Single Point of Failure)을 없애는 것이다.
즉, 어떤 한 노드가 장애가 발생해도, 동일한 처리 능력을 가진 다른 노드로 대체될 수 있어야 하며 이를 위해 필요한 것이 바로 시스템 확장입니다.
확장성
확장 가능한 시스템: 요구되는 시스템의 성능에 따라 동적으로 서버 구성이 변경되고, 시스템 처리 능력을 최적화할 수 있는 시스템을 의미한다.
- 시스템의 처리 능력을 확장하는 방법: 하나의 머신에서 메모리나 CPU를 늘리는 수직 확장(Scale Up), 머신의 인스턴스 수를 늘리는 수평 확장(Scale Out)
- 수직 확장은 한계가 있으므로, 수평 확장이 가능할 때 확장성이 좋다고 평가할 수 있다.
- AWS와 같은 클라우드 사업자가 확장성을 보증하는 경우도 존재하며 기본적으로 AWS 등에서 제공하는 서버리스 서비스들은 확장성이 좋다.
수직 확장을 고려할 경우 다운타임이 발생하여 가용성이 떨어지며, 성능 제한이 있으므로 반드시 한계를 이해해야한다.
'TIL' 카테고리의 다른 글
| 1일차 - JavaScript 챕터1 (0) | 2022.11.07 |
|---|---|
| 67일차 성능테스트 (0) | 2022.07.20 |
| 65일차 서비스 모니터링 (0) | 2022.07.18 |
| 64일차 서비스 모니터링 (0) | 2022.07.16 |
| 63일차 서비스 모니터링 (0) | 2022.07.14 |