데이터 플랫폼 설계와 구축 | 03. 빅3의 활용과 확대 | 수집, 저장, 처리, 메타데이터 계층 설계시 고려사항

현대 플랫폼 아키텍처가 가진 계층들과 각각의 역할을 설명한다. 이와 더불어 고속/저속 스토리지, 스트리밍과 배치 방식 비교, 메타데이터 관리, ETL 오버레이 , 데이터 소비자의 개념도 설명한다.

4계층으로 구성된 데이터 플랫폼

1. 수집
2. 저장
3. 처리
4. 서비스
5. 클라우드 데이터 웨어하우스 / APIs / 데이터 내보내기

데이터 플랫폼의 6계층

수집 : 스트리밍 데이터와 배치 데이터를 수집해서 각각 다르게 처리한다

• 스트리밍 데이터 : 고속 스토리지
• 배치 데이터 : 저속 스토리지 / 데이터 레이크에 접속해 활용

1. 스트리밍 모드 , 배치 모드에서 다양한 데이터 소스로 보안 연결할 수 있어야 한다2
2. 데이터 변환이나 데이터 포맷 변환 과정을 크게 거치지 않고도 소스 시스템에서 데이터 플랫폼으로 데이터를 전송할 수 있어야 하며, 데이터 레이크에서 원시 데이터를 보존할 수 있어야 한다. 나중에 데이터를 재처리해야 할 경우, 소스 시스템에 다시 연결하지 않아도 재처리가 가능할 수 있도록 구축해야 한다.
3. 메타데이터 저장소에 수집 통계와 수집 상태를 등록할 수 있어야 한다. 예를 들어, 스트리밍 데이터 소스인 경우에는 특정 시간 가간격 동안 데이터 수집량을, 배치 방식의 경우에는 배치당 데이터 수집량을 추적하는 것이 중요하다

산업의 방향이 실식나 솔루션으로 나아가고 있는 방향임에는 동의하지만 현재의 상황 또한 무시할 수 없다. 현재 기존 데이터 저장소는 배치 데이터 액세스만 지원하는 경우가 많다.

배치 수집과 스트리밍 수집 둘 다 지원하도록 데이터 수집 계층을 일급 객체로 구축하는 것이 견고한 아키텍처 사고다. 이는 곧 데이터 소스 수형에 따라 적합한 툴을 사용하겠다는 의미다.

하둡 기반 플랫폼에서 사용할 수 있는 스트리밍 프레임워크의 한계 때문에 정확성을 100% 보장하지 못했다. 즉, 고속 경로에서 처리된 결과 값이 불일치할 가능성이 있었기 때문에 배치 경로에서도 동일한 데이터를 처리한 후에 대사reconcile 단계를 거쳐 정확성이 100%인 결과값을 만드는 구조다.

오늘날 구글의 데이터 클라우드 데이터플로우와 같은 클라우드 서비스나 카프카 스트림즈와 같은 오픈 소스 솔루션에서는 이런한 한계점을 거의 극복한 상태다.

• 플러그형 아키텍쳐 : 새로운 유형의 데이터 소스가 항상 추가된다. 모든 데이터 소스에 대한 커넥처를 수집 툴이나 수집 서비스에서 제공할 것이라 기대하는 것은 비현실적이다. 데이터 수집 계층은 큰 노력 없이 새 커넥처 유형을 추가할 수 있는 구조여야 한다.
• 확장성 : 데이터 수집 계층은 대량의 데이터를 처리할 수 있어야 하믈, 컴퓨터 용량의 복수 개의 서버로 스케일 아웃시킬 수 있어야 한다. 이런 규모가 당장 필요하지 않을 수 있지만, 데이터 수집 계층의 확장이 필요할 때 데이터 수집 계층을 재구축하지 않아야 한다. 항상 이러한 부분들을 미리 계획해서 솔루션들을 선정해야 한다.
• 고가용성 : 데이터 수집 계층은 개별 컴포넌트의 장애 유현들, 즉 디스크 장애, 네트워크 장애, 가상 시스템 전체 다운 등을 고려한 장애 대응 채계를 갖고 있어야 하며 장애 대응 상황에서도 데이터를 데이터 플랫폼으로 전달할 수 있어야 한다.
• 관측 가능성 : 데이터 수집 계층은 데이터 처리량, 지연 시간과 같은 중요한 메트릭을 외부 모니터링 툴로 노출시켜야 한다. 이러한 메트릭의 대부분은 이 장 두시부분에서 논의할 중앙 메타데이터 저장소에 저장되어야 한다. 메모리, CPU 또는 디스크 사용률과 같은 기술적 메트릭들은 모니터링 툴에 직접 노출되기도 한다. 데이터 플랫폼으로의 데이터 이동에 대한 가시성을 호가보하고자 할 경우, 데이터 수집 계층이 블랙박스가 돼서는 안된다. 데이터 이동에 대한 가시성 확보는 수집 계층의 모니터링과 문제 해결 목적을 위해 중요하다.

