MSA :: Micro Service Architecture 알아보기

출처/참고 : 삼성SDS https://youtu.be/wVpOboIlZ5I?si=_PG_UPehYpx12yiA

📍 MSA 탄생역사

1. Monolithic Architecture : 각 서비스들이 강하게 결합되어 하나의 전체 시스템을 이루는 구조 (예시:김밥)
2. Service Oriented Architecture
3. Micro Servcie Architecture : 작은 서비스 단위로 분리하고 느슨한 결합을 통해 벌집처럼 모여 하나의 시스템을 이루는 구조 (SOA에서 DevOps가 특화된 아키텍처로도 본다) (예시:뷔페)

MSA는 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 소프트웨어 아키텍처 스타일이다

느슨한 결합 : 각 서비스들이 독립적으로 실행되고 서로 통신을 하지만 문제가 생겼을 때 서로 크게 영향을 받지 않는 유연한 서비스 구조

 

 

 

📍 모놀리딕 아키텍처 :: Monolithic Architecture

 

모놀리딕 아키텍처는 구조가 간단하며 3가지의 단계로 나눠진다

1단계 : 서비스 요청을 받는 부분
2단계 : 요청을 처리하는 부분
3단계 : 데이터를 저장하는 부분

장점

• 개발이 상대적으로 간단한 편
• 흐름, 단계별로 설계가 되어서 데이터 정합성을 맞추기 쉽다
• 구조가 간단해서 전체 아키텍처 설계도 빠르다

단점

• 서비스가 커질수록 장점보단 단점이 많아지는 구조
• 시간이 지나 여러기능이 추가되면 소스코드가 복잡하고 길어져서 초기 개발자가 아니면 이해하기 어렵다
• 새로운 기능을 추가하고 싶어도 소스코드 읽는 시간이 길어져 개발속도 느림
• 기능이 추가되면 테스트시간도 오래 걸림
• 새로운 기술이 나와도 기존 코드가 동작하던 환경을 유지해야해서 쉽게 적용할 수도 없음
• 클라우드의 빠른 확장성과 유연한 인프라 환경구조에는 부적합

 

📍 마이크로 서비스 아키텍처 :: MSA

 

(Business 파트의 각 로직 안에 마이크로 서비스가 다수 포함되어 있다)

• 향후 서비스 확장을 고려해서 설계된 구조이다
• 전체 서비스를 작은 서비스 단위로 분리
• 각 서비스를 독립적으로 개발

장점

✔ 종속성이 낮아 고려해야할 사항도 적다
✔ 독립적으로 배포가 가능하다
✔ 한 서비스 장애가 전체 시스템 장애로 전파되지 않는다
✔ 새로운 기술을 적용하고 싶으면 언제든지 개별 서비스 단위로 적용이 가능하다
✔ 빠른 개발(=신속성) , 독립적 조직운영 (= 독립성, 효율성), 클라우드 제공 최신 기술(=적용성) 과 같은 특징으로 클라우드 핵심 아키텍처로 자리를 잡아가는 추세다

단점

✔ 구조가 복잡해서 관리하기가 어렵다
✔ 서비스 통신이 복잡해서 개발하기도 어렵다
✔ 데이터 정합성을 확보하기 어려움

예시

상황 : 한 시스템에서 회원, 서비스가 늘어나게 되면서 “조회”에 해당하는 기능만 사용빈도수가 높아짐. 이때 “결제”, “정산” 서비스는 사용이 예전과 비슷.

문제 : “조회” 기능의 속도, 성능 등이 떨어짐

해결 : “조회”에 해당하는 기능만 인프라를 향상시킴 → Auto scaling

 

📍 팀 구성 차이

모놀리딕 팀 구성 : 각 팀들이 전체 서비스를 함께 기획 및 운영

(예시 : 개발팀, UX디자인팀, 기획팀, 인프라운영팀 …)

✔ 서비스가 증가할 수록 각 팀에서 이해해야하는 범위가 기하급수적으로 상승

