Sunucusuz olay işleme

Azure Cosmos DB
Azure Functions
Azure Monitor
Azure Pipelines
Azure Storage

Bu başvuru mimarisi, bir veri akışı alan, verileri işleyen ve sonuçları arka uç veritabanına yazan sunucusuz, olay odaklı bir mimariyi gösterir.

Mimari

Azure İşlevleri kullanarak sunucusuz olay işlemeye yönelik başvuru mimarisini gösteren diyagram.

İş Akışı

  • Olaylar Azure Event Hubs'a ulaşır.
  • Olayı işlemek için bir İşlev Uygulaması tetikleniyor.
  • Olay bir Azure Cosmos DB veritabanında depolanır.
  • İşlev Uygulaması olayı başarıyla depolayamazsa, olay daha sonra işlenecek bir Depolama kuyruğuna kaydedilir.

Bileşenler

  • Event Hubs veri akışını alır. Event Hubs , yüksek aktarım hızına sahip veri akışı senaryoları için tasarlanmıştır.

    Not

    Nesnelerin İnterneti (IoT) senaryoları için Azure IoT Hub'ı öneririz. IoT Hub'ın Azure Event Hubs API'si ile uyumlu yerleşik bir uç noktası vardır, bu nedenle arka uç işlemede önemli bir değişiklik olmadan bu mimarideki iki hizmeti de kullanabilirsiniz. Daha fazla bilgi için bkz. IoT Cihazlarını Azure'a Bağlan: IoT Hub ve Event Hubs.

  • İşlev Uygulaması. Azure İşlevleri sunucusuz bir işlem seçeneğidir. Bir kod parçasının ( işlev) tetikleyici tarafından çağrıldığı olay temelli bir model kullanır. Bu mimaride olaylar Event Hubs'a ulaştığında olayları işleyen ve sonuçları depolama alanına yazan bir işlevi tetikler.

    İşlev Uygulamaları, Event Hubs'dan tek tek kayıtları işlemek için uygundur. Daha karmaşık akış işleme senaryoları için Azure Databricks veya Azure Stream Analytics kullanarak Apache Spark'ı göz önünde bulundurun.

  • Azure Cosmos DB. Azure Cosmos DB , sunucusuz, tüketim tabanlı modda kullanılabilen çok modelli bir veritabanı hizmetidir. Bu senaryo için olay işleme işlevi, NoSQL için Azure Cosmos DB kullanarak JSON kayıtlarını depolar.

  • Kuyruk depolama. Kuyruk depolama , teslim edilemeyen iletiler için kullanılır. Bir olay işlenirken bir hata oluşursa işlev, olay verilerini daha sonra işlenmek üzere bir teslim edilemeyen ileti kuyruğunda depolar. Daha fazla bilgi için bu makalenin devamında yer alan Dayanıklılık bölümüne bakın.

  • Azure İzleyici. İzleyici , çözümde dağıtılan Azure hizmetleriyle ilgili performans ölçümlerini toplar. Bunları bir panoda görselleştirerek çözümün durumu hakkında görünürlük elde edebilirsiniz.

  • Azure Pipelines. İşlem hatları , uygulamayı derleyen, test eden ve dağıtan sürekli tümleştirme (CI) ve sürekli teslim (CD) hizmetidir.

Dikkat edilmesi gereken noktalar

Bu önemli noktalar, bir iş yükünün kalitesini artırmak için kullanılabilecek bir dizi yol gösteren ilke olan Azure İyi Tasarlanmış Çerçeve'nin yapı taşlarını uygular. Daha fazla bilgi için bkz . Microsoft Azure İyi Tasarlanmış Çerçeve.

Kullanılabilirlik

Burada gösterilen dağıtım tek bir Azure bölgesinde yer alır. Olağanüstü durum kurtarma için daha dayanıklı bir yaklaşım için çeşitli hizmetlerdeki coğrafi dağıtım özelliklerinden yararlanın:

  • Event Hubs. birincil (etkin) ad alanı ve ikincil (pasif) ad alanı olmak üzere iki Event Hubs ad alanı oluşturun. İkincil ad alanına yük devretmediğiniz sürece iletiler otomatik olarak etkin ad alanına yönlendirilir. Daha fazla bilgi için bkz . Azure Event Hubs Coğrafi olağanüstü durum kurtarma.
  • İşlev Uygulaması. İkincil Event Hubs ad alanından okumayı bekleyen ikinci bir işlev uygulaması dağıtın. Bu işlev, teslim edilemeyen bir kuyruk için ikincil depolama hesabına yazar.
  • Azure Cosmos DB. Azure Cosmos DB, Azure Cosmos DB hesabınıza eklediğiniz tüm bölgelere yazma olanağı sağlayan birden çok yazma bölgesini destekler. Çoklu yazma özelliğini etkinleştirmezseniz, birincil yazma bölgesine yük devretmeye devam edebilirsiniz. Azure Cosmos DB istemci SDK'ları ve Azure İşlev bağlamaları yük devretmeyi otomatik olarak işler, bu nedenle uygulama yapılandırma ayarlarını güncelleştirmeniz gerekmez.
  • Azure Depolama. Teslim edilemeyen ileti kuyruğu için RA-GRS depolama alanını kullanın. Bu, başka bir bölgede salt okunur bir çoğaltma oluşturur. Birincil bölge kullanılamaz duruma gelirse, şu anda kuyrukta olan öğeleri okuyabilirsiniz. Ayrıca, ikincil bölgede bir yük devretme sonrasında işlevin yazabileceği başka bir depolama hesabı sağlayın.

