KR101966201B1 - 빅 데이터의 실시간 저장 및 검색 시스템 - Google Patents

Abstract

대량의 데이터 생성에 대응하여 실시간으로 데이터의 유실 없이 메모리에 저장하고, 이를 실시간으로 동시에 검색할 수 있도록 하고, 일정 수준의 양만 메모리에 남겨두고 나머지 오래된 데이터는 HDFS(Hadoop Distributed File System)에 구조화된 형태로 저장하고 이를 신속하게 검색할 수 있도록 한 빅 데이터의 실시간 저장 및 검색 시스템에 관한 것으로서, Data Source 라이브러리인 BDI(TeraStream BASS Data Source API)를 통해 데이터의 수집하는 데이터 수집부, 클라이언트 라이브러리인 BCI(TeraStream BASS Client API)를 통해 데이터를 검색하는 클라이언트, 실시간으로 데이터 수집을 위한 메모리 클러스터(Memory Cluster)와 디스크(Disk) 저장 공간인 하둡 클러스터(Hadoop Cluster)로 이중화된 데이터 저장부, 데이터 저장부에 구성된 클러스터를 통합 관리하고, 데이터 수집부의 데이터 수집을 관리하며, 클라이언트의 검색 요청에 따라 검색 결과를 웹 또는 사용자 인터페이스(UI)로 전송하도록 관리하는 데이터 검색 및 저장 제어부를 포함하여, 빅 데이터의 실시간 저장 및 검색 시스템을 구현한다.

Description

빅 데이터의 실시간 저장 및 검색 시스템{Big data archiving and searching stsrem}

본 발명은 빅 데이터의 실시간 저장 및 검색 시스템에 관한 것으로, 특히 대량의 데이터 생성에 대응하여 실시간으로 데이터의 유실 없이 메모리에 저장하고, 이를 실시간으로 동시에 검색할 수 있도록 하고, 일정 수준의 양만 메모리에 남겨두고 나머지 오래된 데이터는 HDFS(Hadoop Distributed File System)에 구조화된 형태로 저장하고 이를 신속하게 검색할 수 있도록 한 빅 데이터의 실시간 저장 및 검색 시스템에 관한 것이다.

최근 저비용 서버를 이용한 대량의 클러스터(Cluster)를 통한 분산처리 기술이 급격히 발전함에 따라 기존에 저장 및 분석할 수 없었던 대량의 데이터를 분석하기 위한 시도가 동시 다발적으로 시도되고 있다. 이러한 대량 혹은 분석에 폭발적인 컴퓨팅 파워가 필요한 데이터 저장 및 분석 기술을 별도로 빅 데이터(Big Data) 기술이라는 기술 셋으로 지칭하는 명칭이 생겨날 정도로 기술적, 사회적으로 파장을 일으키고 있다.

이러한 빅 데이터 처리 기술의 핵심인 분산 저장 및 분산 처리의 중심에는 현재 오픈소스인 하둡(Hadoop)과 이를 이용하는 수많은 소프트웨어 그룹이 기술적인 트랜드를 주도하고 있는 상황이다.

현재 빅 데이터 기술은 크게 실시간 데이터 분석을 위한 Streaming Data Clustering과 대량의 데이터를 빠르게 분석하는 Batch Clustering으로 구분되어 발전하고 있으며, 특히 최근 대량의 센서 데이터 등의 Machine Generated Data에 관심이 집중되면서 Streaming Data Clustering과 Machine Learning을 이용한 Data Mining이 관심을 받고 있다.

그러나 기술적으로 아직 해결할 과제가 많아 많은 기업에서 기술선점을 위해 이 분야에 다양한 연구들이 진행되고 있다.

이미 설명한 바와 같이 기존 Big Data 기술은 Batch 분석과 실시간 분석이라는 두 분야로 나뉘어 상호 보완 및 경쟁하는 형태로 발전하고 있다. 그러나 아직 실시간 분석과 Batch 분석의 요건이 혼재하는 상황에서는 Big Data 연구 분야에서 해답을 찾지 못하고 있는 상황이며 실제 이러한 상황에 Big Data Platform을 적용해야 하는 상황에서는 매우 복잡하고 불확실한 Architecture를 선택할 수밖에 없는 것이 현실이다.

특히, 기존 Hadoop 중심의 저장 및 분산 시스템에서는 데이터 저장을 위한 공간은 Clustering을 통해 증가하였으나, 실제적으로는 대량으로 발생하는 데이터에 대한 수집은 아직 풀어야 할 숙제가 많은 분야이다. Hadoop의 저장 공간 역할을 하고 있는 HDFS(Hadoop Distributed File System)는 데이터를 읽는 것은 분산처리를 통해 매우 빠르게 처리할 수 있지만, 데이터를 쓰는 것은 상대적으로 느리기 때문에 데이터 수집을 위한 별도의 소프트웨어가 필요하고, 이 수집을 위한 소프트웨어가 수집 성능을 결정하게 된다. 그리고 수집된 데이터에 대한 분석은 Hadoop을 이용할 경우 Batch 형태의 분석에는 용이하나 실시간에 대응하는 형태의 즉시 대응을 위한 분석은 응답시간의 문제로 인해 또다시 별도의 분석 소프트웨어가 필요하게 된다. 이러한 Hadoop의 특성으로 인해 실시간성 분석과 Batch 분석 요건을 동시에 만족시키는 것은 현재 Big data 기술 수준으로는 소프트웨어 Architecture 구성도 쉽지 않으며, 실시간 분석에 대한 응답속도도 사용자가 만족할 만한 수준에 미치지 못하는 상황이다.

실시간으로 데이터를 저장하고 검색하기 위해서 종래에 제안된 기술이 하기의 <특허문헌 1> 에 개시되어 있다.

<특허문헌 1> 에 개시된 종래기술은 컴퓨팅 장치에서 수행되는 실시간 검색을 위한 데이터 인덱싱 방법으로서, 메모리의 문서를 로그 파일로 기록하는 단계, 로그 파일에서 읽은 정보의 적어도 일부를 포함한 일정량의 문서를 선택하는 단계, 문서에 대한 적어도 하나의 임시 세그먼트를 생성하는 단계, 적어도 하나의 임시 세그먼트를 검색엔진의 검색에 노출하는 단계, 및 적어도 하나의 임시 세그먼트가 노출된 상태에서 적어도 하나의 임시 세그먼트에 포함된 문서가 머징(merging) 중이면, 해당 삭제 후보 문서의 식별자를 저장한 삭제 요청 파일을 생성하는 단계를 포함하여, 실시간 검색을 위한 데이터 인덱싱 방법을 구현한다.

대한민국 등록특허 10-1744017(2017.06.07. 공고)(실시간 검색을 위한 데이터 인덱싱 방법 및 장치)

그러나 상기와 같은 종래기술도 실시간 검색을 위한 데이터 인덱싱 방법을 제공할 수는 있으나, 대량으로 발생하는 빅 데이터를 실시간으로 메모리에 저장하는 것은 제공해주지 못하는 단점이 있다.

따라서 본 발명은 상기와 같은 종래기술에서 발생하는 제반 문제점을 해결하기 위해서 제안된 것으로서, 대량의 데이터 생성에 대응하여 실시간으로 데이터의 유실 없이 메모리에 저장하고, 이를 실시간으로 동시에 검색할 수 있도록 하고, 일정 수준의 양만 메모리에 남겨두고 나머지 오래된 데이터는 HDFS(Hadoop Distributed File System)에 구조화된 형태로 저장하고 이를 신속하게 검색할 수 있도록 한 빅 데이터의 실시간 저장 및 검색 시스템을 제공하는 데 그 목적이 있다.

상기한 바와 같은 목적을 달성하기 위하여, 본 발명에 따른 빅 데이터의 실시간 저장 및 검색 시스템은 검색 시스템은, Data Source 라이브러리인 BDI(TeraStream BASS Data Source API)를 통해 데이터의 수집하는 데이터 수집부; 클라이언트 라이브러리인 BCI(TeraStream BASS Client API)를 통해 데이터를 검색하는 클라이언트; 실시간으로 데이터 수집을 위한 메모리 클러스터(Memory Cluster)와 디스크(Disk) 저장 공간인 하둡 클러스터(Hadoop Cluster)로 이중화된 데이터 저장부; 상기 데이터 저장부에 구성된 클러스터를 통합 관리하고, 상기 데이터 수집부의 데이터 수집을 관리하며, 상기 클라이언트의 검색 요청에 따라 검색 결과를 웹 또는 사용자 인터페이스(UI)로 전송하도록 관리하는 데이터 검색 및 저장 제어부를 포함하는 것을 특징으로 한다.

상기에서 데이터 검색 및 저장 제어부는 상기 데이터 저장부의 메모리 클러스터의 각 노드에 사용할 데이터를 미리 할당하고, 상기 BDI로부터 수집되는 데이터를 직접 상기 각 노드에 저장하는 것을 특징으로 한다.

상기에서 데이터 검색 및 저장 제어부는 사용할 전체 메모리를 복수의 소 메모리 블록으로 분할하고, HDFS에 저장하는 단위를 상기 분할한 소 메모리 블록 단위로 처리하는 것을 특징으로 한다.

상기에서 데이터 검색 및 저장 제어부는 하나의 BDI로부터 전송되는 데이터는 모든 노드에 분산저장하며, 하나의 메모리 블록에는 하나의 스키마(Schema)의 데이터만 저장하는 것을 특징으로 한다.

상기에서 데이터 검색 및 저장 제어부는 상기 BCI(TeraStream BASS Client API)를 통해서 BASS SQL을 이용하여 데이터 검색이 요청되면, Master에서 구문 검사를 거친 후 모든 Slave Node로 SQL을 전달하고, 전달된 SQL에 따라 해당 Schema가 저장된 모든 메모리 블록의 Index에서 해당 데이터 검색을 수행하는 것을 특징으로 한다.

상기에서 데이터 검색 및 저장 제어부는 요청된 데이터 검색이 HDFS 검색을 동반할 경우, 데이터 검색을 위한 Map/Reduce 프로그램이 자동으로 생성되며, Hadoop Cluster 전체 데이터를 기반으로 검색을 수행하고, 수행 결과는 상기 BCI로 전달하는 것을 특징으로 한다.

상기에서 데이터 검색 및 저장 제어부와 데이터 수집부 또는 클라이언트 또는 데이터 저장부는 커넥터-어댑터(Connector-Adapter) 연결 모델을 사용하여 서버-클라이언트 연결을 수행하며, 상기 커넥터는 클라이언트 프로그램이 서버 프로그램으로 접속할 때 사용하는 객체로서, 로그인 요청, 명령 전송 및 응답 수신, 로그오프 통지에 대한 프로토콜을 포함하고, 상기 어댑터는 서버 프로그램이 클라이언트 프로그램으로부터의 접속을 받아들일 때 사용하는 객체로서, 로그인 승인, 명령 처리 및 응답 전송, 로그오프 처리에 대한 프로토콜을 포함하는 것을 특징으로 한다.

상기에서 데이터 검색 및 저장 제어부는 마스터 노드 호스트 머신과 슬레이브 노드 호스트 머신을 포함하고, 상기 마스터 노드 호스트 머신은 슬레이브 맵이라는 객체를 통해 슬레이느 노드를 제어하는 것을 특징으로 한다.

상기에서 슬레이브 맵은 하위에 슬레이브 기술자 객체의 집합을 포함하고, 상기 슬레이브 기술자는 슬레이브 어댑터에 대한 참조를 가지고 직접 슬레이브 노드와 통신하는 것을 특징으로 한다.

