Azure Functions 개발자 가이드

아티클
09/22/2023

Azure Functions의 모든 함수는 기본 언어 또는 개발 환경에 관계없이 몇 가지 핵심 기술 개념 및 구성 요소를 공유합니다. 이 문서는 언어별로 다릅니다. 문서 맨 위에서 원하는 언어를 선택합니다.

이 문서에서는 Azure Functions 개요를 이미 읽었다고 가정합니다.

바로 시작하려면 Visual Studio, Visual Studio Code 또는 명령 프롬프트에서 빠른 시작 자습서를 완료할 수 있습니다.

바로 시작하려면 Maven(명령줄), Eclipse, IntelliJ IDEA, Gradle, Quarkus, Spring Cloud 또는 Visual Studio Code를 사용하여 빠른 시작 자습서를 완료할 수 있습니다.

바로 시작하려면 Visual Studio Code 또는 명령 프롬프트에서 빠른 시작 자습서를 완료할 수 있습니다.

코드 프로젝트

Azure Functions 핵심은 함수라는 하나 이상의 코드 실행 단위를 구현하는 언어별 코드 프로젝트입니다. 함수는 이벤트, HTTP 요청에 대한 응답 또는 일정에 따라 Azure 클라우드에서 실행되는 메서드일 뿐입니다. Azure Functions 코드 프로젝트를 Azure에서 실행할 때 프로젝트에서 개별 함수를 구성, 배포 및 공동으로 관리하는 메커니즘이라고 생각하세요. 자세한 내용은 함수 구성을 참조하세요.

코드 프로젝트를 배치하는 방법과 프로젝트에서 함수인 메서드를 나타내는 방법은 프로젝트의 개발 언어에 따라 달라집니다. 자세한 언어별 지침은 C# 개발자 가이드를 참조하세요.

코드 프로젝트를 배치하는 방법과 프로젝트에서 함수인 메서드를 나타내는 방법은 프로젝트의 개발 언어에 따라 달라집니다. 자세한 언어별 지침은 Java 개발자 가이드를 참조하세요.

코드 프로젝트를 배치하는 방법과 프로젝트에서 함수인 메서드를 나타내는 방법은 프로젝트의 개발 언어에 따라 달라집니다. 자세한 언어별 지침은 Node.js 개발자 가이드를 참조하세요.

코드 프로젝트를 배치하는 방법과 프로젝트에서 함수인 메서드를 나타내는 방법은 프로젝트의 개발 언어에 따라 달라집니다. 자세한 언어별 지침은 PowerShell 개발자 가이드를 참조하세요.

코드 프로젝트를 배치하는 방법과 프로젝트에서 함수인 메서드를 나타내는 방법은 프로젝트의 개발 언어에 따라 달라집니다. 자세한 언어별 지침은 Python 개발자 가이드를 참조하세요.

모든 함수에는 함수가 시작되는 방법을 정의하고 함수에 입력을 제공할 수 있는 트리거가 있어야 합니다. 함수는 필요에 따라 입력 및 출력 바인딩을 정의할 수 있습니다. 이러한 바인딩은 클라이언트 SDK를 사용하지 않고도 다른 서비스에 대한 연결을 간소화합니다. 자세한 내용은 Azure Functions 트리거 및 바인딩 개념을 참조하세요.

Azure Functions는 새 코드 프로젝트를 쉽게 만들고 프로젝트에 함수를 추가할 수 있는 언어별 프로젝트 및 함수 템플릿 집합을 제공합니다. Azure Functions 개발을 지원하는 도구를 사용하여 이러한 템플릿을 사용하여 새 앱과 함수를 생성할 수 있습니다.

개발 도구

다음 도구는 원하는 언어로 Azure Functions에 대한 통합 개발 및 게시 환경을 제공합니다.

Visual Studio

Visual Studio Code
Azure Functions Core Tools(명령줄)

이러한 도구는 Azure Functions Core Tools와 통합되므로 Functions 런타임을 사용하여 로컬 컴퓨터에서 실행하고 디버그할 수 있습니다. 자세한 내용은 Azure Functions를 로컬에서 코딩 및 테스트를 참조하세요.

Azure Portal에는 포털에서 직접 코드 및 function.json 정의 파일을 업데이트할 수 있는 편집기도 있습니다. 이 편집기는 작은 변경 또는 개념 증명 함수 만들기에만 사용해야 합니다. 가능하면 항상 로컬에서 함수를 개발해야 합니다. 자세한 내용은 Azure Portal에서 첫 번째 함수 만들기를 참조하세요.

