Journal Archive

데이터 보호(Data protection)는 회사, 기업 등에서 특정 시점의 데이터를 필요로 할 때 항상 데이터를 사용할 수 있도록 보장하는 행위를 말한다[1]. 데이터 손실에는 다양한 원인이 있다. 스토리지 장애, 스토리지 및 서버의 네트워크 장애, 정전 등과 같은 물리적 장애로 인한 데이터 손실이 있을 수 있다. 또한, 데이터베이스 테이블 또는 레코드 삭제, 서비스 디렉터리 삭제, 데이터 덮어쓰기 등과 같이 시스템 운영자나 사용자의 조작 실수로 데이터의 손실이 발생할 수 있다. 데이터 손실은 서비스를 지속하지 못하는 중요한 원인이 된다. 서비스를 지속하지 못하게 되면 손실된 데이터를 복구하여 서비스를 지속하도록 해야 한다. 복구 시에는 사용자가 요구하는 시점의 데이터에 대한 복구는 물론 복구 완료 및 가능 시간을 같이 고려해야 한다.

백업[1], 스냅샷(Snapshot)[2], CDP(Continuous Data Protection)[2]등과 같은 다양한 데이터 보호 및 복구 기술들이 존재한다. 백업은 서비스 장치의 데이터를 다른 장치로 주기적으로 복사하는 것을 말한다. 이후 서비스 장치에서 장애가 발생하면 다른 장치에 복사해놓은 데이터를 다시 복사하여 복구한다[3]. 스냅샷은 보호하려는 데이터의 특정 시점 이미지를 보관하고 추후 해당 시점으로 데이터를 복구하는 방식이다[4]. CDP는 보호하려는 데이터의 모든 변경 내용을 원본 데이터와는 독립적으로 저장하고 임의 시점의 데이터 복구를 가능하게 하는 기술이다[2]. CDP는 주기적 백업이나 스냅샷과는 달리 RPO(Recovery Point Objective)와 RTO(Recovery Time Objective)에 제한이 없는 장점이 있다. 하지만, 모든 데이터 변경 분을 저장해야 하므로 시스템에 가해지는 부하가 상대적으로 큰 편이다.

CDP의 부하를 줄이기 위한 다수의 연구가 진행되었으며 기존 CDP 방법들은 크게 파일 시스템 수준, 응용 수준, 블록 수준으로 구분해 볼 수 있다. 기존 응용 수준 및 파일 시스템 수준의 CDP들의 복원 시점까지의 기록한 모든 변경 데이터의 로그를 롤백(Roll Back)시키는 방식으로 복원한다. 이 때문에 복구 시간이 블록 수준의 CDP보다 길어지는 문제점이 있다. 블록 수준의 CDP는 응용 및 파일 시스템 수준의 CDP보다 메타데이터 및 변경 데이터를 복원하고 관리하는데 상대적으로 용이하다. 하지만 파일시스템 버퍼 캐시에 대한 플러시 연산이 실행 후에만 일관되게 데이터 변경 분을 저장 할 수 있다는 문제점이 있다.

이 논문에서는 CDP에서 효과적인 데이터 복구 방법을 제안한다. 제안하는 복구 방법은 기존에 제안된 파일 시스템 수준의 CDP 방법[3]을 기반으로 하며 사용자 요청을 기반으로 점진적 복구가 가능하여 복구하려는 데이터에 대한 즉각적인 접근(Instant access)를 보장한다. 또한, 제안하는 복구 방법은 사용자에게 CDP 시스템에 대한 투명성을 제공한다. 즉, 사용자는 CDP를 통해서 복구하는 데이터가 자신의 로컬 스토리지의 파일이나 디렉터리로 인식하고 접근할 수 있도록 한다.

이 논문에서는 제안하는 복구 방법을 실제로 구현하여 성능 검증을 수행한다. 리눅스 운영체제의 사용자 영역과 커널 영역에 걸쳐 제안하는 복구 방법을 구현하고, 다양한 측면에서 제안하는 방법의 성능을 분석한다.

CDP는 원본 데이터의 변화를 추적하여 원본 데이터와는 독립적인 형태로 데이터의 변경 분을 저장해서 과거에 모든 지점에서의 복원을 가능하게 하는 데이터 보호 방법이다. CDP는 블록 수준, 파일 시스템 수준, 응용 수준에서 구현될 수 있다[4]. 어떤 수준에서 구현된 CDP라도 일반적으로 다음과 같은 절차에 의해 데이터 보호를 수행한다.

