꾸준하게

현재 Buy Now 클릭 → 주문 생성 → 재고 감소 의 흐름으로 인해,결제 창에서 취소하면 재고 복구가 안되는 현상이 발생하고 있습니다. 재고 감소를 어느 시점에 하냐에 따라 로직이 변경될 수 있습니다. 저는 현재 테스트를 위해 결제 창을 껐다 켰다 하는데 재고는 계속 줄어들기에 결제 완료를 하면 재고를 감소하는 방향으로 수정하였습니다. 하지만 그 전에 이렇게 하면 생길 문제를 먼저 말씀드리겠습니다.Overselling 현상으로 예를 들어 재고 1개, 동시 결제하는 사람이 2명이면 상대적으로 늦은 사람은 0 -> -1로 재고소진하게 됩니다. 해결 방안낙관적 락 @Version OptimisticLockException을 통해 두번째 요청을 눌렀을 때는 이미 소진되었다는 문구를 띄워주는 방식으로 하면..

결제 시스템에서 가장 중요한 것은 돈은 정확하게 한 번만 나가야 한다는 것 입니다. 네트워크 불안정이나 사용자의 실수로 인해 동일한 결제 요청이 중복으로 들어오더라도, 서버는 항상 동일한 응답을 내려주어야 합니다. 이를 멱등성이라고 합니다. 저는 이를 보장하기 위해 Redis 분산 락과 캐싱 전략을 조합하였습니다. 요청이 들어오면 먼저 Redis에 해당 멱등 키로 락을 획득하려고 시도합니다. Redis의 SET NX EX 40 명령어를 사용하는데, 이는 "키가 없을 때만 값을 설정하고, 20초 후 자동 만료"를 원자적으로 수행합니다. 이 시점에 캐시가 있다면 이미 다른 요청이 처리를 완료한 것이므로, 락을 해제하고 캐시된 결과를 그대로 반환합니다. 캐시가 없다면 실제 결제 검증 로직을 수행하고, 완..

캡스톤 디자인 우수상을 받게 되었습니다...! (ㅎㅇ이가 홍보를 야무지게 잘해주심) 티모지지는 정말 2024 겨울부터 기획하여 7월까지 진행한 프로젝트로 프론트 개발까지 하느라 고생이 많았습니다..(챗지피티가 올 해 초만 하더라도 정말 바보같았다..) 에타, 단톡방에 홍보도 하며 나름 유저를 40명까지 채워봤지만 서비스가 상용화 되기에는 한계가 있었네요.... 그래도 캡스톤디자인 프로젝트로 시작해서 기승전결이 좋았기에 우수상까지 받을수도 있었나 싶습니다. 거의 6월까지는 티모지지 서비스만 생각하고 살았던 것 같습니다. 이제 AWS 프리티어도 끝나기도 했고 비즈니스적 한계가 명확하기에 보내줘야 될 때인 것 같습니다. 열심히 기획하고 개발했던 티모지지.... ㅎㅇ, ㅅㅇ 모두 고생했다.. 2026년 1..

나르지지 서비스 : nar.kr 1달 전 디자이너 분과 프론트엔드 분을 모시게 되었습니다. 🙌혼자 상상하고 만든 서비스에 공감하고 합류하는 분들이 있다는게 좋았습니다. 기존에 많은 프로젝트를 해봤지만 이 프로젝트의 특별한 점이라면 '덕업일치'라고 표현 될 것 같습니다. 모두 롤을 좋아하고 특히 LCK보는 것에 관심이 있어서 자연스레 확장해 나갈 수 있는 원동력이 되는 것 같습니다. 개인 프로젝트에서 팀 프로젝트로 확장되면서 느낀점이 확실히 각자의 강점을 발휘할 수 있는 분야를 맡으니 더 효율적이고 견고해지는 것 같습니다. 매 주 점점 발전하는 서비스를 보면서 얼른 사용자가 많이 생겼으면 좋겠다는 상상을 합니다 ㅎㅎ2025년은 아이디어를 그려보는 시간이었다면 2026년은 실제 서비스로 거듭나서 프로 ..

배경 현재 진행중인 나르지지 서비스는 스케줄링으로 적재되는 데이터 이외에는 유저의 데이터가 들어갈 일이 없습니다.하지만 서비스를 확장하면서 몇 명이 조회했는지, 리뷰 등록과 같은 상황이 발생할 수 있습니다.이러한 상황에서는 현재 DB인 SQLite의 한계가 발생할 수 있기에 먼저 테스트 환경에서 측정해보고자 합니다. 내용기본적으로 SQLite도 MySQL과 같이 트랜잭션을 지원하지만 단위에서 차이가 있습니다.SQLite는 단일 파일기반으로 임베디드 형식이라 파일에 락이 걸리게 됩니다. 반면 MySQL은 Row Lock기반이기에 동시성 처리에서 처리량이 높다는 강점이 있습니다. 스레드 개수와 요청 수의 개수를 조절하면서 SQLite와 MySQL을 비교해보겠습니다. 가상 시나리오 : 특정 게시글에 대해 ..

