글로벌 칼럼 | 클라우드 백업 솔루션 선택 시 기억해야 할 4계명

데이터 보호의 세계에서 클라우드는 인기 백업 장소로 부상했다. 백업 인프라의 복잡성과 비용을 공급업체에 맡기고, 데이터가 오프사이트에 안전하게 보관되므로 안심할 수 있다는 점이 매력적이다. 
 

클라우드에 백업하면 백업 데이터 사본 하나를 오프사이트에 저장하는 3-2-1 백업 규칙을 지킬 수 있다. 또한 여러 백업 솔루션 제공업체가 변경 불가 백업(immutable backup)을 제공하므로 해커가 백업 시스템에 대한 관리 권한을 획득하더라도 어떤 방식으로든 백업을 삭제, 암호화 또는 손상할 수 없다. 

이런 이유로 클라우드 백업은 인기가 많지만, 클라우드 백업에 위험성이 전혀 없는 것은 아니다. 클라우드 백업 솔루션 업체인 카보나이트(Carbonite)와 스토리지크래프트(StorageCraft)의 사례가 이런 점을 가장 잘 보여준다. 

2009년 카보나이트는 백업 스토리지 어레이의 다중 디스크 장애로 인해 고객 7,500명의 가장 최근 백업을 손실했다. 스토리지크래프트는 2014년 다른 방식으로 매우 유사한 결과를 초래한 사건을 경험했다. 클라우드 마이그레이션 중 인적 오류로 인해 데이터를 손실한 것이다. 서버를 클라우드로 완전히 마이그레이션하기 전에 관리자가 서버 사용을 중지하고 데이터를 삭제했다. 이는 메타데이터 손실로 이어졌고, 백업 시드(seed) 작업을 위한 긴급 조치를 취해야 했다.  

2가지 사례의 기술적인 세부 사항은 다르지만, 핵심 문제는 고객 백업 데이터에 대한 부적절한 중복성과 미흡한 복원력이라는 점에서 동일하다. 

장애 발생 가능성을 간과한 카보나이트

카보나이트는 RAID5만 사용하는 개별 RAID 어레이에 의존했기 때문에 여러 가지 장애 가능성에 취약했다. 이는 가장 흔한 문제로, 2개 이상의 드라이브에 동시에 장애가 발생하면 RAID5 어레이에 오류가 발생할 수 있다. 어레이의 드라이브 수, 크기(이전보다 훨씬 커짐), 드라이브가 고장 날 수 있다는 사실을 고려할 때 RAID5는 권장되는 구성이 아니었지만, 카보나이트는 이런 수준에 머물러 있었다. 

즉, 카보나이트는 고객 7,500명의 데이터를 시한폭탄과도 같은 어레이에 저장하고 있었다. 홍수, 정전, 화재가 발생하면 고객 데이터도 함께 사라질 수 있다는 뜻이기도 하다. 2021년 OVH 데이터센터에 불이 났던 것처럼 자연재해는 클라우드 공급업체에 피해를 입힐 수 있다는 사실을 잊지 말아야 한다. 다른 회사의 데이터를 보관하는 공급업체는 S3, 애저 블롭 또는 구글 객체 스토리지와 같은 지리적 이중화 스토리지를 사용하는 것이 좋다. 

인적 오류로 드러난 복원력 부족

스토리지크래프트에서 관리자가 단일 서버를 폐기하면서 모든 메타데이터를 손실했다는 사실은 백업 스토리지 아키텍처에 지리적 중복성과 내결함성이 부족했음을 시사한다. 스토리지크래프트는 모든 고객의 백업을 통합한 유일한 데이터 사본을 단일 서버에 보유하고 있었다. 자연재해가 발생하면 쉽게 전멸할 수도 있다는 의미다. 하지만 결국은 한 사람의 실수로 인해 사고가 발생했다. 인적 오류와 악의적인 행위는 백업을 해야 하는 대표적인 이유다.

이런 사건은 수십 년의 경험을 가진 백업 전문가인 필자를 움찔하게 만든다. 3-2-1 백업 규칙은 데이터 사본 3개를 만들어 2개는 서로 다른 미디어에, 나머지 1개는 오프사이트에 보관하는 것이다. 책임감 있는 백업 제공업체라면 여러 계층의 중복성, 지리적 복제, 장애 격리 등을 고려해 클라우드를 설계해야 한다. 그렇지 않으면 고객 데이터가 감당할 수 없는 위험에 노출될 수 있다. 어떤 백업 환경에서든 모든 사본을 손실하는 상황을 방지해야 한다. 

