[끄적끄적] Apache Storm, Hbase, 빅데이터 보안, Flume&Kafka

* 스톰 

1. 개요 

- 실시간 데이터를 병렬 분산 처리하기 위한 SW.  실시간 처리를 위해서는 이벤트가 발생함과 동시에 감지하여 데이터를 적재하는 방식과 데이터 적재와 동시에 마이크로 배치를 실행해 이벤트를 감지하는 방식이 있는데, 스톰은 전자에 해당한다. 

2. 주요 구성요소 

- spout : 외부로부터 데이터를 유입받아 가공 처리해서 튜플을 생성. 이후 해당 튜플을 bolt에 전송 

- bolt : 튜플을 받아 실제 분산 작업을 수행하며, 필터링(filtering), 집계(aggregation), 조인(join)등의 연산을 병렬로 실행 

- topology : spout-bolt의 데이터 처리 흐름을 정의. 하나의 spout와 다수의 bolt로 구성 

- nimbus : topology를 supervisor에 배포하고 작업을 할당. supervisor를 모니터링하다 필요 시 fail-over 처리 

- supervisor : topology를 실행할 worker를 구동시키며 topology를 worker에 할당 및 관리 

- supervisor 상에서 실행중인 자바 프로세스로 spout와 bolt를 실행 

- executor : worker 내에서 실행되는 자바 스레드 

- tasker : spout 및 bolt 객체가 할당 

3. 아키텍처 

- Nimbus가 서버 프로그램으로 구성된 topology jar를 배포하기 위해 zookeeper로부터 supervisor의 정보를 알아낸다. 그 후 해당 topology jar 파일을 각 supervisor에 전송하면 supervisor는 node에 worker 프로세스를 생성하고 woker에서는 내부적으로 executor들을 만든다. 또 executor 안에는 task가 할당되는데 그 안에서 spout와 bolt가 실행된다. supervisor가 정상적으로 배포되면, external source 에서 발생한 데이터가 spout를 통해 유입되기 시작한다. 이 데이터는 spout에서 bolt로 전달되어 분산처리하고, 처리 결과는 bolt를 통해 external target 시스템에 저장한다. bolt/spout는 executor에서 수행되기 때문에, executor의 수를 늘려주면 대규모 병렬 처리가 가능해지고 성능이 향상된다.  

- 만약 특정 supervisor가 생성한 worker 프로세스에 심각한 문제가 발생해 종료되면 supervisor는 새로운 worker 프로세스를 다시 생성한다. 이때 처리중이던 데이터(튜플)들은 이전 수신지로 롤백되고 topology가 다시 정상적으로 복구되면 롤백 시점부터 spout가 다시 처리하면서 데이터의 정합성을 보장한다. 

* HBase 

1. 개요 

- Hbase는 하둡 기반의 column-based NoSQL DB이다.  NoSQL Db는 데이터를 단순히 key/value 형식으로 단순하게 구조화 하는 대신고성능의 쓰기/읽기가 가능하도록 만든  DB인데, Hbase의 경우 특히 쓰기 성능에 더 최적화 되어 있어 빅데이터 처리에서 자주 사용된다. Google의 BigTable 논문을 모델로 개발이 시작되었고 hadoop과 함께 가장 오래된 에코이다. 

2. 주요 구성요소 

- HTable : 칼럼 기반 데이터 구조를 정의한 테이블로써, 공통점이 있는 칼럼들의 그룹을 묶은 column-family와 table의 각 row를 식별해서 접근하기 위한 row-key로 구성. 

- HMaster : HRegion 서버를 관리하며, HRegion들이 속한 HRegion 서버의 meta 정보를 관리 

- HRegion : HTable의 크기에 따라 자동으로 수평 분할이 발생하고, 이때 분할된 블록을 HRegion 단위로 지정 

- HRegionServer: 분산 노드별 HRegionServer가 구성되며, 하나의 HRegionServer에는 다수의 HRegion이 생성되어 HRegion을 관리 

- Store : 하나의 Store에는 하나의 column-family가 저장 및 관리되며, memStore와 HFile로 구성된다. (하나의 column-family는 1개 이상의 store를 가짐, 1:N 관계) 

- MemStore : Store 내의 데이터를 in-memory에 저장 및 관리하는 데이터 cache 영역

- HFile : Store 내의 데이터를 스토리지에 저장 및 관리하는 영구 저장 영역 

3. 아키텍처 

- Hbase는 반드시 HDFS 기반으로 설치 및 구성된다. 하둡 없는 HBase 구성은 없다. 

