[Project] DE Toy Project - 팀 프로젝트 회고 및 고도화 계획

 

지난 포스팅에서 이어집니다.

 

개인 프로젝트(DE Toy Project)를 진행하다가 운이 좋게 클라우드 아키텍처 솔루션 교육과정의 팀 프로젝트에서 개인 프로젝트를 Hybrid Cloud를 이용한 서비스로 확장 시킬 수 있었습니다.

 

하지만 기간이 정해져있어 제한 시간안에 서비스를 구현하는 것이 1순위였기에 데이터 처리 및 분석 작업을 심도있게 다루지 못하고 여러모로 아쉬운점이 있었습니다.

 

그래서 이번 포스팅은 팀 프로젝트 이후 지금까지 작업한 내용을 검토해보고 개선할 점과 앞으로 진행할 내용에 대해 작성해보겠습니다.

 

 

프로젝트 돌아보기

지금까지 진행한 내용

1. 실시간 대규모 데이터 ETL과 분석경험을 위해 data(쿠팡 상품과 리뷰정보) ETL 및 분석 pipeline 구축을 목표로 프로젝트를 진행함
2. 차단 우회 및 멀티 프로세싱 크롤링 작업 구현
3. 데이터 분석 모델과 분석 환경 테스트 진행
4. Team Project에서 Hybrid Cloud 환경 구축
5. 데이터 ETL 및 분석 Pipeline 구축

개선할 점

1.  가용성이 부족한 인프라
   클라우드 환경 구성 초기에는 클라우드 환경에서 크롤링 차단 문제로 데이터 수집만 로컬에 돌리려고 했습니다. 데이터 처리는 Dataproc, 데이터 분석은 Vertex AI 서비스를 활용하려 했습니다.
   
   하지만 LLM 모델을 정한 후 Vertex AI에 모델 등록 시 자동으로 환경을 구성해 주었는데 가격이 비싸고 따로 GPU사용 신청을 해야했습니다. Kanana 모델을 사용하려면 NVIDIA H100 80GB GPU 2대를 설정해야 했습니다.(Custum Container를 사용하면 GPU 사양 변경 가능하지만 당시에는 알지 못했습니다.) 해당 구성을 사용하려면 유료 결재 계정으로 변경 해야했고 시간 당 $9~$11이라는 상당한 비용이 들었습니다.
   
   저희 팀은 무료 크레딧으로 진행하길 원했기에 클라우드에서 데이터 분석 서버 운영을 포기하고 로컬에서 돌리기로 결정되면서 자연스럽게 데이터 처리 서버도 로컬에 돌려 최대한 비용 효율적으로 진행하기로 결정했습니다.
   
   비용을 생각해 데이터 ETL Pipeline을 모두 로컬에서 운영하다보니 가용성을 챙길 수 없었습니다. 각 서버가 단일 서버로 운영되었기에 서버 하나라도 문제가 있으면 서비스 사용이 불가능하다는 문제점이 있었습니다.
   
   짧은 기간과 서비스 구현에 초점을 맞춰 프로젝트를 진행하면서 가장 중요한 점을 간과했고 부족한 가용성 및 보안을 가장 높은 순위로 개선할 필요성을 느꼈습니다.
   
   
2. 실시간이라고 부르기 어려운 분석 속도
   분석 서버는 제 개인 노트북(Mac M1 Pro)으로 구성했습니다.
   
   맥북의 GPU 16 core 성능을 믿고 사용했지만 요약 작업 한 개당 7~10초가 소요되었습니다. 결국 한 상품 당 10~15개의 리뷰만 분석하게 만들었고 그것조차 1분~2분이 소요되었습니다.
   
   속도를 줄이기 위해 여러 방법을 사용해봤지만(출력 토큰 수 줄이기 / 여러 작업 배치 처리) 크게 개선은 할 수 없었습니다.
   
   결국 성능 좋은 GPU를 사용하기 위해 GCP에 유료 결재 요청과 GPU 사용 신청을 했지만 프로젝트 끝날 때 까지 허가가 안떨어져서 사용하지 못했습니다...
   
   
3. Spark를 사용할 만큼 데이터가 크지 않음
   이 내용은 느린 데이터 분석과도 연관이 있습니다. 데이터 분석 속도가 느리니 상품 당 리뷰 10~15개만 처리하게 되었고 그만큼 대용량 데이터 처리의 필요성이 없어졌습니다.
   
   이 문제 외에도 데이터 수집 시 10개의 상품 정보과 상품에 대한 리뷰 100개를 추출하게 됩니다. 그러면 총 1000개의 리뷰를 가지고 오게되며 크기로는 500KB 정도에 불과합니다.
   
   500KB면 Pandas로 처리하는 것이 오히려 빨랐기에 Spark를 제대로 활용할 방법을 생각할 필요가 있습니다.
   
   
