SRE 란

October 26, 2021 6 분 소요

SRE

INDEX

용어 정의
소개
원리와 원칙
관리
사례
참고 자료

용어 정리

SRE
- Site Reliability Engineering
- 의미 : 구글의 DevOps 환경 실현 방법론이다.
DevOps
- Development + Operations 의 합성어
- 의미 : 개발자와 운영담당자 등 IT전문가들의 소통 / 협업 / 통합을 강조하는 개발환경이나 문화를 이야기 한다.
- SW개발조직과 운영조직간의 상호의존적으로 대응을 하며, 조직이 빠른 시간에 개발 및 배포하는 것을 목적으로 하고 있다.
MTTF
- Mean Time to Failure
- 의미 : 평균 고장(장애)시간
  - 첫 정상 사용 시간 부터 첫 고장(장애)시간까지
MTTR
- Mean Time To Repair
- 의미 : 평균 수리(복구)시간
  - 고장수리(장애복구)까지 걸리는 시간
MTBF
- Mean Time Between Failure
- 의미 : 평균 고장 시간 간격
  - MTTR + MTTF = MTBF
Provisioning
- 의미 : 자원을 미리 준비 해놓은 상태에서 요청이 들어왔을때, 해당 요청사항에 맞게 자원을 공급하는 것
- 종류
  - 서버 자원 프로비저닝
  - OS 프로비저닝
  - SW 프로비저닝
  - 스토리지 프로비저닝
push on green
- 의미 : 안전하고 통제된 방식으로 서비스를 자동으로 배포하고 업데이트하는 프로세스이며, 최소한의 사용자 개입을 통해 서비스 배포 중 다운 타임 최소화 및 장애상황에 빠른 대응 및 롤백을 지원하기 위한 방법이다.
- 만약 새로운 WEB 및 WAS 서버를 push on green으로 배포할 떄.
- 1차 - 초기 상태
- 2차 - 신규 서비스 추가
- 3차 - 신규 서비스 연결
- 4차 - 기존 서비스 연결 해제
- 5차 - 기존 서비스 삭제
SLA
- Service Level Agreement -> 서비스 수준 협약
- SLO를 만족했을때 또는 만족하지 못했을 경우, 보상에 대한 명시적 또는 암묵적인 계약
SLI
- service level indicator -> 서비스 수준 척도,
- SLO를 설정할수 있는 기준 지표
- 서비스 수준을 판단할수 있는 정량적으로 측정한 값
  - 서비스가 사용 가능한 상태로 존재하는 시간의 비율 -> 가용성
  - 요청에 대한 응답속도
  - 전체 요청수 대비 에러율
  - 시스템 처리량
SLO
- service level objective -> 서비스 수준 목표
- SLI에 의해서 측정된 값에 대한 목표 값 또는 범위이다.
  - 표현 방식 : SLI <= 목표치 or 목표치_MIN <= SLI <= 목표치_MAX
업타임 : 서비스가 동작을 시작한 이후 장애 없이 실행 중인 시간
다운타임 : 서비스가 장애 등으로 인해 실행이 중단된 시간
기술부채 : 제품이나 서비스에는 영향이 없지만 엔지니어 관점에서 기술적으로 해결이 되지 않으면 향후 문제가 될 수 있는 부분들

SRE 소개

SRE 란
1. SRE 의미
  - class SRE implements DevOps
  - “희망은 전략이 아니다.” -> 보수적인 SRE가 남긴 말.
2. SRE의 목적
  - 서비스는 100% 안정성을 보장 할 수 없다.
  - 시스템이 자동화되는(automated) 것이 아니라 자동적(automatic)이 되는 것이다.
  - 서비스에 대한 장애 상황을 허용해서 적정 수준의 가용성을 어떻게 확보하고 보장 할것인지에 대한 가이드를 만드는 것이다.
  - 시스템운영/관리팀과 개발팀이 분리되어 있어 각 팀의 배경 지식등의 차이로 인해 문제의 해결방향을 서로 다르게 인식하고 서비스의 안정성 등의 목표를 다르게 설정할수 있다.
  - 개발팀은 언제든지 방해 없이 원하는 서비스를 출시하려고 하고 시스템운영/관리팀은 시스템이 서비스를 시작하게 되면 시스템 변경을 원치 않다.
