Azure Functions 대한 스토리지 고려 사항

Azure 함수 앱 인스턴스를 만들 때 기본 Azure Storage 계정에 대한 액세스를 제공해야 합니다. 다음 다이어그램 및 표에서는 Azure Functions 기본 스토리지 계정에서 서비스를 사용하는 방법을 자세히 설명합니다.

이 글 상단에서 호스팅 요금제를 선택하셔서 기능 앱에 적용되는 저장 안내를 확인하세요.

Azure Functions가 Azure Storage 계정 내에서 Blob 스토리지, 파일 공유, 큐 스토리지, 그리고 Table 스토리지와 같은 다양한 스토리지 서비스를 어떻게 사용하는지를 보여주는 다이어그램입니다.

스토리지 서비스 Functions 사용량
Azure Blob Storage 바인딩 상태 및 함수 키 1을 유지 관리합니다.
Flex 사용량 플랜에서 실행되는 앱 배포 소스입니다.
기본적으로 작업 허브 in Durable Functions에 사용됩니다.
이는 Linux 사용 원격 빌드나 외부 패키지 URL 배포의 일부로 함수 앱 코드 저장에 사용할 수 있습니다.
Azure Files2 사용량 플랜 및 프리미엄 플랜에서 함수 앱 코드를 저장, 실행하는 데 사용되는 파일 공유입니다.
확장 번들을 유지 관리합니다.
배포 로그를 저장합니다.
PowerShell에서 관리되는 종속성을 지원합니다.
Azure Queue Storage 기본적으로 작업 허브 in Durable Functions에 사용됩니다. 특이 Azure Functions 트리거 오류 및 재시도 처리에 사용됩니다. 이는 Blob 스토리지 트리거에 따른 개체 추적에 사용됩니다.
Azure 테이블 스토리지 기본적으로 작업 허브 in Durable Functions에 사용됩니다.
진단 이벤트를 추적하는 데 사용됩니다.
  1. Blob 스토리지는 함수 키의 기본 저장소입니다. 그러나 대체 저장소를 구성할 수도 있습니다.
  2. Azure Files 기본적으로 설정되지만 특정 조건에서는 Azure Files 없이 앱을 만들 수 있습니다.

중요 고려 사항입니다

귀하의 기능 앱에서 사용하는 스토리지 계정에 대해 다음과 같은 사실을 고려해 보세요:

Consumption 플랜(Windows) 또는 Premium 플랜에서 기능 앱을 호스팅할 때, 기능 코드와 설정 파일을 연결된 스토리지 계정의 Azure Files에 저장합니다. 이 저장 계정을 삭제하면 콘텐츠가 영구적으로 삭제됩니다. 자세한 내용은 스토리지 계정이 삭제되었음을 참조하세요.

  • 스토리지 계정은 기능 코드, 접근 키 및 기타 중요한 서비스 관련 데이터와 같은 중요한 데이터를 유지합니다. 다음과 같은 방법으로 함수 앱에서 사용하는 스토리지 계정 액세스를 신중하게 관리하세요.

    • 최소 권한 모델에 따라 앱 및 사용자 스토리지 계정 액세스를 감사 및 제한하세요. 스토리지 계정 권한은 할당된 역할의 데이터 작업이나 listKeys 작업을 수행할 수 있는 권한으로 얻을 수 있습니다.

    • 컨트롤 플레인 작업(예: 키 검색)과 데이터 평면 작업(예: Blob에 쓰기)을 스토리지 계정에서 모두 모니터링하세요. Azure Storage 이외의 위치에서 스토리지 로그를 유지 관리하는 것이 좋습니다. 더 자세한 내용은 스토리지 로그를 참조하세요.

  • Durable Functions 사용하는 경우 태스크 허브 스토리지는 임의 코드 실행 트리거를 포함하여 애플리케이션 동작을 변경하는 데 쓰기 액세스를 사용할 수 있으므로 특히 보안에 중요합니다. 자세한 내용은 작업 허브 스토리지 보안을 참조하세요.

