[아이디어] 테슬라 데이터 수집 - 테슬라가 빌런이다.

테슬라의 차량 데이터를 API를 통해, 수집을 해야하는데, 테슬라 이놈들 API로 장사를 하네...ㅠ

 

오픈API는 일반적으로 사용요금이 저렴한 편인데...

테슬라 1만대 기준 한달사용하는 API비용이 최악의 경우 4억이 넘어간다.

(물론, 사용/용도에 따라 다르겠지만, 우리가 만드는 서비스는 대략 계산해보니 저정도 발생하더라... 갑부도 아니고..이거뭐..쩝)

물론, 최악을 기준으로 계산한것이긴 하지만 , 후덜덜하다.

 

테슬라에서 API를 통해,

내 차량의 데이터(배터리 충전량, 주행가능거리등)를 가져오려면, 기본적으로 테슬라차량이 깨어있어야 한다.

깨어있다는 이야기는,

주차를 한 상태면 배터리 사용을 줄이기위해 시스템도 동면에 들어가는데,

이경우는 차량의 데이터를 API를 통해서 가져올수없게 된다.

이경우 테슬라API중에 차량을 Walkup시키는 API를 호출하여,

잠시동안 차량을 깨워서 데이터를 받을수있는 상태로 만들어야하는데,

이경우 API의 사용료가 비싸다. 건당 16원정도 ....

(충전중일때는 데이터 조회 가능함)

 

테슬라의 연동을 통해 회원들의 차량 데이터를 서비스상에서 지속적으로 수집을 해야하는 서비스를 만들어야하는경우.

주기적으로 (짧은 주기) wakeup api를 호출해야하고, 차량데이터 조회 API를 호출해야하기에...

비용이 어마어마하게 나올수있다.

대충 1만대 기준, 15분간격으로 데이터를 wakeup시켜서 가져오도록 하면, 한달에 4억정도 나온다...(후덜덜하다)

 

다행히,

테슬라에서는 API방식이 아닌, 스트리밍 방식을 제공하는데, 이경우는 훨씬 저렴하게 차량의 데이터를 받아올수있다.

하지만, 스트리밍 방식은 등록된 회원의 데이터가 콜백(grpc)으로 지속적으로 유입되기에, 해당회원이 탈퇴하거나 연동을 해제하는경우, 스트리밍에서 해당 차량의 데이터를 구독해제되도록 만들어야 한다.

(불필요한 사용자의 데이터의 구독 콜백 수신을 줄일수있다)

 

그래야, 폭주하는 데이터 컨슘을 막을수있다.

(데이터 구독을 끊지않으면, 지속적으로 구독하는 데이터가 늘어나, 서비스가 죽을수도있다)

 

여러가지 방법을 생각해봤지만, 우선 현재는 내가 생각한 가장 합리적인 방법은 아래와 같다.

 

1) 앱이 실행되는 시점에 사용자의 구독을 ON한다.

2) 앱이 종료되거나, 백그라운드로 넘어가는경우 사용자의 구독을 OFF한다.

 

이렇게 구현을 하면, 가장 합리적인선에서 데이터의 구독과 해제를 할수있을듯하다.

 

앱에서는 카프카큐를 통해 사용자의 앱 접속/종료 여부를 이벤트로 발행하고,

((유저아이디와 앱 접속/종료 여부)의 이벤트로 발행함)

 

해당 이벤트를 컨슘하여, MurMurHash를 이용하여, 해시맵에 저장한다.

그리고 5분주기로, 구독/구독해제를 판단하여, 테슬라 스트리밍을 받을지 않받을지를 판단하여 프로세스를 진행한다.

 

또는 BloomFilter를 현재 필터와 이전 필터를 유지하며, 사용자의 구독/구독해제여부를 판단하여 프로세스를 진행하는 방법도 가능할듯하다.

 

여기서 MurMurHash, BloomFilter등을 거추장스럽게 써야한다고 판단을 했냐면...

대량의 데이터를 실시간으로 처리대상을 판단할때,

우리가 사용하는 일반적인 Set자료구조 방식을 사용하면,

대상이 지속적으로 늘어나는경우, 메모리 사용량 폭주로 서비스가 죽을 가능성이 굉장히 높기때문이다.

(먼미래가 아닌, 1000tps만 해도 메모리 사용량이 어머어마하게 늘어날것이다.)

 

위에 말한 MurMurHash, BloomFilter은 확률에 기반한 자료구조알고리즘이기에, 약간의 오차가 발생하지만,

그 오차가 서비스에 크게 중요하지 않고 타협이 가능한 수준이라고 한다면,

메모리 사용량이나, 성능면에서 일반 Set구조 방식과는 비교할수없을정도로 뛰어나기 때문이다.

(100배, 1000배 ~ 메모리 더적게 먹음)

 

가장 중요한건, 사용자의 앱접속에 대한 시그널을 어떻게 받아야하는지에 대한 고민이 컸는데,

이부분은 앱의 시작과 종료/또는 백그라운드여부에 따른 시그널을 앱에서 받도록 하는 방법을 사용하는것이 모든 측면에서 장점이라고 생각이 들어서, 이 방법으로 설계를 해봐야 겠다.

 

대용량 트래픽에 대한 수집/수신처리에서는 최대한 구독하는 프로세스에서는 외부 인프라의 조회/사용을 최대한 줄이는 방법을 사용해야한다. 대표적인 예로 위의 Set기반 인프라중에 가장 쉽게 사용가능한것이 REDIS가 떠오르지만, REDIS가 대량의 트래픽을 견디도록 하는것이 상당히 어렵고 비용이 많이 발생하는 것이기에, 최대한, 인스턴스 내부에서 (자료구조와 알고리즘, 샤딩) 외부 인프라에 의존하지않고 프로세스를 만드는 방법을 고민해야한다.

 

우선 위에 기능도 레디스는 사용하지 않도록 고민을 할예정이다.

레디스에서의 장점인, 공유 기능은 샤딩을 통해 해결을 해야할것같다..

 

결론!! 테슬라가 빌런이다.