본문 바로가기

SW LAB/Cloud

클라우드에서 빅데이터 아키텍처란?

데이터베이스 : 빅데이터

클라우드는 데이터의 처리 및 저장 방법을 비롯하여 애플리케이션이 디자인되는 방식을 바꾸고 있습니다. Polyglot Persistence Solution은 모든 솔루션의 데이터를 처리하는 단일 범용 데이터베이스 대신, 각각이 특정 기능을 제공하도록 최적화된 여러 특수한 데이터 저장소를 사용합니다. 단일 데이터 계층에서 읽고 쓰는 비즈니스 논리의 여러 계층이 더 이상 존재하지 않습니다. 대신, 솔루션을 통해 데이터가 흐르는 방식, 처리되는 위치, 저장되는 위치, 파이프라인의 다음 구성 요소에서 사용되는 방식을 설명하는 데이터 파이프라인을 중심으로 솔루션이 디자인됩니다.

Microsoft Azure에서는 관계형 데이터, 비관계형 데이터, 빅 데이터로 데이터 유형을 나누고 있습니다. 이 중에서 빅 데이터 관점에서 BigData Solution에 대해서 다루어 보도록 합니다.


빅 데이터 아키텍처

빅 데이터 아키텍처는 기존의 데이터베이스 시스템에 비해 너무 크거나 복잡한 데이터의 수집, 처리 및 분석을 수행하도록 디자인되었습니다. 빅 데이터 집합으로 작업하기 위한 도구가 발전하면서 빅 데이터의 의미도 달라지고 있습니다. 이 용어는 엄격히 데이터 크기만을 고려하지 않고, 고급 분석을 통해 데이터 집합에서 추출할 수 있는 가치와 점점 더 밀접한 관련을 갖습니다. 데이터 크기만 고려한다면 빅 데이터는 훨씬 더 큰 데이터일 것입니다.

빅 데이터 솔루션에는 일반적으로 다음 중 하나 이상의 워크로드 유형이 포함됩니다.

  • 미사용 빅 데이터 원본의 일괄 처리
  • 사용 중인 빅 데이터의 실시간 처리
  • 빅 데이터의 대화형 탐색
  • 예측 분석 및 기계 학습

다음 작업이 필요할 때 빅 데이터 아키텍처를 고려합니다.

  • 기존 데이터베이스에 비해 너무 큰 볼륨의 데이터 저장 및 처리
  • 분석 및 보고를 위해 구조화되지 않은 데이터 변환
  • 제한됟지 않은 데이터 스트림을 실시간으로 또는 짧은 대기 시간으로 수집, 처리 및 분석

빅 데이터 아키텍처의 구성 요소

