목표
작가는 작품을 발행하고, 독자는 작품을 읽을 수 있다.
유즈케이스
- 작가는 작품을 발행한다.
- 독자는 작품을 읽을 수 있다.
- 미리보기 상태의 작품은 유료 결제를 통해 작품을 조회할 수 있다.
다이어그램
유즈케이스 다이어그램
도메인 다이어그램
작품 상태 다이어그램
유즈케이스별 고려 사항
전제 조건 (국내 기준)
- 국내 MAU 2400만
- 빈도: 주 4.6일 / 20% 이용자
- 일반 트래픽: 피크 트래픽 = 1: 5
- 피크트래픽 시간: 출근 시간(8 ~ 9), 퇴근 시간 (18 ~ 19), 수면 전 시간 (23 ~ 24)
- 초당 API 트래픽 (애플리케이션 서버)
- 평균 : 피크 = 1.6k : 8k
- 초당 이미지 트래픽 (cdn, 회당 20컷 정도로 가정)
- 평균: 피크 = 32k : 160k
2-a. 예약 발행
- 작가들은 미리 작품 작업을 끝낸 후 예약 시스템에 업로드한다.
- 특정 요일에 맞게 일괄적으로 작품들을 업로드한다.
5. 프리뷰 상태면 쿠키 차감
- 초당 API 트래픽의 피크 시간 8k를 고려한다.
- 23 ~ 24시엔 미리보기가 업데이트되므로 초당 8k의 요청이 결제 서버로도 흘러갈 수 있다.
- 쿠키를 이용한 미리보기 결제는 20%라고 가정 = 1.6k
결제 서버에 대량의 쿠키 구매 요청이 들어온다면( = 작품 서비스에 대량의 쿠키 차감 요청)?
- 이용자마다 각자의 결제사는 다르므로 종단점인 결제사 요청은 부하 분산된다.
- 다만, 중간 서비스인 결제 서비스는 모든 요청이 몰리는 구간이므로 스케일 아웃, 스케일 업을 고려해야한다.
- 스케일 업 상한 스펙을 정의한다. (메모리 2gb, heap 1.6gb, 스레드 200개 (200mb))
- 단일 인스턴스의 cpu 사용률이 80%에 도달하면, 스케일 아웃으로 인스턴스 갯수를 늘린다.
- 단, 결제 데이터는 자사에서 관리하는 DB에 적재되므로 요청을 감당해야 한다.
- DB cpu 사용률이 70%에 도달하면, 쿼리 개선 혹은 DB 스케일 업을 고려한다.
- 쓰기 요청으므로 master db로 흘러가게 된다. 따라서 외부 결제사와의 트랜잭션 경계를 분리해야한다.
- 결제 API
-
- 결제 DB 커넥션 획득 ~ 커밋 ~ 반납
-
- 외부 결제사 요청 성공
- 요청이 실패한다면 결제 DB에 취소 요청
- 만약 순서를 반대로 한다면, 1. 결제사 요청 2. 결제 DB 실패할 경우 외부 결제사에서 보내는 알림에 대한 핸들링이 불가
-
- 결제 API
- 전제 조건 요청량을 본다면 피크 시간 대엔 1.6k이므로 최소 8대 필요
미리보기 시 쿠키가 없다면 트랜잭션의 경계는?
- ux를 2단계로 나눈다.
-
- 미리보기 시 쿠키가 없다면, 쿠키를 결제하도록 유도한다.
- 사용자는 쿠키 구매 트랜잭션이 종료된다. 이 쿠키를 어디서 사용할지는 사용자가 선택한다.
-
- 1에서 구매한 쿠키를 미리보기에 사용한다.
- 작품 서비스는 사용자와 연결된 쿠키를 차감하는 API를 호출한다.
6. 읽기 요청
- DB에서 파일 key를 조회하여 CDN_DOMAIN/key 형태로 응답한다.
- 작품 서비스는 모든 요청이 몰리는 구간이므로 스케일 아웃, 스케일 업을 고려해야한다.
- 스케일 업 상한 스펙을 정의한다. (메모리 4gb, heap 3.2gb, 스레드 400개 (400mb))
- 단일 인스턴스의 cpu 사용률이 80%에 도달하면, 스케일 아웃으로 인스턴스 갯수를 늘린다.
- 전제 조건 요청량을 본다면 피크 시간 대엔 8k이므로 최소 20대 필요
7. 전달받은 경로로 조회
작품 공개 후 캐시 미스 문제
- 작품을 업로드한 직후 cdn에는 아직 캐싱이 되어있지 않은 상황이다.
- 때문에 작품을 공개로 돌리기 전에 미리 여러 ip 대역으로 조회 요청을 수행하여 비슷한 대역망의 cdn 엣지 서버들이 작품 캐시를 워밍업한다.