✔ 각 단계별 서비스에 새로운 기술을 적용할 경우 각 팀의 설정변경이 달라 업그레이드 하기 어려움

 

MSA 팀 구성 : 서비스 별로 팀을 나눠 독자적으로 설계, 개발, 운영 / 다른 팀에 대한 의존성 떨어짐

✔ 역할 별로 요청 및 피드백 반영 속도 증가

✔ 유연하고 지속적인 운영 및 개발 가능

✔ 인력 리소스 관리에 어려움이 있음

✔ 각 역할 담당자는 기본적인 업무 성숙도 필요

(개발자는 인프라 관리가 가능해야 함, 직접적인 물리 인프라 운영없이 환경설정 기능..)

 

📍 MSA 설계 원칙

각 기능들이 느슨한 결합을 가지면서 상호의존없이 단일 목적 기능을 수행하도록 설계.
전체 서비스를 유연하고 빠르게 개발.
장애전파 : 하나의 서비스에서 발생한 장애가 다른 서비스로 전파.
서비스가 늘어갈 수록 통신에 많은 에너지 소요, 관리가 어려워짐

⭐ 효율적으로 운영하기 위해 필요한 것

• 서비스메시구조로 설계하기
• 서비스메시구조 : 매 순간 통신해야하는 마이크로서비스를 찾고 연결하는 과정을 자동으로 처리
• 부하분산 : 한 서버에 트래픽이 과도하게 집중하는 것을 방지하기 위해 적절히 데이터의 경로를 설정하는 기능

 

서비스 앞단에 프록시(SideCar) ; 프록시의 뜻은 대리인이다 
서비스간의 커뮤니케이션 담당기능을 추가하면 하나의 서비스에서 장애가 발생할 경우 프록시가 다른 서비스에게 장애상황을 알려주기 때문에 장애가 전파되지 않음.

또한 최적의 서비스를 찾아서 부하를 분산하므로 전체 서비스가 쾌적하게 운영되도록 도와줌.

 

📍 MSA 도입시 주의사항

1. Why? 도입 목적에 이유가 필요하다

• 빠른 개발을 위해 / 유지보수성이 좋으니까 / 동작수행이 빠르다
• 다른 기업을 따라서 도입하는 것은 매우 위험
• 명확한 목적성을 가지고 MSA로 전환해야함
• MSA의 특성을 제대로 이해하여 여러 방면에서 고려해야함

 2. 기술만의 관점에서 바라보는 것은 금물! 아키텍처는 기술만의 영역이 아니라 조직구조와 운영의 영역이 함께 포함되어 있음.

• 모놀리딕 구조 : 조직, 운영, 기술이 하나에 집중되어 단순한 구조
• 서비스 운영이 어렵지 않아보일 수 있지만, 다양한 장애물을 마주할 수 있음
• MSA 구조 : (예시)(상품선택 → 혜택선택 → 결제 → 주문완료) 하나의 프로세스로 관리 한다
• 비즈니스 영역을 집중적으로 살펴볼 수 있는 조직으루 구성되어 있는가? 비즈니스 요구사항을 즉각 반영할 수 있는 DevOps팀이 구성되어 있는가?

3. MSA의 장점을 잘 계산하라

장점

• 비즈니스 요구사항을 빠르게 적용하여 개발가능
• 변경사항을 빠르게 운영환경에 배포가능
• 부분장애가 전체로 미치지 않아 장애영향도 최소화
• 서비스별로 신기술 적용이 용이

단점

• 다양한 신기술에 대한 학습 및 관리가 필요함
• 테스트가 복잡하고 운영복잡도도 커짐
• 서비스간 트랜잭션이 보장되지 않아 실패에 대한 데이터 정합성 보장을 직접 관리해야함

4. MSA 도입에 필요한 기술을 제대로 이해하자

• API, 서비스 메시, 변화관리, DevOps , 부하분산, 이벤트처리, 로그관리