[빅데이터 실시간 데이터 적재] HBase, Redis, Storm, Espher

빅데이터 실시간 적재 개요

원천에서 어떠한 데이터가 발생할 때, 데이터의 실시간이라는 것에는 여러가지 의미가 있다.

• 빠르게 데이터가 발생
• 오랜 시간 발생
• 대규모로 발생
  만약 이런 실시간 데이터를 DB에 저장한다고 한다면 초당 수백, 수천건의 데이터를 RDBMS의 트랜잭션과, 영속성을 생각하며 저장할 수 있을지를 생각해줘야한다.
  이 외에도 실시간 데이터는 실시간으로 분석을 할 수 있어야 하는데, 초당 수백, 수천, 수만건의 데이터가 발생하는 환경에서 이를 실시간으로 분석한다는 것은 큰 오버헤드를 발생시키는 일이다. 또한 장애가 발생했을 경우 데이터의 유실 문제를 피할 수 없으며, 장애가 복구됐다고 하더라도 그 시간동안의 데이터 또한 유실이 되는 것이다.
  따라서 빅데이터의 실시간 적재라 함은 대규모로 발생되는 데이터를 어떻게 데이터의 유실 없이 안정적으로 처리, 적재, 분석할 것인가를 고민해야한다. 그렇기 때문에 많이 복잡하다.

빅데이터 적재 저장소 유형

실시간 데이터의 경우에는 경우에 따라서 어떤 저장소를 사용할것인가도 고민해주어야 한다.

• 대규모 메시지 전체를 영구 저장 -> NoSQL
• 대규모 메시지 전체를 버퍼링 처리 -> MoM(Message Oriented Middleware)
• 대규모 데이터 일부만 임시 저장 -> Cached
  이렇게 복잠함에도 불구하고 이를 사용하는 이유는 그럼에도 불구하고 비즈니스적으로 얻을 수 있는 가치가 매우 높기 때문이다.

실시간 적재에 활용하는 기술

빅데이터를 관계형 데이터베이스에 저장할 때 관계형 데이터베이스의 원칙인 ACID를 지키기 위해서 데이터베이스 엔진과 옵티마이저에 부하가 많이 갔다. 그래서 이 ACID 특성을 제공하지 않으며 뛰어난 확장성과 성능을 갖는 비 관계형 데이터 베이스가 등장했으며, 이것이 NoSQL이다.
이 NoSQL의 특징은 Key, Value구조를 가지고 있다. 이 구조로 단순화하고 컬럼이나 도큐멘트 형식의 제약사항이 적은 스키마 모델로 고성능의 쓰기와 읽기를 가능하게 하는 특징이 있다.
참고로, 10개의 컬럼이 있는 테이블이 있을때, RDBMS의 경우 10번째 컬럼의 데이터를 가지고 오기 위해서는 1번부터 10번까지 모두 접근을 한 뒤 10번 컬럼의 데이터를 가지고와야하지만 NoSQL은 바로 10번의 컬럼에 접근하여 데이터를 가지고 올 수 있다. 따라서 NoSQL이 빠른 access와 scan이 가능하다.

HBase

하둡 기반의 컬럼 지향의 NoSQL 데이터 베이스이다. 스키마 변경이 자유롭고, 리전이라는 수십, 수백대의 분산 서버로 샤딩과 복제 기능을 지원해주는 특징을 가지고 있다.

주요 구성 요소

• HTable
  • 컬럼 기반 데이터 구조를 정의한 테이블로서, 공통점이 있는 컬럼들의 그룹을 묶은 컬럼 패밀리와 테이블의 로우를 식별해서 접근하기 위한 로우키로 구성되어 있다.
• HMaster
  • HRegion 서버를 관리하며, HRegion들이 속한 HRegion Server의 메타 정보를 관리한다.
• HRegion
  • HTable의 크기에 따라 자동으로 수평 분할이 발생하고, 이때 분할된 블록을 HRegion 단위로 지정한다.
• HRegionServer
  • 분산 노드별 HRegionServer가 구성되며, 하나의 HRegionServer에는 다수의 HRegion이 생성되어 HRegion을 관리한다.
• Store
  • 하나의 Store에는 컬럼 패밀리가 저장 및 관리되며, MemStore와 HFile로 구성된다.
• MemStore
  • Store 내의 데이터를 인메모리에 저장 및 관리하는 데이터 캐시 영역이다.
• HFile
  • Store 내의 데이터를 스토리지에 저장 및 관리하는 영구 저장 영역이다.

HBase 아키텍처

아키텍처의 특징은 다음과 같다.

