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

🍎 클라이언트와 서버 간 데이터를 주고받을 때, 데이터 순서 정렬이 필요한 상황에서 고려할 사항들을 정리합니다.

---

🍏 상황 설명

- 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한 데이터를 랜덤으로 보여줄 때, 매 번 서버에 재정렬을 요청하지 않아도 되는 것입니다.