Cloud Storage에서 99.999999999% 내구성을 제공하는 방법과 도움이 되는 권장사항

  * 본 아티클의 원문은 2021년 1월 29일 Google Cloud 블로그(영문)에 게재되었습니다.  

스토리지 솔루션의 가장 기본은 내구성으로 데이터가 손실이나 손상으로부터 얼마나 잘 보호되는지를 나타냅니다. 클라우드 환경에서는 이 내구성이 특히 중요하게 느껴질 수 있습니다. Cloud Storage는 최소 99.999999999%의 연간 내구성(9가 11개)을 갖추도록 설계되었으므로 100년의 시간이 지난다고 해도 10억 개의 객체 중 하나라도 손실되는 일이 없을 것입니다. 

Google은 내구성 목표 달성을 매우 중요하게 생각합니다. 이 게시물에서는 Cloud Storage 데이터를 보호하는 주요 방법을 살펴봅니다. 이와 동시에 데이터 보호는 궁극적으로 모두의 책임이므로(데이터 손실의 가장 일반적인 원인은 사용자 또는 스토리지 관리자가 실수로 삭제하는 경우임) 자연재해, 사용자 오류와 같은 위험으로부터 데이터를 보호하는 데 도움이 되는 권장사항을 소개합니다.

물리적 내구성

대부분의 사람은 내구성이라고 하면 네트워크, 서버, 스토리지 하드웨어 장애로부터 데이터를 보호하는 상황을 떠올립니다.

궁극적으로 하드웨어 장애로부터 데이터를 보호하는 가장 좋은 방법은 소프트웨어라는 Google의 철학에 따라 생소한 하드웨어 솔루션에 의존하지 않고 경제적인 비용으로 더 높은 안정성을 확보할 수 있습니다. 하드웨어 장애는 언제든지 일어날 수 있다고 가정하고 있고 실제로도 그렇지만 이로 인해 내구성이 저하되어서는 안 됩니다.

객체를 Cloud Storage에 저장하기 위해 수많은 ‘데이터 청크’로 나눈 다음 각기 다른 전원을 사용하는 여러 서버에 저장합니다. 또한, 중복성을 위해 많은 ‘코드 청크’도 만듭니다. 하드웨어(예: 서버, 디스크) 장애가 발생하면 이 데이터 청크와 코드 청크를 사용하여 전체 객체를 재구성하는데, 이러한 기법을 이레이저 코드(Erasure Code)이라고 합니다. 게다가 객체를 찾고 읽는 데 필요한 메타데이터 사본을 여러 개 저장하므로 하나 이상의 메타데이터 서버에서 장애가 발생해도 해당 객체에 계속 액세스할 수 있습니다. 

이때 중요한 점은 데이터를 항상 여러 가용성 영역에 중복 저장해야만 쓰기 작업이 성공한 것으로 확인된다는 것입니다. Google에서 사용하는 인코딩은 하드웨어 장애 시 99.999999999% 이상의 내구성 목표를 지원하기에 충분한 중복성을 제공합니다. 데이터가 저장되면 정기적으로 체크섬을 검증하여 저장 데이터를 특정 유형의 데이터 오류로부터 보호하고 체크섬이 일치하지 않는 경우에는 인코딩의 중복성을 이용하여 데이터가 자동으로 복구됩니다.

권장사항: 이중 리전 또는 멀티 리전 위치 사용

물리적 내구성 위험 요소에 대비한 이러한 보호 레이어가 잘 구현되어 있지만 이것으로 리전의 상당한 물리적 파괴(예: 전쟁이나 소행성 충돌, 기타 대형 재해)에 대해 데이터를 보호할 수는 없습니다. 

