트래픽이 몰려도 멈추지 않는 서비스
웹서비스를 만들 땐, 대부분 단순한 구조로 시작합니다. 사용자는 많지 않고, 요청도 적기 때문에 서버 한 대, 데이터베이스 한 개로도 충분히 돌아갑니다. 하지만 서비스가 성장하면서 상황은 급격히 달라집니다. 사용자가 늘어나고, 동시에 접속하는 트래픽이 폭발적으로 증가하면서 기존 구조로는 감당이 되지 않습니다.
이 때 개발자들은 트래픽을 처리하기 위해 서비스를 확장을 고려합니다.
1. 수직적 확장 - 서버를 키우자
가장 먼저 떠오르는 방법은 기존 서버를 더 좋은 사양으로 바꾸는 것입니다. CPU 코어 수를 늘리고, 메모리를 더 추가하는 식입니다. 이를 수직적 확장(Vertical Scaling)이라 부릅니다.
이 방식은 간단하면서도 즉각적인 효과를 줍니다. 코드도 거의 건드릴 필요가 없기 때문에, 시간이 소요되지도 않습니다. 하지만 한계는 명확합니다. 아무리 좋은 사양이라도 물리적으로 한계는 존재하고, 무엇보다 가격이 너무 비쌉니다. 클라우드에서는 고사양 인스턴스일수록 비용이 가파르게 올라가기 때문입니다. 그리고 서버가 한 대 뿐이라면, 그 서버가 다운되는 순간 서비스도 같이 멈춰버립니다.
2. 수평적 확장 - 서버를 늘리자
그래서 수평적 확장이 등장했습니다. 하나의 서버에 의존하는 것이 아니라, 여러 대의 서버를 두고 트래픽을 나누는 전략입니다. 사용자 요청은 로드밸런서가 받아서 여러 서버로 분산시킵니다.
+-----------+
| Client |
+-----------+
|
+----v-----+
| Load |
| Balancer |
+----+-----+
| \
+----v--+ +--v----+
| App A | | App B |
+-------+ +-------+이 방식은 서버를 더 추가하여 트래픽을 분산시킬 수 있기 때문에 확장성이 매우 뛰어납니다.
하지만 여기에도 문제가 있습니다. 서버가 늘어날수록 서로 상태를 어떻게 공유할지, 데이터는 어디서 읽을지, 장애가 났을 때 어떤 서버가 대체할지 등 여러 문제가 따라옵니다.
수평 확장의 두 가지 전략: 복제, 분산
📍복제 (Replication): 똑같은 데이터를 여러 서버에 복사
복제는 데이터베이스에서 주로 쓰입니다. Master DB에 데이터를 쓰고, 읽기는 여러 Replica DB에서 처리하게 하는 방식이죠.
- 장점: 읽기 부하를 줄여 읽기 성능 향상, Master DB 장애시 Replica DB로 빠르게 대체 가능
- 단점: 데이터 일관성이 깨질 수 있음 (복제 지연), 쓰기 성능은 개선되지 않음
📍분산 (Sharding): 데이터를 나눠서 각 서버에 저장
예를 들어, 사용자 ID가 1~10000인 경우는 A서버, 10001~ 20000인 경우는 B서버에 저장하는 방식입니다.
- 장점: 읽기뿐 아니라 쓰기 성능도 확장 가능
- 단점: 노드가 추가될 때마다 리밸런싱과 라우팅을 다시 해주어야 해서 데이터 균형을 맞추기 어려움, 분산된 데이터를 함께 조회하기가 복잡함(RDB에서 JOIN 연산이 불가능함)
😥 수평 확장을 하면 확장성은 좋아지지만, 시스템의 복잡도는 급격히 증가합니다.
이벤트 기반 아키텍처 (Event Driven Architecture)
이런 복잡성과 병목을 줄일 수 있는 방법으로 이벤트 기반 아키텍처가 있습니다.
말 그대로, 어떤 일이 발생하면(이벤트), 그걸 중개 시스템에 던져 놓고, 필요한 다른 서비스들이 그것을 비동기적으로 받아서 처리하는 구조입니다. 이 구조는 단순히 호출 방식이 바뀌는 것을 넘어, 시스템의 결합도를 낮추고, 처리 흐름을 유연하게 만들며, 트래픽 급증에도 탄력적으로 대응할 수 있는 기반을 제공합니다.
✅ 이벤트 기반 아키텍처의 주요 장점
- 비동기 처리 구조 덕분에 요청량이 급증하더라도 병목 현상 없이 유연하게 확장 가능
- 서비스 간의 느슨한 결합(loose coupling) 구조로, 기능 변경이나 배포 시 영향도 최소화
- 장애 전파 최소화: 이벤트를 처리하는 서비스 하나가 실패해도 전체 서비스는 계속 동작
- 필요한 Consumer만 선택적으로 확장 가능 → 비용과 리소스 최적화
- 대용량 데이터의 실시간 처리에 적합, 기존 배치(Batch) 방식보다 더 빠른 반응 가능
물론 이벤트 기반 아키텍처는 이벤트 순서 보장이 까다롭고, 디버깅과 트레이싱이 어렵고, 메시지 유실 방지 처리, 에러 처리 전략 등 고려해야할 점이 많습니다. 하지만 대규모 트래픽, 빠른 반응성, 서비스 간 독립성이 중요한 요즘 서비스 시스템에 있어 중요한 전략입니다.