많은 수의 insert 요청으로 인한 GCS 비용 문제GCS Consumer는 Kafka의 topic에서 메시지를 읽어오고, JSON 타입의 호가창 데이터를 GCS bucket에 저장하는 역할을 합니다.이러한 적재 과정에서 실시간성을 보장하기 위해, Kafka Consumer의 파라미터 설정을 fetch_max_wait_ms=0으로 하여 topic에 메시지가 있다면 바로 읽어오고 처리하는 방식으로 구현했었습니다.이는 GCS bucket에 최신의 데이터를 유지할 수 있다는 장점이 있지만, 초 당 많은 insert 요청이 발생하여 GCS 비용이 증가하는 문제가 발생했습니다. 실제로 데이터 파이프라인을 운영해본 결과, GCS 비용으로만 하루에 ₩150,000 ~ ₩200,000의 비용이 발생했습니다. 또한 b..

도입 배경현재 데이터 파이프라인에서 메시지 브로커로 Redis Stream을 사용하고 있으며, 이를 운영하며 다음과 같은 문제점이 있음을 확인했습니다. 늘어나는 메모리 부담Redis Stream는 기본적으로 데이터를 캐시 메모리에 저장합니다.데이터 파이프라인에서 3일치의 데이터를 저장하기 위해, ticker 하나당 1,500,000건을 Redis Stream에 저장하고 있으며, 6개 ticker의 데이터를 수집 했을 때 지속적으로 메모리 사용량이 증가하여 최대 4.5GiB를 사용함을 확인했습니다.이를 기준으로 ticker 하나당 3일치 데이터를 저장하기 위해서는 약 0.75GiB의 메모리가 필요함을 추정할 수 있습니다.현재 원화 마켓에서 거래 중인 코인은 155개입니다. 이를 모두 Redis Stream..

개요본 프로젝트는 암호화폐 거래소인 Upbit에서 제공하는 실시간 호가창 데이터를 추출하고 저장하기 위한 데이터 파이프라인 구축을 목표로 합니다.Upbit의 현재 거래 가능한 암호화폐의 종류는 수십개 이상이며, 호가창 데이터는 실시간으로 변동되는 특징을 가집니다. 이러한 데이터의 특성을 고려하여 모든 암호화폐의 호가창 데이터를 실시간으로 처리하고, 부하 분산이 가능한 스트림형 데이터 파이프라인을 설계하고 구현하고자 합니다. 프로젝트 목표실시간 데이터 적재호가창 데이터를 스트림형 데이터 파이프라인을 통해 실시간으로 수집 및 저장합니다.부하 분산모든 암호화폐에 대한 데이터를 안정적으로 처리하기 위해 부하 분산 메커니즘을 설계 및 검증합니다.확장 가능성 확보초기에는 Docker 환경에서 데이터 파이프라인을 구..