대규모 시스템 설계와
분산 아키텍처 완전 정복

A부터 Z까지 — 수천만 사용자를 견디는 서비스를 설계하는 법

# 가정
DAU = 3억 명
트윗 읽기 : 쓰기 = 100 : 1
사용자 1명이 하루 평균 트윗 1개 작성, 읽기 100개

# QPS 계산
쓰기 QPS = 3억 / 86400 ≈ 3,500 QPS
읽기 QPS = 3,500 × 100 = 350,000 QPS  # 피크는 2배 = 700,000 QPS

# 저장 용량 계산 (5년)
트윗 1개 용량 = 텍스트 300B + 메타데이터 200B = 500B
하루 새 트윗 = 3억 개
5년 총 트윗 = 3억 × 365 × 5 = 5,475억 개
5년 저장 공간 = 5,475억 × 500B ≈ 274 TB

# 미디어 저장 (트윗 중 10%가 이미지, 평균 1MB)
하루 미디어 = 3억 × 0.1 × 1MB = 30 TB/일
5년 미디어 = 30 × 365 × 5 ≈ 54 PB

# 결론: 어떤 아키텍처가 필요한가?
- DB 읽기 부하: 캐시(Redis) 필수
- 쓰기 부하: DB 파티셔닝/샤딩 필요
- 미디어: CDN + 분산 스토리지(S3)
- 팔로워 피드: 팬아웃 전략 필요

# CDN 캐시 전략 — Cache-Control 헤더

// NestJS에서 정적 파일 캐시 설정
@Get('image/:id')
@Header('Cache-Control', 'public, max-age=86400, s-maxage=604800')
// max-age=86400     → 브라우저 1일 캐시
// s-maxage=604800   → CDN 7일 캐시 (CDN 전용)
getImage(@Param('id') id: string) { ... }

// API 응답은 캐시하지 않음 (실시간 데이터)
@Header('Cache-Control', 'no-store')

// 버전 관리된 파일은 영구 캐시
// main.a3b4c5.js → 파일명에 해시 포함
@Header('Cache-Control', 'public, max-age=31536000, immutable')
// immutable → 만료 전 재검증 요청 안 함 (성능 최적화)

# Nginx 로드밸런서 설정 — 실전

upstream api_servers {
    # Least Connections 알고리즘
    least_conn;

    server api1.internal:3000 weight=3;  # 성능 좋은 서버 3배 더
    server api2.internal:3000 weight=2;
    server api3.internal:3000 weight=1;

    # 헬스체크: 3번 실패하면 제외, 10초마다 재시도
    server api4.internal:3000 backup;    # 나머지 다 죽으면 사용

    # Keep-Alive 커넥션 풀 (성능 최적화)
    keepalive 32;
}

server {
    listen 80;

    location /api/ {
        proxy_pass http://api_servers;
        proxy_http_version 1.1;
        proxy_set_header Connection "";       # keep-alive 활성화
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # 서버 장애 시 다른 서버로 자동 재시도
        proxy_next_upstream error timeout http_500 http_502 http_503;
        proxy_next_upstream_tries 3;

        # 타임아웃 설정
        proxy_connect_timeout 5s;
        proxy_read_timeout 30s;
    }
}

// TypeORM Read Replica 설정
TypeOrmModule.forRoot({
  type: 'postgres',
  replication: {
    master: {
      host: 'primary.db.internal',   // 쓰기 전용
      port: 5432,
      database: 'mydb',
      username: 'user',
      password: 'pass',
    },
    slaves: [
      { host: 'replica1.db.internal', port: 5432, database: 'mydb', username: 'user', password: 'pass' },
      { host: 'replica2.db.internal', port: 5432, database: 'mydb', username: 'user', password: 'pass' },
    ],
  },
  // TypeORM이 SELECT는 자동으로 replica에서 실행!
  // INSERT/UPDATE/DELETE는 master에서 실행
})

// 주의: 복제 지연(Replication Lag)!
// 쓰기 직후 읽기 시 최신 데이터가 없을 수 있음
// 해결: 방금 쓴 데이터는 Master에서 읽기 (강제 지정)
const masterEntityManager = dataSource.createEntityManager({ replication: { primary: true } });

// 샤딩 라우터 구현 예시
@Injectable()
export class ShardRouter {
  private shards: DataSource[];

