Azure Functions Durable Task Scheduler Consumption

4 May 2026 tarixli Azure Functions yeniliyi ilə Durable Task Scheduler üçün Consumption SKU dəstəyi elan olundu; sonrakı sənədlər 1 May 2026 preview resource modelini, 2 İyun 2026 billing detalları və iyuladək idarəetmə nüanslarını tamamladı

Bu yeniliyin dəyəri ondadır ki, stateful orchestration artıq Azure Storage backend-ə bağlı klassik modeldən uzaqlaşıb purpose-built, managed backend-as-a-service modelinə keçir. Microsoft Durable Task Scheduler-i Durable Functions və Durable Task SDK-lar üçün tövsiyə olunan storage provider kimi təqdim edir. Consumption SKU isə xüsusən serverless AI agent orchestration üçün çox uyğun pay-per-use model verir: əvvəlcədən CU almağa ehtiyac olmur, dispatch olunan action-lar üzrə ödəniş edilir, maksimum throughput təxminən 500 action/saniyə, data retention isə otuz günlə məhdudlaşır. Bu kombinasiya dəyişkən workload, test, PoC və bursty agent workflow-lar üçün çox əlverişlidir.

Əsas biznes təsiri storage transaction economics və operational complexity-nin ayrılmasıdır. Azure Storage provider modelində queue polling, table/blob əməliyyatları və hub hygiene sizin hesabınıza və sizin tuning məsuliyyətinizə düşürdü. Durable Task Scheduler modelində isə orchestration state managed xidmətin içində saxlanılır, app scheduler-ə TLS-lə qorunan gRPC bağlantısı ilə qoşulur, iş elementləri pull yox, push modeli ilə stream olunur. Bu yanaşma end-to-end latency-ni və tətbiq tərəfdəki resurs istifadəsini azaldır, eyni scheduler-in bir neçə app tərəfindən paylaşılmasını mümkün edir və fault isolation-i yaxşılaşdırır.

Arxitektura və Dəyişikliyin Mahiyyəti.
Arxitektura baxımından scheduler resursu tətbiqdən ayrıdır. Bu ayrılıq üç üstünlük yaradır: state management app host-dan çıxır, scheduler müstəqil skeyllənir, troubleshooting səviyyəsində platforma ilə tətbiq hadisələrini ayırmaq asanlaşır. Scheduler-in endpoint-i {scheduler-name}.{region}.durabletask.io formatındadır; trafik TLS üzərindən gedir və managed identity ilə autentikasiya olunur. Private endpoint dəstəyi olduğuna görə VNet içindən public internetə çıxmadan secure xətt qurmaq mümkündür. Consumption SKU üçün scheduler və task hub quota-ları da ayrıca nəzərə alınmalıdır: region/subscription üzrə on scheduler və beş task hub limiti var. Həmçinin payload limitləri bir çox AI agent workflow-u üçün real məhdudiyyətdir: orchestrator input/output, activity input/output, external event data və entity state üçün bir meqabayt həddi var.

Bu SKU-nun economics modelində “action” anlayışı əsasdır. Orchestrator start, activity schedule, activity result processing, timer completion və external event kimi hadisələr action sayılır. Deməli, xərci təkcə orchestration sayına görə yox, orchestration başına düşən state transitions sayına görə ölçmək lazımdır. AI agent orchestration design edərkən “chat loop daxilində həddindən artıq xırda activity parçalanması” xərci sürətlə artıra bilər. Əksinə, çox böyük payload-ların bir orchestrasiya dövrünə yığılması da limit problemləri yarada bilər. Doğru dizayn orta granularitet, idempotent activity-lər və xarici payload storage pattern-i tələb edir.

Adım-adım Tətbiq və Konfiqurasiya.
Ən praktik yol əvvəl scheduler və task hub yaratmaq, sonra Function App-i managed identity ilə ona attach etməkdir. Microsoft-un task hub sənədi scheduler və task hub-un tətbiq istifadə etməzdən əvvəl explicit yaradılmasını tövsiyə edir. Həmçinin eyni backend üzərində birdən çox tətbiqin eyni task hub-u paylaşması undefined behavior və stuck orchestration riskinə görə tövsiyə edilmir; hər app və hər staging slot üçün unikallıq saxlanmalıdır.

# Durable Task CLI extension
az extension add --name durabletask
az extension update --name durabletask

# Resource group
az group create --name rg-dts --location westeurope

# Consumption scheduler via ARM-compatible resource type is supported;
# the CLI flow below illustrates the scheduler/task hub lifecycle
az durabletask scheduler create \
  --name dts-agent-orch \
  --resource-group rg-dts \
  --location westeurope \
  --ip-allowlist "[10.10.0.0/24]" \
  --sku-name consumption

