LOG-INFO
commented
3 months ago 끄적끄적
-
이번장 간단 후기: 음..! 좀 더 뭔가 더 디테일한 내용이 나올 줄 알았는데, 낙관적락, 비관적락이 거의 전부라 김샜음
-
항공쪽은 오버부킹문제가 간혹 들리니 오버부킹이란게 있다는걸 알고 있었는데 숙박쪽에도 있었군
-
객실 가격 유동적인 것은 요구사항에 나왔는데 안 다룸?
-
Non-Functional Requirement(NFR)에 '성수기/대규모 이벤트 기간에는 일부 호텔의 특정 객실을 예약하려는 고객이 많이 몰릴 수 있다'라고 해놓고 뒤에 가서는 '예약이 3 TPS 밖에 안되니까 간단히 DB Constraint를 사용한다'며 넘어가다니!
주요 키워드
- Lock
- Optimistic Lock
- Pessimistic Lock
- DB Constraint
- Data Access Pattern
- Micro-Service Architecture(MSA)
- gRPC
- Cold Storage
- 2-Phase Commit(2PC) vs Saga
- Eventually Consistency
HaeUlNam
나와바리
호텔 예약 시스템을 설계해보자! (메리어트 인터내셔널은 대체 뭐임..? )
호텔 예약 사이트에서 실제 객실 수 보다 더 많은 객실을 판매할 수 있다는 사실에 놀랐음 ( 이러면 고객 입장에선 나중에 취소건이 없으면 예약이 취소될 수도 있는데 이게 가능하다니...?? )
예약 취소 시 환불 수수료에 대한 내용이 없는 부분은 조금 아쉬웠음 ( 어차피 시스템 설계라서 별로 필요없으려나? )
100만개의 호텔 객실 수 중 70%만 사용중이고 평균 투숙 기간이 3일이면 (100*0.7)/3 => 233,3333 -> 반올림시 240이고 초당 예약 건수는 24만/10^5 => 3 QPS 정도로 계산한다. ( 고작 3QPS..?? )
호텔 예약은 동시성 제어가 비교적 쉬운 편이긴 하다. ( 객실 당 총 재고는 그 날짜에 재고가 1개이므로 )
호텔 서비스의 설계 시, 호텔/요금/예약/결제로 나눈 부분이 인상적이다.
요금은 굳이 서비스로 나눌 필요까지 있었을까 싶긴 한데, 여기선 나누었다. 특정 날짜별로 객실 요금을 다르게 측정하기 위함이라고 한다.
이 챕터에선 구체적으로 DB 테이블 설계와 질의 과정을 보여준다.
예약 데이터를 단일 데이터베이스에 담기 너무 크다면, 현재 및 향후 데이터만 보관하고 나머지는 Cold Storage로 보내는 전략이 필요할 수 있다. ( 이는 매우 당연한 작업임 )
DB 샤딩 방식도 지원해볼 수 있다. 호텔 ID로 샤딩을 하는 방법도 있음
예약에서는 동시성 문제가 중요하다. 이를 막기 위해선 클라이언트 단에서 예약 버튼을 눌러서 진입할 시 BE로 API를 보내서 해당 에약건을 점유할 필요가 있음.
SELECT FOR UPDATE 락은 굉장히.. 굉장히 위험한 락이므로 가급적이면 사용하지 않는 편이 좋음. Application Lock으로 풀어볼 것을 추천
결국 마이크로서비스간 데이터 불일치를 해결하기 위해 사용되는 복잡한 메커니즘은 시스템 전체 설계의 복잡성을 크게 증가시키는 만큼, 그만한 가치가 있는지를 잘 판단하는 것이 중요하다고 함. ( 매우 매우 매우 공감되고 중요한 내용인 듯!! )
추가 : Hotels.com 시스템 아키텍처 분석 아티클 : https://medium.com/@sahintalha1/high-level-system-architecture-of-booking-com-06c199003d94