TwentyTwentyOne

백엔드에서 Rate Limiting은 왜 필요할까? 429 응답, Retry-After, IP·사용자 단위 제한까지 FastAPI · Spring Boot · Node.js 실전 정리백엔드 운영을 조금만 해보면, “장애를 어떻게 복구할까”보다 먼저 부딪히는 질문이 하나 있어요.“애초에 과도한 요청을 어떻게 막을까?”저도 이 구간을 꽤 늦게 체감했어요.처음엔 기능만 잘 만들면 될 줄 알았거든요. 그런데 로그인 API, 검색 API, 문자 발송 API, AI 호출 API 같은 게 붙기 시작하면, “정상 사용자 트래픽”이 아니라 짧은 시간에 몰리는 요청 자체가 문제가 되더라고요.같은 사용자가 버튼을 연속 클릭하는 경우봇이 로그인 엔드포인트를 계속 두드리는 경우비싼 외부 API를 붙인 엔드포인트가 과도하게 호출..

백엔드에서 복원력 패턴은 언제부터 넣어야 할까? Timeout, Retry, Circuit Breaker, Bulkhead를 FastAPI · Spring Boot · Node.js로 이해하기한 줄 요약외부 API 호출이나 느린 작업이 조금만 늘어나면, 백엔드는 “정상 기능 구현”만으로는 버티기 어려워집니다. 이때 제일 먼저 필요한 건 timeout, 그다음은 조건 있는 retry, 그리고 장애 전파를 막는 circuit breaker, 마지막으로 자원 고갈을 막는 bulkhead입니다. HTTPX는 기본적으로 네트워크 비활성 5초 timeout을 강제하고, Resilience4j는 CircuitBreaker, Retry, Bulkhead, TimeLimiter를 공식 제공하며, Spring Cloud ..

분산 트레이싱은 언제부터 붙여야 할까? OpenTelemetry로 요청 흐름을 끝까지 추적하는 방법 — FastAPI · Spring Boot · Node.js로그를 열심히 남겼고, 메트릭도 붙였는데도 답답한 순간이 옵니다.“느린 건 보이는데 어디서 느린지 모르겠다”는 순간이요.예를 들어 이런 상황이죠.API 응답이 2.8초나 걸린다DB는 100ms 정도다외부 결제 API도 가끔 느리다큐 등록도 들어간다그런데 정확히 어디가 병목인지 한눈에 안 보인다이때 필요한 게 분산 트레이싱(distributed tracing) 입니다.OpenTelemetry는 벤더 중립 관측 프레임워크이고, 코드 기반 계측과 제로코드 계측을 모두 지원합니다. 또 context propagation을 통해 서로 다른 서비스에서 생성된..

백엔드 모니터링은 어디서부터 시작해야 할까? 헬스체크, 메트릭, Prometheus까지 FastAPI · Spring Boot · Node.js 실전 정리한 줄 요약운영에서 로그만으로는 부족합니다. 최소한 헬스체크 엔드포인트, 요청 수·에러 수·응답 시간 같은 메트릭, 그리고 필요하면 Prometheus 수집 구조까지 붙여야 “서버가 살아 있나”를 넘어서 “지금 느려졌는지, 에러가 늘었는지, 어디가 병목인지”를 볼 수 있습니다. Spring Boot는 Actuator로 health와 metrics, /actuator/prometheus를 공식 지원하고, Prometheus는 카운터·게이지·히스토그램 같은 메트릭 모델을 제공합니다. FastAPI는 미들웨어로 요청 전후 처리를 넣기 쉽고, Node.js에선..

백엔드 로그는 어떻게 남겨야 할까? FastAPI · Spring Boot · Node.js에서 구조화된 로깅 시작하는 법한 줄 요약운영에서 진짜 도움이 되는 로그는 console.log()를 여기저기 찍는 로그가 아니라, 레벨이 있고, 검색 가능하고, 요청 단위로 묶이고, JSON처럼 구조화된 로그입니다. Python 표준 logging은 유연한 로깅 시스템을 제공하고, Spring Boot는 기본적으로 콘솔 로그와 파일 로그를 지원하며, Spring Boot 3.4부터는 구조화된 로깅 포맷도 지원합니다. Node.js 쪽은 console이 가장 기본이지만, 운영용으론 Pino처럼 JSON 중심 구조화 로그 도구를 쓰는 쪽이 훨씬 낫습니다. (Python documentation)이 글에서 다루는 내용..

