SRE 1장 - 소개

시스템이 스스로 작동하지 않는다는 것은 이미 널리 알려진 사실이다. 그렇다면 대용량 작업을 수행하는 복잡한 컴퓨팅 시스템은 어떻게 운영되어야 할까?

 

서비스 관리를 위해 시스템 관리자를 활용하는 방법

  기존에는, 시스템 관리자들을 채용했었다. 이 시스템 관리자들은 소프트웨어 컴포넌트들을 모아 배포함으로써 서비스를 구축해 나간다. 이벤트와 업데이트에 대응하는데, 시스템의 복잡도와 트래픽이 증가할수록 감당하기 위해 시스템 관리팀의 규모 역시 커지게 된다.

 

  시스템 관리자를 두면 장점이 몇 가지 있다. 상대적으로 쉽게 서비스를 운영할 수 있다. 수많은 예시가 존재하기 때문이다. 전문 인력들도 이미 풍부하다. 도움이 되는 다양한 도구와 컴포넌트, 그리고 시스템 통합을 업으로 삼는 회사들도 많아서 조금 미숙하더라도 충분히 도움을 받아 시스템 운영이 가능하다.

 

  하지만 단점도 분명히 존재한다. 직접 비용이 상당히 많이 든다. 서비스와 트래픽이 증가함에 따라 업무량 역시 증가하므로 팀의 규모가 커져 결국 큰 비용을 지출하게 된다.

  개발팀와 운영팀을 나누는 데 필요한 간접 비용은 소소하지만, 종종 큰 비용이 발생하기도 한다. 두 팀의 배경 지식과 스킬, 동기 유발 조건 등이 각각 다르기 때문이다. 위험 요소나 기술적인 해법에 대해서 서로 다른 방향으로 예측하고, 안정성에 대한 목표 수준 역시 서로 다르게 예상한다. 

 

  운영팀과 그에 맞대응하는 제품 개발팀 간에는 충돌이 종종 발생한다. 주로 얼마나 빨리 프로덕션 환경에 릴리즈할 것인가로 인해 충돌이 발생한다. 개발팀은 빠르게 릴리즈를, 운영팀은 안정적으로 운영하기를 선호한다. 

 

서비스 관리에 대한 구글의 해법 : 사이트 신뢰성 엔지니어링

  서비스를 공급하는 데 있어 충돌이 필연적인 요소는 아니다. 구글은 시스템 운영에 대해 약간은 다른 접근법을 취하고 있다. 구글의 SRE팀은 제품을 운영하고, 때로는 시스템 관리자가 수동으로 처리하던 일을 대신할 시스템을 개발하기 위해 소프트웨어 엔지니어를 채용한다. 

 

  그렇다면 사이트 신뢰성 엔지니어링(SRE)이란 정확히 어떤 개념일까? 간단하게 설명하면, 운영팀을 위한 소프트웨어 엔지니어를 말한다. 

 

 SRE 채용에 대한 결과로 구글은 크게 두 부류의 사람들로 구성된 팀을 완성하게 되었다. 

1. 어떤 작업을 손으로 직접 수행하는 것을 금세 싫증 내는 부류
2. 해결책이 복잡한 경우라 하더라도 이전까지 사람이 손으로 하던 작업을 대신할 수 있는 소프트웨어를 작성하는 데 필요한 기술을 갖춘 부류

그래서 SRE팀은 기본적으로 기존의 운영팀이 수행하던 업무를 수행한다. 다만 인간의 노동력을 대체할 자동화된 소프트웨어를 설계하고 구현하려는 성향과 능력을 활용한다는 차이점이 있다. 

 

