[빅데이터를 지탱하는 기술] 4. 빅데이터의 축적 - 비구조화 데이터의 분산 스토리지

목차

4. 빅데이터의 축적

 

4.4. 비구조화 데이터의 분산 스토리지

4.4.1. [기본 전략] NoSQL 데이터베이스에 의한 데이터 활용

4.4.2. 분산 KVS - 디스크로의 쓰기 성능을 높이기

① Amazon DynamoDB

② [기초지식] ACID 특성과 CAP 정리

4.4.3. 와이드 칼럼 스토어 - 구조화 데이터를 분석해서 저장하기

① Apache Cassandra

4.4.4. 도큐먼트 스토어 - 스키마리스 데이터 관리하기

① MongoDB

4.4.5. 검색 엔진 - 키워드 검색으로 데이터 검색

① Elasticsearch

② Splunk

 

---

4. 빅데이터의 축적

4.4. 비구조화 데이터의 분산 스토리지

NoSQL 데이터베이스를 활용하면 데이터를 단순히 모아서 저장할 뿐만 아니라 애플리케이션에서 온라인으로 이용하거나 실시간으로 집계할 수도 있다. 이 절에서는 NoSQL 데이터베이스의 몇 가지 특징을 설명한다.

4.4.1. [기본 전략] NoSQL 데이터베이스에 의한 데이터 활용

빅데이터를 위한 분산 스토리지에는 필요에 따라 얼마든지 확장할 수 있는 확장성과 데이터를 구조화하지 않고도 저장할 수 있는 유연성이 요구된다. 그중에서도 기본이 되는 객체 스토리지는 임의의 파일을 저장할 수 있다는 점이 장점이지만, 다른 한편으로는 단점도 많다.

먼저 객체 스토리지 상의 파일은 교체하기 어렵다. 일단 파일을 써넣으면 그것을 통째로 교체하는 방법밖에 없다. 로그 파일처럼 나중에 변경할 일이 없는 것은 그래도 상관없지만, 데이터베이스처럼 수시로 변경하는 용도로는 적합하지 않다. 쓰기 빈도가 높은 데이터는 별도 RDB에 저장하고 정기적으로 스냅샷을 하거나 다른 '분산 데이터베이스(distributed database)'에 저장하도록 한다. 

특히 중요한 데이터는 트랜잭션 처리에 대해 고려된 데이터베이스에 기록하는 것이 원칙이다. 스트리밍 형의 메시지 배송 등은 트랙잭션 처리가 이루어지지 않기 때문에 확실한 기록을 보증하는 것이 어렵다. 대부분 애플리케이션에서는 일반적인 RDB라도 충분한 쓰기 성능을 얻을 수 있겠지만, 그것이 불충분한 경우에는 분산 데이터베이스를 검토하는 것이 좋다.

다른 문제는 객체 스토리지에 저장된 데이터를 집계할 수 있게 되기까지는 시간이 걸린다는 것이다. 열 지향 스토리지를 만듦으로써 집계는 고속화되지만, 그 작성에는 아무래도 시간이 걸린다. 데이터를 기록하고 곧바로 활용하고자 하는 경우에는 실시간 집계와 검색에 적합한 데이터 저장소가 필요하다. 

특정 용도에 최적화된 데이터 저장소를 일컬어 'NoSQL 데이터베이스'라는 말이 자주 사용된다. 다음으로는 NoSQL 데이터베이스의 예로 '분산 KVS', '와이드 칼럼 스토어', '도큐먼트 스토어', 그리고 '검색 엔진'의 특징을 살펴보겠다.

 

4.4.2. 분산 KVS - 디스크로의 쓰기 성능을 높이기

분산 KVS(distributed Key-Value Store)'는 모든 데이터를 키값 쌍으로 저장하도록 설계된 데이터 저장소를 말한다. 객체 스토리지도 넓은 의미에서는 분산 KVS의 일종이지만, 여기에서는 좀 더 '작은 데이터'를 가정한다. 구체적으로는 몇 KB 정도의 데이터를 초당 수만 번 읽고 쓰는 경우다.

분산 KVS는 모든 데이터에 고유의 키를 지정하고 그것을 부하 분산을 위해 이용한다. 키가 정해지면 그 값을 클러스터 내의 어느 노드에 배치할 것인지 결정한다. 이 구조에 의해 노드 간에 부하를 균등하게 분산하고 노드를 증감하는 것만으로 클러스터의 성능을 변경할 수 있게 되어 있다(그림 4.17).

