서비스를 운영하다 보면 자연스럽게 로깅과 모니터링에 신경을 쓰게 된다. 에러 로그를 남기고, 지표를 수집하고, 문제가 생기면 로그를 뒤져 원인을 찾는다.
하지만 운영을 하다 보니 한 가지 분명하게 느낀 점이 있었다.
로깅만으로는 서비스의 상태를 빠르게 알아차릴 수 없다.
로깅은 기록이지 우리한테 알림을 날려주는 것이 아니다.
로그는 기본적으로 문제가 발생한 이후에 확인하는 도구다. 에러가 발생한 후 로그를 보고 나서야 이상을 파악하고 대처할 수 있다.
특히 다음과 같은 상황에서는 로깅만으로는 한계가 분명했다.
우리가 항상 24시간 서비스를 사용하고 있지 않기 때문에 잠자는 시간대에는 문제가 발생해도 바로 체감하기 어렵다.
게다가 트래픽의 70% 정도가 미국인만큼 우리와 시간대가 달라 모니터링 알림 도입 전에는 사용자의 피드백 채널을 보고 늦게서야 일어나서 대응할 수밖에 없었다.
아침에 일어나서 사용자의
User : It seems chats are not working...
라는 댓글을 보면 심장부터 턱 가라앉는 느낌이 났다.
그래서 필요했던 것이 바로 사용자 입장에서 서비스를 계속 사용해보는 모니터링이었다.
서비스가 정상인지 판단하는 기준은 단순하다.
사용자가 접속해서 기능을 사용할 수 있어야 하므로, 서버 프로세스가 살아있는지, Pod가 Running 상태인지 CPU, Memory가 정상인지 등이 있겠다.
하지만 사용자에게 중요한 것은, 페이지가 열리는지, API 요청이 응답하는지 특정 기능이 실제로 동작하는지 이다.
우리는 외부에서, 사용자 관점으로 서비스를 주기적으로 확인해주는 도구인 Checkly를 도입했다.
Checkly를 사용하면 다음과 같은 것들을 할 수 있다.
- 서버가 살아있는지 주기적으로 확인
- 특정 API가 정상 응답하는지 검증
- 실제 사용자가 사용하는 흐름을 시뮬레이션
- 문제가 발생하면 즉시 알림
즉, 실제 사용자가 계속 서비스를 쓰고 있는 것처럼 자동으로 확인해주는 도구라고 보면 된다.
Checkly는 기본적으로 서버 코드 변경 없이 GUI만으로도 코드 변경 없이 바로 연동 가능하기 때문에 어렵지 않게 연동이 가능하다.
우리는 여러 테스트 상황에 대해 문제가 있을 때 디스코드로 알림이 오도록 설정했다.
우리는 아래 상황을 모니터링 하도록 했다.
[Backend]
- 데이터베이스에 연결이 잘 되는지
- 각 서버의
/healthAPI에 연결이 잘 되는지 - 채팅 스트리밍 기능이 잘 작동하는지
- 콘텐츠 추천 API가 잘 작동하는지
[Frontend]
- 메인 화면 요청이 잘 되는지
- 로그인 기능이 잘 동작하는지
아래와 같이 디스코드로 알림이 온다.
아래 알림은 새벽 4시에 온 건데, 인증 서버, 데이터베이스가 동작하지 않는 아주 큰 이슈였다.
이때 자고있던 것이 기억나는데, 갑자기 알림이 떠서 봤더니 DB가 안 먹는 상황이어서 재빨리 일어나 대처했다.
만약 Checkly가 없었으면 이보다 몇 시간 더 장애가 계속되었을 것이다.
우리는 간단한 몇몇 서버는 EC2에서 직접 돌리고 있는데, 이렇게 SSL 인증서 만료 예정 알림도 주니 너무 편리한 거 같다.
Checkly를 도입하고 나서, 밤에 자다가 서비스가 중단되는 것을 못 알아챌 수도 있다는 두려움을 없애주었다.
비록 새벽에 일어나는 것은 유쾌한 일이 아니지만, 서비스가 중단되는 것보다는 낫다.
24시간 사람이 직접 서비스를 보고 있을 수 없는 환경에서, Checkly는 우리 대신 사용자가 되어 서비스를 계속 두드려보는 역할을 해주었다.
모니터링은 복잡하게 구성하기 보다는 필요한 지점을 정확히 보고 알려주도록 하난 것이 더 중요하다고 생각한다. 이런 점에서 Checkly는 가볍게 시작하면서도 실제 운영에 큰 도움을 준 도구였다.
댓글 남기기