실무에서 전하는 따끈한 마이크로서비스 아키텍처(MSA) 이야기(2) - MSA 아키텍처
해당 글은 인프런에서의 실무에서 전하는 따끈한 마이크로서비스 아키텍처(MSA) 이야기 강의를 보고 간략하게나마 정리한 글입니다.
1. 아키텍처
1-1. 아키텍처란?
- 목표하는 대상에 대하여 구 구성고 동작 원리, 구성 요소 간의 관계 및 시스템 외부 환경과의 관계 등을 설명하는 설계도
- 아키텍처 특성
- 가용성, 신뢰성, 시험성, 확장성, 보안, 민첩성, 내고장성, 탄력성, 복구성, 성능, 배포성, 학습성
- 아키텍처 결정
- 시스템의 제약조건, 개발자가 해도 되는 것과 하지 말아야 할 것을 정의
- 설계 원칙
- 아키텍처 결정을 만족시키는 가이드 라인
- 시스템 구조
- 아키텍처 결정 및 설계 원칙에 적합한 상위 수준의 시스템 구조를 정의
1-2. 아키텍처와 아키텍트
- 아키텍트
- 비즈니스 요건을 분석 아키텍처 특성을 도출.
- 아키텍처 스타일과 패턴을 선택하고 각종 시스템 구성요소를 정의.
- 아키텍처 결정사항 및 정의된 시스템 구성요스를 개발팀에게 전달.
-아키텍처 준수를 위해 지속적인 가이드, 멘토링 진행.
- 개발팀(설계자/개발자)
- 정의된 아키텍처에 기반한 컴포넌트 모듈화, 식별하고 적절한 역할 및 책임을 부여.
- 도메인 기능이 응집되도록 컴포넌트 간 의존관계를 줄임.
- 정의된 아키텍처 결정사항 및 제약사항 준수.
- 규정된 컴포넌트 내부 구성요소를 활용하여 비즈니스 로직 구현을 위한 컴포넌트 설계를 진행.
1-3. 아키텍처링 과정
2. 아키텍처 스타일
- 아키텍처 스타일은 기술의 변화 흐름을 반영한다.
- 다양한 아키텍처 스타일이 존재한다.
- 레이어드 아키텍처 스타일
- 파이프라인 아키텍처 스타일
- 마이크로커널 아키텍처 스타일
- 서비스 기반 아키텍처 스타일
- 이벤트 기반 아키텍처 스타일
- 공간 기반 아키텍처 스타일
- 오케스트레이션 기반 서비스 지향 아키텍처 스타일
- 마이크로서비스 아키텍처 스타일
2-1. 레이어드 아키텍처 스타일
- 가장 표준적인 아키텍처 스타일
- 관심사의 분리
- 장점 : 익숙하고, 단순, 소규모, 비용
- ex) OSI 7 계층
MVC는 아키텍처 스타일이 아니다.
2-2. 서비스 기반 아키텍처 스타일
- 유연성 있는 대규모 분산 레이어 구조.
- 아키텍트에 따라 다양한 서비스 기반 아키텍처 스타일로 나뉠 수 있음.
- 중앙 공유 데이터베이스 사용(Join 기능 사용)
- 유저 인터페이스 변형
- 단일 모놀리식 유저 인터페이스, 도메인 기반 유저 인터페이스,서비스 기반 유저 인터페이스
- 데이터베이스 변형
- 개별 데이터베이스(DB)로 분리(마이크로서비스와 유사)
- 각 데이터베이스에 있는 도메인 데이터를 다른 도메인 서비스가 필요하지 않도록 설계해야 함.
- 각 DB 역할 별로 격리함.
- 서비스 내부 설계
- 레이어드 설계(기술분할) vs 도메인설계(도메인분할)
- 일반적인 모놀리스식 데이터베이스 공유
- 데이터베이스 커플링 문제, 스키마 변경 시 변경영향도 문제 발생
- 데이터베이스를 논리적으로 분할, 전용 공유 라이브러리화, 도메인별 접근 권한 분리
2-3. 이벤트 기반 아키텍처 스타일
- 확장성이 뛰어난 고성능 어플리케이션에서 널리 쓰이는 비동기 분산 아키텍처.
- Queue 메커니즘.
- 다른 아키텍처에 내장이 가능.
- 이벤트 발생에 액션이 반응하는 방식.
- RabbitMQ, ActiveMQ, Kafka 등 경랑 메시지 브로커를 통해 이벤트를 발생.
- 각 서비스가 자율적으로 이벤트를 처리하는 코레오그래피(Choreography) 방식.
- 장점
- 성능, 확장성, 응답성
- 단점
- 비동기 통신으로 인한 트랜잭션 통제가 어려움
- 교착 상태, 데이터 비일관성
- 통신 도중 데이터 유실에 대한 에러 처리가 어려움
2-4. 공간 기반 아키텍처 스타일
- 높은 확장성, 탄력성, 동시성을 가짐.
- 동시 유저수가 가변적인 예측 곤란한 어플리케이션에 유용(콘서트 예매 등)
- 복제된 인 메모리 그리드
- 데이터 펌프, 데이터라이터, 데이터 리더
- 캐시로 처리 가능한 부분은 처리하고, 데이터 일관성 문제가 생김
2-5. 마이크로서비스 기반 아키텍처 스타일
- 분산 아키텍처, 성능은 다소 부정적, 세분도가 중요
- 데이터 격리, 재사용보다는 중복, 프로토콜인지 이종간 상호 운용성
- API 레이어, 고도의 의존성 추구
3. 최적의 아키텍처 스타일
- 최고의 아키텍처 스타일은 없다 상황에 의해 최적의 아키텍처를 고려해야 할 뿐이다.
- 아키텍처 유형은 계속해서 변함.
- 결정의 기준은 도메인, 데이터 아키텍처, 조직 역량, 개발 프로세스 등을 고려해야한다.
- 모노리스 vs 분산
- 데이터를 어디에 둘 것 인가
- 서비스간 통신 방법
- 소프트웨어 아키텍처의 모든 것은 트레이드 오프.
- '어떻게(How)' 보다 '왜(Why)'가 더 중요
참고
- https://www.inflearn.com/course/%EC%8B%A4%EB%AC%B4-msa-%EC%9D%B4%EC%95%BC%EA%B8%B0/dashboard