IGMO는 여러 플레이어가 실시간으로 상호작용하며 게임을 진행하는 서비스예요. 잦은 배포로 인한 배포 중 다운타임을 줄이기 위해 Blue-Green 기반의 무중단 배포를 적용했고, 새 버전으로 트래픽을 끊김 없이 전환할 수 있었어요. 하지만 기존 서버에서 진행 중이던 게임은 배포 과정에서 함께 종료될 수 있었어요. 이 글에서는 배포 구조의 개선과 이로 인해 문제가 생긴 원인을 살펴보고, Spring의 Graceful Shutdown과 Drain으로 서버를 안정적으로 종료하도록 개선한 과정을 정리해 볼게요.기존 배포 방식의 한계초기에는 기존 애플리케이션을 종료하고 새로운 버전을 실행하는 인플레이스(In-Place) 방식으로 배포했어요.구조는 단순했지만 새 애플리케이션이 기동 되는 동안 요청을 처리할 서버가..

문제 상황게임을 시작하려면 최소 3명의 플레이어가 필요하다. 이 규칙은 GameRoom이 검증하도록 설계했다.GameRoom.java public synchronized void start() { ... if (players.size() 클라이언트 개발자는 로컬 환경에서 게임 흐름을 테스트할 때마다 최소 3개의 브라우저 창을 열고, 각 브라우저에서 플레이어를 생성해야 했다. 이 과정이 반복되어 테스트 준비가 번거롭다는 의견을 받았다.특히 게임의 전체 흐름을 자주 확인해야 하는 작업에서는 같은 준비 과정을 반복해야 했고, 이는 개발 속도를 늦추는 원인이 되었다.따라서 운영 환경에서는 최소 3명 규칙을 유지하면서도, 로컬 환경에서는 플레이어 1명만으로 게임을 시작할 수 있는 방법이..

상황웹소켓 연결 테스트를 하던 중 프론트엔드 팀원에게 아래와 같은 메시지를 받았다.요청 헤더에 쿠키가 없는데 웹소켓 연결이 되고, 채팅 메세지도 잘 보내지네?무슨 말이지? 웹소켓에 기반한 채팅은 로그인된 사용자만 가능하다. 따라서 로그인 여부를 확인하기 위해 토큰을 통한 인증 과정을 거친다. 이때 토큰은 쿠키에 담겨 요청 헤더에 실린다. 그런데, 클라이언트 측에서 웹소켓 연결을 하던 중 쿠키가 없는데 웹소켓 연결이 잘 되고, 메시지도 잘 보내진다고 한다. 프로젝트의 웹소켓 인증 흐름클라이언트가 서버로 웹소켓 연결 요청을 보내면 서버의 HandshakeInterceptor가 요청에 담겨있는 쿠키를 꺼내어 토큰으로 사용자 인증을 진행한다. 토큰이 유효하지 않거나, 만료된 토큰이라면 예외를 반환하고, 토큰이..

동시 삽입 이슈(따닥 이슈)개념 및 문제점따닥 이슈란 사용자가 어떤 버튼을 동시에 여러 번 클릭해서 동일한 API 요청이 짧은 시간 안에 중복으로 서버에 전달되는 현상을 말한다.중복 데이터 삽입이 허용되지 않는 정책에서 따닥 이슈로 인한 중복 삽입은 문제가 된다.이때 서버에서는 각 요청이 독립적인 트랜잭션으로 처리되기 때문에, 단순한 비즈니스 로직 검증만으로는 동시성을 보장할 수 없다. 문제 상황현재 멘토링 예약의 정책은 한 사람이 같은 멘토링을 중복 예약할 수 없다는 정책을 가지고 있다. 여기서 문제 상황은 따닥 요청으로 인한 중복 삽입이 될 수 있다는 것이다.두 개의 요청이 거의 동시에 들어와 모두 아직 예약이 없다고 판단한 뒤 각각 예약을 생성하게 된다.그 결과, 한 명의 사용자가 같은 멘토링에 대..

원래는 25년이 끝나기 전에 완성하려고 했지만, 그러지 못했습니다.. 어찌 되었건, 저도 1년간의 행적을 정리하기 위해서 2025년 정리하기를 시작으로 매년 회고를 작성해 볼까 합니다. 해야 할 말이 많으니 아래부터는 말을 편하게 하겠습니다.회고를 하는 이유나는 2024년, 정확히는 2024년 11월부터 블로그를 시작했다. 시작은 개발 블로그였다.우테코를 지원할 당시에 나의 구글 검색 목록은 1주 차 회고, 2 주차 회고,... n 주차 회고 들로 가득 차 있었다.수많은 회고글을 보면서 느낀 점은 두 가지였다.저 많은 내용을 적기 위해서 얼마나 걸렸을까?진짜 회고가 도움이 될까?느낀 점 보단 의문점에 가깝지만 어찌 되었건 우테코에 지원했다는 과정을 "기록"하고 싶다는 마음과 함께 "나도 해봐야지" 하는 ..

문제/kakako/callback API의 응답을 테스트하다가 LazyInitializationException 을 만나게 되었다.이유예외 로그에서 볼 수 있듯이 지연로딩된 Member 엔티티에 접근하다가 LazyInitializationException 이 발생했다./kakao/callback 로직 내부를 살펴보자.카카오 콜백 로직 흐름카카오 콜백의 흐름은 간단하게 다음과 같다.사용자가 카카오 로그인 페이지에서 로그인을 한다.카카오 서버는 요청을 받아서 클라이언트에게 `/kakao/callback` 으로 리디렉션 한다.클라이언트는 서버에게 `/kakao/callback` 요청을 보낸다.요청을 받은 서버는 카카오 서버에게 토큰을 요청하고 응답받는다.서버의 `kakaoCallBack()`은 카카오에게 응답..

RestAssured 기반의 인수테스트 실행 중 위와같은 예외가 발생했다.JSON 직렬화를 할 수 없다는 뜻으로 해석된다. 왜 이런 문제가 발생했지? 프로젝트의 환경으로 Spring Boot 4.0.0 버전을 사용중이었다.기존의 Spring Boot 3.x 버전에서 Spring Boot 4.x 버전으로 업데이트 되면서 Jackson 버전도 2.x 버전에서 3.x 버전으로 변경되었다. 정리하면 다음과 같다. 변경 전변경 후스프링 부트 버전Spring Boot 3.xSpring Boot 4.xJackson 버전Jackson 2.xJackson 3.x 직렬화가 안되는 범위는 어디까지 인가?직렬화가 안되는 범위를 찾기 위해서 실제 Http 요청을 테스트해봤다.포스트맨으로 테스트 한 결과, 정상동작 하는것을 확인..

본 글은 스프링 컨텍스트를 사용하는 테스트에서 발생했던 문제점의 원인을 찾고, 해결하는 과정, 그 과정에서 배운점들을 기록한 글입니다.문제 상황ci가 돌아가지 않는다.기능개발 후, pr을 머지했을때 ci를 실행하던 중 ci가 끝나지 않고, 계속해서 로딩되었다.원인 찾기CI Report 확인위에서 실패한 ci는 featrue(기능) 브랜치에서 develop(개발)브랜치로 PR이 발생했을 때 실행되는 ci 다.로컬에서 테스트가 모두 통과하더라도 github action에서 실행하는 ci 테스트가 실패할 수도 있기 때문에 ci 스크립트에 테스트 실패시 실패 로그를 자세하게 알 수 있는 report 생성 스크립트를 추가하여 사용하고 있었다.report를 확인 했을 때 몇가지 테스트가 실패했었다.실패한 테스트는 ..

문제 상황멘토링 목록을 오프셋 기반의 페이지네이션으로 구현하기 위해 QueryDSL을 사용해야 했다.이유는 멘토링에 해당하는 멘토링카테고리 (예: 멘토링1 -> {근력증진, 자세교정, 체력증가})처럼 하나의 멘토링에 카테고리가 여러개 일수 있기 때문에 리스트를 응답에 포함시켜야 했다. 처음엔 네이티브 쿼리나 projection으로 구현하려고 했지만, 생각보다 로직이 복잡해져서 나중에 유지보수가 힘들다고 판단했고,이전에 QueryDSL을 도입하여 이미 사용중이었기 때문에 QueryDSL을 사용하기로 결정했다.최종적으로 이런 모습의 메서드가 만들어졌고, 테스트를 위해 테스트 코드를 작성하고 실행시켜 봤다.그리고 위와같은 예외를 만나게 되었는데,예외 메세지를 보면 NoSuchMethodError 예외라고 하..

DB에는 테이블이 존재하는데, 엔티티가 없는데 왜 예외가 안 나지?validate의 진짜 의미그동안 validate를 DB와 엔티티 전체 일치 검증으로 오해하고 있었다.하지만, Hibernate는 실제로 "엔티티 기준"으로만 검사한다.Hibernate의 검증 순서Hibernate는 아래와 같은 순서로 검증하게 된다.@Entity로 등록된 모든 엔티티를 스캔한다.각 엔티티가 매핑된 테이블 이름을 찾는다.DB에서 해당 테이블을 조회해 컬럼, 타입, 제약조건이 일치하는지 확인한다.불일치 시 예외(SchemaValidationException) 발생Hibernate는 엔티티가 없는 테이블은 검증하지 않는다 예시로 이해하기DB에는 category, chat_message 테이블이 존재함코드에는 ChatMessag..