az durabletask taskhub create \
  --resource-group rg-dts \
  --scheduler-name dts-agent-orch \
  --name agents-hub

Microsoft-un Bicep resurs modelində Microsoft.DurableTask/schedulers@2026-05-01-preview tipi artıq Consumption və Dedicated SKU-larını, eləcə də publicNetworkAccess və ipAllowlist kimi şəbəkə parametrlərini təqdim edir. Bu, IaC ilə standardlaşdırma üçün ən təmiz yoldur.

param location string = resourceGroup().location
param schedulerName string = 'dts-agent-orch'
param taskHubName string = 'agents-hub'

resource scheduler 'Microsoft.DurableTask/schedulers@2026-05-01-preview' = {
  name: schedulerName
  location: location
  properties: {
    publicNetworkAccess: 'Disabled'
    ipAllowlist: [
      '10.10.0.0/24'
    ]
    sku: {
      name: 'Consumption'
      capacity: 1
    }
  }
}

resource taskHub 'Microsoft.DurableTask/schedulers/taskHubs@2025-04-01-preview' = {
  parent: scheduler
  name: taskHubName
  properties: {}
}

Function App tərəfdə host konfigurasiya dəyişikliyi kritik nöqtədir. storageProvider.type artıq azureManaged olmalıdır və bağlantı string-i storage account secret deyil, scheduler endpoint + task hub + managed identity semantikası ilə qurulmalıdır. Əgər user-assigned identity istifadə edirsinizsə ClientID yeni connection string-in bir hissəsidir. az durabletask scheduler attach əmri bu prosesi, role assignment və env var sazlaması da daxil olmaqla, bir yerdə avtomatlaşdıra bilir.

{
  "extensions": {
    "durableTask": {
      "hubName": "agents-hub",
      "storageProvider": {
        "type": "azureManaged",
        "connectionStringName": "DURABLE_TASK_SCHEDULER_CONNECTION_STRING"
      }
    }
  }
}

Mümkün Problemlər və Troubleshooting Ssenariləri.
Ən tipik problem RBAC-dir. Scheduler managed identity ilə işlədiyi üçün storage key tipli düşüncə burada işləmir. Funksiya tətbiqi ya scheduler, ya da daha yaxşısı task hub scope-da Durable Task Data Contributor və ya uyğun role almalıdır; əks halda orchestration-lar queue görünmədiyi halda stuck ola bilər. Hədəf identitini task hub scope-da bağlamaq least privilege üçün daha doğrudur.

İkinci tip problem task hub collision-dir. Eyni scheduler/backend üzərində bir neçə app və ya staging slot eyni task hub-u paylaşdıqda orchestrations mesaj uğrunda yarışa girə, “undefined behavior” və gözlənilməz stuck vəziyyət yarada bilər. Microsoft bunu explicit şəkildə xəbərdar edir. Əgər siz CI/CD-də slot swap edirsinizsə, slot üçün ayrıca hub naming standard təyin edin.

Üçüncü tip problem şəbəkədir. Public access söndürülüb private endpoint açılıbsa, DNS resolution düzgün qurulmalıdır; əks halda app public endpoint-ə çıxmağa çalışar və gRPC handshake uğursuz olar. Private endpoint sənədi DNS-in private IP-yə map olunmalı olduğunu, həmçinin scheduler subresource-ının ayrıca target olduğunu açıq göstərir. Əgər self-hosted AI agent bütün orchestration-ları “Pending”də saxlayırsa, DNS, private link və identity triadası eyni anda yoxlanmalıdır.

Dördüncü problem cost model misunderstanding-dir. Consumption SKU ucuz görünə bilər, amma action count düzgün modellənməyibsə, xərclər gözləniləndən yüksək ola bilər. Üç activity çağıran sadə orchestration belə start və result processing daxil olmaqla bir neçə action yaradır. Ona görə AI agent fan-out pattern-lərində action budgeting mütləq aparılmalıdır.

Ən Yaxşı Təcrübələr.
User-assigned managed identity istifadə edin; bu identiti app lifecycle-dan ayırır. Hər app və hər slot üçün unikal task hub saxlayın. Large payload-ları orchestration input-un içinə yığmayın; bir meqabaytı keçən data üçün external storage və pointer passing pattern-i seçin. Production-da private endpoints və dar ipAllowlist, development-də isə Consumption SKU istifadə edin. Agent orchestration-ları üçün activity-ləri idempotent saxlayın və action-count əsaslı cost model qurun.