Cloud Native Design Pattern #2

Event-Driven Architecture Pattern

loose coupling, 확장성에 필요

event source
signal, method call, state change, time passing
event는 정보 제공 목적
event 처리 여부를 확실히 하려면 event broker 필요
lambda 등으로 처리 로직 구현 가능
연속적 event가 stream event

Event-driven architecture

최대 한 번 전달
retry 없음
최소 한 번 전달
무응 시 retry

Exactly once processing

중복 요청에 대해서도 한 번만 처리되어야 함을 보장

message broker types

• standard(store-based)
  • event를 data store에 저장 후 처리
  • 소비 시 삭제
  • ex. RabbitMQ, ActiveMQ
• Log-based
  • event를 commit log에 저장
  • 소비 후에도 유지
  • ex. Kafka

CloudEvents

event의 schema 정의 (id, source type, title, time, ...)
JSON, XML 등으로 정의
protobuf 등의 이진 포맷도 사용 가능
schema version 관리

Event-Delivery patterns

producer-consumer

event queue로 비동기 통신
message broker를 통해 message queue를 관리
하나 이상의 생산자, 하나 이상의 소비자

RabbitMQ: store에 저장 후 처리 시 제거
Kafka: log로 영구 저장

사용 경우
비동기 전달
결합도 낮춤
전달 보장
요청 버퍼링 (queue에 쌓아 consumer가 여력이 될 때 pull 즉, back pressure)
워크로드 분배
RabbitMQ
Round-robin
Fair dispatch
워커가 작업을 종료 한 경우 작업을 할당
Kafka
파티션을 통한 분배
Rebalancing
파티션 내 순서 보장

cf.
back pressure
방식들
Queue 기ㅏ반
queue에서 여력이 될 때 pull

        rate limit
            요청 속도 제한

        circuit breaker
            과부하 시 요청 거부

고려
상황에 따른 여러 queue 사용
복잡도 감소
성능 저하 감소
queue size
유실을 막기 위한 적정 크기
사실 queue에 계속 쌓이는건 문제인듯 jitter의 최대 크기의 2배 잡고,
결국 다 처리되는 것으로 consuming 해야 함

Pub-sub pattern

durable subscription: 전달 보장
계층적 topic

RabbitMQ나 Kafka는 pub-sub을 지원

• RabbitMQ
  • fanout
    • 모든 구독자에게 broadcast
  • topic
    • topic 별 queue 지정
  • direct
    • routinug key가 정확히 일치하는 경우 전송
• Kafka
  • consumer group으로 pub-sub 구현
    • group id 별
  • topic 별 혹은 app level의 filtering
  • 메시지 영구 저장
  • 파티션 내 순서보장

Fire and Forget

Store and forward

DB나 queue에 event를 저장
전송 성공 시 삭제
실패 시 재시도

Polling

주기적으로 작업 확인 필요 시

Request callback

WebSocket

client와 server 모두 web socket으로 통신
client는 server로 연결을 생성하여 긴 시간 유지
연결이 유지된 상태에서 송/수신

WebSocket은 HTTP 기반 기술이나, HTTP2와 gRPC와 유사한 콜백 기반 통신

GraphQL

구독 기ㅡㄴㅇ에서 WebSocket 사용
구독 중인 서비스에 GraphQL 질의를 realtime event로 송신
client는 중간에 구독 종료 가능

web hook

open protocol
HTTP 사용
pub/sub service 사용

State Management patterns

event source

앱의 모든 상태 변화를 event의 sequence로 저장
상태 변경 event들들 persistence store에 저장

상태 재현, 여러 domain 모델 새엇ㅇ, 임시 질의 수행

Orchestration

mediator

직접적인 의존 관계를 끊고 mediator가 여러 의존과 routing 및 조합 등의 처리를 하고자 해서 사용
중재자는 중앙에서 협력 로직을 실행

• event를 이해하고 경로를 설정
• event 순차, ㅕㅇ렬로 조율 및 오류처리
• mediator는 event queue와 topic, API를 통해 다른 service와 상호작용
• event filtering, 다양한 프로토콜 대응

mediator 사용 사례

• API gateway
• SAGA
• Efvent mediator

책임

• routing
• aggregation 집계
• transformation
• erorr handling
• rate limiting & throtting

중앙 제어가 필요한 경우에만 사용

pipes and filters

event queue들로 여러 서비스를 연결해서 filter graph를 생성
topic으로 여러 서비스가 통합

고려

• event schema
  • decouple을 위해 표준화된 schema를 정의
  • schema registry를 사용해서 schema를 찾고 소비
• 특정 event만 관심
  • 구독 필터 사용
  • topic event 전체를 받아 내부에서 filtering

Priority Queue

event를 우선순위별로 queue를 둬서 전달
consumer는 더 높은 우선순위 큐에서 보다 많은 작업을 처리

