현재 삼성전자에는 천 개가 넘는 서비스의 데이터가 조직별로, 분산되어 운영되고 있습니다. 내가 원하는 데이터를 찾기 위해선, 각 서비스 담당자를 일일이 찾아다니며 어떤 데이터가 있는지 물어야 하는 상황입니다. 하지만 DIS를 활용하면 당사 모든 데이터를 한 곳에서 쉽게 찾을 수 있습니다. 그러나, 찾아낸 데이터를 바로 이해하고 활용하기란 쉽지 않습니다. 사용자는 여러 쿼리를 시도해보며 데이터가 어떻게 구성되어 있는지, 어떤 데이터를 결합해서 사용해야 하는지, 등을 알기 위해 많은 시간을 소모해야 합니다. DIS는 이런 어려움을 해결하고자, 다양한 데이터 Knowledge를 제공하고 있습니다.



DIS 기본구조

먼저 DIS는 검색을 위해, 전사 모든 데이터의 메타 정보를 수집하는, Metadata 파이프라인이 필요 합니다. 사내 각 서비스의 DB에서, 하루 한 번 샘플 데이터를 수집하여 저장하고, GCP Composer 기반의 파이프라인을 활용하여 Metadata를 추출합니다. 이렇게 수집된 Metadata는, Neo4j(GraphDB)에 저장되며, Elastic Search 기반의 검색 엔진에 인덱싱 됩니다. 이후 AI를 활용하여 데이터 추가 생성하여 Knowledge를 풍부하게 하고, 사용자의 활동 이력을 주기적으로 수집하여 Knowledge를 추가합니다. 또한, 대규모 시스템의 안정적인 운영을 위해, Bigquery에 Metadata의 통계를 수집하고, 개선에 활용합니다.



검색을 위해서는 매일 500만개 이상의 Sample data를 수집하고, Metadata를 추출해야 합니다. 이를 위해 지속적인 데이터 증가에 대응 가능한 확장성 높은 파이프라인이 필요합니다. 데이터의 이해를 위해 8천만개 이상의 컬럼에 대한 Knowledge가 필요하지만, 사람이 수동으로 만들 수는 없습니다. 대규모 데이터에 대해 AI를 활용하여 Knowledge를 생성할 수 있어야 합니다. 또한, 개인정보 여부도 컬럼 단위로 판단해야 하는데, 이것 또한 AI 활용이 필수적입니다. 이런 어려움들을 구체적으로 어떻게 해결했는지 설명 하겠습니다.

데이터 스케일이 폭발적으로 증가하면서, 우리 Airflow 파이프라인은 전체 데이터 처리 과정에 큰 영향을 미치는 스케줄링 지연이 발생했습니다. 

기존 파이프라인은 수집할 DB 1개마다, DAG 1개가 Dynamic하게 생성되고, 이를 주단위로 scheduling 하여 재사용하는 구조였습니다. 하지만 요구사항이 변화하면서 데이터 수집 주기가 Weekly에서 Daily로 변경되고, 수집해야 할 DB종류가 많아지면서 DAG의 수가 수십배가 늘어났습니다. Airflow Scheduler는 생성된 DAG인스턴스들을 주기적으로 스캔하면서 실행 여부를 결정하는데요, 일 단위 수집으로 바뀌면서 Scheduler는 기존보다 7배 더 많은 작업을 처리해야했고, 이러한 부하로 인해 Scheduling 지연이 발생했습니다. 또한 DAG의 수가 많아지면서 관리도 어려워졌을 뿐만 아니라, Worker가 동시에 처리해야 하는 Task의 수가 기하급수적으로 증가하여, 메타데이터 수집이 지연되기 시작했습니다. 

이를 개선하기 위해, DB 수집 이벤트를 발생시키고, 이 모든 이벤트를 처리할 수 있는 범용적인 로직을 포함한 단일 DAG로 통합하였습니다. 개선된 구조의 장점으로 Scheduler의 부하가 크게 감소하였습니다. 단일 DAG로 통합함으로써, Scheduler가 파싱하고 관리해야 할 DAG의 수가 현저히 줄어들었습니다. 이로 인해 스케줄링 지연과, 상태 관리 문제가 줄어들어 메타데이터 적재 속도가 빨라졌습니다. 그리고 Worker의 효율성이 증가하였는데요, 하나의 DAG에서 다양한 이벤트를 모두 처리함으로써, Worker는 코드 캐시를 활용해 메모리 사용량과 로딩 시간을 절약할 수 있었습니다.



