불필요한 Delete 쿼리 → Soft Delete 로 리팩토링
문제
•
현재 불필요한 DELETE 처리가 수행되고 있음
•
불필요한 DELETE 처리를 SOFT DELETE로 리팩터링하기로 함
해결방안
시스템 내에서 DELETE가 나가는 상황들
•
구매입찰 취소요청
◦
구매입찰 데이터 자체를 삭제
•
판매입찰 취소요청
◦
판매입찰 데이터 자체를 삭제
•
즉시구매 요청
◦
판매입찰 조회, 주문 생성 => 이후 판매입찰 삭제
•
판매입찰 스케줄러
◦
기한을 지난 판매입찰 삭제
•
구매입찰 스케줄러
◦
기한을 지난 구매입찰 삭제
•
환급요청 처리
◦
환급 데이터 삭제
아래와 같이 변경하기로 함
•
엔티티에 삭제처리에 대한 flag 필드를 추가
•
삭제처리에 대해서 삭제처리 flag 필드를 체크하기로 함
◦
BaseEntity 확장/상속관계
•
조회 시, 삭제처리된 데이터들을 포함하지 않게끔 쿼리문을 변경
◦
변경해야하는 코드 스코프가 넓음
•
우선순위가 높은 것 같지 않으니, 가장 중요한 성능개선 처리 후 최대한 빨리 구현하자
서비스가 돌아가고 있는 중, Merge 와 Deploy는 어떻게?
문제
•
서비스가 실행되고 있어 Merge 와 Deploy가 제한적임
•
만약 서비스 전체를 변경할만큼의 스코프 변경이라면 어떻게 해주어야할까?
해결방안
•
서비스 전체를 변경할만큼의 스코프 변경이라면, 서비스 마감의 마지막에 적용하기로 함
•
merge는 바로바로 하되, deploy는 prometheus 를 붙이고 모니터링 세팅 완료한 후 deploy 처리!
우리 상황에 어떤 Caching 전략이 어울릴까?
문제
•
다량의 트래픽에 따른 성능을 개선하고자, 캐싱처리를 하고자 한다.
이 때, 다음과 같은 유의사항을 고려해야한다.
◦
어떤 비즈니스 요구사항이 가장 자주 참조되는가?
◦
그렇다면 해당 요구사항에 따라 캐싱 target data는 무엇으로 할 것인가?
◦
캐싱 보관 데이터의 만료 정책은 어떻게 할 것인가?
◦
데이터정합성(일관성), 즉 RDB와의 동기화은 어떻게 처리할 것인가?
◦
장애에는 어떻게 대처할 것인가?
◦
캐시 메모리는 얼마나 크게 잡을 것인가?
◦
데이터 방출 정책은 무엇인가?
•
조사한 전략 중 어떤 것을 선택할 것인가?
◦
읽기 전략
▪
Look Aside
▪
Read Through
◦
쓰기 전략
▪
Write Back
▪
Write Through
▪
Write Around
해결방안
•
다량의 트래픽에 따른 성능을 개선하고자, 캐싱처리를 하고자 한다.
이 때, 다음과 같은 유의사항을 고려해야한다.
◦
어떤 비즈니스 요구사항이 가장 자주 참조되는가?
▪
상품 데이터 조회 ⇒ 캐싱처리
•
상품 종류가 많지 않아서 애매모호함
▪
상품 이미지 조회 ⇒ Cloud Front 로 CDN 처리함
▪
최근 검색 기록 ⇒ 캐싱처리
▪
상품 랭킹 ⇒ 캐싱처리
•
지난 일주일 간 { 판매입찰 + 구매입찰 + 주문 } 전체건수량에 따른 랭킹
◦
그렇다면 해당 요구사항에 따라 캐싱 target data는 무엇으로 할 것인가?
▪
상품 데이터
•
상품명
•
상품브랜드
•
즉시구매가 (가장 낮은 판매희망가)
•
즉시판매가 (가장 높은 구매희망가)
•
전체 체결거래가
•
전체 판매입찰가
•
전체 구매입찰가
▪
최근 검색 기록
•
로그인한 유저의 검색기록
▪
상품 랭킹
•
전체 상품에 대해, 지난 일주일 간 { 판매입찰 + 구매입찰 + 주문 } 전체건수량에 따른 랭킹
◦
캐싱 보관 데이터의 만료 정책은 어떻게 할 것인가?
▪
TTL
▪
어느 정도로 잡으면 좋을지 가늠이 잘 안 됨
•
일단 CloudFront 를 따라해보자
•
최소 TTL은 60초, 기본 TTL은 300초로 , 최대 TTL은 3600초
◦
데이터정합성(일관성), 즉 RDB와의 동기화은 어떻게 처리할 것인가?
▪
조사한 전략 중 선택할 예정
◦
장애에는 어떻게 대처할 것인가?
▪
캐시 서버를 한 대만 두면 SPOF가 발생할 가능성이 있다
▪
최소 3개의 분산서버를 사용
•
1개의 마스터 노드와, 1개 이상의 복제본(Replica)를 두고, 각 노드에도 각각 센티널을 두어 자동 페일오버 처리
◦
캐시 메모리는 얼마나 크게 잡을 것인가?
▪
메모리가 너무 작으면 액세스 패턴에 따라 데이터가 밀려나버려 캐시 성능이 떨어진다.
▪
규모에 따라 상이함
•
소규모 : 100MB ~ 1GB
•
중규모 : 1GB ~ 10GB
•
대규모 : 100GB ~
▪
우리의 상황상 t3.small 정도의 메모리가 적합하다고 판단했음
•
t3.small 1.37 GB
◦
데이터 방출 정책은 무엇인가?
▪
Redis 방출 정책은 다음과 같음
•
No Eviction
•
LRU
•
LFU
•
Random Eviction
•
TTL
▪
이 중 어떤 걸 쓸까?
•
상품 데이터 : No Eviction이 적합
◦
데이터 보존용으로 처리하기 때문
•
최근 검색 기록 : LRU 적합
◦
접속한지 오래된 사용자의 검색기록을 삭제하면 적합하게 처리할 수 있음
•
상품 랭킹 : LFU 적합
◦
랭킹 : 지난 일주일 간 { 판매입찰가 + 구매입찰가 + 주문건수량 } 합
◦
key : 1위 ~ 10위 ⇒ value : 상품
◦
스케줄링 vs 조회할 때 연산 ( 쿼리,스레드 낭비 )
▪
스케줄링에 대해서 검증처리해주어야함
•
로직 스케줄링
스케줄링•
입찰기한이 지나면 데이터 삭제 스케줄링
◦
안 돌아버리면??
▪
⇒ 입찰건 조회 후 주문 처리 비즈니스에 악영향
▪
“주문처리 비즈니스 내에서 입찰건 조회 시, 마감기한이 기난 입찰을 배제하는 검증 로직이 필요하다”
▪
현업에서 스케줄러 안 돌면 ⇒ 실제 사람이 달려가서 쿼리 날려줌
▪
스케줄링
•
관리 허들 UP
•
스케줄링 인스턴스 분리해야함
▪
조회마다 연산
•
로그 테이블을 따로 만들어서 COUNT 쿼리로 쳐버리면 뚝딱
•
초기 요청에 대한 핸들링은 해야하지만
•
TTL에 따른 캐싱 처리
◦
방출 정책 : TTL 적합
◦
가장 조회 빈도수가 적은 상품의 랭킹을 방출하기
•
No Eviction X
•
Random Eviction X
•
조사한 전략 중 어떤 것을 선택할 것인가?
◦
읽기 전략
▪
Look Aside
▪
Read Through
◦
쓰기 전략
▪
Write Back
▪
Write Through
▪
Write Around
앞으로 최종 발표까지 할만한 컨텐츠
문제
•
재윤님이 프론트만, 규빈님이 인프라만 담당하느라 백엔드 부분에 참여를 하지 못함
해결방안
•
알림 기능을 재윤님 및 규빈님이 담당하여 개발하기로 함. 아직 기획 및 설계는 정하지 않음.
•
규정님은 테스트 코드를 작성하여 자코코 커버리지 비율 높이기.
•
지훈님은 현재 자리 비운 상태라 이후 논의를 하기로 함.
내일 무슨 주제로 피드백을 요청드릴까?
문제
•
제곧내 ㅎㅎ
