본문 바로가기

소프트웨어-이야기/아키텍처

<김용욱> 마이크로서비스 아키텍처 구축 가이드: 설계원칙 서비스의 의존관계 코드 레벨의 참조 코드 레벨의 참조는 다른 서비스의 API나 이벤트 정의를 따르는 것이다. 참조하는 서비스의 스펙이 변경되면, 자신도 같이 변경되어야 한다. 런타임 레벨 참조 실행 중에 다른 서비스의 API나 이벤트를 호출하는 것이다 런타임 레벨에서 다른 서비스의 기능을 호출한다면, 해당 서비스에 장애가 발생했을 때 영향을 받을 수 있다. 설계원칙 (1) 참조 방향을 역전하자! 코드 레벨의 참조와 런타임 레벨의 참조는 보통 동일한 방향을 가진다. 하지만 코드 레벨의 참조를 역전시키는 경우, 둘의 방향이 반대가 된다. 예제로 살펴본 참조의 역전: Callback API callback API가 코드 레벨 참조와 런타임 레벨 참조의 방향이 바뀌는 대표적인 사례이다. Payment serve..
<김용욱> 마이크로서비스 아키텍처 구축 가이드: 프론트엔드 마이크로 서비스 아키텍처 5.1.3 프론트엔드 마이크로 서비스 아키텍처 프론트 도메인 분리하기 프론트엔드를 여러 도메인 별로 분할해야하는 경우가 있다. 프론트엔드 팀의 규모가 지나치게 큰 경우다. 이 경우, 개발 생산성이 낮아지고, 테스트와 배포가 어려워진다. 도메인 별로 팀을 묶어두었으나, 프론트엔드 애플리케이션은 1개인 케이스다. 이렇게 되면 팀 별로 독립적인 배포가 어려워진다. UI 조합하기  화면을 도메인 별로 분리하고 난 이후에는, 분리된 화면을 연결해줄 수 있는 방법이 필요하다. 크게 두가지 방법이 있다. 분리된 UI를 조합하는 심플한 방법은 HTML 링크를 사용하는 것이다. 서비스마다 별도의 사이트를 두고, 메뉴를 선택할 때 해당 사이트로 전환한다. 각 서비스는 같은 인증 체계를 갖고 있어서, 별도의 로그인 없..
개발자를 위한 최소한의 인증 시스템 지식: Oauth2.0 + HTTP JWT 인증에 필요한 정보를 암호화한 Token이다. JWT 구성을 살펴보자. JWT은 3가지 구성요소로 나뉜다. 각 구성영역은 토큰의 점으로 구분된다. header payload signature JWT이 등장한 배경 요구사항 로그인을 하려면 아이디와 패스워드가 필요하다. 그리고 로그인을 일정 시간동안 유지해야한다. 아이디와 패스워드를 매번 보내주려면, 어딘가에 이 정보를 저장해야한다. 대안 (1) 아이디와 패스워드를 API를 요청할 때마다 전달하기 아이디와 패스워드를 사용자에게 매번 입력받는 것은 무리이다. 그래서 클라이언트 저장소에 아이디와 패스워드를 저장해서, 매번 전달해야한다. 쿠키에 아이디, 패스워드를 저장해서 전달하는 안이 있다. 그러나 개인 민감정보가 쿠키에 담겨있는 것은 보안상 안전하지 ..
Service Aggregator VS BFF 애플리케이션 아키텍처 패턴으로 Service Aggregator와 BFF가 있다. 둘이 비슷한듯 다른데, 그 차이점을 이해해보자. Service Aggregator은 여러 MSA 호출을 조합하는 오케스트레이션 역할을 하는 서버를 말한다. Backend For Front은 UI에 친화적인 응답을 만드는 서버를 말한다. 그래서 Mobile/PC 별로 다른 화면을 위한 BFF도 존재할 수 있다. BFF도 여러 API을 호출한다는 점에서 Service Aggregator와 공통점이 있다. 그러나 사용하는 목적이 다르다는 점에서 차이가 있다는 생각이 든다.
[EDA] 이벤트 발행하기 애플리케이션에서 이벤트를 발행하는 방법은 크게 Application layer event와 Persistence layer event으로 나뉜다. Application layer event 애플리케이션 안에서 명시적으로 이벤트를 발행하는 방법이다. 장점은 원하는 시점에 이벤트를 발행할 수 있다는 것이다. DB에 데이터가 적재되지 않는 상황에서도 이벤트를 발행할 수 있다. 단, 도메인과 DB가 명시적으로 분리되어있는 경우에만 사용가능하다. 만약 도메인과 DB를 다른 애플리케이션에서 사용하고 있는 경우, 이벤트를 감지하지 못하는 상황이 발생할 수 있다. Persistence layer event 데이터 저장소를 활용하여 이벤트를 발행하는 방법이다. CDC가 대표적인 예이다. 이 방법은 도메인/DB가 분리되어..
Transactional outbox Transactional outbox은 MSA 환경에서 이벤트 메시지 발행을 보장할 때 사용하는 패턴이다. 이벤트 메시지 발행 시점 애플리케이션에서 이벤트를 발행할 때에는 트랜잭션 내부 혹은 외부에서 호출하는 상황에 따라 장단점이 있다. (1) 트랜잭션 안에서 메시지 발행 메시지 발행 여부를 쉽게 보장할 수 있다. 그러나 메시지 발행의 실패가 곧 전체 서비스로 장애가 전파될 수 있다는 단점이 있다. (2) 트랜잭션 밖에서 메시지 발행 메시지 발행 실패가 즉시 해당 서비스의 장애로 전파되지 않는다. 그러나, 메시지 발행에 실패해도 메시지 발행을 재시도 할 수 없다는 단점이 있다. 위의 방안은 모두 안정적으로 메시지 발행을 보장할 수 없기 때문에 다른 대안이 필요하다. 메시지 발행 보장하기 Transacti..
broadleafcommerce으로 재고 시스템 맛보기 이커머스 오픈소스인 broadleafcommerce의 재고 서비스를 살펴봄으로써, 재고 시스템 구조를 맛보고자 한다. 재고 예약 Flow Diagram 체크아웃을 완료하기 전인 임시 주문 단계에서 재고를 임시로 예약한다. (Soft Reservation) 그리고 체크아웃이 모두 완료되어, 주문서가 만들어지고난 이후 재고를 영구적으로 예약한다. (Hard Reservation) DB Diagram inventory transaction은 sku의 재고 히스토리를 관리하기 위한 도메인이다. inventory transaction의 8개의 타입으로 이루어져있다. SOFT_RESERVED HARD_RESERVED FULFILLED CANCELLED ORDERED RETURNED RECEIVED SHRINKAGE..
레이어드 아키텍처 레이어드 아키텍처 (n티어 아키텍처)는 일반적으로 많이 사용되는 아키텍처이다. 더 나은 아키텍처 대안을 찾지 못할 때, 쉽게 선택하는 아키텍처 패턴이다. Spring Project에서 각 레이어는 다음과 같은 클래스로 구현된다. Presentation Layer : Controller Business Layer : Service Persistence Layer : Entity Database Layer : Repository 특징 레이어드 아키텍처는 작고 간단한 서비스를 만들 때, 출발점으로 적합한 아키텍처다. 개발자에게 익숙하고, 복잡도도 낮기 때문에 소규모 애플리케이션에 적합하다. 단점 계층형 아키텍처는 영속성 계층을 토대로 만들어지기 때문에, 데이터베이스 주도 설계를 유도한다. 계층형 아키텍처에서 ..

티스토리툴바