Icednut's Note

스프링캠프 2017 둘째날 메모

2017-04-23

들은 세션 목차

  • Keynote
  • Reactive Spring ( Spring 5 & Reactor )
  • 이벤트 소싱 (Event Sourcing) 소개
  • Implementing EventSourcing & CQRS (구현부)
  • Indroductory RxJava
  • Spring Data Envers

Keynote

발표자료: http://benelog.github.io/docs/spring-camp-2017/

  • spring-composed?

Reactive Spring: Spring 5 & Reactor (발표자: 정윤진)

발표자료: https://www.slideshare.net/PivotalKorea/reactive-spring5-springcamp2017-23th-of-april

  • Spring 5가 어떤 모양으로 될지, Reactor가 어떻게 적용될지 소개
  • Ice Breaking
  • Spring 5
    • JDK 9, HTTP/2, Reactive 차용
  • Project Reactor
    • 왜 필요한가? 2000년대에 의존하는 기술이 많음 -> 요청 처리에 대한 처리를 Thread별로 진행 (요청 지연이 각각 다름) -> 요청이 더 많아지는 것을 처리하기 위해 Load Balancer를 앞에 둠(Are you dead?) -> 어플리케이션이 통으로 하나가 되어 있는 경우라서 처리할 서버만 늘리는 꼴
    • 이 구조를 탈피할순 없을까? Nonblocking Runtime -> 요청 처리만큼 스레드를 만들지 말자라는 아이디어에서 출발 -> 요청을 받을 때마다 가용한 스레드가 뭔지 알 필요없이 Pub/Sub으로 Worker Thread에게 요청처리를 알림
    • JVM을 위한 Reactive Streams
  • Reactive Manifesto
    • 응답성: 모든 요청에 대해 적시에 응답, 문제에 대해 빠르고 효율적으로 응답
    • 탄력성: 시스템 부하, 자원 변경에도 응답성을 유지
    • 회복성: 시스템이 장애에도 응답성을 유지 (Circuit Breaker, 응답 불가 상태를 감지하여 미리 지정한 응답으로 전달)
    • 메세지 중심: 리액티브 시스템은 느슨한 결합을 사용, 컴포넌트들은 비동기 방법으로 메세지 드리븐으로 동작
  • Reactive System, Reactive Programming -> 복수개의 서비스로 이루어진 분산 시스템에 대한 해법, Microservice가 지향하는 방향
  • Reactive Streams
    • 인프라간의 상호 운용성에 집중 (웹서버, 데이터 저장소 드라이버, 프레임워크)
    • NonBlocking Backpressure 지원 -> 응답 못하면 다른 곳에서 처리할 수 있게 -> 백프레셔는 응답을 처리하지 못하면 역류
    • RxJava, Project Reactor, Vert.x, Akka
    • Subscriber가 처리를 못하면 Publisher가 큐에 담아놓고 Subscriber를 확보한다.
    • 크게 Mono와 Flux를 보면 됨
    • docker run -p 127.0.0.1:27017:27017 mongo
  • Reactive 디버깅은? 뭐 있었는데 못봄…
  • Managing State with RxJava By Jake Wharton

이벤트 소싱 (Event Sourcing) 소개 (발표자: 이규원)

