데이터 처리기술_분산 데이터 저장 기술

분산 데이터 저장 기술

데이터베이스 구축시 데이터를 복수개의 데이터 저장소에 분산하여 부하를 분산할 수 있다.

몇 개의 데이터베이스가 가동불능인 경우에도 임계치 이상의 데이터베이스가 가동 가능한 경우 안전하게 데이터를 접근할 수 있도록 결함 감내 기능을 제공하며, 복수 개의 분산정보를 복수 개의 데이터 저장소에 분산함으로써 보안성을 높인 데이터베이스 시스템 기술.

분산 파일 시스템은 Master node와 Slave node, 두 개의 노드로 구성되어 있다. 마스터 노드는 실제 데이터를 저장하는 서버 및 저장되어 있는 데이터를 관리하는 역할을 하고, 슬레이브 노드는 실제 데이터를 저장하는 역할 및 사용자 요청에 따라 데이터를 전달해 주는 역할을 한다.

 

마스터 노드

- 분산 파일 시스템에서 사용하고 있는 모든 슬레이브 노드들을 관리

: 일반적으로 분산 파일 시스템은 수십, 수백, 수천 개의 슬레이브 노드들이 동작. 마스터 노드는 각 슬레이브 노드들의 상태를 알고 있어야만 사용자가 데이터 저장을 요청하거나 데이터 다운로드를 요청할 때 어느 슬레이브 노드에 저장하거나 가져올지 결정할 수 있다.

-> 현재 어떤 슬레이브 노드가 분산 파일 시스템을 위해서 동작 중인지, 아니면 동작 중 고장으로 인해 더 이상 동작하지 않는지에 대한 정보를 실시간으로 파악

 

- 디렉터리와 파일에 대한 정보를 포함하는 메타데이터 관리

: 분산 파일 시스템에서 슬레이브 노드는 실제 사용자의 데이터를 보관하고 있기 때문에 마스터 노드는 사용자가 생성한 디렉터리 구조와 파일 목록을 보관하고 있어야 한다. 여기에 분산 파일 시스템 환경에서 중요한 또 하나의 메타데이터가 존재한다. 

 

* 메타데이터 = 사용자 데이터가 어느 슬레이브 노드에 존재하는지에 대한 정보

 

분산되어 저장된 사용자 데이터를 가져오기 위해 모든 슬레이브 노드들을 찾아가며 사용자가 원하는 데이터가 존재하는지 확인할 수 없기에, 마스터 노드는 데이터가 어느 슬레이브 노드에 저장되어 있는지 정확히 알고 있어야 한다.

 

마스터 노드가 데이터 저장 위치를 알고 있으면?

원하는 데이터를 어느 슬레이브 노드에 요청해야 하는지 빠르게 알 수 있다.

현재 슬레이브 노드가 동작 중인지, 디스크 용량은 충분한지 등의 정보를 마스터 노드가 실시간으로 확보함으로써 사용자가 데이터 업로드를 요청하면 이 정보를 바탕으로 어느 슬레이브 노드에 데이터를 저장할지 결정하는 역할.

 

슬레이브 노드

- 사용자의 데이터를 저장하는 역할 담당

: 사용자가 파일을 업로드  -> 해당 파일 저장 / 사용자가 데이터를 다운로드 -> 해당 데이터 전달

 

- 하나의 파일을 여러 개의 슬레이브 노드에 동일하게 복제하여 관리하는 역할

: 분산 파일 시스템의 가장 강력한 기능

-> 일반적으로 사용자 데이터를 저장하고 있는 디스크는 자주 고장을 일으키기에 항상 고장에 대비

 

디스크 고장과 서버의 고장을 쉽게 처리하기 위해, 여러 서버에 사용자의 데이터를 복제.

 

구글 파일 시스템

Google File System, GFS

- Google에 의해 회사 사용 목적으로 개발된 분산 파일 시스템

- 일반 상용 하드웨어를 이용하여 대량의 서버를 연결, 안정적이고 효율적인 데이터 접근

: 엄청나게 많은 데이터를 보유해야 하는 구글의 핵심 데이터 스토리지와 구글 검색엔진을 위해 최적화

 

- 파일들은 일반적인 파일 시스템에서의 클러스터, 섹터들과 비슷하게 64MB로 고정된 크기의 Chunk들로 구성

: 덮어쓰거나 크기를 줄이는 경우가 극히 드물며, 보통 추가되거나 읽혀지기만 한다. 가격이 저렴한 범용 컴퓨터들로 구성되고 집적도가 높은 구글의 컴퓨팅 클러스터들에서 잘 동작하도록 최적화

- 가격이 저렴한 서버에서도 사용 가능 : 하드웨어 안정성이나 자료 유실 고려 설계

