텍스트 데이터 기반 빅데이터 분석 플랫폼 개발

빅데이터 분석 플랫폼 개발

  • 자연어 처리 기술 기반의 텍스트 데이터를 쉽고 빠르게 분석할 수 있는 빅데이터 분석 솔루션 개발
  • 개발 기간: 2022.3. - 2023.5.
  • 개발인원: 8명 (개발: 4명, 디자인: 2명, 기획: 2명)
  • 기술스택: Vue.js, Java/SpringBoot, Python, MySQL, Kafka, ElasticSearch, gRPC

성과

  • 사용성 개선: 서버 구조 개선을 통한 CPU 점유율 50% 수준으로 절감, 데이터 처리 병목 해소 및 사용자 만족도 향상
  • 대용량 분산 처리 향상: 리뉴얼을 통해 UX 개선 및 대규모 사용자 분석 요청 처리 능력 향상
  • 품질 향상: 자연어 처리 및 분석 파이프라인 개선으로 멀티 언어 정제 및 감성 분석 품질 향상

역할

1) 테크니컬 리더(Technical Leader): 팀 기술 리딩 및 의사 결정

  • 팀의 기술적 방향성 제시 및 코드 리뷰
  • 각 파트 간의 원활한 데이터 연동 및 협업 프로세스 조율

2) 시스템 아키텍처 설계: MSA 구조 설계

  • 모놀리식 구조를 수집, 분석, 관리 서비스로 분리하여 확장성 있는 MSA 환경 설계

3) 분산 처리 구조 설계: 고성능 데이터 파이프라인 구현

  • Apache Kafka 및 gRPC를 적용하여 비동기 데이터 중계 및 분산 수집 서버 구축

소감

2019년 컴퓨터공학과 석사 과정에 입학하면서 해당 시스템 개발을 본격적인 연구 주제로 삼아 연구를 시작하였다. 이후 시스템의 핵심 아키텍처 설계, 알고리즘 최적화, 실증 실험 등을 중점적으로 수행한 결과, 총 4편의 관련 논문을 국내 학회에 게재할 수 있었다.

이 시스템을 실제로 개발·운영하면서 가장 큰 난관은 데이터 수집과 전처리 단계였다. 원천 데이터가 여러 웹사이트·API·DB 등 이기종 출처에서 수집되다 보니 결측치, 이상치, 포맷 불일치 문제가 만연했고, 초기 규칙 기반 수작업 전처리는 규칙이 방대해지면서 시스템 복잡도와 유지보수 비용을 급격히 증가시켰다. 수집 원천의 구조 변경이 잦아 매번 코드를 수정해야 하는 상황이 반복되면서 개발·운영팀 전체의 부담이 매우 컸다.

이 문제를 해결하기 위해 머신러닝 기반 자동 전처리·적응형 수집 모델을 연구·도입하였으나, 상용 환경에서는 안정적 운영에 실패했다. 웹사이트 UI·구조의 빈번한 변화로 모델 성능이 빠르게 저하되었고, 재학습 주기가 너무 짧아 실시간 서비스에 적용하기 어려웠기 때문이다. 이는 머신러닝의 자동화 장점과 실제 운영 환경의 동적 특성 사이에 존재하는 근본적인 괴리를 직접 체감한 경험이었디.

분석 모듈에서도 중요한 교훈을 얻었다. TF-IDF 기반 서비스 개발 당시, 해당 기법의 수학적 원리와 적절한 활용 범위를 충분히 검토하지 않은 채 구현이 진행된 부분이 있었다. 이는 개발자 개인의 전문성과 조직의 코드 리뷰·품질 관리 프로세스가 최종 서비스 품질에 미치는 영향을 뼈저리게 느끼게 해준 사례였다.

2022년 말 ChatGPT의 등장과 함께 AI 기술이 폭발적으로 발전하는 모습을 지켜보며, 기존 빅데이터 중심 시스템의 한계를 명확히 인식하게 되었다. 이 변화는 저에게 큰 위기감과 동시에 새로운 도전의식을 불러일으켰고, 연구 관심사를 Smart Factory와 Physical AI 분야로 자연스럽게 전환하는 계기가 되었다. 현재는 로봇·센서·엣지 컴퓨팅을 결합한 지능형 제조 환경과 물리 세계와 AI의 실시간 융합 기술에 집중하며, 이전 실패와 경험을 바탕으로 더욱 견고하고 적응력 높은 차세대 시스템을 설계하는 데 전념하고 있다.

시스템 아키텍처