SRE의 역활
1. 가용성(availability)
  - 에러 예산(error budget)
    - 개발팀과 운영팀 사이에 각팀이 목표를 달성하는 과정에 발생하는 여러가지 문제점들을 해결하기 위한 개념
    - 신뢰성 목표를 100%로 설정하는 것은 잘못된 목표설정 관찰 결과로 유래 됨.
    - 이 에러 예산을 통해서 ‘무정지 시스템’과 같은 목표를 설정하지 않는다.
  - 응답시간(latency)
    - http 응답시간 등
  - 성능(performance)
    - 서버 스펙등.
2. 효율성(efficiency)
  - 서비스에 대한 지속적인 모니터링을 이용해서 서버의 성능을 지속적으로 개량하여 수용력을 확보해서 효율성을 향상시킨다.
3. 변화관리(change management)
  - 수용량 계획과 변화 관리 이 2가지를 합쳐서 프로비저닝(provisioning)이라고 하며, 필요한 시점에 최대한 빠르게 수용량이 증가하여 적절한 수용량을 확보하고 빠른 수용량 증가를 위해서 추가되는 여러 인스턴스(Server, application 등)의 환경설정 정보등 기존 시스템의 변경사항이 항상 최신상태이며, 올바르게 동작한다는 것을 확인하는 과정을 의미한다.
4. 모니터링(monitoring)
  - 최우선 수단 중 하나로 서비스에 대한 시스템의 상태와 가용성을 지속적으로 점검 하는 것.
  - 가능한 사람이 관여하여 장애를 판단하고 대응하는것을 지양해야한다.
  - 모니터링 결과는 3가지로 압축 할 수 있다.
    1. 알람 -> 문제 발생 시 사람이 즉각적으로 투입되어 대응 할 것을 알린다.
    2. 티켓 -> 문제 발생 시 사람의 대응이 필요하지만 즉각적인 대응은 필요하지 않는 상황을 의미한다. 즉 시스템이 자동으로 문제 해결은 불가능하지만 하루나 2일 내에 대응하도 특별한 문제가 없는 경우
    3. 로깅 -> 누군가가 이 정보를 반드시 확인할 필요는 없지만 향후 분석이나 조사를 위해서 기록되는 내용. 즉 알람 발생으로 사람이 대응하면서 확인하기 전까지 굳이 로그 분석을 하지 않아도 되는 내용
5. 위기 대응(emergency)
  - 기능/서비스 장애가 발생한 시점 부터 정상화 되기 까지의 시간이 사이트의 신뢰성을 판달할수 있는 근거 중 일부 가 될 수 있다.
6. 수용량 계획(capacity planning)
  - 많은 사용자가 서비스를 이용하면서 발생하는 자연적 증가에 따른 계획과 마케팅 또는 사업부 등의 이벤트로 인해서 급증하는 인위적 증가 까지 이 모두를 고려하여 계획 해야한다.

원리와 원칙

서비스 수준 목표
1. 서비스 수준 척도(SLI)
  1. 의미 : 서비스 수준을 판단할수 있는 몇가지 정량적으로 측정한 값.
  2. 핵심 SLI
    1. 가용성 : 서비스가 사용 가능한 상태로 존재하는 시간의 비율 (수율이라고 하기도 한다.)
    2. 내구성 : 데이터 저장소 스세템에서 오랜 시간 에 걸쳐 데이터를 보관하는 기준
    3. 응답속도 : 요청에 대한 응답이 리턴되기까지의 시간
    4. 에러율 : 시스템에서 수신한 전체 요청수 대비 발생한 에러에 대한 비율
    5. 시스템 처리량 : 시스템이 초당 처리할수 있는 요청수
2. 서비스 수준 목표(SLO)
  1. 의미 : SLI에 의해 측젗된 서비스 수준의 목표값 또는 일정 범위 값
  2. SLI <= 목표치 OR 최솟값 <= SLI => 최댓값