• 하둡에 HDFS를 기반으로 설치 및 구성된다. 이에 따라 분산 데이터베이스 아키텍처를 채택하고 있고, HDFS의 확장성과 고가용성을 그대로 물려받았다.
• 데이터를 쓸 때
  • 클라이언트는 주키퍼를 통해서 HTable의 기본 정보와 해당 HRegion의 위치를 알아내고 해당 정보를 기반으로 클라이언트가 직접 HRegionServer에 Access를 하게 된다.
  • 접근 후 먼저 MemStore에 데이터를 기록한다.
  • 이후 특정 크기, 특정 시점이 되면 이 파일을 HFile로 내리고, HFile은 다시 하둡으로 내려 영구 저장이 된다.
• 데이터를 읽어올 때
  • 클라이언트는 주키퍼를 통해서 참조하고자 하는 테이블의 로우 키 정보를 알아낸다. 알아내는 방법은 HMaster에서 HTable에 대한 메타 정보를 관리하고 있기 때문에 메타 정보를 읽어와서 HTable이 있는 HRegion에 접근하는 것이다.
  • 접근 후 MemStore에 데이터가 있다면 MemStore의 데이터를 불러와서 전달해준다.
  • 만약 데이터가 MemStore에서 Flush되어 존재하지 않는다면 HFile영역으로 이동하여 데이터를 찾게 된다. 이때 HBase과 HDFS 사이의 모든 데이터 스트림라인은 항상 열려있어 latency가 발생하지 않아 HDFS의 파일도 빠르게 조회해 올 수 있다.

Redis

분산 캐시 시스템이면서 NoSQL처럼 대규모 데이터를 관리할 수 있는 능력도 갖추었다. 이 역시 Key, Value 형식으로 데이터를 관리한다. Redis는 실시간 데이터 중 일부 특정한 데이터만 HBase에 저장되기 전에 Redis에 저장할 필요가 있을 때 사용하며, 나머지 데이터는 그대로 HBase에 저장된다.
캐시 기능을 지원한다고 해서 영구 저장을 지원하지 않는 것이 아니다. 영구 보관 주기를 지정하여 데이터를 저장하는 기능을 가지고 있다.

주요 구성 요소

• Master
  • 분산 노드 간의 데이터 복제와 Slave 서버의 관리를 위한 마스터 서버
• Slave
  • 다수의 Slave 서버는 주로 읽기 요청을 처리하고, Master 서버는 쓰기 요청을 처리한다.
• Sentinel
  • 레디스 3.x 버전부터 지원하는 기능으로, Master 서버에 문제가 발생할 경우 새로운 Master를 선출하는 기능이다.
• Replication
  • Master 서버에 쓰인 내용을 Slave 서버로 복제해서 동기화 처리한다.
• AOF/Snapshot
  • 데이터를 영구적으로 저장하는 기능으로, 명령어를 기록하는 AOF와 스냅샷 이미지 파일 방식을 지원한다.

레디스 아키텍처 1 - Single Master

마스터 서버 한 대를 놓고, 클라이언트에서 공유하고 싶은 데이터가 있으면 마스터에 있는 인메모리 캐시에 Write / Read를 하는 구조이다.

레디스 아키텍처 2 - Single Master / Multi Slave

Master 한 대를 놓고, Slave 서버를 여러대의 분산 구조로 만드는 구조이다. 클라이언트가 캐시에 기록을 할 때는 마스터에 Write를 하고, Master에 기록된 데이터가 Slave에 복제가 되는 매커니즘의 구조이다.
클라이언트는 데이터를 읽을 때 마스터가 아닌 슬레이브를 통해서 읽게 된다.

레디스 아키텍처 3 - HA Master / Multi Slave

앞의 싱글 마스터의 단점을 극복한 아키텍처이다. 센티넬이라는 것이 등장하는데, 센티넬은 마스터가 SPOF(Single Point Of Failure)가 되지 않도록 모니터링을 하고 있다가 마스터에 장애가 발생했을 때, 슬레이브중에 하나를 마스터로 선출할 수 있는 기능을 가지고 있다. 이러한 기능은 레디스 3.x부터 사용이 가능하며, 레디스의 안정성과 고가용성을 크게 높여주는 아키텍처이다.

Storm

카프카에서 실시간 데이터를 토픽에 저장을 한다. 이 토픽의 메모리 또는 카프카의 브로커의 디스크에 한계가 발생할 수 있기 때문에 한계가 발생하기 전에 원천에서 발생하는 수많은 데이터를 카프카에서 빼주어야 한다. 이 때, 빼주는 역할 또한 원천에 발생하는 데이터의 트랜잭션만큼 곧바로 소비를 할 수 있을만큼의 분산 처리 능력이 필요하다. 여기서 사용되는 것이 스톰이다. 즉, 카프카의 컨슈머 역할을 스톰이 하게 되는 것이다.
또한 스톰은 영구 저장소에 저장하기 전에 전처리, 집계, 분석을 해주는 기능도 가지고 있다. 따라서 카프카에서 바로 저장소로 저장해도 되지만, 중간에 이런 과정이 필요하다면 스톰의 사용을 고려해보아야 한다.

