2023 - Bulk Mailler 실종 사건

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

 

 

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

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

 

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

 

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

 

변명

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

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

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

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

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

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

추적

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

1. 배포되어 있는 서버
2. 서비스와 연결된 DB
3. 프로젝트가 저장되어 있는 Git Repo

하나씩 추적해보자 

배포되어 있는 서버 찾기

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

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

메일의 원본을 확인한다. 

Received 정보를 확인한다.

후이즈 도메인 검색에 IP 을 검색하면 호스트 정보가 나온다. 

결론

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

 

서비스와 연결된 DB

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

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

 

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

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

 

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

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

 

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

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

 

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

 

프로젝트가 저장되어 있는 Git Repo

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

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

 

살려내자 

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

 

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

다신 안 만났으면 좋겠다.