2023 - Bulk Mailler 실종 사건

임시보관/실무 이슈

귀찮은 개발자 2024. 2. 29. 00:57

태어난 모든 것들은 기약조차 없는 이별을 준비하고 있어야 한다
발타사르 그라시안

레거시 서비스에서 어느날 갑자기 예약 메일 발송하는 서비스가 사라졌다.

해당 서비스에서 동작하던 내가 알고 있던 Application 도 아니었다.

그렇다면 사라진걸 어떻게 알았을까

예약 메일이 발송되지 않으니까 알았지..

변명

우선 이 서비는 2000년도 초반에 오픈하였으며 2010년도 후반부터 간단한 유지보수 작업만 이루어졌다.

이 서비스를 담당했던 직원들은 극 소수를 제외하고 모두 퇴사하였고, 질문을 해도 5할은 모른다..

혼자 유지보수하는 Application 은 약 20개 정도이며 뭐가 더 있는지는 모른다.

보안상의 이유로 대부분의 문서를 볼 수 있는 권한이 없다.

장애가 발생했을 때만 엄청난 고뇌를 통해 하나씩 알게되는 녀석이다.

서버만 10개가 넘는데 1년에 1-2번 밖에 안들어가본다. (들어갈 이유가 없으니까)

찾아야 하는 단서는 3가지로 매우 단순했다.

하나씩 추적해보자

이건 생각보다 단순했다. Mail 을 발송하면 어느 서버에서 발송되었는지 정보를 확인할 수 있기 때문이다.

예를 들어 Github 의 정보는 이렇다.

Bulk Mailer 의 서버를 찾았지만 IDC 가 매각 당하고, 인수당하는 사이 관리가 안되서 사라졌기 때문에 희망이 사라졌다.

서버를 찾아서 서버에 접속을 했다면 모든 것이 쉬웠을 것이다.

하지만 서버를 찾지 못했기 때문에 Master DB 에 접속하여 의심가는 테이블을 찾고 SQL 쿼리가 사용되는 곳을 찾아봤다.

의심가는 테이블을 사용하는 서비스는 하나.

그 하나를 뒤져야했다. 결과적으론 Read 와 Write 는 하지만 Send 는 하지 않고 있었다. (왜냐 Send 는 사라진 서버에서 했기 때문에)

그렇다면 서비스가 분리된 것이다.

이전 개발자의 의도를 생각해보자.

하나의 서버에서 많은양의 단체 메일을 발송하면 스팸메일로 차단당할 수 있다.

또한 단체메일 Queue 와 인증과 같은 단순 메일이 동일한 서버에 있다면 Queue 또는 메모리가 확 튀는 현상으로 서비스에 순간적 장애를 잃으킬 수 있기 때문이다.

일단 테이블은 찾았으니 SELECT (조회) 와 UPDATE (발송 상태 관리) 하는 서비스를 Git Repo 에서 더 찾아보자.

약 100개가 되는 Git Repo 를 모두 Clone 받았다. 하나씩 열어보는 것은 비율적 이기 때문에 터미널로 테이블을 키워드로 하여 검색할 것이기 때문이다.

그 결과 두개의 레포를 찾았고 Git Commit Log 을 분석하여 무엇이 진짜이고 가짜인지 구분을 해야했고 진짜로 의심가는 프로젝트의 코드를 리뷰했다.

코드를 리뷰하니 의심이 확신이 되었고 리소스가 여유있는 서버에 Application 을 배포할 준비를 마치고 TXT SPF 레코드를 수정하여 DNS 쿼리가 잘 전파되었는지 확인을 하고 Apllication 을 배포하였다.

그리고 재발 방지는 못하겠고, 관리 차원에서 메트릭 API 을 만들고 그라파나에 붙여줬다.

다신 안 만났으면 좋겠다.