MSA 개념 정리

Scale-up & Scale-out

인프라를 업그레이드 하는 방법 2가지

스케일 업(Scale-up), 스케일 아웃(Scale-out)

 

스케일 업(Scale-up)

기존의 서버를 보다 높은 사양으로 업그레이드하는 것을 의미 

하드웨어: 성능, 용량 증강을 목적으로 디스크 추가나 CPU, 메모리를 업그레이드시키는 것을 말한다. 

소포트웨어: AWS의 EC2 인스턴스 사양을 micro → (small, medium)등으로 업그레이드 

이처럼 하나의 서버의 능력을 증강하기 때문에 수직 스케일링(vertical scaling)이라고도 한다. 

 

스케일 아웃(Scale-out)

스케일 아웃(Scale-out)은 장비를 추가해서 확장하는 방식

기존 서버만으로 용량이나 성능의 한계에 도달했을 때, 비슷한 사양의 서버를 추가로 연결해 처리할 수 있는 데이터 용량이 증가할 뿐만 아니라 기존 서버의 부하를 분담해 성능 향상의 효과를 기대할 수 있다

서버를 추가로 확장하기 때문에 수평 스케일링(horizontal scaling)이라고도 불린다

 

클라우드 서비스에서는 자원 사용량을 모니터링하여 자동으로 서버를 증설(Scale Out)하는 Auto Scaling 기능도 있다

 

스케일 업(Scale-up) vs 스케일 아웃(Scale-out) 

스케일 업

• 스케일 업 아키텍처에서는 추가적인 네트워크 연결 없이 용량을 증강할 수 있다
• 스케일 아웃보다 관리 비용이나 운영 이슈가 적고, 사양만 올리면 되는 것이기 때문에 비교적 쉽다
• 성능 향상에 한계가 있으며 성능 향상에 따른 비용부담이 크고, 서버 한 대가 부담하는 양이 많아서 자연재해 등의 다양한 이유로 서버에 문제가 생기면 큰 타격을 입게 된다
• 기존의 서버를 교체함으로써 성능을 올릴 때에는 서비스를 이용할 수 없는 다운타임이 불가피

스케일 아웃

• 스케일 아웃 아키텍처의 가장 큰 장점 중 하나는 확장의 유연성
• 스케일 업 시스템을 구축한 상황에서는 향후 확장 가능성에 대비해 서버를 현재 필요한 만큼보다 더 많은 용량이나 성능을 확보해놓는 경우가 많다 그러나 이런 경우 예상했던 정도와 요구되는 정도가 다르거나, 확장의 필요성이 없어졌을 경우 추가로 확보해놓은 만큼의 손해가 발생하게 된다
• 스케일 아웃 방식으로 시스템을 구축한 상황에서는 서버를 필요한 만큼만 도입해 놓고, 장기적인 용량 증가 추이를 예측할 필요 없이 그때그때 필요한 만큼 서버를 추가해 용량과 성능을 확장(pay-as-you-grow)할 수 있게 된다
• 여러 노드를 연결해 병렬 컴퓨팅 환경을 구성하고 유지하려면 아키텍처에 대한 높은 이해도가 요구된다
• 서버의 수가 늘어날수록 관리가 힘들어지는 부분이 있고, 아키텍처의 설계 단계에서부터 고려되어야 할 필요가 있다 
• 여러 노드에 부하를 균등하게 분산시키기 위해 로드 밸런싱(load balancing)이 필요하고, 노드를 확장할수록 문제 발생의 잠재 원인 또한 추가한 만큼 늘어나게 된다

---

서비스 지향 아키텍처/SOA(Service-Oriented Architecture)

SOA는 소프트웨어 시스템을 설계하는 패턴 또는 아키텍처 스타일

서로 다른 서비스들이 네트워크를 통해 상호 작용하도록 설계

SOA의 각 서비스는 독립적이고 자기 완결적인 단위로, 특정 기능이나 비즈니스 프로세스를 수행