상기에서 마스터 노드 호스트 머신은 주기적인 하트비트 교환, 특정 슬레이브 노드의 기동/종료/제거, 새로운 슬레이브 노드의 추가를 관리하는 것을 특징으로 한다.

상기에서 데이터 저장부는 메모리 맵이라는 객체를 이용하여 메모리 블록을 관리하며, 상기 메모리 맵은 미리 배정되어 있는 메모리 블록의 참조를 요소로 삼는 큐와 스택을 이용하여 메모리 블록을 관리하는 것을 특징으로 한다.

상기에서 메모리 맵은 Free Block Stack에 그 참조가 모두 등록된 메모리 블록의 스택을 검사하여 메모리 블록을 배정하되, 상기 메모리 블록의 상태를 "BUSY"로 변경하고, Holding Count라 불리는 값을 1 증가시킨 후, 메모리 블록이 가득 차거나, 데이터를 전송하던 세션이 종료되면 블록의 상태를 "FULL"로 변경하고, 해당 메모리 블록의 참조를 Full Block Queue에 등록하는 것을 특징으로 한다.

상기에서 데이터 수집부의 BDI 및 클라이언트의 BCI는 모든 슬레이브 노드로 직접 접속하여 수집 데이터를 저장하거나, 저장된 데이터를 검색하는 것을 특징으로 한다.

상기에서 데이터 저장부는 상기 BDI가 데이터를 전송하고 슬레이브 노드가 메모리 블록에 데이터를 저장하기까지의 구간인 저장 구간, 상기 BCI가 쿼리를 전송하고 검색된 데이터를 수신하는 조회 구간을 기초로 데이터 저장과 검색을 수행하는 것을 특징으로 한다.

상기에서 데이터 저장부는 메모리의 가용성 확보를 위해, 오래된 데이터부터 HDFS에 저장하여 메모리를 확보하는 것을 특징으로 한다.

상기에서 데이터 검색 및 저장 제어부는 생산자-소비자 모델을 이용하며, 상기 생산자는 인터페이스 호출로 데이터를 버퍼링하는 구조를 이용하고, 상기 소비자는 주기적으로 버퍼를 검사하여 데이터가 존재할 경우 벌크로 전송하는 구조를 이용하며, 이를 이용한 주기적 전송 모델을 통해 대용량 데이터를 고속으로 전송하는 것을 특징으로 한다.

상기에서 주기적 전송 모델은 라운드-로빈(Round-Robin) 방식을 이용하여 로드 밸런싱을 구현하는 것을 특징으로 한다.

상기에서 데이터 검색 및 저장 제어부는 하나의 슬레이브에 여러 개의 연결을 수립하여 전송 병렬도를 높여 데이터 고속 전송 성능을 높이는 것을 특징으로 한다.

상기에서 데이터 검색 및 저장 제어부는 소비자 스레드에서 자신이 마지막으로 전송한 데이터의 끝을 별도로 기록하고, 추후 동일한 버퍼 유닛에서 데이터를 읽을 때 상기 기록된 위치에서부터 생산자가 삽입한 데이터를 읽어 데이터 유실을 방지하는 것을 특징으로 한다.

상기에서 데이터 검색 및 저장 제어부는 저장 데이터 검색을 위해, Leaf Node가 더블 링크로 구현한 Linked B+ Tree를 이용하여 저장 데이터를 검색하는 것을 특징으로 한다.

상기에서 데이터 검색 및 저장 제어부는 데이터의 삽입과 검색이 발생할 경우, 바이너리 서치를 이용하여 데이터가 삽입될 위치와 검색 위치를 탐색하며, 상기 데이터의 탐색 시 상기 바이너리 서치를 두번 수행하는 것을 특징으로 한다.

상기에서 데이터 저장부는 메모리 상의 데이터를 HDFS로 이동시킬 때, 해당 파일이 들어갈 파일 이름을 기초로 데이터들의 키값에 대응하는 인덱스 파일을 동시에 생성하는 것을 특징으로 한다.

상기에서 데이터 검색 및 저장 제어부는 미리 정의된 Indexed Column에 대하여 사용자가 요청한 질의문 조건에 부합하는 Index 값을 Map/Reduce를 이용하여 탐색한 후, 생성된 결과를 기초로 Input Formatter에서 RAW Data와 Querying Index 결과를 취합하여 Map/Reduce에게 필요한 Input Splits 들을 생성하는 방식으로 HDFS 검색을 수행하는 것을 특징으로 한다.

본 발명에 따르면 분산 Memory 저장과 HDFS를 동시에 Storage로 사용하는 Hybrid 저장 및 검색 시스템을 제공함으로써, 대량의 데이터 생성에 대응하여 실시간으로 데이터의 유실 없이 Memory에 저장하고 이를 실시간으로 동시 검색이 가능하도록 도모해주며, 일정 수준의 양만 Memory에 남겨두고 나머지 오래된 데이터는 HDFS에 구조화된 형태로 저장하여, 검색에 신속함을 도모해주는 장점이 있다.

도 1은 본 발명에 따른 빅 데이터의 실시간 저장 및 검색 시스템의 전체 구조도,
도 2는 도 1의 클러스터 구조도,
도 3은 데이터 흐름 구조로,
도 4는 통신 구조 예시도,
도 5는 SSH를 이용한 원격 실행 절차도,
도 6은 명령 처리 구조도,
도 7은 명령 처리 및 슬레이브 노드 관리 구조도,
도 8은 메모리 맵 관리 체계 예시도,
도 9는 BDI와 BCI의 슬레이브 직접 연결 구성도,
도 10은 주기적 전송 아키텍처,
도 11은 session multiplying과 로드 밸런싱 예시도,
도 12는 컨텍스트 스위칭에 의한 데이터 유실 예시도,
도 13은 데이터 유실 방지 예시도,
도 14는 세션 수에 따른 전송 속도 변화 결과도,
도 15는 일반적인 B Tree의 구조도,
도 16은 B Tree의 삽입 과정 예시도,
도 17은 B+ Tree의 예시도,
도 18은 B+ Tree의 삽입 과정 예시도,
도 19는 Linked B+ Tree 구조 예시도,
도 20은 예시 데이터,
도 21은 Linked B+ Tree에서 각각 인덱스되어 있는 트리가 링크(Link)되어 있는 예시도,
도 22는 Linked B+ Tree에 데이터 27을 삽입하는 과정 예시도,
도 23은 Linked B+ Tree에 데이터 20을 검색하는 과정 예시도,
도 24는 HDFS Data Set 예시도,
도 25는 원하는 데이터가 1번 파일 앞쪽에 몰려 있는 것을 가정한 HDFS Data Set 예시도,
도 26은 도 24 및 도 25의 HDFS Indexing 비교도,
도 27은 TeraStream Bass의 Building Indexing의 예시도,
도 28은 TeraStream Bass의 Full Searching 예시도,
도 29는 TeraStream Bass의 Indexing Searching 예시도,
도 30은 노드 수에 따른 전체 속도 관측표,
도 31은 노드 수에 따른 전체 속도 그래프,
도 32는 노드 수에 따른 노드별 속도 관측표,
도 33은 노드 수에 따른 전체 속도 그래프,
도 34는 삽입 성능 결과 예시도,
도 35는 검색 성능 결과도,
도 36은 Hadoop NameNode의 사양 예시도,
도 37은 Hadoop DataNode의 사양 예시도,
도 38은 샘플 데이터의 포맷도,
도 39는 Compare No Index와 Index Test 결과도,
도 40은 Compare No Index와 Index Test 데이터 예시도.

이하 본 발명의 바람직한 실시 예에 따른 빅 데이터의 실시간 저장 및 검색 시스템을 첨부된 도면을 참조하여 상세하게 설명한다.

본 발명에 따른 빅 데이터의 실시간 저장 및 검색 시스템은 전체적으로 실시간 데이터 수집을 위한 Memory Cluster와 Disk 저장 공간이 Hadoop Cluster로 이중 Cluster 구성을 가진다. 그리고 이 모든 Cluster를 Main Daemon이 통합 관리하는 구조이며, Main Daemon을 통해 Data Source로부터 데이터가 수집되고 Client를 통해 Web 혹은 UI로 분석 결과를 전송하는 구조이다.

도 1은 본 발명에 따른 빅 데이터의 실시간 저장 및 검색 시스템(이하, "TeraStream BASS"라 약칭함)의 구조로, 외부는 Client Library인 BCI와 Data Source Library인 BDI를 통해 데이터의 수집 및 검색이 이루어지는 구조이다. BASS Cluster와 HDFS Cluster는 논리적으로는 구분되어 있으나 물리적으로 동일 Cluster로 구성이 가능하며 데이터의 양에 따라 HDFS Cluster의 Node 수를 늘려서 별도의 Cluster로 구성할 수 있도록 설계되었다. 이러한 Architecture로 설계한 이유는 Memory에 저장할 데이터의 양과 HDFS에 저장할 양이 동일 Cluster로 구성하는 것이 불가능할 수 있기 때문에 별도 Cluster로 구성할 수 있도록 하는 것이 사용자의 요건에 더 유연하게 대응할 수 있기 때문이다.

도 2는 빅 데이터의 실시간 저장 및 검색 시스템에 적용된 클러스터 구조이다. 기본적으로 메모리에 데이터를 분산하여 저장하는 구조이기 때문에, 각 Node에 사용할 데이터를 미리 할당하고 여기에 데이터 수집부(10)의 BDI로부터 수집되는 데이터를 직접 Node에 저장하는 구조이다. 본 발명은 Hadoop과는 달리 Node Fail에 대비하여 데이터를 중복 저장하지 않으며, 한 건의 데이터는 오직 하나의 Node에 존재하게 된다. 본 발명은 자신이 사용할 Memory를 하나의 큰 Memory로 관리하지 않고 작은 Memory Block로 나누어 관리하는데, 그 이유는 Memory의 양이 한정되어 있기 때문에 메모리의 가용성을 유지하기 위해서는 메모리의 데이터를 반드시 HDFS로 옮기는 작업이 필요하게 된다. 이때 메모리 전체를 하나로 관리할 경우 HDFS 저장이 필요한 Node 전체가 사용 불가능한 상태가 되기 때문이다. 이를 피하기 위해서 HDFS에 저장하는 단위를 Memory Block 단위로 처리하게 되며, HDFS에 저장하는 과정이 진행되더라도 Memory의 나머지 Memory Block은 데이터 저장이 계속 진행된다.

상기 데이터 검색 및 저장 제어부(40)의 관리에 따라 실시간으로 데이터를 수집하는 과정은 다음과 같다.

TeraStream BASS는 Data Soruce로부터 직접 데이터를 수집하거나 혹은 Agent를 통해 데이터를 수집하는 두 가지 방법을 모두 사용할 수 있는 형태이나, 다만 두 가지 경우 모두 BDI라는 TeraStream BASS Data Source API를 반드시 통해야만 한다. 즉 Data Source가 직접 BDI를 통해 데이터를 TeraStream BASS로 전송하거나 혹은 Agent를 개발하여 Agent가 데이터를 수집하고 수집된 데이터를 BDI를 통해 TeraStream BASS로 전송하는 방법을 이용하여 데이터가 TeraStream BASS로 전송되게 된다.

