1. 기존 응원 등록 흐름의 구조적 한계현재 Eatda의 응원 등록 기능은DB 트랜잭션 내부에서 S3 이미지 복사 작업을 함께 수행하는 구조로 구현되어 있습니다.응원 등록 요청 하나는 다음과 같은 흐름으로 처리됩니다.응원 정보 DB 저장S3 임시 경로에 업로드된 이미지를 도메인 하위의 영구 경로로 복사응원 최종 발행 처리이 모든 과정이 하나의 DB 트랜잭션 안에서 순차적으로 실행되고 있었고,트랜잭션 범위 안에 S3 이미지 이동이라는 외부 작업이 포함되어 있습니다. 문제 1. 트랜잭션 내 외부 I/O로 인한 자원 점유이 구조에서는 S3 호출이 트랜잭션 안에 포함되기에요청 처리 시간이 길어질수록 DB 커넥션과 스레드를 불필요하게 오래 점유하게 됩니다.트래픽이 증가할 경우, 이는 커넥션 풀 고갈이나 스레드 ..

1. 무엇이 문제였고 왜 개선이 필요했을까?Eatda 서비스를 운영하면서 Datadog을 본격적으로 도입해 사용하고 있었습니다.초반에는 익숙하지 않기도 했고, 빠르게 적용해야 하는 상황이 많다 보니대부분의 대시보드나 알람을 Datadog 콘솔에서 직접 만들며 운영했습니다. 하지만 서비스의 모든 인프라 리소스를 Terraform으로 관리하는 구조에서콘솔 기반 설정은 재현성이나 변경 이력 관리가 어렵다는 점에서 계속 아쉬움이 남아 있었습니다.GitHub 이슈에도 “Datadog Terraform으로 관리”를 등록해두었지만급한 일이 아니다 보니 작업 순위가 뒤로 밀린 상태였습니다.비슷하게 알람도 하나의 Discord 채널에SLO Burn Rate 알람메트릭 기반 주의/경고개발 환경 리소스 부족으로 인한 알람이..

2025년 10월 24일 파르나스에서 열린 Datadog Summit Seoul을 다녀왔다.작년 AWS Summit 이후 오랜만에 오프라인 기술 컨퍼런스에 참석할 수 있는 기회였다.요즘 대부분의 행사가 추첨제로 진행되기에 참여할 기회가 적었는데,Datadog Summit은 신청만으로 참여할 수 있어 망설임 없이 등록했다. 기존에 Datadog를 사용해볼 기회가 없었는데,Eatda 프로젝트를 진행하며 동료인 충안님 도움으로모든 모니터링은 Datadog 환경에서 구축해놓아 꾸준히 관심이 있었다.관심점행사 일정은 오전에는 기조연설, 오후는 세션 및 워크샵으로 구성되어 있었다.그중에서 가장 흥미가 있던건 SRE 실습 워크샵이였는데Eatda 프로젝트에서 SLI/SLO를 도입기를 쓰며, 스스로도 “내가 제대로 알고..

문제상황Eatda 서비스의 Datadog 모니터링 대시보드에서 P95 500 ms 이하 SLO 알람이 연속적으로 발생했습니다./api/shop, /api/store, /api/cheer API의 응답 시간이 주기적으로 500 ms를 초과했고,이는 일시적인 트래픽 증가가 아닌 구조적 병목으로 의심되었습니다. 쿼리 로그를 확인해보니 세 API가 공통적으로 EntityGraph와 Pageable을 함께 사용하고 있어이 조합이 원인일 가능성이 높았습니다.따라서 데이터 접근 방식과 쿼리 실행 구조를 점검하기로 했습니다.원인 분석EntityGraph는 연관된 엔티티를 함께 조회하기 위해 Hibernate가 fetch join을 수행하도록 지시합니다.문제는 여기에 Pageable이 결합될 때 발생합니다. Hibern..

