Preface

• SE (Software Engineering) 와 아이를 가지는 것의 공통점은 탄생전의 노력도 힘들고 고통스럽지만, 출산 후에 들어가는 노력과 정성이 더 크다는 것이다.
• 전체 소프트웨어 라이프 사이클의 40%~90% 의 노력이 개발 후에 발생한다.
• 배포되고 운영되는 소프트웨어를 안정적이라고 간주하는 것은 틀렸다
• SE는 주로 디자인과 개발에 초점을 두는 경향
• 개발에서 – 배포 – 운영까지 모든 생명주기를 다루는 규칙이 필요
• 이런 규칙은 보다 넒은 기술셋을 요구하고 다른 종류의 엔지니어와는 조금 다른 관심사를 가진다 – 이런 discipline 을 SRE라고 부른다.

Introduction

• 전통적인 SysAdmin 은 개발자에 비해서 Operational 한 기술셋을 요구함
  • SysAdmin 의 장점
    • 구현이 쉬움, 다른 유사산업(건설?)에서 예제들을 가져다 쓸 수 있음
    • 관련 스킬 보유자를 찾기 쉬움
    • 기존 도구 & 서비스 제공업체 들이 이미 존재 해서 새로운 도구 개발 필요없음
  • 단점 (개발과 운영을 분리 했을 시)
    • 직접 비용 발생
      • 서비스가 커지면서 변경이 일어나거나 이벤트 발생시에 수동으로 대처하는 방식으로는 많은 인원을 필요로함 -> 비용증가
    • 간접 비용 발생
      • 두팀의 기술셋과 동기, 백그라운드가 다르다는 사실
      • 각자다른 리스크 인식, 해결방안, reliability 에 대한 개념
  • 개발팀은 빠른 기능추가를 원함 ,운영팀은 문제가 없기를 바람람
  • 두팀의 목표가 상이함함
• 구글은 이런 문제에 SRE 라는 다른 접근 방식을 취함함
• 간단하게 설명하면 SRE는 개발자 출신의 운영팀
  • 크게 두가지로 분류됨
    • 60%는 구글 Software Engineering
    • 40%는 개발자 역량으로는 조금 부족하지만 다른 전문성을 가진사람 (주로 유닉스와 네트워킹)
  • 근무 시간의 50%는 운영, 50%는 개발에만 씀
  • 채용이 힘들다
• SLO (Service Level Objective)
  • 사용자는 100%나 99.99%의 Availability 나 차이를 못 느끼기 때문에 100%를 목표로 잡는 것은 잘못 됨
  • 다른 요인으로 인해 100%가 될수도 없음 (네트워크 유실 등)
  • Target Availability 는 반드시 있어야 함
  • 99.99%의 Availability 를 가진다면 0.01% 의 Error Budget 을 가짐짐
  • 이 Error Budget 을 활용하면 SRE팀과 개발팀의 목푤르 일치 시킬 수 있음음
    • Error Budget 내에서 더 빠른 기능 개발 및 배포
• 모니터링
  • 전통적인 system Metric 에 의한 alert은 잘못된 것임.
  • 인간이 해석을 하는게 아니라 컴퓨터가 해석을 하고 사람은 행동여부만 결정해야 함
    1. alert
    2. ticket
    3. logging
• 변경관리
  • Progressive roll out
  • 빠르고 정확하게 문제 찾기
  • 문제 발생시 안전한 롤백
• 수요조사
  • Organic Growth (서비스 런칭 후 자연스러운 증가)
  • Inorganic Growth (새로운 기능 추가 등으로 인한 증가)
• 프로비져닝

2. Google Production Environment

• pass

3. Embracing Risk

• Extreme reliability comes at cost
  • 사용자경험(UX)이 네트워크나 디바이스 같이 less reliable 한 컴포넌트들에 의해 주도되기 때문
• reliability 를 늘리는 비용은 not linear 이고.. 100x의 비용이 들어감
  • 유후장비에 대한 Cost (cost of redundant machine)
  • 기회 비용 (opportunity cost)
  • 최대한 reliable 하게 만들돼 필요이상은 아님 (no more reliable than it needs to be)
