시스템 아키텍처 기초

대규모 시스템 서버 인프라 기초

1. Scale Out

단일 서버의 성능을 향상시키는 수직 확장으로는 한계가 있다.(scale up)

서버를 추가하는 수평 확장을 통해 여러 서버를 동시에 실행하여 처리를 분산할 수 있다. (scale out)

트래픽을 라우팅 및 분산하기 위한 도구로 Load Balancer를 활용할 수 있다.

Scale-Out은 Load Balancer, Database에 대해서도 처리될 수 있다. Database의 분산을 위한 Sharding, Replication 등의 기법은 추후 살펴본다.

2. Cache

서버가 Client의 요청을 처리하는 과정이 복잡해질 수록 응답은 느려질 수 있다.

더 빠른 성능을 위해 Cache를 도입할 수 있다.(더 빠른 저장소에 데이터를 저장해두고 접근)

Cache도 필요하다면 Scale-Out을 적용하여 단일 서버의 부하를 줄일 수 있다.

 

이러한 캐시는 각 구간마다 적절히 적용될 수 있다.

• 브라우저에서 자체적인 캐시 활용
• DNS 쿼리 결과를 캐시
• 데이터베이스보다 더 빠르게 데이터에 접근하기 위한 캐시
• CDN 기술

3. 다중화

네트워크는 안전하지 않기 때문에 언제든 순단 가능성이 있고, 서버와 데이터는 시스템 오류 및 자연 재해 등으로 언제든 중단 및 유실될 수 있다. 또, 지리적으로 서버와 멀리 떨어져있다면, 응답 시간에 큰 지연이 생길 수 있다.

서버가 설치된 데이터 센터 다중화

이러한 문제를 방지하기 위해, 서버를 지리적으로 여러 장소에 구성할 수도 있다.

분산된 각 서버에 대한 client의 라우팅을 위해 DNS를 활용할 수도 있고, 더욱 정밀하고 복잡한 라우팅이 필요한 경우 GSLB 등 다양한 방법을 활용할 수도 있다.

4. 기능별 애플리케이션 분리 (feat. API/Message)

단일 서버가 처리해야할 트래픽이 너무 많아지면, 리소스가 부족할 수도 있고,

시스템이 커질수록 애플리케이션의 유지보수가 어려워질 수 있다.

따라서 단일 애플리케이션을 기능에 맞는 여러 개의 애플리케이션으로 분리하여 관리할 수 있다.

각 애플리케이션은 담당한 기능에 대해 개별 작업만 처리할 수 있는 것이다.

예를 들면, A 애플리케이션은 게시글 기능만, B 애플리케이션은 댓글 기능만 처리한다. 필요하다면 DB도 각 기능별로 분리 구성할 수 있다.

 

분리된 웹 애플리케이션이 하나의 서비스를 이루려면, 서로 네트워크 통신이 필요할 수 있다.

API를 통해 직접적으로 통신할 수 있지만, 메시지(이벤트)를 통해 간접적으로 통신할 수도 있다.

 

---

시스템 아키텍처

시스템의 구조나 설계 방식을 말하는 것으로, 확장성, 유지보수성, 성능 드엥 큰 영향을 준다.

 

대표적인 아키텍처로는 Monolithic Architecture, Microservice Architecture가 있다.

Monolithic Architecture

모든 기능이 단일의(Monolithic) 코드베이스로 결합된 아키텍처.

소규모 시스템에서 개발 및 배포가 간단하기 때문에 많이 선택한다.

단점

1. 특정 부분만 확장하기 어려움

게시글의 조회 수와 작성 트래픽이 급증했다고 가정해보자.

부하를 감당하기 위해 Scale-Up을 고려해볼 수 있으나, 한계가 있고 가격도 점점 비싸진다.

수평 확장을 통해 트래픽을 분산하는 방법을 고려해볼 수 있다.

하지만 위 구성은 리소스가 낭비된다. 게시글 기능에 대한 부담만 대응해주면 충분했을 것이다.

Monolithic Architecture에서는 모든 기능이 단일 애플리케이션에서 함께 배포되므로, 

게시글과 관련없는 다른 기능들도 같이 배포되어서 리소스를 점유하고 있는 것이다.

 

2. 변경 사항 시스템 전체에 영향을 미침

프로그래밍 관점에서의 문제도 살펴보자.

인기글 코드와 개발 편의를 위해 사용하던 공통코드에 변경이 생겼을때, 건드린 적도 없던 다른 기능이 동작하지 않을 수 있다.

단일 코드베이스에서 통합 관리하다보면, 공통 코드 관리 등으로 변경 사항이 타 기능에 예기치않게 전파될 수 있다.

전파되는 범위는 시스템이 커질수록 넓어지고 복잡해진다.

공통 기능이 아니더라도, 연관된 기능에 대해 서로의 코드를 침범하여 코드 간 결합도가 높아지고, 각 기능의 응집도가 낮아질 수 있다. 이는 유지보수를 점점 어렵게 만든다.

 

또한 모든 기능이 단일 애플리케이션에서 함께 관리되기 때문에, 한 기능만 변경하려고 했음에도 모든 기능이 다시 배포돼야 한다.

애플리케이션이 무거워질수록, 빌드 및 배포 시간은 늘어난다.

 

만일 인기글 기능 변경 사항에 오류가 있어 장애가 발생했다면, 최악의 경우 모든 기능으로 장애가 전파될 수 있다.

(ex. 인기글이 모든 메모리를 점유해서 다른 기능들이 메모리를 할당할 수 없는 상황)

 

 

이처럼 Monolithic Architecture는 대규모 시스템에서 복잡도가 커지고 개발/관리가 어려운 문제점이 있다.

이러한 문제를 해결하기 위한 Microservice Architecture를 살펴보자.

 

Microservice Architecture (MSA)

시스템이 작고 독립적인 서비스(Microservice)로 구성된다.

각 서비스는 단일 기능을 담당하며, 독립적 배포가 가능하다.

각 서비스는 유기적으로 연결되어서 통신하며, 하나의 시스템을 이룬다.

 

각 서비스의 코드는 독립적으로 관리 및 배포되므로, 개별 서비스 내에서는 복잡도가 낮고 빠르게 빌드 및 배포할 수 있다.

 

한 기능의 트래픽에 대응해야 한다면, 특정 서비스의 서버만 증설할 수 있다.

 

특정 서비스에 대한 코드 변경 또는 장애가 발생하더라도,

다른 서비스의 코드와 물리적으로 분리되어 있기 때문에 전파 범위가 줄어든다.

 

단점

• 서비스 간 복잡한 통신 및 모니터링 필요
• 데이터 일관성 및 트랜잭션 관리의 어려움
• 어려운 개발 난이도, 테스트, 설계(서비스 분리 기준)

등 고려할 부분이 너무 많다.

 

정리

---

참고 자료 & 이미지 출처
스프링부트로 직접 만들면서 배우는 대규모 시스템 설계 - 게시판