Azure Functions의 스토리지 고려 사항
함수 앱 인스턴스를 만들 때 Azure Functions에는 Azure Storage 계정이 필요합니다. 함수 앱에서 사용할 수 있는 스토리지 서비스는 다음과 같습니다.
| 스토리지 서비스 | Functions 사용 |
|---|---|
| Azure Blob Storage | 바인딩 상태 및 함수 키를 유지 관리합니다1. Flex 사용량 플랜에서 실행되는 앱의 배포 원본입니다. Durable Functions의 작업 허브에 기본적으로 사용됩니다. Linux 사용량 원격 빌드 또는 외부 패키지 URL 배포의 일부로 함수 앱 코드를 저장하는 데 사용할 수 있습니다. |
| Azure Files2 | 사용 플랜 및 프리미엄 플랜에서 함수 앱 코드를 저장 및 실행하는 데 사용되는 파일 공유입니다. |
| Azure Queue storage | Durable Functions의 작업 허브에 기본적으로 사용됩니다. 특정 Azure Functions 트리거의 실패 및 재시도 처리에 사용됩니다. Blob Storage 트리거에 의한 개체 추적에 사용됩니다. |
| Azure Table Storage | Durable Functions의 작업 허브에 기본적으로 사용됩니다. |
- Blob Storage는 함수 키의 기본 저장소이지만 대체 저장소를 구성할 수 있습니다.
- Azure Files는 기본적으로 설정되지만 특정 조건에서 Azure Files 없이 앱을 만들 수 있습니다.
중요 사항
함수 앱에서 사용하는 스토리지 계정과 관련하여 다음과 같은 사실을 강력히 고려해야 합니다.
함수 앱이 사용 계획 또는 프리미엄 계획에서 호스트되는 경우 함수 코드 및 구성 파일은 연결된 스토리지 계정의 Azure Files에 저장됩니다. 이 스토리지 계정을 삭제하면 콘텐츠가 삭제되고 복구할 수 없습니다. 자세한 내용은 스토리지 계정이 삭제됨을 참조하세요.
함수 코드, 액세스 키 및 기타 중요한 서비스 관련 데이터와 같은 중요한 데이터는 스토리지 계정에 유지될 수 있습니다. 다음과 같은 방법으로 함수 앱에서 사용하는 스토리지 계정에 대한 액세스를 신중하게 관리해야 합니다.
최소 권한 모델을 기반으로 앱 및 사용자의 스토리지 계정에 대한 액세스를 감사하고 제한합니다. 스토리지 계정에 대한 권한은 할당된 역할의 데이터 작업 또는 listKeys 작업을 수행하는 권한을 통해 얻을 수 있습니다.
스토리지 계정에서 컨트롤 플레인 작업(예: 키 검색)과 데이터 평면 작업(예: Blob에 쓰기)을 모두 모니터링합니다. Azure Storage 이외의 위치에서 스토리지 로그를 유지 관리하는 것이 좋습니다. 자세한 내용은 스토리지 로그를 참조하세요.
스토리지 계정 요구 사항
Azure Portal의 함수 앱 만들기 흐름의 일부로 생성된 스토리지 계정은 새 함수 앱에서 작동할 수 있습니다. 기존 스토리지 계정을 사용하도록 선택하면 제공된 목록에 지원되지 않는 특정 스토리지 계정이 포함되지 않습니다. 함수 앱에서 사용하는 스토리지 계정에는 다음과 같은 제한 사항이 적용되므로 기존 스토리지 계정이 이러한 요구 사항을 충족하는지 확인해야 합니다.
계정 유형은 Blob, 큐 및 테이블 스토리지를 지원해야 합니다. 일부 스토리지 계정은 큐 및 테이블을 지원하지 않습니다. 해당 계정에는 Blob 전용 스토리지 계정 및 Azure Premium Storage가 포함됩니다. 스토리지 계정 형식에 대한 자세한 내용은 스토리지 계정 개요를 참조하세요.
함수 앱이 사용량 플랜에서 호스트되는 경우 네트워크 보안 스토리지 계정을 사용할 수 없습니다.
포털에서 함수 앱을 만들 때 만드는 함수 앱과 동일한 지역에 있는 기존 스토리지 계정만 선택할 수 있습니다. 이는 성능 최적화이며 엄격한 제한 사항이 아닙니다. 자세한 내용은 스토리지 계정 위치를 참조하세요.
가용성 영역 지원이 사용하도록 설정된 계획에 따라 함수 앱을 만드는 경우 영역 중복 스토리지 계정만 지원됩니다.
배포 자동화를 사용하여 네트워크 보안 스토리지 계정으로 함수 앱을 만드는 경우 ARM 템플릿 또는 Bicep 파일에 특정 네트워킹 구성을 포함해야 합니다. 이러한 설정과 리소스를 포함하지 않으면 자동화된 배포의 유효성이 검사에 실패할 수 있습니다. 보다 구체적인 ARM 및 Bicep 지침은 보안 배포를 참조하세요. 네트워킹으로 스토리지 계정을 구성하는 방법에 대한 개요는 Azure Functions에서 보안 스토리지 계정을 사용하는 방법을 참조하세요.
스토리지 계정 지침
모든 함수 앱은 스토리지 계정이 있어야 작동합니다. 해당 계정이 삭제되면 함수 앱이 실행되지 않습니다. 스토리지 관련 문제를 해결하려면 스토리지 관련 문제를 해결하는 방법을 참조하세요. 함수 앱에서 사용하는 스토리지 계정에는 다음 기타 고려 사항이 적용됩니다.
스토리지 계정 위치
최상의 성능을 위해 함수 앱은 대기 시간이 감소하도록 동일한 지역에서 스토리지 계정을 사용해야 합니다. Azure Portal은 이 모범 사례를 적용합니다. 어떤 이유로든 함수 앱과 다른 지역에서 스토리지 계정을 사용해야 하는 경우 Portal 외부에서 함수 앱을 만들어야 합니다.
스토리지 계정은 함수 앱에 액세스할 수 있어야 합니다. 보안 스토리지 계정을 사용해야 하는 경우 스토리지 계정을 가상 네트워크로 제한하는 것이 좋습니다.
스토리지 계정 연결 설정
기본적으로 함수 앱은 AzureWebJobsStorage 연결을 AzureWebJobsStorage 애플리케이션 설정에 저장된 연결 문자열로 구성하지만 비밀 없이 ID 기반 연결을 사용하도록 AzureWebJobsStorage를 구성할 수도 있습니다.
소비 플랜(Windows에만 해당) 또는 Elastic Premium 플랜(Windows 또는 Linux)에서 실행되는 함수 앱은 Azure Files를 사용하여 동적 스케일링을 사용하도록 설정하는 데 필요한 이미지를 저장할 수 있습니다. 이러한 플랜의 경우 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 설정에서 스토리지 계정에 대한 연결 문자열을 설정하고 WEBSITE_CONTENTSHARE 설정에서 파일 공유의 이름을 설정합니다. 이 계정은 일반적으로 AzureWebJobsStorage에 사용되는 것과 동일한 계정입니다. Azure Files를 사용하지 않는 함수 앱을 만들 수도 있지만 스케일링이 제한될 수 있습니다.
참고 항목
스토리지 키를 다시 생성하는 경우 스토리지 계정 연결 문자열을 업데이트해야 합니다. 여기에서 스토리지 키 관리에 관해 자세히 알아보세요.
공유 스토리지 계정
여러 함수 앱에서 문제 없이 동일한 스토리지 계정을 공유할 수 있습니다. 예를 들어 Visual Studio에서 Azurite 스토리지 에뮬레이터를 사용하여 여러 앱을 개발할 수 있습니다. 이 경우 에뮬레이터는 단일 스토리지 계정처럼 작동합니다. 함수 앱에서 사용하는 동일한 스토리지 계정을 사용하여 애플리케이션 데이터를 저장할 수도 있습니다. 그러나 프로덕션 환경에서는 이 접근 방법이 항상 좋은 것은 아닙니다.
호스트 ID 충돌을 방지하려면 별도의 스토리지 계정을 사용해야 할 수도 있습니다.
수명 주기 관리 정책 고려 사항
함수 앱에서 사용하는 Blob Storage 계정에 수명 주기 관리 정책을 적용하면 안 됩니다. 함수는 Blob Storage를 사용하여 함수 액세스 키와 같은 중요한 정보를 유지하며, 정책은 Functions 호스트에 필요한 Blob(예: 키)을 제거할 수 있습니다. 정책을 사용해야 하는 경우 azure-webjobs 또는 scm 접두사가 붙은 Functions에서 사용하는 컨테이너를 제외합니다.
스토리지 로그
함수 코드와 키는 스토리지 계정에 유지될 수 있으므로 스토리지 계정에 대한 활동을 로깅하는 것은 무단 액세스를 모니터링하는 좋은 방법입니다. Azure Monitor 리소스 로그를 사용하여 스토리지 데이터 평면에 대한 이벤트를 추적할 수 있습니다. 이러한 로그를 구성하고 검사하는 방법에 대한 자세한 내용은 Azure Storage 모니터링을 참조하세요.
Azure Monitor 활동 로그에는 listKeys 작업을 포함한 컨트롤 플레인 이벤트가 표시됩니다. 그러나 키 또는 기타 ID 기반 데이터 평면 작업의 후속 사용을 추적하도록 스토리지 계정에 대한 리소스 로그도 구성해야 합니다. 일반 Functions 작업 이외의 데이터에 대한 수정 사항을 식별할 수 있도록 StorageWrite 로그 범주 이상을 사용하도록 설정해야 합니다.
광범위한 범위의 스토리지 권한의 잠재적 영향을 제한하려면 Log Analytics와 같은 이러한 로그에 대해 비스토리지 대상을 사용하는 것이 좋습니다. 자세한 내용은 Azure Blob Storage 모니터링을 참조하세요.
스토리지 성능 최적화
성능을 최대화하려면 각 함수 앱에 대해 별도의 스토리지 계정을 사용하세요. 이는 많은 양의 스토리지 트랜잭션을 생성하는 Durable Functions 또는 Event Hub 트리거 함수가 있는 경우에 특히 중요합니다. 애플리케이션 로직이 직접(Storage SDK를 사용하여) 또는 스토리지 바인딩 중 하나를 통해 Azure Storage와 상호 작용하는 경우 전용 스토리지 계정을 사용해야 합니다. 예를 들어 일부 데이터를 Blob Storage에 기록하는 Event Hub 트리거 함수가 있는 경우 두 개의 스토리지 계정을 사용하는데, 하나는 함수 앱용 스토리지 계정이고, 다른 하나는 함수가 저장하는 Blob용 스토리지 계정입니다.
가상 네트워크를 통한 일관된 라우팅
동일한 플랜에서 호스트되는 여러 함수 앱은 Azure Files 콘텐츠 공유에 대해 동일한 스토리지 계정을 사용할 수도 있습니다(WEBSITE_CONTENTAZUREFILECONNECTIONSTRING에서 정의됨). 이 스토리지 계정도 가상 네트워크에서 보호되는 경우 이러한 모든 앱은 vnetContentShareEnabled(이전의 WEBSITE_CONTENTOVERVNET)의 동일한 값을 사용하여 트래픽이 의도한 가상 네트워크를 통해 일관되게 라우팅되도록 보장해야 합니다. 동일한 Azure Files 스토리지 계정을 사용하는 앱 간에 이 설정이 일치하지 않으면 트래픽이 공용 네트워크를 통해 라우팅되고 스토리지 계정 네트워크 규칙에 의해 액세스가 차단될 수 있습니다.
Blob 작업
Functions의 주요 시나리오는 이미지 처리 또는 감정 분석과 같은 Blob 컨테이너의 파일 처리입니다. 자세한 내용은 파일 업로드 처리를 참조하세요.
Blob 컨테이너에서 트리거
스토리지 컨테이너의 Blob에 대한 변경 내용에 따라 함수 코드를 실행하는 여러 방법이 있습니다. 다음 표를 사용하여 요구 사항에 가장 적합한 함수 트리거를 결정합니다.
| 전략 | 컨테이너(폴링) | 컨테이너(이벤트) | 큐 트리거 | Event Grid |
|---|---|---|---|---|
| 대기 시간 | 높음(최대 10분) | 낮음 | 중간 | 낮음 |
| 스토리지 계정 제한 사항 | Blob 전용 계정은 지원되지 않음¹ | 범용 v1은 지원되지 않음 | 없음 | 범용 v1은 지원되지 않음 |
| 트리거 형식 | Blob Storage | Blob Storage | Queue Storage | Event Grid |
| 확장 버전 | 모두 | Storage v5.x 이상 | 모두 | 모두 |
| 기존 Blob 처리 | 예 | 아니요 | 아니요 | 아니요 |
| 필터 | Blob 이름 패턴 | 이벤트 필터 | 해당 없음 | 이벤트 필터 |
| 이벤트 구독 필요 | 예 | 예 | 아니요 | 예 |
| Flex 사용량 플랜 지원 | 예 | 예 | 예 | 예 |
| 대규모 지원² | 예 | 예 | 예 | 예 |
| 설명 | 업데이트를 위해 컨테이너를 폴링하는 기본 트리거 동작입니다. 자세한 내용은 Blob Storage 트리거 참조의 예제를 참조하세요. | 이벤트 구독에서 Blob 스토리지 이벤트를 사용합니다. EventGrid의 Source 매개 변수 값이 필요합니다. 자세한 내용은 자습서: 이벤트 구독을 사용하여 Blob 컨테이너에서 Azure Functions 트리거를 참조하세요. |
Blob이 컨테이너에 추가되면 Blob 이름 문자열이 스토리지 큐에 수동으로 추가됩니다. 이 값은 Queue storage 트리거에서 동일한 함수의 Blob Storage 입력 바인딩에 직접 전달합니다. | 스토리지 컨테이너에서 나오는 이벤트 외에 이벤트에 대해 트리거할 수 있는 유연성을 제공합니다. 스토리지가 아닌 이벤트도 함수를 트리거해야 하는 경우에 사용합니다. 자세한 내용은 Azure Functions에서 Event Grid 트리거 및 바인딩을 사용하는 방법을 참조하세요. |
- Blob Storage 입력 및 출력 바인딩은 Blob 전용 계정을 지원합니다.
- 높은 확장성은 100,000개 이상의 BLOB이 있는 컨테이너 또는 초당 100개 이상의 BLOB 업데이트가 있는 스토리지 계정으로 정의할 수 있습니다.
스토리지 데이터 암호화
Azure Storage는 미사용 스토리지 계정의 모든 데이터를 암호화합니다. 자세한 내용은 미사용 데이터에 대한 Azure Storage 암호화를 참조하세요.
기본적으로 데이터는 Microsoft 관리형 키로 암호화됩니다. 암호화 키에 대한 추가 제어를 위해 Blob 및 파일 데이터의 암호화에 사용할 고객 관리 키를 제공할 수 있습니다. 스토리지 계정에 액세스하려면 이러한 키가 함수에 대한 Azure Key Vault에 있어야 합니다. 자세한 내용은 고객 관리형 키를 사용하여 미사용 암호화를 참조하세요.
지역 내 데이터 보존
모든 고객 데이터가 단일 지역 내에 유지되어야 하는 경우 함수 앱과 연결된 스토리지 계정은 지역 중복을 사용하는 것이어야 합니다. 또한 지역 중복 스토리지 계정은 Azure Durable Functions에서 사용해야 합니다.
다른 플랫폼 관리형 고객 데이터는 내부적으로 부하가 분산된 ASE(App Service Environment)에서 호스팅할 때만 지역에 저장됩니다. 자세한 내용은 ASE 지역 중복성을 참조하세요.
호스트 ID 고려 사항
Functions는 저장된 아티팩트에서 특정 함수 앱을 고유하게 식별하는 방법으로 호스트 ID 값을 사용합니다. 기본적으로 이 ID는 함수 앱의 이름에서 자동 생성되며 처음 32자로 잘립니다. 그런 다음 이 ID는 연결된 스토리지 계정에 앱별 상관 관계 및 추적 정보를 저장할 때 사용됩니다. 이름이 32자보다 긴 함수 앱이 있고 처음 32자가 동일한 경우 이 잘림으로 인해 호스트 ID 값이 중복될 수 있습니다. 동일한 호스트 ID를 가진 두 개의 함수 앱이 동일한 스토리지 계정을 사용하는 경우 저장된 데이터를 올바른 함수 앱에 고유하게 연결할 수 없기 때문에 호스트 ID 충돌이 발생합니다.
참고 항목
두 슬롯이 동일한 스토리지 계정을 사용하는 경우 프로덕션 슬롯의 함수 앱과 스테이징 슬롯의 동일한 함수 앱 간에 동일한 종류의 호스트 ID 충돌이 발생할 수 있습니다.
Functions 런타임 버전 3.x부터 호스트 ID 충돌이 검색되고 경고가 기록됩니다. 버전 4.x에서는 오류가 기록되고 호스트가 중지되어 하드 오류가 발생합니다. 호스트 ID 충돌에 대한 자세한 내용은 이 문제에서 확인할 수 있습니다.
호스트 ID 충돌 방지
다음 전략을 사용하여 호스트 ID 충돌을 피할 수 있습니다.
- 충돌과 관련된 각 함수 앱 또는 슬롯에 대해 별도의 스토리지 계정을 사용합니다.
- 함수 앱 중 하나의 이름을 32자 미만의 값으로 변경하면 앱의 계산된 호스트 ID가 변경되고 충돌이 제거됩니다.
- 하나 이상의 충돌 앱에 대해 명시적 호스트 ID를 설정합니다. 자세한 내용은 호스트 ID 재정의를 참조하세요.
Important
기존 함수 앱과 연결된 스토리지 계정을 변경하거나 앱의 호스트 ID를 변경하면 기존 함수의 동작에 영향을 줄 수 있습니다. 예를 들어 Blob Storage 트리거는 스토리지의 특정 호스트 ID 경로 아래에 영수증을 작성하여 개별 Blob이 처리되었는지 여부를 추적합니다. 호스트 ID가 변경되거나 새 스토리지 계정을 가리키면 이전에 처리된 Blob이 다시 처리될 수 있습니다.
호스트 ID 재정의
AzureFunctionsWebHost__hostid 설정을 사용하여 애플리케이션 설정에서 함수 앱의 특정 호스트 ID를 명시적으로 설정할 수 있습니다. 자세한 내용은 AzureFunctionsWebHost__hostid를 참조하세요.
슬롯 간에 충돌이 발생하면 프로덕션 슬롯을 포함하여 각 슬롯에 대해 특정 호스트 ID를 설정해야 합니다. 또한 이러한 설정을 배포 설정으로 표시해야 교환되지 않습니다. 앱 설정을 만드는 방법을 알아보려면 애플리케이션 설정 작업을 참조하세요.
Azure Arc 사용 클러스터
함수 앱이 Azure Arc 지원 Kubernetes 클러스터에 배포되면 함수 앱에 스토리지 계정이 필요하지 않을 수 있습니다. 이 경우 스토리지 계정은 함수 앱이 스토리지가 필요한 트리거를 사용할 때만 Functions에 필요합니다. 다음 표에는 스토리지 계정이 필요할 수 있는 트리거와 필요하지 않은 트리거가 나와 있습니다.
| 필요하지 않음 | 스토리지가 필요할 수 있음 |
|---|---|
| • Azure Cosmos DB • HTTP • Kafka • RabbitMQ • Service Bus |
• Azure SQL • Blob 스토리지 • Event Grid • Event Hubs • IoT Hub • 큐 스토리지 • SendGrid • SignalR • 테이블 스토리지 • 타이머 • Twilio |
스토리지 없이 Azure Arc 지원 Kubernetes 클러스터에서 함수 앱을 만들려면 Azure CLI 명령 az functionapp create를 사용해야 합니다. Azure CLI 버전에는 버전 0.1.7 이상 버전의 appservice-kube 확장이 포함되어야 합니다. az --version 명령을 사용하여 확장이 설치되어 있고 올바른 버전인지 확인합니다.
Azure CLI 이외의 방법을 사용하여 함수 앱 리소스를 만들려면 기존 스토리지 계정이 필요합니다. 스토리지 계정이 필요한 트리거를 사용하려는 경우 함수 앱을 만들기 전에 계정을 만들어야 합니다.
Azure Files 없이 앱 만들기
Azure Files 서비스는 대규모 시나리오를 지원하는 공유 파일 시스템을 제공합니다. 함수 앱이 Windows에서 탄력적 프리미엄 또는 사용량 플랜으로 실행되면 스토리지 계정에 기본적으로 Azure Files 공유가 만들어집니다. 해당 공유는 Functions에서 로그 스트리밍과 같은 특정 기능을 사용하도록 설정하는 데 사용됩니다. 또한 모든 인스턴스에서 배포된 함수 코드의 일관성을 보장하는 공유 패키지 배포 위치로도 사용됩니다.
기본적으로 프리미엄 및 사용량 플랜에서 호스트되는 함수 앱은 이 Azure 파일 공유에 배포 패키지가 저장된 zip 배포를 사용합니다. 이 섹션은 이러한 호스팅 플랜에만 관련됩니다.
Azure Files를 사용하려면 앱 설정에 WEBSITE_CONTENTAZUREFILECONNECTIONSTRING으로 저장되는 연결 문자열을 사용해야 합니다. Azure Files는 현재 ID 기반 연결을 지원하지 않습니다. 시나리오에서 앱 설정에 비밀을 저장하지 않도록 요구하는 경우 Azure Files에 대한 앱의 종속성을 제거해야 합니다. 기본 Azure Files 종속성 없이 앱을 만들어 이를 수행할 수 있습니다.
참고 항목
또한 관리 ID 연결을 사용하는 기능을 포함하여 배포 패키지에 대한 더 큰 제어를 제공하는 Flex Consumption 계획의 함수 앱에서 실행하는 것을 고려해야 합니다. 자세한 내용은 Flex 사용량 문서의 배포 설정 구성을 참조하세요.
Azure 파일 공유 없이 앱을 실행하려면 다음 요구 사항을 충족해야 합니다.
- 패키지를 원격 Azure Blob Storage 컨테이너에 배포한 다음 해당 패키지에 대한 액세스를 제공하는 URL을
WEBSITE_RUN_FROM_PACKAGE앱 설정으로 설정해야 합니다. 이 옵션을 사용하면 관리 ID를 지원하는 Azure Files 대신 Blob Storage에 앱 콘텐츠를 저장할 수 있습니다.
배포 패키지를 수동으로 업데이트하고 SAS(공유 액세스 서명)가 포함되어 있을 수 있는 배포 패키지 URL을 유지 관리할 책임은 사용자에게 있습니다.
- 앱은 쓰기 가능한 공유 파일 시스템에 의존할 수 없습니다.
- 앱은 Functions 런타임 버전 1.x를 사용할 수 없습니다.
- Azure Portal과 같은 클라이언트의 로그 스트리밍 환경은 기본적으로 파일 시스템 로그입니다. Application Insights 로그를 대신 사용해야 합니다.
위 요구 사항이 시나리오에 적합하면 Azure Files 없이 함수 앱을 만들 수 있습니다. WEBSITE_CONTENTAZUREFILECONNECTIONSTRING 및 WEBSITE_CONTENTSHARE 앱 설정 없이 앱을 만들면 이 작업을 수행할 수 있습니다. 시작하려면 표준 배포를 위한 ARM 템플릿을 생성하고 두 설정을 제거한 다음 수정된 템플릿을 배포합니다.
Azure Files는 Functions에 대한 동적 스케일 아웃을 사용하도록 설정하는 데 사용되므로 Windows에서 실행되는 탄력적 프리미엄 플랜 및 사용량 플랜에서 Azure Files 없이 앱을 실행할 때 스케일 아웃이 제한될 수 있습니다.
파일 공유 탑재
이 기능은 현재 Linux에서 실행하는 경우에만 사용할 수 있습니다.
기존 Azure Files 공유를 Linux 함수 앱에 탑재할 수 있습니다. Linux 함수 앱에 공유를 탑재하면 기존 기계 학습 모델 또는 함수의 기타 데이터를 사용할 수 있습니다. 다음 명령을 사용하여 Linux 함수 앱에 기존 공유를 탑재할 수 있습니다.
az webapp config storage-account add
이 명령에서 share-name은 기존 Azure Files 공유의 이름이며 custom-id는 함수 앱에 탑재될 때 공유를 고유하게 정의하는 문자열일 수 있습니다. 또한 mount-path는 함수 앱에서 공유에 액세스하는 경로입니다. mount-path는 /dir-name 형식이어야 하며 /home으로 시작할 수 없습니다.
전체 예제는 Python 함수 앱 만들기 및 Azure Files 공유 탑재의 스크립트를 참조하세요.
현재는 AzureFiles의 storage-type만 지원됩니다. 지정된 함수 앱에는 5개의 공유만 탑재할 수 있습니다. 파일 공유를 탑재하면 콜드 부팅 시간이 최소한 200~300ms 증가하며 스토리지 계정이 다른 지역에 있는 경우 훨씬 더 증가할 수 있습니다.
탑재된 공유는 지정된 mount-path에서 함수 코드에 사용할 수 있습니다. 예를 들어 mount-path가 /path/to/mount인 경우 다음 Python 예제와 같이 파일 시스템 API를 통해 대상 디렉터리에 액세스할 수 있습니다.
import os
...
files_in_share = os.listdir("/path/to/mount")
다음 단계
Azure Functions 호스팅 옵션에 대해 자세히 알아보세요.