헤드리스 데이터 아키텍처를 구현하는 방법

헤드리스(headless) 데이터 아키텍처를 사용하면 조직 전체적으로 강력한 데이터 액세스를 실현할 수 있다. 출발점은 시프트 레프트다.

헤드리스 데이터 아키텍처는 조직의 중심에서 데이터 액세스 계층을 공식화하는 것이다. 스트림과 테이블을 모두 포괄하는 이 아키텍처는 운영과 분석 사용 사례를 위한 일관적인 데이터 액세스를 제공한다. 스트림은 이벤트에 대한 시의적절한 대응을 위한 저지연 기능을 제공하고, 테이블은 지연은 높지만 배치 효율성이 매우 높은 쿼리 기능을 제공한다. 요구사항에 가장 잘 맞는 처리 헤드를 선택하고 데이터에 연결하기만 하면 된다.

ⓒ Getty Images Bank

헤드리스 데이터 아키텍처를 구축하려면 데이터 분석 평면 내부 깊은 곳에서 이미 수행 중인 작업을 파악하고 이를 왼쪽으로 옮겨야 한다. 데이터 정리, 구조화, 도식화와 같이 이미 다운스트림으로 하고 있는 작업을 가져와 업스트림 소스 시스템으로 푸시한다. 데이터 소비자는 운영과 분석, 그 외의 모든 작업에서 스트림과 테이블을 통해 제공되는 하나의 표준화된 데이터 집합에 의존할 수 있다.

우리는 헤드리스 데이터 아키텍처를 시프트 레프트 접근 방식을 통해 구현한다. 다음 차트는 전반적인 개념을 보여준다. 작업을 왼쪽으로 옮김으로써 다운스트림 비용을 대폭 줄일 수 있다.

ⓒ Confluent

시프트 레프트 접근 방식은 데이터를 생성, 액세스, 사용하는 데 있어 특히 전통적인 멀티 홉 접근 방식에 비해 더 간편하고 비용 효율적인 방법을 제공한다.

멀티 홉과 메달리온 데이터 아키텍처

대부분의 조직에는 추출-변환-로드(ETL) 데이터 파이프라인, 데이터 레이크, 데이터 웨어하우스, 또는 데이터 레이크하우스가 구축돼 있다. 분석 평면의 데이터 분석가에게는 운영 평면의 소프트웨어 개발자들이 사용하는 것과는 다른 전문화된 툴이 필요하다. "데이터를 왼쪽에서 오른쪽으로 옮기는" 이 전반적인 구조를 일반적으로 멀티 홉 데이터 아키텍처라고 한다.

메달리온 아키텍처는 멀티 홉 아키텍처에서 가장 인기 있는 형식이다. 메달리온 아키텍처에는 올림픽 메달 색으로 표현되는 세 가지 수준의 데이터 품질이 있다(브론즈, 실버, 골드). 브론즈 계층은 데이터 랜딩 존 역할을 하며 실버는 정제되고 잘 정의된 데이터 계층(2단계), 골드는 비즈니스 수준의 집계된 데이터 집합(3단계) 역할을 한다.

ⓒ Confluent

1단계에서 랜딩한 데이터는 일반적으로 비구조적인 원시 데이터이며 정제, 도식화, 표준화를 거쳐 2단계로 작성된다. 여기서 추가로 집계, 그룹화, 비정규화 및 처리를 거쳐 3단계 비즈니스별 데이터 집합을 형성해 대시보드, 보고서에 사용되고 AI와 머신 러닝 모델을 위한 학습 데이터를 제공한다.

ⓒ Confluent

멀티 홉 아키텍처의 문제점

첫째, 멀티 홉 아키텍처는 대부분이 주기적으로 트리거되는 배치 프로세스로 구현되므로 속도가 느리다. 데이터가 소스에서 브론즈로 이동해야 다음 홉이 시작될 수 있다.

