내 서버가 내려갔고 5시간 후에 우연히 알게 됨

알림은 모니터링 서비스에서 오지 않았습니다. 자동화된 경고나 Slack으로 들어오는 webhook에서 오지 않았습니다. 가장 원시적인 모니터링 시스템에서 나왔습니다: 브라우저를 열고, URL을 입력하고, 빈 페이지를 바라보는 것. 그것은 화요일 오후였습니다. 사이트는 아침 9시경부터 내려가 있었고, 이제 오후 2시를 훨씬 넘었습니다. 하루에 수천 개의 요청을 처리하는 웹 애플리케이션으로부터 5시간의 완전한 침묵. 그 5시간 동안 모든 방문자는 오류 페이지를 보았고, 모든 API 호출은 아무것도 반환하지 않았으며, 모든 예약된 작업은 백그라운드에서 조용히 실패했습니다. 서버는 극적으로 충돌하지 않았습니다. 커널 패닉도, 디스크 오류도, 포렌식 증거를 남긴 공격도 없었습니다. Contabo VPS는 단순히 HTTP 요청에 응답을 중단했고, 유효한 IP 주소와 네트워크 계층의 하트비트를 가지고 앉아 있었지만 어떤 웹 트래픽도 제공하기를 거부했습니다.

발견은 완전히 관련 없는 작업 때문에 일어났습니다. 디자인 변경을 위해 특정 페이지 레이아웃을 확인해야 할 필요가 있었기 때문에, 브라우저가 URL로 이동했고 아무것도 반환하지 않았습니다. 첫 번째 본능은 로컬 네트워크를 탓하는 것이었습니다. 페이지를 새로고침했습니다. 여전히 아무것도 없습니다. 다른 브라우저를 시도했습니다. 여전히 아무것도 없습니다. 터미널을 열고 서버를 핑했습니다. 패킷이 정상적으로 반환되었습니다. SSH 연결? 정상 작동. Apache 상태? 죽어 있습니다. 웹 서버 프로세스는 이른 아침 시간 어딘가에 충돌했고 다시 시작되지 않았습니다. 왜냐하면 정확한 오류 모드를 처리하도록 구성된 프로세스 감독자가 없었기 때문입니다. 수정은 30초가 걸렸습니다. 이것이 다시 발생할 수 있고 아마도 아무도 알아채지 못한 채 이전에 발생했을 수 있다는 깨달음은 받아들이는 데 상당히 더 오래 걸렸습니다.

VPS에서 프로덕션 서비스를 실행해 본 모든 개발자는 이 이야기의 버전을 가지고 있습니다. 아마도 5시간이 아닐 것입니다. 아마도 2, 8, 또는 전체 주말이었을 것입니다. 세부 사항은 다르지만 패턴은 동일합니다. 서버가 내려갔고, 아무도 알아채지 못했으며, 발견은 우연이었습니다. 근본적인 문제는 서버 신뢰성이 아닙니다. 서버는 실패하고, 프로세스는 충돌하고, 디스크는 가득 찬고, 메모리 누수가 축적됩니다. 그것이 물리적 하드웨어에서 소프트웨어를 실행하는 것의 본질입니다. 근본적인 문제는 모니터링의 부재이고, 더 구체적으로는 서버가 온라인 상태인지 알고 있는 것과 애플리케이션이 실제로 작동하고 있는지 아는 것 사이의 간격입니다.

가동 시간 모니터링과 실제로 사이트가 작동하고 있다는 것을 아는 것의 차이

전통적인 가동 시간 모니터는 한 가지를 잘합니다. 정기적인 간격으로 URL에 HTTP 요청을 보내고 응답 코드가 200인지 확인합니다. 코드가 다른 것이거나 요청이 시간 초과되면 경고가 발생합니다. 이는 가장 치명적인 실패를 포착합니다: 서버에 완전히 접근할 수 없고, 도메인이 만료되었으며, SSL 인증서가 유효하지 않습니다. 하지만 논증상 더 일반적이고 더 손상적인 문제의 엄대한 범주를 놓칩니다.

서버가 200 상태 코드를 반환하지만 페이지가 손상된 시나리오를 고려하세요. 데이터베이스 연결이 실패했으므로 콘텐츠 영역에는 예상되는 제품 목록 대신 오류 메시지가 표시됩니다. CSS 파일이 로드되지 않아서 페이지가 스타일이 지정되지 않은 HTML로 렌더링됩니다. JavaScript 오류로 인해 메인 애플리케이션이 초기화되지 않아 사용자는 절대 해결되지 않는 로딩 스피너를 바라봅니다. 타사 위젯이 전체 페이지 콘텐츠를 덮는 오버레이를 주입합니다. 이 모든 경우에 가동 시간 모니터는 200 응답을 받았기 때문에 모든 것을 정상으로 보고합니다. 서버가 작동합니다. 사이트가 손상되었습니다. 아무도 모릅니다.