1) 시스템 구성도 arch

2) 시스템 특징

  • Scalability: Master/Slave 구조로 수집 노드 무한 확장 가능
  • Reliability: Kafka 도입으로 장애 시 데이터 유실 0% 및 자동 재처리
  • Efficiency: gRPC 통신으로 네트워크 오버헤드 최적화
  • Availability: Health Checker 기반의 실시간 상태 감시 및 장애 노드 자동 제외로 무중단 서비스 유지

3) 구성요소

  • 수집 & 통신 Layer (Python, gRPC)

    • Earthling-Master가 수집 요청을 관리하고 Slave들이 실제 수집 및 분석을 수행하는 분산 구조로 확장성 확보
    • gRPC protobuf(프로토콜)을 사용하여 마스터-슬레이브 간 상태 체크(Health Check)

  • 메시징 & 버퍼 Layer (Apache Kafka)

    • 수집 작업 명세와 로그를 Kafka에 적재하여, 수집 서버 장애 시에도 오프셋(Offset) 기반 재처리를 통해 데이터 무결성 보장
    • 수집 레이어와 Health-Checker 계층을 분리하여 부하가 전체 시스템에 전이되지 않도록 버퍼 역할 수행

  • 저장 & 검색 Layer (ES, MySQL)

    • MySQL(RDB): 사용자 요청, 작업 명세 등 트랜잭션이 중요한 메타데이터의 정형 저장 및 상태 관리.
    • Elasticsearch: 수집된 대규모 비정형 텍스트 데이터의 고속 형태소 분석 및 분산 인덱싱을 통해 분석 파이프라인(NLP)에 필요한 검색 성능 극대화

  • 분석 & 서비스 Layer (FastAPI, Vue.js)

    • FastAPI: 비동기 I/O를 통해 대규모 분석 요청을 병목 없이 수용
    • Vue.js: 실시간 대시보드 구현 및 사용자 인터페이스의 반응성 최적화

트러블 슈팅(Trouble Shooting)

1) 수집 서버의 DB 폴링 부하 해소 및 작업 분배 효율화

  • Master-Slave 아키텍처와 gRPC 도입으로 개별 서버의 DB 부하를 해소하고, 시스템 전체의 데이터 처리 효율과 확장성을 확보
  • 이슈내용
    • DB 커넥션이 급증하고 쿼리 실행 지연이 발생하는 등 데이터베이스 부하 한계치 도달함
    • 서버가 늘어날수록 DB 부하가 기하급수적으로 증가하여 시스템 전체의 안정성 저하 현상 발생
  • 원인분석
    • 개별 수집 서버들이 할당된 작업을 확인하기 위해 직접 DB에 접근하는 폴링 방식으로 설계되어 있었음
    • 서버 간의 작업 조율 프로세스가 부재하여 데이터 중복 조회 혹은 불필요한 IO 반복 발생
  • 해결방안
    • 모든 수집 서버가 DB에 직접 접근하던 방식을 폐기하고, 단일 매니저(Master) 서버만 DB 폴링하는 구조로 단일화함 (Github: eathling-cube)
    • 매니저 서버가 DB에서 분석/수집 대상 리스트를 확보한 뒤, 각 수집 서버(Slave)의 현재 상태와 부하를 고려하여 작업 균등 배분 로직 구현
    • 매니저와 슬레이브 서버 간의 통신은 gRPC와 같은 가벼운 프로토콜을 사용하여 작업 전달 시 발생하는 오버헤드 최소화

-

  • 결과
    • DB 접근 주체를 단일화함으로써 커넥션 점유율과 쿼리 발생 빈도를 대폭 줄여 DB 안정성 확보
    • 서버를 추가하더라도 DB 부하에 영향을 주지 않게 되어, 데이터 처리량 증설 용이한 구조로 개선
    • 중복 조회를 방지하고 서버별 할당량을 최적화하여 전체 시스템의 데이터 처리 효율 향상

