2026/06 14

CSR 방식을 SSR 방식으로 변경했더니 생긴 문제점

1. 개요요청량이 많이 몰리는 프론트 페이지가 있음.서비스의 모든 기능이용의 진입점으로, 누구나 반드시 거쳐야 하는 화면이다. Node.js로 운영된다. 이 페이지의 프론트 렌더링 방식을 CSR에서 SSR로 바꿨다. SSR이 더 우아한 선택처럼 보였으니까.그런데 그 변경 하나가, 신규 서비스 론칭 날 전체 서비스를 30분간 멈춰 세웠다. 렌더링 방식을 바꿨을 뿐인데 어떻게 시스템 전체가 마비됐을까. 2. 문제신규 서비스 출시 순간 해당 페이지로 Burst 트래픽이 몰렸다. 평소의 완만한 곡선이 아니라, 짧은 시간에 수직으로 꽂히는 트래픽이다. Node.js 서버가 과부하에 빠졌다. 요청 응답이 Internal Server Error로 떨어지기 시작했고, 그 상태가 약 30분간 이어졌다. 해당 페이지는 ..

Front-end 2026.06.29

단일 인스턴스 배치를 멀티 인스턴스 구조로 리팩터링: 설계 옵션 비교와 선택

1. 개요정해진 시각마다 도는 batch 서비스가 하나 있다.오래된 데이터를 정리하고, 조건에 맞는 사용자에게 안내 메일을 보내고, 만료된 레코드를 지우는, 흔한 정리성 잡들의 모음이다.지금까지는 인스턴스 한 대로만 돌았다. 한 대뿐이니 @Scheduled로 매일 정해진 시각에 잡을 깨우면 그만이었다. 중복도, 경합도 없다. 이걸 여러 대로 늘리기로 했다. 한 대에 몰리는 부하를 나누고, 그 한 대가 죽으면 서비스가 멈추는 구조도 벗어나고 싶었다.그런데 인스턴스를 열 대로 늘리는 순간 그동안 신경 쓸 필요 없던 것들이 한꺼번에 튀어나온다. 2. 무엇이 문제인가인스턴스를 늘릴 때 가장 먼저 떠오르는 걱정은 중복 실행이다.@Scheduled는 각 인스턴스의 타이머에서 독립적으로 수행된다. 열 대면 같은 잡..

Back-end 2026.06.28

Argo Rollouts로 Canary 배포 도입하기: 트래픽 분할 방식 비교부터 analysis 자동 롤백까지

1. 배경운영 중 배포 도중 문제가 생겨 롤백한 적이 있었다.신버전을 한 번에 전체 파드로 올리다 보니, 이상을 알아챘을 땐 이미 전체 트래픽이 신버전을 타고 있었다.그래서 신버전을 일부 트래픽에만 먼저 노출하고 문제가 없으면 비중을 단계적으로 올리는 canary 배포를 검토하게 됐다. 목표는 두 가지였다.문제가 나도 영향 범위를 canary 트래픽으로 한정하고 즉시 롤백한다.단계마다(ex: 10% → 50% → 100%) 검증하면서 비중을 올린다.환경은 이렇다. 쿠버네티스 클러스터가 버전이 다른 두 종류로 공존하고(argo-rollouts 컨트롤러 v1.2.0과 v1.6.6), 두 클러스터 모두 ingress로 Citrix(NetScaler)를 쓴다.argo-rollouts는 이미 설치돼 있었지만 사내..

Kubernetes 2026.06.28

java 25 가상스레드 적용 시 실제 서비스 기준으로는 얼만큼 성능이 향상될까?

1. 개요Java 21에서 정식화된 가상 스레드(virtual thread)는 Spring Boot 3.2+ 에서 spring.threads.virtual.enabled=true 한 줄로 켜진다. "켜면 처리량이 오른다"는 기대가 흔하다. 운영 중인 서비스(Spring Boot 4 / JDK 25 - vt pinning issue 해소)에 적용하면 실제로 얼마나 빨라질까? 결론은 단순하다. 처리량은 거의 오르지 않는다. 가상 스레드가 효과를 내는 조건은 "병목이 스레드일 때"로 한정되며, 잘 짜인 서비스는 대개 스레드보다 먼저 다른 자원에서 막힌다. 그리고 효과가 실제로 나타나는 지점은 처리량이 아니라 장애 격리다. 2. 가상 스레드는 언제 효과가 있나서버는 보통 요청 1개에 스레드 1개를 할당하는 th..

Back-end 2026.06.28

분산 환경 지연 작업 처리: 설계 대안 비교와 Redisson RDelayedQueue 선택

1. 문제 정의어떤 작업을 지정된 시각에 정확히 한 번 실행해야 하는 경우가 있다. (지연 작업)예를 들어 사용자가 가입한 뒤 24시간이 지난 시점에 온보딩 안내 메일을 1회 발송하는 상황을 생각해 보자.이를 여러 인스턴스로 동작하는 분산 환경(예: Kubernetes replicas)에서 처리하려면 다음을 보장해야 한다.정해진 시각(예: 24시간 뒤)에 작업이 실행될 것인스턴스가 여러 대여도 작업이 중복 실행되지 않을 것어떤 경우에도 작업이 유실되지 않을 것여기에 더해, 운영 관점에서 두 가지를 피하고자 했다. 이 두 가지가 이후 방식 선택의 핵심 기준이 된다.기준 1: 모든 인스턴스가 동시에 무언가를 주기적으로 폴링하는 구조를 피한다.기준 2: 그 폴링이 DB를 향하는 것을 특히 피한다(DB 부하)...

Back-end 2026.06.28