- 대기시간이 조금 길더라도 데이터의 높은 성능에 중점

 

- 하나의 마스터 서버와 다수의 청크 서버로 구성

# 마스터 서버 : 파일 시스템의 네임스페이스와 청크의 위치 정보 관리. 파일의 개수가 많아질 경우 모든 파일에 대한 메타데이터를 마스터 서버 메모리에 유지하기에는 무리

 

- 하나의 파일은 고정 크기의 청크 단위로 나뉘어 청크 서버에 저장

- 장애 대응을 위해 각각 청크는 기본적으로 3개의 서로 다른 청크 서버에 복제

- 파일들은 고정된 크기의 조각들로 나뉘어 저장 : 각각의 조각은 서버 전체에 걸쳐 고유불변한 64비트 조각 번호를 마스터로부터 부여

- 조각 서버는 로컬 디스크에 조각들을 리눅스 파일로 저장하고, 조각 번호 해당 바이트 범위에 따라 파일을 읽고 쓰게 된다.

- 구성요소의 오류는 당연하다고 간주 : 파일시스템은 수백 내지 수천 개의 저가용 하드웨어로 구성된 저장 기기에서 구현되며 상당한 숫자의 클라이언트에서 접속 -> 지속적인 모니터링과 오류검사, 무정지 기능 그리고 자동 복구 기능이 필수적.

 

 

Ex. Gmail 서비스 : 적은 비용으로 성능이 우수하고, 신뢰성 있는 저장 장치를 대용량으로 구축이 가능한 GFS를 활용하여 후발주자임에도 다수의 사용자를 확보

 

하둡 분산 파일 시스템

Apache Hadoop

- 파일을 저장하기 위한 HDFS와 저장된 파일을 처리하는 맵리듀스로 구성

- 다수의 노드에서 동작하며, 마스터 노드와 하나 이상의 슬레이브 노드로 구성

 

각각 노드는 유형에 따라 동작하는 프로세스가 서로 다르며, 마스터 노드의 역할은 파일 시스템 관리 및 작업관리, 슬레이브 노드는 파일을 저장하고 작업을 실행한다

 

[대용량 파일을 처리할 때]

파일을 읽기 편한 크기로 분할한 다음, 각각 노드에 저장한 후 분할 크기를 기준으로 동시에 여러 노드에서 읽어서 처리함으로써 이를 고성능으로 처리한다. 또한 시스템 확장이 용이하여 한두 개의 데이터노드 장애에도 정상적으로 동작하며, 운영 중인 시스템에서의 노드의 추가/제거 또한 간단히 할 수 있다.

 

# 마스터 노드 : NameNode, SecondaryNode

: 사용자의 데이터를 저장하고 사용자의 요청에 따라 사용자 데이터를 저장 및 복제하요 보관

# 잡 트래커 : NameNode와 함께 HDFS와 MapReduce를 하나의 서버에서 동작 가능, 하나의 마스터 노드에 네임노드와 잡 트래커를 함께 동작

# 슬레이브 노드 : DataNode

: 맵리듀스 구성

 # 태스크 트래커 : 여러 슬레이브 노드에서 동작, 데이터노드가 동작하는 슬레이브 노드에 태스크 트래커도 함께 실행

 

- 대량의 데이터를 빠르게 처리할 수 있도록 설계

- 저렴한 서버들 수백, 수천 대를 이용하여 구축 : 서버들의 고장이 발생하더라도 분산 파일 시스템이 아무런 문제없이 동작할 수 있도록 고장 방지 기능 구현

- HDFS는 한두 대의 서버로 구성하기 보다는 많은 서버를 이용하여 구축하는 것이 전체 성능이나 분산 파일 시스템의 전체 용량을 늘리는 데 유용 

- WORM(Write-Once-Read-Many)

: HDFS에 있는 데이터들은 수정이 불가능

- 파일을 열고 쓴 후 닫으면 더 이상 수정이 불가능하도록 설계.

 

 이러한 이유는 MapReduce 와 관련되어 있다. 맵리듀스를 작성하기 위한 파일 시스템은 수정 기능이 필요하지 않기 때문이다. 맵리듀스를 이용하여 분석할 파일들은 수정 기능이 필요 없다. 각각의 중간 결과 파일도 독립적으로 저장되기 때문에 수정 기능을 추가하지 않도록 설계되었기 때문이다.

 

- HDFS가 여러 개의 복제본을 관리하는데 전체 모델을 매우 간단하게 관리할 수 있음을 의미

: 파일 수정이 가능하도록 설계 -> 하나의 파일 수정 시 여러 데이터 노드에 저장되어 있는 특정 파일을 모두 수정

