[Project] 프로젝트 삽질기51 (feat 검색 로그 구축 1)

들어가며

육아크루 서비스가 고도화되면서, 검색 기능을 통해 동네 육아 친구를 찾고 싶어 하는 고객들이 늘었습니다. 고객이 서비스 이용에 불편함을 겪지 않도록 검색 기능을 구현해야 했습니다. 검색 기능을 구현하면서 만약 유저들이 검색 기능을 어떻게 사용하는지 분석할 수 있다면, 유저들에게 더 좋은 서비스를 만들 수 있겠다고 판단했습니다. 이를 위해 실시간으로 저장되는 검색 로그 데이터를 수집하고 저장, 가공, 분석하고 시각화하는 단계를 구축하여 팀 내에서 데이터 드리븐하게 의사결정할 수 있도록 구성했습니다. 

 

이번 글을 시작으로 로그란 무엇이며, 팀에서는 어떻게 로그 데이터를 수집하고, 분석하며, 시각화하는지에 대한 과정에서 겪은 삽질의 경험이 담긴 글을 정리하려 합니다.

 

 

 

 

 

 

 

---

 

 

로그

고객에 대한 새로운 인사이트를 얻기 위해 유저가 검색 기능을 사용할 때 언제, 어떤 키워드를 검색하는지와 관련된 데이터를 모아보고 싶었습니다.

 

유저가 특정 행동을 하면 서비스 내에서 데이터가 생성됩니다. 이런 데이터를 기록한 것을 로그라고 정의할 수 있습니다. 이런 로그에는 크게 3가지 로그로 나눠서 생각해 볼 수 있습니다. 첫 번째는 프로그램의 버그나 OS 레벨에서 시스템 이벤트를 추적하기 위해 남기는 시스템 로그, 두 번째는 우리가 운영하는 서비스에 대해 KPI와 같은 지표를 분석하기 위해 남기거나 유저의 CS에 대응하기 위해 남기는 서비스 로그, 마지막으로 유저의 행동 데이터를 기록하는 유저 행동 로그로 나눠볼 수 있습니다.

 

3가지 로그 종류 중, 어떤 로그를 수집해야 할지 조금 더 자세히 알아볼 필요가 있었습니다. 시스템 로그는 개발과 관련된 데이터이기 때문에, 유저 행동에 집중한 서비스 로그와 유저 행동 로그에 대해 조금 더 자세히 살펴봤습니다.

 

 

 

 

 

 

 

 

---

 

 

서비스, 유저 행동 로그

서비스가 운영되기 위해 필요한 데이터를 서비스 로그라고 부른다고 합니다. 예를 들어 고객이 언제 가입했는지, 언제 모임에 참여했는지, 게시글은 언제 작성했는지 등의 데이터를 서비스 로그라고 볼 수 있을 것 같습니다.  반면, 앱이나 웹에서 유저가 어떤 행동을 하는지를 나타내는 데이터를 유저 행동 로그라고 부른다고 합니다. 앱이나 웹에서 유저가 어떤 행동을 하는지를 나타내는 데이터를 유저 행동 로그라고 볼 수 있을 겁니다.

 

서비스 로그와 유저 행동 로그의 특성을 살펴보며, 검색 기능을 사용할 때 사용자들이 언제, 어떤 키워드를 검색하는지와 관련된 행동 데이터를 모아보고 싶었으니 서비스 로그보단 유저 행동 로그를 수집해야겠다고 판단했습니다. 

 

유저 행동 로그를 분석하기 위해선 먼저 유저가 언제, 어떤 검색어를 입력했는지와 관련된 이벤트 데이터를 특정 저장 공간에 적재해야만 했습니다. 그리고 데이터를 저장하기 위해선 배치성 작업으로 데이터를 저장하거나 실시간으로 데이터를 저장하는 방법을 생각해 볼 수 있었습니다.

방식을 고민하면서, 만약 지속적으로 만들어지는 유저의 행동 데이터를 빠르게 적재하여 데이터를 실시간으로 분석할 수 있다면, 팀원들이 기획을 할 때 있어 의사결정을 더 빠르게 할 수 있도록 도울 수 있지 않을까 판단했습니다. 그래서 육아크루에서는 사용자의 행동 데이터를 실시간으로 적재하는 환경을 구축하고자 했습니다.

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

