데이터 처리 기술

분산 파일 시스템

개요

• 저장 기술은 분산 파일시스템, 클러스터, DB, NOSQL로 구분됨
• 사용자 중심의 인터넷 서비스와 유비쿼터스 컴퓨팅 환경은 대규모 클러스터 시스템 플랫폼의 필요성을 부각시킴.
• 최근에는 파일의 메타데이터를 관리하는 전용 서버를 가지고 있는 ‘비대칭형 클러스터 파일 시스템’이 활발히 개발

구글 파일 시스템 (GFS)

개념

• GFS는 구글의 대규모 클러스터 서비스 플랫폼의 기반이 되는 파일 시스템
• 파일을 고정된 크기(64MB)의 CHUNK들로 나누고 각 CHUNK에 대한 여러 개의 복제본과 CHUNK를 청크서버에 분산저장함
• 기본 64MB로 정하고 해시 테이블 구조 사용 -> 효율적인 메타데이터 처리 지원
• CHUNK는 마스터에 의해 생성/삭제, 유일한 식별자에 의해 구분됨

GFS 설계의가정

• 서버의 고장이 빈번히 발생할 수 있다 가정
• 작업 부하는 주로 연속적으로 많은 데이터를 읽는 연산이거나 임의의 영역에서 적은 데이터를 읽는 연산에서 발생
• 쓰기 연산은 주로 순차적으로 이루어지며, 갱신은 드물게 이루어짐
• 동기화 오버헤드를 최소화할 수 있는 방법이 요구됨
• 낮은 응답 지연시간보다 높은 처리율 중요

GFS 구성요소

• 여러 클라이언트, 하나의 마스터 청크서버들

GFS에서 파일 읽기

• 클라이언트는 파일에 접근하기 위해 마스터로부터 해당 파일의 CHUNK가 저장된 CHUNK 서버의 위치와 핸들을 받아온 뒤, 직접 청크서버에 파일 데이터를 요청

하둡 분산 파일 시스템(HDFS)

개념 : 아파치 너치의 파일 시스템으로 개발, 클로닝 프로젝트

• 마스터와 유사한 네임노드, 청크서버와 유사한 데이터 노드
• HDFS에서 파일 데이터는 블록 단위 , 여러 데이터 노드에 분산,복제,저장됨
• 파일은 한번 쓰이면 변경되지 않는다고 가정
• 순차적 스트리밍 방식
• 낮은 응답 지연시간보다 높은 처리량 중요
• 통신을 위해 TCP/IP에서 RPC사용

HDFS 구성 요소

HDFS 파일 저장 과정

• 64MB, 128MB 단위의 블록으로 분리
• 첫 번째 데이터노트로부터 세 번째 데이터노드까지 저장 완료 -> 각 데이터 노드들은 순차적으로 클라이언트에게 저장이 완료되었다는 신호를 보냄
• 모든 블록의 저장이 완료될 때까지 반복
• 모든 블록의 저장이 완료되면 네임노드는 블록들이 저장된 데이터노드의 주소(메타데이터) 저장

HDFS 파일 읽기 과정

• 클라이언트가 읽고자 하는 파일의 정보를 네임노드에게 요청
• 네임노드는 모든 블록의 목록과 블록이 저장된 데이터 노드의 위치를 클라이언트에 반환

러스터

개념

• 클러스터 파일 시스템에서 개발한 객체 기반 클러스터 파일 시스템
• 고속 네트워크 연결 클라이언트 파일 시스템, 메타데이터 서버, 객체 저장서버들로 구성
• 계층화된 모듈 구조, TCP/IP, 인피니밴드, 미리넷과 같은 네트워크 지원

구성요소

구동 방식

• 라이트백 캐시 지원
• 클라이언트에서 메타데이터 변경에 대한 갱신 레코드 생성, 나중에 메타데이터 서버에 전달
• 메타데이터서버는 전달된 갱신 레코드를 재수행해 변경된 메타데이터를 반영
• 클라이언트에서 라이트백 캐시 지원, 메타데이터 서버에서 메타데이터를 처리하는 방식을 적용
• 동시 접근이 적으면 클라이언트 캐시를 위용한 라이트백 캐시 사용, 많으면 클라이언트 캐시 사용 -> 오버헤드 줄임
• 동시성 제어를 위해 별도의 잠금 사용
• 인텐트 기반 잠금 프로토콜 : 네트워크 트래픽 최소화 위해 잠금 요청 시 접근 의도를 같이 전달
  • 라이트백 캐시 : 데이터를 캐시에만 저장하고 어쩔 수 없이 캐시영역에서 밀려나는 경우 하위저장소에 저장

데이터베이스 클러스터

개념