포털 편집은 function.json 파일을 사용하는 Node.js 버전 3에서만 지원됩니다.

포털 편집은 function.json 파일을 사용하는 Python 버전 1에서만 지원됩니다.

배포

코드 프로젝트를 Azure에 게시하는 경우 기본적으로 기존 함수 앱 리소스에 프로젝트를 배포합니다. 함수 앱은 함수가 실행되는 Azure의 실행 컨텍스트를 제공합니다. 함수에 대한 배포 및 관리 단위입니다. Azure 리소스 관점에서 함수 앱은 웹앱과 동일한 Azure App Service의 사이트 리소스(Microsoft.Web/sites)와 동일합니다.

함수 앱은 함께 관리, 배포 및 스케일링되는 하나 이상의 개별 함수로 구성됩니다. 함수 앱의 모든 함수는 동일한 가격 책정 계획, 배포 방법 및 런타임 버전을 공유합니다. 자세한 내용은 함수 앱을 관리하는 방법을 참조하세요.

함수 앱 및 기타 필수 리소스가 Azure에 아직 없는 경우 먼저 이러한 리소스를 만들어야 프로젝트 파일을 배포할 수 있습니다. 다음 방법 중 하나로 이러한 리소스를 만들 수 있습니다.

Visual Studio 게시 중

Visual Studio Code 사용
Azure CLI, Azure PowerShell, ARM 템플릿 또는 Bicep 템플릿을 사용하여 프로그래밍 방식으로
Azure Portal에서

도구 기반 게시 외에도 Functions는 기존 함수 앱에 소스 코드를 배포하기 위한 다른 기술을 지원합니다. 자세한 내용은 Azure Functions의 배포 기술을 참조하세요.

서비스에 연결

클라우드 기반 컴퓨팅 서비스의 주요 요구 사항은 데이터를 읽고 다른 클라우드 서비스에 쓰는 것입니다. Functions는 클라이언트 SDK를 사용하지 않고도 서비스에 쉽게 연결할 수 있는 광범위한 바인딩 집합을 제공합니다.

Functions에서 제공하는 바인딩 확장을 사용하든 클라이언트 SDK를 직접 사용하든 관계없이 연결 데이터를 안전하게 저장하고 코드에 포함하지 않습니다. 자세한 내용은 연결을 참조하세요.

바인딩

Functions는 확장으로 구현되는 여러 Azure 서비스 및 몇 가지 타사 서비스에 대한 바인딩을 제공합니다. 자세한 내용은 지원되는 바인딩의 전체 목록을 참조하세요.

바인딩 확장은 입력과 출력을 모두 지원할 수 있으며, 많은 트리거도 입력 바인딩 역할을 합니다. 바인딩을 사용하면 Functions 호스트가 데이터 액세스를 처리할 수 있도록 서비스에 대한 연결을 구성할 수 있습니다. 자세한 내용은 Azure Functions 트리거 및 바인딩 개념을 참조하세요.

바인딩에서 발생하는 오류에 문제가 있는 경우 Azure Functions 바인딩 오류 코드 설명서를 참조하세요.

클라이언트 SDK

Functions는 함수 코드에서 데이터 액세스를 간소화하는 바인딩을 제공하지만 원하는 경우 프로젝트에서 클라이언트 SDK를 사용하여 지정된 서비스에 직접 액세스할 수 있습니다. 함수에 바인딩 확장에서 지원되지 않는 기본 SDK의 기능이 필요한 경우 클라이언트 SDK를 직접 사용해야 할 수 있습니다.

클라이언트 SDK를 사용하는 경우 바인딩 확장에서 사용하는 연결 문자열을 저장하고 액세스하는 데 동일한 프로세스를 사용해야 합니다.

함수에서 클라이언트 SDK 인스턴스를 만들 때 환경 변수에서 클라이언트에 필요한 연결 정보를 가져와야 합니다.

연결

보안 모범 사례로 Azure Functions에서는 Azure App Service의 애플리케이션 설정 기능을 활용하여 다른 서비스에 연결하는 데 필요한 문자열, 키 및 기타 토큰을 보다 안전하게 저장할 수 있습니다. Azure의 애플리케이션 설정은 암호화된 상태로 저장되며 앱에서 런타임에 name환경 변수value 쌍으로 액세스할 수 있습니다. 연결 속성이 필요한 트리거 및 바인딩의 경우 실제 연결 문자열 대신 애플리케이션 설정 이름을 설정합니다. 연결 문자열 또는 키를 사용하여 바인딩을 직접 구성할 수 없습니다.