백업 솔루션을 선택할 때 고려해야 할 것

백업 솔루션에 문제가 발생하면 업체의 대처를 살펴봐야 한다. 카보나이트의 대응은 스토리지 공급업체를 고소하고 책임을 지는 대신 손가락질하는 것이었다. 회사의 아키텍처에는 문제가 없었으며, 고객 데이터를 잃게 만든 것은 스토리지 공급업체의 어레이 때문이라고 주장했다(이 소송은 법정 밖에서 합의가 이루어졌고 어떤 일이 있었는지 공개되지 않았다.) 또한 카보나이트 CEO는 손실된 것은 백업 데이터일 뿐 운영 데이터가 아니라며 해당 사건을 공개적으로 대수롭지 않게 여기려고 했다. 프로덕션 데이터를 잃어 백업 데이터로만 복원할 수 있었던 기업 54곳을 생각하지 못한 듯하다. 

반면 스토리지크래프트는 훨씬 더 나은 반응을 보였다. 스토리지 CEO는 이 문제가 얼마나 중요한지 잘 알고 있다며 공개 사과문을 발표했다. 또한 고객이 데이터를 더 빨리 받을 수 있도록 드라이브를 배송하는 등 백업을 다시 시드할 수 있도록 할 수 있는 모든 조치를 취했다(드라이브 배송은 '시드'라고 하는 첫 번째 백업을 인터넷 업로드보다 훨씬 빠르게 수행하기 위해 사용하는 일반적인 방법이다). 

클라우드 백업 서비스를 사용하려는 기업은 2가지 사례에서 다음과 같은 교훈을 얻을 수 있다. 
 

• 클라우드가 완벽하다고 가정하지 않을 것. 스토리지 이중화, 지리적 복제, 데이터 무결성 조치, 재해 복구 기능에 대해 공급업체에 까다로운 질문을 하고 계약서 및 SLA에 구체적인 내용을 서면으로 명시하라. 가장 좋은 답변은 모든 백업을 S3 또는 애저 블롭과 같이 검증된 지리적 중복 개체 스토리지에 저장하는 것이다. 단 한 번의 화재나 홍수로 인해 백업이 손실되는 일을 방지할 수 있다. 또한 사람의 실수나 부정행위로 인한 백업 손상을 막기 위해 백업의 불변성을 보장하는지도 확인하라. 
• 공유 책임 모델을 이해할 것. 공급업체가 클라우드 인프라를 보호하고 보안을 유지하더라도 백업 구성, 보존 기간 및 복원 테스트 관리는 여전히 사용자의 책임이다. 공급업체에 모든 책임을 떠넘기지 말라.
• 비상 계획을 세울 것. 탄탄한 클라우드 백업 전략을 갖추고 있더라도 국가적인 재해는 여전히 온프레미스 데이터를 위협할 수 있다. 물리적 백업 또는 보조 클라우드 제공업체를 통해 프로덕션과 클라우드 백업 사본이 동시에 손실될 위험을 완화하라. 여러 클라우드 제공업체에 데이터를 복사할 수 있는 서드파티 백업 서비스 및 소프트웨어도 있다. 이런 옵션을 살펴보고 운영에 경제적으로 적합한지 확인하라. 
• 마케팅 문구에 현혹되지 말 것. 독립적인 리뷰를 살펴보고, 기존 고객과 이야기를 나누고, 소송이나 공개적인 실패 이력이 있는지 찾아보라. 평판이 좋은 공급업체는 아키텍처를 투명하게 공개하며, 안정성과 신속한 고객 서비스에 대한 실적이 좋다. 

 
클라우드는 백업 현대화 및 비용 효율화를 위한 강력한 도구가 될 수 있다. 하지만 인프라 관련한 다른 의사결정과 마찬가지로 엔터프라이즈급 제공업체와 비용 절감형 업체를 구분하기 위해서는 면밀한 실사가 필요하다. 카보나이트와 스토리지크래프트 사례는 잘못될 수 있는 일에 대한 경각심을 일깨운다. 신뢰하되, 검증하라. 
editor@itworld.co.kr