SRE팀은 엔지니어링에 초점을 맞춘다. 끊임없이 엔지니어링을 추구하지 않으면 운영 업무에 대한 부담은 서비스 트래픽과 함께 증가하게 되고, 사람을 계속해서 채용할 수 밖에 없다.

 

  이러한 숙명에서 벗어나려면 서비스를 관리하는 팀은 코드를 작성해야 한다. 구글은 SRE팀에 소위 '운영' 업무에 최대 50%의 시간만 투입하도록 정해두고 있다. 이 시간은 최대상한값이다. 시간이 흐르면서 SRE팀의 운영 부담은 최소한의 수준으로 줄어들고 대부분은 개발 작업에 투입된다. 스스로 복구가 가능한 수준이 되기 때문이다.  구글의 첫 번째 규칙은 SRE팀은 반드시 남은 50%의 시간을 오롯이 개발을 위해 활용해야 한다는 것이다. 

 

  SRE들은 모두 자신들의 필요에 따라 직접 코드를 수정하므로 빠르게 혁신하고 변화를 폭넓게 수용하는 특징을 보인다. 결과적으로 SRE 팀을 도입함으로써 개발과 운영의 분리로 인한 부작용을 피할 수 있을 뿐만 아니라 개발팀의 성장에도 도움이 되었다. 

 

제품 개발팀과 SRE팀 간에 손쉬운 업무 전환을 허용함으로써 전체 구성원들이 두 분야를 모두 학습할 수 있게 되었고, 개발자들의 성장으로 이어졌다.

 

이러한 장점과 더불어 SRE 모델은 독특한 도전과제가 즐비하다는 특징도 있다. 하나는 SRE의 채용이다. 채용 기준이 코딩 및 시스템 엔지니어링 기술 전반에 걸쳐 너무 높게 형성되어 있었다. 하지만 그에 상응하는 인력 수가 많지 않다는 것이 문제다.

혹자는 데브옵스를 SRE의 여러 원리를 좀 더 폭넓은 조직과 관리 구조 및 개인에 적용하기 위해 일반화한 모델로 바라보기도 한다. 어떤 사람은 SRE를 확장된 형태의 데브옵스로 분류하기도 한다. 

 

SRE의 신조

SRE팀은 가용성, 응답 시간, 성능, 효율성, 변화 관리, 모니터링, 위기 대응, 그리고 서비스의 수용량 계획에 대한 책임을 진다. 

 

지속적으로 엔지니어링에 집중한다

SRE가 운영 업무에 투입할 수 있는 시간을 최대 50%로 제한하기 위해, SRE가 수행한 운영 업무의 양을 지속적으로 모니터링하고 초과 운영 업무가 발생하면 이는 제품 개발팀에서 처리하도록 했다. 사실 이런 방식은 전체 조직, 즉 SRE와 개발팀 전체가 제품에 대한 운영 부담을 최소화함으로써 과중한 업무가 발생하지 않도록 해야 한다는 목적을 달성하려는 충분한 의지가 있어야 비로소 그 효과를 볼 수 있다.

 

  SRE가 운영 업무에 집중할 때는 업무 시간 동안 최대 두 건의 업무만을 담당하게 한다. 그러면 업무를 최대한 정확하고 신속하게 처리한 후, 주변을 정리하고 포스트모텀(postmortem)을 작성하기까지 할 수 있다. 

 

포스트모텀 : 사후 분석

 

  모든 심각한 장애에 대해서는 알림 여부를 떠나 반드시 포스트모텀을 작성해야 한다. 알림을 발생시키지 않은 건에 대한 포스트모텀이 더 중요한 이유는 모니터링되지 않고 있는 부분을 알 수 있기 때문이다. 

 

  해당 장애에 대한 조사를 통해 발생한 현상에 대한 상세한 내용과 발견된 모든 원인, 그리고 그 문제를 해결하거나 개선하기 위해 취했던 행동, 마지막으로 같은 문제가 다시 발생했을 때의 대응 방안 등을 도출해야 한다. 실수를 공유함으로써 엔지니어가 자신의 단점을 피하거나 숨기려 하지 않고 스스로 고쳐나갈 수 있도록 유도하는 문화로 이미 정착되어있다.