큐잉(Queueing)서버를 이용한 메일서비스 가용성강화

큐잉(Queueing)서버를 이용한 메일서비스 가용성강화

외부에서 누군가가 메일을 보냈다고 하는데, 못 받은 적이 있는가? 이런 일이 한 두 번이라면 무시하겠지만 두 번, 세 번 계속 늘어나게 되면 아마도 서버관리자의 능력을 의심받게 될 것이다.

더군다나 계약이나 구매 등 중요한 내용의 비즈니스 관련 메일이었다면 더더욱 그러할 것이다.

sendmail은 25번 포트를 리슨하면서 보내는 메일 서버 역할을 하지만 외부에서 오는 메일을 수신하여 MDA인 procmail을 통해 사용자의 메일 박스에 저장하는 역할도 한다.

그런데, 만약 시스템의 부하율이 일정수치 이상으로 상승하거나 /var 파티션이 100%인 경우에는 sendmail이 작동하지 않게 되는데, 다운된 시간 동안에는 수신하여야 할 중요한 메일을 받을 수 없거나 반송이 될 것이다.

이에 대한 대안은 없을까?

이를 위해 dns에서 MX 레코드 값을 조정하여 별도의 백업 역할을 할 서버를 구축하면, 주 메일 서버가 다운되었을 때 임시로 메일을 수신해 두었다가 메일 서버가 복구되면 원래의 메일 서버로 수신해 두었던 메일을 포워딩 하도록 할 수 있는데, 이러한 서버를 큐잉(Queueing) 서버라고 한다.

이 큐잉 서버를 통해 메일 서비스의 가용성을 향상할 수 있을 것이다.

먼저 아래와 같이 메일 서버에 대한 MX(Mail Exchanger) 레코드 질의를 하여 메일 설정을 살펴보기 바란다.

아래는 ns.dacom.co.kr이라는 dns 서버에 server.com이라는 도메인의 MX 레코드 값을 질의한 결과이다.

위와 같은 경우 현재는 id@server.com으로 메일이 발송되면 server.com 서버에서 메일을 함께 수신하도록 되어 있다.

그런데, 만약 server.com 서버의 sendmail이나 qmail등 메일 서비스가 중지되면 즉, server.com의 25번 포트가 리슨하지 않으면 id@server.com으로 향하는 메일은 반송되거나 SMTP 서버의 큐에 저장되었다가 삭제되는 등 메일을 수신하지 못하게 될 수 있다.

이를 위해 DNS 서버의 zone 파일에서 다음과 같이 설정을 변경할 수 있다.

기존 설정)

변경 설정)

이후 DNS 질의를 하면 다음과 같이 MX 설정이 변경되어 있는 것을 발견할 수 있다.

위 설정의 의미는 외부에서 id@server.com으로 메일을 발송할 때 일차적으로 MX 값이 제일 작은(10)-따라서 선호도가 높은- server.com 서버로 메일이 발송되고, 만약 server.com 메일 서버가 다운되었을 경우 즉, 25번 포트가 리슨하지 않고 있을 경우 다음으로 MX 값이 작은(20) 메일 서버인 mail2.server.com으로 메일이 발송되고, 만약 두 번째 메일 서버인 mail2.server.com조차도 다운되었을 경우에는 그 다음 MX 우선도(30)인 mail3.server.com으로 메일이 발송되는 것이다.

즉, 메일 데몬의 다운에 대비하여 메일 서버를 3중으로 구성한 것이다.

단, 여기에서 보여 지는 MX 레코드의 순서는 중요하지 않으며 MX값의 크고 작음만 보면 된다.

[그림] MX 의 작동원리

여기에서 MX 레코드에 대해 잘못 이해하는 것 중 하나는 만약 1차 메일 서버인 server.com이 다운되어 mail2.server.com으로 메일이 배달되었을 때, 메일이 mail2의 메일 박스에 저장 된다고 생각하는 것인데, 만약 이렇게 된다면 유저 입장에서는 메일 수신 시 pop3 서버를 server.com와 mail2.server.com과 같이 MX 설정 수만큼 여러 개 설정해야 하는 번거로움이 있을 것이다.

