어제 오늘 내일

웹 개발을 하다 보면 사용자의 요청에 실시간으로 응답하는 것(OLTP) 외에, 뒤에서 묵묵히 데이터를 처리하는 작업(Batch)이 반드시 필요합니다.정산: 매일 밤 매출 집계알림: 휴면 회원 전환 안내 메일 발송데이터 마이그레이션: 구형 DB에서 신형 DB로 데이터 이관이런 작업을 단순히 List에 담아서 for 문을 돌리면, 메모리가 터져버립니다. Spring Batch는 이 문제를 해결하기 위해 태어났습니다.1. 배치가 일반 로직과 다른 점 (Chunk 지향 처리)Spring Batch의 핵심은 "데이터를 한 번에 다 읽지 않는다"는 것입니다.대신 청크(Chunk)라는 덩어리로 잘라서 처리합니다.일반적인 방식: 100만 개 조회(메모리 펑!) -> 100만 개 가공 -> 100만 개 저장Spring ..

쇼핑몰이나 티켓팅 서비스를 개발할 때 가장 무서운 순간이 언제일까요? 바로 "재고 관리"입니다.재고 = 재고 - 1이라는 아주 간단한 로직도, 수천 명이 동시에 누르면 재앙(Race Condition)이 발생합니다.오늘은 자바의 synchronized 키워드로는 해결할 수 없는 다중 서버 환경에서의 동시성 문제를 Redis와 Redisson 라이브러리를 사용해 완벽하게 해결해 보겠습니다.1. 왜 동시성 문제가 생기나요? (Race Condition)가장 흔한 재고 감소 로직을 볼까요?// 재고 감소 로직 (문제 있음!)public void decrease(Long id) { Stock stock = stockRepository.findById(id).orElseThrow(); stock.dec..

