코드 저장소.

목차1. 도입 배경2. EOS(Exactly Once Semantics) 접근 방식3. 설계 및 구현 방법4. 성능 측정5. 후기 1. 도입 배경현재 서비스는 Outbox + DLQ + Retry 구조로 이벤트 발행 및 복원력을 확보하고 있습니다. 이 방식은 at-least-once 전달 보장을 만족하여 메시지 유실은 방지할 수 있습니다. Outbox로 DB 트랜잭션과 메시지 발행의 원자성을 맞췄고, DLQ/Retry를 통해 장애 상황에서도 재처리가 가능하기 때문에 안정적으로 이벤트를 보낼 수 있습니다. 하지만 여전히 한 가지 문제가 남아 있습니다. 메시지의 중복 처리입니다. 문제의 소지는 동일한 Outbox 이벤트가 재발행되었을 때 Retry 스케줄러가 같은 이벤트를 재전송했을 때 Consumer가 재..

목차1.OpenFeign 에서 WebClient로 바꾸게 된 이유2. 일정추천의 고도화 작업 3. 적용 결과4.후기 1.OpenFeign 에서 WebClient로 바꾸게 된 이유처음 일정 추천 기능을 OpenAI API와 연동할 때는 OpenFeign을 사용했다. 단순하게 동작했고 구현 난이도도 낮았지만, 실제 운영 환경에서는 여러 제약이 드러났다. 1-1. GraalVM을 도입을 하기 위해서 현재 배포된 프로젝트의 서버의 용량이 2GB인 점에서 서버를 띄우게 되면 서버의 메모리가 500MB밖에 남지 않았다는 점으로 graalvm을 적용을 하게 되면 서버 메모리의 양을 줄일 수 있다는 장점이 있기 때문인데. 하지만 GraalVM 적용 시 OpenFeign은 다음과 같은 기술적 문제점이 있습니다. Op..

목차1.도입 배경2.문제 분석3.캐시 적용4.느낀점 1.도입 배경CI/CD 파이프라인을 GitHub Actions로 구성한 이후, 커밋이나 PR마다 평균 2~3분의 빌드 시간이 소요되는 문제가 있었습니다.현재 프로젝트는 멀티모듈 Gradle 기반으로 구성되어 있으며, 외부 의존성도 많아 빌드 성능의 손실이 반복되고 있었습니다.단순한 변경 사항이나 테스트 커밋임에도 매번 전체 빌드를 새로 수행해야 했고, 이로 인해 개발 흐름이 끊기거나 PR 리뷰 속도가 느려지는 병목이 발생했습니다.운영 환경 배포를 자동화하기 위해 CI를 구성했지만, 오히려 개발 속도를 방해하는 상황이 생긴 것입니다.2.문제 분석GitHub Actions는 매 빌드마다 새로운 VM 환경에서 실행되기 때문에, 기존에 다운로드된 의존성 파일(..

목차1. 도입 배경 2. 고도화 구현 사항3. 성능 비교: 기존 S3 직접 업로드 vs Presigned URL 방식 4. 회고 및 향후 개선점 1. 도입 배경현재 Presigned URL 기반 구조를 도입하였지만, 다음과 같은 이슈들이 남아있었습니다. MIME 타입 우회 가능성클라이언트에서 확장자만 검사하고 서버에서 MIME 검사를 하지 않으면, 악성 파일을 .jpg 등으로 위장하여 업로드할 수 있다는 점이 있습니다. 이는 보안적인 리스크로 이어질 수 있습니다. (예: XSS, 다운로드 시 실행 파일 위장 등)고아 객체 문제클라이언트가 Presigned URL로 S3에 파일은 업로드했지만, 최종적으로 등록 API를 호출하지 않고 종료할 경우, S3에는 미사용 파일이 남게 됨.누적되면 저장 공간 낭비 및..

목차1.기존 구조의 문제점2.문제 분석3.문제 해결4.후기 1.기존 구조의 문제점일정 관리 프로젝트를 라이트세일의 2GB서버에 띄우고 모니터링을 구축을 하기 위해서 도커 컴포즈를 사용해서 띄운 것은 아래와 같습니다.Spring BootNginxRedisKafkaZooKeeperGrafanaPromtailPrometheusLokiKafka Exporter/ Redis Exporter그리고 사진과 같이 모든 서비스를 하나의 서버에 동시에 띄우니 1.53GB까지 올라가더니 모니터링을 켜면 메모리 과부하로 인해서 서버가 다운이 되는 현상이 발생을 했습니다. 2.문제 분석우선은 이러한 문제점에 대한 원인은 아래와 같습니다.모니터링 스택이 가벼운 줄 알았으나, Loki,Grafana,Prometheus 자체가 상당..

목차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}",..