이 책은 구글의 "사이트 신뢰성 엔지니어링(Site Reliability Engineering)" 즉, SRE가 무엇인지 설명하는 책이다. 구글에서는 10년 이상 전부터 SRE라는 역할을 가진 사람들이 있었다고 하는데 그 경험을 가지고 SRE를 외부에 소개하기 위해서 웹사이트를 만들고 내부 SRE들의 경험을 모아서 책으로 공개했다. 이 책은 구글이 공개한 이 책을 번역한 책이다.

소프트웨어 엔지니어링도 마찬가지로 제품을 출시한 이후보다는 출시하기 전에 더 많은 노력이 필요한 것처럼 보이지만, 사실 시스템의 총비용 중 어림잡아 40%~90%가 제품을 출시한 이후에 발생한다. 현재 소프트웨어 업계에서는 프로덕션 환경에 배포가 완료되어 실제로 동작하는 소프트웨어를 '안정화된' 것으로 생각하고 소프트웨어 엔지니어들이 이에 대해 비교적 신경을 덜 쓰는 형태가 정착되어 있는데, 이는 완전히 잘못된 것이다. 이 관점에 따라 소프트웨어 엔지니어링이라는 것이 주로 소프트웨어 시스템을 디자인하고 개발하는 데 초점을 맞춘 것이라면, 소프트웨어 객체를 처음부터 배포와 운영, 개선, 그리고 폐기에 이르기까지 전체 생명주기를 다루는 방법 또한 존재해야 한다.

나는 이전에 있던 회사에서 SRE팀을 만들면서 SRE에 대해서 본격적으로 관심을 가지기 시작했다. "SRE가 어떤 일을 하는가?"에 대해서 설명을 하다 보면 대부분은 "DevOps구나"라고 받아들인다. 꼭 틀린 말은 아니라고 생각하지만 요즘 관심 분야기도 하고 구글은 SRE라는 역할을 어떻게 보고 만들어왔는지가 궁금해서 이 책이 나오자마자 사서 읽게 되었다. 페이지가 500페이지가 넘는데 이렇게 두꺼운 책을 보는 건 오랜만이지만 재미있게 읽었다.

업계 표준 용어인 데브옵스를 다른 의미를 가진 단어로 간주한다. 분명히 코드로서의 인프라스트럭처에 무게 중심을 두기는 하지만, 우리에게 가장 중요한 것은 신뢰성이기 때문이다.

이 책은 SRE가 무엇인지 장황하게 설명하기보다는 실제로 구글 내에서 SRE가 어떻게 일을 하는지를 구체적으로 설명하고 있다. 그래서 각 장의 저자들은 다 다른 사람들이고 이렇게 에세이처럼 작성된 많은 글을 분야별로 묶어서 하나의 책으로 낸 것이다. 다 읽고 나서도 그래서 SRE는 무엇이지? 우리 조직에서는 어떻게 해야 하지?에 대한 명확한 답을 얻지 못할 수도 있다고 생각한다. 대신 쉽게 알지 못하던 구글 내에서 SRE가 어떻게 일하는지를 자세하게 살펴보고 있고 이런 접근방식에서 많은 생각을 하게 될 수 있을 것 같다. 내가 SRE로 일한다면 이 책에 나온 부분과 비슷한 사례를 겪으면 책을 다시 한번 참고하고 접근방식에 대해서 다시 한번 고민해 보면 많은 것을 얻을 수 있을 것 같다.

추가로 이 책을 읽으면서 계속 든 생각은 "내가 있는 조직은 구글이 아니다."라는 점이었다. 이 책에 나오는 수많은 사례에서 "이 정도 까지 고민하고 이런 부분까지 개선하는구나!" 싶으면서도 내가 속한 조직에서 이렇게까지 할 일이 있을지, 혹은 그런 노력을 들일 여유가 있을지 하는 생각이 들었다. 구글과 똑같이 할 여력은 대부분 없으니 구글의 SRE는 어떤 마인드로 일하는가에 더 집중해야 할 것 같다.

Part 1 소개

SRE란 운영팀을 위한 소프트웨어 엔지니어를 말한다.

SRE가는 용어가 아직 많이 알려주지 않으므로 1부에서는 SRE에 대해 설명한다.

기본적으로 SRE팀은 엔지니어링에 초점을 맞춘다는 점이 가장 중요하다. 끊임없이 엔지니어링을 추구하지 않으면 업무 부담이 증가하여 그 부담을 나누기 위해 더 많은 인력이 필요하게 되고 결국에는 서비스의 크기에 따라 전통적인 운영 업무를 담당하는 인력이 기하급수적으로 늘어나게 된다.
...중략...
이러한 숙명에서 벗어나려면 서비스를 관리하는 팀은 코드를 작성해야 한다. 그렇지 못하면 늘어나는 일감에 파묻히게 될 뿐이다. 그래서 구글은 SRE팀에 티켓, 전화 응대, 수작업 등, 소위 '운영' 업무에 최대 50%의 시간만 투입하도록 정해두고 있다.

