Scalable Distributed Systems 구축 사례 정리

이번 SI 프로젝트에서 관련 서비스를 Distributed and Scalable Systems으로 설계 후 구축을 진행했다.

나는 TA 역할로 참여했으며, Distributed and Scalable Systems을 구성하고 아키텍처를 설계 하는데 있어 여러 요소들을 고려해야 했다.

 

관련 이야기를 하자면 아래와 같다.

프로젝트 수행 이야기

프로젝트 초기 단계에서 나는 시스템의 Scalability(확장성)를 최우선으로 고려했다.

일단 이전의 AS-IS기반의 사용자를 대비하여 시스템 확장을 고려하면 되지 않을까 하였지만 이번 프로젝트는 여러개의 시스템을 하나의 시스템으로 통합시키는거라 Scalability를 어느정도로 잡아야 할지 고민이 되었다. 그나마 다행인건 EKS의 pod로 올라가고 Fargate 형태로 운영되는거라 그나마 다행이었다.

 

일단, 서비스는 많거나 적은 사용자 요청을 처리해야 하므로, 수평적 확장(서버 추가)과 수직적 확장(서버 성능 향상)을 통해 시스템이 증가하는 부하를 처리할 수 있도록 설계했다. 그리고 수축적인 면도 고려하여 사용자가 없을때에는 자동적으로 수축 되도록 설계 했다.

 

다음으로, Fault Tolerance(결함 내성)를 확보하기 위해 데이터 복제와 자동 복구 메커니즘을 도입했다.

이는 시스템의 일부 구성 요소가 실패하더라도 서비스가 중단되지 않도록 보장했다.

예를들어 멀티 AZ에 관련 서비스를 배포 해놓으면 1개의 AZ가 장애가 나더라도 충분히 다른 AZ를 통해서 서비스가 가능하도록 구현 했다. 보통 흔히 말하는 HA 고가용성을 확바하여 설계가 되었다. 그리고 기본으로 2개의 pod가 각각의 AZ에 배포되도록 설계 했다.

 

Consistency(일관성)는 분산 시스템에서 매우 중요한 요소이다.

나는 흔히 CAP 이론에 따라 일관성, 가용성, 파티션 허용성 간의 균형을 맞추기 위한 구성을 진행 했다. 보통 AWS는 RDS로 구성이 되니, 자동적으로 일관성을 확보 할수 있다. 메인 DB가 여러개로 나눠진게 아니고 단일 RDS였고 그리고 Aurora로 구성되어 있었고 RW,RO로 나눠져 있었으며 클러스터로 구성 되어 있었다. (괜히 Managed 서비스가 아닌거 같다...)

 

Latency(지연시간)를 줄이기 위해 캐싱 전략을 사용하여 응답 시간을 최소화했다. 여기서 캐싱은 Elasticache를 활용하여 키:밸류 형태의 저장방법을 적용 하였다. 일부 데이터는 Elasticache에 저장하여 빠른 응답성을 보장했다. (예를들어 세션 정보 등...)

 

Load Balancing(부하분산)은 부하를 여러 서버에 고르게 분산시키기 위해 로드 밸런서를 사용했다. 이를 통해 시스템의 성능을 최적화하고, 특정 서버에 부하가 집중되는 것을 방지했다. (TCP/IP는 NLB, HTTPS는 ALB로...)

 

Security(보안) 측면에서는 데이터와 시스템을 보호하기 위한 다양한 보안 메커니즘을 도입했다.

인증, 권한 부여, 데이터 암호화 등을 통해 시스템의 보안을 강화했다. 여기서는 인프라의 보안과 애플리케이션의 보안등 여러 단계에서의 보안 요소가 적용 되었다. (대표적으로 네트워크 구성의 예를 들어보면 Private Subnet 환경에 리소스를 배치하도록 구성하고 ALB나 NLB로와 NAT를 통해 IGW로 데이터를 송 수신 한다던지...)

 

Monitoring and Logging(모니터링 및 로깅)은 시스템 상태를 모니터링하고 로그를 기록하여 문제를 신속하게 감지하고 해결할 수 있도록 했다.

보통 로그는 클라우드와치와 애플리케이션에서 발생하는 로그를 확인 하였으며, 애플리 케이션에서 발생하는 로그를 Datadog에서 중앙 집중식으로 처리 가능하도록 Datadog Agent를 Sidecar Pattern으로 pod에 구현 되었다.

 

마지막으로, Data Management(데이터 관리)를 위해 데이터 저장소 선택, 데이터 분할, 데이터 복제 등을 고려해야 했다. 

AWS의 RDS를 사용하면 데이터 저장소, 데이터 분할, 데이터 복제등을 별도로 고려하지 않아도 되어 관리 포인트를 줄일수 있다.

심지어 클러스터로 구성이 가능하고 RW, RO형태로 나눌수 있어서 매우 효율적이라 생각 한다.

 

이러한 요소들을 종합적으로 고려하여 시스템을 설계하고 구현함으로써, 안정적이고 확장 가능한  서비스를 구성 할 수 있었다.

 

구성을 생각나는대로 적어서 빠진 부분도 있을것이고 이 구성이 다 맞다고 볼수 는 없겠으나 대부분의 요소가 적용이 되었고 복잡 할 수도 있는 요소를 하나하나씩 확인하며 구성하였다.

설계는 처음에 잘해야지 나중에 바꾸면 너무 큰 손실이 발생 하므로 처음 설계할때 시간이 걸리더라도 잘 ~ 하는게 매우 중요하다고 다시한번 느끼고 생각한 시간이었다.

 

- 끝 -