2020.10.20

데이터베이스 백업을 이해하는 넓고 얇은 기초 상식 모음

W. Curtis Preston | Network World
데이터베이스, 또는 구조적 데이터는 모든 데이터센터의 필수 요소다. 일반적으로 데이터센터에 저장하는 테라바이트 단위의 데이터 중 데이터베이스에 저장되는 비율은 높지 않지만, 그중에서 핵심 데이터의 비중은 높다. 데이터베이스를 백업하려면 데이터베이스의 고유한 구조와 작동 방식을 파악하는 것이 중요하다.
 
© Getty Images Bank

구조적 데이터를 비구조적 데이터처럼 백업해선 안 되는 이유는 3가지다. 첫째, 일반적으로 데이터베이스는 데이터 파일에 저장되고, 데이터 파일은 어떤 작업으로 인해 데이터베이스가 업데이트되는 한 끊임없이 변경된다. 따라서 다른 파일처럼 단순히 백업할 수 없다. 둘째, 대부분의 데이터베이스에는 특정 시점 복원 후 트랜잭션을 복원하거나 작동 중단 이후 부분적으로 완료된 트랜잭션을 롤백하기 위해 재생이 가능한 일종의 저널이 있다.

셋째, 일반적인 복원은 데이터파일을 최근 백업에서 복원하는 것으로 시작해 그다음 데이터베이스를 최대한 최근 상태로 복원하기 위해 저널에서 복원하는 단계로 진행된다. 대부분의 백업 시스템에서 일반적인, 한 단계로 구성된 복원으로 실현되는 복구 지점 목표(RPO)는 24시간 이상일 수도 있는데, 이는 핵심 데이터베이스에 사용하기에는 충분하지 않다. 결국 데이터베이스를 제대로 백업하기 위해서는 사용 중인 데이터베이스가 이 3가지 과제에 어떻게 대처하는지를 이해해야 한다.
 

데이터베이스 모델

현재 기업 환경에 쓰이는 데이터베이스는 13개 이상이다. 사용 중인 데이터베이스를 백업하는 방법을 알기 위해서는 먼저 어떤 종류의 데이터베이스를 백업하는지를 알아야 한다. 데이터베이스 모델에는 관계형(가장 일반적), 키-값, 시계열, 문서, 그래프, 검색 엔진, 와이드 칼럼, 객체 지향, RDF, 다중 값, 네이티브 XML, 탐색형, 이벤트가 포함된다. 가장 많이 사용되는 모델, 그리고 그중에서 백업에 대한 질문이 가장 많은 데이터베이스는 다음과 같다.
 
  • 관계형: 데이터베이스라고 하면 대부분의 사람이 관계형 데이터베이스 관리 시스템(RDBMS)을 떠올린다. RDBMS는 일련의 테이블과 정해진 스키마(테이블 레이아웃), 레코드(행), 속성(값)으로 구성된다. 오라클, SQL 서버, 마이SQL, 포스트그리SQL이 여기에 속한다. 사용하는 쿼리 언어를 따서 흔히 SQL 데이터베이스라고 한다.
  •  
  • 키-값: 매우 간단한 NoSQL(Not only SQL) DBMS로, 키와 값으로 구성되며 키를 알면 값을 조회할 수 있다. 대표적인 예로 레디스(Redis)와 다이나모DB(DynamoDB)가 있다.
  •  
  • 시계열: NoSQL 데이터베이스는 시간 데이터를 처리하도록 설계됐다. 각 항목에는 시간 스탬프가 있다. 인기 있는 프로메테우스(Prometheus) 데이터베이스가 시계열의 예로, 쿠버네티스에서 많이 사용된다.
  •  
  • 문서: 스키마가 없는 NoSQL DBMS는 문서 저장용으로 만들어졌다. 레코드는 균일한 표준을 준수할 필요가 없고 다양한 유형의 데이터를 저장할 수 있다. JSON은 이러한 데이터베이스에서 문서를 저장하는 데 자주 사용된다. 몽고DB(MongoDB)는 문서 모델만 지원하는 데이터베이스 중에서 가장 많이 사용된다.
  •  
  • 와이드 칼럼: 역시 스키마 없는 NoSQL DBMS로, 사전 정의된 스키마 없이 매우 많은 수의 데이터 열을 저장할 수 있는 모델이 와이드 칼럼 모델이다. 데이터베이스 전역에 열 이름과 키를 정의할 수 있다. 와이드 칼럼 데이터베이스 중에서는 카산드라(Cassandra)가 가장 유명하다.
 

