이벤트 기반 마이크로서비스 기반 시스템에 대한 아키텍처 고려 사항

이벤트 기반 아키텍처 및 마이크로서비스 아키텍처 개요

EDA(Event-Driven Architecture) 는 오래전부터 존재해 왔습니다. 클라우드, 마이크로서비스, 서버리스 프로그래밍 패러다임과 정교한 개발 프레임워크는 미션 크리티컬 비즈니스 문제를 실시간으로 해결하는 데 EDA의 적용 가능성을 높이고 있습니다. Kafka , IBM Cloud Pak for Integration 및 Lightbend 와 같은 기술 및 플랫폼과 Spring Cloud Stream , Quarkus 및 Camel 과 같은 개발 프레임워크는 모두 EDA 개발에 대한 최고 수준의 지원을 제공합니다. EDA는 또한 실시간 인공 지능 또는 기계 학습 솔루션 개발에 필요한 스트리밍 데이터 처리 를 위해 확장됩니다. 기사 "이벤트 기반 아키텍처의 장점 ”에서는 EDA를 정의하고 개발자가 EDA를 사용해야 하는 이유를 설명합니다.

마이크로서비스 아키텍처 는 모놀리식 애플리케이션을 도메인 기반 설계를 사용하여 식별되는 독립적이고 독립적으로 배포된 서비스로 분할하는 변환 프로젝트에서 널리 채택되고 사용됩니다. 마이크로서비스 아키텍처와 그 특성에 대한 좋은 소개는 Martin Fowler & James Lewis 기사 에서 찾을 수 있습니다 . 마이크로서비스는 API를 노출하고 EDA와 원활하게 통합하기 위해 이벤트를 생성 및 소비하기 위한 인터페이스를 가질 수 있습니다. 많은 특성으로 인해 EDA와 결합하기에 좋은 후보입니다. " 마이크로 서비스 아키텍처 스타일의 과제 및 이점 " 기사에서는 개발자가 마이크로 서비스를 구현할 때 직면하는 과제에 대해 설명합니다.

다음 표에서는 이러한 두 가지 아키텍처 스타일이 서로를 어떻게 보완하는지 보여줍니다.

EDA	마이크로서비스 아키텍처
구성 요소/서비스 간의 느슨한 결합	관심사의 분리를 제공하는 경계 컨텍스트
개별 구성 요소를 확장하는 기능	독립적으로 배포 및 확장 가능
처리 구성 요소는 서로 독립적으로 개발될 수 있습니다.	다국어 프로그래밍 지원
높은 클라우드 친화도	클라우드 네이티브
비동기 특성. 워크로드를 조절하는 기능뿐만 아니라	탄력적인 확장성
내결함성 및 복원력 향상	장애를 신속하게 감지하는 우수한 관찰성
프로세싱 파이프라인 구축 능력	본질적으로 진화하는
정교한 이벤트 브로커의 가용성으로 코드 복잡성 감소	흔히 라고 하는 재사용 가능한 표준 기술 서비스 세트MicroServices Chassis
입증된 엔터프라이즈 통합 패턴 의 풍부한 미각	재사용 가능한 구현 패턴 의 풍부한 저장소 제공

이 두 가지 아키텍처 스타일을 결합하여 개발자는 확장성, 가용성, 내결함성 및 확장성이 뛰어난 분산 시스템을 구축할 수 있습니다. 이러한 시스템은 매우 많은 양의 이벤트 또는 정보를 실시간으로 소비, 처리, 집계 또는 상호 연관시킬 수 있습니다. 개발자는 업계 표준 오픈 소스 프레임워크와 클라우드 플랫폼을 사용하여 이러한 시스템을 쉽게 확장하고 향상할 수 있습니다.

아키텍처 문제 및 복잡성

EDA와 마이크로서비스 아키텍처 스타일을 결합하여 개발자는 성능, 확장성, 가용성, 탄력성 및 개발 용이성과 같은 비기능적 품질을 쉽게 달성할 수 있습니다. 그러나 이 두 가지 아키텍처 스타일은 또한 몇 가지 주요 문제를 야기합니다.

이러한 우려 사항 중 일부는 다음과 같습니다.

• 다음과 같은 문제를 야기하는 다수의 분산 및 독립적으로 배포된 구성 요소 또는 서비스:

  • 설계 및 구현의 복잡성. 이러한 시스템을 이해하고 디버깅하는 것은 어렵습니다. 이벤트 처리 워크플로는 직관적이지 않으며 문서화해야 합니다.
  • 여러 실패 지점. 테스트, 디버깅 및 예외 처리의 복잡성이 증가했습니다.
  • 릴리스 프로세스, 배포 및 시스템 모니터링이 복잡해지고 높은 수준의 자동화가 필요합니다.
  • 개발 관점에서 구현의 일관성, 설계에 대한 적합성 및 구현 표준이 요구됩니다. 그러나 여러 개발 팀이 있습니다. 이로 인해 일관성 없는 구현 및 품질 문제가 발생할 수 있습니다. 따라서 아키텍처 패턴의 사용, 개발 프레임워크, 재사용 가능한 서비스 또는 유틸리티 개발, 강력하고 효과적인 거버넌스 모델 설정을 설명하는 참조 아키텍처의 개발이 필수적입니다.

