다음을 통해 공유

AKS(Azure Kubernetes Service)에 대한 스토리지 고려 사항

이 문서에서는 AKS(Azure Kubernetes Service) 워크로드에 가장 효과적인 스토리지 옵션을 선택하고 구현하는 방법을 설명합니다. 올바른 스토리지 솔루션을 선택하는 것은 Kubernetes 환경에서 최적의 애플리케이션 성능, 안정성 및 비용 효율성을 달성하는 데 중요합니다.

Azure Kubernetes Service는 상태 없음 및 상태 저장 워크로드를 모두 지원합니다. 상태 저장 애플리케이션을 배포할 때 애플리케이션 상태를 유지하기 위해 적절한 스토리지 솔루션이 필요합니다. AKS는 관리되는 데이터베이스, 디스크(블록 스토리지), 파일 및 Blob(개체) 스토리지를 비롯한 여러 네이티브 스토리지 옵션과 통합됩니다. 각 옵션은 다양한 워크로드 요구 사항을 해결하기 위해 다양한 성능 특성, 가용성 보장 및 비용 구조를 제공합니다.

적합한 스토리지 서비스 선택

AKS 워크로드에 적합한 스토리지 솔루션을 선택하면 성능, 안정성 및 비용 효율성에 영향을 줍니다. 다음 지침을 사용하여 데이터 요구 사항에 따라 적절한 스토리지 서비스를 선택합니다.

데이터 형식 권장 스토리지 서비스 이 서비스를 사용하는 경우
구조적 데이터 관리되는 데이터베이스(Azure SQL, Azure Database for MySQL, Azure Database for PostgreSQL, Azure Cosmos DB) 기본 인프라를 관리하지 않고 기본 제공 고가용성, 자동 백업 및 확장성이 필요한 관계형 또는 NoSQL 데이터의 경우
구조화되지 않은 데이터 Azure Blob Storage SDK, NFS 프로토콜 또는 BlobFuse를 통해 HTTP/REST 기반 액세스가 필요한 미디어 파일, 문서 및 로그와 같은 대량의 개체 데이터의 경우
공유 파일 데이터(고성능) Azure NetApp Files 또는 Azure Files Premium 하위 밀리초 대기 시간(Azure NetApp Files) 또는 일관된 한 자리 밀리초 대기 시간(Azure Files Premium) 요구 사항을 사용하여 공유 파일 액세스
공유 구성 데이터 Azure Files Standard 보통 성능 요구 사항이 있는 구성 파일, 공유 애플리케이션 상태 및 기타 데이터의 경우
데이터베이스 및 트랜잭션 워크로드 Azure Managed Disks (Premium SSD, Premium SSD v2, Ultra Disk) 특정 IOPS 및 처리량 보장이 있는 전용 고성능 블록 스토리지가 필요한 상태 저장 애플리케이션의 경우
순간적인, 임시 데이터 임시 디스크 Pod 또는 노드 다시 시작 사이에 유지할 필요가 없는 임시 데이터의 경우

최종 스토리지 결정을 내리기 전에 실제 워크로드를 사용하여 개념 증명 테스트를 통해 성능 요구 사항을 평가합니다. AKS의 모든 스토리지 트래픽은 네트워크를 통해 이동하므로 노드에 애플리케이션 및 스토리지 트래픽을 모두 처리하기에 충분한 네트워크 대역폭이 있는지 확인합니다.

디자인 고려 사항

AKS용 스토리지를 디자인하기 위한 고려 사항은 다음과 같습니다. AKS 환경에서 스토리지가 필요한 위치를 고려하고 각 요구 사항에 가장 적합한 솔루션을 결정합니다.

OS(운영 체제) 디스크

