프레임 변경
이 모듈의 모든 단원 중에서 이 단원이 가장 중요한 단원 중 하나입니다. 이 단원에서는 무엇이 중요한 모니터링 대상이고 왜 중요한지에 관한 이해의 틀을 바꿀 수 있는 몇 가지 아이디어를 생각해 보겠습니다. 어떤 사람들에게는 이것이 안정성 향상을 위한 모니터링에 대한 사고 방식을 근본적으로 바꿀 수도 있습니다.
생각의 재구성 #1: 고객의 관점에서 본 안정성
앞에서 모니터링을 고려할 수 있는 안정성의 여러 측면에 대해 설명했지만 모니터링 가능한 항목 집합을 확장한 데 그친 것 같습니다. 안정성 개선을 위해 모니터링해야 할 것에 집중하는 데 도움이 되는 한 가지 아이디어는 다음과 같습니다.
안정성은 구성 요소 관점이 아니라 고객 관점에서 측정해야 합니다.
이것은 정말 중요합니다. 다시 읽어 보는 것이 좋을 정도로 매우 중요합니다. 과거에는 "모든 것을 모니터링해야 한다"는 의견이 우세했습니다. 카운터를 읽거나 통계를 그래프로 만들거나 대시보드에 배치할 수 있는 것은 모니터링해야 한다고 생각했습니다. "고객의 관점에서 측정하라"가 훨씬 더 정확한 격언입니다.
핵심을 보여 주고 이해할 수 있는 간단한 시나리오를 살펴보겠습니다.
시나리오
회사의 전자 상거래 웹 사이트 운영을 책임지고 있다고 가정합니다. 웹 팜에는 100개의 서버 인스턴스가 있습니다. 운영 체제 오류, 소프트웨어 업데이트, 전원 변동 또는 기타 예기치 않은 이벤트로 인해 이 100개의 인스턴스 중 14개가 갑자기 작동을 중지합니다. 이 14개 인스턴스는 이제 완전히 쓸 수 없게 되었습니다.
검토할 사항: 86개의 서버 인스턴스는 작동하고 14개의 서버 인스턴스는 작동하지 않습니다.
다음 중 이 상황에서 올바른 설명은 무엇인가요?
A: 별일 아닙니다. 시간이 나면 언젠가 문제를 처리할 수 있습니다.
B: 심각한 문제입니다. 진행 중 작업을 모두 중지하고 가능한 한 빨리 14개의 서버 인스턴스를 복구해야 합니다.
C: 회사의 존폐가 걸린 위기입니다. 최고위 임원에게 알리고 한밤중에 자고 있는 사람을 깨워서라도 최대한 빨리 상황을 처리해야 합니다.
답하기 전에 이 시나리오를 충분히 생각해 본 다음 더 읽어 보세요. A, B, C 중 어느 것이라고 생각하나요?
정답은 A, B, C 어느 것도 아니고 “상황에 따라 다르다”입니다. 좀 더 정확하게 말하자면 "고객이 이 중단을 어떻게 경험하는지에 따라 다르다"입니다.
백 엔드가 다운된 것을 고객이 알아차리지 못하고 다른 86개의 서버 인스턴스가 부하를 분담하도록 사이트를 설계했다면 위기는 없습니다. SEV-3 또는 SEV-4 인시던트이거나 지원 티켓에 불과할 수도 있습니다.
가동 중단으로 인해 전체 비즈니스가 실패하고 서버 다운 기간 동안 상당한 비용 손해가 발생한다면 비상 버튼을 누르고 모두를 호출할 충분한 이유가 될 수 있습니다. 답변이 "B"가 되는 중간 지점이 있을 수도 있습니다.
다시 말하지만 안정성은 구성 요소 관점이 아니라 고객 관점에서 측정해야 합니다. "100대의 서버 중 다운된 14대”라는 구성 요소 개수는 전적으로 정확하지만 이 시나리오에서는 안정성 관점에서 가장 중요한 정보는 아닙니다.
이 점은 보다 일반적인 구성 요소 기반 모니터링에 대해 이야기할 때도 유효합니다. 데이터베이스 서버가 50%의 CPU 부하로 작동하고 있다면 좋은 것일까요, 나쁜 것일까요? 90%로 올라가면 더 좋은가요, 나쁜가요? 서비스가 정상적으로 실행되고 사용자가 만족한다면 리소스 사용률을 상당히 개선했다는 뜻이므로 90%정도 좋은 것이라고 할 수 있습니다. 하지만 50%의 CPU 부하에서 애플리케이션 실행 속도가 느리다고 사용자들이 불만을 제기했다면 90%는 개선이 아닐 수 있습니다.
생각의 재구성 #2: 적절한 수준의 안정성
이 아이디어를 올바로 정립하려면 그 기원을 간단히 살펴봐야 합니다. 이 아이디어는 SRE(사이트 안정성 엔지니어링)에서 나왔습니다. SRE의 정의를 면밀하게 검토하기만 해도 이 섹션에 필요한 아이디어를 포함한 몇 가지 유용한 아이디어를 추출할 수 있습니다.
참고 항목
사이트 안정성 엔지니어링은 조직이 시스템, 서비스, 제품에서 적절한 수준의 안정성을 지속적으로 달성하도록 지원하는 엔지니어링 원칙입니다.
이 정의에는 다음과 같은 세 가지 중요한 단어가 있습니다.
안정성: 안정성의 중요성은 소개 단원에서 충분히 설명했으므로 추가로 언급하지 않겠습니다.
지속적: 이 맥락에서 “지속성”이란 관련된 모든 상황에서 사람들의 역할을 나타냅니다. 지속 가능한 운영 방식을 만드는 것이 중요합니다. 신뢰할 수 있는 시스템, 서비스, 제품은 사람이 만듭니다. 매일 새벽 3시에 호출해 직원들을 깨우거나 가족과 함께 보낼 시간을 주지 않거나 자신을 돌보는 데 시간을 쓸 기회를 주지 않는 등 업무를 지속 가능하게 만들기 위한 노력을 하지 않는다면 신뢰할 수 있는 시스템을 구축할 방법은 없습니다. SRE에 따르면 시간이 지나도 지속 가능한 운영 방식을 구현하여 사람들이 업무에 최선을 다할 수 있도록 하는 것이 중요합니다.
적절성: 일부 사람들에게는 혁신적인 단어일 수 있습니다. 과거에는 모든 것을 연중무휴 24시간 가동하는 것이 운영의 목표였습니다. 모든 것을 24시간 연중무휴로 가동하려고 노력했습니다. 어떤 것이든 다운되는 것을 절대 용납할 수 없었습니다. 사이트 안정성 엔지니어링이 운영 논의에 도입한 것 중 하나는 적절한 수준의 안정성을 위해 노력해야 한다는 생각이었습니다.
이 아이디어를 살펴보겠습니다. 여기서 중요한 점은 100% 안정성이 바람직한 목표인 경우는 거의 없다는 것입니다. 의료 기기나 항공 등 일부 예외를 제외하면 100% 안정성은 필요하지 않으며, 실제로 100% 안정성은 불가능한 경우가 많습니다.
“전혀 가능하지 않음”의 예는 다음과 같습니다. 요즘에는 다들 다른 시스템에 종속된 시스템을 실행합니다. 결제 프로세서나 인증 시스템을 호출해야 하는 소프트웨어를 실행 중일 수 있습니다. 결제 프로세서나 인증 시스템을 100% 신뢰할 수 없다면 우리 시스템도 100% 신뢰하기가 매우 어려울 수 있습니다.
100% 안정성 목표의 곤란한 점은 이 말이 즉 0의 가동 중지 시간을 뜻한다는 것입니다. 또한 가동 중지 시간이 생길지도 모르는 변경은 전혀 할 수 없다는 뜻이기도 합니다. 어쩌면 원할 수도 있고 필요할 수도 있는 여유 공간을 전혀 가질 수 없다는 것입니다.
운영하려는 특정 요소의 "적절한 수준의 안정성이란 무엇인가?"를 생각하기 시작하면 도움이 됩니다. 이를 지금 주제에 연결하려면 모니터링이 이 목표를 지원해야 합니다.
이 두 가지 프레임을 염두에 두고 현실을 감안하여 목표 달성에 도움이 되는 몇 가지 도구를 살펴보겠습니다.