PART02-2장. 데이터 처리기술 ( 분산 데이터 저장 기술)

PART02-2장. 데이터 처리기술 ( 분산 데이터 저장 기술)

분산 파일 시스템

---

• 개요
  • 분산 데이터 저장기술 : 분산 파일 시스템, 클러스터, 데이터베이스, NoSQL
  • 대용량 저장공간, 빠른 처리 성능, 확장성, 신뢰성, 가용성 등
  • 파일의 메타데이터를 관리하는 별도의 서버를 가지고 있는 비대칭형 클러스터 파일 시스템 활발히 개발
    1. 메타데이터에 접근하는 경로와 데이터에 접근하는 경로 분리
• 구글 파일 시스템(GFS)
  • 데이터를 고정크기(64MB)로 나눈 Chunk(청크)를 분산 저장
  • 해쉬 테이블 구조를 사용 -> 메모리상에서 효율적인 메타데이터 처리 지원
  • 설계 가정
    1. 저가형 서버 구성으로 빈번한 고장 발생 가능
    2. 대용량 파일 가정
    3. 작업 부하는 연속적인 데이터 Read 혹은 임의의 영역의 적은 데이터 Read
    4. write연산은 순차적, 갱신은 드물게
    5. 여러 클라이언트에서 동일 파일에 데이터를 adding 하는 환경에서 오버헤드를 최소화할 수 있는 방법 요구
    6. 낮은 응답 지연보다 높은 처리율 중요
  • 구성요소
    

    클라이언트	1. Read/Write 2. POSIX 지원 안 함, 파일 시스템 인터페이스와 유사 3. 원자적인 데이터 추가(atomic append) 연산 지원
    마스터	1. 단일 마스터 구조 - 모든 메타데이터를 메모리상에서 관리 2. 수집되는 하트비트 - 회복 동작 수행 3. 하나의 청크를 primary로 지정하여 복제본의 갱신 연산이 일관되게 처리할 수 있도록 보장 4. 파일 시스템 이름 공간과 파일의 청크 매핑 변경 연산 로깅, 마스터 상태를 shadow마스터에 복제
    청크 서버	1. 청크 관리, IO관리 2. 하트비트 쏨

    ※ POSIX(Portable Operating System Interface) : 이식 가능 운영 체제 인터페이스
  • 파일을 읽는 과정
    <그림>
    
    1. GFS 마스터에서 읽는 데이터가 있는 청크 서버의 위치와 핸들을 받아와 직접 청크 서버로 요청
• 하둡 분산 파일 시스템(HDFS)
  • 개념
    1. GFS 아키텍처 사상을 그대로 구현한 클로닝(Cloning)
    2. GFS와 유사하게 하나의 네임 노드와 다수의 데이터 노드 구성
    3. 한 번 쓰이면 변경되지 않는다고 가정(2.0부터는 append 가능)
    4. 순차적 스트리밍 방식으로 저장/조회, 배치작업에 적합하도록 설계
    5. 낮은 데이터 접근 지연시간보다는 높은 데이터 처리량 중점
    6. 구성요소 간 통신을 위해 TCP/IP 네트워크상 RPC 사용
  • 구성요소
    

    네임 노드	1. 모든 메타데이터 관리, 시스템 전반의 상태 모니터링 2. 마스터-슬레이브 중 마스터 역할 3. 수집된 하트 비트로 상태 체크(수신된 하트비트에는 블록 정보가 있고, 이로 블록 상태 확인)
    데이터 노드	1. 슬레이브, 클라이언트에서의 입출력 처리 2. 3중 복제, 파일의 체크섬 별도 저장 3. 하트비트 전송 시 관리하는 블록 목록인 blockreport 전송
    보조 네임 노드	1. HDFS 상태 모니터링 보조 2. 주기적으로 네임 노드 이미지 스냅숏

  • 과정
    1. Write 과정
       <그림>
       ① 클라이언트는 지정된 크기(64 혹은 128MB) 여러 블록으로 분리(첫 번째 블록 크기만큼 로컬에 쌓이면 요청)
       ② 어디다 보관해야 할지 네임 노드에 요청
       ③ 네임 노드는 어디다 저장할지 데이터 노드 목록 전송
       ④ 첫 번째 노드에게 전달
       ⑤ 첫번째 노드는 저장한 후 2에게 전달, 2는 저장하고 3 노드에게 전달
       ⑥ 3 -> 2 -> 1 순으로 작업 완료 신호
       ⑦ 완료 신호를 받은 클라이언트는 네임 노드에게 완료 신호, 메타데이터 저장
    2. Read 과정
       ① 애플리케이션은 클라이언트에 있는 HDFS클라이언트에 읽고자 하는 파일 요청
       ② HDFS클라이언트는 네임 노드에게 필요한 파일이 어디 있는지 위치 조회
       ③ 네임 노드는 데이터 노드 목록 전달
       ④ HDFS클라이언트는 데이터 노드에게 데이터 요청
       ⑤ 데이터 노드는 데이터 전송
       ⑥ HDFS클라이언트는 애플리케이션에 전달
