194
이벤트 기반 마이크로서비스 구축
커를 통해 통신하므로 다른 서비스의 간헐적인 실패로부터 영향을 받지 않기 때문입니다.
●
재시도하는 장치가 내장돼 있어서 실패 시 재시도할 이벤트가 이벤트 스트림에 그대로 남
아 있습니다.
직접 호출 워크플로는,
●
이벤트 스트림에서 생산/소비하는 오버헤드가 없기 때문에 일반적으로 속도가 빠릅니다.
●
간헐적인 접속 문제를 오케스트레이터가 알아서 관리해야 합니다.
정리하면 모든 종속된 서비스가
SLA
범위 내에서 작동되는 경우에는 직접 호출, 즉 동기식 요
청-응답을 통한 워크플로가 이벤트 기반 워크플로보다 빠른 편입니다. 실시간 작업 등 아주 신
속한 응답이 필요한 곳에서는 아주 잘 동작하죠. 반면 이벤트 기반 워크플로에는 보존성이 더
좋은
I
/
O
스트림이 있고 속도는 상대적으로 느리지만 작업은 더 안정적이며, 특히 간헐적인 실
패를 아주 잘 처리합니다.
실제로는 이 두 가지 방법을 잘 짜맞춰 사용해야 할 경우가 많습니다. 이를테면 메인은 이벤트
기반 오케스트레이션 워크플로를 사용하고 외부
API
나 기존 서비스는 직접 요청-응답 호출을
사용하는 식입니다. 이렇게 두 가지 방법을 혼용할 때에는 각 서비스가 실패 시 예상대로 잘 처
리되는지 꼼꼼히 확인하세요.
8.2.4
오케스트레이션 워크플로의 생성과 수정
오케스트레이터는 각 입출력 이벤트 스트림과 요청-응답 결과를 구체화함으로써 워크플로에
서 이벤트를 추적합니다. 워크플로 자체가 오케스트레이션 서비스 내부에만 정의되므로 워크
플로를 한 군데서만 변경할 수 ...