[SRE] Error Budget이란? - 서비스 안정성과 개발 속도의 균형점

"우리 시스템이 얼마나 에러가 나도 되나? 의 지표 Error Budget"

Error Budget 이란?

Error Budget(오류 예산)은 Google에서 개발한 SRE 방법론의 핵심개념이다. 서비스의 안정성과 새로운 기능 개발 속도간의 균형을 정량적으로 관리하는 개념으로 보면 된다.

 

IT업계에 있는 분들이라면 다 아시겠지만 100% 완벽한 소프트웨어는 불가능하다. 기술의 혁신을 가져가자니 시스템의 안정성이 떨어지고 안정성만 따지자니 기술 부채는 늘어간다. 이런 딜레마를 해결하는 방법 중에 하나가 Error Budget인 것 같다.

Error Budget 계산

Error Budget은 보통 아래 식과 같이 계산된다.

Error budget = [100% - availability target] 

 

조직에 서비스 수준 목표를 측정할 수 있다면 SLI, SLO로 더 정교하게 Budget을 계산해볼 수도 있을 것 같다.

예시:

• SLO: 99.9% 가용성
• 월간 1억 건 요청 처리
• Error Budget: 0.1% X 100,000,000 = 100,000개 요청 오류 허용

이렇게 계산하면 일일 허용 오류는 33,333건 요청이 된다. 이 안에서 조직은 자유롭게 시스템 개선이나 실험을 진행해볼 수 있고, 범위를 초과하면 안정성에 집중하면 될 것이다.

 

Error Budget 활용 전략

현 회사에서 이런 저런 이슈로 시스템에 사소한 작업을 할 때마다 검토를 받아야 하는 Pain Point가 있다.(실무진들의 Pain Point이지 사실 경영/임원진 입장에서는 그래야 마음이 놓일 것 같기도 하다) 우리 조직에 Error Budget 개념을 사용한다면 어떨까? 라는 생각이 들어 내 맘대로 몇 가지 전략을 생각해 봤다.

 

Error Budget을 사용하려면 이를 측정할 수 있는 Observability 체계가 필요하다.

단계별 대응 정책 설정하기

반기별로 Error Budget 설정 및 KPI 지표 설정 해놓는다.

소진률	단계	대응 방안
50%	주의	모니터링 체계 강화 ex. cpu, memory alert 임계치 낮추기 등
75%	경고	신규배포 및 시스템 작업 시 리더급 검토
90%	위험	신규배포 중단
100%	긴급	안정성 우선 모드

 

팀별 Error Budget 할당

하나의 시스템에 Error Budget을 설정해놔도 R&R이 모호할 수 있을 것 같다. 하나의 시스템에도 백엔드, 프론트엔드, 인프라, DevOps, 네트워크 등등 여러 이해관계가 있기 때문에 팀단위 별로 Error Budget을 할당해서 해소하는 전략을 생각해봤다.

• 프론트엔드: 월 30% 할당
• 백엔드: 월 50% 할당
• 인프라: 월 20% 할당

에러나면 어느 팀의 Budget에서 차감해?

점점 전략을 짜볼 수록 현실적인 문제에 직면하는 것 같다. :) 

 

- MSA 환경에서는 연쇄 장애 시 책임 소재 모호

- 대규모 Enterprise급의 경우 아예 사업부 자체가 다른 조직 이슈일 수 있는 경우

 

등등이 있을 것 같다. 기본적으로 어찌됐든 에러가 났다면 고객의 신뢰를 잃어버린 것이니 외부의 불가항력적인 요소에 의한 거라도 (통신사 네트워크의 문제, 물리적인 천재지변 등) 공통 1/N로 차감해야할 것 같다.

결론

결국 빠르게 이슈를 파악하고 대응하기 위해서는 Observability가 확보된 시스템을 만들어야 한다. Observability가 없이 이런 전략을 도입했다면 서로 싸우게 만드는 전략이 될 수도 있을듯 하다.

 

 

참고.

https://jdhyeok.tistory.com/23

[SRE] 서비스 수준 목표 - 서비스가 잘 돌아 가는지에 대한 척도