[30일차] | 대규모 시스템 설계 기초2 | 책너두

시스템 규모 확장

• 일반적으로 개별 호텔의 객실 예약시스템의 부하는 높지 않다.
• 하지만 만약 booking.com이나 expedia.com과 같은 대형 플랫폼과 연동이 필요하다면 확장이 필요하다.

데이터베이스 샤딩

• 샤딩을 할 때 가장 중요한것은 테이블을 어떻게 분할할 것인가이다.
• 이 케이스에서는 hotel_id를 기준으로 샤딩하는 것이 적절하다.
  • 대부분의 질의(query)에서 호텔 정보를 조회하는 경우가 많기 때문이다.

캐시

• 이 시스템의 특징으로는, 현재와 미래의 데이터만이 필요하다는 점이다.
• 따라서 redis를 사용하고 TTL을 통해 과거의 데이터는 자동으로 삭제되도록 하면 효율적이다.
  • 다만, 이에따라 캐시 유효성 문제가 발생할 수 있다.
  • 따라서 실제 예약 단계에서 데이터베이스를 확인할 필요가 있다.
• 또한 캐시 유효성 문제에 대해 고려해야 한다.
  • 변경 데이터 감지(Change Data Capture) 기능을 사용할수도 있다.
    • ex) Debezium

예약 서비스

• 주어진 조건에 맞는 객실의 존재유무를 질의한다.
• 객실을 예약하고, 취소할 때 잔여객실수를 업데이트한다.

잔여 객실 캐시

• 레디스에 키-값 형태로 잔여 객실 수를 저장한다.
  • 키: hotelID_roomTypeID_{날짜}
  • 값: 주어진 호텔 ID, 객실 유형 ID, 잔여객실 수

Q. 값에 주어진 호텔과 객실유형 ID는 왜?

잔여 객실 데이터베이스

• 잔여 객실 수에 대한 가장 신뢰할 수 있는 정보를 제공한다.

서비스 간 데이터 일관성

• 이 시스템에서는 MSA를 도입하였다.
  • 전통적으로 MSA에서는 서비스마다 독립적인 DB를 사용한다.
  • 하지만 독립적인 DB를 갖는 서비스간에 트랜잭션을 구현하는 것은 상당히 어렵다.
  • 따라서 이 시스템에서는 여러 서비스가 데이터베이스를 공유하도록 한다.

4단계: 마무리

• 주요 논의내용
  • 락
    • 비관적 락
    • 낙관적 락
    • 데이터베이스 제약 조건
  • 데이터베이스 확장(샤딩)
  • 캐시
  • 서비스 간 데이터 일관성