데이터베이스 용어

데이터베이스 용어 역시 중요하다. 다음은 중요한 언어 목록이다. 데이터베이스마다 사용하는 용어가 조금씩 다르지만 같은 것을 의미하는 용어는 대체로 서로 비슷하다. 단, NoSQL 데이터베이스에는 전혀 다른 용어가 많고, 아래 용어와 비슷한 의미의 용어가 없는 경우도 있다.
 
  • 데이터파일: 데이터파일은 데이터베이스가 데이터를 저장하는 곳이다. 원시 디바이스(예를 들어 리눅스의 경우 /dev/hda1), 또는 “쿠킹된(cooked)” 파일(예를 들어 /sap/datafiles/dbs06.dbf 또는 c:\MySQL\datafile.dbf)일 수 있다. 현재 대부분의 데이터베이스는 쿠킹된 파일 또는 일반 파일을 데이터파일로 사용하며 대체로 데이터베이스마다 2개 이상이 있다.
  •  
  • 테이블: 약간 혼란스러운 부분이다. SQL, 관계형 데이터베이스에서 테이블은 일종의 가상 스프레드시트처럼 작동하는 관련된 값 모음이다. NoSQL 데이터베이스에는 이와 비슷한 테이블이 있을 수도, 없을 수도 있다.
  •  
  • 테이블스페이스: 테이블스페이스는 테이블을 넣는 공간이며 하나 이상의 데이터파일 모음이다. 데이터베이스에 테이블이 없으면 테이블스페이스도 없을 수 있다.
  •  
  • 파티션: 현대 데이터베이스는 여러 테이블스페이스를 비롯해 여러 리소스에 걸쳐 테이블을 쪼개 분산하거나 파티션으로 나눌 수 있다.
  •  
  • 샤딩: 샤딩은 파티션 분할을 한 단계 높인 것으로, 대규모 수평 확장 데이터베이스에서 중요하다. 샤딩은 테이블의 여러 조각(샤드)을 서로 다른 노드에 배치할 수도 있다.
  •  
  • 마스터 데이터베이스: 마스터 데이터베이스는 모든 데이터베이스와 데이터파일의 상태를 추적한다. 여러 데이터베이스가 허용되는 경우 각 데이터베이스도 추적해야 한다.
  •  
  • 트랜잭션: 트랜잭션은 데이터베이스 내의 활동으로, 하나 이상의 테이블에 있는 하나 이상의 속성을 변경한다. 단순한 트랜잭션은 하나의 속성을 바꾸고, 복잡한 트랜잭션은 한 번의 작업으로 다수의 속성을 변경한다. NoSQL 데이터베이스는 간단한 트랜잭션을 사용하는 경향이 있는데, 많은 NoSQL 사용자는 트랜잭션이 결코 간단하다고 생각하지 않는다.
  •  
  • 트랜잭션 로그: 트랜잭션 로그는 각 트랜잭션과 트랜잭션이 변경하는 요소를 기록한다. 이 정보는 시스템 충돌 시, 또는 실행 취소나 다시 실행 트랜잭션으로 복원한 후에 사용된다.
 

일관성 모델

삽입되거나 업데이트된 데이터베이스 데이터가 모든 데이터베이스 뷰어에 동일하도록 보장하는 방법은 2가지인데, 서로 매우 다르다. 이를 가리켜 일관성 모델이라고 하며 일관성 모델은 백업과 복구에 영향을 미친다. 첫 번째는 즉각적 일관성으로, 강한 일관성이라고도 하며 모든 사용자가 데이터를 보는 장소 또는 방법과 관계없이 동시에 동일한 데이터를 보도록 보장한다. 가장 전통적인 관계형 데이터베이스는 이 모델에 따른다.