• 비동기식 이벤트 처리는 이벤트 순서 또는 순서 지정, 콜백 및 예외 처리와 관련된 요구 사항으로 인해 동기식 처리에 비해 어렵습니다.

• 정보나 사건을 잃는 것은 바람직하지 않습니다(분명히). 따라서 가용성이 매우 높고 확장 가능하며 내결함성이 있는 시스템에 대한 요구 사항이 특히 중요하므로 시스템 설계 및 배포가 매우 복잡합니다. 이벤트 생성자와 소비자는 실패를 견디고 실패한 이벤트를 재생할 수 있으며 중복 제거 기능을 갖도록 설계되어야 합니다.

• 분산 트랜잭션에 대한 지원 부족. 이 문제는 개발자가 여러 분산 시스템에 걸쳐 사용자 지정 및 복잡한 롤백 및 복구 구현을 만들어야 함을 의미합니다.

• 데이터 일관성 유지. 분산된 특성과 여러 기록 시스템으로 인해 데이터 일관성을 유지하는 것은 복잡합니다. 대부분의 경우 여러 분산 시스템에서 원자성 트랜잭션이 없기 때문에 최종 일관성이 유지됩니다.

• 이벤트 소비자와 생산자는 이벤트 브로커, 데이터 캐시 등에 사용되는 제품에 특정한 속성을 고려해야 합니다. 예를 들어, 배송 보증은 생산자와 소비자의 디자인에 영향을 미칩니다.

EDA 마이크로서비스 시스템을 위한 아키텍처 청사진

다음 그림은 EDA 마이크로서비스 기반 엔터프라이즈 시스템의 아키텍처 다이어그램입니다. 아키텍처를 보다 명확하게 하기 위해 일부 마이크로 서비스 구성 요소 및 유형이 별도로 표시됩니다.

이 청사진의 EDA 및 마이크로서비스별 구성 요소는 다음과 같습니다.

• 이벤트 백본 . 이벤트 백본은 주로 이벤트의 전송, 라우팅 및 직렬화를 담당합니다. 이벤트 스트림 처리를 위한 API를 제공할 수 있습니다. 이벤트 백본은 여러 직렬화 형식을 지원하며 내결함성, 탄력적 확장성, 처리량 등과 같은 아키텍처 품질에 큰 영향을 미칩니다. 이벤트를 저장하여 이벤트 저장소 를 만들 수도 있습니다. 이벤트 저장소 는복구 및 복원력을 위한 핵심 아키텍처 패턴입니다.

• 서비스 계층 . 서비스 계층은 마이크로서비스, 통합, 데이터 및 분석 서비스로 구성됩니다. 이러한 서비스는 REST API, UI 또는 EDA 이벤트 생성자 및 소비자를 포함한 다양한 인터페이스를 통해 기능을 노출합니다. 서비스 계층에는 오케스트레이션 서비스, 스트리밍 데이터 처리 서비스 등과 같은 교차 문제를 해결하고 EDA에 고유한 서비스도 포함됩니다.

• 데이터 레이어 . 데이터 계층은 일반적으로 두 개의 하위 계층으로 구성됩니다. 이 청사진에서 마이크로서비스가 소유한 개별 데이터베이스는 표시되지 않습니다.

  • CQRS와 같은 패턴을 지원하고 성능을 향상시키기 위해 분산 및 인메모리 데이터 캐시 또는 그리드를 제공하는 캐싱 계층 . 수평으로 확장 가능하며 복원력을 위해 일정 수준의 복제 및 지속성을 가질 수도 있습니다.
  • 데이터 웨어하우스, ODS, 데이터 마트, AI/ML 모델 처리로 구성된 빅 데이터 계층 .

• 마이크로서비스 섀시 . 마이크로서비스 섀시는 시스템의 여러 계층에 필요한 기술 및 교차 절단 서비스를 제공합니다. 개발 및 런타임 기능을 제공합니다. 마이크로서비스 섀시를 사용하면 설계 및 개발 복잡성과 운영 비용을 줄이는 동시에 수많은 마이크로서비스의 출시 시간, 결과물 품질 및 관리 용이성을 개선할 수 있습니다.

• 배포 플랫폼 : 탄력적, 비용 최적화, 안전하고 사용하기 쉬운 클라우드 플랫폼을 사용해야 합니다. 개발자는 유지 관리 및 관리 오버헤드를 줄이기 위해 가능한 한 많은 PaaS 서비스를 사용해야 합니다. 아키텍처는 하이브리드 클라우드 설정도 제공해야 하므로 Red Hat OpenShift 와 같은 플랫폼을 고려해야 합니다.

주요 아키텍처 고려 사항

아키텍처 고려 사항은 시스템 아키텍처에 영향을 줍니다. 그들은 건축적 결정을 내리기 위한 가이드 레일 역할을 합니다. 시스템의 비기능적 특성에 큰 영향을 미칩니다. 다음 아키텍처 고려 사항은 이벤트 중심의 마이크로 서비스 기반 시스템에 매우 중요합니다.

