#13 Site Reliability Engineering

DevOps
 도구 : Infra 구성 관리 도구
 개발 : Git, Gitlab
 CI/CD : Gitlab runner, Github Action

Flicker로부터 DevOps가 시작
 > Google에서도 DevOps와 비슷한 내용이 존재 했음 : 운영에 조금더 초점이 맞춰져 있던 형태
 > Site Reliability Engineering

사이트 신뢰성 엔지니어링(Site Reliability Engineering / SRE)
 - DevOps를 운용하는 방법 중 하나
 - Google의 운영으로 축적된 노하우
 - DevOps와 달리 운영에 초점을 맞춘 개념

사이트 신뢰성(Site Reliability)
 - 어떤 것에서 저하가 발생 = 비즈니스 실현의 저해 확률을 높이는 것
  : ex) 시스템 가용성(Availability) > 높으면 언제든 사용 가능 / 낮으면 실행해도 동작 안하는 경우가 발생
         : 하락 > 사이트 신뢰성 저하 > 비즈니스 실현의 저해 확률 증가(실제 저해로 이어지는 것은 미지수)
 - 당장 표면화 되지 않은 시스템 문제에 대해서 관심
  : 자동화/간소화 > 작업 품질 향상 활동, 중장기에 걸친 용량

DevOps와 SRE의 공통점
 DevOps)
  - 안정적인 가동 및 최적화가 목표가 아님(당연한 것) => 비즈니스 실현이 목적
 SRE)
  - 사이트 신뢰성을 확보(저해 요소를 없앰) => 비즈니스 실현이 목적

SRE 팀의 미션
 - 가용성, 지연, 성능, 효율화, 변화 관리, 모니터링, 긴급 대응, 용량 관리에 책임을 짐
  : 전통적인 운용 팀이 담당하고 있는 영역과 크게 겹침
  : 다양한 도구와 방법의 확실한 사용 => 사이트 신뢰성 기여

SRE 접근법
 - engineering : 어떤 분야에 관련된 기술의 집합
 - SR + E : 사이트 안전성을 위한 테크닉(기술)
 - 종류
  > 시스템 튜닝
   : 가용성(Availability), 지연(Latency)/성능(Performance)
  > 모니터링
   : 서비스, 용량(Capacity)
  > 작업 품질
   : 자동화/간소화, 변경 관리
  ----------------------------<< 사전 대책
  > 장애 대응 : 대응 대책

SRE - 시스템 튜닝 : 가장 알기 쉬운 사이트 신뢰성 향상 방법
 : 시스템 다운 혹은 사용이 어려워지는 상태
  > 비즈니스에 악영향, 비즈니스 가치 저하
 : 문제가 있는 곳 분석 >> 모니터링 필요
  > 하드웨어 성능에 근본적인 문제, 애플리케이션의 좋지 않은 구현

 : SRE 팀의 역할 >> 인프라에서 애플리케이션에 이르기까지 다양한 전문성이 요구되는 고급 작업
  > 팀 전체로써 시스템에 사용되는 기술 요소를 많은 부분에서 커버할 수 있는 것이 바람직
  > 전통적인 운영 팀과의 차이점 : DevOps와 같이 개발팀과 운용팀이 잘 연계 되는 것

SRE - 모니터링 : 튜닝을 위해 선행되어야하는 작업
 : SRE 실천에 필요한 도구
  > 사이트 신뢰성은 여러가지 요인에 의해 저해 : 서비스와  Capacity 관점으로 분석
 : 문제의 조기 발견 > 기록 확인 > 원인 분석 > 튜닝

 : 서비스 모니터링 > 시스템에 대한 모니터링
  - 웹 서비스 > Access Test > 정상 Code / Error Log 
   : Resource Monitoring > CPU Load / Memory Usage / IOPS의 이상 탐지
  - 문제 발견 시 즉시 대책 강구 : CPU 부하 증가 > 새로운 서버 추가

 : Capacity 모니터링 > 미래의 시스템에 대한 모니터링
  - 서비스 모니터링 : CPU 부하측정
  - Capacity 모니터링 : 변화 추이에 주목
   : 위험 영역 임계에 도달하는 시점 예측 > 사전 대응

SRE - 작업품질
 : 사이트 신뢰성을 향상시키는 작업(대응, 튜닝, 개선, 진단)
  > 해당 작업이 사이트 신뢰성을 저하시키지 않도록 대책 강구
 : DevOps의 작업의 자동화/간소화를 통한 변경 관리와 동일함

SRE - 장애 대응
 : 장애를 완전히 배제할 수 없음
  > 물리적 장애 ~ 논리적 장애(특정 상황에서만 발생하는 장애)
  > 인프라 ~ 애플리케이션에 이르는 다양한 장애
 : 어떤 문제든 사이트 신뢰성을 저해하는 것에 대해 SRE 팀은 총력을 기울여 사태를 해결하기 위해 노력

 : 장애 대응의 중요한 것
  > "단 시간"에 "적은 인원"으로 장애 대응을 하는 것
  > 수 많은 장애에 대응 가능한 인력을 전부 배치할 수는 없음
     특히, 운영 개선을 목적으로 하고 있기에 인력을 많이 배치할 수 있는 조직은 아님
  > 장애가 길게 이어진다는 것은 사이트 신뢰성이 떨어진 다는 것을 의미 >> 장애는 짧아야 함

SRE의 목적
 : "Engineering"하는 것
 : SRE 팀의 목적 > 사이트 신뢰성에 기여하는 것 = 비즈니스 가치 향상으로 이어짐
 : DevOps의 목적과 일치
   - 전통적인 운용팀을 DevOps 팀으로 변화시킬 때, SRE의 구체적 기술을 넣는 것이 매우 효과적임