이러한 서비스들은 조합되어 재사용될 수 있어 유연하고 확장 가능한 시스템을 만들 수 있다. 

---

Monolithic Architecture 

Monolithic Architecture ?

소프트웨어 모든 구성요소가 한 프로젝트에 통합되어 있는 형태

개발이 완료된 웹 애플리케이션을 하나의 결과물로 패키징하여 배포하는 형태 

이런 애플리케이션 형태를 모놀리식 애플리케이션이라 한다. 

주로 소규모/개인 프로젝트에 사용된다. 

Monolithic Architecture 한계 

1. 부분 장애가 전체 서비스의 장애로 확대될 수 있다

개발자의 잘못된 코드 배포 또는 갑작스런 트래픽 증가로 인해 성능에 문제가 생겼을 때, 서비스 전체의 장애로 확대될 수 있다. 

ex)

배달의 민족 리뷰 서비스가 죽었는데 전체 배달의 민족 서비스 장애 

 

2. 부분적인 Scale-out 불가능 

Monolithic Architecture에서는 서비스가 나누어져 있지 않아서 모든 서비스 많이 사용되지 않는 모든 서비스 또한 같이  Scale-out 되어야 한다. (리소스 낭비) 

 

ex)

배달의 민족 쿠폰 발급 서비스에 트래픽이 엄청 증가했는데 서버 증설로 모든 서비스가 Scale Out

 

3. 서비스의 변경이 어렵고, 수정 시 장애의 영향 파악이 힘들다. 

여러 컴포넌트가 하나의 서비스에 강하게 결합되어 있기 때문에 수정에 대한 영향도 파악이 힘들다 

 

4. 배포 시간이 오래 걸린다.

최근 개발 방법은 CI/CD를 통한 개발부터 배포까지 빠르게 반영하는 추세 

그러나 규모가 커짐에 따라 작은 변경에도 높은 수준의 테스트 비용이 발생하기도 하며, 많은 사람이 하나의 시스템을 개발하여 배포하기 떄문에 영향을 줄 수 밖에 없다. 

 

5. Framework와 언어에 종속적

ex)

블록체인 연동 모듈을 추가할 때 node.js를 사용하는 것이 일반적이고 트랜드 

그러나 이미 선정했던 프레임워크가 Spring 이어서 java를 이용하여 해당 모듈을 작성할 수 밖에 없다. 

 

MSA 등장 이유 

이런 Monolithic Architecture의 문제점을 보완하기 위해서 MSA가 등장하게 되었다. 

기존의 특정한 물리적인 서버에 서비스를 올리던 Monolithic Architecture에서 이제는 클라우드 환경을 이용하여 서비스를 구성하는 MicroServiceArchitecture로 많은 서비스들이 전환되고 있다. 

---

MSA: MicroServiceArchitecture 

MSA?

MSA는 API를 통해서만 상호작용할 수 있다

즉, 마이크로 서비스는 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다
내부의 구현 로직, 아키텍처와 프로그래밍 언어, 데이터베이스, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려진다. 

따라서 SOA(Service Oriented Architecture)의 특징을 다수 공통으로 가진다. 

 

제대로 설계 된 마이크로서비스는 하나의 비즈니스 범위에 맞춰 만들어지므로 하나의 기능만 수행한다.

즉, 어플리케이션 출시처럼 하나의 목표를 향해 일하지만 자기가 개발하는 서비스만 책임진다. 그리고 여러 어플리케이션에서 재사용할 수 있어야 한다.

어플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하므로 서비스 구현 기술과는 무관하다. 따라서 마이크로서비스 기반의 어플리케이션을 다양한 언어와 기술로 구축할 수 있다는 것을 의미한다. 

 

SOA VS MSA

SOA(서비스 지향 아키텍처) MSA(마이크로서비스 아키텍처)는 둘 다 서비스 단위로 시스템을 구성하는 아키텍처 스타일

 

서비스의 크기 & 범위

