[이벤트 기반 마이크로서비스 구축] Chapter13. 이벤트 기반 마이크로서비스와 요청-응답 마이크로서비스의 통합

13. 이벤트 기반 마이크로서비스와 요청-응답 마이크로서비스의 통합

 

13.1 외부 이벤트 처리

- 외부에서 생성된 이벤트는 크게 두 종류로 나뉜다.

ㄴ 자율적으로 생성된 이벤트

ㄴ 반응하여 생성된 이벤트

 

13.1.1 자율적으로 생성된 이벤트

- 주기적인 상태 측정이나 센서가 읽어들인 값 또는 사용자가 하고 있는 일에 관한 정보를 메트릭 형태로 수집한 이벤트

ex, 넷플릭스 같은 미디어 스트리밍 서비스는 가입자가 어떤 영화를 보기 시작했는지, 얼마나 오래 보았는지 등을 측정하기 위해 분석 이벤트를 독립적으로 수집한다. 

 

13.1.2 반응하여 생성된 이벤트

- 어떤 서비스의 요청에 반응하여 생성된 이벤트로 서비스는 요청을 만들어 엔드포인트로 보낸 다음 응답을 기다리게 된다.

- 경우에 따라 클라이언트 입장에서 요청이 수신됐다는 사실만 중요할 뿐 자세한 응답 내용은 필요하지 않을 수도 있다. 

 

13.2 자율적으로 생성된 분석 이벤트 처리 

- 분석 이벤트는 한데 모아 주기적으로 전송하거나 발생 즉시 전송한다. 

- 외부 클라이언트 애플리케이션은 분석 이벤트 수신기 서비스로 보내고 이 서비스는 다시 해당 출력 이벤트 스트림으로 이벤트를 전달한다. 

 

13.3 서드파티 요청-응답 API 연계 

- 마이크로서비스는 이벤트기반의 로직에 따라 API를 호출한 뒤 응답을 기다리고 응답이 도착하면 파싱해서 해당 스키마를 준수하는지 확인한 다음, 어느 이벤트 처리와 마찬가지로 비즈니스 로직을 적용한다. 

- 장점으로 첫째, 비즈니스 로직을 적용하는 동안 요청-응답 API와 이벤트 처리를 혼합할 수 있고 둘째, 서비스는 필요한 모든 API를 호출할 수 있고, 병렬 처리도 가능하다. 

- 단점으로는 외부 서비스에 요청하면 결국 워크플로우에 비확정적인 요소가 스며들어 실패한 이벤트 재처리하면 처음에 호출했던 것과 결과가 달라질 수 있다. 

 

13.4 상태 저장 데이터 처리 및 서비스

13.4.1 내부 상태 저장소를 이용해 실시간 요청 처리 

- 마이크로서비스는 자신의 내부 상태에서 소싱한 결과를 제공할 수 있다. 

- 클라이언트 요청이 로드 밸런서로 전달되면 로드 밸런서는 이 요청을 하부 마이크로서비스 인스턴스 중에서 하나로 보내게 된다. 

 

- 모든 내부 상태는 키에 따라 샤딩되며 키 있는 값은 오직 하나의 파티션에만 할당된다. 

ㄴ 키는 단일 파티션에만 매핑된다.

ㄴ 파티션은 하나의 컨슈머 인스턴스에만 할당된다. 

 

13.4.2 외부 상태 저장소를 이용해 실시간 요청 처리

- 내부 상태 저장소 대신 외부 상태 저장소를 이용하면 두 가지 장점이 있다. 

ㄴ 첫째, 각 인스턴스가 모든 상태를 사용할 수 있다 = 내부 스토리지 모델에 따라 데이터를 호스팅하는 마이크로서비스로 요청을 전달할 필요가 없다.

ㄴ 둘째, 모든 상태는 인스턴스 외부에 유지되므로 컨슈머 그룹 리밸런스가 일어나도 마이크로서비스가 새 인스턴스에 내부 상태를 다시 구체화할 필요가 없다. 

 

- 이벤트 기반 마이크로 서비스를 구체화하여 요청 처리 

 

- 별도 마이크로 서비스를 통해 요청 처리 

 

13.5 이벤트 기반 워크플로 내에서 요청 처리

- 왼쪽 그림은 객체를 생성하고 DB에 직접 기록하는 저농적인 방식,

- 오른쪽 그림은 먼저 요청을 이벤트로 파싱하여 해당 이벤트 스트림에 발행한 다음, 이벤트 기반 워크플로우가 이벤트를 소비하기 전에 비즈니스 로직을 적용해서 DB에 저장하는 이벤트 우선 방식이다. 

ㄴ 이벤트를 우선 이벤트 소비에 기록하면 모든 서비스가 이 데이터를 구체화하여 쓸 수 있다는 장점이 있지만 그만큼 지연이 발생하고 서비스가 결과를 사용하려면 데이터 저장소에 구체화될 때까지 기다려야 한다는 단점도 있다. 

 

13.5.1 UI 이벤트 처리 

- 요청을 이벤트로 처리하는 애플리케이션은 반드시 비동기 UI를 포함하도록 설계해야 한다. 

ㄴ ex, '잠시 기다려주세요' 

- 사용자의 추가 입력을 기다리는 와중에도 계속 유입되는 비사용자 이벤트를 마이크로 서비스가 처리해야 한다. 

- ex, 신문 발행 워크플로 (승인 패턴) 

ㄴ 신문 편집기 마이크로서비스는 조판, 광고, 기사 스트림을 받아 관계형 DB에 넣는다. 

ㄴ 조판 담당자가 작업을 마치고 신문을 승인 요청할 준비가 되면 편집된 신문을 PDF파일에 넣고 편집된 신문 스트림을 생산한다. 

ㄴ 승인은 별개의 마이크로 서비스가 실행한다. 

ㄴ 편집자 승인 서비스와 광고주 승인 서비스를 분리해야 한다는 비즈니스 요건이 생긴다면 ? 

 

 

13.6 요청-응답 애플리케이션과 마이크로프런트앤드

- 프론트앤드/백엔드 서비스는 크게 세 가지 방식으로 비즈니스 가치를 제공한다.

ㄴ 모놀리식 벡엔드는 조직 규모에 상관없이 일반적이다.

ㄴ 마이크로서비스 백엔드는 동기식 이벤트 기반의 마이크로 서비스를 점점 더 많이 사용하면서 인기를 얻고 있다. 

ㄴ 마이크로프런트앤드는 백엔드부터 프론트엔드까지 모든 구현을 완전히 비즈니스 관심에 맞춘다. 

 

13.7 마이크로프런트앤드의 장점

- 조합형 마이크로 서비스

ㄴ 일종의 조합형 패턴이라 기존 UI에 필요한 만큼 서비스를 추가할 수 있다. 

- 비즈니스 요건에 맞추기 쉽다. 

 

13.8 마이크로프런트앤드의 단점

- UI 엘리먼트와 스타일의 일관성이 어긋날 수 있다. 

- 복합적인 프레임워크의 조각들이라 성능이 일관적이지 않을 수 있다.