Part 2. SRE란 무엇일까?

https://sre.google/sre-book/being-on-call/

 

DevOps에 대해 공부하는 도중에 SRE란 개념이 나왔고 이 개념이 저를 햇갈리게 했습니다.

DevOps == SRE 인 것 같았거든요. 그래서 이 둘의 차이점을 알아내려고 이것저것 알아봤습니다.

이 둘이 의미하는 뜻은 명백히 다르지만 하는 역할은 비슷합니다. 

https://bcho.tistory.com/1325 블로그에서 설명을 인용하자면

"SRE implements DevOps" 입니다. 

즉, 광범위한 DevOps의 문화중 일부분을 구현하는 것이 SRE입니다.

 

SRE

SRE는 Site Reliability Engineering의 약자로 처음 이 개념을 제시한 곳은 Google입니다. 

해당 개념은 DevOps와 굉장히 밀접해 있으며, 추 후 DevOps vs SRE에 대해서 다룰 예정입니다.

 

SRE의 궁극적인 목표는 고객들에게 신뢰성 있는 Site(Service)를 제공해주는 것입니다.

즉, 트래픽이 순간적으로 몰려도 사이트에 접속하는데 이상이 없어야 하며,

자연재해로 인해 서버가 터져도 문제 없이 서비스를 제공해야 합니다.

팀 내부든 외부든 일상적으로 발생하는 오류에 대해 분석하고 이를 자동화시켜 해결해야 합니다.

여기서 자동화란 말은 오류가 나와도 자동으로 recovery해야 한다는 뜻입니다.

 

그리고 이러한 개념은 서비스를 이용하는 클라이언트들이 많아질수록 중요합니다.

때문에 구글, 네이버, 토스, 카카오 등에서 SRE를 도입하고 있으며, 실제로 SRE를 구현하기 위해 노력중입니다.

 

그럼 SRE를 구현하기 위해선 무엇이 필요할까?

SRE를 정의하기 위해 Google은 SLI, SLO, SLA에 대해 정의하고 설명하고 있습니다.

1. SLI

SLI는 (Service Level Indicator)의 약자로 사용자에게 제공되는 서비스의 일부를 측정하는 것입니다.

즉, 요청 대기 시간(요청에 대한 응답을 반환하는 데 걸리는 시간), 수신된 모든 요청의 일부로 표시되는 

오류율과 초당 요청으로 측정되는 시스템 처리량을 SLI로 간주합니다.

이런 측정 값들을 Metric으로 분류하고 데이터화 시킵니다.

2. SLO

SLO는 (Service Level Object)의 약자로 시스템에서 기대되는 가용성을 설정한 목표입니다.

즉, 얼마만큼 안정된 서비스를 제공할 것이냐 입니다. Google에서는 이를 yield라고 표현하고 있으며,

100%가용성은 힘들지만 99.99%, 99.95%정도의 가용성을 유지할 수 있다고 설명합니다.

(구글은 현재 99.95% yield를 목표로 하고 있다고 합니다.)

 

예를 들어, 웹 애플리케이션의 SLO가 1주일 중 99%에 해당하는 시간 동안,

2초 이내에 비디오 재생을 시작하는 것이라고 가정하겠습니다. 

SLI는 웹사이트에서 2초 이내에 재생을 시작한 비디오의 비율을 측정합니다.

만약 설정한 SLO에 SLI가 도달하지 못한다면 시스템적으로 개선이 필요할 것입니다.

 

3. SLA

SLA는 (Service Level agreements)의 약자로 고객이 서비스를 사용할 때 기대하는 서비스 레벨을 정의하고,

사용자와 명시적 혹은 묵시적 계약을 하는것을 말합니다.

사실 SRE는 SLA구성에 관여하지 않습니다. 이 부분은 비즈니스적인 측면이 더 강하기 때문입니다.

하지만 SLA가 필요한 이유는 SLA를 기반으로 SLO를 정하고 SLI를 측정할 수 있기 때문입니다.

 

구글 또한 사용자와 SLA를 명시적으로 체결하고 있지는 않습니다. 하지만 어떠한 이유로 인해

검색을 사용할 수 없으면, 평판이 나빠지고 광고 수익이 감소합니다. 때문에 묵시적으로 SLA를 정하고 이를 이행합니다.
Google for Work와 같은 다른 많은 Google 서비스에는 사용자에 대한 명시적인 SLA가 있습니다.