SRE가 접근하는 방법에 거의 동의하는 편이다. 구글이 사내에서 어떻게 SRE가 시간을 사용하는지 추적하는지가 궁금하긴 했지만...

사실 우리가 원하는 것은 시스템이 자동화되는(automated) 것이 아니라 자동적(automatic)이 되는 것이다.

Part 2 원리와 원칙들

그동안 SRE를 운영하면서 쌓아온 경험을 바탕으로 한 원칙들이 2부에 정리되어 있다.

사용자들은 주로 적절하게 높은 수준의 신뢰성과 극대화된 신뢰성의 차이를 알아차리지 못한다. 왜냐하면, 사용자의 경험이란 모바일 네트워크나 그들이 사용하는 장비처럼 신뢰성이 낮은 컴포넌트들에 의해 좌우되기 때문이다.
...중략...
SRE는 이런 점을 고려하여 업타임을 극대화하는 대신, 서비스가 다운될 수 있는 위험 요소와 빠른 혁신과 효과적인 서비스 운영 사이의 균형을 찾음으로써 사용자의(기능, 서비스, 그리고 성능에 대한) 전체적인 만족도를 향상시키는 것에 집중된다.

처음부터 그랬는지 진행하면서 개선되어 있는지는 모르지만, 구글이 꽤 큰 조직임에도 실용성을 유지하고 있음이 느껴졌다. 말로만 하면서 실용성이 떨어지는 것이 아니라 실제로 더 나아지도록 많은 고민을 한 걸 알 수 있었다.

우리의 목표는 서비스에서 발생 가능한 위험 요소 중 기업이 기꺼이 부담할 용의가 있는 위험 요소들을 찾아내는 것이다. 우리는 충분히 신뢰할 수 있는 서비스를 구현하기 위해 노력하지만, 필요 이상의 신뢰성을 확보하려고는 하지 않는다.

SLO는 서비스 수준 목표(Service Level Objectives)를 의미하며, SLI에 의해 측정된 서비스 수준의 목표 값 혹은 일정 범위의 값을 의미한다. 그래서 SLO는 SLI <= 목표치 또는 최소값 SLI <= 최댓값으로 표현할 수 있다.

책 전체에서 SLO 얘기가 계속 나오는데 SRE가 이 수치를 큰 목표로 하고 있음을 알수 있었다. 이런 수치를 목표로 작업해 본 적은 없기는 한데 운영 관점에서 상태를 파악하기 좋은 수치라는 생각이 들었다.

삽질이란 프로덕션 서비스를 운영하는 것과 직접적으로 연관이 있지만, 수작업을 동반하고, 반복적이며, 자동화가 가능하고, 사후 대처가 필요하며(tactical), 지속적인 가치가 결여되어 있으면서도 서비스의 성장에 따라 지속적으로 늘어나는 업무들을 말한다.

우리는 소프트웨어 기반의 자동화는 대부분의 상황에서 사람이 직접 수행하는 작업보다 우수하다고 생각하기는 하지만, 이 두 가지보다 더 나은 방법은 둘 다 필요치 않은 고수준의 시스템, 즉 자율(autonomous) 시스템을 디자인하는 것이다.

결국, 우리의 임무는 시스템의 신속함과 안정성 사이의 균형을 유지하는 것이다.

Part 3 사례

3부에서는 구체적인 프로젝트나 사례를 가지고 설명한다. 구글에서 SRE가 어떤 일을 처리하고 어떻게 접근하는지를 볼 수 있고 구글의 시스템을 엿볼 수 있어서 개발자로서도 재미있는 부분이었다. 개별 사례를 정리하기는 무리이니 인상적인 부분만 정리한다. 특히 앞에서 얘기한 "우린 구글이 아니다"를 많이 생각한 부분이기도 한데 분산 크론을 구현하거나 마이크로서비스에서 연속적인 장애를 막기 위해 처리하는 사례에서 많이 놀랐다.

우리는 'SRE'에서 'E'가 우리 조직의 특성을 정의한다고 믿고 있으므로 최소 50%의 시간을 엔지니어링에 투자하려고 노력한다. 남은 50% 중에서는 25% 정도를 비상대기에 사용하고 나머지 25%는 프로젝트 업무가 아닌 다른 운영 업무에 할애한다.

운영 업무의 부족은 SRE팀에게 있어서는 당황스러운 부분이다. 프로덕션 환경을 너무 오래 접하지 못한다면 자신감이 너무 지나치거나 혹은 부족해질 수 있으며, 더 큰 문제는 실제 환경과 SRE가 보유한 지식 간의 차이가 장애가 발생한 후에야 비로소 드러난다는 점이다.