- 한 특정 파일을 한 바이트만 변경되는 경우에도 동일한 파일을 저장하고 있는 모든 데이터노드를 찾아 한 바이트씩 모두 수정해야 한다

 

이렇게 만든 이유는, 메타데이터를 관리하고 있는 네임노드와 사용자 데이터를 관리하고 있는 데이터노드 모두에 부담을 경감시키기 위함이다. 

 

HDFS의 전체 구조

클라이언트가 메타데이터 관련 명령을 네임노드에 전달 -> 사용자 데이터 읽기/쓰기를 위해 데이터노드에게 데이터 전달 -> 데이터 노드 간 데이터 복제, 상호 간 통신

 

NameNode

- 파일 시스템의 모든 메타데이터를 저장하고 사용자에게 전달

: HDFS는 메타데이터가 항상 네트워크를 통해 전달. -> 일반적인 파일 시스템의 메타데이터 성능을 기대하기 어렵기에, 하둡은 네트워크를 거치는 메타데이터를 메모리에 상주시킴으로써 사용자에게 조금 더 메타데이터를 전달할 수 있도록 설계

 

메타데이터 : 파일 시스템의 디렉터리 이름과 구조, 파일이름과 하나의 파일을 여러 블록으로 나눈 목록을 지칭하며, 이 블록들이 데이터노드에 저장되어 있는 정보들을 관리

 

- 데이터 노드들의 관리

: 현재 HDFS가 사용하고 있는 데이터노드의 목록과 동작이 가능한지 등을 지속적으로 알아내어 데이터 노드의 정보를 관리. 네임노드는 새롭게 업로드하는 블록이 어느 데이터노드에 저장되어야 하는지, 모든 데이터노드들이 동작하고 있어서고장 방지를 위한 복제 수를 만족하고 있는지를 지속적으로 알아낼 수 있음

 

 

 

DataNode

- 사용자의 데이터를 저장. 사용자의 파일은 블록 단위로 나누어 관리하도록 함

- HDFS의 기본 설정 : 하나의 블록을 3개의 데이터노드에 복제하여 저장.

블록들을 복제해 놓기 때문에 하나 또는 두 개의 데이터 노드가 동시에 문제가 발생하더라도 재 복제 과정을 통하여 안전하게 존재할 수 있도록 관리 -> 높은 수준의 고장 방지 기능 탑재

 

- 블록 : HDFS에서 데이터를 나누는 기준으로 사용. 블록 크기는 설정에 의해 변경될 수도 있으나 기본적으로 64MB로 설정

- 동일한 데이터를 여러 개의 노드에 동시 저장 : 블록들을 복제해 저장하기 때문에, 데이터ㄴㅗ드에 문제가 발생하더라도 재 복제  과정을 통해 안전하게 존재할 수 있도록 관리

 

SecondaryNode

"만약 모든 메타데이터를 메모리에 저장한 상태에서 네임노드에 문제가 생겨 다운되면?"

 -> 당연히 모든 디렉터리 구조 및 블록관련 정보를 잃어버리게 되고, 서비스도 지속할 수 없다.

 

- NameNode : 한 곳에서 고장이 발생하면 전체 시스템이 중단되는 단일 고장점 문제 보유

: HDFS는 메타데이터 관련 데이터들을 파일로 저장하여 네임노드에 문제가 발생해 다운되었을 경우 다시 빠르게 복구시킬 수 있도록 함 = Edits 파일과 FsImage

 

- 네임노드에 문제가 발생해 꺼져버린 경우 빠르게 복구하기 위해 세컨더리 네임노드를 이용해 제공

- 네임노드의 역할을 대신하는 게 아님

- 주기적으로 네임노드에 있는 Edits 파일을 가져오고 이 파일을 FsImage 파일에 병합

- 병합된 파일을 다시 네임노드로 전달 -> 이 과정에서 자신의 디렉터리에 Edits 파일과 FsImage 파일을 저장

- 데이터노드들이나 클라이언트들과는 전혀 통신하지 않고 오직 네임노드와 통신

 

[Edits 파일을 세컨더리 네임노드로 가져오는 조건]

1. Edits 파일을 마지막으로 가져온 후 일정 시간이 경과한 경우 세컨더리 네임노드로 가져옴

2. Edits 파일의 용량이 특정 임계치를 초과하면 세컨더리 네임노드로 가져온다

 

*기본설정 : Edits 파일을 마지막으로 가져온 후 1시간이 초과하면 세컨더리 네임노드로 가져오거나, 용량이 64MB를 초과하면 세컨더리 네임노드로 가져오도록 되어 있다.

 

오늘은 우선 하둡까지만 알아보기로 한다.

더 많은 툴들이 나와있지만, 차근차근 알아볼 예정이다.