크롤링 한 데이터를 어떻게 처리할까?

현 문제점 분석

현재 크롤링 데이터를 처리하면서 몇 가지 중요한 문제점들이 발생하고 있다.

 

사이트 간 데이터 형태의 불일치

사람인과 잡코리아의 데이터 구조가 조금 달라서 통합이 어렵다.

 

비정형 keyword 데이터

잡코리아에서 수집된 키워드 데이터는 정리되지 않은 형태로 제공된다.

 

불충분한 position 데이터

직무가 일괄적으로 "개발자"로 표기되어 있어 추가적인 분석 및 정리가 필요하다.

 

불완전한 데이터 처리 방법 필요

연봉 정보가 "면접 후 결정"이거나, 마감일이 없는 등 값이 추출되지 않는 데이터에 대한 처리를 고민해야 한다.

 

 

데이터 정형화 전략 구상

DB 내 정형화

데이터를 최종적으로 Elasticsearch로 전송하기 전에 DB 단계에서 정형화를 수행하자.

흐름 상 DB 정형화 -> Elasticsearch 동기화 -> 크롤링 순으로 진행하는 게 맞다.

크롤링 해오는 시점에 createdAt이 생성되니까, 정형화를 createdAt 기준으로 작업이 가능하다.

정형화 과정은 코틀린 기반 크롤링 서버를 통해 비동기적으로 또는 코루틴을 사용해 수행하면 성능 효율이 좋을 것으로 예상된다.

(또는 실시간 반영을 위해 크롤링 시점에 병렬적으로 수행할지도 고민거리이다. 하지만 지금 크롤링으로 테스트는 불가능한 상황이니, 실시간 반영까지 구현을 하게 된다면 커스텀 스케줄러를 이용해보자.)

 

AI 활용 가능성 검토

AI를 통해 정형화 작업(직무 분석, 키워드 정리 등)을 효율적으로 처리할 수 있지만, RPM(ai 분당 사용량)초과, 성능 및 일관성 문제로 모든 데이터를 매번 AI로만 수정하는 방식은 고민을 해봐야 한다.

특히나 정형화 작업을 비동기나 코루틴으로 처리하게 된다면 openai 사용량에 이슈가 있을거다.(내돈!!!)

따라서 정규표현식이나 .. 잘모르겠다!!!! 찾아봐야된다. 학습시켜야되나?

비정형 데이터 처리 방침

DB에서 비정형 데이터와 정형 데이터의 테이블을 따로 두자. 

정형화가 잘못되었을 때 롤백수단이 필요하다.

 

 

데이터 동기화 전략 구상

동기화 시기와 주기

하루 약 800건의 채용공고(대강 이 정도 올라오는 듯 하다)를 대상으로 하루 4회 정도 동기화를 수행한다고 가정하면, 한 번에 처리할 데이터는 약 200~300건 수준이다.

각 동기화 작업 시작 시점을 기준으로 최신 6시간 이내의 데이터를 정형화 및 Elasticsearch로 동기화해야 누락되는 데이터가 없다.

 

 

엘라스틱서치 활용 방식

Elasticsearch의 데이터 관리 범위

Elasticsearch는 마감 기한이 지난 채용공고도 유지할 필요가 있는가에 대해 생각해봐야 한다(북마크 조회 등 목적).

마감 기한이 지난 채용공고도 유지하는 방식을 택한다면 DB에 데이터가 늘어날 수록 마이그레이션 작업이 점차 길어지며, 굳이 엘라스틱서치에 담지 않아도 되는 정보를 담는 꼴이 된다.

 

DB와 Elasticsearch의 역할 분리

DB는 크롤링한 데이터를 정형화하여 저장하고, Elasticsearch는 조회 성능 향상 및 분석을 위한 최적화된 검색 엔진으로 활용하자.

 

 

메세지 브로커 활용?

Redis Stream 또는 기타 메시지 브로커

정형화된 데이터를 Elasticsearch에 비동기적으로 동기화할 때 메시지 브로커(Redis Stream, RabbitMQ, Kafka 등)를 사용하는 것이 성능과 확장성 면에서 유리하다.

하지만 적용 전 고려해야될 게 많다. 한번에 데이터를 얼마나 이동시킬지가 포인트가 된다.

 

 

크롤러 서버, 메인 어플리케이션 서버

크롤러 서버 구성

메인 어플리케이션 서버가 아닌 코틀린 기반 별도 크롤링 서버를 EC2 등 클라우드에 올려 필요 시 가동할 수 있도록 구성한다.

크롤러 서버는 클라이언트가 없어서 가용성이 100%가 아니어도 되기 때문에 로컬에 설치해도 될거다.

심지어 로컬호스트로도 RDS, Elasticsearch와 연결만 한다면 구동 가능하긴 하다..

 

메인 서버와의 역할 명확화

메인 서버는 사용자 요청 처리와 Elasticsearch 조회 작업을 담당하고,

크롤러 서버는 데이터 수집, 정형화, 동기화 등 비동기 작업을 전담하도록 분리한다.

 

 

결론 및 향후 계획

데이터는 DB에서 정형화를 완료한 뒤 Elasticsearch로 전달하는 방식이 가장 효율적이다.

크롤러 서버와 메인 어플리케이션 서버를 명확히 분리하여 효율성과 확장성을 동시에 확보한다.

AI 활용은 꼭 필요한 비정형 데이터에 한정해 성능 문제를 최소화한다.

 

1. 코틀린 기반 크롤러 서버에서 데이터를 DB에서 효율적으로 정형화하는 로직을 구현하자.

- 한 DB 내에서 테이블을 분리하여 관리하자.

- AI 사용은 가급적 최소화하자.

- 동기 vs 비동기 비교하고, 동시성 문제를 파악해보자.

 

2. 마찬가지로 크롤러 서버에서 정형화된 DB데이터를 ElasticSearch에 효율적으로 동기화하는 작업을 구현하자.

- 현재 소요시간은 단일스레드에서 1.2만건에 15초 정도다.

- 한번에 모든 데이터를 보낼 것인지, 마감된 채용공고를 제외하며 인덱스를 새로 갈아끼울 것인지 고민해보자.

그리고 여담으로 사람인한테 ip밴 당했다 눈물자국3000km

나 크롤링 엄청 천천히했는데

 

 

After 현실직시

못한다!!!!!!!!!!!!!!!!!!!!!!!

이 데이터 정형화 작업이 이렇게 어렵고 까다로운 작업인 줄은 몰랐다 검색도메인은 정말 어려운거구나

키워드도 중구난방에 도저히 못한다

일단 포지션은 title 이용해서 백엔드, 프론트엔드 둘로만 나눴다.
근데 도저히 키워드는.. 안된다 못하겠다 제대로 된 데이터 분석이 필요해..

 

나중에 관련도메인 일을 하게되면 파야되는 공부인거같다. 지금 주어진 리소스랑 내 지식으로는.. 어렵다

 

그리고 DB -> ElasticSearch migration도, 실시간 동기화가 조회수 반영 쪽에서 민감한 주제였는데(인기채용공고 업데이트 때문에)

조회수 담당자 분한테 해당 내용 토스하면서 마무리됐다..

테스트코드 쓰면서 서비스 마무리 해야겠다.