AWS 기반 MSA 서비스(1) 아키텍쳐-MSA와 MA

KangMinSoo·2021년 10월 17일

aws cloud msa

AWS기반 MSA 서비스

목록 보기

1/4

내가 서버나 아키텍쳐를 잘 몰라서 공부하려고 쓴 글.

시리즈 목차

1. MSA (Architecture and Framework)

2. Cloud (서버를 두는 방식)

3. Docker

4. AWS기반 MSA서비스

프로그래밍 아키텍쳐에는 두 가지 방식이 존재한다. MA와 MSA

MA(모놀로식 아키텍쳐) 는 스프트웨어의 모든 구성 요소가 한 프로젝트에 통합되어 있는 형태
MSA(마이크로 서비스 아키텍쳐) 는 작고 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 형태
먼저 이 두가지 아키텍쳐를 알아보자.

1) MSA란?

Micro Service Architecture의 줄임말로 작고 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임 워크, 아키텍쳐.
1. 완전히 독립적인 배포가 가능하고
2. 다른 기술 스택(Language, DB 등)이 사용 가능한 단일 사업 영역에 초점을 둔다.
3. 주로 비즈니스 기능을 중심으로 구축된다.
4. MSA는 *MA의 문제점을 보완하기 위해 등장하게 되었다.

*MA

Monolithic Architecture의 줄임말로 스프트웨어의 모든 구성 요소가 한 프로젝트에 통합되어 있는 형태이다. 예를들어 웹 개발시 모듈별로 개발하고 개발이 완료된 웹 앱을 하나의 결과물로 패키징하여 배포되는 형태이다. 이런 형식을 모놀리식 앱이라 하며 웹의 경우 WAR파일로 빌드되어 WAS에 배포하는 형태이다. 주로 소규모 프로젝트에 쓰임.

MA의 한계

일정 규모 이상의 서비스 혹은 수백명 이상 개발자 투입되는 프로젝트에서 주로 아래와 한계를 보임

부분 장애가 전체 서비스의 장애로 확대 될 수 있음.
부분적인 Scale-out(여러 서버로 나누어 일 처리 방식)이 어려움
서비스의 변경이 어렵고 수정시 장애의 영향도 파악이 힘듬
배포 시간이 오래걸림.
한 Framework에 종속적 -> 선정했던 frame work가 Spring이면 node.js로 사용 못함. java를 이용해 작성 해야 함

MSA의 장점

MSA는 API(HTTP기반)를 통해서만 통신. 서비스의 end-point(접근점)을 API형태로 외부에 노출. 실질적 세부 사항은 모두 추상화한다. 따라서 SOA(Service Oriented Architecture)의 특징을 가짐.
제대로 설계된 마이크로 서비스는 하나의 비즈니스 범위에 맞춰 만들어지므로 하나의 기능만 수행. 예를 들어 앱 출시처럼 하나의 목표를 향해 일하지만 자기가 개발하는 서비스만 책임을 짐. 그리고 여러 어플리케이션에서 재사용할 수 있어야 함
MSA는 SOA에서 사용되는 집중화된 관리 체게를 사용하지 않는다. MSA구현체의 공통적인 특징 중 하나는 ESB(Enterprise Service Bus)와 같은 무거운 제품에 의존하지 않음. REST등 가벼운 통신 아키텍쳐 또는 Kafka등을 이용한 message stream을 주료 사용.
각각의 서비스가 모듈화 되어있음. 각 모듈끼리 RPC 또는 Message-driven API등을 이용하여 통신함. 이러한 MSA는 각각 개별의 서비스 개발을 빠르게 하며 유지 보수도 쉽다.
팀 단위로 적절한 수준에서 기술 스택을 다르게 가져갈 수 있음. 회사가 JAVA의 Spring 기반이어도 MSA적용하면 node.js로 블록체인 개발 모듈을 연동할 수 있음. 어플리케이션은 항상 기술 중립적으로 프로토콜을 사용해 통신하므로 서비스 구현 기술과는 무관.
MSA는 서비스별로 독립적 배포(자동화된 배포머신)가 가능. 따라서 지속적인 배포 CD도 모놀로식에 비해 가볍게 할 수 있음.
MSA는 각각 서비스의 부하에 따라 개별적으로 Scale-out이 가능. 이는 메모리와 CPU적으로 상당한 이득.

MSA 단점

모놀리식에 비해 상대적으로 복잡.
->서비스가 모두 분산되어 있어 테스트와 트랜잭션이 복잡. 개발자는 내부 시스템 통신을 어떻게 가져갈지 정해야함.
->데이터가 여러 서비스에 분산되어 있기 때문에 관리가 어려움.
또한 통신의 장애와 서버의 부하 등의 경우 어떻게 Transaction을 유지할지 결정하고 구현해야함
-> 기능단위의 시스템이 많아져, 인터페이스의 수가 늘어나게되어 오류 발생확인이 어렵다.
통합 테스트가 어려움. 개발 환경과 실제 운영 환경을 동일하게 가져가는 것이 쉽지 않음.
실제 운영환경에 대해서 배포하는 것이 쉽지 않음.

MSA 정리

장애 격리와 복구가 쉽다.
비용이 효율적이다.
서비스가 작아 배포가 빠르고 서비스 개선 속도가 빠르다.
서비스가 작아 생산성 향상이 될 수 있다. 코드의 양이 적다.
신기술 도입이 쉽다. 작은 단위에 적용하면 되니까.
Polyglot을 적용할 수 있다. 서비스에 최적화된 개발 언어와 데이터베이스를 선택하기 쉽다.
앞서 말한 장 단점을 고려해서 MSA를 도입하기 전에 내가 서비스할 것이 MSA와 적합한 서비스인지 먼저 고려해보아야 함.