• 하나의 DB를 여러 개의 서버 상에 구축
• 파티셔닝 : DB를 여러 부분 분할, 분할된 요소는 파티션
• 각 파티션은 트랜잭션 수행
• 데이터를 통합할 때 성능과 가용성의 향상을 위해 데이터베이스 차원의 파티셔닝 또는 클러스터링 이용

효과

데이터 베이스 클러스터의 구분

형태에 따라 단일 서버 내 파티셔닝과 다중 서버 사이의 파티셔닝으로 구분 리스크 공유 관점에서는 공유 디스크, 무공유 디스크로 구분

무공유 디스크

• 무공유 클러스터에서 각 DB 인스턴스는 자신이 관리하는 파일을 자신의 로컬 디스크에 저장, 노드 간 이 파일들은 공유X
• 각 인스턴스나 노드는 완전히 분리된 데이터 서브 집합에 대한 소유권을 가짐, 소유권을 가진 인스턴스가 처리
• 노드가 처리 요청을 받으면 데이터를 가진 노드에 신호를 보냄
• Oracle RAC을 제외한 대부분 DB 클러스터가 무공유 방식
• 장점 : 노드 확장 제한X
• 단점 : 장애가 발생할 경우를 대비해 별도의 폴트톨러런스 구성
  • 폴트 톨러런스 : 고장이 발생해도 일부를 유지하는 기술

공유 디스크

• 파일은 논리적으로 모든 DB 인스턴스 노드들은 논리적으로 공유, 각 인스턴스는 모든 데이터에 접근할수 있다
• 공유하려면 SAN과 같은 네트워크가 있어야함
• 모든 노드가 데이터를 수정할 수 있음 -> 별도의 커뮤니케이션 채널 필요
• 장점 : 높은 수준의 폴트톨러런스 제공 -> 하나의 노드만 살아도 서비스 가능
• 단점 : 클러스터가 커지면 디스크 영역에서 병목현상 발생

데이터 베이스 클러스터 종류

1. Oracle RAC DB 서버

   • 공유 클러스터, 모든 노드에서 실행
   • 특정 노드가 데이터를 소유하는 개념이 없다
   • 파티셔닝 필요X, 하지만 성능 향상을 위해 하는 경우 빈번
   • 응용 프로그램은 RAC클러스터에 연결, RAC는 클러스터 모든 노드에 로드를 고르게 분산
   • 장점 : 가용성, 확장성, 비용 절감

2. IBM DB2 ICE

   • 무공유 클러스터
   • 데이터가 어느 파티션에 존재하는지 알 필요가 없다.
   • 데이터와 사용자가 증가해도 시스템의 성능과 용량을 일정하게 유지할 수 있다.
   • 파티셔닝 구성에 따라 성능 차이가 있다
   • 별도의 페일오버 메커니즘 필요 -> DB2를 이용해 클러스터링 구성할 때는 공유 디스크 방식 사용해 가용성 보장
   • 장애 상황이 발생하면 다른 노드가 해당 데이터에 대한 서비스를 처리하는 방식
     • 페일오버 : DB의 최신 버전을 백업해두어 장애가 발생했을 때 장애 극복

3. 마이크로소프트 SQL 서버

   • 연합 DB 형태 -> 여러 노드로 확장 기능
   • 독립된 서버에서 실행되는 다른 DB간 결합
   • 수평 분할, 모든 파티션에 대해 UNION ALL로 논리적인 뷰(DPV)를 구성
   • 마이크로 소프트 SQL 서버 구성 문제점
     1. DBA개발자가 파티셔닝 정책에 맞게 테이블과 뷰를 생성해야됨
     2. 전역 스키마 정보가 없어서 모든 노드를 액세스해야 함
     3. 노드가 많아지거나 노드의 추가/삭제가 발생할 경우 파티션을 새로 구성해야함
     4. 페일오에 대해 별도로 파티션 구성해야함
   • Active-Standby 방법 사용

4. MySQL

   • 비공유형, 메모리 기반 DB 클러스터링 지원
   • 병렬 서버구조 확장 가능, 관리 노드, 데이터 노드, MySQL노드로 구성
   • 관리 노드 : 클러스터 관리, 시작과 재구성 시에만 관여
   • 데이터 노드 : 클러스터의 데이터 저장
   • MySQL 노드 : 클러스터 데이터에 접근을 지원
   • 가용성을 높이기 위해 다른 노드에 데이터를 복제
   • 복구되어 투입되어도 기존 데이터와 변경된 데이터에 대한 동기화 작업이 자동 수행
   • 동기화 방식 복제 -> 데이터 노드 간 별도의 네트워크를 구성
   • 최근 버전에서는 디스크 기반 클러스터링, 인덱스가 생성된 칼럼은 기존과 동일하게 메모리에 유지, 생성하지 않은 칼럼은 디스크에 저장

   제한 사항

   • LINEAR KEY 파티셔닝만 가능
   • 클러스터 참여 노드 수는 255로 제한, 데이터 노드는 최대 48개
   • 문제가 발생하면 트랜잭션 이전으로 롤백해야함
   • 여러 개 트랜잭션으로 분리해 처리하는 게 좋음
   • 칼럼명 길이 31자,, 테이블명 길이 122자, 메타데이터 2만320개
   • 클러스터 테이블 2만 320개, 로우 8KB, 테이블 키 32개 최대
   • 모든 클러스터 기종은 동일해야 함.
   • 운영 중 노드를 추가 삭제할 수 없다.
   • 디스크 기반일 경우 tablespace $2^{32}$, tablespace당 파일 개수 $2^{16}$ 파일 크기 32GB

