11.24(수) 데일리 스크럼 & 회의록

박세환

어제 한일

• 차트 데이터 생성 스케줄작업
• datetype이랑 timestamp 혼용되는 부분 통일
• API URL 논리적 오류 수정
• develop 병합 후 발생한 오류 수정

오늘 할일

• auctioneer 최적화

이슈

• 민준님 ncloud 인스턴스에 접속할 권한을 주실 수 있나요? 아뇨
• 노션 오늘 자정까지 최종 수정

권구상

어제 한일

• 트레이딩 봇
• 옥셔니아 체결 방식 변경
• 베타적 락 충돌 원인 분석

오늘 할일

• 쿼리 최적화

이슈

김재현

어제 한일

• 차트해야되는데 설계문제 때문에 차트 못함

오늘 할일

• 차트해야되는데

이슈

• 왜 벌써 아침이죠?

장민준

어제 한일

• 차트 가로선, 교차선

오늘 할일

• API 연결
• 상하좌우 드래그 인터렉션

이슈

• 차트 데이터
  • API : api/stock/log (code, type, start, end)
    • start gte, end lt
  • 실시간 데이터 : 실시간 체결현황 가져와서 쓰기

11.24 회의록

show status where variable_name like 'table_locks%'

• Auctioneer (Chart, User, UserStock) / Back (User, UserStock)

1번주제

• 김재현 : 세환님이 슬랙에 올린 내용처럼 종목별로 주문 테이블을 가지게 하는게 어떨까요?

• 박세환 : 주문이 쌓이느라 인덱스를 걸기에도 어렵고 하지만 적합한 주문을 찾기위해서는 범위검색이 필요해서 종목별로 테이블을 나눠서 검색범위를 축소하는 것은 좋은 것 같다.

2번주제

어제 테스트 하던 상황이 구상님컴 -> ncloud DB 왔다갔다하는 과정에서 네트워크지연이 있었지 않았을까 하는 생각이 들었습니다 근데 auctioneer랑 DB는 가까운 위치에 있을거니깐 DB서버와 가까운 상태에서 트랜잭션에 걸리는 시간을 조사해보고 싶습니다.

->[구상님컴 -> ncloud DB] 주문 넣는 트랜잭션 약 4060ms => 트랜잭션 내부에 디비접근하는 부분 콘솔타임이 궁금해요 약 240380ms

3번주제

우리의 서비스로직이 pessimistic_lock이 필요할까요??

프로세스

• 매수 주문
  1. [user] update balance
  2. [order] insert order
• 매수 주문 취소
  1. [user] update balance
  2. [order] delete order
• 매도 주문
  1. [user_stock] update amount
  2. [order] insert order
• 매도 주문 취소
  1. [user_stock] update amount
  2. [order] delete order
• 주문 체결
  1. [order] select 매수주문, 매도주문
  2. [user] update 매도자 balance
  3. [user_stock] update 매수자 amount
  4. [stock] update 종목 현재가 수정
  5. [chart] update 데이터 수정
  6. [order] update or delete 매수주문, 매도주문
• 현금 입금
  1. [user] update
• 현금 입금
  1. [user] update
• 종목 즐겨찾기 추가
  1. [user_favorite] insert
• 종목 즐겨찾기 제거
  1. [user_favorite] delete

주문 체결 도중에 다른 종목 주문 체결이 돌아가서 유저테이블의 현금이 불일치할 경우??

• JK 사서 10000원이 9000이 되는 과정에서 IVY사서 10000원이 9000원이 되고 결국 두개 다 샀는데 9000원이 남는 경우
  • USER의 BALANCE는 SELECT FOR UPDATE로 블락한다.

주문 체결 도중에 주문이 최소되서 유저 보유수량은 돌아오고 주문은 정상적으로 처리 될 경우?

• JK 팔아서 100개가 0개가 되는 과정에서 주문을 취소해서 보유수량이 0개되고 잔액은 늘었는데 매도 주문이 체결되어서 잔액이 두배로 느는 경우
  • USER_STOCK의 AMOUNT는 SELECT FOR UPDATE로 블락한다.

매수 주문 접수 도중에 현금 인출이 발생할 경우?

• JK 사는데 1000원 빠져야 되는데 그 동시에 현금 인출이 발생하면 사용자의 현금이 1000원이었다는 것을 보고 둘다 처리되는 경우

테이블 별 잠금 정리

테이블	충돌이 발생하는 경우	잠금	비고
종목	- 한 종목에 대한 동시 체결 (SELECT -> UPDATE)	불필요	종목별로 거래체결이 하나만 동작하도록 애플리케이션레벨에서 제어
차트	- 한 종목에 대한 동시 체결 (SELECT -> UPDATE)	불필요	종목별로 거래체결이 하나만 동작하도록 애플리케이션레벨에서 제어
사용자	- 수 많은 상황	비관적 잠금
보유종목	- 주문 요청 (UPDATE) - 주문 취소 (DELETE) - 주문 체결 (SELECT -> UPDATE or DELETE)	낙관적 잠금	동시 체결이 있어도, 알아서 한쪽이 롤백하므로 문제는 없음
주문	- 주문 취소 (DELETE) - 주문 체결 (SELECT -> UPDATE or DELETE)	낙관적 잠금	동시 체결이 있어도, 알아서 한쪽이 롤백하므로 문제는 없음

전제조건

1. 1개 종목에 대해, 체결 프로세스가 동시에 2개 동작하지 않아야 함 - 다른 종목은 동시에 처리가능
2. FULL SCAN에 의한 TABLE LOCK이 없도록 해야함 - 대안: 조건 검색 (without LOCK) -> PK를 통한 조회 (with LOCK) - 낙관적 잠금은 FULL SCAN 해도 상관없지 않을까? (조사 필요) - 쿼리에 인덱스가 적용된 컬럼이 포함되지 않았을 경우 TABLE LOCK이 걸림. 출처: https://offbyone.tistory.com/225 [쉬고 싶은 개발자]

• 낙관적 잠금(Optimistic Lock)은 실제로 DB에 락이 걸리는것이 아님
  • 낙관적 잠금은 애플리케이션레벨에서 버전 컬럼으로 검증하고, DEADLOCK을 유발하지 않음
  • 테이블 중 실질적인 Lock은 사용자에게만 걸리므로, 순서에 따른 DEADLOCK도 해결됨
  • 레퍼런스
  • TypeORM

---

통계 자료 (새 탭으로 열어서 봐주세요)

속도를 더 빠르게 한 경우