  getShardForUser(userId: string): DataSource {
    // 일관된 해싱으로 샤드 결정
    const hash = this.consistentHash(userId);
    const shardIndex = hash % this.shards.length;
    return this.shards[shardIndex];
  }

  // ⚠️ 샤딩의 주요 문제점
  // 1. 크로스-샤드 JOIN 불가 → 앱 레벨에서 처리
  // 2. 샤드 추가 시 데이터 재분배 (리샤딩) 비용
  // 3. 분산 트랜잭션 매우 복잡
  // → 일관된 해싱으로 리샤딩 최소화
}

// NestJS + Kafka 이벤트 드리븐 구현

// 1. Producer — 주문 이벤트 발행
@Injectable()
export class OrderService {
  constructor(@Inject('KAFKA_CLIENT') private kafka: ClientKafka) {}

  async createOrder(dto: CreateOrderDto) {
    const order = await this.orderRepo.save(dto);

    // 이벤트 발행 (비동기, 다른 서비스가 처리)
    await this.kafka.emit('order.created', {
      orderId: order.id,
      userId: order.userId,
      items: order.items,
      totalAmount: order.totalAmount,
      createdAt: order.createdAt,
    });

    // 주문 서비스는 여기서 완료! 결제/알림/재고는 각 서비스가 처리
    return order;
  }
}

// 2. Consumer — 결제 서비스 (order.created 이벤트 소비)
@Controller()
export class PaymentConsumer {
  @MessagePattern('order.created')
  async handleOrderCreated(
    @Payload() data: OrderCreatedEvent,
    @Ctx() context: KafkaContext,
  ) {
    try {
      await this.paymentService.processPayment(data.orderId, data.totalAmount);
      context.getMessage().commit();  // 성공 시 오프셋 커밋
    } catch (err) {
      // 실패 시 DLQ(Dead Letter Queue)로 이동
      await this.kafka.emit('order.payment.failed', data);
    }
  }
}

// 3. 알림 서비스도 동일한 이벤트 구독 (서비스 간 결합도 없음!)
@MessagePattern('order.created')
async handleOrderCreated(data: OrderCreatedEvent) {
  await this.notificationService.sendOrderConfirmation(data.userId, data.orderId);
}

// NestJS Circuit Breaker 구현
// npm install opossum

@Injectable()
export class PaymentService {
  private breaker: CircuitBreaker;

  constructor(private httpService: HttpService) {
    // 서킷 브레이커 설정
    this.breaker = new CircuitBreaker(
      async (amount: number) => {
        return this.httpService.post('http://payment-service/pay', { amount }).toPromise();
      },
      {
        timeout: 3000,           // 3초 내 응답 없으면 실패
        errorThresholdPercentage: 50,  // 50% 실패율 시 OPEN
        resetTimeout: 30000,     // 30초 후 HALF-OPEN으로
        volumeThreshold: 10,     // 최소 10번 요청 후 판단
      }
    );

    // fallback: 서킷 OPEN 시 대안 응답
    this.breaker.fallback((amount: number) => ({
      success: false,
      message: '결제 서비스 일시 장애. 잠시 후 다시 시도해주세요.',
      retryAfter: 30,
    }));

    // 상태 변화 이벤트
    this.breaker.on('open', () => this.logger.warn('🔴 Circuit OPEN: payment-service'));
    this.breaker.on('halfOpen', () => this.logger.log('🟡 Circuit HALF-OPEN'));
    this.breaker.on('close', () => this.logger.log('🟢 Circuit CLOSED: 복구됨'));
  }

  async pay(amount: number) {
    return this.breaker.fire(amount);  // 자동으로 상태 관리
  }
}

# Kubernetes에서 서비스 디스커버리 — DNS 자동 등록
# Service 생성 시 자동으로 DNS 등록됨
# 서비스명.네임스페이스.svc.cluster.local

# 예시
payment-svc.production.svc.cluster.local:80
user-svc.production.svc.cluster.local:80

# NestJS에서 서비스 호출 (하드코딩 대신 DNS 사용)
// ❌ 하드코딩
http://10.0.1.45:3001/pay

// ✅ DNS 기반 (K8s 내부)
http://payment-svc/pay

// ✅ 환경변수로 관리
PAYMENT_SERVICE_URL=http://payment-svc
USER_SERVICE_URL=http://user-svc