예를 들어 connection 속성이 있는 트리거 정의를 고려합니다. 연결 문자열 대신 connection을 연결 문자열을 포함하는 환경 변수의 이름으로 설정합니다. 이 비밀 액세스 전략을 사용하면 앱을 더 안전하게 보호하고 환경 간에 연결을 더 쉽게 변경할 수 있습니다. 보안을 강화하려면 ID 기반 연결을 사용할 수 있습니다.

기본 구성 공급자는 환경 변수를 사용합니다. 이러한 변수는 Azure에서 실행할 때 애플리케이션 설정에 정의되고 로컬로 개발할 때는 로컬 설정 파일에 정의됩니다.

연결 값

연결 이름이 정확한 단일 값으로 확인되면 런타임은 일반적으로 비밀을 포함하는 연결 문자열로 값을 식별합니다. 연결 문자열의 세부 정보는 연결하려는 서비스에 따라 다릅니다.

그러나 연결 이름은 ID 기반 연결을 구성하는 데 유용한 여러 구성 항목 컬렉션을 참조할 수도 있습니다. 이중 밑줄(__)로 끝나는 공유 접두사를 사용하여 환경 변수를 컬렉션으로 처리할 수 있습니다. 그런 다음 연결 이름을 이 접두사로 설정하여 그룹을 참조할 수 있습니다.

예를 들어 Azure Blob 트리거 정의에 대한 connection 속성이 Storage1일 수 있습니다. Storage1이라는 환경 변수로 구성된 단일 문자열 값이 없는 한 Storage1__blobServiceUri라는 환경 변수를 사용하여 연결의 blobServiceUri 속성을 알릴 수 있습니다. 연결 속성은 각 서비스마다 다릅니다. 연결을 사용하는 구성 요소에 대한 설명서를 참조하세요.

참고 항목

Azure App Configuration 또는 Key Vault를 사용하여 관리 ID 연결에 대한 설정을 제공하는 경우 설정 이름은 올바르게 확인되도록 __ 대신 : 또는 /와 같은 유효한 키 구분 기호를 사용해야 합니다.

예: Storage1:blobServiceUri.

ID 기반 연결 구성

Azure Functions의 일부 연결은 비밀 대신 ID를 사용하도록 구성할 수 있습니다. 지원은 연결을 사용하는 확장에 따라 다릅니다. 경우에 따라 연결하는 서비스에서 ID 기반 연결을 지원하는 경우에도 Functions에서 연결 문자열이 필요할 수 있습니다. 관리 ID로 함수 앱을 구성하는 방법에 대한 자습서는 ID 기반 연결로 함수 앱 만들기 자습서를 참조하세요.

참고 항목

소비 또는 탄력적 프리미엄 계획에서 실행하는 경우 앱은 함수 앱에서 사용하는 스토리지 계정의 Azure Files에 연결할 때 WEBSITE_AZUREFILESCONNECTIONSTRING 및 WEBSITE_CONTENTSHARE 설정을 사용합니다. Azure Files는 파일 공유에 액세스할 때 관리 ID 사용을 지원하지 않습니다. 자세한 내용은 Azure Files 지원되는 인증 시나리오를 참조하세요.

다음 구성 요소는 ID 기반 연결을 지원합니다.

연결 원본	지원되는 계획	자세한 정보
Azure Blob 트리거 및 바인딩	모두	Azure Blob 확장 버전 5.0.0 이상, 확장 번들 3.3.0 이상
Azure 큐 트리거 및 바인딩	모두	Azure 큐 확장 버전 5.0.0 이상, 확장 번들 3.3.0 이상
Azure 테이블(Azure Storage 사용 시)	모두	Azure 테이블 확장 버전 1.0.0 이상, 확장 번들 3.3.0 이상
Azure SQL Database	모두	관리 ID 및 SQL 바인딩을 사용하여 Azure SQL에 함수 앱 연결
Azure Event Hubs 트리거 및 바인딩	모두	Azure Event Hubs 확장 버전 5.0.0 이상, 확장 번들 3.3.0 이상
Azure Service Bus 트리거 및 바인딩	모두	Azure Service Bus 확장 버전 5.0.0 이상, 확장 번들 3.3.0 이상
Azure Event Grid 출력 바인딩	모두	Azure Event Grid 확장 버전 3.3.0 이상, 확장 번들 3.3.0 이상
Azure Cosmos DB 트리거 및 바인딩	모두	Azure Cosmos DB 확장 버전 4.0.0 이상, 확장 번들 4.0.2 이상
Azure SignalR 트리거 및 바인딩	모두	Azure SignalR 확장 버전 1.7.0 이상 확장 번들 3.6.1 이상
Durable Functions 스토리지 공급자(Azure Storage)	모두	Durable Functions 확장 버전 2.7.0 이상 확장 번들 3.3.0 이상
호스트 필수 스토리지("AzureWebJobsStorage")	모두	ID로 호스트 스토리지에 연결

