pandaterry's 개발로그

운영 중 발생한 장애를 원인부터 끝까지 추적하려면, 신뢰할 수 있는 로그가 반드시 필요합니다. 특히 JPA를 사용하는 시스템에서는, 엔티티가 변경될 때마다 무엇이 바뀌었고, 누가 변경했으며, 언제 어떤 요청에서 발생했는지 그 이력을 상세히 남기는 일이 중요합니다. 많은 시스템에서는 Kafka나 Redis Stream, 또는 Change Data Capture 기반 구조를 활용합니다. 하지만 다음과 같은 환경에서는 그런 선택이 불가능합니다.외부망과 완전히 단절된 폐쇄망 환경 (군/금융기관 등)Kafka, Redis, ELK 등 인프라 설치 자체가 제한된 경우외부 브로커 없이도 로그 유실 없는 처리가 요구되는 상황실제로 제가 경험한 한 시스템은 배치 업로드 한 번에 수만 건 이상의 엔티티가 변경되는 구조였습..

배경요즘 SQL ResultSet을 받아 데스크톱 앱에서 바로 엑셀 파일로 내려주는 서비스를 개발 중입니다. 초기에는 수만 건 단위의 다운로드만 고려했지만,“고객사의 요구에 따라 향후 수백만 건, 심지어 수천만 건까지 조회량이 늘어날 수도 있겠다” 는 생각이 들었습니다. 아직 실제로 그런 대규모 요청이 들어온 것은 아니지만, 미리 대비하지 않으면 나중에 갑작스러운 부하에 허용하지 못할 수 있습니다. 그래서 이번에는 JVM 힙 2 GB 환경에서 잠재적인 극한 부하를 가정해 보고자 합니다. 다음 세 가지 기법을 동일 조건에서 비교·검증하며, “어떤 구조가 가장 안정적으로 견딜 수 있을까?”를 확인해 보겠습니다. 근데 왜 JVM 힙을 2GB로 제한했는가?이번 실험에서 JVM 힙을 2GB로 제한한 이유는 단..