예를 들어 15분 간격으로 브론즈 계층으로 데이터를 끌어온다면 각각의 후속 홉 역시 15분 간격이 한계다. 다음 단계로의 데이터 이동 속도는 가장 느린 부분에 의해 좌우되기 때문이다. 간격을 홉당 1분으로 줄인다 해도 골드 계층에서 데이터를 사용할 수 있으려면 처리 시간을 제외해도 최소 3분이 필요하다.

둘째, 멀티 홉 아키텍처에는 비용이 많이 든다. 각 홉이 데이터의 또 다른 복사본이고 따라서 이를 로드해서 처리하고 홉의 다음 단계로 쓰기 위해서는 처리 성능이 필요하기 때문이다. 이 비용은 빠르게 누적된다.

셋째, 멀티 홉 아키텍처는 불안정한 경향이 있다. 대체로 워크플로우의 다양한 단계, 소스 데이터베이스, 최종 사용 사례를 다양한 사람들이 소유하기 때문이다. 아키텍처에 균열이 발생하지 않도록 하기 위해서는 매우 강력한 조율이 필요한데, 실무에서 이는 확장하기가 어렵다.

넷째, 데이터 분석가가 자신의 데이터 확보를 책임지므로 비슷한 여러 데이터 파이프라인이 생성될 수 있다. 소유권 분산 문제를 방지하기 위해 각 팀이 자체 맞춤형 파이프라인을 구축할 경우 비슷한 파이프라인의 난립으로 이어질 수 있다. 비슷하지만 다른 파이프라인과 데이터 집합 문제는 회사의 규모가 클수록 더 흔히 나타난다. 사용 가능한 모든 데이터 집합을 찾기가 어려울 수 있다.

여기서 다섯 번째 문제, 비슷하지만 다른 데이터 집합이 발생한다. 왜 여러 데이터 집합이 있을까? 어느 것을 사용해야 할까? 이 데이터 집합은 여전히 유지 관리될까, 아니면 아직 주기적으로 업데이트되지만 아무도 감독하지 않는 좀비 데이터 집합일까? 중요한 계산 작업이 있는데, 동일해야 하지만 실제로는 그렇지 않은 여러 데이터 집합에 의존하는 탓에 계산 결과가 상충하는 경우 이 문제가 불거진다. 상충하는 보고서와 대시보드 또는 지표를 고객에서 제공할 경우 신뢰를 잃게 되고 최악의 경우 비즈니스를 망치거나 소송에 휘말릴 수도 있다.

상기한 모든 문제를 해결한다 해도(지연을 줄이고 비용을 낮추고 중복되는 파이프라인과 데이터 집합을 제거하고 문제 해결 작업을 없애는 등) 운영 측에서 사용할 수 있는 것은 아직 아무것도 제공하지 않은 상태다. 운영 부서는 여전히 ETL의 업스트림에서 스스로 알아서 해야 한다. 모든 정리, 구조화, 리모델링, 배포 작업은 데이터 분석 영역의 사람들에게만 유용하기 때문이다.

헤드리스 데이터 아키텍처를 위한 시프트 레프트

헤드리스 데이터 아키텍처를 구축하려면 조직에서 데이터를 순환, 공유, 관리하는 방법을 재고해야 한다. 즉, 시프트 레프트가 필요하다. 다운스트림에서 ETL->브론즈->실버 작업을 추출해서 데이터 제품 내부의 업스트림, 즉 소스에 훨씬 더 가까운 곳에 배치한다.

ⓒ Confluent

주기적인 ETL로 생성되는 데이터 집합의 신선도는 아무리 짧아도 몇 분 수준이지만 스트림 우선 접근 방식은 데이터 제품에 1초 미만의 데이터 신선도를 제공한다. 시프트 레프트를 통해 회사 전체에서 더 저렴하고 쉽고 빠르게 데이터에 액세스할 수 있다.

데이터 제품으로 헤드리스 데이터 아키텍처 구축

