실시간 시장 데이터를 위한 서버리스 파이프라인 만들기

* 본 아티클의 원문은 2021년 4월 8일 Google Cloud 블로그(영문)에 게재되었습니다.  

편집자 주: 이 게시물은 Google Cloud에서 시장 데이터를 사용하는 방법에 관한 특별 시리즈 2부입니다. Google이 서버리스 구성요소를 이용하여 유연한 데이터 수집 파이프라인을 구축한 방법을 중점적으로 소개합니다. 클라우드의 실시간 시장 데이터 시각화에 관한 첫 번째 게시물을 확인하세요.

자본 시장 기업은 방대한 실시간 데이터 세트에서 유용한 정보를 빠르게 추출해야 합니다. 기업의 시장 데이터 파이프라인에서는 최종 사용자의 데이터 액세스 요구사항을 가장 중요한 설계 조건으로 고려해야 하지만 유연하지 못한 배포 메커니즘과 분석 도구가 이 목표의 걸림돌로 작용하는 경우가 많습니다. 서버리스 데이터 서비스는 운영에 거의 지장을 주지 않으면서 다양한 기능을 갖춘 새 도구를 도입할 수 있어 이러한 문제를 피할 수 있습니다. 즉, 하나의 데이터 파이프라인으로 실시간 머신러닝 모델 학습, 과거 데이터 분석 등 각기 다른 사용자 목표를 손쉽게 지원할 수 있습니다. 

서버리스 데이터 파이프라인을 이용하는 자본 시장 기업은 인프라가 아닌 유용한 정보를 얻는 데 집중하고 빠르게 변화하는 업계에서 앞서갈 수 있습니다. 이 게시물에서는 CME Group의 Smart Stream 주문장 상단(ToB) JSON 피드를 통해 실시간 데이터를 수집하기 위한 권장사항을 설명합니다. 참조 아키텍처는 저장 및 전송 옵션을 선택할 때 데이터 사용 패턴과 스키마를 고려합니다. 또한 Cloud Functions에 비즈니스 로직을 캡슐화하여 개발 속도를 높이고 운영상의 복잡함을 줄여줍니다. 이러한 데이터 사용 패턴과 설계는 다양한 사용 사례에 적용할 수 있습니다.

그림 1은 수집 파이프라인의 참조 아키텍처입니다.

실시간 데이터 수집을 설정하는 방법

여기서 사용한 실시간 데이터 소스는 Google Cloud에서 이용 가능한 CME Group의 Smart Stream 서비스입니다. 데이터 출처는 CME Globex 거래 플랫폼이며 UDP를 통해 실행되는 멀티캐스트 스트림을 사용합니다. 상품 가격 데이터가 상호 연결을 통해 은 또는 농축 오렌지 주스 선물과 같은 단일 제품에 각각 해당하는 여러 Pub/Sub 주제로 전달됩니다.

Pub/Sub는 서버리스이고 다른 Google Cloud 서비스와 긴밀하게 통합되어 있습니다. Google에서 제공하는 완전 관리형 서비스이므로 확장, 계획, 안전성과 관련된 사용자의 많은 업무 부담이 줄어듭니다. Pub/Sub에서 BigQuery 및 Cloud Storage와 같은 다양한 싱크로 데이터를 수집하기 위한 오픈소스 Dataflow 템플릿도 제공됩니다. 

Bigtable은 실시간 데이터 저장소로 사용되어 최신 데이터와 기능을 예측 엔드포인트에 제공하는 역할을 했습니다. (엔드포인트는 이 데이터를 Google Cloud AI 플랫폼에 호스팅된 머신러닝 모델로 전달합니다.) 이와 동시에 BigQuery가 확장 가능한 분석 웨어하우스로 사용됩니다. Pub/Sub 데이터는 별도의 Dataflow 작업을 통해 두 싱크로 스트림되었습니다.

그림 2는 Google이 제공하는 PubSub 및 BigQuery 간 파이프라인용 템플릿으로 Dataflow 작업을 실행하는 셸 스니펫입니다.

그림 2: Pub/Sub에서 BigQuery로 메시지를 수집하기 위한 Dataflow 템플릿 실행

그림 3은 입력 Pub/Sub 주제가 3가지(거래 상품당 하나씩)이고 Bigtable이 싱크인 Dataflow 파이프라인을 보여줍니다.

그림 4의 클래스는 한 가지 주제(예: 제품 코드)로 데이터를 수집하고 Bigtable에 기록하는 Apache Beam 파이프라인을 정의합니다.

