분산 백엔드 아키텍처를 구성하는 방법

다음 내용은 "가상 면접 사례로 배우는 대규모 시스템 설계 기초"에서 얻은 내용과 필자의 지식이 더해진 글입니다.

https://m.yes24.com/Goods/Detail/102819435

가상 면접 사례로 배우는 대규모 시스템 설계 기초 - 예스24

 

서비스가 커지고, 사용자가 늘어남에도 서버는 고가용성과 장애내성, 장애극복, 높은 성능을 유지해야 한다.

 

서버 스펙을 스케일업 하는 것은 한계가 있고, 단일 장애 포인트(SPOF) 문제도 있기 때문에 결국은 다중화를 통한 분산 시스템을 구축해야 한다.

 

이를 실현시키기 위한 백엔드 아키텍처를 점진적으로 개선해 나가는 방법에 대해 정리하고자 한다.

 

 

# 단일 서버

서버는 기본적으로 서버 어플리케이션(WAS, 이하 서버)과 데이터베이스로 이루어진다.

 

AWS 예로 들면 하나의 스프링 부트를 실행하는 EC2와 MySQL 서버인 RDS를 들 수 있다.

 

 

 

이러한 구조는 아주 기초적인 구조로, 작은 규모 프로젝트에서 처음 구조로 많이 차용한다.

 

수직적 확장(스케일 업)인 서버 인스턴스의 CPU, RAM 등을 업그레이드하는 방향으로도 성능 향상을 할 수 있지만, 이는 제한적이다.

 

추가로, 단일 서버와 단일 데이터베이스로 인한 SPOF (단일 장애지점) 문제를 갖고 있다.

 

처음 서비스를 출시하는 MVP 단계에서는 활성 유저가 적기 때문에, 이 정도 구조로도 충분히 유지 가능할 것이다.

 

# 다중 서버

SPOF 문제를 해결하기 위해선, 서버를 다중화하면 된다. 

 

 

서버를 2대로 수평적 확장(스케일아웃)을 했다.

 

이 구조부터 사용자의 요청 트래픽을 적절히 서버로 라우팅 해주기 위한 로드밸런서가 필요하다.

 

그림으로는 서버를 2대로 했지만, 자유롭게 새로운 서버 인스턴스를 추가하거나 제거할 수도 있는 유연한 구조가 되었다.

 

다중 서버 구조부터는 무중단 배포가 가능하다. 무중단 배포 방식은 롤링, 블루-그린, 카나리 등 다양하게 있는데 이를 활용할 수 있게 된다.

 

서비스를 운영함에 있어 로그/메트릭 수집, 모니터링은 필수인데 서버가 다중 구조로 되었으므로 각 인스턴스별로 관리하기보단, 중앙 집중화된 로그/메트릭 수집 방식을 도입해야 한다.

 

로그는 보통 ELK(Elasticsearch Logstash Kibana)를, 모니터링은 그라파나나 타노스를 사용한다.

 

장점

• 서버 SPOF 해결
• 서버 무중단 배포 가능

 

단점

• 로드밸런서 SPOF 문제
• 데이터베이스 SPOF 문제

이럴 때 고려해보기

하나의 서버로 유저의 트래픽을 처리 못하는 시그널 (ex. 인스턴스 자원 사용률이 너무 증가하는게 포착)을 발견하면 도입을 고려하자.

 

혹은 무중단 배포를 구현하고 싶다면 고려해보자.

 

# 데이터베이스, 로드밸런서 다중화

데이터베이스는 중요한 정보를 저장하는 컴포넌트이므로, SPOF를 반드시 극복해야 한다.

 

읽기 전용 데이터베이스인 Replica 서버와, 쓰기 전용 데이터베이스인 Master로 다중화를 한다.

 

이를 CQRS(Command and Query Responsibility Segregatio) 패턴이라고 한다.

 

Master-Replica는 데이터를 서로 동기화하며 데이터의 일관성을 유지해야 한다.

 

보통 데이터는 쓰기 연산보다 읽기 연산이 훨씬 많으므로, Master 서버의 스펙을 높은 수준으로 스케일업 하는 것도 방법일 것이다.

 

비슷하게, Replica 서버의 부하를 분산시키기 위해 여러 데이터베이스 서버들로 또 다중화를 할 수도 있다.

 

이를 샤딩이라고 한다.

 

 

Replica 서버와 로드밸런서에 다중화를 진행한 구조다.

 

장점

• 로드밸런서, 서버, 데이터베이스 SPOF 극복

 

서비스에 따라 다르겠지만, 여기서는 기본적으로 가장 많이 사용하는 RDBMS를 기준으로 설명했다.

 