헤드리스 데이터 아키텍처에서 논리적인 데이터의 최상위 수준은 데이터 제품이다. 데이터 메시(data mesh) 접근 방식을 통해 이미 이 개념에 익숙한 사람도 있을 것이다. 헤드리스 데이터 아키텍처에서 데이터 제품은 스트림(아파치 카프카 기반) 및 관련 테이블(아파치 아이스버그 기반)로 구성된다. 스트림에 작성되는 데이터는 자동으로 테이블에도 추가되므로 카프카 주제 또는 아이스버그 테이블로 데이터에 액세스할 수 있다.

다음 그림은 소스 시스템에서 생성된 스트림/테이블 데이터 제품을 보여준다. 먼저 스트림에 데이터를 쓴다. 이후 선택적으로 스트림에서 데이터를 변환해서 최종적으로 아이스버그 테이블로 구체화할 수 있다.

ⓒ Confluent

스트림(카프카 주제)을 사용해 주문 관리, 배차, 금융 거래와 같은 저지연 비즈니스 작업을 구동할 수 있다. 또한 배치 쿼리 헤드를 아이스버그 테이블에 연결해서 일일 보고, 고객 분석, 정기적인 AI 학습과 같이 지연이 큰 워크로드를 계산할 수도 있다.

데이터 제품은 다른 팀 및 서비스와 함께 공유하고 재사용하도록 만들어지는 신뢰할 수 있는 데이터 집합이며 작업 및 서비스에 필요한 데이터를 가져오는 과정을 간소화하기 위해 책임과 기술, 프로세스를 공식화한 것이다. 데이터 제품을 '재사용 가능한 데이터 자산'이라고도 하는데, 어떻게 부르든 공유와 재사용이 가능한 표준화된 신뢰할 수 있는 데이터라는 본질은 동일하다.

데이터 제품 생성 로직은 소스 시스템에 따라 크게 달라진다. 예를 들면 다음과 같다.

• 아이스버그 테이블로 손쉽게 구체화가 가능한 카프카 주제에 이벤트 기반 애플리케이션이 직접 출력을 쓴다. 데이터 제품 생성 로직은 예를 들어 기밀 필드 가리기 또는 완전한 제거와 같이 최소화될 수 있다.
• 일반적인 요청/응답 애플리케이션은 변경 데이터 캡처(CDC)를 사용해서 기반 데이터베이스에서 데이터를 추출해 이벤트로 변환하고 카프카 주제에 쓴다. CDC 이벤트에는 소스 테이블을 기반으로 한 잘 정의된 스키마가 포함된다. 커넥터 자체 또는 플링크SQL(FlinkSQL)과 같은 더 강력한 것을 사용해서 데이터 변환을 추가로 수행할 수 있다.
• SaaS 애플리케이션은 스트림에 쓰기 위해 카프카 커넥트를 사용해 주기적으로 엔드포인트를 폴링해야 할 수 있다.

스트림 우선 데이터 제품의 좋은 점은 스트림에 쓰기만 하면 그 외의 요구사항은 없다는 것이다. 스트림과 테이블에 동시에 쓰기 위해 분산 트랜잭션을 관리할 필요가 없다(이 작업은 제대로 하기가 상당히 어려우며 속도도 느릴 수 있음). 대신 카프카 커넥트, 또는 컨플루언트 테이블플로우(Tableflow)와 같은 독점 SaaS 스트림-테이블 솔루션을 통해 스트림에서 추가 전용 아이스버그 테이블을 만든다. 내결함성과 정확히 한 번 쓰기는 데이터 무결성을 유지하는 데 도움이 되므로 스트림에서 읽든 테이블에서 읽든 동일한 결과를 얻게 된다.

시프트 레프트를 위한 데이터 집합 선택

시프트 레프트는 양자택일의 방식이 아니라 사실 고도로 모듈화되고 점진적인 방식이다. 어느 부하를 왼쪽으로 옮기고 그대로 둘지를 선택할 수 있다. 병렬 시프트 레프트 솔루션을 설정하고 검증한 다음 결과가 만족스러우면 기존 작업을 전환할 수 있다. 프로세스는 다음과 같다.

