[마이크로서비스패턴] 1장 모놀리식 지옥에서 벗어나라
1장. 모놀리식 지옥에서 벗어나라
1장의 핵심 내용
- 모놀리식 지옥 도래 조짐, 마이크로서비스 아키텍처 도입을 통해 벗어나는 방법
- 마이크로서비스 아키텍처의 주요 특징, 장단점
- 크고 복잡한 애플리케이션을 데브옵스 스타일로 개발하는 방법
- 마이크로서비스 아키텍처 패턴 언어 사용 이유
모놀리식 아키텍처 장점
- 개발이 간단함
- 애플리케이션 쉽게 변경 가능
- 테스트 쉬움
- 배포 쉬움
- 확장 쉬움
영원한 장점일까?
- 시간이 지날수록 복잡성이 증가할 수밖에 없음 : 점점 복잡해지는 의존성
- 개발 생산성 저하 : 실행, 빌드 소요 시간 증가
- 배포 어려움 증대 : 커밋 병합, 배포 어려움 발생. 테스트 시간 증가.
- 확장 어려움 : 애플리케이션 모듈 별 사용 리소스가 다른 경우 서버 리소스 구성에 고려할 점이 많아 확장 어려움 존재.
- 신뢰성 하락 : 테스트 어려움 발생 -> 버그 발생 증가. 동일 프로세스 상 실행되어 결함 격리 불가. 메모리 누수 발생 시 전체 애플리케이션에 영향
- 기술 스택 교체 어려움
마이크로서비스?
크기에 중점을 두기에는 애매모호.
경계 컨텍스트가 있는, 느슨하게 결합된 엘리먼트로 구성된 서비스 지향 아키텍처
3차원 확장 모델 : 확장 큐브
1. X축 : 다중 인스턴스에 고루 요청 분산
인스턴스 N 개 + 앞 단에 부하 분산기 : 부하 분산기로 들어온 요청을 각 인스턴스에 고루 분배
2. Z축 : 요청 속성별 라우팅
eg) 각 인스턴스는 자신에게 배정된 사용자 하위 집합만 처리
3. Y축 : 기능에 따라 애플리케이션을 서비스로 분해
X, Z축 확장의 한계 : 서비스의 복잡도는 줄여주지 못함
하나의 애플리케이션을 여러 서비스로 기능 분해하는 아키텍처 스타일 : 중요한 것은 각 서비스가 집중된/응집된 책임을 맡고 있음
마이크로서비스
- 모듈성 : 서비스를 모듈성의 단위로 사용. 각 서비스 간의 경계로 인해 모듈성 유지 가능. + 부가적으로 독립적 배포/확장 가능
- 서비스마다 별도 DB 사용 : 각 서비스 담당자가 스키마 외부 영향도 고려 없이 변경 가능. DB 락에 의한 서비스 블로킹 케이스 발생 X.
마이크로서비스 vs SOA
| 구분 | SOA | 마이크로서비스 |
|---|---|---|
| 서비스 간 통신 | SOAP, WS 표준처럼 무거운 프로토콜을 응용한 엔터프라이즈 서비스 버스 중심의 스마트 파이프(smart pipe) | REST나 gRPC처럼 가벼운 프로토콜 응용한 메시지 브로커 또는 서비스 간 통신 중심의 덤 파이프(dumb pipe) |
| 데이터 | 전역 데이터 모델 및 공유 DB | 서비스 개별 데이터 모델 및 DB |
| 주요 사례 | 대규모 모놀리식 애플리케이션 | 소규모 서비스 |
마이크로서비스 장단점
장점
- 크고 복잡한 애플리케이션을 지속 전달/배포 가능
- 테스트성 : 자동화된 테스트. 상대적으로 작은 크기의 테스트.
- 배포성 : 독립적 배포 가능.
- 자율성, 느슨한 결합
- 서비스 규모가 작아 관리 용이 : 비교적 적은 코드로 이해하기 쉬움. IDE, 실행 속도 등 더 빠름.
- 서비스를 독립적으로 배포/확장
- 팀이 자율적으로 움직일 수 있음
- 결함 격리 용이
- 신기술 실험 및 도입 용이
단점
- 딱 맞는 서비스를 찾기 쉽지 않음
- 분산 시스템은 너무 복잡해서 개발, 테스트, 배포 어려움
- 사용 불능, latency 등 문제 발생에 대한 처리 가능 설계 필요
- 다중 DB 접속, 조회, 트랜잭션 구현 =>
사가통한 데이터 일관성 유지 - 여러 서비스의 데이터 조회 : API 조합 또는 CQRS 뷰 쿼리
- 운영 복잡도 : 자동화 배포 툴 필요 (spinnaker, k8s 등)
- 여러 서비스에 걸친 기능을 배포할 때에는 잘 조정해야
- 세밀한 배포 계획 수립 필요
- 마이크로서비스 아키텍처 도입 시점 결정 어려움
마이크로서비스 아키텍처 패턴 언어
왜 필자는 패턴 언어를 강조하는가? 자신의 감정을 극복한 상태에서 기술을 논할 수 있어야 함. 그러기 위해 패턴 포맷으로 기술을 객관적 기술.
상용 패턴의 구조
1. 강제조항 : 문제 해결을 위해 반드시 처리해야 할 이슈
- 충돌하는 조항도 있을 수 있음.
우선 순위에 따라 고려
2. 결과 맥락 : 패턴 적용 결과
- 장점, 단점, 이슈 세 부분으로 기술
- 장점 : 해결된 강제 조항 등
- 단점 : 미해결 강제 조항 등
- 이슈 : 새롭게 발견된 문제점
3. 연관 패턴 : 다섯 가지 관계 유형
한 패턴과 다른 패턴 관계 기술
- 선행자 : 이 패턴을 필요하게 만든 선행 패턴
- 후행자 : 이 패턴으로 야기된 이슈를 해결하는 패턴
- eg) 마이크로서비스 아키택처 패턴의 후행자 : 서비스 디스커버리 패턴, 서킷 브레이커 패턴 등
- 대안 : 이 패턴의 대체 솔루선을 제공하는 패턴
- 모놀리식 vs 마이크로서비스
- 일반화 : 문제를 해결하는 일반적인 솔루션 해당 패턴
- 세분화 : 특정 패턴은 더 세부적으로 나타낸 형태
마이크로서비스 아키텍처 패턴 언어 개요
분해 패턴(Decomposition) : 대안 관계의 두 패턴
- 비즈니스 능력에 따라 분해
- 하위 도메인에 따라 분해
통신 패턴(Communication)
- Communication style : 어떤 종류의 프로세스 간 통신(IPC) 사용?
- Discovery : 서비스 클라이언트는 서비스 인스턴스의 IP주소 어떻게 조회
- Reliability : 서비스 불능 시 서비스 간 통신의 신뢰성 어떻게 보장
- Transactional messaging : DB 트랜잭션에 메시지 송신 및 이벤트 발행 어떻게 통합
- 외부 API : 애플리케이션 클라이언트는 서비스와 어떻게 통신
Maintaining data consistency
서비스마다 자체 DB를 갖게됨. 기존 분산 트랜잭션(2PC) -> 사가 패턴 통해 데이터 일관성 유지
Querying
DB 분리로 인한 데이터 조인 쿼리 문제 발생.
- API 조합 패턴 : 하나 이상의 서비스를 호출해서 그 결과 조합
- CQRS : 하나 이상의 데이터 레플리카를 유지해서 쉽게 쿼리하는 방식
Deployment
- 서비스 배포 플랫폼을 통해 서버리스 배포 / 컨테이터, VM에 배포
Observability
- 여러 서비스에 걸친 클라이언트의 요청. 문제의 원인 파악 어려움
- 여러 패턴 필요
- 헬스 체크 API
- 로그 수집
- 분산 추적
- 예외 추적
- 애플리케이션 지표
- 감사 로깅
Testing
- 컨슈머 주도 계약 테스트(consumer-driven) : 클라이언트가 의도한 대로 서비스 동작 확인
- 컨슈머 쪽 계약 테스트(consumer-side) : 클라이언트와 서비스가 상호 통신 가능한지 확인
- 서비스 컴포넌트 테스트 : 서비스 개별 테스트
Cross cutting concerns
- Microservice Chassis 패턴 적용을 통한 공통 관심사 적용
보안 패턴
- API 게이트웨이가 일반적으로 identity, role 등 사용자 정보 인증 후 호출 서비스에 전달.
- 일반적으로 JWT 같은 액세스 토큰 패턴 적용
