블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

피쳐 크로싱 (Feature crossing)

아키텍쳐 /머신러닝 | 2019.05.21 23:00 | Posted by 조대협


참고 문서 : 구글 머신러닝 크래쉬 코스


피처 엔지니어링 #1  - 피처 크로스


조대협 (http://bcho.tistory.com)


일반적인 선형 모델의 경우에 선을 그어서 문제를 해결할 수 있다. 아래 그림과 같은 데이타 분포의 경우에는 파란선과 붉은선 사이에 선을 그으면 문제가 해결된다.


그러나 아래와 같은 데이타 모델의 경우에는 선을 하나 그어서 해결할 수 가 없다. (선형 모델의 경우에)



세로축을 x1, 가로축을 x2라고 할때, y = w1x1 + w2x2 + w3(x1x2) +b 로 세번째 피쳐를 앞의 두 피쳐를 곱한 값을 이용하게 되면, 문제를 해결할 수 있다. 즉 x1이 양수이고 x2가 양수이면 양수가 되고 ,  x2가 음수이면 x1*x2는 양수가 된다. 즉 파란색 점이 위치한 부분은 모두 양수 값이 나온다.

x1이 양수, x2가 음수 이면 x1*x2는 음수가 된다. x1이 음수이고 x2가 음수이면 x1*x2는 음수가 된다. 즉 주황생점이 위치한 부분은 x1*x2가 음수 값이 된다.


이렇게 두개 이상의 피쳐를 곱해서 피쳐를 만드는 기법을 피쳐 크로싱이라고 한다. (Feature crossing) 그리고, 이렇게 피쳐를 가공해서 생성된 피쳐를 Synthetic feature 라고 한다.


위의 공간 문제의 경우에는 전형적인 XOR 문제인데, 이런 XOR 문제는 MLP (Multi Layered Perceptron)로 풀 수 있는데, 굳이 리니어 모델에서 피쳐 크로싱을 하는 이유는, 요즘에야 컴퓨팅 파워가 좋아졌기 때문에 MLP와 같은 복잡한 네트워크 연산이 가능하지만, 기존의 컴퓨팅 파워로는 연산이 어렵기 때문에, 스케일한 큰 모델에는 리니어 모델이 연산양이 상대적으로 적기 때문에, 큰 모델에는 리니어 모델을 사용했고, 리니어 모델에서 XOR와 같은 문제를 해결하기 위해서 피쳐 크로싱을 사용하였다.


'아키텍쳐  > 머신러닝' 카테고리의 다른 글

피쳐 크로싱 (Feature crossing)  (0) 2019.05.21
Deep learning VM  (2) 2018.12.05
본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

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

조대협 (http://bcho.tistory.com)

Toil

Toil의 사전적인 뜻은 “노역"이라는 뜻을 가지고 있는데, 비속어를 사용해서 표현하자면 운영 업무에서의 “노가다" 정도로 이해하면 된다.  Toil 에 대한 정의를 잘 이해해야 하는데, Toil은 일종의 반복적인 쓸모없는 작업 정도로 정의할 수 있다.

경비 처리나, 회의, 주간 업무 보고서 작성과 같은 어드민 작업은 Toil에 해당하지 않는다. Toil은 운영상에 발생하는 반복적인 메뉴얼 작업인데, 다음과 같은 몇가지 특징으로 정의할 수 있다.

메뉴얼 작업이고 반복적이어야함

Toil의 가장 큰 특징은 사람이 직접 수행하는 메뉴얼 작업이라는 것이다. 그리고 어쩌다 한번이 아니라 지속적으로 발생하는 반복적인 작업이다.

자동화 가능함

자동화가 가능하다는 것은 자동화가 가능한데, 시간이 없어서(?) 자동화를 못하고 사람이 작업을 하고 있다는 것이다. 즉 사람이 하지 않아도 되는 일을 시간을 낭비하면서 하고 있다는 것인데, 서버 배포를 테라폼등으로 자동화할 수 있는데, 자동화 하지 않고, 수동으로 작업하고 있는 경우 Toil에 해당한다.

밸류를 제공하지 않는 작업

Toil작업은 작업을 하고나도, 서비스나 비지니스가 개선되지 않는 작업이다. 작업 전/후의 상태가 같은 작업인데, 장애 처리와 같은 것이 대표적인 예에 속한다. 장애 처리는 시스템을 이전 상태로 돌리는 것 뿐일뿐 새로운 밸류를 제공하지 않는다.

서비스 성장에 따라서 선형적으로 증가하는 작업

Toil은 보통 서비스가 성장하고 시스템이 커지면 선형적으로 증가한다. 애플리케이션 배포나, 시스템 설정, 장애 처리도 시스템 인스턴스의 수가 늘어날 수 록 증가하게 된다.


정리해보자면, Toil이란 성장에 도움이 되지 않으면서 시간을 잡아먹는 메뉴얼한 작업이고, 서비스의 규모가 커지면 커질 수 록 늘어나는 자동화가 가능한 작업이다. 일종의 기술 부채의 개념과도 연결시켜 생각할 수 있다.

Toil을 왜? 그리고 어떻게 관리해야 하는가?

그러면 Toil을 어떻게 관리해야 할까? Toil은 의미없는 작업이 많지만, Toil을 무조건 없애는 것은 적절하지 않다. 예를 들어서 일년에 한두번 발생하는 작업을 자동화하려고 노력한다면, 오히려 자동화에 들어가는 노력이 더 많아서 투자 대비 효과가 떨어진다. 반대로 Toil이 많으면 의미있는 기능 개발작업이나 자동화 작업을할 수 없기 때문에 일의 가치가 떨어진다.

그래서 구글의 SRE 프랙티스 에서는 Toil을 30~50%로 유지하도록 권장하고 있다.  Toil을 줄이는 방법 중에 대표적인 방법은 자동화를 하는 방법이다. 자동화를 하면 Toil을 줄일 수 있는데, 그러면 남은 시간은 어떻게 활용하는가? 이 시간을 서비스 개발에 투자하거나 또는 다른 서비스를 운영하는데 사용한다.



위의 그림이 가장 잘 설명된 그림인데, 초반에는 Service A에 대해서 대부분의 Toil이 발생하는데, 자동화를 하게 되면, Toil 이 줄어든다.그러면 줄어든 Toil 시간을 다른 서비스를 운영하는데 사용을 하고 결과적으로는 여러 서비스를 동시에 적은 시간으로 운영할 수 있도록 된다.


이 개념을 확장해보면 Devops의 목표와도 부합이 되는데, Devops는 개발과 운영을 합쳐서 진행하는 모델인데, 개발이 직접 운영을 하기 위해서는 플랫폼이 필요하다. 즉 개발자가 직접 하드웨어 설치, 네트워크 구성등 로우 레벨한 작업을 하는것이 아니라, 자동화된 운영 플랫폼이 있으면, 개발팀이 직접 시스템을 배포 운영할 수 있게 된다.


<그림, Devops에서 개발자와 Devops 엔지니어의 역할>


그래서 개발팀이 이러한 플랫폼을 이용해서 Devops를 한다면, Devops엔지니어는 개발팀이 사용할 운영플랫폼을 개발하는데, 운영플랫폼이란 자동화된 플랫폼을 이야기 한다.

Toil을 측정해가면서 각 서비스별로 자동화 정도를 측정하고, 자동화가 될 수 록, 그 서비스에서 빠져가면서 새로운 서비스로 옮겨가는 모델이라고 볼 수 있다.


Toil를 어떻게 측정할것인가?

이제 Toil이 무엇인지, Toil을 줄여서 어떻게 활용하는지에 대해서 알아보았다.

그러면, 이 Toil을 어떻게 측정하는가?

Toil의 종류를 보면, 크게 배포나 장애처리 등으로 볼 수 있는데, 장애처리의 경우, 장애 발생시 장애 티켓을 버그 시스템에 등록한후에, 처리가 완료될때까지의 시간을 측정하면, 장애 처리에 대한 Toil을 측정할 수 있다.

메뉴얼 배포와 같은 경우에는 특별한 시스템 (Task management)을 사용하지 않는 이상 정확하게 측정하기가 어려운데 그래서 이런 경우에는 snippet (주간 업무보고)나 또는 주기적인 설문 조사를 통해서 측정하는 방법이 있다.



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요


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 초만 허용된다.

그러면 이 시간을 어떻게 활용하는가? 허용되는 다운 타임에 한해서 예고된 다운 예를 들어서 배포나 시스템 업데이트를 수행한다. 만약에 남은 Error budget이 없다면, 새로운 기능에 대한 업데이트를 중지하고, 시스템의 가용성을 높이기 위해서 자동화나 프로세스 개선등의 작업등을 한다.

Error budget의 차감은 앞에서 이야기 한것 처럼 계획된 다운 타임이 아니라, 장애등에 의한 계획 되지 않은 다운 타임에도 차감을 한다.

Error budget을 활용하게 되면 개발팀 입장에서도 책임감을 가질 수 있는데, 예를 들어 코드의 허용된 Error budget 안에서만 배포를 할 수 있게 되기 때문에, 한달에 2번할 배포를 한번 하게 되거나 (횟수를 줄이는 것에 중점을 두지 말고, 그 만큼 신중해진다는 의미에 중점을 두기 바란다. ) Error budget을 차감당하지 않도록 하기 위해서 테스트를 좀 더 꼼꼼하게 할 수 있다.

Error budget 을 다 소모하면, Error budget을 복구하는 여러가지 방법이 있겠지만, 이건 팀에서 (임원포함) 정책적으로 동의해서 결정해야 한다. 앞에 예에서 언급한것과 같이 새로운 기능 배포를 멈추고 안정화 작업에 집중을 하는 방법도 있고, 또는 Error budget이 0이 된 경우 해당 엔지니어나 개발팀에 대해서 강도 높은 코드 리뷰를 다시 받도록 하는 방법등 여러가지 방법이 있다.

예전 김요섭님 강의에 몇가지 사례가 있으니 참고하면 좋다.

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

Azure Devops


조대협 (http://bcho.tistory.com)


페이스북 타임라인을 보다가. “Azure Devop가 나왔는데. JIRA 따위는 꺼져버려.." 라는 말이 있어서 몬가 궁금해서 살펴봤는데 이거 정말 물건이다. MS가 요즘 많이 변하하고 있다고 들었는데, 정말 잘 만든 제품인듯 Devops라고 해서 Monitoring,Logging쪽 제품으로 생각했는데,


Task management, 부하 테스트, git repo & 빌드, 빌드 파이프라인, 웹테스트 툴 등이 들어있는데, 전반적으로 정말 좋은듯. 예전 IBM의 Jazz 플랫폼과 컨셉은 비슷한데, UI나 기능이나 반응 속도나 압권이고 거기다가 일부 플랜은 무료다!! 나 같은 개인 개발자(집에서는)에게는 딱이 아닐까 싶다.


대충 후욱 살펴봤는데,

Board

이건 JIRA대응의 Task management tool + agile board 정도로 보면되는데, JIRA가 충분히 위협 받을만 하겠다.


아래는 백로그를 등록하는 화면인데, 스크럼 스프린트 맞게 맵핑할 수 있도록 되어 있다. 사용자 스토리에 스토리 포인트 넣는 기능도 있고,  




아래는 스프린트 화면인데, 사용자 스토리 아래에 Sub task를 정의할 수 있도록 되어있고, Subtask 마다 진행 상황을 컨트롤할 수 있도록 되어 있다.


Task 트렌드를 추적할 수 있는 그래프도 제공하고


전체 상황을 볼 수 있는 대쉬 보드도 제공한다. 그리고 사용자 스토리 기반으로 스프린트 기반의 팀 속도를 나타낼 수 있는 기능도 제공한다.

그리고 마지막으로, 사용자 스토리 마다, 소스코드 저장소에서 스토리마다 브렌치로 연결할 수 있는 기능이 있다.


한마디로 군더더기가 없고, 아쉬운 기능이 없다. (나중에 찾으면 있을지도 모르지만). 가격도 괜찮고, 정말 써볼만한듯. 그동안 JIRA가 무료 호스팅 버전의 경우에는 사용자 수나 기타 제약이 있었는데, 미니 프로젝트는 이걸로 써도 충분하겠다.


Test plans

테스트 플랜 도구는 테스트 관리 도구인데, 앞의 Board와 연동이 되서 사용자 스토리에 테스트 플랜을 연결해서 사용할 수 있다. 별거 아닌 기능처럼 보일 수 있는데, TestLink(오픈소스)등이 이런 기능을 제공하고, 탐색적 테스팅이나 메뉴얼 테스팅에는 절대적으로 유용한 도구이다.



Testing extension을 이용하면, 별도의 툴을 이용해서 웹 액티버티를 레코딩해서 웹 테스팅도 가능한걸로 보이는데, 모바일 앱쪽은 자료가 없어서 잘모르겠다. Testing extension은 다운받을려고 보니 30일 무료가 뜨는 걸로 봐서 패스.. (사실 우분투가 메인 OS라서 안도는건지도..)

그리고 부하 테스트 기능이 같이 있다.



Jmeter 테스트도 되고, URL 기반으로 간단한 부하테스트등 왠만큼 복잡하지 않은 마이크로벤치정도는 충분히 가능할것 같다.


Repo

다음툴은 Repos 서비스 인데 git 호환 리파지토리로 보이는데 상당히 깔금하다.

github에서 바로 import가 되길래, 바로 Import도 해봤는데, 여기서 연동해서 빌드도 바로 가능하더라.. Maven 등 빌드 타입만 정해주면 바로 빌드가 되니, 빌딩에 들어가는 시간도 절약할 수 있을듯하다.




아직 다 자세하게 보고 써보지 않아서 대형 프로젝트에는 잘 모르겠지만 일반적인 스타트업 수준이라면 이걸로 대부분의 개발은 크게 문제가 없지 않을까 싶다.

일단 강추하는걸로!!



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

2019년 샌프란시스코 구글 NEXT 2019에서 발표한 로깅 시스템에 대한 강의 입니다.

구글 스택 드라이버 로깅에 대한 소개와, 삼성전자가 어떻게 스택 드라이버 툴을 이용해서 Devops로 적응했는지에 대한 사례입니다.

영어 컨텐츠 입니다.



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

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

조대협 (http://bcho.tistory.com)


앞에서 SRE의 주요 지표인 SLO/SLI의 개념에 대해서 설명하였는데, 그러면 실제 서비스에서는 어떻게 SLO/SLI를 정의하는지에 대해서 알아본다.

SLI는 사용자 스토리당 3~5개 정도가 적당하다. 사용자 스토리는 로그인, 검색, 상품 상세 정보와 같이 하나의 기능을 의미한다고 보면된다.


아래 그림과 같은 간단한 게임 서비스가 있다고 가정하자. 이 서비스는 웹사이트를 가지고 있고, 그리고 앱을 통해서 접근이 가능한데, 내부적으로 API 서비스를 통해서 서비스가 된다. 내부 서비스에는 사용자 랭킹(Leader board), 사용자 프로파일 (User profiles) 등의 서비스가 있다.


이 서비스에서 "사용자 프로필" 에 대한 SLI를 정의해보도록 하자.

SLI 지표 레퍼런스

앞에서 설명한 SLI 지표로 주로 사용되는 지표들을 되집어 보면 다음과 같다.

  • 응답 시간 (Request latency) : 시스템의 응답시간

  • 에러율 (Error rate%)  : 전체 요청에서 실패한 요청의 비율

  • 처리량(Throughput) : 일반적으로 초당 처리량으로 측정하고 TPS (Thoughput per second) 또는 QPS (Query per second)라는 단위를 사용한다.

  • 가용성(availability)  : 시스템의 업타임 비율로, 앞에서 예를 들어 설명하였다.

  • 내구성(Durability-스토리지 시스템만 해당) : 스토리지 시스템에만 해당하는데, 장애에도 데이타가 유실되지 않을 확률이다.

이런 지표들이 워크로드 타입에 따라 어떤 지표들이 사용되는지 정의해놓은 정보를 다시 참고해 보면 다음과 같다.

  • 사용자에게 서비스를 제공하는 서비스 시스템 (웹,모바일등) : 가용성, 응답시간, 처리량

  • 스토리지 시스템(백업,저장 시스템): 가용성, 응답시간, 내구성

  • 빅데이터 분석 시스템 : 처리량, 전체 End-to-End 처리 시간

  • 머신러닝 시스템 : 서빙 응답시간, 학습 시간, 처리량, 가용성, 서빙 정확도


이 서비스는 "사용자에게 서비스를 제공하는 서비스 시스템 패턴" 이기 때문에, 이 중에서 가용성과 응답시간을 SLI로 사용하기로 한다.

가용성 SLI

가용성은 프로파일 페이지가 성공적으로 로드된 것으로 측정한다.

그러면 성공적으로 로드 되었다는 것은 어떻게 측정할 것인가? 그리고, 성공호출 횟수와 실패 횟수는 어떻게 측정할것인가? 에 대한 질문이 생긴다.

이 서비스는 웹기반 서비스이기 때문에, HTTP GET /profile/{users}와 /profile/{users}/avatar 가 성공적으로 호출된 비율을 측정하면 된다. 성공 호출은 어떻게 정의할것인가? HTTP response code 200번만 성공으로 생각할 수 있지만 5xx는 시스템 에러이지만 3xx, 4xx는 애플리케이션에서 처리하는 에러 처리 루틴이라고 봤을때, 3xx,4xx도 성공 응답에 포함시켜야 한다. 그래서 2xx,3xx,4xx의 횟수를 성공 호출로 카운트 한다.


그러면 이 응답을 어디서 수집해야 할것인가? 앞의 아키텍쳐 다이어그램을 보면 API/웹서비스 앞에 로드밸런서가 있는 것을 볼 수 있는데, 개별 서버 (VM)에서 측정하는 것이 아니라 앞단의 로드밸런서에서 측정해도 HTTP 응답 코드를 받을 수 있기 때문에, 로드밸런서의 HTTP 응답 코드를 카운트 하기로 한다.

응답시간 SLI

그러면 같은 방식으로 응답시간에 대한 SLI를 정의해보자

응답 시간은 프로파일 페이지가 얼마나 빨리 로드 되었는지를 측정한다. 그런데 빠르다는 기준은 무엇이고, 언제부터 언제까지를 로딩 시간으로 측정해야 할것인가?

이 서비스는 HTTP GET /profile/{users} 를 호출하기 때문에, 이 서비스가 100ms 를 임의의 기준값으로 하여, 이 값 대비의 응답시간으로 정의한다.

응답 시간 역시 가용성과 마찬가지로 로드밸런서에서 측정하도록 한다.


이렇게 SLI를 정의하였으면, 여기에 측정 기간과 목표값을 정해서 SLO를 정한다.



가용성 SLO는 28일 동안 99.95%의 응답이 성공한것으로 정의한다.

응답시간 SLO는 28일 동안 90%의 응답이 500ms 안에 도착하는 것으로 정의한다. 또는 좀더 발전된 방법으로 99% 퍼센타일의 응답의 90%가 500ms 안에 도착하는 것으로 높게 잡을 수 있지만, 처음 정한 SLO이기때문에, 이정도 수준으로 시작하고 점차 높여가는 모델을 사용한다.

복잡한 서비스의 SLI 의 정의

앞의 예제를 통해서 SLI와 SLO를 정의하는 방법에 대해서 알아보았다. 사용자 스토리 단위로 SLI를 정한다하더라도, 현실에서의 서비스는 훨씬 복잡하고 많은 개수를 갖는다.

SLI가 많아지면, 관련된 사람들이 전체 SLI를 보기 어렵기 때문에 조금 더 단순화되고 직관적인 지표가 필요하다.

예를 들어보다. 구글 플레이 스토어를 예를 들어봤을때, 구글 플레이스토어는 홈 화면, 검색, 카테고리별 앱 리스트 그리고 앱 상세 정보와 같이 크게 4가지 사용자 스토리로 정의할 수 있다.


이 4가지 사용자 스토리를 aggregation (합이나 평균)으로 합쳐서 하나의 지표인 탐색(Browse)라는 지표로 재 정의할 수 있다. 아래는 4개의 SLI를 각각 측정한 값이다.



이 개별 SLI들을 합쳐서 표현하면 다음과 같이 표현할 수 있다. 전체 SLI의 값을 합친 후에, 백분률로 표현하였다.


이 하나의 지표를 사용하면 4개의 기능에 대한 SLI를 대표할 수 있다. 이렇게 개별 SLI의 합이나 평균을 사용하는 경우는 대부분의 경우에는 충분하지만 특정 서비스가 비지니스 임팩트가 더 클 경우 이를 동일하게 취급해서 합해버리면 중요한 서비스가 나도 이 대표값에는 제대로 반영이 안될 수 있기 때문에, 필요한 경우 개별 SLI에 적절한 가중치를 곱해서 값을 계산하는 것도 방법이 된다.



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

SRE #3-SRE 주요 지표 (SLI/SLO)

조대협 (http://bcho.tistory.com)

이글은 앞글 (https://bcho.tistory.com/1327)과 연결 됩니다.
앞에 까지 SRE가 무엇이고,  SRE가 하는일은 무엇이며, 어떻게 그 일을 수행 하는지에 대해서 알아보았다. SRE 프랙티스 에서는 의사 결정을 데이터에(data based decision) 따라 하기 때문에, 데이타 즉 지표를 정의하는 것이 중요하다. 그러면 SRE 에서는 어떻게 지표를 정의하고 활용하는지에 대해서 알아본다.

SLI (Service Level Indicator)

SLI는 서비스에 대한 수준을 측정하여, 정량적으로 정의한 지표이다.

"REST API의 응답시간 = 300ms"와 같이 절대 값을 사용하기도 하지만, (측정값/이상적인 값)과 같은 상대적인 지표를 사용하는 것도 이해하기가 쉽다. 예를 들어 한달동안 30분 장애가 났다고 하면 장애에 대한 SLI를 30분이 아니라 가용성으로 SLI를 정의해서 (30일-30분)/(30일) * 100 = 99.9305 %와 같은 식으로 표현하는게 좋다.

SLI로 사용할 수 있는 지표는 여러가지가 있지만 일반적으로 다음과 같은 지표들을 많이 사용한다.

  • 응답 시간 (Request latency) : 시스템의 응답시간

  • 에러율 (Error rate%)  : 전체 요청에서 실패한 요청의 비율

  • 처리량(Throughput) : 일반적으로 초당 처리량으로 측정하고 TPS (Thoughput per second) 또는 QPS (Query per second)라는 단위를 사용한다.

  • 가용성(availability)  : 시스템의 업타임 비율로, 앞에서 예를 들어 설명하였다.

  • 내구성(Durability-스토리지 시스템만 해당) : 스토리지 시스템에만 해당하는데, 장애에도 데이타가 유실되지 않을 확률이다.

어떤 지표를 SLI로 사용해야 하는가?

SLI로 정의할 수 있는 지표들이 많은데, 그러면 나의 서비스에서는 어떤 지표를 SLI로 정의해서 사용해야 할까? 특별히 정해진 정답은 없지만 시스템의 특성에 따라서 다음과 같이 정의한다.

  • 사용자에게 서비스를 제공하는 서비스 시스템 (웹,모바일등) : 가용성, 응답시간, 처리량

  • 스토리지 시스템(백업,저장 시스템): 가용성, 응답시간, 내구성

  • 빅데이터 분석 시스템 : 처리량, 전체 End-to-End 처리 시간

  • 머신러닝 시스템 : 서빙 응답시간, 학습 시간, 처리량, 가용성, 서빙 정확도

SLI 수집 및 표현

SLI 지표는 각종 모니터링 도구를 통해서 측정할 수 있고, 또는 로그 데이터에서 지표를 추출해 낼 수 있다. 예를 들어 정상 응답과 비정상 응답의 수를 카운트 하거나 또는 로그 메시지내에 있는 필드에서 값을 추출할 수 있다. 이렇게 추출된 값을 합하거나 평균 값을 내서 SLI를 정할 수 있는데, 평균값 보다는 값의 분포를 퍼센타일에 따른 분포를 사용하는것이 좋다. 아래 예제를 보자. 아래 예제는 웹 시스템의 응답 시간을 표현한 그래프이다.


50%,85%,95%,99% 응답 시간의 분포를 본것이다. 50%를 중간값이 이라고 생각하면 이 값이 일반적인 대표 값이 된다. 위의 그래프 값을 보면 20 ms 정도로 볼 수 있다. 느린 응답 시간, 즉 99%에 해당하는 응답 시간을 보면 5000ms (5초)가 나오는 것을 볼 수 있고 그래프 우측을 보면 응답 시간의 변화의 폭도 훨씬 큰것을 볼 수 있다.

실제 시스템에 문제가 되는 것은 느린값들 즉 99% 와 같은 구간에 속하는 응답시간이 문제가 되는데, 평균 값을 사용하게 되면, 느린 응답 시간이 희석화 되서 시스템의 안정성을 제대로 평가하기가 어렵다. 그래서 SRE에서는 퍼센트타일 기반의 SLI 분포도를 보고 90%,99%와 같이 문제가 되는 구간의 지표를 주요 SLI로 정해서 사용하는 것이 좋다.

SLI 지표의 표준화

SLI로 응답 시간이나 가용성 같은 지표를 사용하기로 정하면, 응답시간과 같은 SLI 지표는 여러 컴포넌트에 걸쳐서 측정해야 한다. 그런데 이러한 지표의 측정 단위가 표준화 되어 있지 않으면 혼선을 야기 하기 때문에, 표준을 정할 필요가 있다.


  • 수집 주기 : 지표를 뽑아내는 수집 주기를 10초 단위로 한다.

  • 수집 범위 : 수집 범위는 서비스 클러스터 단위로 한다.

  • 지표화 주기 : 수집은 10초 단위로 했지만, 지표화는 1분 단위로 해서 시각화 한다.

  • 어떤 호출들을 포함 할것인가? : HTTP GET 응답 시간만을 측정하고, 내부 호출은 측정하지 않는다.

  • 어떻게 데이터를 수집할것인가? : 모니터링 시스템을 통해서 수집한다.


이러한 SLI 표준은 여러 시스템에 적용될 수 있기 때문에 재 사용을 위해서 템플릿으로 만들어서 사용하는 것도 좋다.

SLO (Service Level Objective)

앞서 SLI를 통해서 시스템의 지표를 정의하는 방법을 이야기 하였다. 그러면 각 지표에 대한 목표 값은 어떻게 정의할까? 이를 SLO (Service Level Objective)라고 한다.


SLO = SLI + 목표값(Goal)


예를 들어 REST API의 응답시간을 SLI로 정했다면, SLO는 다음과 같이 정의할 수 있다.

“매주, 99% of REST API호출의 응답 시간은 100ms 이하여야한다.”

여기서 "매주,99% REST API 호출 응답시간"이 SLI가 되고, 응답시간 100ms가 목표값이 되서 위의 전체 문장이 SLO가 된다.

What user cares?

SLO를 정의할때 잘못하면, 서비스 제공자 관점에서 생각해서 SLO를 정의하기 쉬운데, SLO는 사용자 관점에서 서비스에 얼마나 영향을 주는 가의 관점에서 결정해야 한다.

시스템 관점에서 API 호출 응답시간이 80% 퍼센타일 구간에서 1초면 꽤 높은 것으로 느껴질 수 있지만, 모바일 서비스를 가정한다면, 모바일 서비스의 경우 지하철이나 차량 이동등으로 인해서, 모바일 네트워크 통신 속도 자체가 느리기 때문에, 80% 퍼센타일 구간에서  1초의 지연이면 사용자에게 체감되는 속도는 그렇게 느린편은 아니다. 이를 무리하게 맞추기 위해서 API호출 응답시간을 1초 이하로 내리는 행위는 적절하지 않다. (오버엔지니어링의 사례로 그 시간에 자동화나 다른 개발을 하는데 시간을 투자하는 것이 났다.)


또는 모바일 앱의 경우 통신망의 가용성이 99.99% 인데, 시스템의 가용성을 99.999%로 만든다 하더라도 통신망에서 더 많은 에러가 나기 때문에 쓸모 없는 SLO가 된다.


물론 많은 경우 사용자가 어떤 지표에 대해서 얼마 만큼의 기대값을 가지는지 알기 어려운 경우가 많다. 이런 경우에는 사용자의 기대치에 대해서 가설을 세워서 시작하고 측정하기 쉬운 항목부터 측정해가면서 나중에 실제로 유용한 SLO로 발전 시켜가는 접근 방법을 사용하도록 한다.


SLO는 반드시 사용자 관점에서 정의해야한다. SLO 관점에서 시스템에 문제가 없다 하더라도, Customer Support Team으로, 불만(성능/안정성)이 들어온다면, SLO 설정을 잘못했을 가능성에 대해서도 생각해봐야 한다. 이런 지표를 효과적으로 수집하기 위해서 Customer Support 항목에 성능/안정성 등에 대한 항목을 넣고 이를 모니터링 하는 것도 좋은 방법중의 하나이다.

좋은 SLO 란?

그러면 좋은 SLO의 정의란 무엇인가? SLO에서 설정하는 목표는 단순히 기술적인 목표가 아니라 그 비지니스가 추구하고자 하는 가치를 반영한 목표여야 한다. 그러면 좋은 SLO를 만들기 위한 조건을 보자

  • 단순할것
    좋은 SLO를 복잡하지 않고 단순해서 이해하기 쉬워야한다. SLO는 개발/운영 조직뿐만 아니라 영업 조직 및 고위 임원까지 모두 동의하고 사용하는 지표이기 때문에, 어려운 정의는 서로 이해하기가 어렵다.

  • 완벽한 값을 사용하지 말것
    완벽한 시스템을 존재할 수 없고 현실성이 없다. 예를 들어 100% 업타임인 무장애 시스템은 존재하지 않는다. 상식적으로 타당한 선에서 SLO를 정의하자

  • 되도록이면 적은 수의 SLO만 정의할것
    보통 시스템에는 하나의 SLO만을 사용하지 않는다. 여러개의 SLO 값을 지정해서 사용하는데, 많은 수의 SLO는 관리가 어렵고 실제로 제대로 사용되지도 않는다. 적은 수의 SLO를 사용하되, 사용되는 SLO는 비지니스 의사결정의 기준으로 사용될 수 있는 SLO만 사용하도록 한다. 의사결정에 사용되지 않는 SLO는 쓸모가 없는 SLO이다.

  • 지속적이고 점진적으로 SLO값을 발전 시킬것
    SLO의 값은 조직의 능력이나 비지니스의 상황에 따라서 지속적으로 조정해야 한다. SLO를 낮은 값에서 시작해서 점점 높은 수준의 값으로 발전 시키는 방법이 있고, 그 반대 방향도 있다.
    만약에 높은 값의 SLO를 목표값으로 시작했다가 개발/운영 조직이 이 목표를 맞추지 못했으니 SLO를 낮추자는 접근 방법은 그다지 좋지 못하다. SLO를 맞추지 못했을때  SLO를 계속해서 낮춰가는 나쁜 습관을 만들 수 있기 때문에 습관적으로 SLO 목표값을 점점 낮추게 되는 나쁜 결과를 나을 수 있다.
    그래서 SLO의 목표값은 낮은 값에서 시작해서 점차적으로 높은 값으로 바꿔 나가는 것이 바람직하다.

SLO에 대한 기대치 관리

SLO는 의사 결정의 기준이 되는 지표로 사용되기 때문에, SLO를 잘 이해하고 활용하는 것이 중요한데, 그중에서도 SLO에 관련된 이해 당사자들의 SLO에 대한 기대치를 잘 관리하는 것이 중요하다. 엄격하게 지켜야할 SLO이기는 하지만 너무 타이트하게 SLO를 잡으면, 반대로 다른 부작용이 발생할 수 있다.


  • SLO의 최소/최대 범위 지정

일반적으로 SLO는 "SLO<=목표값" 식으로 최대값만 설정하거나 또는 "최소값 <==SLO ⇐ 목표값" 형태로 설정을 한다." REST API 의 응답시간 ⇐ 300ms” 는 SLO로 크게 이상하지 않지만 “100ms <= REST API 응답시간 <==300ms”라고 정하는 것과 같이 최소값을 정하는 이유는 무엇일까?

100ms 이상의 지연을 허용한다는 점을 명시적으로 SLO에 적어놓게 되면, 개발자에게는 성능 향상의 목표가 생긴다. 300ms 이하를 유지 하면 되지만, 경우에 따라서 과하게 성능을 끌어 올리려고 몰두 하는 바람에, 정작 개발해야 하는 기능 개발을 하지 못할 수 있기 때문에, 오버 엔지니어링을 막는 차원에 SLO의 최소/최대 범위를 정하는 것도 좋은 방법이라고 할 수 있다.


  • 여유 값을 둘것

SLO를 정의할때, SLO를 외부에 공유해야 하는 경우 (예를 들어, 클라우드 서비스와 같은 경우) 외부에 공유하는 SLO와 내부에서 사용하는 SLO 둘을 나눠서 관리하고 내부용 SLO에 여유치를 둬서 외부용 SLO를 정의하면, 문제 발생시 어느정도의 여유 폭을 가질 수 있다.

물론 외부용 SLO가 사용자의 기대치에 미치지 못하는 수준이면 안되지만, 사용자가 인정할 수 있는 범위라면 어느정도의 여유 폭을 두는게 좋다.


  • Don’t overachieve

만약에 서비스에서 제공되는 성능이나 가용성이 SLO에 정의된 것보다 높다면 사용자는 당연히 현재의 성능에 익숙해진다. 예를 들어 시스템의 REST API 응답시간을 500ms 로 정해놨는데, 실제 시스템의 응답시간이 300ms 라면, 사용자는 이 300ms 응답시간에 익숙해질 것이고, 오히려 500ms 의 정상적인 응답시간이 나오면 느려진다고 느낄 수 있다.

  • 앞에 언급했던 SLO의 최소/최대 범위를 정하는 것도 이런 이유 중의 하나이다.


지금까지 SLO에 대해서 살펴보았다. SLO는 의사결정과 일의 우선 순위를 정하기 위한 매우 중요한 지표이다. 만약에 SLO가 의사 결정이나 우선 순위 결정에 사용되지 않는다면, 그 SLO와 넓게는 SRE 자체가 잘못된 것이다. SLO 는 SRE에서 그만큼 중요한 지표이기 때문에,  정의할 때 신중해야 하는데, SLO를 지정할때 너무 높은 수준의 SLO를 정하게 되면 SLO 수준에 맞는 성능과 안정성을 위해서 개발 자원을 투자해야 하고 그로 인해서 새로운 기능 개발이 늦어진다. 반대로 너무 낮은 수준의 SLO를 정하게 되면, 서비스 자체의 품질을 떨어 뜨린다.


앞에서도 계속  설명했듯이 SLO는 SRE에서 비즈니스 의사 결정과, 개발의 우선 순위를 결정하는등 아주 큰 의미를 가지는 중요한 지표이기 때문에, 현명하게 사용해야 한다.

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요


SRE는 어떻게 일하는가?

조대협 (http://bcho.tistory.com)


이글은 앞의 글 "SRE/DEOPS의 개념과 SRE는 무엇을 하는가?" (https://bcho.tistory.com/1325) 와 연결된 글입니다.

How SRE does Devops?

그럼 SRE들은 이런한 일들을 어떤 방법으로 수행할까?

앞에서 SRE가 해야 하는 일에 대해서 설명하면서 각각에 대해서 일부를 언급했지만, 다시 SRE가 해야하는 일을 하기 위해서는 어떻게(How) 해야 하는지에 대해서 다시 정리해보자.

SRE는 앞에서 언급한 다섯가지 일을 하기 위해서 아래와 같이 다섯 가지 방법을 사용한다.


Reduce organizational silos

첫번째는 부서간 (개발과 운영)의 사일로(단절) 현상을 없애는 노력을 한다. 여러가지 방법이 있겠지만 앞에서도 언급한 Share ownership 기반으로, 시스템 안정성에 대한 오너쉽(주인인식)을 서로 공유한다. 앞에 자세한 설명을 하였기 때문에 기타 부연 설명은 생략하겠다.

Accept failure as normal

두번째는 장애에 대해서 민감하게 반응하지 않아야 하는데, 이를 위해서는 서로 비난 하지 않는 문화와 장애가 발생후에 이를 회고 하고 향후 대책을 수립하는 Postmortem  회고를 수행한다. 또한 시스템의 가용성에 대한 적절한 관리를 위해서 Error budget 의 개념을 도입하여 사용한다.

Implement gradual changes

변화 관리 특히 배포에 관련해서 큰 변경보다는 작은 변경이 배포하기도 편하고 장애가 났을때도 쉽게 롤백이 가능해서 MTTR을 줄일 수 있기 때문에, 점진적인 변경 방법을 쓴다. 카날리 배포나 롤링 업그레이드들이 이에 해당한다.


Leverage tooling and automation

시스템 운영을 자동화 함으로써 사람이 운영에 관여하면서 발생할 수 있는 오류를 최소화하고, 수동(메뉴얼) 작업을 줄여서 사람은 좀 더 가치가 있는 일에 집중할 수 있도록 한다.

이렇게 하려면 수동작업의 양을 측정하고, 수동작업의 양을 적절한 수준으로 조절해야 하는데 이를 위해서 Toil 이라는 개념을 사용할 수 있다. 이 Toil의 개념은 나중에 다시 자세하게 설명하도록 한다.

Measure everything

그리고 SRE는 의사결정을 데이타에 기반으로하기 때문에, 어떤 값들을 어떻게 메트릭으로 표현할것인지를 정하고, 시스템 지표뿐만 아니라, 수동 작업 시간, 장애 시간등 모든 것을 측정해서 데이타화 한다.

Metric matters

앞에 까지 SRE가 무엇이고,  SRE가 하는일은 무엇이며, 어떻게 그런일을 하는지에 대해서 알아보았다. SRE 프랙티스 에서는 의사 결정을 데이터에 따라 하기 때문에, 지표를 정의하는 것이 중요하다. 그러면 SRE 에서는 어떤 지표를 어떻게 사용하는지에 대해서 알아보자. 다음글 https://bcho.tistory.com/1328



본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

AutoEncoder vs Variant AutoEncoder

빅데이타/머신러닝 | 2019.05.10 22:30 | Posted by 조대협

AutoEncoder vs Variant AutoEncoder


조대협 (http://bcho.tistory.com)


Abnormal

AutoEncoder는 입력값을 기반으로 여기서 특징을 뽑아내고, 뽑아낸 특징으로 다시 원본을 재생하는 네트워크이다. 이미지 합성이나 압축, Abnormal Detection 등 여러 유스케이스에 사용이 될 수 있지만, 특히 추출된 특징 (latent coding)은 데이타의 특징을 이해하는데도 유용하게 사용될 수 있다.

이 글에서는 AutoEncoder와 요금 각광 받는 VAE (Variant Auto Encoder) 의 차이를 알아보고 특히 latent coding의 값이 어떻게 다르게 표현되며, 어떤 의미를 가지는지에 대해서 이해한다.


일반 오토 인코더의 모양은 다음과 같다.



<그림 AutoEncoder의 구조>

출처 : https://excelsior-cjh.tistory.com/187


입력값 x로 부터 추출된 특징을 latent code z 라고 하는데,

이를 조금 더 이해하기 쉽게 표현해보면 다음과 같다.


<그림. AutoEncode의 latent code z 표현 방식 비교>

출처 : https://www.jeremyjordan.me/variational-autoencoders/


위의 그림은 오토 인코더를 이용해서 특징을 추출한 결과로 6개의 특징을 추출하였는데, 추출된 특징 latent code z는 특정 숫자값을 갖는다.

VAE는 이 latent code z의 값을 하나의 숫자로 나타내는 것이 아니라 가우시안 확률 분포에 기반한 확률값 (값의 범위)로 나타낸다.

아래 그림은 오토 인코더와 VAE에서 latent code z를 표현하는 방법을 설명한 것인데



<그림. AutoEncoder와 VAE의 latent code z 표현 방식 비교>

출처 : https://www.jeremyjordan.me/variational-autoencoders/


얼굴의 특징을 추출했다고 했을때 좌측은 오토인코더로 하나의 숫자로 특징을 표현하였고, 우측은 가우시안 확률 분포로 특징을 표현하였다. (확률값으로) 그래서 네트워크의 모양을 보면 다음과 같다.



<그림. VAE 구조>

출처 : https://excelsior-cjh.tistory.com/187


AutoEncoder latent coding 값이 single value z라면, VAE는 latent coding z를 가우시안 분포로 나타내기 위해서 평균과, 분산값으로 나타낸다.


AutoEncoder와 VAE의 latent space를 시각화 해보면 다음과 같은 차이를 발견할 수 있다. 아래 그림은 4 dimension latent space를 PCA(차원감소기법)을 통해서 2차원으로 변환한후 시각화 한 내용이다.


<그림. AE vs VAE의 latent space 비교>

출처 : https://thilospinner.com/towards-an-interpretable-latent-space/


MNIST에 대한 latent space인데, 각 점의 색깔은 0~9 숫자(이미지 라벨)을 표현한다.

좌측의 AE의 latent space는 군집이 넓게 퍼져있고, 중심점을 기반으로 잘 뭉치지 않는데 반해서 VAE는 중심점을 기반으로 좀더 컴팩트하게 잘 뭉쳐지는 것을 볼 수 있다.  그래서 원본 데이타를 재생하는데, AE에 비해 장점이 많고, latent space를 통해서 데이타의 군집을 파악하는데도 군집 강도가 높기 때문에 데이타의 특징을 파악하는데 좀더 유리하다.



참고 :


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

Site Reliability Engineering(SRE)

#1 SRE/DEVOPS의 개념

조대협 (http://bcho.tistory.com)

배경

Devops는 운영팀과 개발팀을 하나의 팀으로 묶어놓고 전체적인 개발 사이클을 빠르게 하고자 하는 조직 구조이자 문화이다.


이 Devops라는 컨셉이 소개된지는 오래되었지만, Devops의 개념 자체는 명확하지만 이 Devops를 어떻게 실전에 적용할것인 가는 여전히 어려운 문제였다.(예전에 정리한 Devops에 대한 개념들 1 , 2)  예전 직장들에 있을때 Devops의 개념이 소개되었고 좋은 개념이라는 것은 이해하고 있었지만, 여전히 운영팀은 필요하였고, 그 역할이 크게 바뀌지 않았다. 심지어 Devops를 하는 기업들도 보면 기존 개발팀/운영팀이 있는데, 새롭게 Devops팀을 만들거나 또는 운영팀 간판을 Devops팀으로만 바꾸는 웃지 못할 결과들이 있었다.

나중에 위메프에서 CTO를 하셨던 김요섭님의 강의를 들을 수 있는 기회가 있었는데, 그때 구글이나 넷플릭스와 같은 사례에 대해 들을 수 있었지만, 그에 대한 디테일한 프렉틱스는 찾을 수 가 없었다.


여러 고민을 하고 있다가 구글에 입사한 후에, 구글의 Devops에 대해서 알게되었고, 여러 자료를 찾아서 공부하고 나니 어느정도 이해가 되서, 개념을 정리해놓는다.

Devops와 SRE

일반적으로 개발팀은 주어진 시간내에 새로운 기능을 내기 위해서 개발 속도에 무게를 두고, 운영팀의 경우에는 시스템 안정성에 무게를 둔다. 그래서 개발팀이 무리하게 기능을 배포하게 되면 장애로 이어지고, 이러한 장애로 인하여 서로를 욕하는 상황이 만들어져서 팀이 서로 멀어지게된다. 그래서 Devops는 이러한 두팀을 한팀에 묶어 놓고 운영하는 문화이자 일종의 운영 철학이다.

그런데 그러면 운영팀과 개발팀을 묶어놓으면 운영을 하던 사람들은 무엇을 하는가? 요즘은 클라우드가 발전해서 왠만한 부분은 개발자들이 직접 배포하고 운영도 할 수 있지만 시스템이 커지면 여전히 운영의 역할은 필요하다. 그렇다면 Devops 엔지니어라고 이름을 바꾼 Devops 엔지니어들이 하는 일은 무엇인가?


그 해답을 구글의 SRE(Site Reliability Engineering)에서 찾을 수 있었는데, 개발자가 셀프 서비스로 운영을 하려면 그 플랫폼이 자동화되어 있어야 한다. 애플리케이션을  빌드하고 유연하게 배포하고, 이를 모니터링할 수 있는 플랫폼이 필요한데, SRE의 역할은 이러한 플랫폼을 개발하고, 이 플랫폼 위에서 개발자들이 스스로 배포,운영을 하는 것이 목표이다. 물론 완벽한 셀프 서비스는 불가능하다. 여전히 큰 장애 처리나 배포등은 SRE 엔지니어가 관여하지만 많은 부분을 개발팀이 스스로 할 수 있도록 점점 그 비중을 줄여 나간다.


그러면 구글 버전의 Devops인 SRE는 서로 다른것인가? 그 관계는 어떻게 되는가? 이 질문에 대해서는 다음 하나의 문장으로 정리할 수 있다.

“ class SRE implements Devops

Devops가 개발과 운영의 사일로(분단) 현상을 해결하기 위한 방법론이자 하나의 조직문화에 대한 방향성이다. 그렇다면 SRE는 구글이 Devops에 적용하기 위한 구체적인 프렉틱스(실사례)와 가이드로 생각하면 된다. 구글도 다른 기업들과 마찬가지로  회사의 성장과 더블어 2000 년도 즈음에 개발자들이 속도에 무게를 두고 운영팀이 안정성에 무게를 둬서 발생하는 문제에 부딪혔고, 이 문제를 풀고자 하는 시도를 하였는데 이것이 바로 SRE (Site Reliability Engineering)이다. SRE는 크게 3가지 방향으로 이런 문제를 풀려고 했는데,

  • 첫번째는, 가용성에 대한 명확한 정의

  • 두번째는, 가용성 목표 정의

  • 세번째는, 장애 발생에 대한 계획

구글 팀은 이러한 원칙을 개발자/운영자뿐만 아니라 임원들까지 동의를 하였는데, 좀 더 구체적으로 이야기를 하면, 이러한 원칙에 따라 장애에 대한 책임을 모두 공유한다는 컨셉이다. 즉 장애가 나도 특정 사람이나 팀을 지칭해서 비난 하는게 아니라, 공동책임으로 규정하고 다시 장애가 나지 않을 수 있는 방법을 찾는 것이다.

위의 3가지 원칙에 따라서, 가용성을 측정을 위해서 어떤 지표를 사용할지를 명확히 정하고 두번째로는 그 지표에 어느 수준까지 허용을 할것인지를 정해서 그에 따른 의사결정은 하는 구조이다.

SRE는 단순히 구글의 운영팀을 지칭하는 것이 아니라, 문화와 운영 프로세스 팀 구조등 모든 개념을 포함한 포괄적인 개념이다.

What does an SRE Engineer do?

그러면 SRE에서 SRE엔지니어가 하는 일은 무엇일까? 아래 그림과 같이 크게 다섯까지 일을 한다.



<출처. 구글 넥스트 2018 발표 자료>

Metric & Monitoring

첫번째는 모니터링 지표를 정의하고, 이 지표를 모니터링 시스템을 올리는 일이다. 뒤에 설명하겠지만 구글에서는 서비스에 대한 지표를 SLI (Service Level Indictor)라는 것을 정하고, 각 지표에 대한 안정성 목표를 SLO (Service Level Objective)로 정해서 관리한다.

이러한 메트릭은 시스템을 운영하는 사람과 기타 여러 이해 당사자들에게 시스템의 상태를 보여줄 수 있도록 대쉬 보드 형태로 시각화 되어 제공된다.

그리고 마지막으로 할일은 이런 지표들을 분석해서 인사이트를 찾아내는 일이다. 시스템이 안정적인 상황과 또는 장애가 나는 지표는 무엇인지 왜인지? 그리고 이러한 지표를 어떻게 개선할 수 있는지를 고민한다. 기본적으로 SRE에서 가장 중요한점중 하나는 모든것을 데이타화하고, 의사결정을 데이타를 기반으로 한다.

Capacity Planning

두번째는 용량 계획인데, 시스템을 운영하는데 필요한 충분한 하드웨어 리소스(서버, CPU,메모리,디스크,네트워크 등)을 확보하는 작업이다. 비지니스 성장에 의한 일반적인 증설뿐만 아니라 이벤트나 마케팅 행사, 새로운 제품 출시등으로 인한 비정상적인 (스파이크성등) 리소스 요청에 대해서도 유연하게 대응할 수 있어야 한다.

시스템의 자원이란 시스템이 필요한 용량(LOAD), 확보된 리소스 용량 그리고 그 위에서 동작하는 소프트웨어의 최적화, 이 3가지에 대한 함수 관계이다.

즉 필요한 용량에 따라 적절하게 시스템 자원을 확보하는 것뿐만 아니라, 그 위에서 동작하는 소프트웨어 대한 성능 튜닝 역시 중요하다는 이야기다. 소프트웨어의 품질은 필요한 자원을 최소화하여 시스템 용량을 효율적으로 쓰게 해주기도 하지만 한편으로는 안정성을 제공해서 시스템 전체에 대한 안정성에 영향을 준다.

그래서 SRE 엔지니어는 자원 활용의 효율성 측면에서 소프트웨어의 성능을 그리고 안정성 측면에서 소프트웨어의 안정성을 함께 볼 수 있어야 한다.

Change Management

세번째는 한글로 해석하자면 변경 관리라고 해석할 수 있는데, 쉽게 이야기 하면 소프트웨어 배포/업데이트 영역이라고 보면 된다. (물론 설정 변경이나 인프라 구조 변경도 포함이 되지만)

시스템 장애의 원인은 대략 70%가 시스템에 변경을 주는 경우에 발생한다. 그만큼 시스템의 안정성에는 변경 관리가 중요하다는 이야기인데, 이러한 에러의 원인은 대부분 사람이 프로세스에 관여했을때 일어나기 때문에, 되도록이면 사람을 프로세스에서 제외하고 자동화하는 방향으로 개선 작업이 진행된다.

이러한 자동화의 베스트프래틱스는 다음과 같이 3가지 정도가 된다.

  • 점진적인 배포와 변경 (카날리 배포나 롤링 업데이트와 같은 방법)

  • 배포시 장애가 발생하였을 경우 빠르고 정확하게 해당 문제를 찾아낼 수 있도록 할것

  • 마지막으로 문제가 발생하였을때 빠르게 롤백할 수 잇을것

자동화는 전체 릴리스 프로세스 중에 일부분일 뿐이다. 잠재적인 장애를 막기 위해서는 코드 관리, 버전 컨트롤, 테스트 등 전체 릴리즈 프로세스를 제대로 정의 하는 것이 중요하다.

Emergency Response

네번째는 장애 처리이다. 시스템 안정성이란 MTTF(Mean Time to failure:장애가 발생하지 않고 얼마나 오랫동안 시스템이 정상 작동했는가? 일종의 건설현장의 "무사고 연속 몇일"과 같은 개념)와 MTTR(Mean time to recover:장애가 났을때 복구 시간)의 복합 함수와 같은 개념이다.

이 중에서 장애처리에 있어서 중요한 변수는 MTTR인데, 장애 시스템을 가급적 빠르게 정상화해서 MTTR을 줄이는게 목표중의 하나이다.

장애 복구 단계에서 사람이 직접 매뉴얼로 복구를 하게 되면 일반적으로 장애 복구 시간이 더 많이 걸린다. 사람이 컨트롤을 하되 가급적이면 각 단계는 자동화 되는게 좋으며, 사람이 해야 하는 일은 되도록이면 메뉴얼화 되어 있는 것이 좋다. 이것을 “Playbook”이라고 부르는데, 물론 수퍼엔지니어가 있는 경우에 수퍼엔지니어가 기가막히게 시스템 콘솔에 붙어서 장애를 해결할 수 있겠지만 대부분의 엔지니어가 수퍼엔지니어가 아니기 때문에, “Playbook” 기반으로 장애 처리를 할 경우 “Playbook”이 없는 경우에 비해 3배이상 MTTR이 낮다는 게 통계이다.

그리고 "Playbook”이 있다고 하더라도, 엔지니어들 마다 기술 수준이나 숙련도가 다르기 때문에, "Playbook”에 따른 장애 복구 모의 훈련을 지속적으로 해서 프로세스에 익숙해지도록 해야한다.

Culture

마지막으로 문화인데, SRE 엔지니어는 앞에서 설명한 운영에 필요한  작업뿐만 아니라 SRE 문화를 전반적으로 만들고 지켜나가는 작업을 해야 한다. 물론 혼자서는 아니라 전체 조직의 동의와 지원이 필요하고, 특히 경영진으로 부터의 동의와 신뢰가 없다면 절대로 성공할 수 없다.

나중에 설명하겠지만 SRE에는 Error budget 이라는 개념이 있는데, 모든 사람(경영층 포함)해서 이 Error budget에 대해서 동의를 하고 시작한다. Error budget은 특정 시스템이 일정 시간동안 허용되는 장애 시간이다. 예를 들어 일년에 1시간 장애가 허용 된다면 이 시스템의 Error budget는 1시간이고, 장애가 날때 마다 장애시간만큼 그 시간을 Error budget에서 차감한 후에, Error budget이 0이 되면 더 이상 신규 기능을 배포하지 않고 시스템 안정성을 올리는 데 개발의 초점을 맞춘다.

그런데 비지니스 조직에서 신규 기능 출시에 포커스하고 Error budget이 0이 되었는데도 신규 기능 릴리즈를 밀어붙이면 어떻게 될까? 아니면 시스템 운영 조직장이 Error budget이 10시간이나 남았는데도 불구하고 10분 장애가 났는데, 전체 기능 개발을 멈추고 시스템을 장애에 잘 견디게 고도화하라고 하면 어떻게 될까? 이러한 이유로 전체 조직이 SRE 원칙에 동의해야 하고,장애가 났을 때도 서로 욕하지 말고 책임을 나눠 가지는 문화가 필요하다.

이런 문화를 만들기 위해서는 크게 3가지 가이드가 있는데 다음과 같다.

  • 데이타에 기반한 합리적인 의사결정
    모든 의사결정은 데이타 기반으로 되어야 한다. 앞에서도 설명했듯이 이를 지키기 위해서는 임원이나 부서에 상관없이 이 원칙에 동의해야 하고, 이것이 실천되지 않는다면 사실상 SRE를 적용한다는 것은 의미가 없다. 많은 기업들이 모니터링 시스템을 올려서 대쉬 보드를 만드는 것을 봤지만 그건 운영팀만을 위한것이었고, SRE를 하겠다고 표방한 기업이나 팀들 역시 대표가 지시해서. 또는 임원이 지시해서 라는 말 한마디에 모든 의사결정이 무너지는 모습을 봤을 때, 이 원칙을 지키도록 고위 임원 부터 동의하지 않는 다면 SRE 도입 자체가 의미가 없다.

  • 서로 비난하지 않고, 장애 원인을 분석하고 이를 예방하는 포스트포턴 문화
    장애는 여러가지 원인에서 오지만, 그 장애 상황과 사람을 욕해봐야 의미가 없다. 장애는 이미 발생해버린 결과이고, 그 장애의 원인을 잘 분석해서 다음에 그 장애가 발생하지 않도록 하는  것이 중요하다. 보통 장애가 나고나서 회고를 하면 다음에는 프로세스를 개선한다던가. 주의하겠다는 식으로 마무리가 되는 경우가 많은데. 사람이 실수를 하도록 만든 프로세스와 시스템이 잘못된것이다. 사람은 고칠 수 없지만 시스템과 프로세스는 개선할 수 있다. 그리고 모든 개선은 문서화되어야 하고 가능한것들은 앞에서 언급한 Playbook에 반영되어야 한다.

  • 책임을 나눠가지는 문화
    그리고 장애에 대해 책임을 나눠 가지는 문화가 있어야 한다. 예를 들어 장애란 개발팀 입장에서 장애는 코드의 품질이 떨어져씩 때문에 장애가 일어난 것이고, 운영팀입장에서는 운영이 고도화 되지 않아씩 때문이며, 비지니스쪽에서는 무리하게 일정을 잡았기 때문이다.  책임을 나눠 가지는 문화는 누군가를 욕하지 않기 위해서라기 보다는 나의 책임으로 일어난 장애이기 때문에, 장애를 없애기 위한 노력도 나의 역할이 되고 동기가 된다.


지금까지 간단하게 나마 SRE의 개념과 SRE엔지니어가 무슨 일을 하는지에 대해서 설명하였다. 다음은 그러면 SRE 엔지니어들이 어떻게 이런일을 해나갈 수 있는지 How(방법)에 대해서 설명하도록 하겠다. 다음글 https://bcho.tistory.com/1325




Reference


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. scinix 2019.05.11 17:40  댓글주소  수정/삭제  댓글쓰기

    Change Management는 "변화관리"보다는 "변경관리"로 번역하시는 게 맞을 것 같네요. ("What does..." 챕터에 있는 대부분의 내용은 ITMS 운영에서 일반적인 내용인데, 해당 부분은 국내에서는 "변경관리"로 부릅니다. 그리고 "변화관리"는 조금 다른 의미로 쓰입니다.)
    글 뒤 쪽의 "포스트포던"은 아마 포스트모텀(Postmortem; 부검)의 오타가 아닌가 싶네요.

    참고로, 저는 이 주제와 관련해서 다음 팟케스트를 재밌게 들었... 아니, 읽었습니다.
    https://www.gcppodcast.com/post/episode-127-sre-vs-devops-with-liz-fong-jones-and-seth-vargo/

  2. sangikbae 2019.05.13 12:58  댓글주소  수정/삭제  댓글쓰기

    예를 들어 장애란 개발팀 입장에서 장애는 코드의 품질이 떨어져씩 때문에 장애가 일어난 것이고, 운영팀입장에서는 운영이 고도화 되지 않아씩 때문이며, 비지니스쪽에서는 무리하게 일정을 잡았기 때문이다. 책임을 나눠 가지는 문화는 누군가를 욕하지 않기 위해서라기 보다는 나의 책임으로 일어난 장애이기 때문에, 장애를 없애기 위한 노력도 나의 역할이 되고 동기가 된다.

    울림이있네요

  3. 제쉬 2019.05.14 08:04  댓글주소  수정/삭제  댓글쓰기

    관리자의 승인을 기다리고 있는 댓글입니다

SRE는 구글의 Devops의 프랙티스 로 구글의 서비스에 대한 배경과 철학을 읽을 수 있다.

SRE의 기본 사상중의 하나는 서비스의 안정성이 완벽할 수 없으며, (아니 완벽하지 않게 만들며) 장애를 허용하는 모델이다.

고 가용/고 성능 시스템을 만들기 위해서는 그만큼 많은 개발에 대한 노력이 소요되는데, 이로 인해서 기능 개발에 대한 속도가 느려지기 때문에, 사용자가 납득할만한 수준의 가용성을 제공하되 개발의 속도를 유지하는 철학이다.

배경을 살펴보면 구글은 모바일을 기반으로 한 B2C 서비스를 주력으로 하기 때문에, 서비스가 99.999%의 가용성을 제공하더라도, 스마트폰과 통신망 자체가 그정도의 안정성을 제공하지 않기 때문에, 백앤드 서비스가 높은 가용성을 제공하더라도 사용자가 느끼는 가용성은 그 정도 수준이 되지 않는다. 그렇기 때문에 장애를 허용하면서 적정 수준의 가용성을 가지는 구조로 Devops 운영 모델이 정립되었다고 생각한다. 이러한 내용은 구글 엔지니어들이 저술한 SRE 서적에서도 찾아볼 수 있다.


이러한 사상을 반영하여 실제 운영환경에 적용하기 위한 구체적인 가이드와 프랙틱스가 SRE이다. 예를 들어 운영에 측정 가능한 지표를 SLI (Service Level Indicator)로 정의하고, SLI에 대한 목표를 SLO로 정해서 수치화하고 서비스 운영의 지표로 삼는 모델등 다양한 프랙틱스가 있는데, 이 부분은 차차 살펴봐야 겠다.

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요