운영 체제(OS) 디스크의 경우 다음 요소를 고려합니다.

  • OS용 임시 디스크입니다. Azure의 각 VM(가상 머신)에는 OS용 디스크가 필요합니다. Kubernetes 노드는 임시 노드이므로 AKS는 기본적으로 지원되는 VM 크기에서 임시 OS 디스크를 사용합니다. 임시 OS 디스크에 대한 자세한 내용은 임시 OS를 참조하세요.

  • OS용 관리 디스크입니다. 워크로드에 필요한 경우 AKS 클러스터의 노드에 대해 일반 관리 디스크를 대신 사용할 수 있습니다. 이렇게 하면 OS 드라이브에 영구 데이터가 필요한 워크로드가 지원됩니다. 영구 스토리지 옵션에 대한 자세한 내용은 AKS(Azure Kubernetes Service)의 애플리케이션에 대한 스토리지 옵션을 참조하세요.

  • 관리 디스크 크기 조정 관리 디스크를 OS 디스크로 선택하는 경우 OS, Kubernetes 시스템 및 워크로드의 요구 사항을 지원하도록 크기를 조정해야 합니다. 옵션 및 차이점에 대한 자세한 내용은 Azure 관리 디스크 유형을 참조하세요.

애플리케이션 데이터

일부 워크로드에는 애플리케이션 데이터 스토리지에 일관된 데이터 저장소가 필요합니다. 애플리케이션에 데이터베이스가 필요한 경우 다음 옵션을 포함하는 Azure에서 관리되는 데이터베이스를 탐색하는 것이 좋습니다.

AKS의 스토리지 솔루션

관리되는 데이터베이스가 애플리케이션의 요구 사항을 충족하지 않는 경우 AKS에서 사용할 수 있는 다른 스토리지 옵션을 사용하여 일관된 데이터를 저장하는 것이 좋습니다. 옵션에는 디스크 기반 솔루션, 임시 디스크, 파일 기반 솔루션, Blob Storage 및 이 문서에서 다루지 않는 기타 옵션이 포함됩니다.

디스크 기반 솔루션

디스크 또는 블록 스토리지는 원시 블록 기반 디바이스에 직접 데이터를 저장하는 데 적합합니다. 디스크 기반 스토리지는 Kubernetes 클러스터가 호스트하는 데이터베이스에 대한 데이터를 저장하는 데 적합합니다. Azure에서 관리 디스크는 블록 기반 스토리지를 가져오는 솔루션입니다.

임시 디스크 솔루션

애플리케이션에 비영구적 임시 스토리지가 필요한지 또는 스토리지 최적화 VM에서 고성능 드라이브를 사용하려는 위치를 고려합니다. 임시 볼륨에 연결하려면 Kubernetes의 emptyDir 옵션 또는 CSI 임시 로컬 볼륨에 대한 드라이버를 사용할 수 있습니다. 임시 데이터, 예를 들어 스크래치 공간에는 emptyDir를 사용하는 것을 추천합니다. 스토리지 최적화 VM 시리즈의 스토리지의 경우 임시 로컬 볼륨과 함께 CSI를 사용하는 것이 좋습니다. CSI 드라이버에 대한 자세한 내용은 AKS(Azure Kubernetes Service)의 CSI(Container Storage Interface) 드라이버를 참조하세요.

Azure 컨테이너 스토리지 (Azure Container Storage)

Azure Container Storage는 기본적으로 컨테이너용으로 구축된 클라우드 기반 볼륨 관리, 배포 및 오케스트레이션 서비스입니다. ReadWriteOnce 모드에서 Azure Disks, Ephemeral Disk 또는 Azure Elastic SAN을 사용하여 블록 기반 스토리지를 사용하려는 경우 Azure Container Storage는 CSI 드라이버를 직접 사용하는 데 비해 이점을 제공합니다.

  • 가격 대비 성능 향상: 여러 PC에서 단일 디스크를 공유하여 과잉 프로비전을 줄이고 비용을 절감합니다.
  • 더 높은 PV 규모: CSI 드라이버로 64-PV 제한을 대체하는 노드당 최대 75개의 PV를 지원합니다.
  • 복제를 사용하는 로컬 NVMe: 임시 디스크에 대해 하위 밀리초 대기 시간 및 복원력을 사용하도록 설정하며 Cassandra와 같은 기본 제공 복제가 있는 워크로드에 적합합니다.
  • 더 빠른 프로비전 및 크기 조정: 일괄 처리 작업은 직렬 CSI 드라이버 작업에 비해 볼륨 프로비전 및 크기 조정 속도를 향상합니다.

