이전 스타트업에서 cloudwatch를 통해 서버 로그를 확인하고, lambda + eventbridge를 통해 동작하는 배치 작업들의 로그를 확인하고, 배포과정에서 빌드로그들도 모두 확인할 수 있도록 제작했었다.
하지만 항상 고객문의를 통해 문제점을 알고 aws console에 접속해 로그를 뒤져가며 확인해야 했다.
log insights
cloudwatch에는 log insights라는 것이 존재한다. 쌓이는 로그들을 적절한 쿼리를 통해 필터링하고 원하는 정보만 가져올 수 있도록 도와주는 기능이다.
또한 cloudwatch의 로그파일에 들어가 검색하는 것보다 빠른 속도를 보여주는 것 같았다. 이를 이용해서 우선 5xx대 에러, 4xx 에러 그리고 시간이 오래걸린 API들의 로그들을 각각 필터링하여 cloudwatch내 dashboard에 보여줄 수 있도록 했다.
이를 통해 고객문의를 통해 문제를 인지하였을 때, 좀 더 빠르게 해당 로그들을 찾아볼 수 있었고 약간의 빠른 대응이 가능했다.
하지만 여전히 고객문의를 통해 문제를 해결해야했다.
alarm
cloudwatch에는 alarm을 보내는 기능또한 존재한다. 이를 이용해 서버 및 로드밸런서에서 발생하는 모든 5xx번대 에러들이 발생했을 때, alarm이 발생하도록 했다.
이렇게 alram이 발생하게 되면, SNS의 server error logging 토픽으로 메시지를 전송하여 해당 토픽을 구독하고 있는 주체들에게 전달될 수 있도록 했다.
뿐만 아니라, rds와 사용중인 ec2 인스턴스들의 상태에 대한 알림들도 추가해 경보를 받을 수 있도록 했다.
배치 및 배포
lambda + eventbridge를 사용한 배치작업 그리고 code deploy, code bulid, code pipeline를 통한 배포 과정들도 SNS 특정 토픽을 구독 시켜 동작의 결과들을 이메일 알림을 받을 수 있도록 했다.
slack
하지만 매번 이메일로 알림을 받고 이메일도 내 이메일만 등록해놓다보니 매번 발생한 에러를 공유해야 했고, 내가 확인하지 못하는 경우, 다른 팀원들이 알 수 없었다.
그래서 회사에서 사용하고 있는 메신저인 slack으로 모든 알림이 올 수 있도록 하려고 했다.
배포과정에서 발생하는 모든 알림 및 경보들은 aws chatbot을 사용해 각각의 slack 채널들과 쉽게 연동할 수 있었고 메시지 템플릿도 알아서 잘 보내주었다.
하지만 lambda를 사용한 배치 작업들은 chatbot을 통해 연결하는 것이 잘 되지 않았다. 그래서 별도의 slack알림용 lambda를 만들어 배치작업의 알림을 발행하는 토픽을 구독시켰고, slack web api hook을 사용해 적절하게 만든 메시지를 slack 채널에 전달될 수 있도록 했다.
오늘 봤던 구름 세미나에서 장애 대응 관련한 강의를 보고 서너달전에 만들어봤던 모니터링 작업들을 까먹지 않게 적어봤다.
모니터링의 중요성과 장애대응을 어떤 순서로 진행해야하는지, 의사소통은 어떻게 해야하는지 등 여러 이야기를 들어볼 수 있었다.
매우매우 빈약하지만 나름 혼자 위와 같은 방법들로 모니터링을 구축했었는데, 실제로 로드밸런서 idle timeout과 서버 keepalivetimeout 설정의 문제로 발생했던 502 bad gateway에러도 확인하고 수정할 수 있었고, 5xx번대 에러가 발생하는 즉시 알림을 받고 고객 문의가 아닌 먼저 문제를 인지하고 원인을 파악할 수 있었다.
먼저 문제를 인지하고 공유하고 원인을 파악해 나가는 것이 결국은 회사의 좋은 이미지를 구축하고 사용자 경험을 향상시키는데에도 많이 중요하다는 생각도 들었다.
