컨테이너용 영구 스토리지란 무엇인가요?

클라우드 네이티브 애플리케이션 개발에 필수적인 컨테이너는 애플리케이션과 그 종속성을 함께 패키징하는 가볍고 이식 가능한 소프트웨어 단위로, 현대 IT 인프라 전반에 쉽게 배포할 수 있도록 합니다.

컨테이너는 본질적으로 일시적입니다. 필요에 따라 실행되고 종료되는 임시 단위로 설계되었습니다. 이러한 유연성 덕분에 높은 확장성과 탄력성을 제공하지만, 컨테이너가 종료되면 생성된 데이터는 모두 사라집니다. 지속형 스토리지는 개별 컨테이너와 독립적으로 데이터를 유지함으로써 이 문제를 해결합니다.

지속형 스토리지가 없다면 핵심 시스템은 정상적으로 작동할 수 없습니다. 예를 들어 컨테이너에서 실행되는 은행의 거래 데이터베이스는 정기 업데이트 시 고객 계좌 잔액을 잃을 수 있으며, 이커머스 플랫폼은 재시작할 때마다 장바구니 정보를 잃게 됩니다.

조직이 계속해서 클라우드 네이티브 및 마이크로서비스 아키텍처로 전환함에 따라 컨테이너는 애플리케이션 배포 및 관리의 핵심이 되었으며, 상태를 유지하는 애플리케이션을 대규모로 운영하기 위해 컨테이너용 지속형 스토리지가 필수 요소가 되었습니다.Strategic Market Research의 최근 보고서에 따르면 글로벌 애플리케이션 컨테이너 시장은 2024년에 약 21억 달러로 평가되었습니다. 이 시장은 2030년까지 약 69억 달러에 이를 것으로 예상되며, 연평균 성장률(CAGR)은 21.1%입니다.¹

기업 환경에서 지속형 스토리지는 파일, 블록 및 오브젝트 스토리지 형태로 제공되며, 각각 서로 다른 워크로드에 적합합니다. 조직은 일반적으로 하드웨어 시스템과 소프트웨어 정의 스토리지(SDS) 플랫폼을 결합하여 이러한 스토리지 솔루션을 제공하며, 이는 하이브리드 클라우드 및 분산 클라우드 환경을 지원하도록 설계되었습니다.

컨테이너화는 소프트웨어 코드를 실행에 필요한 운영 체제(OS) 라이브러리 및 종속성(일반적으로 Linux 기반)만 포함하여 패키징하는 것을 의미합니다. 이 과정은 컨테이너와 같은 단일 경량 단위를 생성하여 어떤 인프라에서도 일관되게 실행할 수 있도록 합니다.

조직이 가상 머신(VM)에서 컨테이너로 전환함에 따라 컨테이너화된 워크로드를 대규모로 관리해야 할 필요성이 증가했습니다. 2013년에 도입된 Docker는 개발자가 컨테이너를 표준화된 방식으로 구축하고 공유할 수 있도록 하여 이를 널리 활용 가능하게 만들었습니다. 그러나 하이브리드 멀티클라우드 환경 전반에서 수백 또는 수천 개의 컨테이너를 오케스트레이션하려면 이러한 복잡성을 관리할 수 있는 방법이 필요합니다. 따라서 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하기 위해 Kubernetes가 개발되었습니다.

2014년에 Google이 개발한 Kubernetes는 Cloud Native Computing Foundation(CNCF)이 유지 관리하는 오픈 소스 플랫폼입니다. AWS, Microsoft Azure, Google Cloud 및 IBM Cloud와 같은 주요 클라우드 공급자가 이 플랫폼을 지원합니다.

Kubernetes는 컨테이너를 파드에서 실행하며, 파드는 Kubernetes 클러스터의 노드 전반에 배포됩니다. 이는 애플리케이션 프로그래밍 인터페이스(API)를 통해 구성과 구성 요소 간 통신을 관리하며, 다양한 시스템 전반에서 자동화된 오케스트레이션을 지원합니다. 오늘날 Kubernetes는 컨테이너 오케스트레이션의 사실상 표준입니다.

데이터 스토리지 관점에서 Kubernetes 작동 방식을 이해하는 데 있어 중요한 요소는 상태 비저장 애플리케이션과 상태 저장 애플리케이션의 차이를 이해하는 것입니다. 상태 비저장 애플리케이션(예: API 요청을 처리하는 웹 서버)은 각 요청을 독립적으로 처리합니다. 따라서 세션 간 데이터를 유지하지 않습니다. 반면 상태 저장 애플리케이션(예: 데이터베이스)은 데이터를 유지하며 이전 상호작용의 정보를 기반으로 정상적으로 동작합니다.