아키텍처

데이터 수집 과정은 위와 같이 구성했습니다. Kinesis Streams와 Kinesis Firehose, lambda, s3를 활용해서 데이터를 수집하는 프로세스를 구축했습니다. 각 서비스의 특징은 무엇인지에 대해 간단히 설명드리겠습니다.

 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

AWS Kinesis

실시간 데이터 적재 환경을 구축하기 위해 AWS Kinesis 서비스를 활용하려 했습니다. AWS Kinesis는 실시간으로 데이터 스트림을 손쉽게 수집, 처리 및 분석하기 위한 클라우드 서비스입니다. 여러 스트리밍 서비스를 심리스 하게 연결하고 운영 부담과 비용 최소화를 가져다주는 완전 관리형 서비스입니다. Kinesis는 활용하기 쉽고 고가용성을 제공한다는 점에서 장점이 있다고 생각했습니다. 

 

 

Kinesis 서비스는 총 4가지로 구성되어 있는데, 그중 로그 데이터 수집 및 분석을 위해 Data Streams와 Data Firehose를 활용했습니다. 그럼 Kinesis Data streams와 Data Firehose에 대해 조금 더 자세히 살펴보겠습니다.

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

Kinesis Data Streams

Data Streams은 대량의 데이터를 실시간으로 수집, 처리하는 서비스입니다. 내부적으로 샤드로 구성되어 있으며 이를 동적으로 증가/감소할 수 있도 샤드 수에 따른 보장된 전송 시간을 제공합니다. 데이터 수신, 재처리, 분석, 처리 및 저장을 포함한 실시간 애플리케이션을 구축할 때 사용할 수 있습니다. 주로 연속적으로 생산되는 대량의 데이터 소스(1MB 이하)를 처리해야 하는 파이프라인에 사용하기 좋습니다.

 

이와 비슷한 서비스로 Kafka, Rabbitmq, ... 등이 있으며 이와 구별되는 Kinesis Stream의 특징으로는 아래와 같습니다.

 

• AWS 클라우드 서비스로 제공되어 서버관리가 필요없음
• AWS 보안을 사용하기 때문에 보안성이 좋음
• 이미 AWS 클라우드 서비스를 사용하고 있다면 도입이 간편
• 수집/처리하는 데이터량을 당장 몰라도 손쉽게 변경/유지관리가 가능

 

 

Data Streams가 무엇인지 간단하게 알아봤고, 이번엔 Data Firehose에 대해 간단히 알아보겠습니다.

 

 

 

 

 

 

 

Kinesis Data Firehose

Data Firehose는 실시간 스트리밍 데이터를 제공하기 위한 완전 관리형 서비스입니다. 생산자 -> Kinesis Data Firehose -> 소비자와 같이 Kinesis Data Streams와 동일한 입출력 개념으로 사용되며 전송 과정에서 데이터 변환이 가능합니다. 예를 들어 JSON 포맷의 데이터를 Apache Parquet 포맷으로 변경할 수 있습니다. AWS의 S3, RDS 등을 소비자로 사용하기에 간편하게 구성되어 있습니다. 

 

 

Data Streams와 Data Firehose 두 개의 개념을 보면서, 두 개의 서비스는 각각 어떤 차이점이 있는지를 알아야 했습니다. 이를 아래에서 정리해 보겠습니다.

 

 

Data Streams vs Data Firehose

첫 번째, Kinesis Data Stream은 Stream에서 데이터를 꺼내와서 작업한다는 개념의 서비스이며 길게는 일주일까지 데이터를 저장할 수 있지만, Firehose는 Destination에 전해 다 주는 개념의 서비스이다 보니 데이터를 잠시라도 들고 있을 수 없습니다. 

 

두 번째, Data Stream 은 Consumer를 여러 개 지정할 수 있으며 open-ended model 인 반면, Firehose는 단일 Destination을 가지는 close-ended 모델입니다. 다르게 표현하면, Data Stream 은 Consumer들이 Stream에서 데이터를 꺼내와서 작업한다는 개념이고 Firehose는 데이터를 직접 Destination에 전해 다 주는 개념입니다.

 