그러나 mail2.server.com이나 mail3.server.com처럼 MX 값이 높은(즉, 우선도가 낮은) 메일 서버는 소위 ‘큐잉 서버’로 동작하기 때문에 비록 2차, 3차 메일 서버로 메일이 발송된다 하더라도 전송된 메일은 임시로 큐잉 서버에 저장(큐잉)된 후 일정 시간 후 메인 메일 서버인 server.com이 살아났을 때 자동으로 server.com으로 메일을 재전송하게 되므로 결국 id@server.com으로 발송된 메일은 하나의 메일 서버(server.com)로 모이게 되는 것이다.

위와 같이 mail2와 mail3 서버가 큐잉 메일 서버로 작동하려면 mail2와 mail3 서버의 설정파일에 아래와 같이 해당 도메인으로 릴레이(Relay)를 허용하도록 하는 추가 설정을 해 주기만 하면 된다.

# sendmail의 경우(다른 메일 데몬 프로그램도 설정은 비슷하다.)

(1) mail2와 mail3의 /etc/mail/access에서 아래와 같이 RELAY를 허용하여야 한다.

(2) mail2의 /etc/mail/local-host-names에는 mail2.server.com을 mail3의

/etc/mail/local-host-names에는 mail3.server.com을 추가해 주어야 한다.

여기에서 주의하여야 할 것은 큐잉 서버인 mail2와 mail3에는 /etc/mail/local-host-names 파일에 server.com 파일이 정의되어 있으면 절대(!) 안 된다는 것이다.

만약 정의되어 있을 경우에는 MX 레코드 값이 높다 하여도 로컬 도메인으로 인식하여 더 이상 큐잉 서버로서 작동하지 않게 되어 메인 서버로 메일을 포워딩하지 않게 되기 때문이다.

설정을 마친 후에는 실제로 큐잉이 작동하는지 확인하기 위해 메인 서버인 server.com의 메일 데몬을 다운시킨 후 아래와 같이 외부에서 메일을 발송해 보기 바란다.

위와 같이 메일을 전송하기 위해 먼저 server.com으로 접속을 시도한 후 server.com이 다운된 것을 확인하자 큐잉 서버인 mail2.server.com으로 재접속을 시도한 것을 알 수 있다.

이후 mail2 규잉 서버에서 mailq를 실행해 보면 아래와 같이 테스트로 발송한 메일이 임시로 큐에 저장되어 있는 것을 확인하였고, 잠시 후 server.com 메일 데몬이 살아나자 직접 "/usr/sbin/sendmail -qR@server.com -v"을 실행하거나 잠시 기다리면 메인서버인 server.com 서버로 큐잉 되었던 메일이 발송된 것을 확인하였다.

이와 같은 방식으로 다른 유명한 사이트들은 어떻게 운영하는지 확인해 보자.

앞에서 4691과 361은 각각 해당 dns서버가 캐싱하고 있는 초단위의 Cache time(TTL)을 의미한다.

먼저 yahoo.co.kr의 경우를 예로 들면, MX 값이 20인 호스트가 두 개가 있는데, 이러한 경우에는 두 호스트 중 random하게 한 호스트에 메일이 전달되고 만약, 한 호스트가 다운되면 MX 레코드가 20인 다른 호스트로 전달된다.

그리고 MX 레코드가 20인 호스트 둘 다 다운되었을 경우 MX 레코드가 40인 호스트로 전달되는 것이다.

microsoft.com의 경우 mx preference 값이 10으로 모두 동일한데, 이는 random하게 로드발랜싱된다고 생각하면 된다.

그런데 위와 같이 MX가 동일한 경우 pop3를 이용하여 메일을 수신하려고 할 때 pop3 서버는 어떤 서버를 지정하여야 할까? 이는 내부 시스템이 어떻게 구성되었는가에 따라 다를 수 있는데, 시스템을 어떻게 설계하였는가에 따라 여러 가지 구성이 있을 수 있기 때문이다.

가장 간단히 사용할 수 있는 방법은 sendmail 데몬 또는 프로세스만 각각 별도의 두 서버에서 실행하고, 메일박스(/var/spool/mail/) 디렉토리는 NFS나 storage등으로 묶어 공유하도록 하면 메일 박스는 한 서버에 저장될 것이다.

[그림] mx 레코드가 같을 경우의 구성 예

또는 앞단의 서버에서 1차적으로 메일을 수신 후 스팸이나 바이러스 메일은 걸러내고 정상 메일만 내부에 지정된 pop 서버로 전송할 수도 있을 것이다.

위의 예는 여러 가지 방법들 가운데 한 가지를 언급하였을 뿐이며 실제로는 위 그림과 다르게 구현될 수도 있으므로 참고만 하기 바란다.