Spring Boot 글 모음
총 19개의 글이 있습니다.
대규모 트래픽 경험기 - 대기열
이전 글에서 Pessimistic Lock으로 동시성 문제를 해결했다. 이번에는 한 단계 앞으로 가서, "애초에 서버에 동시에 들어오는 요청 수를 제어하면 어떨까?" 라는 질문에서 출발한다. 콘서트 티켓 오픈 시간에 2000명이 동시에 좌석 조회를 요청한다고 가정하자.
대규모 트래픽 경험기 - 동시성 제어
현재 코드는 성능적인 문제를 어느정도 해결했지만 동시성 문제를 해결하지 못한다. 예를들어, 10명의 사람이 한 좌석에 대해 동시에 예약을 한다면 아래와 같이 10명 모두 같은 좌석을 예매할 수 있게 된다.
대규모 트래픽 경험기 - SSE
3편에서 API를 seat-map(정적 메타)과 seat-status(동적 상태)로 분리하고, DTO 프로젝션으로 조회 비용을 줄였다. 2000명 동시 접속 기준 TPS 51 → 136, p95 36초 → 13초. 처리량 2.7배, Tail Latency 2.6배 개선이었다.
대규모 트래픽 경험기 - api 분리
Redis 캐시를 적용했지만 결과는 기대 이하였다. TPS 48 → 57, 평균 응답 19.2초 → 18.2초. DB 접근은 2초에 1회까지 줄였는데도 체감 성능은 거의 그대로였다. 분석 결과 병목은 이미 DB가 아니었다.
대규모 트래픽 경험기 - 레디스 캐싱 적용
1편에서 확인한 문제는 명확했다. 2000명이 동시에 좌석을 조회하면 TPS 51, 평균 19.2초, p95 36.2초. 서버가 처리할 수 있는 것보다 더 많은 요청이 몰리면서, 대부분의 시간이 쿼리 실행이 아니라 자기 차례를 기다리는 대기 시간으로 소비되고 있었다.
트래픽 경험기 – 문제 상황 관찰
백엔드 개발을 공부하면서 항상 마음에 걸리던 질문이 있었다. "나는 실제 대규모 트래픽을 겪어본 적이 있는가?" CRUD를 만들 수 있고, 트랜잭션을 이해하고, API를 설계할 수 있다. 하지만 현실의 수강신청, 콘서트 티케팅, 한정 수량 이벤트는 다르다.
대규모 트래픽 경험기 – 문제 상황 관찰
백엔드 개발을 공부하면서 항상 마음에 걸리던 질문이 있었다. "나는 실제 대규모 트래픽을 겪어본 적이 있는가?" CRUD를 만들 수 있고, 트랜잭션을 이해하고, API를 설계할 수 있다. 하지만 현실의 수강신청, 콘서트 티케팅, 한정 수량 이벤트는 다르다.
유저 신고 기능을 위한 Redis 채팅 로그 관리
게임 내 실시간 채팅 기능을 제공하면서, 유저 신고 기능도 자연스럽게 필요해졌다. 단순히 채팅 한 줄만 저장해서 신고하는 방식은 정확한 맥락 파악이 어렵기 때문에, 신고된 메시지를 기준으로 앞뒤의 대화 흐름까지 함께 저장하는 구조가 필수적이었다.
Spring Boot에서 JWT + Redis로 게스트 로그인 시스템 구현하기
이번에 웹게임 프로젝트를 진행하면서 비회원도 게스트 계정으로 게임을 플레이할 수 있게 하는 기능이 필요했다. 따라서 평소엔 항상 회원만 관리했지만 이번에는 비회원을 관리하는 로직이 필요해졌다. 하지만 구글링을 해도 내가 원하는 방식의 게스트 로그인은 보이지 않았다.
MySQL LIKE 대신 Full-Text Index 쓰는 이유
이번에 데이터베이스 수업을 듣는 중에 LIKE를 배우다가 교수님께서 검색기능에 LIKE를 쓰는건 아주 멍청한 짓이다 라는 말을 듣고 아차! 싶었다. 우리가 개발 중인 서비스에서 교수님이 하지말라던 코드와 일치하는 코드를 사용하고 있었다.
Spring SSE로 실시간 알림 구현하기
SSE는 Server Sent Events 라는 뜻으로 말그대로 서버에서 이벤트를 보내준다 라는 의미이다. 저번시간에 정ㅇㅇ군의 발표에서 봤듯이 통신에는 여러 방식이 있다. 여기서 SSE는 스트리밍과 가장 유사하다고 할 수 있다.
REST API가 RESTful하지 않은 이유
우리는 웹 개발을 하면서 REST라는 것을 많이 접하게 된다. 우리는 REST를 대략 아래처럼 생각하고 있을 것이다. HTTP URI를 통해 자원을 명시한다. HTTP Method를 통해 행동을 명시한다. 서버는 클라이언트가 보낸 요청에 의한 응답을 보낸다.
Spring API 성능 최적화 — 병렬 처리, 트랜잭션 분리, 캐시 적용
우리가 현재 개발하고 있는 서비스들은 사용자가 적고, 규모도 작기 때문에 API 성능에 대해 큰 고민을 하지 않고 개발을 하게 된다. 하지만 사용자 수가 증가하고, 규모가 커지면서 원래는 빠르던 API들이 점점 느려질 수 있다고 한다.
Java에서 null을 안전하게 다루는 방법
의미가 모호함. 모든 참조의 기본이 null이고, null이 가능함. 1000여 개의 어플리케이션의 소프트웨어 결함 중 두번째로 많은 것이 Null Pointer Exception 이라고 한다. 이런 NPE 는 개발자의 부주의로 대부분 발생하게 된다.
Spring JPA Soft Delete : @SQLDelete, @Where, @SoftDelete
이번에 소공을 하면서 삭제와 관련된 이야기를 한 적이 있는데 관련된 자료들을 찾다가 우리가 얘기하던 주제와는 관련이 없지만 Soft Delete라는 것을 알게 되었다. 삭제에는 크게 두가지 종류가 있다고 한다.
Spring 서비스 간 의존, 어디까지 허용될까? Service vs Repository vs Facade
스프링으로 개발을 하다보면 아래와 같은 상황이 자주 생길 것이다. Post라는 글을 처리하는 비즈니스 로직에서 User를 처리해야할 경우와 같이 서로 다른 도메인을 건드려야하는 경우이다. 이때 우리는 크게 3가지 방법을 사용할 수 있다.
Spring Data JPA 페이징 : Page, Slice, List 차이와 사용법
페이징은 사용자가 데이터를 요청했을 때, 전체 데이터 중 일부를 원하는 정렬 방식으로 보여주는 방식이다. 만약 페이징을 사용하지 않고 수많은 데이터를 한번에 클라이언트로 보내게 된다면 성능에 큰 문제가 생길 수 있을 것이다.
Spring 의존성 주입 방식 정리: 필드 주입 vs 생성자 주입 vs 수정자 주입
우리가 스프링을 공부하다보면 아래와 같은 의존성 주입을 사용하지 말라는 말을 많이 듣는다. 위와 같은 의존성 주입법을 필드 주입이라고 한다. 그렇다면 왜 이런 주입법을 사용하지 말라고 하는걸까? 의존성 주입의 종류에는 크게 3가지 방법이 있다.
Spring Boot 테스트 코드 작성법 정리 (JUnit, AssertJ, Given-When-Then)
아직 시큐리티 부분을 제대로 파지 못한 관계로 딱히 새롭게 배운 점은 없는 것 같다. 사실 지금까지 스프링을 하면서 테스트 코드를 제대로 작성해본 적이 거의 없는데, 이번에 새로 공부하면서 테스트 코드를 작성하는 법도 새롭게 공부할 수 있었다.