Azure Functions 서비스에서 호스트되는 경우 ID 기반 연결에 관리 ID가 사용됩니다. 사용자가 할당한 ID는 credential 및 clientID 속성을 사용하여 지정할 수 있지만 기본적으로 시스템 할당 ID가 사용됩니다. 리소스 ID를 사용하여 사용자가 할당한 ID를 구성하는 것은 지원되지 않습니다. 로컬 개발과 같은 다른 컨텍스트에서 실행할 때 사용자 지정할 수 있지만 대신 개발자 ID가 사용됩니다. ID 기반 연결을 사용하여 로컬 개발을 참조하세요.

ID에 권한 부여

사용되는 모든 ID에는 의도한 작업을 수행할 수 있는 권한이 있어야 합니다. 대부분 Azure 서비스의 경우 이는 해당 권한을 제공하는 기본 제공 또는 사용자 지정 역할을 사용하여 Azure RBAC에서 역할을 할당해야 함을 의미합니다.

Important

일부 사용 권한은 모든 컨텍스트에 필요하지 않은 대상 서비스에 의해 노출될 수 있습니다. 가능한 경우 최소 권한 원칙을 준수하여 ID에 필요한 권한만 부여하세요. 예를 들어 앱이 데이터 원본에서 읽을 수만 있으면 되는 경우 읽기 권한만 있는 역할을 사용합니다. 읽기 작업에 대한 과도한 권한이 될 수 있으므로 해당 서비스에 쓰기도 허용하는 역할을 할당하는 것은 부적절합니다. 마찬가지로 역할 할당이 읽어야 하는 리소스에 대해서만 범위가 할당되도록 할 수 있습니다.

각 구성 요소에 대한 사용 권한에 대해 알아보려면 다음 탭 중 하나를 선택합니다.

런타임에 Blob 컨테이너에 대한 액세스를 제공하는 역할 할당을 만들어야 합니다. 소유자와 같은 관리 역할로는 충분하지 않습니다. 다음 표는 정상 작동에서 Blob Storage 확장을 사용할 때 권장되는 기본 제공 역할을 보여 줍니다. 작성하는 코드에 따라 애플리케이션에 추가 권한이 필요할 수 있습니다.

바인딩 유형	기본 제공 역할 예
트리거	Storage Blob 데이터 소유자 및Storage 큐 데이터 기여자¹ AzureWebJobsStorage 연결에도 추가 권한을 부여해야 합니다.²
입력 바인딩	Storage Blob 데이터 읽기 권한자
출력 바인딩	Storage Blob 데이터 소유자

¹ Blob 트리거는 연결에 의해 지정된 스토리지 계정의 큐에 포이즌 Blob을 작성하여 여러 다시 시도에서 실패를 처리합니다.

² AzureWebJobsStorage 연결은 트리거를 사용하도록 설정하는 Blob 및 큐에 내부적으로 사용됩니다. ID 기반 연결을 사용하도록 구성된 경우 기본 요구 사항 이상의 추가 권한이 필요합니다. 필요한 권한은 Storage Blob 데이터 소유자, Storage 큐 데이터 기여자 및 Storage 계정 기여자 역할에서 다룹니다. 자세한 내용은 ID로 호스트 스토리지에 연결을 참조하세요.

런타임에 큐에 대한 액세스를 제공하는 역할 할당을 만들어야 합니다. 소유자와 같은 관리 역할로는 충분하지 않습니다. 다음 표는 정상 작동에서 Queue Storage 확장을 사용할 때 권장되는 기본 제공 역할을 보여 줍니다. 작성하는 코드에 따라 애플리케이션에 추가 권한이 필요할 수 있습니다.

바인딩 유형	기본 제공 역할 예
트리거	Storage 큐 데이터 읽기 권한자, Storage 큐 데이터 메시지 프로세서
출력 바인딩	Storage 큐 데이터 기여자, Storage 큐 데이터 메시지 보낸 사람

