[가상면접 사례로 배우는 대규모 시스템 설계 기초2] 8장.분산 이메일 서비스

지메일, 아웃룩 또는 야후 메일같은 대규모 분산 이메일 서비스 설계

 

1단계 : 문제 이해 및 설계 범위 확정

---

기능 요구사항

• 이메일 발송/수신 + 첨부파일
  • SMTP, POP, IMAP 등의 프로토콜과 서비스 제공자 전용 프로토콜 사용
• 모든 이메일 가져오기
• 읽음 여부에 따른 이메일 필터링
• 제목, 발신인, 메일 내용에 따른 검색 기능
• 스팸 및 바이러스 방지 기능 

 

개략적인 규모 측정

• 10억 명의 사용자
• 한 사람이 하루에 보내는 이메일 수는 10건, 이메일 전송 QPS = 10의 9승 * 10 / 10의 5승 = 100,000 이다. 
• 한 사람이 하루에 수신하는 이메일 수는 평균 40건, 하나의 메타데이터는 50MB라고 가정 (이때 첨부파일은 미포함)
• 메타데이터는 데이터베이스에 저장한다고 가정. 1년간 10억명 사용자 * 하루 40건 이메일 * 365 * 50KB = 730PB
• 첨부파일 포함하는 이메일의 비율은 20프로이며, 첨부파일 평균 크기는 500KB라고 가정, 1년간 저장 용량은 10억명 사용자 * 하루 40개 이메일 * 365일 * 20% * 500KB = 1,460PB

 

2단계 : 개략적 설계안 제시 및 동의 구하기

---

이메일101

이메일 프로토콜

1. SMTP (Simple Mail Transfer Protocol)

• 역할: 메일을 보낼 때 사용하는 프로토콜
• 흐름:
  클라이언트(메일 앱) → 메일 서버 → 상대방 메일 서버
• 특징:
  • 발신 전용
  • POP/IMAP과 함께 사용됨 (SMTP만으로는 수신 불가)
• 대표 포트: 25, 465(SSL), 587(TLS)

---

2. POP (Post Office Protocol)

• 역할: 메일을 받을 때 사용하는 프로토콜
• 흐름:
  메일 서버 → 클라이언트(PC/앱)
• 특징:
  • 기본적으로 서버에서 메일을 내려받으면 서버에는 삭제됨
  • 단일 기기 사용에 적합
  • 설정에 따라 “서버에 복사본 남기기” 가능
• 대표 포트: 110, 995(SSL)

---

3. IMAP (Internet Message Access Protocol)

• 역할: 메일을 받고 동기화할 때 사용하는 프로토콜
• 흐름:
  메일 서버 ↔ 클라이언트(PC/앱/모바일)
• 특징:
  • 메일이 서버에 남아 있음
  • 여러 기기에서 같은 메일함을 동기화
  • 읽음/삭제/폴더 이동 등의 상태가 모든 기기에 반영됨
• 대표 포트: 143, 993(SSL)

 

도메인 이름 서비스 (DNS)

메일 전송 과정과 DNS의 역할

1. 내가 메일을 보냄 → 메일 클라이언트가 SMTP 서버에 전달
2. SMTP 서버는 수신자 주소(user@example.com)에서 도메인 부분(example.com) 을 확인
3. 그 도메인을 DNS에 조회해서, 메일 서버(MX 레코드) 를 찾음
4. DNS 응답으로 받은 MX 서버 주소(IP)를 통해 실제 수신 서버와 연결
5. 그 후 메일이 상대 서버에 전달됨

 

첨부파일 

MIME (Multipurpose Internet Mail Extensions)

• 핵심 기술: 첨부파일은 사실 메일 본문 안에 포함된 텍스트 데이터임
• MIME은 텍스트가 아닌 데이터를 이메일로 전송할 수 있도록 만든 확장 규약
• 첨부파일을 → Base64 인코딩 → 문자 데이터로 변환 → 메일 본문에 삽

 

 

전통적 메일 서버

전통적 메일 서버 아키텍쳐 

저장소 

• 전통적 메일 서버는 이메일을 파일 시스템의 디렉터리에 저장한다. 
• 파일과 디렉터리를 활용하는 방안은 사용자가 많지 않을 때는 잘 동작하나 수십억 개의 이메일을 검색하고 백업하는 목적으로 확용하기에는 어려웠다 
• 이메일 양 많아지면 디스크 I/O 병목 발생하거나 서버의 파일 시스템에 보관해서 가용성과 안전성 요구사항도 만족할 수 없었다. 

 

 

분산 메일 서버

분산 메일 서버 아키텍쳐  

• 웹서버 
  • 사용자가 이용하는 요청/응답 서비스
• 실시간 서버
  • 새로운 이메일 내역을 클라이언트에 실시간으로 전달하는 상태 유지 (stateful) 서버 
  • 실시간 통신 지원 방식으로 롱 폴링(long polling)이나 웹소켓(websocket)등이 있다. 
• 메타데이터 데이터베이스
  • 이메일 제목, 본문, 발신인, 수신인 목록 등의 메타데이터 저장하는 데이터베이스
• 첨부 파일 저장소 
  • 아마존 S3 같은 객체 저장소 사용 
  • 카산드라 같은 컬럼 기반 데이터베이스는 적합하지 않다. 
    • 카산드라가 BLOB 자료형 지원 (최대 2GB) 하지만, 실질적으로 1MB 이상의 파일을 지원하지 못한다. 
    • 첨부 파일 저장하면 레코드 캐시를 사용하기 어렵다. 첨부 파일이 너무 많은 메모리를 잡아먹을 것이기 때문이다. 