1. 분석 평면에서 일반적으로 사용되는 데이터 집합을 선택한다. 자주 사용될수록 시프트 레프트에 더 적합한 후보다. 오류의 여지를 거의 둘 수 없는 비즈니스 핵심 데이터(예를 들어 청구 정보) 역시 시프트 레프트 대상으로 적합하다.
2. 운영 평면에서 데이터의 소스를 파악한다. 이는 데이터 스트림을 만들기 위해 필요한 시스템이다. 참고로 이 시스템이 이미 이벤트 기반이라면 스트림 사용이 이미 가능한 상황일 수 있고, 이 경우 아래 4단계로 건너뛸 수 있다.
3. 기존 ETL 파이프라인과 병렬로 소스-스트림 워크플로우를 만든다. 카프카 커넥터(예: CDC)를 사용해 데이터베이스 데이터를 이벤트 스트림으로 변환해야 할 수 있다. 또는 스트림에 직접 이벤트를 생성하는 방법을 선택할 수도 있다. 소스 데이터베이스와 일관성을 유지하도록 데이터 집합 전체를 써야 한다는 점만 주의하면 된다.
4. 스트림에서 테이블을 만든다. 카프카 커넥트를 사용해서 아이스버그 테이블을 생성하거나, 아이스버그 테이블을 제공하는 자동화된 서드파티 독점 서비스를 사용할 수도 있다. 참고로, 카프카 커넥트를 사용하는 경우 데이터의 복사본이 아이스버그 테이블로 작성된다. 데이터의 또 다른 복사본을 만들지 않고 카프카 주제를 아이스버그 테이블로 스캔하는 기능을 제공하는 써드 파티 서비스가 조만간 등장할 것으로 예상된다.
5. 테이블을 실버 계층의 데이터와 함께 기존 데이터 레이크에 연결한다. 이제 새 아이스버그 테이블이 기존 데이터 집합의 데이터와 일치하는지 검증할 수 있다. 결과가 만족스럽다면 배치 방식으로 생성된 기존 테이블에서 데이터 분석 작업을 마이그레이션하고 해당 테이블은 사용을 중단하도록 설정한 다음 편한 시간에 제거하면 된다.

그 외의 헤드리스 데이터 아키텍처 고려 사항

이전 기사에서 살펴본 바와 같이 데이터를 복사하지 않고도 아이스버그 테이블을 호환되는 모든 분석 엔드포인트에 연결할 수 있다. 데이터 스트림도 마찬가지다. 두 경우 모두 처리 헤드를 선택해서 필요에 따라 테이블 또는 스트림에 연결하기만 하면 된다.

시프트 레프트는 일반적인 복사-붙여넣기, 멀티 홉, 메달리온 아키텍처에는 없는 몇 가지 강력한 기능도 사용할 수 있게 해준다. 하나의 논리 지점에서 스트림 진화와 테이블 진화를 함께 관리하고 스트림 진화가 아이스버그 테이블을 손상시키지 않는지 확인할 수 있다.

작업이 데이터 분석 영역 밖 왼쪽으로 이동됐으므로 데이터 검증과 테스트를 소스 애플리케이션 배포 파이프라인에 통합할 수 있다. 이렇게 하면 코드가 프로덕션으로 들어가기 전에 손상이 일어나지 않도록 할 수 있으므로 오랜 시간이 지난 후에 다운스트림에서 손상된 부분을 감지하게 될 일이 없다.

마지막으로, 테이블이 스트림에서 파생되므로 한 지점에서만 수정하면 된다. 스트림에 쓰는 모든 내용은 테이블로 전파된다. 스트리밍 애플리케이션은 수정된 데이터를 자동으로 수신해서 스스로 수정할 수 있다. 단, 테이블을 사용하는 주기적인 배치 작업은 찾아서 다시 실행해야 한다. 그러나 이 작업은 기존 멀티 홉 아키텍처에서도 어차피 해야 할 일이다.

헤드리스 데이터 아키텍처는 조직 전체적으로 강력한 데이터 액세스를 실현해준다. 출발점은 시프트 레프트다.
editor@itworld.co.kr

Adam Bellemare editor@itworld.co.kr
저작권자 한국IDG & ITWorld, 무단 전재 및 재배포 금지