두 번째 모델은 결과적 일관성 또는 약한 일관성 데이터베이스로, 특정 속성이 모든 뷰어에 결과적으로 일관적으로 되도록 보장하지만 그렇게 되기까지 다소 시간이 걸릴 수 있다. 결과적 일관성의 대표적인 예는 DNS 시스템에서 볼 수 있다. DNS 시스템은 DNS 레코드의 라이브 시간(time-to-live)이 만료될 때까지 기다렸다가 도메인 이름에 대한 정보를 업데이트한다. 여기에 최대 72시간이 소요될 수 있다.
 

무엇을, 어떻게, 왜 백업하는가

데이터베이스 백업 실무자라면 데이터베이스가 어떻게 구축되고 어떻게 작동하는지를 이해해야 한다. 데이터베이스가 데이터베이스를 저장하는 위치(예를 들어 데이터파일), 복잡한 트랜잭션을 사용하는지 간단한 트랜잭션을 사용하는지 여부, 그리고 트랜잭션의 로그를 저장하는 위치를 파악해야 한다. 저장된 데이터와 트랜잭션 로그의 일관적인 백업을 확보하는 방법을 알아야 한다.

그 외에 데이터베이스가 어떻게 분산되어 있는지도 알아야 한다. 파티션으로 분할되어 하나의 호스트에 있는가? 또는 샤딩되어 수십, 수백 개의 호스트에 흩어져 있는가? 후자라면 대부분 결과적 일관성 데이터베이스일 것이다. 수백 개의 노드에 분산된 데이터베이스의 일관적인 스냅샷을 얻는 과정은 상당히 까다롭고, 복원하기 역시 마찬가지로 어렵다.

다수의 노드에 걸쳐 복제를 사용하는 결과적 일관성 데이터베이스는 백업할 필요가 없다고 생각할 수 있지만 백업은 절대적으로 필요하다. 노드 장애에 대해서는 보호가 되지만 사람의 실수에 대해서는 보호되지 않기 때문이다. 테이블을 삭제한 경우 복제 방법과 관계없이 복원해야 한다. editor@itworld.co.kr


2020.10.20

데이터베이스 백업을 이해하는 넓고 얇은 기초 상식 모음

W. Curtis Preston | Network World
데이터베이스, 또는 구조적 데이터는 모든 데이터센터의 필수 요소다. 일반적으로 데이터센터에 저장하는 테라바이트 단위의 데이터 중 데이터베이스에 저장되는 비율은 높지 않지만, 그중에서 핵심 데이터의 비중은 높다. 데이터베이스를 백업하려면 데이터베이스의 고유한 구조와 작동 방식을 파악하는 것이 중요하다.
 
© Getty Images Bank

구조적 데이터를 비구조적 데이터처럼 백업해선 안 되는 이유는 3가지다. 첫째, 일반적으로 데이터베이스는 데이터 파일에 저장되고, 데이터 파일은 어떤 작업으로 인해 데이터베이스가 업데이트되는 한 끊임없이 변경된다. 따라서 다른 파일처럼 단순히 백업할 수 없다. 둘째, 대부분의 데이터베이스에는 특정 시점 복원 후 트랜잭션을 복원하거나 작동 중단 이후 부분적으로 완료된 트랜잭션을 롤백하기 위해 재생이 가능한 일종의 저널이 있다.

셋째, 일반적인 복원은 데이터파일을 최근 백업에서 복원하는 것으로 시작해 그다음 데이터베이스를 최대한 최근 상태로 복원하기 위해 저널에서 복원하는 단계로 진행된다. 대부분의 백업 시스템에서 일반적인, 한 단계로 구성된 복원으로 실현되는 복구 지점 목표(RPO)는 24시간 이상일 수도 있는데, 이는 핵심 데이터베이스에 사용하기에는 충분하지 않다. 결국 데이터베이스를 제대로 백업하기 위해서는 사용 중인 데이터베이스가 이 3가지 과제에 어떻게 대처하는지를 이해해야 한다.
 

데이터베이스 모델

