Delivery

Delivery

캐시 적용으로 읽기 성능 향상

안녕하세요 이번글은 Home-Delivery프로젝트에서 주문을 하는과정 중 반복적인 읽기 요청을 하는 부분에 대해서 캐시를 적용하여 성능을 향상시킨 과정을 적었습니다. 문제상황 주문까지의 유저들의 사용과정을 예상한다면 앱에접속 -> 카테고리 선택 -> 매장리스트 조회 -> 매장 상세조회 메뉴,메뉴그룹 조회 -> 메뉴옵션 조회 -> 장바구니담기 -> 주문의 과정이 이루어집니다. 이와같은 작업들은 주문하기전까지 한번에 이루어지는경우도있지만, 여러사이클이 반복될거라 생각됩니다. 동일한 데이터에 대한 반복적인 DB 요청이 발생합니다. DB요청이 많으면 발생하는 문제는 DB접근은 커넥션 뿐만 아니라 DB자체에서의 연산도 느리니 DB요청을 적게하면 좋습니다. 요구사항 - 매장목록, 메뉴목록, 메뉴그룹목록, 메뉴옵션..

Delivery

FCM 푸시알림 구현 이슈 - 비동기 처리(성능개선)

이번글은 저희의 home-delivery서비스는 유저 주문이 수락할경우, 주문취소, 라이더가 배달완료, 라이더가 음식픽업 시 알림이 가도록하기위한 알림 서비스를 구현하면서 경험을 작성하였습니다. FCM이란? Firebase 클라우드 메시징(FCM)은 메시지를 안정적으로 무료 전송할 수 있는 크로스 플랫폼 메시징 솔루션(교차 플랫폼)입니다. FCM의 주요 기능으로는 알림 메시지 또는 데이터 메시지 전송, 다양한 메시지 타겟팅, 클라이언트 앱에서 메시지 전송 이있습니다. 이 중 저희가 필요한 부분은 알림 메시지였습니다. FCM의 장점 1) FCM은 교차 플랫폼 메시지 솔루션이기 때문에 FCM을 이용해서 개발을 진행하면, 플랫폼에 종속되지 않고 Push 메시지를 전송할 수 있습니다. -> Web, Androi..

Delivery

레디스 테스트코드 문제점 - TestContainer도입

안녕하세요 이번글은 프로젝트 Unit 테스트코드와 Integration 테스트코드 작성시 발생했던 문제에대해서 작성하였습니다. 문제상황 팀원분이 했던 코드를 PULL를 받고 테스트를 돌리던중 발생했던문제가있습니다. - 팀원분의 Redis포트번호가 저와 다르기때문에 발생했습니다. - Redis는 테스트 코드 실행 후 롤백이 불가능하므로 깨지는 테스트가 존재했습니다. 생각한 방법 방법1. Docker컨테이너를 테스트코드를 실행하고 나서 Redis 컨테이너 삭제하자. 왜냐하면 레디스는 롤백이없기때문에 테스트를 종료시키는게 좋다고생각했습니다. 그런데 이 방법은 개발자가 직접 매번 작동해야한다면 이것은 매우 불편한 일입니다. 즉 향후 CI / CD도입을 하는데 도입의 목적은 자동화를 도입시켜 생산성을 향상시키는데..

Delivery

Redis 장바구니 - 2 (Redis pipelining)

안녕하세요, 이번글은 장바구니 로직을 로직완성을 하고 개선을 하기위해 겪었던 과정의 글입니다. 문제상황 저는 장바구니 로직중 메뉴를 지우는 로직은 이와같습니다. 1. 장바구니에 담긴 메뉴를 지웁니다. 2. 장바구니가 비어있는지 확인합니다. 3. 비어있다면 유저가 가진 매장정보 + 유저의 장바구니 정보도 지워줘야합니다. 이부분에서 로직한번에 db커넥션을 4번이나 해야하는 상황이 생깁니다. 🎈레디스도 커넥션 풀을 가질가? 레디스는 메인 프로세스가 싱글스레드인것이고 커넥션은 일반 디비처럼 커넥션풀을 씁니다. 레디스 커넥션 설정을 찾아보면 설정하는게 존해합니다. 커넥션이란게 어차피 데이터 전송이 다 끝나고 handshake까지 마쳐야 종료되는거라 메인 프로세스와는 별도로 여러개의 커넥션을 가지고 네트워크 rou..

Delivery

Redis를 이용한 장바구니 - 1

안녕하세요 이번 주제는 배달 음식을 시킬때 장바구니를 구현을 하면서 겪었던 문제점 입니다. 저희는 배달의 민족 클론코딩이기때문에 아래 사진과 비슷하게 장바구니 UI를 생각했습니다. 지희가 원하는 서비스는 - 장바구니에 같은 매장 음식들만 담을 수 있다. - 같은 메뉴이지만 메뉴옵션이 다르면 다른 메뉴로 장바구니에 담아진다. - 수량은 한번씩만 변경할 수 있다. - 메뉴에서 같은 (메뉴+옵션)을 선택한다면 수량이 증가한다 위와같은 로직을 구현해야했습니다. 저는 레디스 저장소를 사용했습니다. 인메모리저장소를 사용한이유는? 왜냐하면 장바구니 특성상 유저들이 대부분 장바구니에는 담았다 지웠다 많이 조회가 많이 일어나기도 해서 db에 매번 I/O를 것보다 속도가 더 빠르다고 생각하기도 하였고, 추가적으로 장바구니..

