Azure Functions 개발자 가이드

아티클
03/14/2023

Azure Functions에서 특정 함수는 사용하는 언어나 바인딩에 관계없이 몇 가지 핵심적 기술 개념과 구성 요소를 공유합니다. 특정 언어나 바인딩에 해당하는 세부 정보를 학습하기 전에, 모든 항목에 해당하는 이 개요를 꼼꼼히 읽어 보시기 바랍니다.

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

함수 코드

함수 는 Azure Functions의 기본 개념입니다. 함수에는 다양한 언어로 작성할 수 있는 코드와 일부 구성인 function.json 파일의 두 가지 중요한 부분이 포함되어 있습니다. 컴파일된 언어의 경우, 이 구성 파일은 코드의 주석에서 자동으로 생성됩니다. 스크립팅 언어의 경우 구성 파일을 직접 제공해야 합니다.

function.json 파일은 함수의 트리거, 바인딩 및 기타 구성 설정을 정의합니다. 모든 함수에 하나의 트리거만 있습니다. 런타임은 이 구성 파일을 사용하여 모니터링할 이벤트와 함수 실행에 데이터를 전달하고 반환하는 방법을 확인합니다. 다음은 function.json 파일의 예제입니다.

{
    "disabled":false,
    "bindings":[
        // ... bindings here
        {
            "type": "bindingType",
            "direction": "in",
            "name": "myParamName",
            // ... more depending on binding
        }
    ]
}

자세한 내용은 Azure Functions 트리거 및 바인딩 개념을 참조하세요.

bindings 속성은 트리거와 바인딩을 모두 구성하는 곳에 위치합니다. 각 바인딩은 몇 가지 공통적인 설정과 특정 바인딩 형식에 해당하는 일부 설정을 공유합니다. 모든 바인딩에는 다음 설정이 필요합니다.

속성	값	유형	의견
type	바인딩의 이름입니다. 예들 들어 `queueTrigger`입니다.	문자열
direction	`in`, `out`	문자열	함수 안으로 데이터를 수신할 바인딩인지 또는 함수의 데이터를 전송할 바인딩인지를 나타냅니다.
name	함수 식별자입니다. 예들 들어 `myQueue`입니다.	문자열	함수에서 바인딩 데이터에 사용되는 이름입니다. C#의 경우 인수 이름이며, JavaScript의 경우 키/값 목록의 키입니다.

함수 앱

함수 앱은 함수가 실행되는 Azure의 실행 컨텍스트를 제공합니다. 함수에 대한 배포 및 관리 단위입니다. 함수 앱은 함께 관리, 배포 및 스케일링되는 하나 이상의 개별 함수로 구성됩니다. 함수 앱의 모든 함수는 동일한 가격 책정 계획, 배포 방법 및 런타임 버전을 공유합니다. 함수 앱을 함수를 구성하고 전체적으로 관리하는 방법으로 생각합니다. 자세한 내용은 함수 앱을 관리하는 방법을 참조하세요.

참고

함수 앱의 모든 함수는 동일한 언어로 작성되어야 합니다. 이전 버전의 Azure Functions 런타임에서는 이러한 요구 사항이 필요하지 않았습니다.

폴더 구조

특정 함수 앱의 모든 기능에 대한 코드는 호스트 구성 파일이 포함된 루트 프로젝트 폴더에 있습니다. host.json 파일은 런타임별 구성을 포함하며 함수 앱의 루트 폴더에 있습니다. bin 폴더에는 함수 앱에 필요한 패키지 및 기타 라이브러리 파일이 포함되어 있습니다. 함수 앱에 필요한 특정 폴더 구조는 언어에 따라 달라집니다.

Functions 런타임의 2.x 이상 버전부터 함수 앱의 모든 함수는 동일한 언어 스택을 공유해야 합니다.

위 그림은 함수 앱의 기본(및 권장) 폴더 구조입니다. 함수 코드의 파일 위치를 변경하려면 function.json 파일의 scriptFile 섹션을 수정합니다. 또한 패키지 배포를 사용하여 Azure의 함수 앱에 프로젝트를 배포하는 것이 좋습니다. 연속 통합 및 지속적인 배포, Azure DevOps 등의 기존 도구를 사용할 수도 있습니다.

참고

패키지를 수동으로 배포하는 경우 host.json 파일과 함수 폴더를 wwwroot 폴더에 직접 배포해야 합니다. 배포에 wwwroot 폴더를 포함하지 마세요. 그렇지 않으면 wwwroot\wwwroot 폴더가 만들어집니다.

로컬 도구 및 게시 사용

함수 앱은 Visual Studio, Visual Studio Code, IntelliJ, Eclipse 및 Azure Functions Core Tools를 비롯한 다양한 도구를 사용하여 작성하고 게시할 수 있습니다. 자세한 내용은 Azure Functions를 로컬에서 코딩 및 테스트를 참조하세요.

Azure Portal에서 함수를 편집하는 방법

Azure Portal에 기본 제공된 함수 편집기를 사용하면 코드와 function.json 파일을 인라인에서 직접 업데이트할 수 있습니다. 이 작업은 사소한 변경이나 개념 증명에만 권장되며, VS Code와 같은 로컬 개발 도구를 사용하는 것이 좋습니다.

병렬 실행

복수의 트리거 이벤트가 단일 스레드 함수 런타임이 해당 이벤트를 처리할 수 있는 속도보다 빨리 발생하면 런타임은 병렬 모드로 함수를 여러 번 호출할 수 있습니다. 함수 앱이 소비 호스팅 계획을 사용하는 경우 함수 앱은 자동으로 확장할 수 있습니다. 앱이 소비 호스팅 계획 또는 일반 App Service 계획에서 실행되는지 여부에 관계없이 함수 앱의 각 인스턴스는 여러 스레드를 사용하여 동시 함수 호출을 병렬로 처리할 수 있습니다. 각 함수 앱 인스턴스의 최대 동시 함수 호출 수는 함수 앱 내의 다른 함수에서 사용하는 리소스뿐만 아니라 사용 중인 트리거 유형에 따라 달라집니다.

