Caremet 서비스에서 개발했던 채팅시스템의 Redis를 단순 Pub/Sub 용도로만 사용하던 것에서 벗어나, Redis의 다양한 자료구조를 활용해 채팅 시스템의 핵심 로직을 최적화한 것을 문서화하여 남깁니다. 🤔 기존 시스템의 한계점 분석기존에 구현했던 채팅 시스템은 다음과 같이 동작했습니다.1. 비효율적인 FCM 알림 시스템// 기존: 현재 서버 세션에서만 사용자 상태 확인if (currentServerSessions.contains(receiverId)) {// 알림 전송 안함} else { sendFCMNotification()// 다른 서버에 접속 중인 사용자도 알림 받음}문제점로드밸런서 뒤의 여러 서버 환경에서 사용자가 다른 서버에 연결되어 있을 경우를 감지할 수 없어, 채팅 중인 사..
크롤링 공고 위치 기반 페이징 API를 Redis GEO 기반으로 리팩터링하여 높은 동시성 요청에서도 안정적으로 응답 처리하고, 페이지 전환 시 응답 속도 단축을 목표로 하였습니다.🐢 기존 구현 방식의 문제점 (Mysql + Spatial Query 기반)기존에는 Mysql spatial기반 공간 쿼리를 활용하여 반경 5km 내의 공고만을 최대로 조회하고, UUID를 기준으로 Cursor 기반 페이징을 적용하였었습니다. fun findAllInRange( carerId: UUID, location: Point, next: UUID?, limit: Long, ): List { val crawledJobPostingIds = jpaQ..
개발을 하면서, 효율적인 SQL을 작성하기에 앞서 SQL 에 대해 더 친근해지고자!!예전에 프로그래머스에 있는 SQL 문제를 모두 풀었습니다.저만 알기보다, 각 게시글을 Lv 1에서 5까지하여 모든 문제의 답을 공유하고자합니다.(참고로 기본적인 데이터베이스 지식과 함께 SQL을 공부한다면,따로 SQLD를 학습하지 않아도 쉽게 따실 수 있습니다!! 따로 준비 안하고 땄습니듯! ) 상품을 구매한 회원 비율 구하기 프로그래머스SW개발자를 위한 평가, 교육, 채용까지 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프programmers.co.krSELECT DATE_FORMAT(O.SALES_DATE, '%Y') AS YEAR, DATE_FORMAT(O.SALES_DATE, '..
개발을 하면서, 효율적인 SQL을 작성하기에 앞서 SQL 에 대해 더 친근해지고자!!예전에 프로그래머스에 있는 SQL 문제를 모두 풀었습니다.저만 알기보다, 각 게시글을 Lv 1에서 5까지하여 모든 문제의 답을 공유하고자합니다.(참고로 기본적인 데이터베이스 지식과 함께 SQL을 공부한다면,따로 SQLD를 학습하지 않아도 쉽게 따실 수 있습니다!! 따로 준비 안하고 땄습니듯! ) 보호소에서 중성화한 동물 프로그래머스SW개발자를 위한 평가, 교육, 채용까지 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프programmers.co.krSELECT I.ANIMAL_ID, I.ANIMAL_TYPE, I.NAMEFROM ANIMAL_INS AS IJOIN ANIMAL_OUTS AS OUSING..
반가워요 SQL!개발을 하면서, 효율적인 SQL을 작성하기에 앞서 SQL 에 대해 더 친근해지고자!!예전에 프로그래머스에 있는 SQL 문제를 모두 풀었습니다.저만 알기보다, 각 게시글을 Lv 1에서 5까지하여 모든 문제의 답을 공유하고자합니다.(참고로 기본적인 데이터베이스 지식과 함께 SQL을 공부한다면,따로 SQLD를 학습하지 않아도 쉽게 따실 수 있습니다!! 따로 준비 안하고 땄습니듯! ) 없어진 기록 찾기 프로그래머스SW개발자를 위한 평가, 교육, 채용까지 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프programmers.co.kr SELECT O.ANIMAL_ID, O.NAME FROM ANIMAL_OUTS AS O LEFT JOIN ANIMAL_INS AS ION I.A..
문제상황프로젝트에서 하나, 둘 씩 테스트가 늘어가며 문제점이 발생!1분 이하였던 테스트들이 4분을 넘어가기 시작했다.(실제로는 실행시간에 포함되지 않는 과정까지 영상으로 확인했을때 5분 정도 되었다) 테스트는 기능을 추가하고 수정하며 빠른 피드백을 얻기 위함이었는데깃허브 액션 환경에서는 20분이 걸리기도하고.. 여러모로 협업 효율을 낮춘다고 생각이 들었다.개선 해봐야지라는 생각으로 로그를 살펴봤다. 크게 보이는 문제는 2가지였는데첫번째는 각 테스트마다의 컨텍스트 빌드에 시간이 많이 걸린다는 점 그리고 두번째는 데이터베이스의 쿼리문이 테스트 시간의 대부분을 차지한다는 점이었다. 1. 컨텍스트 환경 통합시키기 이전에 Mockbean을 사용하며, 테스트 환경 캐싱으로 인한 충돌로 테스트가 실패를 했..
알아두기 - HTTP와 웹소켓의 인증과정에서의 차이점HTTP 통신은 요청-응답 패러다임에 기반을 두고 있으며, 각 요청 후 연결이 종료됩니다. 따라서 매 요청 마다 새롭게 AccessToken을 검증해야 합니다. 이를 두고 Stateless 라고 합니다. 반면, 웹소켓은 최초 연결시에만 HTTP 요청을 사용하며, 연결이 맺어진 후에는 지속적인 데이터 교환을 제공하기에 추가적인 AccessToken 검증이 불필요해지게 됩니다. 이를 두고 Stateful이라고 하며, 웹소켓이 연결된 동안 인증과 관련된 정보를 웹소켓 세션에 유지 시켜 활용할 수 있게 됩니다. Overview - 채팅 인증 절차위 그림을 크게 두 가지 요청으로 나누어 설명드리겠습니다!CONNECT 요청 - 연결 요청 가장 먼저 웹소켓 연결 요..
💥 기존 : 초기에 개발되어 있던 형태 매칭 로직 동작에 걸렸던 시간 : 513초처음엔 프로젝트 마감 시간에 쫓겨, 평범하고 빠르게 만들었습니다. 만들고 나서 300명을 대상으로 테스트 했더니, 예상보다 성능이 너무 안나왔고 완성된 코드에서도 만족스럽지 않았습니다.저희 앱은 이전 회차의 매칭이 마감되고 다시 신청자들을 매칭 시키는데 2시간이라는 은행 점검시간 개념의 매칭 점검 시간을 갖습니다.팀 내에서는 점검 시간이 있기 때문에 매칭 로직이 조금 느려도 상관없다고 했지만, 저는 이것이 프로젝트의 장기적인 지속을 위해, 더 나은 방법이 있을지 항상 고민했습니다.그래서 조금 더 시간을 내어, 알고리즘의 병목 지점을 식별하고, 데이터 처리 방식을 최적화하여, 제가 할 수 있는 범위 안에서 성능을 향상시킬..