우리의 규모와 변화의 속도를 고려하면 사건 사고는 필연적인 것이다.
...중략...
이런 장애들로부터 계속해서 학습할 수 있는 정규화된 절차를 갖지 않는다면 이런 장애들은 무한정 반복될 것이다.

SRE가 엔지니어링에 많은 투자를 하고 있기는 하지만 소프트웨어 개발 조직은 아니므로 운영에 대한 부분에도 계속 신경 쓰고 있다는 것을 알 수 있다. 추측건대 전통적인 운영조직을 SRE로 바꾸면서 엔지니어링을 강조하게 되지만 실제로는 운영업무가 나머지 반이므로 지금은 운영업무에 대해 감이 너무 적어지지 않도록 계속 유지하는 것 같다. 특히 운영에 문제가 없어서 잘 동작하는 경우 SRE가 개입할 일이 적어지면 프로덕션에 대해 감이 멀어져서 생기는 잠재적인 문제를 해결하기 위해 노력하는 것도 인상적이었다.

어떤 종류의 장애도 발생할 수 있다는 생각보다는 모든 것이 잘못될 수 있다는 생각을 갖는 것은 실제로 발생할 긴급 사태를 대비하기 위한 중요한 과정이다. 가능한 모든 재난의 조합과 각 재난에 대응하기 위한 계획을 세워두면 적어도 하룻밤의 숙면을 보장한다.

한편으로는 SRE나 DevOps에 관심이 있지만 나는 소프트웨어 엔지니어로서의 경력을 계속 가져왔기 때문에 대부분 접근방법도 소프트웨어 엔지니어링에 치중되어 있다는 생각이 들었다. 각종 사례를 읽다 보니 나는 좀 더 운영 쪽 마인드와 접근방법을 배울 필요가 있겠다 싶었다.

무언가를 배우는 데 있어 과거에 있었던 일을 문서로 남기는 것보다 나은 방법은 없다. 기록은 다른 누군가의 실수를 바탕으로 학습을 하는 것이다.

포스트모텀은 SRE에게는 필수적인 도구다.
...중략...
포스트모텀은 불이익을 주기 위한 것이 아니다. 회사 전체가 실패로부터 새로운 것을 배울 수 있는 기회인 것이다.
...중략...
서로를 비난하지 않는 포스트모텀은 SRE 문화의 신조다. 실제로 포스트모텀 과정에서 누군가를 비난하는 상황을 완전히 방지하려면 어떤 개인이나 팀의 실수나 부적절한 조치를 지목하지 않고 장애를 유발한 원인을 판단하는 데 집중해야 한다.

포스트모텀이나 문서로 남기는 부분은 그동안 해온 접근이 틀리진 않았구나 하는 생각과 구체적인 사례를 보니 더 개선할 부분도 꽤 있겠다는 생각도 들었다.

Part 4 관리

4부에서는 SRE 조직은 운영하고 다른 팀과 협업하는 관리 측면을 얘기하는데 내가 관리자는 아니다 보니 확 다가오진 않았다. 나중에 비슷한 고민을 할 때 참고해 보면 좋을 것 같기는 하다. 특히 다른 팀과 SRE의 협업 관점은 생각해 볼 만한 부분도 많고 구글도 개발조직이 SRE를 호의적으로 받아들이지 않는다는 느낌도 있었다.

SRE 지원자는 찾기도 어려울 뿐 아니라 효과적으로 면접을 진행하기는 더욱 어렵다.

구글에서도 어려운 거 보면 아직은 SRE는 역할이 업계에 제대로 자리 잡은 건 아닌 것 같다. 아마 시간을 들여서 책을 쓰고 사이트도 만들고 하는 것이 이런 이유 때문이 아닐까 싶다.

엔지니어들은 산만한 주변 환경으로 인해 여러 가지 방식으로 인지적 몰입 상태를 이루지 못한다.
...중략...
주의가 분산되는 상황을 최소화하기 위해서는 컨텍스트 전환(context switching)을 최소화해야 한다. 일부 방해 요소는 불가피하다.

막연하게 SRE라는 용어만 사용하고 있었는데 책을 다 읽고 나니 많이 구체화한 느낌이다. 아직도 그래서 SRE가 뭐야? 라고 하면 너무 많은 생각이 스쳐 지나가서 잘 정리 안 되긴 하지만....

마지막으로 Google에서 올린 What's the Difference Between DevOps and SRE?라는 영상을 공유한다. 5분짜리 영상이지만 DevOps와 SRE가 어떻게 다른지를 이해하기 쉽다고 생각한다. "If you think about DevOps as a philosophy, SRE is a prescriptive way of accomplishing that philosophy."가 핵심이라고 생각하고 있다.

“class SRE implements DevOps”