BDI를 통해 전송된 데이터는 데이터 저장부(30)의 Memory Cluster인 BASS Cluster(31)와 Hadoop의 HDFS Cluster(32)에 저장되는 과정을 거치게 된다. 기본적으로 수집된 데이터는 1차적으로 TeraStream BASS의 Memory Cluster(31)에 저장되는데, 데이터는 BASS Slave Node에서 할당받은 하나의 Memory에 전송하도록 되지만 전체 Cluster에서는 모든 Node에 하나의 Memory Block 하나를 할당받게 되므로 하나의 BDI에서 전송되는 데이터는 모든 Node에 분산되어 저장되며 하나의 Memory Block에는 하나의 Schema의 데이터만 저장되게 된다.

클라이언트(20)의 요청에 따른 데이터 검색 과정을 설명하면 다음과 같다.

데이터의 검색은 BCI(TeraStream BASS Client API)를 통해서 이루어지게 되며, 사용자가 Web이나 혹은 명령을 통해 BASS SQL을 이용하여 데이터 검색을 요청하면, 이는 우선 Master에서 구문 검사를 거친 후 모든 Slave Node로 전달된다. 전달된 SQL에 따라 우선 해당 Schema가 저장된 모든 Memory Block에 전달되며 각 Memory Block의 Index에서 해당 데이터 검색이 이루어진다.

그리고 요청된 데이터 검색이 HDFS 검색을 동반할 경우, Hadoop Cluster(HDFS Cluster)에 데이터 검색이 요청된다. 이 경우 데이터 검색을 위한 Map/Reduce Program이 자동으로 생성되며, Hadoop Cluster 전체 데이터를 기반으로 검색이 수행되며 결과를 BCI로 전달하게 된다.

이어, 검색한 결과 데이터의 전송을 위한 통신 구조를 살펴보면 다음과 같다.

다수의 실행 모듈이 네트워크로 연결되어 동작하는 구조에서는 단일한 서버-클라이언트 연결 모델을 사용하는 것이 안정성 및 유지보수 측면에서 중요하다. BASS 역시 이러한 모델을 이용하며, 이를 커넥터-어댑터(Connector-Adapter) 연결 모델이라 명명한다.

커넥터는 클라이언트 프로그램이 서버 프로그램으로 접속할 때 사용하는 객체로서, 로그인 요청, 명령 전송 및 응답 수신, 로그오프 통지에 대한 프로토콜을 구현하고 있다.

어댑터는 서버 프로그램이 클라이언트 프로그램으로부터의 접속을 받아들일 때 사용하는 객체로서, 로그인 승인, 명령 처리 및 응답 전송, 로그오프 처리에 대한 프로토콜을 구현하고 있다.

BASS의 각 피어(BDI, BCI, ADMIN, 마스터, 슬레이브)들은 기본적으로 커넥터와 어댑터를 각자의 역할에 적합하게끔 확장 구현하고 있다.

단일 연결에 대한 어댑터 모델이 있다고 하더라도 서버는 다수의 어댑터를 안전하고 효율적으로 관리하는 모델을 필요로 한다. 일반적으로 사용되는 연결 관리 모델에는 Select, Fork, Thread creation, Pre-forked connection pool, Thread based connection pool이 있다.

우선 Select 모델은 단일 프로세스의 단일 스레드가 입출력 다중화 시스템 콜을 이용하여 모든 연결을 처리하는 방법으로서, 각 연결이 병렬 처리되어야 하는(복잡한 논리적 처리나 대규모 패킷 교환이 빈번하므로) BASS와 같은 시스템에서는 적합하지 않다.

Fork 방식과 Thread-creation 방식은 새로운 연결이 발생하면 그에 대응하는 새로운 프로세스나 스레드를 생성하는 방법으로서, 그렇지 않아도 시스템 리소스 사용량이 많은 본 발명에서는 언제 자원 문제로 연결에 실패하게 될지 모르는 위험이 있다.

Pre-forked connection pool은 연결 처리를 위해 미리 지정된 수의 프로세스를 만들어두는 방식으로서, 연결 처리를 위해 고정된 자원을 미리 확보할 수 있고, 특정 연결에서 메모리 침범이나 잘못된 시그널 처리와 같은 문제가 발생하더라도 전체 데몬에 영향을 미치지 않는다는 장점이 있으나, 각 프로세스가 공통의 메모리 영역에 빈번하게 접근해야 하는 본 시스템의 특성으로 인해 공유메모리의 사용이 불가피하다. 공유메모리는 그 제어가 까다롭고, 일반적인 메모리 처리에 비해 그 속도가 다소 느리다는 문제점이 있다.

마지막으로 Thread based connection pool은 미리 지정된 수의 Thread를 만들어두는 방식으로서 연결 처리를 위해 고정된 자원을 미리 확보할 수 있다는 점은 Pre-forked 방식과 동일하지만 특정 연결에서 발생한 문제가 전체 데몬의 비정상 종료를 야기할 수 있다는 위험이 있다. 장점은 메모리 데이터의 빠르고 유연한 제어가 가능하다는 것이다. 한 프로세스 내의 스레드는 같은 메모리 영역을 사용한다.

BASS에서는 가장 마지막에 설명한 Thread based connection pool 방식을 채택하였는데, 이유는 바로 메모리 데이터의 빠르고 유연한 제어에 있다. BASS의 핵심 기능이 메모리 상에서의 데이터 처리라는 점을 생각했을 때, 이는 가장 우선시되어야 할 특징이다. 또한, Pre-forked 방식이 원론적으로는 보다 안정적이나, 실제 데몬 프로그램이라면 굳이 연결 관리가 아니더라도 어떤 형태로든 멀티 스레드 코드가 반드시 포함되기 때문에 그리 큰 의미가 없다.

개념적 아키텍처와 별개로, 통신 관점에서의 아키텍처를 도식으로 나타내면 도 4와 같은 형태가 된다.

BDI, BCI, ADMIN은 모두 클라이언트 프로그램으로서, 마스터와 슬레이브로 접속하기 위한 확장 커넥터를 이용하여 연결을 요청한다.

마스터 노드와 슬레이브 노드는 모두 서버 데몬으로서, Thread based connection pool을 가지고 있으며, 새로운 연결이 발생하면 Factory 패턴 기반의 Adapter Factory로부터 적합한 확장 어댑터를 생성하고 이를 연결 풀에 할당한 뒤 해당 스레드를 활성화 시킨다. 여기에서 특이한 점은 슬레이브 노드가 가지고 있는 커넥터의 존재이다. 서버 데몬임에도 커넥터를 가져야 하는 이유는 마스터의 관점에서는 슬레이브 역시 하나의 클라이언트이기 때문이다. 전술한 바와 같이 서버-클라이언트 연결 관계를 동일한 모델로 처리하기 위해 슬레이브 노드에 커넥터 객체를 포함하는 방식으로 구현하였다. ADMIN의 경우에는 직접 슬레이브에 접속하지 않는다. 통신 모델 자체의 이해를 용이하기 위해 BDI, BCI와 함께 도면에 표현하였다.

한편, 클러스터 구조의 시스템은 서로 다른 머신에 설치된 데몬을 일괄적으로 기동하고 종료할 수 있어야 한다. 일괄 종료의 경우에는 하나의 데몬이 사용자의 종료 명령을 받아들여 다른 데몬으로 전달하는 것이 가능하지만, 기동의 경우에는 그렇지 않다.

이를 해결하기 위해 BASS는 SSH를 이용하여 클러스터를 일괄적으로 기동한다. SSH 서비스는 모든 유닉스/리눅스 시스템에 기본적으로 탑재되어 있으며, Hadoop 프레임워크에서도 이용되고 있다.

도 5는 SSH를 이용하여 원격지의 데몬을 기동하는 절차를 설명한다. 사용자가 마스터 데몬을 기동하게 되면 마스터 노드는 XML 형태로 작성된 환경 정보를 메모리에 적재한다. 환경정보는 각 슬레이브 데몬의 위치를 비롯하여 슬레이브 데몬이 기동하는 데에 필요한 모든 정보들을 가지고 있다. 이 정보들을 SCP를 통해 원격지의 호스트 머신으로 복사한다. 그리고 SSH를 통해 기동 명령을 전송하게 되면 슬레이브 데몬이 실행된다. 슬레이브 데몬은 복사된 환경정보를 통해 초기화를 수행하고, 마스터 노드로 접속하게 된다. 이때 마스터는 미리 생성되어있는 연결 풀을 통해 슬레이브의 접속을 받아들이게 되고, 슬레이브 제어를 위한 슬레이브 맵에 해당 정보를 등록함으로써 기동 절차를 완료한다.

이를 위해서는 SSH 기본 포트인 22번 포트가 열려있어야 하며, 클러스터로 구성된 각 호스트 머신 사이에 RSA 키 교환이 미리 이루어져야 한다.

사용자 관점에서 소프트웨어를 사용한다는 것은 명령을 내리고 그 결과를 받아보는 행위이다. BASS가 사용자의 명령을 수행하는 단계는 다음과 같다.

마스터 노드가 명령을 수신 -> 마스터 노드가 슬레이브 노드로 명령을 전달 -> 마스터 노드와 슬레이브 노드가 기능을 수행 -> 슬레이브 노드가 마스터 노드로 결과를 전달 -> 마스터 노드가 결과를 취합 -> 마스터 노드가 결과를 전송하는 과정으로 이루어진다.

원격지에 산개해 있는 여러 데몬이 연계하여 하나의 기능을 수행하기 위해서는 기능 자체의 구현도 중요하지만, 데몬 사이에서 명령과 응답이 오가고, 결과를 취합하는 구조 또한 그에 못지않게 중요하다.

일괄 기동의 설명에서 언급했듯이, 마스터 노드는 슬레이브 맵이라는 객체를 통해 슬레이브 노드를 제어한다. 슬레이브 맵은 그 아래에 슬레이브 기술자(Descriptor) 객체의 집합을 가지고 있으며, 이 기술자들은 슬레이브 어댑터에 대한 참조를 가지고 직접 슬레이브 노드와 통신한다.

사용자, 즉 프런트-엔드 피어의 커넥터가 마스터 노드의 해당 어댑터로 명령을 전송하면, 어댑터는 슬레이브 맵에 동일한 명령을 브로드캐스트하도록 요청한다. 슬레이브 맵 내부의 브로드캐스터는 각 디스크립터를 통해 명령을 전송하고, 도착하는 응답을 취합하여 어댑터로 돌려준다. 이때 중요한 것은, 여러 어댑터가 독립적인 스레드로 동작하게 되므로 브로드캐스터 영역은 임계구간으로 보호되고 있다는 점이다.

마스터 노드는 명령 처리 외에 슬레이브 노드의 관리에도 슬레이브 맵을 이용한다. 슬레이브 맵의 관리 기능은 다음과 같다.

주기적인 하트비트 교환, 특정 슬레이브 노드의 기동, 종료, 제거, 새로운 슬레이브 노드의 추가를 포함한다.

하트비트 교환의 경우 슬레이브 맵 내부에 하트비트 교환만을 담당하는 독립적인 스레드를 두어, 이 스레드가 스스로 하트비트 명령을 슬레이브 노드에 전달하고, 그 응답을 받는 구조를 가지고 있다. 슬레이브 노드의 상태는 통신 연결 상태의 이상 유무와 메모리 블록 사용 불능과 같은 실제 유효성 상의 이상 유무 두 가지를 확인하도록 되어있다. 하트비트 센서는 슬레이브 노드의 응답을 해석하여 해당 디스크립터의 상태 정보를 업데이트한다.

슬레이브 노드의 종료는 ADMIN의 명령으로만 이루어지게 되는데, 상기 명령 처리과정에서 설명한 방식에 따라 이루어진다. 특정 슬레이브 노드를 종료하게 되면 해당 디스크립터의 상태는 연결 단절로 업데이트된다.