Cloud Storage의 99.999999999% 내구성 목표는 리전 하나하나에 적용됩니다. 전체 리전을 완전히 파괴할 수 있는 자연재해로부터 보호하려면 가장 중요한 데이터를 이중 리전 또는 멀티 리전 버킷에 저장하는 것이 좋습니다. 이러한 버킷은 여러 지리적 리전에 저장되어 있으므로 데이터 중복성이 저절로 보장됩니다. 이 위치 유형에서는 버킷을 사용하기 위해 애플리케이션을 추가 구성하거나 API를 변경할 필요가 없으며 매우 드물지만 치명적인 결과를 초래할 수 있는 이벤트 발생 시 더욱 향상된 내구성을 제공합니다. 뿐만 아니라 이 위치 유형은 일시적으로 리전에 액세스할 수 없는 경우에도 둘 이상의 위치에서 객체를 투명하게 제공할 수 있기 때문에 높은 수준의 가용성 SLA를 지원합니다.

전송 중 내구성

또 다른 내구성 위험 요소로 전송 중 데이터의 손상이 있습니다. Cloud Storage 자체 서비스 내의 네트워크를 통해 전송되거나 Cloud Storage에 객체를 업로드하거나 다운로드할 때 전송되는 데이터가 여기에 해당할 수 있습니다.

이러한 손상을 원천적으로 방지하기 위해 Cloud Storage 내에서 전송 중 데이터는 예외 없이 항상 체크섬으로 보호되도록 설계되었습니다. 체크섬 검증 오류가 발생하면 상황에 따라 요청을 자동으로 재시도하거나 오류가 반환됩니다.
권장사항: 업로드 및 다운로드에 체크섬 사용
Google Cloud에서는 Google 서비스 내에서 이동하는 모든 Cloud Storage 객체에 체크섬이 적용되지만 엔드 투 엔드 보호를 실현하기 위해 데이터를 Cloud Storage에 업로드할 때는 체크섬을 제공하고 객체를 다운로드할 때는 클라이언트에서 이 체크섬을 검증하는 것이 좋습니다.

사람으로 인한 내구성 리스크

서비스 개발자와 운영자 또는 Cloud Storage 사용자의 실수 등 사람이 저지르는 실수가 데이터 손실을 유발하는 가장 큰 위험 요소로 알려져 있습니다.

데이터 내구성을 위협하는 가장 큰 단일 위험 요소는 소프트웨어 버그일 수 있습니다. 소프트웨어 버그로 인한 내구성 손실을 방지하기 위해 Google은 처음부터 데이터를 손상시키거나 데이터를 지울 수 있는 버그를 피하는 조치를 취합니다. 그런 다음 이러한 유형의 버그를 신속하게 감지하는 보호 장치를 유지하여 내구성 저하가 내구성 손실로 이어지기 전에 이를 포착하려고 합니다.

버그를 사전에 포착하기 위해 대규모 통합 테스트를 통과한 후에만 새로운 Cloud Storage 버전을 프로덕션 환경에 배포됩니다. 가용성 영역의 작동 중지와 같이 다양하고 극단적인 장애 시나리오를 연습하고 데이터 인코딩 및 배치 API의 동작을 이전 버전과 비교하여 회귀를 검사하는 등의 테스트를 거치게 됩니다.

새 소프트웨어 출시가 승인되면 가용성 영역에 따라 매우 제한적으로 영향을 받는 초기 영역을 시작으로 보편화될 때까지 서서히 대상을 확대해 가는 단계별 업그레이드를 수행합니다. 이렇게 하면 버그가 큰 영향을 미치기 전에, 필요할 경우 복구에 사용할 데이터 사본(또는 충분한 수의 이레이저 코드 청크)이 있는 상태에서 문제를 포착할 수 있습니다. 이러한 방식의 소프트웨어 출시는 필요한 경우 빠르게 롤백할 수 있도록 마련된 계획에 따라 면밀히 모니터링됩니다.

이 외에도 데이터가 손실되지 않도록 보호하기 위한 다음과 같은 다양한 권장사항이 있습니다.

권장사항: 객체 버전 관리 사용 설정

데이터 손실을 유발하는 가장 일반적인 원인 중 하나는 스토리지 관리자 또는 최종 사용자가 실수로 데이터를 삭제하는 것입니다. 객체 버전 관리를 사용 설정하면 나중에 복원해야 하는 경우에 대비해 삭제된 객체가 Cloud Storage에 보관됩니다. 객체 수명 주기 관리 정책을 구성하면 버전 관리된 객체가 영구 삭제되기 전까지 보존되는 기간을 제한하여 스토리지 비용을 효과적으로 제어할 수 있습니다.

