대규모 아키텍쳐 정리

728x90

수십만 명의 동시 사용자를 감당하는 대규모 플랫폼을 구축하는 것은 거대한 엔지니어링 도전입니다. 단순한 '서버 증설'만으로는 해결할 수 없으며, 각 기능의 특성에 맞는 전문적인 아키텍처가 필요합니다.

공통적으로는 **MSA(마이크로서비스 아키텍처)**를 기반으로, 각 기능을 독립적으로 개발, 배포, 확장할 수 있도록 설계하는 것이 기본입니다.

다음은 공통적으로 사용해야 할 핵심 아키텍처와 4가지 기능별 특화 아키텍처입니다.

🌍 공통 핵심 아키텍처 (플랫폼의 기반)

모든 서비스에 공통적으로 필요한, 대규모 트래픽을 지탱하는 기반 기술입니다.

마이크로서비스 아키텍처 (MSA)
- 스트리밍, 비디오, 커뮤니티, 이벤트 기능을 각각 별개의 작은 서비스로 분리합니다.
- 이점: 특정 기능(예: 이벤트 신청)에 트래픽이 몰려도 다른 서비스(예: 커뮤니티)에 영향을 주지 않습니다. 각 서비스에 맞는 기술 스택(예: 스트리밍은 C++, 커뮤니티는 Java/Kotlin)을 선택할 수 있고, 독립적인 스케일 아웃(서버 확장)이 가능합니다.
클라우드 네이티브 (Cloud Native)
- AWS, GCP, Azure 같은 클라우드 플랫폼 사용을 전제로 합니다. 수십만 명 규모의 인프라를 직접 구축하고 운영하는 것은 거의 불가능에 가깝습니다.
- 핵심: **오토 스케일링(Auto Scaling)**을 통해 트래픽에 따라 서버 수를 자동으로 늘리고 줄여 비용을 최적화하고, **로드 밸런서(Load Balancer)**로 트래픽을 여러 서버에 분산시킵니다.
CDN (Content Delivery Network)
- 필수 중의 필수입니다. 비디오, 이미지, 스트리밍 데이터 등 용량이 큰 콘텐츠를 사용자에게서 가장 가까운 CDN 서버(캐시 서버)에서 전송합니다.
- 이점: 본 서버(Origin Server)의 부하를 90% 이상 줄일 수 있으며, 사용자에게는 전 세계 어디서나 빠른 로딩 속도를 제공합니다.
캐시 (Cache)
- 자주 요청되는 데이터를 DB까지 가지 않고 메모리(e.g., Redis, Memcached)에서 바로 꺼내 줍니다.
- 이점: DB 부하를 획기적으로 줄이고 응답 속도를 수십 배 향상시킵니다. (예: 인기 커뮤니티 글, 사용자 세션 정보)
메시지 큐 (Message Queue)
- Kafka, RabbitMQ, AWS SQS 등이 있습니다. 서비스 간의 요청을 '줄 세우는' 역할을 합니다.
- 이점: 요청을 비동기적으로 처리하여 트래픽이 폭주할 때 시스템이 다운되는 것을 막아줍니다. (특히 '이벤트 신청' 기능에서 핵심입니다.)
다중 데이터베이스 전략 (Polyglot Persistence)
- 하나의 거대한 DB로 모든 것을 처리하지 않습니다.
- RDB (관계형, e.g., MySQL, PostgreSQL): 사용자 정보, 이벤트 정보 등 정형화되고 트랜잭션이 중요한 데이터. (Read Replica를 두어 읽기 성능 확장)
- NoSQL (비관계형, e.g., MongoDB, DynamoDB): 커뮤니티 글, 댓글, 채팅 메시지 등 대량의 비정형 데이터를 빠르고 유연하게 저장할 때 사용.

🚀 기능별 특화 아키텍처

각 기능은 요구하는 기술이 완전히 다릅니다.

1. 스트리밍 (Live Streaming)

라이브 스트리밍은 '초저지연'과 '대규모 동시 접속'이 핵심입니다.

프로토콜:
- 송출 (Ingest): 스트리머가 서버로 영상을 보낼 때 (e.g., RTMP)
- 배포 (Delivery): 서버가 시청자에게 영상을 배포할 때 (e.g., HLS, MPEG-DASH)
핵심 구성:
1. 미디어 서버 (Media Server): RTMP로 받은 고화질 원본 영상을 HLS/DASH 포맷으로 실시간 트랜스코딩(Transcoding)(1080p, 720p 등 여러 화질로 변환)합니다.
2. CDN 전송: 변환된 영상 조각(Chunk)들을 CDN으로 전송하여 전 세계 시청자에게 배포합니다.
3. 채팅 서버: 스트리밍 영상과 별개로, 웹소켓(WebSocket) 기반의 채팅 서버가 필요합니다. 수십만 개의 동시 연결을 유지해야 하므로 Redis Pub/Sub 등을 활용한 확장이 필요합니다.
추천: 직접 구축은 난이도가 극도로 높습니다. AWS IVS (Interactive Video Service)나 GCP Live Stream 같은 매니지드 서비스를 사용하는 것이 효율적입니다.