슬레이브 노드의 기동은 이미 디스크립터가 존재하되, 상태가 "연결 유실"인 슬레이브를 대상으로 사용되는 관리 기능이다. 실제 사용 환경에서는 의도적인 재기동이나, 슬레이브 데몬이 의도치 않게 비정상 종료한 경우에 해당한다. 기동 역시 ADMIN의 명령으로만 이루어지며, 그 처리 절차는 "일괄 기동"에서 설명한 내용과 동일하다.

추가와 제거의 경우에도 ADMIN 명령을 통해서만 가능하다. 슬레이브 노드를 추가하게 되면 슬레이브 맵은 새로운 디스크립터를 생성하여 리스트에 추가한 후, 추가된 디스크립터를 통해 자동으로 원격 기동을 수행한다. 슬레이브 노드를 제거하게 되면 대상 디스크립터를 통해 종료 명령을 수행한 후, 디스크립터 리스트에서 제거한다. 슬레이브 노드 관리 측면을 포함하여 도 6과 같은 명령 처리 구조를 다시 그려보면 도 7과 같은 형태가 된다.

상기 데이터 검색 및 저장 제어부(40)에서 데이터 저장부(30)의 메모리 관리 과정을 설명하면 다음과 같다.

메모리 블록은 메모리 맵이라는 객체에 의해 관리된다. 메모리 맵은 유휴 메모리 블록이 있다면 해당 블록을 내어주고, 없을 경우, 유휴 블록이 발생할 때까지 검색을 계속한다. 메모리 맵은 미리 배정되어 있는 메모리 블록의 참조를 요소(elememt)로 삼는 큐와 스택을 이용해서 메모리 블록들을 관리한다. 도 8은 메모리 맵이 메모리 블록을 어떻게 관리하는지를 설명한 그림이다.

기동 당시, 모든 메모리 블록은 Free Block Stack에 그 참조가 모두 등록된다. 메모리 맵은 이 스택을 검사하여, 메모리 블록을 배정한다. 이때 메모리 블록의 상태를 "BUSY"로 변경하고, Holding Count라 불리는 값을 1 증가시킨다. 그리고 메모리 블록이 가득 차거나, 데이터를 전송하던 세션이 종료되면 블록의 상태를 "FULL"로 변경하고, 해당 메모리 블록의 참조를 Full Block Queue에 등록한다.

Full Block Queue에 등록된 블록들은 다음의 두 단계로 이루어지는 보관(Archiving) 절차에 의해 관리된다.

Holding count의 값이 Threshold 값에 도달하였는지를 주기적으로 검사, Threshold에 도달하였을 경우, Lower limit에 도달할 때까지 Full Block Queue에 등록된 블록들을 Archiving 한다.

Threshold와 Lower limit 값은 전체 메모리 블록의 수에 대한 백분율로 표현되며, 검사 기준도 메모리 사용량이 아닌 사용되고 있는 메모리 블록의 수를 백분율로 환산한 값이다. Holding Count는 위에서 설명한 바와 같이 사용중인 메모리 블록과 사용이 완료된 메모리 블록의 수를 합한 값이 되므로, 사용중인 블록의 수가 많을 경우에는 Lower limit에 도달하지 못하고 Archiving이 끝날 수 있다. 이러한 구조를 택한 이유는, 현재 사용중인 메모리 블록들이 수신 병목에 대한 버퍼의 역할을 하게 되어, 완전히 가득 찬 블록의 수를 기준으로 삼았을 때보다 균일한 성능을 보일 수 있기 때문이다.

Archiving이 끝난 블록은 자신이 속한 스키마의 데이터 저장 컴포넌트 목록에서 제외되며, 메모리 맵의 Free Block Stack으로 되돌아가게 된다.

가득 찬 블록은 큐로 관리하고, 유휴 블록은 스택으로 관리하는 데에는 그 나름의 이유가 존재한다. 우선, 가득 찬 블록은 먼저 등록된 순서대로 보관에 들어가야 하기 때문에 큐 구조가 적합하다. 유휴 블록의 경우에는 다소 복잡한 이유에서 스택 구조가 채택되었다. 개발 초기, 메모리 블록을 처음 배정하고 인덱스 객체를 준비하는 데에 매우 많은 시간이 소요되었다. 따라서 한 번 사용되었던 메모리 블록을 곧장 다시 꺼내 쓰는 편이 인덱스 객체의 준비 시간을 확률적으로 줄일 수 있어 스택 구조를 채택했었다. 하지만, 현재에는 인덱스 객체의 개선으로 특별한 의미가 없는 구조가 되었다.

저장 구간이란 BDI가 데이터를 전송하고 슬레이브 노드가 메모리 블록에 데이터를 저장하기까지의 구간을 말한다. 이 절차는 다소 복잡하며, 나열하면 아래와 같다.

BDI가 마스터에 로그온 -> 마스터가 BDI에 슬레이브 접속 정보를 전달 -> BDI가 모든 슬레이브에 로그온 -> BDI가 데이터를 저장할 스키마를 지정 -> 슬레이브 노드가 메모리 블록을 할당하고 스키마를 바인딩 -> BDI가 데이터를 전송 -> 슬레이브 노드가 데이터를 메모리 블록에 복사 -> 슬레이브 노드가 데이터를 인덱싱 -> 메모리 블록이 가득 차면 새로운 메모리 블록을 할당하고 스키마를 바인딩 -> BDI가 전송 완료를 통보하는 절차로 이루어진다.

데이터 저장 절차는 BDI가 마스터로 접속하면서 시작된다. 데이터를 저장할 때, BDI는 모든 슬레이브 노드로 직접 접속하게 되는데, 이유는 단순하다. 마스터 노드가 BDI와 슬레이브 사이에서 데이터를 중계할 경우, 병목이 발생하기 때문이다. 후에 설명하겠지만, BCI가 데이터를 조회할 때에도 같은 이유로 동일한 구조를 가지게 된다. ADMIN은 데이터 통신이 없기 때문에 제외된다. 도 9는 BDI와 BCI의 슬레이브 직접 연결 구조를 나타낸다.

도 9에 도시한 것처럼, 접속이 완료되면 BDI는 자신이 전송하는 데이터가 어떠한 스키마에 저장되어야 하는지를 통보한다. 슬레이브는 해당 스키마의 존재 유무를 검사하여 BDI에 알려주고, 이때부터 본격적인 데이터 전송이 시작된다.

슬레이브 노드가 데이터를 수신했을 때 가장 먼저 하는 동작은, 현재 데이터를 기록 중인 메모리 블록이 존재하는지의 여부이다. 그렇지 않다면 메모리 맵에 메모리 블록 할당을 요청한다. 새로운 메모리 블록이 할당되면 내부적으로 인덱스 객체를 하나 생성하고, 해당 스키마의 데이터 포맷에 따라 메모리 블록에 삽입될 수 있는 최소 건수를 계산한다. 그리고 해당 스키마의 데이터 저장 컴포넌트 목록에 등록한다. 이러한 일련의 과정을 바인딩이라 한다. 메모리 블록이 가득 찼는 지의 여부는, 실제로 삽입된 데이터의 사이즈가 아닌 상기 최소 건수가 기준이 된다. 데이터 길이의 편차가 심한 경우 메모리 가용성 측면에서 다소 손실이 발생할 수 있지만, 이미 들어온 데이터의 반려 처리에 수반될 수 있는 안정성 훼손을 피할 수 있고, 인덱스 객체를 고정된 크기로 미리 생성할 수 있어 성능 측면에서 훨씬 더 큰 이득을 기대할 수 있다. 인덱스 객체는 그 구조가 매우 복잡하여, 데이터 저장 상황에 따라 유동적으로 생성할 경우 사용이 불가능한 수준의 심각한 성능 저하를 유발하게 된다.

바인딩이 완료된 이후에는 수신된 데이터의 메모리 복사와 인덱싱이 수행되고, 메모리 블록이 가득 차게 되면 메모리 블록의 할당부터 다시 반복하게 된다.

조회 구간이란 BCI가 쿼리를 전송하고, 검색된 데이터를 수신하는 구간을 말한다. 이 절차 역시 저장 구간과 마찬가지로 다소 복잡하게 이루지며, 순서대로 나열하면 아래와 같다.

BCI가 마스터에 로그온 -> 마스터가 BCI에 슬레이브 접속 정보를 전달 -> BCI가 모든 슬레이브 노드에 로그온 -> BCI가 마스터로 쿼리를 전송 -> 마스터 노드가 쿼리의 유효성을 검사 -> 마스터 노드가 스키마 정보를 BCI로 전송 -> BCI의 결과집합 객체 준비 -> BCI가 각 슬레이브 노드로 쿼리를 전송 -> 슬레이브 노드가 데이터를 검사 -> 슬레이브 노드가 데이터를 전송 -> 슬레이브 노드가 데이터의 끝을 통보하는 절차로 이루어진다.

BCI의 쿼리는 SQL의 select와 유사한 형태를 지니며, 그 기능상의 범위는 다음과 같다.

기본적으로 데이터베이스의 select 쿼리와 유사

select * from <schema_name> where <조건절>

select <col_name>, <col_name> … <col_name> from <scheama> where <조건절>

지원하는 조건 연산자: <, >, <=, =>, =, !=, between, and, or, 결합괄호.

스키마에 키로 지정된 컬럼에 대해서만 조건 지정 가능. 향후 키가 아닌 컬럼에 대해서도 full-scan 방식의 조건 지정을 지원할 수 있으나 지원 여부 미정, Join, group by, 집계 함수 등은 지원하지 않는다.

단일 스키마에 대한 복합조건만을 지원한다. 즉, from 절에는 하나의 스키마만이 위치할 수 있다.

일 단위나 월 단위 배치 같은 배치성 서비스의 경우 HDFS에 저장된 영역에서만 데이터를 가지고 올 수 있도록 지원한다.

실시간성이나 준 실시간성을 띠는 showing 위주의 서비스는 메모리에 저장된 영역에서만 데이터를 가지고 올 수 있도록 지원한다.

전송된 쿼리는 lex-yacc 기반의 쿼리 파서에 의해 분석되고, 분석 결과로 만들어진 Parse-Tree 객체를 이용하여 데이터 검색 및 전송이 이루어지며, 조회중인 스키마에 대해서도 저장이 동시에 가능하도록 동기화되어있다.

데이터 조회 시의 전송 속도는 데이터 저장 시의 전송 속도에 비해 매우 낮은데, 이는 BDI가 매우 복잡한 멀티스레딩 모델을 통해 전송 속도를 극대화한 반면, 슬레이브가 BCI로 데이터를 전송할 때에는 단일 스레드로 전송하기 때문이다. 여기에는 두 가지 이유가 있다. 첫째로, BCI를 이용하여 사용자가 데이터에 액세스할 때, 데이터베이스 API처럼 Fetch 구조를 이용하기 때문에 벌크 전송이 의미가 없기 때문이고, 둘째로, BCI 응용 프로그램에서 한 건의 데이터에 대해 얼마나 많은 작업을 할지 알 수 없기 때문에, 슬레이브 측에서 고속 전송을 위해 CPU 점유율을 마냥 높은 상태로 유지할 수는 없기 때문이다.

HDFS Archiving은 Memory Block의 가용성을 확보하기 위해 오래된 데이터부터 HDFS에 저장하여 Memory를 확보하는데 이러한 일련의 절차를 HDFS Archiving이라 한다. HDFS Archiving은 TeraStream BASS Main Daemon(데이터 검색 및 저장 제어부)의 설정에 의해 동작하는데 관련 설정 값은 아래와 같다.

