어제 오늘 내일

MVC에서 List를 리턴하면 "유저 목록이구나", User를 리턴하면 "단건 조회구나"라고 바로 알 수 있죠.WebFlux에서도 마찬가지입니다. 리턴 타입만 봐도 "데이터가 몇 개 흐를지" 예측할 수 있어야 합니다.WebFlux의 기반 라이브러리인 Project Reactor는 데이터를 담는 그릇을 딱 두 가지로 정의했습니다.바로 Mono(모노)와 Flux(플럭스)입니다.1. Flux [0..N]: 끝없는 데이터의 강물Flux는 0개에서 N개(무한대 포함)의 데이터를 발행할 수 있는 Publisher입니다.비유: 컨베이어 벨트. 물건이 계속해서 지나갑니다.유사한 개념: List, Stream, Iterable용도:findAll(): DB에서 여러 건 조회실시간 주식 시세 (끝없이 데이터가 들어옴)로그 ..

자바 개발자에게 데이터란 무엇일까요? 보통 List, Map 같은 컬렉션에 담긴 "완성된 결과물"을 의미했습니다.DB에서 100만 건을 조회하면, 100만 건이 다 메모리에 올라올 때까지 기다렸다가 한 번에 List로 받아서 처리했죠. (Memory: "살려줘...")하지만 리액티브 프로그래밍(Reactive Programming)에서는 다릅니다.데이터는 고여있는 호수가 아니라, 끊임없이 흐르는 강물(Stream)과 같습니다.오늘은 WebFlux의 뼈대가 되는 표준 사양, 리액티브 스트림즈(Reactive Streams)와 그 핵심 기능인 백프레셔(Backpressure)를 알아보겠습니다.1. Iterable(과거) vs Reactive Streams(미래)가장 큰 차이는 "누가 주도권을 쥐고 있는가?"..

우리가 지금까지 써왔던 Spring MVC는 정말 훌륭한 프레임워크입니다. 안정적이고, 코짜기도 쉽고, 디버깅도 편하죠.하지만 서비스가 커지고 동시 접속자가 수만 명을 넘어가면 문제가 생기기 시작합니다. 서버를 아무리 늘려도(Scale-out) 응답 속도가 느려지고, 메모리가 부족해집니다.이유는 단 하나, MVC가 "기다림의 미학(Blocking)"을 추구하기 때문입니다.반면 WebFlux는 "기다리지 않는 효율성(Non-Blocking)"을 추구합니다. 이 둘의 차이를 완벽하게 파헤쳐 보겠습니다.1. Spring MVC: "손님 1명당 직원 1명" (Thread per Request)MVC는 전통적인 서블릿(Servlet) 모델을 따릅니다.요청이 들어올 때마다 쓰레드(Thread)라는 일꾼을 하나씩 배..

카카오톡, 슬랙, 주식 시세창의 공통점은 무엇일까요?내가 가만히 있어도 새로운 정보가 화면에 뿅! 하고 나타난다는 것입니다.HTTP가 무전기(단방향)라면, WebSocket은 전화기(양방향)입니다.오늘은 스프링 부트에서 이 웹소켓을 이용해 간단한 실시간 채팅방을 구현해 보겠습니다.1. WebSocket만 쓰면 안 되나요? (STOMP의 필요성)웹소켓은 그냥 "통신 파이프"만 뚫어줄 뿐입니다.빨대만 꽂아놓고 "안녕?"이라고 보내면, 서버는 이게 귓속말인지, 전체 공지인지, 채팅방 1번인지 알 방법이 없습니다.그래서 우리는 규칙(프로토콜)이 필요합니다. 그게 바로 STOMP (Simple Text Oriented Messaging Protocol)입니다.STOMP는 "주소(Topic)" 개념을 도입해서 메시..

