개요
apache arrow flight 통신으로 1년 치, 약 540,000개의 캔들 데이터 차트를 그리는데 41ms로 줄인 내용을 작성한다. 이전 포스팅을 확인하면 백테스팅 시간이 소요된다 하더라도 차트를 렌더링 하는데 걸리는 시간이 너무 오래 걸렸다. 데이터를 읽어오는 시간 + 데이터를 보내는 시간 등 전체적으로 최적화가 필요했다. 찾은 방법으로는 polars, parquet, apache arrow flight이다. polars와 parquet은 이전 포스팅에서 정리했으니 넘어가겠다.
Apache Arrow Flight란?
gRPC stream 통신을 베이스로 Apache Arrow 형식을 보내서 받는 즉시 메모리에 있는 값을 역직렬화 없이 바로 사용할 수 있는 프로토콜이다. 차트를 그리기 위해서는 많은 데이터가 필요하다. 특히 SoA구조로 데이터를 받으면 더욱 좋다. Apache Arrow는 컬럼 지향이므로 적합하다고 판단했다. gRPC 베이스지만 proto 파일로 코드젠을 할 필요도 없었다. 자세한 내용은 Arrow Flight RPC에 더 자세히 나와있다.
Candle Fetch 시퀀스 다이어그램
프로젝트를 웹에서 Tauri로 변경한 가장 큰 이유는 Arrow Flight(gPRC) 활요을 위해서이다. 일반적인 웹 브라우저 환경에서는 HTTP/2 gPRC 사용이 까다롭기 때문이다. 웹에 대한 이해도가 부족하기에 익숙한 RUST를 사용해 손쉽게 해결할 수 있는 Tauri를 선택했다.. 그리고 평소 선호하는 네이티브 앱 개발 방식과 유사하다는 점이다. 프론트엔드에서 여전히 웹기술을 사용하지만, ai agent의 힘을 빌리면 쉽게 해결할 수 있을 것 같다.
tauri에서 Server에 적절한 ticket을 넣어 do_get 요청을 하게 되면 준비된 parquet파일을 빠르게 읽어들여 데이터를 zero copy로 준비하고 tauri으로 보내준다.
기본적으로 tauri에서 백엔드와 프론트의 통신은 json/rpc 통신을 한다. 해당 방식을 사용하면 장점이 사라지기에 bytes로 넘길 수 있도록 설정하여 넘겼다. 프론트에서는 받은 데이터를 최초 1만 개의 캔들에 대해서 차트를 그리고 백그라운드에서 남은 캔들을 그리는 방식을 선택했다.
차트 사진
우측 상단을 보면 초기 load 시간이 0.44s이다. 아래 사진을 보면 전체적인 프로세스와 소요된 시간을 확인할 수 있다.
결론
Apache Arrow Flight 통신이 생소하여 개념을 이해하는데 힘들었다. 물론 ai agent가 만들어주는 데로 사용하면 손쉽게 가능하지만 프로젝트의 베이스를 만들어는 중에는 프로토콜을 이해하고 싶어 구현 시간이 오래 걸렸다. 캔들 데이터를 가져오고 차트를 그리는데 시간이 440ms 소요되는 것이 정말로 만족스러운 결과다. 백테스트 로직을 추가한다면 소요되는 시간이 늘어나겠지만 이 정도면 빠르게 테스트하며 전략을 수정하는데 무리 없어 보인다.
