마이크로서비스를 위한 이벤트 기반 디자인 패턴 이해하기

우리가 사용할 기본 기술은 이벤트 기반 애플리케이션에 적합한 오픈 소스 분산 스트리밍 플랫폼인 Apache Kafka 입니다. Apache Kafka 주변의 애플리케이션 개발을 위한 오픈 소스 도구를 사용하면 이 기사 전체에서 언급된 모든 개념을 구현할 수 있습니다.

이벤트 기반 프리미티브

네트워크를 통해 분산 시스템에서 발생하는 모든 상호 작용은 이벤트 , 명령 및 쿼리 의 세 가지 기본 유형 으로 분류할 수 있습니다 .

이벤트 기반 시스템에 대해 이야기할 때 이러한 구분은 메시지 전송 이면의 의도를 표현하는 데 도움이 됩니다.

이벤트

시스템이 작업을 수행할 때마다 해당 사실의 관찰을 포함하는 메시지를 이벤트라고 합니다.

이벤트는 로그 항목과 같이 "무언가가 발생했습니다"라는 일반 정보로 생각할 수 있습니다. 관찰 가능한 사실. 이벤트 는 부작용을 유발할 수도 있고 그렇지 않을 수도 있습니다 .

이벤트에는 두 가지 기본 기능이 있습니다.

• 그것들은 시스템 어딘가에서 부작용 을 유발 합니다.
• 그들 은 또한 임의 데이터 의 캐리어 입니다 .

순수한 정보와 마찬가지로 이벤트는 수행할 향후 작업이나 반환될 응답에 대한 기대를 반드시 포함하지는 않지만 데이터는 계속 전달할 수 있습니다. 우리는 이 이중성을 활용하여 매우 다르지만 강력한 두 가지 이벤트 기반 패턴을 구별하는 방법을 나중에 보게 될 것입니다.

명령

메시지가 시스템의 내부 상태를 변경한다는 기대를 전달할 때마다 해당 메시지는 명령입니다.

명령은 권위 있는 방식으로 수행할 특정 작업이 있음을 시스템에 알리는 데 사용됩니다. 그들은 반드시 부작용을 유발합니다 .

명령은 이벤트와 매우 유사합니다. 실제로 일부 구현에서는 실제로 구별할 수 없습니다. 그러나 의사 소통 의도의 명확한 차이가 차이를 만듭니다.

명령과 이벤트 를 혼동하는 것은 이벤트 기반 시스템을 디버깅하는 데 어려움을 주는 안티 패턴 입니다!

쿼리

시스템이 내부 상태를 검색하여 호출자에게 제공해야 할 때마다 그렇게 하기 위한 요청을 쿼리라고 합니다.

쿼리를 처리하는 것은 시스템에 어떠한 부작용도 전혀 없습니다.

쿼리에는 본질적으로 동기 응답이 필요합니다. 쿼리는 HTTP GET 요청 또는 데이터베이스 쿼리와 비교할 수 있습니다. 특정 구현에서는 정확히 그렇습니다.

이벤트 기반 디자인 패턴

이제 우리는 이벤트 기반 시스템(사실상 다른 분산 시스템에서)에서 발생할 수 있는 모든 유형의 상호 작용을 이해합니다.

4가지 기본 디자인 패턴에 대해 바로 알아보자!

주목할 가치가 있습니다:

확인된 이벤트 기반 시스템의 대부분은 그 중 하나 이상을 사용합니다. Martin Fowler

... 실제로 시스템은 대부분의 경우 한 번에 많은 패턴을 사용할 수 있고 사용합니다.

이벤트 알림

Event Store에서 촉진하는 이벤트 중심의 커뮤니케이션을 설명하는 가장 기본적인 패턴입니다. 이벤트 트리거 기능을 포함합니다 .

이벤트 저장소를 통한 반응, 비동기 및 위치 투명 통신 촉진.

서비스가 서로 전혀 통신하지 않는 마이크로서비스 아키텍처를 상상해 보십시오. 사실, 그들은 다른 서비스가 있는지조차 모릅니다.

대신, 그들은 무언가가 필요하거나 무언가를 전달하고 싶을 때 비동기식 이벤트를 발생시킵니다. 이러한 이벤트 는 이벤트를 스트림으로 저장 하는 이벤트 저장소 라고 하는 중앙 엔터티인 한 곳에서만 끝납니다 .

