회사에서 판매하는 솔루션 중, ETL Batch 를 도와주는 솔루션이 있습니다. 또한 제가 속한 팀은 ‘데이터솔루션센터’의 R&D 팀으로 이러한 사내 빅데이터 솔루션들을 개발 및 고도화 하는 업무를 담당하고 있습니다. 저희 회사 솔루션은 종류별로 크게 (구)솔루션과, (현)솔루션으로 나뉘며, 그 안에 각각 ‘실시간 솔루션’ 과 ‘배치 솔루션’ 으로 나뉘게 됩니다.

물론 (구)솔루션은 이미 판매&구축 된 곳에서 가끔 유지보수만 진행하며, 2024년 기준으로는 (현)솔루션을 개발 및 판매하고 있습니다.

저는 그 (현)솔루션 중 배치 솔루션을 팀에서 함께 개발하였으며, Quartz 를 활용한 스케줄러 개발과, 작업 풀 관리를 돕는 풀 관리를 개발하게 되었습니다.

📚 1장 : 풀 관리가 필요한 이유 & 초기 개발 히스토리

이 이야기를 하기 위해서는 먼저 ETL 에 대하여 알아야 합니다.

ETL 은, Extract Transform Load 의 줄인 말로, 여러 소스의 데이터를 일관 된 단일 데이터 세트로 결합하여 DW 나 DL 등에 적재하는 프로세스입니다.

사내 솔루션은 이러한 ETL 프로세스를 활용한 솔루션입니다.

그렇기 때문에, 추출과 적재의 대상에 Connection 을 맺어야 하는 경우가 있는데, 각 소스마다 그것을 통제 할 수 있는 총량이 다르게 정해져 있음을 알아야 합니다.

예를들면, xx카드 관련 MySQL DB 의 TB_CARD 에 있는 데이터를 DW 로 옮기려고 합니다. 근데, 하지만 현재 작업을 제외하고도 xx카드 MySQL DB에 많은 작업들로 인하여 Connection 이 맺어져 있다면, 성능에도 문제가 생길뿐더러 심한경우는 Connection Timeout 이 발생할 수도 있습니다.

그런 경우를 사전에 대비하고 핸들링 하기 위해, 사용자가 커스텀하게 풀 사이즈를 지정하고 관리 할 수 있도록 하는 기능을 개발해야 했습니다.

( 물론, DB 뿐 아니라 File 이 있는 특정 서버나, DW, DL 에 대한 접근에도 한 번에 많은 I/O 가 발생하지 않도록 제어가 필요합니다. )

📚 2장 : 간단한 로직 & 동시성 이슈 제어를 위한 Lock ( feat. 이중화 서버 )

📚 3장 : MySQL 대신 Oracle 로 ?

📚 4장 : Spark Core Pool 관리

📚 5장 : 고도화 및 성능 튜닝

📚 6장 : 결론