릴레이 서버 기술적 구조

SMTP 릴레이 프로세스

 
클라이언트 → [SMTP AUTH] → 릴레이 서버 → [DNS MX 조회] → 목적지 서버

릴레이 서버는 다음과 같은 기술적 단계를 거칩니다:

  1. 연결 수락: TCP 25번 포트에서 SMTP 연결 수신
  2. 인증 검증: SMTP AUTH 또는 IP 기반 인증 수행
  3. 메일 큐잉: 전송할 메일을 큐에 저장
  4. DNS 조회: 수신 도메인의 MX 레코드 조회
  5. 전달 시도: 목적지 서버로 SMTP 연결 및 전송
  6. 재시도 관리: 실패 시 백오프 알고리즘으로 재시도

릴레이 인증 메커니즘

SMTP AUTH 방식

  • PLAIN: Base64 인코딩된 사용자명/비밀번호
  • LOGIN: 대화형 인증 방식
  • CRAM-MD5: 챌린지-응답 기반 해시 인증
  • DIGEST-MD5: 더 강화된 다이제스트 인증

IP 기반 릴레이 제어

 
# Postfix 예시
mynetworks = 192.168.1.0/24, 10.0.0.0/8
relay_domains = example.com, partner.com

릴레이 서버 구성 유형