• 건축 패턴
• 기술 스택
• 이벤트 모델링
• 처리 토폴로지
• 배포 토폴로지
• 예외 처리
• 이벤트 백본 기능 활용
• 보안
• 관찰 가능성
• 내결함성 및 응답

건축 패턴

아키텍처 및 통합 패턴을 선택하는 것은 이벤트 중심의 마이크로서비스 기반 시스템에 대한 중요한 아키텍처 고려 사항입니다. 그들은 원하는 많은 아키텍처 품질에 대해 입증되고 테스트된 솔루션을 제공합니다. 다음 아키텍처 패턴은 이벤트 기반 마이크로서비스 기반 시스템을 개발하는 데 매우 유용합니다.

• 파이프 및 필터
• 단계적 이벤트 기반 아키텍처(SEDA)
• 이벤트 소싱
• 명령 쿼리 책임 분리(CQRS)
• 사거
• 스트림 처리
• 마이크로서비스 섀시
• 배달 못한 편지 대기열(DLQ)

또한 많은 엔터프라이즈 통합 패턴 및 마이크로서비스 패턴 은 이벤트 기반 마이크로서비스 기반 시스템을 위한 빌딩 블록을 제공합니다.

시스템에서 원하는 요구 사항 및 아키텍처 품질을 기반으로 패턴을 선택해야 합니다.

기술 스택

이벤트 브로커, 데이터 캐시 또는 그리드, 마이크로서비스 프레임워크, 보안 메커니즘, 분산 데이터베이스, 모니터링 시스템 및 경고 시스템과 같은 구성요소는 이벤트 기반 마이크로서비스 기반 시스템의 기술 백본을 형성합니다. 이 백본은 주요 아키텍처 품질(성능, 가용성, 안정성, 운영 비용, 내결함성 등)을 지원하고 개발을 단순화합니다. 또한 여러 설계 및 개발 결정에 영향을 미칩니다.

기술 스택을 선택할 때 다음 특성을 고려하십시오.

• 개별 구성 요소의 수평 확장성 . 확장으로 인해 가용성이 손상되어서는 안 됩니다. 즉, 노드를 추가할 때 가동 중지 시간이 필요하지 않아야 합니다.
• 개별 구성 요소의 고가용성 . 선택한 제품 또는 프레임워크는 다양한 가용 영역 또는 지역에 걸쳐 구성원을 보유하고, 롤링 업그레이드를 지원하고, 데이터 복제를 지원하는 기능이 있는 클러스터링을 지원해야 하며, 내결함성이 있어야 합니다. 즉, 노드 손실 시 클러스터가 자체적으로 균형을 다시 조정해야 합니다.
• 클라우드 친화성 , 즉 클라우드에 쉽게 배포할 수 있어야 합니다. 실제로 PaaS 플랫폼에서 서비스로 사용할 수 있다면 관리 및 유지 관리 오버헤드가 줄어들기 때문에 더욱 좋습니다. 컨테이너화 지원은 필수입니다.
• 낮은 운영 비용 , 즉 상용 하드웨어에서 실행할 수 있어야 하고 CPU, 메모리 및 스토리지 측면에서 검소해야 합니다.
• 가동 중지 시간 없이 동작 및 비기능적 특성의 구성 및 조정.
• 관리 용이성 .
• 공급업체 종속성을 피해야 합니다. 개방형 표준을 기반으로 하거나 오픈 소스 제품인 제품을 선택합니다. 오픈 소스 제품을 선택할 때 제품이 얼마나 널리 채택되었는지, 개발자 커뮤니티가 번창하는지, 라이선스가 개방적이어야 하며 매우 제한적이지 않아야 하는지(예: Apache License V2.0)를 고려하십시오.
• 이벤트 브로커 및 개발 프레임워크의 경우 다음을 지원해야 합니다.
  • 다중 직렬화 형식(JSON, AVRO, Protobuf 등)
  • 예외 처리 및 배달 못한 편지 대기열(DLQ)
  • 스트림 처리(집계, 조인 및 윈도우 지원 포함)
  • 이벤트 순서 분할 및 유지
• 반응형 프로그래밍 지원이 있으면 좋습니다.
• 다국어 프로그래밍 지원은 이벤트 백본에 있는 것이 좋습니다.

다음 표에는 다양한 구성 요소에 대해 많이 사용되는 선택 항목이 나열되어 있습니다.

구성 요소 유형	선택
이벤트 백본	Apache Kafka , 통합 을 위한 IBM Cloud pak , Lightbend , AWS Eventbridge + Kinesis 와 같은 통합 플랫폼
마이크로서비스 개발 프레임워크	Spring Boot , Spring Cloud Stream , Quarkus , Apache Camel 과 같은 Spring 프레임워크
데이터 캐시/그리드	Apache Ignite , Redis , Ehcache , Elasticsearch , Hazelcast
관찰 가능성	Prometheus + Grafana , ELK , StatsD + Graphite , Sysdig, AppDynamics, Datadog

이벤트 모델링

