코드 저장소.

목차 1. Zookeeper를 걷어낸 이유?2. 마이그레이션 과정 3.회고 1. Zookeeper를 걷어낸 이유?기존의 Kafka는 분산 시스템의 특성상 클러스터의 상태를 관리할 '코디네이터'가 필수적이었습니다. "어떤 브로커가 살아있는지", "누가 리더인지", "설정 정보는 무엇인지"와 같은 핵심 메타데이터를 저장할 별도의 공간이 필요했습니다. 그 역할을 오랫동안 담당해 온 것이 바로 Zookeeper입니다. 하지만 Kafka 2.8 버전부터 KRaft(Kafka Raft)가 등장하며 이 구조는 완전히 뒤바뀌었습니다. 저는 왜 이번 프로젝트에 기존 Zookeeper 기반 구조 대신 KRaft 기반 구조를 선택했는지, 그 이유를 정리해 보았습니다. 1-1. Zookeeper 방식의 한계운영 복잡성의 증가..

목차1.공통 환경 구축: Docker & Docker Compose2.인프라 서버: Nginx & SSL 인증서(Certbot) 적용3.Docker Compose를 통한 서비스 배치4.후기 1.공통 환경 구축: Docker & Docker Compose4대의 EC2 서버에 동일한 런타임 환경을 구축하고, 외부 트래픽을 안전하게 수용하기 위한 SSL 인증서 발급 과정을 정리했습니다.# 패키지 업데이트 및 Docker/Compose 설치sudo apt-get updatesudo apt-get install -y docker.io docker-compose# 사용자 권한 부여 (sudo 없이 Docker 명령 실행 가능)sudo usermod -aG docker ubuntu# 서비스 활성화sudo system..

목차 1.아키텍처 개요 2.인프라 구축 3.회고 1.아키텍처 개요 전환 배경 및 동기 기존에는 AWS Lightsail 환경에서 정해진 예산 내로 서비스를 운영하고 있었습니다. 하지만 프로젝트 규모가 커질수록 Lightsail 환경에서는 몇 가지 한계가 분명해졌습니다. 고정 비용 구조 Lightsail은 인스턴스 실행 여부와 관계없이 월 단위 고정 요금이 발생합니다. 테스트하지 않는 시간에도 비용이 계속 발생해 학습 단계에서는 부담이 되었습니다.제한적인 네트워크 제어 VPC, Subnet, 보안 그룹을 세밀하게 구성하기에는 Lightsail의 네트워크 제어 범위가 제한적이었습니다.단일 장애점(SPOF) 문제 하나의 서버에 모든 컴포넌트가 집중된 구조는 장애 발생 시 전체 서비스 중단 가능성이 높았습..

목차1.왜 로드벨런싱이 필요 했는가?2.로드벨런싱 테스트3.마치며 1.왜 로드벨런싱이 필요 했는가?기존의 프로젝트 배포 환경은 단일 인스턴스였습니다. 비용 문제로 서버를 무한정 늘릴 수 없는 상황에서, 제한된 자원으로 최대한 안정적으로 운영할 수 있는 구조를 고민하면서 진행을 했습니다. 하지만 서버가 죽는 상황 자체를 막을 수는 없었습니다. 그래서 서버가 죽더라도 데이터가 유실되지 않도록 Outbox 패턴과 Kafka 오프셋 커밋 설정 등 여러 장치를 미리 심어두었지만 마음 한편에 걸리는 게 있었습니다. "장치를 아무리 잘 만들어도, 서버 자체가 죽으면 요청을 받을 곳이 없다." 기존의 배포에서는 Nginx를 리버스 프록시와 HTTPS 인증 용도로만 사용하고 있었습니다. 그런데 Nginx의 로드밸런서를..

목차1. 테스트 환경 및 도구2. 테스트 시나리오3. 정상 테스트 결과4. 부하 테스트 결과4-1.50VU - 1차 실패와 원인 분석4-2.50VU - 개선 후 재검증4-3.100VU 5. 일괄 테스트 결과6.후기 1. 테스트 환경 및 도구 테스트를 해볼 서버와 측정 도구에 대한 설명은 아래와 같습니다 서버 환경서버: 2GB VM (JVM 힙 512m~1g, HikariCP max=20)API: 일정 생성 API (/api/schedule/)인증: JWT 헤더 포함측정 도구Jmeter : 요청 부하 발생 및 응답 시간 측정Grafana (Prometheus 연동): JVM Heap, GC, DB 커넥션 풀 등 서버 내부 지표 모니터링2. 테스트 시나리오정상 테스트부하 조건이 없는 상황에서 일정 생성 AP..

목차1.프로젝트 목적2.사용 기술 스택3.아키텍처4.ERD5.주요기능6.전체 개발 과정 정리7.소감 1.프로젝트 목적이 프로젝트는 단순 CRUD 일정 관리에서 출발했습니다. 하지만 실제 서비스를 만들다 보면 일정 생성 이후에 훨씬 많은 일이 발생했습니다.알림 생성반복 일정 전파파일 업로드 처리추천 기능을 위한 외부 API 연동Kafka 기반 비동기 이벤트 처리이 중 하나라도 실패하면 전체 기능이 연쇄적으로 무너질 수 있었습니다. 그래서 이번 프로젝트의 핵심 목표는 비동기 영역에서 발생하는 장애를 어떻게 격리하고, 어떻게 자동 복구할 수 있을까?였습니다. 이를 검증하기 위해 Kafka Outbox + DLQ + 멱등성(EOS) 구조를 직접 설계하고, Prometheus·Loki·Grafana 기반 모니터링..