RabbitMQ가 아닌 Kafka를 선택한 이유 지난 MSA 모듈 간 통신 과정에서 X-Tenant-ID 헤더를 통해 Gateway부터 내부 마이크로서비스까지 요청의 Context를 전파하고 동적 스키마 라우팅을 구현하는 방법에 대해 작성했습니다. 하지만 MSA 환경에서 데이터 무결성을 보장하는 것은 다른 주제 입니다. 주문 서비스의 DB와 정산 서비스가 DB가 물리적으로 분리되어 있기 때문에 기존 트랜잭션을 이용해 ACID 보장을 할 수 없습니다. (원자성, 일관성, 고립성, 영속성) 동일한 message broker를 선정하는 과정에서 고려한 부분은 데이터의 처리 방식과 주요 강점 입니다. 특징 RabbitMQ (Message Broker) Apache Kafka (Event Streaming P..

MSA 멀티테넌시 환경에서의 스키마 별 트랜잭션 관리와 안정성 확보 전략 마이크로서비스 아키텍처를 구현하며 멀티 테넌시를 유실하지 않고 요청의 시작과 끝을 향해가는 과정에 사용자와 데이터를 유실하지 않고 트랜잭션을 유지하는 것을 말합니다.현재 구성된 서버의 경우 Spring Cloud로 이뤄진 각각의 모듈 서버들 간 통신 과정에서 어떻게 데이터 정합성과 사용자 정보 유실 없이 안정성을 확보했는지에 대해 정리할 예정입니다.+ 서버의 데이터 베이스는 각각의 서버별 Tenant 기반 Schema 구분을 통해 사용자별 데이터를 저장하고 있습니다 테넌시 식별하는 방식과 GateWay와 X-Tenant-ID 전략 (실패) 멀티테넌시 전략의 핵심은 어떻게 사용자 요청을 식별하는 것입니다. 첫 방식은 서브 도메인을 ..

MSA 구조 설계 중 사용자 DB 관리에 사용된 방식으로 하나의 소프트웨어 인스턴스가 여러 사용자 그룹 또는 테넌트를 지원하도록 설계된 아키텍처입니다. 쉽게 말해 여러 사용자가 동일한 소프트웨어와 인프라를 공유하면서도 서로의 데이터나 설정을 간섭받지 않고 독립적으로 서비스를 이용할 수 있는 구조입니다. 다수의 이용자들을 하나의 애플리케이션 서비스를 제공하고 사용자별 데이터를 노출되지 않도록 완전 분리함. 아키텍처 전체 흐름클라이언트 요청 수신필터/인터셉터에서 헤더에서 테넌트 식별자 추출(GateWay 서버에서 request에 추가되어 전달됨)Spring JPA 호출 시DynamicDataSourceRouter가 TenantContext로부터 lookup key(테넌트 ID) 결정기존에 생성된 Dat..

모니터링 서버 자체를 구축하는 방법은 크게 어렵지 않았지만 그 과정에서 서버에 적용된 Security에 대해 다시 공부해보는 계기가 되었습니다.  총 두가지 방법으로 모니터링 페이지를 구축하였습니다.Spring Security의 별도 SecurityFilterChain 생성 + 모니터링 전용 Id와 role을 생성Spring Security의 별도 SecurityFilterChain 생성 + 도커 내부망 통신Spring Security의 별도 SecurityFilterChain 생성 + 모니터링 전용 Id와 role을 생성 필터 체인의 적용 순서기존 SecurityFilterChain이 먼저 선언되어 있으면, 기존 로그인 방식(LoginForm)을 사용하지 않는 문제가 발생합니다.이를 해결하기 위해 별도..

프로젝트를 진행하면서 JPA의 save와 saveAll 메서드를 사용해 데이터를 저장하게 됩니다. 일반적으로 100개 미만의 데이터를 저장할 때는 두 메서드 간의 성능 차이를 크게 느끼지 못할 수 있습니다. 그러나 대량의 데이터를 저장할 때는 두 메서드의 성능 차이가 매우 크다는 점을 확인할 수 있었습니다. 이번 글에서는 이 차이에 대해 살펴보고 각각의 사용 시 주의해야 할 점을 정리해 보겠습니다. Save vs SaveAll 차이점 save와 saveAll의 가장 큰 차이는 트랜잭션의 생성 방식과 처리 방식에 있습니다.동작 방식: 데이터를 하나씩 저장하며, 호출될 때마다 별도의 트랜잭션을 생성하여 처리합니다.특징: N개의 데이터를 저장할 경우 N번의 트랜잭션이 생성됩니다.동작 방식: 한 번의 트랜잭션 ..

이번 문제는 API 요청이 중복 클릭과 네트워크 지연으로 동일한 요청을 반복하는 문제가 발생하는 일이 생겨 이를 해결하는 과정을 작성할 예정입니다. 멱등성이란 멱등성은 동일한 연산을 여러 번 수행해도 결과가 달라지지 않는 성질을 말한다. 이는 클라이언트에서 같은 요청을 여러 번 보내거나 네트워크 지연으로 인한 오류로 인한 중복 요청이 오더라도 서버는 상태가 변하지 않게 유지하도록 보장하는 것을 말한다. 멱등성이 보장되지 않는다면 어떻게 될까? 멱등성이 보장되지 않는 요청의 종류에는 무엇이 있을까? 서버 리소스 조회 혹은  대체하는 GET, PUT의 경우 여러번 요청해도 멱등성이 보장된다. 불가피하게 같은 요청이 발생하더라도 데이터 변경이 없기 때문이다. 문제가 생길 거 같은 DELETE의 경우에도 데이터..