• 분산 캐시
  • 최근에  수신된 이메일은 자주 읽을 가능성이 높으므로 클라이언트로 하여금 메모리에 캐시해 두면 시간을 많이 줄일 수 있다. 
• 검색 저장소
  • 고속 테스트 검색을 지원하는 역 인덱스를 자료구조로 사용한다. 

 

이메일 전송 절차 

 

이메일 수신 절차

3단계 : 상세 설계 

---

메타데이터 데이터베이스 

이메일 메타데이터의 특징

• 이메일의 헤더는 일반적으로 작고, 빈번하게 이용된다.
• 이메일 본문의 크기는 작은 것부터 큰 것 까지 다양하지만 사용 빈도는 낮다. 일반적으로 사용자는 한 번만 읽는다.
• 이메일 가져오기, 읽은 메일로 표시 검색 등의 이메일 관력 작업은 사용자 별로 격리 수행되어야 한다. 
• 데이터의 신선도는 데이터 사용 패턴에 영향을 미친다. 사용자는 보통 최근 메일만 읽고, 만들어진 지 16일 이하 데이터에 발생하는 읽기 질의 비율은 전체 질의의 82%에 달한다. 
• 데이터의 높은 안정성이 보당되어야 한다. 

올바른 데이터베이스의 선정

• 다음 조건을 충족해야 한다. 
  • 어떤 단일 컬럼의 크기는 한 자릿수 MB 정도일 수 있다. 
  • 강력한 데이터 일관성이 보장되어야 한다. 
  • 디스크 I/O가 최소화되도록 설계되어야 한다. 
  • 가용성이 아주 높아야 하고 일부 장애를 감내할 수 있어야 한다. 
  • 증분 백업이 쉬워야 한다. 
• 관계형 데이터베이스 : 
  • (장점) 이메일을 효율적으로 검색할 수 있다. 
  • (단점) 데이터 크기가 작을 때 적합하다. 
  • (단점) BLOB 자료형을 쓰더라도 해당 컬럼의 데이터를 접근할 때마다 많은 디스크 I/O가 발생한다. 
• 분산 객체 저장소
  • 이메일 원시 데이터를 그대로 아마존 S3같은 객체 저장소에 보관하는 것이다. 
  • 객체 저장소는 백업 데이터를 보관하기에는 좋지만 검색/이메일 타래 등의 기능을 구현하기에는 적합하지 않다. 
• NoSQL 데이터베이스
  • 지메일은 구글 빅테이블을 저장소로 사용한다. 
  • 하지만 빅테이블은 오픈 소스로 공개되어 있지 않고, 이메일 검색을 빅테이블 위에서 어떻게 구현했는지가 알려져 있지 않다. 
  • 카산드라도 대형 이메일 서비스 제공 업체에서 사용한 곳이 없다. 

 

일관성 문제 

• 높은 가용성 달성하기 위해 다중화에 의존한다. 그래서 사이에 타협적인 결정을 내려야 한다. 
• 이메일 시스템의 경우, 데이터의 정확성이 아주 종요하므로, 모든 메일함은 반드시 하나의 주 사본을 통해 서비스된다고 가정해야 한다. 
• 장애가 발생하면 클라이언트는 다른 사본을 통해 주 사본이 복원될때까지 동기화/갱신 작업을 완료할 수 없다. 
• 데이터 일관성을 위해 가용성을 희생한다. 

 

검색

방안1) 엘라스틱서치

방안2) 맞춤형 검색 솔루션 

• 메일 저장소에 추가되는 메타 데이터와 첨부 파일의 양은 페타바이트 수준이다. 
• 이메일 색인 서버의 주된 병목은 보통 디스크 I/O이다. 
• 색인을 구축하는 프로세스는 다량의 쓰기 연산을 발생시키므로 LSM(Long-Structured Merge) 트리 사용해 디스크에 저장되는 색인을 구조화하는 전략을 사용한다. 

 

* LSM(Log-Structured Merge) 트리로 색인 구조화

LSM 트리는 “쓰기 먼저, 나중에 정리”하는 철학이다. 이메일처럼 지속적인 대량 쓰기가 있는 워크로드에 적합하다.

• WAL(Write-Ahead Log): 먼저 로그에 순차 기록 → 내구성 확보
• MemTable → SSTable: 메모리에서 정렬 구조로 유지 후 배경에서 순차 Flush
• Compaction: 오래된 SSTable을 병합/정리하여 읽기 성능과 공간 효율 개선
• Bloom Filter: 불필요한 디스크 조회 차단 → 랜덤 읽기 감소
• Tiered Compaction: 최근 데이터는 빠르게, 장기 데이터는 느슨하게 병합 → I/O 평탄화

 

4단계 : 마무리

• 결함 내성 (fault tolerance)
  • 시스템의 많은 부분에 장애가 발생할 수 있다
  • 노드 장애, 네트워크 문제, 이벤트 전달 지연 등의 문제 대처할지 살펴본다.
• 규정 준수 (compliance)
  • 전 세계 다양한 시스템과 연동해야 하고, 각 나라에는 준수해야 할 법규가 있다. 
• 보안 (security)
  • 민감한 정보가 포함되어 피싱 방지, 안전 브라우싱, 사전 경고 등의 기능을 제공해야 한다. 
• 최적화 (optimization)
  • 같은 이메일이 여러 수신자에게 전송되기 때문에 똑같은 첨부 파일이 그룹 이메일 객체 저장소에 여러번 저장되는 경우가 있다. 

 

 

 

이메일 시스템, 분산 시스템, 지메일 아키텍처, SMTP, IMAP, DNS MX 레코드, MIME, 첨부파일 처리, 엘라스틱서치, LSM 트리, 이메일 검색, 고가용성, 보안 이메일, 시스템 최적화