SRE 6

SRE #6 - 운영에서 반복적인 노가다 Toil

SRE #6-운영에서 반복적인 노가다 Toil조대협 (http://bcho.tistory.com)ToilToil의 사전적인 뜻은 “노역"이라는 뜻을 가지고 있는데, 비속어를 사용해서 표현하자면 운영 업무에서의 “노가다" 정도로 이해하면 된다. Toil 에 대한 정의를 잘 이해해야 하는데, Toil은 일종의 반복적인 쓸모없는 작업 정도로 정의할 수 있다.경비 처리나, 회의, 주간 업무 보고서 작성과 같은 어드민 작업은 Toil에 해당하지 않는다. Toil은 운영상에 발생하는 반복적인 메뉴얼 작업인데, 다음과 같은 몇가지 특징으로 정의할 수 있다.메뉴얼 작업이고 반복적이어야함Toil의 가장 큰 특징은 사람이 직접 수행하는 메뉴얼 작업이라는 것이다. 그리고 어쩌다 한번이 아니라 지속적으로 발생하는 반복적인 작..

SRE #5 - Error budget

SRE #5 - Error budget 조대협 (http://bcho.tistory.com) SLI와 SLO에 대한 개념을 이해 했으면 다음은 Error budget에 대한 개념을 이해해야 한다.Error budget은 단순하게 생각하면Error budget = [100% - availability target] 와 같다. 예를 들어 설명하면, 한달에 SLO가 99.999%를 목표치로 설정했다면, 한달간 SLO는 0.001%의 다운 타임을 허용하게되고, 이 0.001%가 Error budget이된다. 위의 표는 가용성에 따라서, 허용되는 장애 시간을 정리해놓은 표이다.앞의 예제에서 99.999% 가용률을 목표로 봤을 때 허용되는 장애시간은, 0.001%로 다운 타임은 한달에 25.9 초만 허용된다. 그러..

SRE #4-예제로 보는 SLI/SLO 정의 방법

SRE #4-예제로 살펴보는 SLI/SLO 정의 방법조대협 (http://bcho.tistory.com) 앞에서 SRE의 주요 지표인 SLO/SLI의 개념에 대해서 설명하였는데, 그러면 실제 서비스에서는 어떻게 SLO/SLI를 정의하는지에 대해서 알아본다.SLI는 사용자 스토리당 3~5개 정도가 적당하다. 사용자 스토리는 로그인, 검색, 상품 상세 정보와 같이 하나의 기능을 의미한다고 보면된다. 아래 그림과 같은 간단한 게임 서비스가 있다고 가정하자. 이 서비스는 웹사이트를 가지고 있고, 그리고 앱을 통해서 접근이 가능한데, 내부적으로 API 서비스를 통해서 서비스가 된다. 내부 서비스에는 사용자 랭킹(Rank ), 사용자 프로파일 (User profiles) 등의 서비스가 있다. 이 서비스에서 "사용자..

SRE #2-SRE는 어떻게 일하는가?

SRE는 어떻게 일하는가? 조대협 (http://bcho.tistory.com) 이글은 앞의 글 "SRE/DEOPS의 개념과 SRE는 무엇을 하는가?" (https://bcho.tistory.com/1325) 와 연결된 글입니다.How SRE does Devops?그럼 SRE들은 이런한 일들을 어떤 방법으로 수행할까? 앞에서 SRE가 해야 하는 일에 대해서 설명하면서 각각에 대해서 일부를 언급했지만, 다시 SRE가 해야하는 일을 하기 위해서는 어떻게(How) 해야 하는지에 대해서 다시 정리해보자.SRE는 앞에서 언급한 다섯가지 일을 하기 위해서 아래와 같이 다섯 가지 방법을 사용한다. (참고 : 구글 NEXT 발표자료 https://drive.google.com/file/d/1iOMaYIwlUBiGoG2..

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

Site Reliability Engineering(SRE)#1 SRE/DEVOPS의 개념조대협 (http://bcho.tistory.com)배경Devops는 운영팀과 개발팀을 하나의 팀으로 묶어놓고 전체적인 개발 사이클을 빠르게 하고자 하는 조직 구조이자 문화이다. 이 Devops라는 컨셉이 소개된지는 오래되었지만, Devops의 개념 자체는 명확하지만 이 Devops를 어떻게 실전에 적용할것인 가는 여전히 어려운 문제였다.(예전에 정리한 Devops에 대한 개념들 1 , 2) 예전 직장들에 있을때 Devops의 개념이 소개되었고 좋은 개념이라는 것은 이해하고 있었지만, 여전히 운영팀은 필요하였고, 그 역할이 크게 바뀌지 않았다. 심지어 Devops를 하는 기업들도 보면 기존 개발팀/운영팀이 있는데, ..

구글의 Devops 운영 모델 SRE (Site Reliability Engineering)

SRE는 구글의 Devops의 프랙티스 로 구글의 서비스에 대한 배경과 철학을 읽을 수 있다.SRE의 기본 사상중의 하나는 서비스의 안정성이 완벽할 수 없으며, (아니 완벽하지 않게 만들며) 장애를 허용하는 모델이다.고 가용/고 성능 시스템을 만들기 위해서는 그만큼 많은 개발에 대한 노력이 소요되는데, 이로 인해서 기능 개발에 대한 속도가 느려지기 때문에, 사용자가 납득할만한 수준의 가용성을 제공하되 개발의 속도를 유지하는 철학이다.배경을 살펴보면 구글은 모바일을 기반으로 한 B2C 서비스를 주력으로 하기 때문에, 서비스가 99.999%의 가용성을 제공하더라도, 스마트폰과 통신망 자체가 그정도의 안정성을 제공하지 않기 때문에, 백앤드 서비스가 높은 가용성을 제공하더라도 사용자가 느끼는 가용성은 그 정도 ..