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