Last Updated on 9월 13, 2021 by Jade(정현호)
1. HDFS
HDFS(Hadoop Distributed File System) 는 수십 테라 또는 페타바이트 이상의 대용량 파일을 분산된 서버에 저장하고, 많은 클라이언트가 저장된 데이터를 빠르게 처리할 수 있게 설계된 파일 시스템 입니다.
HDFS 와 기존의 대용량 파일시스템의 큰 차이점은 HDFS는 저사양 서버를 이용해 스토리지를 구성할 수 있다는 점 입니다. 기존의 대용량 파일시스템 또는 데이터베이스를 구성하려면 고성능의 서버나 대용량의 외장 스토리지가 필요 하였으며 이러한 시스템은 웹 서버 와 같은 서버에 비해 상당히 많은 비용이 발생되게 됩니다. 하지만 HDFS를 이용하면 수십 혹은 수백 대의 웹 서버급 서버나 저사양 서버를 묶어서 하나의 스토리지 처럼 사용 할 수 있게 됩니다.
이때 HDFS에 저장되는 데이터는 물리적으로 분신된 서버의 로컬 디스크에 저장되게 되고, 파일의 읽기 와 저장 같은 제어는 HDFS에서 제공되는 API 를 통해 처리 되게 됩니다. 모든 업무의 유형이 HDFS로 대체할 수 있는 것은 아니며 대규모 데이터 저장 이나 배치로 대규모 데이터의 처리를 하는 경우 HDFS 를 이용하면 유용하게 사용할 수 있습니다.
2. HDFS 설계 목표
HDFS는 아래와 같은 목표를 가지고 설계와 구현이 되어 있습니다.
1. 장애 복구
HDFS 를 구성하는 분산 서버에는 여러가지 다양한 장애가 발생 될 수 있습니다. 예를 들어 대표적으로 사용 중인 하드디스크의 문제가 발생하여서 데이터 저장 할 때 실패 할 수도 있고, 디스크 복구가 불가능 경우 데이터 유실이 되는 심각한 상황이 발생될 수 도 있습니다.
HDFS 는 장애를 빠른 시간에 감지하고,대처 할수 있도록 설계/구현 되어 있습니다. HDFS 에 데이터를 저장하면, 복제 데이터도 함께 저장되어 데이터 유실을 방지 합니다.
2. 스트리밍 방식의 데이터 접근
HDFS 는 클라이언트의 요청을 빠른시간 안에서 처리하는 것 보다 동일한 시간내에 더 많은 데이터를 처리하는 것을 목표로 하고 있습니다. HDFS 는 이를 위해서 랜덤 방식의 데이터 접근을 고려하고 있지 않습니다. 그래서 인터넷 뱅킹, 인터넷 쇼핑몰 과 같은 서비스에서 기존 파일 시스템 대신 HDFS 를 사용하는 것은 적합하지 않습니다.
HDFS 는 랜덤 접근 방식 대신 스트리밍 방식으로 데이터에 접근 되도록 설계/구현 되어 있습니다. 그래서 클라이언트는 끊김없이 연속된 흐름 데이터에 접근할 수 있습니다.
3. 대용량 데이터 저장
HDFS 는 하나의 파일이 기가바이트에서 테라바이트 또는 그 이상의 크기로 저장 할 수 있도록 설계되어 있습니다. 하나의 클러스터에서 수백 대의 노드를 지원할 수 있으며 하나의 인스턴스에서는 수백만개 이상의 파일 처리를 지원하고 있습니다.
4. 데이터 무결성
데이터베이스에서 데이터 무결성이란 저장되는 데이터의 일관성을 의미합니다. 즉 데이터의 입력 이나 변경등을 제한해 데이터의 안전성을 저해는 요소를 막는 것을 의미 합니다. HDFS 에서는 한 번 저장한 데이터는 더는 수정 할 수 없고, 읽기만 가능해서 데이터 무결성을 유지 하게 됩니다.
데이터의 수정은 불가능 하지만 파일 이동, 삭제, 복사 할 수 있는 인터페이스를 제공 하고 있으며 한번 기록된 데이터의 수정이 불가능한 부분은 하둡 2.0 알파 버전부터 저장된 파일에 append 는 가능하게 추가/개선 되었습니다.
3. 블록 구조 파일 시스템
HDFS 는 블록 구조의 파일시스템 입니다.
HDFS 에 저장하는 파일은 특정 크기의 블록으로 나눠져 분산된 서버에 저장 됩니다. 블록 크기는 기본적으로 64MB로 설정돼 있으며, 하둡 환경설정 파일이나 다른 방법으로 변경이 가능 합니다. 여러 개의 블록은 동일한 서버에 저장하기 때문에 로컬 서버의 하드디스크보다 큰 규모의 데이터를 저장 할 수 있으며 저장할 수 있는 용량을 수십 GB,TB,PB 까지 확대가 가능 하게 됩니다.
3-1 블록의 사이즈 64MB
HDFS의 기본 블록의 사이즈가 64MB 로 디스크의 블록 사이즈나 파일시스템 또는 데이터베이스 블록 사이즈 보다 큰 이유는 여러가지가 있습니다.( 64MB 는 하둡 1 버전 기준 입니다 )
• Disk Seek Time 감소
디스크의 탐색 시간은 데이터의 위치를 찾는 데 걸리는 시간인 시크 타임 과 원하는 데이터의 섹터에 도달하는 데 걸리는 시간인 서치 타임(Search time) 의 합 입니다. 하둡의 개발 시절 일반적인 디스크의 시크 타임은 10ms, 디스크 전송 대역폭은 100MB/s 였습니다. HDFS 는 시크 타임이 디스크 전송 대역폭의 1%만 사용하는 데 목표를 두었고 그래서 100MB 에 근접한 64MB를 사용하게(기본값으로) 된 것이며 하둡 2.0 버전 부터는 기본 블록 크기는 128MB 로 증가되었습니다.
이와 같이 일반적인 파일시스템이나 Database의 블록 사이즈에 비해 큰 용량을 사용하는 이유는 블록이 커짐에 따라 탐색 비용을 최소화 할 수 있으며 디스크에서 블록 시작점을 탐색하는데 걸리는 시간을 줄일 수 있게 되며 데이터를 전송하는데 더 많은 시간을 할애 할 수 있게 됩니다.
• 네임노드의 메타데이터 크기 감소
네임노드는 블록 위치, 파일명, 디렉토리 구조, 권한 정보와 같은 메타데이터 정보를 메모리에 저장하고 관리하게 됩니다. 예를 들어 100MB 크기의 파일을 저장할 경우 HDFS는 두 블록에 해당 하는 메타데이터만 저장하면 되게 됩니다. 하지만 일반적인 OS의 파일 시스템 블록 사이즈인 4k~8k 단위를 사용하게 된다면 동일한 크기의 파일을 저장할 경우 훨씬 더 많은 메타데이터가 생성이 되게 됩니다.
블록 개수는 네임노드에 할당된 힙 메모리의 크기에 영향을 받게 되며 약 100만개의 블록을 저장할 경우 힙 메모리는 약 1GB 정도 필요 할 수 있게 됩니다.
• 클라이언트와 네임노드 통신 감소
클라이언트가 HDFS에 저장된 파일을 접근 할 때 네임노드에서 해당 파일을 구성하는 블록의 위치를 조회하게 되며 블록이 커서 블록수가 작아진다면 접근 횟수가 감소하게 됩니다.
3-2 블록 단위 파일 저장
HDFS는 블록 단위로 파일을 나누어서 저장을 하게 되고 파일 하나의 크기가 단일 디스크의 크기보다 크더라도 저장할 수 있게 됩니다.
[HDFS 파일 블록 저장 구조]
위의 그림은 64MB로 설정된 블록에 200MB 파일을 저장할 때 이며 블록 단위로 나누어서 저장되게 되고 64MB 3개와 8 MB 1개, 총 4개의 블록에 나눠서 저장되게 됩니다.
그리고 HDFS 에서는 블록 저장시 기본적으로 3개씩 블록의 복제본을 생성하여 저장 하게 됩니다. 블록이 복제되어 있기 때문에 특정 서버의 디스크에서 문제가 발생 되더라도 복제된 블록을 이용해서 데이터를 계속 조회 할 수 있게 됩니다. 복제본의 수도 하둡 환경 설정에서 변경 할 수 있습니다.
위에서 저장된 모습처럼 기본 블록 사이즈(하둡1에서는 기본 64MB, 하둡2에서는 기본 128MB) 보다 작은 파일도 저장 할 수 있으며 크기가 작은 파일이더라도 64MB 크기를 모두 사용하는 것이 아니라 크기에 맞게 블록이 저장되게 됩니다. 예를 들어 1MB 크기의 파일을 저장한다면 1MB 디스크의 용량만 사용하게 됩니다.
4. 네임노드와 데이터노드
HDFS 는 마스터-슬레이브 구조이며 마스터 서버는 네임노드(NameNode)이며, 슬레이브 서버는 데이터노드(DataNode) 입니다. 
[HDFS 아키텍처]
4-1. 네임노드
HDFS의 마스터 서버인 네임노드는 아래와 같은 기능을 수행하게 됩니다.
4-1-1 메타데이터 관리
네임노드는 파일 시스템을 유지하기 위한 메타데이터를 관리하게 되고 메타데이터에는 파일 시스템 이미지(파일명, 디렉토리, 크기, 권한) 와 파일에 대한 블록 매핑 정보로 구성되게 됩니다. 클라이언트에게 빠른 응답을 할 수 있도록 전체 메타데이터는 메모리에서 저장되어 로딩해서 관리 됩니다.
4-1-2 데이터노드 모니터링
데이터노드는 네임노드에게 3초마다 하트비트(Heartbeat) 메세지를 전송하고, 하트비트는 데이터노드 상태 정보 와 데이터노드에 저장되어 있는 블록의 목록(blockreport)으로 구성되어 있습니다. 네임노드는 하트비트를 이용해 데이터 노드의 실행 상태와 용량을 모니터링 하며, 일정 기간 동안 하트비트를 전송하지 않은 데이터노드가 감지가 될 경우 장애가 발생한 서버로 판단 하게 됩니다.
4-1-3 블록 관리
네임노드는 다양한 방법으로 블록을 관리하게 되며 네임노드는 장애가 발생한 데이터노드를 발견하면 해당 데이터노드의 블록을 새로운 데이터노드로 복제 합니다. 또한 용량이 부족한 데이터노드가 있다면 용량에 여유가 있는 데이터노드로 블록을 이동시킵니다. 마지막으로 네임노드는 블록의 복제본 수도 관리하게 되며 복제본 수가 일치 하지 않는 블록이 발견될 경우 축로 블록을 복제하거나 삭제하게 됩니다.
4-1-4 클라이언트 요청 접수
클라이언트가 HDFS에 접근하려면 반드시 네임노드에 먼저 접속 해야만하며 HDFS에 파일을 저장하는 경우 기존 파일의 저장 여부와 권한 확인의 절차를 거쳐서 저장을 승인하게 됩니다. 또한 HDFS에 저장된 파일을 조회하는 경우 블록의 위치 정보를 반환 합니다.
4-2. 데이터노드
데이터노드는 클라이언트가 HDFS에 저장하는 파일을 로컬디스크에 유지하며 로컬 디스크에 저장되는 파일은 두 종류로 구성이 되게 됩니다
첫번째 파일은 실제 데이터가 저장되어 있는 로우 데이터이며, 두 번째 파일은 체크섬이나 파일 생성 일자 와 같은 메타 데이터가 설정되어 있는 파일 입니다.
다음 포스팅에서 계속 됩니다.
※ Ref : 시작하세요! 하둡 프로그래밍(개정 2판) 책의 내용을 정리한 포스팅 입니다
이전 글
Principal DBA(MySQL, AWS Aurora, Oracle)
핀테크 서비스인 핀다에서 데이터베이스를 운영하고 있어요(at finda.co.kr)
Previous - 당근마켓, 위메프, Oracle Korea ACS / Fedora Kor UserGroup 운영중
Database 외에도 NoSQL , Linux , Python, Cloud, Http/PHP CGI 등에도 관심이 있습니다
purityboy83@gmail.com / admin@hoing.io