그 결과, 파이프라인은 더 많은 데이터를 처리하고 적재할 수 있게 되었지만, 이 때문에Metadata를 저장하는 우리 Main DB에 큰 부하가 발생하였습니다. Meta 파이프라인을 통해 수집된 정보는 Graph DB인 Neo4j에 저장이 됩니다. 이것은 전사 데이터의 효율적인 활용을 위해, 데이터간의 관계 및 패턴 탐색이 필요하기 때문d이었습니다. 예를 들어, 특정 데이터의 네트워크를 분석하거나, 패턴을 추적하는 등의 결과를 도출하는데 Neo4j가 매우 효율적이였기 때문입니다.

Neo4j를 데이터 검색에 사용하는게 만능처럼 보이긴 하지만, 사실 여기에서도 큰 이슈가 있었습니다. Neo4j는 Graph DB이기 때문에, 데이터의 일관성을 보장하기 위해 쓰기 작업 시, 연결된 모든 Node와 Relation에 Lock을 걸고 있습니다. 특히 동일한 부모 Node에, 여러 자식 node가 있는경우, 서로 다른 쓰기 작업이 발생하면, 부모 노드에 대한 Lock Contention이 일어날 수 있습니다. 이러한 Lock은 동시성 문제를 방지 해주기는 하지만, 특히, 다수의 쓰기 작업이 “동시에” 발생하면, 시스템 성능이 크게 저하되었습니다. 우리는 Neo4j에 약 3억 개의 노드를 가지고 있기 때문에, 이 문제를 반드시 해결해야만 했습니다.

우선, 모든 데이터를 DB에 쓰는것이 아닌, 변경되는 metadata에 대해서만 쓸 수 있도록 하였습니다. 이를 통해, DB I/O가 감소하여, 메인 DB에 대한 전체적인 성능을 향상시킬 수 있었습니다. 

두 번째로, Neo4j의 Write Performance를 해결하기 위해 Pub/Sub을 사용했습니다. Neo4j는 쓰기 작업 중 부모 Node에 Lock을 걸기 때문에, 다수의 쓰기 작업이 발생할 경우 성능저하가 발생할 수 밖에 없습니다. 따라서, Neo4j의 쓰기 작업을 조절하기 위해 Google Cloud Pub/Sub을 사용하여 이벤트 기반 아키텍처로 전환했습니다. Micro Service에서는 직접 Neo4j에 쓰기 트랜잭션을 수행하지 않고, Pub/Sub 이벤트를 기반으로 Application간 느슨한 결합을 통해 쓰기 작업을 수행하여 성능을 개선하였습니다. 

마지막으로, Neo4j 트랜잭션을 최적화하였는데요, 한 번의 트랜잭션에서 처리하는 Node와 Relation수를, 최대한 작게 조절함으로써, Lock Contention을 피하고 성능을 최적화할 수 있었습니다. 또한, 큰 트랜잭션은 더 많은 Lock을 필요로 하기 때문에, 여러 개의 작은 트랜잭션으로 분할하여 문제를 해결할 수 있었습니다.



LLM 기반 Description 자동 생성

원하는 데이터를 더욱 잘 찾기 위해 LLM을 기반으로 description을 만들었습니다. 실제로 우리가 수집하는 삼성전자 데이터 중 description이 기재되어 있는 비율은 약 1.5%에 불과합니다. 그 말은, 사용자가 원하는 데이터를 DIS에서 찾기도 힘들 뿐만 아니라, 우연히 찾았다 하더라도, 이게 무슨 데이터지? 하며 활용하기에도 어렵다는 것입니다. 그리고 테이블과 컬럼에 대한 어떠한 설명없이, 해당 테이블에 어떤 데이터가 들어있는지 파악하기엔, 너무나도 어려운 일입니다.