가장 간단한 경우에는 하나의 키에 하나의 값만 할당할 수 있다. 시스템에 따라서는 키에 여러 값을 할당하거나, 혹은 반대로 여러 키의 조합에 값을 할당할 수 있는 것도 있다. 분산 KVS는 구현이 다양하기 때문에 사용하는 시스템에 따라 크게 다르다.

 

 

① Amazon DynamoDB

여기에서 클라우드 서비스에 통합된 예로 아마존 웹 서비스(AWS)의 'Amazon DynamoDB'를 살펴보자. DynamoDB는 항상 안정된 읽기 쓰기 성능을 제공하도록 디자인된 분산형 NoSQL 데이터베이스로 하나 또는 두 개의 키에 연결하는 형태로 임의의 스키마리스 데이터를 저장할 수 있다. JSON과 같이 중첩된 데이터 구조도 취급할 수 있어 간단한 분산 KVS라기보다는 도큐먼트 스토어로 사용할 수 있다.

 DynamoDB는 P2P형의 분산 아키텍처를 갖고 있으며, 미리 설정한 초 단위의 요청 수에따라 노드가 증감되는 특징이 있다. 따라서, 데이터의 읽기 및 쓰기에 지연이 발생하면 곤란한 애플리케이션에 유용하다. 예를 들어, 사용자의 요청에 고유 ID를 붙여서 DynamoDB에 저장한다고 하자. 사용자가 늘어나서 기록하는 빈도가 증가했을 경우, 그에 따라 설정을 바꾸는 것만으로 성능이 향상되고 데이터베이스의 지연이 발생하지 않도록 운용할  수 있다.

DynamoDB의 데이터를 분석하려면, 동일하게 AWS 서비스인 Amazon EMR 및 Amazon Redshift 등과 결합함으로써 Hive에 의한 배치 처리를 실행하거나 데이터 웨어하우스에 데이터를 전송하도록 한다. DynamoDB 고유의 기능인 'DynamoDB Streams'를 사용하면 데이터 변경을 이벤트로 외부에 전송해 실시간 스트림 처리를 할 수 있다(그림 4.18).

DynamoDB에만 국한된 것이 아니라 일반적으로 NoSQL 데이터베이스는 애플리케이션에서 처음에 데이터를 기록하는 장소로 이용된다. NoSQL 데이터베이스 자체는 대량의 데이터를 집계하는 기능이 없는 것이 많아 데이터 분석을 위해서는 외부로 데이터를 추출해야 한다. 단, RDB 등과 비교하면 읽기 성능이 높기 때문에 쿼리 엔진에서 접속해도 성능상의 문제는 발생하기 어렵다. 따라서 애드 혹 분석 등에서는 데이터를 사전에 복사하지 않고 필요시에 직접 연결하여 사용할 수 있다.

 

② [기초지식] ACID 특성과 CAP 정리

NoSQL 데이터베이스를 이해하기 위해 'ACID 특성'과 'CAP 정리'에 대해 알아두는 것이 좋다.

ACID 특성은 트랜잭션 처리에 요구되는 4가지 성질을 말하는 것으로 다음과 같다.

• 원시성(atomicity)
• 일관성(consistency)
• 독립성(isolation)
• 내구성(durability)

일반적인 RDB는 이들을 충족하고 있어 신뢰성 있는 트랙잭션 처리를 실현하고 있다. 한편, ACID 특성을 만족하면서 분산 시스템을 구축하는 것은 어렵기 때문에 그 한계를 극복하기 위해 만들어진 것이 'CAP 정리'다. 일반적으로 분산 시스템에서는 다음의 세 가지를 동시에 충족시킬 수 없어 어느 하나가 희생될 수 있다.

• 일관성(consistency)
• 가용성(availability)
• 분단내성(partition-tolerance)

CAP 정리는 제한된 조건에서만 성립하며, 분산 시스템에서 트랜잭션 처리를 실행할 수 없다는 의미는 아니다. 그러나 실제 NoSQL 데이터베이스 중에는 성능상의 이유로 ACID 특성을 충족하지 않는 것도 있으므로 주의가 필요하다. 즉, RDB처럼 반드시 신뢰성 있는 트랜잭션 처리를 수행할 수 있다고는 할 수 없다.

결과 일관성

NoSQL 데이터베이스의 일부는 CAP 정리의 '일관성'이나 '가용성' 중 하나를 선택한다. 즉, 일관성을 우선하고 가용성을 포기하거나(단시간의 장애 발생을 수용), 반대로 가용성을 우선하고 일관성을 포기하는(오래된 데이터를 읽을 수 있는) 선택이다. 그중에서도 자주 볼 수 있는 것이 '결과 일관성(eventual consistency)'의 개념으로, '써넣은 데이터를 바로 읽을 수 있다고는 말할 수 없다'는 것이다.