모든 마이크로서비스는 이러한 스트림을 구독하고 이러한 이벤트를 알림으로 수신할 수 있습니다. 그런 다음 그들은 이러한 알림에 적절하게 반응합니다. 대부분의 경우 다른 마이크로서비스에서 선택하는 더 많은 이벤트를 생성하여 방대하고 광범위하며 아름다운 안무를 만듭니다. 이것은 이벤트 알림 패턴의 핵심입니다.

장점:

• 위치 투명성은 소비자와 생산자의 존재를 구식으로 만들어 시스템 탄력성을 높입니다. 즉, 마이크로 서비스 또는 장치 중 하나가 꺼지더라도 시스템 내의 통신은 최종적으로 일관된 방식으로 적절하게 처리됩니다 .
• 데이터 통합을 쉽게 만드는 뛰어난 시스템 플러그 기능. 새로운 마이크로서비스는 누가 이벤트를 생성하든 상관없이 이벤트를 소비합니다. 이벤트 저장소는 궁극적인 진실 소스입니다 . 마이크로서비스는 확장 가능한 아키텍처의 플러그형 빌딩 블록이 됩니다.
• 특히 마이크로서비스의 세계에서 이러한 구성 요소의 캡슐화는 매우 바람직하며 시스템이 더 복잡해지면 점점 더 중요해집니다.

단점:

• 이벤트 알림 패턴은 단순함에서 오는 주요 단점이 있습니다. 처리 흐름이 시간이 지남에 따라 여러 이벤트 알림에 걸쳐 있는 흐름의 복잡성이 증가합니다. 이를 위해서는 지속적인 모니터링이 필요하며 디버깅이 다소 어렵습니다.
• 수동-공격적 이벤트를 명령으로 착각하면 시스템 아키텍처에 대해 추론할 때 혼란을 초래할 수 있습니다. 이로 인해 외부 소비를 위한 것이 아닌 알림에 대한 결합이 발생하여 부적절한 데이터 결합으로 인한 구성 요소 오류가 발생합니다.

이벤트 수행 상태 이전

이벤트 의 데이터 기능 을 활용한 패턴 . 이는 데이터의 출처 가 이벤트 저장소 인 경우에만 달성할 수 있습니다 .

이벤트의 비동기식 소비를 통한 애플리케이션 상태의 지속적인 복제.

Event Store를 구독하는 마이크로서비스는 팔로우하는 스트림의 변경 사항에 대한 알림을 받습니다. 이러한 스트림에 상태 데이터가 포함되어 있으면 이 데이터도 끌어옵니다.

데이터는 배포된 마이크로서비스 자체 데이터 저장소 내부에 로컬로 저장됩니다. 보다 복잡한 데이터 집계를 저장하기 위해 여러 이벤트 스트림을 구성하여 보다 정교한 데이터 흐름을 생성할 수 있습니다.

원격 데이터 원본에서 데이터를 검색하는 대신 마이크로 서비스는 이제 로컬 저장소에 복제해야 하는 모든 데이터를 보유합니다. Query가 들어오는 경우 해당 데이터를 즉시 저렴하게 검색할 수 있습니다.

장점:

• 마이크로 서비스는 완전히 자율적입니다. 모든 서비스에 수명 기간 동안 필요한 모든 필수 데이터의 복사본이 포함되어 있으면 서비스 간 쿼리가 중복됩니다.
• 데이터는 오프라인으로 액세스할 수 있으므로 네트워크를 사용할 수 없을 때 복제된 데이터를 활용하고 온라인 상태가 된 후 이벤트 저장소와 동기화할 수 있습니다.

단점:

• 대량 복제에는 많은 메모리가 필요하지만 Martin Fowler가 말했듯이 오늘날의 세계에서는 데이터 저장소가 풍부합니다.
• 서비스 전반에 걸친 데이터 일관성과 일관성은 문제를 제기할 수 있으므로 개발자는 적시성 및 충돌과 같은 최종 일관성 문제를 고려해야 합니다.

이벤트 소싱

이벤트는 모든 이벤트 기반 소프트웨어 시스템의 핵심입니다. 애플리케이션 상태에 대한 모든 변경은 반드시 이벤트에 의해 시작됩니다. 따라서 이벤트 저장소는 시스템이 과거에 수행한 상태 저장 작업에 대한 정보를 포함 하는 Source of Truth 의 기능에서 데이터베이스를 대체합니다 .

이를 통해 클린 빌드에서 지속 이벤트 시퀀스를 재생하여 애플리케이션 상태를 임의의 시점으로 유연하게 재구성할 수 있습니다.

