ioh's Development

테스트에서 사라진 30명동시성 테스트를 돌리고 있었다. 100명이 대기열에 등록하고, 전원이 활성화된 뒤 주문하는 시나리오였다. 그런데 결과가 계속 70명만 성공했다.100 - 70 = 30. 배치 사이즈가 30이었다.처음에는 동시성 문제를 의심했다. 락 충돌인가? 커넥션 풀 부족인가? 한참을 뒤지다가 원인을 찾았다. @SpringBootTest가 @Scheduled 빈을 자동으로 시작하고, 테스트 실행 중에 스케줄러가 대기열에서 30명을 꺼내가고 있었다. 테스트가 100명을 등록하고 읽으려는 사이에 스케줄러가 30명을 소비해버린 것이다.이건 로컬에서의 문제였지만, 프로덕션에서는 더 심각한 버전이 존재한다. 서버가 3대면 스케줄러도 3개다.@Scheduled의 본질: JVM 로컬 타이머@Scheduled..

들어가며우리 회사는 온프레미스 환경에서 MSA(Microservices Architecture)를 운영하고 있다. 하지만 초기 구축 과정에서 일부 핵심 패턴들이 누락되거나 미흡하게 적용되어 있었고, 이로 인해 실무에서 여러 문제들을 마주하게 되었다. 현재 우리가 직면한 문제들:서킷 브레이커 미적용: 한 서비스의 장애가 연쇄적으로 전파되어 전체 시스템 장애로 확대SAGA 패턴 부재: 분산 트랜잭션 관리가 어렵고, 데이터 정합성 문제 발생오케스트레이션 패턴 미흡: 서비스 간 복잡한 비즈니스 플로우를 관리하기 어려움왜 완벽하게 적용하지 못할까?1. 조직적 장벽학습 곡선이 높고 팀 전체의 이해가 필요레거시 시스템과의 통합 부담"일단 돌아가는 것"이 우선순위2. 기술적 복잡도SAGA 패턴의 보상 트랜잭션(Comp..