Ölçeklenebilirlik

Event Hubs

Event Hubs'ın aktarım hızı kapasitesi aktarım hızı birimleriyle ölçülür. Otomatik şişirme özelliğini etkinleştirerek olay hub'ını otomatik olarak ölçeklendirerek aktarım hızı birimlerini trafiğe göre yapılandırılan en yüksek değere kadar ölçeklendirin.

İşlev uygulamasında Event Hubs tetikleyicisi, olay hub'ında bölüm sayısına göre ölçeklendirilir. Her bölüme bir kerede bir işlev örneği atanır. Aktarım hızını en üst düzeye çıkarmak için olayları birer birer yerine toplu olarak alın.

Azure Cosmos DB

Azure Cosmos DB iki farklı kapasite modunda kullanılabilir:

İş yükünüzün ölçeklenebilir olduğundan emin olmak için Azure Cosmos DB kapsayıcılarınızı oluştururken uygun bir bölüm anahtarı seçmeniz önemlidir. İyi bir bölüm anahtarının bazı özellikleri şunlardır:

  • Anahtar değer alanı büyük.
  • Anahtar değeri başına okuma/yazma işlemleri eşit bir şekilde dağıtılır ve kısayol tuşlarından kaçınılır.
  • Tek bir anahtar değeri için depolanan maksimum veri sayısı, fiziksel bölüm boyutu üst sınırını (20 GB) aşmaz.
  • Belgenin bölüm anahtarı değişmez. Mevcut bir belgedeki bölüm anahtarını güncelleştiremezsiniz.

Bu başvuru mimarisi senaryosunda işlev, veri gönderen cihaz başına tam olarak bir belge depolar. İşlev, bir upsert işlemi kullanarak belgeleri sürekli olarak en son cihaz durumuyla güncelleştirir. Yazma işlemleri anahtarlar arasında eşit olarak dağıtılacağından ve her anahtar değeri için tek bir belge bulunduğundan her bölümün boyutu kesin olarak sınırlanacağından, cihaz kimliği bu senaryo için iyi bir bölüm anahtarıdır. Bölüm anahtarları hakkında daha fazla bilgi için bkz . Azure Cosmos DB'de bölümleme ve ölçeklendirme.

Dayanıklılık

Event Hubs tetikleyicisini İşlevler ile kullanırken, işleme döngünüz içindeki özel durumları yakalayın. İşlenmeyen bir özel durum oluşursa, İşlevler çalışma zamanı iletileri yeniden denemez. İleti işlenemiyorsa, iletiyi teslim edilemeyen bir kuyruğa yerleştirin. İletileri incelemek ve düzeltici eylemi belirlemek için bant dışı bir işlem kullanın.

