꾸준하게

배경 현재 진행중인 나르지지 서비스는 스케줄링으로 적재되는 데이터 이외에는 유저의 데이터가 들어갈 일이 없습니다.하지만 서비스를 확장하면서 몇 명이 조회했는지, 리뷰 등록과 같은 상황이 발생할 수 있습니다.이러한 상황에서는 현재 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 모니터링 툴을 이용하여로컬에서 운영..

1차 리팩토링: 구조 개선 + 비동기 전환(1차 리팩토링 글 : https://changha-dev.tistory.com/188 )처음 진행한 리팩토링에서는 다음과 같은 개선을 통해 구조적 안정성과 기본적인 성능 향상을 도모했습니다:외부 API URL 하드코딩 문제 → HttpInterface와 RestClient 기반으로 추상화하여 가독성과 유지보수성 향상전적 조회 10건을 순차적으로 호출하던 방식 → CompletableFuture와 ThreadPool을 활용한 비동기 처리 방식으로 전환이 과정을 통해 기존 평균 2~3초 걸리던 요청을 1초 미만으로 단축하는 데 성공했습니다. 그러나... 성능은 아직 충분하지 않았다비동기 구조로 전환한 이후, 내부 처리 시간 자체는 약 500ms 수준으로 빨라졌지만실..

작년 12월부터 지금까지, 내 머릿속 절반은 TIMO.GG로 가득 차 있었다고 해도 과언이 아닌 것 같다..작년 디자이너분이 만들어주신 귀엽고 정감 가는 로고와 캐릭터 덕분에, 이 프로젝트에 더 큰 애정을 갖게 된 것 같다. 대학 생활 중 정말 다양한 프로젝트를 해봤지만, 실제 서비스로 운영까지 간 적은 없었다. (대부분 비즈니스 모델의 한계 때문이었다)그래서 이번에는 ‘우리가 좋아하고 직접 써볼 수 있는 서비스’를 만들고, 끝까지 운영까지 해보자는 목표를 세웠다. 이 프로젝트를 진행하며 가장 집중한 부분은 무엇이었을까?사용자 중심적 사고 회원가입 플로우 단순화기본 닉네임 자동생성티모대위-a12b42(랜덤UUID 활용)오직 OAuth 로그인 통한 비밀번호 미사용→ 유저가 빠르게 서비스를 경험하는 것이..

이 책을 읽게 된 이유취준 단톡방을 통해 처음 접하게 되었다. 요즘 취준하면서 부족한 CS를 채우려고 노력하는데 이 책의 목차를 보고 꽤 중요한 개념들이 있어서 바로 빌렸다.특히 CPU, 메모리 관리, 스레드, 프로세스, 동기/비동기, 블로킹/논블로킹 이러한 개념들은 알아도 계속 학습을 안하면 휘발되어서 다시 한번 숙지하자는 목표도 있었다. 어떠한 내용들이 있었나운영체제에서 하드웨어까지 전반적으로 필요한 개념들은 모두 주제로 등장한 것 같다. 이 책의 목표는 책 제목처럼 컴퓨터 밑바닥의 비밀을 아는 것, 즉 컴퓨터 내부의 동작원리를 파헤치는 것이다. 그런 관점에서 의문형으로 깊숙이 들어가는 구성이 도움이 되었다.[목차 일부] 대부분의 주제, 소제목이 의문형으로 되어있다.나에게 도움이 된 부분추상화이 책에..

바로 이전에 책을 읽고 디자인 패턴은 객체지향의 핵심인 역할, 책임, 협력 관점에서 반복되는 문제들을 해결하기 위해 개발자들이 자주 사용하는, 검증된 기법들을 정리한 것임을 알게 되었다. 그래서 디자인 패턴에 대해 좀 더 자세히 알아보기 위해서 읽게되었다. GoF의 디자인패턴 책이 유명하지만 학교 전자 도서관에서 지원을 안해서 선택하게 되었다.별점 (3.5/5) (후반부 디자인패턴쪽은 처음 접한 개념은 혼자 이해하기 쉽지 않았다.) 초반부는 객체지향 패러다임에 대해 소개해주는 부분이 있었고중반부는 코드 리팩토링 관점 후반부는 디자인패턴의 여러 개념및 적용 예시를 보여주었다. 특히 오늘 플라이웨이트 기법의 객체 재사용 측면에 대해 알게되었는데 Integer의 비교 기법에서 == 이 어떨 때 true이고 ..