코드 저장소.

목차1.도입: 왜 도입을 했는가?2.아키텍처 개요3.Prometheus로 메트릭 수집4.Loki + Promtail로그 수집5. Grafana로 통합 대시보드 구성6.느낀점 1.도입: 왜 도입을 했는가?일정관리 프로젝트 개발 초기에는 Spring Boot의 MDC(Mapped Diagnostic Context)를 활용해서 requestId, username 등의 식별자를 로그에 포함시키고, 콘솔(logback)을 통해 디버깅을 진행했다.MDC.put("requestId", UUID.randomUUID().toString());MDC.put("username", authentication.getName()); { "timestamp": "%d{yyyy-MM-dd'T'HH:mm:ss.SSSZ}", ..

목차1. 왜 통합 테스트가 필요했는가?2. Testcontainers 기반 인프라3. 테스트4. 회고 1. 왜 통합 테스트가 필요했는가?이번 일정 관리 프로젝트는 기획 단계부터 Kafka, Redis, RDS(MySQL) 등 다양한 외부 시스템과의 연동을 기반으로 설계되었습니다. 특히 Kafka를 통한 이벤트 기반 구조, Redis를 활용한 캐시 및 분산 락 처리, RDS와의 스케줄러 기반 트랜잭션 흐름 등은 단순한 로직 검증을 넘어서, 실제 환경과 유사한 상황에서 전체 동작 흐름을 검증할 필요가 있었습니다. 처음부터 mock/stub 기반 단위 테스트 대신, "외부 시스템을 포함한 통합적인 테스트 환경을 어떻게 구성할 것인가?"가 주요 고민이었습니다. 실제 테스트 중 직면했던 이슈는 다음과 같습니다:K..

목차1. 도입 / 배경2.MobaXterm을 활용한 배포 자동화 & 운영3.후기 1. 도입 / 배경지난글에서는 배포를 할 기본적인 인프라를 세팅을 했고 이번에는 GithubAction을 활용해서 CI/CD를 구축을 하기로 했습니다. CI/CD를 적용을 하게 된 이유는 아래와 같습니다.수동으로 서버를 올리면서 배포를 하면 작업을 하는데 있어서 시간소모가 크다.작업을 하면서 운영을 하기 위해서는 빌드,테스트,배포를 자동화하는 것이 필요.위와 같은 이유로 GithubAction을 사용해서 CI/CD를 구축을 하고자 합니다. 그래서 이번글의 목표는 아래와 같습니다.main 브랜치에 코드가 머지되면 자동으로 빌드/테스트/배포가 이루어지게 만드는 것운영 서버에서는 실제 서비스가 무중단으로 배포/재시작되는 구조로 만..

목차1.왜 Outbox가 필요했는가?2.Outbox 패턴이란?3.프로젝트에 적용4.후기 1.왜 Outbox가 필요했는가?기존의 프로젝트에서는 회원가입, 일정 등록 등 주요 도메인 이벤트 발생 시 ApplicationEventPublisher를 통해 비동기로 알림이나 이메일을 발송하고 있었다. 하지만 이 방식은 트랜잭션과 이벤트 발행 시점이 분리되어 있어 문제가 발생했다.예를 들어 DB에 저장되기 전에 Kafka나 Email 발송이 먼저 일어나거나, DB 트랜잭션은 롤백되었는데 Kafka 이벤트는 발행되어 데이터 불일치가 발생할 수 있었다. Kafka를 직접 발행하는 구조로 바꾸더라도 KafkaTemplate.send()는 비동기 Future 기반이라 동기 트랜잭션과 연동하는 것이 어려웠고, 장애 발생 시..

목차1.문제점2.해결 전략 – 후처리 아키텍처 도입3.적용 구조 및 구현4.후기 1.문제점회원가입 시 인증 메일을 전송하거나, 각종 알림 메일을 발송하는 기능은 대부분의 서비스에서 필수입니다. 하지만 실제 운영 중 다음과 같은 문제가 발생했습니다: - 메일 서버의 일시적인 장애- SMTP 인증 실패 - 네트워크 지연 및 타임아웃 - `MessagingException` 등의 예외 발생 이런 예외가 발생했을 때, 시스템이 아무런 후처리를 하지 않는다면 중요한 이메일이 유실되고, 사용자 입장에서는 인증/알림을 받지 못해 혼란을 겪게 됩니다. 결국 이러한 구조는 시스템 신뢰도 저하와 사용자 불만으로 이어질 수 있습니다. 2.해결 전략 – 후처리 아키텍처 도입이메일 실패를 무시하지 않고, 시스템이 자동으로 ..

목차1.DLQ를 적용하기 위한 이유2.적용3.후기 1.DLQ를 적용하기 위한 이유Kafka 기반의 알림 시스템을 운영하면서, 메시지 컨슈머에서 특정 상황에서 예외가 발생하는 문제를 마주했습니다. 예를 들어 DB 저장 실패, WebSocket 전송 실패, 직렬화 오류 등 다양한 이유로 Consumer에서 예외가 발생할 수 있습니다. Kafka에서는 기본적으로 Consumer가 예외를 던지면 해당 파티션의 메시지 소비가 멈춰버립니다. 이런 구조에서는 일시적인 오류 하나로 인해 전체 알림 시스템이 영향을 받을 수 있습니다. 이를 해결하기 위해 DLQ(Dead Letter Queue) 를 도입했다. DLQ는 실패한 메시지를 별도의 토픽으로 격리시켜 메시지 유실을 방지하고, 이후에 재처리 로직을 통해 운영..