• 러스터
  • 개념
    1. 객체 기반 클러스터 파일 시스템
    2. 고속 네트워크로 연결된 클라이언트 파일 시스템, 메터 데이터 서버, 객체 저장서버 구성
    3. 계층화된 모듈,  TCP/IP, 인피니밴드, 미리넷 지원
  • 구성요소
    

    클라이언트 파일 시스템	1. 리눅스 VFS(Virtual File System)에서 설치할 수 있는 2. 클라이언트 응용에 파일 시스템 인터페이스 제공
    메타데이터	1. 이름 공간과 파일에 대한 메타데이터 관리
    객체 저장서버	1. 파일 데이터 저장 및 IO관리 2. 스트라이핑 방식으로 분산 저장   (세그먼트라는 작은 데이터 단위로 분할, 복수의 장치에 저장)

  • 구동방식
    1. 유닉스 시멘틱
    2. 메타데이터를 동시에 접근하는 부하에 따라, 클라이언트 캐시에서 라이트백 캐시를 지원하거나, 메타 서버에서 메타데이터를 처리하는 방식
       ① (동시 접근이 적으면) 라이트백 캐시 지원 - 클라이언트에서 메타데이터 변경에 대한 갱신레코드 생성 -> 메타서버 전송
           라이트백 캐쉬 : 데이터를 캐시에만 저장하고, 밀려나는 경우에 하위 저장소에 저장하는 방식
       ② 메타 서버는 전달된 갱신 레코드를 재수 행하여 메타데이터 갱신
    3. 동시성 제어를 위해 별도의 잠금
    4. 네트워크 트래픽을 최소화하기 위해 데이터 잠금 요청 시 접근 의도를 같이 전달하는 인텐트 기반 잠금 프로토콜 사용

• •  
• 파일 시스템 비교
  • GFS와 HDFS는 동일
  • 무중단 가능한 건 동일, atomic 지원, 메타데이터를 저장하기 위해 DB를 사용하지 않음
  • 러스트의 특징
    1. Chunk를 사용하지 않고 객체 사용
    2. 복제가 일어나지 않음
    3. 멀티 메타 서버 지원 안 함
    4. POSIX 지원
    5. 데이터 수정 가능

---

데이터베이스 클러스터

---

• 개념
  • 하나의 데이터 베이스를 여러 개의 서버상에 구축하는 것
  • 각 파티션은 여러 노드로 분할 배치
  • 성능과 가용성 향상을 위해 데이터베이스 차원의 파티셔닝 또는 클러스터링 구축
  • 효과
    1. 병렬 처리, 고가용성(특정 DB 장애 시 서비스 지속), 성능 향상(선형 증가)