"서버가 응답한다"와 "사이트가 작동한다"는 이 간격이 스크린샷 모니터링이 필수적인 곳입니다. 예약된 스크린샷은 정기적인 간격으로 페이지가 실제로 어떻게 보이는지를 캡처합니다. 페이지가 갑자기 오류 메시지, 손상된 레이아웃, 또는 빈 흰색 화면을 표시하면, 스크린샷이 그것을 즉시 보이게 합니다. 예약된 스크린샷을 픽셀 diff 비교와 결합하면, 시스템은 페이지가 예상치 못한 방식으로 변경되었는지 자동으로 감지할 수 있습니다. 콘텐츠 업데이트로 인해 몇 픽셀이 이동하는 것은 정상입니다. 전체 페이지가 흰색으로 바뀌거나 오류 스택 추적을 표시하는 것은 그렇지 않으며, diff 알고리즘은 설정 가능한 민감도 임계값으로 두 가지를 구분할 수 있습니다.

5시간 장애 후, 가장 먼저 설정된 것은 모든 중요한 서비스에 대한 가동 시간 모니터였습니다. 하지만 더 흥미로운 추가는 15분마다 핵심 페이지의 실제 시각적 상태를 캡처하는 예약된 스크린샷 모니터링이었습니다. 가동 시간 모니터는 명백한 충돌을 포착합니다. 스크린샷 모니터는 다른 모든 것을 포착합니다: 200 상태 코드를 반환하면서 손상된 페이지를 표시하는 미묘한 실패, 예상치 못한 콘텐츠를 주입하는 타사 스크립트, 특정 조건에서만 표시되는 데이터베이스 오류.

처음부터 존재했어야 하는 경고 파이프라인 구축

적절한 모니터링 시스템의 아키텍처는 이론상으로는 복잡하지 않습니다. 스케줄러는 정의된 간격으로 검사를 트리거합니다. 검사는 목표의 현재 상태를 캡처합니다. 상태는 예상 기준선과 비교됩니다. 비교가 임계값을 초과하면 경고가 발생합니다. 도전은 아키텍처에 있지 않지만 각 구성 요소의 신뢰성에 있습니다. 자체가 내려가는 모니터링 시스템은 모니터링 시스템이 없는 것보다 나쁩니다. 왜냐하면 거짓된 보안감을 만들기 때문입니다.

스크린샷 모니터링 파이프라인은 단계별로 작동합니다. 스케줄러는 설정된 간격(페이지의 중요도에 따라 일반적으로 5, 10, 또는 15분)으로 캡처 작업을 발송합니다. 캡처 작업은 페이지를 로드하고, 렌더링이 완료될 때까지 기다리고, 결과 스크린샷을 저장하는 헤드리스 Chromium 인스턴스를 실행합니다. 새 스크린샷은 변경된 영역을 식별하고 변경의 총 백분율을 계산하는 픽셀 diff 알고리즘을 사용하여 이전 캡처와 비교됩니다. 변경이 설정된 임계값을 초과하면, 알림이 설정된 채널을 통해 발송됩니다: 이메일, webhook, Slack, 또는 모든 커스텀 엔드포인트.

Diff 비교는 기술적 관점에서 정말 흥미로운 곳입니다. 소박한 픽셀 비교는 타임스탬프, 광고, 또는 애니메이션 요소와 같은 동적 콘텐츠 때문에 모든 스크린샷을 변경된 것으로 표시했을 것입니다. Diff 엔진은 비교 전에 마스크 처리되는 직사각형 영역인 배제 영역을 지원하여 이를 설명합니다. 헤더의 타임스탬프, 회전하는 배너 광고, 모서리의 라이브 채팅 위젯: 이것들은 모두 제외될 수 있으므로 의미 있는 변경만 경고를 트리거합니다. 배제 후 남은 것은 안정적인 콘텐츠 영역이며, 그곳의 모든 변경은 거의 확실히 조사할 가치가 있습니다.

5시간 장애는 이 시스템 하에서 몇 분 내에 포착되었을 것입니다. 서버가 내려간 후 첫 번째 예약된 스크린샷은 빈 이미지 또는 오류 페이지를 반환했을 것이고, 둘 다 기준선과 극적으로 달랐을 것입니다. Diff 백분율은 100%에 가까웠을 것이고, 합리적인 임계값을 훨씬 초과했으며, 경고가 즉시 발생했을 것입니다. 5시간의 다운타임은 5분이 되었을 것이고, 그 5분은 모니터링 간격 자체였고, 사람이 우연히 문제를 우연히 발견하는 데 걸린 시간이 아닐 것입니다.