빅 데이터 구성요소
대부분의 빅 데이터 아키텍처에는 다음 구성 요소의 일부 또는 전체가 포함됩니다.

  • Data Sources
    모든 빅 데이터 솔루션은 하나 이상의 데이터 원본으로 시작합니다.

    • 애플리케이션 데이터 저장소(예: 관계형 데이터베이스)
    • 애플리케이션에서 생성하는 정적 파일(예: 웹 서버 로그 파일)
    • 실시간 데이터 원본(예: IoT 디바이스)
  • Data Storage
    일괄 처리 작업을 위한 데이터는 대개 대용량 파일을 다양한 형식으로 저장할 수 있는 분산 파일 저장소에 저장됩니다. 이런 종류의 저장소를 Data Lake라고도 합니다.

  • Batch Processing
    데이터 집합이 너무 큰 경우 빅 데이터 솔루션은 필터링, 집계 및 그 밖의 분석을 위한 데이터를 준비하기 위해 장기간 실행되는 일괄 처리 작업을 사용하여 데이터 파일을 처리해야 하는 경우가 있습니다. 일반적으로 이러한 작업은 원본 파일 읽기 및 처리와 새 파일에 출력 작성으로 이루어집니다.

  • Real-Time Message Ingestion
    솔루션에 실시간 원본이 포함되는 경우 스트림 처리를 위해 실시간 메시지를 캡처하고 저장하는 방법이 아키텍처에 포함되어야 합니다. 이는 들어오는 메시지가 처리를 위해 폴더에 저장되는 간단한 데이터 저장소일 수 있습니다. 그러나 많은 솔루션에는 메시지에 대한 버퍼로 작동하고 스케일 아웃 처리, 안정적인 전달 및 기타 메시지 큐 의미 체계를 지원하는 메시지 수집 저장소가 필요합니다. 스트리밍 아키텍처의 이 부분을 스트림 버퍼링이라고도 합니다.

  • Stream Processing
    실시간 메시지를 캡처한 후 솔루션은 필터링, 집계 및 그 밖의 분석을 위한 데이터 준비를 통해 해당 메시지를 처리해야 합니다. 그런 다음, 처리된 스트림 데이터는 출력 싱크에 기록됩니다.

  • Analytical Data Store
    대다수의 빅 데이터 솔루션은 분석할 데이터를 준비한 다음, 분석 도구를 사용하여 쿼리할 수 있는 구조화된 형식으로 처리된 데이터를 제공합니다. 이러한 쿼리를 처리하는 데 사용되는 분석 데이터 저장소로는 대부분의 기존 BI(비즈니스 인텔리전스) 솔루션에서 볼 수 있는 Kimball 스타일의 관계형 데이터 웨어하우스가 있습니다. 또는 HBase와 같이 대기 시간이 짧은 NoSQL 기술이나, 분산 데이터 저장소의 데이터 파일에 대한 메타데이터 추상화를 제공하는 대화형 Hive 데이터베이스를 통해 데이터를 제공할 수 있습니다.

  • Analytics and Reporting
    대부분의 빅 데이터 솔루션의 목표는 분석 및 보고를 통해 데이터에 대한 정보를 제공하는 것입니다.

  • Orchstration
    대부분의 빅 데이터 솔루션은 원본 데이터를 변환하고, 여러 원본과 싱크 간에 데이터를 이동하고, 처리된 데이터를 분석 데이터 저장소로 로드하거나, 또는 결과를 보고서나 대시보드로 직접 전달하는 '반복되는 데이터 처리 작업'을 워크플로 내에 캡슐화한 형태로 구성됩니다.

Lambda Architecture

매우 큰 데이터 집합을 사용할 경우 클라이언트가 필요로 하는 쿼리 종류를 실행하는 데 시간이 오래 걸릴 수 있습니다. 이러한 쿼리는 실시간으로 수행할 수 없으며, MapReduce와 같이 전체 데이터 집합에 대해 병렬로 작동하는 알고리즘이 필요할 수 있습니다. 그런 후 결과는 원시 데이터와 별도로 저장되고 쿼리에 사용됩니다.

이 방식의 한 가지 단점은 대기 시간이 발생한다는 것입니다. 즉, 처리에 몇 시간이 걸릴 경우 쿼리는 몇 시간 늦은 결과를 반환할 수 있습니다. 일부 결과를 실시간으로 가져온 후(정확도가 다소 손실될 수 있음) 이러한 결과를 일괄 처리 분석의 결과와 조합하면 이상적일 것입니다.

Nathan Marz가 최초로 제안한 람다 아키텍처는 데이터 흐름에 대해 두 개의 경로를 만들어 이 문제를 해결합니다. 시스템으로 들어오는 모든 데이터는 다음 두 경로를 거칩니다.

  • 일괄 처리 계층(실행 부하 미달 경로)은 들어오는 모든 데이터를 원시 형식으로 저장하고 해당 데이터에 대해 일괄 처리를 수행합니다. 이러한 처리의 결과는 일괄 처리 보기로 저장됩니다.
  • 빠른 레이어(실행 부하 과다 경로)는 데이터를 실시간으로 분석합니다. 이 계층은 정확도는 떨어지지만 짧은 대기 시간을 제공하도록 디자인되었습니다.