• 리스크 측정 (Measuring risks)
  • 대부분의 서비스에서 risk tolerance (받아 들일 수 있는 리스크)는 계획되지 않은 다운타임 (unplanned downtime)의 허용시간과 동일
    • Unplanned downtime 은 99.99 와 같이 뒤에 붙는 9의 숫자로 표현될 수 있다.
      

      Availability = uptime / (uptime + downtime) e.g) 99.99% Availability 는 년간 52.56 분의 downtime 을 의미함

  • 그러나 Google 과 같이 Globally 서비스 하는 회사는 위 값이 의미가 없다
    • 그래서 request success rate 를 사용
      

      Availability = successful requests / total requests

  • daily 2.5M 요청을 처리할 경우 99.99%의 가용성은 하루에 250 errors 를 의미한다
• 서비스의 Risk tolerance 알아내기
  • 다음과 같은 Factor 를 사용
    • 필요로 하는 Availability level . 다음과 같은 기준으로 정한다.
      • 사용자의 기대 Level
      • 매출과 즉결되는가?
      • 유료인가 무료인가
      • 시장에 경쟁서비스가 있는가? 그 경쟁상대의 레벨은?
      • 기업고객 대상인가 일반고객 대상인가
    • 종류가 다른 장애는 서비스에 미치는 영향도 다른가?
      • 이미지가 늦데 로딩되는 것과 개인정보가 유출되는 장애는 수준이 다름

4. Service Level Objective

• SLI (Service Level Indicator)
  • request Latency
  • error rate
  • system throughput
  • Availability
• SLO (Service Level Objective)
  • SLI < 목표 & lower bound < upper bound

5. Eliminating Toil

• 구글에서 SRE는 Operational Work 보다 장기 엔지니어링 프로젝트에 시간을 쏟길 원한다. Operational work 는 종종 오해되서 Toil 로 대체해서 사용한다
• Toil (잡일) 정의하기
  • Manual
    • 예를들어 어떤 작업을 자동화한 스크립트를 사람이 수동으로 돌리는 것
  • Repetitive
  • Automatable
  • 태스크 종료후에도 똑같은 상태일 경우
  • O(n) 으로 증가할 경우
• SRE 는 50% 이하의 시간만 Toil (잡일)에 쓰고 나머지 시간은 Toil 을 제거하는 일에 쓴다
  • 이 잡일들을 빨리 제거하지 않으면 곧 일의양이 늘어나고 모든 사람들의 시간을 100% 소비하게 된다
    • SRE 채용시에도 분명히 알려줌. 단순 운영업무가 아니다
  • 잡일은 항상 나쁜가?
  • 규모가 작을때는 그렇지 않을 수도 있다. 그런종류의 일에서 성취감을 느끼고 , 좋아하는 사람들도 있음음.
  • low risk , low stress
  • 양이 많아지면 그사람의 커리어 자체를 위협

6. Monitoring Distributed system

• 구글에서 사용하는 용어
  • 화이트박스 모니터링
    • JVM 메트릭이나 내부 시스템 정보를 사용한 모니터링
  • 블랙박스 모니터링
    • 외부에서 사용자의 시선으로 모니터링
  • 대시보드
    • 서비스의 핵심 지표를 보여주는 웹 애플리케이션
• 4가지 중요 지표
  • Latency
    • 성공한 요청과 실패한 요청의 latency 를 섞지 마라라
    • Slow error 는 Fast error 보다 나쁘다
  • Traffic
    • 시스템 별로 조금씩 측정기준이 다를 수 있다
    • 웹서비스의 경우 초당 http request
    • 오디오 스트리밍의 경우 동시 세션수나 네트워크 량
  • errors
    • 요청당 에러 비율
    • 500 or 200 이지만 비정산 응답을 모두 카운팅
  • Saturation
    • 시스템의 포화도

7. Evolution of automation at Google

• 자동화의 가치
  • 일관성 (Consistency)
  • 확장 가능한 플랫폼으로 커질 수 있다
    • 플랫폼화 되면 버그나 실수들도 쉽게 관리가 되고 동시에 처리 가능능
  • Faster Recovery
  • Faster Action
• automation
  • 소프트웨어 위에 동작하는 소프트웨어. Meta SW
  • 예제..
    • 사용자 계정 생성
    • 클러스터 구성
    • 소프트웨어설치
    • 서비스 롤아웃
    • 실시간 설정 변경