데이터엔지니어 부트캠프 - 파이널 프로젝트 (12월의 기록)

파이널 프로젝트를 진행중이다. 이제 일주일정도 남았는데, 얼추 마무리가 되어 정리를 해보고자 한다.

 

 

팀프로젝트 개요

 

현재 다양한 플랫폼에 분산된 공연 및 스포츠 경기 등의 티켓 정보를 한곳에서 확인하고 비교할 수 있도록 지원하는 플랫폼을 개발합니다. 이를 통해 사용자들이 다양한 선택지를 쉽게 탐색하고 티켓 구매의 편의성을 높이고자 합니다.

 

 

목표

 

사용자가 여러 티켓 플랫폼에서 제공되는 티켓 정보를 쉽게 비교할 수 있도록 하여, 공연 및 스포츠 경기 티켓 구매 과정에서 시간을 절약하고, 최적의 선택을 할 수 있는 환경을 제공합니다.

 

 

기대 효과

 

1. 티켓 구매의 불편함 해소

현재 다양한 공연, 스포츠 경기 티켓들이 여러 플랫폼에 분산되어 판매되며, 최적의 티켓을 찾기 위해 여러 웹사이트를 방문해야 하는 불편함을 해소하고 사용자가 한 곳에서 다양한 티켓 정보를 확인하고 구매할 수 있습니다.

2. 티켓 추천과 필터링 
사용자가 사이트에서 클릭한 공연 정보를 바탕으로 연령대와 일자별로 순위를 제공함으로써 공연 선택이 편해지도록 돕습니다. 날짜와 지역 필터링 기능을 통해 사용자가 관심 있는 날짜와 장소에서 원하는 공연 정보를 편리하게 확인할 수 있도록 하여, 정보 탐색 시간을 절감하고 만족도를 높일 수 있습니다.

3. 관심 공연 및 아티스트 알림 기능
사용자가 좋아하는 아티스트나 찜해둔 공연에 대한 알림을 제공하여, 관심 있는 공연 정보를 놓치지 않도록 지원합니다. 이러한 기능을 통해 사용자는 자신이 원하는 공연과 관련된 최신 소식이나 예약 기회를 놓치지 않게 되어, 공연 탐색 과정이 더욱 편리해집니다.

 

 

화면 설계

 

 

아키텍처 설계

 

1. 데이터 크롤링

• 티켓 사이트에서 데이터를 크롤링하여 Amazon S3에 저장.

2. 데이터 전처리

• S3에 저장된 원본 데이터를 정리하고 변환(전처리)하여 MongoDB에 저장.

3. 추천 시스템 (ML)

• 저장된 데이터를 기반으로 머신러닝(ML) 모델이 추천 시스템을 수행.
• 추천 결과는 MongoDB에 다시 저장되며, FastAPI를 통해 사용자에게 제공.

4. 데이터 제공

• FastAPI가 MongoDB와 ML 추천 결과를 연결하여 사용자 요청에 응답.
• 사용자 요청에 따라 추천 공연 리스트, 관심 공연, 인기 공연 등의 데이터를 반환.

5. 로깅

• FastAPI는 사용자의 행동 로그(검색, 클릭 등)를 Kafka로 전송.
• Kafka 프로듀서는 Kafka 컨슈머에 전달하고 컨슈머는 로그를 S3에 전송 및 저장.

6. 분석 및 시각화

• Amazon S3에서 로그데이터를 Spark로 읽어와 Spark로 집계하고 결과를 Amazon S3에 저장.
• Tableau를 사용하여 분석 결과를 시각화.

 

 

도큐먼트 구조

• data: 모든 공연 데이터
• similar: 각 공연에 대해 유사도가 높은 공연 3개를 묶어 저장 (추천시스템)
• popular: 인기있는 공연을 보여주기 위한 콜렉션 (기준은 전날 유저가 많이 조회한 공연으로 매일 데이터가 바뀐다.)
• kakao: 카카오로 로그인한 유저 정보
• users: 자체 회원가입을 한 유저 정보

 

 

나의 Task

 

나는 여기에서 전반적인 데이터 엔지니어 쪽 업무를 맡았다.

 

1. 데이터 크롤링 및 전처리 (ETL)

2. 추천시스템 개발

3. 로깅

4. 데이터 분석 및 시각화

 

 

기술 스택

 

 

개발일정

 

개발기간: 2024-11-14 ~ 2025-01-06 (총 54일)

 

 

사실 관심 공연 및 아티스트 알림 기능은 공식적인 프로젝트 기간 이후에 구현하기로 해서 뒤로 빼두었다. 이유는 기간 안에 모든 기능을 만드는 게 불가능할 것 같았기 때문! 필수 기능만 우선적으로 개발하기로 결정하였다.

 

 

기술설명

 

1. 데이터 ETL

 

셀레니움을 사용한 이유

JavaScript로 생성된 동적 콘텐츠를 처리할 수 있어서 사용하였다. 크롤링해오는 웹사이트들이 모두 동적 콘텐츠였다.

 

카프카를 사용한 이유

Kafka는 데이터를 디스크에 로그 형태로 저장하므로, S3에 전송하기 전에 데이터를 안전하게 보관할 수 있으며(크롤링 중간에 네트워크 문제나 S3 업로드 실패가 발생해도 Kafka에 저장된 데이터를 다시 처리할 수 있음.), 크롤링 데이터의 양이 많아지거나, 크롤링 대상이 증가할 경우 Kafka는 쉽게 클러스터를 확장하여 처리량을 증가시킬 수 있다. 즉, 높은 트래픽 처리 요구에 대응 가능하다. (안정성 + 속도)

 