스토리지 계정 요구 사항

Azure 포털에서 함수 앱 생성 프로세스 중에 만든 스토리지 계정은 새 함수 앱에서 작동합니다. 기존에 존재하는 스토리지 계정을 선택하는 경우. 목록에 지원되지 않는 특정 스토리지 계정이 포함되지 않습니다. 함수 앱에서 사용하는 스토리지 계정에는 다음 제한 사항이 적용됩니다. 기존 저장 계정이 다음 요건을 충족하는지 확인하세요:

  • 사용량 플랜에서 함수 앱이 호스트되는 경우 네트워크 보안 스토리지 계정을 사용할 수 없습니다.

  • 계정 유형은 Blob, Queue 및 Table 스토리지를 지원해야 합니다. 일부 스토리지 계정의 경우, 큐 및 테이블을 지원하지 않습니다. 이러한 계정에는 Blob 전용 스토리지 계정 및 Azure Premium Storage 포함됩니다. 스토리지 계정 형식에 대한 더 자세한 내용은 스토리지 계정 개요를 참조하세요.

  • Azure 포털에서 함수 앱을 만들 때 만든 함수 앱과 동일한 지역에 있는 기존 스토리지 계정만 선택할 수 있습니다. 이 요구 사항은 엄격한 제한 사항이 아니라 성능 최적화입니다. 더 자세한 내용은 스토리지 계정 위치를 참조하세요.

  • 가용성 영역 지원을 사용하도록 설정된 계획에서 함수 앱을 만들면 영역 중복 스토리지 계정만 지원됩니다.

배포 자동화를 사용하여 네트워크 보안 스토리지 계정으로 함수 앱을 만드는 경우 ARM 템플릿 또는 Bicep 파일에 특정 네트워킹 구성을 포함해야 합니다. 이러한 설정 및 리소스를 포함하지 않으면 자동화된 배포가 유효성 검사에 실패할 수 있습니다. ARM 템플릿 및 Bicep 지침에 대한 자세한 내용은 보안 배포를 참조하십시오. 네트워킹을 사용하여 스토리지 계정을 구성하는 방법에 대한 개요는 Azure Functions 보안 스토리지 계정을 사용하는 방법을 참조하세요.

스토리지 계정 가이드

스토리지 계정이 있어야 모든 함수 앱이 작동합니다. 해당 계정을 삭제하면 함수 앱의 실행이 중지됩니다. 스토리지 관련 문제를 해결하는 방법을 참조해 스토리지 관련 문제를 해결하세요. 함수 앱에서 사용하는 스토리지 계정에는 다음 고려 사항이 적용됩니다.

스토리지 계정 위치

함수 앱은 동일한 지역의 스토리지 계정을 사용하세요. 최상의 성능을 발휘할 수 있으며, 지연 시간을 줄일 수 있습니다. Azure 포털은 이 모범 사례를 적용합니다. 함수 앱과 다른 지역에서 스토리지 계정을 사용해야 하는 경우 Azure 포털 외부에서 함수 앱을 만들어야 합니다.

스토리지 계정은 함수 앱에 액세스할 수 있어야 합니다. 보안 스토리지 계정을 사용해야 한다면 스토리지 계정을 가상 네트워크로 제한하는 것을 제안합니다.

스토리지 계정 연결 설정하기

기본적으로 함수 앱은 AzureWebJobsStorage 연결을 연결 문자열로 구성하며, 이 문자열은 AzureWebJobsStorage 애플리케이션 설정에 저장됩니다. 비밀 없이 ID 기반 연결을 사용하도록 AzureWebJobsStorage를 구성할 수도 있습니다.