Event-Driven 기술들

ActiveMQ

• 가장 오래된 AMQP
• open source
• 1회 처리 보장 필요한 pub-sub
• topic으로 여러 구독자에 event 전달
• 신뢰성 있는 전달
• 고성능 저널
• RDB에 영속 저장 가능

RabbitMQ

• AMQP, STOMP, MQTT 지원
• open source
• clustering 및 장애 극복 제공
• exchange 사용
  • 우편함
  • message를 받고 event를 binding 규칙으로 복사하고 queue에 분산
  • 유연한 event 분산
• push, pull 지원
• 우선순위 큐 등의 구현 시 많이 사용

• ActiveMQ
  • 사용 경우
    • topic, queue 필요
    • 단 한번 처리 보장
    • 중간 이하 크기 앱
    • 표준 메시징 프로토콜
  • 안되는 것
    • 높은 확장성
    • 많은 내구성 구독
    • 응답 메시지 재생
• RabbitMQ
  • 사용 경우
    • topic, quque 필요
    • 단 한번 처리 보장
    • 중간 이하 크기 앱
    • 표준 메시징 프로토콜
    • event routing
  • 안되는 것
    • 높은 확장성
    • 많은 내구성 구독
    • 응답 메시지 재생
• Kafka
  • 사용 경우
    • topic
    • 높은 확장성
    • 많ㅇ는 내구성 구독
    • event 재생
    • 단 한번 처리 보장
  • 안되는 것
    • 표준 messaging 지원
    • message에 대한 선택적 응답

Testing

• mock client, mock consumer 연동

• event 생성 및 전달, 앱의 완료 대기

• 생성한 응답에 대해 mock client들을 호출하여 최종 상태를 확인

• test용 topic과 queue를 사용

• 가능하다면 test 용 infra structure 사용

• namespace로 구분된 환경에서 test

observability and monitoring

• event의 흐름을 알기 어려움

• event-driven의 경우

  • topic과 queue로 연결되어 느슨한 열결로 인해 문제 부분을 파악하기 어려움
  • 즉, 관측 기능과 모니터링 기능이 필수

• 추적 시스템

  • Jeager
    • 분산 추적 app
    • event에 causation(원인) ID를 부여
      • 이 ID가 system에 전파
      • ID 별 workflow를 시각화 하여 추적
  • 근본 원인은 log를 통해 찾아야 함
  • 원인 ID 별로 event와 error를 기록
    • log aggregation은
      • Fluentd
      • Log stash
        ...

• 모니터링
  • 비정상으로 동작하는 서비스 파악
  • event 처리 흐름에서 병목 지점을 찾음
  • event 처리가 잘 안되면 결국 message broker에 event가 overflow >. 오류

DevOps

message broker는

• event 전달 패턴
• 보안 적용(인증, 인가)
• 관측, 모니터링
• Auto scaling
  • 자동으로 node 개수 제어
  • K8s 배포 시 Kubenetes based Event Driven AutoScaler를 사용

Stream-Processing Patterns

event-driven 기반
event를 즉시 분석해서 실시간 처리

Stream

시간 순서에 따른 연속된 event sequence
구성

• name, version, id
• StockStream 1.0의 경우 모든 stream은 공통 메시지 포맷과 구조를 지님

Stream Processing

연속ㄷ적인 event 처리

• event를 다른 format으로 변환하는 무상태 처리
• 상태를 저장하고 수행하는 복잡한 처리

Streamingdata processing patterns

Transformation pattern

format 변환
XML to JSON
stateless

사용 경우

• 메시지 변환
  • JSON to XML
• 프로토콜 변환
  • service간 message format의 불일치를 해결

Filters and threshold

이벤트를 특정 조건으로 필터링
ex.

• 2010년 이후 생산된 도요타 자동차에 대한 정보만 전달(나머지는 필터링)

사용 경우

• 분류별로 event filtering
• 경고를 위한 threshold 적용

Windows Aggregation

조건에 따른 event 집합 분석
min/max/avg/sdv 등 분석
sliding window, batching window

types

• length slide
• length batch
• time sliding

사용 경우

• 시간에 따른 event 종합
  • 최근 10분간의 트랜잭션 금액 합계 구하고 상위 10명의 사용자 파악

고려

• 장애로 인한 상태 유실
• 정확도와 효율은 trade-off
• 확장성
  • 샤딩을 통해 event로 나눔
  • event 들은 서로 다른 window에 분배하여 독립적 처리 후 join 하여 aggregation

..... -> Sharding microservice ---> A A Aggregate ---+--> stream jon -> AB, AB
                               ---> B B Aggregate ---+

Stream join

SQL table join과 유사
여러 stream에서 같은 ID의 event가 모두 도착 시 이를 join 하여 emit (Kotlin merge와 유사하네)