이벤트 모델링은 이벤트 유형, 이벤트 계층, 이벤트 메타데이터 및 페이로드 스키마 정의로 구성됩니다. 다음 이벤트 모델링 특성을 신중하게 고려하십시오.

• 이벤트 유형 . 엔터프라이즈 시스템에는 각기 다른 유형의 이벤트를 소비하고 생성하는 여러 비즈니스 도메인이 있습니다. 모델링의 주요 측면 중 하나는 이벤트 유형 및 이벤트를 식별하는 것입니다. 이벤트 스토밍 및 이벤트 소스 와 같은 도메인 기반 설계 및 사례 를 사용하여 이벤트를 식별하고 분류합니다. 이벤트 유형은 본질적으로 계층적일 수 있으므로 이벤트 처리에 대한 계층적 접근 방식을 사용하는 데 도움이 됩니다. 모든 비즈니스 요구 사항을 포괄하는 이벤트 유형 및 이벤트를 정의하고 이를 다양한 비즈니스 프로세스 또는 워크플로에 매핑합니다. 이벤트 유형의 세분성은 구성 요소 간의 긴밀한 결합을 방지하는 데 매우 중요합니다. 이벤트 유형은 라우팅 규칙을 정의하는 데 중요합니다.

• 이벤트 스키마 . 이벤트 스키마는 이벤트 프로세서의 처리에 사용되는 이벤트 메타데이터(유형, 시간, 소스 시스템 등)와 페이로드(정보)로 구성됩니다. 이벤트 유형은 일반적으로 라우팅에 사용됩니다. 이벤트 메타데이터는 일반적으로 이벤트의 상관 관계를 지정하고 순서를 지정하는 데 사용되지만 감사 및 권한 부여 목적으로도 사용할 수 있습니다. 페이로드는 대기열, 주제 및 이벤트 저장소의 크기, 네트워크 성능, (역)직렬화 성능 및 리소스 활용에 영향을 줍니다. 콘텐츠 복제를 피하세요. 필요할 때마다 이벤트를 재생하여 항상 상태를 다시 생성할 수 있습니다.

• 버전 관리 . 요구 사항 및 구현은 시간이 지남에 따라 발전하며 종종 이벤트 모델에 영향을 미칩니다. 이벤트 모델을 변경하면 잠재적으로 너무 많은 마이크로서비스에 영향을 줄 수 있습니다. 영향을 받는 모든 서비스를 동시에 변경하는 것은 실용적이지 않습니다. 따라서 이벤트 모델은 여러 버전을 지원해야 하며 마이크로 서비스가 편리한 시간에 변경될 수 있도록 이전 버전과 호환되어야 합니다. 기존 속성을 변경하는 대신 페이로드에 새 속성을 추가하는 것도 좋은 생각입니다(변경 대신 사용 중단). 버전 관리는 직렬화 형식에 따라 다릅니다.

• 직렬화 형식 . JSON , protobuf 또는 Apache Avro 와 같이 이벤트 및 해당 페이로드를 인코딩하는 데 사용할 수 있는 여러 직렬화 형식이 있습니다 . 여기서 중요한 고려 사항은 스키마 진화 지원, (역)직렬화 성능 및 직렬화된 크기입니다. 이벤트 메시지는 사람이 읽을 수 있기 때문에 JSON을 개발하고 디버그하는 것은 매우 쉽지만 JSON은 성능이 좋지 않으며 이벤트 스토리지 요구 사항이 늘어날 수 있습니다. Avro 또는 Protobuf는 페이로드의 크기를 줄이고 빠르며 스키마 진화를 지원하지만 추가 설계 및 개발 노력이 필요합니다.

• 파티셔닝 . 이벤트 분할은 동시성, 확장성 및 가용성을 높이는 데 중요합니다. 파티셔닝은 메시지 순서의 핵심이기도 합니다. 아키텍처 관점에서 파티션 키를 선택하는 것이 중요합니다. 매우 거친 키를 갖는 것은 확장성과 동시성에 영향을 미칩니다. 매우 세분화된 키를 사용하면 이벤트 순서를 유지하는 데 도움이 되지 않을 수 있습니다. Kafka와 같은 이벤트 브로커에서 파티셔닝은 이벤트 소비자의 확장성을 제한합니다.

• 주문 . 일부 이벤트는 도착 시간을 기준으로 (적어도 주어진 엔터티에 대해) 주문해야 할 수도 있습니다. 예를 들어, 특정 계정에 대한 계정 거래는 순차적으로 처리되어야 합니다. 주문이 필요한 이벤트를 식별하는 것이 중요합니다. 주문은 성능과 처리량에 영향을 미치므로 필수적인 경우에만 사용해야 합니다. Apache Kafka에서 이벤트 순서는 파티셔닝과 직접적인 관련이 있습니다.