3. 서비스 수준 협약(SLA)
  1. 의미 : SLO를 만족 했거나 하지 못했을 경우에 대한 댓가를 사용자와의 명시적 또는 암묵적인 계약\
  2. SRE는 SLA 체결에는 관여하지 않지만 SLA 체결을 할때 필요한 객관적인 정보를 제공해주고 이 정보를 SLO로 제공할수 있어야한다.
4. 지표 설정
  - 시스템 모니터링을 통해서 추적하고 정량적으로 표현할 수 있는 모든 지표를 SLI로 취급 하지 않아도 된다.
  - 운영자 또는 개발자가 원하는 것을 명확히 파악하여 적절한 지표들은 선택해야한다.
  - 지표가 너무 많으면 중요한 지표에 집중하기 어렵고, 너무 적으면 중요한 지표를 놓치게 된다.
삽질(toil)
1. 정의 : 서비스를 운영하는 것과 직접적으로 연관이 있으며, 수작업 / 반복적 / 자동화 가능 / 사후대처 / 지속적인 가치 결여 / 서비스 성장에 따라 지속적으로 늘어나는 업무 등 중 하나 혹은 그이상 연관될 때.
  1. 수작업 : 자동화된 작업을 실행하기 위해 수작업으로 스크립트를 실행하는 경우(crontab에 스케쥴 미등록)
  2. 반복적 : 단순한 명령어을 반복적으로 입력해야되는 일
  3. 자동화 가능 : 인간의 판단에 의해 실행 되어야만 하는 스크립트
  4. 사후 대처 : 미리(proactively) 처리 할수 있는 일이 아니라 업무를 방해(interrupt)하며, 사후(reactive)에 처리하게 되는 일
  5. 지속적인 가치 결여 : 작업이 종료 후 서비스가 변화 없이 같은 상태를 유지하는 경우
  6. 서비스의 성장에 따라 업무가 증가(O(n))한다.
2. 삽질을 줄여야 되는 이유
  1. 앞으로 발생 할 수 있는 삽질의 가능성이 있는 부분을 점검 하기 위해
  2. 서비스의 안정성이나 성능 활용도를 개선 하기 위해
  3. 삽질을 하던 시간이 줄어들어 여유시간이 생기게 되어 다른 서비스나 자동화에 시간적 투자가 가능해짐.
3. 엔지니어링에 해당하는 업무
  1. SW엔지니어링
    - 코드 작성 / 수정하고 관련된 디자인이나 문서화 작업 수행
      - EX
        
        자동화 스크립트 개발
        
        도구나 프레임워크 개발
        
        확장성 및 신뢰성을 위해 서비스 및 기능 추가
        
        인프라스트럭처코드(IAC) 개발 및 수정
  2. 시스템엔지니어링
    - 지속적인 개선을 위해 시스템의 설정을 조정하거나 문서화 작업 수행
      - EX
        
        모니터링 설정 및 수정
        
        LB / 서버 설정 변경
  3. 삽질
    - 서비스 운영과 관련된 반복적으로 발생하는 수작업
  4. 부하
    - 서비스 운영과 관련되지 않은 관리 업무
      - EX
        
        HR 서류작업
분산 시스템 모니터링
1. 정의
  1. 화이트박스 모니터링
    - 로그나 내부의 통계 지표를 제공하는 HTTP 핸들러 등을 이용해서 얻을수 있는 시스템 내부 지표를 기반으로 모니터링 하는 것.
  2. 블랙박스 모니터링
    - 사용자가 보게 되는 확인 가능한 동작들을 외부에서 테스트 하는 과정
  3. 푸시
    - 서비스가 실행하는 소프트웨어나 관련된 설정에 대한 모든 변경사항을 의미한다.
2. 모니터링을 해야되는 이유
  1. 어떤 장애가 왜 발생했는지에 대한 질문에 답을 제시 할 수 있어야한다.
  2. 시간에 따라 변화하는 데이터의 양이나 실 사용자의 수의 변화에 대응하기 위해서
  3. 갑자기 발생한 지연응답에 대해서 동일 시간에 발생한 다른 어떠한 일이 있는지 확인하기 위해
