Kubernetes에 관한 당사의 새로운 블로그 시리즈 중 네 번째 글에 오신 것을 환영합니다! 이 시리즈에서 우리는 Zadara에서의 Kubernetes 배포 세계와, 당사의 AWS 호환 클라우드에서 컨테이너화된 애플리케이션을 관리하기 위해 이것이 어떻게 사용될 수 있는지 탐구합니다. 여러분이 Kubernetes를 처음 접하든 숙련된 사용자이든 상관없이, 이 시리즈는 Zadara 클라우드에서 컨테이너화된 애플리케이션을 관리하기 위한 가치 있는 인사이트와 모범 사례(best practices)를 제공할 것입니다. 앞으로 나올 더 흥미로운 콘텐츠를 계속 지켜봐 주십시오!
이 블로그 포스트는 가장 단순한 스냅샷 생성 기능부터 성숙한 백업 및 복구 솔루션의 사용, 그리고 Kubernetes 컨트롤 플레인의 DR(재해 복구) 준비 절차에 이르기까지, 당사의 Kubernetes 워크로드 연속성을 보장하는 것에 초점을 맞출 것입니다.
일반적인 블록 스토리지 기능 외에도, 당사의 EKS-D 솔루션은 EBS CSI 배포와 일치하도록 Kubernetes 스냅샷 생성 기능이 사전 구성되어 있습니다. 여기에는 VolumeSnapshotClass ebs-vsc CRD가 이미 기본 스냅샷 생성기(default snapshotter)로 설정되어 있는 것이 포함됩니다(아래 주석에 유의하십시오. k10 주석에 대해서는 나중에 이야기하겠습니다).
스냅샷 생성기가 배포된 상태에서, 우리는 아래의 YAML 명세와 같은 것을 사용하여 주어진 PVC의 VolumeSnapshot을 수동으로 생성할 수 있습니다:
스냅샷 생성기가 배포된 상태에서, 우리는 아래의 YAML 명세와 같은 것을 사용하여 주어진 PVC의 VolumeSnapshot을 수동으로 생성할 수 있습니다:
이것은 기존에 존재하는 ebs-claim PVC 리소스의 스냅샷을 생성할 것이며, 몇 초 내에 사용할 준비가 됩니다(실제 시간은 원본 볼륨 크기에 따라 다릅니다).
해당 스냅샷은 콘텐츠를 기반으로 PVC를 재지정하여 생성하는 데 사용될 수 있으며, 아래의 YAML 명세와 같은 것을 사용합니다(dataSource 섹션에 유의하십시오)
VolumeSnapshot은 클라우드 상의 실제 스냅샷 리소스를 참조하는 VolumeSnapshotContent 리소스에 바인딩된다는 점을 언급할 가치가 있습니다:
우리는 AWS API, Symp API 또는 zCompute GUI 콘솔을 사용하여 클라우드 스냅샷 리소스를 볼 수 있습니다 – 예를 들면 다음과 같습니다:
더 발전된 백업 및 복구 기능을 위해서, 우리는 Kasten K10의 사용을 고려할 수 있습니다. 이는 애플리케이션 볼륨뿐만 아니라 전체 Kubernetes 명세(pod 스펙, secret 등)를 처리하는 Veeam 제품으로, 데이터뿐만 아니라 전체 애플리케이션을 백업하고 복구할 수 있도록 해줍니다.
K10은 위에서 언급한 단순화된 예시와 동일한 스냅샷 생성 방식을 사용합니다(우리는 동일한 VolumeSnapshot 리소스 등을 볼 수 있습니다). 그러나 이것은 다양한 데이터베이스 지향 유스케이스뿐만 아니라, 워크로드를 백업 및 복구할 수 있는 쉬운 방법을 찾는 Kubernetes 관리자들에게 큰 가치를 창출하는 풍부한 추가 기능을 돕기 위해 kanister 엔진을 활용합니다.
당사의 EKS-D 솔루션은 배포 자동화의 일부로 K10을 자동으로 설치해 줄 수 있으며, 나중에 간단한 Helm 차트 설치를 통해 추가될 수도 있습니다. 어떤 경우든 이것의 VolumeSnapshotClass 필수 조건은 이전에 본 것처럼 k10 주석으로 이미 충족되어 있으므로, 이를 설치하기 전에 클러스터를 수정할 필요가 없습니다. 만약 K10을 직접 설치하는 경우, 대시보드에 액세스하는 방법에 관한 Helm 메시지에 유의하십시오:
기본적인 클러스터 내부 백업 및 복구 작업을 위해서는 더 이상의 추가 설정이 필요하지 않습니다. 모든 포드가 준비되면 위에서 언급한 대로 게이트웨이 서비스를 포트 포워딩하여 K10에 액세스하면 됩니다:
이 시연을 위해, 저는 “pg” 네임스페이스에 Helm을 통해 설치한 실행 중인 PostgreSQL 데이터베이스를 가지고 있습니다:
이 차트에는 여러 다른 리소스가 포함되어 있습니다. StatefulSet 자체 외에도 Helm은 PVC, Secret(관리자 사용자 자격 증명 포함), 그리고 데이터베이스에 액세스하기 위한 두 개의 서비스를 배포했습니다:
K10은 이러한 모든 리소스를 pg “unmanaged(관리되지 않음)” 애플리케이션 아래로 통합합니다(아직 이에 대한 백업 정책이 없기 때문입니다):
pg 애플리케이션을 위한 백업 정책을 생성해 보겠습니다. 모든 기본값을 그대로 두면 매시간 전체 애플리케이션(데이터 볼륨을 포함한 모든 리소스)의 스냅샷을 찍는 정책이 생성됩니다:
이제 유효한 정책이 있으므로(따라서 애플리케이션은 K10에 의해 “managed(관리됨)” 상태가 됨) 온디맨드로 실행할 수도 있습니다:
이것이 실제 백업 작업입니다(이 단순화된 케이스에서는 40초 이내에 완료되었습니다):
이제 실제 복구 테스트를 진행해 보겠습니다. 애플리케이션이 K10에 의해 관리되고 있으므로(백업 정책 준수), Helm uninstall 명령을 사용하여 Kubernetes 클러스터에서 이를 완전히 삭제하겠습니다. 또한 StatefulSet PVC는 기본적으로 자동 삭제되지 않으므로, PVC까지 수동으로 삭제하여 모든 리소스가 완전히 제거되었는지 확인하겠습니다.
애플리케이션이 K10에 의해 관리되고 있기 때문에, 대시보드에서 간단히 이를 복구할 수 있습니다:
우리는 우리의 유일한 복구 지점(restore point)을 사용하여 동일한 네임스페이스로 백업을 복구할 것입니다(다른 네임스페이스가 될 수도 있습니다):
복구 작업이 완료되면, 애플리케이션은 원본 콘텐츠(스냅샷을 기반으로 한 새 PVC)와 이전 구성을 가지고 다시 온라인 상태가 됩니다. Helm 주석도 그대로 존재하므로 Helm은 자신이 실제로 이를 배포했다고 인식하며, 우리는 Helm을 사용하여 애플리케이션을 계속 관리할 수 있습니다:
우리는 스냅샷으로부터 데이터베이스 배포를 복구하는 과정을 방금 확인했습니다. 하지만 이 스냅샷은 클러스터 내부에서 생성되고, 저장되며, 복구되었다는 점에 유의해야 합니다. 이는 일부 복구 유스케이스에는 문제가 없으나, 클러스터 자체가 손상되는 상황에 대비하려면 백업을 클러스터 외부로 내보내는 것을 고려해야 합니다.
이러한 고급 유스케이스를 위해 K10을 원격 오브젝트 스토리지 솔루션과 통합하는 것을 고려해 보십시오. 예를 들어, K10 인증 원격 스토리지 프로바이더인 Zadara의 Object Storage가 있습니다. 복구 지점을 클러스터 외부로 내보냄으로써 클러스터 수준의 장애로부터 애플리케이션을 보호하고, hot/cold DR 기능을 활성화하며, 애플리케이션을 하나의 클러스터에서 다른 클러스터로 마이그레이션할 수도 있습니다.
K10을 Zadara의 Object Storage와 통합하려면, 먼저 S3 액세스 및 시크릿 키, 리전, API 엔드포인트를 포함한 사용자 자격 증명이 있는 오브젝트 스토리지 계정이 필요합니다:
이러한 세부 정보와 지정된 버킷을 사용하여 새로운 S3 호환 K10 위치 프로필(location profile)을 생성할 수 있습니다:
당사의 위치 프로필이 검증되었으며 이제 사용할 준비가 되었습니다:
우리는 새로운 내보내기 정책을 생성하거나, 기존 정책을 편집하여 새로운 위치 프로필로 스냅샷을 내보내는 기능을 포함시킬 수 있습니다:
이렇게 하면 복구 지점이 더 이상 로컬에만 저장되지 않습니다. 이전에 외부로 내보냈기 때문에, 필요한 경우 클러스터 외부에서 백업을 가져올 수 있습니다:
앞서 언급했듯이 재해 복구(DR) 시나리오, 랜섬웨어 보호(불변 백업 기능 활용), 또는 애플리케이션 마이그레이션과 같이 외부 백업을 요구하는 다양한 유스케이스가 있습니다. Kasten은 Kasten 자체를 위한 외부 DR 솔루션을 포함하여 이러한 모든 유스케이스와 그 이상을 지원할 수 있으며, 이 모든 유스케이스는 방금 우리가 외부 백업 위치로 정의한 것과 동일한 위치 프로필(location profile)을 기반으로 작동하게 됩니다.
이 블로그 포스트에서 논의하고 싶었던 마지막 연속성 기능이 하나 더 있으며, 이는 Kubernetes 컨트롤 플레인(control-plane) 자체와 관련이 있습니다. K10 백업 및 복구 유스케이스와 달리, 이 시나리오는 당사의 Kubernetes 관리 계층이 이런저런 이유로 손상된 상황을 다룹니다. 대부분의 경우, 이는 (모든 Kubernetes 구성을 저장하는) Kubernetes 내부 데이터베이스인 ETCD가 최소 정족수(quorum)를 잃어버린 경우가 될 것입니다.
당사는 각각 ETCD 사본을 보유한 마스터 노드들을 전용 오토스케일링 그룹(기본값은 1개 노드이지만, 일반적인 고가용성 배포를 위해서는 3개 노드로 설정해야 함)으로 관리함으로써 Kubernetes 컨트롤 플레인을 보호하고 있습니다. 하지만 오토스케일링 그룹이 나중에 실제 마스터 노드를 자가 치유하더라도, 마스터 노드의 일시적 손실로 인해 클러스터의 관리 계층이 영구적으로 손상될(brick) 위험은 항상 존재합니다.
이러한 상황은 클러스터 자체를 회복하기 위해 ETCD를 복구해야 하므로 수동 개입이 필요하며, 정확히 이러한 경우를 위해 당사의 EKS-D 솔루션은 빌트인(built-in) ETCD 백업 절차를 포함하고 있습니다. 이는 컨트롤 플레인의 복구가 필요한 상황이 올 때 사용할 수 있도록 Kubernetes 데이터베이스의 주기적인 스냅샷을 저장합니다.
기본적으로 백업은 EKS-D 솔루션과 관련된 모든 것을 저장하는 동일한 /etc/kubernetes/zadara 디렉토리 내에 로컬로(각 마스터 노드 내에)만 저장됩니다. 백업 파일 이름에는 호스트 이름과 인스턴스 ID가 반영되며, 우리는 etcdutl snapshot status 명령을 통해 그 콘텐츠를 검증할 수 있습니다:
이러한 로컬 백업이 일부 유스케이스(예를 들어 3개의 마스터 노드 중 2개를 잃었지만 세 번째 노드를 정족수 복구에 사용할 수 있는 경우)에는 충분히 유용할 수 있지만, 이와 같은 재해 복구(DR) 상황을 위한 유일하고 진정한 해결책은 K10 내보내기에서 했던 것과 매우 유사하게 이 백업 파일들을 클러스터 외부에 저장하는 것입니다.
이러한 요구 사항을 충족하기 위해, EKS-D 솔루션은 로컬 ETCD 백업을 Zadara Object Storage 또는 AWS S3와 같은 원격 오브젝트 스토리지 솔루션으로 내보내도록 구성할 수 있습니다. 초기 자동 배포 변수의 일부로 이를 구성하거나(다음 블로그 포스트에서 자세히 다룸), zadara-backup-export Kubernetes secret 내에 원격 위치 자격 증명을 지정하여 배포 후 작업으로 수행할 수도 있습니다(자세한 내용은 여기를 참조하십시오).
지금은 우선 Kubernetes secret을 생성하고, 이것이 당사의 지속적인 ETCD 백업에 어떤 영향을 미치는지 살펴보겠습니다:
다음 2시간 주기의 백업 사이클부터는 로컬 백업 생성과 더불어 이를 Zadara의 Object Storage로도 내보내게 됩니다. 이는 각 마스터 노드의 etcd-backup.log에서 확인할 수 있습니다. (이전의 로컬 전용 백업 로그 엔트리와, 내보내기(export)까지 함께 포함된 마지막 실행 로그를 비교해 보십시오.)
오브젝트 스토리지 측면(Zadara의 Object Storage 또는 AWS S3 모두 해당)에서는 모든 마스터 노드에서 내보낸(export) 백업 파일들을 확인할 수 있습니다. 이 파일들은 클러스터 이름과 고유 식별자가 접두사(prefix)로 붙은 이름의 폴더 아래에 나타나게 됩니다. (동일한 이름을 가진 다른 클러스터가 존재할 경우에 대비하기 위함입니다.)
이 솔루션은 모든 마스터 노드의 ETCD 백업을 보존하지만, 보존 임계값(retention threshold, 기본값은 100개의 백업 파일)이 지정되어 있다는 점에 유의해야 합니다. 따라서 3개의 마스터 노드로 구성된 환경에서는 보통 약 2~3일 치의 ETCD 백업이 유지되는 반면, 단일 마스터 노드 환경에서는 일주일이 넘는 기간의 백업이 보존됩니다.
이 백업을 사용할 일이 결코 없기를 바라지만, 복구 작업은 꽤나 간단합니다(당사 문서의 이 부분을 참조하십시오). 기본적으로 마스터 오토스케일링 그룹(ASG)의 스케일을 단일 노드로 줄이고, 해당 인스턴스에 ETCD 스냅샷 중 하나를 복사한 뒤, etcdutl snapshot restore 명령을 사용하여 데이터베이스를 복구하고 리셋 플래그(reset flag)와 함께 ETCD 포드(pod)를 재시작하면 됩니다. 그러면 클러스터에 다시 접근할 수 있게 되며, 이후 해당 플래그 없이 ETCD를 다시 시작하고 마스터 ASG를 원래 규모로 스케일 업(scale up)하면 됩니다.
이번 블로그 포스트에서는 Zadara 기반의 Kubernetes에서 프로덕션 급(production-grade) 워크로드를 운영하는 데 필수적인 EKS-D 솔루션의 다양한 백업 및 복구 옵션을 살펴보았습니다. 하지만 지금까지는 실제 프로덕션 급 클러스터를 직접 구성한 것이 아니라, 기본 제공되는(out-of-the-box) 설정을 그대로 사용한 것에 가깝습니다. 다음 블로그 포스트에서는 프로덕션 급 Kubernetes 클러스터에 필요할 수 있는 몇 가지 비기본(non-default) 구성과 기타 선택적 맞춤화(customization) 기능들을 다룰 예정이니, 많은 관심 부탁드립니다!
이번 블로그 포스트는 Zadara 클라우드 환경에서 Kubernetes 워크로드의 연속성을 보장하기 위해 기본 EBS CSI 스냅샷부터 Kasten K10 기반의 애플리케이션 백업, 그리고 EKS-D 솔루션의 빌트인 ETCD 컨트롤 플레인 DR 전략까지 단계별 데이터 보호 체계를 깊이 있게 다루고 있으며, 특히 Zadara Object Storage와의 통합을 통해 클러스터 외부(Remote)에 백업을 안전하게 격리·보존함으로써 랜섬웨어 및 대규모 장애에 대응할 수 있는 프로덕션 급 인프라 생존 전략을 완성도 높게 제시하고 있습니다.
여기에 더해, 이번 아키텍처는 단순한 DR을 넘어 온프레미스와 타 퍼블릭 클라우드를 아우르는 ‘하이브리드 멀티 클러스터 마이그레이션’의 강력한 발판이 된다는 점에서 비즈니스적 가치가 큽니다. 또한, 국내 거점 기반의 고성능 Zadara Object Storage에 데이터를 에어갭(Air-gapped) 형태로 격리 보관함으로써, 국내 금융 및 공공 기관이 요구하는 엄격한 컴플라이언스와 데이터 주권(Data Sovereignty) 문제를 깔끔하게 해결합니다. 마지막으로, 모든 자동화가 무너진 최악의 상황을 가정해 제시된 ETCD 수동 복구 절차는 인프라의 완벽한 통제권을 엔지니어에게 제공하는 가장 확실한 최후의 생존 매뉴얼이라는 점에서 EKS-D의 독보적인 엔지니어 중심 철학을 잘 보여주고 있습니다.
