Skip to main content

사이트신뢰성엔지니어링(SRE)의 요약

Jpub에서 발간한 사이트신뢰성 엔지니어링에 대해 읽고, 자체적으로 해석한 결론입니다. (정확하진 않을수 있습니다. 말 그대로 자체 해석...)

구매는 요기 - http://www.yes24.com/Product/Goods/57979286

SRE란? 구글에서 시스템의 안정성을 증가시키기 위해 활동하는 역활로, Devops보다 한단계 더 발전한 모델이라고 합니다. 

SRE역활

  1. Site Reliability Engineer 의 약자로, 소프트웨어 엔지니어링과 IT인프라 운영 그 중간쯔음에서 일하는 역활로, 직접 만든,in-house 혹은tool이나 오픈소스를 활용해 시스템의 안정성과 확장성을 유지하고 개선하는 업무
  2. Devops/SRE의 업무 목표는 신속한 서비스 제공을 위해 기업문화, 자동화툴을 이용한 플랫폼 설계/구축 하는 공통적인 업무영역이 있는데, 접근하는 방법이 살짝 다른듯. 어떠한 문제와 개선을 하기 위해서는 "무엇을 해야 하는지?-devops"devops관점"과 "어떻게 할 수 있는지-SRE"SRE관점"의 차이점이 있는듯 하다.
  3. 기본적으로 기존 운영팀이 처리하던 업무를 이어서 수행하게 되는데, 소프트웨어 엔지니어들이 모인팀이기 때문에 자동화된 소프트웨어를 설계 / 구현하는 팀이다. 다만 전화응대, 수작업, 티켓처리등의 기존 운영팀이 수행하던 업무는 최대 50%정도의 시간만 투입해야 자동화된 시스템 개발할 수 있는 여력을 확보할 수 있게 된다
    1. 운영성 업무를 수행할때는 업무시간에는 최대 2건의 업무만을 담당하게 하고, 업무를 배정받은 엔지니어는 정확 + 신속하게 업무를 수행하고 사후섬토=포스트모텀(Postmorterm)1) 을 작성하도록 한다. 2건이 넘어가는 경우 업무의 과중으로  문제점에 대한 관찰력이 저하되었는것을 구글은 경험했다.
  4. 가용성, 응답시간, 성능, 효율성, 변화관리, 모니터링, 장애대응 그리고 수용량 계획에 대한 ownership을 가지게 되는데 이 부분은구체적인 사항은 조금 더 학습이 필요한 영역이다.

기업문화의 변화

  1. 포스트모텀 작성시 특정절차에 대해 비난해서는 안되고 실수를 공유하여 스스로 고쳐나갈 수 있도록 유도해야 동일한 문제가 발생시 대응방안들의 절차들이 도출될 수 있다
  2. 100% 신뢰성을 가질수 있는 시스템은 없다. 왜냐하면 사용자와 서비스간의 여러가지 요소들(사용자 단말, ISP, 가정의 인터넷, 전력 등)이 있기 때문에 이런 문제들을 해결하기 위해 에러 예산(Error budget)이라는 개념을 도입하였다. (앞으로 기술한 내용중의 에러예산에 대한 내용이 자주 나올예정이다.)
  3. 시스템을 구성할때 목표 가용성을 설정해야 한다, 가용성 목표가 정의되면 에러 예산은 1에서 목표 가용성을 뺀 값으로 확보하면된다. 예를들어 목표 가용성이 99.99%라면, 에러예산은 0.01%인 셈이고, 이 에러예산을 초과하지 않는 범위내에서 엔지니어링 업무를 수행하면 된다.

에러예산의 활용방안

  1. 개발팀의 업무 목적은 새로운 기능을 출시하여 새로운 사용자를 확보하려고 한다. 때문에 SRE는 새로운 기능을 출시하기 위해 감수해야할 리스크를 활용하는데 사용하는것이 가장 이상적인 활용방안

업무 내역

  1. 모니터링
    1. 서비스의 소유자가 시스템의 상태와 가용성을 점검하고, 모니터링 전략이야기 말로 철저한 계획하에 수립되어야 하는 업무영역이다. 현재 대부분은 특정 임계치를 초과하거나 상태의 변화가 감지되면 noti하는 방식으로 처리하고 있는데, 이런 방법은 효과적인 해결방안이 아니다. 사람이 개입해서 판단하고 결정해야 하는 절차 자체가 문제가 있는 것이다.
    2. 신뢰성이란 문제가 발생하기전 동작했던 평균시간( MTTF)과 평균 수리시간(MTTR)을 의미한다. 이중에 긴급대응의 효율성을 나타내는 수치는 MTTR이 된다.
      사용자가 개입하여 장애를 처리하는것이 시스템이 직접 처리하는 경우보다 MTTR이 3배 이상 증가하는것으로 구글은 검증하였고 실력이 있는 엔지니어가 처리하는 절차도 뛰어나나 잘 만들어진 장애 대응 문서로 훈련된 엔지니어가 보다 더 수행절차가 더 뛰어났다. 때문에 엔지니어들의 장애상황에 대응할 수 있도록 훈련을 지속하고 있다.
  2. 변화관리
    1. 구글 경험상 70%가량의 장애는 서비스 중인 시스템의 변화로 인한 문제로 제품의 단계적 출시, 문제발생을 빠르고 정확하게 도출하고 이전버전으로 롤백하는 절차들을 수행하면 장애상황의 최소화가 가능하다.
  3. 수요예측과 계획수립
    1. 예측과 계획은 정확하지 않을수 있는 지표때문인지 상당수 수용력을 확보하기 위한 과정을 준비하지 않고 있다.
    2. 수용계획은 자연젹 성장(사용자가 활용하면서 생기는 성장)과 인위적 성장(새로운 기능 추가) 모두 고려해야 한다,.

업무지표

  1. 안정성과 확장성을 수행하기 위해서는 기준되는 지표가 필요한데, 여기서 나오는 용어가 SLA / SLI / SLO 3가지 용어
    1. SLA(Service Level Agreement) - 운영팀과 고객간의 서비스 수준에 대해 품질, 가용성 등 주체적인 기준을 설정하는 지표 (구글의 경우 법적인 효력이 있기 때문에 쉽게 변경해서는 안됨)
    2. ,SLI(Service Level Indicator) - 서비스 수준을 측정하는 지표.. 예를들어 대기시간, 가용성, 처리량 등의 자료가 포함
    3. SLO(Service Level Objective) - SLI에서 도출된 지표를 어느정도의 수준으로 품질을 정할것인지 정하는 기준.
  2. 대충이렇게 정리할 수 있을듯 하다.


Reference

 

Back to top