"메일 서버는 절대 직접 돌리지 마라"는 말이 있습니다. 스팸 필터, 발신 평판, DKIM·SPF·DMARC, 24시간 가용성 — 맞는 말입니다. 대부분의 경우에는요.
그런데 저희는 직접 하기로 했고, 지금 사내 메일이 그 위에서 돌아갑니다.
왜 다시 따져봤나
계기는 단순합니다. 이미 클러스터가 있었습니다.
메일을 직접 운영하지 말라는 조언의 전제는 "그거 하나 때문에 서버를 세우고 관리해야 한다"입니다. 인증서 갱신, 모니터링, 백업, 장애 대응 — 전부 메일 때문에 새로 만들어야 하는 것들이죠.
그런데 그 인프라가 다른 이유로 이미 있다면, 계산이 달라집니다. 인증서는 자동 발급·갱신 체계가 이미 돌고 있고, 배포는 저장소에 커밋하면 되고, 모니터링과 로그는 다른 서비스와 같은 곳에 쌓입니다. 메일 서버 하나가 추가로 요구하는 것은 생각보다 적습니다.
무엇을 얻었나
계정 수에 비례하는 비용이 사라집니다. 상용 메일 서비스는 사람이 늘면 돈이 늘어납니다. 직접 운영하면 늘지 않습니다. 회사가 커질수록 격차가 벌어집니다.
메일 데이터가 우리 안에 있습니다. 거래 관련 문서가 오가는 곳이라 이게 작은 문제가 아닙니다.
다른 사내 시스템과 같은 방식으로 관리됩니다. 메일만 별도 콘솔에 들어가서 설정하는 게 아니라, 다른 모든 것과 똑같이 저장소에서 값을 바꾸고 커밋합니다.
어려웠던 것
가장 손이 많이 간 건 메일 자체가 아니라 비밀값 처리였습니다.
이전 배포 체계에서 넘겨받은 설정에는 관리자 비밀번호와 메트릭 계정 정보가
평문으로 들어 있었습니다. 이걸 저장소에서 빼내야 하는데, 차트가
secrets.create: false 로 두면 Secret 을 만들지 않을 뿐 아니라
참조까지 함께 사라지는 구조였습니다. 같은 조건문이 둘 다 감싸고
있었기 때문입니다.
결국 차트가 만들어 주는 경로를 쓰지 않고, 클러스터에 미리 둔 Secret 을 직접 참조하도록 바꿨습니다. 대신 그 Secret 은 배포 도구가 관리하지 않으므로 삭제 동기화를 켜면 지워집니다. 이 위험을 값 파일 맨 위에 경고로 적어 뒀습니다. 몇 달 뒤의 자신이 읽을 것을 전제로요.
메일 수신을 위해 고정 IP 를 잡고 MX 를 붙이는 일, 헬스 체크 설정이 값
파일의 null 때문에 통째로 지워져 있던 것을 되돌리는 일도 있었습니다.
후자는 이관 전부터 조용히 깨져 있던 것이었습니다.
그래서 직접 하라는 말인가
아닙니다. 조건이 맞을 때만입니다.
쿠버네티스 클러스터를 이미 운영하고 있고, 인증서와 배포가 자동화돼 있고, 장애가 났을 때 볼 사람이 있다면 — 그때는 계산해 볼 만합니다. 그 셋 중 하나라도 없다면 상용 서비스를 쓰는 게 맞습니다.
저희는 셋 다 있었고, 그래서 했습니다.