소비 계획(Windows 전용) 또는 Elastic Premium 플랜(Windows 또는 Linux)에서 실행되는 함수 앱은 Azure Files 사용하여 동적 크기 조정을 사용하도록 설정하는 데 필요한 이미지를 저장할 수 있습니다. 이러한 계획의 경우, WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 설정에 스토리지 계정의 연결 문자열을 설정하고, WEBSITE_CONTENTSHARE 설정에 파일 공유 이름을 지정하십시오. 이 값은 일반적으로 에 사용되는 AzureWebJobsStorage계정과 동일합니다. Azure Files 사용하지 않는 함수 앱을 만들 수도 있지만 크기 조정이 제한될 수 있습니다.

참고

스토리지 키를 다시 생성할 때 스토리지 계정 연결 문자열을 업데이트해야 합니다. 자세한 내용은 Azure 스토리지 계정 만들기 참조하세요.

공유된 스토리지 계정

여러 함수 앱은 문제 없이 동일한 스토리지 계정을 공유할 수 있습니다. 예를 들어 Visual Studio Azurite Storage 에뮬레이터 사용하여 여러 앱을 개발할 수 있습니다. 다음 경우에서, 에뮬레이터는 단일 스토리지 계정처럼 작동합니다. 함수 앱에서 사용하는 것과 동일한 스토리지 계정은 애플리케이션 데이터를 저장할 수도 있습니다. 그러나 해당 접근 방법이 프로덕션 환경에서 항상 좋은 것은 아닙니다.

호스트 ID 충돌 방지를 위해 별도의 스토리지 계정을 사용해야 할 수도 있습니다.

수명 주기 관리 정책 고려 사항

함수 앱에서 사용하는 Blob Storage 계정에 lifecycle 관리 정책 적용하지 마세요. 함수는 Blob Storage를 사용하여 함수 액세스 키와 같은 중요한 정보를 유지합니다. 정책은 Functions 호스트에 필요한 키와 같은 Blob을 제거할 수 있습니다. 정책을 사용해야 하는 경우 azure-webjobs 또는 scm로 시작하는 Functions에서 사용하는 컨테이너를 제외하세요.

스토리지 로그

함수 코드와 키는 스토리지 계정에 유지될 수 있습니다. 스토리지 계정에 대한 활동을 로깅하는 것은 무단 액세스 모니터링에 좋은 방법입니다. Azure Monitor 리소스 로그를 사용하여 스토리지 데이터 평면에 대한 이벤트를 추적할 수 있습니다. 이러한 로그를 구성하고 검사하는 방법에 대한 자세한 내용은 모니터링 Azure Storage을 참조하세요.

Azure Monitor 활동 로그에는 listKeys 작업 포함한 컨트롤 플레인 이벤트가 표시됩니다. 또한 스토리지 계정에 대한 리소스 로그를 구성해 키 또는 기타 ID 기반 데이터 평면 작업을 추적하는 것을 권장합니다. StorageWrite 로그 범주 이상을 사용하도록 설정하여 일반 Functions 작업 이외의 데이터 수정 사항을 식별할 수 있게 합니다.

광범위한 범위의 스토리지 권한의 잠재적 영향을 제한하려면 Log Analytics 같은 이러한 로그에 비스토리지 대상을 사용하는 것이 좋습니다. 자세한 내용은 Azure Blob Storage 모니터링을 참조하세요.

스토리지 성능 최적화하기

성능을 최대화하기 위해 각 함수 앱에 대해 별도의 스토리지 계정을 사용합니다. 이 방법은 Durable Functions 또는 Event Hubs 트리거 함수가 있을 때 특히 중요합니다. 이 함수는 둘 다 대량의 스토리지 트랜잭션을 생성합니다. 애플리케이션 논리가 직접(Storage SDK 사용) 또는 스토리지 바인딩 중 하나를 통해 Azure Storage 상호 작용하는 경우 전용 스토리지 계정을 사용해야 합니다. 예를 들어 Blob Storage에 일부 데이터를 쓰는 이벤트 허브 트리거 함수가 있는 경우 함수 앱에 대한 계정과 함수가 저장하는 Blob에 대해 하나씩 두 개의 스토리지 계정을 사용합니다.