1. 왜 SLI와 SLO가 필요한가?Yapp 26기 활동이 끝나고 Eatda라는 맛집 리뷰 플랫폼 서비스를 출시했습니다.신규 기능 개발에만 집중하던 시기와 달리 이제는 로그를 확인하거나 모니터링을 보는 일이 훨씬 줄어들었습니다. 현재 개발팀은 신규 기능 개발보다는 미뤄왔던 리팩터링 작업등 개선에 집중하고 있습니다.이와는 별개로 PD팀에서는 현재 서비스의 마케팅 집행을 준비하고 있는 상태입니다. 마케팅을 집행하고 실제 신규 유저들이 들어올 때 서비스 품질이 낮다면 사용자 리텐션을 보장할 수 없습니다.따라서 장애가 발생하기 전에 방지하고, 개발팀이 상시 서비스를 모니터링하지 않아도 일정 임계점을 넘으면 즉시 대응할 수 있는 알람 체계가 필요했습니다. 하지만 단순히 에러가 몇 번 발생하면 개발팀을 호출하거나,..

이전 글인 API Latency Postmortem-2 게시글에서 클라이언트로 이미지 업로드 작업을 이관했습니다.이제 마지막 작업으로 프로덕션 환경에 DB 마이그레이션을 적용해야 했습니다.하지만 실 사용자 데이터가 있는 프로덕션 환경에서 DB 구조를 변경하는 것은 고려해야 할 부분이 많았습니다.문제상황1. Flyway 마이그레이션 스크립트 문제클라이언트로 이미지 업로드 작업을 이관했던 이전 작업에서 프로덕션 마이그레이션까지 깊이 고려하지 못했습니다.Flyway 마이그레이션 V7에서 DROP COLUMN을 사용해 이미지 키를 삭제하고 새로운 테이블에 seed 데이터를 넣는 방식으로 개발 서버에 배포된 상태였습니다. 문제는 프로덕션 환경에는 이미 실 사용자 데이터가 존재한다는 점이었습니다. 현재 프로덕션은 ..

이전 글인 API Latency Postmortem 게시글에서 이미지 처리 성능 문제를 다뤘었는데,그 후속 작업으로 이미지 아키텍처 개선을 계획하고 있었습니다.개선 목표 및 계획이번 아키텍처 개선의 주요 목표는 두 가지였습니다.API 응답 속도 개선: 기존 1500ms 이상이던 이미지 관련 API 응답 시간 단축다중 이미지 처리 기능: 단일 이미지에서 다중 이미지 지원으로 확장기존 클라이언트 → 서버 → S3 방식을 클라이언트 → S3 직접 업로드로 변경하여 이를 달성할 계획이었습니다.클라이언트가 서버에 Pre-signed URL 요청서버가 업로드용 URL 반환클라이언트가 S3로 직접 업로드업로드된 파일 키를 서버로 전달연관 작업:이미지 조회 개선: Spring 애플리케이션 내부 캐싱 제거S3와 클라이언..

현재 상황저희 서비스는 Dev 환경과 Prod 환경을 분리해서 배포하고 있으며, 각 환경마다 독립적인 데이터베이스를 운영하고 있습니다.Dev 환경: EC2 인스턴스에서 Spring과 MySQL을 컨테이너로 운영Prod 환경: RDS를 활용한 관리형 데이터베이스 사용또한 이전 포스트모템 과정에서 각 환경의 Spring 컨테이너에 Datadog을 연동해놨기 때문에, 현재 모든 애플리케이션 로그는 Datadog을 통해 수집되고 모니터링되고 있는 상황입니다.문제점Datadog 의존성 문제가장 먼저 떠오른 의문은 "Datadog이 우리 로그를 언제까지 보관해줄까?" 였습니다.현재 팀원이 보유한 Datadog 학생 계정 라이센스를 통해 Pro 기능을 무료로 사용하고 있습니다. 하지만 트레이스는 최근 15분, 로그는..

문제상황Eatda 서비스 배포 후 진행한 2차 사용자 테스트(UT)에서 API 응답 지연 현상을 발견했습니다.일반적인 요청은 1~2초 내에 응답했으나,이미지가 포함된 스토리나 가게 응원 기능의 경우 5초, 길게는 10초 이상 지연되는 사례가 발생했습니다.이 문제는 상시적으로 나타나지 않고 간헐적으로 발생하여, 원인 파악이 어려운 상태였습니다.배경 현재 저희 서비스는 비용 제약으로 인해 인프라 리소스를 최소화한 상태에서 운영되고 있습니다.개발 환경에서는 WAS 컨테이너와 MySQL 컨테이너를 모두 AWS t2.micro 인스턴스에서 구동하고 있습니다.MVP 단계에서도 리소스가 부족한 환경이지만, 비용 최적화를 우선 고려한 선택이었습니다.Spring: 0.25 vCPU, 메모리 256MB 할당MySQL: 0..