Ch11. 비상 대기

이번 장에서는 구글의 SRE들이 수년에 걸쳐 개발한 비상 대기(on-call) 업무 수행 방안의 기본적인 원리에 대한 소개와, 이를 바탕으로 서비스의 안정성을 보장하고 업무 부하를 안정적으로 유지하는 방법에 대해 설명하고 있다.

 

1. 소개

구글은 성능과 신뢰성을 책임지는 전담 SRE팀이 있다. 이러한 SRE 분들이 서비스를 위한 비상 대기 업무를 수행하는데 주요 임무는 자신들이 관리하는 서비스들을 문제 없이 운영하는 것이다.

 

문제 없이 운영하기 위해서는 하나의 분야에 특화된 사람이 아니라 다양한 사람들이 필요하다. 따라서 구글은 시스템과 소프트웨어 엔지니어링에 있어 각기 다른 배경지식을 가진 사람들을 SRE팀에 충원하고 있다. 또한 SRE가 순수한 운영 업무에 할애할 수 있는 시간을 최대 50%로 제한하고 있어 최소한 50%의 시간을 서비스 개선은 물론 자동화를 통해 팀의 업무 수행을 개선할 수 있는 엔지니어링 프로젝트에 할애하도록 하고 있다.

 

2. 비상 대기 엔지니어의 삶

비상 대기 엔지니어는 프로덕션 시스템의 보호자로서 팀에 영향을 미치는 장애를 관리하고 프로덕션 환경의 변경을 추진 및 진단하는 등 할애된 운영 업무를 수행한다.

 

비상 대기 시에 엔지니어는 수 분 이내에 프로덕션 환경에서 필요한 운영 작업을 수행할 수 있어야 한다. 이 시간은 사전에 약속된 장애 대응 시간으로 팀과 비즈니스 시스템 소유자의 동의하에 결정된 시간이다. 통상 이 시간은 사용자에게 노출되거나 혹은 시간이 매우 중요한 서비스의 경우에는 5분 정도이며, 시간에 민감하지 않은 서비스의 경우에는 30분 정도라고 한다.

 

많은 팀들이 주 비상 대기조와 보조 대기조를 동시에 운영한다. 주 대기조와 보조 대기조에 어느 정도의 업무를 할당할 것인지는 각 팀이 알아서 결정한다. 보통 아래와 같다.

• 주 비상 대기조가 장애 알림을 놓치는 경우를 대비해 보조 대기조를 운영
• 주 대기조는 장애 알림만 처리하고 보조 대기조는 나머지 프로덕션 업무들을 처리하도록 운영

 

3. 비상 대기 업무의 균형 맞추기

SRE 관리자는 비상 대기 업무의 부하를 균형 있게 관리하고 업무의 양과 품질을 유지할 책임을 진다.

 

보통 50% 정도를 엔지니어링에 투자하고 남은 50% 중에서 25% 정도를 비상 대기에 사용하고, 나머지 25%는 프로젝트 업무가 아닌 다른 운영 업무에 할애한다.

 

25%의 비상 대기 규칙 덕분에 최소한의 인력들로 24시간/7일 내내 대기하는 비상 대기조를 운영할 수 있다. 만일 서비스와 관련된 업무가 충분히 많아서 단일 사이트팀의 규모가 커지게 되면 다중 사이트팀을 구성하는 것을 선호한다. 다중 사이트팀은 다음의 두 가지 장점이 있다.

• 야간에 업무를 교대하는 것은 건강에 좋지 않은 영향을 미치므로, 다중 사이트팀의 '해 뜰 때' 교대하는 방식은 팀 전체가 야간 교대로부터 벗어날 수 있다.
• 비상 대기 업무에 참여하는 엔지니어의 수를 제한함으로써 엔지니어들이 프로덕션 시스템에 대한 관심을 지속할 수 있다.

하지만 다중 사이트팀은 의사소통과 협업에 더 많은 비용을 소모하는 단점이 있다. 상황에 따라서 자신에게 맞는 방법으로 팀을 구성하면 좋을 것 같다.

 

4. 안전에 대해 고려하기

