제 14회 한국 자바 개발자 컨퍼런스의 커뮤니티 세션에서 공유한 `overview of spring4` 의 발표 자료
스프링 프레임워크는 2004년에 출시된 이후 지금까지 많은 변화를 겪어왔습니다. 기억에 남아 있는 굴직한 변화를 더듬어 보면 버전 2.0은 XML 네임스페이스와 AspectJ 지원, 버전 2.5부터 애노테이션을 활용한 프로그래밍 기능이 추가되었습니다. 그리고 버전 3.0으로 올라가며 Java 5+ 기반으로 코드 구조가 바뀌고 자바 코드 기반 설정 기능이 추가되었습니다. 2013년 12월 13일에 버전 4.0 발표이 발표되었습니다. 주목할 변화는 바로 Java 8 지원과 제거 대상(@Deprecated)으로 선언되었던 많은 클래스와 메소드들이 삭제되었다는 것입니다. 이 외에도 많은 변화가 있습니다. 이번 시간에는 조금 높은 곳에서 내려다보는 느낌으로 무엇이 추가되었고, 어떤게 바뀌었는지 살펴보려고 합니다.
예제코드 : https://github.com/arawn/overview-of-spring4
Scala, Spring-Boot, JPA를 활용한 웹 애플리케이션 개발 과정에 대해 다룬다. Spring-Boot와 JPA 조합만으로도 생산성 있는 웹 애플리케이션 개발이 가능하다. 이 조합만으로도 충분히 의미가 있지만 여기에 Scala라는 약간은 불편한 듯 보이는 언어를 도입함으로써 얻을 수 있는 즐거움을 공유한다. Spring-Boot + JPA 조합에 Scala를 적용하면서의 좌충우돌 경험담을 전한다.
제 14회 한국 자바 개발자 컨퍼런스의 커뮤니티 세션에서 공유한 `overview of spring4` 의 발표 자료
스프링 프레임워크는 2004년에 출시된 이후 지금까지 많은 변화를 겪어왔습니다. 기억에 남아 있는 굴직한 변화를 더듬어 보면 버전 2.0은 XML 네임스페이스와 AspectJ 지원, 버전 2.5부터 애노테이션을 활용한 프로그래밍 기능이 추가되었습니다. 그리고 버전 3.0으로 올라가며 Java 5+ 기반으로 코드 구조가 바뀌고 자바 코드 기반 설정 기능이 추가되었습니다. 2013년 12월 13일에 버전 4.0 발표이 발표되었습니다. 주목할 변화는 바로 Java 8 지원과 제거 대상(@Deprecated)으로 선언되었던 많은 클래스와 메소드들이 삭제되었다는 것입니다. 이 외에도 많은 변화가 있습니다. 이번 시간에는 조금 높은 곳에서 내려다보는 느낌으로 무엇이 추가되었고, 어떤게 바뀌었는지 살펴보려고 합니다.
예제코드 : https://github.com/arawn/overview-of-spring4
Scala, Spring-Boot, JPA를 활용한 웹 애플리케이션 개발 과정에 대해 다룬다. Spring-Boot와 JPA 조합만으로도 생산성 있는 웹 애플리케이션 개발이 가능하다. 이 조합만으로도 충분히 의미가 있지만 여기에 Scala라는 약간은 불편한 듯 보이는 언어를 도입함으로써 얻을 수 있는 즐거움을 공유한다. Spring-Boot + JPA 조합에 Scala를 적용하면서의 좌충우돌 경험담을 전한다.
마이크로서비스는 큰 애플리케이션을 독립된 API와 데이터스토어를 가진 작은 단위의 서비스로 느슨하게 결합하여, 서비스를 책임지는 자율성 높은 팀의 자동화된 배포 및 운영 관리를 통해 민첩하게 비지니스 요구를 반영하는 아키텍처 구성 방식입니다. AWS 콘테이너(Container) 서비스 및 서버리스(Serverless) 아키텍처를 이용하여 마이크로 서비스를 구현하는 방법과 이를 위한 모범 사례를 소개합니다. 1) 개별 서비스 확장, 2) API 운영 및
Detailed Information: AWS 콘테이너(Container) 서비스 및 서버리스(Serverless) 아키텍처를 이용하여 마이크로 서비스를 구현하는 방법과 이를 위한 모범 사례를 소개합니다. 1) 개별 서비스 확장, 2) API 운영 및 관리, 3) 일관된 트랙잭션 유지, 4) 서비스 자동 배포, 5) 서비스 모니터링, 6) 서비스 보안 및 인증 그리고 7) 서비스 생태계 구성 등의 다양한 이슈에 AWS를 통한 해결 방법을 알아봅니다. 특히, AWS re:Invent에서 새로 출시한 AWS Step Functions, ECS 관리를 위한 Blox, Lambda@Edge 등의 서비스와 기능을 통해 마이크로서비스를 운영 관리하는 방법을 안내해 드립니다.
엔터프라이즈 클라우드 마이그레이션 준비와 실행. 그리고, 클라우드 운영 모범 사례 공유-최지웅, 오픈소스컨설팅 CTO / 장진환, 스마일샤...Amazon Web Services Korea
클라우드 마이레이션은 단순한 업무의 환경 이전 차원을 넘어 미래를 준비하는 긴 여정의 출발점이기도 합니다. 또한, 클라우드 마이그레이션의 전략,기술 준비사항은 기존의 IT 운영 환경에 비례하여 매우 다양하며 복잡 합니다. 이번 세션에서는 AWS MSP 파트너사인 오픈소스 컨설팅, 스마일 샤크의 다양한 클라우드 마이그레이션 사례 및 운영 환경 최적화 사례를 기반으로 여러분들의 클라우드 여정에 도움을 드리고자 합니다.
모든 것을 연결하여 최적의 인프라 기저를 형성하고 그 위에 빅데이터 저장 및 분석의 기반을 만들어 인공지능을 얹은 글로벌 시장의 리더와 붙을 수 있는 플랫폼을 소개합니다.
멀티벤더 지향의 기본 개념위에 메이저 금융S사의 지원으로 이미 많은 시스템 및 메이저 기업의 IoT데이터를 수집하여 빅데이터 분석을 진행중이며, S사의 로봇 기술 지원 및 향후 Drone의 제어, 데이터의 머신러닝등을 통하여 이미 글로벌 시장을 향하여 나아가고 있습니다.
많은 분들의 관심과 협력 부탁 드립니다.
문의 및 파트너쉽 : contact@littleworld.net
10. 분리에 따른 몇 가지 이점
• 명시적인 (강제) 언어 경계 à bounded
• 컨텍스트별 독립적인 발전
• 인터페이스에 기반한 컨텍스트 간 통신
10
11. Microservice의 특성
• James Lewis, Martin Fowler에 따르면
– 서비스로서 컴포넌트화
– 비지니스 수행에 따른 구성
– 프로젝트가 아닌 제품
– 똑똑한 엔드포인트와 더미(Dumb) 파이프
– 분산화 거버넌스
– 분산화된 데이터 관리
– 인프라 자동화
– 장애 방지 설계
– 진화하는 설계
11
* http://martinfowler.com/articles/microservices.html
12. 서비스로서 컴포넌트화
• 독립 배포 à 서비스의 응집도(경계) 높아짐
• 명시적 인터페이스 à 공개 인터페이스
12
13. 비지니스 수행에 따른 구성
13
발췌: http://martinfowler.com/articles/microservices.html
23. 이벤트 소싱Event Sourcing
23
* http://martinfowler.com/eaaDev/EventSourcing.html
어플리케이션의 모든 상태 변화를
순서에 따라 이벤트로 보관한다.
Capture all changes to an
application state as a sequence of
events.
24. 도메인 객체와 이벤트 소싱
• 도메인 객체 조회
– 저장한 이벤트로부터 도메인 객체 생성
• 도메인 객체 변경
– 모든 상태 변화에 대한 이벤트를 저장
• 일관성의 기준인 애그리거트Aggregate 단위
24
25. 이벤트 구성
• 구성
– 애그리거트 타입
– 애그리거트 식별자
– 버전
– 이벤트 타입
– 이벤트 시간
– 증분(변경) 내역(payload)
• 이벤트 구분(unique idx)
– 애그리거트 타입, 애그리거트 식별자, 버전
25
27. 애그리거트 조회
• 애그리거트는 이벤트 반영
27
public class Order extends Aggregate {
public void on(OrderPlacedEvent evt) {
this.lines = evt.getOrderLines();
this.shippingInfo = evt.getShippingInfo();
}
public void on(ShippingInfoChangedEventevt) {
this.shippingInfo = evt.getShippingInfo();
}
public void on(ShippedEvent evt) {
this.state = SHIPPED;
}
public abstract class Aggregate {
private Integer version;
public void handle(Event evt) {
this.version = evt.getVersion();
Events.handle(this, evt);
}
}
28. 애그리거트 변경
• 애그리거트에서 이벤트 발생
28
public class Order extends Aggregate {
public void cancel() {
….
OrderCanceledEvent evt =
new OrderCanceledEvent(getId(),
version + 1);
super.apply(evt);
}
public abstract class Aggregate {
List<Event> uncommittedEvents;
public void apply(Event evt) {
addUncommittedEvent(evt);
handle(evt);
}
public List<Event> getUncommittedEvents() {
return uncommittedEvents;
}
29. 애그리거트 변경
• 트랜잭션에서 이벤트 저장
29
public class CancelOrderService {
@Transactional
public void cancel(String orderId) {
Order order =
orderRepository.findById(orderId);
checkNull(order);
order.cancel();
}
}
class TransactionHandler {
public void commit() {
List<Aggregate> aggs = getAllUOW();
for (Aggregate agg : aggs) {
eventStore.append(
agg.getClass(),
agg.getUncomittedEvents()
);
}
}
30. 애그리거트 생성
• 애그리거트 생성자 : 생성 이벤트 발생
30
public class PlaceOrderService {
@Transactional
public void cancel(String orderId) {
Order order = new Order(…);
repository.save(order);
}
}
public class Order extends Aggregate {
public Order(…) {
….
OrderCreatedEvent evt =
new OrderCreatedEvent(
getId(), lines, shippingInfo,
1);
super.apply(evt);
}
31. 이벤트 소싱과 유지보수
• 새로운 데이터 추가
31
public class Order extends Aggregate {
private String note;
public Order(…) {
….
OrderCreatedV2Event evt = new OrderCreatedV2Event(...);
super.apply(evt);
}
public void on(OrderCreatedEvent evt) {
…
this.note = "";
}
public void on(OrderCreatedV2Event evt) {
…
this.note = evt.getNote();
}
없어지는 것
- DB 작업 일정
- 매핑 설정 변경
32. 이벤트 소싱 적용한 애그리거트
• 임피던스 미스매치(impedance mismatch) 없음
• 애그리거트 간 참조는 ID
• 비선점 잠금
32
34. SQL(ORM) vs 이벤트 소싱
• 변화되는 것
34
영역 적용 전 (RDBMS/ORM) 적용 후
도메인 객체 로딩 SQL : SELECT 쿼리
ORM : 프레임워크가 매핑
설정을 이용해서 SELECT 쿼리
실행
- 이벤트로부터 도메인 객체 생성
- 도메인 객체의 이벤트 핸들러를
이용해 상태 변경 반영
도메인 기능 SQL : 서비스 클래스
ORM : (일부) 엔티티 클래스
- 도메인 객체가 수행
- 상태 변경을 위한 이벤트 생성
상태 변경 반영
(데이터 변경)
SQL : Insert/Update/Delete 쿼리
ORM : 엔티티 프로퍼티를
변경하면 ORM 프레임워크가
알맞은 쿼리 실행
- 도메인 객체가 발생한 이벤트를
저장소에 보관
35. 장점
• DB에 의존적이지 않은 도메인 코드 구현
– 테이블이나 ORM 기술의 제한/제약에서 벗어남
• 기능 변경
– 하위 호환 처리가 상대적으로 쉬움
– 이벤트로부터 완전히 새로운 도메인 객체의 생성도 가능
• 버그 추적 용이
– 이벤트를 차례대로 검사하면서 버그 원인 추적 가능
• 객체 지향/DDD와 좋은 궁합
– 복잡한 도메인을 객체 지향적으로 구현하기에 좋음
• CQRS와 좋은 궁합
– 조회 관련 코드를 도메인에서 분리
– 조회 모델 분리로 조회 성능 향상 가능
35
36. 단점
• 익숙하지 않음
– SQL 위주(데이터 중심) 개발 성향인 경우 적응 힘듬
• 단순 모델에는 적합하지 않음
– 단순 모델에 적용하기엔 구현이 복잡해짐
• 도구 부족
– 이벤트 소싱과 CQRS 지원 프레임워크 부족
• 운영시 어려움
– 이벤트 데이터만으로는 최신 상태의 빠른 확인 불가
• CQRS 필수!
36
39. 길게 실행되는 프로세스
Long Running Business Process
39
주문하기 상품보내기 배송시작알리기
구매확정
요청하기
40. 길게 실행되는 프로세스
40
주문하기 상품보내기
배송시작
알리기
구매확정
요청하기
배송시작함주문함
배송시작집하하기 전달
배송완료함
입금하기
결제함
41. 길게 실행되는 프로세스/트랜잭션의 특징
• 여러 개의 작은 프로세스(트랜잭션)로 구성
• 하위 프로세스가 순서대로 실행되는 건 아님
• 여러 모듈/서비스가 (비동기로) 엮임
• 한 트랜잭션이 아님
• 실패는 롤백 대신 보상으로 처리
41
42. SAGA
• 여러 하위 트랜잭션 집합으로 구성된 LLT
– LLT: Long Lived Transaction
– 단일 실행 단위
• 각 하위 트랜잭션은 단독 트랜잭션
– 하위 트랜잭션 단위로 일관성 보장
• 각 하위 트랜잭션은 서로 연관
• 하위 트랜잭션 실패시, 보상 트랜잭션
– 일부만 성공해도 끝나지 않음
42
* SAGAS (Hector Garcia-Molina, 1987)