발표자료: http://doc.co/fggswS

  • 이벤트 소싱
    • 이벤트 소싱하면 착각하는거? 이벤트 드리븐 아키텍쳐와 착각 -> 이벤트 소싱은 이벤트를 저장하는 것에 대한 것이지 이벤트를 주고 받는다는 것이 아님
    • 장비구니에 대한 상태는 마지막 것만 저장됨 -> 넣었다가 뻈다가 하는 것에 대한 것은? 이걸 캐치해야지 추천이 가능하지 않을까?
    • 이벤트는 도메인에 대한 사실을 기록하진 않음
    • 이벤트 소싱은 변화를 나타내는 이벤트를 저장하고 이 이벤트를 재생해서 일련의 상태를 만들어냄? -> 도메인에서 발생하는 모든 이벤트를 기록하는 일 -> 외부에서 명령을 받으면 결과로 이벤트를 저장 (ex: 장바구니에 물건을 담았다라는 행위를 기록) -> 상태는 영속 대상이 아니며 이벤트가 영속 대상, 상태는 추가될 뿐
    • 이벤트 소싱의 예) AWS, GIT
  • 데이터 영속
    • 이벤트 저장소는 하나의 거대한 이벤트 스트림이 아님 -> 이벤트 저장소는 수많은 이벤트 스트림으로 구성됨 -> 도메인 오브젝트 하나 당 이벤트 스트림이 저장됨
    • 커맨드와 이벤트는 하나의 데이터 명령(Cammand)는 유효한지 검증이 필요, 반면 이벤트는 이미 지나간 사실 그러므로 검증 대상이 아님 -> 이벤트는 정책이 바뀌어도 실패라는게 없음 -> 이벤트는 재생하면 항상 성공해야함
    • 이벤트 소싱은 데이터베이스가 뭔지 상관없이 모두 구현 가능 -> 임피던스 미스매치가 발생하지 않음
    • CompoundPrimary Key: ShoppingCartId (Object Id), Version | Value: EventType, Payload
  • 백만개의 이벤트를 가지는 도메인 개체일 경우에는? 성능이 이슈가 될 수 있다.
    • 스냅샷을 사용 -> 특정 상황이 있을 떄마다 이벤트를 스냅샷으로 남긴다. 스냅샷 이후의 이벤트만 재생하기 때문에 성능 이슈가 나타나지 않음
    • Key: ObjectId | value: Version, payload
  • Messaging
    • 이벤트 소싱에서는 정확히 한 번 배달이 어렵다. 메세지 누락이 있을 수가 있어서 비지니스에서는 쓰기 어렵다? 메세지를 한 번 이상 보낼 수도 있다라는 것 때문에 멱등성 문제가 있을 수 있다.
    • 이벤트 소싱은 정확히 한 번 배달은 어렵지만 최소 한 번 배달은 쉬울 수 있다.
    • 이벤트 스트림은 순서를 보장
  • CQRS
    • 재고가 10개 미만인 상품 조회 -> 이벤트 스토어를 풀스캔하여 찾는다?
    • 이벤트 스토어는 다양한 비지니스에 대한 조회를 충족할 수 없다. 그러므로 무조건 CQRS를 적용해야 함
    • Command Query Seperation: 질문은 대답을 변경하지 않는다. 질문에 대한 답만 하는 메서드, 저장은 하되 응답은 하지 않는 메서드 이렇게 둘로 나누는 기법
    • CQS를 DDD에 적용하다가 더 발전해서 Command Side / Query Side와 같이 시스템 자체를 나누는 CQRS로 발전
    • Command Side의 이벤트 스토어에 모두 저장 Query Side의 Materialized Store에 복사해서 사용 (정규화, 중복 데이터는 신경 안씀)
  • 고려사항

Implementing EventSourcing & CQRS 구현부 (발표자: 심천보)

발표자료: https://github.com/jaceshim/springcamp2017/blob/master/springcamp2017_implementing_es_cqrs.pdf
예제소스: https://github.com/jaceshim/springcamp2017

  • 이벤트 소싱은 데이터 저장 방식의 새로운 패턴!
  • 스냅샷은 인메모리로 관리?
  • 구현 소스: https://github.com/jaceshim/springcamp2017
    • 데이터 변경 시 버전을 먼저 체크
  • Axon/Eventuate Framework

Indroductory RxJava (발표자: 김인태)

  • RxJava를 이해하려면… 비동기, Java 8 Lamda, High-order function
  • 메인스레드에서 Sub 스레드 수행 시 Sub 스레드의 종료 로그가 안찍힘 왜?
    • setDaemon(boolean)
    • join()
    • 블로킹 방식이기 때문에 notify를 사용
  • Java에서 스레드 생성 시 스택 공간을 잡음 (1MB)
    • Multi-Thread를 직접할 때 문제가 될 수 있음 (without threadPool)

Spring Data Envers (발표자: 김영한)

  • 변경 이력을 어떻게 할 것인가?
  • RevisionRepository를 다른 데이터베이스 서버의 DataSource를 쓸 순 없을까?

그 외

이번 스프링캠프의 이벤트소싱 주제는 실로 충격이었다. 마이크로서비스, Reactive Programming, Spring Cloud Data Flow와 같은 것들이 이벤트 소싱을 하기 위한 발판 같아 보였다. (어쩌면 나의 오해일수도..^^;) 아무튼 내가 하고 있는 업무에 대해서는 규모가 커지면 터질게 분명했다. 개선은? 예전 방식과 비슷한 새로 개발이라는 어리석은 선택을 하지 않기 위해 미리 공부해 대비해놔야겠다.

  • Thread의 이해
  • Reactive Programming (Project Reactor or RxJava)
  • DDD
  • Event Sourcing
Tags: spring springcamp