가상 네트워크를 통해 라우팅 일관성 유지

동일한 계획에 호스트된 여러 함수 앱은 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 정의된 Azure Files 콘텐츠 공유에 대해 동일한 스토리지 계정을 사용할 수도 있습니다. 가상 네트워크를 사용하여 이 스토리지 계정을 보호하는 경우 이러한 모든 앱(슬롯 포함)은 (이전vnetContentShareEnabled의) 동일한 값 WEBSITE_CONTENTOVERVNET 과 동일한 가상 네트워크 통합 구성을 사용하여 트래픽이 의도한 가상 네트워크를 통해 일관되게 라우팅되도록 해야 합니다. 동일한 Azure Files 스토리지 계정을 사용하는 앱 간에 이 설정이 일치하지 않을 경우 공용 네트워크를 통한 트래픽 라우팅이 발생할 수 있습니다. 이 구성에서 스토리지 계정 네트워크 규칙은 액세스를 차단합니다.

vnetContentShareEnabled 지침은 Flex Consumption, Dedicated, Container Apps 또는 Consumption 호스팅에는 적용되지 않습니다.

Blob 작업

Functions 주요 시나리오는 이미지 처리나 감정 분석 같은 Blob 컨테이너 파일 처리입니다. 더 자세한 내용은 파일 업로드 처리를 참조하세요.

Blob 컨테이너에서의 트리거

이 다이어그램에 표시된 대로 스토리지 컨테이너의 Blob 변경 내용에 따라 함수 코드를 실행하는 방법에는 여러 가지가 있습니다.

다이어그램입니다: Azure의 Blob Storage 컨테이너에서 항목이 추가되거나 업데이트될 때 함수를 트리거하는 다양한 옵션을 보여 줍니다.

다음 표를 사용하여 컨테이너에서 추가되거나 업데이트된 Blob을 처리하는 데 가장 적합한 함수 트리거를 결정합니다.

전략 Blob 트리거(폴링) Blob 트리거(이벤트 기반) 큐 트리거 이벤트 그리드 트리거
지연 시간 높음(최대 10분) 낮음 중간 낮음
스토리지 계정 제한 사항 블롭 전용 계정¹과 계층적 네임스페이스(HNS)가 활성화된 계정(예: Azure Data Lake Storage Gen2 계정)은 지원하지 않습니다 범용 v1 계정을 지원하지 않음 없음 범용 v1 계정을 지원하지 않음
트리거 유형 Blob 스토리지. Blob 스토리지. 큐 스토리지 이벤트 그리드
확장 버전 모두 Storage v5.x 이상 모두 모두
기존 Blob을 처리 예 아니요 아니요 아니요
필터 Blob 이름 패턴 이벤트 필터 해당 없음 이벤트 필터
이벤트 구독을 필요로 합니다 아니요 예 아니요 예
Flex 사용량 플랜을 지원합니다 아니요 예 예 예
대규모 사용을 지원² 아니요 예 예 예
인바운드 액세스 제한과 함께 작동 예 아니요 예 예3
설명 기본 트리거 동작입니다. 컨테이너를 폴링해 업데이트를 확인하는 방식입니다. 더 자세한 내용은 Blob 스토리지 트리거 참조 예시를 참조하세요. 이벤트 구독에서 Blob 스토리지 이벤트를 사용합니다. Source 매개 변수 값으로 EventGrid이 필요합니다. 자세한 내용은 Tutorial: 이벤트 구독을 사용하여 Blob 컨테이너에서 Azure Functions 트리거를 참조하세요. 컨테이너에 Blob이 추가되면 Blob 이름 문자열이 스토리지 큐에 수동으로 추가됩니다. Queue Storage 트리거는 이 값을 동일한 함수의 Blob Storage 입력 바인딩에 직접 전달합니다. 스토리지 컨테이너에서 발생하는 이벤트 외에 이벤트에 대해 유연하게 트리거할 수 있습니다. 스토리지가 아닌 이벤트 또한 함수를 트리거해야 하는 경우에 사용합니다. 자세한 내용은 Azure Functions 참조하세요.
  1. 블롭 전용 계정 제한은 폴링 기반 블롭 저장 트리거에만 적용됩니다. Blob 스토리지 입력 및 출력 바인딩은 Blob 전용 계정을 지원합니다.
  2. 대규모의 경우, 대략 100,000개가 넘는 Blob이 있는 컨테이너 또는 초당 100개가 넘는 Blob 업데이트가 있는 스토리지 계정으로 정의할 수 있습니다.
  3. 이벤트 구독이 알려진 사용자 ID를 사용하여 공용 IP 공간의 암호화된 채널을 통해 이벤트를 전달하게 하여 인바운드 액세스 제한을 해결할 수 있습니다. 자세한 내용은 관리 ID를 사용하여 안전하게 이벤트 배달을 참조하세요.

