MSA(Microservices Architecture)

Architecture

by jeonghojin 2022. 3. 10. 11:59

MSA(Microservice Architecture) 는

" 하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍쳐"

MSA(Microservice Architecture) 가 등장하기 이전에는

Monolithic Architecture 개발 방법으로 개발되어왔다. * 한덩어리 구조

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

아직까지는 많은 소프트웨어가 Monolithic 형태로 구현되어 있고, 소규모 프로젝트에는 Monolithic Architecture가 훨씬 합리적인 구조이다.

서비스 / 프로젝트가 커지면 커질수록, 영향도 파악 및 전체 시스템 구조의 파악에 어려움이 있다.
빌드 시간 및 테스트 시간, 그리고 배포시간이 기하급수적으로 늘어가게 된다.
서비스를 부분적으로 scale-out하기가 힘들다. * scale out : 접속된 서버 대수를 늘려 처리 능력을 향상
부분의 장애가 전체 서비스의 장애로 이어지는 경우가 발생한다.

MSA (Microservice Architecture) 란

단일 프로그램을 각 컴포넌트 별로 나누어 작은 서비스의 조합으로 구축하는 방법이다.

각 컴포넌트는 서비스 형태로 구현되고 API를 이용하여 타 서비스와 통신하게 된다. 각 서비스는 독립된 서버로 타 컴포넌트와 의존성이 없기 때문에 독립된 배포를 하게 된다. 또한, 각 컴포넌트가 독립된 서비스로 개발되어있기 때문에 부분적인 확장이 가능하다.

예를 들어, 온라인 쇼핑몰에서 주문 서비스에 트래픽이 증가한다면 해당 서버만 확장해주면 된다.

Monolithic Architecture가 서비스 간의 호출이 하나의 프로세스 내에서 이루어지기 때문에 속도가 빠르지만, MSA(Microservice Architecture) 의 경우 서비스 간 호출을 API통신을 이용하기 때문에 속도가 느리고, 통신에 사용하기 위해 값을 데이터 모델로 변환시켜주는 오버헤드가 발생하기도 한다.

MSA (Microservice Architecture) 의 특징

1. 데이터 분리

데이터 저장 시 하나의 DB에 중앙 집중화를 하지 않고 서비스 별 별도의 데이터베이스를 사용한다. DB의 종류를 별도로 가져갈 수도 있고, 같은 DB를 사용하더라도 나누어서 사용하게 된다. 데이터가 분산되어있기 때문에 다른 서비스 컴포넌트에 대한 의존성이 없이 서비스를 독립적으로 개발 및 배포/운영 할 수 있지만, 다른 컴포넌트의 데이터를 API통신을 통해 가져와야 하기 때문에 성능 상의 문제가 발생할 수 있고, 트랜잭션으로 묶을 수 없는 문제가 발생하기도 한다.

2. API Gateway

MSA(Microservice Architecture)의 문제점 중 하나는 각 서비스가 다른 서버에 분리 배포되어있기 떄문에 서버 URL이 각각 다를 수 밖에 없다.

이때 API Gateway는 API 서버 앞 단에서 모든 API 서버들의 End-Point를 단일화하여 묶어주는 역할을 한다. 또한 거미줄처럼 복잡한 서비스간의 API 호출 구조도 단순화 시켜준다. 그 외에 라우팅, 로드밸런싱, 인증 역할 등등 여러 역할을 수행한다.

* API Gateway 패턴

※ 클라이언트 - 마이크로 서비스 간 직접 통신 대신 API 게이트웨이를 고려하는 이유

API Gateway 없는 경우, 클라이언트 앱은 microservice 로 직접 요청을 보내야 하는데 이 경우 다음과 같은 문제가 발생한다.

결합	API Gateway 패턴이 없으면 클라이언트 앱은 내부 microservice 에 결합된다. 클라이언트 앱은 애플리케이션의 여러 영역이 microservice에서 어떻게 분리 되는지 알아야 한다. 내부 microservice를 개선하고 리팩터링할 경우 클라이언트 앱에서 내부 마이크로 서비스를 직접 참조하기 떄문에 클라이언트 앱에 호환성이 손상되는 변경이 발생하므로 해당 작업은 유지관리에 영향을 준다.
너무 많은 왕복	클라이언트 앱의 단일 페이지/화면에서 여러 서비스를 몇 번 호출해야 할 수 있다. 해당 접근 방식으로 인해 클라이언트ㅘ 서버 간에 여러 번의 네트워크 왕복이 발생할 수 있어 대기시간이 상당히 늘어난다. 중간 수준에서 처리되는 집계는 클라이언트 앱의 성능과 사용자 환경을 향상할 수 있다.
보안 문제	게이트웨이가 없으면 모든 microservice가 "외부 세계"에 노출되어야 하므로 클라이언트 앱에서 직접 사용되지 않는 내부 microservice를 숨길 경우보다 더 큰 공격 표면이 생성된다. 공격 표면이 작을수록 애플리케이션을 더 안전하게 보호할 수 있다.
교차 편집 문제	공개적으로 게시된 각 마이크로 서비스는 권한 부여 및 SSL과 같은 문제를 처리해야하 한다. 대부분의 경우 이러한 문제는 단일 계층에서 처리할 수 있으므로 내부 microservice가 간소화된다.

https://docs.microsoft.com/ko-kr/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern

팀의 변화

기존의 팀 모델은 역할 별로 나누어진 모델로 팀을 구분했다. 이러한 팀 모델은 인력 관리와 운영에 유연성을 부여ㅑ하지만 팀 간의 커뮤니케이션이 원활하지 않고 협업에 걸리는 시간이 지연되는 경우가 많았다.

MSA에서는 서비스 별로 팀을 나누고 서비스 기획에서부터 설계 개발 운영이 팀 내에서 이루어지기 때문에 다른 팀에 대한 의존성이 사라지게 된다. 역할별 요청과 피드백이 빨라지고, 유연하고 지속적인 운영과 개발이 함께 진행된다.

하지만 인력 리소스 관리에 어려움이 생기는 단점도 존재한다. 각 팀의 역할 담당자들은 기본적인 업무 성숙도를 가지고 있어야 하고, 특히 개발자들은 운영 팀의 고유 영역이었던 인프라 핸들링이 가능해야한다. 그리고 이러한 일이 가능하게 된 것은 AWS 같은 클라우드 서비스 발달이다. 직접적인 인프라 운영 없이 클라우드 서비스를 이용하여 개발자가 운영 환경을 설정할 수 있게 되었다.

참조 : https://velog.io/@tedigom/MSA-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-1-MSA%EC%9D%98-%EA%B8%B0%EB%B3%B8-%EA%B0%9C%EB%85%90-3sk28yrv0e

MSA 제대로 이해하기 -(1) MSA의 기본 개념

lego-708086_1920.jpg 마이크로 서비스 아키텍쳐를 한마디로 다음과 같이 표현할 수 있습니다. "하나의 큰 어플리케이션을 여러개의 작은 어플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아

velog.io

참조 : http://clipsoft.co.kr/wp/blog/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98msa-%EA%B0%9C%EB%85%90/