역사적 시스템 상태의 주문형 재구성을 위한 이벤트 기반 운영을 통한 상태의 중앙 집중화.

이 패턴 은 이벤트의 트리거링 및 데이터 기능을 모두 사용하여 애플리케이션 상태 변경 체인을 호출하고 시스템의 모든 구성 요소에 이벤트로 표시되는 완전한 필수 데이터 세트와 함께 이러한 변경 사항을 제공합니다.

이 기능은 개발자가 잘못된 이벤트를 조사하고 비정상적인 동작을 보다 정확하게 모니터링할 수 있도록 하여 디버깅 및 이상 감지에 강력합니다.

잘못된 이벤트의 결과를 계산할 수 있으며, 애플리케이션 상태는 이를 역전시키고 이후의 모든 이벤트를 수정하고 잘못된 이벤트를 수정하고 이벤트를 다시 재생함으로써 수정됩니다.

장점:

• 이벤트 소싱 은 안정적인 감사 로그에서 상태 변경에 대한 완전한 감사를 보존하여 마이크로서비스 기반 아키텍처에서 일반적으로 발견되는 데이터 일관성 문제를 해결합니다 .
• 더욱이 이 패턴은 이벤트 저장소의 이벤트 스트림에서 직접 시스템 상태 보기를 파생함으로써 데이터 발산 및 중복과 같은 상호 종속적인 분산 시스템 간의 일부 고전적인 데이터 일관성 문제를 해결합니다(보기 구체화로 알려진 개념).
• 따라서 데이터베이스는 시스템의 궁극적인 진실 소스 인 이벤트 저장소를 기반으로 구축된 임시 보기이기 때문에 이 패턴은 지속성 불가지론적 입니다.

단점:

• Event Sourced 시스템으로 작업하는 것은 대부분의 개발자에게 익숙하지 않으며 이벤트, 특히 나쁜 이벤트로 작업하는 것은 시간이 많이 걸릴 수 있습니다.
• Event Sourcing을 사용하지 않는 시스템과의 통합도 매우 어렵습니다.
• 마지막으로, 이벤트 스키마가 시간이 지남에 따라 변경되고 일부 구현에서는 버전 관리 문제가 발생하므로 다시 작성하기가 훨씬 더 어려워집니다.

명령 쿼리 책임 분리

CQRS는 이벤트 소싱의 자연스러운 진행으로, 각각의 명령과 쿼리를 입력으로 분리하고 두 모델을 내부적으로 이벤트 저장소와 연결하여 시스템을 WRITE 및 READ 모델로 나눕니다.

이벤트를 사용하여 비동기 방식으로 시스템 동작을 분리하여 단방향 데이터 흐름을 달성합니다.

WRITE 모델은 외부에서 오는 명령을 사용하여 이벤트 알림 을 통해 작업을 평가하고 수행하는 일련의 이벤트를 트리거 합니다. 상태 변경 사항은 이벤트 저장소 내에서 완전한 형태로 보존됩니다.

요청이 완료되면 최종 알림은 시스템 상태가 변경되었음을 관심 서비스에 나타냅니다. Event-Carried State Transfer 패턴에 따라 서비스는 알림에 대한 반응으로 로컬 저장소의 변경 사항을 유지할 수 있습니다.

READ 모델은 언급된 로컬 저장소를 사용하여 쿼리를 처리하고 응답하는 역할을 합니다. 원칙적으로 이 패턴은 고전적인 요청-응답 스타일 대신 읽기와 독립적으로 쓰기를 수행할 수 있는 비동기 메시지 전달을 사용합니다.

장점:

• 기존의 요청-응답 통신 방식에 비해 전반적인 성능이 더 좋습니다.
• 특정 사용 사례에 가장 적합한 방식으로 모델을 독립적으로 배포하고 확장할 수 있습니다.
• 읽기 쪽은 데이터 유형에 대해 가장 합리적인 데이터베이스를 선택하거나 원하는 용도에 더 나은 성능을 보여주는 여러 쿼리 모델을 사용하여 추가로 최적화할 수 있습니다.

단점:

• 패턴을 사용하는 동안 존재하는 비동기 처리는 시스템의 복잡성을 가중시키며, 이는 일부 개발자와 설계자에게 어려울 수 있습니다.
• 시스템 구성 요소는 결국 일관성 을 갖게 되며, 이는 디버깅에 특정 어려움을 수반합니다.

출처 : https://levelup.gitconnected.com/understanding-event-driven-design-patterns-for-microservices-659b3c9fb51f