1장. 모놀리식 지옥에서 벗어나라

1장의 핵심 내용

• 모놀리식 지옥 도래 조짐, 마이크로서비스 아키텍처 도입을 통해 벗어나는 방법
• 마이크로서비스 아키텍처의 주요 특징, 장단점
• 크고 복잡한 애플리케이션을 데브옵스 스타일로 개발하는 방법
• 마이크로서비스 아키텍처 패턴 언어 사용 이유

모놀리식 아키텍처 장점

• 개발이 간단함
• 애플리케이션 쉽게 변경 가능
• 테스트 쉬움
• 배포 쉬움
• 확장 쉬움

영원한 장점일까?

• 시간이 지날수록 복잡성이 증가할 수밖에 없음 : 점점 복잡해지는 의존성
• 개발 생산성 저하 : 실행, 빌드 소요 시간 증가
• 배포 어려움 증대 : 커밋 병합, 배포 어려움 발생. 테스트 시간 증가.
• 확장 어려움 : 애플리케이션 모듈 별 사용 리소스가 다른 경우 서버 리소스 구성에 고려할 점이 많아 확장 어려움 존재.
• 신뢰성 하락 : 테스트 어려움 발생 -> 버그 발생 증가. 동일 프로세스 상 실행되어 결함 격리 불가. 메모리 누수 발생 시 전체 애플리케이션에 영향
• 기술 스택 교체 어려움

마이크로서비스?

크기에 중점을 두기에는 애매모호.
경계 컨텍스트가 있는, 느슨하게 결합된 엘리먼트로 구성된 서비스 지향 아키텍처

3차원 확장 모델 : 확장 큐브

1. X축 : 다중 인스턴스에 고루 요청 분산

인스턴스 N 개 + 앞 단에 부하 분산기 : 부하 분산기로 들어온 요청을 각 인스턴스에 고루 분배

2. Z축 : 요청 속성별 라우팅

eg) 각 인스턴스는 자신에게 배정된 사용자 하위 집합만 처리

3. Y축 : 기능에 따라 애플리케이션을 서비스로 분해

X, Z축 확장의 한계 : 서비스의 복잡도는 줄여주지 못함
하나의 애플리케이션을 여러 서비스로 기능 분해하는 아키텍처 스타일 : 중요한 것은 각 서비스가 집중된/응집된 책임을 맡고 있음

마이크로서비스

• 모듈성 : 서비스를 모듈성의 단위로 사용. 각 서비스 간의 경계로 인해 모듈성 유지 가능. + 부가적으로 독립적 배포/확장 가능
• 서비스마다 별도 DB 사용 : 각 서비스 담당자가 스키마 외부 영향도 고려 없이 변경 가능. DB 락에 의한 서비스 블로킹 케이스 발생 X.

마이크로서비스 vs SOA

마이크로서비스 장단점

장점

• 크고 복잡한 애플리케이션을 지속 전달/배포 가능
  • 테스트성 : 자동화된 테스트. 상대적으로 작은 크기의 테스트.
  • 배포성 : 독립적 배포 가능.
  • 자율성, 느슨한 결합
• 서비스 규모가 작아 관리 용이 : 비교적 적은 코드로 이해하기 쉬움. IDE, 실행 속도 등 더 빠름.
• 서비스를 독립적으로 배포/확장
• 팀이 자율적으로 움직일 수 있음
• 결함 격리 용이
• 신기술 실험 및 도입 용이

단점

• 딱 맞는 서비스를 찾기 쉽지 않음
• 분산 시스템은 너무 복잡해서 개발, 테스트, 배포 어려움
  • 사용 불능, latency 등 문제 발생에 대한 처리 가능 설계 필요
  • 다중 DB 접속, 조회, 트랜잭션 구현 => 사가 통한 데이터 일관성 유지
  • 여러 서비스의 데이터 조회 : API 조합 또는 CQRS 뷰 쿼리
  • 운영 복잡도 : 자동화 배포 툴 필요 (spinnaker, k8s 등)
