우당탕탕

Spring Security + Redis로 DDoS 방어 구축하기 서버를 운영하다 보면 DDoS 공격과 같은 외부 공격을 받는 경우가 존재합니다. API 호출이 초당 10만 건 정도로 폭주하면 Redis 캐싱과 Spring Security 조합으로 99.9% 차단이 가능합니다. 실제 운영 경험에서 Redis 분산 락 + Rate Limiting으로 트래픽 폭증 시 CPU 사용량을 80% → 25%로 줄인 사례를 코드와 함께 정리했습니다.DDoS 공격 패턴과 Redis의 역할운영 중 자주 보는 DDoS 패턴은 IP 단위 초당 1000+ 요청입니다. Spring Security만으로는 IP 블랙리스트가 메모리 폭증하고, Redis는 분산 환경에서 상태 공유가 핵심입니다. 공격 유형 Redis 활용 차..

운영 환경을 위한 실용적인 로그 레벨 설정 방법 운영 환경에서 로그 레벨을 어떻게 설정하는지는 서비스 안정성과 디버깅 효율성을 좌우합니다. 개발 중에는 DEBUG로 모든 걸 찍다가 운영에 배포하면 로그가 폭주하거나 반대로 중요한 정보가 누락되는 경우가 많죠. 개인적으로 Spring Boot MSA 운영하면서 느꼈던 로그 레벨 경험을 정리해 보겠습니다.로그 레벨별 실제 사용 사례먼저 운영하면서 자주 쓰는 로그 레벨을 환경별로 표로 정리하면 다음과 같습니다.DEBUG는 개발/테스트 전용입니다. 운영에서 켜두면 CPU 15-20% 추가 소모 + 디스크 I/O 폭증으로 서비스가 다운됩니다. 실제로 한 번 DEBUG를 실수로 켜두고 트래픽 폭증 시 로그 파일 용량초과로 서버가 다운된 적이 있습니다.Spring B..

빈 라이프사이클과 초기화 실수 feat. Proxy(프록시) 이번에는 프록시와 내부 호출에서 벗어나, 스프링에서 자주 실수하는 빈 라이프사이클 및 초기화와 관련된 내용을 다룹니다.1. @PostConstruct 초기화 타이밍 실수스프링 빈이 생성되고 DI가 끝난 후 호출되는 @PostConstruct 하지만 이 시점에 DB 커넥션 등 외부 자원이 완전히 준비됐다고 기대하면 안됩니다.예를 들어 DB 트랜잭션이나, 다른 빈에서 초기화를 의존할 때 순서 관련 오류가 자주 발생합니다.@Componentpublic class MyBean { @Autowired private UserRepository userRepository; @PostConstruct public void init() ..

@Transactional 분리 시 발생하는 Self Invocation 오류와 그 원인 및 해결Self Invocation과 @Transactional의 관계
Spring에서 트랜잭션을 선언할 때 흔히 사용하는 방식은 바로 @Transactional 어노테이션을 메서드나 클래스에 붙이는 것이다. 이 어노테이션 덕분에 해당 메소드의 실행 시작과 함께 트랜잭션이 열리고, 작업이 끝나면 커밋 또는 롤백이 자동으로 처리된다. 그런데 개발하다 보면 이런 상황이 자주 생긴다.“한 서비스 내 메소드A에서 메서드 B를 호출하는데, B에만 @Transactional을 붙였더니 트랜잭션이 동작하지 않는 것 같다?” “@Transactional(propagation=REQUIRES_NEW)로 새로운 트랜잭션을 만들었는..

Redis + Lua Script를 활용한 분산락안녕하세요!이번 글에서는 대규모 분산 환경에서 안전하게 “한 번에 한 명만” 작업이 이루어지게 하는 Redis + Lua Script 기반 분산 락을 알아보고 예시코드를 통해 개발하는 방법을 알아보도록 하겠습니다. 이전 글 보러가기[동시성 제어 1편] 동시성 제어란? - 데이터가 꼬이지 않는 백엔드의 첫걸음[동시성 제어 2편] 비관적 락(Pessimistic Lock) - JPA 스프링으로 경험해보는 실전 가이드[동시성 제어 3편] 낙관적 락(Optimistic Lock) - @Version 어노테이션을 활용한 락1. 분산락이란? 왜 Redis에서 구현할까• 서버가 2대 이상(마이크로서비스, 스케일아웃 인프라 등)인 환경
→ DB 락/코드 수준 락으로는 “..

[동시성 제어 3편] 낙관적 락(Optimistic Lock)안녕하세요!지난 글에서는 비관적 락(Pessimistic Lock)에 대해 알아보았습니다. 오늘은 그 반대 성격의 낙관적 락(Optimistic Lock)을 실전 코드 중심으로 정리해 보려고 합니다.이전 편 보러 가기[동시성] 동시성 제어란? - 1편 (데이터가 꼬이지 않는 백엔드의 첫걸음)[동시성 2편] 비관적 락(Pessimistic Lock) - JPA 스프링으로 경험해 보는 실전 가이드1. 낙관적 락(Optimistic Lock)이란?이름 그대로 "충돌이 자주 일어나지 않을 것"이라는 낙관적 가정!여러 트랜잭션이 동시에 데이터를 읽고, 수정 시점에만 충돌이 있는지 검사▶️ 행(row)을 잠그지 않고, 데이터를 자유롭게 읽게 한 뒤, 커밋..