런타임 시 Azure Storage 테이블 서비스에 대한 액세스를 제공하는 역할 할당을 만들어야 합니다. 소유자와 같은 관리 역할로는 충분하지 않습니다. 다음 표에서는 정상적인 작업에서 Azure Storage에 대해 Azure Tables 확장을 사용할 때 권장되는 기본 제공 역할을 보여 줍니다. 작성하는 코드에 따라 애플리케이션에 추가 권한이 필요할 수 있습니다.

바인딩 유형	기본 제공 역할의 예(Azure Storage¹)
입력 바인딩	스토리지 테이블 데이터 읽기 권한자
출력 바인딩	스토리지 테이블 데이터 기여자

¹ 앱이 Azure Cosmos DB for Table의 테이블에 대신 연결하는 경우 ID 사용이 지원되지 않으며 연결은 연결 문자열을 사용해야만 합니다.

런타임에 이벤트 허브에 대한 액세스를 제공하는 역할 할당을 만들어야 합니다. 역할 할당의 범위는 Event Hubs 네임스페이스 또는 이벤트 허브 자체에 대한 것일 수 있습니다. 소유자와 같은 관리 역할로는 충분하지 않습니다. 다음 표는 정상 작동에서 Event Hubs 확장을 사용할 때 권장되는 기본 제공 역할을 보여 줍니다. 작성하는 코드에 따라 애플리케이션에 추가 권한이 필요할 수 있습니다.

바인딩 유형	기본 제공 역할 예
트리거	Azure Event Hubs 데이터 수신기, Azure Event Hubs 데이터 소유자
출력 바인딩	Azure Event Hubs 데이터 보내는 사람

런타임에 항목 및 큐에 대한 액세스를 제공하는 역할 할당을 만들어야 합니다. 소유자와 같은 관리 역할로는 충분하지 않습니다. 다음 표는 정상적인 작동에서 Service Bus 확장을 사용할 때 권장되는 기본 제공 역할을 보여 줍니다. 작성하는 코드에 따라 애플리케이션에 추가 권한이 필요할 수 있습니다.

바인딩 유형	기본 제공 역할 예
Trigger¹	Azure Service Bus 데이터 수신기, Azure Service Bus 데이터 소유자
출력 바인딩	Azure Service Bus 데이터 보내는 사람

¹ Service Bus 항목에서 트리거하려면 역할 할당에 Service Bus 구독 리소스에 대한 유효 범위가 있어야 합니다. 항목만 포함하면 오류가 발생합니다. Azure Portal과 같은 일부 클라이언트는 Service Bus 구독 리소스를 역할 할당 범위로 노출하지 않습니다. 이러한 경우 Azure CLI를 대신 사용할 수 있습니다. 자세한 내용은 Azure Service Bus용 Azure 기본 제공 역할을 참조하세요.

런타임 시 Event Grid 항목에 대한 액세스를 제공하는 역할 할당을 만들어야 합니다. 소유자와 같은 관리 역할로는 충분하지 않습니다. 다음 표는 정상 작동에서 Event Hubs 확장을 사용할 때 권장되는 기본 제공 역할을 보여 줍니다. 작성하는 코드에 따라 애플리케이션에 추가 권한이 필요할 수 있습니다.

바인딩 유형	기본 제공 역할 예
출력 바인딩	EventGrid 기여자, EventGrid 데이터 보낸 사람

Cosmos DB는 데이터 작업에 Azure RBAC를 사용하지 않습니다. 대신 유사한 개념으로 빌드되는 Cosmos DB 기본 제공 RBAC 시스템을 사용합니다. 런타임에 데이터베이스 계정에 대한 액세스를 제공하는 역할 할당을 만들어야 합니다. 소유자와 같은 Azure RBAC 관리 역할로는 충분하지 않습니다. 다음 표에는 Azure Cosmos DB 확장을 정상 작동할 때 권장되는 기본 제공 역할이 나와 있습니다. 작성하는 코드에 따라 애플리케이션에 추가 권한이 필요할 수 있습니다.

바인딩 유형	예제 기본 제공 역할¹
트리거²	Cosmos DB 기본 제공 데이터 기여자
입력 바인딩	Cosmos DB 기본 제공 데이터 판독기
출력 바인딩	Cosmos DB 기본 제공 데이터 기여자

¹ 이 역할은 Azure RBAC 역할 할당에서 사용할 수 없습니다. 이 역할을 할당하는 방법에 대한 자세한 내용은 Cosmos DB 기본 제공 RBAC 시스템 설명서를 참조하세요.