서버 개발의 끝은 배포가 아니라 성능 튜닝입니다.API 응답 속도가 0.1초인지 3초인지는 혼자 테스트할 땐 모릅니다.네이버가 만들고 오픈소스로 공개한 nGrinder는 엔터프라이즈급 부하 테스트 도구입니다. 스크립트 하나로 수천 명의 가상 사용자(VUser)가 동시에 로그인하고, 상품을 조회하고, 결제하는 시나리오를 만들 수 있습니다.1. nGrinder 구조 (Controller + Agent)nGrinder는 크게 두 가지로 나뉩니다.Controller (지휘관): 웹 UI를 제공하고, 테스트 스크립트를 관리하고, 결과를 보여줍니다.Agent (병사): 실제 부하(트래픽)를 발생시키는 일꾼입니다. 서버가 여러 대라면 Agent도 여러 대 띄워서 엄청난 트래픽을 만들 수 있습니다.2. 설치하기 (Do..

우리가 흔히 쓰는 관계형 데이터베이스(RDB)는 "저장"과 "정합성"에 특화되어 있지, "검색"에는 약합니다.특히 본문 검색(Full-text Search)이나 오타 교정, 자동 완성 같은 기능은 RDB로 구현하기가 매우 까다롭고 느립니다.이 문제를 해결하기 위해 Elasticsearch를 도입해 보겠습니다.1. 왜 Elasticsearch 인가요? (역색인 구조)RDB는 책의 본문을 처음부터 끝까지 다 읽으면서 찾는 방식(Scan)이라면, Elasticsearch는 책의 맨 뒤에 있는 "색인(Index)"을 보고 찾는 방식입니다.RDB: "강남"이라는 단어가 들어간 행을 다 뒤진다. -> 느림Elasticsearch: "강남" -> [1번 문서, 5번 문서, 100번 문서] -> 즉시 리턴이 역색인(I..

쇼핑몰에서 "주문 버튼"을 눌렀다고 가정해 봅시다.주문 정보 DB 저장재고 감소결제 승인배송 요청사용자에게 알림톡 발송데이터 분석팀에 로그 전송이 모든 걸 한 번의 HTTP 요청(Controller) 안에서 순차적으로 처리하면 어떻게 될까요?알림톡 서버가 1초만 늦게 응답해도, 사용자는 주문 완료 화면을 못 보고 뱅글뱅글 도는 로딩만 보게 됩니다.오늘은 이 강한 결합(Tight Coupling)을 끊어내고, 초당 수십만 건의 데이터도 거뜬히 처리하는 메시지 큐의 제왕, Apache Kafka를 스프링 부트에 연동해 보겠습니다.1. 왜 Kafka 인가요? (RabbitMQ vs Kafka)"메시지 큐(Message Queue)라면 RabbitMQ도 있잖아요?"맞습니다. 하지만 목적이 다릅니다.RabbitM..

서버 개발자의 가장 큰 수치심은 "사용자가 먼저 에러를 발견하는 것"입니다."로그 파일에 다 남아있는데요?"라고 변명해 봤자 소용없습니다. 이미 고객은 떠났으니까요.우리는 수동적(Passive)인 로그 파일 확인에서 벗어나, 능동적(Active)인 알림 시스템을 구축해야 합니다. 전 세계 개발자들이 가장 사랑하는 도구, Sentry가 정답입니다.1. Sentry가 뭔가요?단순히 "에러 났다"고 알려주는 게 아닙니다.어떤 사용자가 (ID, 이메일)어떤 환경에서 (OS, 브라우저 버전)어떤 코드 몇 번째 줄에서 (Stack Trace)무슨 값을 넣었길래 (Request Body)이 모든 정보를 스냅샷처럼 찍어서 예쁜 대시보드로 보여줍니다. 심지어 Jira 이슈를 자동으로 생성하거나 Slack으로 알림을 쏴줍..

멱등성(Idempotency)이란 수학 용어()에서 왔지만, 개발에서는 "연산을 한 번 수행하든 여러 번 수행하든 결과가 똑같아야 한다"는 뜻입니다.GET: 조회는 100번 해도 데이터가 안 변하죠? (멱등하다)POST: 결제 요청을 2번 보내면 2번 결제되죠? (멱등하지 않다!)그래서 우리는 POST(생성/결제) 요청을 강제로 멱등하게 만들어줘야 합니다.1. 해결 원리: "번호표(Key) 먼저 뽑아오세요"핵심은 클라이언트(프론트)와 서버가 약속을 하는 것입니다.Client: 요청을 보낼 때 유니크한 ID(Idempotency-Key)를 헤더에 담아 보냅니다. (예: UUID)Server:이 키를 Redis에서 조회합니다.없으면: 처음 온 요청이네? -> 처리하고 Redis에 저장.있으면: 이미 처리된(..

집에서 드라이기랑 에어컨을 동시에 켰다가 전기가 팍! 나간 적 있으신가요?이때 두꺼비집(누전 차단기)이 내려가서 전기를 끊어주지 않았다면, 과열로 인해 집 전체에 불이 났을지도 모릅니다.소프트웨어에서도 똑같습니다. 외부 API가 에러를 뿜어내고 있는데 계속 호출하면 내 서버까지 불이 납니다. 이때 "잠깐 연결 끊어!"라고 해주는 기술이 바로 서킷 브레이커입니다.1. 서킷 브레이커의 3가지 상태이 기술의 핵심은 상태(State)를 관리하는 것입니다.CLOSED (닫힘 - 정상): 전기가 통하는 상태. API 호출이 정상적으로 잘 됩니다.OPEN (열림 - 차단): 에러가 너무 많이 나서 회로를 끊어버린 상태. API 호출을 아예 안 하고 바로 에러를 뱉습니다. (Fail Fast)HALF-OPEN (반열림..