BASS.SlaveNode.Archiving.Enablement

BASS.SlaveNode.Archiving.Interval

BASS.SlaveNode.Archiving.Threshold

BASS.SlaveNode.Archiving.LowerLimit

Enablement는 Archiving 여부를 결정하는 설정 값이다. 기본 값은 true이며 false로 설정할 경우 HDFS Archiving이 동작하지 않고 순수 Memory 분산 모드로 동작하게 된다.

Interval은 Memory Block의 상태를 점검하는 주기로 단위는 초이다. 예를 들어 3으로 설정할 경우 3초마다 가득 찬 Memory Block의 수를 체크하여 Archiving 절차를 시작할지 말지를 결정하게 된다.

Threshold는 Archiving이 동작을 시작하게 되는 Memory 점유율이며 단위는 %이디. 예를 들어 이를 80으로 설정할 경우 전체 Memory Block 중 80%가 가득 찬 경우에 Archiving을 시작하게 된다.

Lower Limit는 Archiving을 멈추게 되는 Memory 점유율이며 단위는 %이다. 예를 들어 이를 50으로 설정할 경우 Archving이 시작되면 가득 찬 Memory Block의 수가 전체 Memory Block의 50%가 되면 Archiving을 멈추게 된다.

Archiving을 하는 방법은 Hadoop의 put method를 이용하여 수행되며 데이터와 함께 TeraStream BASS의 Index도 HDFS Searching에 맞게 변환하여 함께 저장한다. 수행은 TeraStream BASS의 Slave Node마다 하나의 put이 동작하게 된다. 즉 TeraStream BASS의 전체 Slave Node가 10개 이일 경우 최대 10개의 Archiving이 수행될 수 있으며 저장되는 데이터의 속도가 이보다 빠를 경우 데이터 수집에 지연이 발생할 수 있기 때문에 최대 HDFS 저장속도와 데이터 수집 속도에 따라 위의 설정 값 및 Slave Node의 수를 결정해야 한다.

HDFS의 Archiving 위치는 현재 정해져 있으며 Root Directory의 /bass를 사용한다. 해당 Directory가 없을 경우 최초 Archiving이 발생할 때 필요한 Directory를 자동으로 생성하도록 되어있다. TeraStream BASS는 데이터의 저장단위인 Schema별로 Archiving을 수행하며 Archiving 위치 역시 Schema별로 별도로 정해지며 HDFS상의 Path별 저장되는 내용은 아래와 같다.

/bass/[schema_name]/data : 실제 데이터

/bass/[schema_name]/index : Index 데이터

/bass/[schema_name]/tmp : 임시 공간

/bass/[schema_name]/tmp/select_[select_ID] : select 결과

다음으로, HDFS Searching은 사용자가 TeraStream BASS Client를 통해 데이터 조회를 요청했을 때 결과가 HDFS에 저장된 데이터가 포함되어야 할 경우에 Memory Searching이 완료된 다음에 HDFS의 데이터를 검색하는 것을 말한다.

HDFS Searching은 SQL 중 Select 문에서만 동작하며 SQL에 "ON DISK", "ON DUAL"이 포함되어야만 HDFS Searching이 동작하게 된다. HDFS Searching은 기본적으로 Hadoop의 MAP/REDUCE를 이용하는 방식으로 HDFS Searching이 발생할 경우 Hadoop MAP/REDUCE Job을 생성하게 되기 때문에 java source code 생성 및 compile이 동반되게 된다. 이 작업은 Slave Node에서 진행되며 Slave Node 중 하나의 Node에서 진행되게 된다.

HDFS Searching이 요청되었을 때 데이터의 생성 및 이동 절차는 아래와 같다.

① /bass/[schema_name]/index에서 검색 조건에 맞는 index 데이터를 선별하여 /bass/[schema_name]/tmp/index_[select_ID]에 생성

② 생성된 임시 index를 이용하여 /bass/[schema_name]/data에서 결과에 select 결과에 해당하는 파일만 검색하여 최종 결과를 /bass/[schema_name]/tmp/ select_[select_ID]에 저장

③ 저장된 최종 결과를 사용자에게 전송한다.

BASS에서의 대량 데이터 고속 전송 기술은 다음과 같은 특별한 생산자-소비자 모델에 대한 해결책이다.

생산자는 소량의 데이터를 무한히 생성, 소비자는 데이터를 TCP/IP로 전송, 목표 성능은 10Gbits/s 이상, 데이터 한 건의 크기가 작으므로 버퍼링이 필수, 데이터의 끝을 알 수 없으므로, 생산자 측 병목 발생 시 소비자는 버퍼가 가득 차지 않은 상태에서도 전송할 수 있어야 한다.

이러한 문제를 해결하기 위해 적용된 세부적인 기법들에 대해 설명한다.

사실상 다른 모든 요건은 간단한 버퍼링 및 멀티스레딩 기법으로 해결할 수 있으나, 중요한 것은 마지막 요건이다. 데이터의 끝을 알 수 있다면, 버퍼가 가득 찰 때까지 버퍼링했다가 전송하고, 마지막 데이터는 그냥 전송하면 간단하다. 하지만, 데이터가 무한이 생성되는 상황에서는, 데이터가 들어오지 않는 상태가 데이터의 끝을 의미하는지, 생산자의 일시적 병목을 의미하는지 소비자로서는 알 수가 없다. 이러한 문제를 해결하기 위해 BASS에서는 도 10과 같은 주기적 전송 아키텍처를 적용하였다.

일반적으로 비즈니스 데이터는 한 건당 크기가 그리 크지 않다. 이러한 데이터를 한 건씩 전송할 경우, 전송 시스템 콜에 소요되는 시간이 엄청나게 늘어난다. 따라서 버퍼에 데이터를 쌓고, 일정 용량에 도달했을 때에 전송하는 버퍼링이 필수적이다. 하지만, 상기한 바와 같이, 데이터의 끝을 알 수 없는 상황에서라면 버퍼가 끝까지 채워지지 않았을 경우에도 소비자 측에서는 이를 전송해야 할 필요가 있다. 이러한 문제를, 생산자 측은 일반적인 인터페이스 호출로 데이터를 버퍼링하는 구조로 구현하고, 소비자 측은 주기적으로 버퍼를 검사하여 데이터가 있을 경우 벌크로 전송하는 구조로 구현함으로써 해결하였다. 주기적 처리에 따른 실시간성 훼손을 최소화하기 위해 전송 주기는 100ms (1/10초)로 두었다. 또한, 하나의 버퍼가 전송 중일 때에도 생산자는 다른 버퍼에 데이터를 삽입할 수 있도록 버퍼 내부를 작은 유닛으로 나누어 관리한다. 버퍼링 기법을 사용하여 전송 시스템 콜 횟수는 감소시키되, 버퍼가 가득 차지 않아도 데이터 전송은 계속되어야 한다는 조건을 만족하는 구조이다.

본 발명의 다른 특징으로서 Session Multiplying을 통해 성능 향상을 도모하였다. 목표 성능을 달성하기 위한 방법으로, 하나의 슬레이브에 대해 여러 개의 연결을 수립하여 전송 병렬도를 높이는 방법이다. 슬레이브에서는 각 연결을 독립된 스레드로 처리하며, 한 번 데이터를 벌크로 수신하면 메모리 복사와 인덱싱에 상당한 시간을 소요하게 된다. 이 시간에 다른 연결을 통해 데이터를 수신할 수 있게 되면 그만큼 병렬 처리에 따른 성능 향상을 얻을 수 있다. 현재는 하나의 슬레이브당 네 개의 연결을 열도록 고정되어 있다.

고속 전송 모듈에서 사용되는 로드 밸런싱 기법은 간단한 Round-Robin 방식을 택하고 있다.

주기적 전송 모듈은 내부적으로 슬레이브 커넥터에 대한 참조를 가지게 된다. 슬레이브 노드가 두 개라면, Session Multiplying에 의해 모두 여덟 개의 커넥터가 존재하게 된다. 주기적 전송 모듈은 깨어날 때마다 자신이 마지막으로 데이터를 전송시킨 커넥터의 다음 커넥터를 찾아, 버퍼의 데이터를 전송하게 된다. 이를 통해 모든 슬레이브 노드에 대한 모든 연결이 고르게 데이터를 송수신하게 된다.

도 10에서 알 수 있듯이, 전송 모듈의 임계 구간은 버퍼 영역이 된다. 이는 일반적인 생산자-소비자 모델에서도 동일하며, 버퍼 영역의 동기화 문제가 사실상 본 통신 모델의 핵심이라 할 수 있다. 여기에서는 일반적인 동기화 기법을 채택할 수가 없었는데 그 이유는 아래와 같다.

Mutex와 Condition-variable 기법은 데이터를 입력하는 루틴이 사용자의 호출에 의해 불시에 실행되고, 데이터 전송 스레드는 이 호출에 의해서만 동작을 해야 하는 구조이므로 Mutex를 사용할 경우 Condition-variable와의 조합이 필수이다. 하지만 실시간성의 훼손을 최소화해야 하는 본 프로젝트의 특성으로 인해 매우 빈번한 동기화 함수 호출이 불가피 하며, 동기화 함수의 실행에 소요되는 시간은 상상을 초월한다. 본 통신모듈과 같은 형태의 프로그램에서는 결코 채택할 수 없는 대안이다.

원자 연산 기반의 다양한 Lock-less 알고리즘은 전통적인 동기화 방법론의 단점인 context-switching 비용을 획기적으로 줄이는 방법론이기는 하지만, atomic-write가 빈번할 경우 같은 lock을 바라보는 전체 프로세서의 캐시 라인이 계속 무효화 되어 오히려 성능 저하의 요인이 된다. 또한, 본 통신모듈과 같은 형태의 프로그램에서는 실행시간의 거의 대부분 동안 CPU 점유율이 100%인 상태로 머무른다.

Sleep-Signal 방식은 전혀 성능이 나오지 않았다.

따라서 루프 내에서 volatile 변수로 선언된 플래그를 검사하는 방법밖에 남지 않게 된다. volatile 키워드는 해당 변수를 언제나 CPU 캐시가 아닌 메모리 영역에서 바로 읽고 쓰겠다는 의미로서, 컴파일러 및 CPU의 코드 최적화에 의해 개발자의 의도와 다른 값이 참조되는 것을 방지한다.

Lock-less 알고리즘과 마찬가지로 CPU 점유율에 대한 문제가 있지만, 캐시 일관성으로부터 자유롭다는 면과 구현이 용이하다는 면이 있다. 또한, Lock 변수가 라이브러리 내에 은닉되어 있으므로 다른 Context에 의한 간섭으로부터도 자유롭다. 이미 이와 유사한 방식의 동기화 기법이 TeraSort에서 사용된 바가 있다.

각 버퍼 유닛은 읽기가 가능한지의 여부를 나타내는 읽기 가능 플래그와 쓰기가 가능한지를 나타내는 쓰기 가능 플래그를 가지며, 프로그램이 실행되는 시점의 상태는 읽기와 쓰기가 모두 가능한 상태이다.

데이터가 발생하게 되면, 생산자는 쓰기 가능한 버퍼 유닛이 있는지를 검사하고, 해당 버퍼 유닛을 읽기 불가능한 상태로 전환한다. 이후 데이터를 버퍼에 복사하고, 데이터의 끝을 기록하는 정수형 변수의 값을 변경한다. 마지막으로 버퍼 유닛의 상태를 읽기 가능한 상태로 변경하고, 버퍼 유닛이 가득 찼다면 읽기 불가능 상태로 변경한다.