² ID를 사용하는 경우 Cosmos DB는 컨테이너 만들기를 관리 작업으로 처리합니다. 트리거에 대한 데이터 평면 작업으로 사용할 수 없습니다. 함수를 설정하기 전에 트리거에 필요한 컨테이너(임대 컨테이너 포함)를 만들어야 합니다.

런타임에 Azure Storage에 대한 액세스를 제공하는 역할 할당을 만들어야 합니다. 소유자와 같은 관리 역할로는 충분하지 않습니다. 다음 기본 제공 역할은 정상 작동에서 Durable Functions 확장을 사용할 때 권장됩니다.

작성하는 코드에 따라 애플리케이션에 추가 권한이 필요할 수 있습니다. 기본 동작을 사용하거나 connectionName을 "AzureWebJobsStorage"로 명시적으로 설정하는 경우 다른 권한 고려 사항은 ID로 호스트 스토리지에 연결을 참조하세요.

런타임에 "AzureWebJobsStorage"에 대한 스토리지 계정에 대한 액세스를 제공하는 역할 할당을 만들어야 합니다. 소유자와 같은 관리 역할로는 충분하지 않습니다. Storage Blob 데이터 소유자 역할은 Functions 호스트 스토리지의 기본 요구 사항을 다룹니다. 런타임에는 Blob에 대한 읽기 및 쓰기 권한과 컨테이너 만들기 함수가 모두 필요합니다. 여러 확장은 이 연결을 Blob, 큐 및 테이블의 기본 위치로 사용하며 이러한 사용으로 인해 아래 표에 나와 있는 요구 사항이 추가될 수 있습니다. 다른 용도로 "AzureWebJobsStorage"를 사용하는 경우 추가 권한이 필요할 수 있습니다.

내선 번호	필요한 역할	설명
확장 없음(호스트만 해당)	Storage Blob 데이터 소유자	일반 조정에 사용, 기본 키 저장소
Azure Blob(트리거 전용)	다음 항목 모두: 스토리지 계정 기여자, Storage Blob 데이터 소유자, Storage 큐 데이터 기여자	Blob 트리거는 내부적으로 Azure 큐를 사용하고 BLOB 수신을 씁니다. 트리거에 대해 구성된 연결에 관계없이 AzureWebJobsStorage를 사용합니다.
Azure Event Hubs(트리거 전용)	(기본 요구 사항에서 변경 없음) Storage Blob 데이터 소유자	검사점은 AzureWebJobsStorage 연결을 사용하여 Blob에 유지됩니다.
타이머 트리거	(기본 요구 사항에서 변경 없음) Storage Blob 데이터 소유자	이벤트당 하나의 실행을 보장하기 위해 AzureWebJobsStorage 연결을 사용하여 Blob에 잠금이 설정됩니다.
지속성 함수	다음 항목 모두: Storage Blob 데이터 기여자, Storage 큐 데이터 기여자, 스토리지 테이블 데이터 기여자	Durable Functions는 Blob, 큐 및 테이블을 사용하여 작업 함수를 오케스트레이션하고 오케스트레이션 상태를 유지합니다. 기본적으로 이 모든 것에 대해 AzureWebJobsStorage 연결을 사용하지만 Durable Functions 확장 구성에서 다른 연결을 지정할 수 있습니다.

ID 기반 연결의 공통 속성

Azure 서비스에 대한 ID 기반 연결은 다음과 같은 공통 속성을 허용합니다. 여기서 <CONNECTION_NAME_PREFIX>는 트리거 또는 바인딩 정의의 connection 속성 값입니다.

속성	환경 변수 템플릿	설명
토큰 자격 증명	`<CONNECTION_NAME_PREFIX>__credential`	연결을 위해 토큰을 가져오는 방법을 정의합니다. 배포된 Azure Function이 관리 ID 인증을 사용하려는 경우 이 설정을 `managedidentity`로 설정해야 합니다. 이 값은 호스팅 환경에서 관리 ID를 사용할 수 있는 경우에만 유효합니다.
클라이언트 ID	`<CONNECTION_NAME_PREFIX>__clientId`	`credential`이 `managedidentity`로 설정된 경우 이 속성은 토큰을 가져올 때 사용할 사용자가 할당한 ID를 지정하도록 설정할 수 있습니다. 속성은 애플리케이션에 할당된 사용자가 할당한 ID에 해당하는 클라이언트 ID를 허용합니다. 리소스 ID와 클라이언트 ID를 모두 지정하는 것은 유효하지 않습니다. 지정하지 않으면 시스템 할당 ID가 사용됩니다. 이 속성은 이 설정되지 않아야 하는 로컬 개발 시나리오`credential`에서 다르게 사용됩니다.
리소스 ID	`<CONNECTION_NAME_PREFIX>__managedIdentityResourceId`	`credential`이 `managedidentity`로 설정된 경우 이 속성은 토큰을 가져올 때 사용할 리소스 식별자를 지정하도록 설정할 수 있습니다. 속성은 사용자 정의 관리 ID의 리소스 ID에 해당하는 리소스 식별자를 허용합니다. 리소스 ID와 클라이언트 ID를 모두 지정하는 것은 유효하지 않습니다. 둘 다 지정하지 않으면 시스템 할당 ID가 사용됩니다. 이 속성은 이 설정되지 않아야 하는 로컬 개발 시나리오`credential`에서 다르게 사용됩니다.