또한 Kubernetes의 컨테이너와 파드는 일시적이며 언제든지 중지, 재시작 또는 재스케줄링될 수 있습니다. 상태 비저장 애플리케이션에서는 이러한 동작이 문제가 되지 않습니다. 그러나 상태 저장 애플리케이션에서는 컨테이너가 중지되면 내부에 저장된 데이터가 모두 손실됩니다. 이 지점에서 지속형 스토리지는 데이터와 컨테이너 수명 주기를 분리함으로써 컨테이너 환경에서 중요한 역할을 합니다.

기존 애플리케이션이 컨테이너로 이동하는 것과 더불어 데이터 집약적 워크로드인 데이터베이스, 인공지능(AI) 및 머신 러닝(ML)은 점점 더 클라우드 기반으로 전환되고 있습니다. 이러한 워크로드는 데이터가 컨테이너 종료 이후에도 유지되고 분산 시스템 내 상태를 유지하며, 모델 학습에 필요한 고처리량 및 낮은 지연 시간 성능을 제공하기 위해 지속형 스토리지를 필요로 합니다.

컨테이너용 지속형 스토리지는 데이터를 컨테이너로부터 분리하기 위해 함께 작동하는 구성 요소 집합으로 구축됩니다. Kubernetes에서는 관리자가 스토리지 인프라를 구성하고, 개발자와 애플리케이션은 간단한 요청을 통해 이를 액세스합니다.

구성 요소는 다음과 같습니다.

• 볼륨 및 바인드 마운트
• PersistentVolume(PV)
• PersistentVolumeClaim(PVC)
• 스토리지 클래스
• 컨테이너 스토리지 인터페이스(CSI)

컨테이너에 스토리지를 연결하는 주요 방법은 두 가지로, 바인드 마운트와 네임드 볼륨(예: Docker 볼륨)이 있습니다.

• 바인드 마운트는 호스트 머신의 특정 파일 또는 디렉터리를 컨테이너에 직접 연결합니다.

• 볼륨은 Kubernetes가 다양한 스토리지 시스템 전반에서 이를 관리하기 때문에 더 높은 유연성을 제공합니다.

볼륨은 파드 내 컨테이너에서 액세스할 수 있는 스토리지 위치입니다. 컨테이너 내부의 일시적 스토리지와 달리, 볼륨은 컨테이너가 중지되더라도 파드의 수명 동안 유지됩니다. 이는 동일한 파드 내에서 컨테이너가 실패 후 재시작되더라도 볼륨의 데이터가 계속 사용 가능함을 의미합니다.

볼륨은 로컬 디스크, Network File System(NFS)과 같은 프로토콜을 통한 네트워크 연결 스토리지, 또는 클라우드 기반 스토리지 서비스 등 다양한 유형의 스토리지 장치에 연결할 수 있습니다.

PersistentVolume은 Kubernetes 클러스터 내에서 스토리지를 제공하며 수동 또는 자동으로 생성됩니다.

일반 볼륨과 PersistentVolume의 주요 차이는 수명입니다. PersistentVolume은 어떤 파드와도 독립적으로 존재합니다. 이 구조에서는 해당 스토리지를 사용하는 파드가 삭제되거나 다른 머신으로 이동하더라도 데이터가 유지됩니다.

PersistentVolume은 이를 사용하는 파드와 별도의 수명 주기를 가집니다. 관리자는 특정 스토리지 용량과 읽기/쓰기 액세스 권한(예: 단일 파드 액세스를 위한 ReadWriteOnce 또는 공유 액세스를 위한 ReadWriteMany)으로 이를 구성할 수 있습니다.

PersistentVolumeClaim은 애플리케이션 또는 사용자가 요청하는 스토리지 요청입니다. 파드는 PersistentVolume에 직접 연결하는 대신 중간 계층으로 PersistentVolumeClaim을 사용합니다. 이 클레임은 필요한 스토리지 용량과 액세스 모드를 지정합니다. 이후 Kubernetes는 이를 사용 가능한 PersistentVolume과 매칭합니다. 이러한 분리는 개발자가 기본 스토리지 인프라를 이해하지 않아도 스토리지를 요청할 수 있음을 의미합니다.

클레임이 PersistentVolume에 연결되면 파드는 일반 파일 시스템과 동일하게 데이터를 읽고 쓸 수 있습니다. 파드가 이동되거나 재시작되더라도 동일한 클레임과 동일한 지속 데이터를 계속 액세스할 수 있습니다.

기업 환경에서는 각 애플리케이션마다 스토리지 볼륨을 수동으로 생성하는 것이 복잡하고 관리하기 어려워집니다. Kubernetes는 StorageClasses를 통해 이 문제를 해결하며, 이는 다양한 스토리지 유형(예: 고성능 솔리드 스테이트 드라이브)을 정의하고 프로비저너를 사용하여 필요 시 데이터 볼륨을 자동으로 생성합니다.