2. 비디오 (VOD - Video on Demand)

VOD는 '안정적인 저장'과 '빠른 전송'이 핵심입니다.

핵심 구성 (S3 + MediaConvert + CloudFront):
1. 업로드 및 저장: 사용자가 영상을 업로드하면 S3 (Object Storage) 같은 무한 확장이 가능한 스토리지에 원본을 저장합니다.
2. 트랜스코딩 (변환): S3에 업로드된 것을 트리거(Event)로, AWS MediaConvert 같은 서비스가 자동으로 영상을 여러 화질과 포맷(MP4, HLS)으로 변환하여 다시 S3에 저장합니다.
3. 배포: 사용자가 영상을 요청하면, **CDN (e.g., CloudFront)**을 통해 S3에 저장된 영상을 스트리밍합니다.
특징: 라이브 스트리밍과 달리 실시간성이 필요 없으므로, 업로드 시점에 미리 모든 변환을 끝내놓고 CDN에 캐시해 둡니다.

3. 커뮤니티 (게시판, 댓글, 채팅)

커뮤니티는 '읽기/쓰기 비율'과 '실시간 알림'이 중요합니다.

데이터베이스:
- 게시글/댓글: 쓰기 작업이 매우 빈번하고 데이터 구조가 유연해야 하므로 **NoSQL (e.g., DynamoDB, MongoDB)**이 유리합니다.
- 사용자 피드 (Feed): '내가 팔로우하는 사람들의 글 모아보기' 등은 복잡합니다. 글을 쓸 때마다 팔로워들의 피드 목록(주로 Redis에 저장)에 '밀어 넣어주는' Fan-out 방식이 효율적입니다.
캐시 활용: '오늘의 인기 글', '실시간 베스트' 등은 DB에서 매번 계산하지 않고, Redis 같은 캐시에서 집계하고 제공하여 DB 부하를 최소화합니다.
실시간 알림/채팅: '새 댓글 알림', '1:1 채팅' 등은 **웹소켓(WebSocket)**이나 **SSE(Server-Sent Events)**를 사용하여 서버가 클라이언트에게 실시간으로 데이터를 푸시(Push)해야 합니다.

4. 이벤트 신청 (티켓팅)

이벤트 신청은 '특정 시간 트래픽 폭주' (Thundering Herd Problem)를 해결하는 것이 전부입니다.

핵심 아키텍처: 메시지 큐 (대기열)
1. 요청 접수 (Web/API 서버): 사용자가 '신청' 버튼을 누르면, 서버는 복잡한 재고 확인 로직을 즉시 실행하지 않습니다.
2. 대기열 삽입: 대신 "신청 요청"을 **메시지 큐 (AWS SQS, Kafka)**에 일단 집어넣고, 사용자에게는 "신청 접수됨 (대기 중)" 화면을 즉시 보여줍니다.
3. 비동기 처리 (Worker): 별도의 워커(Worker) 서버들이 큐에 쌓인 요청을 DB가 감당할 수 있는 속도로 하나씩 꺼내어 처리합니다. (예: 1초에 1,000개씩)
4. 재고 관리: 실제 재고(티켓 수량)는 Redis의 Atomic Counter(원자적 연산)를 사용하거나 DB의 **비관적 락(Pessimistic Lock)**을 활용해 중복 신청을 방지합니다.
5. 결과 통보: 처리가 완료되면 웹소켓 등을 통해 사용자에게 '신청 성공' 또는 '실패(매진)'를 알려줍니다.
이점: 이 방식을 쓰면 10시에 50만 명이 동시에 '신청' 버튼을 눌러도 서버는 다운되지 않고, 모든 요청을 공정하게 줄 세워 순서대로 처리할 수 있습니다.

요약

공통: MSA, 클라우드, CDN, 캐시, 메시지 큐는 기본입니다.
스트리밍/비디오: CDN과 트랜스코딩이 핵심이며, 매니지드 서비스(AWS IVS, MediaConvert) 사용을 강력히 권장합니다.
커뮤니티: NoSQL과 Redis 캐시, 웹소켓을 활용해 읽기/쓰기 성능과 실시간성을 잡습니다.
이벤트 신청: **메시지 큐(SQS, Kafka)**를 이용한 비동기 처리(대기열)가 유일한 해결책입니다.

