분산 데이터 저장 기술
분산 파일 시스템의 개요
: 분산 데이터 저장 기술은 분산 파일시스템, 클러스터, 데이터베이스, NoSQL로 구분된다.
: 최근 파일의 메타데이터를 관리하는 전용 서버를 가지고 있는 '비대칭형(asymetric) 클러스터 파일 시스템'이 활발하게 개발되고 있음, 이 시스템은 메타데이터에 접근하는 경로와 데이터에 접근하는 경로가 분리된 구조를 가진다
구글 파일 시스템(GFS, Google File System)
: GFS는 Google File System으로서, 구글이 자사 사용 목적으로 개발한 분산 파일 시스템이며 구글의 대규모 클러스터 서비스 플랫폼의 기반이 되는 시스템이다.
: 일반적 파일 시스템에서의 클러스터 및 섹터와 유사하게 고정된 크기(64MB)의 청크(chunk)들로 나누고, 각 chunk에 대한 여러 개의 복제본과 chunk를 청크서버에 분산, 저장한다. 청크 서버들은 데이터를 자동으로 복사하여 저장하고, 주기적으로 청크서버의 상태를 마스터에게 전달한다.
: 트리 구조가 아닌 해시 테이블 구조 등을 사용함으로써 메모리상에서 보다 효율적인 메타데이터의 처리를 지원한다.
: chunk는 마스터에 의해 생성/삭제될 수 있으며, 유일한 식별자에 의해 구별된다.
GFS 설계의 가정
: 저가형 서버로 구성된 환경으로 서버의 고장이 빈번히 발생할 수 있다고 가정
: 파일에 대한 쓰기 연산은 주로 순차적으로 이루어지며, 파일에 대한 갱신은 드물게 이루어진다.
: 여러 클라이언트에서 동시에 동일한 파일에 데이터를 추가하는 환경에서 동기화 오버헤드를 최소화할 수 있는 방법이 요구됨
: 낮은 응답 지연시간보다 높은 처리율이 더 중요하다.
GFS의 구성요소
: GFS는 여러 클라이언트들에 의해 접근되는 하나의 마스터와 청크서버들로 구성된다.
- 클라이언트(Client) : 파일에 대한 읽기/쓰기 동작을 요청하는 애플리케이션으로 POSIX(Portable Operating System Interface) 인터페이스를 지원하지 않으며, 파일 시스템 인터페이스와 유사한 자체 인터페이스를 지원
- 마스터(Master) : 단일 마스터 구조로 모든 메타데이터를 메모리상에서 관리, 주기적으로 수집되는 청크서버의 하트비트(Heartbeat) 메시지를 이용하여 chunk들의 상태에 따라 chunk를 재복제하거나 재분산하는 것과 같은 회복동작을 수행
- 청크서버(Chunk Server) : 로컬 디스크에 chunk를 저장, 관리하면서 클라이언트로부터 chunk 입출력 요청을 처리, 하트비트(Heartbeat) 메시지를 통해 청크서버의 상태에 대한 정보를 주기적으로 마스터에게 전달
GFS에서 파일을 읽어오는 과정
: 클라이언트는 파일에 접근하기 위해 마스터로부터 해당 파일의 chunk가 저장된 chunk 서버의 위치와 핸들을 먼저 받아온 뒤, 직접 청크서버에게 파일 데이터를 요청한다.
하둡 분산 파일 시스템(HDFS, Hadoop Distributed File System)
: 아파치 너치(Apache Nutch) 웹 검색 엔진의 파일 시스템으로 개발되었으며, 구글 파일 시스템의 아키텍처와 사상을 그대로 구현한 클로닝(Cloning) 프로젝트
: 클라우드 컴퓨팅 환경을 구축하기 위해 이용하여 대용량 데이터의 분산 저장 기능을 제공하는 시스템
: HDFS는 GFS의 마스터와 유사한 하나의 네임노드(NameNode), GFS의 청크서버와 유사한 다수의 데이터노드(DataNodee)로 구성되며, 파일 데이터는 블록(또는 청크) 단위로 나뉘어 여러 데이터 노드에 분산, 복제, 저장된다.
: HDFS에서 기본적으로 파일은 한 번 쓰이면 변경되지 않는다고 가정한다.
: HDFS는 순차적 스트리밍 방식으로 파일을 저장하거나 저장된 파일을 조회하며, 배치 작업에 적합하도록 설계돼 있다.
: 낮은 데이터 접근 지연 시간보다는 높은 데이터 처리량에 중점을 두고 있다.
HDFS의 구성요소
- 네임노드(NameNode) : HDFS상의 모든 메타데이터를 관리하며, 마스터/슬레이브 구조에서 마스터 역할, 시스템 전반의 상태 모니터링, 데이터를 저장하거나 애플리케이션을 실행하는 작업은 수행하지 않음, 클라이언트로부터의 파일 접근 요청을 처리, 데이터노드들로부터 하트비트(HeartBeat)를 받아 데이터노드들의 상태를 체크하는데, 하트비트 메시지에 포함된 블록 정보를 가지고 블록의 상태를 체크할 수 있음
- 데이터노드(DataNode) : HDFS의 슬레이브 노드로, 클라이언트로부터 데이터 입출력 요청을 처리, 데이터의 유실을 방지하기 위해 블록을 3중복제하여 저장, 블록을 저장할 때, 해당 블록에 대한 파일의 체크섬(Checksum) 정보를 별도 저장, 주기적으로 데이터노드의 상태를 나타내는 하트비트(HeartBeat)와 자신이 관리하는 블록의 목록인 Blockreport를 네임노드에게 전송
- 보조네임노드 : HDFS 상태 모니터링을 보조
HDFS의 파일 읽기 과정
: 클라이언트는 읽고자 하는 파일에 대한 정보를 네임노드에게 요청
: 네임노드는 파일에 대한 모든 블록의 목록과 블록이 저장된 데이터노드의 위치를 클라이언트에게 반환
: 클라이언트는 전달받은 블록의 위치를 이용해 데이터노드로부터 직접 데이터를 읽어 들인다.
러스터(Luster)
: 클러스터 파일 시스템에서 개발한 객체 기반의 클러스터 파일 시스템, 계층화된 모듈 구조
구성요소
- 클라이언트 파일 시스템
- 메타데이터 서버
- 객체 저장 서버 : 파일데이터를 저장하고, 클라이언트로부터의 객체 입출력 요청을 처리, 데이터는 세그먼트라는 작은 데이터 단위로 분할해서 복수의 디스크 장치에 분산시키는 기술인 스트라이핑 방식으로 분산, 저장한다.
구동방식
: 러스터는 유닉스 시맨틱을 제공하면서 파일 메타데이터에 대해서는 라이트백 캐시(Write Back Cache)를 지원한다. 이를 위해 클라이언트에서 메타데이터 변경에 대한 갱신 레코드를 생성하고 나중에 메타데이터 서버에 전달한다.
: 러스터는 파일의 메타데이터와 파일 데이터에 대한 동시성 제어를 위해 별도의 잠금을 사용한다.
: 러스터는 클라이언트와 메타데이터 서버 간의 네트워크 트래픽을 최소화하기 위하여 메타 데이터에 대한 잠금 요청 시에 메타데이터 접근 의도를 같이 전달하는 인텐트(Intent) 기반 잠금 프로토콜을 사용한다.
데이터베이스 클러스터
: 데이터베이스 클러스터는 하나의 데이터베이스를 여러 개의 서버(또는 가상 서버) 상에 구축하는 것
: 데이터를 통합할 때, 성능과 가용성의 향상을 위해 데이터베이스 차원의 파티셔닝 또는 클러스터링을 이용
데이터 베이스 파티셔닝 구현의 효과
: 병렬처리, 고가용성(특정 파티션에서 장애가 발생하더라도 서비스가 중단 않음), 성능향상(성능의 선형적인 증가 효과)
데이터베이스 클러스터의 구분
: 데이터베이스 시스템을 구성하는 형태에 따라 단일 서버 내의 파티셔닝과 다중서버 사이의 파티셔닝으로 구분
: 리소스 공유 관점에서는 다시 공유디스크와 무공유로 구분
데이터베이스 클러스터의 구분
무공유 디스크
: 무공유(Shared Nothing) 클러스터에서 각 데이터베이스 인스턴스는 자신이 관리하는 데이터 파일을 자신의 로컬 디스크에 저장하며, 이 파일들은 노드 간에 공유하지 않는다.
: 각 인스턴스나 노드는 완전히 분리된 데이터의 서브 집합에 대한 소유권을 가지고 있으며, 각 데이터는 소유건을 갖고 있는 인스턴스가 처리한다.
: Oracle RAC(Real Application Cluster)를 제외한 대부분 데이터베이스 클러스터가 무공유 방식을 채택
장점 : 노드 확장에 제한 없음
단점 : 각 노드에 장애가 발생할 경우를 대비해 별도의 폴트톨러런스(fault-tolerance)를 구성해야 함
공유 디스크
: 공유 디스크(Shared Disk) 클러스터에서 데이터 파일은 논리적으로 모든 데이터베이스 인스턴스 노드들은 데이터 파일을 논리적으로 공유하며, 각 인스턴스는 모든 데이터에 접근할 수 있음
: 데이터를 공유하려면 SAN(Storage Area Network)과 같은 네트워크가 반드시 있어야 함
: 모든 노드가 데이터를 수정할 수 있기 때문에 노드간의 동기화 작업 수행을 위한 별도의 커뮤니케이션 채널 필요
장점 : 높은 수준의 폴트 톨러런스를 제공하므로 클러스터를 구성하는 노드 중 하나의 노드만 살아 있어도 서비스 가능
단점 : 클러스터가 커지면 디스크 영역에서 병목현상 발생
데이터베이스 클러스터의 종류
- Oracle RAC 데이터베이스 서버
: 공유 클러스터, 클러스터의 모든 노드에서 실행되며 데이터는 공유 스토리지에 저장됨
: 클러스터의 모든 노드는 데이터베이스의 모든 테이블에 동등하게 액세스하며, 특정 노드가 데이터를 '소유'하는 개념 없음
: 응용 프로그램은 클러스터의 특정 노드가 아니라 RAC 클러스터에 연결하며, RAC는 클러스터의 모든 노드에 로드를 고르게 분산
Oracle RAC 데이터베이스 서버의 장점
: 가용성(높은 수준의 폴트 톨러런스), 확장성(새 노드를 클러스터에 쉽게 추가), 비용 절감
도입 비용 때문에 확장성이 중요한 데이터보다는 고가용성을 요구하는 데이터에 많이 사용됨
- IBM DB2 ICE(Integrated Cluster Environment)
: DB2는 CPU, 메모리, 디스크를 파티션별로 독립적으로 운영하는 무공유 방식의 클러스터링 지원
: 애플리케이션은 여러 파티션에 분산된 데이터베이스를 하나의 데이터베이스로 보게 되고, 데이터가 어느 파티션에 존재하고 있는지 알 필요 없음
: 각 노드로 분사되는 파티셔닝을 어떻게 구성하느냐에 따성능의 차이가 많이 발생할 수 있음
- 마이크로소프트 SQL Server
: SQL Server는 연합(Federated) 데이터베이스 형태로, 여러 노드로 확장할 수 있는 기능 제공
: 연합 데이터베이스는 디스크 등을 공유하지 않는 독립된 서버에서 실행되는 서로 다른 데이터베이스들 간의 논리적인 결합이며, 네트워크를 이용하여 연결됨
: 각 노드의 데이터베이스 인스턴스 사이에 링크를 구성한 후 모든 파티션에 대해 UNION ALL을 이용해 논리적인 뷰를 구성하는 방식
: DBA나 개발자가 파티셔닝 정책에 맞게 테이블과 뷰를 생성해야 하고, 전역 스키마 정보가 없기 때문에 질의 수행을 위해 모든 노드를 액세스 해야함
: SQL Server에서도 페일오버 메커니즘을 제공하지만, Active-Active가 아닌 Active-Standby 방법을 사용
- MySQL
: MySQL 클러스터는 비공유형으로 메모리(최근에는 디스크도 제공) 기반 데이터베이스의 클러스터링 지원
: 특정한 하드웨어 및 소프트웨어를 요구하지 않고 병렬 서버구조로 확장 가능
: 관리노드, 데이터노드, MySQL 노드로 구성됨
- 관리노드 : 클러스터를 관리하는 노드로 클러스터 시작과 재구성 시에만 관여
- 데이터 노드 : 클러스터의 데이터를 저장하는 노드
- MySQL 노드 : 클러스터 데이터에 대한 접근을 지원하는 노드
: 장애가 발생했던 노드가 복구되어 클러스터에 투입된 경우에도 기존 데이터와 변경된 데이터에 대한 동기화 작업이 자동으로 수행된다
My SQL 클러스터를 구성을 할 경우의 제한 사항
: 파티셔닝은 LINEAR KEY 파티셔닝만 사용 가능
: 클러스터에 참여하는 노드(SQL 노드, 데이터 노드, 매니저를 포함) 수는 255로 제한, 데이터노드는 최대 48개가지만 가능
: 트랜잭션 수행 중에 롤백을 지원하지 않으므로 작업 수행 중에 문제가 발생하였다면, 전체 트랜잭션 이전으로 롤백해야 한다
: 모든 클러스터의 기종은 동일해야 한다
: 운영 중에 노드를 추가/삭제할 수 없다
NoSQL
: 여러 대의 데이터베이스 서버를 묶어 클러스터링한 후 하나의 데이터베이스를 구성
: 비관계형 데이터베이스 기술로, SQL 계열 쿼리 언어를 사용할 수 있다는 사실을 강조한다는 면에서 Not only SQL로 불리기도 한다
: NoSQL은 저장되는 데이터의 구조에 따라 Key-Value 모델, Document 모델, Graph 모델, Column 모델로 구분된다
: NoSQL은 Key와 Value의 형태로 자료를 저장하고, 빠르게 조회할 수 있는 자료 구조를 제공하는 데이터 저장소
: 스키마 없이 동작하며, 구조에 대한 정의 변경 없이 자유롭게 데이터베이스의 레코드에 필드를 추가할 수 있음
: 복잡한 Join 연산 기능은 지원하지 않음
: 대부분이 오픈소스이며, 구글 빅테이블, 아파치 HBase, 아마존 Simple DB, 마이크로소프트 SSDS 등이 있음
구글 빅테이블
: 빅테이블은 구글이 대용량의 데이터를 저장하기 위해 개발한 분산 데이터 관리 저장소로, 구글 클라우드 플랫폼에서 데이터 저장소로 사용됨
: 공유 디스크 방식이며, 구글에서 개발된 분산 파일시스템을 이용하고 있어 모든 노드가 데이터, 인덱스 파일을 공유하고 있음
구글 빅데이블 데이터 모델
: 빅테이블은 Multi-Dimension Sorted Hash Map을 파티션하여 분산 저장하는 저장소
: 테이블 내의 모든 데이터는 Row-Key의 사전적 순서로 정렬, 저장된다
: Row는 n개의 Column-Family(Column의 모음)를 가질 수 있으며, Column-Family에는 Column-Key, Value, Timestamp의 형태로 데이터를 저장한다.
: 동일한 Column-key에 대해 타임스탬프(Timestamp)가 다른 여러 버전의 값이 존재할 수 있으며, 타임스탬프는 칼럼 값의 버전을 관리하기 위해 사용된다.
: BigTable에 저장되는 하나의 데이터(Map)의 키 값 또는 정렬 기준은 Rowkey + Columnkey + Timestamp(로우식별자 + 칼럼 이름 + 타임스탬프)이다.
페일오버(Failover)
: 특정 노드에 장애가 발생할 경우, 빅데이블의 마스터는 장애가 발생한 노드에서 서비스되던 Tablet을 다른 노드로 재할당
: Chubby는 폴트톨러런스 지원 구조이기 때문에 절대로 장애가 발생하지 않는다
:
AppEngine
: 구글 클라우드 플랫폼의 일부로 빅테이블을 사용
: 빅테이블에서는 별도의 사용자 정의 인덱스를 제공하지 않는 반면, AppEngine에서는 사용자가 수행하는 쿼리를 분석하여 자동으로 인덱스를 생성해준다.
HBase
: 하둡 분산 파일 시스템(HDFS)를 기반으로 구현된 칼럼 기반의 분산 데이터베이스로 파워셋 회사에서 구글의 빅테이블을 모델로 하여 만듦
: HBase는 관계형 구조가 아니며, SQL을 지원하지 않는다
: 구조화된 데이터보다는 비구조화된 데이터에 더 적합
: 노드만 추가하면 선형으로 학장이 가능한 구조를 가지고 있으며, 클러스터를 통한 데이터의 복제 기능을 제공
: 관계형 데이터베이스와는 달리 수평적으로 확장성이 있어 큰 테이블에 적합
아마존 SimpleDB
: SimpleDB는 아마존의 데이터 서비스 플랫폼으로, 웹 애플리케이션에서 사용하는 데이터의 실시간 처리를 지원한다
: SimpleDB는 하나의 데이터에 대해 여러 개의 복제본을 유지하는 방식으로 가용성을 높이며, 트랜잭션 종료 후 데이터가 모든 노드에 즉시 반영되지 않고 초 단위로 지연 동기화되는 Eventual Consistency 정책을 취한다
: SimpleDB의 데이터 모델은 Domain, Item, Attribute, Value로 구성되며 스키마가 없는 구조
- 도메인 : 관계형 데이터베이스의 테이블과 동일한 개념
- Item : 관계형 데이터베이스의 레코드와 동일한 개념
- Attribute : 관겨형 데이터베이스의 칼럼과 동일한 개념이지만 사용하기 전에 미리 정의할 필요 없음, Name, Value 쌍으로 데이터를 저장, Item의 특정 Attribute에는 여러 개의 값을 저장할 수 있음
: 한 번에 하나의 도메인에 대해서만 쿼리를 수행해야함
마이크로소프트 SSDS
: SSDS(SQL Server Data Service)는 마이크로소프트에서 2008년 4월에 베타서비스를 실시한 데이터 서비스로 고가용성을 보장한다
: 컨테이너, 엔티티로 구성됨