# 개발 원인
우리 회사에서는 비용상의 문제로 APM을 이용하고 있지는 않고, Cloudwatch 를 통해 지표와 에러를 모니터링 하고 있다. 그 중 api 에서 500번대 에러가 발생하면, 각각에 매핑된 슬랙 채널로 에러 메시지를 보내고, 상세 내용은 스레드에 담아 에러를 쉽게 파악할 수 있게 하고 있다.
하지만 이전부터 불편한 부분이 좀 있었는데, 어쩌다 에러가 동시다발적으로 많은 양이 발생할 때 아래처럼 동일한 에러가 쌓이게 된다.
이런 경우 생기는 문제는 두 가지 정도가 있는데, 일단 메시지 알림이 무지하게 온다. 동일한 에러이기 때문에, 한 번 인지하고 나면 개선을 하는 동안은 어느정도 무시해도 되는 알림인데, 담당자가 아닌 경우에도 같은 채널에 있다면 의미가 없어진 에러 알림을 계속 받게 된다.
그리고 더 큰 문제는 동일한 에러가 잔뜩 쌓이는 와중에 다른 에러가 몰래 잠입할 수가 있다. 하지만 빠른 속도로 에러는 쌓여가고, 그 사이에 비슷한 템플릿의 에러 메시지가 지나가게 되면 놓칠 수 있는 가능성이 생기게 된다.
만약 그 에러가 치명적인 에러였다면..?
(그렇게 우린 집에 가지 못했다고 한다…)
그래서 어떻게 하면 개선할 수 있을지 생각해 봤다.
동일한 에러는 담당자에게만 노출시키고, 알림이 가게 하면 되지 않을까?
그러려면 담당자를 지정할 수 있어야겠네?
그리고 해결된 에러는 표시를 해서 끝맺음을 명확히 하면 좋겠네?
이제 이걸 구현해보자.
# 아키텍처 구상
현재 EC2에 올라가 있는 백엔드 서버에서는 500 대 에러가 발생하면 특정 슬랙 채널에 해당 에러 정보를 전송한다.
이제 에러 정보를 제공할 때 a. 현재 감지된 에러인지, 그리고 그 b.에러에 담당자가 배정이 됐는지 를 확인하여 조건에 따라 다른 메시지를 적용해야한다. 이를 위한 기준 데이터는 DynamoDB 에서 관리한다.
DynamoDB 를 선택한 이유는,
- 에러 정보를
router 명 + 에러메시지 일부를 key 로 구분할 예정이고, DynamoDB 는 key 를 기반으로 사용하기에 적절한 DB다. - DynamoDB의 요금은 RDS와 달리 저장된 데이터 용량, 읽기, 쓰기 등으로 정해지는데, 저장되는 에러의 양이나 발생 빈도가 매우 적고, 처리 완료된 데이터는 제거하기에 여러모로 거의 비용이 들지 않는다.
- 그리고 특정 컬럼에 대한 조회 조건도 글로벌 인덱스 적용을 통해 가능하다.(비용이 더 들긴 하지만, 애초에 사용 비용이 적어 영향이 적다)
슬랙 메시지의 버튼 및 커맨드와 상호작용하는 API는 Lambda 에 구현했다.
Lambda 를 선택한 이유는,
- 기존에 에러와 같은 부가 기능을 전담하는 서버가 존재하지 않아 대체 서버가 필요했다
- 에러의 담당자를 다루는 기능은 필수 기능이 아니기에, 기존 서버에 영향을 줘서는 안됐다
- 에러는 자주 발생 하지 않기에 서버가 상시 떠 있을 필요는 없다(다 비용이다)
- 복잡하지 않은 기능만 구현하면 되고, 호출 빈도가 적기에 비용도 거의 들지 않는다
EventBridge를 통해 간편하게 배치 스케줄링을 할 수 있다
지정된 시간에 “처리되지 않은 예외 리스트”를 보여주는 배치는 EventBridge 로 Lambda 를 스케줄링하여 구성했다.
## 예상 비용
이쯤에서 예상 비용을 계산해보자.
대략 월 30건의 에러가 발생하고, 그에 따른 상호작용이 3건씩 있다고 가정
Lambda - 128MB 메모리 / 512MB 임시 스토리지 / 평균 실행시간 1초(400ms~1.4s)
→ 0.00 USD / M
DynamoDB - 데이터 스토리지 크기 0.01 GB / 평균 항목 크기 1KB / 쓰기 읽기 각각 300건
→ 0.00 USD / M
추가로 비용이 들어가는 부분을 계산해보니 비용은 거의 0에 수렴했다. 두 서비스 모두 사용한만큼 돈을 부과하는 방식이고, 에러 자체도 자주 발생하는 부분이 아니다보니 저렴하게 사용할 수 있다
** 계산은 AWS pricing calculator 를 이용했다.
# 구현 시나리오
구현 코드 자체는 크게 어렵지 않아서, 어떤 시나리오로 구현 했는지 위주로 살펴보겠다.
## 최초 에러 발생 시
에러가 발생하면 기존처럼 슬랙에 에러 메시지를 보내주는건 동일하다. 다만 이 메시지 안에 담당자 배정에 대한 추가 정보를 담고, 나를 담당자로 지정할 수 있는 버튼을 추가했다.
최초 에러 발생 시 router + message 를 묶어 key 로 만들고, 이를 기준으로 DynamoDB 에 데이터를 쌓는다. 담당자 지정 전에 동일 에러가 발생하면, DB에 새로 생긴 메시지의 thread ts 정보로 업데이트 한다.
참고로 기존 API 서버에서 DynamoDB 와 추가로 연결이 되는 부분은 에러 발생 시 처리 지점인데, 담당자 관련 로직은 필수 로직은 아니므로, 이곳에서 이슈 발생 시 pass 하도록 적용했다.
## 담당자 지정 후
담당자를 나로 지정한 후에는 해당 이벤트를 Lambda 로 전달하여 기존의 슬랙 메시지를 수정하고, 하위 스레드에 담당자를 태그하여 이후 스레드를 트래킹 할 수 있게 한다.
배정된 이후에는 동일한 키를 가진 에러 메시지는 해당 스레드에 쌓아준다. 이렇게 되면 동일한 에러가 메인 화면에 뜨지 않고, 담당자가 아닌 사람은 주의를 뺏기지 않게 된다. 만약 다른 담당자도 넣고 싶다면, 스레드에 수동으로 태그한다.
배정 취소를 하면 다시 [담당자 배정 필요] 상태가 된다. 이 상태가 되면 다시 새로운 에러들은 메인 화면에 노출되게 된다.
## 처리 완료
처리 완료 후에는 이슈 처리 완료 상태가 되고, 처리 일시가 명시된다. 이후 동일한 에러는 다시 [담당자 배정 필요]로 새로운 메시지로 발행된다
## 관련 이슈 처리
그런데 문제(?)가 있긴 했다. 동일 에러가 여러번 슬랙에 발행된 이후에 상태를 처리한다면, 처리하고 있는 메시지를 제외한 다른 메시지들은 상태를 다시 처리하기에 애매한 상황이 된다.
이미 동일한 에러를 처리하고, 담당자가 지정됐다고 DB 에 지정되어 있는데, 또 다른 메시지에서 이 상태를 수정할 수 있다면 안될 일이었다.
이전 메시지들을 모두 찾아서 수정하는 것도 모든 thread ts 를 저장하지 않기 때문에 할 수 없는 일이었고, 굳이 저장해서 하는 것도 불필요하다고 생각했다.
그래서 현재 해당 에러의 처리 상태에 따라 다른 메시지에서 상태 수정을 할 때 예외 처리를 했다.
[내가 처리하기]를 누른 시점에 이미 다른 스레드에서 담당자가 배정된 상태라면, 다른 스레드에서 처리중임을 알리고, 해당 스레드로 이동할 수 있는 링크를 제공했다.
그리고 [내가 처리하기]를 누른 시점에 이미 다른 스레드에서 처리 완료된 상태라면, 처리 완료된 이슈라는 메시지로 수정하여 알려준다. (처리 완료된 데이터는 보관하지 않기 때문에, 해당 데이터 존재 유무로 판단한다)
## 처리 누락을 막기 위한 배치
그리고 에러가 발생한 후 처리되지 않은 상태로 남아 있게 되면, 추가로 에러가 발생하기 전에는 이게 다 처리가 된건지 아닌지를 알기가 쉽지 않을 것 같았다.
그래서 배치를 통해 현재 처리되지 않은 에러들을 리스트로 노출하고, 바로가기를 통해 바로 해당 스레드로 이동할 수 있게 했다. 현재는 매일 아침 특정 시간에 배치를 통해 발행하는 것으로 생각하고 있다
## 조회 커맨드 구현
배치가 도는 시점 외에도 현재 처리되지 않은 에러들을 알고 싶을 때는 슬랙 커맨드를 사용하면 된다. /조회 (전체|배정|미배정) 이라는 슬랙 커맨드를 만들어뒀고, 커맨드를 요청하면 Lambda 에서 해당 결과를 조회해 슬랙으로 보내준다.
# 결론
위와 같이 비용은 들이지 않으면서 기존의 에러 모니터링 시스템을 개선할 수 있었다. 슬랙에서 제공하는 기능과 lambda 를 연결하면 시스템이 부하를 최소화 하면서 여러 가지 기능을 붙이기 좋다는 인사이트(?)도 얻었다.
앞으로의 개선 점으로는 데이터를 어느정도 더 유지할지, 그 데이터를 이용한 대시보드 같은 걸 만들면 효용이 좋을지를 판단해서 디벨롭 해 볼 예정이다.
