안녕하세요, 오늘은 MySQL 에서 겪은 Next-Key Lock 문제를 어떻게 파악했고, 해결했는지 설명해드리려 합니다. 이제 어떻게 문제를 분석하고 해결했는지 시작하겠습니다환경 항목값예상 앱 사용자5000명예상 갱신 API 피크 요청100건서버AWS EC2 t2.xlarge서버 스펙4 vCPU, 16 GiB RAMDBMySQL 8.0트랜잭션 격리 수준REPEATABLE READ커넥션 풀HikariCP 10 테스트게임 갱신 API를 구현한 뒤, 부하테스트를 진행했습니다.예상 사용자를 5000명으로 설정했고, 그 사용자들이 게임을 한다고 가정했을 때 100건의 갱신 요청이 피크일 것이라고 추측했습니다.테스트 데이터 및 시나리오 테스트 데이터는 다음처럼 구성했습니다. fixture구성회원서로 다른 회원..

(글을 읽으시며 잘못된 부분이나 아쉬운 부분이 있다면 댓글 부탁드립니다!!) 환경: AWS T2.micro메모리: 512MB목표: 1분/5분/30분 캔들, 심볼(종목) 100개 확장 고려사용자: 100명 예상tps: 100개 종목 x 한 종목당 100tps = 10,000 tps 안녕하세요 오늘은 Tick 데이터 처리 과정에서의 병목 지점중 한 부분인 Redis I/O 문제를 해결한 내용에 대해 이야기 해보려고 합니다. 일단 설명드리기에 앞서, Tick 데이터 데이터 흐름, 병목 지점 분석에 관한 자세한 부분은 이전 글을 참고해주시면 감사하겠습니다!데이터 흐름과 Redis I/O 병목 지점그래도 다시 간단히 배경 설명을 하며 시작해보겠습니다. 데이터 흐름현재 데이터 흐름은 다음과 같습니다. 1. 외부 A..

(글을 읽으시며 잘못된 부분이나 아쉬운 부분이 있다면 댓글 부탁드립니다!!) 환경: AWS T2.micro메모리: 512MB목표: 1분/5분/30분 캔들, 심볼(종목) 100개 확장 고려사용자: 100명 예상 안녕하세요 오늘은 Tick 데이터 처리 과정에서의 병목 지점 분석과 병목 지점중 한 부분인 수많은 객체 생성 문제를 해결한 내용에 대해 이야기 해보려고 합니다. 일단 설명드리기에 앞서, Tick 데이터 데이터 흐름을 간단히 소개드리겠습니다. 흐름은 다음과 같습니다.데이터 파이프라인 흐름(API - Collector - Consumer)외부 API - Collector 모듈 - Consumer 모듈로 이어지는 흐름을 간단하게 나타내봤습니다. 가장 먼저, Collector 모듈이 외부 API 에서 T..

환경: AWS T2.micro메모리: 512MB목표: 1분/5분/30분 캔들, 심볼(종목) 100개 확장 고려사용자: 100명 예상 안녕하세요 오늘은 캐시를 이용해 차트 조회 속도를 높이는 과정에 대해서 설명하려합니다. 우선, 차트 조회 API가 어떻게 동작하는지 설명드리겠습니다.차트 조회 API 동작 방식그림과 같이 Consumer 모듈이 (수집 과정)현재 진행중인 캔들은 Redis에 저장진행이 끝난 캔들은 DB에 저장이후 차트 조회 API가 호출되면진행중인 캔들을 Redis에서 조회마감된 캔들을 DB에서 조회두 데이터를 합쳐서 -> 응답하는 구조로 되어있습니다.쉽게 말하면 DB 에서 마감된 캔들 데이터 + Redis 에서 현재 진행중인 캔들 데이터를 합쳐 반환하게 됩니다. 그렇다면 현재 차트 조회..

(글을 읽으시며 잘못된 부분이나 아쉬운 부분이 있다면 댓글 부탁드립니다!!) 환경: AWS T2.micro메모리: 512MBDB: HikariCP (default)목표: 1분/5분/30분 캔들, 심볼(종목) 100개 확장 고려사용자: 100명 예상 안녕하세요 오늘은 실시간성을 위해 마감되는 캔들을 어떻게 저장해야 할까에 대해 이야기 해보려고 합니다. 제가 어떤 방식으로 캔들을 저장하고 있었는지 소개하기에 앞서, 캔들이 저장되는 흐름에 대해 먼저 말씀드리려 합니다. 흐름은 다음과 같습니다. 캔들 데이터 저장 흐름Collector 모듈이 외부 API 를 통해 Tick 데이터를 받은 후, 그림과 같은 MessageQueue에 데이터를 집어넣습니다.Consumer 모듈이 MessageQueue에서 데이터를 ..

