요구사항유저는 지인들과 그룹을 만들 수 있으며, 그룹 내에서 서로 어느 위치에 있는지 휴대폰 화면으로 확인할 수 있어야 한다.특히나, 두 명 이상의 유저가 가까운 거리에 있는 경우 느리게 업데이트되면 빠르게 위치를 파악하지 못해 만나는데 서비스가 크게 도움이 되지 않을 것이기에 3초에 한 번 자신의 위치를 클라이언트에서 공유하여 그룹 전체 인원에게 알린다.문제 상황 - 실시간 공유 기술 선택양방향 실시간 위치 공유 구현을 위한 기술 선택 필요요구 사항[실시간성] 실시간으로 데이터 변경 시 신속히 클라이언트에서 확인 가능해야 함변화 시점마다 그룹원의 위치 파악 필요[양방향 지원] 양방향으로 데이터를 공유각 그룹원이 데이터를 서버에 보내면 나머지 그룹원이 데이터 받아야 함[높은 업데이트 빈도] 각 유저는 3..
요구 사항 그룹 랭킹과 그룹 별 회원 랭킹을 보여줘야 한다. 회원 랭킹은 각 회원의 GitHub 기여도(커밋, 이슈, pr, 코드리뷰) 개수를 모두 더한 값을 포인트로 하여 랭킹을 매긴다. 각 기여도는 각 다른 GitHub API를 통해 조회하여 저장한다. 그룹 랭킹은 그룹 내에 속한 회원들의 포인트(GitHub 기여도)를 모두 더한 총합을 토대로 랭킹을 매긴다 문제 상황 동시에 여러 번 호출할 경우 DB 데이터가 중복 저장되는 현상 빈번히 발생 특히, 그룹의 포인트 갱신 시 동시성 이슈 발생 한 번의 요청에 종류가 다른 4가지 멤버의 기여도를 가져와 하나의 같은 테이블을 업데이트, 다른 한 테이블에는 insert DB Lock 적용DB Lock을 통해 데이터..
Latency 3.52s -> 454ms 로 쿼리를 7.7배 개선한 작업을 공유하고자 합니다. 문제 상황 & 고민서비스의 핵심 API의 Latency가 데이터가 몇십만 건이 쌓이는 경우 성능적 개선이 필요했습니다.해당 API에서 사용하는 DB 조회 쿼리 개선이 필요하다고 판단했습니다.개선 작업약 41만 건의 랜덤한 데이터 삽입 이후 K6를 통해 부하테스트를 통한 평균 Latency를 확인하며 진행했습니다.부하테스트의 경우 같은 조건으로 5번 이상씩 수행하며 평균에 가까운 값을 확인했습니다.1. 초기 상태 [3.52s]어떤 작업도 하지 않은 상태에선 조회 API Latency가 3.52초가 걸렸으며, 이로 인해 개선 작업을 시작했습니다.서비스의 가장 중요한 결과 조회 API 이었기에 더더욱 개선이 필요했..