Aşağıdaki kod, alma işlevinin özel durumları nasıl yakaladığını ve işlenmemiş iletileri teslim edilemeyen bir kuyruğa nasıl yerleştirdiği gösterilir.

 [Function(nameof(RawTelemetryFunction))]
 public async Task RunAsync([EventHubTrigger("%EventHubName%", Connection = "EventHubConnection")] EventData[] messages,
     FunctionContext context)
 {
     _telemetryClient.GetMetric("EventHubMessageBatchSize").TrackValue(messages.Length);
     DeviceState? deviceState = null;
     // Create a new CosmosClient
     var cosmosClient = new CosmosClient(Environment.GetEnvironmentVariable("COSMOSDB_CONNECTION_STRING"));

     // Get a reference to the database and the container
     var database = cosmosClient.GetDatabase(Environment.GetEnvironmentVariable("COSMOSDB_DATABASE_NAME"));
     var container = database.GetContainer(Environment.GetEnvironmentVariable("COSMOSDB_DATABASE_COL"));

     // Create a new QueueClient
     var queueClient = new QueueClient(Environment.GetEnvironmentVariable("DeadLetterStorage"), "deadletterqueue");
     await queueClient.CreateIfNotExistsAsync();

     foreach (var message in messages)
     {
         try
         {
             deviceState = _telemetryProcessor.Deserialize(message.Body.ToArray(), _logger);
             try
             {
                 // Add the device state to Cosmos DB
                 await container.UpsertItemAsync(deviceState, new PartitionKey(deviceState.DeviceId));
             }
             catch (Exception ex)
             {
                  _logger.LogError(ex, "Error saving on database", message.PartitionKey, message.SequenceNumber);
                 var deadLetterMessage = new DeadLetterMessage { Issue = ex.Message, MessageBody = message.Body.ToArray(), DeviceState = deviceState };
                 // Convert the dead letter message to a string
                 var deadLetterMessageString = JsonConvert.SerializeObject(deadLetterMessage);

                 // Send the message to the queue
                 await queueClient.SendMessageAsync(deadLetterMessageString);
             }

         }
         catch (Exception ex)
         {
             _logger.LogError(ex, "Error deserializing message", message.PartitionKey, message.SequenceNumber);
             var deadLetterMessage = new DeadLetterMessage { Issue = ex.Message, MessageBody = message.Body.ToArray(), DeviceState = deviceState };
             // Convert the dead letter message to a string
             var deadLetterMessageString = JsonConvert.SerializeObject(deadLetterMessage);

             // Send the message to the queue
             await queueClient.SendMessageAsync(deadLetterMessageString);
         }
     }
 }

Gösterilen kod ayrıca Uygulama Analizler özel durumlarını günlüğe kaydeder. Günlüklerdeki özel durumlarla ölü harf iletilerini ilişkilendirmek için bölüm anahtarını ve sıra numarasını kullanabilirsiniz.

Teslim edilemeyen ileti kuyruğundaki iletiler, hatanın bağlamını anlayabilebilmeniz için yeterli bilgiye sahip olmalıdır. Bu örnekte, DeadLetterMessage sınıfı özel durum iletisini, özgün olay gövdesi verilerini ve seri durumdan çıkarılmış olay iletisini (varsa) içerir.

    public class DeadLetterMessage
    {
        public string? Issue { get; set; }
        public byte[]? MessageBody { get; set; }
        public DeviceState? DeviceState { get; set; }
    }

Olay hub'ını izlemek için Azure İzleyici'yi kullanın. Giriş olduğunu ancak çıkış olmadığını görüyorsanız, bu iletilerin işlenmediğini gösterir. Bu durumda Log Analytics'e gidin ve özel durumları veya diğer hataları arayın.

DevOps

Mümkün olduğunda kod olarak altyapı (IaC) kullanın. IaC, Altyapı, uygulama ve depolama kaynaklarını Azure Resource Manager gibi bildirim temelli bir yaklaşımla yönetir. Bu, DevOps'u sürekli tümleştirme ve sürekli teslim (CI/CD) çözümü olarak kullanarak dağıtımı otomatikleştirmeye yardımcı olur. Şablonlar sürüm oluşturulup yayın işlem hattının bir parçası olarak eklenmelidir.

Şablonları oluştururken, kaynakları iş yükü başına düzenleme ve yalıtma yöntemi olarak gruplandırma. İş yükü hakkında düşünmenin yaygın bir yolu, tek bir sunucusuz uygulama veya sanal ağdır. İş yükü yalıtımının amacı, DevOps ekibinin bu kaynakların tüm yönlerini bağımsız olarak yönetebilmesi ve CI/CD gerçekleştirebilmesi için kaynakları bir ekiple ilişkilendirmektir.

Hizmetlerinizi dağıtırken bunları izlemeniz gerekir. Geliştiricilerin performansı izlemesini ve sorunları algılamasını sağlamak için Uygulama Analizler kullanmayı göz önünde bulundurun.

Daha fazla bilgi için bkz . DevOps denetim listesi.

Olağanüstü durum kurtarma