그림 4: Bigtable에 수집하는 Apache Beam 파이프라인

데이터 최신 상태에 대한 요구를 생각하면 앱의 예측 모델과 웹 프런트엔드 차트가 언뜻 보기에 비슷해 보입니다. 하지만 좀 더 들여다 보면 이 차트는 중간의 데이터 저장소를 거치지 않고 직접 Smart Stream 가격 데이터를 사용할 수 있다는 차이점을 알 수 있습니다. 따라서 Google은 WebSocket을 통한 Pub/Sub를 사용하여 프런트엔드를 제공하기로 결정했습니다.

서버리스 수집 구성요소와 Pub/Sub를 사용하여 아키텍처 유연성을 향상하고 운영상의 복잡성을 해결할 수 있었습니다. 한 가지 Pub/Sub 주제로 수집한 데이터는 WebSocket을 통해 직접 전송되어 빠르게 시각화하고 표시를 변경할 수 있을 뿐 아니라 머신러닝용이라면 Bigtable에, 분석용이라면 BigQuery에 저장할 수 있습니다.

스토리지 및 스키마 고려사항

데이터 사용에 소요되는 시간에 비해 데이터 관리에 지극히 적은 시간이 소요된다면 매우 이상적인 상황입니다. 스키마 설계 및 스토리지 아키텍처가 제대로 실행된다면 주객이 전도되어 사용자가 데이터를 위해 일하고 있다기보다 데이터가 사용자를 위해 일하고 있다는 느낌을 받게 될 것입니다.

row key 설계는 Bigtable 파이프라인에서 매우 중요합니다. Google의 키는제품 기호와 역방향 타임스탬프를 연결한 것으로, 액세스 패턴("fetch N most recent records")에 최적화되고 부하 집중을 방지합니다. 

역방향 타임스탬프는 프로그래밍 언어의 긴 정수 최대값(예: 자바의 java.lang.Long.MAX_VALUE)에서 이것을 빼는 방법으로 만듭니다. 그러면 <SYMBOL>#<INVERTED_TIMESTAMP> 키가 생성됩니다. 제품 코드의 가장 최근 이벤트가 테이블 시작 부분에 표시되고 쿼리 응답 시간이 빨라집니다. 이 방법은 Google의 기본 액세스 패턴(여러 개의 최근 제품 기호를 쿼리하기)에 부합하지만 다른 기능의 성능 저하를 불러올 수 있습니다. 시계열 데이터를 위한 Bigtable 스키마 설계 게시물에 자세한 개념과 패턴, 예가 설명되어 있습니다.

그림 5는 Bigtable로 수집된 데이터 포인트 샘플을 보여줍니다.

그림 5: Bigtable의 시장 데이터 레코드 표현

지연 시간이 짧은 데이터를 머신러닝 모델에 제공하는 데는 Bigtable이 적합하지만, 전환 확인 시간이 긴 정보를 얻기 위해 분석적으로 유연하게 조정되는 쿼리 엔진이 필요했습니다. 서버리스와 확장성, AutoML 등의 도구와 통합되는 장점을 가진 BigQuery는 당연히 여기에 부합했습니다. 

설계 시 기존 OHLC “candlesticks”로 시각화할 수 있게 BigQuery 데이터를 준비하는 방법으로 3가지를 고려했습니다. 첫째, 중첩 Pub/Sub JSON을 BigQuery에 저장하고 중첩 해제(unnest) 및 집계(aggregate)를 위한 복합 SQL 쿼리를 작성할 수 있습니다. 둘째, 중첩 해제 뷰를 작성한 다음 (중첩 해제 없이) 집계하는 간단한 SQL 쿼리를 작성할 수 있습니다. 셋째, BigQuery에 저장할 수 있도록 Pub/Sub 레코드를 '플랫' 형식으로 중첩 해제하는 Dataflow 작업을 개발하고 실행한 다음 간단한 SQL 쿼리로 집계할 수 있습니다. 

세 번째 옵션이 우수한 설계 결과를 가져오지만 기간이 길어질 수 있기 때문에 시간 제약상 두 번째 방법을 선택했습니다. BigQuery 뷰는 설정이 간편하고 평면화된 스키마에 대해 쿼리할 때 팀의 생산성이 향상되었습니다. DATE 파티션 필터 덕분에 SQL 뷰 정의는 견적이 저장된 기본 테이블에서 가장 최근 날짜만 검색합니다. 따라서 뷰의 쿼리 성능이 크게 향상됩니다.   