자세한 내용은 Azure Container Storage란?

파일 기반 솔루션

귀하의 포드가 공유 파일 시스템에 액세스할 필요가 있는지 확인하십시오. Kubernetes 클러스터의 여러 Pod가 읽고 공유해야 하는 애플리케이션 및 구성 데이터에 공유 파일 시스템을 사용합니다. 파일 스토리지는 NFS 또는 SMB/CIFS(공용 인터넷 파일 시스템) 프로토콜을 통해 공유 파일 시스템을 제공합니다. Azure는 파일 기반 스토리지에 대한 두 가지 솔루션인 Azure Files 및 Azure NetApp Files를 제공합니다.

Azure Files

Azure Files의 경우 다음 옵션을 고려합니다.

  • 정적 또는 동적으로 만든 파일 공유입니다. AKS 외부에서 만드는 정적 파일 공유 또는 AKS가 사용자를 대신하여 동적으로 만드는 파일 공유를 사용하는 것이 좋습니다. 자세한 내용은 다음을 참조하세요.

  • 표준 또는 프리미엄 성능. 표준 성능이 충분한지 또는 Azure Files의 프리미엄 성능이 필요한지 평가합니다.

  • SMB/CIFS 또는 NFS. Azure Files에 액세스하려면 워크로드가 기본 프로토콜인 SMB/CIFS에 API를 사용해야 하는지 또는 워크로드에 NFS 지원이 필요한지 평가합니다.

  • 액세스를 위한 네트워크 모델입니다. Azure Files에 액세스하는 데 사용하려는 네트워크 모델( 직접 공용 IP 주소, 서비스 엔드포인트 또는 프라이빗 링크를 통한 액세스)을 고려합니다.

Azure NetApp 파일

Azure NetApp Files의 경우 다음 옵션을 고려합니다.

블롭 스토리지

애플리케이션에서 저장해야 하는 구조화되지 않은 데이터의 양을 고려합니다. Azure Blob Storage는 HTTP API 또는 SDK를 통해 액세스할 수 있습니다. Blob Storage를 파일 시스템으로 컨테이너 또는 Pod에 탑재하는 것은 로그 파일, 이미지, 문서, 스트리밍 미디어 및 재해 복구 데이터와 같은 대량의 비정형 데이터가 있는 애플리케이션 워크로드에 적합합니다.

  • 데이터 중복성. 애플리케이션에 적합한 데이터 중복성을 고려합니다. 자세한 내용은 Azure Storage 중복성을 참조하세요. 데이터 중복성은 스토리지 계정 수준에서 선택됩니다.

  • 성능 계층입니다. 애플리케이션에 필요한 Blob Storage의 성능 계층을 고려합니다. 자세한 내용은 Blob 데이터에 대한 핫, 쿨 및 보관 액세스 계층을 참조하세요.

  • 액세스에 대한 인증 방법입니다. 애플리케이션이 Blob Storage에 액세스하는 데 사용해야 하는 인증 방법(스토리지 키, SAS 또는 Microsoft Entra ID)을 고려합니다. 자세한 내용은 Azure Storage의 데이터에 대한 액세스 권한 부여를 참조하세요.

  • Blob Storage를 추상화하기 위한 API입니다. 사용할 API를 고려합니다. 일반적으로 Blob Storage에 액세스하는 애플리케이션은 Kubernetes 클러스터에서 Blob Storage와의 상호 작용을 추상화하는 SDK 중 하나를 통해 애플리케이션의 API를 사용합니다. 다양한 프로그래밍 언어의 라이브러리에 대한 자세한 내용은 Azure Blob Storage 소개를 참조하세요.

  • 정적 또는 동적으로 만든 Blob Storage입니다. AKS 외부에서 만드는 정적 Blob Storage 컨테이너 또는 AKS가 사용자를 대신하여 동적으로 만드는 Blob Storage 컨테이너를 사용하는 것이 좋습니다. 자세한 내용은 다음을 참조하세요.

  • 스토리지에 액세스하기 위한 드라이버입니다. 애플리케이션이 Blob Storage에 액세스하는 방법을 고려합니다. 파일 시스템으로 액세스하려면 Kubernetes에서 Blob CSI 드라이버를 사용할 수 있습니다. 이 드라이버를 사용하면 NFSv3 프로토콜 또는 퓨즈 드라이버를 통해 Blob Storage에 액세스할 수 있습니다.