스토리지 데이터 암호화

Azure Storage 미사용 스토리지 계정의 모든 데이터를 암호화합니다. 자세한 내용은 미사용 데이터에 대한 Azure Storage 암호화 참조하세요.

기본적으로 데이터는 Microsoft 관리형 키로 암호화됩니다. 암호화 키에 대한 더 많은 제어를 위해 Blob 및 파일 데이터의 암호화에 사용할 고객 관리형 키를 제공할 수 있습니다. Functions가 스토리지 계정에 액세스할 수 있도록 하려면 이러한 키가 Azure Key Vault 있어야 합니다. 자세한 내용은 고객 관리형 키를 사용하여 미사용 애플리케이션 데이터 암호화를 참조하세요.

하위 지역 내 데이터 상주

모든 고객 데이터가 단일 지역 내에 머물러야 할 경우, 지역 내 중복성이 있는 기능 앱과 연동된 스토리지 계정을 사용하세요. 또한 Azure Durable Functions와 함께 지역 내 중복 저장 계정을 사용하세요.

플랫폼은 내부 부하 분산 App Service Environment(ASE)에서 호스팅할 때만 해당 지역 내에 다른 플랫폼 관리 고객 데이터를 저장합니다. 더 자세한 내용은 ASE 영역 중복성을 참조하세요.

호스트 ID 고려 사항

이 섹션에서 고려한 호스트 ID 고려사항은 Flex Consumption에는 적용되지 않습니다. 이 호스팅 계획에서는 이러한 잠재적 문제를 피하는 방식으로 호스트 ID 값이 생성됩니다.

함수는 호스트 ID 값을 사용하여 저장된 산출물 내에서 특정 함수 앱을 고유하게 식별합니다. 기본적으로 런타임은 함수 앱 이름에서 이 ID를 처음 32자로 축약하여 자동으로 생성합니다. 런타임은 연결된 스토리지 계정에 앱별 상관관계 및 추적 정보를 저장할 때 이 ID를 사용합니다. 함수 앱의 이름이 32자를 초과하고 처음 32자가 동일할 경우, 이 절단은 중복된 호스트 ID 값을 초래할 수 있습니다. 동일한 호스트 ID를 가진 두 기능 앱이 동일한 스토리지 계정을 사용할 경우, 저장된 데이터가 올바른 기능 앱과 고유하게 연결될 수 없기 때문에 호스트 ID 충돌이 발생합니다.

참고

동일한 종류의 호스트 ID 충돌이 프로덕션 슬롯에 있는 함수 앱과 스테이징 슬롯에 있는 동일한 함수 앱 간에 발생할 수 있으며, 두 슬롯이 동일한 스토리지 계정을 사용할 때도 발생합니다.