결과적 일관성도 시간이 지나면 언젠가 최신 데이터를 읽을 수 있음을 보장할 수 있지만, 그것이 언제가 될지는 알 수 없다. 앞서 언급한 Amazon DynamoDB 등은 그 예로, 규정상의 동작으로는 결과 일관성이 보장되게 되어 있다.

결과 일관성은 Amazon S3에서도 도입되고 있으며, 기존 객체를 덮어쓰거나 삭제하거나 하는 경우에는 그 변경이 언제 반영되는지 보장되지 않아 지연이 발생할 가능성이 있다.

역사적인 배경으로 봤을 때, NoSQL 데이터베이스의 대부분은 RDB의 한계를 뛰어넘기 위해 개발되어 왔다. 그렇기 때문에 ACID 특성을 부분적으로 포기하거나 어떤 제약을 마련함으로써 높은 성능을 실현하고 있다. 따라서, NoSQL 데이터베이스의 사용에 있어 먼저 그 제약을 잘 이해해두지 않으면 예상치 못한 동작으로 인해 고생하게 된다.

 

4.4.3. 와이드 칼럼 스토어 - 구조화 데이터를 분석해서 저장하기

분산 KVS를 발전시켜 2개 이상의 임의의 키에 데이터를 저장할 수 있도록 한 것이 '와이드 칼럼 스토어(wide-column store)' 다. 'Google Cloud Bigtable'과 'Apache HBase', 그리고 뒤에서 언급할 'Apache Cassandra(아파치 카산드라)'등이 대표적이다.

와이드 칼럼 스토어에서는 내부적으로 행 키와 칼럼명의 조합에 대해 값을 저장한다. 테이블에 새로운 행을 추가하는 것과 마찬가지로 칼럼도 얼마든지 추가할 수 있는 구조로 되어 있으며, 수억의 칼럼을 만들 수도 있다. 즉, 하나의 테이블에 가로와 세로의 2차원(또는 그 이상의 다차원)에 데이터를 쓸 수 있도록 한 것이 와이드 칼럼 스토어의 특징이다(그림 4.19).

① Apache Cassandra

이제 오픈 소스의 와이드 칼럼 스토어인 'Apache Cassandra'를 살펴보자. Cassandra는 내부적인 데이터 저장소로 와이드 칼럼 스토어를 이용하면서도 'CQL'이라 불리는 높은 수준의 쿼리 언어가 구현되어 있어, 아래의 그림 4.20과 같이 SQL과 동일한 감각으로 테이블을 조작할 수 있다.

Cassandra에서는 먼저 테이블의 스키마를 결정할 필요가 있기 때문에 구조화 데이터만을 취급할 수 있다. 이것은 언뜻 보면 RDB와 비슷하지만, 쿼리의 의미는 SQL과는 많은 점에서 다르다. 예를 들면, INSERT INTO는 '추가 또는 갱신'(이른바 "upsert")으로 동작해 동일한 키를 가진 레코드가 존재하면 덮어쓴다. Cassandra는 P2P형의 분산 아키텍처를 갖고 있으며 지정한 키에 의해 결정한 노드에 해당 키와 관련된 모든 값을 저장한다. 사용자 ID를 키로 사용하는 경우 그 사용자에 대한 기록은 하나의 노드에 모이고 그 노드 안에서 쿼리가 실행된다. 따라서, 다수의 독립적인 키가 있는 경우에 처리를 잘 분산할 수 있다.

예를 들어, 전 세계에 1억 명의 활성 사용자가 있는 메시지 서비스가 있다고 하고, 각 사용자가 매일 수십 메시지를 기록한다고 가정해보자. 테이블에는 매일 수십억 레코드가 추가될 것이다. 이 경우, 사용자 ID를 키로 데이터를 분산하고, 메시지의 타임스탬프로 레코드를 분리함으로써 사용자별 타임 라인이 구축된다. CQL에서는 이러한 거대한 테이블을 '복합 키(compound key)'를 이용하여 실현한다.

와이드 칼럼 스토어도 데이터를 집계하는 데는 적합하지 않다. 집계를 위해서는 분산된 모든 노드에서 데이터를 모아야 하기 때문이다. Hive와 Presto, Spark 등의 쿼리 엔진은 모두 Cassandra로부터의 로드에 대응하고 있으며, 데이터를 분석하려면 그것들을 이용해 데이터를 추출해야 한다(그림 4.21).

 

4.4.4. 도큐먼트 스토어 - 스키마리스 데이터 관리하기