두 번째 방법 사용 시 데이터 변환 샘플과 이 차트의 뷰가 그림 6 및 7에 표시되어 있습니다.

그림 6: 원본 레코드를 평면화하는 SQL 뷰 정의

그림 7: OHLC 바("candlesticks")를 생성하는 SQL 뷰 정의

Bigtable 및 BigQuery는 서버리스이기 때문에 각 스토리지 솔루션의 유지보수가 최소 수준이고 스토리지 배열을 조달하기 위한 용량 계획, 운영 복잡성에 신경을 쓰기보다 데이터에서 가치를 창출하고 제공하는 데 더 많은 시간을 할애할 수 있습니다.

시장 데이터 마이크로서비스

Cloud Functions가 개발자에게 제공하는 이점은 크게 두 가지가 있습니다. 첫째, 비즈니스별 코드를 구현할 때 별다른 차이가 없는 하위 수준의 세부적인 사항은 건너뛸 수 있습니다. 둘째, 비즈니스 로직을 데이터베이스 외부에 캡슐화하여 유연한 데이터 사용을 지원합니다. 그에 따라 Google 파이프라인에서 작업별 코드 청크가 분리되도록 Cloud Functions가 사용되었습니다. 

한 가지 예가 Bigtable에서 거래 레코드를 검색하고 머신러닝 모델에 입력할 첫 주문 기능(mean, sum, max 등)을 추출하는 파이프라인의 Fetch Prediction 함수입니다. 덕분에 봇은 한층 빠른 예측을 사용하여 알고리즘을 기초로 한 거래 결정을 거의 실시간으로 내릴 수 있습니다. 

그림 8에 이 내용이 나와 있습니다.

그림 8: 런타임에 예측을 가져오기 위한 Python 루틴

Fetch Candles는 매분 관측된 시작가, 종료가, 최고가, 최저가를 알 수 있는 최근 가격 요약을 BigQuery에서 가져오는 Cloud 함수입니다. 요청-응답 성능을 개선하기 위해 앱에 서버리스 네트워크 엔드포인트 그룹과 함께 HTTP 부하 분산을 사용하고 Cloud CDN으로 전달을 최적화했습니다. 이렇게 구성하면 Fetch Candles는 주어진 시간(분)과 제품 코드로 첫 번째 요청에 대해서만 BigQuery를 쿼리합니다. 이후 요청은 최대 캐시 TTL(1분)에 도달하기 전에 Cloud CDN 캐시에서 전달됩니다. 따라서 웹 클라이언트 트래픽이 늘어나도 전체 쿼리 실행 볼륨을 대폭 줄일 수 있습니다. 데이터가 전환 확인 기간에 있으므로 기능적으로 BigQuery에서 개별 기간마다 두 번 이상 집계를 계산할 필요가 없습니다.

그림 9: OHLC "candlestick" 차트 시각화

Cloud Functions에서 마이크로서비스 아키텍처를 사용하면서 각 개발자는 선호하는 언어로 개발하고 각 함수를 독립된 상태에서 개발, 테스트, 디버깅할 수 있게 되었습니다.

그림 10은 시장 데이터 파이프라인에 사용되는 주요 함수 인벤토리를 보여줍니다.

그림 10: Cloud Functions 샘플 인벤토리

이러한 함수는 대부분 머신러닝 모델에 입력할 데이터를 제공하고, 거래 실적을 실시간 손익 원장에 시각화할 수 있도록  BigQuery에서 데이터를 가져오는 함수도 있습니다.

결론

서버리스 구성요소를 기반으로 구축한 데이터 파이프라인은 자본 시장 기업이 단순한 인프라 관리가 아닌, 가치 있는 정보를 도출하고 우수한 서비스를 개발하는 데 집중할 수 있게 해줍니다. 서버리스 환경에서는 최종 사용자의 데이터 액세스 패턴이 데이터 파이프라인 아키텍처와 스키마 설계에 큰 영향을 미칠 수 있습니다. 이러한 장점과 마이크로서비스 아키텍처의 사용으로 코드 복잡성이 줄어들고 결합이 느슨해지는 효과가 있습니다. 조직의 운영 환경에 데이터 소스와 정보 도구가 계속 추가되는 상황에서 서버리스 컴퓨팅 모델을 사용하면 데이터를 근거로 더 나은 의사결정을 내리는 가치 있는 작업에 주력할 수 있게 됩니다.

금융 서비스의 Google Cloud 사용에 대해 자세히 알아보세요.