Functions 런타임 버전 4.x에서는 오류가 기록되고 호스트가 중지되어 하드 실패가 발생합니다. 자세한 내용은 HostID 잘림으로 인해 충돌이 발생할 수 있습니다 참조하세요.

호스트 ID 충돌 방지하기

호스트 ID 충돌을 피하기 위해 다음 전략을 사용하세요:

  • 각 상호작용하는 호스트가 서로 다른 계정에 쓰도록 별도의 스토리지 계정을 사용하세요.
  • 기능 앱 중 하나를 이름이 32자 미만으로 바꾸면 계산된 호스트 ID가 바뀌고 충돌 위험이 사라집니다.
  • 1개 이상의 충돌 앱에 대해 명시적 호스트 ID를 설정합니다. 자세한 내용은 호스트 ID 재정의를 참조하세요.

중요합니다

기존 함수 앱과 연결된 스토리지 계정을 변경하거나 앱의 호스트 ID를 변경하면 기존 함수의 동작에 영향을 줄 수 있습니다. 예를 들어 Blob Storage 트리거는 스토리지의 특정 호스트 ID 경로 아래에 수신 확인 레코드를 기록하여 개별 Blob의 처리 여부를 추적합니다. 호스트 ID가 변경되거나 새 스토리지 계정을 가리키는 경우, 이전에 처리된 Blob이 다시 처리될 수 있습니다.

호스트 ID 재정의하기

애플리케이션 설정에서 해당 설정을 사용 AzureFunctionsWebHost__hostid 해 함수형 앱의 명시적인 호스트 ID를 설정할 수 있습니다. 더 자세한 내용은 AzureFunctionsWebHost__hostid를 참조하세요.

슬롯 간 충돌이 발생하면, 각 슬롯과 프로덕션 슬롯에 대해 특정 호스트 ID를 설정해야 합니다. 또한 이와 같은 설정을 배포 설정으로 표시해야 바뀌지 않습니다. 앱 설정 생성 방법을 알기 위해 애플리케이션 설정 작업을 참조하세요.

Azure Files 없이 앱 만들기

Azure Files 서비스는 대규모 시나리오를 지원하는 공유 파일 시스템을 제공합니다. 함수 앱이 Elastic Premium 계획이나 소비 계획의 Windows에서 실행될 때, 기본적으로 스토리지 계정에 Azure Files 공유가 생성됩니다. 함수들은 이 공유를 로그 스트리밍이나 공유 앱 콘텐츠 위치와 같은 기능에 사용할 수 있습니다. 배포 위치는 배포 기술과 앱 구성에 따라 다릅니다. 예를 들어, 외부 패키지 URL을 사용하는 앱은 Azure Files 공유 대신 설정된 URL에서 패키지를 실행합니다.

Azure Files를 사용하려면 연결 문자열이 필요하며, 이 문자열은 앱 설정WEBSITE_CONTENTAZUREFILECONNECTIONSTRING에 저장됩니다. Azure Files 현재 ID 기반 연결을 지원하지 않습니다. 만약 시나리오에서 앱 설정에 비밀을 저장하지 않아야 한다면, 앱의 Azure Files 의존성을 제거해야 합니다. 기본 Azure Files 종속성 없이 앱을 만들어 이 종속성을 방지할 수 있습니다.

참고

또한 Flex Consumption 플랜에서 함수 앱을 실행하는 것도 고려해 보세요. 이 플랜은 배포 패키지에 대한 더 큰 제어권을 제공하며, 관리 신원 연결 사용 기능을 포함합니다. 자세한 내용은 배포 설정 구성을 참조하세요.

Azure Files 공유 없이 앱을 실행하려면 다음 요구사항을 충족해야 합니다:

다음 고려 사항도 유의해야 합니다.

  • 앱은 공유 쓰기 파일 시스템에 의존할 수 없습니다.
  • 포털 편집은 지원되지 않습니다.
  • Azure 포털과 같은 클라이언트의 로그 스트리밍 환경은 기본적으로 파일 시스템 로그로 설정됩니다. 대신 Application Insights 로그를 사용해야 합니다.

