인스턴스 스토어와 EBS 볼륨의 차이점은 무엇인가요?

Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스와 연결된 데이터를 저장하고 싶습니다. 인스턴스 스토어를 사용해야 하는지 아니면 연결된 Amazon Elastic Block Store(Amazon EBS) 볼륨을 사용해야 하는지 잘 모르겠습니다.

차이점

데이터를 영속적으로 저장하는 것이 가능합니다.

해결 방법

일부 Amazon EC2 인스턴스 유형은 직접 연결된 블록 디바이스 스토리지 형태인 인스턴스 스토어라는 스토리지를 제공합니다. 인스턴스 스토어를 임시 스토리지로 사용하세요. 인스턴스 스토어 볼륨에 저장된 데이터는 인스턴스 중지, 종료 또는 하드웨어 장애 시 유지되지 않습니다.

데이터를 장기적으로 유지하거나 암호화하려는 경우에는 Amazon EBS 볼륨을 사용하세요. EBS 볼륨에는 다음과 같은 특징이 있습니다.

EBS 볼륨은 인스턴스 중지 및 종료 시에도 데이터를 보존합니다. EBS 스냅샷으로 EBS 볼륨을 백업할 수 있습니다. 한 인스턴스에서 EBS 볼륨을 제거하고 다른 인스턴스에 다시 연결할 수 있습니다. EBS 볼륨은 전체 볼륨 암호화를 지원합니다. 의도하지 않은 변경이나 데이터 손실을 방지하려면 스냅샷을 자주 생성하는 것이 좋습니다. AWS Backup을 사용하여 스냅샷 생성을 자동화할 수 있습니다.

참고: Amazon EBS에서는 인스턴스의 루트 볼륨에 대한 DeleteOnTermination 속성이 기본적으로 true로 설정됩니다. 이 속성을 변경하지 않으면 인스턴스가 종료될 때 인스턴스의 루트 볼륨이 삭제됩니다

https://repost.aws/ko/knowledge-center/instance-store-vs-ebs

볼륨

컨테이너 내의 디스크에 있는 파일은 임시적이며, 컨테이너에서 실행될 때 애플리케이션에 적지 않은 몇 가지 문제가 발생한다. 한 가지 문제는 컨테이너가 크래시될 때 파일이 손실된다는 것이다. kubelet은 컨테이너를 다시 시작하지만 초기화된 상태이다. 두 번째 문제는 Pod에서 같이 실행되는 컨테이너간에 파일을 공유할 때 발생한다

Stateful한 애플리케이션을 관리하려면

파드 명세에 PV를 정의해서 직접 연결하는 것은 좋은 방법이 아닙니다.

Q. 왜 파드와 PV를 직접 연결하는 것이 좋지 않은가요?

파드와 PV(영구 볼륨)를 직접 연결하는 것은 보통 권장되지 않습니다. 이는 파드와 PV 간의 결합을 느슨하게 유지하여 애플리케이션을 더 유연하게 관리하기 위함입니다. 다음은 파드와 PV를 직접 연결하는 것이 권장되지 않는 이유입니다:

결합도와 유연성: 파드와 PV를 직접 연결하면 파드가 특정 PV에 종속되어 해당 PV를 사용할 수 있는 파드에만 스케줄링될 수 있습니다. 이는 파드의 결합도를 높이고 유연성을 제한할 수 있습니다. 만약 다른 PV로 마이그레이션하려는 경우, 모든 파드를 다시 스케줄링해야 할 수도 있습니다.

리소스 활용: 파드와 PV를 분리함으로써 여러 파드가 동일한 PV를 공유할 수 있습니다. 이는 리소스 활용을 향상시킬 수 있습니다. 예를 들어, 여러 파드가 동일한 PV를 통해 데이터를 읽고 쓸 수 있으며, PV의 용량을 최대한 활용할 수 있습니다.

스토리지 관리: PV를 중앙에서 관리하고 파드는 스토리지에 대한 세부 사항을 알 필요가 없도록 분리하는 것이 유리합니다. 이를 통해 스토리지 관리 및 유지보수 작업을 보다 효율적으로 수행할 수 있습니다. PV를 독립적으로 관리하면 스토리지 클래스, 볼륨 스냅샷, 보안 등과 같은 스토리지 관련 기능을 쉽게 구성하고 관리할 수 있습니다.

호환성과 이식성: 파드와 PV 사이의 중간 계층인 볼륨 추상화 계층을 유지함으로써, 다양한 스토리지 백엔드와의 호환성 및 이식성을 갖출 수 있습니다. PV가 파드와 직접 결합되지 않으면 클라우드 공급자나 스토리지 시스템 변경 시에도 애플리케이션을 쉽게 이식하고 업그레이드할 수 있습니다.

요약하면, 파드와 PV를 직접 연결하는 것은 결합도를 높이고 유연성을 제한할 수 있으며, 리소스 활용과 스토리지 관리의 효율성을 저하시킬 수 있습니다.

이때 이러한 의존도를 줄이기 위해, 퍼시스턴스 볼륨 클레임(Persistence Volume Claim, 이하 PVC)을 이용하여 PV와 연결합니다. PVC는 파드가 볼륨의 세부 사항을 몰라도 볼륨을 사용할 수 있게 도와줍니다.

PV는 실제로 데이터가 저장되는 공간입니다. PVC는 PV를 선택, 연결해 주는 요청 그 자체입니다.

Q. PVC는 어떻게 작동되나요?

이 문서에서는 수명이 긴 데이터가 필요한 애플리케이션을 위한 클러스터 범위의 영구 스토리지를 관리하기 위한 모델을 제안합니다.

PV는 클러스터 리소스이다. PVC는 해당 리소스에 대한 요청이며 리소스에 대한 클레임 검사 역할을 한다. PV와 PVC 간의 상호 작용은 다음 라이프사이클을 따른다.

추상적인 두 가지 새로운 API 종류:

A PersistentVolume(PV)는 관리자가 프로비저닝한 스토리지 리소스입니다. 노드와 유사합니다. 사용 방법은 Persistent Volume Guide를 참조하십시오 .

A PersistentVolumeClaim(PVC)는 포드에서 사용할 영구 볼륨에 대한 사용자의 요청입니다. pod와 유사합니다.

클러스터 관리자는 스토리지클래스(StorageClasses)를 사용하여 동적 프로비저닝을 설정할 수도 있다. 파드는 퍼시스턴트볼륨클레임을 사용하여 물리적인 스토리지를 요청한다. 퍼시스턴트볼륨에 자동으로 바인딩

파드는 클레임을 볼륨으로 사용한다. 클러스터는 클레임을 검사하여 바인딩된 볼륨을 찾고 해당 볼륨을 파드에 마운트한다. 여러 접근 모드를 지원하는 볼륨의 경우 사용자는 자신의 클레임을 파드에서 볼륨으로 사용할 때 원하는 접근 모드를 지정한다.

일단 사용자에게 클레임이 있고 그 클레임이 바인딩되면, 바인딩된 PV는 사용자가 필요로 하는 한 사용자에게 속한다. 사용자는 파드의 volumes 블록에 persistentVolumeClaim을 포함하여 파드를 스케줄링하고 클레임한 PV에 접근한다. 이에 대한 자세한 내용은 볼륨으로 클레임하기를 참고하길 바란다.

https://github.com/kubernetes/design-proposals-archive/blob/main/storage/persistent-storage.md

https://kubernetes.io/ko/docs/concepts/storage/persistent-volumes/