이번에 진행하고 있는 모의 주식 투자 프로젝트에서 influx DB 도입을 결정했다.
모의 주식 투자인 만큼 실시간 주식 가격을 받아와야했고, 과거의 주식 가격을 그래프로 보여줘야했다.
이러한 방식의 데이터 저장을 하기 위해서는 초 단위로 변화하는 주식의 가격을 모두 저장해야했고, 이렇게 하면
수십 수백가지가 되는 주식 수만큼의 쿼리가 초단위로 RDB에 날라가게 된다.
그럼 주식의 가짓수가 300가지라고 했을 때, 1분동안 서비스가 실행된다면 300 * 60 으로 총 18,000개의 쿼리가 발생한다.
이는 매우 비효율적일 것이라고 생각되었다.
그래서 어떻게 하면 시간을 기준으로 변화하는 데이터를 효율적으로 저장할 수 있을지 고민을 하며, 방법을 찾던중
Influx DB라는 시계열 DB를 발견했다.
Influx DB는 시간에 따른 데이터들을 처리하기 위해 나온 TSDB(시계열 DB) 중 가장 많이 사용되고, 가장 유명한 DB이다.
이는 일정 주기마다 데이터를 처리하여 저장하는 기능과 일정 주기마다 데이터를 삭제하는 기능, 이 2가지 기능이 핵심이며, DB 인덱스가 시간에 따라 축적된 데이터들에 대해 최적화가 되어 있기 떄문에 매우 빠른 성능을 보장한다.
따라서 나는 Influx DB를 내 프로젝트에 도입하기로 결정했으나, 아직 2가지 문제점이 남아있다.
1. 데이터를 어느 주기로 저장할 것인가?
2. 데이터를 어느 주기로 삭제할 것인가?
이 2가지 문제점들을 해결해야했고, 나는 이 두가지 고민에 대해 ADR을 작성해보고자 한다.
혹여나 ADR이 뭔지 모르는 사람을 위해 간단하게 설명하자면,
Architecture Decision Record 의 약어로 소프트웨어를 구축할 때 발생하는 의사결정에 대해서 어떤 상황에서 어떤 대안들이 있고, 어떻게 해결했으며, 그 결과가 어땠는지 기록하는 것을 의미한다.
ADR InfluxDB 데이터 저장 주기
Status
- Proposed
Context
- 주식 가격 기록에 대한 기능을 처리할 때, InfluxDB를 도입하기로 하였는데,
이때 어느 정도의 주기로 데이터를 저장해야할지 결정해야함.
후보 1 : 길게 가져간다 ( 10초 )
- 장점
- 서버의 부하가 비교적 감소한다
- DB 저장 비용이 감소한다
- 단점
- 주요 가격 변동을 놓칠 수 있다.
- 실시간 모니터링이 어렵다
후보 2 : 적당히 가져간다 ( 5초 )
- 장점
- 균형이 좋다, 주기가 길지 않고 변동성도 어느정도 받아낼 수 있다.
- 주요 가격 변동을 모두 놓치지는 않는다
- 단점
- DB의 저장 비용이나 서버의 부하가 10초보다는 커진다
- 성능이 너무 중간 수준이다.
후보 3 : 짧게 가져간다 ( 1초 )
- 장점
- 실시간 모니터링 및 세밀한 제어가 가능하다
- 모든 변동 기록을 빠짐없이 기록할 수 있다.
- 단점
- 서버의 부하와 DB 저장 비용이 높다
- 저장되는 데이터들을 관리하는데 추가적인 엔지니어링이 필요하다
Decision
1초단위로 저장하는 방법을 선택했다
주식 프로젝트의 특성상, 연도별, 월별, 주별, 일별, 시간별, 5분, 1분, 실시간등 모든 가격 변동 그래프를 보여주는 것이 일반적이다.
이 모든 요구사항을 충족시키기 위해 실시간 그래프는 짧게 가져가는 방식을 사용하고, 나머지 데이터들은 Batch를 사용하여 저장된 실시간 데이터를 계산하여 RDB에 저장하는 방법이 가장 이상적인 방법이라고 생각되었다.
또한 내 프로젝트는 실시간 주식 가격을 받아오는 외부 API의 한계로 인해 50개의 주식에 대해서만 실시간 가격변동을 나타낼 수 있고, 50개라는 수의 주식은 서버나 DB에 부하가 그렇게 크지 않을 것으로 예상이 된다.
Consequences
이번 결정으로 인해 사용자들은 한정된 주식에 한해 실시간으로 모든 가격의 변동을 모니터링 할 수 있고, 다른 기간별 가격 변동 또한 함께 확인할 수 있게 된다.
ADR InfluxDB 데이터 삭제 주기
Status
- Proposed
Context
- 주식의 저장을 1초단위로 했을 때, 삭제의 주기는 어느정도로 잡아야 할지 결정해야함
삭제해야할 데이터는 1초 단의로 저장되는 하루동안의 데이터를 타겟으로 한다.
저장되는 데이터의 양은 약 50 (프로젝트의 주식 수) * 6.5(주식장 시간 09:00 ~ 15:30) * 3600 (1시간 초 단위) = 1,170,000
로 일당 1,170,000개의 데이터가 influxDB에 저장되어야 한다.
후보 1 : 하루
- 장점
- 데이터의 삭제가 하루 단위로 이뤄지기 때문에 DB 저장 비용이 감소한다.
- 단점
- 백업이 어려울 수 있다.
후보 2 : 이틀
- 장점
- 백업용으로 하루를 더 유지하기 때문에, 백업이 용이하다
- 단점
- influxDB에 총 2,340,000개의 데이터를 유지하며 저장하고 있어야 한다.
Decision
삭제 주기는 하루로 결정했다.
주식 가격 변동에 문제가 생긴다면, 하루 백업 데이터로는 다른 모든 주기별 가격 변동 데이터 (연도별, 월별, 주간별....etc)들을 모두 백업하기는 어렵다, 이 모든것에 대한 백업을 준비하기 위해서는 하루치의 백업 데이터로는 불가능하다.
또한 주식 가격에 대한 백업 데이터는 다른 주식 api를 사용해서도 가져올 수 있기 때문에 큰 문제가 된다고는 생각하지 않는다.
따라서 백업 데이터가 유효하려면 더 많은 데이터를 저장해야하고, 그 이하는 의미가 없을 가능성이 있기 때문에 굳이 하루치 백업데이터를 남겨두는 것이 아닌 일별 삭제가 가장 적합하다고 판단되었다.
Consequences
-
처음으로 influxDB 시계열 데이터베이스를 사용해보는 경험이고, 처음으로 ADR이라는 걸 써보았다.
처음 써보는 거라 이렇게 쓰는게 맞는지 의문이 들긴 하지만, 나름 적을건 다 적은 것 같다.
이 ADR을 토대로 프로젝트 개발을 해보고, 그에 대한 회고까지 다시 작성해봐야겠다.
'백엔드 멘토링' 카테고리의 다른 글
[회고록] Stock-simulation 프로젝트 API 완성도 기록지 (1) | 2024.12.20 |
---|---|
[회고록] Triple Clone 프로젝트 API 완성도 기록지 (3) | 2024.09.28 |
주식 투자 프로젝트 실시간 Real time DB 적용기 (9) | 2024.09.06 |
계좌 잔액 업데이트 동시성 문제 해결 과정 (5) | 2024.09.03 |
객체지향적 Refactoring 과정의 기록 (1) | 2024.07.11 |