Ch.3 : 위험 요소 수용하기 (Embracing Risk)
SRE 측면에서, 이번 챕터 한줄 요약
다운 타임과 측정하고, 에러에 대한 에러 버짓을 설정하여 미리 관리하면 위험 요소 (Risk) 를 어느정도 관리할수 있다.
내용 전체를 적는게 아니라, 스터디 하면서 중요하다 생각한 내용 위주로 적고 있기때문에, 아래의 문서들을 참고하시길.
위험 요소(Risk) 관리하기
SRE(사이트 신뢰성 엔지니어링)를 통한 위험 요소(Risk) 관리하는 방법에 대해서 소개하는 챕터이다.
서비스 제공은 현대 비즈니스에서 더 이상 무시할 수 없는 중요한 부분입니다. 그러나 서비스를 제공함에 있어서 완벽한 신뢰성을 기대하는 것은 불가능하다. 서비스를 운영하다보면 다양한 위험 요소들이 존재하고, 이를 적절하게 수용하고 관리하는 것이 필요하다. 이를 통해 효율적으로 서비스 운영의 안정성을 유지할 수 있다.
다른 요소에 의한 불 가용성
서비스의 신뢰성은 사용자의 환경에 의해 영향을 받을 수 있다. 사용자가 사용하는 장비, 인터넷 서비스 제공자(ISP), 그리고 전력망 등의 요소들은 서비스의 신뢰성에 직접적인 영향을 미칠 수 있다. 이러한 외부 요소들을 완전히 통제하기는 어렵기 때문에 신뢰성을 100% 보장하는 것은 불가능하다.
비용의 기하 급수 적인 증가
서비스의 신뢰성을 높이기 위해서는 여분의 머신 자원을 확보하고, 위험 상황에 대비한 준비를 해야한다.
이로 인해 추가 비용이 기하급수적으로 증가한다. 따라서 적절한 수준의 신뢰성을 정하는 것이 중요하다. 감수할 수 있는 Risk인지를 생각하고 비용과 효과를 고려하여 적정 수준을 정의해야한다.
서비스 위험 측정하기
서비스의 현재 상태를 측정하고 분석하는 것은 신뢰성을 유지하는 데에 매우 중요하다.
다음과 같은 방법으로 서비스의 신뢰성을 측정할 수 있다.
| 가용성 수준 | 매년 | 매분기 | 매월 | 매주 | 매일 | 매시간 |
| 90% | 36.5일 | 9 일 | 3 일 | 16.8 시간 | 2.4시간 | 6분 |
| 95% | 18.25일 | 4.5일 | 1.5일 | 8.4시간 | 1.2 시간 | 3 분 |
| 99% | 3.65일 | 21.6시간 | 7.2 시간 | 1.68시간 | 14.4 분 | 36초 |
| 99.5% | 1.83 일 | 10.8 시간 | 3.6시간 | 50.4 분 | 7.20분 | 18초 |
| 99.9% | 8.76시간 | 2.16시간 | 43.2분 | 10.1분 | 1.44 분 | 3.6초 |
| 99.95% | 4.38시간 | 1.08 시간 | 21.6분 | 5.04 분 | 43.2 초 | 1.8초 |
| 99.99% | 52.6분 | 12.96 분 | 4.32분 | 60.5초 | 8.64초 | 0.36초 |
| 99.999% | 5.26분 | 1.30분 | 25.9초 | 6.05초 | 0.87초 | 0.04초 |
목표한 신뢰성 기준에 충족 여부
설정한 신뢰성 목표에 부합하는지를 확인하는 것이 중요하다. 이를 통해 서비스의 운영 상태를 평가하고 문제점을 파악할 수 있다.
변경이 신뢰도에 영향
서비스에 적용되는 변경 사항이 신뢰성에 어떤 영향을 미치는지 파악하는 것이 필요하다. 변경으로 인해 신뢰도가 하락할 경우, 적절한 대응이 필요하다
의도치 않은, 다운 타임에 의한 지표 측정
서비스의 의도되지 않은 다운 타임은 사용자에게 영향을 미칠 수 있는 중요한 요소입니다. 이를 시간을 기준으로 측정하여 가용성 지표를 확인한다.
요청 성공률에 의한 가용성 정의
서비스의 가용성을 평가하는데 있어서 요청의 성공률을 고려하는 것이 유용하다. 사용자에게 직접적으로 제공되지 않는 시스템의 가용성을 평가할 때에도 이 방법을 활용할 수 있다.
서비스 위험 수용도
서비스의 위험 수용도를 정의하는 것은 중요한 결정 사항입니다. 소비자 대상 서비스의 위험 수용도를 고려하여 다음과 같은 사항들을 고려해야 한다.
목표 가용성 수준 선정시 고려 사항
- 사용자의 기대 수준: 사용자는 어느정도 수준의 서비스를 기대하는가?
- 수익과의 관련성: 서비스가 수익과 직접적으로 연관이 있는가? 회사나 사용자의 수익에 영향을 미치는가?
- 서비스의 유형: 유료 서비스인지 무료 서비스인지에 따라 기대되는 신뢰성 수준이 다를 수 있다
- 시장 경쟁: 경쟁자가 있다면 어느 수준의 가용성을 제공하는가?
- 타깃 사용자: 개인 사용자를 위한 서비스인지 기업 사용자를 위한 서비스인지에 따라 다른 수준의 신뢰성이 필요
비용의 문제
- 상향된 목표 가용성이 수익에 어떤 영향을 주는지?
- 추가 수익과 목표 가용성 도달에 필요한 비용 비교해보자
- 가용성 수준의 상향 : 99.9% -> 99.99%
- 향상되는 가용성 : 0.09%
- 서비스 수익 : 10억원
- 향상된 가용성 수준의 가치 : 10억 * 0.0009 = 900,000
- 외부 불 가용성 고려 해야 함 (ISP 백그라운드 에러율 0.01% ~ 1% 를 참고 한다.)
위의 예시처럼 0.09% 향상의 실제 가치는 900,000원 일때, 들어가는 비용과 고민해서 의사결정을 해야한다.
에러 예산 (Error Budget)
서비스를 운영하다보면 충돌하는 목표와 가치가 발생할 수 있다. 이러한 충돌을 완화하기 위해서는 에러 예산을 설정하고 이를 기준으로 서비스를 운영해야 한다.
충돌을 완화를 위해 협의가 필요한 요소
- 소프트웨어 결함 허용: 시스템의 유연성과 안정성 사이에서 어떤 허용 범위를 가져갈 것인지 결정해야 한다.
(시스템의 유연성 vs 안정성) - 테스트: 변경에 대한 비용과 안정성 사이의 균형을 맞추기 위해 테스트 주기와 규모를 조정할 필요가 있다.
(변경 비용 vs 안정성) - 출시 빈도: 에러 예산을 통해 출시 주기를 조정하여 안정성을 유지할 수 있다.
- Canary 테스트: 출시 전 Canary 테스트 주기와 규모를 협의하여 안정성을 검증한다.
에러 예산 산정하기
SRE(신뢰성 엔지니어링) 팀은 서비스 분기별 예상 서비스 목표 수준(SLO)을 산정한다. 이를 통해 실제 업타임과 목표 수준과의 차이를 측정한다. 이 차이가 에러 예산이 되며, 이를 초과하면 출시를 중단하고 안정성 개선에 비용을 할당해야한다.
장점
에러 예산을 설정함으로, 신뢰성과 새로운 출시 사이의 균형을 찾을 수 있다. 에러 예산을 모두 소모하면 출시를 중단하고 시스템의 안정성과 성능 향상에 집중할 수 있다. 또한, 신뢰성 기준이 지나치게 높으면 경직성과 혁신의 저하가 발생할 수 있으므로, 에러 예산을 통해 적절한 출시 주기와 안정성을 조절할 수 있다.
Ch.4 : 서비스 수준 목표 ( Service Level Objectives)
서비스를 운영하는데 가장 중요한 지표들
서비스를 운영하면서 그 성능을 평가하기 위해 사용되는 세 가지 중요한 지표가 있다. 이 지표들은 SLI(서비스 수준 척도), SLO(서비스 수준 목표), SLA(서비스 수준 협약)로 알려져 있다. 이들 지표는 서비스의 품질과 성능을 평가하고, 서비스가 문제없이 잘 돌아가는지를 확인하는데 사용된다.
SLI: 서비스 수준 척도
SLI는 서비스 수준을 정량적으로 측정하기 위해 사용되는 몇 가지 지표들이다 이러한 지표들은 요청 응답속도, 요청 대비 에러율, 초당 요청 처리율 등과 같은 요소들을 포함한다. 서비스 수준 척도는 가용성도 포함하는데, 이는 서비스가 얼마나 사용 가능한 상태로 존재하는지를 나타내는 지표입니다. 100% 가용성을 실현하는 것은 어렵지만 99.9%와 같이 100%에 가까운 가용성을 달성하는 것이 목표
SLO: 서비스 수준 목표
SLO는 SLI에 의해 측정된 서비스 수준의 목표 값이나 일정 범위의 값이다.
예를 들어, 서비스의 응답시간(Response Time) 을 줄이는 것이 목표라면 SLO는 100ms 이하로 설정될 수 있다. SLO를 설정하고 이를 고객에게 공개함으로써 서비스의 동작에 대한 예측을 가능하게 한다.
또한, SLO가 명확하게 설정되지 않으면 사용자들이 지나치게 높은 기대치를 갖게 될 수 있다.
SLO vs SLI
SLI(서비스 수준 척도)는 서비스의 성능을 정량적으로 측정하는데, 사용되는 지표들을 의미한다.
반면에, SLO(서비스 수준 목표)는 이러한 척도들을 기반으로 설정되는 서비스의 목표 값이나 범위를 의미한다.
SLA: 서비스 수준 협약
SLA는 SLO를 만족하거나 만족하지 못했을 때의 대응에 대한 사용자와의 명시적 또는 암묵적인 계약을 의미한다.
SLO와 SLA는 매우 유사하지만 차이점은 “SLO를 달성하지 못하면 어떻게 할 것인가?” 이다. 이러한 SLA는 SRE(신뢰성 엔지니어링) 팀이 아니라 사업부와 제품에 대한 의사결정과 관련되기 때문에 SRE는 SLA 체결에 직접적으로 관여하지 않는다. 그러나 SLO를 객관적으로 설정하기 위해 SRE의 도움이 필요하다. 모든 서비스가 SLA를 체결 하지는 않지만 기업용 서비스는 명확한 SLA를 체결하는 것이 보편적이다. AWS나 카페24 같은 호스팅을 보면 Downtime 시간의 명시와 보상에 대해서 적혀져 있는데 이런것들이라고 볼수 있다.
지표 설정: 중요성과 주의사항
정말 중요한 지표를 SLI로 설정하는 것이 매우 중요하다. 사용자가 무엇을 원하는지 이해한다면 적절한 척도를 선택할 수 있다. 너무 많은 지표를 설정하면 중요한 것에 집중하기 힘들고, 너무 적으면 중요한 부분을 놓칠 수 있다. 따라서 지표 설정에는 신중함이 필요하다. 또한, 여러 로그를 수집해서 서버측 수집이 가능하거나 클라이언트에서 수집해야 하는 경우도 있을 수 있다. 이러한 척도들은 서비스의 특성에 따라 다르게 설정되어야 한다.
또한, 이러한 지표들은 어떤 의미에서 합산되는지에 대한 이해도 필요하다. 평균보다는 분포가 중요하다는 것을 알리는 내용이며, 평균적인 값보다 극단적인 값에 주의를 기울여야 한다는 것을 강조하고 있다. 이렇게 함으로써 서비스의 성능을 더욱 정확하게 파악할 수 있다.
목표설정에 대한 실습: 사용자 중심의 목표 설정 방법
목표를 설정하는 과정에서 사용자가 중요하게 생각하는 값을 먼저 고려해야 한다. 사용자가 원하는 것을 고려하지 않고 단순히 척도를 선택한 후에 목표를 설정하는 것보다, 먼저 목표를 설정하고 그에 맞는 척도를 찾는 것이 더욱 효과적이다. 예를 들어, 서비스의 목표를 고성능, 처리량 등으로 설정하면 사용자들이 원하는 서비스 품질에 맞는 목표를 설정
목표치(SLO)를 선택할 때에도 주의가 필요하다. SLI와 SLO를 어떻게 설정하느냐에 따라 제품과 사업에 영향을 줄 수 있다. 따라서 현재의 성능을 기준으로 목표치를 설정하지 말고, 시스템의 장점과 한계를 고려하여 가능한 범위 내에서 목표치를 설정하는 것이 좋다. 또한, 지나치게 복잡한 SLI를 설정하면 시스템 성능 변화를 명확하게 반영하지 못하고 원인 파악이 어려워질 수 있으므로, 최대한 단순하게 생각하면서 목표를 설정하는 것이 필요하다. 자기만족에 얽매이지 말고 필요 수준 이상의 목표를 설정하면 구축과 운영 비용이 증가할 수 있으며, 실제 사용자들이 그 정도의 성능을 바라지 않을 수 있다. 따라서 가능한 적은 수의 SLO를 설정하고, 처음에는 완벽함을 목표로 하지 않고 나중에 강화하는 것이 중요하다.
측정하기: SLI와 SLO를 모니터링하고 대응하기
서비스의 SLI들을 모니터하고 측정하여 실제 서비스의 성능을 파악해야 하다. 이를 통해 SLO와 비교하여 별도의 대응이 필요한지를 판단하고, 대응이 필요한 경우 목표치를 달성하기 위한 방법을 찾아야 하다. 서비스의 SLI와 SLO를 꾸준히 모니터링하고 측정함으로써 사용자에게 더 나은 서비스를 제공할 수 있다.
결론
서비스 수준 목표를 설정하는 것은 서비스 운영에 있어서 매우 중요한 과정이다. 사용자 중심의 목표 설정과 지표의 선택, 그리고 측정과 대응을 통해 서비스의 품질을 높이고 사용자들에게 더 나은 경험을 제공할 수 있다.
실제 SLO 설정 하면서 느낀 고충
가능한 가장 적은 수의 SLO를 잡아야하며 사용자가 원하는 낮은 수준의 목표를 설정하는것이 SRE 컨셉에 맞으나, 대부분의 의사 결정자들은 목표는 높게 설정하길 원하며, SLO의 갯수는 이것만으로 될까? 라는 질문을 계속 한다.
내가 생각하는 SRE 는 비용과 안정성 사이의 줄다리기를 해주는 역할이지, 극미한 비용으로 안정성을 무한히 확장할수 있는 도구가 아니다. 안정성을 극대화시 많은 비용이 들어가기 때문에 적당히 유지하는게 컨셉이다.
2 thoughts on “[SRE] Ch. 3 & 4 : 위험 요소 수용하기 & 서비스 수준 목표”