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 전략 (실패) 멀티테넌시 전략의 핵심은 어떻게 사용자 요청을 식별하는 것입니다. 첫 방식은 서브 도메인을 ..

오늘은 같은 트랜잭션 내에서 Dirty Check 오류가 발생해 엔티티 값이 갱신 되지 않는 문제에 봉착했다. Update가 실행되지 않는 원인은 크게 3가지다.값이 변경되지 않음엔티티 설정이 updateable = false트랜잭션 경계 오류난 이중 크게 보면 3번의 원인에 해당된다 볼 수 있다. 지금 프로젝트 환경은 dataSource 설정을 통해 두개의 db를 연결해 사용하고 있고 우선 순위가 현재 엔티티를 관리하는 dataSource에 있는 것이 아니라 다른 dataSource 환경에 우선 순위가 주어지고 있어 Dirty Check가 다른 트랜잭션 매니저에게 먹혀 update가 누락된 것이다. 원인 순서 @Primary가 meta TM에 걸려 도메인 JPA 로직도 meta TM로 처리됨.그래서..

Spring Cloud를 이용한 프로젝트를 진행하며 Global Filter를 제외한 이유 4가지 전역 필터는 작은 변경에도 전체 트래픽에 영향을 줘 혼란을 준다.예외 경로가 생길 수 록 if/else와 같이 분기 코드가 추가되어야 한다.내부/외부 통신간의 보안 권한 분류가 깨진다.모든 요청에 대한 같은 작업을 반복하는 문제1) 전역 예외 리스트 특히 모듈 서버가 추가될 때 api 엔드포인트 별 예외 사항이 추가될 때 마다 라우트 별 필터에 해당 엔드 포인트 예외 사항을 일일히 추가해야 되었고 이 때문에 누락된 혹은 생각지 못한 오류가 계속 발생하였습니다. 회원가입/로그인/토큰 재발급 같은 공개 엔드포인트가 늘수록 전역 필터엔 path.startsWith(...) 예외가 누적되고 경로 하나만 틀려도 인증..

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)을 사용하지 않는 문제가 발생합니다.이를 해결하기 위해 별도..