이전 블로그 글인 Data Flow 설계하기: Latency와 Consistency를 고려해보자에서 이어지는 포스팅입니다. 오늘은 Data Flow 재설계를 하게된 배경과 왜 재설계를 하게 되었는지에 대해 자세히 설명해보고자 합니다! 그럼 지금부터 시작합니다~~ [1] 이전 아키텍처(Dual-Path)의 회고: 어떻게 정합성을 맞추려 했는가? 이전 포스팅에서 다루었던 코인플로우의 초기 아키텍처는 Dual-Path Architecture였습니다.금융 데이터의 생명인 실시간성과 데이터 정합성 모두 잡기 위해, 시스템을 속도 전용 파이프라인(Fast-Path)과 정확도 전용 파이프라인(Slow-Path)으로 완전히 분리했던 구조입니다. 이 구조에서 데이터 정합성을 맞추기 위해 사용했던 핵심 전략 세 가지는..

안녕하세요, 오늘은 거래량 계산 방법에 대해 소개하고자 합니다! CoinFlow에서 가장 많이 수신되고, 가장 빈번하게 계산되는 데이터는 체결 틱(Tick)의 거래량과 가격입니다.보통 많은 사람들이 1주를 사면 거래량도 1개 증가하는 것으로 알고 계시지만, 사실 0.xx 단위로도 거래가 될 수 있습니다.그렇기에 매 틱마다 들어오는 거래량 소수점 데이터(예: 0.00123456 BTC)를 1분 봉, 5분 봉으로 쉴 새 없이 더해야 합니다. 물론 아직 초당 수만 건 정도의 Tick 데이터가 수신되지는 않습니다. 하지만 추후에 종목을 늘린다면 초당 수만 건의 거래량 데이터는 충분히 처리해야 합니다. 이를 해결하기 위해 어떤 방식들이 있었고, 최종적으로 제가 적용한 방식이 무엇이었는지 소개해드리고자 합니다. ..

실시간 차트 서비스에서 가장 중요한 것은 무엇일까요 속도? 정확성? 이 질문에서 시작된 고민이 Dual-Path Architecture라는 결과물로 이어지기까지의 과정을 기록합니다.안녕하세요 오늘은 CoinFlow 서비스를 구축하기 위해 Data Flow 를 어떻게 설계했는지 설명해드리고자 합니다. 그럼 바로 시작하겠습니다! 초기 설계처음에는 데이터 정합성과 정확성을 최우선으로 생각하여, 모든 데이터를 DB에 먼저 저장하고, 그 다음에 보여주는 구조로 설계했습니다. 금융 데이터인 만큼 데이터의 유실이나 오차를 절대 허용해서는 안 된다는 생각에, RDBMS를 Single Source of Truth 로 삼고자 했습니다. 데이터 흐름은 매우 직관적이었습니다.Collector: 외부 거래소(Binance)에서..

안녕하세요, 오랜만입니다.오늘은 새로운 프로젝트를 소개해드리려 합니다. 바로 CoinFlow 입니다!!비트코인 차트만을 제공하는 서비스입니다. 프로젝트를 시작하게 된 배경은 다음과 같습니다.제 인생에서 백엔드 첫 프로젝트가 [모의 주식 투자 서비스] 이었는데, ohlc 캔들, tick 데이터 등등.. 모든 데이터를 api 로 제공했습니다. 솔직히 조금 아쉬웠습니다. 문제 해결을 위한 과정도 있었지만, 뭔가 데이터 서빙만 하는 느낌..?? 을 지울 수 없더라고요 그래서 지금 프로젝트를 시작하게 되었고, 오로지 Tick 데이터만으로 모든 기능을 제공하는 서비스를 구축하려고 합니다. 앞으로 CoinFlow 를 구축하며 생기는 문제, 개선사항 등 여러 소식들을 블로그로 전해보겠습니다! https://githu..

오늘은 모각밥 서비스에서 채팅방을 어떻게 구현했고, 어떤 방식을 통해 개선까지 했는지 설명드리고자 합니다. 그럼 지금부터 시작하겠습니다!채팅방 구현 방식저는 웹소켓 + STOMP 를 사용해 채팅방을 구현하였습니다. 처음에는 서비스 사용자가 많지 않을 것 같아, HTTP 기반의 Polling 방식을 이용해 주기적으로 서버에 메시지를 요청하는 방식을 고려했습니다.하지만 클라이언트가 일정 간격으로 계속 요청을 보내야 하므로 불필요한 트래픽이 많아지고, 지연 시간이 발생하며, 실시간성이 떨어지는 문제가 있었습니다. 또한, 사용자 수가 늘어나면 서버 부하가 기하급수적으로 증가할 수 있다는 점에서 한계를 느꼈습니다. 이후, 웹소켓을 이용하여 실시간 채팅방을 구현하고자 하였고, WebSocket만으로는 채팅방 단위의..