장애 관리 도중에는 직감에 기반한 신속한 대응이 미덕이기는 하지만 분명 단점도 존재한다. 자신의 감이 틀릴 수 있을 뿐 아니라 명확한 데이터에 근거한 지원이 제대로 이루어지지 않을 수 있기 때문이다. 그래서 자신의 감을 믿는다는 것은 엔지니어가 문제 해결의 첫 단추를 잘못 채움으로써 시간을 낭비하게 되는 결과를 초래할 수 있다.

 

장애 관리에 있어 이상적인 방법은 자신의 추측을 심도 있게 확인하는 동시에 좀 더 합리적인 의사 결정을 위해 충분한 데이터를 활용할 수 있는 시점에 적절한 속도로 차근차근 각 단계를 밟아나가는 완벽한 균형이 필요하다.

 

비상 대기 중인 SRE에게 있어 중요한 것은 다양한 자원을 활용해 비상 대기 업무에 대한 부담을 줄일 수 있다는 점을 이해하는 것이다. 비상 대기에 활용할 수 있는 가장 중요한 자원들은 다음과 같다.

• 분명한 장애 전파 경로
• 잘 정의된 장애 관리 프로세스
• 비난 없는 포스트모텀 문화

 

장애를 전파하는 적절한 방법은 원칙적으로 정해진 방법을 따르는 것이다. 지금 제가 속한 팀에서도 장애가 발생하면 어떤 식으로 대처를 하면 되는지 정해진 규칙이 있다. 

 

장애가 발생하면, 언제 무엇이 잘못되었고 어떤 부분이 제대로 동작했는지를 판단해서 향후에 동일한 에러가 다시 반복되지 않도록 하는 것이 무엇보다 중요하다. SRE팀은 중대한 장애를 처리한 후에는 반드시 포스트모텀 문서에 사건이 발생한 이후의 모든 시간대별 행위를 상세히 기록해야 한다. 사람이 아닌 사건에 집중해서 작성된 포스트모텀 문서는 큰 가지츨 제공한다. 이 문서는 누군가를 비난하는 것이 아니라, 프로덕션 환경의 장애를 시스템적으로 분석함으로써 그 가치를 이끌어낸다. 실수는 일어나기 마련이다. 따라서 소프트웨어는 가능한 한 실수가 없도록 만들어져야 한다. 그리고 사람의 실수를 줄이는 최고의 방법 중 하나는 자동화할 수 있는 부분을 선별하는 것이다.

 

5. 부적절한 운영 부하에서 벗어나기

모니터링의 설정이 잘못된 경우 운영 부담이 증가할 수 있다. 호출 알림은 서비스의 SLO(Servie Level Objective)를 위협하는 증상이 발생하는 경우에만 보내져야 한다. 그리고 모든 호출 알림은 그에 대한 대응 조치가 가능한 것들이어야 한다. 알림이 너무 많으면 심각한 알림을 놓칠 수 있기 때문에 필요한 알림만 보내는 것은 정말로 중요하다고 생각한다.

 

SRE팀은 모든 엔지니어들이 최소 1~2분기 마다 비상 대기 업무에 투입될 수 있도록 조정해서 모든 팀 구성원들이 프로덕션 환경에 적당히 노출되도록 해야 한다. 이를 통해 서비스에 대한 문제 해결 능력과 지식을 갈고 닦을 수 있기 때문이다. 예전에는 내가 담당할 때 장애가 일어나지 않으면 좋겠다고 생각을 많이 했지만, 요즘은 어짜피 발생할 장애라면 내가 담당할 때 일어나면 좋겠다고 생각한다. 장애를 해결함으로써 문제 해결 능력이 증가하기 때문이다.

 

6. 결론

비상 대기 업무 담당자는 무슨 일을 하는지 알 수 있는 시간이었다. 현재 여러 프로덕션을 운영하고 있지만 모두 사내에 제공하는 플랫폼들이기 때문에 따로 비상 대기 업무를 하고 있지 않다. 하지만 평상시 업무 시간에 장애 대응을 하는 것과 비슷한 과정이 많았고 추후에 비상 대기 업무를 하게 된다면 어떠한 것에 초점을 두고 해야 하는 지 알 수 있는 유익한 시간이었다.