시리즈
MSA
- 1.카프카(Apache Kafka)란 무엇인가
아파치 카프카란? Apache Kafka는 전통적인 메시지 시스템으로서 메시징 처리 뿐만 아니라, 사용자의 웹 사이트 활동 추적 파이프라인으로 활용하고 애플리케이션의 통계를 집계해 모니터링 데이터로 사용한다. 예전에
- 2.Kafka 용어 정리 (pub/sub, 토픽, 파티션, 브로커)
Pub/Sub 모델이란? Pub/Sub 모델(Publish-Subscribe Model)은 분산 시스템에서 메시지 전달을 처리하기 위한 패턴 중 하나입니다. 이 모델에서는 메시지 송신자(publisher)가 메시지를
- 3.API Gateway의 이해
API Gateway는 클라이언트와 백엔드 서비스 컬렉션 사이에 위치하는 API 관리 툴이며, 모든 서버로의 요청을 단일 지점을 거쳐서 처리하도록 한다. 이를 통해 공통된 로직 처리나 인증 및 인가 처리, 라우팅 처
- 4.MSA 개발 가이드(1) - MSA란 무엇인가
지금까지 개발했던 프로젝트들은 모두 모놀로식 아키텍처였는데, 신입으로 입사 이후 마이크로서비스 아키텍처라는 것을 접하게 되었다. MSA는 민첩성과 유연성을 장점으로 하는 클라우드 플랫폼에서 개발, 실행, 운영, 관리
- 5.MSA 개발 가이드(2) - Spring Cloud 기반 마이크로서비스(MSA)
MSA 개발 가이드 목차 Spring Boot Spring Cloud 응용프로그램 개발 분야는 Spring 프레임워크의 유례없는 성장과 함께 더 간결하고 빠른 개발을 가능케 하는 패러다임의 변화를 경험했다. Spri
- 6.MSA 개발 가이드(3) - 마이크로 서비스 아키텍처 구현해보기
Spring Boot와 Spring Cloud 컴포넌트를 사용하여 Cloud-Native Application을 제작해 보자. 본 예제에 사용되는 세팅은 다음과 같다. - OpenJDK 17.0.7 - spring-
- 7.MSA 개발 가이드(4) - Resilience4j(Circuit Breaker)
Spring Cloud의 컴포넌트 활용 클라우드 네이티브한 애플리케이션을 제작하는 과정은 MSA 형태의 애플리케이션 제작뿐만 아니라 실제 서비스가 유연하게 동작하기 위하여 여러 클라우드 컴포넌트와 연동되어야 한다.
- 8.MSA 개발 가이드(5) - Spring Cloud Eureka(Service Registry)
Service Registry - Eureka Eureka는 MSA의 장점 중 하나인 동적인 서비스 증설 및 축소를 위하여 필수적으로 필요한 서비스의 자가 등록, 탐색 및 부하 분산에 사용될 수 있는 라이브러리이다.
- 9.MSA 개발 가이드(6) - Spring Cloud Gateway(Zuul)
API Gateway - Zuul (중요!!) API 게이트웨이는 마이크로서비스 아키텍처(MSA)의 핵심 구성 요소 중 하나로, 클라이언트 요청을 받아 처리하는 단일 진입점을 제공하는 서비스입니다. 이는 프록시 서버
- 10.MSA 개발 가이드(7) - Spring Cloud Config Server/Client
Config 서버 Config 서버는 분산 시스템에서 다수의 애플리케이션 환경 설정 정보를 중앙에서 관리하도록 하는 기능을 제공하는 환경 설정 서버이다. 이것은 서비스 및 비즈니스 로직과 관련된 정보를 애플리케이션으
- 11.MSA 개발 가이드(8) - Spring Cloud Bus(RabbitMQ)
Config 서버의 설정 값이 변경될 경우, 마이크로서비스들이 변경된 설정 값을 갱신하기 위해서는 마이크로서비스를 재시작하거나, 위 Config Client 예제의 /actuator/refresh를 호출해주어야 한다
- 12.MSA 개발 가이드(9) - 마이크로 서비스 배포(Docker)
마이크로 서비스 배포 Spring Boot로 개발된 마이크로서비스는 독립적인 서비스로, 실행 환경으로는 가상 머신(VM), 컨테이너 기술, 그리고 다양한 클라우드 플랫폼을 고려할 수 있다. 몇 개 정도의 마이크로서비
- 13.결제 흐름 안의 물류 API 호출을 걷어내기 – 같은 트랜잭션 아웃박스 + 배치 릴레이 + Kafka 로 OMS 에 주문 넘기기
결제·취소 흐름 안에서 메시지를 바로 발행하고 물류 API 를 부르던 구조를, 주문과 주문 아웃박스를 한 MongoDB 트랜잭션에 저장하고 커머스의 배치 릴레이가 아웃박스를 폴링·CAS 선점해 Kafka 로 OMS 에 발행하는 구조로 바꾸는 설계다. 이미 운영 중인 조각과 앞으로 만들 조각을 나눠 적었다. 그리고 Kafka 를 고른 이유, exactly-once 대신 at-least-once + 멱등 소비를 고른 이유, CDC 를 쓰지 않은 이유, 장애 지점별 동작을 정리했다.