새로운 팀플에서 배송 관련 기능을 담당하게 되었다.
요구사항만 잔뜩이지 정책 관련해서는 세세하게 설정된 부분이 많지가 않아 어렵다.
정말 기획이 개발보다 어렵다...
기능에 대해 정리하면서 고민되었던 부분에 관해 알아본 사실을 정리해 보았다.
고민들
1. 주문 ID 설정 방식
요구사항
user를 제외한 각 엔터티의 Id를 UUID로 설정하도록 함
상황
1. 주문 생성 시 배송 테이블 엔터티가 함께 생성됨
2. 이후 배송 목록 조회 시 주문 엔터티의 Id도 함께 보여줌
고민
주문 관련 내용을 공유할 때 주문 UUID 전체를 불러야만 정확한 주문이 파악이 가능함
UUID가 36자리 문자열인데, 이게 비효율적이며 휴먼 에러 발생으로 이어지지 않을까?
알아본 것
-
해시 알고리즘을 사용한 압축
: 128비트 UUID를 해시 알고리즘(SHA-256또는MD5)으로 변환한 뒤, 상위 몇 비트만 사용해 짧은 고유 ID를 생성한다.장점
- 고유성을 어느정도 유지하며 짧게 표현 가능
단점
- 해시 충돌 가능성 존재
-
Base62인코딩을 사용해 UUID를 압축하는 방법
:Base62(영문 대소문자 + 숫자)로 변환하여 짧게 표현한다.
Base62는 Base64보다 길이를 조금 더 줄이고, URL-safe한 방식이다.장점
- 일단 짧아진다
단점
- 128비트로 설계된 UUID는 3.4 * 10^38개의 고유값을 나타낸다
- Base62를 8자리로 사용할 때, 62^8 = 218,340,105,584개의 정보를 나타낼 수 있다
-> 고유성이 크게 낮아지므로 제한된 범위 내에서만 사용할 것이 권장됨
-
원본 UUID와 함께 사용자 식별용 UUID 생성, 저장
:Base62또는Base64변환을 통해 축약형 UUID를 생성한다.
기본 UUID를 Id로, 축약형 UUID를 short_id로 따로 저장하여 사용한다.- 내부 로직: 원본 UUID(id)로 조회
- 사용자 인터페이스, url: short_id로 조회
장점
- 고유성, 사용자 편의성을 병행해서 가져갈 수 있다.
- url에 id를 포함할 경우 좀 더 짧게 가져갈 수 있다.
단점
- short_id의 길이가 짧을수록 충돌 가능성 증가. 8자리 이상으로 설정할 것이 권장됨
- 8자리면 일단 218조개의 고유 조합이 생성 가능함
- 어쨌든 short_id를 저장하기 위한 추가 공간이 소모된다.
-
Snowflake ID 사용?
: Twitter에서 설계한 고유 ID 생성 알고리즘. 분산 환경에서도 고유성을 보장하는 64비트 정수형 ID를 생성함. 주로 대규모 시스템에서 정렬 가능한 고유 ID를 효율적으로 생성하고 관리하기 위해 사용됨
예약비트, 타임스탬프, 노드 ID, 시퀀스 번호로 구성됨관련 정보로 나오기에 찾아봤는데 현 상황에 필요한 정보는 아닌 것 같다. 나중에 찾아볼 것.
2. 배송 경로 결정
요구사항
재고를 가지고 있는 17개의 허브가 있음
이 허브에서 최종 목적지(수령 업체)로 물건을 배송해야 함
상황
허브를 어떤식으로 경유해서 물건을 배송할 것인지 결정해야 함
4가지 방법이 제시되어 있음
- P2P
- 모든 허브가 직접 연결되어 있음
- Hub and Spoke
- 모든 허브가 중앙 허브를 통해 연결되어 있음
- 서브 허브는 중앙 허브를 경유해서 배송되어야 함
- P2P + Hub to Hub Relay
- 인접 허브가 서로 직접 연결되어 있음
- 중간 허브를 경유하지 않고 직접 목적지로 배송할 수 있음
- 배송거리가 먼 경우(200km 이상)에는 중간 경유지를 통해 배송해야 함
- Hub to Hub Relay
- 인접 허브가 서로 직접 연결되어 있음
- 특정 경로를 통해 전달되어야 함
- 연결된 허브간 배송만 가능
고민
3, 4번 방법에 큰 차이를 느끼지 못했다.
하지만 차이는 있으니까.. 정리해보았는데
| 항목 | P2P + Hub to Hub Relay | Hub-to-Hub Relay |
|---|---|---|
| 인접 허브 간 직접 이동 | 가능 | 불가 |
| 메인 허브 경유 여부 | 필요할 때만 사용 | 항상 경유 |
| 경로 선택 방식 | 동적으로 최단 경로 선택 | 사전에 정의된 경유지 경로 사용 |
| 효율성 | 가까운 거리는 더 효율적 | 경유로 인해 추가 거리 발생 가능 |
결론
P2P + Hub to Hub Relay
- 허브 네트워크가 조밀하고, 인접 허브 간 직접 이동이 가능한 경우 적합
- 좁은 지역에서의 효율적인 이동 가능
Hub-to-Hub Relay
- 메인 허브 중심의 네트워크를 사용해야 하는 경우 적합
- 중앙 집중형 네트워크 구성
지금 사이즈로는 P2P + Hub to Hub Relay 방법이 제일 적합하지 않은가 하는 생각이 든다.
하지만 사이즈가 더 커진다면..?👀