세 번째, Data Stream 은 샤드 수를 조정하여 수동으로 Scailing 해야 하는 반면 Firehose는 데이터 요청에 따라 Scailing 이 자동으로 이루어집니다.

 

 

이렇게 알아본 Kinesis의 Streams와 Firehose를 활용하여 데이터를 실시간으로 적재하는 프로세스를 구축하려 했습니다. 하지만 Kinesis 서비스를 사용한다고 해서 끝이 아니었고, 실시간으로 받아온 데이터를 어디에 저장할 것인가와 관련해서 고민해야 했습니다. 데이터를 저장하는 과정에서 데이터 웨어하우스와 데이터 레이크에 대한 개념을 살펴볼 수 있었습니다. 그럼 데이터 웨어하우스와 데이터 레이크 중 어떤 방식으로 데이터를 구축했는지 정리가 필요했습니다. 그럼 간단하게 데이터 웨어하우스와 데이터 레이크에 대해 알아보겠습니다. 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

 

 

 

데이터 저장소

데이터 웨어하우스와 데이터 레이크는 데이터 저장소로서의 공통점이 있지만, 목적과 구조 등에서 차이가 있습니다.

 

데이터 웨어하우스

데이터 웨어하우스는 오랜 기간 동안 축적된 기업의 데이터를 파악하고 활용하기 위한 목적으로 만들어졌습니다. 따라서 ETL 과정을 통해 데이터를 정재하고 구조화하여 보관합니다. 데이터 웨어하우스는 시간에 따른 변화와 성능 개선에 대한 대응이 유연하지 못하고, 비즈니스 요구사항을 바탕으로 사전 구조화 작업이 필요합니다.

 

 

데이터 레이크

데이터 레이크는 기업이 집중적으로 데이터를 누적하는 저장소입니다. 데이터 레이크에서는 데이터를 수집하기만 하고 구조나 형식을 강제하지 않습니다. 이는 데이터를 더욱 효율적으로 저장하고 다양한 형태로 분석할 수 있는 환경을 제공합니다. 또한, 데이터 레이크는 다양한 유형과 볼륨, 속도의 데이터를 수용할 수 있으며, 머신러닝과 같은 복잡한 알고리즘을 구현할 수 있는 자유로운 환경을 제공해 줍니다.

 

즉, 데이터 웨어하우스는 기존의 산업 분야에서 사용되는 데이터 분석을 위해, 데이터 레이크는 다양한 데이터 분석을 위해 사용됩니다.

 

 

이런 특징을 봤을 때, 현재 유저가 어떤 검색을 하는지 데이터를 수집해서, 수집한 데이터를 어떻게 활용해야 할지 명확하게 구성하지 못한 상태였기 때문에, 유연하게 데이터를 분석할 수 있도록 하려면 데이터 레이크 방식으로 데이터를 수집하는 것이 필요하다고 판단했습니다. 이를 통해 변화에 좀 더 유연하게 대응하고 엔지니어링 비용을 낮추려 노력했습니다.

 

AWS는 S3를 활용해서 데이터 레이크를 구축할 것을 제안하고 있었습니다. 모든 종류의 데이터가 단일화된 저장소의 S3에 저장이 되는 것이 그 자체만으로도 데이터 레이크가 시작됩니다. 다양한 수집도구를 통해 S3에 저장되고, Glue를 통해 S3의 데이터를 실제 사용할 수 있는 형태로 가공할 수 있다는 특징이 있었습니다. 육아크루 팀에서는 데이터 레이크를 구축하기 위해 AWS의 S3를 활용했습니다.

 

 

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

 

마치며

지금까지 데이터 수집을 위해 어떤 기술을 사용하려 했는지 공유드렸습니다. 그럼 다음 글에서는 저희 육아크루가 행동 데이터를 어떻게 수집했는지, 데이터 수집 방법을 공유드리겠습니다.

 

 

 

 

 

 

 

---

 

 

 

 

 

출처

Workshop Studio

데이터 로그 설계, 데이터 로깅, 이벤트 로그 설계, 데이터 QA의 모든 것

AWS Kinesis Data Stream 으로 대용량 데이터 수집을 편하게!

AWS Kinesis 살펴보기

 

준 실시간 Data Lake 구성하기

 

[AWS Kinesis] Data Stream vs. Data Firehose