기타 스토리지 솔루션

Azure에는 Kubernetes와 통합할 수 있는 여러 특수 스토리지 솔루션이 있습니다. 이 문서에서는 이러한 특수 스토리지 솔루션을 다루지 않지만 다음 목록에서는 가능한 솔루션을 식별합니다.

  • Azure HPC 캐시. HPC 캐시는 HPC(고성능 컴퓨팅) 작업을 위해 데이터에 빠르게 액세스할 수 있도록 합니다. Azure에서 파일을 캐싱하여 Azure HPC Cache는 기존 워크플로에 대한 클라우드 컴퓨팅의 확장성을 제공합니다. 자세한 내용은 Azure Kubernetes Service와 Azure HPC Cache 통합을 참조하세요.

  • Azure Data Lake Storage Gen2. Data Lake Storage Gen2는 Hadoop 및 Spark와 같은 빅 데이터 워크로드에 최적화된 특수한 유형의 Blob Storage입니다. 자세한 내용은 Azure Data Lake Storage Gen2소개를 참조하세요.

디자인 권장 사항

이 섹션에서는 Azure 고객에게 효과적인 권장 사항을 제공합니다.

  • Azure Private Link를 사용합니다. 보안을 위해 Azure Private Link를 지원하는 모든 스토리지 솔루션에 사용하는 것이 좋습니다. Azure Private Link를 사용하면 가상 네트워크의 프라이빗 엔드포인트를 통해 Azure Storage 및 SQL Database와 같은 Azure 서비스 및 Azure 호스팅 서비스에 액세스할 수 있습니다. 자세한 내용은 Azure Private Link란?을 참조하세요.

  • OS에 임시 디스크를 사용합니다. OS 디스크의 경우 임시 디스크를 사용하는 것이 좋습니다. 이 기능을 활용하려면 적절한 크기의 임시 디스크가 있는 VM 크기를 선택합니다. 자세한 내용은 Azure VM에 대한 임시 OS 디스크를 참조하세요.

  • 관리되는 데이터베이스를 사용합니다. 애플리케이션 데이터의 경우 관리되는 데이터베이스를 사용하는 것이 좋습니다. 데이터베이스 옵션 목록은 Azure의 데이터베이스 유형을 참조하세요.

다음 섹션에서는 Azure 디스크, Azure Files 및 Blob Storage에 대한 추가 권장 사항을 설명합니다.

Azure 컨테이너 스토리지 사용

다음 섹션에는 AKS에서 Azure Container Storage를 사용하기 위한 권장 사항이 포함되어 있습니다.

Azure Container Storage 요구 사항

  • AKS 클러스터 필수 구성 요소: 노드 풀에 각각 최소 4개의 vCPU가 있는 3개 이상의 가상 머신이 있는 AKS 클러스터를 배포합니다.
  • 액세스 모드 제한 사항: Azure Container Storage는 ReadWriteOnce 액세스 모드만 지원합니다. ReadWriteMany 액세스가 필요한 워크로드의 경우 Azure Files를 대신 사용합니다. 액세스 모드에 대한 자세한 내용은 Kubernetes 설명서를 참조하세요.