// OpenTelemetry — 분산 추적 표준 (NestJS)
// npm install @opentelemetry/sdk-node @opentelemetry/auto-instrumentations-node

// tracing.ts — 앱 시작 전 초기화 필수
const sdk = new NodeSDK({
  serviceName: 'order-service',
  traceExporter: new OTLPTraceExporter({
    url: 'http://jaeger:4318/v1/traces',
  }),
  instrumentations: [
    getNodeAutoInstrumentations(),  // HTTP, Express, DB 자동 추적
  ],
});
sdk.start();

// Trace ID가 자동으로 모든 서비스로 전파됨
// 요청 헤더에 traceparent: 00-TRACE_ID-SPAN_ID-01 포함
//
// Jaeger UI에서 확인:
// api-gateway (10ms)
// └─ order-service (8ms)
// │  └─ DB query (5ms) ← 병목!
// └─ payment-service (3ms)

# PACELC = 네트워크 분할(Partition) 시: A vs C
#          정상(Else) 시: L(Latency) vs C(Consistency)

# 예시: 뱅킹 앱 (일관성 중시)
계좌 이체 API:
  → 쓰기: 모든 레플리카에 동기 복제 완료 후 응답
  → 지연 높음 (100ms+) but 항상 최신 데이터 보장

# 예시: SNS 좋아요 수 (가용성/지연 중시)
좋아요 카운트 API:
  → 쓰기: 하나만 쓰고 즉시 응답 (비동기 복제)
  → 지연 낮음 (10ms) but 잠시 다른 수가 보일 수 있음
  → Eventual Consistency (결국 일관성 달성)

# 결국 비즈니스 요구사항에 따라 결정!

# 요구사항
DAU: 5억 명
사진/동영상 업로드: 하루 1억 건
피드 읽기: 하루 50억 건 (쓰기:읽기 = 1:50)

# 핵심 기능
1. 사진/동영상 업로드
2. 팔로워 피드 (최근 게시글)
3. 좋아요, 댓글

# 아키텍처 결정

미디어 저장:
  사진 → S3 + CloudFront CDN
  이미지 리사이징 → Lambda (썸네일 자동 생성)
  형식: WEBP 변환 (JPEG 대비 30% 작음)

피드 생성 전략:
  팔로워 < 1만 명: Fan-out on Write
    → 게시 시 팔로워의 피드 테이블에 즉시 복사
    → 읽기 빠름, 쓰기 부하 높음
  팔로워 > 1만 명 (셀럽): Fan-out on Read
    → 피드 조회 시 팔로잉 목록 기반 조합
    → 쓰기 부하 없음, 읽기 복잡

데이터 모델:
  posts 테이블 (샤딩: user_id 기반)
  feeds 테이블 (Redis sorted set: 타임스탬프 score)
  users 테이블
  follows 테이블

캐싱:
  인기 계정 피드: Redis에 24시간 캐싱
  이미지 URL: CDN 캐싱 (7일)
  좋아요 수: Redis counter (Write-Behind)

# 핵심 설계 포인트

1. 동영상 업로드 플로우:
   클라이언트 → API Gateway
   → S3 원본 저장 (업로드 완료 이벤트)
   → Kafka: video.uploaded 이벤트 발행
   → 트랜스코딩 서비스 (비동기)
     → 다양한 해상도 생성 (240p/480p/720p/1080p/4K)
     → HLS 형식으로 변환 (스트리밍 최적화)
     → S3에 저장 → CloudFront CDN 배포
   → 메타데이터 DB (제목, 설명, 썸네일)
   → 검색 인덱싱 (ElasticSearch)

2. 동영상 스트리밍:
   HLS(HTTP Live Streaming) 사용
   → 동영상을 수 초 단위 청크(chunk)로 분할
   → 네트워크 속도에 따라 해상도 자동 변경
   → CDN에서 가장 가까운 엣지에서 서빙

3. 인기 동영상 최적화:
   상위 20% 인기 영상 = 80% 트래픽
   → 인기 영상: CDN에 더 많은 엣지 캐싱
   → 실시간 조회수: Redis 카운터 (배치로 DB 동기화)

4. 추천 시스템:
   협업 필터링 + 콘텐츠 기반 필터링 혼합
   → 사용자 시청 이력 → Kafka → 추천 엔진
   → 결과를 Redis에 캐싱 (1시간)