RabbitMQ도 데이터 유실 방지와 확장성을 보장하지만, 크롤링 데이터와 같은 대규모 스트리밍 처리와 다중 시스템 연동에는 Kafka가 더 나은 선택이라고 생각했다. RabbitMQ 초당 메시지 처리 속도는 Kafka에 비해 상대적으로 낮다.

 

EasyOCR을 사용한 이유

Tesseract도 사용해보았지만 둘을 비교하였을 때 한국어를 더 잘 추출하는 건 EasyOCR이었다.다른 Google Vision API 나 네이버 클로바 API는 비용이 발생하여 제외하였다.

 

 

2. 추천시스템

 

 

3. 로그인

 

JWT를 사용한 이유

JWT는 클라이언트 측에서 토큰을 저장하고 관리하기 때문에 서버에서 세션 데이터를 저장할 필요가 없다.

서버에서 세션 데이터를 유지하지 않으므로, 요청마다 세션 상태를 확인할 필요가 없어 성능이 향상된다.

그렇지만, 토큰이 탈취될 경우 만료 시간 내에는 재사용될 수 있기 때문에 이를 방지하려면 Refresh 토큰을 사용해야 했다.

 

처음 로그인 시 Access 토큰이 발급되고 이는 클라이언트가 저장한다. 그리고 우리가 설정해놓은 토큰시간이 만료되면 클라이언트는 Refresh 토큰을 사용하여 새로운 Access 토큰을 요청한다. 그리고 서버는Refresh 토큰을 검증한 후 새로운 Access 토큰을 발급한다.

 

 

4. 로깅

 

Parquet 파일로 저장한 이유

S3의 저장 비용은 데이터 크기에 따라 측정되어서, 압축 효율이 높은 Parquet를 사용하면 스토리지 비용을 절약할 수 있기 때문에 parquet 파일 형태로 저장하였다. 또한, 분석 작업에서 읽는 데이터의 양이 줄어들어 처리 비용도 줄일 수 있다.

 

 

5. 데이터 분석

 

스파크를 사용한 이유

1. Hadoop MapReduce
   • 디스크 기반 처리 방식으로 Spark보다 성능이 느림.
   • 단순 배치 작업에는 적합하지만, Spark의 메모리 기반 처리에 비해 유연성과 속도가 떨어짐.
2. Apache Flink
   • 실시간 스트리밍 처리에 강점이 있지만, 대규모 로그 집계와 같은 Batch 작업에는 Spark가 더 적합.
   • S3와의 통합 및 친화성이 Spark보다 떨어질 수 있음.
3. Dask
   • Python 환경에서 적합하지만, Spark처럼 대규모 클러스터 환경에서 효율적으로 확장하기에는 제한적.
   • 로그 데이터를 처리할 때 대규모 데이터 병렬 처리에서 Spark만큼 최적화되지 않음.

스파크는 S3와의 통합이 원활하여 데이터를 쉽게 로드 및 저장 가능하고 병렬 처리를 활용하여 로그 데이터를 빠르게 분석하고 집계 가능하다. (데이터를 병렬 처리 후, coalesce나 repartition을 사용하여 데이터를 단일 파일로 저장 가능.)

 

또한 Airflow DAG에서 Spark 작업을 정의해 자동화 배치 작업 실행 가능하기 때문에 스파크를 사용하였다.

 

 

 

파이널 프로젝트를 마치면서...

 

좋은 점

팀원들과의 협업을 통해 효율적인 분업과 소통이 이루어졌다. 각자의 역할에 충실하며 프로젝트의 완성도를 높일 수 있었다.

그리고 새로운 기술과 도구를 학습하고 실전에 적용하면서 스스로 성장을 느낄 수 있었다. 특히, Kafka 같은 기술을 배우긴하였는데 다시 적용해보려니 어려웠던 점이 있었지만 한번 더 작업하면서 다시 공부할 수 있었다.
프로젝트 진행 중 발생한 여러 문제를 해결하면서, 문제 해결 능력과 팀워크의 중요성을 다시 한번 느꼈다.

아쉬운 점

디버깅 능력이 부족하여 에러 발생 시 문제 원인을 정확히 찾아내는 데 시간이 오래 걸렸다. 에러가 발생했을 때 다양한 가능성을 고려하며 원인을 추적해야 하지만, 아직 이 과정이 미숙하다고 느껴졌다. 프로젝트 일정이 빡빡해 모든 기능을 충분히 최적화하지 못한 점이 아쉽다. 특히, 성능 테스트와 코드 최적화 부분에서 더 시간을 할애했더라면 좋았을 것 같다.

개선해야할 점

• 디버깅 능력 향상: 에러 발생 시 로그를 체계적으로 분석하고, 다양한 원인을 빠르게 파악할 수 있는 능력을 기를 필요가 있다. 여러 경우의 수를 고려해 문제를 해결하는 연습을 꾸준히 해야겠다.
• 효율적인 일정 관리: 중요한 기능이나 최적화 작업에 더 많은 시간을 할애할 수 있도록 스프린트 계획을 더 세밀하게 세워야 할 것 같다.

앞으로 일주일 남은 기간동안 데이터 시각화랑 README를 작성해야겠다. 아직 시각화가 남아있다!!