[설계] 순서 결정의 책임을 결정하는 방법

Dev

친환경사과 2024. 9. 3. 17:14

- Json Format으로 조회한 제품 리스트의 순서 정렬에 관한 요구사항을 해결 중 정렬의 관한 책임을 서버에 두기로 생각

- 생각의 근거는 순서를 정렬하는 것이 비즈니스 로직에 포함되어야 한다고 판단했고 클라이언트에선 서버에 요청값을

{ “order” : “ASCENDING” }

- 위와 같이 넘겨 정렬이 완료된 값만 받아오는 것이 합리적이라고 생각

- 첫 번째 이유는 서버가 정렬하는 것이 비즈니스 로직이라고 판단했는데 이를 잘못 판단

비즈니스 로직이라는 것은 운영하는 서비스 내부에 존재하며 다른 도메인(혹은 서비스)에선 적용되지 않은 로직
"정렬" 기능은 내가 속한 조직 뿐만아니라 다른 서비스에서 제너럴하게 사용되는 로직이므로 비즈니스 로직이 아님. 따라서 클라이언트에서 정렬을 처리해도 무방

- 두 번째 이유는 요구사항으로 클라이언트에게 넘겨줘야할 데이터의 사이즈를 생각하지 않고 무조건 정렬은 서버에서 이루어져 값이 내려가야 한다고 판단

❗️ 물론 위의 부분도 요구사항의 상황에 따라 달라질 수 있습니다.

- 정렬을 수행하는 곳의 데이터 볼륨과 고정의 유무(e.g. 특정 Index 혹은 특정 record)를 통해 판단 가능

데이터가 많고 고정된 값이 아닐 때
- 데이터가 많고 고정된 값이 아닐 때는 필요하다면 sequence, order 타입을 서버에게 요청값으로 넘겨 서버사이드에서 정렬하는 것이 좋습니다. 정확히 이야기하면 영속계층(DB)에서 해결하는 것이 좋습니다.
- 이유는 많은 데이터를 메모리에 올려 정렬을 수행하는 것은 서버에서 부담이 되기 때문입니다. 서버 메모리의 부담을 줄일 수 있는 장점이 있습니다.

SELECT *
FROM test
WHERE idx > sequence
ORDER BY ASC # or DESC

데이터가 많고 고정된 값이 존재할 때
- 데이터가 많고 고정된 값이 존재하는 상황에선 위의 상황과 마찬가지로 메모리에 모든 데이터를 적재하는 것이 부담됩니다. 블록의 사이즈를 클라이언트에서 받아와 고정된 값을 지정하는 것으로 문제를 해결할 수 있습니다.
- 랜덤 룰렛 기능을 개발한다고 가정했을 때, 이 방법을 사용한다면 1등의 비율을 몇 명의 사용자마다 추첨할 수 있게됩니다. 확률을 고정할 수 있는 이점을 얻을 수 있습니다.

SELECT *
FROM test
WHERE idx > sequence
LIMIT size

한정적인 데이터에 고정된 값이 존재할 때
- 적은 수의 데이터와 고정 값이 존재하는 상황에선 클라이언트에서 순서를 정렬하는 것이 좋습니다. 서버에서는 고정인지 랜덤인지 판단하는 옵션 값(VIEW_TYPE)과 이에 따른 위치 값(POSITION)을 넘겨줍니다. 위 데이터를 받은 클라이언트는 옵션 값을 읽어 순서를 정렬합니다.
- 이 방법을 통해 얻을 수 있는 장점은 클라이언트에서 Cache한 데이터를 랜덤으로 보여줄 때, 매 번 서버에 재정렬을 요청하지 않아도 되는 것입니다.