자동화
- 시스템의 스케일 조정(UP/DOWN or IN/OUT) 작업 등 다수의 서버에 일관성있는 설정을 하기 위한 방법
  - 사용자계정 생성 등
  - 수동작업(사람이 직접 각 서버에 작업)으로는 조직 구조 / 인력관리 모두에게서 만족할수 있는 방법이 아니다.
- 정확하게 정의된 업무 범위와 정해진 절차 수행을 하는 데이 있어 일관성의 가치는 다양한 측면에 있어 자동화가 추구하는 최우선적인 가치이다.
- 자동화는 오로지 일관성을 제공 하기 위한 방법이 아니며, 잘 구현된 자동시스템은 확장이 가능하고 다른 시스템에도 적용이 가능하며, 플랫폼을 제공하게된다.
  - 이 플랫폼은 실수를 중앙집중화 하는데 도움이 된다.
- 일반적인 고장 후 수리 시간 단축에 도움이 된다.
  - 데몬 재구동 / 장애시 트래픽 전환
- 신속한 배포 / 시간 절약
  - 자동화를 위한 초기 개발 투자 비용(시간/돈)이 높지만 개발이 끝나서 운영 및 유지보수 시간을 감소 할 수 있다.
- 자동화 단계
  1. 자동화 하지 않은 단계
    - 마스트 데이터베이스에 대한 장애대응을 각 지역별로 수동으로 진행한다.
  2. 별도로 관리되며 시스템에 특화된 자동화를 수행하는 단계
    - SRE가 홈디렉토리에서 장애 대응스크립트를 실행한다.
  3. 별도로 관리되는 범용 자동화를 수행하는 단계
    - SRE가 데이티베이스 장애 대응을 모두가 사용하는 ‘범용 장애 대응’ 스크립트에 추가해서 실행한다.
  4. 내재화 되었지만 시스템에 특화된 자동화를 수행하는 단계
    - 데이터베이스에 자체적으로 내장된 장애 대응 스크립트를 실행한다.
  5. 자동화가 불필요한 시스템을 도입하는 단계
    - 데이터베이스가 문제를 보고하고 사람의 개입없이 자동으로 장애대응을 수행한다.
릴리즈 엔지니어링
- 신뢰성 있는 서비스를 운영하려면 견고한 릴리즈 프로세스가 필요하다.
- 가능한 초기 부터 도입이 되어야한다.
- 지속적 빌드와 배포
  1. 빌드
  2. 브랜칭
  3. 테스트
  4. 패키징
  5. 배포
- 설정 관리 기법
  1. 설정을 주 저장소에 관리하는 방법
  2. 설정 파일과 바이너리를 동일한 MPM패키지로 묶는 방법
  3. MPM 설정 패키지에 설정 파일을 추가 하는 방법
  4. 설정을 외부 저장소에서 읽는 방법
간결함
1. 시스템의 안정성 vs 신속성
2. 지루함의 미덕
  - 담당하고 운영 책임을 지고 있는 시스템의 복잡도를 제거하기 위해 지속적으로 노력한다.
3. 최소한의 API
4. 모듈화
5. 릴리즈의 간소화

참고 자료

구글 공식 SRE 관련 자료URL
1. URL : https://landing.google.com/sre/books/
참고 URL
1. https://en.wikipedia.org/wiki/Site_Reliability_Engineering
2. https://tacogrammer.com/sre-site-reliability-engineering-%EB%A5%BC-%EC%9D%BD%EA%B3%A0%EB%82%98%EC%84%9C/
3. http://internetplus.co.kr/wp/?p=505

Twitter Facebook LinkedIn

Kim Eun-Pyo

SRE 란

SRE

INDEX

용어 정리

SRE 소개

원리와 원칙

참고 자료

공유하기

댓글남기기

참고

페이스북 의 장애 원인 BGP 란?

Windows IOCP VS Linux Epoll

이더리움 네트워크 구축 및 모니터링

K3S 101