• 이벤트 지속성 지속성 은 대기열 또는 주제에서 이벤트를 사용할 수 있는 기간을 의미합니다. 예를 들어 이벤트가 소비되는 즉시 삭제해야 합니다. 구성된 보존 기간보다 오래된 이벤트를 삭제합니다. 명시적 표시가 있는 이벤트(예: Kafka의 삭제 표시)를 삭제합니다. 요구 사항에 따라 이 중 하나를 선택하고 구성해야 합니다. 시간 기반 보존을 사용하는 동안 필요한 경우 이벤트를 재생할 수 있는 기간을 고려하십시오. 이벤트 저장소 패턴을 사용하는 경우 유지해야 하는 동일한 이벤트 또는 페이로드의 버전 수에 대한 추가 질문을 고려해야 합니다. Kafka와 같은 이벤트 브로커는 이벤트의 지속성을 지정하기 위해 주제 수준에서 설정할 수 있는 다양한 구성 옵션을 제공합니다.

이벤트 처리 토폴로지

EDA에서 처리 토폴로지는 이벤트 처리 기능을 제공하기 위해 생산자, 소비자, 엔터프라이즈 통합 패턴, 주제 및 대기열의 구성을 나타냅니다. 기본적으로 기능 논리(프로세서)의 일부가 엔터프라이즈 통합 패턴과 대기열 및 주제를 사용하여 함께 결합되는 이벤트 처리 파이프라인입니다. 처리 토폴로지는 SEDA, EIP 및 파이프 및 필터 패턴의 조합입니다. 복잡한 이벤트 처리의 경우 여러 처리 토폴로지를 서로 연결할 수 있습니다.

처리 토폴로지의 또 다른 핵심 개념은 오케스트레이션 대 안무 입니다. 오케스트레이션 은 다른 구성 요소를 호출하여 처리 워크플로를 오케스트레이션하는 중앙 오케스트레이터를 갖는 것을 말합니다. 처리에 대한 엄격한 제어가 필요할 때마다 지불 처리와 같이 오케스트레이션이 선택됩니다. 오케스트레이션은 일반적으로 SAGA 패턴이 사용되는 곳에서 사용됩니다. 오케스트레이션은 성능 및 가용성과 절충점이 있습니다(오케스트레이터가 단일 실패 지점이 될 수 있으므로). 안무완전히 분산된 처리 방식을 나타냅니다. 즉, 이벤트가 게시되고 관심 있는 구성 요소가 주제를 구독합니다. 처리 흐름을 제어하는 ​​중앙 구성 요소는 없습니다. 안무는 구현 및 유지 관리가 복잡합니다.

처리 토폴로지를 생성하기 위해 다음 지침을 고려하십시오.

• 처리 단계(프로세서)는 영구 대기열 및 주제를 사용하여 연결되어야 합니다.
• 각 대기열 또는 주제에서 분할 키 및 메시지 보존 정책을 구성합니다.
• 처리의 세분성은 중요합니다. 프로세서가 너무 미세하면 프로세서 간에 긴밀하게 결합될 가능성이 있습니다. 이상적으로는 각 프로세서는 논리적으로 서로 독립적이어야 합니다.
• 마이크로서비스는 프로세서를 구현하는 데 사용할 수 있습니다. 이것은 느슨한 결합, 책임 분리 및 개발 용이성을 허용합니다.
• 처리 동시성은 프로세서 수준에서 구성할 수 있어야 합니다.
• 입증된 EIP(Enterprise Integration Pattern)를 사용하십시오. Apache Camel 또는 Spring Cloud Stream과 같은 기본 제공 EIP 지원을 제공하는 개발 프레임워크를 선택하십시오.
• 간단한 처리 파이프라인을 조합하여 복잡한 이벤트 처리가 달성되도록 모듈식 및 계층적 처리 토폴로지를 구축합니다. 이것은 구현을 모듈화하고 업데이트하기 쉽게 만드는 데 도움이 됩니다.
• 프로세서에 이벤트에 따라 변경되는 상태가 있는 경우 내결함성 및 복구 가능성을 높이기 위해 상태를 뒷받침하는 저장소를 갖는 것을 고려하십시오.

프로세스 이벤트 스트림 및 이벤트 관리 상태 와 같은 아키텍처 방식 을 사용하여 처리 토폴로지를 설계할 수 있습니다. 처리 토폴로지를 정의하는 동안 이벤트 브로커 기능에 대해 자세히 이해하는 것도 좋습니다. 예를 들어 Kafka 스트림은 이벤트 스트림 처리 토폴로지를 정의하기 위한 최고 수준의 지원을 제공합니다. Kakfa는 또한 이벤트 스트림에서 집계 및 조인 작업을 수행할 때 상태 저장소에 대한 자동 지원을 제공합니다.

다음 그림은 처리 토폴로지의 청사진을 보여줍니다.

그리고 다음 그림은 온라인 쇼핑을 위한 단순화된 주문 처리 토폴로지를 보여줍니다. 라우터는 이벤트를 여러 주제로 동적으로 라우팅하는 기능이 있습니다. 또한 이벤트 프로세서에는 컨텍스트를 기반으로 이벤트의 소비 및 생성을 제어하는 ​​'이벤트 필터'도 있습니다.

배포 토폴로지