• 여러 서비스에 걸친 기능을 배포할 때에는 잘 조정해야
  • 세밀한 배포 계획 수립 필요
• 마이크로서비스 아키텍처 도입 시점 결정 어려움

마이크로서비스 아키텍처 패턴 언어

왜 필자는 패턴 언어를 강조하는가? 자신의 감정을 극복한 상태에서 기술을 논할 수 있어야 함. 그러기 위해 패턴 포맷으로 기술을 객관적 기술.

상용 패턴의 구조

1. 강제조항 : 문제 해결을 위해 반드시 처리해야 할 이슈

• 충돌하는 조항도 있을 수 있음. 우선 순위에 따라 고려

2. 결과 맥락 : 패턴 적용 결과

• 장점, 단점, 이슈 세 부분으로 기술
  • 장점 : 해결된 강제 조항 등
  • 단점 : 미해결 강제 조항 등
  • 이슈 : 새롭게 발견된 문제점

3. 연관 패턴 : 다섯 가지 관계 유형

한 패턴과 다른 패턴 관계 기술

1. 선행자 : 이 패턴을 필요하게 만든 선행 패턴
2. 후행자 : 이 패턴으로 야기된 이슈를 해결하는 패턴
   • eg) 마이크로서비스 아키택처 패턴의 후행자 : 서비스 디스커버리 패턴, 서킷 브레이커 패턴 등
3. 대안 : 이 패턴의 대체 솔루선을 제공하는 패턴
   • 모놀리식 vs 마이크로서비스
4. 일반화 : 문제를 해결하는 일반적인 솔루션 해당 패턴
5. 세분화 : 특정 패턴은 더 세부적으로 나타낸 형태

마이크로서비스 아키텍처 패턴 언어 개요

분해 패턴(Decomposition) : 대안 관계의 두 패턴

1. 비즈니스 능력에 따라 분해
2. 하위 도메인에 따라 분해

통신 패턴(Communication)

• Communication style : 어떤 종류의 프로세스 간 통신(IPC) 사용?
• Discovery : 서비스 클라이언트는 서비스 인스턴스의 IP주소 어떻게 조회
• Reliability : 서비스 불능 시 서비스 간 통신의 신뢰성 어떻게 보장
• Transactional messaging : DB 트랜잭션에 메시지 송신 및 이벤트 발행 어떻게 통합
• 외부 API : 애플리케이션 클라이언트는 서비스와 어떻게 통신

Maintaining data consistency

서비스마다 자체 DB를 갖게됨. 기존 분산 트랜잭션(2PC) -> 사가 패턴 통해 데이터 일관성 유지

Querying

DB 분리로 인한 데이터 조인 쿼리 문제 발생.

• API 조합 패턴 : 하나 이상의 서비스를 호출해서 그 결과 조합
• CQRS : 하나 이상의 데이터 레플리카를 유지해서 쉽게 쿼리하는 방식

Deployment

• 서비스 배포 플랫폼을 통해 서버리스 배포 / 컨테이터, VM에 배포

Observability

• 여러 서비스에 걸친 클라이언트의 요청. 문제의 원인 파악 어려움
• 여러 패턴 필요
  1. 헬스 체크 API
  2. 로그 수집
  3. 분산 추적
  4. 예외 추적
  5. 애플리케이션 지표
  6. 감사 로깅

Testing

1. 컨슈머 주도 계약 테스트(consumer-driven) : 클라이언트가 의도한 대로 서비스 동작 확인
2. 컨슈머 쪽 계약 테스트(consumer-side) : 클라이언트와 서비스가 상호 통신 가능한지 확인
3. 서비스 컴포넌트 테스트 : 서비스 개별 테스트

Cross cutting concerns

• Microservice Chassis 패턴 적용을 통한 공통 관심사 적용

보안 패턴

• API 게이트웨이가 일반적으로 identity, role 등 사용자 정보 인증 후 호출 서비스에 전달.
• 일반적으로 JWT 같은 액세스 토큰 패턴 적용

참조

• https://microservices.io/patterns/index.html