소비자는 100ms 동안 잠들어 있다가 깨어나는 것으로부터 시작한다. 생산자와 마찬가지로 읽기 가능한 버퍼 유닛이 있는지를 검사하고, 해당 버퍼 유닛을 쓰기 불가능한 상태로 전환한다. 이후 저장된 데이터가 있다면 크기만큼의 데이터를 전송하고, 해당 버퍼 유닛을 쓰기 가능한 상태로 전환한다.

이러한 알고리즘에는 한 가지 문제점이 있는데, 하나의 변수를 검사하고 다른 변수의 값을 변경시키는 루틴이 임계구간으로 보호받을 수 없다는 점이다. 소비자 스레드가 읽기 가능 플래그를 검사하고 쓰기 가능 플래그를 변경시키려 하는 사이에 컨텍스트 스위칭이 발생하게 되면, 생산자는 데이터를 밀어 넣고, 소비자는 이전에 기록된 데이터 크기만큼만 전송하게 되어, 도 12와 같이 데이터의 일부가 버려지는 경우가 생길 수 있다. 극한의 부하 상황에서 매우 드문 확률로 발생하는 문제이기 때문에, 충분히 느린 속도를 가지는 일반적인 데이터 송수신의 경우에는 실제로 이러한 현상이 발생하지 않는다. 그러나 본 통신모듈은 당초부터 극한 상황을 상정하고 있기 때문에 반드시 해결되어야 하는 문제이다.

이러한 상황을 방지하기 위해 한가지의 장치를 더 마련하였다. 바로 도 13에 도시한 바와 같이, 소비자 스레드에서 자신이 마지막으로 전송한 데이터의 끝을 별도로 기록하도록 한 것이다. 그리하여, 다음번에 같은 버퍼 유닛에서 데이터를 읽은 때에는, 이때 기록된 위치에서부터 생산자가 삽입한 데이터까지를 읽게 되어 데이터 유실을 피할 수 있다.

통신 모듈만의 순수한 전송 성능을 테스트한 결과이다. 테스트는 아래와 같은 환경에서 수행하였으며, 그 결과는 도 14와 같다.

호스트 머신으로서 하이퍼 스레드 8코어(32 스레드)를 사용하였으며, 네트워크 대역의 제약을 피하기 위해 송신 측과 수신 측을 모두 하나의 호스트에서 실행하였고, 105바이트의 데이터를 총 10억 회 전송하였다.

단일 세션만으로도 이미 목표 성능에 근사한 9Gbits/s의 속도를 달성하게 되며, 4개 세션만으로도 최대 속도인 19Gbtis/s에 도달하고 있다. 이는 통신 모듈이 병목 구간이 되지 않으며, 실제 네트워크 환경에서는 데이터 처리 로직이 소요하는 시간을 일정부분 벌충해줄 수 있다는 의미가 된다.

TeraStream BASS의 데이터 Index 기술은 B+ Tree를 여기에 적합한 형태로 변형시킨 Linked B+ Tree이다. 먼저, 기존의 B Tree 계열의 Index 방법을 소개하고 이와 비교하여 Linked B+ Tree의 기술을 소개한다.

도 15는 가장 기본적인 형태의 B Tree 이다.

일정 수의 Element가 Node를 구성하고 그렇게 구성된 Node는 B Tree의 재분배 알고리즘을 통하여 Link가 되어 B Tree가 생성된다.

도 16은 B Tree에 데이터가 삽입이 되면 내부에서 어떤 동작이 진행되는지 보여주고 있다.

B Tree에서 각 Node에서 허용할 수 있는 최대 Element의 수는 Degree로 정의하고 있으며, 이 Degree는 Tree를 생성하기 전에 정해놓는다. 각 Node의 Element들은 항상 오름차순으로 유지되어 있고, 삽입하는 과정에서 Node의 Element의 수가 최대가 되면 재분배가 일어난다. 따라서 B Tree의 각 Node의 Element의 최대 수는 Degree - 1을 넘을 수 없다.

이러한 과정이 일어나기 때문에 BST 계열의 Index 보다 삽입 성능은 조금 떨어지지만 어떠한 경우에도 균형된 Tree가 보장이 되기 때문에 특정한 데이터의 집합에도 성능의 편차가 없다.

B Tree와 비슷하지만 B+ Tree는 도 17에 도시한 바와 같이, Tree의 최하위 Depth의 Node를 Leaf Node라고 정의하여 실제로 검색을 위한 Node, 그 나머지 Node를 Inner Node라고 정의하여 순수하게 데이터 Index만을 위한 Node로 나뉘어 동작하고 있다.

도 18은 B+ Tree에 데이터가 삽입이 되면 내부에서 어떤 동작이 진행되는지 보여주고 있다.

기본적으로 B Tree의 삽입 동작 방식과 비슷하다. 차이점은 데이터가 삽입 되어 재분배가 필요하다고 판단되면 Leaf Node에 존재하는 재분배 대상이 되는 데이터가 Inner Node에 복제가 된다. 그리고 각 Leaf Node는 서로 순차적으로 Single Link가 된다. 따라서 B Tree에 비교하여 복제되는 데이터 공간만큼 메모리의 낭비는 있지만 순차적으로 Single Link가 되어 있는 Leaf Node로 인하여 검색 성능이 훨씬 뛰어나다.

B+ Tree가 B Tree에 비하여 메모리 낭비는 있지만 TeraStream BASS가 분산처리시스템이라는 것을 감안하면 무시할 수 있는 수준이다. 또한, 메모리 저장 성능만큼 실시간 검색 성능 또한 중요하기 때문에 B+ Tree를 이용하여 TeraStream BASS에 최적화된 Linked B+ Tree 기술을 개발하였다.

도 19는 Linked B+ Tree의 기본 형태이다.

B+ Tree의 Leaf Node가 순차적으로 Single Link가 되어 있는 형태이면 Linked B+ Tree는 Double Link가 되어있다. 이는 TeraStream BASS의 검색엔진의 활용도를 위하여 추가된 기법이며 데이터를 저장할 때의 성능이나 메모리 사용의 영향을 주지 않는다. 이 기법으로 인하여 데이터의 오름차순/내림차순 검색 같은 기능을 손쉽게 구현할 수 있었다.

도 21은 데이터에서 필요한 Index 키가 2개 일 경우(도 20 참조), Linked B+ Tree의 구조를 보여주는 그림이다. TeraStream BASS는 데이터의 Index 키가 다수일 경우에도 실시간성을 유지하며 검색이 가능해야 한다.

각각의 키에 따라서 Index는 독립적으로 생성되지만 같은 레코드의 키들은 별도의 Link로 연결함으로써, 서로 다른 키로 복합조건으로 검색을 하였을 경우 Full Search가 아닌 Index를 이용하여 빠른 검색이 가능하다.

Linked B+ Tree에서는 데이터의 삽입과 검색이 발생할 경우 모두 Binary Search를 사용하게 된다.

B Tree 계열의 Index 특성이 그대로 포함되어 있기 때문에 Binary Search가 유리하다.

삽입할 경우에는 데이터가 삽입될 위치를 찾을 때, Binary Search를 이용한다. 도 22에서 확인할 수 있듯이 Linked B+ Tree는 각 Node 들이 Binary Search에 최적화되어있는 구조로 되어있고 Node의 Element들 또한, 이미 정렬이 되어 있는 상태이다. 따라서 Binary Search를 이용하여 데이터가 삽입될 위치를 찾는 것이 가장 효율적이다.

도 23은 Linked B+ Tree에서 데이터 20을 찾는 과정을 나타낸 그림이다.

데이터의 검색도 삽입과 마찬가지로 Binary Search를 이용한다. 차이점이라고 하면 데이터의 검색에서는 Binary Search가 두 번 사용 된다. 삽입에서는 삽입될 위치의 Node를 찾아내면 해당 Node에서는 Node 내부에 저장되어야 할 Position 정보가 있으므로 즉시 삽입이 가능하다. 하지만, 검색에서는 해당 데이터가 속해 있을 Node를 Binary Search로 찾은 다음 해당 Node에서 실제 데이터를 찾기 위해 Binary Search를 한 번 더 수행한다. 두 번의 Binary Search를 수행한다고 해도 Linked B+ Tree 특성상 모든 Node와 각 Node의 Element 들이 정렬이 되어 있는 상태이기 때문에 메모리의 수천만의 데이터를 검색하는 데 1초도 걸리지 않는다.

HDFS에 대한 설명을 하기 전에 우선 먼저 Hadoop HDFS와 Map/Reduce에 대하여 조금 더 깊게 이야기해 볼 필요가 있다. 일반적인 File 기반 Searching을 위한 Indexing 기법은 File의 Offset을 미리 지정해 놓아 검색 시 모든 파일에 대하여 검색을 하지 않고 필요한 부분만 검색을 할 수 있도록 하는데 아이디어를 두고 있다. 이에 대하여 Index 정보를 담고 있는 파일 또는 메모리 상의 데이터가 존재하게 된다. 하지만, HDFS 상에서 Map/Reduce를 이용한 검색 속도를 높이길 위한 목적의 Indexing 기법은 이와는 조금 더 다른 방법으로 접근해야 한다.

검색을 위한 Map/Reduce 작업에서는 Map Tasks 만을 주로 쓰게 된다. 이때 Resource Manager는 몇 개의 Map Tasks가 필요할지 Input Data Set의 크기에 따라 미리 계산을 하게 된다. 이 숫자는 Map Tasks에서 처리하는 Data Set의 사이즈에 따라 변동되게 된다. HDFS 상의 파일은 실제로는 여러 개의 InputSplit으로 나누어 지게 되고, 이 InputSplit 들이 Mapper Instance에 직접적으로 연관이 되게 된다.

따라서 Mapper의 개수는 InputSplit의 개수와 직접적인 연관이 있다. 궁극적으로는 검색에 필요한 Mapper의 개수가 줄어들게 되면 전체적인 속도 향상이 이루어질 수 있다. InputSplit은 다음과 같은 3가지의 다른 값을 가지고 있게 된다.

1) The File Name, 2) The offset(InputSplit의 시작 지점), 3) The Length (InputSplit의 종료 지점).

InputSplit의 Method인 toString()을 호출하면 다음과 같은 패턴의 데이터를 반환하게 된다.

dfs://server.domain:8020/path/to/my/file:0+100000

HDFS상의 Indexing은 3가지 단계로 구현할 수 있다(File level, InputSplit Level, Block Level). 도 24는 HDFS 상의 데이터 구조를 나타낸 그림이다.

위의 그림은 2개의 서로 다른 파일이 25개의 blocks 들로 구성되며, 7개의 다른 InputSplits으로 구분되어 사용자가 찾고자 하는 데이터가 음영 부분에 위치 한 예시이다. 위의 예시는 앞서 제안한 3가지 다른 Indexing 기법에서 다음과 같은 효과를 가질 수 있다.

File Base Indexing은 Full Scanning과 같은 효과를 가진다. InputSplit Base Indexing은 7개 중에서 4개만 읽음으로 약 75%의 성능 향상을 기대할 수 있다. Block Base Indexing은 25개의 블록 중에서 7개만 읽음으로 약 6배의 성능 향상을 기대할 수 있다

도 25는 비슷한 케이스로 원하는 데이터가 1번 파일 앞쪽으로 몰려 있다는 가정을 한 케이스이다. 위의 예시에서는 다음과 같은 효과를 기대할 수 있다.

