마이크로서비스

GraphQL 그리고 MSA

MSA 환경에서 일하는 Front-end 개발자들을 만나면 나는 종종 이런 말을 듣는다. 주문서 화면을 만들 때 4~5개를 호출해서 조합해야 했어요. - 개발자 A 기부 상세 화면을 만드는데 같은 기부 번호로 여러 API를 호출해서 조합하고 있어요 - 개발자 B 벡엑드 개발자분이 API를 너무 잘 개 만들어 놔서 하나의 화면을 만들때 여러 번

Golang에서 카프카 컨슈머 그룹과 재시도로 결과적 일관성 구현하기

필자는 마이크로서비스 아키텍처Microservice Architecture(이하 MSA) 기반으로 커머스 시스템을 만들고 있다. MSA에서 어려운 점 중 하나는 데이터 일관성을 유지하는 일이다. 예를 들어 주문 프로세스(결제, 주문 원장 기록, 재고 차감 등등)는 모두 성공하거나 하나라도 실패한다면 이전 상태로 되돌아가야 한다. 모놀리틱 아키텍처Monolithic Architecture와 관계형 데이터베이스를 사용하는 전통적인 시스템은 데이터베이스 트랜잭션을

커머스 코드 자산화 개발일지 - 5 장바구니(부제. 다중 저장소 지속성 입문)

지금까지 고객이 구매할 수 있는 오퍼Offering를 만들고[1] 쇼핑몰에 노출하였다.[2] 그다음으로 해야 할 일은 오퍼를 장바구니에 담는 것이다. ShoppingCartService는 마이크로서비스 모듈로서 장바구니를 책임진다. Mall은 ShoppingCartService의 API를 이용하여 오퍼를 장바구니에 담는다. 불변성과 의존성 장바구니는 여러 개의 장바구니 아이템을 담을 수 있다. 여기서 오퍼라 하지 않고 ‘장바구니 아이템’이라고 부른 이유는

커머스 코드 자산화 개발일지 - 4 출시

소프트웨어를 배포할 때 비로소 가치는 생겨납니다. - The Nature of Software Development, 26 쪽 소프트웨어는 사용자를 만날 때 진정한 가치가 생긴다. 내가 만든 소프트웨어가 사용자를 만날 수 있도록 서버에 배포해보자. 지금까지 세 개의 모듈을 만들었다. * product-service : 상품 API를 제공하는 서비스 * product-admin : 상품 관리자 서비스 * mall : 사용자 쇼핑몰 모듈을 각기

커머스 코드 자산화 개발 일지-3 오퍼를 쇼핑몰에

지난 이야기 지난 글에서는 상품을 유연하게 다루기 위한 시도로 오퍼Offering 개념을 구현하였다. 개발 주기 목표 오퍼는 존재만으로는 가치가 없다. 고객이 보고 구매함으로써 비로소 가치가 생긴다. 그래서 이번 개발 주기의 목표는 고객이 방문할 수 있는 쇼핑몰(이하 Mall)을 만들고 오퍼를 노출하는 것으로 정했다. Mall은 별도로 존재하는 웹 애플리케이션으로 고객이 상품을

MSA에서 동시에 여러 API 호출로 응답 시간 줄이기

쇼핑몰의 주문 상세 화면은 일반적으로 주문 내역과 배송 정보, 결제 정보 등을 보여준다. 이럴 때 하나의 데이터베이스를 사용하는 모놀리틱 아키텍처Monolithic Architecture에서는 여러 테이블을 조인하면 되지만 다수의 서로 다른 데이터베이스를 사용하는 마이크로서비스 아키텍처Microservice Architecture에서는 여러 마이크로서비스의 데이터베이스에 정보가 들어 있기 때문에 데이터베이스의 물리적 조인이 어렵다. 따라서 마이크로서비스 아키텍처에서 주문 상세 화면은

마이크로서비스

스파게티 조인을 피하고 경계안에서 캐시 구현하기

아침에 출근했더니 동료가 나에게 링크를 하나 던지며 이렇게 말했다. 위 블로그가 어제 말한 오퍼레이션 캐쉬 설명하는것 같은데 한번 검토해주실수있을까요? Why duplication isn’t always a bad thing in micro-services CTO님이 데이터 중복이 필요할 때가 있다고 설파하던 기억이 난다. 그 당시 대부분의 개발자들이 못알아듣는 눈치였는데, 역시 사람들이 배워서 써먹는 데에는

MSA에서 메시징 트랜잭션 처리하기

비동기 메시지를 사용하여 상호 간에 통신하는 방식을 메시징Messaging[1]이라고 부른다. 마이크로서비스 환경에서 비동기 처리 시 보통 카프카Kafka나 래빗엠큐RabbitMQ 같은 메시지 브로커Message Broker를 사용하여 메시징을 구현한다. 아래와 같이 마이크로서비스들이 메시징을 통해 협업하여 주문을 처리한다고 가정해보자. OrderService는 주문 상태 이벤트(예. ORDER_CREATED, ORDER_CANCELLED 등)를 메시지 브로커에 발행하고 이벤트에

JPA 연관 관계 조회 그리고 MSA

먼저 아래와 같은 객체 모델이 있다고 가정해 보자. 하나의 Order(주문)는 여러 개의 LineItem(주문 품목) 가지고 각 LineItem은 하나의 Product(상품)에 의존한다. 특정 상품이 포함된 주문 목록은 어떻게 조회할 수 있을까? 가장 쉬운 방법은 객체 연관관계를 사용하는 것이다. 객체 그래프 탐색이라고 부르는 방식인데 Order 목록을 가져와 반복문을

마이크로 서비스 프로젝트 300개 관리하기

지난 7월 18,19일 이틀에 걸쳐 진행된 Open Infrastructure & Cloud Native Days Korea 2019 행사에 발표자로 참여하면서 몇가지 세션을 들었습니다. 중국 개발자와 같이 발표를 해야 했기 때문에 발표 준비로 많은 세션을 듣지 못했지만 몇가지 세션을 들으면서 다음과 같은 점을 느꼈습니다. * 많은 회사 또는 개발자들이 Docker나 Kubernetes 환경에 관심을 가지고

[후기]MSA, K8S를 이용한 대륙의 서비스 개발 사례

Open Infrastructure & Cloud Native Days Korea 2019 행사에 다녀왔습니다. 좋은 발표가 많았지만 'MSA, K8S를 이용한 대륙의 서비스 개발 사례' 후기를 공유합니다. 이 글은 슬라이드의 내용보다는 청중으로써 필자가 받은 느낌을 위주로 썼습니다. 전체 발표 슬라이드는 아래 링크에서 확인하실 수 있습니다. https://www.slideshare.net/babokim/open-infradays-2019msak8s?

마이크로 서비스 관련 글 총정리

최근 한 전통 산업과 인터넷 서비스를 결합한 비즈니스를 수행하고 있는 회사에 마이크로 서비스라는 주제로 강의를 다녀 왔습니다. 이 회사뿐만 아니라 많은 회사에서 마이크로 서비스 아키텍처의 적용을 고려중이거나 이미 적용하고 있는 상황입니다. Popit에는 다양한 주제의 글이 있는데 그 중 마이크로 서비스 아키텍처에 대한 다양한 글이 있습니다. 다만 여기저기 흩어져 있어 한번