1. 스마트 호스트 릴레이

 
# 모든 외부 메일을 특정 서버로 전송
relayhost = [smtp.isp.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_use_tls = yes

2. 백업 MX 릴레이

 
# DNS MX 레코드 설정
example.com.    IN MX 10 mail.example.com.
example.com.    IN MX 20 backup.example.com.

3. 멀티 홉 릴레이

 
내부서버 → 경계릴레이 → ISP릴레이 → 목적지

큐 관리 시스템

큐 구조 (Postfix 예시)

  • maildrop: 로컬에서 제출된 메일
  • incoming: 외부에서 수신된 메일
  • active: 현재 처리중인 메일
  • deferred: 전송 실패하여 재시도 대기중인 메일
  • corrupt: 손상된 메일 파일

재시도 알고리즘

 
# 백오프 간격 설정
minimal_backoff_time = 300s
maximal_backoff_time = 4000s
maximal_queue_lifetime = 5d

보안 및 스팸 방지

릴레이 보안 설정

 
# 오픈 릴레이 방지
smtpd_relay_restrictions = 
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination

# 연결 제한
smtpd_client_connection_count_limit = 50
smtpd_client_connection_rate_limit = 30

헤더 검증

 
# 릴레이 시 헤더 추가/수정
smtp_header_checks = regexp:/etc/postfix/header_checks
/^Received:/    PREPEND X-Relay-Server: relay.example.com

성능 최적화

연결 풀링

 
# 동시 연결 수 제한
smtp_destination_concurrency_limit = 20
smtp_destination_rate_delay = 1s

메모리 및 디스크 관리

 
# 큐 파일 관리
queue_file_attribute_count_limit = 100
message_size_limit = 50MB
mailbox_size_limit = 1GB

모니터링 및 로깅

로그 분석 포인트

 
# 릴레이 성공/실패 추적
tail -f /var/log/maillog | grep "relay="
# 큐 상태 모니터링
postqueue -p
# 통계 정보
pflogsumm /var/log/maillog

메트릭 수집

  • 릴레이 처리량 (msgs/min)
  • 큐 크기 및 지연 시간
  • 인증 실패율
  • 대상 서버 응답 시간

고가용성 구성

로드 밸런싱

 
# DNS 라운드 로빈
smtp.example.com.  IN A 192.168.1.10
smtp.example.com.  IN A 192.168.1.11

클러스터링

  • 공유 큐 저장소 (NFS, GlusterFS)
  • 데이터베이스 기반 설정 동기화
  • 장애 감지 및 자동 복구

릴레이 서버는 단순한 전달 기능을 넘어 메일 시스템의 신뢰성, 보안성, 성능을 좌우하는 핵심 구성요소입니다. 적절한 설정과 모니터링을 통해 안정적인 메일 서비스를 제공할 수 있습니다.

메일서버 전체 구조

메일 시스템은 여러 구성요소가 협력하여 동작합니다:

MTA (Mail Transfer Agent)

  • 메일 송신과 라우팅을 담당하는 핵심 서버
  • 대표적으로 Postfix, Sendmail, Exim 등이 있음
  • SMTP 프로토콜을 사용하여 메일을 전송

MDA (Mail Delivery Agent)

  • 최종 사용자 메일박스로 메일을 배달
  • Dovecot, Procmail 등이 대표적
  • 로컬 배달과 필터링 규칙 적용

MUA (Mail User Agent)

  • 사용자가 메일을 읽고 쓰는 클라이언트
  • Outlook, Thunderbird, 웹메일 등
  • IMAP/POP3로 메일 서버와 통신

DNS 시스템

  • MX 레코드를 통해 도메인의 메일서버 정보 제공
  • SPF, DKIM, DMARC 등 인증 정보 저장

릴레이 서버 (Mail Relay Server)

릴레이 서버는 메일 전송 과정에서 중간 매개체 역할을 합니다:

기본 개념

  • 발신자와 최종 수신 서버 사이의 중계 역할
  • 메일을 받아서 다음 목적지로 전달
  • 네트워크 토폴로지와 보안 정책에 따라 필요

주요 기능

  • 스마트 호스트: 모든 외부 메일을 특정 서버를 통해 전송
  • 백업 MX: 주 메일서버 장애 시 대체 수신
  • 로드 밸런싱: 트래픽 분산으로 성능 향상
  • 보안 게이트웨이: 스팸/바이러스 필터링

릴레이 설정 고려사항

  • 인증된 릴레이: SMTP AUTH를 통한 인증 사용자만 릴레이 허용
  • IP 기반 제한: 특정 IP 대역에서만 릴레이 허용
  • 오픈 릴레이 방지: 무단 스팸 발송 방지를 위한 필수 보안 조치

일반적인 릴레이 시나리오

  1. 내부 메일서버 → 외부 ISP 릴레이 → 목적지 서버
  2. 모바일 클라이언트 → 회사 릴레이 서버 → 외부 서버
  3. 웹애플리케이션 → 로컬 릴레이 → 외부 메일서버

릴레이 서버는 메일 시스템의 안정성과 보안성을 높이는 중요한 구성요소입니다. 특히 기업 환경에서는 내부 보안 정책과 외부 연결을 분리하는 역할을 합니다.

 

프로젝트 아키텍처 설계는 체계적인 접근이 필요합니다. 다음 순서로 진행하시면 됩니다:

1. 요구사항 분석 및 정의 (1-2주)

비즈니스 요구사항 수집

  • 프로젝트 목표와 핵심 비즈니스 가치 정의
  • 주요 이해관계자 인터뷰 및 요구사항 문서화
  • 성공 지표(KPI) 설정

기능적 요구사항

  • 사용자 스토리 및 유스케이스 정의
  • 핵심 기능 목록 작성
  • 비기능적 요구사항 (성능, 보안, 확장성, 가용성) 명시

2. 현황 분석 및 제약사항 파악 (1주)

기술 환경 분석

  • 기존 시스템 및 레거시 검토
  • 인프라 현황 파악
  • 팀의 기술 역량 평가

제약사항 식별

  • 예산 및 일정 제약
  • 기술적 제약사항
  • 규정 및 컴플라이언스 요구사항

3. 아키텍처 원칙 및 전략 수립 (3-5일)

설계 원칙 정의

  • 확장성, 유지보수성, 재사용성 등 품질 속성 우선순위
  • 기술 스택 선정 기준
  • 보안 및 데이터 거버넌스 정책

4. 고수준 아키텍처 설계 (1-2주)

시스템 분해

  • 도메인 모델링 및 경계 컨텍스트 정의
  • 마이크로서비스 vs 모놀리식 아키텍처 결정
  • 주요 컴포넌트 및 서비스 식별

아키텍처 패턴 선택

  • 레이어드, 헥사고날, 이벤트 드리븐 등 적절한 패턴 선택
  • 통신 방식 결정 (동기/비동기, REST/GraphQL/gRPC)

5. 데이터 아키텍처 설계 (1주)

데이터 모델링

  • 엔티티 관계도 작성
  • 데이터베이스 선택 (RDBMS, NoSQL, 하이브리드)
  • 데이터 플로우 및 저장 전략 수립

6. 기술 스택 및 인프라 설계 (1주)

기술 스택 확정

  • 프로그래밍 언어, 프레임워크 선택
  • 데이터베이스, 캐시, 메시지 큐 등 미들웨어 결정
  • 모니터링, 로깅 도구 선정

인프라 아키텍처

  • 클라우드 vs 온프레미스 결정
  • 컨테이너화 및 오케스트레이션 전략
  • CI/CD 파이프라인 설계

7. 보안 아키텍처 설계 (3-5일)

보안 요구사항 반영

  • 인증/인가 방식 설계
  • 데이터 암호화 전략
  • 네트워크 보안 및 방화벽 정책

8. 아키텍처 문서화 (1주)

문서 작성

  • 아키텍처 다이어그램 (C4 모델 활용)
  • ADR(Architecture Decision Record) 작성
  • 개발 가이드라인 및 코딩 표준 정의

9. 검토 및 승인 (3-5일)

아키텍처 리뷰

  • 기술팀, 보안팀, 인프라팀 검토
  • 이해관계자 승인
  • 피드백 반영 및 최종 확정

10. 프로토타입 및 PoC (1-2주)

검증 작업

  • 핵심 기술 스택 검증
  • 성능 테스트 및 부하 테스트
  • 리스크 요소 사전 검증

각 단계에서는 지속적인 피드백과 반복적 개선이 중요하며, 프로젝트 규모에 따라 일정을 조정하시면 됩니다.

'아키텍처(Airchitecture)' 카테고리의 다른 글

아키텍처 비기능 요소 - 상세  (2) 2025.06.30
아키텍처 비기능요소  (2) 2025.06.30

+ Recent posts