메시지 순서 보장뿐 아니라 중복 없이 정확히 한 번만 처리되는(Exactly-once) 이벤트 시스템을 구성하기 위해 다음과 같은 설정과 전략을 적용했습니다.먼저 프로듀서 측에서는 acks=all, enable.idempotence=true, transactional.id를 설정해 중복 전송 방지와 트랜잭션 컨텍스트를 유지했습니다.컨슈머 측에서는 enable.auto.commit=false로 수동 커밋을 적용하고, isolation.level=read_committed로 트랜잭션이 커밋된 메시지만 읽도록 설정했습니다.또한 메시지를 읽은 후 DB 작업과 offset 커밋을 동일 트랜잭션 내에서 처리하여, 중간에 실패가 발생해도 중복 소비나 손실이 없도록 구성했습니다.외부 시스템(DB 등)과의 종단 간 정합..

예매 시스템에서 하나의 좌석을 두 명 이상이 동시에 요청하는 경우, 선착순으로 하나의 요청만 성공해야 하는 문제가 있었습니다.초기에 Redisson Lock을 사용해 동시성 제어를 구현했지만, 부하 테스트 결과 lock 경합에 따른 응답 지연이 심해지는 문제가 발생했습니다.이를 해결하기 위해 Redis LuaScript를 사용해 선점 가능한지 검사 → 선점 상태 등록까지의 작업을 원자적으로 수행하도록 했습니다.예: SETNX seat:123 reservedUserId EX 600 같은 방식으로 10분 간 예약된 상태를 유지하며, 실패 시에는 즉시 실패 응답을 주도록 구현했습니다.결과적으로 동시에 요청이 들어와도 한 명만 선점할 수 있도록 정합성을 보장하면서, 성능도 개선되었습니다. 꼬리 질문1.만약 R..

주문 생성과 결제는 하나의 비즈니스 트랜잭션이지만, 기술적으로는 DB 트랜잭션(주문)과 외부 API 호출(결제)이 분리되기 때문에 정합성 보장이 필요합니다.저는 이 문제를 Outbox Pattern + Kafka를 사용하여 해결했습니다. 주문 생성 시 결제 요청 이벤트를 저장한 후, Kafka를 통해 결제 서비스를 호출하고, 결제 성공 시 주문 상태를 ‘확정’으로 업데이트합니다.결제가 실패하면 일정 시간 동안 Retry 정책(최대 3회, 10분 간격)을 적용하고, 모두 실패한 경우에는 주문 상태를 ‘결제 실패’로 변경하여 고객에게 알림을 보냅니다.이처럼 분산 환경에서는 Saga 패턴이나 보상 트랜잭션을 통해 각 상태를 명시적으로 관리하고, Kafka 기반의 메시지 재처리 및 DLQ를 함께 활용했습니다. ..

Spring Cloud Gateway나 Config Server는 MSA에서 요청 라우팅 및 설정 전달을 담당하는 핵심 인프라이기 때문에, 이들의 장애가 전체 시스템에 영향을 줄 수 있습니다. 먼저 Config Server는 애플리케이션 부팅 시 설정을 받아오는 역할을 하며, 이후에는 대부분의 경우 로컬 메모리에 설정이 캐싱되어 있기 때문에 서버가 죽더라도 기동 중인 인스턴스에는 영향이 없습니다. 다만 Config Server 장애 시 신규 배포 또는 설정 refresh 시도 시 실패하게 되므로, 이를 대비해 Spring Cloud Config의 Fail Fast 모드를 해제하고, Retry 및 Timeout 설정을 적용했습니다. Gateway 장애 시는 전체 외부 요청이 막히기 때문에 이중화 배포(HA..

각 구성 요소는 비동기적으로 동작하기 때문에, 특정 컴포넌트에 장애가 발생해도 전체 로그 파이프라인이 즉시 중단되진 않습니다.예를 들어, Logstash가 장애를 일으킨 경우, Filebeat는 내부 큐에 로그를 임시 저장하며 일정 시간 동안 버퍼링할 수 있습니다. 하지만 이 큐가 가득 차면 로그 유실이 발생할 수 있기 때문에, backpressure 상황에 대한 모니터링과 알림이 필요합니다.Elasticsearch가 장애 나면 Logstash 출력이 실패하고 큐가 쌓이게 됩니다. 이때 Logstash 자체에 Persistent Queue를 설정해두면 디스크에 저장된 로그를 재처리할 수 있습니다.Kibana는 단순 시각화 도구이므로, Kibana 장애는 로그 수집에는 영향을 주지 않습니다. 다만 관측 및..

Redis가 다운되면 캐싱, 분산락, LuaScript 기반의 원자적 연산 등이 모두 영향을 받습니다.이를 대비해 Redis는 Sentinel 기반으로 구성해 장애 발생 시 자동으로 Slave에서 Master를 선출하고 연결을 재구성하도록 했습니다. 만약 캐시가 유효하지 않거나 Redis 접근이 완전히 불가능한 경우, DB에서 직접 데이터를 조회한 후 응답을 반환하고 Redis는 비동기로 복구합니다.Redisson Lock이나 LuaScript 기반 연산이 실패할 경우에는 lock 획득 실패 로직에 따라 재시도 또는 예외 처리를 수행하고, 임계구간에서는 fallback 전략(예: 큐에 저장 후 지연 처리, 유저에게 대기 안내)을 적용해 일관성을 지키며 사용자 경험을 유지합니다.장애 상황은 ELK와 Sla..