Burada gösterilen dağıtım tek bir Azure bölgesinde yer alır. Olağanüstü durum kurtarma için daha dayanıklı bir yaklaşım için çeşitli hizmetlerdeki coğrafi dağıtım özelliklerinden yararlanın:

  • Event Hubs. birincil (etkin) ad alanı ve ikincil (pasif) ad alanı olmak üzere iki Event Hubs ad alanı oluşturun. İkincil ad alanına yük devretmediğiniz sürece iletiler otomatik olarak etkin ad alanına yönlendirilir. Daha fazla bilgi için bkz . Azure Event Hubs Coğrafi olağanüstü durum kurtarma.

  • İşlev Uygulaması. İkincil Event Hubs ad alanından okumayı bekleyen ikinci bir işlev uygulaması dağıtın. Bu işlev, teslim edilemeyen ileti kuyruğu için ikincil bir depolama hesabına yazar.

  • Azure Cosmos DB. Azure Cosmos DB, Azure Cosmos DB hesabınıza eklediğiniz tüm bölgelere yazma olanağı sağlayan birden çok yazma bölgesini destekler. Çoklu yazma özelliğini etkinleştirmezseniz, birincil yazma bölgesine yük devretmeye devam edebilirsiniz. Azure Cosmos DB istemci SDK'ları ve Azure İşlev bağlamaları yük devretmeyi otomatik olarak işler, bu nedenle uygulama yapılandırma ayarlarını güncelleştirmeniz gerekmez.

  • Azure Depolama. Teslim edilemeyen ileti kuyruğu için RA-GRS depolama alanını kullanın. Bu, başka bir bölgede salt okunur bir çoğaltma oluşturur. Birincil bölge kullanılamaz duruma gelirse, şu anda kuyrukta olan öğeleri okuyabilirsiniz. Ayrıca, ikincil bölgede bir yük devretme sonrasında işlevin yazabileceği başka bir depolama hesabı sağlayın.

Maliyet iyileştirme

Maliyet iyileştirmesi, gereksiz giderleri azaltmanın ve operasyonel verimlilikleri iyileştirmenin yollarını aramaktır. Daha fazla bilgi için bkz . Maliyet iyileştirme sütununa genel bakış.

Maliyetleri tahmin etmek için Azure Fiyatlandırma hesaplayıcısını kullanın. Azure İşlevleri ve Azure Cosmos DB ile ilgili dikkat edilmesi gereken diğer bazı noktalar aşağıdadır.

Azure İşlevleri

Azure İşlevleri iki barındırma modeli destekler:

  • Tüketim planı. Kodunuz çalışırken işlem gücü otomatik olarak ayrılır.
  • App Service Planı. Kodunuz için bir dizi sanal makine (VM) ayrılır. App Service planı, VM sayısını ve VM boyutunu tanımlar.

Bu mimaride Event Hubs'a ulaşan her olay, bu olayı işleyen bir işlevi tetikler. Maliyet açısından bakıldığında, yalnızca kullandığınız işlem kaynakları için ödeme yaptığınız için tüketim planını kullanmanız gerekir.

Azure Cosmos DB

Azure Cosmos DB hizmetinde gerçekleştirdiğiniz veritabanı işlemleri ve verilerinizin kullandığı depolama alanı için ödeme yaparsınız.

  • Veritabanı işlemleri. Veritabanı işlemleriniz için ücretlendirme yönteminiz, kullandığınız Azure Cosmos DB hesabının türüne bağlıdır.
    • Sunucusuz modda, Azure Cosmos DB hesabınızda kaynak oluştururken herhangi bir aktarım hızı sağlamak zorunda değilsiniz. Faturalama döneminizin sonunda, veritabanı işlemleriniz tarafından kullanılan İstek Birimi miktarı için faturalandırılırsınız.
    • Sağlanan aktarım hızı modunda, saniye başına İstek Birimlerinde (RU/sn) ihtiyacınız olan aktarım hızını belirtir ve belirli bir saat için sağlanan maksimum aktarım hızı için saatlik olarak faturalandırılırsınız. Not: Sağlanan aktarım hızı modeli kaynakları kapsayıcınıza veya veritabanınıza ayırdığından, herhangi bir iş yükü çalıştırmasanız bile sağladığınız aktarım hızı için ücretlendirilirsiniz.
  • Depolama. Belirli bir saat boyunca verileriniz ve dizinleriniz tarafından kullanılan toplam depolama alanı miktarı (GB olarak) için sabit bir fiyat faturalandırılırsınız.

Bu başvuru mimarisinde işlev, veri gönderen cihaz başına tam olarak bir belge depolar. İşlev, tüketilen depolama açısından uygun maliyetli bir upsert işlemi kullanarak belgeleri sürekli olarak en son cihaz durumuyla güncelleştirir. Daha fazla bilgi için bkz . Azure Cosmos DB fiyatlandırma modeli.

İş yükü maliyetini hızlı bir şekilde tahmin etmek için Azure Cosmos DB kapasite hesaplayıcısını kullanın.

Bu senaryoyu dağıtın

GitHub logosu Bu mimari için bir başvuru uygulaması GitHub'da kullanılabilir.

Sonraki adımlar