만약 엄청나게 대용량 데이터를 아주 낮은 지연시간으로 읽고, 별도의 조인연산이 필요하지 않는다면 NoSQL 데이터베이스 도입을 고려해 보는 것도 좋은 생각일 것이다.

 

(ex. 채팅 내역 조회)

 

이 정도 구조가 되면, 높은 가용성을 유지할 수 있다. 

 

 

이럴 때 고려해보기

어느정도 서비스가 자리잡았고, 월간/일간 사용자도 유의미한 트래픽을 발생시키기 시작했다면 이러한 구조로 개선하는 것이 좋을 것이다.

 

# 캐시 적용

위와 같은 구조만 해도 서비스를 운영하는데 지장이 없지만, 사용자 트래픽이 증가함에 따라 응답시간을 좀 더 효율적으로 줄일 수 있는 방법이 있다.

 

정적인 데이터는 캐시 서버를 두어서 캐싱을 하고, 이를 참조하여 데이터베이스 질의를 하지 않도록 구성하는 것이다.

 

이미지나, 비디오 등 미디어 파일도 서버에서 관리하지 않고 CDN 서버를 통해서 가져오게끔 하면 부하를 줄이고 성능을 향상할 수 있다.

 

캐시 서버는 레디스를 많이 사용한다.

 

 

 

장점

• 데이터베이스 부하 분산
• 조회 성능 향상

 

이럴 때 고려해보기

높은 트래픽으로 데이터베이스 부하가 걸려 응답이 밀리기 시작한다면, 캐시 도입을 고려해보자

 

 

# MSA

서비스가 커짐에 따라서 서버는 많은 비즈니스 로직을 포함하게 된다.

 

코드 규모가 커질수록 수정하기 힘들고, 그 영향도를 파악하기 힘들기 때문에 도메인을 각기 다른 서버로 분리할 필요가 생긴다.

 

이를 MSA(Micro Service Architecture)라고 한다.

 

앞서 동일한 서버를 여럿 인스턴스로 나눈 스케일아웃 방식과는 조금 다름을 상기하자.

 

이러면 각 서비스 간의 결합도가 줄어들고, 장애가 전파되는 현상 (댓글이 작성 안되는데 회원가입이 되지 않는)을 격리시킬 수 있다.

 

그리고 각 마이크로 서비스 간의 결합도를 낮추고 비동기 통신을 위해 메시지 큐를 도입할 수 있다.

 

마이크로서비스를 관리하기 위한 솔루션으로 가장 대중적으로 사용되는 것은 도커와 쿠버네티스이고, 메시지큐는 카프카이다.

 

 

 

장점

• 도메인 간 결합도 감소
• 모든 구성 컴포넌트 SPOF 해결
• 장애 전파 격리

 

단점

• 각기 다른 도메인간 트랜잭션 처리 난이도 증가
• 구조적 복잡도 증가

 

# 데이터 센터 다중화

클라우드 환경이 아닌 경우, 위와 같은 구조 자체를 다중화하는 방법이 있다.

 

이를 데이터 센터 다중화라고 한다. 데이터 센터는 보통 서로 다른 물리적으로 위치한 곳에 위와 같은 인프라를 구축하고, 로드밸런서를 통해 지리적 라우팅을 수행한다.

 

 

이러면 하나의 데이터 센터가 사용 불능이 되어도 빠르게 다른 데이터 센터로 트래픽을 전환하면, 다운타임 없이 서비스를 운영할 수 있다.

 

보통 기업들은 Active-Standby 구조로 평시에는 하나의 데이터센터를 운영하다가 재난발생이 하면 다른 데이터센터를 활성화시킨다. 

 

은행과 같이 엄청난 고가용성을 필요로 하는 서비스는 Active-Active 구조를 채택하기도 한다.

 

장점

• 모든 장애 상황 극복 가능

 

단점

• 데이터 센터 유지 비용, Active-Standby일 경우 유휴 상태임

 

 

# 마무리

단일 서버로부터 시작해서, 모든 컴포넌트를 다중화한 분산 시스템까지 전반적으로 훑어보았다.

 

당연히 각 컴포넌트를 다중화 할 수록 안정성이 증가하는 것은 사실이지만, 관리 비용이 증가하기 때문에 현실적인 상황을 잘 고려해야 한다.

 

가령, 이제 막 MVP를 출시하여 유저 반응을 살피는 서비스에 데이터베이스 다중화와 로드밸런서 다중화는 오버 엔지니어링일 수 있다.

 

따라서 현재 내가 직면한 상황을 이해하고, 어떤 부분을 개선하면 좋을지를 알고 있는 것이 중요한 것 같다.