첫 번째로 데이터의 변경을 연속적으로 캡처하여 기록한다. 두 번째로 모든 데이터의 변경 사항은 별도의 위치에 저장한다. 마지막으로 데이터는 임의의 시점으로 복구하며 복구 전에 복구 시점을 미리 정의하지 않는다.

2.4 가상 파일 시스템 수준의 CDP[3]

이 방법은 기존의 파일시스템 수준의 CDP와는 다르게 가상 파일 시스템의 시스템 호출(System call)을 캡처하여 데이터 변경을 별도의 저장소(CDP pool)에 기록한다.

저장한 변경 로그를 빠르게 찾기 위해 2단계 비트맵 색인 방법을 제안하였다. 이 방법은 파일시스템에 종속적이지 않고 별도의 응용프로그램을 설치하지 않아도 된다. 변경을 캡처하는 기능은 리눅스 커널의 가상 파일 시스템에 구현된다.

그림 1은 [3]에서 제안하는 2단계 비트맵 색인이다. 이 방법에서는 파일을 일정 크기의 청크 단위로 나누고 청크별로 로그 레코드들을 관리한다. 또한, 주기적으로 체크포인팅을 수행하여 로그 레코드들의 메타데이터를 병합하여 가상 스냅샷을 생성한다. 2계층 비트맵 색인은 체크포인트 주기 사이에 로그 레코드들의 메타데이터를 시간과 청크 번호에 따라 빠르게 검색하여 빠르게 복구에 필요한 로그 레코드들을 찾을 수 있도록 한다.

Fig. 1. 
2 Level bitmap index

이 논문에서 제안하는 CDP 복구 방법은 [3]에서 제안하는 CDP 방법을 기반으로 한다. [3]는 캡처한 변경 로그 레코드들을 효과적으로 저장하고 색인하는 방법을 제안하고 있지만, 복구를 위해서는 해당 시점의 모든 메타데이터와 로그데이터를 복원해야 접근이 가능하다. 이 논문에서는 [5]에서 제안하는 방법과 연계하여 사용자 요청에 따라 점진적으로 데이터를 복구하는 방법을 제안한다.

그림 2는 제안 하는 방법에 전체 구조를 나타낸다. 제안하는 CDP 복구 방법은 CDP 클라이언트, Log Manager, Restore Manager, Log Sender, Restore Communicator, CDP pool Manger, CDP pool로 구성된다. CDP 서버는 프로덕션(Production) 서버에서 캡처한 로그 레코드와 그에 대한 메타데이터들을 수신하여 CDP pool에 저장하는 서버이다. 프로덕션 서버는 실제 서비스가 제공되는 서버이며 보호 대상 소스 디렉터리가 위치한다.

Fig. 2. 
Overall architecture of proposed CDP recovery system

CDP 클라이언트는 사용자의 복구 요청을 처리하는 인터페이스 기능을 수행한다. 사용자는 CDP 클라이언트를 통해 CDP 프로덕션 서버에 보호할 대상(Source_DIR)을 설정하고 복구된 데이터가 저장될(CDP_DIR)을 지정한다. 또한, CDP 서버에 Source_DIR에 대응하는 CDP Pool 생성 및 삭제를 수행한다.

Restore Manager는 CDP 클라이언트로부터 복구 시작 요청을 받게 되면, 복구 시점에 해당하는 디렉터리에 대한 메타데이터를 CDP 서버에 요청한다. 수신한 디렉터리 메타데이터를 기초로 CDP_DIR의 하위 디렉터리 및 파일에 대한 읽기 시스템 호출을 커널에서 가로챈다. 복구 전에 CDP_DIR에는 아무런 데이터도 없으므로 가로챈 시스템 호출에 대한 처리를 원격의 CDP 서버에 요청한다. Restore Manager는 CDP 서버가 처리한 시스템 호출 결과를 CDP_DIR에 반영하고 결과를 사용자에게 반환한다. 이상의 복구과정은 아래에서 다시 자세하게 설명한다. Restore Communicator는 프로덕션 서버가 복구를 수행하기 위해 CDP 서버로부터 시스템 호출 처리 결과를 수신하는 통신 기능을 수행한다. Log Sender는 보호 대상인 Source_DIR애 대한 시스템 호출을 캡처하여 생성한 변경 로그 레코드를 CDP 서버에 전송하기 위한 통신 모듈이다.

제안하는 CDP 복구과정은 다음의 3단계를 거쳐서 진행된다. 첫 번째 단계에서는 사용자가 복구 요청을 하면 CDP 서버로부터 사용자가 요청한 시점에 해당하는 디렉터리의 메타데이터를 가져온다. 메타데이터는 기본적으로 디렉터리의 구조와 각 디렉터리에 해당하는 파일들에 대한 메타데이터를 말한다.

