소프트웨어공학 포털 블로그

2016년 8월 9일 화요일

CEP 아키텍처 기반의 실시간(Real-time)처리

배치 처리가 아닌 실시간 처리가 필요할 경우, CEP(Complex Event Processing) 아키텍처를 활용한다. 데이터 수집 즉시, 전처리, 계산, 패턴 분석을 처리한다. 많이 사용되는 구성은 그림7과 같고, 각 레이어 별 대표적인 구성 요소는 표4와 같다.

<표4> CEP(Complex Event Processing)의 구성 요소

구성 요소	내용
Log Collector	- 이벤트를 실시간으로 수집 - 예) Apache Flume
Message Queue	- 이벤트를 임시로 저장 - 예) Apache Kafka
Real-time Pre-Processing	- 실시간으로 전처리가 필요할 경우 사용 - 예) (Real-time Hadoop이라 불리는 Twitter에서 만든) Apache Storm
Real-time Computing	- 실시간 계산 및 실시간 패턴 분석 - 예) (대표적인 CEP 엔진인) Esper

<그림7> CEP 아키텍처의 실시간(Real-time)처리

출처: http://hadoop.apache.org/

빅데이터를 위해 배치 처리를 하는 하둡(Hadoop) 아키텍처 기반의 시스템과 실시간 처리를 하는 CEP(Complex Event Processing) 아키텍처가 존재한다. 데이터를 실시간 처리해야 하는 경우라면 CEP 아키텍처를, 그렇지 않은 경우는 하둡 아키텍처를 사용하면 되는데 워낙 많은 데이터를 처리해야 하는 빅데이터이기 때문에 하둡 아키텍처가 많이 사용된다.

(1) 하둡 아키텍처 기반의 배치(Batch)처리

배치 처리을 위한 하둡 아키텍처는 다양한 형태로 구성되는데 많이 사용되는 구성은 그림6과 같고, 각 레이어 별 대표적인 구성 요소는 표3과 같다.

<표3> 하둡 아키텍처의 구성 요소

구성 요소	내용
Log Collector	- 로그 이벤트 수집기 레이어로 많이 사용 - 예) Apache Flume
DB Collector	- DB에 저장된 데이터를 수집 - 예) Apache Sqoop
Message Queue	- 로그,이벤트 내용을 Data Store에 넣기 전에 임시로 저장할 경우 사용 - 예) Apache Kafka
Data Store	- 분산 파일 시스템으로 구성 - 예) Apache Hadoop
Data Analysis	- 데이터 분석을 위한 - 예) Apache Pig, Hive, Map/Reduce
Workflow	- Job 제어를 위함 - 예) Apache Oozie, LinkedIn의 Azkaban 등

<그림6> 하둡 아키텍처의 배치 처리

출처: http://hadoop.apache.org/

교통안전공단의 “자동차운행정보 관리시스템” 사례

본 사례는 교통안전공단에서 구축한 시스템이다. 자동차의 운행정보를 수집하고 분석해서 교통안전공단에서 필요한 정보를 전달하고 관리한다. 이 사례는 데이터가 정형화 되어 있어 비정형 데이터에 대해서는 관리하지 않아 수집된 모든 데이터가 데이터베이스 서버에 저장된다.

<그림5> 교통안전공단의 빅데이터 아키텍처에 레이어 맵핑

출처: 교통안전공단

그림5를 살펴보면, 그림의 숫자는 그림2에서 나타낸 각 레이어의 번호와 맵핑 되어 있다. 자동차의 운행정보를 수집(①데이터 수집)하고 있고, 수집된 데이터를 정제(②데이터 정제)하여 분석 시스템으로 보내게 된다. 분석 시스템은 미리 정의된 기준에 따라 데이터를 분석(③데이터 분석)하게 되고, 분석된 데이터는 데이터베이스에 저장(④데이터 정보화)한다. 마지막으로, 정보를 시각화(⑤정보 시각화)하여 보여주게 된다. 나머지 부분은 데이터에 대한 정책, 연계 등을 위한 모니터링, 관리 시스템으로 구분된다.

2016년 8월 8일 월요일

IBM의 “빅데이터 플랫폼 비즈니스 시스템” 사례

IBM은 분석용 데이터 저장관리업체인 네티자(Netezza), 데이터통합업체인 에센셜(Essential), 분석 솔루션 업체인 코그너스(Cognus) 등 다수의 비즈니스 분석 업체들을 인수하여 자체 빅데이터 솔루션으로 인포스피어 빅인사이트[InfoSphere Biginsight(Hadoop)], 인포스피어 스트림즈(InfoSphere Streams) 등을 개발했다.