이전 글(https://pandaterry.tistory.com/10)에서는 Redis AOF, RDB과 Kafka를 비교하며 메시지 유실 문제를 직접 실험했습니다. AOF(Append Only File)와 RDB 설정을 활용해 Redis에 유실되지 않는 메시지 큐 구조를 흉내내는 실험을 진행했었고,단순 큐잉 수준에서는 Redis로도 Kafka의 일부 역할을 대체할 수 있다는 가능성을 확인했습니다. 하지만 여전히 해결되지 않은 문제가 있었습니다. Kafka가 주목받는 진짜 이유는 ‘복구’와 ‘재처리’에 있습니다. 단순히 메시지를 저장하는 것을 넘어서,누가 메시지를 소비했는지 추적하고실패한 메시지는 다시 재시도하거나결국에는 DLT(Dead Letter Topic)으로 보낼 수 있는 운영 가능한 복구 흐름..

이전 글(https://pandaterry.tistory.com/9)에서는 Redis Pub/Sub과 Kafka를 비교하며 메시지 유실·재처리 이슈를 검증했습니다. 이번 글에서는 “Redis만으로도 신뢰형 메시지 큐를 구현할 수 있지 않을까?”라는 의문으로 다음 방식으로 직접 비교·실험해보겠습니다. 왜 Pub/Sub만으로는 부족했을까?현재 개발중인 SaaS 서비스는 “사용자의 Saas 기능 사용 -> 사용량 측정”이라는 흐름을 비동기로 처리합니다. 이 구조에서 가장 먼저 선택한 메시지 브로커는 Redis Pub/Sub이었습니다. 설정이 간단하고, 즉각적인 전달이 가능했기 때문입니다.하지만 곧 문제를 마주하게 됩니다."만약 메시지를 구독 중이던 서버가 죽는다면?""그 사이에 발행된 메시지는 어떻게 되는가..

Kafka로 전환하기 전, 직접 실험해봤습니다 SaaS에서 비동기 메시지는 선택이 아니라 필수입니다제가 구축하고 있는 SaaS 시스템은 마케팅/비즈니스 부서가 자연어로 데이터를 요청하면, 그 요청을 백엔드에서 SQL로 변환하고 엑셀로 응답해주는 플랫폼입니다. 문제는 여기서 끝나지 않았습니다. 사용자의 요청은 내부 시스템에서 백엔드 작업자에게 전송돼야 하고동시에 로그로 남겨져야 하며실패 시 재시도도 가능해야 합니다 처음엔 Redis Pub/Sub으로 충분하다고 생각했습니다.하지만 “요청이 처리됐는지 안 됐는지조차 확인할 수 없다면, 그건 SaaS가 아니라 알 수 없는 상자”가 되어버리더군요. 그래서 Kafka를 검토하게 되었고, “진짜로 필요한가?”라는 의문에 답하기 위해 직접 실험을 진행했습니다...

1.  마케팅이 더 이상 '마케팅'이 아닌 시대 예전에는 마케팅하면 5P(Product, Price, Promotion, Positioning, Publicity) 만 잘해도 성공할 수 있었다.하지만 지금은 다르다. 소비자는 이미 모든 것을 갖고 있다. 이제는 '어떻게 팔 것인가'보다 ‘무엇을 만들 것인가’가 중요한 시대다. 사람들의 주의를 끌지 못하면, 광고는 무시당하고, 제품은 존재조차 알리지 못한 채 사라진다. 그래서 등장한 개념이 바로 ‘퍼플 카우(Purple Cow)’,즉 주목받을 만한(Remarkable) 제품이다.  2.  퍼지는 아이디어가 이긴다 – 스니저와 오타쿠 제품을 성공시키는 것은 광고가 아니라 ‘입소문을 퍼트릴 사람들’이다. 이 책에서는 그들을 스니저(Sneezer)라고 부른다. ..

개요이 책은 자바 애플리케이션의 디버깅과 성능 최적화를 위한 다양한 기법과 도구를 소개했다. 디버깅의 기본 개념부터 시작해 복잡한 멀티스레드 환경에서의 문제 해결, 메모리 누수 찾기, 그리고 대규모 시스템 분석까지 폭넓게 다루었다.주요 내용 요약디버깅의 본질과 기본 기술디버깅은 단순히 오류를 찾아 수정하는 것만이 아니라 애플리케이션의 작동 방식을 이해하고 새로운 기술을 습득하는 과정이기도 하다. 디버깅의 목적은 예상한 결과와 실제 결과 간의 차이를 밝히는 것이며, 이를 위해 디버거, 프로파일러, 로깅 등 다양한 도구를 상황에 맞게 활용해야 한다.코드만으로는 애플리케이션의 로직을 완전히 이해하기 어려운데, 이는 코드가 선형적으로 읽히지 않고 인지적 복잡성이 높기 때문이다. 디버거를 활용하면 코드의 실행 흐..

사가 패턴 : 오케스트레이션여러 마이크로서비스에 걸친 분산 트랜잭션을 관리하기 위해 사용한다.일련의 로컬 트랜젝션으로 만들어서 비즈니스 프로세스를 구성하고, 각 단계별로 실패시 보상 트랜젝션을 통해 이전 상태로 롤백한다.사가 오케스트레이션 + 아웃박스 패턴Command는 즉시성때문에 아웃박스 XOrchestrator가 각 서비스에 명령(Command)를 보낼 때 아웃박스 패턴을 사용하지 않음. (바로 카프카로 전송. 그리고 아웃박스 패턴을 사용하려면 Command도 EventStore에 저장해야하는데, Relay하지도 않는 메시지를 굳이 이벤트 스토어에 저장하여 부하를 발생시킬 이유도 없음.)이벤트로 비동기 응답처리는 아웃박스 O각 서비스의 Response(성공/실패)도 아웃박스 패턴으로 발행타 마이크로..