[이벤트 기반 마이크로서비스 구축] Chapter1. 왜 이벤트 기반 마이크로서비스인가?

https://product.kyobobook.co.kr/detail/S000001810379

이벤트 기반 마이크로서비스 구축 | 애덤 벨메어 - 교보문고

 

 

Chapter1. 왜 이벤트 기반 마이크로서비스인가?

 

1.1 이벤트 기반 마이크로서비스란 ?

• 서비스는 입력 이벤트 스트림에서 이벤트를 받아 특정한 비즈니스 로직을 적용한 다음, 출력 이벤트를 내보내서 요청-응답 접근에 필요한 데이터를 제공하거나 서드파티 API와의 통신, 또는 다른 필요한 일을 수행한다. 
• 이벤트를 소비해도 메시지를 전달한 시스템에서 바로 사라지는 건 아니고 같은 메시지를 필요로 하는 다른 컨슈머도 가져갈 수 있게 보존한다. 

 

1.2 도메인 주도 설계와 경계 콘텍스트

경계 콘텍스트 (bounded context)

• 입력, 출력, 이벤트, 요건 프로세스, 데이터 모델 등 하위 도메인과 연관된 논리적 경계
• 경계 콘텍스트와 하위 도메인이 완벽히 일치하면 이상적이겠지만, 레거시 시스템과 기술 부채, 서드 파티 시스템 연계로 예외적인 경우가 많다.
• 경계 콘텍스트는 응집력이 강해야 한다. 
  • 내부 기능은 집약적이고 깊이 연관되어 있고, 대부분의 통신이 경계를 넘나들지 않고 내부에서만 일어나야 한다. 
  • 할 일이 고도로 응집되어 있으면 그만큼 설계 범위가 좁혀지고 구현하기도 간단해진다. 

 

1.2.2 비즈니스 요건에 따라 경계 콘텍스트 조정

• 비즈니스 요건 변경에 맞추면 팀별로 느슨하게 결합하며 고도로 응집된 마이크로 서비스 구현체를 바꿀 수 있다. 
• 기술 요건에 맞추면  여러 경계 콘텍스트에 걸쳐 비즈니스 기능을 수행할 책임이 여러 팀으로 분산돼서 제각기 다른 스케줄로 다른 업무를 진행하게 된다. 

 

1.5 이벤트 기반 통신 구조 

1.5.1 이벤트는 통신의 근간이다.
1.5.2 이벤트 스트림은 단일 진실 동급원이다. 
1.5.3 컨슈머가 스스로 모델링과 쿼리를 수행한다. 

• 컨슈커는 여러 이벤트 스트림에서 들어온 데이터를 혼합하거나 특별한 쿼리를 하거나 특정한 비즈니스 로직을 적용하는 일을 전담한다. 
  • 예전 구조라면, 프로듀서/컨슈머 모두 쿼리 메커니즘, 데이터 전송 메커니즘, API, 전체 팀 서비스를 상대로 데이터 통신 수단을 제공해야 했지만 이제는 각자 맡은 경계 콘텍스트 니즈를 해결하는 일을 책임지면 된다. 

1.5.4 조직 전반적으로 데이터 통신이 원할해진다. 
1.5.5 접근 가능한 데이터 덕분에 비즈니스 통신 변경이 가능하다. 

 

1.6 비동기식 이벤트 기반 마이크로서비스

• 세분성 granularity
  • 서비스가 경계 콘텍스트에 알맞게 매칭되고 비즈니스 요건이 바뀌어도 쉽게 재작성할 수 있다. 
• 확장성 scalability
  • 개별 서비스는 필요시 규모를 늘리거나 줄일 수 있다. 
• 기술 유연성(technological flexibility)
  • 서비스마다 가장 적합한 언어와 기술로 구현할 수 있고 첨단 기술을 적용해서 쉽게 프로토 타이핑 prototyping 할 수 있다.
• 비즈니스 요건 유연성(business requirement flexibility)
  • 단위가 작은 마이크로서비스는 소유권을 재조정하기 쉽다.
• 느슨한 결합(loosely coupling)
  • 이벤트 기반 마이크로서비스는 도메인 데이터와 결합할 뿐, 어떤 특정한 구현 API에 구애받지 않는다.
• 지속적 전달 지원(continuous delivery support)
  • 작은 모듈로 나눈 마이크로서비스는 옮기기 쉽고 필요시 간편하게 롤백할 수 있다..
• 우수한 시험성(high testability)
  마이크로서비스는 덩치 큰 모놀리스보다 디펜던시 dependency가 적어서 필요한 테스트 엔드포인트를 모킹 mocking (모의)하고 코드 커버리지를 적절히 유지하기 쉽다.

 

1.7 동기식 마이크로서비스

1.7.1 동기식 마이크로서비스의 단점

• 점대점 결합
  
  • 의존 관계가 넓게 퍼지면 어떤 서비스가 어떤 비즈니스 로직 담당하는지 파악하기 어려워진다. 
• 의존적 확장
• 서비스 실패 처리
• API 버저닝과 디펜던시 관리
• 데이터 접근이 구현체에 종속된다.
• 분산 모놀리스
• 통합 테스트를 수행하기 어렵다. 

1.7.2 동기식 마이크로 서비스의 장점

• 사용자 인증, A/B 테스트 같은 데이터 접근 패턴은 직접 요청/응답을 주고받는 방식이 더 유리하다. 
• 여러 시스템에 걸쳐 작업을 추적하기 용이하다. 

 

 

도메인 vs 경계 콘텍스트

1. 문제 공간 vs 해결 공간

• 도메인 (Problem Space): 비즈니스의 '영역' 그자체. 예를 들어 "쇼핑몰 서비스를 만들자"라고 하면 쇼핑몰 자체가 도메인이다. 그 안에는 결제, 배송, 상품 관리 같은 하위 도메인들이 존재한다.
• 경계 콘텍스트 (Solution Space): 그 도메인의 문제를 해결하기 위해 우리가 '실제로 구현한 소프트웨어의 경계'인다.

2. 비유: 국토와 행정구역

• 도메인 (국토): 우리가 살고 있는 땅 그 자체. 산이 있고 강이 있는 자연적인 지형이다.
• 경계 콘텍스트 (행정구역): 그 땅을 효율적으로 관리하기 위해 인간이 그어놓은 '선'. 경기도, 서울시처럼 선을 긋고 각기 다른 법규(비즈니스 로직)를 적용하는 것과 같다.