올바른 Azure Container Storage 유형 선택

  • Azure Disks: 계층 1 및 MySQL, MongoDB 및 PostgreSQL과 같은 범용 데이터베이스에 사용합니다. UltraSSD_LRS 또는 PremiumV2_LRS 디스크를 사용하는 경우 IOPSReadWrite 및 MBpsReadWrite 매개 변수를 사용하여 스토리지 풀 정의에서 직접 성능 매개 변수(IOPS 및 처리량)를 지정합니다. 이 접근 방식을 통해 Azure Container Storage는 성능 요구 사항에 맞게 최적의 디스크 리소스를 프로비전합니다.

  • Azure 임시 디스크: 데이터 내구성 요구 사항이 없거나 기본 제공 애플리케이션 수준 데이터 복제(예: Cassandra)를 사용하는 초저 대기 시간(하위 밀리초)이 필요한 애플리케이션에 가장 적합합니다. 임시 디스크의 데이터는 VM 재부팅을 통해 유지되지 않습니다. NVMe를 사용하는 Azure Container Storage는 단일 노드 오류에 대한 복원력을 위해 볼륨 복제를 지원하지만 모든 복제본이 동시에 다시 부팅되면 데이터가 손실됩니다. 특정 워크로드에 대해 이 위험을 신중하게 평가합니다. NVMe는 스토리지 최적화 L-Family VM SKU에서 사용할 수 있습니다.

Azure Container Storage 복원력 구성

Azure Container Storage를 사용하여 복원력을 위해 디자인할 때 고가용성을 위해 다음 방법 중 하나를 선택합니다.

복원력 접근 방식 설명 가장 적합한
ZRS(영역 중복 스토리지) 영역 오류로부터 보호하기 위해 둘 이상의 가용성 영역에 데이터를 자동으로 복제합니다. 애플리케이션 수준 복제 없이 영역 수준 오류로부터 자동 데이터 보호가 필요한 워크로드.
다중 지역 스토리지 풀 각 영역이 고유한 스토리지 리소스를 유지 관리하는 가용성 영역에 스토리지 용량을 동일하게 분산합니다. 자체 데이터 중복성을 이미 관리하는 애플리케이션 수준 복제(예: Cassandra)를 사용하는 워크로드.

비고

ZRS 및 다중 영역 스토리지 풀은 서로 다른 메커니즘을 통해 유사한 용도로 사용되므로 동시에 사용할 수 없습니다. 선택한 방법에 관계없이 백업 및 재해 복구 전략의 일부로 일반 볼륨 스냅샷 을 구현합니다.

Azure 디스크

Azure 디스크의 경우 다음 디자인 옵션을 사용하는 것이 좋습니다.

  • 프리미엄 또는 울트라 디스크를 사용합니다. 대부분의 경우 적절한 성능을 보장하기 위해 프리미엄 또는 울트라 디스크를 사용하는 것이 좋습니다. 자세한 내용은 Azure Disk Storage를 참조하세요.

  • 디스크 및 처리량에 대한 노드 크기를 조정합니다. Kubernetes 노드의 크기가 디스크 수와 집계 처리량의 양을 지원할 만큼 충분히 큰지 확인하는 것이 좋습니다. 크기 및 특성에 대한 자세한 내용은 Azure에서 가상 머신의 크기를 참조하세요.

  • 영구 볼륨의 스냅샷을 만듭니다. Azure Disks CSI 드라이버를 사용하여 영구 볼륨의 스냅샷을 만들어 데이터를 백업하거나 볼륨을 이전 상태로 복원합니다. 자세한 내용은 볼륨 스냅샷을 참조하세요.

  • 디스크에서 디스크 스트라이프를 방지합니다. Kubernetes에서 여러 디스크 간 디스크 스트라이핑을 피하는 것이 좋습니다.

  • PV/PVC를 사용합니다. Kubernetes에서 PV 및 PVC를 사용하여 필요한 경우 디스크를 동적으로 만드는 것이 좋습니다. 영구 스토리지에 대한 자세한 내용은 AKS(Azure Kubernetes Service)의 애플리케이션에 대한 스토리지 옵션을 참조하세요.