람다 아키텍처 사진

실행 부하 과다 경로로 이동하는 데이터는 빠른 계층의 대기 시간 요구 사항으로 제약되므로 가능한 한 빠르게 처리될 수 있습니다. 대개, 가능한 한 빠르게 데이터를 준비하기 위해 정확도는 어느 정도 손상되게 됩니다. 예를 들어, 많은 수의 온도 센서가 원격 분석 데이터를 보내는 IoT 시나리오를 고려해 보세요. 들어오는 데이터의 슬라이딩 기간을 처리하기 위해 빠른 계층을 사용할 수 있습니다.

반면에 실행 부하 미달 경로로 흐르는 데이터에는 동일한 짧은 대기 시간 요구 사항이 적용되지 않습니다. 따라서 큰 데이터 집합에서 시간이 많이 소요되는 높은 정확도의 계산이 수행될 수 있습니다.

결과적으로, 실행 부하 과다 경로 및 실행 부하 미달 경로가 분석 클라이언트 애플리케이션에서 수렴됩니다. 클라이언트는 덜 정확할 수 있는 데이터를 실시간으로 표시해야 할 경우 실행 부하 과다 경로에서 해당 결과를 얻게 됩니다. 그렇지 않은 경우, 실행 부하 미달 경로에서 결과를 선택하여 시기 적절성은 떨어지지만 좀 더 정확한 데이터를 표시합니다. 즉, 실행 부하 과다 경로는 비교적 짧은 기간 동안 데이터를 보유하며, 그 이후에는 실행 부하 미달 경로의 보다 정확한 데이터로 업데이트될 수 있습니다.

일괄 처리 계층에 저장된 원시 데이터는 변경할 수 없습니다. 들어오는 데이터는 항상 기존 데이터에 추가되며, 이전 데이터를 덮어쓰지 않습니다. 특정 데이터 값의 변경 내용은 새 타임스탬프 이벤트 레코드로 저장됩니다. 따라서 데이터가 수집되는 모든 시점에서 재계산을 수행할 수 있습니다. 원래의 원시 데이터에서 일괄 처리 보기를 다시 계산하는 기능은 매우 중요합니다. 시스템 변화에 따라 새로운 보기를 만들 수 있기 때문입니다.

Kappa Architecture

람다 아키텍처의 단점은 복잡하다는 것입니다. 처리 논리는 다른 프레임워크를 사용하는 실행 부하 과다 경로와 실행 부하 미달 경로의 두 위치에서 나타납니다. 이로 인해 중복된 계산 논리와 두 경로의 아키텍처 관리에 따른 복잡성이 발생합니다.

Kappa Architecture는 람다 아키텍처의 대안으로 Jay Kreps가 제안했습니다. 람다 아키텍처와 동일한 기본 목표가 있지만 중요한 차이점이 있습니다. 스트림 처리 시스템을 사용하여 단일 경로를 통한 모든 데이터 흐름입니다.

카파 아키텍처 사진

이벤트 데이터가 변경 불가능하며, 일부가 아닌 전체가 수집된다는 측면은 람다 아키텍처의 일괄 처리 계층과 약간 유사합니다. 데이터는 이벤트 스트림 형태로 내결함성이 있는 분산 통합 로그로 수집됩니다. 이러한 이벤트는 순서대로 정렬되며, 이벤트의 현재 상태는 추가되는 새 이벤트에 의해서만 변경됩니다. 람다 아키텍처의 빠른 계층과 비슷하게, 모든 이벤트 처리가 입력 스트림에서 수행되고 실시간 보기로 유지됩니다.