File Base Indexing은 4개의 파일 중에서 1개의 파일만 읽음으로, 약 4배의 성능 향상을 기대할 수 있다. InputSplit Base Indexing은 7개 중에서 1개만 읽음으로써, 약 7배의 성능 향상을 기대할 수 있다. Block Base Indexing은 25개의 블록 중에서 4개만 읽음으로 약 7배의 성능 향상을 기대할 수 있다.

이 계산법은 한 가지 큰 사실을 간과하고 있다. 바로 Indexing 파일을 만드는 시간이다. 특히 TeraStream Bass에서는 실시간으로 데이터 검색이 이루어져야 하기 때문에 매 번 검색마다 Index를 Rebuild 해야 한다는 조건이 붙는다.

Index를 Map/Reduce에 적용하는 방법은 총 3가지 단계로 Building Index, Querying Index, Execute Map/Reduce를 거치게 된다. 상세 구현 방안에 대해서는 이후 사용된 기술 및 알고리즘 섹션에서 다루게 되며 본문에서는 앞서 제시한 3가지 Indexing 방법의 비교 중심으로 설명한다.

우선 각 단계들에 대한 상세 설명은 다음과 같다.

① Build Index 단계에서는 Index 데이터와 File 명 또는 Input Split 또는 Block을 연결하는 과정이다. 이 단계에서 출력되는 결과 값은 다음과 같다. 예를 들어 123, 234, 456, 567이라는 데이터가 특정 경로 밑의 파일에 특정 위치에 있다는 표현은 다음과 같이 하게 된다.

123 dfs://domain:8020/path/to/my/file:0+6

234 dfs://domain:8020/path/to/my/file:7+13

456 dfs://domain:8020/path/to/my/file:14+20

567 dfs://domain:8020/path/to/my/file:21+27

② Querying Index 단계에서는 Build Index 단계의 출력 값 중 사용자가 입력한 Query에 맞는 값을 추출해내는 방법이다. 위의 예시에서 123과 456만 추출해낸다면 다음과 같은 결과를 가지게 된다.

123 dfs://domain:8020/path/to/my/file:0+6

456 dfs://domain:8020/path/to/my/file:14+20

③ 상기 결과를 바탕으로 Execute Map/Reduce 단계에서는 입력받은 Data Set 중에서 Index에 해당하는 데이터만 새로운 Data Set으로 가지고 작업을 실행하게 된다. 이 과정에서 모든 데이터 대신에 일부 데이터만으로 작업을 함으로 실행되는 Mapper의 개수가 줄어들게 되어 성능 향상을 기대할 수 있게 된다.

각각의 단계들에 각 Indexing 방법의 장단점들은 다음과 같다.

File Base Indexing은 Building Index 단계가 단순하게 된다. File 명으로 Index를 빌드하는 과정은 Hadoop에 넣기 전부터 Index를 생성하는 게 가능하다. 따라서 실시간으로 Index를 생성하기엔 File Base Indexing이 가장 적합하다 할 수 있겠다.

InputSplit Base Indexing은 Build Index 단계에서 우선 HDFS에 데이터를 넣은 다음에 Index를 Build 할 수 있다. 이는 File을 외부에서 추가할 시 Hadoop의 상위 레이어에서는 내부적으로 Input Split이 어떻게 이루어지는지를 알 수 없기 때문이다. 따라서 Build Index 단계에서부터 Map/Reduce를 한번 돌려야 하는 단점이 있다. 물론 Build Index 단계 이후부터는 File Indexing 보다 더욱 효율적이게 된다.

Block Base Indexing 전체적인 방법은 InputSplit Base Indexing과 비슷하게 동작 하나 Build Index 단계가 더욱 복잡하게 된다. 이로 인해 전체적인 성능 향상은 예외적인 케이스 이외에는 기대하기 어렵다.

TeraStream Bass에서는 상기 3가지 Indexing 방법 중 File Indexing을 사용한다. 이는 Memory 상의 데이터를 HDFS로 내리는 과정에서 Build Index를 하기 때문이다. 따라서 첫 번째 단계를 건너뛸 수 있는 이점 때문에 전체적인 성능 향상이 가장 효율적이라는 판단하에 File Indexing 기법을 적용하게 되었다.

도 27은 TeraStream Bass에서 Memory 상의 데이터를 HDFS로 옮길 때의 상황을 설명하고 있다. Data를 내릴 때 TeraStream Bass는 해당 파일이 들어갈 File name을 알 수 있음으로 데이터들의 Key 값에 대응하는 Index 파일을 같이 생성을 한다. 이 과정으로 인하여 Data를 생성할 때 동시에 Index를 Building 할 수 있는 장점으로 인해 Build Indexing 과정에 대한 Advantage를 가질 수 있다.

TeraStream Bass에서 생성된 Index 는 다음과 같은 형태를 지니게 된다.

123 dfs://domain:8020/path/to/my/file:1

234 dfs://domain:8020/path/to/my/file:2

456 dfs://domain:8020/path/to/my/file:3

567 dfs://domain:8020/path/to/my/file:4

이 데이터들을 입력으로 하여 사용자가 입력한 Query에 부합하는 Input Data 가 속해 있는 Index 정보만을 정재하는 Map/Reduce 작업을 실행하게 된다.

사용자가 키 값이 500보다는 작고 100보다는 큰 파일을 원한다면 이 정보를 바탕으로 다음과 같은 출력을 내보내게 된다.

234 dfs://domain:8020/path/to/my/file:2

456 dfs://domain:8020/path/to/my/file:3

이 출력 값은 다음 단계인 Execute Map/Reduce 에서 사용되게 된다.

Execute Map/Reduce 단계는 기존의 TeraStream for Hadoop의 Convert Engine 과 유사하게 작동한다. 그러나 Full Search 기반의 Convert Engine 과의 틀린 점을 설명하기 위해서는 Convert Engine과 Indexed HDFS Searching 방법을 비교할 필요가 있다.

도 28은 TeraStream For Hadoop의 Convert Engine으로 TeraStream Bass에서 Full Searching을 할 경우 사용되는 방법이다. 사용자가 질의한 문장에 대하여 Map/Reduce 쪽에서 걸러 내는 방법이다. 이 방법은 우선 모든 파일 내용을 Input Split으로 만든 후 Mapper에게 보내는 가장 기본적인 방법이다.

이에 반하여, 도 29의 경우는 사용자가 3번째 컬럼의 값 중 30000 ~ 39999 사이의 컬럼 값을 찾아내는 질의문에 대해 동작하는 방식이다. 이에 대한 전재 조건은 해당 컬럼이 Indexing되고 있다는 가정에서 출발한다. 실제로 TeraStream Bass에서 Scheme를 정의할 시 Index Column을 미리 정의하게 되어 있다. 정의된 Indexed Column에 대하여 사용자가 요청한 질의문 조건에 부합하는 Index 값을 Map/Reduce를 이용하여 찾아낸다. 이렇게 생성된 결과를 Input Formatter에게 보낸 후 Input Formatter는 RAW Data와 Querying Index 결과를 취합하여 Map/Reduce에게 필요한 Input Splits 들을 만든다. 이렇게 생성된 결과는 Full Searching보다 월등히 빠른 성능을 보이게 된다.

HDFS 저장을 배제한 상태에서, 하나의 슬레이브 노드에서 달성할 수 있는 최대 인-메모리 저장 속도와 전체 프레임 워크에서 노드 수를 증가시켰을 때에 달성할 수 있는 최대 인-메모리 저장 속도를 확인하고자 테스트를 수행하였다.

한 대의 서버상에서 전송 에뮬레이터, 마스터 노드, 슬레이브 노드를 모두 기동한다. 이와 같이 테스트를 하는 이유는 사내 서버 간의 네트워크가 1Gbits/s 망으로 구성되어 있기 때문에 이로 인한 제약을 없애기 위해 로컬 네트워크를 이용하려는 목적이다.

에뮬레이터는 다음과 같은 특징을 지니는 100만 건의 데이터를 무한 반복 전송한다.

Packet-flow 데이터, 12개의 전체 컬럼, 6개의 키 컬럼(키 중복 없음), 건 별 데이터 크기 118바이트, 슬레이브 노드는 모두 2~10개를 기동하며, 각 슬레이브는 10MB짜리 메모리 블록을 100개씩 생성하도록 하였다.

상기한 테스트 시나리오를 수행하면서 nmon 유틸리티를 이용하여 노드 수에 따른 로컬 네트워크 속도를 1분간 관측하였다.

관측 결과, 도 30에 도시한 바와 같이, 하나의 슬레이브 노드에서 기록한 최대 속도는 노드 수가 두 개일 때 약 0.74Gbits/s로서 초당 약 84만 건의 데이터를 처리하였으며, 전체 슬레이브 노드를 기준으로 보았을 때에는 노드 수가 열 개일 때 약 3.08Gbits/s로서 초당 약 351만건의 데이터를 처리하였다.

도 30 내지 도 33을 통해 보면, 노드 수가 적을수록 한 노드의 처리 속도가 높은 것을 확인할 수 있는데, 이는 Session Multiplying으로 인해 적은 노드 수로도 제한적인 시스템 자원을 효율적으로 사용할 수 있기 때문으로 분석된다. 하나의 호스트에 마스터, 슬레이브, 에뮬레이터를 모두 기동시킨 상황이기 때문에 이러한 현상이 더욱 두드러지게 나타났다.

또한, 노드의 수에 따른 속도 상승이 분명히 나타나고 있다. 노드 수가 늘어날수록 상승세가 둔화되는 경향을 확인할 수 있는데, 상기한 바와 같이 제한된 시스템 자원을 여러 프로세스가 나누어 써야 하기 때문에 나타나는 현상이다. 실제로 10Gbits/s 망을 구축하여 여러 호스트 머신에서 각 슬레이브 노드를 실행한다면 보다 큰 성능 향상 폭을 달성할 수 있을 것으로 기대된다.

본 테스트 결과만을 보면 현존하는 최대 네트워크 대역인 10Gbps의 속도를 달성하기 위해서는 약 14대의 머신이 요구된다. 하지만, 테스트 데이터(Packet-flow 유사 데이터)의 키 컬럼 수와 크기가 전체 데이터 대비 50%를 넘는다는 점을 생각했을 때, 데이터 특성에 따라 얼마든지 더 나은 성능을 보일 수 있다.

1개 Node에서 Indexing Module만 동작하는 상태에서 순수 Indexing 성능을 측정한다. 성능 측정 대상 데이터는 한 레코드의 크기가 128byte이고 해당 키의 크기가 16byte인 데이터를 천만 건씩 10회 반복하여 삽입, 천만 건씩 누적될 때마다 걸린 시간을 측정한다. 그리고 삽입이 끝난 후 1억 건의 데이터에 대하여 TeraStream BASS가 지원하는 다양한 검색 연산을 수행하며 성능을 측정한다.

도 34는 천만 건씩 10회 반복하여 삽입하여 1억 건의 데이터를 Indexing 하는 데 걸리는 시간을 측정한 결과이다. 도 34에서 보면 천만 건까지의 삽입하는데 걸린 시간은 4.19초이고 이후에 천만 건씩 누적 삽입을 하지만 시간의 차가 크지 않음을 알 수 있다. 이는 B Tree 계열의 Index 기법의 재분배 알고리즘이 Tree를 항상 균등하게 만들어 줌으로써 나타나는 결과이다. 따라서 초고속으로 수집되는 많은 데이터에 대해서 안정적으로 데이터 저장이 가능하며 이미 저장되어 있는 데이터의 양이 실시간으로 저장되는 데이터의 저장 성능에 미치는 영향이 크지 않음을 확인할 수 있다.

