- 작성자 : macle
- 작성자 블로그: https://macle.dev
- 원본경로: https://macle.dev/posts/parallel-processing/
개요
최근에는 병렬처리쪽은 대부분 GPU 로 진행합니다. 적당한 그래픽카드도 쿠다프로세스가 수천개씩 있기 떄문입니다. CPU 는 지금 시점에서 괜찮은것을 구매해도 12코어 24Thread 정도 입니다.
그래서 머신러닝의 대양한 학습은 대부분 GPU를 이용하는데 꼭 CPU가 필요한 부분도 있습니다. 데이터정제, 데이터표준화, 문장구분, 토크나이징(형태소분석), 개체명인식, 자연어 룰 패턴 인식과 관련된 전처리 부분에서는 CPU를 사용합니다.
이 post는 데이터 전처리 부분에서의 CPU를 활용한 빅데이터 병렬처리를 개발하게 된 경험에 대한 내용 입니다.
개발하게 된 계기
문제
개발 할 당시에는 2017년 이었는데 이때에는 빅데이터처리 = 하둡애코시스템 이렇게 당연히 받아드리는 시기였습니다.
당시에 기술연구소에서 자연어처리 관련된 AI 플랫폼을 개발하고 있었는데 SI프로젝트 팀에서 연락이 왔습니다. 계약할때 저희쪽 시스템은 하둡애코시스템을 이용하는 신청을 하지 못해서 20대 가량으로 구성된 하둡환경을 사용하지 못하는 상황인데…
처리 조건은 아래와 같은 상황이었습니다
- 일 천만건 가량의 텍스트문서
- STT, VOC, 채팅
- 단어 사전정보 및 도메인사전, 룰베이스 분류패턴등, 개체명 인식 관련된 알고리즘 메타데이터 등이 약 2500만 row
- 문서 한건을 분석하는데 사용되어야 되는 기본 정보
- 복잡한 분류를 패턴 5만개
- 복잡한 분류룰은 긍정문장을 파악할때 앞에 상품에 해당하는단어 의 4글자안에 긍정에 포함하는 단어가 나오고, 반전에 해당하는 단어가 나오지 말아야한다 등과 같은 복잡한 패턴식
- 하나의 문서가 분석되면 약 1000건 이상의 row가 생성되는데 일부 row는 다음 분석업체를 위해 하둡애코시스템에 저장하고, 통계성 결과를 제공해야함
- 통계성 결과또한 카테고리 별로 분류한 후 통계를 하여햐하는데
- 카테고리가 수백개 여서 수백개를 각자 통계해야함
- 4시간안에 저장까지 완료되어야 하므로 분석은 2시간안에 되어야함
원천 데이터가 넘어오고 필요한 정보를 생성해서 모델을 만들거나 활용하는쪽에 전달해야 했는데 저러한 기능을 병렬처리 없이 1 thread 로 분석하면 24시간이 돌아도 끝나지 않을 기능이었습니다.
우리쪽에서 일을 처리하지 못하면 뒤에 다른업체가 하고 있는일이 잘 되지 않는 상황이었죠.. 계약부터 다시 해야 한다는 등의 많은 의견이 있는 상황에서 기술연구소에서 해결이 가능한지 들어온 업무였습니다.
그래서 사용할 수 있는 서버를 조사해보니 그래도 다행인부분이 4대의 서버가 계약되었는데 24 core 48 thread 가 2대 12 core 24 thread 2대 총4대의 서버가 memory, cpu 성능이 좋앗습니다.
해결방안
그래서 아래와 같은 방향으로 개발을 진행하였습니다.
- 문서 한건을 분석할때마다 2500만 row를 사용하므로 2500만 row의 메타정보는 in memory로 구성
- 싱글턴 패턴으로 메모리에 올려놓게 하고 메타 데이터가 변경되면 DB를 감시하게해서 메모리 데이터 변경
- 위 구성정보는 인스턴스가 올라갈때 로딩
- 하나의 문서당 복잡한 룰패턴이 5만개이상 점검해야되는데 관련부분 필수조건을 활용하여 index 기능을 만들어서 체크해야하는 건수를 줄임
- thread 병렬처리
성공적인 결과
개발이 완료되었을때 하루종일 돌아도 끝나지 않았던 기능이 1시간도 되지않아서 분석이 종료되었고 프로젝트는 성공적으로 종결되었습니다.
하둡에코시스템을 사용하지 않은 이유
계약을 다시 진행하게하여 spar k를 이용할까도 고민해 보았지만 위에 방식을 직접 개발하였는데 이는 하둡애코시스템을 활용해도 첫번째 조건인
- 문서 한건을 분석할때마다 2500만 row를 사용하므로 2500만 row의 메타정보는 in memory로 구성
- 위 문제를 해결할 방법이 없어보였기 떄문입니다.
(사실 계약을 다시 진행하는건 무적 어렵습니다.. 을에 입장이기에…)
개발
아래방식으로 진행되게 프로그램을 개발 하엿습니다.
스토리지 생성
- 사용 할 thread count, memory 를 설정한후 복잡한 알고리즘을 해결하는 성능측정
- 원문이 들어오면 성능측정된 점수대로 문서를 나누어서 스토리지 생성
- 분석이 빨리 끝나는 서버는 다른서버의 데이터를 분석할 수 있도로 다른 서버의 데이터도 일부 복제(리플레카)
- 여러개의 thread 에서 동시에 접근해야 하므로 파일을 특정 사이즈로 분할 (샤딩)
데이터 분석 및 통계
- 위에서 생성한 스토리지를 활용하여 job을 생성하여 동작
- 하나의 job은 분류결과, 토크나이징결과, 패턴인식결과 … 들을 만들거나 통계를생성 함
- 하나의 job은 설정된 자원을 사용하여 업무를 수행
- 즉 하나의 스토리지를 여러 job을 생성해서 분석
- 하나의 job이 수행될때 서버의 대부분의 자원을 사용하므로 job은 Q에 저장하여 실행
어려웠던 문제들
위에 내용을 보면 간단해보이지만 실제로 구현한양은 엄청 났습니다. 당시에 이러한 기능을 제공하는 플랫폼을 혼자 만들었는데 제가 진행해본 개발중 범위가 큰편에 속하는 개발이었습니다.
여러 thread 를 활용하므로 동기화(synchronized) 구간을 줄이기 위해서 이부분을 최소화 시켰는데 이러한 작업중에 DeadLock 을 발생시키는 코드가 종종 생겼습니다.
- DeadLock 교착상태
- A thead 는 B thread 를 기다리고 B thread 는 A thread 를 기다리는 상태
- 무한대기 상태
개발당시에는 잘되다가 운영환경에서 DeadLock 이 발생하였을때는 원인 찾기가 어려운 경우가 많았고, job을 감시하여 DeadLock 을 강제로 해제시키는 코드를 넣을까도 생각해 봤지만 이부분도 문제가 될것같아 고생하면서 찾은 기억이 납니다
값진 경험
이런 개발을 했던 경험은 지금 주식분석프로그램을 만드는 데에도 큰 도움이 되고 있습니다. 주식분석 알고리즘도 다양한 형태를 자동으로 벡테스팅 하여 수천개의 종목을 분석해야하 하는 경우에 분산처리를 직접 짜는게 편한경우가 많더군요.
기술연구소에 속하면 저런 경험을 종종하게 되는데, 하둡애코시스템을 더 깊게 이해하게 되기도 하였습니다.
개발하기전에도 하둡애코시스템을 활용만 했지 큰 이해는 하지 않고 사용했는데, 직접 설계하여 만들고 비교해보니 비슷한 고민을 한부분도 많은걸 발견 했습니다.
개인적인 성향이 직접 만드는걸 재밌어 하는 성향도 있어서 하둡애코시스템 원리를 공부 하지않고 게발을 시작했었는데, 힘들지만 좋은 경험 이었던 프로젝트라 기억이 납니다.