이러한 아키텍처를 조합하여 각 기능의 요구사항을 충족하는 확장 가능하고 안정적인 플랫폼을 구축할 수 있습니다.

🏛️ 대규모 플랫폼 아키텍처: 핵심 11가지 요약

수십만 명을 감당하는 서비스를 구축할 때 가장 중요한 11가지 핵심 개념입니다.

1부: 인프라 (Infra) - "어떻게 트래픽을 감당할 것인가?"

📈 1. 오토 스케일링 (Auto Scaling)

역할: 트래픽에 맞춰 서버 수를 자동으로 늘리고 줄이는 기술입니다.
개념: "손님이 몰리면 계산대(서버)를 늘리고, 빠지면 줄여서" 비용을 최적화하고 서비스 다운을 막습니다. (예: CPU 사용률 70% 넘으면 2대 추가)

🌍 2. CDN (Content Delivery Network)

역할: 이미지/비디오를 사용자 근처의 서버에 '복사'해 둡니다.
개념: 최초 1회만 원본 서버에서 콘텐츠를 가져가고, 이후 모든 요청은 CDN이 대신 응답합니다. (속도 향상, 원본 서버 보호)

2부: 데이터베이스 (Database) - "어떻게 데이터를 저장하고 관리할 것인가?"

🗂️ 3. 리드 레플리카 (Read Replica)

역할: 원본(Master) DB를 실시간 복제한 '읽기 전용' DB입니다.
개념: '읽기' 요청을 복제본으로 분산시켜, 원본 DB는 '쓰기' 작업에만 집중할 수 있게 합니다.

🚀 4. NoSQL vs. 🗄️ RDBMS

RDBMS (관계형): 정해진 '표(Schema)'에 맞춰 저장합니다. (예: MySQL)
NoSQL (비관계형): 형식이 유연하고(JSON처럼), 수평 확장이 쉬워 대용량/비정형 데이터(예: 커뮤니티 글)에 유리합니다. (예: MongoDB)

🔒 5. 원자적 연산 (Atomic Operation)

역할: "쪼갤 수 없는 하나의 작업 단위"입니다.
개념: 여러 요청이 동시에 몰려도 '락(Lock)' 없이 데이터의 정합성을 보장합니다. (예: Redis의 INCR - '좋아요' 동시 클릭 시 순서대로 +1 처리)

🔐 6. 비관적 락 (Pessimistic Lock)

역할: 데이터 충돌을 막기 위해 "일단 잠그고" 보는 방식입니다.
개념: "내가 쓸 동안 아무도 쓰지 마"라고 선언합니다. (예: DB의 FOR UPDATE - 티켓 재고를 수정할 때 다른 사람이 접근 못 하게 막음)

3부: 메시징 & 비동기 (Messaging) - "어떻게 요청을 안정적으로 처리할 것인가?"

📻 7. 레디스 펍/섭 (Redis Pub/Sub)

역할: '발행(Pub)/구독(Sub)' 모델로 실시간 메시지를 전달합니다.
개념: 특정 '채널'을 구독한 모든 사람에게 메시지를 즉시 발행(전송)합니다. (예: 실시간 채팅방, 전체 공지사항)

📬 8. SQS vs. 🚂 Kafka

SQS (대기열): "단순 작업 요청서"입니다. 1:1 처리에 적합하고, 처리 후 메시지가 삭제됩니다. (예: 이벤트 신청 접수)
Kafka (스트림): "데이터 컨베이어 벨트"입니다. 1:N 처리가 가능하고, 데이터가 보관되어 여러 번 읽을 수 있습니다. (예: 로그 수집)

⚙️ 9. 별도의 워커 (Worker)

역할: 메시지 큐(SQS 등)에서 작업을 꺼내 '실제로 처리'하는 배경 서버입니다.
개념: API 서버는 "접수 완료!"(빠른 응답)만 하고, 오래 걸리는 실제 일(예: 당첨 처리)은 워커가 뒤에서 처리합니다.

4부: 애플리케이션 (Application) - "어떻게 기능을 구현할 것인가?"

📹 10. RTMP (Real-Time Messaging Protocol)

역할: 스트리머가 방송 서버로 영상을 '송출(업로드)'할 때 쓰는 전용 규약입니다.
개념: (스트리머 PC) ➡️ (RTMP) ➡️ (플랫폼 미디어 서버)

🌬️ 11. 팬아웃 (Fan-out)

역할: '읽기' 속도를 극도로 높이기 위한 데이터 전파 방식입니다.
개념: 글을 '쓸 때' 미리 팔로워들의 피드 목록에 '복사'해둡니다. 사용자는 계산 과정 없이 이미 완성된 피드를 읽기만 하면 됩니다. (예: 트위터 피드)

저작자표시 (새창열림)

Jonghyun