[SRE] Ch03. 위험 요소 수용하기

프로젝트를 구현하다 보면 어느 정도 수준의 제품을 사용자 혹은 기업에게 제공해야 하는지 명확하지 않은 경우가 있습니다. 이런 상황에서 명확한 의사 결정을 수행할 수 있게 도와주는 내용에 대해서 정리해 보도록 하겠습니다 🧑🏻‍💻

 

사용자들은 적절하게 높은 수준의 신뢰성과 극대화된 신뢰성의 차이를 알아차리지 못한다.

 

사용자의 경험이란 모바일 네트워크나 그들이 사용하는 장비처럼 신뢰성이 낮은 컴포넌트들에 의해 좌우되기 때문에 알아차리지 못한다고 합니다. 신뢰성을 향상시키기 위해서는 엄청난 비용이 소모되며 신뢰성을 극대화하면 새로운 기능을 개발하는 속도나 사용자에게 제품을 출시하는 기간에 오히려 제동을 걸게 되며 비용이 상승하여 팀이 더 많은 수의 기능을 구현하는 데 방해가 될 수 있기 때문에 적절하게 높은 수준의 신뢰성을 구축하는 것이 오히려 사용자에게 더 좋을 수 있습니다.

 

SRE는 이런 점을 고려하여 업타임(서비스가 동작을 시작한 이후 장애 없이 실행 중인 시간)을 극대화하는 대신, 서비스가 다운될 수 있는 위험 요소와 빠른 혁신과 효과적인 서비스 운영 사이의 균형을 찾음으로써 사용자의 전체적인 만족도를 향상시키는 것에 집중시킵니다.

 

1. 서비스 위험 측정하기

위험의 수용도를 표현하는 가장 직관적인 방법은 의도되지 않은 다운타임(서비스가 장애 등으로 인해 실행이 중단된 사건)을 어느 정도나 수용할 수 있는지를 알아보는 것입니다. 의도되지 않은 다운타임은 기대하는 서비스 가용성 수준에 의해 결정됩니다. 가용성 수준은 99.9%, 99.99% 등 숫자 '9'로 표현합니다. 현재 동작 중인 시스템이라면 이 지표는 시스템의 업타임 비율로 계산하는 것이 보편적입니다.

위 공식을 일 년에 걸쳐 적용해 보면 목표 가용성 수치를 달성하기 위해 허용할 수 있는 다운타임이 몇 분인지를 계산할 수 있습니다. 예를 들어 가용성 목표치가 99.99%인 시스템의 경우, 허용 가능한 연간 다운타임은 52.56분입니다.

 

하지만, 제공하는 서비스에 따라서 시간 기준의 가용성 지표는 큰 의미가 없을 수 있습니다. 예를 들어 전 세계에 분산된 서비스를 운영하는 경우 어떤 지역에서는 장애가 발생하였지만 다른 지역에서는 서비스를 정상적으로 제공하는 경우가 발생할 수 있습니다. 이러한 경우에는 업타임과 관련된 지표 대신 요청 성공률에 기초한 가용성을 사용하는 것이 적합합니다.

 

서비스마다 적합한 가용성 지표와 목표 수치를 설정한 후 주 단위 혹은 일 단위로 목표치에 대한 성능을 측정하면 보다 적절하게 높은 수준의 가용성을 가진 서비스를 관리할 수 있을 것이라 기대합니다.

 

2. 서비스 위험 수용도

서비스의 위험 수용도를 정의하기 위해서 SRE는 반드시 제품 소유자와 협의를 통해 기업의 목표를 우리가 처리할 수 있는 명확한 목표로 설정해야 합니다. 소비자를 대상으로 하는 서비스는 대부분 제품 소유자가 분명하지만 인프라스트럭처 서비스는 제품 소유자와 유사한 구조를 갖추지 못하는 경우가 대부분입니다. 지금부터는 소비자를 대상으로 하는 서비스와 인프라스트럭처 서비스를 구분해서 살펴보도록 하겠습니다.

 

2.1 소비자 대상 서비스의 위험 수용도 정의하기

서비스의 위험 수용도를 결정하기 위해서는 다음과 같은 여러 요소들을 고려해야 합니다.

• 어느 정도 수준의 위험 수용도가 요구되는가?
• 장애의 종류에 따라 서비스에 미치는 영향이 달라지는가?
• 지속적으로 발생하는 위험 중 어느 지점에 서비스 비용을 투입할 것인가?
• 중요하게 고려해야 할 다른 서비스 지표로는 어떤 것들이 있는가?

 

2.1.1 목표 가용성 수준

이뿐만 아니라, 해당 서비스가 제공하는 기능과 시장에서의 위치에 맞는 목표 가용성 수준도 정의해야 합니다.

• 사용자는 어느 정도 수준의 서비스를 기대하는가?
• 이 서비스가 수익과 직접적으로 연관이 있는가
• 유로 서비스인가 아니면 무료 서비스인가?
• 시장에 경쟁자가 있다면 그 경쟁자는 어느 정도 수준의 가용성을 제공하는가?
• 이 서비스는 개인 사용자를 위한 서비스인가 기업 사용자를 위한 서비스인가?

 

기업용 구글 앱스로 예를 들어보겠습니다. 이 서비스의 주요 사용자층은 다양한 규모의 기업 사용자입니다. 따라서 이 서비스에 장애가 발생하면 구글의 장애일 뿐만 아니라 서비스를 사용하는 모든 기업의 장애입니다. 일반적으로 기업용 구글 앱스 서비스라면 대외적으로는 분기별 가용성 수준을 99.9%로 설정하겠지만 내부적으로는 그보다 더 높은 수준의 가용성 목표를 설정합니다.

 