NoSQL 데이터베이스를 대표하는 또 하나의 형태가 '도큐먼트 스토어(document store)'다. 와이드 칼럼 스토어가 주로 '성능 향상'을 목표로 하는 반면, 도큐먼트 스토어에서는 주로 '데이터 처리의 유연성'을 목적으로 한다. 구체적으로는 JSON처럼 복잡하게 뒤얽힌 스키마리스 데이터를 그대로의 형태로 저장하고 쿼리를 실행할 수 있도록 한다.

물론 간단한 분산 KVS도 JSON 텍스트로 저장할 수 있다. 하지만 그에 대한 복잡한 쿼리를 실행할 수 있다고는 말할 수 없다. 도큐먼트 스토어는 배열과 연상 배열(맵 형)과 같은 중첩된 데이터 구조에 대해 인덱스를 만들거나 도큐먼트 일부만을 치환하는 식의 쿼리를 쉽게 실행할 수 있다.

도큐먼트 스토어의 장점은 스키마를 정하지 않고 데이터 처리를 할 수 있다는 점이다. 그래서 외부에서 들여온 데이터를 저장하는 데 특히 적합하다. 자체 개발한 애플리케이션 등에서는 명시적으로 스키마를 정하는 편이 좋은 점도 많으므로 도큐먼트 스토어는 주로 참고 시스템의 데이터 및 로그 저장 등에 적합하다.

 

+ 스키마란..?

https://coding-factory.tistory.com/216

[DB기초] 스키마란 무엇인가?

 

① MongoDB

MongoDB는 오픈 소스의 분산형 도큐먼트 스토어로 자바스크립트나 각종 프로그래밍 언어를 사용하여 데이터를 읽고 쓸 수 있다(그림 4.22). 예전부터 성능을 우선하여 신뢰성을 희생해왔기 때문에 이에 대한 비판도 많았지만, 그 간편함 때문인지 NoSQL 데이터베이스 중에서도 특히 인기가 높다.

MongoDB도 여러 노드에 데이터를 분산할 수 있지만, 그 자체는 대량의 데이터를 집계하는 데 적합하지 않다. 데이터 분석이 목적인 경우에는 역시 쿼리 엔진으로부터 접속하는 등 데이터를 추출할 필요가 있다.

 

 

4.4.5. 검색 엔진 - 키워드 검색으로 데이터 검색

'검색 엔진(search engine)'은 NoSQL 데이터베이스와는 조금 성격이 다르지만, 저장된 데이터를 쿼리로 찾아낸다는 점에서는 유사한 부분도 많고, 특히 텍스트 데이터 및 스키마리스 데이터를 집계하는 데 자주 사용된다. 

검색 엔진의 특징은 텍스트 데이터를 전문 검색하기 위해 '역색인(inverted index)'을 만드는 부분이다. 따라서 데이터를 기록하는 시스템 부하 및 디스크 소비량은 커지지만, 그 덕분에 키워드 검색이 훨씬 고속화된다.

풀 스캔에 의한 전문 검색
검색 엔진은 텍스트 데이터를 검색하기 위해 '역 색인(inverted index)'을 만든다. 즉, 텍스트에 포함된 단어를 분해하고 어떤 단어가 어떤 레코드에 포함되어 있는가 하는 인덱스를 먼저 만들어 둠으로써 검색을 고속화한다.
만약 역색인이 없으면 모든 텍스트를 전체 스캔해야 원하는 레코드를 찾을 수 있기에 검색 효율이 크게 저하된다.
예전이라면 검색 엔진을 사용하지 않고 전체 스캔하는 것은 생각할 수 없었지만, 빅데이터 기술의 발전에 의해 그것도 가능한 일이 되었다. SQL로도 정규 표현을 통해 키워드를 찾아내고 패턴에 일치하는 문자열을 추출할 수 있으르모 나머지는 처리 속도의 문제다.
예를 들어, Google BigQuery를 사용하면 대량의 계산 자원을 이용하여 몇 초만에 빅데이터의 전체 스캔이 가능하다. 쿼리를 실행시킬 때마다 모든 데이터를 로드하게 되기(=비용이 발생)때문에 매우 비효율적인 방법이지만, 실행 빈도가 높지 않다면 문제가 될 일은 없다.
검색 엔진은 독자적인 쿼리 언어를 사용하는 것이 많아 SQL에 익숙한 사람에게는 학습 비용이 많이 든다. 평소 자주 로그를 검색하는 사람은 제쳐두고, 드물게만 텍스트 데이터를 취급하는 경우라면, SQL을 중심으로 하는 데이터 분석의 구조를 그대로 이용하여 검색하는 것이 더 간단하다.