Functions 런타임 버전 관리

FUNCTIONS_EXTENSION_VERSION 앱 설정을 사용하여 Functions 런타임의 버전을 구성할 수 있습니다. 예를 들어 ‘~3’ 값은 함수 앱이 주 버전으로 3.x를 사용한다는 의미입니다. 함수 앱은 부 버전이 새로 릴리스될 때마다 업그레이드됩니다. 정확한 함수 앱 버전을 확인하는 방법을 비롯한 자세한 내용을 보려면 Azure Functions 런타임 버전을 대상으로 지정하는 방법을 참조하세요.

리포지토리

Azure Functions에 대한 코드는 공개 소스이며 GitHub 리포지토리에 저장됩니다.

바인딩

지원되는 모든 바인딩을 포함하는 테이블입니다.

이 표는 Azure Functions 런타임의 주요 버전에서 지원되는 바인딩을 보여 줍니다.

유형	1.x	2.x 이상¹	트리거	입력	출력
Blob Storage	✔	✔	✔	✔	✔
Azure Cosmos DB	✔	✔	✔	✔	✔
Azure SQL		✔	✔	✔	✔
Dapr³		✔	✔	✔	✔
Event Grid	✔	✔	✔		✔
Event Hubs	✔	✔	✔		✔
HTTP 및 웹후크	✔	✔	✔		✔
IoT Hub	✔	✔	✔
Kafka²		✔	✔		✔
Mobile Apps	✔			✔	✔
Notification Hubs	✔				✔
Queue Storage	✔	✔	✔		✔
RabbitMQ²		✔	✔		✔
SendGrid	✔	✔			✔
Service Bus	✔	✔	✔		✔
SignalR		✔	✔	✔	✔
Table Storage	✔	✔		✔	✔
타이머	✔	✔	✔
Twilio	✔	✔			✔

¹ 버전 2.x 런타임부터는 HTTP 및 Timer를 제외한 모든 바인딩이 등록되어야 합니다. 바인딩 확장 등록을 참조하세요.

² 트리거는 소비 계획에서 지원되지 않습니다. 런타임 기반 트리거가 필요합니다.

³ Kubernetes, IoT Edge 및 기타 자체 호스팅 모드에서만 지원됩니다.

바인딩에서 들어오는 오류와 함께 문제가 있습니까? Azure Functions 바인딩 오류 코드 설명서를 참조하세요.

Connections

함수 프로젝트는 구성 공급자의 이름별로 연결 정보를 참조합니다. 연결 세부 정보를 직접 허용하지 않으므로 환경 간에 변경될 수 있습니다. 예를 들어 트리거 정의에는 connection 속성이 포함될 수 있습니다. 이는 연결 문자열을 참조할 수 있지만 function.json에서 직접 연결 문자열을 설정할 수 없습니다. 대신 connection을 연결 문자열을 포함하는 환경 변수의 이름으로 설정합니다.

기본 구성 공급자는 환경 변수를 사용합니다. Azure Functions 서비스에서 실행 중일 때 애플리케이션 설정에서, 또는 로컬에서 개발할 때 로컬 설정 파일에서 설정할 수 있습니다.

연결 값

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

그러나 연결 이름은 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 기반 연결로 함수 앱 만들기 자습서를 참조하세요.

다음 구성 요소는 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 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에서 역할을 할당해야 함을 의미합니다.

중요

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

아래 탭을 선택하여 각 구성 요소의 권한에 대해 알아봅니다.

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

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

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

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

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 스토리지에 대한 액세스를 제공하는 역할 할당을 만들어야 합니다. 소유자와 같은 관리 역할로는 충분하지 않습니다. 다음 기본 제공 역할은 정상 작동에서 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 속성 값입니다.

속성	환경 변수 템플릿	Description
토큰 자격 증명	`<CONNECTION_NAME_PREFIX>__credential`	연결을 위해 토큰을 가져오는 방법을 정의합니다. 이 설정은 사용자 할당 ID를 "managedidentity"로 설정해야 하는 경우에만 권장됩니다. 이 값은 Azure Functions 서비스에서 호스트되는 경우에만 유효합니다.
클라이언트 ID	`<CONNECTION_NAME_PREFIX>__clientId`	`credential`이 "managedidentity"로 설정된 경우 이 속성은 토큰을 가져올 때 사용할 사용자가 할당한 ID를 지정합니다. 속성은 애플리케이션에 할당된 사용자가 할당한 ID에 해당하는 클라이언트 ID를 허용합니다. 지정하지 않으면 시스템 할당 ID가 사용됩니다. 이 속성은 이 설정되지 않아야 하는 로컬 개발 시나리오`credential`에서 다르게 사용됩니다.

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

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

참고

ID 기반 연결을 사용한 로컬 개발에는 Azure Functions Core Tools의 업데이트된 버전이 필요합니다. func -v를 실행하여 현재 설치된 버전을 확인할 수 있습니다. Functions v3의 경우 버전 3.0.3904 이상을 사용합니다. Functions v4의 경우 버전 4.0.3904 이상을 사용합니다.

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

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

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

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

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

속성	환경 변수 템플릿	Description
테넌트 ID	`<CONNECTION_NAME_PREFIX>__tenantId`	Azure Active Directory 테넌트(디렉터리) 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 확장 구성에서 다른 연결을 지정할 수 있습니다.

문제 보고

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

다음 단계

자세한 내용은 다음 자료를 참조하세요.