기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

스토리지

개요

단기 또는 장기적으로 데이터를 보존해야 하는 애플리케이션을 실행하려는 시나리오가 있습니다. 이러한 사용 사례의 경우 포드가 볼륨을 정의하고 탑재하여 컨테이너가 다양한 스토리지 메커니즘을 활용할 수 있도록 할 수 있습니다. Kubernetes는 임시 및 영구 스토리지를 위해 다양한 유형의 볼륨을 지원합니다. 스토리지 선택은 주로 애플리케이션 요구 사항에 따라 달라집니다. 각 접근 방식에는 비용에 영향을 미치며, 아래에 설명된 관행은 EKS 환경에서 일종의 스토리지가 필요한 워크로드에 대한 비용 효율성을 달성하는 데 도움이 됩니다.

임시 볼륨

임시 볼륨은 일시적인 로컬 볼륨이 필요하지만 재시작 후 데이터를 유지할 필요가 없는 애플리케이션을 위한 것입니다. 여기에는 스크래치 공간, 캐싱, 구성 데이터 및 보안 암호와 같은 읽기 전용 입력 데이터에 대한 요구 사항이 포함됩니다. Kubernetes 임시 볼륨에 대한 자세한 내용은 여기에서 확인할 수 있습니다. 대부분의 임시 볼륨(예: emptyDir, configMap, downwardAPI, secret, hostpath)은 로컬에 연결된 쓰기 가능한 디바이스(일반적으로 루트 디스크) 또는 RAM으로 지원되므로 가장 비용 효율적이고 성능이 뛰어난 호스트 볼륨을 선택하는 것이 중요합니다.

EBS 볼륨 사용

호스트 루트 볼륨으로 gp3로 시작하는 것이 좋습니다. Amazon EBS에서 제공하는 최신 범용 SSD 볼륨이며 gp2 볼륨에 비해 GB당 더 저렴한 가격(최대 20%)을 제공합니다.

Amazon EC2 인스턴스 스토어 사용

Amazon EC2 인스턴스 스토어는 EC2 인스턴스에 임시 블록 수준 스토리지를 제공합니다. EC2 인스턴스 스토어에서 제공하는 스토리지는 호스트에 물리적으로 연결된 디스크를 통해 액세스할 수 있습니다. Amazon EBS와 달리 인스턴스가 시작될 때만 인스턴스 스토어 볼륨을 연결할 수 있으며, 이러한 볼륨은 인스턴스 수명 동안에만 존재합니다. 분리하여 다른 인스턴스에 다시 연결할 수 없습니다. Amazon EC2 인스턴스 스토어에 대한 자세한 내용은 여기에서 확인할 수 있습니다. 인스턴스 스토어 볼륨과 관련된 추가 요금은 없습니다. 이렇게 하면 EBS 볼륨이 큰 일반 EC2 인스턴스보다 (인스턴스 스토어 볼륨)가 더 비용 효율적입니다.

Kubernetes에서 로컬 스토어 볼륨을 사용하려면 볼륨을 포드 사양에서 HostPath로 마운트할 수 있도록 Amazon EC2 사용자 데이터를 사용하여 디스크를 분할, 구성 및 포맷해야 합니다. 또는 Local Persistent Volume Static Provisioner를 활용하여 로컬 스토리지 관리를 간소화할 수 있습니다. 로컬 영구 볼륨 정적 프로비저너를 사용하면 표준 Kubernetes PersistentVolumeClaim(PVC) 인터페이스를 통해 로컬 인스턴스 스토어 볼륨에 액세스할 수 있습니다. 또한 노드 선호도 정보가 포함된 PersistentVolumes(PVs)을 프로비저닝하여 포드를 올바른 노드로 예약합니다. Kubernetes PersistentVolumes를 사용하지만 EC2 인스턴스 스토어 볼륨은 본질적으로 일시적입니다. 임시 디스크에 기록된 데이터는 인스턴스 수명 동안에만 사용할 수 있습니다. 인스턴스가 종료되면 데이터도 마찬가지입니다. 자세한 내용은이 블로그를 참조하세요.

Amazon EC2 인스턴스 스토어 볼륨을 사용할 때 총 IOPS 한도는 호스트와 공유되며 특정 호스트에 포드를 바인딩합니다. Amazon EC2 인스턴스 스토어 볼륨을 채택하기 전에 워크로드 요구 사항을 철저히 검토해야 합니다.

영구 볼륨

