습관처럼
빅데이터 실시간 처리 그리고 람다 & 카파 아키텍처 본문
빅데이터와 하둡 그리고 한계
하둡이 빅데이터를 처리하는 분산처리 플랫폼으로서 적용되는 사례가 늘어나면서 하둡은 잘 작동하였지만 하둡은 실시간성의 처리구조는 아니였습니다. 오히려 하둡은 배치성의 성격을 갖는 프로세싱 구조라고 할수 있습니다. 이러한 준실시간성을 보완하여 실시간 처리를 하기 위한 하둡오픈소스 생태계들도 발전하기 시작합니다.
실시간성의 데이터를 처리하기 위해 Storm과 Spark의 실시간 처리를 위한 Spark Streaming, Samza, Flink등의 처리인프라와 실시간성의 데이터 수집을 위한 Flume 과 Kafka 등의 다양한 처리 에코시스템이 발전 합니다.
람다 아키텍처란?
실시간 분석을 지원하는 빅데이터 아키텍쳐이다. 대량의 데이터를 실시간으로 분석하기 어려우니 batch로 미리 만든 데이터와 실시간 데이터를 혼합해서 사용하는 방식이다.
람다 아키텍처의 3계층과 장단점
하둡의 배치성/준실시간성을 극복하기 위해 위의 여러 오픈소스 생태계를 조합하여 실시간 처리를 할수 있는 개념들이 나타납니다. 여러가지의 오픈소스 인프라들이 사용되어 폴리글랏(Polyglot: 여러언어의 다중언어의) 프로세싱이라고도 합니다.
람다아키텍처는 나르단 마르츠(Nathan Marz)가 트위터에서의 분산프로세싱 경험을 바탕으로 스피드레이어(Speed Layer)+배치레이어(Batch Layer)+서빙레이어(Serving Layer)로 3계층으로 구성된 실시간처리 아키텍처입니다.
[배치레이어(Batch Layer)]
베치레이어는 기존에 데이터처리를 위한 배치 프로세스라고 볼수 있습니다. 데이터를 처리하는 단위(unit)로 데이터가 입력되면 해당 단위로 데이터 처리를 하게 됩니다. 입력되는 데이터는 마스터데이터 셋이라고 해서 저장되거나 읽기만 가능하고 변경은 안되는 immutable data set의 성질을 갖습니다.
또한 단위 프로세스로 처리되기때문에 해당 단위의 처리시에 이후에 들어온 데이터는 처리하지 못합니다. 특정단위의 배치 프로세스이기 때문에 데이터의 정합성이나 충돌, 동시성, 이상현상, 장애등에 대해서 비교적 자유로운 특성을 갖습니다.
[스피드레이어(Speed Layer)]
스피드레이어는 배치레이어가 특정단위작업 이후에 들어오는 실시간 데이터를 처리하고 응답시간을 빠르게 유지하는 역할을 하는 레이어입니다. 스트림으로 들어온 데이터를 처리하기 위한 큐나 버퍼같은 구조를 사용하고 효율적 스트림처리를 위한 증분처리 방식을 사용합니다. 배치프로세스가 완료된 시점에는 처리된 실시간 뷰는 삭제되게 됩니다.
[서빙레이어(Serving Layer)]
서빙레이어는 배치레이어와 스피드레이어를 통해 처리된 배치뷰와 실시간뷰를 병합하여 사용자에게 결과값을 제공해주는 계층입니다.
이와 같은 3계층의 람다아키텍처는 데이터의 정확성,일관성을 제공함과 동시에 최소의 지연으로 실시간적인 결과를 사용자에게 제공하는 장점이 있습니다. 하지만 배치레이어와 스피드레이어의 분리로 인한 관리포인트의 증가가 단점이라고 할수 있습니다. 배치처리와 실시간처리시의 개발언어나 오픈소스 인프라의 컨셉자체가 틀려 고려할 사항이 많고 이에 따라 기능이 중복되고 관리/유지보수에 많은 공수가 투입되며 복잡하다는 단점이 있습니다.
중복성과 복잡성의 제거, 카파아키텍처
람다 아키텍처의 배치레이어와 스피드레이어의 기능적 중복성과 복잡성을 제거하기 위해 제안된것이 카파아키텍처입니다. 링크드인의 제이크렙스(Jay Kreps)가 제안한 카파아키텍처는 배치레이어를 제거하고 스피드레이어에서 모든 데이터를 스트림 처리하여 서빙레이어로 전달하는 구조로 되어있습니다.
카파아키텍처는 스피드레이어를 통해 스트림처리를 하기 때문에 재작업은 버전이 변경된 경우 버전별로 처리후 별도의 테이블로 저장되고 이전 버전의 스트림의 처리가 종료되면 재작업이 완료되게 됩니다.
람다아키텍처와는 달리 배치레이어가 제거 되면서 하나의 레이어에 대한 관리 포인트만을 갖고 단일 프레임웍하에 동작하기 때문에 운영/유지보수의 장점이 있고 이상현상또는 장애 발생시의 디버깅과 테스트에 대한 장점도 갖게 됩니다. 하지만 스피드 레이어의 이상이나 장애 발생시의 실시간 서비스 제공에 대한 부분과 데이터의 유실등에 대한 보완등도 고려해야 할것으로 판단됩니다.
빅데이터 실시간 아키텍처 구성시 고려사항
데이터의 정합성 및 유실: 배치레이어나 스피드 레이어에서의 처리시 데이터의 정합성을 보장하고 모니터링 할수 있는 수단이 필요하며 비즈니스 적으로 중요한 데이터이고 스트리밍 처리시 데이터가 유실되지 않도록 일정기간 데이터의 롤링, 백업될수 있도록 설정이 필요합니다.
처리현황 모니터링: 실시간 처리 시스템 구성후에는 처리현황 및 인프라에 대한 이상유무 및 특정시점 데이터처리의 누락여부를 모니터링 할 수 있는 모니터링 체계가 중요하며 또한 유용합니다.
대시보드 및 자동화: 현황을 모니터링 하고 제어할수 있는 기능을 따로 모아서 대시보드를 구성하고 사용자레벨 별로 권한 관리할 경우 효율적으로 관리가 가능합니다. 또한 관리가 필요한 부분은 자동화하는 방안도 고려가 필요합니다.
빅데이터의 사용자관점 시각화: 처리된 데이터가 사용자에게 trend 상에 직관적으로 인지되도록 텍스트나 수치 보다는 그래프나 표, 색깔 등으로 시각화 될 경우 데이터 사용성이 증가합니다.
용량 산정 및 처리인프라의 Provisioning: 빅데이터 처리시의 필요 인프라의 용량 산정 및 그에 따른 인프라가 자동으로 투입되도록 AutoScaling 고려도 필요합니다.(처리 서버의 cpu, memory, network usage, active thread 등에 따른 AutoScaling)
오픈소스 version upgrade시 변경사항의 이력관리: 시스템을 구성하는 오픈소스의 버젼에 따라 관련 인프라간의 영향도 파악 및 반영에 따른 이력 및 문서화가 필요합니다.
사용자 데이터 보안 및 백업: 인프라의 access 권한에서 부터 처리데이터의 개인정보 보호 및 기밀성에 대한 고려가 필요할 수 있습니다.