✅ 압박면접 대응 시리즈 31편: 백엔드 시스템 확장성(Scalability) 설계 — 수평 확장, 메시징 큐, 분산 캐시

✅ 압박면접 대응 시리즈 31편: 백엔드 시스템 확장성(Scalability) 설계 — 수평 확장, 메시징 큐, 분산 캐시

압박면접에서 “시스템 확장은 어떻게 하셨나요?”라는 질문은
단순히 “서버를 더 늘립니다”가 아닌,

“이 지원자는 트래픽 급증 상황을 예측하고, 아키텍처적으로 대비할 줄 아는가?”
“시스템이 커져도 성능과 안정성을 유지할 수 있는 설계 능력이 있는가?”
를 평가하는 질문입니다.

이번 글에서는 확장성(Scalability)의 개념, 수직/수평 확장 전략,
그리고 큐, 캐시, 비동기 구조를 이용한 실무 확장 설계 사례를 다룹니다.

---

📌 1. 확장성(Scalability)이란?

시스템의 처리량을 늘릴 때, 성능 저하 없이 확장 가능한 능력

유형 설명 예시

수직 확장 (Vertical Scaling)	한 서버의 성능을 높임	CPU/RAM 업그레이드
수평 확장 (Horizontal Scaling)	서버를 여러 대로 나눠 부하 분산	서버 클러스터링, 로드밸런싱

📌 핵심 포인트:

“수직 확장은 한계가 있고, 수평 확장은 관리가 복잡하다.”

---

📌 2. 확장성의 핵심 3요소

요소 목적 기술 예시

로드밸런싱	요청 분산	Nginx, HAProxy, AWS ELB
비동기 처리	작업 분리로 부하 완화	Redis Queue, RabbitMQ
분산 캐시	데이터 조회 부하 감소	Redis Cluster, Memcached

---

📌 3. 수평 확장 설계 구조

반응형

graph TD
A[Client] --> LB[Load Balancer]
LB --> S1[Server 1]
LB --> S2[Server 2]
LB --> S3[Server 3]
S1 --> DB[(Database)]
S2 --> DB
S3 --> DB

• 트래픽은 LB를 통해 여러 서버에 분산
• Stateless 구조를 유지해야 수평 확장이 가능

📌 면접 포인트:

“세션을 서버가 아닌 Redis에 저장하여 무상태(Stateless) 아키텍처를 유지했습니다.”

---

📌 4. 비동기 처리 (Message Queue)

✅ 왜 필요한가?

동기 처리로는 순간적인 트래픽 폭주를 감당할 수 없기 때문

✅ 구조

graph LR
A[API Server] --> Q[Queue (Redis / RabbitMQ)]
Q --> W[Worker]
W --> DB[(Database)]

• Producer: API 서버가 메시지를 큐에 넣음
• Consumer(Worker): 큐에서 메시지를 꺼내 비동기 처리

✅ 예시 (Bull Queue)

import Queue from "bull";

const emailQueue = new Queue("email", "redis://localhost:6379");

emailQueue.add({ to: "user@test.com", subject: "Welcome!" });

emailQueue.process(async (job) => {
  await sendEmail(job.data);
});

📌 면접 포인트:

“이메일 발송, 로그 기록, 이미지 리사이징 등 비실시간 처리를 Bull Queue로 분리했습니다.”

---

📌 5. 분산 캐시(Distributed Cache)

• 여러 서버가 동일 캐시를 공유 → DB 부하 최소화
• Redis Cluster, Memcached로 구성

const redis = new Redis.Cluster([
  { host: "redis-node1", port: 6379 },
  { host: "redis-node2", port: 6379 },
]);

📌 면접 포인트:

“Redis Cluster로 캐시를 분산 구성해 장애시 자동 Failover를 구현했습니다.”

---

📌 6. 데이터베이스 확장 전략

전략 설명 예시

Read Replica	읽기 전용 DB를 분리	PostgreSQL Replication
Sharding	데이터를 기준별로 나누기	User ID 해시 기반 분할
Connection Pooling	DB 연결 재사용	Prisma / TypeORM Pool

📌 핵심 문장:

“읽기 부하가 많을 땐 Replica, 데이터가 많을 땐 Sharding이 답입니다.”

---

📌 7. 실무 적용 사례

상황:
이벤트 트래픽 급증 시 API 응답 지연(3초 이상), DB 커넥션 오류 다발

해결 과정:

1. Bull Queue로 비동기 메시징 구조 도입
2. Redis Cluster로 캐시 분산
3. Nginx L7 Load Balancer로 요청 분산
4. PostgreSQL Read Replica 구성

📈 결과:

• 최대 처리량 3배 증가 (RPS 4,000 → 12,500)
• DB 부하 60% 감소
• 장애 발생률 0.2% 미만

---

📌 8. 압박면접 예상 질문 & 답변 포인트

• ❓ Q. Scale up과 Scale out의 차이는?
  → “Scale up은 서버 성능 향상, Scale out은 서버 개수 확장입니다.”
• ❓ Q. 메시지 큐가 필요한 이유는?
  → “사용자 응답을 빠르게 반환하고, 비실시간 작업을 분리하기 위함입니다.”
• ❓ Q. 분산 캐시 장애 시 대처 방법은?
  → “캐시 미스 시 DB fallback, 장애 감지 후 자동 재시작 스크립트를 구성했습니다.”
• ❓ Q. 확장 가능한 구조의 핵심은 무엇이라 생각하나요?
  → “Stateless 아키텍처 + 비동기 처리 + 분산 캐시의 조합입니다.”

---

📌 9. 면접에서 활용할 한 줄 정리

“트래픽 급증 상황에서도 안정적인 확장을 위해
Stateless 구조, Bull Queue 비동기 처리, Redis Cluster 분산 캐시를 도입했습니다.
결과적으로 처리량을 3배 향상시키고 DB 부하를 60% 줄였습니다.”

---

압박면접,확장성,Scalability,RedisCluster,BullQueue,비동기처리,Sharding,로드밸런싱,DevOps,MSA

---