✅ 백엔드 시스템의 확장성(Scalability)을 높이기 위한 설계 방식은?

✅ 백엔드 시스템의 확장성(Scalability)을 높이기 위한 설계 방식은?

서비스가 잘 되면 트래픽은 반드시 늘어납니다.
그때가 문제죠. 서버가 버벅이기 시작하면 "우리 시스템 구조가 확장성에 적합한가?"를 고민하게 됩니다.

이번 글에서는 **확장성(Scalability)**의 의미부터
실무에서 적용할 수 있는 아키텍처 설계 방식까지,
직접 겪은 문제와 경험 위주로 정리해볼게요.

---

📌 1. 확장성이란?

서비스의 사용자 수나 데이터 처리량이 증가해도
성능 저하 없이 효율적으로 처리할 수 있는 능력을 의미합니다.

---

📌 2. 확장 방식의 두 가지 종류

확장 방식 설명

🧱 수직 확장 (Scale-up)	한 대의 서버 성능(CPU, RAM 등)을 높이는 방식
🧱 수평 확장 (Scale-out)	여러 대의 서버로 역할을 나누어 병렬 처리

→ 실무에서는 대부분 수평 확장을 전제로 시스템을 설계합니다.

---

📌 3. 확장 가능한 시스템 설계 전략

반응형

✅ 1. 무상태 아키텍처 (Stateless)

• 각 서버가 요청을 독립적으로 처리
• 로그인 세션, 상태 정보는 Redis나 DB 등 외부 저장소에 보관

📌 장점: 서버 추가/삭제 자유로움
❌ 단점: 외부 스토리지 의존도 증가

---

✅ 2. 마이크로서비스 아키텍처 (MSA)

• 기능 단위로 서비스를 나눠서 개발/배포
• 예: 회원 서비스 / 주문 서비스 / 결제 서비스 분리

📌 장점: 개별 확장 가능, 팀 분리 운영
❌ 단점: 초기 복잡도, 인터서비스 통신 부담

---

✅ 3. 메시지 큐 기반 비동기 처리

• RabbitMQ, Kafka 등을 활용
• 처리 시간이 오래 걸리는 작업은 큐에 넣고 비동기로 처리

예: 이메일 발송, 썸네일 생성, 영상 인코딩 등

📌 장점: 병목 제거, 처리 분산
❌ 단점: 큐 장애 시 처리 지연

---

✅ 4. 데이터베이스 샤딩 / 리플리케이션

• 샤딩(Sharding): 데이터를 여러 DB 서버에 나눠 저장
• 리플리케이션: 읽기 전용 DB를 복제하여 읽기 성능 향상

📌 장점: 고용량 데이터 처리
❌ 단점: 트랜잭션 처리 복잡

---

✅ 5. CDN(Content Delivery Network)

• 이미지, JS, CSS, 동영상 등 정적 리소스를 전 세계에 분산

📌 장점: 사용자 가까운 위치에서 빠르게 제공
❌ 단점: 캐시 무효화 전략 필요

---

📌 4. 실무 경험 공유

🧪 문제 상황

• 사용자 수 급증 → DB CPU 90% 이상
• 서버 응답 느림, 장애 빈번

✅ 해결 방식

1. NestJS 서버 무상태화 → ECS로 수평 확장
2. Redis 세션 저장소 도입
3. API 요청 로그 저장을 비동기화 (Kafka)
4. CloudFront CDN 적용으로 정적 리소스 최적화
5. DB 읽기 전용 리플리카 추가

📉 결과:

• 요청당 평균 응답 시간 60% 감소
• 장애 발생률 1/10 수준으로 감소

---

📌 5. 면접에서 이렇게 말하세요

백엔드 시스템의 확장성을 위해선 설계부터 무상태 구조와 수평 확장을 고려해야 한다고 생각합니다.
실무에선 ECS 기반 수평 확장, Redis 세션 저장, Kafka 큐 처리, DB 리플리케이션 등을 통해
트래픽 증가에 유연하게 대응했던 경험이 있습니다.

---

백엔드확장성,수평확장,무상태아키텍처,MSA,NestJS,Kafka,Redis,DB리플리케이션,CDN적용,면접질문

---