구매입찰에 대해서 판매입찰 생성 시, 체결이 안 됨,,,?
문제
•
판매자가 판매입찰을 생성해둔 상태에서
◦
구매자가 즉시구매로 하지 않고, 구매입찰을 요청했을 때 주문체결이 안 됨
해결방안
•
프론트에서 구매입찰 요청 시, 자동으로 즉시구매 플로우로 넘어갈 수 있게끔 조치해야함
앞으로 남은 일정에 관련해서
문제
•
다 같이 모이는 시간대 결정
해결방안
•
지훈 : 언제든 ok
•
규빈님 : 13~19 커리어톤
•
규정님 : 저녁에 일정이 있는 일자 많음
•
재윤님 : 13~19 커리어톤
09시~12시
각자 맡고자 하는 요구사항에 관련해서
문제
•
각자 맡고자 하는 요구사항을 정해서 개발하기로 하자!
해결방안
•
재윤님 :
◦
Redis 캐싱을 사용한 데이터 캐싱
▪
캐싱 전략 구축
◦
+ 시간나면 Redis Streams 로 알림
•
지훈님 :
◦
마감에 따른 포인트 환급 배치
스프링 클라우드 펑션을 사용해보는 것도 고려해보기!
•
규빈님 :
◦
SOFT DELETE
◦
판매입찰(즉시구매) 체결
◦
구매입찰(즉시판매) 체결
•
규정님 :
◦
데드락에 대해서 비관적락을 사용한 성능 vs 분산락을 사용한 성능 비교해보기
Async 에 대한 Thread Pool 설정에 관해서
문제
•
@임지훈님께서 설정한 Config가 올바른지 확인해보자.
해결방안
•
더 공부가 필요하나,, 적합한 것 같음,,, !!
•
성민 튜터님의 추가답변이 필요함,, !!
음... 좀 만져봤는데 queue capacity를 조절하면서 optimal한 값을 찾을 수 있지 않을까 싶었으나 더 나은 방법을 별달리 찾기 어렵네요 ㅡ,.ㅡ;;
첨부한 스샷에 따르면 queue capacity만 조절한다고 해서 thread 개수가 늘어나진 않고, 새로운 스레드가 생성됨에 따른 응답속도 차이는 core pool size, max pool size를 조절하면서 테스트 해봤어야 맞는 듯 합니다~
제 랩탑에서 corePoolSize이 8로 계산되는데, call count 100만건으로 잡고 8일 때 대략 0.7초가 걸리는데 corePoolSize가 2~3일때는 0.65초정도 걸리네요. 큰 차이는 아니지만 corePoolSize를 조정해서는 성능 차이를 눈으로 확인 가능할 수 있긴 했습니다.
본 질문하고는 조금 벗어난 얘기지만, 위 케이스에서 비동기 서비스가 여러개 있다고 가정하고 개 중 하나의 서비스에서만 대용량 트래픽을 받는다고 예상된다면, 다른 서비스들의 queue capacity 개수를 줄여서 대용량 트래픽을 받는 서비스에게 한정된 자원에서의 더 많은 자원 할당을 해줌으로써 성능향상 기대를 할 수 있을 거 같네요
저도 이렇게까지 해본적이 없었어서 잘못된 내용이 있을지도 몰라요. 호기롭게 도전했는데 별달리 유의미한 결과를 도출해내지 못하겠네요 ㅜ.ㅜ 다른 의견 있으시면 편하게 남겨주세요!
마감기한이 지난 구매입찰에 대해서 포인트 미반환
문제
•
마감기한이 지난 구매입찰에 대해서 미반환 되고 있음
•
아래와 같이 변경되어야 함
문제상황
마감기한이 지난 구매입찰에 대해서
1.
구매자에게 포인트 환급
2.
마감기한이 지난 구매입찰 삭제
해결방안
•
지훈님께서 맡기로 함!
토큰데이터를 Redis 에 저장하면 확장성이 떨어지지는 않을까?
문제
•
토큰을 레디스에 저장하면 확장하기가 어렵지 않을까??
•
파티셔닝을 해야되나??
해결방안
•
accessToken : 0.2KB / refreshToken : 0.15KB
•
userId(key) : refreshToken(value) 만 저장하기에 100만명이 로그인을 했을 때, 0.2GB 정도로 저장됨
•
따라서 부하가 높지 않음
의문점
•
세션데이터가 Token데이터보다 용량이 적은데 굳이 Token데이터를 선택하는 이유?
◦
서버가 세션데이터를 hold하고 있어야하기 때문에
◦
NoSQL에 TTL을 통한 refreshToken 데이터를 저장함으로써 일정시간 이후 휘발하게끔 관리
CAP Theorem 에 따라서 Master-Slave 에 대한 대책안은,,,? (완료 시 )
문제
•
Master 가 죽어버렸을 떄, failover 지원에 대한 latency 가 1분 [AWS RDS 기준]
◦
서비스에 치명적이지 않을까??
◦
Aurora 스케일 업 하는 경우, 30초 이내로 해결 가능
◦
Aurora 는 너무 비싸고,,, 더 좋은 방법이 없을까??
•
Master 와 Slave 와의 connection 이 lost 되는 것에 대해 CA 를 지원하던 RDB 가 CA 를 지원할 수 없게 됨
◦
Master 와 Slave 와의 connection 이 lost 되는 것을 복구할 수 있기 위한 좋은 방법이 없을까?
해결방안
•
Master-Slave Latency 에 대해서는 스케일 아웃이 답인가,,,?
•
Galera Cluster
◦
Master : Slave = 1 : N 보다 Master : Slave = N : M 을 채택해보자!
◦
Galera Cluster
노드에 트랜젝션이 발생하고 COMMIT이 실행이되면, 디스크에 내용을 쓰기 전에 다른 노드로 복제를 요청하고 다른 노드에 복제 요청이 접수되었을때, 해당 노드의 디스크에 실제로 데이타를 쓰게 된다.
이러한 특성으로, 전체 노드에 데이타가 항상 일관성있게 저장되고, 모든 노드가 마스터 노드로 작동을 하며, 특정 노드가 장애가 나더라도 서비스에 크게 문제가 없다.(MySQL Replication의 경우 마스터 노드가 장애가 나면 슬레이브 노드중 하나를 마스터로 승격을 해야하는 등 다소 운영 프로세스가 갈레라에 비해서는 복잡하다.)
