팝콘도팝이다

이길저길의 실시간 양방향 위치 공유 시스템 설계 과정에 수행한 성능테스트 결과를 공유하고자 한다.성능테스트 결과 뿐만 아니라 이전 글의 분석까지 종합하여 기술을 선정하였다. 시스템의 요구사항은 간략하게 다음과 같다:각 클라이언트는 연결이 된 시점부터 3초에 한 번 자신의 위치를 공유한다.위치 공유 대상은 사용자가 생성한 그룹의 그룹원들이며, 설계 단계의 예상 평균 그룹 인원수는 4명이다. 실시간 통신 기술들을 성능테스트 사전에 비교했던 흐름은 다음과 같다:SSE  vs  Short PollingSSE로 구현시 API를 총 2개를 구현하여 사용해야한다.SSE 커넥션 API자신의 위치를 전송하여 그룹원들에게 알리는 API Short Polling 에 비해 커넥션을 하나 더 가지고 있게 되어 SSE는 비효율적..

문제상황‘TWTW’의 테스트는 크게 Controller, Service, Repository Layer에서 진행되었다. 우리의 목표는 단위 테스트 적용이었다. 하지만 Service 테스트 코드 내에서 Repository를 통한 실제 DB 접근이 이루어져 완벽한 단위 테스트를 수행할 수 없었다. Repository Layer의 Mock 처리?Mock으로 처리할 수도 있다. 하지만 단위테스트 도중 무분별한 중복 Mock 사용이 많아졌다.또한, Mock으로는 동적인 테스트 불가로 구조 개선을 고민했다.Ex) 하나의 테스트 내에서 save한 엔티티를 조회해야 한다면 두 번의 Mock을 거쳐야 하고 동적으로 테스트가 불가하게 되며, Mock으로 시작해 Mock으로 끝나는 테스트가 되어버린다.접근 방식Reposit..

문제상황사용자 경로 제공에 있어 Kakao, Naver, Tmap Open API를 사용하였고 Open API에 장애가 발생한 경우 처리에 있어 유연한 처리가 필요함을 느낌장애가 발생하더라도 지속적으로 [OpenAPI 요청 -> 예외 발생] 이 반복되는 상황다음과 같은 부분이 가장 개선하고 싶었다.지속적으로 네트워크를 활용해 요청하는 부분어차피 데이터를 못 받아오는데, 매번 요청하여 에러를 반환할 때까지 기다리는 부분여러 OpenAPI에 의존하고 있는 이길저길 서비스에서 OpenAPI를 동적으로 호출하지 않도록 제한하면 비용을 많이 아낄 수 있을 것이라 기대했다.이러한 자잘한 문제도 있었다.DB를 같이 활용하는 API의 경우 OpenAPI 정보를 제외한 정보는 반환하고 싶은데, DB 정보까지 반환 못하는..

Redis Cache 성능 비교문제상황사용자에게 지명 정보, 경로를 제공하기 위해 Kakao, Naver, Tmap Open API를 사용한다. 위 API 제공에 있어 호출까지의 시간이 소요되고 비용 낭비가 발생이미 반환된 정보를 사용자가 재사용하는 경우가 많기 때문에 경로를 임시 메모리에 저장하는 로직 필요데이터 특성 상 한번 참조된 값에 대해 변경이 자주 일어나지 않음접근Redis Cache를 이용하여 Open API의 반환값을 일부 저장하여 사용자에게 제공적용@CachePut과 @Cacheable Annotation을 사용하여 API에 레디스 캐시 적용캐시 적용시 동작 흐름 @CachePut과 @Cacheable을 사용하는 API 분리 (동일 로직 수행)위와 같이 API를 분리해 구현한 이유사용자가..

문제 상황 & 접근FCM 오류 처리그룹 초대 , 친구 요청 서비스를 수행하는데 있어 FCM을 사용했다. FCM 자체의 성능 개선을 위해 RabbitMQ을 사용함. FCM 요청에 있어 오류가 발생할 경우 처리를 위해 데드레터 처리비동기 적용FCM 자체는 동기방식이기 때문에 짧은 시간에 많은 요청이 수행되는 경우 성능상 개선 필요, 메시지 큐를 사용하여 비동기 방식으로 처리적용queue 설정알림을 위한 RabbitMQ queue에서 발생한 오류는 데드레터로 메시지가 전달되도록 연결하였다.producer알림관련 정보 즉, rabbitmq로 발행할 메시지 정보들을 db에 저장한 이후 rabbitmq로 알림 발송을 위한 메시지를 발행한다.알림 consumerFCM을 통해 알림을 발송한다.db에 저장된 알림 관련 ..

문제 상황‘이길저길’ 서비스 내에서 친구 검색 시 Member의 닉네임(문자열)으로 검색을 수행하는 API가 있고 기존 Like 검색은 데이터의 개수가 많아질수록 성능에서 부족함이 있었다.Like 연산시Member 데이터를 500만 row 저장하고 특정 닉네임을 검색하는 쿼리를 Like 연산을 이용하여 수행하였다.준비 작업 (프로시저)sql로 프로시저 작성 (그대로 실행하면 500만개의 member를 insert한다)기존 자바 코드로 500만개를 넣으려 시도하니 heap 영역의 공간이 없어 error 발생DELIMITER $$DROP PROCEDURE IF EXISTS twtw.insertLoop$$CREATE PROCEDURE twtw.insertLoop()BEGIN DECLARE i INT DE..

(내용 작성 예정입니다.)문제 상황 & 고민매번 수동으로 배포하기에는 소요되는 시간 개선 필요해결 & 결과Github Actions로 CI workflow에서 테스트 후 JIB를 통해 컨테이너화CI 완료시 자동으로 CD workflow 를 실행하여 AWS ec2에 배포실행 예시

요구사항유저는 지인들과 그룹을 만들 수 있으며, 그룹 내에서 서로 어느 위치에 있는지 휴대폰 화면으로 확인할 수 있어야 한다.특히나, 두 명 이상의 유저가 가까운 거리에 있는 경우 느리게 업데이트되면 빠르게 위치를 파악하지 못해 만나는데 서비스가 크게 도움이 되지 않을 것이기에 3초에 한 번 자신의 위치를 클라이언트에서 공유하여 그룹 전체 인원에게 알린다.문제 상황 - 실시간 공유 기술 선택양방향 실시간 위치 공유 구현을 위한 기술 선택 필요요구 사항[실시간성] 실시간으로 확인할 수 있도록 낮은 지연 시간 요구됨변화 시점마다 그룹원의 위치 파악 필요[양방향 지원] 양방향으로 데이터를 공유각 그룹원이 데이터를 서버에 보내면 나머지 그룹원이 데이터 받아야 함[높은 업데이트 빈도] 각 유저는 3초 주기로 데이..