보이지 않는 5시간의 다운타임이 실제로 드는 비용

5시간 다운타임의 즉각적인 비용은 숫자를 사용할 수 있을 때 계산하기 쉽습니다. 하루에 수천 개의 요청을 처리하는 사이트의 경우, 5시간은 일일 트래픽의 상당한 부분을 나타냅니다. 오류를 반환한 모든 요청은 원하는 것을 얻지 못한 사용자였습니다. 그 중 일부는 다시 돌아올 수 없을 새로운 방문자였습니다. 일부는 약간의 신뢰를 잃을 기존 사용자였습니다. 일부는 종속성 때문에 자신의 애플리케이션이 실패한 API 소비자였습니다. 직접적인 수익 영향은 사이트의 성격에 따라 다르지만, 사소한 SaaS 애플리케이션의 경우에도 영업 시간 동안 5시간의 다운타임은 손실된 전환에서 수백 달러를 쉽게 나타낼 수 있습니다.

숨겨진 비용은 정량화하기가 더 어렵지만 논증상 더 큽니다. 그 5시간 동안 사이트를 크롤링한 검색 엔진은 오류 응답을 받았으며, 짧은 장애는 일반적으로 Google의 크롤링 인프라에 의해 허용되지만, 연장된 다운타임은 영향을 받은 페이지의 임시 색인 제거 결과를 야기할 수 있습니다. 장애 중에 실행 중이던 이메일 캠페인은 죽은 엔드포인트로 트래픽을 유도했으므로 전체 캠페인 지출이 낭비되었습니다. 웹 애플리케이션에 종속된 예약된 작업(webhook 배달, 보고서 생성, 배치 처리와 같은 것)이 모두 조용히 실패했으며 서버가 복원된 후 수동으로 식별하고 다시 실행해야 했습니다.

가장 음습한 비용은 평판이 있는 것입니다. 다운 사이트를 만난 사용자는 일반적으로 "귀 사이트가 다운 상태"라고 말하는 이메일을 보내지 않습니다. 그들은 단순히 떠나고 다시 올 수도 있고 안 할 수도 있습니다. 다운타임에 대한 피드백 메커니즘은 피드백 메커니즘 자체가 다운 상태이기 때문에 일반적으로 없습니다. 5시간의 창은 일부 사용자가 사이트를 시도했고, 손상된 것을 발견했으며, 발생한 일을 나타낼 단일 데이터 포인트를 생성하지 않고 경쟁자로 이동했을 가능성이 충분할 정도로 길었습니다. 그들은 단순히 사라졌고, 몇 명이거나 누가 인지 알 방법이 없습니다.

반응형에서 예방적으로 변경 및 우연히 알게 되지 않기

그 화요일 오후의 교훈은 서버가 충돌한다는 것이 아닙니다. 그것은 이미 알려져 있었습니다. 교훈은 실패와 발견 사이의 모든 분이 누적된 피해의 분이며, 그 창을 최소화할 유일한 방법은 감지를 자동화하는 것입니다. 인간의 모니터링은 확장되지 않습니다. 사이트를 하루에 한 번 수동으로 확인하면 장애에 대한 평균 감지 시간은 12시간입니다. 시간에 한 번 확인하면 30분으로 단축되지만, 인간이 모든 애플리케이션의 모든 페이지를 1시간에 한 번 연중무휴로 현실적으로 확인할 수는 없습니다.

가동 시간 모니터링과 시각적 스크린샷 모니터링의 조합은 문제의 두 계층을 모두 다룹니다. 가동 시간 모니터는 서버가 완전히 오프라인으로 되는 것을 포착합니다. 스크린샷 모니터는 서버가 작동하는 동안 애플리케이션이 손상되는 것을 포착합니다. 함께, 그들은 감지 창을 "누군가 알아채기로 결정할 때마다"에서 모니터링 간격 자체로 줄이며, 이는 중요한 서비스의 경우 1분만큼 짧을 수 있습니다. 경고가 발생하고, 알림이 도착하며, 수정이 몇 시간이 아닌 몇 분 내에 시작됩니다.

서버는 그 원래 사건 이후로 두 번 더 내려갔습니다. 두 경우 모두, 경고는 3분 내에 도착했습니다. 두 경우 모두, 수정은 상당한 트래픽이 손실되기 전에 적용되었습니다. 모니터링 인프라는 그것이 포착한 첫 번째 사건으로 스스로 비용을 지불했으며, 그 후 모든 것은 순수한 이점이 되었습니다. 우연히 장애를 알게 되는 시대는 끝났으며, 뒤를 보면, 유일한 실제 질문은 5시간의 장애가 투자를 명백하게 만드는 데 왜 걸렸는지입니다.