SRE 11장 - 비상대기

비상 대기는 많은 운영팀 및 엔지니어링팀이 서비스의 신뢰성과 가용성을 위해 반드시 수행해야 할 중요한 임무다. 그러나 교대로 수행하는 과정 속에는 많은 어려움이 도사리고 있다.

---

소개

  구글의 여러 주요 서비스팀, 예를 들면 검색, 광고 및 지메일 등은 이 서비스들의 성능과 신뢰성을 책임지는 전담 SRE팀이 있다. 그래서 SRE들이 서비스를 위한 비상 대기 업무를 수행한다. SRE팀은 순수한 운영팀과는 사뭇 달라서 문제를 해결하기 위한 엔지니어링적 접근법을 강조한다. (가장 큰 차이점이다. 항상 엔지니어링을 생각하자)

이 문제들은 대부분 운영과 관련된 것들이지만 스케일링과 관련해서 소프트웨어 엔지니어링 솔루션 없이는 다루기 어려운 것들이다.

 

  이런 종류들의 문제를 해결하기 위해 구글은 시스템과 소프트웨어 엔지니어링에 있어 각기 다른 배경지식을 가진 사람들을 SRE팀에 충원한다.(시스템과, 소프트웨어 엔지니어링이 둘 다 필요한 이유는, 앞선 1~2장에서 다뤘듯이 구글은 생각보다 더 많은 것들을 엔지니어링으로 풀고 있기 때문이라고 생각한다)

  또한 SRE가 순수한 운영 업무에 할애할 수 있는 시간을 최대 50%로 제한하고 있어 최소한 나머지는 서비스 개선과 자동화를 통한 업무 수행 개선 프로젝트에 할애하도록 하고 있다.

 

비상 대기 엔지니어의 삶

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

비상 대기 시에 엔지니어는 수 분 이내에 프로덕션 환경에서 필요한 운영 작업을 수행할 수 있어야 한다. 이 시간은 사전에 약속된 장애 시 대응 시간으로 사용자에게 노출되거나 혹은 시간이 매우 중요한 서비스의 경우에는 5분 정도이며, 그 외에는 30분 정도다. ( 라이브 서비스는 5분이겠군.. )

일반적으로 휴대전화를 통해 알림을 수신한다. 구글은 다양한 메커니즘(이메일, SMS, 자동 전화, 모바일 앱 등)으로 알림을 받을 수 있다. 

 

  장애에 대한 대응 시간은 서비스의 가용성에 따라 다르지만 규칙은 매우 간단하다. 사용자에게 노출되는 서비스의 경우에는 분기별로 99.99%의 가용성을 반드시 확보해야 한다. 그래서 분기별로 허용되는 다운타임은 약 13분 정도이다. 즉 대응 시간이 대략 분 단위로 이루어져야 한다는 것을 의미한다. 

 

  일단 장애 알림을 받게 되면 비상 대기 엔지니어는 문제의 수위를 판단하고 해결해야 한다. 

우선 순위가 낮은 일림이나 소프트웨어 릴리즈 같이 장애 알림이 발송되지 않는 프로덕션 이벤트의 경우에는 비상 대기 엔지니어가 업무 시간에 처리하는 것도 무방하다. 그럼에도 불구하고, 비교적 급하지 않은 업무들일지라도 장애 알림이 발송되는 이벤트들은 "프로젝트 업무를 포함한 다른 모든 업무들보다 높은 우선순위를 갖는다."(그만큼 장애 알림은, 함부로 설정하지 말아야 한다. 라는 뜻으로 이해했다.)

 

  주 비상 대기조와 보조 대기조를 동시에 운영할 때, 어느 정도의 업무를 할당할 것인가는 각 팀이 알아서 결정한다. 보통은 서로 관련 있는 두 팀이 서로의 보조 대기조 역할을 하는 것이 일반적이다. 이렇게하면 운영의 부담이 줄어든다.

 

 

---

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

  SRE팀에는 비상 대기 업무에 편셩될 경우의 업무의 양과 품질에 대한 상세한 제약이 있다. 그 양은 엔지니어가 비상 대기 업무에 할애한 시간의 백분율로 계산한다. 그리고 비상 대기 품질은 비상 대기 업무 기간 동안 발생한 장애의 수로 계산될 수 있다.

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

 

업무 양의 균형

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

 

25%의 비상 대기 규칙 덕분에 최소한의 SRE 인력들로 24/7 대기 비상 대기조를 운영할 수 있다. 