주요 구성 요소

• Spout
  • 외부로부터 데이터를 받아 가공 처리해서 튜플을 생성한다. 이후 해당 튜플을 Bolt에 전송하는 기능을 한다.
  • 위의 예시에서 카프카에서 데이터를 빼오는 담당이 spout가 된다.(kafka-spout)
• Bolt (중요)
  • 튜플을 받아 실제 분산 작업을 수행하며, Filtering, Aggregation, Join 등의 연산을 병렬로 실행할 수 있다.
• Topology
  • Spout-Bolt의 데이터 처리 흐름을 정의한다. 하나의 Spout과 다수의 Bolt로 구성한다.
• Nimbus
  • Topology를 Supervisor에 배포하고 작업을 할당한다. Supervisor를 모니터링하다 필요시 fail-over 처리를 한다.
• Supervisor
  • Topology를 실행할 Worker를 구동시키며 Topology를 Worker에 할당 및 관리하는 역할을 한다.
  • 하나의 Supervisor는 하나의 분산 노드로 생각할 수 있다.
• Worker
  • Supervisor 상에서 실행 중인 자바 프로세스로 Spout와 Bolt를 실행한다.
• Executor
  • Worker 내에서 실행되는 자바 스레이드이다.
• Tasker
  • Spout 및 Bolt 객체가 할당된다.

Storm과 Spark Stream이 자주 비교가 되는데 Storm이 RealTime에 가까운 데이터를 처리한다면 Spark Stream은 Micro Batch(Batch 처리의 주기를 아주 짧게 갖는 것)에 주로 사용된다. 

Storm 아키텍처

Nimbus가 있고 분산 노드로 구성되어 있다. 각 노드에는 각각의 Supervisor가 구성되어 있다. Nimbus와 Node 사이에는 주키퍼가 관여하여 클러스터 구성을 할 수 있도록 되어 있으며 각 node의 worker에 executor가, executor 안에 Task, Task 안에서 Spout과 Bolt가 실행되는 구조를 가지고 있다.
External Source가 Spout을 통해 데이터를 가지고오면, 해당 데이터를 Bolt로 보내고, Bolt가 이를 분산 병렬 처리를 해서 최종적으로 External Target으로 데이터를 전송하는 구조이다.

Esper

Storm의 Bolt에서 filtering, Aggregation 등의 처리에서 처리에 대한 룰을 정의하는 역할을 한다. 예를 들어서 이번 스마트카 파일럿 프로젝트에서는 실시간 데이터 중 과속한 차량에 대한 데이터를 Bolt에서 filtering할 예정인데, 과속이라는 룰을 정의하는데 Esper가 사용된다. Esper는 Esper만의 쿼리가 존재하고, 이 쿼리를 사용한다.

주요 구성 요소

• Event
  • 실시간 스트림으로 발생하는 데이터들의 특정 흐름 또는 패턴을 정의한다.
• EPL
  • 유사 SQL을 기반으로 하는 이벤트 데이터 처리 스크립트 언어이다.
• Input Adapter
  • 소스로부터 전송되는 데이터를 처리하기 위한 어댑터를 제공한다. (CSV, Socket, JDBC, Http 등)
• Output Adapter
  • 타겟으로 전송하는 데이터를 처리하기 위한 어댑터를 제공한다. (HDFS, CSV, Socket, Email, Http 등)
• Window (중요)
  • 실시간 스트림 데이터로부터 특정 시간 또는 개수를 설정한 이벤트들을 메모리 상에 등록한 후 EPL을 통해 결과를 추출한다. (타이밍도 처리)

Esper 아키텍처 1

애플리케이션 서버 안에 에스퍼 엔진이 위치하는 형태이다. Storm을 Esper 앞단에 위치할 것이기 때문에 Storm이 애플리케이션 서버가 된다. 데이터가 Input Adaptor로 들어오게 되면 이 데이터를 Espher 엔진에서 event processing 처리를 하고 결과를 output adaptor로 전달을 하여 Storm이 최종적으로 데이터베이스 등의 타겟으로 전달하는 구조이다.
즉, Espher는 Storm 안에 Building되는 라이브러리 엔진이다.

Esper 아키텍처 2

Storm을 통한 분산 처리를 하기 때문에 응용 서버 또한 분산 서버로 위치한다. 각 서버에는 Espher 엔진이 위치하게 된다. Espher 안에는 동일안 EPL 스크립트들이 작동하게 되며, 이 EPL 스크립트들을 분산 노드에 통합 관리를 하기 위해서 EPL 공유 저장소를 별도로 두기도 한다.

---

인프런 - 빅데이터 파일럿 프로젝트의 내용을 공부하며 작성한 글입니다.