그러나 유튜브는 이와 반대되는 정책을 도입하고 있습니다. 2006년 유튜브는 개인 고객 중심의 서비스였으며, 사업의 진행 단계는 당시의 구글과는 다른 시기에 있었습니다. 유튜브는 빠르게 변화하며 성장하고 있었기 때문에 신속한 기능 개발이 더 중요한 시기였으므로 구글의 기업용 제품에 비해 상대적으로 낮은 가용성 목표를 설정했습니다.

 

2.1.2 비용

비용 역시 서비스의 적절한 목표 가용성 수준을 결정하기 위해 고려해야 할 핵심 요소 중 하나가 될 수 있습니다. 구글 애드의 경우, 요청의 성공과 실패 여부가 수익에 곧바로 연결되는 서비스이기 때문에 좋은 예라고 생각합니다. 구글 애드 서비스의 목표 가용성 수준을 결정하기 위해서는 다음과 같은 사항들을 점검해봐야 합니다.

• 서비스를 구축하고 운영하는 데 있어 상향 조정된 목표 가용성 수준이 수익에 어떤 긍정적 영향을 미치는가?
• 발생 가능한 추가 수익이 목표한 가용성 수준에 도달하기 위한 비용을 상쇄할 수 있는가?

이와 같은 트레이드 오프를 정확하게 산정하기 위해, 비용/이익이라는 공식을 도입해 보는 것도 좋을 것 같습니다.

 

이 경우 가용성 수준을 0.09% 향상시키는비용이 90만 원 이하라면 투자할 만한 가치가 있다고 판단할 수 있습니다.

 

위 예시와 달리 신뢰성과 수익 사이의 단순한 방정식을 도출할 수 없다면 이런 목표치를 설정하기가 어려울 수 있습니다. 이런 경우 유용한 전략 중 하나는 인터넷 서비스를 제공하는 ISP들의 백그라운드 에러율을 고려하는 것입니다. 만일 최종 사용자의 관점에서 에러의 발생 빈도를 측정할 수 있고 서비스의 에러율을 백그라운드 에러율보다 낮게 유지할 수 있다면 서비스에서 발생하는 에러는 사용자의 인터넷 연결 상태에 의해 발생하는 에러에 의해 묻힐 수 있습니다. (ISP의 평균 백그라운드 에러율은 0.01%에서 1% 사이로 추측합니다.)

 

3. 인프라스트럭처 서비스의 위험 수용도 정의하기

인프라 스트럭처 서비스는 소비자 대상 서비스와 달리 다양한 요구사항을 여러 클라이언트로부터 전달받습니다.

 

3.1 목표 가용성 수준

모든 인프라스트럭처 서비스를 엄청나게 높은 신뢰성을 제공하도록 개발하는 것은 너무나 비용이 많이 드는 작업이기 때문에 서비스의 활용 방식에 따라 다르게 목표 가용성 수준을 정의해야 합니다. 

• 응답 속도가 빠르며 높은 신뢰성을 필요로 하는 서비스
• 신뢰성보다는 처리량을 더 필요로 하는 서비스

 

3.2 비용

처리량을 중시하는 클러스터는 다중화된 시스템의 수는 적지만 굉장히 바쁘게 실행되며 응답 속도보다는 처리량에 중점을 둡니다. 실제로 구글에서는 응답 성능 위주의 클러스터 대비 약 10~50% 정도의 비용으로 처리량 위주의 클러스터를 구성하여 비용을 절감하였다고 합니다. 빅테이블의 엄청난 규모를 생각하면 이와 같은 비용 절감은 상당히 중요한 부분이라고 말할 수 있습니다.

 

4. 에러 예산 활용

목표 데이터를 도출하기 위해서는 SLO(Service)에 따라 분기별 에러 예산을 산정해야 합니다. 에러 예산을 산정하면 한 분기 내에 서비스가 불안정한 상태로 존재할 수 있는 시간이 얼마나 되는지에 대한 명확한 목표 지표를 설정할 수 있습니다. 이 지표를 활용하면 SRE팀과 제품 개발팀이 얼마만큼의 위험을 감수할 것인지를 결정할 때 협상 과정에서 발현될 수 있는 정치적 요소들을 제거할 수 있습니다. 그다음에 할 일은 다음과 같습니다.

• 제품 관리자들이 서비스의 분기별 예상 업타입을 의미하는 SLO를 산정한다.
• 실제 업타임은 제3자, 즉 우리가 보유한 모니터링 시스템으로 측정한다.
• 이 두 숫자 사이의 차이점이 분기별로 얼마만큼의 '불안정성'을 허용할 것인지를 의미하는 '예산'이 된다.
• 업타임이 SLO를 초과한다면 새로운 릴리즈를 출시할 수 있다.

 

5. 결론

위험 요소를 수용하기 위해서 서비스 위험은 어떻게 측정하는지, 위험 수용도는 어떻게 정의하는지 서비스에 따라 구분해서 살펴보았습니다. 그리고 에러 예산을 통해 SRE와 제품 개발팀 사이의 의사 결정 방법에 대해서도 알아보았습니다. 책을 읽기 전에는 위험 요소라는 것이 무엇인지 간략하게 알고 있었지만 이제는 명확하게 어떤 것인지 알게 되었습니다. 그리고 100%는 절대로 올바른 신뢰성 목표치가 될 수 없다는 점이 인상적이었습니다.