위의 요구 사항이 시나리오에 적합한 경우 Azure Files 없이 함수 앱을 계속 만들 수 있습니다. 다음 방법 중 하나로 앱 설정 없이 WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGWEBSITE_CONTENTSHARE 앱을 만듭니다.

  • Bicep/ARM 템플릿: ARM 템플릿이나 Bicep 파일에서 두 가지 앱 설정을 제거한 후 수정된 템플릿을 사용해 앱을 배포하세요.
  • Azure 포털: Azure 포털에서 앱을 생성할 때 Storage 탭의 Azure Files 연결 추가 선택을 해제하세요.

Azure Files 함수에 대해 동적 스케일 아웃을 사용하도록 설정하는 데 사용됩니다. Windows 실행 중인 Elastic Premium 플랜 및 소비 계획에서 Azure Files 않고 앱을 실행할 때 크기 조정이 제한될 수 있습니다.

Flex Consumption은 Azure Files 콘텐츠 공유에 의존하지 않습니다. 구성 가능한 Blob 배포 저장소를 사용하며 관리 신원 연결을 지원합니다. 자세한 내용은 배포 설정 구성을 참조하세요.

전용 요금제 앱은 이 섹션에서 설명한 기본 Azure Files 콘텐츠 공유 의존성을 가지고 있지 않습니다.

Azure Container Apps의 함수는 이 섹션에서 설명한 기본 Azure Files content-share 의존성을 가지고 있지 않습니다.

파일 공유를 탑재

이 기능은 리눅스에서 실행될 때만 사용할 수 있습니다.

Azure Files 공유를 Linux 함수 앱에 마운트할 수 있어, 기존 파일, 머신러닝 모델, 함수 내 큰 바이너리 파일에 접근할 수 있습니다. 스토리지 탑재, 바인딩 및 외부 데이터베이스 중에서 선택하는 개념 지침은 Azure Functions 대한 파일 액세스 전략의 선택을 참조하세요.

Flex Consumption은 서버 메시지 블록(SMB) Azure Files 마운트만 지원합니다.

기존 공유를 Linux 함수 앱에 마운트하려면 다음 명령어를 사용하세요.

az webapp config storage-account add 명령은 웹앱 설정에 저장소 계정을 추가합니다.

이 명령에서 share-name 기존 Azure Files 공유의 이름입니다. custom-id 는 함수 앱에 탑재될 때 공유를 고유하게 정의하는 문자열일 수 있습니다. 또한 mount-path는 함수 앱에서 공유에 액세스할 때 사용하는 경로입니다. mount-path는 /dir-name 형식이어야 하며 /home으로 시작할 수 없습니다.

전체 예제는 Python 함수 앱 만들기 및 Azure Files 공유 탑재 참조하세요.

Azure Container Apps의 Functions에 대해 컨테이너 앱에 Azure Files 볼륨을 구성하세요. 자세한 내용은 Azure Container Apps 참조하세요.

Consumption 플랜에서는 스토리지 마운트를 지원하지 않습니다.

중요합니다

Linux에서 사용량 요금제를 사용 중이며 여전히 지원 종료된 v3 런타임을 실행 중인 Function 앱은 2026년 9월 30일 이후부터 더 이상 실행되지 않습니다. 서비스 중단을 방지하려면 앱을 v4 런타임으로 마이그레이션합니다.

소비 계획에서 Linux에서 함수 앱을 호스트하는 옵션은 2028년 9월 30일에 사용 중지됩니다. Linux 사용 계획은 새로운 기능 또는 언어 버전을 가져오지 않습니다. 소비 계획에서 Windows 실행되는 앱은 현재 영향을 받지 않습니다. 앱을 Flex 사용 플랜으로 마이그레이션을 종료일 이전에 완료하세요.

  • 에 마지막으로 업데이트됨