애플리케이션이 스토리지를 요청하고 StorageClass를 참조하면 Kubernetes는 수동 설정 없이 적절한 볼륨을 프로비저닝합니다. 이 기능은 전체 스토리지 관리를 간소화합니다.

컨테이너 스토리지 인터페이스(CSI)는 Kubernetes가 다양한 스토리지 시스템과 상호 작용할 수 있도록 하는 표준화된 벤더 중립 API입니다.

CSI는 스토리지 공급업체 플랫폼(예: IBM® Storage Fusion, NetApp)이 자체 플러그인을 독립적으로 개발하고 업데이트할 수 있도록 합니다. 이러한 플러그인은 볼륨 생성, 연결, 프로비저닝 및 제거를 포함한 전체 스토리지 라이프사이클을 관리합니다.

컨테이너용 지속형 스토리지는 조직이 컨테이너 환경에서 상태 저장 애플리케이션을 실행할 수 있도록 하며 다음과 같은 이점을 제공합니다.

• 데이터 내구성 및 복원력: 각 지속 볼륨에 기록된 데이터는 컨테이너 장애, 재시작 및 재스케줄링 이후에도 유지되어 데이터 손실을 방지하고, 기반 컨테이너 인프라가 변경되더라도 상태 저장 애플리케이션이 계속 안정적으로 유지되도록 합니다.

• 운영 간소화: 동적 프로비저닝과 자동화된 스토리지 관리는 수작업 부담을 줄입니다. 플랫폼 팀은 스토리지 정책을 한 번 정의하면 애플리케이션이 해당 네임스페이스 내에서 셀프 서비스 리소스로 스토리지를 사용할 수 있습니다.

• 고성능 및 확장성: 컨테이너용 지속형 스토리지는 AI/ML 학습 및 실시간 분석과 같은 데이터 집약적 워크로드에 필요한 처리량, 낮은 지연 시간 및 확장성을 제공합니다.

• 유연성 및 이식성: Kubernetes 퍼시스턴트 볼륨과 CSI 드라이버는 스토리지를 추상화하여 조직이 온프레미스 인프라, 프라이빗 클라우드 및 퍼블릭 클라우드 환경 전반에서 애플리케이션을 실행할 수 있도록 하며 하이브리드 클라우드 전략을 지원합니다.

• 보안 및 규정 준수: 기업용 스토리지 시스템을 기반으로 하는 퍼시스턴트 볼륨은 데이터 보호 기능을 제공하며, 여기에는 규정 준수 및 규제 요구사항 충족에 필요한 암호화, 복제 및 백업 기능이 포함됩니다.

• 비용 효율성: 동적 프로비저닝은 수요에 따라 스토리지를 확장하거나 축소하며, 자동화된 데이터 계층화는 자주 사용되지 않는 데이터를 비용 효율적인 스토리지 계층으로 이동시켜 조직이 비용을 최적화하도록 돕습니다.

• 공유 액세스: 컨테이너용 지속형 스토리지는 여러 파드가 동일한 데이터를 동시에 읽고 쓸 수 있도록 하여 스토리지 리소스를 중복하지 않고 협업 워크플로를 지원합니다.

조직은 다양한 툴과 솔루션을 통해 컨테이너용 지속형 스토리지에 액세스할 수 있습니다.

• 컨테이너 오케스트레이션 플랫폼
• 기업용 스토리지 솔루션
• 퍼블릭 클라우드 공급자 

컨테이너 오케스트레이션 플랫폼(예: Red Hat OpenShift)은 CSI 드라이버 및 동적 스토리지 프로비저닝에 대한 기본 지원과 함께 통합된 지속형 스토리지 관리 기능을 제공합니다.

이러한 플랫폼은 컨테이너화된 워크로드를 대규모로 운영하는 조직의 배포 및 운영을 간소화합니다.

기업용 스토리지 플랫폼(예: IBM Storage Fusion)은 스냅샷, 클로닝, 복제 및 재해 복구를 포함한 고급 데이터 서비스를 갖춘 컨테이너 네이티브 스토리지 솔루션을 제공합니다.

이러한 플랫폼은 CSI 드라이버를 통해 Kubernetes와 직접 통합되며, 상태 저장 애플리케이션을 위한 보안, 규정 준수 기능 및 공유 액세스 제어를 제공합니다.

AWS, Microsoft Azure, Google Cloud 및 IBM Cloud를 포함한 퍼블릭 클라우드 공급자는 Amazon Elastic Block Store(EBS) 및 IBM® Cloud Block Storage와 같은 기본 지속형 스토리지 옵션을 갖춘 관리형 Kubernetes 서비스를 제공합니다.

컨테이너용 지속형 스토리지는 다음과 같은 비즈니스 사용 사례를 지원합니다.

• 데이터베이스 및 데이터 관리
• AI 워크로드
• DevOps 및 CI/CD
• 백업 및 재해 복구(BDR)