복잡한뇌구조마냥

웹 애플리케이션에서 실시간 데이터 처리는 점점 더 중요한 요구사항이 되고 있다.채팅, 알림, 실시간 게임, 주식·모니터링 대시보드 등은 모두 “서버 상태 변화를 즉시 사용자에게 전달”해야 한다.이 글에서는 웹에서 사용되는 대표적인 실시간 통신 방식인Polling → Long Polling → Streaming(SSE) → WebSocket을 흐름 중심으로 정리한다.1️⃣ Polling (폴링) 개념클라이언트가 주기적으로 서버에 요청서버는 항상 즉시 응답변경 사항이 없어도 요청은 계속 발생Client ──(요청)──> ServerClient 특징구현이 매우 단순HTTP 기반 → 브라우저 호환성 좋음불필요한 트래픽 발생단점실시간성이 떨어짐서버 부하 큼요청 주기를 짧게 하면 비용 폭증사용 예관리자 페이지 단순..

✅ 배경 – “실시간”이라는 요구는 하나가 아니었다이번 프로젝트에서는 실시간 통신이 필요한 화면이 여러 개 존재했다.하지만 구현을 진행하면서, 이 실시간 요구는 하나의 문제로 묶기 어렵다는 점이 드러났다.1️⃣ 로비 / 경기 대기실방 목록 변경참가자 입장 / 퇴장준비 상태 변경강퇴 처리다른 사용자가 어떤 행동을 했는지 즉시 반영2️⃣ 게임 진행 중사용자 입력 전송상대방 행동의 즉각적인 반영짧은 주기의 반복적인 상호작용처음에는 두 영역 모두“실시간 통신”이라는 하나의 문제로 접근했지만,통신의 방향·빈도·지연 민감도가 서로 다르다는 점을 무시할 수 없었다.✅ 실시간 통신 요구사항을 분리해보면🔹 로비 / 대기실의 성격서버 → 클라이언트 단방향상태 변경 알림 중심이벤트 빈도는 높지 않음연결은 비교적 오래 유지..

Redis를 사용하다 보면 TTL, 만료 키, eviction 같은 개념을 자연스럽게 접하게 된다.하지만 Redis가 내부에서 어떤 기준으로 키를 만료시키고, 왜 그런 구조를 선택했는지까지 깊게 생각해볼 기회는 많지 않다. 이번 글에서는 Redis의 TTL 동작 방식을 이해하기 위해TTL(Time To Live)을 지원하는 간단한 캐시를 Java로 직접 구현해보며,그 설계 과정과 핵심 포인트를 정리해본다.왜 TTL 캐시를 직접 구현해봤을까?Redis는 단순한 Key-Value 저장소가 아니라,만료 시간 관리메모리 제한 하에서의 eviction 정책성능을 고려한 lazy expiration 전략같은 시스템적인 선택들이 녹아 있는 저장소다.이런 개념들을 “문서로 읽는 것”보다직접 작은 구현을 해보는 게 훨씬..

🏆 프로젝트 성과운영진 평가 1위참여 기업 평가 1위동기 수강생 투표 2위“기획–개발–배포–운영–개선”까지 실제 서비스 수준으로 완성한 End-to-End 프로젝트🧭 왜 만들었는가취미 장비는 가격이 비싸고 사용 빈도는 낮아 진입 장벽이 높습니다.기존 대여 방식은 보통 아래 중 하나였습니다.중고 거래로 직접 구매렌탈샵에서 비싸고 제한된 품목 대여특정 카테고리만 다루는 플랫폼(캠핑/촬영 등)그래서 저희는 개인 간으로 장비를 안전하게 대여하고,예약·결제·채팅·후기까지 하나의 흐름으로 연결된 플랫폼을 만들고자 했습니다.🧩 핵심 기능 소개✔️ AI 기반 기능AI 게시글 자동 작성 (Image + Text)이미지 업로드만으로 제목/설명/카테고리/가격/보증금 등 주요 필드 자동 생성당근마켓 AI 게시글 작성 기..

AWS 콘솔 캡처는 지저분하고,draw.io는 아이콘 찾다가 시간 다 쓰는 경우가 많다.이럴 때 Cloudcraft는👉 AWS 공식 아이콘 + 실제 서비스 배치 느낌으로👉 아키텍처 다이어그램을 아주 빠르게 만들 수 있는 도구다.Cloudcraft란?AWS 인프라 전용 다이어그램 툴AWS 공식 아이콘 제공실제 리소스 배치 느낌의 시각화문서 / 발표 / README / 기술 블로그용으로 최적👉 특히 EC2, ALB, CloudFront, S3, RDS, Lambda 같은 구조 표현이 깔끔함1️⃣ Cloudcraft 시작하기https://cloudcraft.co 접속GitHub 계정으로 로그인New → Blank Diagram 선택무료 플랜도 아키텍처 설명용으로는 충분2️⃣ 기본 화면 구성왼쪽 패널: 리..

🧩무중단 배포란?👉 서비스를 중단하지 않고 새로운 버전을 배포하는 방식을 의미한다.배포 중에도기존 사용자는 정상 요청 처리새 버전은 준비 완료 후 자연스럽게 전환❓ 왜 무중단 배포가 필요한가?전통적인 배포 방식의 문제 서버 종료→ 새 버전 배포→ 서버 재시작→ 서비스 재개이 방식은 배포 시간 동안❌ 서비스 접속 불가❌ 요청 실패❌ 사용자 이탈❌ 트래픽 많은 서비스에 치명적“배포 = 장애”가 되어버리는 구조🎯 무중단 배포의 핵심 목표목표설명서비스 연속성배포 중에도 요청 처리안정성문제 발생 시 빠른 롤백점진적 전환새 버전으로 자연스럽게 이동🧩 무중단 배포의 기본 원리무중단 배포의 핵심은 단 하나다.“트래픽을 어디로 보낼지 제어한다”1️⃣ Blue-Green Deployment🔹 개념Blue: 현재 ..

대규모 트래픽 환경에서 캐시를 사용하다 보면, 특정 시점에 DB로 요청이 한꺼번에 몰리는 현상이 발생할 수 있다.이를 Cache Stampede(캐시 스탬피드) 라고 부른다.간단히 말하면,캐시가 비는 순간, 모든 요청이 동시에 DB로 몰려가는 문제이다.🧩 캐시 스탬피드는 언제 발생할까?가장 대표적인 상황은 다음과 같다.1️⃣ 캐시 만료(TTL Expire) 시점인기 데이터(메인 페이지, 인기 게시글, 랭킹 등)캐시 TTL이 만료되는 순간다수의 요청이 동시에 유입 [요청 1] 캐시 없음 → DB 조회[요청 2] 캐시 없음 → DB 조회[요청 3] 캐시 없음 → DB 조회...👉 원래는 캐시 1번만 갱신하면 되는데, DB를 N번 조회 2️⃣ 서버 재시작 / Redis FlushRedis 재시작FLUS..

1. 배경 및 문제 상황기존 아키텍처의 한계프로젝트에서 프로필 이미지 업로드 시 Spring Boot의 ImageOptimizer를 사용하여 동기적으로 리사이징을 처리했습니다.기존 방식의 문제점:@Servicepublic class ImageOptimizer { public String optimizeAndUpload(MultipartFile image) { // 1. 이미지 검증 validateImage(image); // 2. 동기 리사이징 (사용자가 대기) BufferedImage resized = resize(image, 1024, 1024); // 3. S3 업로드 String url =..