EDA-마이크로서비스 아키텍처에는 배포할 구성 요소가 많이 있습니다. 확장성, 가용성, 탄력성, 보안 및 비용과 관련된 아키텍처 요구 사항이 충족되도록 배포 토폴로지를 선택해야 합니다. 그러나 중복성, 성능 및 비용 간에는 절충점이 있습니다. 클라우드에 배포하면 아키텍처의 성능, 탄력성 및 비용 효율성이 훨씬 높아집니다. 클라우드 배포에서 제공하는 기능(예: high availabilityKubernetes 설정)을 활용해야 합니다.

배포 토폴로지에 대해 다음과 같은 주요 원칙을 고려하십시오.

• 배포된 각 구성 요소는 독립적으로 확장 가능해야 하며 동시성과 복원력을 높이기 위해 클러스터로 배포해야 합니다.

• 각 클러스터가 여러 가용 영역에 걸쳐 있는지 확인합니다. 이 설정은 데이터 센터 오류 발생 시 더 많은 복원력을 제공합니다. 이것의 또 다른 장점은 수동 DR을 사용하는 대신 다양한 가용 영역 또는 지역에 걸쳐 능동-능동 배포를 수행할 수 있다는 것입니다.

• 복제 요소는 이벤트 또는 정보의 복제본 수를 결정합니다. 복제가 없으면 개별 인스턴스에 장애가 발생하면(클러스터된 경우라도) 데이터가 손실됩니다. 이는 특히 이벤트 브로커 및 데이터베이스에 필요합니다. 그러나 복제에는 컴퓨팅 및 스토리지 비용이 발생합니다. 복제는 가용 영역, 데이터 지역, 노드 수 등과 같은 요소를 기반으로 설정해야 합니다.

• Kafka의 경우 토픽 파티션의 수는 소비자의 동시성에 대한 상한을 설정합니다.

• 워크로드 조절. 스레드 풀과 소비자 및 생산자 인스턴스 수를 구성하여 처리량을 조절합니다. 다운스트림 프로세서의 볼륨과 처리량에 따라 이러한 매개변수를 적절하게 조정해야 합니다.

• 데이터 압축. 페이로드 크기가 크고 CPU 가용성이 높으면 압축을 사용하여 전송 전에 이벤트를 압축할 수 있습니다. 그러나 압축은 네트워크 사용률과 CPU 사용률 간의 절충점입니다.

• 데이터 암호화. 조직의 보안 표준을 기반으로 이벤트 브로커와 생산자 및 소비자(및 데이터베이스에 대한) 간의 TLS, 인증 및 권한 부여를 구성합니다. TLS를 활성화하면 CPU 사용률이 증가할 수 있습니다.

또한 자동화된 배포, 자동화된 장애 조치, 롤링 업그레이드 또는 블루-그린 배포, 배포 아티팩트의 환경을 독립적으로 만들기 위한 구성의 외부화를 지원하는 것이 중요합니다.

예외 처리 전략

EDA에서 포괄적이고 일관된 예외 처리 전략을 갖는 것은 복원력을 향상시키는 데 중요합니다. 예외 처리 전략은 다음 중 일부 또는 전부로 구성됩니다.

• 예외 로깅
• 지정된 시간 동안 지정된 재시도 간격으로 이벤트 재시도
• 모든 재시도가 소진된 경우 이벤트를 배달 못한 편지 대기열로 이동(또는 이벤트 처리 중지)
• 경고 제기
• 경우에 따라 이벤트 생성
• 예외의 원인 수정 및 이벤트 재생

예외는 비즈니스 예외와 시스템 예외의 두 가지 유형일 수 있습니다. 검증 또는 비즈니스 조건이 실패하면 비즈니스 예외가 발생합니다. OutOfMemory시스템 예외는 구성 요소(데이터베이스, 이벤트 브로커 또는 기타 마이크로서비스)를 사용할 수 없거나 리소스 문제(예: 오류), 네트워크 또는 전송 관련 문제(예: 페이로드 직렬화 또는 역직렬화 오류) 로 인한 광범위한 오류 범주입니다. , 또는 예기치 않은 코드 오류(예: NullPointerException또는 ClassCastException).

다양한 유형의 예외를 처리하는 방법에는 상당한 차이가 있습니다. 일부 예외 처리 메커니즘은 다음과 같습니다.

• 예상되는 비즈니스 예외는 일반적으로 코드에서 처리됩니다. 처리에는 예외 기록, 엔터티 및 해당 상태 업데이트, 예외 이벤트 생성 또는 예외 소비 및 계속 진행이 포함될 수 있습니다.

• 잘못된 페이로드(직렬화 또는 역직렬화 문제 포함)로 인한 예외는 재시도를 통해 해결되지 않습니다. 이러한 이벤트는 poision pillsKafka에서 참조됩니다(해당 파티션의 후속 메시지를 차단하기 때문에). 이러한 이벤트에는 개입이 필요할 수 있습니다. 배달 못한 편지 대기열(DLQ)로 이동하는 것이 좋습니다. DLQ 소비자는 이벤트의 수정 및 재생을 허용해야 합니다.

