SRE(Site Reliability Engineering)
이 글은 SRE에 대해서 조금씩 정리해가는 포스트이다.
팀 프로젝트에서 배포 자동화 작업을 담당하면서 ‘사용자가 많은 환경이라면 좀 더 나은 인프라나 배포 방식이 필요하겠다.’라는 생각을 했었고 DevOps나 관련된 자료를 검색하다보니 SRE라는 분야가 있다는 것은 알고 있었다. 관련된 동물책을 구매하여 본적도 있고 토이 프로젝트에서 메트릭 모니터에 사용되는 오픈소스인 Prometheus나 Grafana를 설치해서 사용해보고 있기는 한데, SRE에 대해 다시 학습하는 것이 좋을 것 같아서 작성한다.
개발과 운영 사이의 벽
개발자와 운영자의 이해타산이 상충되는 문제가, 소프트웨어 개발에는 내포되어 있다.
개발자(민첩성)는 새로운 기능을 추가하고 시스템도 새로 개발하여 원하는 때에 활용할 수 있기를 원하는 한 편, 운영자(안정성)는 시스템이 항시 안정적으로 돌아가야 한다는 시각을 갖고 있다.
개발자들은 새로운 기능을 출시하고 싶어하는데 기능의 추가는 필시 버그를 동반하고, 시스템의 속도는 빨라질 수도, 느려질 수도 있다. 즉, 개발자 주도적인 일방적 확장은 곤란하다.
하지만 그렇다고 하여 개발자에게 기능 추가를 너무 자주 하지 말라고 얘기하기도 곤란한다. 엔드 유저에게 있어서 개발자의 기능 추가는 소프트웨어에 상존하는 문제를 해결하는데 대단히 중요한 역할을 하기 때문이다.
그와 동시에 소프트웨어 운영의 안정성을 고려하지 않으면 소프트웨어(또는 서비스)의 사용률에 문제가 생겨 엔드 유저가 피해를 입는다.
개발자와 운영자 어느 한 편만 들어서는 문제를 해결할 수 없으며, 이들이 상호 목표하는 바를 균형 있게 달성할 수 있도록 하는 조치가 필요한데 이를 해결하기 위해 나온 일종의 방법론이자 문화가 DevOps이다.
DevOps
IT 개발, 운영, 아키텍처, 네트워킹, 보안 간 사일로를 타파하기 위해 설계된 일련의 실천방안, 가이드라인 및 문화.
5가지 주요 분야
- 운영 사일로 축소
- 오류를 일상으로 받아들임
- 점진적 변화 구현
- 도구와 자동화 활용
- 모든 것을 측정
사이트 신뢰성 엔지니어링(SRE)
class SRE implements DevOps
효율적으로 작동하는 것으로 밝혀진 일련의 실천방안, 여기에 활력을 불어넣는 신념 그리고 직무 역할을 말함.
DevOps는 개발과 운영의 사일로 현상을 해결하기 위한 방법론이자 문화이다. SRE는 DevOps에 적용하기 위한 구체적인 실사례와 가이드라인으로 생각할 수 있다.
SRE 엔지니어는 무슨 일을 할까?
- Metric & Monitoring (측정항목 및 모니터링)
- Capacity Planning (용량 계획)
- Change Management (변경 관리)
- Emergency Response (비상 대응)
- Culture (문화)
지표
SLI (Service Level Indicator)
- SLO/SLA 설정에 사용됨
- 서비스 사용률에 관련된 일반적인 지표
- 서비스의 신뢰성을 정의하는데 활용됨
SLI는 서비스에 대한 수준을 측정하여, 정량적으로 정의한 지표이다.
가령 하루(24시간) 중 20분 동안 서비스를 사용할 수 없다면, SLI를 20분이 아니라 가용성으로 SLI를 정의하여 $ \dfrac{1440 - 20}{1440} = 98.6111 \% $와 같은 식으로 표현하는게 좋다.
SLO (Service Level Objective)
SLO = SLI + 목표값
- 목적을 정함 (SLI + 목적)
서비스 수준 목표는 SLI의 한 부류로, 지표를 수치적으로 나타내며 목표 수준도 함께 정의하는 개념이다.
서비스 신뢰성의 목표, 예를 들어99.95%, 99.99% 등과 같은 수치들이 이에 해당된다고 볼 수 있는데 통상적으로 9가 많이 포함되어 있을수록 신뢰성이 높은 것으로 간주할 수 있다.
예를 들어 REST API의 응답시간을 SLI로 정했다면 SLO는 다음과 같이 정의할 수 있다.
“매주, 99% of REST API 호출의 응답시간은 100ms 이하여야 한다.”
여기서 “매주, 99% of REST API 호출 응답시간”이 SLI가 되고, “응답시간 100ms”가 목표값이 되어서 위의 전체 문장이 SLO가 된다.
SLI가 실제로 측정되는 지표라면, SLO는 중요성에 따라 설정해야 할 목표가 된다.
SLA (Service Level Agreement)
서비스 수준 계약
결과
- SLA = (SLO + 여유분) + 결과 = SLI + 목적 + 결과
일반적으로 클라우드 서비스와 함께 제공되는 지표이며 SLO와 더불와 해당 SLO가 충족되지 못했을 시의 결과를 아울러 이르는 개념이다.
참고
영상 : [SEOUL Summit - T2] Site Reliability Engineering (SRE) 으로 더 신뢰할 수 있는 시스템 구축하기
도서 : 사이트 신뢰성 엔지니어링
조대협님 블로그 : SRE/DevOps의 개념