지정된 연결 유형에 대해 다른 옵션이 지원될 수 있습니다. 연결을 구성하는 구성 요소에 대한 설명서를 참조하세요.

ID 기반 연결을 사용하여 로컬 개발

참고 항목

ID 기반 연결을 사용한 로컬 개발에는 4.0.3904Azure Functions Core Tools 버전 이상 버전이 필요합니다.

함수 프로젝트를 로컬로 실행하는 경우 위의 구성은 런타임에 로컬 개발자 ID를 사용하도록 지시합니다. 연결은 다음 위치에서 토큰을 순서대로 가져오려고 시도합니다.

Microsoft 애플리케이션 간에 공유되는 로컬 캐시
Visual Studio의 현재 사용자 컨텍스트
Visual Studio Code의 현재 사용자 컨텍스트
Azure CLI의 현재 사용자 컨텍스트

성공적인 옵션이 없는 경우 오류가 발생합니다.

ID에 개발에 사용되는 Azure 리소스에 대한 일부 역할 할당이 이미 있을 수 있지만 이러한 역할은 필요한 데이터 액세스를 제공하지 않을 수 있습니다. 소유자와 같은 관리 역할로는 충분하지 않습니다. 각 구성 요소에 대한 연결에 필요한 권한을 다시 확인하고 자신에게 할당했는지 확인합니다.

경우에 따라 다른 ID를 사용하도록 지정할 수 있습니다. Microsoft Entra 서비스 주체에 대한 클라이언트 ID 및 클라이언트 암호를 기반으로 하는 대체 ID를 가리키는 연결에 대한 구성 속성을 추가할 수 있습니다. 이 구성 옵션은 Azure Functions 서비스에서 호스팅되는 경우 지원되지 않습니다. 로컬 컴퓨터에서 ID와 비밀을 사용하려면 다음 추가 속성으로 연결을 정의합니다.

속성	환경 변수 템플릿	설명
테넌트 ID	`<CONNECTION_NAME_PREFIX>__tenantId`	Microsoft Entra 테넌트(디렉터리) ID입니다.
클라이언트 ID	`<CONNECTION_NAME_PREFIX>__clientId`	테넌트에 있는 앱 등록의 클라이언트(애플리케이션) ID.
클라이언트 암호	`<CONNECTION_NAME_PREFIX>__clientSecret`	앱 등록을 위해 생성된 클라이언트 암호.

다음은 Azure Blob에 대한 ID 기반 연결에 필요한 local.settings.json 속성의 예제입니다.

{
  "IsEncrypted": false,
  "Values": {
    "<CONNECTION_NAME_PREFIX>__blobServiceUri": "<blobServiceUri>",
    "<CONNECTION_NAME_PREFIX>__queueServiceUri": "<queueServiceUri>",
    "<CONNECTION_NAME_PREFIX>__tenantId": "<tenantId>",
    "<CONNECTION_NAME_PREFIX>__clientId": "<clientId>",
    "<CONNECTION_NAME_PREFIX>__clientSecret": "<clientSecret>"
  }
}

ID로 호스트 저장소에 연결

Azure Functions 호스트는 AzureWebJobsStorage에서 스토리지 연결 집합을 사용하여 타이머 트리거 및 기본 앱 키 스토리지의 싱글톤 실행 조정과 같은 핵심 동작을 사용하도록 설정합니다. ID를 사용하도록 이 연결을 구성할 수도 있습니다.

주의

