MSA

MSA(MicroService Architecture)

마이크로서비스란 작고, 독립적으로 배포 가능한 각각의 기능을 수행하는 서비스로 구성된 프레임워크라고 할 수 있다. 마이크로서비스는 완전히 독립적으로 배포가 가능하고, 다른 기술 스택(개발 언어, 데이터베이스등)이 사용 가능한 단일 사업 영역에 초점을 둔다

 

 

 

등장배경

Monolithic Architecture

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

웹 개발을 예로 들면 웹 프로그램을 개발하기 위해 모듈별로 개발하고, 개발이 완료된 웹 어플리케이션을 하나의 결과물로 패키징하여 배포된 형태를 말한다.

웹의 경우 WAR파일로 빌드되어 WAS에 배포하는 형태를 말하며, 주로 소규모 프로젝트에 사용된다.

하지만 일정 규모 이상의 서비스, 혹은 수백명 이상의 개발자가 투입되는 프로젝트에서 Monolithic Architecture는 한계를 보인다

 

 

 

Monolithic Architecture 한계

 

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

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

 

부분적인 Scale-out이 어렵다

Monolithic Architecture에서는 사용되지 않는 다른 모든 서비스가 Scale-out되어야 하기때문에 부분 Scale-out이 어렵다

Scale-out : 여러 server로 나누어 일을 처리하는 방식

 

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

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

 

배포 시간이 오래 걸린다

최근 어플리케이션 개발 방법은 CI/CD를 통한 개발부터 배포까지 빠르게 반영하는 추세이다.

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

 

한 Framework와 언어에 종속적이다

Spring Framework를 사용할 경우, 블록체인 연동 모듈을 추가할 때 node.js를 사용하는 것이 일반적이며 강세이다. 그러나 선정했던 Framework가 Spring이기때문에 Java를 이용하여 해당 모듈을 작성할 수 박에 없다.이러한 Monolithic Architecture의 한계를 보완하기 위해 MSA가 등장하게 되었다. 기존의 특정한 물리적인 서버에 서비스를 올리던 on-promise 서버 기반 Monolithic Architecture에서 이제는 클라우드 환경을 이용하여 서버를 구성하는 MicroService Architecture로 많은 서비스들이 전환되고 있다.

 

 

특징

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

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

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

 

 

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

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

 

어플리케이션은 항상 기술 중립적 프로토콜을 사용해 통신하므로 서비스 구현 기술과는 무관하다

따라서, 마이크로서비스 기반의 어플리케이션을 다양한 언어와 기술로 구축할 수 있다는 것을 의미한다

 

마이크로서비스는 SOA에서 사용되는 집중화된 관리체계를 사용하지 않는다.

마이크로서비스 구현체의 공통적인 특징 중 하나는 ESB(Enterprise Service Bus)와 같은 무거운 제품에 의존하지 않는다는 점이다. REST 등 가벼운 통신 아키텍처, 또는 Kafka등을 이용한 message stream을 주로 사용한다

 

 

장점

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

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

 

팀 단위로 적절한 수준에서 기술 스택을 다르게 가져갈 수 있다

 

서비스별로 독립적 배포가 가능하다

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

 

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

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

 

 

단점

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

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

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

 

트랜잭션 유지가 어렵다

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

 

통합 테스트가 어렵다

개발 환경과 실제 운영 환경을 동일하게 가져가는 것이 쉽지 않다

 

실제 운영 환경에 대해서 배포하는 것이 쉽지 않다

마이크로서비스의 경우 서비스 1개를 재배포한다고 하면 다른 서비스들과의 연계가 정상적으로 이루어지고 있는지도 확인해야 한다

 

 

기업으로 알아본 적용 사례

이모티콘 서비스는 왜 MSA를 선택했나?

넷플릭스로 알아보는 MSA | 인사이트리포트 | 삼성SDS

 

서비스 경량화를 위한 MSA 설계 시 고려사항 | 인사이트리포트 | 삼성SDS

 

11번가 주니어 개발자의 첫 MSA 설계 및 개발기 | 11번가 TechBlog — 11번가 기술블로그

 

 

 

 

SOA(Service Oriented Architecture)

대규모 컴퓨터 시스템을 구축할 때의 개념

업무상 일 처리에 해당하는 소프트웨어 기능을 서비스로 판단하고 그 서비스를 네트워크상에 연동하여 시스템 전체를 구축해가는 방법론이다. 업무 처리 변화를 시스템에 빠르게 반영하고자 하는 수요에 대응하기 위해 2004년부터 IT업계에서 주목하고 있다

• 플랫폼에 종속되지 않는 표준 인터페이스를 통해 기업의 업무를 표현한 ‘느슨하게 연결되고(Loosly coupled) 상호 조합 가능한 소프트웨어’
• SOA에서는 각각의 서비스가 데이터 계층, 비즈니스 로직, 뷰에 대한 모듈을 모두 가지고 있고, 각 서비스 간의 의존성이 최소화된다
• SOA시스템의 규모가 증가함에 따라 서비스의 중복이 발생할 수 있고, 이를 방지하기 위해 이미 구현된 서비스가 있는지 검색할 수 있어야 한다

SOA 아키텍처 모델

1. Fundamental SOA(통합)
2. Networked SOA(유연성과 통제 추가)
3. Process Oriented SOA(민첩성의 추가)