• SOA에서의 서비스는 비교적 큰 단위로, 보통 여러 기능을 포함하고 있으며 다양한 비즈니스 기능을 지원하는 경우가 많다. 서비스의 크기가 크다. 
• MSA에서는 서비스가 매우 작은 단위로 쪼개져 있으며, 각 서비스는 독립적으로 배포 가능하고 특정 기능에만 집중한다. 이러한 작은 단위의 서비스들은 각자 독립적으로 운영되며, 기능별로 분리되어 있다. 

통신 방식

• SOA에서는 주로 엔터프라이즈 서비스 버스(ESB)를 사용하여 서비스 간 통신을 중재합니다. ESB는 다양한 서비스 간에 메시지를 라우팅하고, 변환하며, 보안을 관리하는 등의 역할을 한다. 
• MSA에서는 주로 경량 메시지 브로커(RabbitMQ, Kafka)나 RESTful API를 통해 서비스 간 통신을 수행합니다. 서비스 간의 통신이 더 단순하고 직접적

데이터 관리

• SOA에서는 데이터베이스가 공유되는 경우가 많다. 여러 서비스가 동일한 데이터베이스를 사용할 수 있으며, 이를 통해 서비스 간 데이터 통합이 쉽게 이루어진다.
• MSA에서는 각 서비스가 독립적인 데이터베이스를 가지며, 데이터베이스가 공유되지 않는 것이 일반적이다. 이는 데이터 독립성과 서비스의 낮은 결합도를 유지하기 위해서이다. 

배포 및 운영

• SOA 서비스는 종종 함께 배포되거나 같은 애플리케이션 서버에서 실행되는 경우가 많다. 이로 인해 배포 및 운영이 단순하지만, 서비스 간의 독립성이 낮아질 수 있다.
• MSA에서는 각 서비스가 독립적으로 배포되며, 컨테이너화된 환경(Docker)을 통해 독립적으로 관리된다. 이를 통해 유연성과 확장성이 높아지지만, 운영 복잡성은 증가할 수 있다.

MSA의 장점

각각의 서비스는 모듈화가 되어있으며 이러한 모듈까리는 RPC 또는 message-driven API등을 이용하여 통신한다. 

이러한 MSA는 각각 개별의 서비스 개발을 빠르게 하며, 유지보수도 쉽게할 수 있도록 한다. 

Framework와 언어에 종속되지 않는다. 

마이크로서비스는 서비스별로 독립적 배포가 가능하다. 

따라서 지속적인 배포 CD도 모놀로식에 비해서 가볍게 할 수 있다.

마이크로서비스는 각각 서비스의 부하에 따라 개별적으로 scale-out이 가능하다. 

메모리, CPU적으로 상당부분 이득이 된다.

MSA의 단점

MSA는 모놀리식에 비해 상대적으로 많이 복잡하다. 

서비스가 모두 분산되어 있기 때문에 개발자는 내부 시스템의 통신을 어떻게 가져가야 할지 정해야한다. 

또한, 통신의 장애와 서버의 부하 등이 있을 경우 어떻게 transaction을 유지할지 결정하고 구현해야한다. 

 

모놀리식에서는 단일 트랜잭션을 유지하면 됐지만 MSA에서는 비즈니스에 대한 DB를 가지고 있는 서비스도 각기 다르고, 서비스의 연결을 위해서는 통신이 포함되기 때문에 트랜잭션을 유지하는게 어렵다. 

 

통합 테스트가 어렵다. 개발 환경과 실제 운영환경을 동일하게 가져가는 것이 쉽지 않다. 

 

실제 운영환경에 대해서 배포하는 것이 쉽지 않다. 마이크로서비스의 경우 서비스 1개를 재배포 한다고 하면 다른 서비스들과의 연계가 정상적으로 이루어지고 있는지도 확인해야한다. 

---

참고 자료 

Tecoble 3기_파피 Scale-up과 Scale-out에 대해 알아보자!

Scale-up과 Scale-out에 대해 알아보자!

https://wooaoe.tistory.com/57

[MSA] MSA란 무엇인가? 개념 이해하기