두 번째 단계에서는 해당 메타데이터를 기반으로 사용자 요청에 따라 해당 디렉터리 및 파일을 CDP_DIR에 생성한다. 파일의 경우 최초에는 비어있는 파일을 생성한다. 모든 메타데이터에 해당하는 디렉터리와 파일을 미리 생성하는 것은 메타데이터의 크기에 따라 시간이 많이 소요될 수 있다. 이 경우에 사용자가 복구 요청을 하고 첫 번째 복구 데이터를 요청해서 응답을 받는 시간이 오래 걸리게 된다. 이를 방지하기 위해서 요청에 따라 점진적으로 디렉터리 및 파일을 생성하는 접근 방법을 이용한다.

마지막 세 번째 단계에서는 두 번째 단계에서 디렉터리와 비어있는 파일을 생성한 후 사용자가 파일을 읽으려고 하면 파일 읽기 시스템 호출을 가로챈 후 시스템 호출 처리에 필요한 데이터를 CDP 서버에 요청하여 수신하고 이를 시스템 호출에 대한 응답으로 반환한다. 동시에 해당 파일에 CDP 서버로부터 수신한 데이터를 기록하여 동일한 시스템 호출에 대해서는 CDP_DIR에서 바로 처리할 수 있도록 한다.

3.2 점진적인 디렉터리 구조 생성

그림 3은 사용자 요청에 따라 복구 시점의 소스 디렉터리(Source_DIR) 구조를 CDP_DIR에 점진적으로 생성하는 과정을 보여 준다.

Fig. 3. 
Incremental construction of the directory structure

그림 3의 우측의 트리 구조에서 동그라미는 디렉토리를 의미하며 사각형은 파일을 의미한다. 가장 위쪽의 트리구조는 복구시점의 소스 디렉토리 구조를 보여주며 중간의 트리구조는 A 디렉토리부터 접근하는 상황에서 A와 점섬으로 연결된 B, C 디렉터리와 G 파일을 생성해야 함을 표시한다. 하단의 트리구조는 B 디렉토리를 접근할 때 하위의 디렉토리인 D와 E를 생성해야 함을 점선을 통해서 표현하였다. 자세한 복구과정은 다음에서 설명한다.

Restore Manager는 파일 시스템 호출을 가로채서 CDP_DIR/A 경로에 대한 시스템 호출인지 확인한다. CDP_DIR에 CDP_DIR/A 디렉터리가 생성되어있는지 확인하고 생성되어있지 않으면 메타데이터 B-Tree에서 CDP_DIR/A 경로의 하위 디렉터리 및 파일을 검색하고 검색 결과를 CDP_DIR에 생성한다. 그 결과 디렉터리 CDP_DIR/A, CDP_DIR/A/B, CDP_DIR/A/C와 파일 CDP_DIR/A/G가 생성된다. 다시 CDP_DIR/A/B를 접근하는 시스템 호출을 가로채면 CDP_DIR/A의 하위 디렉토리를 메타데이터 B-Tree에서 검색하여 디렉터리 CDP_DIR/A/B/D, CDP_DIR/A/B/E를 생성한다.

그림 4는 사용자 요청에 따라 점진적으로 디렉터리 구조를 복구하는 절차에 대한 의사코드이다. 사용자의 디렉터리 탐색은 getdents() 시스템 호출을 통해서 이루어진다. Restore Manager는 getdents() 호출을 가로채어 메타데이터 B-Tree를 기반으로 사용자가 탐색요청을 할 때 마다 점진적으로 디렉터리 및 파일 구조를 복구한다.

Fig. 4. 
Pseudo code for incremental construction of directories

3.3 복구 시점의 파일 읽기

앞서 기술한 절차에 의해서 복구시점의 디렉토리 구조가 점진적으로 복구되면서 비어있는 파일들도 생성된다. 이후 사용자는 해당 파일에 대해 읽기 시스템 호출을 이용하여 복구시점의 데이터를 읽으려고 시도한다. 그림 3에서 CDP_DIR/A/G경로의 파일을 읽기 위한 시스템 호출이 커널로 전달된 것을 가정한다.

Restore Manager는 이 시스템 호출을 가로채어 시스템 호출에서 필요로 하는 부분을 메타데이터 B-Tree를 참조하여 CDP 서버에 대한 요청 (inode, offset, length)으로 생성하여 CDP 서버로 전달한다. CDP 서버는 CDP Pool에서 해당 데이터를 합성해서 반환한다. Restore Manager는 CDP 서버가 반환한 데이터를 가로챈 시스템 호출에 대한 응답으로 반환하고 동시에 CDP_DIR/A/G 파일의 해당 위치에 데이터를 기록한다.