저장 : 고속 스토리지와 저속 스토리지

데이터 수집 계층에는 임시 캐시를 사용할 수는 있지만, 일반적으로 데이터 자체를 저장하고 있지 않기 때문에, 일단 데이터가 수집 계층을 통과한 후 안정적으로 저장될 수 있어야 한다.

저속 스토리지는 대용량 파일(수집 MB 이상)에 최적화된 클라우드 스토리지 서비스를, 고속 스토리지는 작은 단위의 데이터(일반적으로 KB)를 보관하면서 매우 높은 성능 특성을 가진 클라우드 스토리지 서비스를 의미한다. 후자의 경우 영속성 특성을 가진 큐 형태의 분산 로그 시스템이라 볼 수 있다. 여기서 저속과 고속은 HDD, SSD 드라이브의 차이와 같은 하드웨어 특성을 말하는 것이 아닌, 유스케이스에 따른 스토리지 소프트웨어 설계 특성을 말한다.

데이터를 실시간으로 처리할 수 있는 프레임워크(클라우드 데이터 플로우, 카프카 스트림즈 등) 중에는 특정 스토리지 시스템에 종속돼 있는 경우도 있다. 따라서 실시간 처리를 가능하게 하려면 고속 스토리지 계층을 활용해 작업해야 한다.

• 단기 데이터 보관과 장기 데이터 보관 둘 다 가능해야 한다.
• 배치 방식과 스트리밍 방식에서 데이터를 사용할 수 있어야 한다.

저속 스토리지에는 보관 및 영구 데이터를 위한 주요 스토리지다. 이 영역에는 며칠부터 몇년동안의 데이터가 보관되기도 한다. 객체 젖아소의 단점은 짧은 지연을 제공하지 않는다. 고속 스토리지에는 단일 메시지의 읽기/쓰기 작업시 짧은 지연을 확보할 수 있다. 대부분 아차피 카프카를 이러한 유형의 스토리지로 연관짓지만, 클라우드 공급 업체들이 제공하는 유사 서비스들이 있다. 고속 스토리지를 활요하려면 스트리밍 데이터 수집 시 짧은 지연 액세스가 가능하지만, 이를 위해서는 관련 컴퓨팅 서버가 필요하다는 의미를 내퐇ㄴ다. 예를 들어 카프카 클러스터의 겅우, 고속 스토리지 용량을 늘리려면 RAM, CPU, 디스크가 포함된 서버를 함께 추가해야 한다. 즉, 고속 스토리지 비용이 저속 스토리지 비용보다 훨씬 더 높다는 의미다.

스토리지 계층이 가져야할 특성은 다음과 같다.

1. 안정성 : 저속/고속 스토리지 둘 다 다양한 형태의 장애 발생 상황에도 데이터를 지속적으로 유지할 수 있어야 한다.
2. 확장 가능성 : 최소한의 노력으로 스토리지 용량을 추가할 수 있어야 한다.
3. 성능 : 저속 스토리지는 대용량 데이터를 읽을 떄의 읽기 성능, 고속 스토리지는 단일 메시지를 읽고 쓸 때의 짧은 지연시간을 확보할 수 있어야 한다.
4. 비용 효율성 : 데이터 보관 주기 정책에 비용 측면도 적용해 스토리지 사용을 최적화할 수 있어야 한다.

처리 계층

데이터 플랫폼 구현의 핵심은 처리 계층이다. 비즈니스 로직 적용, 데이터 검증, 데이터 변환이 수행되는 곳이 처리 계층이다. 또한 처리 계층의 중요 역할 중한나로 데이터 플랫폼 데이터로의 애드혹 액세스를 제공한다.

처리 계층은 다음 작업을 수행할 수 있어야 한다.

1. 스토리지에서 배치 방식이나 스트리밍 처리 방식으로 데이터를 읽고 비즈니스 로직을 적용할 수 있어야 한다.
2. 데이터 분석가나 데이터 과학자가 데이터에 액세스하기 위해 데이터를 스토리지에 다시 저장할 수 있어야 한다.
3. 스트리밍 데이터 결과물을 소비자, 즉 다른 시스템으로 제공할 수 있어야 한다.