권장사항: 데이터 백업

Cloud Storage에서 99.999999999%의 내구성 목표가 실현된다고 해서 데이터를 백업할 필요가 없는 것은 아닙니다. 예를 들어 악성 해커가 내 Cloud Storage 계정의 액세스 권한을 손에 넣는다면 어떤 일들이 일어날 수 있는지 생각해 보세요. 목표에 따라 예비 데이터 사본을 다른 리전이나 클라우드 또는 온프레미스에 백업해 두거나 에어 갭을 통해 테이프 또는 디스크에 물리적으로 분리하여 백업해 둘 수 있습니다.

권장사항: 데이터 액세스 보관 정책 및 감사 로그 사용

데이터를 장기간 보관하려면 Cloud Storage 버킷 잠금 기능을 사용하여 데이터 보관 정책을 설정하고 일정 기간 동안 데이터가 잠겨 있도록 하세요. 이렇게 하면 실수로 수정 또는 삭제하는 상황을 방지하고, 데이터 액세스 감사 로깅과 함께 사용할 경우 FINRA, SEC, CFTC와 특정 의료 산업 보존 규정 등의 관련 규제 및 규정 준수 요건을 충족할 수 있습니다.

권장사항: 역할 기반 액세스 제어 정책 사용

업무 분리와 최소 권한의 원칙을 따르는 IAM 데이터 액세스 제어 정책을 마련한다면 악성 해커의 영향 범위와 실수로 인한 삭제를 제한할 수 있습니다. 예를 들어 프로젝트 삭제 권한이 있는 사람과 버킷 생성 권한이 있는 사용자를 분리하는 것이 좋습니다.

암호화 키와 내구성

모든 Cloud Storage 데이터는 클라우드 내에서 저장 상태이든 전송 중이든 항상 암호화되도록 설계되었습니다. 암호화 키가 없으면 객체를 읽을 수 없기 때문에 암호화 키 분실은 내구성에 심각한 위험을 초래합니다. 내구성이 아무리 좋은 데이터라고 하더라도 읽을 수 없다면 결국 아무 소용이 없기 때문입니다. Cloud Storage에서는 1) 신뢰를 바탕으로 Google에서 암호화 키를 대신 관리하도록 하거나 2) 고객 관리 암호화 키(CMEK)와 Cloud KMS를 사용하거나 3) 고객 제공 암호화 키(CSEK)와 외부 키 서버를 사용하는 세 가지 키 관리 옵션이 제공됩니다.

Google은 이레이저 코드, 일관성 확인과 같이 앞의 설명과 유사한 조치를 통해 관리하는 암호화 키의 내구성을 보호합니다.

권장사항: 암호화 키 보호

키 관리를 위해 CMEK 또는 CSEK를 선택하면 자신의 키를 직접 관리할 수 있습니다. 이 경우에도 99.999999999% 이상의 내구성을 제공하는 방식으로 키를 보호하는 것이 중요합니다. CSEK의 경우 키의 외부 백업을 유지하므로 키가 어떤 식으로든 분실되거나 손상되더라도 복구할 방법이 있습니다. 이러한 예방 조치를 취하지 않는다면 데이터의 내구성이 암호화 키의 내구성에 의해 결정됩니다.

99.999999999%를 넘어서

Google Cloud는 데이터 보호 책임을 매우 중요하게 생각합니다. 실제로 여기에 소개된 많은 기술 덕분에 Cloud Storage는 지금까지 99.999999999%가 넘는 연간 내구성을 달성할 수 있었습니다. 이에 더해 이 게시글에 소개된 권장사항을 적용한다면 현재 혹은 향후 수십 년 후에도 언제든지 필요할 때 데이터를 이용할 수 있는 내구성을 확보할 수 있습니다. 시작하려면 Cloud Storage 안내 가이드 전체 문서를 확인해 보세요.