[pilot] Ch5. 빅데이터 적재 이론 (2)
[출처: 실무로 배우는 빅데이터 기술, 김강원 저]
1. 빅데이터 실시간 적재 개요
- 앞장에 이어서 이번에는 스마트카 운전자의 실시간 운행 정보를 분석한 후 적재하는 영역 다룸
- 실시간 로그 분석에는 작지만 대량으로 발생하는 메시지성 데이터를 실시간으로 분석 처리하며, 해당 결과를 인메모리에 저장해 주변 시스템과 빠르게 공유함
- 이때 대량의 메시지 데이터를 영구 저장하기 위해 하둡을 직접 이용하지는 않음
- 유입된 작은 메시지 한 건을 바로 하둡에 저장할 경우 한 개의 HDFS 파일이 생성되는데, 초당 수천 건의 트랜잭션이 발생하는 메시지의 경우 파일 개수가 기하급수적으로 늘어나고, 이로 인해 하둡 클러스터에 지나친 오버헤드가 발생하기 때문
- 중간에 메시지를 특정 크기로 모았다가 한번에 적재하거나, 대규모 트랜잭션 데이터를 처리하는 데 최적화된 칼럼 지향형 NoSQL DB 주로 이용
2. HBASE
1) HBASE 소개
- 하둡 기반의 칼럼 지향 NoSQL 데이터베이스
- 스키마 변경이 자유롭고,
리전이라는 수십~수백 대의 분산 서버로 샤딩과 복제등의 기능을 지원해 성능과 안정성을 보장하는 특징을 가짐 - 특히 하둡의 확장성과 내고장성을 그대로 이용할 수 있어 대규모 실시간 데이터 처리를 위한 스피트 레이어 저장소에 주로 사용됨
2) 주요 구성 요소
| 주요 구성 요소 | 설명 |
|---|---|
| HTable | 칼럼 기반 데이터 구조를 정의한 테이블 공통점이 있는 칼럼들의 그룹을 묶은 칼럼 패밀리와 테이블의 로우를 식별해서 접근하기 위한 로우키로 구성 |
| HMaster | HRegion 서버를 관리하며, HRegion들이 속한 HRegion 서버의 메타 정보 관리 |
| HRegion | HTable의 크기에 따라 자동으로 수평 분할이 발생하고, 이때 분할된 블록을 HRegion 단위로 지정 |
| HRegionServer | 분산 노드별 HRegionServer가 구성되며, 하나의 HRegionServer에는 다수의 HRegion이 생성되어 HRegion 관리 |
| Store | 하나의 Store에는 칼럼 패밀리가 저장 및 관리되며, MemStore와 HFile로 구성됨 |
| MemStore | Store 내의 데이터를 인메모리에 저장 및 관리하는 데이터 캐시 영역 |
| HFile | Store 내의 데이터를 스토리지에 저장 및 관리하는 영구 저장 영역 |
3) HBase 아키텍처
- 가장 큰 특징은 하둡의 HDFS를 기반으로 설치 및 구성된다는 것
- 그로 인해 분산 데이터베이스 아키텍처를 채택하고 있으며,
- HDFS의 가용성과 확장성을 그대로 물려받음
-
클라이언트가 HBase에 데이터를 저장(put)하는 과정
- 클라이언트가 HBase 테이블에 특정 데이터를 저장하기 전, 주키퍼를 통해 HTable의 기본 정보와 해당 HRegion의 위치 정보를 알아냄
- 해당 정보를 기반으로 클라이언트가 직접 HRegionServer로 연결되어 HRegion의 Memory 영역인 MemStore에 데이터 저장
- 이때 MemStore에 저장된 데이터는 특정 시점이 되면 HFile로 HDFS에 플러시(Flush)되고, HFile은 HRegion의 상황에 따라 최적의 HFile로 재구성되는 작업이 이루어짐
- 이러한 플러시 과정들을 HBase에서는
Minor/Major Compaction이라고 함
- HBase에서 특정 데이터를 가져오는 과정
- 주키퍼를 통해 로우키(RowKey)에 해당하는 데이터의 위치 정보를 알아냄
- 해당 HRegionServer의 Memory 영역인 MemStore에서 데이터를 가져옴으로써 디스크 I/O를 최소화하면서 빠른 응답 속도 보장
- 만일 데이터가 MemStore에서 플러시되어 존재하지 않으면 HFile 영역으로 이동해 데이터 찾게 되는데, 이때 HBase와 HDFS 사이의 모든 데이터 스트림 라인들은 항상 열려있으므로 레이턴시가 발생하지 않음
(레이턴시: 시간 지연, 하나의 데이터 패킷을 한 지점에서 다른 지점으로 보내는데 소요되는 시간)
4) HBase 활용 방안
- 앞서 CH03에서 Flume을 이용해 수집한 스마트카 운전자의 운행 정보를 Kafka까지 전송했음
- 이번 장에서는 Kafka에 저장되어 있는 데이터를 Storm이 받아서 HBase의 테이블에 모두 적재
- 또한, HBase에 저장된 스마트카 운전자의 운행 정보를 특정 조건에 따라 필터링해서 신속하게 조회해 보고, 하이브 핸들러를 이용해 HBase에 저장된 데이터와 하이브 데이터를 동시에 활용해봄
3. Redis
1) 레디스 소개
- 분산 캐시 시스템이면서, NoSQL DB처럼 대규모 데이터 관리 능력도 갖춘 IMDG(In-Memory Data Grid) 소프트웨어
- 키/값 형식의 데이터 구조를 분산 서버 상의 메모리에 저장하면서 고성능의 응답 속도 보장
- 다양한 데이터 타입을 지원하기 때문에 데이터를 구조화해서 저장할 수 있어, 단순 키/값 이상의 데이터 복잡성도 처리할 수 있음
- 인메모리 데이터를 영구적으로 저장할 수 있는 스냅샷 기능 제공
- 데이터의 유실에 대비해 AOF(Append Only File) 기능으로 정합성 보장
- NoSQL의 특징인 데이터의 샤딩과 복제도 지원하여 높은 성능이 필요한 서비스에서 많이 사용됨
2) 주요 구성 요소
| 주요 구성 요소 | 설명 |
|---|---|
| Master | 분산 노드 간의 데이터 복제와 Slave 서버의 관리를 위한 Master 서버 |
| Slave | 다수의 Slave 서버는 주로 읽기 요청을 처리하고, Master 서버는 쓰기 요청을 처리 |
| Sentinel | 레디스 3.x부터 지원하는 기능으로, Master 서버에 문제가 발생할 경우 새로운 Master를 선출하는 기능 |
| Replication | Master 서버에 쓰인 내용을 Slave 서버로 복제해서 동기화 처리 |
| AOF / Snapshot | 데이터를 영구적으로 저장하는 기능으로, 명령어를 기록하는 AOF와 스냅샷 이미지 파일 방식 지원 |
3) 레디스 아키텍처
- 3.x에서부터 HA 기능이 강화되면서 클러스터의 완성도가 높아짐
- 요구사항과 데이터의 샤딩 및 복제 구성 방식에 따라 세가지 아키텍처 구성 가능
1) 레디스 아키텍처 1
- Single Master 형식
- 개발과 테스트 환경에 주로 사용됨
- 설치하기가 쉽고 단일 서버만으로도 빠른 응답 속도와 안정적인 기능을 제공함으로써 소규모이면서 중요도가 비교적 낮은 시스템 간의 데이터 공유에도 종종 사용됨
2) 레디스 아키텍처 2
- Single Master / Multi Slave 형식
- Master에 쓰여진 데이터는 복제를 통해 Slave 노드로 복제되면서 데이터 정합성 유지
- 쓰기 / 읽기 노드를 분리해서 전체적인 성능을 향상시킨 구성
- Slave 2와 같이 읽기 노드를 추가해서 성능을 극대화할 수 있음
3) 레디스 아키텍처 3
- 버전 3.x부터 지원되는 HA 클러스터링 구조
- 아키텍처 2는 두가지 문제점이 있음
- Master 서버 장애 발생 시 쓰기 요청이 실패하면서 데이터 유실이 발생할 수 있는 취약한 구조
- 클라이언트가 쓰기 노드와 읽기 노드를 알고 있으야 하므로 클라이언트 프로그램에 복잡도 발생
- 이러한 문제점 극복을 위해
Sentinel이라는 노드 모니터링/제어 컴포넌트 추가 - Sentinel이 노드들을 모니터링하고 있다가, Master 서버에 문제가 발생하면 Slave 노드 중 하나를 Master 노드로 지정하고, 문제가 됐던 Master 노드와 연결을 끊으면서 HA 기능 제공
4) 레디스 활용 방안
- 스마트카 운전자의 상태 정보를 실시간으로 분석
- 분석한 결과를 빠르게 저장하면서 주변 시스템과 공유하기 위한 저장소로 레디스 활용
- 위의 그림에서 Storm에서 두 개의 경로로 분리되는 것을 볼 수 있음
- HBase에는 운전자의 모든 상태 정보를 저장
- 레디스에는 운전자의 특정 패턴을 감지한 이벤트 결과(과속한 운전자 정보)만 저장
- 그러면 주변 응용 시스템에서 레디스에 적재된 정보를 빠르게 조회해서 활용하게 됨
4. Storm
1) 스톰 소개
- 스피드 데이터를 인메모리 상에서 병렬 처리하기 위한 소프트웨어
- 스피드 데이터는 원천 시스템의 수많은 이벤트가 만들어내며, 작지만 대규모의 동시다발적이라는 특성이 있음
- 이러한 스피드 데이터를 실시간으로 다루기 위해 모든 데이터를 인메모리 상에서 분산 병렬 처리하고, 분산 데이터를 통제하기 위한 강력한 기능(분리, 정제, 통합, 집계 등)과 아키텍처 제공
- 실시간 분산 처리 유형으로는 데이터 발생과 동시에 처리하는
완전 실시간 방식과, 발생한 데이터를 적재한 후 빠르게 배치를 실행하는마이크로 배치 방식이 있음 - 스톰은 전자에 해당하는 완전 실시간 방식으로, 조금의 레이턴시도 허용하지 않는 아키텍처에 적용
2) 주요 구성 요소
| 주요 구성 요소 | 설명 |
|---|---|
| Spout | 외부로부터 데이터를 유입받아 가공처리해서 튜플을 생성, 이후 해당 튜플을 Bolt에 전송 |
| Bolt | 튜플을 받아 실제 분산 작업 수행 필터링, 집계, 조인 등의 연산을 병렬로 실행 |
| Topology | Spout-Bolt의 데이터 처리 흐름 정의 하나의 Spout과 다수의 Bolt로 구성 |
| Nimbus | Topology를 Supervisor에 배포하고 작업 할당 Supervisor를 모니터링하다 필요 시 페일오버(Fail-over) 처리 |
| Worker | Supervisor 상에서 실행 중인 자바 프로세스로 Spout과 Bolt 실행 |
| Executor | Worker 내에서 실행되는 자바 스레드 |
| Tasker | Spout과 Bolt 객체가 할당 |
3) 스톰 아키텍처
1) Nimbus와 Supervisor
- Nimbus가 자바 프로그램으로 구성된 Topology Jar를 배포하기 위해 주키퍼로부터 Supervisor 정보 알아냄
- 그 후 해당 Topology Jar 파일을 각 Supervisor에 전송하면 Supervisor는 해당 Node에서 Worker, Executor를 만들고, Spout과 Bolt가 수행되기 위한 Task도 할당함
- Supervisor가 정상적으로 배포되면, Exeternal Source Application 1에서 발생한 데이터가 Spout을 통해 유입되기 시작
- 이를 다시 Bolt가 받아 데이터를 분산 처리하고, 처리 결과는 Bolt를 통해 타깃 시스템인 Exeternal Target Application 2로 전송됨
- 이때 Task, Executor 개수를 증가시키면서 대규모 병렬 처리가 가능해지고, Spout과 Bolt의 성능이 향상됨
- 매우 견고한 장애 복구 기능도 제공
- 만약 특정 Supervisor가 생성한 Worker 프로세스에 심각한 문제가 발생해 종료되면 Supervisor는 새로운 Worker 프로세스 다시 생성
- 이때 처리중이던 데이터들(튜플)은 이전 수신지로 롤백되고, Topology가 다시 정상적으로 복구되면 롤백 시점부터 다시 처리하면서 데이터 정합성 보장
4) 스톰 활용 방안
- 파일럿 프로젝트에서 스톰은 스마트카 운전자의 실시간 운행 정보를 대상으로 데이터 라우팅과 스트리밍 처리에 활용될 것
- 카프카의 Spout을 통해 유입되는 모든 운전자의 운행 정보 데이터는 두 개의 Bolt (HBase Bolt / Redis Bolt)로 나눠져서 처리됨
- HBase Bolt는 모든 운행 정보를 정제없이 HBase로 곧바로 적재
- Redis Bolt는
에스퍼라는 룰 엔진이 감지한 이상 운행 패턴의 정보만 레디스 서버에 저장
4. Esper
1) 에스퍼 소개
- 실시간 스트리밍 데이터의 복잡한 이벤트 처리가 필요할 때 사용하는 룰 엔진
- 스톰은 실시간으로 발생하는 데이터로부터 복잡한 패턴을 찾고, 그 패턴에 따른 이벤트 처리하는 것은 쉽지 않음
- 실시간으로 발생하는 데이터 간의 관계를 복합적으로 판단 및 처리하는 것을
CEP라고 하는데, 에스퍼가 이 CEP 기능을 제공함
2) 주요 구성 요소
| 주요 구성 요소 | 설명 |
|---|---|
| Event | 실시간 스트림으로 발생하는 데이터들의 특정 흐름 또는 패턴 정의 |
| EPL | 유사 SQL을 기반으로 하는 이벤트 데이터 처리 스크립트 언어 |
| Input Adapter | 소스로부터 전송되는 데이터를 처리하기 위한 어댑터 제공 (CSV, Socket, JDBC, http 등) |
| Output Adapter | 타깃으로 전송하는 데이터를 처리하기 위한 어댑터 제공 (HFS, CSV, Socket, Email, Http 등) |
| Window | 실시간 스트림 데이터로부터 특정 시간 또는 개수를 설정한 이벤트들을 메모리 상에 등록한 후 EPL을 통해 결과 추출 |
3) 에스퍼 아키텍처
1) 에스퍼 아키텍처 1
- 에스퍼는 CEP(Complex Event Processing) 엔진
- 엔진은 단순 자바 라이브러리 프로그램
- 애플리케이션 서버(톰캣, 제이보스, OSGI, 스톰 등) 또는 애플리케이션의 컨텍스트에 에스퍼 라이브러리를 설치하고, 해당 라이브러리를 이용해 CEP 프로그래밍을 하는 단순 아키텍처
2) 에스퍼 아키텍처2
- 에스퍼의 EPL을 이용해 대규모 분산 아키텍처를 구성할 때는 룰을 통합 관리하고, 분산 노드에 일관되게 적용하기 위해 위 이미지처럼 다소 복잡한 구성 필요
- 이때 분산된 응용 서버에 에스퍼 엔진을 설치하고, 에스퍼 엔진들이 동일한 EPL 룰을 동작으로 일괄 로딩하기 위해 EPL 공유 저장소가 이용됨
4) 에스퍼 활용 방안
- 파일럿 프로젝트에서는 운전자의 운행 데이터를 실시간으로 분석하기 위해 데스퍼 EPL 활용
- EPL은 30초 동안의 평균 시속을 체크해서 80km/h를 초과하는 운전자 이벤트 정보를 실시간으로 감지할 수 있도록 룰 정의
- 해당 이벤트 데이터는 감지 즉시 레디스에 적재되어 과속한 차량 정보만 관리할 수 있게 됨
5. 실시간 적재 아키텍처
1) 실시간 적재 요구사항
요구사항 1: 차량의 다양한 장치로부터 발생하는 로그 파일을 수집해서 기능별 상태 점검요구사항 2: 운전자의 운행 정보가 담긴 로그를 실시간으로 수집해서 주행 패턴 분석
| 실시간 적재 요구사항 구체화 | 분석 및 해결 방안 |
|---|---|
| 1. 1초 간격으로 발생하는 100명의 운행 정보(1건: 약 4KB는 손실없이 적재해야 함 | 카프카와 스톰을 이용해 수집한 데이터에 대해 분산 처리 및 무결성 보장, 분산 처리가 완료된 데이터는 HBase에 적재 |
| 2. 적재한 운행 정보를 대상으로 조건 검색이 가능해야 하며, 필요시 수정도 가능해야 함 | HBase의 테이블에 적재된 데이터는 스캔 조건으로 검색하며, 저장(Put) 기능을 이용해 기적재한 데이터에 대해 칼럼 기반으로 수정 |
| 3. 운전자의 운행 정보 중 30초를 기준으로 평균 속도가 80km/h를 초과한 정보는 분리 적재함 | 에스퍼의 EPL에서 사용자별로 운행 정보를 그루핑하고, 30초의 윈도우 타임 조건으로 평균 시속 집계 및 임계치별 이벤트 정의 |
| 4. 과속한 차량을 분리 적재하기 위한 조건은 별도의 룰로 정의하고 쉽게 수정할 수 있어야 함 | 과속 기준을 80km/h에서 100km/h로 수정해야 할 경우 EPL의 평균 속도를 체크하는 조건값만 수정 |
| 5. 분리 적재한 데이터는 외부 애플리케이션이 빠르게 접근하고 조회할 수 있게 해야 함 | 실시간 이벤트로 감지된 데이터는 인메모리 기반 저장소인 레디스에 적재하여 외부 애플리케이션에서 빠르게 조회 |
| 6. 레디스에 적재한 데이터는 저장소의 공간을 효율적으로 사용하기 위해 1주일이 지나면 영구적으로 삭제함 | 레디스 클라이언트 라이브러리인 **제디스(Jedis) 클라이언트를 이용해 데이터 적재 시 만료(Expire) 시간을 설정해 자동으로 영구 삭제 처리 |
2) 실시간 적재 아키텍처
- CH03에서는 플럼의 DriverCarInfo 에이전트에서 수집한 운전자 운행 정보를 카프카의 토픽에 실시간으로 전송함
- Ch05에서는 스톰의 카프카-Spout을 이용해 카프카의 토픽에 저장되어 있는 운전자 운행 정보를 가져와 처리하고, 카프카-Bolt에서 이벤트 조건에 따라 레디스와 HBase에 각각 분리 적재함
스톰의 실시간 데이터 처리
- 스톰은 카프카로부터 수신받은 운행 정보 데이터를 분산 처리하고, 최종 목적지 저장소에 적재하는 역할
- 이때 빠르게 유입되는 데이터로부터 의미 있는 패턴을 발견하기 위해 에스퍼 엔진 이용
- 그림에서 ⓵)
- 스톰의 Spout가 카프카의 토픽으로부터 운전자의 실시간 운행 정보를 수신받아 첫 번째 볼트에 전송
- 해당 Bolt에서는 모든 운행 정보를 HBase Bolt로 전송하면서, 에스퍼의 EPL에서 정의한 조건에 따라 과속한 차량의 정보를 레디스 Bolt에 전송
HBase에 모든 운전자 운행 정보 적재
- 그림에서 ⓶)
- HBase의 테이블에는
차량번호+발생일시를 로우키로 해서 8개의 칼럼의 구조로 모든 스마트카 운전자의 운행 정보가 적재됨 - 칼럼 (발생일시, 차량번호, 가속 페달, 브레이크 페달, 운전대 회전각, 방향지시등, 주행 속도, 주행 구역)
- HBase의 테이블에는
레디스에 과속한 운전자 정보 적재
- 그림에서 ⓷)
- 레디스에 적재될 때는 현재 날짜를 키로 해서 과속한 차량의 정보를 세트 데이터 구조로 적재
- 적재 영속 시간은 5시간으로 하며, 이후에 만료 처리되어 메모리에서 자동으로 삭제됨
6. 실시간 적재 환경 구성
- 3개의 소프트웨어 추가 설치
- CM으로
HBase를 Server01, 02에 있는 데이터노드에 설치 레디스와스톰은 CM에 포함되어 있지 않은 소프트웨어로 별도의 패키지로 설치
- CM으로
