[SRE] SRE란 (Site Reliability Engineering)

https://bcho.tistory.com/1325

SRE - #1 SRE/DEVOPS의 개념과 SRE는 무엇을하는가?

 

DevOps와 SRE

• DevOps 엔지니어(운영)의 역할
  • DevOps는 개발과 운영이 하나의 팀으로 묶여 개발 사이클을 빠르게하는 조직구조이자 문화
  • 클라우드로 개발자가 직접 배포/운영이 가능
  • 그러나 시스템이 커지면서, 안전성을 중요하게 생각하는 "운영"의 역할이 여전히 필요
• SRE
  • 개발자가 스스로 서비스를 운영하려면 애플리케이션을 빌드/배포/모니터링 할 수 있는 자동화 플랫폼이 필요
  • SRE는 이 플랫폼을 개발하는 역할
  • 큰 장애 처리/배포에는 SRE 엔지니어가 관여하지만 개발팀 스스로 할 수 있도록 비중을 줄여나감
• DevOps와 SRE
  • 구글이 DevOps에 적용하기위한 구체적 practice와 가이드 (Devops의 개념에 대한 실제)
  • 구글도 DevOps 적용 중에 개발자팀은 속도 / 운영팀은 안전성에 무게를 두어 문제가 발생
    - 이 문제를 풀고자 한 시도가 SRE
• SRE의 목표
  • 1) 가용성에 대한 명확한 정의 (SLI, Service Level Indicator)
    - 가용성 측정을 위해 어떤 지표를 사용할지 정의
  • 2) 가용성 목표 정의 (SLO, Service Level Objective)
    - 지표에 어느 수준까지 허용할지 정의
  • 3) 장애 발생에 대한 계획
    - 문제 상황에서의 의사 결정

 

SRE의 역할

https://bcho.tistory.com/1325

• Metric & Monitoring
  • 모니터링 지표 정의
  • 지표를 모니터링 시스템에 등록
  • 지표를 분석하여 인사이트 확보
    - 장애가 나는 지표가 무엇인지
    - 이러한 지표를 어떻게 개선할 수 있는지
    - 모든 것을 데이터화하고, 의사결정은 데이터 기반
• Capacity Planning (용량 계획)
  • 시스템 운영에 필요한 충분한 하드웨어 리소스(서버, CPU, 메모리, 디스크, 네트워크 등)를 확보
  • 리소스 요청에 유연한 대응이 필요
    - 비즈니스 성장에 의한 일반 증설
    - 이벤트, 신제품 출시 등 스파이크성
  • 이들의 함수 관계
    - 시스템에 필요한 용량
    - 확보된 리소스 용량
    - 동작하는 소프트웨어의 최적화
• Change Management (변경 관리)
  • 소프트웨어 배포/업데이트 영역 (+설정/인프라 변경)
  • 시스템 장애 원인의 70%가 "시스템 변경"
  • 따라서 시스템 안전성에는 변경 관리가 중요하며, 휴먼 에러가 주요 원인으로 자동화로 개선
  • 자동화의 best-practice
    - 점진적인 배포/변경 (카나리, 롤링)
    - 배포 후 장애발생시 빠르고 정확하게 문제 파악
    - 문제 발생시 빠르게 롤백
• Emergency Response (장애 처리)
  • 시스템 안전성은 이들의 함수 관계
    - MTTF(Mean Time To Failure) : 장애가 발생하지 않고 정상 동작한 시간
    - MTTR(Mean Time To Recover) : 장애가 났을 때 복구 시간
  • 특히 MTTR, 장애시 가급적 빠르게 정상화하여 MTTR을 줄이는 것이 주요 목표
  • 사람이 컨트롤하지만, 각 단계를 자동화 및 메뉴얼화 필요
    - Playbook
• Culture
  • SRE 문화를 전반적으로 만들고 지켜나가는 작업
  • 장애 발생 시간이 지정한 시간(Error budget)보다 길어지면, 신규 기능 배포를 중단하고 시스템 안전성을 올리는데 집중하는 방식
  • 이런 문화를 만드는 3가지 가이드
    - 데이터 기반 합리적 의사결정
    - 비난 없이 장애를 해결
    - 책임을 나누어 가지는 문화