새벽 3시에 죽은 서버를 오전에야 알았다
새벽 3시에 GCP에서 메일이 왔는데, 프로젝트가 shutdown됐다는 내용이었다.
오전에 경영지원팀이 "앱 접근이 안 된다"는 고객 이메일을 사내 채팅에 올렸고 그제야 알았다.
처음엔 Cloud Run 일부 인스턴스가 순단된 거라고 생각했다. 콘솔을 열었더니 인스턴스가 전부 0개였다. 순단이 아니라 전멸이었다. Cloud Run도, Cloud SQL도, Redis도 다 내려가 있었다.
배경은 결제 분쟁이었다. 몇천만 원. 구글 측은 협의 중엔 서비스에 이상 없을 거라고 했는데 믿는 내가 바보였다. 최종 청구일이 지나자 바로 shutdown됐다.
결제하고 서비스가 다시 뜨는 데 30분 걸렸다. 총 다운타임은 7~8시간. 복구에 쓴 시간은 30분이고, 나머지는 전부 모르고 있던 시간이었다.
모니터링이 없었던 게 아니다
서버 에러가 나면 Cloud Monitoring이 팀즈 채널로 알림을 보내는 연동은 있었다. 그런데 그 알림을 보내는 주체가 GCP였다.
그라파나도 팀즈 알림을 보낼 수 있다. 근데 그라파나를 GCE 위에 올렸다면 똑같이 죽는다. 그라파나가 못 하는 게 아니라, 그 자리에서는 아무도 못 한다. 차이는 기능이 아니라 위치다.
GCP가 shutdown될때를 대비해서 "밖에서 감시하는 창구가 있어야겠다."
Uptime Kuma를 Mac Studio에 올렸다
Uptime Kuma는 "살아 있냐"만 묻는 도구다. 그라파나가 "어떻게 살아 있냐"를 보여주는 도구라면, 이건 그 아래 층이다. URL이나 포트를 정해진 간격으로 두드리고 응답이 없으면 알림을 보낸다. 그게 전부다.
사내 공용 장비인 Mac Studio에 Docker로 띄웠다. 이유는 GCP 밖에서 감지하기 위해서다.
붙인 건 세 개다. Cloud Run은 HTTP로, MySQL과 PostgreSQL은 Cloud SQL 공개 IP에 TCP 포트 체크로. 쿼리는 안 날린다. 포트가 열려 있냐까지만 묻는다.