백엔드에서 환경변수와 시크릿 관리는 어떻게 해야 할까? .env, 설정 분리, 운영 배포까지 FastAPI · Spring Boot · Node.js 실전 정리한 줄 요약백엔드 설정은 코드에 하드코딩하지 말고 환경변수와 외부 설정으로 분리하는 게 기본입니다. FastAPI는 Pydantic Settings로 .env와 환경변수를 다룰 수 있고, Spring Boot는 외부 설정 파일·환경변수·명령줄 인자를 함께 지원합니다. Node.js도 process.env로 환경변수를 읽고, 최근 버전에서는 --env-file로 .env 파일을 직접 불러올 수 있습니다. 12-Factor App 역시 설정은 코드에서 분리해 환경변수로 관리하라고 권장합니다. (FastAPI)이 글에서 다루는 내용환경변수와 시크릿이 왜..

웹훅(Webhook)은 어떻게 안전하게 받아야 할까? 서명 검증, 멱등성, 재시도까지 한 번에 정리 — FastAPI · Spring Boot · Node.js한 줄 요약웹훅은 “외부 서비스가 우리 서버로 보내는 이벤트”인데, 진짜 실무에서는 그냥 POST 받기가 아니라 원본 바디(raw body)로 서명 검증하고, 중복 이벤트를 막고, 빠르게 2xx 응답한 뒤 비동기 후처리하는 구조로 가야 덜 망가집니다. Stripe는 Stripe-Signature 헤더와 원본 요청 바디로 서명을 검증하라고 안내하고, GitHub도 X-Hub-Signature-256으로 HMAC 검증을 하라고 공식 문서에서 설명합니다. (Stripe Docs)이 글에서 바로 정리할 것웹훅이 정확히 뭔지왜 웹훅 엔드포인트는 일반 API..

폴링, SSE, WebSocket 중 뭐가 맞을까? 비동기 작업 상태를 실시간으로 보여주는 백엔드 설계 — FastAPI · Spring Boot · Node.js한 줄 답작업 상태 조회는 처음엔 폴링으로 시작하는 게 가장 현실적이고, “서버에서 클라이언트로 일방향 업데이트”만 필요하면 SSE, 채팅처럼 양방향 통신이 필요하면 WebSocket이 맞습니다. FastAPI는 EventSourceResponse 기반 SSE와 WebSocket을 공식 문서에 두고 있고, Spring은 SseEmitter와 STOMP over WebSocket을 지원하며, Node.js 쪽은 브라우저 EventSource와 ws 라이브러리 조합이 가장 흔한 선택지입니다. (FastAPI)이 글에서 바로 정리할 것폴링, SSE,..

비동기 작업을 큐에 넣은 다음엔 뭘 봐야 할까? 작업 상태 추적, Job Status API, 폴링 구조 정리 — FastAPI · Spring Boot · Node.js한 줄 요약비동기 작업과 큐를 도입했다면, 다음 단계는 **“작업이 지금 어디까지 갔는지 추적할 수 있게 만드는 것”**입니다. 사용자는 요청이 접수됐는지, 처리 중인지, 실패했는지 알고 싶고, 운영자는 어떤 작업이 자주 실패하는지 봐야 합니다. 그래서 보통 job_id, status, progress, result, error_message를 포함한 작업 상태 모델과, 이를 조회하는 Job Status API를 같이 설계합니다.이 글에서 다루는 내용비동기 작업 다음에 왜 상태 추적이 필요한지QUEUED, PROCESSING, SUCCE..

백엔드에서 비동기 작업과 큐는 언제 도입해야 할까? FastAPI · Spring Boot · Node.js로 보는 실전 기준한 줄 요약비동기 작업은 사용자가 기다릴 필요 없는 일을 요청-응답 흐름 밖으로 빼는 방식이고, 큐는 그 일을 안전하게 쌓고, 나중에, 다시, 다른 워커가 처리하게 만드는 구조입니다. 메일 발송, 이미지 리사이즈, AI 요약, 웹훅 후처리처럼 느리거나 실패 가능성이 있는 작업은 큐로 빼는 게 보통 더 안정적입니다. (FastAPI)이 글에서 다루는 내용비동기 작업이 왜 필요한지BackgroundTasks, @Async, setTimeout 수준으로 끝나는 일과 큐가 필요한 일을 어떻게 구분하는지FastAPI, Spring Boot, Node.js에서 바로 시작 가능한 최소 구현재시..