그림 5는 사용자가 복구 시점의 파일을 읽고자 할 때 이를 처리하는 의사코드이다. 사용자의 읽기 요청은 read() 시스템 호출로 처리된다. Restore Manager는 read() 시스템 호출을 가로채서 CDP 서버에 대한 요청으로 변환하여 CDP 서버로부터 해당 데이터를 받아서 처리하도록 한다.

Fig. 5. 
Pseudo code for reading recovered files

이 논문에서는 제안하는 연속적인 데이터 보호 시스템에서 효과적인 복원 방법의 성능을 평가하기 위해서 리눅스 운영체제를 기반으로 직접 구현하고 실험을 통해 실제 복구 시간을 측정하였다. 실험에 사용된 환경은 표 1과 같다.

실험 환경은 기본적으로 CDP Pool을 관리하는 CDP 서버 노드와 실제 데이터를 서비스하는 프로덕션 서버 노드로 구성하였다. CDP 서버 노드는 [5]에서 제안하는 방식에 따라 구현하였다. 각 노드와 네트워크의 사양은 아래 표와 같다. 실험을 위해서 가상의 파일 및 디렉토리를 생성하였으며 총 데이터의 크기는 최대 50Gbyte 이다.

실험을 통해서 사용자의 복구 요청에 즉각적으로 반응할 수 있는지를 확인하기 위해서 사용자가 복구를 요청하고 최초에 복구 시점의 파일에 접근하기까지의 시간을 측정하였다. 그림 6은 실험에 사용된 파일의 수를 200K에서 500K까지 증가시켜 가면서 제안하는 방법과 기존 방법의 복구 데이터에 대한 최초 접근시간을 측정한 결과를 보여준다.

Fig. 6. 
First access time of exising method and proposed method

제안하는 방법의 경우 실험에 사용한 파일의 수가 200K에서 500K로 증가함에 따라 소요시간이 48.757초에서 89.051초 증가하였다. 이것은 최대 50Gbyte의 데이터에 대해 특정 시점으로 접근하는 데 걸리는 시간이 최대 1분 30초 정도임을 의미한다.

이 시간을 차지하는 대부분은 CDP 서버가 해당 시점의 메타데이터를 복원하고 이를 프로덕션 서버로 전송하면 이를 수신하여 메타데이터 B-Tree를 구축하는 데 걸리는 시간이다. 파일의 수가 많을수록 메타데이터의 크기가 커지므로 시간이 더 걸리는 것으로 판단된다.

기존 방법과 비교했을 때에는 그림 6에서 보는 바와 같이 제안하는 방법이 평균 22배 정도 더 빠른 것을 볼수 있다. [12]와 같은 CDP 방법들은 복구를 위해서 해당 시점의 모든 데이터를 합성해서 Produciton 서버로 전송한 후 접근해야 하므로 제안하는 방법에 비해서 접근시간이 더 많이 걸릴 수밖에 없다.

이 논문에서는 기존에 제안된 [12]의 CDP 방법을 기반으로 특정 시점에 대한 데이터를 점진적으로 복구하는 방법을 제안하였다. 제안하는 방법은 복구시점의 메타데이터를 기반으로 사용자의 복구 요청에 대해 점진적으로 디렉터리 및 파일 구조를 생성한다. 생성한 디렉터리 및 파일 구조를 기반으로 사용자가 요청하는 파일의 콘텐츠를 제공한다. 사용자는 이 모든 과정을 투명하게 지역의 파일시스템 접근 방식으로 처리하게 된다.

제안한 방법에 대해 성능을 검증하기 위해서 리눅스 운영체제를 기반으로 구현하고 특정 시점 복구 데이터에 대한 접근 속도를 제안하는 방법과 기존에 제안된 방법에 대하여 측정하고 비교하였다. 비교 결과 제안하는 방법이 최초 데이터 접근시간이 약 22배 더 빠른 것을 확인하였다. 대용량의 데이터를 지속적으로 접근할 경우 네트워크 대역폭에 성능이 영향을 받을 수밖에 없으므로 CDP 데이터 복구시간을 줄이기 위해서는 네트워크 전송시간을 줄이기 위한 다양한 시도가 필요하다. 향후 좀 더 대역폭인 높은 네트워크 환경에서 RDMA(Remote Direct Memory Access)를 이용하여 CDP 서버로부터 데이터를 읽어 오는 시도를 추진할 계획이다.