• 구분
  • 구성 관점 : 단일 서버 내 파티 셔링, 다중서버 파티셔링
  • 리소스 공유 관점
    1. 무공유 디스크
       - 각 데이터베이스 인스턴스는 관리하는 데이터를 자신의 로컬에 저 정하며, 공유하지 않음
       - 완전히 분리된 데이터의 서브 집합에 대한 소유권
       - Oracle RAC를 제외하고는 무공유 방식
       - 노드 확장에 제한이 없음
       - 장애의 경우 별도의 fault-tolerance 필요
    2. 공유 디스크
       - 논리적으로 데이터 공유, 모든 인스턴스 접근 가능
       - SAN 반드시 필요
       - 모든 노드가 데이터 수정 가능하기에 별도의 커뮤니케이션 채널 필요
       - 높은 수준의 fault-tolerance
       - 클러스터가 커지면 병목현상
• 클러스터 종류
  • Oracle RAC
    1. 공유 클러스터(특정 노드의 데이터 소유 개념 없음)
    2. 데이터를 파티셔닝 할 필요는 없지만 성능 위해서 파티셔닝 종종 함
    3. 응용 애플리케이션은 RAC 클러스터에 연결
    4. 장점
       - 고가용성
       - 확장성 : 수정 없이 새 노드를 클러스터에 쉽게 추가
       - 비용절감 : 소규모 저가형 상용 하드웨어의 클러스터에서도 성능 좋음(선형?)
    5. 도입 비용 때문에 확장성보다는 고가용성이 필요한 경우 사용
  • IBM DB2 ICE
    1. 무공유 방식(CPU, 메모리, 디스크)
    2. 분산된 데이터베이스를 하나의 데이터베이스 뷰로 봄
    3. 애플리케이션 수정 없이 노드 추가
    4. 파티셔닝 구성 방식에 따라 성능에 많은 차이
    5. failover 메커니즘 : 공유 디스크 방식을 사용하여 가용성 보장
  • 마이크로소프트 SQL 서버
    1. 연합(Federated) 데이터 베이스 형태
    2. 무공유 방식이며 논리적인 결합, 네트워크를 이용하여 연결
    3. 서버들 간 수평 분할
    4. 링크를 구성하여 Union all을 이용해 논리적인 View 제공 -> DPV(Distributed Partitioned View)
    5. 구성의 문제점
       - 파티셔닝 정책에 맞게 테이블과 뷰 생성, 전역 스키마 정보가 없어 질의 시 모든 노드 액세스
       - 노드가 많아지거나, 추가/삭제의 경우 파티션 새로 구성
       - failover 별도 구성 필요
    6. Active-Active가 아닌 Active-Stand by 형태의 failover
  • MySQL
    1. 비공 유형, 메모리(최근에는 디스크도 제공) 기반 데이터베이스 클러스터링 제공
       -다른 노드에 데이터 복제
    2. 특정 하드웨어, 소프트웨어 요구하지 않고, 병렬 구조 확장
    3. 구성
       - 관리 노드 : 클러스터 시작과 재구성시만 관여
       - 데이터 노드
       - MySQL노드 : 데이터에 접근을 지원
    4. 장애 노드 복구되어 클러스터에 투입되는 겨우 기존 데이터와 변경된 데이터에 대한 동기화 작업으로 수행
    5. 동기화 방식의 복제, 데이터 노드 간 네트워크 구성
    6. MySQL 최근 버전은 인덱스 생성 칼럼은 메모리 유지, 인덱스 비생성 컬럼은 디스크 저장
    7. 제한사항
       - LINEAR KEY 파티셔닝만
       - 노드수 255개 제한, 데이터 노드는 최대 48개
       - 트랜잭션 수행 중 롤백 지원하지 않음, 트랜잭션 이전 전체 롤백
       - 하나의 트랜젝션에 많은 데이터 처리 시 메모리 부족 -> 여러 트랜젝션으로 처리
       - 칼럼명, 테이블명 길이 제한
       - 최대 테이 슬 수는 2만 320개
       - 모든 클러스터의 기종은 동일해야 한다.
       - 운영 중 노드 추가/삭제 불가
  • NoSQL
    1. 특징
       - 분산 데이터베이스 기술, 확장성, 가용성, 높은 성능
       - 비 관계형 데이터베이스 , SQL 계열 언어, Not Only SQL
       - 데이터 구조에 따른 분리
         ① key-value 모델
         ② Document모델(JASON 또는 XML)
         ③ Graph 모델
         ④ Column 모델
       - 스키마 없이 동작, 구조에 대한 정의 변경 없음
       - 복잡한 조인 연산 기능 지원 안 함
       - 대용량 데이터 처리와 수평적 확장성
    2. 구글 빅 테이블
       - 공유 디스크 방식
       - 실시간 서비스와 대량 배치 작업 적합
       - HBase와 Neptune 유사
       - 데이터 모델
         ① multi-dimension sorted hash map을 파티션
         ② row-key의 사전적 순서로 정렬, 저장
         ③ row-key를 이용한 tablet (파티션)
         ④ 하나의 row는 n개의 column-family(column-key, value, time stamp)
         ⑤ 동일 column-key에는 여러 개의 time stamp(버전 값 관리)
         ⑥ 저장되는 하나의 데이터(map)의 키값, 정렬 기준 "rowkey + column key + timestamp"
       - 페일오버
         ① 장애 발생 시 빅 테이블의 마스터는 장애 발생 노드에서 서비스되는 Tablet을 다른 노드로 재할당
         ② 재 할당된 노드는 GFS에 저장된 로그, 인덱스, 데이터 등을 이용해 서비스를 위한 초기화 작업 후 서비스
         ③ SPOF(Single Point of Failure) : 마스터
         ④ Chubby(분산 락 서비스를 제공하는 - fault tolerance 안 죽음)를 이용하여 Master 모니터링
         ⑤ 데이터 저장소를 위한 별도 클러스터가 아닌 동일 클러스터에 위치
       - App Engine
         ① 구글 클라우드 플랫폼의 일부, 빅 테이블 사용
         ② API와 데이터 추상화
         ③ 테이블 생성 시 새로운 빅 테이블이 생성되는 것이 아니라 빅 테이블의 특정 영역에 테이블 생성
         ④ 사용자 인덱스 대신, 자사 수행 쿼리 분석으로 자동 인덱스 생성
         ⑤ 생성한 인덱스도 칼럼으로 저장
    3. HBase
       - HDFS 기반, 컬럼 기반, 파워셋에서 만듦
       - 비 관계형 구조, SQL 지원 안 함
       - 비구조화된 데이터에 적합, 실시간 read/write
       - 선형 확장
       - 클러스터를 통한 데이터 복제
       - 단일형 트랜잭션 보장
       - 로우키에 대한 인덱싱, zookeeper를 이용한 고가용성 보장
    4. 아마존 SimpleDB
       - 데이터의 실시간 처리 지원
       - 주로 아마존 다른 플랫폼 서비스(EC2, S3 등)와 같이 사용
         ① 아마존 서비스 정책 때문(내부 트래픽은 무료)
       - 데이터 복제본
       - 초단위 지연 동기(Evential Consistency)
       - 전용 쿼리(표준  SQL 미지원)
       - 구조
         ① 도메인 : 테이블과 동일 개념
         ② 아이템 : 레코드의 개념
         ③ 어트리뷰트 : 칼럼 개념, name-value 쌍, 특정 attribute에는 여러 값 저장 가능 
       - 한 번에 하나의 도메인에 대한 쿼리 수행 가능
    5. 마이크로소프트 SSDS
       - 구성
         ① 컨테이너 : 테이블과 유사 개념이지만 여러 개의 엔터티를 담을 수 있다
         ② 엔터티 : 레코드와 유사 개념, 하나의 엔터티는 여러개의 property(name-value쌍)
       - 쿼리는 하나의 컴 테이너만을 대상