Azure Functions의 스토리지 고려 사항
함수 앱 인스턴스를 만들 때 Azure Functions에는 Azure Storage 계정이 필요합니다. 함수 앱에서 사용할 수 있는 스토리지 서비스는 다음과 같습니다.
| 스토리지 서비스 | 함수 사용 |
|---|---|
| Azure Blob Storage | 바인딩 상태 및 함수 키를 유지 관리합니다1. Durable Functions의 작업 허브에 기본적으로 사용됩니다. Linux 소비 원격 빌드 또는 외부 패키지 URL 배포의 일부로 함수 앱 코드를 저장하는 데 사용할 수 있습니다. |
| Azure Files2 | 사용 플랜 및 프리미엄 플랜에서 함수 앱 코드를 저장 및 실행하는 데 사용되는 파일 공유입니다. |
| Azure Queue Storage | Durable Functions의 작업 허브에 기본적으로 사용됩니다. 특정 Azure Functions 트리거의 실패 및 재시도 처리에 사용됩니다. Blob Storage 트리거에 의한 개체 추적에 사용됩니다. |
| Azure Table Storage | Durable Functions의 작업 허브에 기본적으로 사용됩니다. |
1 Blob Storage는 함수 키의 기본 저장소이지만 대체 저장소를 구성할 수 있습니다.
2 Azure Files는 기본적으로 설정되지만 특정 조건에서 Azure Files 없이 앱을 만들 수 있습니다.
중요 사항
함수 앱에서 사용하는 스토리지 계정과 관련하여 다음과 같은 사실을 강력히 고려해야 합니다.
함수 앱이 사용 계획 또는 프리미엄 계획에서 호스트되는 경우 함수 코드 및 구성 파일은 연결된 스토리지 계정의 Azure Files에 저장됩니다. 이 스토리지 계정을 삭제하면 콘텐츠가 삭제되고 복구할 수 없습니다. 자세한 내용은 스토리지 계정이 삭제됨을 참조하세요.
함수 코드, 액세스 키 및 기타 중요한 서비스 관련 데이터와 같은 중요한 데이터를 스토리지 계정에 유지할 수 있습니다. 다음과 같은 방법으로 함수 앱에서 사용하는 스토리지 계정에 대한 액세스를 신중하게 관리해야 합니다.
최소 권한 모델을 기반으로 앱 및 사용자의 스토리지 계정에 대한 액세스를 감사하고 제한합니다. 스토리지 계정에 대한 권한은 할당된 역할의 데이터 작업 또는 listKeys 작업을 수행하는 권한을 통해 얻을 수 있습니다.
스토리지 계정에서 컨트롤 플레인 작업(예: 키 검색)과 데이터 평면 작업(예: Blob에 쓰기)을 모두 모니터링합니다. Azure Storage 이외의 위치에서 스토리지 로그를 유지 관리하는 것이 좋습니다. 자세한 내용은 스토리지 로그를 참조하세요.
Storage 계정 요구 사항
Azure Portal의 함수 앱 만들기 흐름의 일부로 생성된 스토리지 계정은 새 함수 앱에서 작동할 수 있습니다. 포털에서 지원되지 않는 계정은 함수 앱을 만드는 동안 기존 스토리지 계정을 선택할 때 필터링됩니다. 함수 앱에서 기존 스토리지 계정을 사용할 수도 있습니다. 함수 앱에서 사용하는 스토리지 계정에는 다음과 같은 제한 사항이 적용되므로 기존 스토리지 계정이 이러한 요구 사항을 충족하는지 확인해야 합니다.
계정 유형은 Blob, 큐 및 테이블 스토리지를 지원해야 합니다. 일부 스토리지 계정은 큐 및 테이블을 지원하지 않습니다. 해당 계정에는 Blob 전용 스토리지 계정 및 Azure Premium Storage가 포함됩니다. 스토리지 계정 형식에 대한 자세한 내용은 스토리지 계정 개요를 참조하세요.
방화벽 또는 가상 사설망을 사용하여 이미 보호되는 스토리지 계정은 포털 만들기 흐름에서 사용할 수 없습니다. 자세한 내용은 스토리지 계정을 가상 네트워크로 제한을 참조하세요.
포털에서 함수 앱을 만들 때 만드는 함수 앱과 동일한 지역에 있는 기존 스토리지 계정만 선택할 수 있습니다. 이는 성능 최적화이며 엄격한 제한 사항이 아닙니다. 자세한 내용은 Storage 계정 위치를 참조하세요.
가용성 영역 지원이 사용하도록 설정된 계획에 따라 함수 앱을 만드는 경우 영역 중복 스토리지 계정만 지원됩니다.
스토리지 계정 지침
모든 함수 앱에서 작동하려면 스토리지 계정이 필요합니다. 해당 계정이 삭제되면 함수 앱이 실행되지 않습니다. 스토리지 관련 문제를 해결하려면 스토리지 관련 문제를 해결하는 방법을 참조하세요. 함수 앱에서 사용하는 스토리지 계정에는 다음 기타 고려 사항이 적용됩니다.
스토리지 계정 위치
최상의 성능을 위해 함수 앱은 동일한 지역의 스토리지 계정을 사용하여 대기 시간을 줄여야 합니다. 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 모니터링을 참조하세요.
스토리지 성능 최적화
성능을 최대화하려면 각 함수 앱에 대해 별도의 스토리지 계정을 사용합니다. 이는 지속성 함수 또는 Event Hub 트리거 함수가 있을 때 특히 중요합니다. 이 함수는 둘 다 대량의 스토리지 트랜잭션을 생성합니다. 애플리케이션 논리가 직접(Storage SDK 사용) 또는 스토리지 바인딩 중 하나를 통해 Azure Storage와 상호 작용하는 경우 전용 스토리지 계정을 사용해야 합니다. 예를 들어 일부 데이터를 Blob Storage에 기록하는 Event Hub 트리거 함수가 있는 경우 두 개의 스토리지 계정을 사용하는데, 하나는 함수 앱용 스토리지 계정이고, 다른 하나는 함수가 저장하는 Blob용 스토리지 계정입니다.
Blob 작업
Functions의 주요 시나리오는 이미지 처리 또는 감정 분석과 같은 Blob 컨테이너의 파일 처리입니다. 자세한 내용은 파일 업로드 처리를 참조하세요.
Blob 컨테이너에서 트리거
스토리지 컨테이너의 Blob에 대한 변경 내용에 따라 함수 코드를 실행하는 여러 방법이 있습니다. 다음 표를 사용하여 요구 사항에 가장 적합한 함수 트리거를 결정합니다.
| 고려 사항 | Blob Storage(표준) | Blob Storage(이벤트 기반) | Queue Storage | Event Grid |
|---|---|---|---|---|
| 대기 시간 | 높음(최대 10분) | 낮음 | 중간 | 낮음 |
| 스토리지 계정 제한 사항 | Blob 전용 계정은 지원되지 않음¹ | 범용 v1은 지원되지 않음 | 없음 | 범용 v1은 지원되지 않음 |
| 확장 버전 | 모두 | Storage v5.x 이상 | 모두 | 모두 |
| 기존 Blob 처리 | 예 | 없음 | 아니요 | 아니요 |
| 필터 | Blob 이름 패턴 | 이벤트 필터 | 해당 없음 | 이벤트 필터 |
| 이벤트 구독 필요 | 예 | 네 | 아니요 | 예 |
| 대규모 지원² | 예 | 네 | 네 | 예 |
| 설명 | 업데이트를 위해 컨테이너를 폴링하는 기본 트리거 동작입니다. 자세한 내용은 Blob Storage 트리거 참조의 예제를 참조하세요. | 이벤트 구독에서 Blob 스토리지 이벤트를 사용합니다. EventGrid의 Source 매개 변수 값이 필요합니다. 자세한 내용은 자습서: 이벤트 구독을 사용하여 Blob 컨테이너에서 Azure Functions 트리거를 참조하세요. |
Blob이 컨테이너에 추가되면 Blob 이름 문자열이 스토리지 큐에 수동으로 추가됩니다. 이 값은 Queue Storage 트리거에서 동일한 함수의 Blob Storage 입력 바인딩에 직접 전달합니다. | 스토리지 컨테이너에서 나오는 이벤트 외에 이벤트에 대해 트리거할 수 있는 유연성을 제공합니다. 스토리지가 아닌 이벤트도 함수를 트리거해야 하는 경우에 사용합니다. 자세한 내용은 Azure Functions에서 Event Grid 트리거 및 바인딩을 사용하는 방법을 참조하세요. |
1 Blob Storage 입력 및 출력 바인딩은 Blob 전용 계정을 지원합니다.
2 높은 확장성은 100,000개가 넘는 Blob이 있는 컨테이너 또는 초당 100개가 넘는 Blob 업데이트가 있는 스토리지 계정으로 정의할 수 있습니다.
스토리지 데이터 암호화
Azure Storage는 미사용 스토리지 계정의 모든 데이터를 암호화합니다. 자세한 내용은 미사용 데이터에 대한 Azure Storage 암호화를 참조하세요.
기본적으로 데이터는 Microsoft 관리형 키로 암호화됩니다. 암호화 키에 대한 추가 제어를 위해 Blob 및 파일 데이터의 암호화에 사용할 고객 관리형 키를 제공할 수 있습니다. 이러한 키는 스토리지 계정에 액세스할 수 있도록 Functions용 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는 확장성이 높은 시나리오에서 공유 파일 시스템으로 사용할 수 있도록 탄력적 프리미엄 및 Linux가 아닌 소비 계획에 대해 기본적으로 설정되어 있습니다. 파일 시스템은 로그 스트리밍과 같은 일부 기능에 대해 플랫폼에서 사용되지만 주로 배포된 함수 페이로드의 일관성을 보장합니다. 앱이 외부 패키지 URL을 사용하여 배포되면 앱 콘텐츠는 별도의 읽기 전용 파일 시스템에서 제공됩니다. 즉, Azure Files 없이 함수 앱을 만들 수 있습니다. Azure Files를 사용하여 함수 앱을 만드는 경우 쓰기 가능한 파일 시스템이 계속 제공됩니다. 그러나 이 파일 시스템은 모든 함수 앱 인스턴스에 사용할 수 없습니다.
Azure Files를 사용하지 않는 경우 다음 요구 사항을 충족해야 합니다.
- 외부 패키지 URL에서 배포해야 합니다.
- 앱은 쓰기 가능한 공유 파일 시스템에 의존할 수 없습니다.
- 앱은 Functions 런타임 버전 1.x를 사용할 수 없습니다.
- Azure Portal과 같은 클라이언트의 로그 스트리밍 환경은 기본적으로 파일 시스템 로그입니다. 대신 Application Insights 로그를 사용해야 합니다.
위의 사항을 제대로 고려한 경우 Azure Files 없이 앱을 만들 수 있습니다. 및 애플리케이션 설정을 지정 WEBSITE_CONTENTAZUREFILECONNECTIONSTRINGWEBSITE_CONTENTSHARE 하지 않고 함수 앱을 만듭니다. 표준 배포용 ARM 템플릿을 생성하고 두 설정을 제거한 다음 템플릿을 배포하면 이러한 설정을 방지할 수 있습니다.
Functions는 동적 스케일 아웃 프로세스의 일부 동안 Azure Files를 사용하기 때문에 소비 및 탄력적 프리미엄 계획에서 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 공유 탑재의 스크립트를 참조하세요.
현재는 1개 storage-typeAzureFiles 만 지원됩니다. 지정된 함수 앱에 5개의 공유만 탑재할 수 있습니다. 파일 공유를 탑재하면 스토리지 계정이 다른 지역에 있는 경우 콜드 시작 시간이 200-300ms 이상 증가할 수 있습니다.
탑재된 공유는 지정된 함수 코드에서 mount-path 사용할 수 있습니다. 예를 들어 mount-path가 /path/to/mount인 경우 다음 Python 예제와 같이 파일 시스템 API를 통해 대상 디렉터리에 액세스할 수 있습니다.
import os
...
files_in_share = os.listdir("/path/to/mount")
다음 단계
Azure Functions 호스팅 옵션에 대해 자세히 알아보세요.