백엔드 엔지니어
JavaKotlinSpring BootSpring Data JPA PostgreSQLMySQLAWSTerraform
READTHEM.md개발자의 도서 리뷰 플랫폼
소셜 로그인 직후 병렬 API 요청 6건 중 최대 5건이 실패하던 세션 경쟁 조건 해결
InvestUP주식 초보자를 위한 교육형 모의 주식 트레이딩 서비스
데이터 보존이 필요해진 시점에 Flyway 도입, 8일간 마이그레이션 17건 자동 반영
READTHEM.md개발자의 도서 리뷰 플랫폼
소셜 로그인 직후 병렬 API 요청 6건 중 최대 5건이 실패하던 세션 경쟁 조건 해결
READTHEM.md개발자의 도서 리뷰 플랫폼
SessionCreationPolicy.STATELESS 설정state 값을 세션에 임시 저장 (2 + 4)Session was invalidated, 가끔 ERR no such key쿠키를 모두 지운 상태에서 소셜 로그인 → 메인 화면 리다이렉트 직후 병렬 요청
Network 탭
로그
... 16 frames omitted (Lettuce, RedisTemplate)
...
두 에러(Session was invalidated, ERR no such key)의 스택 트레이스를 확인해보니모두 RedisSessionRepository.save에서 발생
SessionRepositoryFilter.commitSession
병렬 요청 중 500 응답 1건의 Request Headers
3
RedisSessionRepository.save는 요청이 끝날 때마다 실행되는 commitSession에서 호출(2)JWT 인증(STATELESS)을 쓰는 일반 API 요청이 세션을 가지고 있다는 뜻
Cookie에 토큰과 함께 SESSION 쿠키가 담겨 있음(3).Set-Cookie로 발급됨.소셜 로그인용 임시 세션이 로그인 이후에도 남아 모든 API 요청에 따라붙고 있었음.
OAuthLoginSuccessHandler.onAuthenticationSuccess
state 비교(4)에서 끝남 → 로그인 이후 요청에는 필요 없는 세션해결은 됐지만 의문이 남았음.
STATELESS인데 왜 6에서 세션 쿠키가 발급됐고, 같은 세션을 가진 요청들은 왜 실패했을까?
STATELESS인데 6에서 SESSION 쿠키가 발급된 이유STATELESS는 Spring Security가 세션에 인증 정보를 저장하지 않게 할 뿐, 다른 곳의 세션 생성은 막지 않음.changeSessionId()로 세션 회전 → 응답에 새 SESSION 쿠키 발급SESSION 쿠키를 들고 감STATELESS라 인증 정보가 세션에 없음 → SessionManagementFilter가 매 요청을 "막 인증됨"으로 보고 changeSessionId() 실행RedisSessionRepository.save
RedisSession.saveChangeSessionId
| 요청 상황 | 결과 |
|---|---|
| 가장 먼저 RENAME | 200 |
| 다른 요청의 RENAME 이후에 세션 조회 | 세션 없음 → 저장 안 함 → 200 |
hasKey(129행) 전에 다른 요청이 RENAME | Session was invalidated |
hasKey ~ RENAME(319행) 사이에 다른 요청이 RENAME | ERR no such key구간이 짧아 가끔 발생 |
Set-Cookie: SESSION이 붙은 건 1건뿐 → 나머지 성공은 세션을 못 찾아 저장을 건너뛴 요청hasKey → rename으로 저장 → 원자적이지 않아 경쟁 발생소셜 로그인 직후 메인 화면의 병렬 API 요청 6건이 모두 200
다중 인스턴스 환경에서도 안정적으로 소셜 로그인의 임시 세션을 사용할 수 있음.
세션 저장소를 바꾸기 전에 세션을 쓰는 곳(OAuth2 state 임시 세션)을 미리 정리했다면 배포 전에 발견할 수 있었음.
일정상 각자 맡은 기능을 공유할 시간이 없었고, 그 결과 인증 흐름을 모르는 상태에서 장애를 맞아 소셜 로그인 구조를 공부하는 데 시간을 씀.
→ 각자 작업한 영역을 공유하는 자리가 필요
로그가 길게 나오면 피로부터 느꼈는데, 중요한 단서라는 것을 체감함.
아무리 난해한 오류도 단서를 잘 수집하면 설명 가능한 원인을 찾을 수 있음.
톰캣 메모리에서는 문제없던 코드가 Redis에서 경쟁 조건이 됨.
→ 외부 저장소로 옮길 때는 병렬 요청 시나리오를 함께 검증
InvestUP주식 초보자를 위한 교육형 모의 주식 트레이딩 서비스
데이터 보존이 필요해진 시점에 Flyway 도입, 8일간 마이그레이션 17건 자동 반영
InvestUP주식 초보자를 위한 교육형 모의 주식 트레이딩 서비스
프로그래머스 데브코스 백엔드 10기 최종 프로젝트 최우수상(1위)
schema.sql, timescale.sql로 관리 컨테이너 재생성 불가 → DDL로 수동 마이그레이션
기동 시 적용되지 않은 마이그레이션만 실행 → 데이터 유지
수동 DDL 휴먼 에러로 인한 스키마 드리프트
모든 환경에 같은 마이그레이션 파일 적용
인프라 담당에게 DDL 전달 후 대기
PR에 마이그레이션 파일을 넣으면 배포 시 자동 반영
서버에서 직접 실행해 사전 검증·실행 기록 없음
로컬 기동으로 먼저 실행, PR 리뷰를 거쳐 반영, 실행 내역은 마이그레이션 파일(git)과 flyway_schema_history로 추적
개발 서버 스키마·데이터를 최신으로 수동 마이그레이션
Flyway가 만든 DB에 데이터만 이관
지속 가능한 백업·복원 구조
개발 서버 스키마·데이터를 최신으로 수동 마이그레이션
데이터를 보존하기 위해 기존 데이터를 최신 스키마(V1)로 맞춤.
수동 DDL
V1로 만든 DB유니크 제약 누락 → 추가 수동 DDL
컬럼 순서 외 차이 없음
Flyway가 만든 DB에 데이터만 이관
수동 DDL로 맞춘 스키마 대신, Flyway가 처음부터 스키마를 관리하도록 V1으로 DB 생성
S3 · 일반 테이블 pg_dump --data-only
캔들 하이퍼테이블 \copy CSV
개발 서버는 기존 DB 삭제 후
Flyway가 V1으로 스키마 생성
* 데이터를 먼저 넣으면 Flyway가 비어 있지 않은 DB로 판단해 실패하므로 앱 기동 후 복원
지속 가능한 백업·복원 구조
부트스트랩으로 작성해 인스턴스 교체 시 자동 복원함.
S3 · pg_dump
* 스키마와 함께 백업한 덤프에 flyway_schema_history가 포함되어, 데이터를 먼저 복원해도
Flyway가 이력을 이어받아 이후 마이그레이션만 실행
종목·일봉 등 약 6.5만 건의 데이터를 Flyway가 관리하는 DB로 옮기고, 이후 인스턴스 교체 시에도 자동 복원
도입 후 8일간(9/8~9/15) 마이그레이션 17건이 수동 DDL 없이 PR 병합만으로 개발 서버에 반영
팀원 5명 모두 마이그레이션을 직접 작성, 인프라 담당에게 DDL을 전달하지 않고 git으로 공유·리뷰
지금은 인스턴스 교체 직전에만 백업해 예기치 않은 장애에 대비하지 못함.
→ cron 기반 정기 백업 (RDS는 비용 증가로 제외)
병렬 작업이 늘면 같은 버전 번호나 순서 역전이 생길 수 있음
→ PR 단계에서 중복 버전·순서 역전을 검사
데이터가 쌓인 뒤 도입해 스키마 최신화부터 데이터 이관까지 3단계가 필요했지만, 데이터가 없을 때는 V1 파일 하나로 끝나는 작업
→ 다음 프로젝트는 첫 스키마부터 Flyway로 관리
무엇을 실행했는지 남지 않아 유니크 제약 누락 같은 드리프트를 비교해 보기 전까지 알 수 없었음.
→ 스키마 변경도 코드처럼 파일로 남기고 리뷰해야 함.