루비 데이터베이스는 고스펙 사양 DB라 하나의 테이블에만 문제가 있어도 전체 시스템 장애 발생
- PHP에서 자바로 이동(대용량 트래픽 대응 가능)
- 마이크로서비스 아키텍처. 리뷰, 주문, 결제를 분리하여 서비스 구현
- IDC에서 AWS로 이동하여 트래픽이 특정 시점에 몰려 생기는 문제를 해결
CQRS - 비즈니스 커맨드(Command. 주문)와 사용자 요청(Query. 가게정보 조회)이 분리되어 실행될 수 있도록.
- 조회 : 고성능 DB 이용. dynamoDB, mongoDB, redis, elesticsearch(광고리스팅, 검색)
- 커맨트 : 안정성 중시. 오로라DB 이용.
Querysql - querydsl을 사용하는 경우 exist를 내부적으로 count로 실행하는데 보통 exist는 발견 즉시 exit하지만 count>1은 전체를 스캔한다. 그러므로 1개 이상을 찾으려면 exist 방식이 더 효율적이므로 하나를 찾으면 exit하는 방식으로 sql.exist를 구현해줌.
zero-payload 방식 - 주문이 들어와서 이벤트를 보낼 때 전체 주문정보를 보내는 게 아니라 가게 id만 보냄. 그러면 id와 api를 이용해 최신의 정보를 받아온다. 그러면 테이블이 많아도 specific api를 호출해 최신 데이터로 갱신 가능.
비동기 non-blocking 시스템 - 대기 상황에서 다른 작업 수행 가능. 대기 상황에서 요청이 많아져도 적은 수의 스레드로 처리 가능.
무중단 마이그레이션 - 기존 DB와의 커넥션을 그대로 놔두고, 새 DB에 특정 시점을 기준으로 마이그레이션한 뒤 쌓이는 데이터를 동시 적재. 양쪽 데이터를 일치시키는 계속적인 validation 작업 필요. source db를 마스터로, 타겟db를 standby로 진행. 타겟db의 성능이 검증되면 타겟db를 마스터로 전환. 충분한 시간 동안 양쪽의 커넥션을 유지해 문제가 생길 경우를 대비.
Greedy algorithm - 지역적으로 optimal이지만 전역적으로 optimal이도록 조건을 세팅하여 최선의 라이더 매칭을 찾음.비용함수를 세워 비용을 최소화한다는 점에서 머신러닝, 딥러닝의 관점과 다르지 않다는 생각이 들었다.
DB 설계 시 각 테이블에는 최소한의 데이터만 보유하는 것(중복 데이터가 없도록), 최적으로 라이더를 배치하는 것 등 그동안 했던 고민들을 현업에서도 비슷하게 하고 있어서 재미있게 들었다.