<그림4> IBM의 빅데이터 아키텍처에 레이어 맵핑

출처: IBM

그림4를 살펴보면, 데이터를 수집/변환(①데이터 수집, ②데이터 정제)하고, 데이터를 저장/처리(③데이터 분석, ④데이터 정보화)한다. 마지막으로, 데이터분석/시각화(⑤정보 시각화)를 통해 정보를 제공한다.

사례별 빅데이터 아키텍처의 레이어 맵핑

시중에 알려져 있는 빅데이터 시스템은 대부분 위에서 언급한 아키텍처 레이어로 구성되어 있다. 이번 사례 연구는 언급된 5개의 레이어로 구분하여 살펴보고 각 레이어 별로 특징을 살펴보려 한다. 아키텍처를 그리는 전문가에 따라 아키텍처가 다양한 형태로 나타나지만, 아무리 복잡해도 5개의 레이어로 구분할 수 있다.

그림3은 오픈소스컨설팅의 빅데이터 통합 분석 아키텍처다. 앞에서 언급한 두 개의 예제처럼 5개의 빅데이터 아키텍처 레이어로 구분할 수 있다. 이렇게 구분하는 것을 강조하는 이유는 빅데이터 아키텍처를 구성할 때 해당 레이어에 속한 솔루션을 고민하면서 선택하는 것이 편하다는 것이다.

<그림3> 오픈소스컨설팅의 빅데이터 아키텍처에 레이어 맵핑

출처: 오픈소스컨설팅

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

아키텍처의 가장 중요한 요소는 강건성이다. 아키텍처의 강건성은 외부 요인에 의해 아키텍처가 흔들리지 않는 것을 말한다. 다시 말해, 아키텍처 구성을 완료한 후, 외부 요인을 변경했을 때 기존에 구성한 아키텍처가 변경되지 않는 것을 나타낸다. 빅데이터 아키텍처를 구성하는데 강건성을 유지시킬 필요한 전제 조건이 몇 가지 있다.

< 빅데이터 아키텍처를 구성하는데 필요한 전제 사항 >

- 데이터의 라이프 사이클(수집, 정제, 분석, 저장, 폐기) 관리 가능

- 데이터 유형의 변화에도 아키텍처의 변경 없이 적용 가능

- 다양한 분석 알고리즘이나 도구가 적용 가능

- 비즈니스 요구사항에 맞는 적절한 분석 방법 지원

- 데이터의 용량이 증가해도 즉시 대응 가능

위와 같은 전제 사항을 기초로 빅데이터 아키텍처의 각 레이어에 맞춰 인프라를 구성하게 되는데 비즈니스 요구사항에 맞는 솔루션 선정, 구성하는 아키텍처와 인프라에 대한 기술적 이해, 각 레이어 간 연결 방안 수립, 그리고 아키텍처와 인프라에 대한 관리 도구 선정이 반드시 필요하다(표1).

<표1> 빅데이터 아키텍처의 구성 요건

이 밖에, 빅데이터 아키텍처는 아키텍처의 중요 요소인 강건성이 확보된 상태에서 확장이 용이하도록 확장성, 이중화 등으로 시스템이 안정적으로 운영될 수 있도록 안정성, 비즈니스 요구사항에 맞추어 다양한 솔루션으로 대체가능 하도록 유연성이 확보되어야 한다.

2016년 8월 5일 금요일

SW테스팅프론티어 서비스

서비스 내용

- 지역 내 중ㆍ소 SW 기업의 SW 테스팅 전문인력 육성과 역량강화를 위해 테스팅 프론티어 서비스를 무료로 제공
- 본 서비스는 지역 SW기업을 위한 맞춤형 서비스로 각 지역 SW 진흥기관과의 긴밀한 협력을 통해서 수행
- 지역 SW진흥기관의 수요기업 모집을 통해 교육 대상 및 일정을 확정하여 지역 SW진흥기관에서 교육 서비스를 실시
- 컨설팅 서비스를 요청한 업체에 대해서는 기업별로 일정을 확정하여 직접 방문 서비스를 실시
- 소프트웨어공학센터 포털 사이트를 통해 업체에서 서비스를 신청하면 담당자와 협의를 통해 서비스를 실시

피드 구독하기: 글 ( Atom )