Contabo가 경고 없이 내 서버를 종료했고 5시간 후에 우연히 알았다

서버는 몇 개월 동안 문제 없이 실행되고 있었습니다. 저렴한 VPS 계획으로 알려진 독일 호스팅 회사인 Contabo는 웹 애플리케이션부터 예약된 작업, 데이터베이스 작업까지 모든 것을 처리하고 있었습니다. 트래픽 급증, 하드웨어 성능 저하의 징후, 아무도의 경고 이메일이 없었습니다. 서버는 단순히 거기에 있었고 서버가 하는 일을 하고 있었습니다. 오전 중반 즈음 기계가 다운되었습니다. 알림이 오지 않았습니다. 사건 보고서가 발표되지 않았습니다. 자동화된 시스템이 문제를 표시하지 않았습니다. 그 서버에 의존하는 애플리케이션은 조용히 실패하기를 계속했으며 방문한 사람에게 연결 오류를 반환했습니다. 그동안 아무도 무언가 잘못되었다는 것을 알지 못했습니다.

문제가 발견되기까지 5시간이 지났고 발견 자체는 완전히 우연이었습니다. 무관한 유지보수 작업을 위해 서버에 SSH를 시도했는데 연결 시간 초과가 반환되었습니다. 그것이 현실이 깨달아지는 순간이었습니다. 5시간의 다운타임입니다. 그 기계에서 호스팅되는 모든 웹 속성에 액세스할 수 없었습니다. 모든 API 끝점이 오류를 반환했습니다. 모든 예약된 작업이 실패했습니다. 누구도 알지 못했습니다. 아무도 경보를 울릴 수 있는 것이 없었기 때문입니다. 호스팅 공급자가 최소한 잘못된 일이 발생하면 이메일을 보내거나 웹사이트가 오프라인이면 누군가 알아챌 것이라고 가정했습니다. 두 가정 모두 위험할 정도로 잘못되었습니다.

그 후는 길고 긴 피해 평가였습니다. 정확히 언제 중단이 시작되었는지 확인하기 위해 로그를 확인합니다. 영향을 받은 서비스를 검토합니다. 5시간 동안 실패한 API 요청이 몇 개인지 계산합니다. Contabo 지원팀에 연락하여 서버가 자신들이 "정기적인 유지보수 이벤트"라고 설명했으며 고객에게 미리 통지할 필요가 없었던 이유를 알아냅니다. 실망은 단순히 다운타임 자체에 관한 것이 아닙니다. 다운타임은 발생합니다. 하드웨어가 실패합니다. 네트워크의 문제가 발생합니다. 실망은 정보의 총 부재, 서버가 오프라인 상태가 된 순간부터 문제가 우연히 발견될 때까지의 완전한 침묵에 관한 것이었습니다.

패시브 모니터링이 가장 필요할 때 실패하는 이유

그 사건 이전에는 모니터링 전략을 관대하게 패시브로 설명하고 현실적으로는 존재하지 않는 것으로 설명할 수 있었습니다. 접근 방식은 간단했습니다. 무언가가 깨지면 누군가 알아챌 것입니다. 사용자가 불평할 것입니다. 제3자 분석 도구의 오류율이 급증할 것입니다. 호스팅 공급자가 통신할 것입니다. 확실히 현대의 클라우드 인프라와 자동화된 시스템의 시대에 서버가 완전히 오프라인 상태가 되면 어떤 종류의 관찰 가능한 반응을 트리거할 것입니다. 하지만 이 중 어느 것도 유용한 시간 내에 일어나지 않았습니다. 오류가 발생한 사용자는 단순히 떠났습니다. 분석 플랫폼은 측정할 수 있는 것만 보고합니다. 서버가 데이터를 제공하고 오프라인 상태가 되면 측정할 것이 없습니다. 호스팅 공급자는 알려지지 않은 종료를 이메일할 가치가 있다고 생각하지 않았습니다.

이것은 놀랍도록 많은 중소 규모 작업을 포착하는 함정입니다. 엔터프라이즈 회사는 24시간 내내 대시보드를 감시하는 팀 전체가 있는 전용 모니터링 스택을 실행합니다. 개인 개발자와 소규모 기업은 호스팅이 충분히 안정적이고 치명적인 실패가 드물며 모니터링 설정의 수동 오버헤드가 "아마도 일어나지 않을" 일의 수고할 가치가 없다는 가정에 따라 작동합니다. 그 논리의 문제는 다운타임의 비용이 감지되지 않은 기간에 비례하고 얼마나 자주 발생하는지에 비례하지 않다는 것입니다. 즉시 발견되는 5분의 중단은 사소한 사건입니다. 아무도 우연히 발견될 때까지 알아채지 못하는 5시간의 중단은 진정한 비즈니스 문제입니다.