대부분의 NoSQL 데이터베이스가 성능 향상을 위해 색인 작성을 제한하고 있는 것과는 대조적으로, 검색 엔진은 적극적으로 색인을 만듦으로써 데이터를 찾는 것에 특화되어 있다. 결과적으로 검색 엔진은 데이터의 집계에 적합하며, 특히 비정상적인 상태의 감지 및 보안 체크, 고객 서포트처럼 민첩성이 요구되는 용도에서 최근의 데이터를 보기 위해 사용된다.

검색 엔진은 장기적으로 데이터를 축적하기보다는 실시간 집계 시스템의 일부로 이용된다. 예를 들어, 메시지가 배송된 데이터를 분산 스토리지에 저장하는 한편, 같은 데이터를 검색 엔진에도 전송하여 실시간성이 높은 데이터 처리를 위해 활용한다(그림 4.23).

① Elasticsearch

오픈 소스의 검색 엔진으로 인기를 끌고 있는 것이 'Elasticsearch'이다. 로그 수집 소프트웨어인 'Logstash', 시각화 소프트웨어인 'Kibana'와 함께 'ELK 스택' 또는 'Elastic 스택'으로 자주 이용된다.

Elasticsearch에는 임의의 JSON 데이터를 저장할 수 있기 때문에 도큐먼트 스토어와 비슷하지만, 아무것도 지정하지 않으면 모든 필드에 색인이 만들어진다는 특징이 있다. 텍스트 데이터에서는 역색인이 구축된다. 따라서 간단한 도큐먼트 스토어와 비교하면 쓰기의 부하가 크고, 필요에 따라 명시적으로 스키마를 결정함으로써 색인을 무효로 하는 식의 튜닝이 필요하다.

Elasticsearch는 자체 쿼리 언어에 의한 고급 집계 기능을 제공하고 있다. 열 지향 스토리지에도 대응하고 있어 그것만으로도 데이터를 집계하기 위한 기반이 된다. 다만, 표준 쿼리 언어는 사람의 힘으로 쓰기에는 너무 복잡하므로, Kibana 같은 프론트엔드를 이용하거나 프로그램 안에서 호출하는 것이 주요한 사용법이다. 

 

도큐먼트 스토어로서의 Elasticsearch
Elasticsearch를 검색 엔진이 아닌 일반 도큐먼트 스토어로서 임의의 스키마리스 데이터를 읽고 쓰는 데 사용하는 경우도 있다.
특히, 데이터를 자주 집계하는 애플리케이션은 Elasticsearch의 집계 기능이 도움이 된다. 그러나 그 구성을 생각한다면, 어디까지나 검색과 집계를 목적으로 하는 참고용 데이터 스토어로 생각하는 것이 안전하다.

 

② Splunk

오픈 소스는 아니지만, 상용 검색 엔진인 'Splunk'도 텍스트 데이터를 집계하기 위한 도구로 알려져 있다. Splunk가 자신하는 분야는 비정형 데이터로, 주로 웹 서버나 네트워크 기기 등으로부터 출력되는 로그 파일이나 JSON 파일을 다루어 텍스트 처리를 해야만 분석할 수 있는 데이터다. 예를 들어, 다음과 같은 로그가 있다고 하자.

Splunk는 검색 엔진이므로 키워드를 입력하면 그것을 포함하는 로그를 찾을 수 있다. 최근의 데이터부터 순서대로 검색되므로 매일 발생하는 각종 이벤트를 빠르게 찾거나 보고서를 작성하는 목적으로 이용된다(그림 4.24).

 

Splunk의 재미있는 점은 검색을 실행할 때 텍스트에서 필드가 추출된다는 것이다. 처음에 키워드 검색을 통해 로그를 찾으면 패턴 매치에 의해 키와 값이 추출된다. 그 결과, 검색할때마다 데이터가 구조화되게 되어 있어 쿼리를 다시 작성함으로써 어떤 테이블이라도 유연하게 만들어낼 수 있다.

그림 4.25는 앞의 로그 데이터를 이용하여 정규 표현으로 사용자 명을 추출하여 테이블로 출력한 것이다. Splunk는 파이프라인(|)을 사용하여 데이터를 순차적으로 가공한다. 이러한 대화형 쿼리를 사용하여 데이터를 추출, 필터링하면서 최종적으로는 교차 분석 및 시각화까지 하나의 화면에서 실행할 수 있어서 텍스트 데이터를 신속하게 애드 혹 분석할 때 유용하다.