동시성 제어하기 - 07. 읽기와 쓰기의 트레이드 오프

병목 해소하기

• 쓰기 지점의 병목은 하나의 레코드를 점유 → 락 대기가 발생
  • 락 대기를 풀고자 테이블 형식으로 분리 → 조회 지점의 병목이 발생
• 조회 지점의 병목은 카운트로 처리
  • INSERT 했던 데이터들을 aggregation해서 sum 하기 위해서 매번 카운트 쿼리가 발생

데이터의 성질 확인하기

정합성을 요구하는 데이터인가?

 

예시) 좋아요수가 0.1초의 딜레이를 가진다고 해서 고객에게 엄청난 손해를 주는 데이터인가?

         그렇지 않다. 좋아요 수는 어느 정도의 실시간성만 보장만 된다면 괜찮다.

따라서 이런 형식으로 아키텍처링을 할 수 있음

1. 클라이언트는 웹 서버에 좋아요 누름에 대한 요청을 한다.
2. 웹 서버는 좋아요 테이블에 INSERT를 한다.
3. 조회 시점은 게시물 테이블 컬럼에 캐싱을 해놓는다.
4. 특정 주기를 가진 스케쥴러가 좋아요 테이블을 주기적으로 count한다.
5. count를 통해서 얻은 결과를 게시물 테이블에 UPDATE 해줌

장점

고객이 요청을 할 때마다 count query가 나가는 것이 아닌, 고객의 요청이 몇번이 오든간에 주기마다 1번씩만 count가 발생함 (만약 주기를 1초로 설정했으면, 1초마다 1번의 count가 발생)

→ count query의 횟수를 비약적으로 줄일 수 있음

 

단점

기존에는 웹 서버만 관리하면 되는데, 위의 방식은 웹 서버와 스케쥴러를 관리해야 함 → 시스템 복잡도가 올라감

예를 들어, 만약 스케쥴러의 메모리가 부족하다면 고객은 잘못된 데이터(오르지 않는 좋아요 수)를 보게 될 것임

위의 아키텍처를 적용했을 때 따라오는 문제점

누른 좋아요가 곧바로 반영이 되는가?

클라이언트 캐싱으로 어느정도 해소할 수 있음

(브라우저 상에서 고객이 보는 즉시 카운트를 해주는 것)

정리

데이터의 성질, 병목 지점등을 파악하고, 적당한 기술들을 도입해 해소

더 공부해야 한다면?

• Repository Layer를 JPA로 리팩토링
• 팔로워가 100만명인 유저의 게시물 작성 성능 테스트
  • 비동기 큐를 통해 개선
  • Mixed Push / Pull Model
• 로그인 / 팔로우 승인, 취소 / 댓글 구현
• 파티셔닝

---

2023 KAKAO Tech Campus_BackEnd 필수 과정
DB(MySQL) 강의 정리 내용입니다.