SRE (Site Reliablity Engineering)
그동안 DevOps 담당자라고 부르짖던 사람들의 Role이 인프라 담당자인지 플랫폼 담당자인지 아니면 개발하는 운영자인지 헷갈릴때가 많았다.
갑자기 국내에서도 SRE 채용 공고가 많아지는것을 보면서 내 자신도 한번 정리를 하고 가야할것 같은 생각이 들었다.
https://docs.microsoft.com/ko-kr/learn/modules/intro-to-site-reliability-engineering/
개념정리 측면에서 위 MS Azure의 온라인 교육내용을 정리해봤다.
SRE
SRE(사이트 안정성 엔지니어링)란 조직이 해당 시스템, 서비스 및 제품에서 적절한 수준의 안정성을 달성하도록 지원하는 엔지니어링 분야이다.
출처 : https://landing.google.com/sre/sre-book/chapters/introduction/
기본적으로 운영경험이 있는 sysadmin, IT전문가, DevOps실행 담당자 등이 대상이 될 수 있다.
적절한 수준의 안정성
가장 핵심이 되는 단어는 안정성이다. 조직에서 만든 애플리케이션이 안정성이 부족하여 작동하지 않거나 불안정한 경우 실제 비즈니스에 피해를 줄 수 있다는건 누구나 알고 있는 당연한 이야기이지만 100%의 안정적인 시스템은 존재하지 않으므로 적절한 수준(정량적으로 측정하긴 어렵지만 이해관계자들이 납들할만한 수준)의 안정성을 달성하기 위한 일련의 작업들을 수행하는 것이 SRE의 기본 속성이라고 볼수 있다.
SRE는 Google에서 2003년부터 7명의 소프트웨어 엔지니어로 구성된 팀에서 시작된 이후 (자세한 내용은 위 링크 ebook 참조) Google 사내에 널리 확산되고 내부적인 문화로 조성되는 중에 밖에서는 DevOps라고 하는 문화가 동시에 확산되었다 한다. 결국 동일한 문제를 해결하기 위한 측면에서 두개의 방법론은 다르다고 봐야한다.
차이점
- SRE - 안정성을 위한 엔지니어링, DevOps - 개발과 운영조직 각각의 사일로를 해체하기 위한 문화적인 움직임
- SRE - 저는 SRE 입니다, DevOps - 저는 DevOps를 하는 운영자 또는 개발자 입니다.
- SRE - 규범으로 인식, DevOps - 문화로 인식
공통점
- 모니터링/식별 가능, 자동화
주요 SRE원칙 : 선순환
새로운 서비스의 상태의 지표는 어떻게 정의할까? 보통은 무엇을 SLI(서비스 수준 지표)로 사용할지를 정하는것으로 본다. 일반적으로 성공 및 실패 측정값(200 OK,500 Error), 응답시간(ms), 처리량 등의 조합으로 결정될 수 있다. 보통 카나리아 분석을 통해 Scoring을 한 SLI를 200 OK와 500 또는 에러코드의 비율로 결정하는 방법을 사용하는 경우가 많다.
서비스 상태를 식별하는 지표를 정하고 나면 고객이나 우리가 원하는 안정성 수준을 결정해야 한다. 개발팀과 운영팀이 같이 만든 원하는 안전성 수준을 SLO(서비스 수준 목표)라고 말하면 된다.
SLO는 Prometheus나 Datadog과 같은 모니터링 시스템을 활용하여 정확하게 측정하고 표시해야 한다. 서비스의 안정성에 대해서 명확하게 이해할수 있는 목표이기도 하다. 반드시 SLO를 만족하는지 못하는지 명확한 측정값으로 데이터가 존재해야 하고 SLO를 충족하지 못하면 문제가 있는것으로 판단하고 문제를 해결해야 한다.
오류 예산
오류 예산이라는 말을 명확히 이해하려면 흔히 고객과 체결하는 계약서 상의 명시된 서비스 가동율(SLA)을 생각하면 될 것 같다. 보통 99.9% 의 SLO를 정한다고 한다면 1년에 8시간 45분 57초의 서비스 다운타임을 허용하는 것이다. 오류 예산은 서비스의 완벽한 안정성과 원하는 안정성의 차이(100%-99.9%=0.01%)를 말한다. 0.01%로 즉 8시간정도의 오류 예산을 가지는 것은 그 시간을 모두 사용할 때까지 추가 릴리스나 패치를 진행할 수 있다는 이야기와 같다. 어떤 팀은 해당 예산을 신규 기능을 릴리스하는데 사용하기도 하고 장애가 발생했을때 문제의 원인을 발견하고 개선하는데 사용하기도 한다.
일반적으로 서비스에 대한 오류 예산이 모두 사용되면 서비스가 원하는 안정성 수준으로 돌아갈때 까지 해당 서비스의 추가적인 릴리스를 보류하는게 일반적이긴 하지만 특정기간(월 또는 분기 또는 연간) 기준으로 계산되기 때문에 서비스 안정성이 정상 상태라면 오류 예산은 다시 주어지게 되므로 선순환 구조를 가진다고 볼 수 있다.
비난 없는 장애 회고
일반적으로 비즈니스에 크리티컬한 장애가 발생했을때 사후 분석(회고)을 하게 되는데 이때는 비난 없는 분석을 해야한다. 오래전 기억이지만 예전 직장 특정팀에서는 장애가 발생하면 유관자들이 모두 엔지니어 책상 뒤에 서서 모든 화살과 눈총을 주기 때문에 도저히 일을 할 수 없게 만든 경우가 많았었다.
특정 운영자의 작업 실수로 인해 장애가 발생했다 하더라도 해당 이벤트가 발생하게 된 프로세스나 기술기반에 실패 원인을 파악하는데 중점을 두어야 할것이다.
시스템의 안정성을 저하시키고 서비스를 중단시킨 작업(릴리스, 패치 등)을 사유로 개인에게 페널티를 주거나 고과에 반영하는 방법은 장애로 부터 교훈을 얻을수가 없고 해당 담당자의 충성도나 생산성 저하를 유발하는 안좋은 장치가 될 수 있다. 내 경험이기도 하지만 한동안 두려워서 아무 변경도 하지 못하는 경우가 종종 있었다.
회사나 조직, 팀은 시스템 중단으로부터 교훈을 얻고 지속적으로 시스템을 개선할수 있다. 적절한 분석을 통해 후속조치를 수행함으로써 실패를 수용하는 것이 SRE의 핵심 원칙이다. 이러한 내용을 모두에게 공유하고 타 조직이나 팀에게 인사이트를 제공하는 선순환 구조를 만드는것 또한 SRE의 기본 원칙이라고 볼 수 있다.
주요 SRE원칙 : 사람측면
Toil(수고스런 일, 번거로운 작업)
항상 SRE에서는 Toil에 초점을 맞춰야 한다. Toil은 사람이 수행하는 운영 작업 중 특정한 패턴이나 특성이 있는 작업을 말한다. 종종 반복적이고 자동화 될 수 있는 작업일지라도 대부분 수동작업으로 처리를 한다. 서비스의 규모가 커지거나 고객이 많아지게 되면 보통 우리가 이야기 하는 티켓(또는 SR)의 수가 많아지고 공수가 많이 필요하게 된다.
배포때마다 Config를 적용하거나 계정 등록, 볼륨이나 디스크 프로비저닝 등 수동으로 처리해야하는 모든 작업이 운영자에게는 부하로 다가올수 있다. 이러한 반복적인 작업을 티켓시스템을 통해 처리를 하게 되면 티켓 생성, 작업계획서 작성, 검토, 승인 단계를 그때 마다 해야하는 아주 번거로운 작업(Toil)을 해야한다.
SRE는 최대한 이러한 반복적이고 번거로운 작업을 제거하기 위해 노력해야하고 자동화와 Self-Service로 개발자가 편하게 직접 사용할수 있도록 환경을 제공해 주어야 한다. 이러한 요청이나 티켓을 자동으로 처리할 수 있으면 조금 더 생산적인 일을 수행할수 있다.
위에서 이야기한 적절한 안정성과 비슷한 맥락으로 생각하면 될 것 같다. 번거로운 작업을 없애는것이 다른 중요한 작업보다 우선순위가 떨어지기도 하지만 서비스 상에서 Toil을 제거하는것도 SRE의 주된 업무이다.
운영작업의 비율
Toil을 제거하거나 서비스/시스템 안정성을 개선하기 위해 SRE는 장애를 해결하고 티켓을 처리하는 시간 비중을 50%를 넘겨서는 안된다. 티켓이 필요하지 않도록 개발자 Self-Service를 구성/제공하고 효율성을 증대시키기 위해서 IaC등(Shell, Ansible, Terraform) 과 같이 자동화를 위한 코드를 만드는데에도 집중을 해야한다.
정리
지금까지 SRE에 대해서 간단하게 소개하고 이해하는 측면에서 정리해 봤다.
그림과 같이 서비스 안정성 계층 구조에서는 기본적으로 모든 서비스를 모니터링 하는 시스템을 갖추어야 한다고 말한다. 모니터링 시스템이 준비가 되면 서비스에 대한 SLI, SLO를 만들고 모니터링 시스템에서 구현하는것이 첫번째 SRE를 적용하는 방법이라고 할 수 있을 것이다.