현재 기업 환경에 쓰이는 데이터베이스는 13개 이상이다. 사용 중인 데이터베이스를 백업하는 방법을 알기 위해서는 먼저 어떤 종류의 데이터베이스를 백업하는지를 알아야 한다. 데이터베이스 모델에는 관계형(가장 일반적), 키-값, 시계열, 문서, 그래프, 검색 엔진, 와이드 칼럼, 객체 지향, RDF, 다중 값, 네이티브 XML, 탐색형, 이벤트가 포함된다. 가장 많이 사용되는 모델, 그리고 그중에서 백업에 대한 질문이 가장 많은 데이터베이스는 다음과 같다.
 
  • 관계형: 데이터베이스라고 하면 대부분의 사람이 관계형 데이터베이스 관리 시스템(RDBMS)을 떠올린다. RDBMS는 일련의 테이블과 정해진 스키마(테이블 레이아웃), 레코드(행), 속성(값)으로 구성된다. 오라클, SQL 서버, 마이SQL, 포스트그리SQL이 여기에 속한다. 사용하는 쿼리 언어를 따서 흔히 SQL 데이터베이스라고 한다.
  •  
  • 키-값: 매우 간단한 NoSQL(Not only SQL) DBMS로, 키와 값으로 구성되며 키를 알면 값을 조회할 수 있다. 대표적인 예로 레디스(Redis)와 다이나모DB(DynamoDB)가 있다.
  •  
  • 시계열: NoSQL 데이터베이스는 시간 데이터를 처리하도록 설계됐다. 각 항목에는 시간 스탬프가 있다. 인기 있는 프로메테우스(Prometheus) 데이터베이스가 시계열의 예로, 쿠버네티스에서 많이 사용된다.
  •  
  • 문서: 스키마가 없는 NoSQL DBMS는 문서 저장용으로 만들어졌다. 레코드는 균일한 표준을 준수할 필요가 없고 다양한 유형의 데이터를 저장할 수 있다. JSON은 이러한 데이터베이스에서 문서를 저장하는 데 자주 사용된다. 몽고DB(MongoDB)는 문서 모델만 지원하는 데이터베이스 중에서 가장 많이 사용된다.
  •  
  • 와이드 칼럼: 역시 스키마 없는 NoSQL DBMS로, 사전 정의된 스키마 없이 매우 많은 수의 데이터 열을 저장할 수 있는 모델이 와이드 칼럼 모델이다. 데이터베이스 전역에 열 이름과 키를 정의할 수 있다. 와이드 칼럼 데이터베이스 중에서는 카산드라(Cassandra)가 가장 유명하다.
 

데이터베이스 용어

데이터베이스 용어 역시 중요하다. 다음은 중요한 언어 목록이다. 데이터베이스마다 사용하는 용어가 조금씩 다르지만 같은 것을 의미하는 용어는 대체로 서로 비슷하다. 단, NoSQL 데이터베이스에는 전혀 다른 용어가 많고, 아래 용어와 비슷한 의미의 용어가 없는 경우도 있다.
 
  • 데이터파일: 데이터파일은 데이터베이스가 데이터를 저장하는 곳이다. 원시 디바이스(예를 들어 리눅스의 경우 /dev/hda1), 또는 “쿠킹된(cooked)” 파일(예를 들어 /sap/datafiles/dbs06.dbf 또는 c:\MySQL\datafile.dbf)일 수 있다. 현재 대부분의 데이터베이스는 쿠킹된 파일 또는 일반 파일을 데이터파일로 사용하며 대체로 데이터베이스마다 2개 이상이 있다.
  •  
  • 테이블: 약간 혼란스러운 부분이다. SQL, 관계형 데이터베이스에서 테이블은 일종의 가상 스프레드시트처럼 작동하는 관련된 값 모음이다. NoSQL 데이터베이스에는 이와 비슷한 테이블이 있을 수도, 없을 수도 있다.
  •  
  • 테이블스페이스: 테이블스페이스는 테이블을 넣는 공간이며 하나 이상의 데이터파일 모음이다. 데이터베이스에 테이블이 없으면 테이블스페이스도 없을 수 있다.
  •  
  • 파티션: 현대 데이터베이스는 여러 테이블스페이스를 비롯해 여러 리소스에 걸쳐 테이블을 쪼개 분산하거나 파티션으로 나눌 수 있다.
  •  
  • 샤딩: 샤딩은 파티션 분할을 한 단계 높인 것으로, 대규모 수평 확장 데이터베이스에서 중요하다. 샤딩은 테이블의 여러 조각(샤드)을 서로 다른 노드에 배치할 수도 있다.
  •  
  • 마스터 데이터베이스: 마스터 데이터베이스는 모든 데이터베이스와 데이터파일의 상태를 추적한다. 여러 데이터베이스가 허용되는 경우 각 데이터베이스도 추적해야 한다.
  •  
  • 트랜잭션: 트랜잭션은 데이터베이스 내의 활동으로, 하나 이상의 테이블에 있는 하나 이상의 속성을 변경한다. 단순한 트랜잭션은 하나의 속성을 바꾸고, 복잡한 트랜잭션은 한 번의 작업으로 다수의 속성을 변경한다. NoSQL 데이터베이스는 간단한 트랜잭션을 사용하는 경향이 있는데, 많은 NoSQL 사용자는 트랜잭션이 결코 간단하다고 생각하지 않는다.
  •  
  • 트랜잭션 로그: 트랜잭션 로그는 각 트랜잭션과 트랜잭션이 변경하는 요소를 기록한다. 이 정보는 시스템 충돌 시, 또는 실행 취소나 다시 실행 트랜잭션으로 복원한 후에 사용된다.
 