이 사건은 또한 호스팅 공급자를 서버 상태에 대한 유일한 진실의 원천으로 신뢰하는 것이 더 미묘한 문제임을 드러냈습니다. 대부분의 예산 호스팅 회사처럼 Contabo는 제어판을 통해 기본 서버 상태 정보를 제공합니다. 하지만 제어판을 방문하려면 이미 무언가 잘못되었다고 의심해야 합니다. 푸시 메커니즘, 적극적인 경고, "서버가 오프라인 상태이고, 여기서 무엇이 발생했는지"라고 말하고 나에게 연락하는 시스템이 없습니다. 관계는 전적으로 반응적입니다. 고객은 답변을 받기 전에 질문을 해야 합니다. 다운타임의 모든 초가 놓친 수익, 손실된 신뢰 및 손상된 검색 엔진 순위로 변환되는 세계에서 그 반응적 모델은 근본적으로 부적절합니다.

5시간의 침묵이 실제로 비용이 드는 것

감지되지 않은 중단으로 인한 피해를 수량화하는 것은 단순히 분 단위로 계산하는 것보다 더 복잡합니다. 즉각적인 비용은 충분히 간단합니다. 손실된 API 수익, 실패한 웹훅 배달, 가동 시간에 의존하는 사용자의 끊어진 통합. 하지만 2차 비용은 대시보드에 나타나지 않는 방식으로 누적됩니다. 중단 중에 도착하고 오류 응답을 받는 검색 엔진 크롤러는 복구하는 데 몇 주가 걸릴 수 있는 순위 페널티를 트리거할 수 있습니다. 죽은 사이트를 마주친 사용자는 다시 돌아올 수 없으며 5시간 동안 몇 명의 잠재 고객이 방문했으며 오류 페이지를 받고 영구적인 부정적인 인상을 형성했는지 알 수 있는 방법이 없습니다.

SSL 인증서 만료는 문제를 악화시키는 또 다른 조용한 위협입니다. 경고 없이 만료되는 인증서는 단순히 보안 취약성을 만들지 않습니다. 방문자의 진행을 적극적으로 방해하는 브라우저 경고를 트리거합니다. 검색 엔진은 만료된 인증서를 순위 신호로 취급합니다. 그리고 서버가 다시 온라인 상태가 되면 적어도 해결되는 서버 중단과 달리 만료된 인증서는 누군가 수동으로 갱신할 때까지 계속해서 손상을 일으킵니다. 모니터링되지 않은 서버 상태와 모니터링되지 않은 인증서 유효성의 조합은 여러 실패 모드가 서로 쌓일 수 있는 상황을 만들어 각각의 복구를 더 어렵게 만듭니다.

응답 시간 저하는 패시브 모니터링이 완전히 놓치는 또 다른 측면입니다. 서버는 항상 한 순간에 작동에서 죽음으로 바뀌지는 않습니다. 더 자주, 성능이 점진적으로 저하됩니다. 200밀리초였던 응답 시간이 800, 1500, 3000으로 올라가기 시작합니다. 서버가 실제로 충돌할 때까지 사용자 경험은 몇 시간 또는 며칠 동안 악화되었습니다. 응답 시간을 추적하고 임계값을 초과할 때 경고하는 활성 모니터링 없이는 이러한 점진적 저하는 최종 재앙적 실패까지 완전히 주목받지 않습니다. 그리고 그 시점까지 사용자 경험과 검색 순위에 대한 손상은 이미 완료되었습니다.

존재했어야 했던 모니터 구축