Functions의 다른 구성 요소는 기본 동작에 대해 AzureWebJobsStorage를 사용합니다. Azure Blob, Event Hubs 및 Durable Functions에 대한 트리거 및 바인딩을 포함하여 이 형식의 연결을 지원하지 않는 이전 버전의 확장을 사용하는 경우 ID 기반 연결로 이동하면 안 됩니다. 마찬가지로 AzureWebJobsStorage는 Linux 사용에서 서버 쪽 빌드를 사용할 때 배포 아티팩트에 사용되며, 이를 사용하도록 설정하면 외부 배포 패키지를 통해 배포해야 합니다.

또한 함수 앱은 트리거, 바인딩 및/또는 함수 코드에서 다른 스토리지 연결에 AzureWebJobsStorage를 재사용할 수 있습니다. 연결 문자열에서 이 연결을 변경하기 전에 모든 AzureWebJobsStorage 사용이 ID 기반 연결 형식을 사용할 수 있는지 확인합니다.

AzureWebJobsStorage에 대한 ID 기반 연결을 사용하려면 다음 앱 설정을 구성합니다.

설정	설명	예제 값
`AzureWebJobsStorage__blobServiceUri`	HTTPS 체계를 사용하는 스토리지 계정의 Blob service에 대한 데이터 평면 URI입니다.	https://<storage_account_name>.blob.core.windows.net
`AzureWebJobsStorage__queueServiceUri`	HTTPS 체계를 사용하는 스토리지 계정의 큐 서비스에 대한 데이터 평면 URI입니다.	https://<storage_account_name>.queue.core.windows.net
`AzureWebJobsStorage__tableServiceUri`	HTTPS 체계를 사용하는 스토리지 계정의 테이블 서비스에 대한 데이터 평면 URI입니다.	https://<storage_account_name>.table.core.windows.net

ID 기반 연결의 공통 속성도 설정할 수 있습니다.

https://<accountName>.[blob|queue|file|table].core.windows.net 형식에 따라 전역 Azure에 대한 기본 DNS 접미사 및 서비스 이름을 사용하는 스토리지 계정을 사용하여 AzureWebJobsStorage를 구성하는 경우 대신 AzureWebJobsStorage__accountName을 스토리지 계정의 이름으로 설정할 수 있습니다. 각 스토리지 서비스의 엔드포인트는 이 계정에 대해 유추됩니다. 스토리지 계정이 소버린 클라우드에 있거나 사용자 지정 DNS가 있는 경우에는 작동하지 않습니다.

설정	설명	예제 값
`AzureWebJobsStorage__accountName`	스토리지 계정의 계정 이름으로, 계정이 소버린 클라우드에 없고 사용자 지정 DNS가 없는 경우에만 유효합니다. 이 구문은 `AzureWebJobsStorage`에 고유하며 다른 ID 기반 연결에는 사용할 수 없습니다.	<storage_account_name>

내선 번호	필요한 역할	설명
확장 없음(호스트만 해당)	Storage Blob 데이터 소유자	일반 조정에 사용, 기본 키 저장소
Azure Blob(트리거 전용)	다음 항목 모두: 스토리지 계정 기여자, Storage Blob 데이터 소유자, Storage 큐 데이터 기여자	Blob 트리거는 내부적으로 Azure 큐를 사용하고 BLOB 수신을 씁니다. 트리거에 대해 구성된 연결에 관계없이 AzureWebJobsStorage를 사용합니다.
Azure Event Hubs(트리거 전용)	(기본 요구 사항에서 변경 없음) Storage Blob 데이터 소유자	검사점은 AzureWebJobsStorage 연결을 사용하여 Blob에 유지됩니다.
타이머 트리거	(기본 요구 사항에서 변경 없음) Storage Blob 데이터 소유자	이벤트당 하나의 실행을 보장하기 위해 AzureWebJobsStorage 연결을 사용하여 Blob에 잠금이 설정됩니다.
지속성 함수	다음 항목 모두: Storage Blob 데이터 기여자, Storage 큐 데이터 기여자, 스토리지 테이블 데이터 기여자	Durable Functions는 Blob, 큐 및 테이블을 사용하여 작업 함수를 오케스트레이션하고 오케스트레이션 상태를 유지합니다. 기본적으로 이 모든 것에 대해 AzureWebJobsStorage 연결을 사용하지만 Durable Functions 확장 구성에서 다른 연결을 지정할 수 있습니다.

보고 문제

항목	설명	링크
런타임	스크립트 호스트, 트리거 및 바인딩, 언어 지원	문제 보관
템플릿	생성 템플에 대한 코드 문제	문제 보관
포털	사용자 인터페이스 또는 환경 문제	문제 보관