일관성 모델

삽입되거나 업데이트된 데이터베이스 데이터가 모든 데이터베이스 뷰어에 동일하도록 보장하는 방법은 2가지인데, 서로 매우 다르다. 이를 가리켜 일관성 모델이라고 하며 일관성 모델은 백업과 복구에 영향을 미친다. 첫 번째는 즉각적 일관성으로, 강한 일관성이라고도 하며 모든 사용자가 데이터를 보는 장소 또는 방법과 관계없이 동시에 동일한 데이터를 보도록 보장한다. 가장 전통적인 관계형 데이터베이스는 이 모델에 따른다.

두 번째 모델은 결과적 일관성 또는 약한 일관성 데이터베이스로, 특정 속성이 모든 뷰어에 결과적으로 일관적으로 되도록 보장하지만 그렇게 되기까지 다소 시간이 걸릴 수 있다. 결과적 일관성의 대표적인 예는 DNS 시스템에서 볼 수 있다. DNS 시스템은 DNS 레코드의 라이브 시간(time-to-live)이 만료될 때까지 기다렸다가 도메인 이름에 대한 정보를 업데이트한다. 여기에 최대 72시간이 소요될 수 있다.
 

무엇을, 어떻게, 왜 백업하는가

데이터베이스 백업 실무자라면 데이터베이스가 어떻게 구축되고 어떻게 작동하는지를 이해해야 한다. 데이터베이스가 데이터베이스를 저장하는 위치(예를 들어 데이터파일), 복잡한 트랜잭션을 사용하는지 간단한 트랜잭션을 사용하는지 여부, 그리고 트랜잭션의 로그를 저장하는 위치를 파악해야 한다. 저장된 데이터와 트랜잭션 로그의 일관적인 백업을 확보하는 방법을 알아야 한다.

그 외에 데이터베이스가 어떻게 분산되어 있는지도 알아야 한다. 파티션으로 분할되어 하나의 호스트에 있는가? 또는 샤딩되어 수십, 수백 개의 호스트에 흩어져 있는가? 후자라면 대부분 결과적 일관성 데이터베이스일 것이다. 수백 개의 노드에 분산된 데이터베이스의 일관적인 스냅샷을 얻는 과정은 상당히 까다롭고, 복원하기 역시 마찬가지로 어렵다.

다수의 노드에 걸쳐 복제를 사용하는 결과적 일관성 데이터베이스는 백업할 필요가 없다고 생각할 수 있지만 백업은 절대적으로 필요하다. 노드 장애에 대해서는 보호가 되지만 사람의 실수에 대해서는 보호되지 않기 때문이다. 테이블을 삭제한 경우 복제 방법과 관계없이 복원해야 한다. editor@itworld.co.kr


X