항상 두 사람(주,보조)이 한 조를 이룬다고 가정하면 단일 사이트(single-site) 팀에서 비상 대기 업무를 수행하기 위해 필요한 최소 엔지니어의 수는 8명이다. 비상 대기 업무를 일주일 단위로 교대로 수행한다면 각 엔지니어는 한 달에 한 주 동안 비상 대기 업무에 투입된다.

이중 사이트 팀의 경우라면 각 팀이 25%의 규칙을 지키면서 충분한 수의 엔지니어들을 유지하려면 최소 6명 이상이 있어야 한다.( 이중 사이트 팀이란? - 아래 )

 

 

서비스와 관련된 업무가 충분히 많아서 단일 사이트팀의 규모가 커지게 되면 다중 사이트 팀을 구성하는 것을 선호한다. 장점은 아래와 같다.

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

( 결국 부담을 줄이는 것이 중요하다고 보인다. )

 

하지만 다중 사이트 팀은 의사소통과 협업에 더 많은 비용을 소모하는 단점이 있다. 다각적으로 검토해야 한다.

 

 

품질의 균형

  비상 대기 업무에 투입되면 종류에 관계없이 발생한 장애를 처리하고 포스트모텀을 쓰는 등의 사후 활동을 수행하기 위한 충분한 시간을 확보해야 한다. 이 시간은 평균 6시간이 소요된다는 점을 발견했다. 비상 대기 업무의 교대는 매 12시간마다 이 루어지므로 하루에 처리할 수 있는 최대 장애는 2개라는 결론이 나온다. 

 

보상

근무 외 시간을 지원하기 위해서는 적절한 보상에 대해 고민해야 한다. 구글의 경우는 일정 비율의 현금 보상을 제공한다. 보상의 상한을 통해 특정 개인이 비상 대기 업무에 투입되는 시간을 제어할 수 있다. 보상 정책을 채택하면 동기 부여, 등의 잠재적 부작용으로부터 벗어날 수 있다.

 

---

안전에 대해 고려하기

SRE 비상 대기 업무를 수행한다는 것은 관리 책임을 진다는 것을 의미한다. 

 

최근 연구결과에 따르면 사람은 자신이 직면한 도전에 대해 크게 두 가지 방향으로 생각하는 것으로 밝혀졌다.

• 직관적, 자동화적, 그리고 신속한 대응
• 합리적, 집중적, 그리고 계획적이며 경험에 기반한 행위

복잡한 시스템의 장애를 처리할 때는 두 번째 방식이 더 나은 결과를 도출해내며 계획에 따른 장애 조치가 가능하다. 

엔지이너들이 후자의 마음가짐을 가지고 적절하게 자신을 제어할 수 있도록 하기 위해서는 비상 대기와 관련된 스트레스를 줄여주는 것이 중요하다.

 

장애 관리 도중에는 직감에 기반한 신속한 대응이 미덕이기는 하지만 단점도 존재한다. 감이 틀릴 수도 있고, 명확한 데이터에 근거한 지원이 제대로 이루어지지 않을 수 있기 때문이다.

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

 

다양한 자원을 활용해 비상 대기 업무에 대한 부담을 줄일 수 있다. 

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

실수는 일어나게 마련이다. 따라서 소프트웨어는 가능한 한 실수가 없도록 만들어져야 한다. 그리고 사람의 실수를 줄이도록 자동화를 해야 한다.

 

---

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

운영 부하

이상적으로는 운영 업무 부담의 증가에 대한 증상을 측정할 수 있어서 목표치가 정량화될 수 있어야 한다(티켓 개수, 알림 몇회 미만 등).

 

알림이 너무 많으면 이를 간과하고 정말 심각한 알림을 놓칠 수도 있다. 또한 시스템이 하나의 장애에 대해 하나의 알림을 발신해야 한다. 

애플리케이션 개발자의 작업 과정에서 시스템의 신뢰성에 문제가 생기거나 혹은 알림 발신이 잦아지는 등의 운영 부담을 가중시키는 변화가 생기기도 한다. 이는 SRE팀의 관할 밖에 있다. 이런 경우에는 협업을 통해 공통의 목표를 설정하면 된다.

 

 

뜻밖의 적: 운영 업무의 부족

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

 

모든 팀 구성원들이 프로덕션 환경에 적당히 노출되도록 해야 한다. 

 

---

결론

이 방식이 IT서비스에 비상 대기가 필요한 모든 엔지니어들 모두에게 곧바로 적용할 수 있는 방법은 아닐 수 있지만, 비상 대기 업무가 늘어나는 조직이 쉽게 도입할 수 있는 견고한 모델이라는 점을 믿어 의심치 않는다.