(https://workspace.google.com/terms/sla.html)

 

 

SRE를 수행하기위해서 SLI, SLO, SLA에 대해 알아봤습니다.

그럼 SLO, SLI를 수행하기 위해서 어떠한 노력이 필요할까요?

 

Collecting Indicators

SLA를 만들고, 그에 기반하여 SLO를 정의합니다. 

SLO를 기반으로 SLI를 정하죠.

 

그럼 SLI는 아무 Metric이나 측정하면 될까??

우선 Metric을 측정하려면 성공한 갯수와 총 갯수를 알 수 있는 Metric을 기본으로 합니다.

그래야 Raito(비율)을 산정할 수 있기 때문입니다.

구글에선 다음과 같은 Metric을 SLI로 선정하고 있습니다.

• 성공한 HTTP 요청 수/ 총 HTTP 요청(성공률)
• < 100ms 안으로 성공한 gRPC / 총 gRPC 요청
• 검색에 사용된 전체 코퍼스(글, 단어 등) / 총 검색 결과 수(잘못된 검색 포함)
• 10분 이내의 최신 재고 데이터를 사용한 상품 검색의 "재고 확인 횟수" 요청 수 / 총 재고 확인 요청 수
• 양호한 사용자 시간(분) / 총 사용자 시간(분)

이런식으로 SLI를 정합니다. 또한 어디까지 성공의 범위로 정할지도 선택해야 합니다.

(예를들어 HTTP Status code 2xx, 3xx, 4xx, 5xx가 있다면 어디까지 성공으로 간주할지 등...)

 

SLI는 단순해야 하며, 복잡성을 띄면 안됩니다. 즉, 이것 저것 측정하는 것은 오히려 Metric을 분석하는데 방해가 될 수 있습니다.

 

또한 Metric을 기반으로 데이터를 분석할 때 평균적으로 분석하면 안됩니다.

SLO를 평균 100ms < 로 정했다고 예를 들겠습니다.

24시간동안 Response에 대한 Latency가 평균적으로 100ms < 이라고 해도, 이 지표를 그대로 믿어선 안됩니다.

00시 ~ 17시 까지는 평균 50ms < 이지만 18시 ~ 20시 까지의 Latency가 300ms < 라고 한다면,

이 특정 시간대에 대해서 개선이 필요할 것입니다. 

 

Emergency Response

SRE는 가용성을 유지해야 합니다.

가용성이 유지되어야 한다는 말은 시스템이 장애 없이 어느정도 시간동안 정상으로 동작하는지를 의미합니다.

가용성을 계산하는 방법은 다음과 같습니다.

http://www.ktword.co.kr/test/view/view.php?m_temp1=4865

MTBF (Mean Time Between Failures, 평균 무고장 시간) =  고장이 발생 후 다음 고장까지 유지된 평균 시간

MTTR (Mean Time To Repair, 평균 복구 시간) = 고장이 감지된 후 복구가 될 때까지의 시간

MTTF (Mean Time To Failures, 평균 고장 시간) = 수리가 불가능한 시스템의 평균 고장 시간
(MTTF는 주로 수리가 불가능한 장비를 교체해야 할 때 사용되는 것 같습니다.)

 

SRE는 장애에 민감해야 합니다. 때문에 운영중인 시스템의 Availability를 계산하고, Availability의 평균 값을 높여야 합니다.

그렇기에 DR훈련을 해야하고, System architecture에 대한 이해가 필요합니다. 

 

하지만 모든 장애에 민감하면 안됩니다.
장애에도 등급을 나눠야 하며, 단순하게 복구되는 장애나 쉽게 처리되는 장애에 대해서는 높은 등급의 위험성을 부여할 필요는 없습니다.

구글에서는 SRE를 교대근무로 편성하여 모니터링과 장애 발생에 대해 대처하고 있습니다.

하지만 그들도 오전 12시 이후에는 근무하는 일이 없어야 한다고 말하고 있습니다.

 

또한 SRE의 이상적인 문화는 모든 개발자, 운영자, SRE 엔지니어들이 장애에 대해 인식할 줄 알아야 하고,

장애가 발생했을 때의 책임을 특정 사람에게 부여하는 것이 아닌, 팀 전체에게 부여한다는 점이어야 합니다.

때문에 오류가 발생했을 시 SRE가 모두 처리하는 것이 아닌, 협업을 통해 문제를 해결해야 할 수 있어야 합니다.

 

개인적으로 이 부분에 대해서는 정의를 내리기 어려울 것 같습니다. 어느 누가 어디까지 책임을 져야할지 말입니다.

또한 문제가 발생했을 시 모든 인원이 그 문제를 해결하기 위해 리소스를 투자한다면, 낭비가 될 수 있습니다.

그렇기에 적절한 분배가 되어야 하는데, 이건 팀간의 조율과 회사 방침에 따라 정해져야 할 것으로 보입니다.

SRE skills

SRE는 어떤 스킬들을 가져야 할까?

• Operation
  기본적으로 운영에 대한 지식이 있어야 합니다. 운영을 하면서 발생할 수 있는 문제점, 
  DR훈련, Network troubleshooting 등을 능숙하게 할 줄 알아야 합니다.
• Software
  회사 제품의 어플리케이션이 어떤식으로 동작하는지 이해가 필요합니다.
  필요에 따라서 해당 코드를 수정할 수 있어야 하며, 문제 발생시 문제 발생 지점을 신속하게 찾을 수 있어야 합니다.
• Monitoring
  지속적인 모니터링이 필요합니다. 모니터링을 통해 장애 발생을 미연에 방지할 수 있으며, 부족한 점은 보완할 수 있습니다.
  뿐만 아니라 필요한 SLI를 선정해 꼭 필요한 Metric을 수집해야 합니다.
• Automation
  SRE는 많은것을 자동화 할 줄 알아야 합니다. 반복적으로 고치는 일들, 수동적으로 행해지는 일들에 대해 자동화 해야하며,
  이런 불필요한 리소스 낭비를 최소한으로 줄여야 합니다. 이로 인해 팀원들의 업무 효율성은 증가될 것입니다.
• System architecture
  인프라 설계를 어떻게 할 것이며, 어느 부분에서 분산처리를 할지, 어느 부분에서 Auto scaling을 할지, 어느 부분을 보완할지 등...
  또한 IaC를 통해 협업을 해야하며, 이를 자동화 시켜야 합니다. 뿐만 아니라 System architecture를 파악하면,
  장애발생시 문제가 되는 부분을 빠르게 찾을 수 있습니다.

참고 : https://sre.google/workbook/team-lifecycles/

 

결론

사실 SRE에 대한 정의와 방법론은 너무나도 많고, 이를 한 페이지에 다 담아내기 어렵습니다.

이 글의 목적은 "SRE가 무엇인지?, SRE는 이런 것들을 하는 직업이구나..." 정도로만 이해할 수 있으면 그것으로 만족합니다.

 

제가 적은 SRE skills에서 필요한 기술들은 더 많습니다.

예를들어 DB성능을 업그레이드 하기 위한 DB Upgrade,
Redis용량을 늘리기 위한 migration, 

Availability를 측정하기 위한 스트레스 테스트,

사후 문화를 가져가기 위한 행동 등...

 

SRE를 찾아보고 공부하면서 느낀것은...

"스팩트럼이 넓어야 하는 직군이다."

"DevOps문화를 만들어가기 위한 하나의 직군이다."

"문화를 만들어가야 한다. 즉, 변화에 민감하지 않아야 하며, 항상 개선을 생각해야 한다."

정도입니다. 그 외에도 많지만... 핵심이라 생각되는 부분을 적었습니다.

 

DevOps와 SRE는 성과를 내기 어려울 것 같다고 생각을 합니다.

외부적으로 티가 나질 않으니깐요. 뿐만 아니라 둘 다 Dev와 Ops다보니, 

"전문성이 떨어지는 것이 아닐까?", "너무나 많은 일에 관여하지 않을까?"

라는 생각이 듭니다.

 

다행히도 이 부분에 대해서 구글도 인지하고 있으며, 해결책을 제시하고 있습니다.

몇 가지 적어보자면...

1. 베테랑 엔지니어를 팀에 합류시켜 전문성을 길러라.

2. 너무 많은걸 관여하다 보면 업무 효율이 떨어질 수 있다. 여러 프로젝트가 있다면 하나의 프로젝트에 집중해라.

3. 효율성을 획기적으로 개선하고, 업무의 자동화를 해라. 시스템의 불안정성을 영구적으로 제거한 SRE는 축하받아야 한다.

등.... 

 

SRE가 왜 나왔을까?... 생각을 해보면 결국, 서비스 규모가 커지면서 생긴 자연스러운 직군이라 생각이 듭니다.

서비스 규모가 커질수록 이용자는 많아지고, 이용자가 많아지면 자연스럽게 불만, 건의사항이 많아지죠.

이러한 것들을 Claim으로 정의할 수 있을 것 같습니다. 

결국 이러한 Claim을 줄이는 것이 장기적으로 봤을 때, 회사의 이미지, 신뢰성, 더 나아가 회사 수익에 영향을 미치기 때문이죠.

이러한 것들을 개선하고자 나온게 DevOps와 SRE가 아닐까 생각을 합니다.

팀 내부적으로 문화를 개선하면서, CI/CD를 통해 변화를 점진적으로 가져가면서, 자동화를 통해 내부, 외부적으로 개선할 수 있기 때문입니다.

 

SRE는 매력적인 직군이라 생각을 하면서도 전문성이 뛰어난 엔지니어가 맡아야 한다고 생각합니다.

결국 운영과 개발을 전부다 해야 하거든요. Google에서도 DevOps or SRE엔지니어에게 코드 수정권한을 적극 권장하라고 합니다.

부하 분산을 하기 위한 Infra architecture를 구성해야하고 모니터링 해야합니다.

또한 전문가를 배치시키고, SRE 팀원들의 교육, 훈련에 투자하라고 합니다. 

 

긴 글 봐주셔서 감사합니다.

다음은 DevOps vs SRE에 대해 적어보도록 하겠습니다.

 

참고

Google SRE : https://sre.google/sre-book/introduction/

Google - Site Reliability Engineering

Data Dog : https://www.datadoghq.com/blog/establishing-service-level-objectives/

Service level objectives 101: Establishing effective SLOs

 

조대협님 블로그 : https://bcho.tistory.com/1328

SRE #3-SRE의 주요 지표 SLI/SLO (Service Level Indicatior, Service Level Objectives)

Toss : https://toss.im/slash-21/sessions/1-4

SRE 사례 소개

Naver : https://d2.naver.com/helloworld/2047663