서비스를 운영하다 보면 사용자가 늘어날수록 데이터베이스(DB)가 힘들어하는 소리가 들리기 시작합니다."게시글 목록 좀 보여줘", "내 정보 좀 보여줘"... 똑같은 데이터를 수천 명이 동시에 요청하면 DB는 결국 뻗어버리고 맙니다.이때 구세주처럼 등장하는 것이 바로 캐시(Cache)입니다.오늘은 "메모리에 데이터를 저장해서 100배 빠르게 조회하는 기술", Redis와 가장 대중적인 캐싱 전략인 Look Aside(Cache Aside) 패턴을 스프링 부트로 구현해 보겠습니다.1. 왜 Redis를 써야 하나요? (Disk vs Memory)우리가 흔히 쓰는 MySQL, Oracle 같은 RDB는 데이터를 하드디스크(Disk)에 저장합니다. 안전하지만 느립니다.반면 Redis는 데이터를 RAM(Memory..

서버 개발자의 불안감은 배포가 끝난 뒤부터 시작됩니다."지금 잘 돌아가고 있나?", "메모리가 부족하진 않나?", "에러가 많이 나진 않나?"이걸 확인하려고 매번 터미널 들어가서 로그(tail -f)를 볼 수는 없죠. 오늘은 데이터 수집(Prometheus)과 시각화(Grafana)의 끝판왕 도구들을 사용해, 내 서버의 상태를 한눈에(Dashboard) 보는 법을 알려드립니다.1. 모니터링 3대장 구조 이해하기이 시스템은 3단계로 동작합니다.Spring Boot Actuator: "내 상태 정보(CPU, 메모리, 요청 수)를 알려줄게!" (데이터 제공자)Prometheus (프로메테우스): "내가 주기적으로 가서 그 정보를 긁어올게!" (데이터 수집가 - Time Series DB)Grafana (그라파..

예전에는 SSL 인증서를 사려면 매년 수십만 원을 내야 했습니다. 하지만 이제는 Let's Encrypt라는 비영리 단체 덕분에 누구나 무료로 보안 접속(HTTPS)을 구축할 수 있습니다.특히 우리가 앞서 설치한 Nginx가 있다면, 명령어 몇 줄로 1분 만에 적용할 수 있습니다.1. 준비물: 도메인 (필수!)SSL 인증서는 IP 주소(예: 13.124.xx.xx)에는 발급해 주지 않습니다. 반드시 도메인(예: my-service.com)이 있어야 합니다. 가비아, 호스팅케이알, AWS Route53 등에서 도메인을 하나 구매하세요. (실습용이면 .shop 같은 건 500원이면 삽니다.) 도메인 관리 페이지에서 A 레코드에 여러분의 EC2 탄력적 IP(Elastic IP)를 등록해 두세요. 2. Ce..

지난 시간 Nginx 설정을 통해 80번 포트로 들어온 요청을 8080번으로 넘기는 것까지 성공했습니다.하지만 배포할 때마다 서버를 껐다 켜야 하는 문제는 여전합니다.오늘은 서버를 2개(8081, 8082) 운영하면서, Nginx가 바라보는 방향만 살짝 바꿔주는 무중단 배포의 마법을 부려보겠습니다.1. 블루/그린(Blue/Green) 배포란?구 개념은 아주 간단합니다.Blue (기존): 현재 서비스 중인 서버 (예: 8081 포트)Green (신규): 새로 배포할 서버 (예: 8082 포트)새로운 버전(Green)을 8082포트에 몰래 띄우고, 다 떴는지 확인(Health Check)한 다음, Nginx에게 "이제 8082를 바라봐!"라고 명령하는 방식입니다. 그리고 마지막에 기존 서버(Blue)를 끕니..

지난 시간, GitHub Actions로 자동 배포까지 성공했습니다. 하지만 치명적인 단점이 하나 있었죠."배포하는 동안에는 서비스가 멈춘다(Downtime)."이걸 해결하려면 서버를 두 대 띄우고 교대로 배포해야 하는데, 그러려면 사용자의 요청을 이리저리 토스해 줄 문지기가 필요합니다. 오늘 소개할 Nginx가 바로 그 주인공입니다.1. 리버스 프록시(Reverse Proxy)가 뭔가요?이름이 어렵지만 원리는 간단합니다.클라이언트(사용자)가 스프링 부트 서버(8080 포트)에 직접 붙는 게 아니라, Nginx(80 포트)에게 먼저 요청을 보내고, Nginx가 뒤에 있는 스프링 부트에게 대신 전달하는 구조입니다.왜 이렇게 쓰나요?무중단 배포: A 서버가 배포 중이면 B 서버로 요청을 보내면 됩니다.보안:..

지난 시간에는 GitHub가 우리 코드를 대신 빌드해 주는 것까지 성공했습니다.하지만 빌드된 파일(jar)이 GitHub 서버에만 있으면 아무 소용 없겠죠? 이걸 우리의 진짜 서버(AWS EC2)로 옮겨서 실행시켜야 합니다.오늘은 appleboy라는 아주 유명한 액션을 사용해서 파일 전송(SCP)과 명령어 실행(SSH)을 자동화해 보겠습니다.1. 준비물: AWS EC2와 Key 파일당연히 서버가 있어야겠죠? AWS EC2 인스턴스 (Ubuntu 추천) 접속용 키 파일 (.pem): 서버 만들 때 받은 그 파일입니다. 절대 잃어버리면 안 됩니다! Java 설치: 서버에 미리 자바를 설치해 두세요. # (EC2 터미널에서)sudo apt updatesudo apt install openjdk-17-jd..

혹시 아직도 배포할 때마다 이런 과정을 반복하고 계신가요? 로컬에서 ./gradlew build 실행 (한참 기다림) FTP나 SCP로 서버에 jar 파일 전송 서버 접속해서 기존 프로세스 죽이고(kill), 다시 실행(java -jar) 이 과정은 귀찮기도 하지만, 사람이 하기 때문에 반드시 실수가 발생합니다. 오늘은 이 과정을 로봇에게 맡기는 CI(Continuous Integration, 지속적 통합)를 GitHub Actions로 구현해 보겠습니다.1. CI/CD가 도대체 뭔가요?CI (Continuous Integration): "지속적 통합"개발자가 코드를 합칠(Merge) 때마다, 자동으로 빌드하고 테스트해서 "이 코드 문제없어!"라고 검증하는 과정입니다.CD (Continuous De..

"개발 끝났다!" 하고 좋아하기엔 이릅니다. 진짜 끝은 서버에서 돌아가는 것을 확인해야 끝이죠.Spring Boot가 혁명적인 이유는 바로 내장 톰캣(Embedded Tomcat) 덕분입니다. 서버를 설치하는 게 아니라, 서버를 내 코드 안에 넣어버리는 것이죠.이 모든 것을 가능하게 하는 실행 가능한 Jar(Executable Jar)의 비밀과 빌드 방법을 알아보겠습니다.1. 일반 Jar vs 실행 가능한 Jar (Fat Jar)우리가 평소에 라이브러리로 쓰는 Jar 파일과 Spring Boot가 만드는 Jar 파일은 다릅니다. 일반 Jar (Skinny Jar): 내가 짠 코드(.class)만 들어있습니다. 이것만으로는 실행 못 합니다. (의존성 라이브러리가 없으니까요) 실행 가능한 Jar (Fat..