따라서 저희는 LLM을 활용하여 테이블과 컬럼의 description을 생성했습니다.  예를 들어, 핸드폰 번호가 들어있는 데이터를 찾는다고 했을 때, 모든 DBA분들께서, 핸드폰 번호가 들어있는 colum의 이름을  phone_number라고 선언했다면 크게 문제가 되지 않았겠지만, 실상은 그렇지 않았고, 데이터를 찾기 위해 phone_number, p_num_txt와 같이 Column 혹은 Table의 이름을 정확히 알고 검색해야만 했습니다. 하지만 LLM으로 Description이 풍부해지면서, “전화번호”라고 검색해도, 이제는 원하는 데이터가 들어있는 테이블을 “키워드” 기반으로 손쉽게 찾을 수 있게 되는 것입니다. 

그렇다면 LLM을 통해 Description을 어떻게 만들었을까요? 

우선, Meta Store에서 테이블이나 컬럼 정보와 같은 다양한 메타데이터를 추출하고 이를 정제하여 프롬프트에 삽입하는 과정을 거치게 됩니다. 이때 프롬프트 디자인은 다음과 같이 구조적으로 이루어졌는데요, 사실 LLM을 통해 description을 만드는건 매우 어려운 일이였습니다. 우리는 LLM을 서비스와 어플리케이션에 활용하기 때문에, 지속해서 원하는 결과를, 그리고 항상 일관성 있게 만들어주는 것이 중요했습니다.

따라서, 항상 일관성 있는 description 품질을 유지하기 위해서, 프롬프트 엔지니어링을 통해 프롬프트 디자인을 하는 것도 있었지만, 항상 같은 방식으로 동일한 결과를 보장할 수는 없음을 이해하고, 응답 형식을 구체적으로 작성하도록 하는 것이 매우 중요했습니다. 이렇게 우리는 LLM을 활용해 데이터 검색 경험을 혁신적으로 개선하였습니다.



Query History 활용한 교차분석 테이블

DIS에서는 Query History를 분석하여, joinable한 테이블을 찾을 수 있도록 지원하고 있습니다. 보통 개별 테이블만으로는 충분한 인사이트를 얻기 어려운 경우가 많고, 다양한 테이블을 결합하면 더 깊은 분석이 가능해지기 때문입니다. 또한 사용자가 직접 일일이 테이블을 찾고, 그것이 joinable한지 확인 하는것은 시간과 노력이 너무 많이 드는 일입니다. 자동화된 joinable table detection은 이러한 과정을 크게 단축시켰습니다. 이 과정으로 데이터 카탈로그내의 구석구석 모든 데이터를 최대한 활용할 수 있도록 유도 할 수 있게 되었고,  조직 내 데이터 자산의 가치를 극대화 하는데 기여 할 수 있었습니다. 



AI 기반 개인정보(PII) 탐지 FLOW

마지막으로, 데이터의 안전한 활용을 위해 개인정보가 포함된 데이터에 대해 강화된 권한 관리와 암호화가 필요합니다. 이를 위해 우리가 다루고 있는 데이터에 대한 개인정보 탐지는 필수적입니다. 우선 신규 테이블이 생성되면, 이를 감지하여 자동으로 개인정보 탐지 로직이 실행됩니다, 주소나 이름과 같이 패턴이 불명확한 경우에는 머신 러닝을 활용하고, 계좌번호나 처럼 패턴이 일정한 경우에는 정규표현식을 사용하여 탐지하고 있습니다. 서비스 소유자는 자동 탐지된 개인정보를 변경하거나, 확정하는 프로세스를 도입하여 보다 더 안전한 개인정보 관리 또한 진행하고있습니다.

데이터의 양이 증가함에 따라 시스템이 점점 느려지는 문제가 발생하고 있습니다. 이를 해결하기 위해 확장성이 높은 시스템을 위해 노력하고 있습니다. 사용자들은 데이터 이해하고 활용하기 위한 Knowledge가 여전히 부족하다고 느낍니다. 이를 개선하기 위해 더 많은 Knowledge를 제공할 계획입니다. 사용자들이 원하는 데이터를 찾는 것에 어려움을 겪고 있습니다. 이를 해결하기 위해 검색 정확도를 향상시키는 작업을 진행 중입니다. 

Big Data Center BD플랫폼팀의 박병현, 박기철이였습니다. 긴 글 읽어주셔서 감사합니다.