NoSQL

개념

• 분산 데이터베이스 기술, 비관계형 DB 관리 시스템
• 구조에 따라 key-value, Document, Graph, Column 모델로 구분
• key, value의 형태 자료저장
• 스키마 없이 작동, 구조 정의 변경 없이 추가 가능
• join 지원X, 대규모 수평적 확장성
• 대부분이 오픈 소스 구글 빅테이블, 아파치 base, 아마존 SimpleDB, 마이크로소프트 SSDS

1. 구글 빅테이블 개념

• 구글의 개발, 공유 디스크 방식
• 모든 노드가 데이터 인덱스 파일 공유
• 유사한 솔루션 : Neptune

모델

• 모든 데이터는 row-key의 사전적 순서로 정렬,저장
• 파티션도 row-key로 이루어지고 Tablet이라 불리는 파티션은 분산된 노드에서 서비스됨 100~200MB
• row는 n개의 column-family를 가질 수 있고 column-key, value, time stamp형태로 데이터 저장
• 동일한 column-key에 대해 timestamp가 다른 여러 버전의 값이 존재할 수 있음
• 빅테이블 정렬 기준은 ‘rowkey + column-key + timestamp’

페일오버

• 장애가 발생할 때 Tablet을 다른 노드로 재할당, GFS에 저장된 것을 이용해 초기화 작업 수행 후 다시 서비스를 함
• SPOF는 마스터다
• 분산 락 서비스를 제공하는 Chubby를 이용해 마스터를 모니터링 하다가 장애가 발생하면 가용한 노드가 마스터 역할을 함
• Chubby는 폴트톨러런스 구조라 절대 장애 발생하지 않음
• 빅테이블은 별도 클러스터 구성하기 보다는 파일시스템, 맵리듀스 컴퓨팅 클러스터와 동일한 클러스터 위에 구성됨

AppEngine

• 구글 클라우드 플랫폼의 일부, 빅테이블 사용
• 추상 계층을 두고 API 직접 공개x, 데이터 모델도 추상화
• 생성되는 것이 아닌 특정 한 테이블에 대한 한 영역만 차지하게 됨
• 쿼리를 분석해 자동으로 인덱스 생성
• 인덱스가 빅테이블의 특정 테이블, 테이블 내 칼럼으로 저장됨

2. HBASE

• HDFS를 기반으로 구현된 칼럼 기반 분산 데이터베이스
• 관계형 구조X, SQL 지원X
• 비구조화된 데이터에 적합, 실시간 읽기/쓰기에 용이
• 선형 확장 가능 구조, 복제 기능, 수평적 확장성
• 큰 테이블에 적합, 트랜잭션 보장, Zookeeper를 이용한 고가용성

3. 아마존 SimpleDB

• 아마존의 다른 플랫폼 서비스와 같이 사용
• 사용자는 EC2에서 수행되는 웹 서버로 접근하고 웹 서버에서 SimpleDB의 데이터를 조회해 적절하게 가공 후 사용자에게 제공
• 관계형, SQL 지원 X, 전용 쿼리 언어 사용
• 데이터 모델은 Domain, Item, Attribute, Value로 구성, 스키마 없음

• 한 번에 하나의 도메인에 대해서만 쿼리 수행해야 함
• 1:N관계의 모델을 갖는 두 개의 도메인으로부터 조회할 경우 쿼리가 여러번 수행되어야 함
• 다음과 같은 API 제공

4. 마이크로소프트 SSDS

• 컨테이너, 엔티티로 구성
• 컨테이너 : 테이블과 유사한 개념, 하나의 컨테이너에 여러 종류의 엔티티 저장 가능
• 엔티티 : 레코드 유사 개념, 여러개의 property 가질 수 있음. property는 name-value 쌍으로 지정
• 정보를 하나의 컨테이너에 저장
• 이런 방식으로 컨테이너를 구성하면 많은 컨테이너가 생성됨, 이들은 여러 노드에 분산, 관리됨
• 쿼리는 하나의 컨테이너만을 대상으로 함
• 컨테이너 생성,삭제 엔티티의 생성, 삭제 , 조회, 쿼리 등의 API를 제공, SOAP/REST 기반 프로토콜을 지원