Azure Functions의 스토리지 고려 사항
함수 앱 인스턴스를 만들 때 Azure Functions에는 Azure Storage 계정이 필요합니다. 함수 앱에서 사용할 수 있는 스토리지 서비스는 다음과 같습니다.
| 스토리지 서비스 | Functions 사용 |
|---|---|
| Azure Blob Storage | 바인딩 상태 및 함수 키를 유지 관리합니다. Durable Functions의 작업 허브에서도 사용됩니다. |
| Azure 파일 | 사용 플랜 및 프리미엄 플랜에서 함수 앱 코드를 저장 및 실행하는 데 사용되는 파일 공유입니다. Azure Files는 기본적으로 설정되지만 특정 조건에서 Azure Files 없이 앱을 만들 수 있습니다. |
| Azure Queue Storage | Durable Functions의 작업 허브와 특정 Azure Functions 트리거에 의한 실패 및 다시 시도 처리에 사용됩니다. |
| Azure Table Storage | Durable Functions의 작업 허브에서 사용됩니다. |
중요
사용/프리미엄 호스팅 계획을 사용하는 경우 함수 코드 및 바인딩 구성 파일은 기본 스토리지 계정의 Azure Files에 저장됩니다. 기본 스토리지 계정을 삭제하면 이 콘텐츠는 삭제되고 복구할 수 없습니다.
Storage 계정 요구 사항
함수 앱을 만들 때 Blob, Queue 및 Table 스토리지를 지원하는 범용 Azure Storage 계정을 만들거나 해당 계정에 연결해야 합니다. 이 요구 사항은 Functions가 트리거 관리 및 함수 실행 로깅과 같은 작업을 위해 Azure Storage에 의존하기 때문에 존재합니다. 일부 스토리지 계정은 큐 및 테이블을 지원하지 않습니다. 해당 계정에는 Blob 전용 스토리지 계정 및 Azure Premium Storage가 포함됩니다.
스토리지 계정 형식에 대한 자세한 내용은 스토리지 계정 개요를 참조하세요.
함수 앱에서 기존 스토리지 계정을 사용할 수 있지만 관련 요구 사항을 충족하는지 확인해야 합니다. Azure Portal의 함수 앱 만들기 흐름의 일부로 생성된 스토리지 계정은 관련 스토리지 계정 요구 사항을 충족합니다. Portal에서 함수 앱을 만드는 동안 기존 스토리지 계정을 선택하면 지원되지 않는 계정이 필터링됩니다. 이 흐름에서는 만들려는 함수 앱과 동일한 지역에 있는 기존 스토리지 계정만 선택할 수 있습니다. 자세한 내용은 스토리지 계정 위치를 참조하세요.
방화벽 또는 가상 사설망을 사용하여 보호되는 스토리지 계정은 포털 만들기 흐름에서도 사용할 수 없습니다. 자세한 내용은 스토리지 계정을 가상 네트워크로 제한을 참조하세요.
스토리지 계정 지침
모든 함수 앱은 스토리지 계정이 있어야 작동합니다. 해당 계정이 삭제되면 함수 앱이 실행되지 않습니다. 스토리지 관련 문제를 해결하려면 스토리지 관련 문제를 해결하는 방법을 참조하세요. 함수 앱에서 사용하는 스토리지 계정에는 다음 기타 고려 사항이 적용됩니다.
스토리지 계정 위치
최상의 성능을 위해 함수 앱은 대기 시간이 감소하도록 동일한 지역에서 스토리지 계정을 사용해야 합니다. Azure Portal은 이 모범 사례를 적용합니다. 어떤 이유로든 함수 앱과 다른 지역에서 스토리지 계정을 사용해야 하는 경우 Portal 외부에서 함수 앱을 만들어야 합니다.
스토리지 계정은 함수 앱에서 액세스할 수 있어야 합니다. 보안 스토리지 계정을 사용해야 하는 경우 스토리지 계정을 가상 네트워크로 제한하는 것이 좋습니다.
스토리지 계정 연결 설정
스토리지 계정 연결은 AzureWebJobsStorage 애플리케이션 설정에서 유지 관리됩니다.
스토리지 키를 다시 생성하는 경우 스토리지 계정 연결 문자열을 업데이트해야 합니다. 여기에서 스토리지 키 관리에 관해 자세히 알아보세요.
공유 스토리지 계정
여러 함수 앱에서 문제 없이 동일한 스토리지 계정을 공유할 수 있습니다. 예를 들어 Visual Studio에서 Azurite 스토리지 에뮬레이터를 사용하여 여러 앱을 개발할 수 있습니다. 이 경우 에뮬레이터는 단일 스토리지 계정처럼 작동합니다. 함수 앱에서 사용하는 동일한 스토리지 계정을 사용하여 애플리케이션 데이터를 저장할 수도 있습니다. 그러나 프로덕션 환경에서는 이 접근 방법이 항상 좋은 것은 아닙니다.
호스트 ID 충돌을 방지하려면 별도의 스토리지 계정을 사용해야 할 수 있습니다.
수명 주기 관리 정책 고려 사항
Functions는 Blob Storage를 사용하여 함수 액세스 키와 같은 중요한 정보를 유지합니다. Blob Storage 계정에 수명 주기 관리 정책을 적용하면 정책에 따라 Functions 호스트에 필요한 Blob이 제거될 수 있습니다. 이 팩트 때문에 Functions에서 사용하는 스토리지 계정에 이러한 정책을 적용하면 안 됩니다. 이러한 정책을 적용해야 하는 경우 azure-webjobs 또는 scm 접두사가 붙은 Functions에서 사용하는 컨테이너를 제외해야 합니다.
스토리지 성능 최적화
성능을 최대화하려면 각 함수 앱에 대해 별도의 스토리지 계정을 사용하세요. 이는 많은 양의 스토리지 트랜잭션을 생성하는 Durable Functions 또는 Event Hub 트리거 함수가 있는 경우에 특히 중요합니다. 애플리케이션 로직이 직접(Storage SDK를 사용하여) 또는 스토리지 바인딩 중 하나를 통해 Azure Storage와 상호 작용하는 경우 전용 스토리지 계정을 사용해야 합니다. 예를 들어 일부 데이터를 Blob Storage에 기록하는 Event Hub 트리거 함수가 있는 경우 두 개의 스토리지 계정을 사용하는데, 하나는 함수 앱용 스토리지 계정이고, 다른 하나는 함수가 저장하는 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 재정의를 참조하세요.
중요
기존 함수 앱과 연결된 스토리지 계정을 변경하거나 앱의 호스트 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_CONTENTAZUREFILECONNECTIONSTRING 및 WEBSITE_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 공유 탑재의 스크립트를 참조하세요.
현재는 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 호스팅 옵션에 관해 자세히 알아보세요.