uptime.yeb.to를 구축하기로 한 결정은 나쁜 하루에 대한 자발적인 반응이 아니었습니다. 이는 오랫동안 쌓여오던 문제의 논리적 결론이었고 마침내 무시할 수 없게 되었습니다. 요구 사항은 실제 경험에서 직접 나왔기 때문에 처음부터 명확했습니다. 모니터는 서버 가용성을 지속적으로 확인해야 했습니다. 시간에 한 번도, 하루에 한 번도 아닌, 몇 초 내에 중단을 감지할 수 있을 정도로 자주. ping 요청에 응답하는 서버뿐만 아니라 HTTPS 연결이 성공적으로 완료되고, SSL 인증서가 유효하고 만료 임박하지 않으며, 응답 시간이 허용 가능한 범위 내에 있는지 확인해야 했습니다. 그리고 즉시 경고를 제공해야 했습니다. 수동 확인이 필요한 대시보드가 아니라, 문제가 감지된 후 몇 초 내에 받은 편지함에 도착할 이메일 알림을 통해.

나타난 아키텍처는 이러한 우선 순위를 반영합니다. 모니터링되는 모든 끝점은 동시에 여러 차원에서 정기적인 간격으로 확인됩니다. ping 확인은 기본 네트워크 도달 가능성을 확인합니다. HTTPS 확인은 웹 서버가 응답하고 SSL 핸드셰이크가 오류 없이 완료됨을 확인합니다. 인증서 확인은 만료 날짜를 검사하고 갱신이 필요할 때 경고합니다. 응답 시간 확인은 전체 요청이 얼마나 오래 걸리는지 측정하고 치명적이 되기 전에 저하를 표시합니다. 이러한 각 확인은 실시간 경고와 과거 추세 분석 모두에 포함되는 데이터 포인트를 생성합니다. 즉, 시스템은 중단을 포착한 후에 포착할 뿐 아니라 문제가 발생하기 전에 문제를 예측할 수 있는 패턴도 밝혀냅니다.

일일 및 주간 다이제스트 이메일은 모니터링되는 모든 끝점, 가동 시간 백분율, 평균 응답 시간 및 해당 기간 동안 발생한 모든 사건에 대한 요약 보기를 제공합니다. 이러한 다이제스트는 실시간 경고와는 다른 목적을 제공합니다. 경고는 순간의 문제를 포착하는 것이라면, 다이제스트는 인프라의 전반적인 상태 궤적을 이해하는 것입니다. 99.9%의 가동 시간을 유지했지만 지난 2주 동안 응답 시간이 꾸준히 증가한 서버는 문제로 향하는 서버이며, 다이제스트는 이 추세를 개별 경고 이메일이 할 수 없는 방식으로 가시화합니다.

개인 도구에서 플랫폼으로

개인 위기에 대한 해결책으로 시작한 것은 점차 더 광범위하게 유용한 것으로 확장되었습니다. 6개의 서로 다른 지리적 위치에서 확인을 보내는 다중 지역 모니터링 기능은 서버가 유럽에서는 액세스할 수 있지만 라우팅 문제로 인해 북미에서는 도달할 수 없는 실제 시나리오에서 나왔습니다. 단일 위치 모니터링은 모든 것이 정상이라고 보고했을 것입니다. 다중 지역 탐사는 불일치를 즉시 포착하고 영향을 받은 정확한 지리적 지역을 식별했습니다. 이러한 종류의 통찰력은 글로벌 대상을 제공하는 사람들에게 매우 귀중합니다. 한 위치에서만 모니터링이 발생하면 지역 중단이 완전히 감지되지 않을 수 있습니다.

사건 기록 기능은 호스팅 공급자와의 대화 중에 확실한 데이터를 가져야 할 필요성에서 나왔습니다. 반복되는 문제에 대해 지원팀에 연락할 때 모든 중단의 세부 타임라인, 지속 시간, 실패한 특정 확인 및 사건 전후의 응답 시간 측정을 갖추는 것은 "약간의 다운타임이 있었던 것 같습니다"라는 대화를 "정확한 타임스탬프, 지속 시간 및 실패 패턴이 있습니다"로 변환합니다. 해당 데이터를 통해 공급자에게 책임을 묻고 호스팅 회사와 함께 머물러야 할지 아니면 다른 곳으로 마이그레이션해야 할지에 대해 정보를 바탕으로 결정하기가 훨씬 쉬워집니다.

uptime.yeb.to의 전체 플랫폼은 이제 하나의 공지되지 않은 서버 종료와 5시간의 침묵으로 인해 존재합니다. 모든 기능은 적절한 모니터링으로 포착되거나 완전히 예방되었을 특정 실패로 거슬러 올라갑니다. Contabo 사건은 발생한 마지막 서버 문제가 아니었지만, 5시간 동안 감지되지 않은 마지막 문제였습니다. 그 구별이 모든 차이를 만듭니다.