Kubernetes는 일반적으로 상태 비저장 애플리케이션을 실행하는 것과 관련이 있습니다. 그러나 한 요청에서 다음 요청으로 영구 데이터 또는 정보를 보존해야 하는 마이크로서비스를 실행하려는 시나리오가 있습니다. 데이터베이스는 이러한 사용 사례의 일반적인 예입니다. 그러나 포드와 포드 내의 컨테이너 또는 프로세스는 본질적으로 일시적입니다. 포드의 수명을 초과하여 데이터를 유지하려면 PVs 사용하여 포드와 독립적인 특정 위치에서 스토리지에 대한 액세스를 정의할 수 있습니다. PVs와 관련된 비용은 사용 중인 스토리지 유형과 애플리케이션이 이를 사용하는 방식에 따라 크게 달라집니다.

여기에 나열된 Amazon EKS에서 Kubernetes PVs 지원하는 다양한 유형의 스토리지 옵션이 있습니다. 아래에서 다루는 스토리지 옵션은 Amazon EBS, Amazon EFS, Amazon FSx for Lustre, Amazon FSx for NetApp ONTAP입니다.

Amazon Elastic Block Store(EBS) 볼륨

Amazon EBS 볼륨을 Kubernetes PVs을 제공할 수 있습니다. 이는 임의 읽기 및 쓰기와 길고 지속적인 읽기 및 쓰기를 수행하는 처리량 집약적인 애플리케이션에 의존하는 데이터베이스에 적합합니다. Amazon Elastic Block Store 컨테이너 스토리지 인터페이스(CSI) 드라이버를 사용하면 Amazon EKS 클러스터가 영구 볼륨에 대한 Amazon EBS 볼륨의 수명 주기를 관리할 수 있습니다. 컨테이너 스토리지 인터페이스는 Kubernetes와 스토리지 시스템 간의 상호 작용을 활성화하고 용이하게 합니다. CSI 드라이버가 EKS 클러스터에 배포되면 영구 볼륨(PVs), 영구 볼륨 클레임(PVCs), 스토리지 클래스(SCs. 이 링크는 Amazon EBS CSI 드라이버를 사용하여 Amazon EBS 볼륨과 상호 작용하는 방법에 대한 실제 예제를 제공합니다.

올바른 볼륨 선택

가격과 성능 간에 적절한 균형을 제공하므로 최신 세대의 블록 스토리지(gp3)를 사용하는 것이 좋습니다. 또한 추가 블록 스토리지 용량을 프로비저닝할 필요 없이 볼륨 크기와 관계없이 볼륨 IOPS 및 처리량을 조정할 수 있습니다. 현재 gp2 볼륨을 사용하는 경우 gp3 볼륨으로 마이그레이션하는 것이 좋습니다. 블로그 게시물 gp2에서 gp3 EBS 볼륨으로 Amazon EKS 클러스터 마이그레이션에서는 애플리케이션 가동 중지가 필요한 CSI 볼륨 스냅샷 기능을 사용하여 백업 및 복원을 통해 Amazon EKS 클러스터의 gp2에서 gp3로 마이그레이션하는 방법을 설명합니다.

Amazon EBS를 사용하면 볼륨 크기, IOPS 및 처리량과 같은 볼륨 특성을 온라인으로 변경할 수 있습니다. 이 기능을 사용하면이 블로그에 설명된 대로 EBS CSI 드라이버 v1.19.0+를 사용하거나 여기에 설명된 VolumeAttributesClass API를 사용하여 Amazon EKS v1.31 및 EBS CSI 드라이버 1.35로 시작하는 PVC 주석을 사용하여 애플리케이션 가동 중지 없이 gp3의 gp2에서 마이그레이션할 수 있습니다.

더 높은 성능이 필요하고 단일 gp3 볼륨이 지원할 수 있는 것보다 더 큰 볼륨이 필요한 애플리케이션이 있는 경우 io2 블록 익스프레스를 사용하는 것이 좋습니다. 이러한 유형의 스토리지는 SAP HANA 또는 지연 시간이 짧은 기타 대규모 데이터베이스와 같은 가장 크고 가장 많은 I/O 집약적이며 미션 크리티컬한 배포에 적합합니다. 인스턴스의 EBS 성능은 인스턴스의 성능 제한에 따라 제한되므로 모든 인스턴스가 io2 블록 Express 볼륨을 지원하는 것은 아닙니다. 이 문서에서 지원되는 인스턴스 유형 및 기타 고려 사항을 확인할 수 있습니다.

단일 gp3 볼륨은 최대 16,000 IOPS, 최대 1,000MiB/s 처리량, 최대 16TiB를 지원할 수 있습니다. 최대 256,000 IOPS, 4,000MiB/s, 처리량 및 64TiB를 제공하는 최신 세대의 프로비저닝된 IOPS SSD 볼륨입니다.

이러한 옵션 중에서 애플리케이션의 요구 사항에 맞게 스토리지 성능과 비용을 가장 잘 조정해야 합니다.

시간 경과에 따른 모니터링 및 최적화

애플리케이션의 기준 성능을 이해하고 선택한 볼륨에 대해 모니터링하여 애플리케이션이 요구 사항/기대치를 충족하는지 또는 과다 프로비저닝되었는지(예: 프로비저닝된 IOPS가 완전히 활용되지 않는 시나리오) 확인하는 것이 중요합니다.

대용량 볼륨을 처음부터 할당하는 대신 데이터를 누적할 때 볼륨 크기를 점진적으로 늘릴 수 있습니다. Amazon Elastic Block Store CSI 드라이버(aws-ebs-csi-driver)의 볼륨 크기 조정 기능을 사용하여 볼륨 크기를 동적으로 조정할 수 있습니다. EBS 볼륨 크기만 늘릴 수 있다는 점에 유의하세요.

매달린 EBS 볼륨을 식별하고 제거하려면 AWS 신뢰할 수 있는 어드바이저의 비용 최적화 범주를 사용할 수 있습니다. 이 기능을 사용하면 연결되지 않은 볼륨 또는 일정 기간 동안 쓰기 활동이 매우 적은 볼륨을 식별할 수 있습니다. 라이브 Kubernetes 클러스터를 스캔하고 배포된 리소스 및 구성과 관련된 잠재적 문제를 보고하는 Popeye라는 클라우드 네이티브 오픈 소스 읽기 전용 도구가 있습니다. 예를 들어 미사용 PVs 및 PVCs를 스캔하고 경계가 있는지 또는 볼륨 마운트 오류가 있는지 확인할 수 있습니다.

모니터링에 대한 자세한 내용은 EKS 비용 최적화 관찰성 가이드를 참조하세요.

고려할 수 있는 또 다른 옵션은 AWS Compute Optimizer Amazon EBS 볼륨 권장 사항입니다. 이 도구는 최적의 볼륨 구성과 필요한 올바른 성능 수준을 자동으로 식별합니다. 예를 들어 지난 14일 동안의 최대 사용률을 기반으로 프로비저닝된 IOPS, 볼륨 크기 및 EBS 볼륨 유형과 관련된 최적의 설정에 사용할 수 있습니다. 또한 권장 사항에서 파생된 잠재적 월별 비용 절감액도 정량화합니다. 자세한 내용은이 블로그를 참조하세요.

백업 보관 정책

point-in-time 스냅샷을 생성하여 Amazon EBS 볼륨에 데이터를 백업할 수 있습니다. Amazon EBS CSI 드라이버는 볼륨 스냅샷을 지원합니다. 여기에 설명된 단계를 사용하여 스냅샷을 생성하고 EBS PV를 복원하는 방법을 배울 수 있습니다.

후속 스냅샷은 증분 백업입니다. 즉, 가장 최근 스냅샷 이후에 변경된 디바이스의 블록만 저장됩니다. 그러면 스냅샷을 만드는 데 필요한 시간이 최소화되며 데이터를 복제하지 않으므로 스토리지 비용이 절약됩니다. 그러나 적절한 보존 정책 없이 이전 EBS 스냅샷 수를 늘리면 대규모로 운영할 때 예상치 못한 비용이 발생할 수 있습니다. AWS API를 통해 Amazon EBS 볼륨을 직접 백업하는 경우 Amazon Elastic Block Store(EBS) 스냅샷 및 EBS 지원 Amazon Machine Image(AMI)에 대한 자동화된 정책 기반 수명 주기 관리 솔루션을 제공하는 Amazon Data Lifecycle ManagerAMIs. 콘솔을 사용하면 EBS 스냅샷 및 AMIs.

Kubernetes 환경에서는 Velero라는 오픈 소스 도구를 활용하여 EBS 영구 볼륨을 백업할 수 있습니다. 백업 만료 작업을 예약할 때 TTL 플래그를 설정할 수 있습니다. 다음은 Velero의 예제 가이드입니다.

Amazon Elastic File System(EFS)

Amazon Elastic File System(EFS)은 광범위한 워크로드 및 애플리케이션에 대해 표준 파일 시스템 인터페이스 및 파일 시스템 의미 체계를 사용하여 파일 데이터를 공유할 수 있는 서버리스의 완전 탄력적 파일 시스템입니다. 워크로드 및 애플리케이션의 예로는 Wordpress 및 Drupal, JIRA 및 Git과 같은 개발자 도구, Jupyter와 같은 공유 노트북 시스템, 홈 디렉터리 등이 있습니다.

Amazon EFS의 주요 이점 중 하나는 여러 노드와 여러 가용 영역에 분산된 여러 컨테이너에서 탑재할 수 있다는 것입니다. 또 다른 이점은 사용하는 스토리지에 대해서만 비용을 지불한다는 것입니다. 파일을 추가 및 제거하면 EFS 파일 시스템이 자동으로 확장 및 축소되므로 용량 계획이 필요하지 않습니다.

Kubernetes에서 Amazon EFS를 사용하려면 Amazon Elastic File System Container Storage Interface(CSI) 드라이버인 aws-efs-csi-driver 사용해야 합니다. 현재 드라이버는 액세스 포인트를 동적으로 생성할 수 있습니다. 그러나 Amazon EFS 파일 시스템을 먼저 프로비저닝하고 Kubernetes 스토리지 클래스 파라미터에 대한 입력으로 제공해야 합니다.

올바른 EFS 스토리지 클래스 선택

Amazon EFS는 네 가지 스토리지 클래스를 제공합니다.

두 가지 표준 스토리지 클래스:

두 개의 단일 영역 스토리지 클래스:

Infrequent Access(IA) 스토리지 클래스는 매일 액세스하지 않는 파일에 대해 비용이 최적화됩니다. Amazon EFS 수명 주기 관리를 사용하면 수명 주기 정책 기간(7, 14, 30, 60 또는 90일) 동안 액세스하지 않은 파일을 IA 스토리지 클래스로 이동할 수 있으므로 EFS Standard 및 EFS One Zone 스토리지 클래스에 비해 스토리지 비용을 각각 최대 92% 절감할 수 있습니다.

EFS Intelligent-Tiering을 사용하면 수명 주기 관리가 파일 시스템의 액세스 패턴을 모니터링하고 파일을 가장 최적의 스토리지 클래스로 자동으로 이동합니다.

Amazon FSx for Lustre

Lustre는 최대 수백 GB/s의 처리량과 작업당 밀리초 미만의 지연 시간이 필요한 워크로드에 일반적으로 사용되는 고성능 병렬 파일 시스템입니다. 기계 학습 훈련, 금융 모델링, HPC 및 비디오 처리와 같은 시나리오에 사용됩니다. Amazon FSx for Lustre는 Amazon S3와 원활하게 통합된 확장성과 성능을 갖춘 완전관리형 공유 스토리지를 제공합니다.

Amazon EKS의 FSx for Lustre CSI 드라이버 또는 AWS의 자체 관리형 Kubernetes 클러스터를 사용하여 FSx for Lustre에서 지원하는 Kubernetes 영구 스토리지 볼륨을 사용할 수 있습니다. 자세한 내용과 예제는 Amazon EKS 설명서를 참조하세요.

Amazon S3에 대한 링크

Amazon S3에 있는 내구성이 뛰어난 장기 데이터 리포지토리를 FSx for Lustre 파일 시스템과 연결하는 것이 좋습니다. 연결된 대용량 데이터 세트는 필요에 따라 Amazon S3에서 FSx for Lustre 파일 시스템으로 지연 로드됩니다. 분석 및 결과를 S3로 다시 실행한 다음 Lustre 파일 시스템을 삭제할 수도 있습니다.

올바른 배포 및 스토리지 옵션 선택

FSx for Lustre는 다양한 배포 옵션을 제공합니다. 첫 번째 옵션은 스크래치라고 하며 데이터를 복제하지 않고, 두 번째 옵션은 영구적이라고 하며, 이름에서 알 수 있듯이 데이터가 유지됩니다.

첫 번째 옵션(스크래치)을 사용하여 일시적인 단기 데이터 처리 비용을 줄일 수 있습니다. 영구 배포 옵션은 AWS 가용 영역 내에서 데이터를 자동으로 복제하는 장기 스토리지를 위해 설계되었습니다. 또한 SSD 및 HDD 스토리지를 모두 지원합니다.

FSx for lustre 파일 시스템의 Kubernetes StorageClass의 파라미터에서 원하는 배포 유형을 구성할 수 있습니다. 다음은 샘플 템플릿을 제공하는 링크입니다.

데이터 압축 활성화

"LZ4"를 데이터 압축 유형으로 지정하여 파일 시스템에서 데이터 압축을 활성화할 수도 있습니다. 활성화되면 새로 작성된 모든 파일은 디스크에 기록되기 전에 FSx for Lustre에서 자동으로 압축되고 읽을 때 압축되지 않습니다. LZ4 데이터 압축 알고리즘은 손실이 없으므로 압축된 데이터에서 원본 데이터를 완전히 재구성할 수 있습니다.

FSx for lustre 파일 시스템의 Kubernetes StorageClass의 파라미터에서 데이터 압축 유형을 LZ4로 구성할 수 있습니다. 값이 기본값인 NONE으로 설정되면 압축이 비활성화됩니다. 이 링크는 샘플 템플릿을 제공합니다.

Amazon FSx for NetApp ONTAP

Amazon FSx for NetApp ONTAP은 NetApp의 ONTAP 파일 시스템에 구축된 완전 관리형 공유 스토리지입니다. FSx for ONTAP은 AWS 또는 온프레미스에서 실행되는 Linux, Windows 및 macOS 컴퓨팅 인스턴스에서 광범위하게 액세스할 수 있는 기능이 풍부하고 빠르고 유연한 공유 파일 스토리지를 제공합니다.

Amazon FSx for NetApp ONTAP은 1/프라이머리 티어와 2/용량 풀 티어의 두 가지 스토리지 티어를 지원합니다.

기본 계층은 지연 시간에 민감한 활성 데이터를 위한 프로비저닝된 고성능 SSD 기반 계층입니다. 완전 탄력적 용량 풀 계층은 자주 액세스하지 않는 데이터에 대해 비용 최적화되고, 데이터가 계층화되면 자동으로 확장되며, 사실상 무제한 페타바이트의 용량을 제공합니다. 용량 풀 스토리지에서 데이터 압축 및 중복 제거를 활성화하고 데이터가 소비하는 스토리지 용량을 추가로 줄일 수 있습니다. NetApp의 기본 정책 기반 FabricPool 기능은 데이터 액세스 패턴을 지속적으로 모니터링하여 스토리지 계층 간에 양방향으로 데이터를 자동으로 전송하여 성능과 비용을 최적화합니다.

NetApp의 Astra Trident는 Amazon EKS 클러스터가 Amazon FSx for NetApp ONTAP 파일 시스템이 지원하는 영구 볼륨 PVs의 수명 주기를 관리할 수 있도록 CSI 드라이버를 사용하여 동적 스토리지 오케스트레이션을 제공합니다. 시작하려면 Astra Trident 설명서의 Amazon FSx for NetApp ONTAP에서 Astra Trident 사용을 참조하세요.

기타 고려 사항

컨테이너 이미지 크기 최소화

컨테이너가 배포되면 컨테이너 이미지가 호스트에 여러 계층으로 캐시됩니다. 이미지 크기를 줄이면 호스트에 필요한 스토리지 양을 줄일 수 있습니다.

처음부터 스크래치 이미지 또는 무분별한 컨테이너 이미지(애플리케이션 및 런타임 종속성만 포함)와 같은 축소된 기본 이미지를 사용하면 공격 표면적 감소 및 이미지 풀 타임 단축과 같은 다른 보조 이점 외에도 스토리지 비용을 절감할 수 있습니다.

또한 Slim.ai 같은 오픈 소스 도구를 사용하면 최소한의 이미지를 쉽고 안전하게 생성할 수 있습니다.

패키지, 도구, 애플리케이션 종속성, 라이브러리의 여러 계층이 컨테이너 이미지 크기를 쉽게 팽창시킬 수 있습니다. 다단계 빌드를 사용하면 최종 이미지에서 필요하지 않은 모든 것을 제외하고 한 단계에서 다른 단계로 아티팩트를 선택적으로 복사할 수 있습니다. 여기에서 더 많은 이미지 빌드 모범 사례를 확인할 수 있습니다.

또 다른 고려 사항은 캐시된 이미지를 얼마나 오래 유지할지입니다. 일정량의 디스크를 사용할 때 이미지 캐시에서 오래된 이미지를 정리할 수 있습니다. 이렇게 하면 호스트 작업에 충분한 공간이 있는지 확인하는 데 도움이 됩니다. 기본적으로 kubelet은 5분마다 미사용 이미지에 대해 가비지 수집을 수행하고 1분마다 미사용 컨테이너에 대해 가비지 수집을 수행합니다.

미사용 컨테이너 및 이미지 가비지 수집에 대한 옵션을 구성하려면 구성 파일을 사용하여 kubelet을 조정하고 KubeletConfiguration 리소스 유형을 사용하여 가비지 수집과 관련된 파라미터를 변경합니다.

이에 대한 자세한 내용은 Kubernetes 설명서에서 확인할 수 있습니다.