Kafka Consumer에서 에러가 발생했을 때 그냥 로그만 남기고 넘어가면 해당 메시지는 영원히 유실된다. DLQ(Dead Letter Queue)는 처리 실패한 메시지를 별도 토픽에 보관해 나중에 재처리할 수 있게 해주는 패턴이다. 기존 코드의 문제점 @KafkaListener(topics = "${gateway.kafka.topic}")...

개요 PuppyNote 서비스의 게시물 좋아요 기능을 구현하면서 DB 부하 최소화와 실시간 반영이라는 두 가지 요구사항을 동시에 만족시켜야 했다. 단순히 좋아요를 누를 때마다 DB에 바로 쓰는 방식은 트래픽이 몰릴 때 DB 부하가 급격히 증가한다. 이를 해결하기 위해 Redis Write-Behind Cache 패턴을 적용했다. 문제 정의 ...

Kafka를 직접 구성하고 운영하면서 생긴 궁금증들을 파고든 내용을 정리했다. 1. 브로커 구성 - 왜 3대인가 Kafka 클러스터는 과반수(Quorum) 원칙으로 동작한다. 브로커 수 과반수 허용 장애 수 1대 1대 0대 ...

이전 포스팅에서 Kafka 단일 브로커로 IoT 데이터 파이프라인을 구성했다. 단일 브로커는 브로커가 죽는 순간 전체 파이프라인이 멈춘다. 운영 환경에서는 이를 허용할 수 없어 VM 3대로 Kafka 클러스터를 구성했다. 왜 3대인가 Kafka 클러스터는 과반수(Quorum) 원칙으로 동작한다. 브로커 수 ...

IoT 기기에서 수집된 데이터를 저장하는 파이프라인을 운영하던 중, 기존 아키텍처의 한계를 느끼고 Kafka 기반으로 전환하게 되었다. 기존 아키텍처 IoT 기기 → MQTT → Gateway 서버 → Azure Function App → Table Storage ...

개요 이전 포스트에서 해시태그 검색 성능 비교를 통해 Elasticsearch 도입을 결정했다. 이번에는 MySQL을 원본 데이터 저장소로 유지하면서 Elasticsearch와 자동으로 동기화하는 파이프라인을 Logstash로 구축한 과정을 정리한다. 아키텍처 [Spring Boot 앱] │ ▼ MySQL (post...

개요 PuppyNote 서비스의 게시물 검색 기능을 개선하면서 MySQL과 Elasticsearch 중 어느 쪽이 더 적합한지 판단하기 위해 성능 벤치마크를 진행했다. 100만 건의 게시물 데이터를 기준으로 해시태그 정확 검색 시나리오에서 두 기술의 평균 응답 시간을 비교했다. 테스트 환경 및 데이터 구성 항목 ...

개요 ALB나 Auto Scaling Group 없이 EC2 단일 서버에서 Blue/Green 무중단 배포를 구현했습니다. Nginx의 proxy_pass 포트를 배포 시마다 교체하는 방식으로, 추가 인프라 비용 없이 다운타임 제로 배포가 가능합니다. 기존 In-place 배포의 문제 stop.sh → 기존 프로세스 종료 ← 이 순간 ...

개요 PuppyNote 서버를 GitHub에 push하면 자동으로 EC2에 배포되는 CI/CD 파이프라인을 구축했습니다. AWS CodePipeline, CodeBuild, CodeDeploy를 활용했고 서버는 t4g.small(ARM64) EC2 인스턴스를 사용합니다. 전체 아키텍처 GitHub (main push) → CodePipe...

개요 커뮤니티 기능에 해시태그 검색을 구현하면서 Elasticsearch를 도입했습니다. MySQL의 LIKE 검색은 인덱스를 타지 못해 대규모 데이터에서 느리지만, Elasticsearch는 역색인(Inverted Index) 구조로 구글처럼 빠른 검색이 가능합니다. 이 글에서는 Docker Compose로 Elasticsearch와 Kibana...