DevOps의 온기가 식기도 전에 또 새로운 용어가 나타났습니다. SRE라는 단어가 요새 컨퍼런스나 솔루션 설명회, 또는 RFP 제안설명회에서 인용되고 있어 한번 정리해보았습니다.
제목은 SRE 이지만 내용의 이해를 위해 Agile과 DevOps도 꽤 언급되어 있음을 미리 알려드립니다.
SRE는 구글내 한 부서의 이름입니다. 이 부서는 2003년(무려 이십여년전)에 만들어졌는데, 국내에서는 최근 1년 사이에 조금씩 눈에 보이고 있고, 해외의 경우도 2~3년 전부터 빠르게 퍼지는 느낌입니다. 참고로 구글은 2016년 부터 2년 단위로 SRE Workbook을 온라인에서 무료로 발간하고 있는데, 이 Workbook의 양도 어마어마합니다.
그러니 아무리 잘 요약한다한들 이 한페이지에 담는 건 어불성설입니다.
Google - Site Reliability Engineering
The Site Reliability Workbook Edited by: Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara and Stephen Thorne The Site Reliability Workbook is the hands-on companion to the bestselling Site Reliability Engineering book and uses concrete exa
sre.google
사족을 하나 붙이자면 국내금융사의 디지털부서의 보고서에 빠지지 않는 양념이 바로 Agile과 DevOps라는 용어입니다. 실제 현실은 아직 Waterfall 인 느낌인데...머 저만의 느낌일수도 있구요. 아직 국내는 앞서 말씀드린 애자일과 데브옵스로도 숨이 차선지 SRE를 도입하거나 적용한 사례를 많이 보진 못했습니다.
이제 SRE에 대해 조금 더 깊이 들어가겠습니다. 먼저 직관적으로 이해하기 위해 SRE를 구성하고 있는 단어를 하나하나 연결해 보겠습니다. "Site(서비스가 수행되는 곳)이 Reliability(신뢰)받게 하기 위한 공학(Engineering)이다." 정도가 되겠네요.
이번엔 이 단어를 만들어낸 구글의 SRE 부서페이지에서는 이렇게 정의하고 있습니다.
SRE is what you get when you treat operations as if it’s a software problem. Our mission is to protect, provide for, and progress the software and systems behind all of Google’s public services — Google Search, Ads, Gmail, Android, YouTube, and App Engine, to name just a few — with an ever-watchful eye on their availability, latency, performance, and capacity.
짧은 영어로 해석하여 요약하자면...
"SRE(부서)는 운영업무를 할 때 이것을 소프트웨어적인 문제인 것처럼 다룰 때(접근할 때) 당신이 얻는 것입니다. 우리의 미션은 구글의 모든 소프트웨어와 시스템 및 서비스를 보호하고 공급하며, 진보시키기 위해 이들에 대한 가용성, 지연여부, 퍼포먼스, 용량을 끊임없이 관찰하는 것입니다."
운영과 개발의 Silo는 갖은 방법을 동원해도 해결되지 않는 IT업계에서의 오랜 숙제 중 하나입니다. 이러한 Silo의 해결을 위해 다양한 시도가 이루어지고 있는데 그 중 하나가 DevOps방식이고, SRE 역시 그와 맥을 같이 한다고 생각됩니다. 그래서 구글에서는 DevOps를 철학(Philosophy)으로 본다면 SRE는 이 철학을 완수하는 잘 정돈된 일하는 방식이라 설명하고 있습니다.
"SRE is a prescriptive way of accomplishing DevOps philosophy."
이해가 되시나요? 보통 Agile은 업무분석 및 설계의 방법론으로 DevOps는 개발과 운영이 어우러지는 그 다음단계의 발전단계로 이해하는 경우가 많습니다. SRE 또한 DevOps보다 조금더 효율화되고 발전되어 TCO를 줄이는 하나의 방법론으로 국내에서는 인용되는 경우를 봤습니다만, 제 개인적인 생각은 이들은 어느정도의 시간순서를 갖긴 하겠지만, 각각의 사상(또는 방법론)이 서로 일정부분 공통된 기본철학을 가지긴 하지만 독립적인 방법론으로 봐야 한다고 봅니다. 미시경제와 거시경제의 쓰임새가 다르지만 연결고리가 많은 것과 비슷하겠죠.
예를 들어 기획에이전시 같은 곳은 애자일 방법론을 적용하는게 적절할테고, 서비스를 기획부터 실제로 배포하는 곳이라고 해서 반드시 DevOps가 적절한 게 아니라 운영팀이 있는 사이트에서 적용되어야 할테고, 또 조직이나 운영하는 서비스의 규모에 따라 이러한 방법론이 적절한지 따져봐야 합니다. 또한 구글처럼 기획부터 개발, 운영까지 모두 커버해야 하는 조직에서는 서비스(Site)의 신뢰도(Reliability)를 실체화하고 측정하기 위해 조금더 feasible한 접근이 필요하여 SRE라는 개념이 필요하다는 겁니다.
다시 SRE로 돌아가보겠습니다.
구글에서는 SRE의 특징에 대해 아래와 같은 5가지 키워드를 내세웁니다. 물론 조금 더 있고, 조금 더 부연설명된 부분도 있으나, 아래 정도의 특징이면 기본 개념을 이해하는데는 충분합니다.
Sharing ownership of production, Blameless postmortems, Gradual Change, Eliminating manual work(Automating), Measuring toil and reliablility
대부분의 단어는 직관적으로나 사전적으로 이해되실테고, Blameless Postmortems를 잠깐 언급해보겠습니다.
다른 키워드들과 마찬가지로 사전을 찾아보시면, '사후부검'이라 해석됩니다.
뜻 자체는 섬뜩하지만 해외의 많은 스타트업이나 빅테크에서 자신들의 특장점으로 내세우는 것이기도 합니다.
이는 어떤 문제(라 말하고 '사고'라고 보고되죠.)가 생겼을때, 이에 대하여 비난 없이 본인이 직접 부검(분석)을 하라는 겁니다. 일반적으로 분석이 완료되면 회사의 전 사원에게 메일로 보낸다고 합니다. 매우 감동적인 Practice가 아닐 수 없습니다. 국내의 경우 사고가 나면 가장 먼저 범인찾기를 해야하고, 다음날 감사실에 불려갈 준비를 해야할텐데 말이죠.
전 위에 언급된 특징들을 보며, Agile, XE(Extreme Programming), DevOps, CBD 등등의 단어들이 떠올랐습니다.
아마 그 이유는 이 모든 Software Engineering 방법론 및 다양한 시도들이 결국은 수요자와 공급자 모두의 win-win을 위한 노력이기 때문이고 이같은 노력은 본질이 동일하니 특징 역시 유사하게 나타날 수밖에 없을 것입니다.
SRE는 DevOps라는 철학을 실현하기 위한 구글이라는 회사가 고민한 결과물입니다.
즉, 운영(Operation)하는 서비스의 안정적이고 점진적인 발전을 위한 실질적인 방법론이라고 정의할 수 있겠습니다.
"class SRE implements DevOps."
구글이 한문장으로 요약한 SRE와 DevOps의 관계인데요,
이를 직역하면 '클래스 SRE는 (인터페이스 클래스인) DevOps를 구현한다.' 정도가 됩니다. 객체지향 프로그래밍을 해 본 사람은 익숙하겠지만 여기에서는 조금더 인간들의 언어에 가깝게 해석해보자면, 이상적인 DevOps의 사상(철학)을 SRE를 통해 실현한다 정도로 해석될 수 있습니다.
마지막으로 제가 찾아 본 비교표 중 가장 깔끔하게 정리한 테이블 붙입니다.
'2-minutes lecture' 카테고리의 다른 글
| 마이크로 인터랙션 톧아보기 (0) | 2021.10.25 |
|---|---|
| 와이어프레임, 목업, 프로토타입, 스토리보드 구분하기 (0) | 2021.10.22 |
| API vs. BaaS vs. Embedded Finance (0) | 2021.10.20 |
| 유학유직-유 (0) | 2021.10.14 |
| Global PEF (초보자 가이드) (0) | 2021.09.29 |
