현재 데이터베이스 선택의 문제점:
유저 관리와 출석 같은 도메인은 MySQL로 적절히 처리 가능하지만, 모의투자 특성상 사용자들은 서로간의 거래가 아닌, 가격을 설정하고, 이러한 가격이 맞춰지면 대량의 거래가 한번에 실행됩니다.
초당 2~5번 100개가 넘는 코인이 특정 가격에 도달했는지 MySQL 데이터베이스에서 지속적으로 확인하는 것은 성능이 크게 저하됩니다.
Redis와 Spring Batch를 솔루션으로 검토:
성능 문제를 완화시키기 위해 Redis와 Spring Batch를 솔루션으로 고려하였습니다. Redis에 데이터를 올린다면 빠르게 검색이 가능하지만, 거래가 실행되면 MySQL에 다시 저장해야 합니다.
결국 앞의 문제와 같이 상당한 양의 데이터를 처리해야 한다면, MySQL이 잠재적으로 단일 실패 지점(SPOF)이 돼버립니다.
기능을 다른 시스템에 나누기:
다른 시스템에서 기능을 운영하는 것(MSA)이 부하를 줄일 수 있을지도 모른다고 생각하여 Reactive Programming 서적을 보며 공부를 해봤지만 기능을 나누는 것은 본질적으로 MySQL의 성능을 향상시키지 않았습니다. 거래 데이터를 저장하는 것과 관련하여 MySQL을 스케일 업 ,아웃 하지 않는 한, 성능 향상의 여지가 없습니다.
프로젝트 실패한 이유.
현재 데이터베이스 선택의 문제점: 유저 관리와 출석 같은 도메인은 MySQL로 적절히 처리 가능하지만, 모의투자 특성상 사용자들은 서로간의 거래가 아닌, 가격을 설정하고, 이러한 가격이 맞춰지면 대량의 거래가 한번에 실행됩니다. 초당 2~5번 100개가 넘는 코인이 특정 가격에 도달했는지 MySQL 데이터베이스에서 지속적으로 확인하는 것은 성능이 크게 저하됩니다.
Redis와 Spring Batch를 솔루션으로 검토: 성능 문제를 완화시키기 위해 Redis와 Spring Batch를 솔루션으로 고려하였습니다. Redis에 데이터를 올린다면 빠르게 검색이 가능하지만, 거래가 실행되면 MySQL에 다시 저장해야 합니다. 결국 앞의 문제와 같이 상당한 양의 데이터를 처리해야 한다면, MySQL이 잠재적으로 단일 실패 지점(SPOF)이 돼버립니다.
기능을 다른 시스템에 나누기: 다른 시스템에서 기능을 운영하는 것(MSA)이 부하를 줄일 수 있을지도 모른다고 생각하여 Reactive Programming 서적을 보며 공부를 해봤지만 기능을 나누는 것은 본질적으로 MySQL의 성능을 향상시키지 않았습니다. 거래 데이터를 저장하는 것과 관련하여 MySQL을 스케일 업 ,아웃 하지 않는 한, 성능 향상의 여지가 없습니다.