[이벤트 기반 마이크로서비스 구축] Chapter8 마이크로서비스 워크플로 구축 - 미쉐린은 오케스트레이션을 버렸고, Netflix는 오케스트레이션을 만들었다

Chapter8 마이크로서비스 워크플로 구축

• 워크플로(작업 흐름/절차)란 논리적 분기, 보상 액션 등 비즈니스 프로세스를 구성하는 특정한 작업을 지칭한다. 

워크플로 구성할 때 고려해야 하는 항목 

• 워크플로 생성 및 수정
  • 워크플로 내부의 서비스들은 어떻게 서로 연관되는가?
  • 기존 워크플로를 수정할 때 다음과 같은 일들이 생기지 않도록 하려면 어떻게 해야 하나?
    • 이미 진행 중인 작업을 중단시킨다.
    • 여러 마이크로서비스를 변경해야 한다.
    • 모니터링과 가시성이 깨진다
• 워크플로 모니터링
  • 어떤 이벤트에 대해 워크플로가 언제 완료됐는지 어떻게 알 수 있나?
  • 이벤트 처리 도중 실패하거나 워크플로 어딘가에서 막혔는지 여부를 어떻게 판단할까?
  • 워크플로의 전체 상태는 어떻게 모니터링할 것인가?
• 분산 트랜잭션 구현
  • 대부분의 워크플로는 여러 액션이 함께 일어나거나 아무 액션도 일어나지 않아야 한다.
    분산 트랜잭션은 어떻게 구현할 것인가?
  • 분산 트랜잭션은 어떻게 롤백하나?
    
    

8.1 코레오그래피 패턴 choregraphed architecture(리액티브 아키텍쳐 reactive architecture)

• 고도로 분리된 마이크로서비스 아키텍쳐를 가리키는 용어
• 일체의 차단과 대기 없이 입력 이벤트가 도착하는 대로 반응
• 새로운 단계를 워크플로 끝부분에 쉽게 추가하는 것은 간단하지만 중간에 단계를 삽입하거나 워크플로우 순서 바꾸면 문제가 될 수 있다. 
• 개별적으로 분산되어 있어서 특정 이벤트의 진행 상황을 파악하기 어려운 경우가 많다. 

 

michelin 오케스트레이션 → 코레오그래피

Moving from orchestration to choreography - Part 3

One of the first challenge we faced was the absence of error handling; in case of something going wrong during the processing of an event, nothing would be able to "catch" the error. This discovery led to a first set of 
technical solutions, with the creation of a framework that would allow for the streaming process to continue without crashing, using a generic error-handling mechanism.

우리가 직면했던 첫 번째 과제 중 하나는 오류 처리의 부재였습니다. 이벤트 처리 중에 문제가 발생할 경우, 오류를 "포착"할 수 있는 방법이 없었습니다. 이러한 문제점을 발견하면서 일반적인 오류 처리 메커니즘을 사용하여 스트리밍 프로세스가 중단 없이 계속될 수 있도록 하는 프레임워크를 개발하는 초기 기술적 해결책을 마련하게 되었습니다.

 

The second axis came from our ambition: knowing that we had a couple hundreds micro-services ahead of us, it seemed vital to us to figure out how to standardize the code implementation , through factorization and an abstraction layer preventing common setup mistakes during development phase. This abstraction layer was integrated in the same framework mentioned previously, and allows us to fully implement a deployment-ready microservice in a matter of a few days, if not hours, versus a couple weeks at the beginning of the project. Here is the abstract class that each micro-service app inherits from:

두 번째 축은 우리의 야망에서 비롯되었습니다. 수백 개의 마이크로서비스를 개발해야 한다는 것을 알고 있었기에, 
코드 구현을 표준화하는 것이 매우 중요하다고 생각했습니다. 이를 위해 코드 분해(팩토링)와 추상화 계층을 구축하여 개발 단계에서 흔히 발생하는 설정 오류를 방지하고자 했습니다. 이 추상화 계층은 앞서 언급한 프레임워크에 통합되었으며, 프로젝트 초기에는 몇 주가 걸리던 작업을 이제는 며칠, 심지어 몇 시간 만에 배포 준비가 완료된 마이크로서비스를 구현할 수 있게 되었습니다. 다음은 각 마이크로서비스 앱이 상속받는 추상 클래스입니다.

 

The last axis was centered around a well known issue when dealing with multiple systems: 
how do we ensure non-regression without spending months in testing phases?

마지막 축은 여러 시스템을 다룰 때 발생하는 잘 알려진 문제, 즉 테스트 단계에 몇 달씩 소요하지 않고 회귀 오류를 방지하는 방법을 중심으로 했습니다.

 

 

8.2 오케스트레이션 패턴

• 중앙의 마이크로서비스가 하위 워커 마이크로 서비스에게 명령을 내린 뒤 응답을 기다린다. 
• 속도는 상대적으로 느리지만 작업은 더 안정적이고, 간헐적인 실패를 잘 처리한다. 
• 오케스트레이션 워크플로를 가시화할 수 있어 특정 이벤트의 진행 상황 및 워크플로에서 발생 가능한 이슈를 파악하기 쉽다. 

netflix 코레오그래피 → 오케스트레이션

Netflix Conductor: A microservices orchestrator

 

Process flows are “embedded” within the code of multiple applicationsOften, there is tight coupling and assumptions around input/output, SLAs etc, making it harder to adapt to changing needsAlmost no way to systematically answer “What is remaining for a movie’s setup to be complete”?

프로세스 흐름은 여러 애플리케이션의 코드 내에 "내장"되어 있습니다.종종 입력/출력에 대한 긴밀한 연관성과 가정이 존재합니다.SLAs등등으로 인해 변화하는 요구에 적응하기가 더욱 어려워집니다."영화의 설정이 완성되기 위해 남은 것은 무엇인가?"라는 질문에 체계적으로 답할 방법은 거의 없다.

 

출처 : 미슐랭 기술 블로그 https://blogit.michelin.io/choregraphy-or-orchestration-thats-the-question/

 

 

관련 내용을 한국 기술 블로그에서 찾아봤으나 (네이버 / 당근마켓 / 배달의민족 ) 정확히 그런 용어는 쓰지 않았음. 

https://techblog.woowahan.com/7835/

회원시스템 이벤트기반 아키텍처 구축하기 | 우아한형제들 기술블로그

 

https://tech.kakaopay.com/post/event-driven-architecture/

이벤트 드리븐 적재적소에 사용하기 | 카카오페이 기술 블로그

 

 

 

8.3 분산 트랜잭션

• 둘 이상의 마이크로서비스에 걸쳐있는 트랜잭션을 말한다. 
• 마이크로서비스는 각자 트랜잭션에서 자신의 분량을 처리하되 트랜잭션이 중단되어 되돌아갈 경우 처리한 내용을 되돌린다. 
• 이벤트 기반 아키텍쳐에서 분산 트랜잭션은 보통 사가라고하며, 코레오그래피 패턴이나 오케스트레이퍼 패턴으로 구현한다. 
• 사가 패턴에서는 참여하는 마이크로 서비스가 각자 트랜잭션에서 자신이 처리한 분량을 알아서 돌려야 한다.