2) 작업 프로세스 모니터링 부재로 인한 장애 대응 지연 해결

  • 작업 상태 세분화와 실시간 Slack 알림 체계를 구축하여 장애 인지 및 복구 시간(MTTR)을 획기적으로 단축하고 서비스 신뢰도를 높임
  • 이슈내용
    • 사용자가 요청한 대규모 데이터 수집 및 분석 작업이 특정 단계에서 멈추거나 지연될 경우, 관리자가 이를 실시간으로 인지하지 못함
    • 사용자의 문의가 들어온 후에야 로그를 통해 원인을 파악하게 되어, 장애 복구 시간(MTTR)이 길어져 서비스 신뢰도 하락
  • 원인분석
    • 분산 처리 환경(MSA) 특성상 수집-분석-저장으로 이어지는 전체 파이프라인의 작업 상태를 한눈에 파악할 수 있는 통합 모니터링 체계 부족
    • 작업별 진행 상태(Status)가 DB에 기록은 되지만, 지연을 감지하고 알리는 능동적인 감시 로직 부재
  • 해결방안
    • DB를 주기적으로 조회하여 'Processing' 상태가 설정된 임계치(Threshold)를 초과한 작업을 추출하는 감시 로직 구현
    • 지연 발생 시 해당 작업의 ID, 소요 시간, 단계 등의 정보를 담은 알림을 관리자 메신저(Slack)로 즉시 전송하도록 구축
    • 분석 작업 단계를 세분화하여 병목 발생 지점 즉각 식별 가능하도록 개선

-

  • 결과
    • 관리자가 사용자의 불편 신고 이전에 지연 상황을 먼저 파악하고 조치할 수 있는 선제적 대응 체계 마련
    • 수동 모니터링 리소스를 절감하고, 알림 메시지를 통해 병목 구간을 바로 파악함으로써 원인 분석 및 복구 속도 획기적 개선
    • 시스템 장애에 대한 가시성을 확보하여 대규모 분석 요청 시에도 안정적인 서비스 운영 가능

3) Apache Kafka를 활용한 데이터 유실 방지 및 실시간 처리 안정화

  • 메시지 큐 기반의 Kafka 도입으로 데이터 유실 0%를 달성했으며, 수집-분석 계층의 독립적 확장이 가능한 고가용성 MSA 구조를 구현
  • 이슈내용
    • 웹 사이트의 텍스트를 크롤링하는 수집 서버의 특성 상 수집 작업은 평균적으로 오래 걸림 (수 십분 ~ 수 시간)
    • 수집 서버 장애 시, 사용자가 요청한 수집 요청 작업 유실로 수집이 멈춰버리는 현상 발생
    • 이러한 현상으로 수집이 지연되면, 분석 작업이 늦게 실행되거나 실행되지 않아 사용자 불만 폭주
  • 원인분석
    • 기존 메모리 기반 버퍼링 방식은 서버 다운 시 보관 중인 데이터를 보호할 수 있는 영속성(Persistence) 결여
    • 이에 따라 수집 서버에 장애가 발생하면 사용자가 수집 작업을 다시 등록하지 않으면, 장애 발생 시 수집 작업 재개되지 않음
    • 또한 십 수개에 달하는 수집 서버 각각이 메인 DB를 직접 pulling 하므로, 쿼리 속도 저하로 제때 작업을 배정받지 못하는 경우가 있음
  • 해결방안
    • Kafka의 영속성을 활용하여 수집 요청을 영구 기록하고, 장애 복구 시 오프셋(Offset) 관리를 통해 중단된 지점부터 데이터를 재처리하도록 구성
    • Kafka를 중심으로 MSA 구조로 개편함으로써 메인 RDB의 부하에 영향을 받지 않고 수집 작업을 유휴 서버에 배치되도록 함
  • 결과
    • 분석 서버가 일시적으로 중단되더라도 Kafka에 저장된 데이터를 통해 장애 복구 후 완벽한 데이터 복구 가능
    • 대량의 트래픽 유입 시에도 메시지 큐잉을 통해 분석 부하를 조절함으로써, 사용자 대시보드에 끊김 없는 실시간 분석 결과 제공
    • 수집과 분석 계층이 독립적으로 확장 가능해짐에 따라 전체 플랫폼의 안정성 강화

구현화면

-

References

  • 김진환. (2022). 태그 경로 및 텍스트 출현 빈도 기반 웹 크롤링 시스템 [석사학위논문]. 한국기술교육대학교.
  • 김진환, 김은경. (2021). 빈도 분석을 이용한 HTML 텍스트 추출. 한국정보통신학회논문지, 25(9), 1135-1141.
  • 김진환, 김은경. (2021). 태그 경로 및 텍스트 출현 빈도를 이용한 HTML 본문 추출. 한국정보통신학회논문지, 25(12), 1709-1715.
  • 김진환, 김은경. (2022). WCTT:HTML 문서 정형화 기반 웹 크롤링 시스템. 한국정보통신학회논문지, 26(4), 495-502.
  • GitHub. https://github.com/cerulean85/earthling-cube