1. 로플랫의 대용량 데이터 활용
오프라인 데이터를 다루고 있는 로플랫에서는 월간 4.5TB의 로그 데이터가 쌓이고 있습니다. 이는 매달 외장하드 하나를 위치 로그로만 채우는 어마어마한 용량인데요. 이처럼 방대한 양의 데이터를 다루기 위해서는 많은 사항을 고려해야 합니다.
예를 들어 한 사용자가 로플랫이 제공하는 서비스를 통해 일주일간의 데이터를 분석한다고 가정해보겠습니다. 이를 위해서는 지난 일주일간 쌓인 데이터 약 1TB를 모두 검색하는 과정이 필요합니다. 혹여 과거 90일간의 데이터를 확인한다고 가정하면 그간 쌓인 13.5TB의 로그 데이터에서 원하는 조건으로 검색해야 하는데, 결과를 보기 위해 소요되는 약 1분도 기다려줄 사람이 많지 않은 게 사실입니다. 아무리 빠른 SSD와 컴퓨터로도 해결하기는 어려움이 있습니다.
그래서 로플랫은 현재 위치 인식 기술 기반 오프라인 마케팅 솔루션인 ‘loplat X’와 방문객의 동선 기반 오프라인 분석 서비스 ‘loplat i’를 통해 사용자에게 다양한 오프라인 기반 인사이트를 방대한 양의 데이터에서 추출, 가공해 제공하고자 노력하고 있는데요.
그럼 사용자의 니즈에 따라 필요한 기간별로 오프라인 데이터 검색 결과를 보고 싶다면 어떻게 시스템을 꾸려야 할까요?
2. 대용량 데이터 처리 과정에서 겪을 수 있는 어려움
사실 방대한 대용량 데이터를 처리하는 것은 엔지니어에게도 쉽지만은 않은 일입니다.
그동안 학교나 책에서 배운 내용은 입문 위주의 내용이거나, 구현하는 자체에 초점을 두는 경우가 대부분이었다 보니 실제로 이를 처리하는 데 있어서 예상치 못한 난관을 겪을 때가 많습니다.
개발자 컨퍼런스의 내용도 관련 지식이나 경험이 부족해 마치 돌도끼로 바퀴를 발명하는 상황에 처한 것 같은 사람들에게는 외계인의 기술처럼 아득히 멀게만 느껴지곤 하죠.
그러다 보니 개발한 프로덕트가 본 궤도에서 서비스되고, 또 어느 정도 사용자가 생겨 트래픽이 나올 시점부터는 삐걱거리는 소리를 들을 수 있습니다. 가령 개발이 잘못되었다든지, 데이터베이스를 잘못 다루고 있다든지, 서비스를 잘못 배포하고 있는 등의 문제가 발생하는 것인데요.
이러한 문제는 사용자 수가 적은 서비스와 낮은 트래픽, 그리고 소용량 데이터를 처리하는 과정에서는 대부분 발생하지 않다 보니, 우리가 쉽게 접할 수 있는 지식만으로는 해결이 어렵습니다.
결국 대용량 데이터를 처리하는 기술은 이러한 시행착오를 몸소 겪으면서 터득하게 되는데요. 여러 사례를 바탕으로 쌓은 경험과 느낀 점들을 함께 공유해보고자 합니다.
3. 대용량 데이터 처리를 위해 개발 프로세스에서 고려할 사항
대용량 데이터를 다루고 있는 기업이라면 전반적인 개발 프로세스에서 이를 염두하고 모든 것을 계획해야 하는데요.
(1) 설계 단계
이를 위해 첫 번째로 설계 단계에서부터 대용량 데이터 처리를 고려해야 합니다.
많지 않은 로그에서 원하는 정보를 추출하는 것은 어려운 일은 아니지만, 이것이 방대한 양이 된다면 기존의 방식을 그대로 적용해서는 안 됩니다.
그래서 대용량 데이터를 처리할 수 있는 시스템을 이용하는 것이 좋은데요. 여러 좋은 솔루션들이 많지만, 로플랫은 구글 클라우드의 BigQuery를 사용하는 것으로 데이터 처리 및 분석을 수행하고 있습니다. 내부적으로 쿼리를 분산해 처리하기 때문에 높은 확장성을 가지고 있고 인프라에 대한 관리 포인트를 줄여 비즈니스 로직에 집중할 수 있도록 하는 점이 방대한 양의 데이터를 다루기 위해 설계에서부터 선택하는 이유입니다.
(2) 구현 단계
두 번째로 구현 단계에서도 최적화를 통해 대용량 데이터 처리에 대한 부담을 덜어야 합니다.
보통 관계형 데이터베이스에서 원하는 정보를 부분 검색하고자 할 땐 LIKE 검색하도록 배우는데요. 하지만 검색하고자 하는 데이터의 양이 늘어난다면 인덱스를 활용하지 못해서 동시에 검색하는 인원이 2명만 돼도 데이터베이스의 부하가 치솟을 수도 있습니다. 이를 해결하기 위해 Full Text Search, FTS 인덱스를 사용하거나 혹은 Elasticsearch 로 해결할 수도 있습니다.
그렇다면 로그 데이터에 대해 시간별, 일별 집계 메타 데이터를 추출하거나 중복되지 않는 유일한 값의 메타 데이터는 어떻게 조회할 수 있을까요?
단순하게는 COUNT와 GROUP BY, 그리고 DISTINCT 키워드를 조합해 집계 메타 데이터를 완성할 수 있습니다.
하지만, 로그 데이터의 특성상 실시간으로 로그 데이터가 생성되고 업데이트되기 마련인데요. 이러한 조건 속에서도 유일한 값을 포함하는 집계 데이터를 실시간으로 보여줘야 한다면 해당 쿼리로 해결할 수 있을까요?
이럴 때 집계 데이터를 실시간으로 생성하기보다는 일정 주기로 미리 만들어 보여주거나 Redis같은 인메모리 데이터 스토어를 사용하는 편이 좋습니다.
(3) 운영 단계
실제로 운영할 때에는 대용량 데이터의 특성에 맞는 상황을 고려하고자 노력합니다.
대규모의 데이터일지라도 때에 따라 모든 정보가 필요하지 않을 수도 있고 시기에 맞는 데이터만 필요할 수가 있습니다. 저희는 Bigquery를 사용하지만, Silver bullet 이 아니기 때문에 내부적으로는 최적화 작업을 거친 데이터를 분석에 사용합니다.
또한 주기적으로 일정 기간이 지난 데이터는 더 저렴한 스토리지로 옮기거나 쿼리 시 와일드 카드 검색을 자제하고 원하는 필드와 기간만 조회하도록 하며 효율적인 운영을 추구하고 있습니다.
(4) 장애 발생 시 대응
마지막으로 운영 중 예기치 못한 문제 상황이 발생할 때도 미리 대비할 수 있어야 하는데요.
Bigquery 같은 SaaS를 사용하게 되면 SLA가 100%가 아니기 때문에 항상 실패할 때에 대해 대비를 해두고 재실행할 수 있도록 구성해야 합니다.
구성 단계에서 이중화나 실패 시 알림이 발생될 수 있도록 세팅해야 하며 장애 발생시 우회하거나 혹은 재시도할 수 있는 로직 혹은 프로세스의 추가도 고려해야 하며 최악의 경우 수동으로라도 돌릴 수 있도록 대비할 수 있어야 합니다.
이러한 방법론으로는 카오스 엔지니어링이 있습니다. 기존 테스트와 다른 점으로는 클라우드 기반의 분산 시스템에서 문제를 발생시켜 장애 상황에 대처하기 위함입니다.
이처럼 대용량 빅데이터를 다루는 일은 꽤 까다롭긴 하지만, 빅데이터 시대에 있어 양질의, 흔치 않은 오프라인 데이터를 직접 다뤄볼 수 있다는 건 정말 좋은 경험이자 경쟁력이 될 수 있다고 생각합니다.
앞으로도 많은 분들이 로플랫에 합류하여 더 나은 기술로 긍정적인 영향을 만들어갈 수 있길 바랍니다. 🙂
👉🏼 로플랫 채용 공고 바로가기 👈🏼