Azure Files

Azure Files의 경우 다음 디자인 옵션을 사용하는 것이 좋습니다.

  • 프리미엄을 선택합니다. 성능이 중요한 경우 프리미엄 계층을 사용하는 것이 좋습니다.

  • 전용 스토리지 계정을 만듭니다. 파일 공유에 대한 전용 스토리지 계정을 제공하는 것이 좋습니다.

  • 정적 또는 동적으로 만든 파일 공유를 선택합니다. AKS에서 파일 공유를 만들 것인지 아니면 Kubernetes 외부에서 정적으로 만들 것인지 신중하게 고려해야 합니다. 동적으로 만든 스토리지는 동적으로 삭제할 수도 있습니다. AKS에서 파일 공유를 동적으로 만들 수 있도록 하는 방법에 대한 자세한 내용은 Azure Files에서 동적으로 영구 볼륨 만들기 및 사용을 참조하세요.

Azure NetApp 파일

Azure NetApp Files의 경우 다음 디자인 옵션을 사용하는 것이 좋습니다.

  • 애플리케이션 요구 사항에 따라 성능 계층을 선택합니다. Azure NetApp Files는 다양한 성능 클래스를 제공하는 세 가지 성능 계층을 제공합니다. 자세한 내용은 Azure NetApp Files에 대한 성능 고려 사항을 참조하세요.

  • AKS 클러스터와 동일한 Azure 지역에 용량 풀을 만듭니다. 자세한 내용은 Azure NetApp Files에 대한 용량 풀 만들기를 참조하세요.

  • 용량 풀에 자동 QoS 유형을 사용합니다.

  • 네트워크를 계획합니다. 네트워크 디자인에는 다음 두 가지 옵션이 있습니다.

    1. AKS 및 Azure NetApp Files에 동일한 가상 네트워크를 사용하는 경우 Azure NetApp Files용 전용 서브넷을 만들고 Microsoft.NetApp/Volumes에 서브넷을 위임 합니다.
    2. 다른 VNet을 사용하는 경우 가상 네트워크 피어링을 설정합니다.

블롭 스토리지

Blob Storage의 경우 다음 디자인 옵션을 사용하는 것이 좋습니다.

  • SDK를 사용하여 스토리지와 인터페이스합니다. 애플리케이션 수준 SDK를 사용하여 Blob Storage와 인터페이스하는 것이 좋습니다.

  • NFS와 함께 CSI를 사용하여 스토리지와 인터페이스합니다. 애플리케이션 수준 SDK를 사용하여 Blob Storage와 인터페이스할 수 없는 경우 Blob CSI 드라이버에서 NFS v3 옵션을 사용하는 것이 좋습니다. 자세한 내용은 Azure Blob Storage CSI(Container Storage Interface) 드라이버 사용을 참조하세요.

  • 액세스를 위해 Microsoft Entra ID를 사용합니다. Blob Storage에 대한 액세스 권한을 부여하려면 Microsoft Entra ID를 사용하는 것이 좋습니다. 공유 스토리지 계정 키를 사용하지 않습니다. 자세한 내용은 Azure Active Directory를 사용하여 Blob에 대한 액세스 권한 부여를 참조하세요.

  • 계층 수준을 조정합니다. 자주 액세스하지 않는 데이터를 쿨러 액세스 계층으로 이동하려면 수명 주기 관리 정책을 사용하는 것이 좋습니다. 자세한 내용은 Blob 데이터에 대한 핫, 쿨 및 보관 액세스 계층을 참조하세요.

다음 단계

Kubecost를 사용하여 AKS에서 배포, 서비스, 레이블, Pod 또는 네임스페이스로 비용 할당 범위를 지정하는 방법을 알아봅니다.

Kubecost를 통한 비용 거버넌스