전체 데이터 집합을 다시 계산해야 하는 경우(일괄 처리 계층이 람다에서 수행하는 것과 같음) 스트림을 재생하기만 하면 됩니다. 그러면 병렬화를 통해 시기 적절하게 계산이 완료됩니다.

Batch Processing (일괄 처리)

일반적인 빅 데이터 시나리오는 미사용 데이터의 일괄 처리입니다. 이 시나리오에서는 원본 데이터는 원본 애플리케이션 자체에 의해 또는 오케스트레이션 워크플로에 의해 데이터 스토리지에 로드됩니다. 그런 다음 데이터는 병렬 작업에 의해 내부에서 처리됩니다(오케스트레이션 워크플로를 통해서도 처리가 시작될 수 있음). 이러한 처리에는 변환된 결과가 분석 및 보고 구성 요소에 의해 쿼리될 수 있는 분석 데이터 저장소로 로드되기 이전의 여러 반복적인 단계가 포함될 수 있습니다.

예를 들어, 웹 서버의 로그가 폴더에 복사된 다음, 야간에 처리되면서 웹 작업의 일일 보고서가 생성될 수 있습니다.
Batch Processing 사진

이 솔루션을 사용하는 경우

일괄 처리는 간단한 데이터 변환에서 보다 완전한 ETL(추출-변환-로드) 파이프라인에 이르는 다양한 시나리오에서 사용됩니다. 빅 데이터 컨텍스트에서 일괄 처리는 계산에 상당한 시간이 소요되는 매우 큰 데이터 집합에 작동될 수 있습니다. 일괄 처리는 일반적으로 대화형 탐색을 통해 발생하거나, 기계 학습을 위한 모델링 준비 데이터를 제공하거나, 분석 및 시각화에 최적화된 데이터 저장소에 데이터를 기록합니다.

일괄 처리의 한 가지 예는 반구조화된 대규모 플랫 CSV 또는 JSON 파일 집합을 추가 쿼리 준비가 완료된 스키마화 및 구조화 형식으로 변환하는 것입니다. 일반적으로 데이터가 수집에 사용되는 원시 형식(예: CSV)에서 쿼리 성능을 높일 수 있는 이진 형식으로 변환됩니다. 이 방법에서는 데이터를 열 형식으로 저장하고, 종종 데이터에 대한 인덱스 및 인라인 통계를 제공하기 때문에 성능이 향상됩니다.

아키텍처

일괄 처리(Batch Processing) 아키텍처는 위 다이어그램에 표시되는 다음 논리적 구성 요소를 갖습니다.

  • Data Storage
    일반적으로 다양한 형식의 대용량 파일의 리포지토리로 사용될 수 있는 분산 파일 저장소입니다. 일반적으로 이 종류의 저장소를 데이터 레이크라고도 합니다.

  • Batch Processing
    빅 데이터는 일반적으로 대용량이므로 빅 데이터 솔루션은 필터링, 집계 및 그 밖의 분석을 위한 데이터를 준비하기 위해 장기간 실행되는 일괄 처리 작업을 사용하여 데이터 파일을 처리해야 하는 경우가 있습니다. 일반적으로 이러한 작업은 원본 파일 읽기 및 처리와 새 파일에 출력 작성으로 이루어집니다.

  • Analytical Data Store
    대다수의 빅 데이터 솔루션은 분석할 데이터를 준비한 다음, 분석 도구를 사용하여 쿼리할 수 있는 구조화된 형식으로 처리된 데이터를 제공하도록 디자인되어 있습니다.

  • Analysis and Reporting
    대부분의 빅 데이터 솔루션의 목표는 분석 및 보고를 통해 데이터에 대한 정보를 제공하는 것입니다.

  • Orchestration
    일괄 처리를 사용할 경우, 일반적으로 데이터를 데이터 스토리지, 일괄 처리, 분석 데이터 스토리지 및 보고 계층으로 마이그레이션 또는 복사하기 위해 오케스트레이션이 어느 정도 필요합니다.