상황 설명 개인 프로젝트인 NAR.GG 서비스 DB는 MySQL로 AWS RDS 설정을 하였습니다. 하지만 RDS 과금이 생각보다 많이 나갔습니다. 총 6만 원 가까이 지출하게 되었습니다..😱 위 상황에서 일단 RDS를 무조건적으로 없애야 됐습니다. (안그래도 용돈 받는 입장에서 6만 원씩 지출되는 건 타격이 크다.) 굳이 MySQL을 고집해야하나??RDS가 아니라면 EC2인스턴스에 Docker로 MySQL을 올리는 게 최선인 방법 같았습니다.그러면 안 그래도 1GB밖에 안 되는 스프링인스턴스에서 더 쪼개서 반반 사용해야 됐습니다.MySQL의 용량을 최대한 최적화하기 위해 튜닝을 해야 하나 생각도 들었습니다. 어떻게 해야 될지 정확히 확신이 안 서 개발자 커뮤니티에 제 상황을 적어서 의견을 구했습니다...

서문이전 DTO 프로젝션 적용 후, 응답 시간이 두 자릿수(ms) 수준으로 개선되어 사용자 경험 측면에서는 불편함이 거의 사라졌습니다.그러나 일정 서비스의 과거 게임 데이터는 불변성이라는 특성을 가지고 있기에, 캐시를 활용하여 더욱 최적화를 할 수 있다고 판단하였습니다.본문서비스 특성 고려하여 캐싱 전략 수립 LCK 일정 서비스 업데이트 주기가 6시간 간격으로 스케줄링을 통해 저장됩니다. 하지만 오늘 경기가 아직 진행중일 경우 절반만 업데이트되는 경우가 있을 수 있습니다. 이럴 경우를 대비해 총 5가지의 캐시로 분류하였습니다. 오늘 경기 일정오늘 경기 상세정보 과거 경기 일정과거 경기 상세정보 기록 페이지 오늘 경기 일정, 상세정보는 과거 데이터들과 다르게 스케줄링이 성공하면 @CacheEvict를 통..

문제 상황일정 서비스 로직은 단순한 조회 기능인데, 사용자가 체감할 정도의 응답 지연(약 750ms)이 발생하고 있었습니다. 접근스프링단 코드는 크게 이상이 없어 DEBUG 레벨 로그로 설정해보았습니다.API 조회 콜 1개당 수많은 쿼리문이 발생하였습니다. 바로 N+1문제였습니다. 원인ONE TO ONE 양방향 매핑 N+1 문제연관관계 주인 - game_player_stat반대 - game_participant GameParticipant 조인 시 GamePlayerStat도 EAGER 방식으로 가져오게 되어 문제 발생 자식 쪽에서는 부모 존재여부를 모르기 때문에 체크하게 되어 LAZY방식 작동안하게 됨해결책@OneToOne(optional = false) (DTO 프로젝션과 비교분석함)JOIN FE..

들어가며나르지지 서비스는 Riot에서 제공하는 대회 데이터 기반으로 분석 서비스를 제공하는 것을 목표로 합니다. 위와 같이 서버 단에서 데이터 수집 및 정제 후 DB에 저장하여 가공한 서비스를 제공하는 것이 목표입니다. 이를 위해 주기적으로 업데이트되는 Google Drive 파일을 우리 서비스에서도 똑같이 업데이트해야됩니다. 진행 사항 스케줄링 Google Drive 파일이 6시간 간격으로 업데이트 됩니다.@Scheduled(cron = "0 30 4,10,16,22 * * ?", zone = "Asia/Seoul") 이에 맞춰 저희 서비스에서도 6시간 간격으로 스케줄링을 설정하였습니다. Data Ingestion DataIngestionFacade배치처리에 있어서 가장 중심이 되는 Class입니..

들어가며- 롤 e-스포츠 데이터를 다루는 개인 프로젝트 ‘NAR’에서 “챔피언 조합 통계(Combination)” API를 만들었습니다.- 첫 구현은 메모리 중심 설계로 하였습니다. DB에서 GameParticipant 전부를 읽어 와 자바 컬렉션으로 그룹핑, 집계, 정렬, 페이징까지 처리하는 방식입니다. 문제상황서비스 운영 중, java.lang.OutOfMemoryError: Java heap space 에러가 터짐. 로그를 확인해보니 챔피언 조합 통계 API가 반복적으로 호출됨. 운영 환경 인스턴스: AWS EC2 t3.micro (vCPU: 2, Memory: 1GB)JVM 옵션 : -Xmx512m 성능 테스트 (기존 코드)정확한 진단을 위해 VisualVM 모니터링 툴을 이용하여로컬에서 운영..