사용 경우

• scatter and gather
  • 같은 event를 병렬로 처리
• 여러 type의 event를 join
  • stock과 tweet의 내용 join

고려사항

• join을 위해 event 대기 상태 관리 필요
• 긴 기간의 join은 어려움
  • 공간 사용 증가...

Temporal event ordering

시간 순서대로 도착하는 event들의 pattern을 식별하고 다양한 관심있는 복잡한 event 발생을 검출
pattern 찾기

사용 경우

• event 순차 발생 탐지
  • 정의한 순서대로 event의 발생인지 탐지
  • 주로 사기 행위 탐지 시 사용

Machine Learner

예측을 위한 정보를 기반으로 계속 학습하여 모델을 향상
즉, 예측 결과와 실제 정답을 게속 loop back 하여 feeding 을 통해 모델을 학습

Scaling and Performance Optimization patterns

Sequential Convoy pattern

event 등르 분류해서 병렬처리

• event들을 category 별 병렬 처리
• 순번을 매겨 병렬 처리 시에도 순서대로 작어ㅜㅂ

Buffered event ordering pattern

event 사용 전에 순서대로 정렬
event는 network 지연, 연결 재시도 등 여러 이유로 도착 순서가 달라짐

event에 증가하는 값을 부여

• sequence number
• time stamp

Event ordering buffer가 순서보장을 위해 미리 온 event를 버퍼링

Course Correction pattern

먼저 결과를 알리고 나중에 필요 시 수정

Watermark pattern

여러 service가 event stream으로 mesh 형 연결로 동작
watermark 된 특정 event 보다 먼저 도착한 event 들이 모두 처리되었는지 확인 가능

주기적으로 watermakr event를 생성해서 일부 읿력 지점으로 전송
watermark efvent 소비시 이를 재 전달 (깥은 위치로)

병렬 처리 시 watermark event 사이의 event들에 대해서 synchronize

Reliability patterns

Replay pattern

과거 발생 event들을 재생하여 service의 상태 복구

Periodic snapshot state persistence pattern

주기적 상태 snapshot 저장
장애 시 재시작에 사용
S3 등에 저장

Two-node failover pattern

이중화 노드로 장애 극복 (중복 처리)

저지연 서비스의 경우 복구 등을 대기할 여유가 없음
여러 노드를 돌려 가용 상태를 확보

동작

• 여러 서비스를 병렬로 실행

• 서비스 리더 선출

• primary, secondary는 같은 입력 처리

  • primary만 결과를 출력

• secondary는 primary와 secondary의 결과를 비교해서 primary가 이미 처리한 결과는 버림

• primary 장애 시 secondary가 primary로 승격

Technologies

Esper

Siddhi

KsqlDB

Spark

Apache Flink

Amazon Kinesis

Azure Stream Analytics

Google Dataflow

Testing

Security

Observability and Monitoring

DevOps

API management and consumption patterns

API management patterns

API 관리는 API의 생성, 관리, 보안, 분석, 확장

API 구성

• API proxy
• API
  • 하나 이상의 servie로 구성
  • 별도로 분리된 API gateway를 제공하는 경우가 많음
  • API는 보안, 스로틀링, 버전 관리 등을 수행
  • API에 business logic 구현은 피해야 함
• API product
  • 하나 이상의 API를 보다 상위 수준의 비즈니스 기능으로 연결

API gateway pattern

별도의 layer를 통해 service를 제공

• API control plane
• API developer portal

• API store에서 API를 검색해서 사용
• API를 구독하고 access token을 사용해 API를 호출

• API gateway

  • API 접근 endpoint
  • API 사용자가 여기 연결
  • Access Token, Certificates, Credential validation 같은 보안 적용
  • QoS 처리
    • caching
    • version
    • API 호출 별 quota 제한

• API management plane

  • API 및 API product를 정의, 생성
  • API lifecycle 관리
  • APi access token, throttling, caching, security, version 관리

• API development protal

  • API 소개
  • API feedback 기록 기능
  • security key나 token 생성
  • 사용 정보 저장/조회

API microgateway pattern

API gateway를 쪼개서 각 API를 독립적인 실행환경으로 배포

사용 경우

• 온라인 쇼핑몰에서 각 API로 서로 다른 service를 사용자에게 제공하고자 할때

Service mesh sidecar as an API gateway pattern

독립적인 API gateway runtime이 아닌 service mesh를 사용하는 환경에서 API gateway 기능을 sidecar proxy로 옮겨서 micro service와 함께 실행

API consumption pattern

• frontend가 service에 직접 연결 (load balancer를 통해)
• frontend가 API gateway를 통해 service 기능을 사용
• client type(mobile, desktop 등) 별 별도의 API를 제공