4. ETL Pipeline 관리 필요성
   데이터 ETL 작업 Pipeline을 전체적으로 관리할 Orchestration 서비스 사용 필요성을 느꼈습니다. 해당 pipeline은 앞서 말했듯 단일 서버로 구성되어 있고 실패 시 장애조치 수단이 없어 장애 발생 시 치명적입니다.
   
   
5. 데이터 저장 방식
   데이터 추출 후 상품 정보 -> Cloud SQL에 저장되며, 상품 리뷰는 GCS에 저장됩니다. 그리고 분석된 리뷰 결과는 Cloud SQL로 저장됩니다. 해당 저장방식은 '웹 서비스를 위한 데이터는 바로 Cloud SQL에 저장하면 되지 않을까?' 라는 단순한 생각에서 비롯됐습니다.
   
   데이터 저장소 특성과 관리 측면을 생각했을때 먼저 데이터 레이크에 데이터를 적재 후 Cloud SQL에 적재하는 식으로 가는게 좋을 것같다는 생각이 듭니다.
   
   분석 결과 또한 분석용 DB를 따로 구성하는 방안을 생각해보면 좋을 것 같습니다.
    
6. 작업 관리용 Queue 필요성
   현재 여러 사용자가 동시에 웹 서비스에서 검색을 해도 첫번째 작업 말고는 모두 반려가 됩니다. 이러한 동시 작업을 관리할 수 있게 Queue서비스를 도입할 필요가 있습니다. 

 

 

 

앞으로의 개선 방향

1. 인프라 고도화 및 가용성 확보

• 클라우드 기반 구성 재도입: 무료 크레딧이 아닌 최소 유료 계정 기반으로 GCP 리소스를 점진적으로 사용해볼 계획입니다.
• 멀티 서버 구성 고려: 데이터 처리와 웹 서버를 분리하고, GCP Cloud Run 또는 GKE를 도입해 컨테이너 기반의 확장 가능성을 확보하려 합니다.
• 보안 강화: 데이터베이스 접근 권한 분리, 서비스 계정 키 관리, VPN 또는 프록시 서버를 통한 보안 계층 추가를 검토합니다.

 

2. 분석 성능 개선

• 양자화 모델 도입: 현재 사용 중인 Kanana 모델을 bitsandbytes를 통해 4bit 또는 8bit로 양자화하여, GPU 리소스 소모를 줄이고 로컬에서도 보다 빠른 추론이 가능하도록 개선할 예정입니다.
• Cloud GPU 도입: GCP에서 T4 또는 L4 GPU를 사용하는 형태로 모델을 서빙하고, Vertex AI 대신 Custom Container + FastAPI 등의 조합으로 비용을 절감하는 구조를 도입하려 합니다.

 

3. Spark 활용 방향 재정립

• 현재 데이터량에서는 Pandas가 효율적이지만, 향후 수집 대상이 확대되거나, 대량 병렬 처리 요구가 생기면 Spark를 다시 활용할 수 있도록 구조를 느슨 결합으로 설계해두려 합니다.
• Spark는 ETL 전처리용 Batch 파이프라인에만 제한적으로 도입하고, 분석은 로컬 또는 GPU로 최적화된 환경에서 수행하는 식으로 역할 분리를 시도할 계획입니다.

 

4. 데이터 파이프라인 아키텍처 정비

• Orchestration 도구 도입: Airflow 같은 Workflow 관리 도구를 통해 ETL 작업을 모니터링하고 자동 재처리 구조를 갖출 계획입니다.
• 데이터 레이크 도입: 원천 데이터를 GCS에 먼저 저장하고, 분석이나 서비스용 DB로 적재하는 구조를 마련하여, 스토리지 계층 분리와 이력 보존을 위한 환경을 구축하겠습니다.
• 분석용 DB 분리 설계: 분석 결과는 서비스용 DB와 분리하여 OLAP/OLTP 혼용에 따른 부하를 분산할 수 있도록 구조 개선합니다.

 

5. Queue 기반 작업 관리 구조

• 작업 요청 큐 구성: Redis, RabbitMQ, 또는 Cloud Tasks 같은 큐 서비스를 도입하여 다수의 사용자 요청을 순차 처리할 수 있도록 개선합니다.
• 비동기 작업 처리 구조 도입: Celery 또는 FastAPI + Background Task를 통해 비동기 작업을 수행하고, 사용자에게는 작업 상태를 실시간으로 제공할 수 있는 UI도 구축할 예정입니다.

 

 

후기

이번 회고를 통해 단기간에 많은 구성 요소를 얹으려다 보니, 중요한 인프라 안정성과 관리 체계를 소홀히 했던 점을 깨달았습니다. 다음 단계에서는 비용 효율성과 안정성, 그리고 확장 가능한 구조를 목표로 프로젝트를 개선하고자 합니다.