요즘 건설 분야에서도 디지털 트랜스포메이션 물결이 거세다. 이런 현상은 특히 선진국에서 빈번히 관찰되고 있는 데, 건설 데이터를 변환하고 이를 플랫폼에 올려 서비스하는 방식이 매우 탄탄하다는 것을 알 수 있다. 실리콘밸리 건설 테크 스타트업 수준이 소프트웨어 공학 분야에서 진행된 최신 트랜드를 따라가고 있다. 이런 이유로, 최근 서비스 개발 트랜드 중 마이크로 서비스를 살펴보기로 한다.
개념
개요
Spring Boot / Dropwizard / Docker를 사용한다고 해서 마이크로 서비스를 하고 있는 것은 아니다.
Microsoft가 마이크로 서비스 아키텍처를 시도하는 이유 중 가장 중요한 것은 팀 전체에 미치는 영향을 최소화하면서 빠른 속도로 시스템의 다른 부분에서 기능 개발을 지원할 수 있도록 하는 것이다. 요즘은 팀이 서비스를 비즈니스가 원하는대로 신속하게 변경할 수 있기를 원한다.
"각 마이크로 서비스가 자체 데이터베이스를 소유하고 제어해야 하며 두 서비스가 데이터베이스를 공유해서는 안된다"라는 의견도 있다. 이 경우 경쟁적인 읽기 / 쓰기, 데이터 모델 충돌, 조정 문제 등과 같은 충돌이 발생한다. 사실 단일 데이터베이스는 많은 안전과 편의를 제공한다. 분리된 데이터베이스의 ACID 트랜잭션와 같은 문제를 해결하며 마이크로 서비스 안전성을 어떻게 보장할까?
마이크로 서비스의 경우 다음 사항을 명확하게 해야한다.
- 도메인은 무엇인가? 유스케이스는 무엇인가?
- 범위는 어디에 있는가?
- 도메인은 무엇인가?
마이크로 서비스를 구축하고 사용하는 데이터 (생산 / 소비 등)를 잘 이해해야한다. 예를 들어, 예약 정보를 데이터베이스에 저장하려면 예약이 무엇인가를 이해해야 한다. 도메인에서와 마찬가지로 계정, 직원 또는 클레임 등이 무엇인지 이해해야 할 수 있다.
환경 및 문제에 대한 맥락을 가지고 있어야 이해의 모호성을 해결할 수 있다. 소프트웨어를 구축하고 데이터를 모델링 할 때 컨텍스트를 명시적으로 만들어야 한다.
도메인 기반 디자인 작업은 도메인의 복잡성을 정리하는 데 도움이 된다. 도메인을 모델링하는 엔티티, 객체 및 집합체에 대한 경계 컨텍스트를 생각해야 한다. 도메인을 나타내는 모델을 구축하고 구체화하면 모델은 맥락을 정의하는 경계 내에서 정의될 것이다.
아키텍처
데이터 모델은 도메인 모델에 의해 결정된다. 경계를 가질 때, 모델은 올바른것과 틀린 것을 구분할 수 있다. 예를 들어 경계 컨텍스트 "A"는 경계 컨텍스트 "B"와 다른 시나리니오를 가질 수 있다. 예를 들어, 경계 컨텍스트 "A"는 책 제목을 검색하는 검색 서비스 일 수 있다. 제한 컨텍스트 "B"는 구매한 책 등을 기반으로 트랜잭션을 처리하는 결제 서비스이다.
영화 검색 및 표시, 트윗 게시, linkedIn 프로필 업데이트 등은 모두 보험 청구 처리 시스템보다 훨씬 간단한다. 이 인터넷 회사는 마이크로 서비스를 이용했다. 기업은 규모뿐만 아니라 도메인의 복잡성에 직면하고 있다.
트랜잭션 경계란 비즈니스에 대해 필요한 가장 작은 원자 단위를 의미한다 . 원자성 또는 2단계 커밋 등을 구현하기 위해 데이터베이스의 ACID 속성을 사용하는지 여부는 실제로 중요하지 않다. 요점은 이러한 트랜잭션 경계를 가능한 한 작게 만드는 것이다.
예를 들어 다음과 같은 사용 사례가 있다고 가정 해 보겠다.
"고객이 항공편을 검색"
"고객이 특정 항공편에서 좌석을 선택"
“고객이 항공편을 예약”
검색, 예약 및 발권과 같은 세 가지 컨텍스트가 있을 것이다. 지불, 충성도, 대기, 업그레이드 등과 같이 훨씬 많을 것 같지만이 세 가지로 좁혀 질 것이다. 검색은 특정 기간(일, 시간 등) 동안 특정 경로 및 여정에 대한 항공편을 표시한다. 예약은 고객 정보(이름, 주소, 상용 고객 번호 등), 좌석 환경 설정 및 지불 정보로 예약 프로세스를 책임 져야 한다. 발권은 항공사와 실제로 예약을 정하고 발권을 담당한다. 항공편 집계는 예약 생성을 위해 비행기, 좌석 등을 추적할 책임이 있다.
예약 과정에서 SeatAvailability 집계를 호출하여 비행기 좌석을 예약하도록 요청할 수 있다. 이 좌석 예약은 단일 거래로 구현된다. 그리고, 예약 ID를 반환한다. 예약 ID를 예약과 연관시키고 좌석이“예약된”지점이라는 것을 알고 예약을 제출할 수 있다. 이러한 개별 거래는 2 단계 커밋 또는 2 단계 잠금 없이 독립적으로 진행할 수 있다.
마이크로서비스는 이런 내용을 고려한 기능을 다음과 같이 제공한다.
- 도메인 서비스 - 전체 시스템이 분할된 상태
- 복합 서비스 - 도메인 서비스에 대한 여러 호출로 구성된 서비스 작업
- 명령 - 특정 컨텍스트 내에서 특정 엔티티에 대한 작업
- 복합 거래 - 그룹화하고 함께 수행해야 하는 명령 세트
- 코디네이터 - 복합 트랜잭션 수명주기를 관리하는 서비스
- TCC 서비스 - 시도, 취소, 확인 프로토콜 구현
개발
TCC는 여러가지 도구가 있다. 다음은 TCC를 지원하는 Spring Cloud 도구를 사용한 시나리오 예이다.
시나리오
주문과 이벤트는 다음과 같이 같은 이벤트를 가진다.
주문 이벤트
이 경우, TCC는 다음과 같은 형식으로 개발할 수 있다.
try - POST /Account/req HTTP/1.1
cancel - DELETE /Product/order/q1XA9j HTTP/1.1
confirm - PUT /Product/reservation/q1XA9j HTTP/1.1
그 결과 다음과 같은 응답을 받을 수 있다.
try - HTTP/1.1 201 Created
confirm/cancel succeseds - HTTP/1.1 204 No Content
confirm/cancel fails - HTTP/1.1 404 Not Found
partical confirm - HTTP/1.1 409 Conflict
이런 방식으로 TCC를 개발할 수 있다. TCC는 다양한 프레임웍과 라이브러리가 있고, 관련 예제가 제공되므로 이런 부분을 고려해 개발을 진행할 필요가 있다.
레퍼런스
- Microservices: Your data
- Microservices-transactions-tcc
- Transactions for the REST of Us
- REST 기반 분산 트랜잭션
댓글 없음:
댓글 쓰기