• 구성 요소를 사용할 수 없음으로 인한 시스템 예외는 본질적으로 일시적입니다. 따라서 다중 재시도를 구성해야 합니다. 또 다른 주요 구성 매개변수는 백오프 승수입니다. 연속 재시도 사이에 기하급수적으로 증가하는 시간 간격을 갖는 데 사용됩니다. 재시도 후에도 실패가 지속되는 경우 프레임워크마다 전략이 다릅니다. 예를 들어 Camel은 이벤트를 DLQ로 이동합니다. Kafka 스트림은 처리를 중지합니다. 이러한 시나리오에서는 프레임워크의 기본 동작을 사용하는 것이 좋습니다.

• 리소스 문제(예: OutOfMemory오류)는 일반적으로 구성 요소 수준에서 발생하며 구성 요소를 사용할 수 없게 됩니다. 이벤트 브로커의 내결함성 특성으로 인해 여기에서 이벤트 손실 위험이 최소화됩니다. 또한 Kubernetes 환경에 배포하면 실패한 포드를 대체하기 위해 새 포드가 시작됩니다.

• SAGA 패턴은 데이터 일관성이 매우 중요하고 처리에 여러 마이크로 서비스가 포함되는 경우에 사용됩니다. 데이터 일관성 요구 사항이 매우 엄격한 이벤트에 SAGA 패턴을 사용합니다.

• 복구 및 재생은 처음부터 생각해야 하며 나중에 생각해서 적용하지 않아야 합니다(나중에 매우 복잡해짐). 복구 및 재생 구성 요소는 일반적으로 맞춤 개발되며 이벤트 처리에 따라 다릅니다. 가장 단순한 재생 구성 요소는 실패한 이벤트를 선택하여 입력 주제에 다시 게시할 수 있습니다.

개발 프레임워크는 모든 마이크로서비스에서 일관된 예외 처리 전략을 지원해야 합니다. 비즈니스 예외에 대해 미리 정의된 예외 클래스 집합을 제공하고 구성을 사용하여 사용자 지정할 수 있지만 예외 처리와 관련된 아키텍처 결정을 시행하는 일반 예외 처리기를 제공해야 합니다. 대부분의 개발 프레임워크는 이러한 지원을 제공합니다. 그러나 필요한 기능을 제공하려면 올바르게 구성하거나 확장해야 합니다.

이벤트 백본 기능 및 제약 조건

다양한 이벤트 백본 제품 또는 플랫폼은 아키텍처 품질에 대한 지원을 다르게 제공합니다. 동시에 그들은 디자인과 아키텍처에 제약을 가합니다. 아키텍처를 정의하는 동안 비기능 요구 사항을 효과적으로 처리하려면 해당 기능과 제약 조건을 고려해야 합니다. 예를 들어 다음은 Kafka 에 대한 몇 가지 중요한 기능 및 제약 조건입니다 .

• Kafka는 파티션 키를 기반으로 하는 이벤트 순서 지정을 지원합니다. 또한 파티션에서 수신 대기하는 단일 소비자(스레드)가 있는지 확인합니다. 따라서 적절한 파티션 키를 선택하는 것만으로 이벤트를 매우 쉽게 주문할 수 있습니다. 예를 들어, OrderId파티션 키로 사용할 때 특정 주문과 관련된 모든 이벤트가 도착한 순서대로 처리되도록 합니다.
• Kafka는 idempotence생산자를 지원합니다. 즉, Kafka는 이벤트가 생산자에 의해 정확히 한 번 생성되도록 합니다. 개발자는 그것에 대해 걱정할 필요가 없습니다.
• Kafka는 at least once배달 보증을 제공합니다. 이는 소비자가 중복 메시지를 처리할 수 있어야 함을 의미합니다. 개발자는 이벤트 브로커가 제공하는 보증을 알고 있어야 합니다.
• Kafka의 또 다른 중요한 측면은 offset-commit소비자를 위한 전략입니다. 즉, 이벤트를 자동으로 승인할지 아니면 수동으로 승인할지를 의미합니다. 자동 커밋이 활성화된 경우 오류를 생성하는 이벤트가 손실되거나(예외가 사용된 경우) 소비자에게 중복 메시지가 표시될 수 있습니다. 수동 커밋을 사용하여 이에 대응할 수 있지만 추가 코드가 필요합니다. Kafka와 원활하게 작동하는 spring-cloud-stream과 같은 프레임워크는 auto-committing수동/자동 커밋 외에 오류가 발생하지 않거나 실패한 이벤트를 DLQ로 이동하는 옵션을 제공합니다. 이것은 설계 중에 숙고해야 하는 중요한 측면입니다.
• Kafka Streams는 이벤트 스트림을 처리하고 집계 및 조인과 같은 이벤트 스트림에 대해 다양한 고급 및 복잡한 작업을 쉽게 수행할 수 있는 기능을 제공합니다. 따라서 실시간으로 분석을 수행하는 것이 매우 쉽습니다. 예를 들어, 다양한 차원으로 그룹화된 이벤트의 실시간 통계를 계산하려면 최소한의 코딩이 필요합니다. 상태 저장 작업이며 상태를 유지합니다. Kafka는 또한 상태 저장소 를 통해 자동 내결함성을 제공합니다 .