Delivery

리펙토링 디비조회

안녕하세요 이번글은 제가 메뉴리스트를 우선순위별로 불러오면서 겪었던 문제입니다. 메뉴그룹과 메뉴를 불러와야하기때문에 저는 아래 코드와같이 1. 먼저 storeId가 존재하는지 확인하고 2. 매장의 메뉴그룹리스트를 불러옵니다. 3. 메뉴그룹리스트의 메뉴그룹의 아이디를 통해서 menuMapper를 통해 각 메뉴리스트들을 가져옵니다. MenuListResponseDto에는 ( id, List) 를 속성으로 가집니다. 쿼리에서 정렬을 수행해주기때문에 저는 이상이없다고 생각했습니다. 그런데 문제점이있습니다. 위의 코드와 같이 한다면 steam을 돌면서 매장의 메뉴그룹마다 db를 호출해야하기때문에 수가 많아진다면 n번 만큼 호출하게 됩니다. 그래서 다음 작업은 db호출을 줄이고 Map 자료구조를 이용하는방법입니다...

Delivery

캐싱전략, 메모리

이번 글은 성능을 향상시키기 위해서 캐시를 사용할려는데 캐시사용에도 여러 전략이 존재합니다. 그래서 여러전략들을 정리하도록하겠습니다. 캐싱전략이란? 캐싱(Caching)은 애플리케이션의 처리 속도를 높여준다. 이미 가져온 데이터나 계산된 결과값의 복사본을 저장함으로써 처리 속도를 향상시키며, 이를 통해 향후 요청을 더 빠르게 처리할 수 있습니다 로컬 캐싱 vs 글로벌 캐싱 로컬 캐싱은 서버 내부 저장소에 캐시 데이터를 저장하는 것이다. 만약 scacle out을 한다면 데이터가 공유가 안되므로 서버마다 캐시 데이터가 다를수있습니다 그런데 서버내에서 작동하기 때문에 속도가 빠릅니다. 예를 들어, 사용자가 같은 리소스에 대한 요청을 반복해서 보내더라도 A 서버에서는 이전 데이터를, B 서버에서는 최신 데이터..

Delivery

레디스를 선택한 이유, 세션클러스터링

이번글은 저희가 대용량을 생각하면서 개발을 하자는 목적으로 Delivery프로젝트를 진행했습니다. 저희는 세션을 통한 로그인을 하는데 지금은 애플리케이션이 한개이지만 대용량 처리를 위해 scale-out을 통해서 여러개의 애플리케이션이 존재한다면 발생되는 문제점인 세션 정합성 문제를 해결하기 위한 세션 관리 전략에 대해 알아보겠습니다 정합성이란? 데이터 정합성 : 어떤 데이터들이 값이 서로 일치함. 왜 세션 정합성이 안맞는 문제가 발생할가? 아래와 같이 3대로 scale-out을 진행한다면 유저가 요청마다 Nginx가 요청을 분배해주는데 동일한곳으로 계속 연결을 시켜준다면 이상이없겠지만 요청마다 다른곳으로 요청을 분산시켜준다면 로그인을 했는데 또해야하는 문제가 발생하게될것입니다. 그래서 이러한 문제를 해..

Delivery

레디스에 대해 알아보자

이글의 목적은 Delivery 프로젝트에서 레디스를 활용하는 부분이 여러곳이 예상되어 생겼습니다. 그래서 저는 레디스를 사용하기 전 확실하게 다시 정리하기 적게되었습니다. 인메모리 데이터베이스란? In-Memory Database IMDB, 혹은 MMDB(Main Memory DBMS)라고 부르는 것을 알기위해선 메모리 계층을 알아야합니다. 인메모리란 컴퓨터의 메인 메모리 RAN에 데이터를 올려서 사용하는 방법을 말합니다. 사진과같이 위로갈수록 비싸고 속도가 더 빠릅니다. 왜 메모리에 데이터를 올려서 사용할가요? 바로 속도입니다. SSD,HDD와 같은 저장공간에서 데이터를 가져오는 것보단 RAM에 올려진 데이터를 가져오는데 걸리는 속도가 수백배 이상 빠릅니다. 그래서 빠른속도가 Redis의 장점입니다. ..

Delivery

Mybatis batch처리 성능과 트랜잭션

이번글은 제가 우선순위 업데이트를 구현하는 과정에서 발생한 문제를 해결하는 글입니다. 문제상황 우선순위 업데이트를 할때 update문이 여러번 실행되는것입니다. 우선순위를 바꿀때 하나의 로우에서 우선순위 컬럼이 2로 변경된다면 이에따른 메뉴들의 우선순위가 다같이 변경되어야한다고 생각해서 구현을 한 상황에서 db호출이 여러번 진행되므로 db호출을 할때 connection을 맺고 그리고 쿼리를 실행하는 과정이 반복되기때문에 느려진다고 판단했습니다. 프론트에서 받는데이터 [{id : 1, priority:3}, {id : 2, priority:1}, {id : 1, priority:4}, {id : 1, priority:5}] 프론트에서 저는 화면에 배치된 순서대로 받는다고 가정했습니다. 요구사항 하나의 co..

cwangg897
'Delivery' 카테고리의 글 목록