실시간 위치 추적 서비스
Kinesis를 이용해서 데이터 스트림 전송
Amazon Kinesis를 사용하면 실시간 스트리밍 데이터를 손쉽게 수집, 처리 및 분석할 수 있으므로 적시에 통찰력을 확보하고 새로운 정보에 신속하게 대응할 수 있습니다. - AWS
우리는 뭐든 움직이는 것을 좋아한다. 만약 배달을 하더라도 실시간으로 배달기사의 위치가 어디에 있는지 확인 할 수 있다면 이용자들의 만족감도 상당히 높이 질 것이다.
실시간으로 지속적인 스트림 데이터를 전송하는 방법들이 Kafka등이 있지만 managed service인 Kinesis를 이용하면 편리하게 스트림 데이터를 전송할 수 있다.
그리하여 Kinesis를 이용하여 화물 위치 추적 서비스를 제작 해 보았다.
운송상태를 포함한 화물 드라이버 위치 추적 시스템
실시간 화물 추적 시스템을 만들기 위해 다음과 같은 서비스들을 사용하였다.
드라이버 App에서 실시간으로 현재 위치를 REST Api를 통하여 Kinesis data stream으로 전달 된다. 아키텍처의 간략한 설명은 다음과 같다.
-
API Gateway
동기적으로 rest api를 사용하기 위해서 gateway를 사용했고 일대일로 요청/응답(PutRecord) -
Kinesis Data stream
실시간 위치 정보를 수집하고 순서에 따라 저장. -
Kinesis Data Firehose
Kinesis Data Stream으로부터 record를 받아(GetRecord) 실시간 데이터 처리 및 전송 -
Opensearch
실시간 데이터 저장 및 검색과 대량의 로그 정보들을 빠르게 검색 -
API Gateway
GET {endpoint}/delivery/{:truckerId}와 같은 REST Api를 사용하여 드라이버의 위치를 조회
6 ~ 9. DB와 Lambda
OpenSearch에서 받아온 드라이버의 위치정보와 DynamoDB에서 받아온 출발지와 도착지의 위치정보를 람다를 이용해 서로 비교하여 운송상태를 다시 DynamoDB에 저장.
그리고 배송상태와 위치정보가 합쳐진 정보를 사용자에게 전달.
근데 Real-Time으로 위치정보가 오지 않는다.
드라이버의 위치정보를 보낸지 3분이 지나도 opensearch에 데이터가 들어오지 않았다.
그 원인을 조사해보니 일반적인 데이터와 달리 우리는 실시간 스트림 데이터를 다룬다.
스트리밍 데이터는 수천 개의 데이터 원본에서 연속적으로 생성되는 데이터로서, 보통 데이터 레코드를 작은 크기(KB 단위)로 동시에 전송합니다. -AWS
그리고 우리가 사용한 Kinesis firehose는 한 장소에서 다른 장소로 실제 데이터를 처리 및 이동하는 스트리밍 ETL 솔루션 이다. 그리고 ETL은 데이터베이스 기능의 추출, 변환 및 로드(extract, transform, and load)의 약자이다. 위의 아키텍처에서 사용한 Firehose의 속성은 다음과 같다.
- 데이터 원본 === Kinesis data stream
- 대상 === AWS Opensearch service
Firehose의 버퍼 속성
Amazon OpenSearch Service로 데이터를 전송하는 빈도는 전송 스트림에 구성한 OpenSearch 버퍼 크기와 버퍼 간격에 따라 다르다.
Firehose는 Amazon OpenSearch Service로 데이터를 전송하기 전에 수신 데이터를 버퍼링하게 되는데, OpenSearch 버퍼 크기(1MB에서 100MB) 또는 버퍼 간격(60초에서 900초)의 값을 구성할 수 있으며, 둘 중에 먼저 충족되는 조건이 Amazon OpenSearch Service로 데이터가 전송되도록 트리거한다.
기존에 설정한 버퍼링 사이즈와 간격은 다음과 같았다.
10MiB가 쌓이거나 5분마다 데이터가 전송되는 설정을 가지고 있었다. 드라이버가 보내는 위치정보 데이터는 정말 작은 JSON 바디이기때문에 10MiB를 채운다면 결고 실시간 서비스가 될 수 없다. 그래서 아래와 같이 데이터와 전송 간격을 최솟값으로 설정했다.
이렇게 설정을 하고 나니 전보다 훨씬 자주 데이터가 OpenSearch로 전송 되었다. 하지만 60초, 1MiB라는 조건을 충족시켜야 진정한 Real-Time 애플리케이션이 될 수 있다.
이를 해결하기 위한 방법으로 조사한 바는 2가지가 있다.
1. 트래픽 증가
트래픽이 증가하게 된다면 데이터 전송 조건인 1Mib를 빠르게 충족시켜 실시간 데이터를 전송 가능하게 할 수 있다.
2. 데이터 크기 증가
1회당 보내는 데이터의 크기를 증가시키면 더 자주 데이터를 보낼 수 있게 된다.
하지만 2번의 방법은 데이터 양을 늘려 필요없는 네트워킹 비용이 발생이 될 수 있는 차선책으로 생각이 된다.
실시간 데이터는 물레방아 같다?!
일반적인 데이터와 달리 실시간으로 처리되는 데이터는 전송이 멈춰지거나 조금씩 흐르게 되면 제 기능을 하지 못하는 것 같다.
물레방아도 마찬가지로 끊임없이 물이 들어가야 정상적으로 회전할 수 있게 된다.
추후 실시간 스트리밍(위치정보, 동영상 등등)서비스를 계획 할 때 우리가 다루어야 할 데이터의 양과 특징들을 고려하여 적절한 아키텍처를 구성하는 것이 필요해 보인다.