보안

개발자는 EDA 마이크로서비스 아키텍처에서 다음과 같은 보안 측면을 고려해야 합니다.

• 전송 수준 보안
• 이벤트 제작 및 소비에 대한 인증 및 승인된 액세스
• 이벤트 처리를 위한 감사 추적
• 데이터 보안(승인된 액세스 및 암호화된 스토리지 등)
• 코드의 취약점 제거
• 경계 보안 장치 및 패턴

관찰 가능성

관찰 가능성에는 모니터링, 로깅, 추적 및 경고가 포함됩니다. 시스템의 각 구성 요소는 장애를 방지하고 장애로부터 신속하게 복구할 수 있도록 관찰할 수 있어야 합니다.

대부분의 EDA 제품 및 개발 프레임워크는 Prometheus 및 Grafana, ELK, StatsD 및 Graphite, Splunk 또는 AppDynamics와 같은 업계 표준 관측 가능성 도구로 내보낼 수 있는 메트릭을 게시하여 관측 가능성을 지원합니다. 예를 들어 Apache Kafka는 내보내고 이러한 도구 대부분과 통합할 수 있는 자세한 메트릭을 제공합니다. 또한 이벤트 백본(IBM Event Streams)에 대한 관리 서비스를 제공하는 클라우드 플랫폼은 관찰 가능성에 대한 최고 수준의 지원을 제공합니다. Spring 또는 Camel과 같은 마이크로서비스 개발 프레임워크는 모니터링을 위한 코드 계측에 대한 우수한 지원을 제공합니다.

EDA 관점에서 메트릭 게시, 이벤트 브로커 메트릭 게시 및 메트릭 대시보드를 통해 이들의 상관 관계를 위해 생산자 및 소비자 코드를 계측하는 것은 EDA에 분산된 구성 요소의 수가 많기 때문에 필수적입니다. EDA 관점의 주요 메트릭 중 일부는 수신 및 발신 메시지 비율, 소비 지연, 네트워크 대기 시간, 대기열 및 주제 크기 등입니다.

마이크로 서비스 모니터링의 경우 마이크로 서비스 계측 및 모니터링에 대한 자세한 내용은 내 Monitor Spring Boot 마이크로 서비스 자습서를 참조하십시오.

내결함성 및 응답

적절한 내결함성 을 제공하기 위해 아키텍처는 중복성, 예외 처리 및 탄력적 확장(임계값 위반 시 확장 및 로드가 정상으로 돌아올 때 축소)을 제공해야 합니다. EDA와 클라우드를 사용하면 이러한 대부분을 쉽게 달성할 수 있습니다. 이벤트 백본은 큐 및 주제의 클러스터링 및 복제를 지원하여 내결함성을 제공합니다. 생산자와 소비자는 여러 인스턴스를 배포할 수 있습니다. Kubernetes 플랫폼에 컨테이너로 배포하면 자동 확장(수평 포드 자동 확장 사용)을 통해 탄력적 확장을 쉽게 달성할 수 있지만 예외 처리는 생산자와 소비자를 위해 설계되어야 합니다.

EDA 기반 시스템은 단계적 아키텍처를 통해 탄력성을 제공하지만 지연 및 일관성 문제를 방지하려면 빠른 장애 대응 및 복구 가 중요합니다. 이 빠른 복구를 수행하려면 다음이 필요합니다.

• Red Hat OpenShift와 같은 Kubernetes 기반 플랫폼에서 쉽게 구성할 수 있는 인스턴스 시작 및 중지, 실패한 인스턴스 다시 시작을 위한 자동화
• 장애 발생 시 경보 및 사고 발생
• 잘 정의된 사고 관리 프로세스
• 로그의 가용성 및 추적을 통해 여러 구성 요소의 로그를 상호 연관시키는 기능. 마이크로 서비스에서 추적을 활성화해야 합니다. 이를 위해 spring-sleuth와 같은 개발 프레임워크를 사용할 수 있습니다. 로그 집계에는 ELK 또는 Splunk와 같은 도구를 사용할 수 있습니다. 이렇게 하면 팀에서 근본 원인을 식별하고 문제를 신속하게 해결하는 데 도움이 됩니다.

결론

개발자는 이벤트 기반 아키텍처와 마이크로서비스 아키텍처 스타일을 결합하여 분산형, 고가용성, 내결함성 및 높은 처리량 시스템을 개발할 수 있습니다. 이러한 시스템은 매우 많은 양의 정보를 처리할 수 있으며 극도의 확장성을 가질 수 있습니다. 그러나 이러한 시스템을 구축하는 동안 개발자는 많은 아키텍처 문제와 복잡성을 고려하고 많은 주요 아키텍처 결정을 내려야 합니다. 이 기사에서는 주요 아키텍처 결정과 이러한 결정을 내리기 위해 고려해야 할 요소에 대해 논의했습니다. 이 문서의 지침을 따르면 강력한 EDA-마이크로서비스 아키텍처를 정의하여 원하는 목표를 달성할 수 있습니다.

https://developer.ibm.com/articles/eda-and-microservices-architecture-best-practices/