도 35는 도 34에서 삽입된 1억 건의 데이터에 대해서 각 연산의 수행 시간을 측정한 결과이다. 결과에서 알 수 있듯이 Linked B+ Tree의 메모리 검색 시간은 없다고 봐도 무관하다.

따라서 본 발명에서 제안된 Index & Search 기술은 초고속으로 수집된 데이터를 안정적으로 저장을 하면서 동시에 실시간으로 검색할 수 있음을 알 수 있다.

HDFS 검색 성능 측정에는 사내에서 운영하는 Hadoop 서버가 테스트 시스템으로 사용되었다.

테스트에 사용한 NameNode 장비 사양은 도 36과 같으며, DataNode 장비의 사양은 도 37과 같다. 15개 DataNode 들이 동일하게 사용되어 Hadoop이 설치되어 있다.

사용한 Hadoop Version은 Hadoop 2.3.0-cdh5.0.0이다.

정해진 구조의 데이터를 가진 가변형 SAM 파일을 HDFS 상에서 읽어서 이중 2번째 컬럼이 조건에 부합하는 데이터를 찾아내어 해당 Row를 출력하는 조건이다.

사용된 데이터는 가변형으로 총 11컬럼으로 이루어져 있다. 데이터의 샘플은 도 38과 같다.

TeraStream BASS에서는 고정형 데이터가 지원하기는 하나, 가변 데이터 처리만을 원칙으로 하기 때문에 가변형 데이터 Indexing 테스트만을 주로 하게 되었다.

HDFS Indexing Searching은 TeraStream BASS를 위해 만들어진 방법으로 Build Index 단계는 생략을 하여야 한다. 따라서 데이터에 맞는 Index를 미리 생성해 놓고 테스트가 진행되었다.

성능 비교는 약 5G, 10G, 15G, 20G, 25G에 대한 비교를 진행하였으며, 이중 각각 조건에 부합하는 Record가 2건, 4건, 6건, 8건, 10건을 가지고 있으며 이를 찾는 Hadoop Map/Reduce 작업을 진행하였다.

테스트 결과는 도 39 및 도 40과 같다. 5G와 10G에 대한 테스트결과 시간이 비슷한 이유는 테스트 장비의 사용 가능한 Mapper 개수가 144개 이기 때문에 거의 동시에 끝난다. 그러나 15G 이후부터는 시간이 Linear하게 늘어나는 것을 볼 수 있다. 또한, 전체적인 성능은 Index를 이용한 작업이 아닌 작업에 비해 속도가 현저히 빠른 것을 확인할 수 있다. 이는 Index가 미리 빌드되어 있는 환경에서는 처리 시간이 짧아진다는 것을 보여 준다.

이상 본 발명자에 의해서 이루어진 발명을 상기 실시 예에 따라 구체적으로 설명하였지만, 본 발명은 상기 실시 예에 한정되는 것은 아니고 그 요지를 이탈하지 않는 범위에서 여러 가지로 변경 가능한 것은 이 기술분야에서 통상의 지식을 가진 자에게 자명하다.

본 발명은 대용량 데이터를 실시간으로 저장 및 검색하는 기술에 적용된다.

10: 데이터 수집부
20: 클라이언트
30: 데이터 저장부
40: 데이터 검색 및 저장 제어부

Claims (24)

1. 빅 데이터를 실시간으로 저장 및 검색하기 위한 시스템으로서,
   Data Source 라이브러리인 BDI(TeraStream BASS Data Source API)를 통해 데이터의 수집하는 데이터 수집부;
   클라이언트 라이브러리인 BCI(TeraStream BASS Client API)를 통해 데이터를 검색하는 클라이언트;
   실시간으로 데이터 수집을 위한 메모리 클러스터(Memory Cluster)와 디스크(Disk) 저장 공간인 하둡 클러스터(Hadoop Cluster)로 이중화된 데이터 저장부;
   상기 데이터 저장부에 구성된 클러스터를 통합 관리하고, 상기 데이터 수집부의 데이터 수집을 관리하며, 상기 클라이언트의 검색 요청에 따라 검색 결과를 웹 또는 사용자 인터페이스(UI)로 전송하도록 관리하는 데이터 검색 및 저장 제어부를 포함하고,
   상기 데이터 저장부는 상기 BDI가 데이터를 전송하고 슬레이브 노드가 메모리 블록에 데이터를 저장하기까지의 구간인 저장 구간, 상기 BCI가 쿼리를 전송하고 검색된 데이터를 수신하는 조회 구간을 기초로 데이터 저장과 검색을 수행하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
   
2. 삭제
3. 청구항 1에서, 상기 데이터 검색 및 저장 제어부는 상기 데이터 저장부의 메모리 클러스터의 각 노드에 사용할 데이터를 미리 할당하고, 상기 BDI로부터 수집되는 데이터를 직접 상기 각 노드에 저장하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
   
4. 청구항 1에서, 상기 데이터 검색 및 저장 제어부는 사용할 전체 메모리를 복수의 소 메모리 블록으로 분할하고, HDFS에 저장하는 단위를 상기 분할한 소 메모리 블록 단위로 처리하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
   
5. 청구항 1에서, 상기 데이터 검색 및 저장 제어부는 하나의 BDI로부터 전송되는 데이터는 모든 노드에 분산저장하며, 하나의 메모리 블록에는 하나의 스키마(Schema)의 데이터만 저장하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
   
6. 청구항 1에서, 상기 데이터 검색 및 저장 제어부는 상기 BCI(TeraStream BASS Client API)를 통해서 BASS SQL을 이용하여 데이터 검색이 요청되면, Master에서 구문 검사를 거친 후 모든 Slave Node로 SQL을 전달하고, 전달된 SQL에 따라 해당 Schema가 저장된 모든 메모리 블록의 Index에서 해당 데이터 검색을 수행하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
   
7. 청구항 1에서, 상기 데이터 검색 및 저장 제어부는 요청된 데이터 검색이 HDFS 클러스터 검색을 동반할 경우, 데이터 검색을 위한 Map/Reduce 프로그램이 자동으로 생성되며, Hadoop Cluster 전체 데이터를 기반으로 검색을 수행하고, 수행 결과는 상기 BCI로 전달하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
   
8. 청구항 1에서, 상기 데이터 검색 및 저장 제어부와 클라이언트는 커넥터-어댑터(Connector-Adapter) 연결 모델을 사용하여 서버-클라이언트 연결을 수행하며, 상기 커넥터는 클라이언트 프로그램이 서버 프로그램으로 접속할 때 사용하는 객체로서, 로그인 요청, 명령 전송 및 응답 수신, 로그오프 통지에 대한 프로토콜을 포함하고, 상기 어댑터는 서버 프로그램이 클라이언트 프로그램으로부터의 접속을 받아들일 때 사용하는 객체로서, 로그인 승인, 명령 처리 및 응답 전송, 로그오프 처리에 대한 프로토콜을 포함하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
   
9. 청구항 1에서, 상기 데이터 검색 및 저장 제어부는 마스터 노드 호스트 머신과 슬레이브 노드 호스트 머신을 포함하고, 상기 마스터 노드 호스트 머신은 슬레이브 맵이라는 객체를 통해 슬레이브 노드를 제어하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
   
10. 청구항 9에서, 상기 슬레이브 맵은 하위에 슬레이브 기술자 객체의 집합을 포함하고, 상기 슬레이브 기술자는 슬레이브 어댑터에 대한 참조를 가지고 직접 슬레이브 노드와 통신하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
    
11. 청구항 9에서, 상기 마스터 노드 호스트 머신은 주기적인 하트비트 교환, 특정 슬레이브 노드의 기동/종료/제거, 새로운 슬레이브 노드의 추가를 관리하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
    
12. 청구항 1에서, 상기 데이터 저장부는 메모리 맵이라는 객체를 이용하여 메모리 블록을 관리하며, 상기 메모리 맵은 미리 배정되어 있는 메모리 블록의 참조를 요소로 삼는 큐와 스택을 이용하여 메모리 블록을 관리하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
    
13. 청구항 12에서, 상기 메모리 맵은 Free Block Stack에 그 참조가 모두 등록된 메모리 블록의 스택을 검사하여 메모리 블록을 배정하되, 상기 메모리 블록의 상태를 "BUSY"로 변경하고, Holding Count라 불리는 값을 1 증가시킨 후, 메모리 블록이 가득 차거나, 데이터를 전송하던 세션이 종료되면 블록의 상태를 "FULL"로 변경하고, 해당 메모리 블록의 참조를 Full Block Queue에 등록하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
    
14. 청구항 1에서, 상기 데이터 수집부의 BDI 및 클라이언트의 BCI는 모든 슬레이브 노드로 직접 접속하여 수집 데이터를 저장하거나, 저장된 데이터를 검색하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
    
15. 삭제
16. 청구항 1에서, 상기 데이터 저장부는 메모리의 가용성 확보를 위해, 오래된 데이터부터 HDFS에 저장하여 메모리를 확보하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
    
17. 청구항 1에서, 상기 데이터 검색 및 저장 제어부는 데이터 저장 및 검색을 위해 생산자-소비자 모델을 이용하며, 상기 생산자는 인터페이스 호출로 데이터를 버퍼링하는 구조를 이용하고, 상기 소비자는 주기적으로 버퍼를 검사하여 데이터가 존재할 경우 벌크로 전송하는 구조를 이용하며, 이를 이용한 주기적 전송 모델을 통해 대용량 데이터를 고속으로 전송하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
    
18. 청구항 17에서, 상기 주기적 전송 모델은 라운드-로빈(Round-Robin) 방식을 이용하여 로드 밸런싱을 구현하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
    
19. 청구항 1에서, 상기 데이터 검색 및 저장 제어부는 하나의 슬레이브에 여러 개의 연결을 수립하여 전송 병렬도를 높여 데이터 고속 전송 성능을 높이는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
    
20. 청구항 1에서, 상기 데이터 검색 및 저장 제어부는 소비자 스레드에서 자신이 마지막으로 전송한 데이터의 끝을 별도로 기록하고, 추후 동일한 버퍼 유닛에서 데이터를 읽을 때 상기 기록된 위치에서부터 생산자가 삽입한 데이터를 읽어 데이터 유실을 방지하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
    
21. 청구항 1에서, 상기 데이터 검색 및 저장 제어부는 저장 데이터 검색을 위해, Leaf Node가 더블 링크로 구현한 Linked B+ Tree를 이용하여 저장 데이터를 검색하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
    
22. 청구항 1에서, 상기 데이터 검색 및 저장 제어부는 데이터의 삽입과 검색이 발생할 경우, 바이너리 서치를 이용하여 데이터가 삽입될 위치와 검색 위치를 탐색하며, 상기 데이터의 탐색 시 상기 바이너리 서치를 두 번 수행하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
    
23. 청구항 1에서, 상기 데이터 저장부는 메모리 상의 데이터를 HDFS로 이동시킬 때, 해당 파일이 들어갈 파일 이름을 기초로 데이터들의 키 값에 대응하는 인덱스 파일을 동시에 생성하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
    
24. 청구항 1에서, 상기 데이터 검색 및 저장 제어부는 미리 정의된 Indexed Column에 대하여 사용자가 요청한 질의문 조건에 부합하는 Index 값을 Map/Reduce를 이용하여 탐색한 후, 생성된 결과를 기초로 Input Formatter에서 RAW Data와 Querying Index 결과를 취합하여 Map/Reduce에게 필요한 Input Splits 들을 생성하는 방식으로 HDFS 검색을 수행하는 것을 특징으로 하는 빅 데이터의 실시간 저장 및 검색 시스템.
    
    
    

Images