처리 계층은 스토리지에서 데이터를 읽고 처리 로직을 적용한 다음, 재활용을 위해 스토리지에 다시 저장하는 역할을 한다. 처리 계층은 저속/고속 데이터 스토리지 모두를 활용할 수 있어야 한다. 즉, 계층 구현을 위해 사용할 프레임워크는 저속 스토리지 기반인 파일 배치 처리 방식과, 고속 스토리지 기반인 한 번에 하나의 메시지를 처리하는 방식을 모두 지원해야 한다.

일반적으로 데이터 플랫폼 계층을 구현할 때 클라우드 서비스 하나만 사용하거나, 단일 소프트웨어 제품만 사용할 필요가 없다. 배치 처리에 전문화된 솔루션과 스트림 처리에 전문화된 솔루션을 사용하는 것이 다목적 툴 하나를 사용해 구축하는 것보다 더 나은 결과를 제공하는 경우가 자주 있따.

처리 계층이 갖추어야 할 특성

1. 단일 컴퓨터 이상으로 스케일아웃 시킬 수 있는 구조여야 한다. MB, GB, TB, PB에 이르는 데이터 규모를 효율적으로 처리할 수 있어야 한다.
2. 배치 처리 모델과 실시간 스트리밍 모델 모두 지원해야 한다. 떄로는 이를 위해 두 개의 다른 툴을 사용할 수도 있다.
3. 파이썬, 자바, 스칼라와 같이 널리 사용되는 프로그래밍 언어르 지원해야 한다.
4. SQL 인터페이스를 제공해야 하며, 이는 있으면 좋은 요구 조건이다. 애드혹 분석 시나리오에서 특히 분석 대부분을 SQL을 사용해 수행하기 때문이다. 프레임워크가 SQL을 지원하면 데이터 분석가, 데이터 과학자, 데이터 엔지니어의 생산성이 크게 향상된다.

기술 메타데이터 계층

비즈네스 메타데이터가 아닌 기술 메타데이터에는 일반적으로 데이터 소스의 스키마 정보, 수집 상태 저옵, 성공, 실패 오류율 등과 같은 변환 파이프라인의 상태 정보, 행 개수와 같은 수지 데이터와 처리 데이터에 관한 통계 정보, 데이터 변환 파이프에 대한 계보 정보가 있다.

1. 데이터 플랫폼 계층들의 처리 상태에 대한 정보를 저장한다.
2. 각 계층에서 저장소의 메타데이터를 읽고, 추가, 변경할 수 있도록 인터페이스를 제공한다.

데이터 플랫폼은 여러 계층으로 구성된 형태로 설계되어 있다. 각 계층 간 직접 통신하지 않는 경우도 있기에 각 계층의 상태 정보를 저장할 수 있는 저장소가 있어야 한다. 이 개념을 활용하면 데이터 처리 계층이 수집 계층과 직접 통신하는 대신, 메타 데이터 계층을 통해 현재 어떤 데이터를 처리 가능한지 알 수 있게 된다. 이를 통해 계층 간 상호 의존성과 관련된 복잡성을 줄이면서 계층의 독립성을 높일 수 있다.

비즈니스 메타데이터는 비즈니스 관점의 데이터의 실제 의미에 대한 정보를 가진다. 예를 들면 특정 데이터 소스의 특정 컬럼이 의미하는 정보 같은 것들이다. 비즈니스 메타 데이터가 있으면 데이터 검색과 소통이 더욱 용이하기 때문에 전체 데이터 전략 수립과 실행에 중요한 구성 요소로 자리잡고 있다. 여러 서드파티 솔루션에서 비즈니스 메타데이터 저장소와데이터 카탈로그 기능을 제공한다.

데이터 플랫폼 메타데이터 저장소가 가져야할 특성은 다음과 같다.

1. 확장성 : 데이터 플랫폼 환경에서 수백 ~ 수천개의 개별 작업이 수행될 수 있다. 개별 작업에서 오는 요청에 빠르게 응답할 수 있도록 메타데이터 계층은 확장 가능해야 한다.
2. 고가용성 : 메타데이터 계층은 데이터 플랫폼 파이프라인에서 단일 장애 지점이 될 가능성이 있다. 처리 계층은 메타데잍 계층으로부터 처리할 데이터 정보를 가져와야 한다. 메타데이터 서비스가 응답하지 않으면 처리 파이프라인에 장애가 발생하거나 처리가 멈출 수 있다. 장애가 발생한 파이프라인과 관련된 다른 파이프라인들에도 장애가 연속적으로 발생할 수 있다.
3. 확장 가능 : 메타데이터 계층에서 관리해야 할 메타데이터의 종류에 대한 정확한 규칙은 아직 없다. 뒷장에서 스키마와 파이프라인 통계정보와 같은 가장 일반적인 메타데이터 항목을 다룰 것이다.