- Clinet가 Hbase에 데이터를 저장하기 위해서는 zookeeper를 통해 HMaster의 meta 정보를 가져온다. (HTable 기본 정보 및 HRegion 위치 등) 그 정보를 바탕으로 client가 직접 HRegionServer에 접속하여 HRegion의 memStore에 데이터를 저장한다. memStore의 임계치 설정에 따라 특정 시점이되면 memStore에 있던 데이터가 HFile로 flush 되고, HFile 역시 설정된 임계치의 이벤트 시점이 되면 HDFS로 데이터를 flush 한다. 이러한 flush 과정을 Hbase에서는 Major/Minor Compaction 이라고 한다. 

- HBase에서 특정 데이터를 가져오는 과정도 우선 client에서 zookeeper를 통해 rowkey에 해당하는 데이터의 위치 정보를 알아내고 해당 HRegionServer의 memStore에서 데이터를 가져와 disk I/O를 최소화 시킨다. 만약 데이터가 memStore에서 flush되어 존재하지 않는다면 HFile 영역으로 이동해 데이터를 찾게되고, 그래도 없으면 HDFS에서 데이터를 찾게된다. 

* 접근제어 보안 

1. 개요 

- 대용량 분산처리 시스템의 접근제어를 완벽하게 처리하는 데는 어려움이 많다. 빅데이터 시스템의 물리적 N/W 위치는 대부분 내부망 안에 있기 때문에 외부 공격이나 불특정 다수에 의해서 조작될 위험이 없기 때문에, 저수준의 접근제어 정책을 사용한다. 하지만 민감한 개인정보를 다루는 비즈니스인 경우 고수준의 접근제어 정책과 보안 준수를 요구하고 있으며 이를 해결하기 위해 Knox, Sentry, Ranger, kerberos 등을 활용한다. 

2. 주요 컴포넌트

- Apache Knox : 네트워크 상의 DMZ에 위치하여 외부 client가 하둡 echosystem에 직접 접근하는 것을 막고, 항상 knox를 거쳐 통신하게 하는 중간 gateway 역할을 수행한다. LDAP(Lightweight Directory Access Protocol)과 KDC(Key Distribution Center)로 제공받을 수 있다. 

- Apache Sentry : HDFS에 상세한 접근제어(하둡 파일/디렉토리, Hive table 등) 의 접근제어가 필요한 경우 사용된다. 하둡 데이터에 접근하려는 client는 sentry agent를 반드시 설치해야 하고 sentry agent가 중앙에 있는 sentry server와 통신하면서 접근 권한을 얻게된다. 또한 접근 이력을 관리하는 기능이 있어 향후 audit 로그를 편리하게 조회할 수 있다. 

- Apache Ranger는 sentry와 유사한 역할을 하며 아키텍처도 큰 차이가 없다. Ranger는 Hortonwork에서 Sentry는 cloudera에서 지원하고 있으며 Ranger가 지원하는 에코가 많아 범용성이 더 높은 편이다. Ranger를 사용할 경우 plugin을 통해 ranger서버와 통신하게되고 audit 로그 기능을 제공한다. 

- Kerberous : KDC(Key Distribution Center) 시스템으로 불리며 빅데이터 외에도 범용화된 인증 시스템이다. 커버로스는 크게 AS(Authentication Service)라는 인증 서버와 TGS(Ticket Granting Service) 라는 티켓 발행 서버로 구성된다. HDFS에 접근하려는 client 는 AS 인증서버를 통해 인증을 수행하고 TGS 티켓발행서버로 부터 HDFS에 접근을 허용하는 티켓을 발행받는다. 이후부터는 유효한 티켓만 있으면 HDFS에 인증 없이 접근할 수 있다. 

* Kafka & Flume 

- Flume이 빠르게 생성되는 데이터를 실시간으로 수집하게 되면 이를 최종 목적지에 전달하기 전에 중간에서 안정적으로 buffering(queuing) 처리를 해주기 위해 kafka를 사용한다. 만약 flume이 수집한 데이터를 kafka를 거치지 않고 곧바로 목적지(Hbase, ElasticSearch 등)에 전송하게 되는 경우 목적지에 장애가 발생하면 flume의 channel이 event로 가득차게되고 데이터를 수집할 수 없게된다. 실시간으로 생성되는 event의 경우 데이터 유실이 불가피 함으로 곧 바로 장애로 이어진다. 

- Flume의 agent를 여러 계층으로 구성함으로써 위와 같은 문제를 완화시킬 수 있으나 결국은 모든 channel이 가득차는 경우 똑같은 장애로 이어진다. 

출처 - '실무 프로젝트로 배우는 빅데이터 기술'