Real-Time Processing (실시간 처리)

실시간 처리는 실시간으로 캡처되고 최소 대기 시간으로 처리되는 데이터 스트림을 사용하여 실시간(또는 거의 실시간) 보고서 또는 자동화된 응답을 생성합니다. 예를 들어, 실시간 트래픽 모니터링 솔루션은 센서 데이터를 사용하여 높은 트래픽 볼륨을 감지할 수 있습니다. 이 데이터는 정체 상태를 표시하도록 지도를 동적으로 업데이트하거나, 점유율이 높은 차선 또는 기타 트래픽 관리 시스템을 자동으로 시작하는 데 사용될 수 있습니다.

실시간 처리 사진

실시간 처리는 바인딩되지 않은 입력 데이터의 스트림 처리로 정의되며 처리 대기 시간이 매우 짧습니다(밀리초 또는 초 단위로 — 측정). 이러한 들어오는 데이터는 일반적으로 JSON과 같은 비구조화 또는 반구조화 형식으로 도착하며, 일괄 처리와 같은 처리 요구 사항을 가지지만 실시간 사용을 지원하기 위해 좀 더 짧은 소요 시간을 유지합니다.

처리된 데이터는 주로 분석 및 시각화에 최적화된 분석 데이터 저장소에 기록됩니다. 또한 처리된 데이터는 분석, 비즈니스 인텔리전스 및 실시간 대시보드 시각화를 위해 분석 및 보고 계층으로 직접 수집될 수도 있습니다.

아키텍처

실시간 처리(Real-Time Processing) 아키텍처는 다음 논리적 구성 요소를 갖습니다.

  • Real-Time Message Ingestion
    아키텍처에는 실시간 메시지를 캡처하고 스트림 처리 소비자가 사용할 수 있게 저장하는 방법이 포함되어야 합니다. 대부분의 경우 이 서비스는 폴더에 새 메시지를 보관하는 간단한 데이터 저장소로 구현할 수 있습니다. 하지만 솔루션에 메시지에 대한 버퍼로 작동하는 Azure Event Hubs와 같은 메시지 브로커가 필요한 경우가 많습니다. 메시지 브로커는 스케일 아웃 처리 및 안정적인 배달을 지원해야 합니다.

  • Stream Processing
    실시간 메시지를 캡처한 후 솔루션은 필터링, 집계 및 그 밖의 분석을 위한 데이터 준비를 통해 해당 메시지를 처리해야 합니다.

  • Analytical Data Store
    대다수의 빅 데이터 솔루션은 분석할 데이터를 준비한 다음, 분석 도구를 사용하여 쿼리할 수 있는 구조화된 형식으로 처리된 데이터를 제공하도록 디자인되어 있습니다.

  • Analysis and Reporting
    대부분의 빅 데이터 솔루션의 목표는 분석 및 보고를 통해 데이터에 대한 정보를 제공하는 것입니다.

마치며 ...

내용을 정리하면서 작성하려고 했는데.. 가이드가 너무 잘 되어 있어서 거의 읽고 복사&붙여넣기 작업을 하였네요 ..
배치 작업과 실시간 처리 작업에 대한 이해가 되는 가이드였습니다.
데이터 처리 설계를 수행할 때, 이를 고려하고 본 아키텍처를 참고삼으면 더 쉽게 접근이 가능할 것입니다.

참고

MicronSoft Azure 빅 데이터 아키텍처

'SW LAB > Cloud' 카테고리의 다른 글

AWS CLI를 이용하여 S3 다루기  (0) 2020.04.29
AWS SA Professional 시험 후기  (0) 2020.04.29
클라우드에서 빅데이터 아키텍처란?  (0) 2020.04.27
AWS ECS : 소개  (0) 2020.04.26
AWS CloudFront : Log 만들기  (0) 2020.04.25
AWS Athena : 성능 테스트  (0) 2020.04.25