일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- SQL
- 디자인 패턴
- 일정관리프로젝트
- Lv.0
- GIT
- LV02
- 일정관리 프로젝트
- 알고리즘
- CoffiesVol.02
- CI/CD
- Join
- 포트폴리오
- 이것이 자바다
- 프로그래머스
- LV1
- mysql
- 데이터 베이스
- docker
- LV01
- Redis
- LV0
- LV03
- 코테
- 연습문제
- S3
- Java
- spring boot
- LV.02
- JPA
- Til
- Today
- Total
목록2025/05 (8)
코드 저장소.

목차1.Jib이란 무엇인가?2.왜 도입을 했는가?3.프로젝트에 적용4.후기 1.Jib이란 무엇인가?Jib 공식 문서Jib은 구글에서 만든 Java 컨테이너 이미지 빌더다. 간단히 말하면 Dockerfile없이 Gradle이나 Maven 플러그인만으로 Spring Boot프로젝트를 쉽고 빠르게 Docker이미지를 만들 수 있다. 기존 방식 기존의 DockerFile의 경우에는 빌드 → jar 생성 → Dockerfile 작성 → docker build/push 순으로 진행합니다.하지만 이러한 방식은 이미 패키징된 jar 파일을 이미지화 시켰기 때문에 약간의 소스 수정이 일어나더라도 변경된 소스로 인해 dependency들이 포함된 jar 파일 전체가 새로운 이미지로 인식 되어 전체 파일 빌드를 다시 수행하..

목차1.왜 Outbox가 필요했는가?2.Outbox 패턴이란?3.프로젝트에 적용4.후기 1.왜 Outbox가 필요했는가?기존의 프로젝트에서는 회원가입, 일정 등록 등 주요 도메인 이벤트 발생 시 ApplicationEventPublisher를 통해 비동기로 알림이나 이메일을 발송하고 있었습니다. 하지만 이 방식은 트랜잭션과 이벤트 발행 시점이 분리되어 있어 다음과 같은 문제의 소지가 있습니다.이벤트 발행 시점과 DB 트랜잭션 커밋 시점이 분리되어 있어, 데이터의 일관성이 깨질 수 있습니다.Kafka의 이벤트는 발행이 되었지만 DB 저장은 실패를 한 경우 -> 시스템간의 불일치Kafka를 직접 발행하는 구조로 바꾸더라도 KafkaTemplate.send()는 비동기 Future 기반이라 동기 트랜잭션과 연..

목차1. 들어가며2. 가비아 연결 도메인(A레코드 설정)3. AWS Lightsail 인스턴스 설정4.RDS(MySQL 설정)5.회고 1. 들어가며 현재 진행 중인 일정 관리 프로젝트의 첫 번째 배포 환경을 구성하면서 겪은 과정을 기록합니다. 프론트엔드는 Next.js, 백엔드는 Spring Boot 멀티모듈 구조이며, AWS Lightsail, RDS(MySQL), S3, 가비아 도메인을 활용해 실서비스 환경을 구축했습니다.왜 이렇게 인프라를 구성했는가?이번 인프라 설계의 핵심 기준은 "비용 효율성, 학습 난이도, 기능별 분리"였습니다.도메인(GABIA): 국내 도메인 업체 중 가장 직관적이고 저렴한 가격. DNS 설정 UI가 단순해 초보자에게 적합했습니다.Lightsail: EC2보다 저렴하면서도 고..

목차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는 실패한 메시지를 별도의 토픽으로 격리시켜 메시지 유실을 방지하고, 이후에 재처리 로..

목차1.기존의 코드의 문제점2.왜 Kafka를 사용을 했는가?3.적용4.후기 1.기존 코드의 문제점현재 일정관리프로젝트에서는 스프링 이벤트 드라이븐을 사용해서 단일 인메모리 이벤트 처리로 후처리를 하고 있지만 해당 방식에는 다음과 같은 문제가 있습니다. 비동기 처리라 해도 같은 서버 내에서만 작동→ 서버가 죽거나 장애가 발생하면 스프링 이벤트는 영속성이 없어서 유실이 된다는 점입니다. 후처리 로직이 많아질수록 하나의 서비스에 부하 집중서비스 간 확장 어려움→ 향후 알림 시스템을 별도 분리하고자 할 때 제약이 됩니다. 결론적으로, 비동기 이벤트 처리의 영속성, 확장성, 결합도 측면에서 한계를 드러내기 시작했다.2.왜 Kafka를 사용을 했는가?카프카는 분산 메시징 시스템입니다. 물론 Kafka의 대안으로..