Pertimbangan desain aplikasi untuk beban kerja misi penting

Arsitektur referensi misi-kritis dasar menggunakan aplikasi katalog online sederhana untuk mengilustrasikan beban kerja yang sangat andal. Pengguna dapat menelusuri katalog item, meninjau detail item, serta memposting peringkat dan komentar untuk item. Artikel ini berfokus pada aspek keandalan dan ketahanan aplikasi misi penting, seperti pemrosesan permintaan asinkron dan cara mencapai throughput tinggi dalam solusi.

Penting

Implementasi referensi tingkat produksi yang menampilkan pengembangan aplikasi misi penting di Azure mendukung panduan dalam artikel ini. Anda dapat menggunakan implementasi ini sebagai dasar untuk pengembangan solusi lebih lanjut dalam langkah pertama Anda menuju produksi.

Komposisi aplikasi

Untuk aplikasi penting misi skala tinggi, Anda harus mengoptimalkan arsitektur untuk skalabilitas dan ketahanan end-to-end. Anda dapat memisahkan komponen menjadi unit fungsional yang dapat beroperasi secara independen. Terapkan pemisahan ini di semua tingkat pada tumpukan aplikasi sehingga setiap bagian sistem dapat menskalakan secara independen dan memenuhi perubahan permintaan. Implementasi menunjukkan pendekatan ini.

Aplikasi ini menggunakan titik akhir API stateless yang memisahkan permintaan tulis yang berjalan lama secara asinkron melalui broker olahpesan. Komposisi beban kerja memungkinkan Anda menghapus dan membuat ulang seluruh kluster Azure Kubernetes Service (AKS) dan dependensi lain dalam stempel kapan saja. Komponen utama aplikasi adalah:

• Antarmuka pengguna (UI): Aplikasi web satu halaman yang dapat diakses pengguna. UI dihosting di hosting situs web statis akun Azure Storage.

• API (CatalogService): REST API yang dipanggil oleh aplikasi UI tetapi masih tersedia untuk aplikasi klien potensial lainnya.

• Pekerja (BackgroundProcessor): Pekerja latar belakang yang mendengarkan peristiwa baru di bus pesan dan memproses permintaan tulis ke database. Komponen ini tidak mengekspos API apa pun.

• API layanan kesehatan (HealthService): API yang melaporkan kesehatan aplikasi dengan memeriksa apakah komponen penting berfungsi, seperti database atau bus olahpesan.

  

Beban kerja terdiri dari API, pekerja, dan aplikasi pemeriksaan kesehatan. Namespace layanan AKS khusus yang disebut workload menghosting beban kerja sebagai kontainer. Tidak ada komunikasi langsung yang terjadi di antara pod. Pod tanpa status dan dapat diskalakan secara independen.

Komponen pendukung lain yang berjalan di kluster meliputi:

• Pengontrol ingress NGINX: Merutekan permintaan masuk ke beban kerja dan keseimbangan beban antar pod. Pengontrol ingress NGINX diekspos melalui Azure Load Balancer dengan alamat IP publik tetapi hanya dapat diakses melalui Azure Front Door.

• Cert manager: Sertifikat Transport Layer Security (TLS) provisi otomatis Jetstack cert-manager dengan menggunakan Let's Encrypt untuk aturan masuk.

• Driver CSI Penyimpanan Rahasia: Penyedia Azure Key Vault untuk Driver Secrets Store CSI membaca rahasia dengan aman, seperti string koneksi dari Key Vault.

• Agen pemantauan: Konfigurasi OMSAgentForLinux default disesuaikan untuk mengurangi jumlah data pemantauan yang dikirim ke ruang kerja Log Azure Monitor.

Koneksi Database

Karena sifat sementara stempel penyebaran, hindari status bertahan dalam stempel sebanyak mungkin. Anda harus mempertahankan status di penyimpanan data eksternal. Untuk mendukung tujuan tingkat layanan keandalan (SLO), buat penyimpanan data yang tangguh. Kami menyarankan agar Anda menggunakan terkelola, atau platform as a service (PaaS), solusi dalam kombinasi dengan pustaka SDK asli yang secara otomatis menangani batas waktu, pemutusan sambungan, dan status kegagalan lainnya.

Dalam implementasi referensi, Azure Cosmos DB berfungsi sebagai penyimpanan data utama untuk aplikasi. Azure Cosmos DB menyediakan penulisan multi-wilayah. Setiap stempel dapat menulis ke replika Azure Cosmos DB di wilayah yang sama, dan Azure Cosmos DB secara internal menangani replikasi dan sinkronisasi data antar wilayah. Azure Cosmos DB for NoSQL mendukung semua kemampuan mesin database.

Untuk informasi selengkapnya, lihat Platform data untuk beban kerja misi penting.

Catatan

Gunakan Azure Cosmos DB untuk NoSQL untuk aplikasi baru. Untuk aplikasi warisan yang menggunakan protokol NoSQL lain, evaluasi jalur migrasi ke Azure Cosmos DB.

Untuk aplikasi misi penting yang memprioritaskan ketersediaan daripada performa, sebaiknya tulis satu wilayah dan baca multi-wilayah dengan tingkat konsistensi yang kuat.

Arsitektur ini menggunakan Storage untuk menyimpan status sementara di stempel untuk titik pemeriksaan Azure Event Hubs.

Semua komponen beban kerja menggunakan Azure Cosmos DB .NET Core SDK untuk berkomunikasi dengan database. SDK mencakup logika yang kuat untuk mempertahankan koneksi database dan menangani kegagalan. Pengaturan konfigurasi utama meliputi:

• Mode konektivitas langsung: Pengaturan ini adalah default untuk .NET SDK v3 karena menawarkan performa yang lebih baik. Mode konektivitas langsung memiliki lebih sedikit lompatan jaringan dibandingkan dengan mode Gateway, yang menggunakan HTTP.

• Mengembalikan respons konten saat menulis: Pendekatan ini dinonaktifkan sehingga klien Azure Cosmos DB tidak dapat mengembalikan dokumen dari operasi buat, upsert, dan patch dan ganti, yang mengurangi lalu lintas jaringan. Pemrosesan lebih lanjut pada klien tidak memerlukan pengaturan ini.

• Serialisasi kustom: Proses ini mengatur kebijakan penamaan properti JSON ke JsonNamingPolicy.CamelCase untuk menerjemahkan properti .NET ke properti JSON standar. Ini juga dapat menerjemahkan properti JSON ke properti .NET. Kondisi abaikan default mengabaikan properti dengan nilai null, seperti JsonIgnoreCondition.WhenWritingNull, selama serialisasi.

• ApplicationRegion: Properti ini diatur ke wilayah stempel, yang memungkinkan SDK menemukan titik akhir koneksi terdekat. Titik akhir sebaiknya berada di wilayah yang sama.

Blok kode berikut muncul dalam implementasi referensi:

//
// /src/app/AlwaysOn.Shared/Services/CosmosDbService.cs
//
CosmosClientBuilder clientBuilder = new CosmosClientBuilder(sysConfig.CosmosEndpointUri, sysConfig.CosmosApiKey)
    .WithConnectionModeDirect()
    .WithContentResponseOnWrite(false)
    .WithRequestTimeout(TimeSpan.FromSeconds(sysConfig.ComsosRequestTimeoutSeconds))
    .WithThrottlingRetryOptions(TimeSpan.FromSeconds(sysConfig.ComsosRetryWaitSeconds), sysConfig.ComsosMaxRetryCount)
    .WithCustomSerializer(new CosmosNetSerializer(Globals.JsonSerializerOptions));

if (sysConfig.AzureRegion != "unknown")
{
    clientBuilder = clientBuilder.WithApplicationRegion(sysConfig.AzureRegion);
}

_dbClient = clientBuilder.Build();

Pesan asinkron

Saat Anda menerapkan kopling longgar, layanan tidak memiliki dependensi pada layanan lain. Aspek longgar memungkinkan layanan beroperasi secara independen. Aspek kopling memungkinkan komunikasi antarlayanan melalui antarmuka yang terdefinisi dengan baik. Untuk aplikasi misi penting, kopling longgar mencegah kegagalan hilir berjendela ke ujung depan atau stempel penyebaran lainnya, yang memberikan ketersediaan tinggi.

Karakteristik utama olahpesan asinkron meliputi:

• Layanan tidak perlu menggunakan platform komputasi, bahasa pemrograman, atau sistem operasi yang sama.

• Layanan diskalakan secara independen.

• Kegagalan hilir tidak memengaruhi transaksi klien.

• Integritas transaksi ini sulit dipertahankan karena pembuatan dan persistensi data terjadi di layanan terpisah. Integritas transaksi adalah tantangan di seluruh layanan olahpesan dan persistensi. Untuk informasi selengkapnya, lihat Pemrosesan pesan idempotoen.

• Pelacakan end-to-end memerlukan orkestrasi yang kompleks.

Kami menyarankan agar Anda menggunakan pola desain terkenal, seperti pola Tingkatan Beban Berbasis Antrean dan pola Konsumen yang Bersaing. Pola-pola ini mendistribusikan beban dari produsen ke konsumen dan memungkinkan pemrosesan asinkron oleh konsumen. Misalnya, pekerja memungkinkan API menerima permintaan dan dengan cepat kembali ke pemanggil, dan pekerja memproses operasi penulisan database secara terpisah.

Azure Event Hubs menaungi pesan antara API dan pekerja.

Penting

Jangan gunakan broker pesan sebagai penyimpanan data persisten untuk jangka waktu yang lama. Layanan Azure Event Hubs mendukung fitur pengambilan. Fitur pengambilan memungkinkan hub peristiwa untuk menulis salinan pesan secara otomatis ke akun Penyimpanan tertaut. Proses ini mengontrol penggunaan dan berfungsi sebagai mekanisme untuk mencadangkan pesan.

Menulis detail implementasi operasi

Operasi tulis, seperti peringkat posting dan komentar posting, diproses secara asinkron. API pertama kali mengirim pesan dengan semua informasi yang relevan, seperti jenis tindakan dan data komentar, ke antrean pesan dan segera kembali HTTP 202 (Accepted) dengan Location header objek yang akan dibuat.

BackgroundProcessor instans memproses pesan dalam antrean dan menangani komunikasi database aktual untuk operasi tulis. BackgroundProcessor menskalakan masuk dan menskalakan secara dinamis berdasarkan volume pesan antrean. Batas peluasan skala instans prosesor ditentukan oleh jumlah maksimum partisi Azure Event Hubs, yaitu 32 untuk tingkat Dasar dan tingkat Standar, 100 untuk tingkat Premium, dan 1.024 untuk tingkat Khusus.

Pustaka Prosesor Azure Event Hubs dalam BackgroundProcessor menggunakan Azure Blob Storage untuk mengelola kepemilikan partisi, keseimbangan beban antara instans pekerja yang berbeda, dan menggunakan titik pemeriksaan untuk melacak kemajuan. Titik pemeriksaan tidak ditulis ke penyimpanan blob setelah setiap peristiwa karena menambahkan penundaan mahal untuk setiap pesan. Sebagai gantinya, titik pemeriksaan ditulis pada perulangan timer, dan Anda dapat mengonfigurasi durasi. Pengaturan default adalah 10 detik.

Blok kode berikut muncul dalam implementasi referensi:

while (!stoppingToken.IsCancellationRequested)
{
    await Task.Delay(TimeSpan.FromSeconds(_sysConfig.BackendCheckpointLoopSeconds), stoppingToken);
    if (!stoppingToken.IsCancellationRequested && !checkpointEvents.IsEmpty)
    {
        string lastPartition = null;
        try
        {
            foreach (var partition in checkpointEvents.Keys)
            {
                lastPartition = partition;
                if (checkpointEvents.TryRemove(partition, out ProcessEventArgs lastProcessEventArgs))
                {
                    if (lastProcessEventArgs.HasEvent)
                    {
                        _logger.LogDebug("Scheduled checkpointing for partition {partition}. Offset={offset}", partition, lastProcessEventArgs.Data.Offset);
                        await lastProcessEventArgs.UpdateCheckpointAsync();
                    }
                }
            }
        }
        catch (Exception e)
        {
            _logger.LogError(e, "Exception during checkpointing loop for partition={lastPartition}", lastPartition);
        }
    }
}

Jika aplikasi prosesor mengalami kesalahan atau dihentikan sebelum dapat memproses pesan:

• Instans lain mengambil pesan untuk pemrosesan ulang karena tidak dicentang dengan benar di Penyimpanan.

• Konflik terjadi jika pekerja sebelumnya mempertahankan dokumen dalam database sebelum pekerja gagal. Kesalahan ini terjadi karena ID dan kunci partisi yang sama digunakan. Prosesor dapat mengabaikan pesan dengan aman karena dokumen sudah dipertahankan.

• Instans baru mengulangi langkah-langkah dan menyelesaikan persistensi jika pekerja sebelumnya dihentikan sebelum menulis ke database.

Membaca detail implementasi operasi

API langsung memproses operasi baca dan segera mengembalikan data kembali kepada pengguna.

Metode saluran belakang tidak dibuat untuk berkomunikasi dengan klien jika operasi berhasil diselesaikan. Aplikasi klien harus secara proaktif melakukan polling API untuk pembaruan tentang item yang ditentukan di Location header HTTP.

Skalabilitas

Komponen beban kerja individual harus diskalakan secara independen karena setiap komponen memiliki pola beban yang berbeda. Persyaratan penskalaan tergantung pada fungsionalitas layanan. Layanan tertentu secara langsung memengaruhi pengguna dan harus menskalakan secara agresif untuk memastikan respons yang cepat dan pengalaman pengguna yang positif.

Implementasi mengemas layanan sebagai gambar kontainer dan menggunakan bagan Helm untuk menyebarkan layanan ke setiap stempel. Layanan dikonfigurasi untuk memiliki permintaan dan batasan Kube yang diharapkan dan aturan penskalaan otomatis yang telah dikonfigurasi sebelumnya. komponen CatalogService beban kerja dan BackgroundProcessor dapat menskalakan masuk dan meluaskan skala secara individual karena kedua layanan tidak memiliki status.

Pengguna berinteraksi langsung dengan CatalogService, sehingga bagian beban kerja ini harus merespons di bawah beban apa pun. Ada minimal tiga instans untuk setiap kluster yang tersebar di tiga zona ketersediaan di wilayah Azure. Autoscaler pod horizontal (HPA) di AKS secara otomatis menambahkan lebih banyak pod sesuai kebutuhan. Fitur skala otomatis Azure Cosmos DB dapat secara dinamis meningkatkan dan mengurangi unit permintaan (RU) yang tersedia untuk koleksi. CatalogService Azure Cosmos DB dan menggabungkan untuk membentuk unit skala dalam stempel.

HPA disebarkan dengan bagan Helm yang memiliki jumlah maksimum yang dapat dikonfigurasi dan jumlah minimum replika. Pengujian beban menentukan bahwa setiap instans dapat menangani sekitar 250 permintaan per detik dengan pola penggunaan standar.

Layanan BackgroundProcessor ini memiliki persyaratan yang berbeda dan dianggap sebagai pekerja latar belakang yang memiliki efek terbatas pada pengalaman pengguna. Jadi BackgroundProcessor memiliki konfigurasi penskalakan otomatis yang berbeda dibandingkan dengan CatalogService, dan dapat menskalakan antara 2 dan 32 instans. Tentukan batas ini berdasarkan jumlah partisi yang Anda gunakan di hub peristiwa. Anda tidak memerlukan lebih banyak pekerja daripada partisi.

Komponen	minReplicas	maxReplicas
CatalogService	3	20
BackgroundProcessor	2	32

Setiap komponen beban kerja yang mencakup dependensi seperti ingress-nginx memiliki pengaturan anggaran gangguan pod (PDB) yang dikonfigurasi untuk memastikan bahwa jumlah minimum instans tetap tersedia saat kluster berubah.

Blok kode berikut muncul dalam implementasi referensi:

#
# /src/app/charts/healthservice/templates/pdb.yaml
# Example pod distribution budget configuration.
#
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: {{ .Chart.Name }}-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: {{ .Chart.Name }}

Catatan

Tentukan jumlah minimum aktual dan jumlah maksimum pod untuk setiap komponen melalui pengujian beban. Jumlah pod dapat berbeda untuk setiap beban kerja.

Instrumentasi

Gunakan instrumentasi untuk mengevaluasi leher botol performa dan masalah kesehatan yang dapat dimasukkan komponen beban kerja ke dalam sistem. Untuk membantu Anda mengukur keputusan, setiap komponen harus memancarkan informasi yang memadai melalui metrik dan melacak log. Pertimbangkan pertimbangan utama berikut saat Anda melengkapi aplikasi Anda:

• Kirim log, metrik, dan telemetri lainnya ke sistem log stempel.
• Gunakan pengelogan terstruktur alih-alih teks biasa sehingga Anda bisa mengkueri informasi.
• Terapkan korelasi peristiwa untuk mendapatkan tampilan transaksi end-to-end. Dalam implementasi referensi, setiap respons API berisi ID Operasi sebagai header HTTP untuk keterlacakan.
• Jangan hanya mengandalkan pengelogan stdout , atau pengelogan konsol. Tetapi Anda dapat menggunakan log ini untuk segera memecahkan masalah pod yang gagal.

Arsitektur ini menerapkan pelacakan terdistribusi dengan Application Insights dan ruang kerja Log Azure Monitor untuk data pemantauan aplikasi. Gunakan Log Azure Monitor untuk log dan metrik beban kerja dan komponen infrastruktur. Arsitektur ini menerapkan pelacakan permintaan end-to-end penuh yang berasal dari API, melalui Azure Event Hubs, lalu ke Azure Cosmos DB.

Penting

Sebarkan sumber daya pemantauan stempel ke grup sumber daya pemantauan terpisah. Sumber daya memiliki siklus hidup yang berbeda dari stempel itu sendiri. Untuk informasi selengkapnya, lihat Memantau data untuk sumber daya stempel.

Detail implementasi pemantauan aplikasi

Komponen BackgroundProcessor menggunakan Microsoft.ApplicationInsights.WorkerService paket NuGet untuk mendapatkan instrumentasi out-of-the-box dari aplikasi. Serilog juga digunakan untuk semua pengelogan di dalam aplikasi. Application Insights dikonfigurasi sebagai sink selain sink konsol. Instans TelemetryClient untuk Application Insights digunakan secara langsung hanya jika perlu untuk melacak metrik lain.

Blok kode berikut muncul dalam implementasi referensi:

//
// /src/app/AlwaysOn.BackgroundProcessor/Program.cs
//
public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
    .ConfigureServices((hostContext, services) =>
    {
        Log.Logger = new LoggerConfiguration()
                            .ReadFrom.Configuration(hostContext.Configuration)
                            .Enrich.FromLogContext()
                            .WriteTo.Console(outputTemplate: "[{Timestamp:yyyy-MM-dd HH:mm:ss.fff zzz} {Level:u3}] {Message:lj} {Properties:j}{NewLine}{Exception}")
                            .WriteTo.ApplicationInsights(hostContext.Configuration[SysConfiguration.ApplicationInsightsConnStringKeyName], TelemetryConverter.Traces)
                            .CreateLogger();
    }

Untuk menunjukkan keterlacakan permintaan praktis, setiap permintaan API yang berhasil dan tidak berhasil mengembalikan header ID Korelasi ke pemanggil. Tim dukungan aplikasi dapat mencari Application Insights dengan pengidentifikasi ini dan mendapatkan tampilan terperinci dari transaksi lengkap, yang diilustrasikan dalam diagram sebelumnya.

Blok kode berikut muncul dalam implementasi referensi:

//
// /src/app/AlwaysOn.CatalogService/Startup.cs
//
app.Use(async (context, next) =>
{
    context.Response.OnStarting(o =>
    {
        if (o is HttpContext ctx)
        {
            // ... code omitted for brevity
            context.Response.Headers.Add("Server-Location", sysConfig.AzureRegion);
            context.Response.Headers.Add("Correlation-ID", Activity.Current?.RootId);
            context.Response.Headers.Add("Requested-Api-Version", ctx.GetRequestedApiVersion()?.ToString());
        }
        return Task.CompletedTask;
    }, context);
    await next();
});

Catatan

Pengambilan sampel adaptif diaktifkan secara default di Application Insights SDK. Pengambilan sampel adaptif berarti bahwa tidak setiap permintaan dikirim ke cloud dan dapat dicari dengan ID. Tim aplikasi misi penting perlu melacak setiap permintaan dengan andal, itulah sebabnya implementasi referensi memiliki pengambilan sampel adaptif yang dinonaktifkan di lingkungan produksi.

Detail implementasi pemantauan Kubernetes

Anda dapat menggunakan pengaturan diagnostik untuk mengirim log dan metrik AKS ke Log Azure Monitor. Anda juga dapat menggunakan fitur wawasan kontainer dengan AKS. Aktifkan wawasan kontainer untuk menyebarkan OMSAgentForLinux melalui Kubernetes DaemonSet pada setiap node dalam kluster AKS. OMSAgentForLinux dapat mengumpulkan lebih banyak log dan metrik dari dalam kluster Kubernetes dan mengirimkannya ke ruang kerja Log Azure Monitor yang sesuai. Ruang kerja ini berisi data terperinci tentang pod, penyebaran, layanan, dan kesehatan kluster secara keseluruhan.

Pengelogan ekstensif dapat berdampak negatif pada biaya dan tidak memberikan manfaat. Untuk alasan ini, pengumpulan log stdout dan pengikisan Prometheus dinonaktifkan untuk pod beban kerja dalam konfigurasi wawasan kontainer karena semua jejak sudah diambil melalui Application Insights, yang menghasilkan rekaman duplikat.

Blok kode berikut muncul dalam implementasi referensi:

#
# /src/config/monitoring/container-azm-ms-agentconfig.yaml
# This is just a snippet showing the relevant part.
#
[log_collection_settings]
    [log_collection_settings.stdout]
        enabled = false

        exclude_namespaces = ["kube-system"]

Untuk informasi selengkapnya, lihat file konfigurasi lengkap.

Pemantauan kesehatan aplikasi

Anda dapat menggunakan pemantauan dan pengamatan aplikasi untuk mengidentifikasi masalah sistem dengan cepat dan menginformasikan model kesehatan tentang status aplikasi saat ini. Anda dapat memunculkan pemantauan kesehatan melalui titik akhir kesehatan. Pemeriksaan kesehatan menggunakan data pemantauan kesehatan untuk memberikan informasi. Load balancer utama menggunakan informasi tersebut untuk segera mengeluarkan komponen yang tidak sehat dari rotasi.

Arsitektur ini menerapkan pemantauan kesehatan pada tingkat berikut:

• Pod beban kerja yang berjalan di AKS. Pod-pod ini memiliki pemeriksaan kesehatan dan keaktifan, sehingga AKS dapat mengelola siklus hidup mereka.

• Layanan Kesehatan, yang merupakan komponen khusus pada kluster. Azure Front Door dikonfigurasi untuk memeriksa Layanan Kesehatan di setiap stempel dan menghapus stempel yang tidak sehat dari penyeimbangan beban secara otomatis.

Detail implementasi Layanan Kesehatan

HealthService adalah komponen beban kerja yang berjalan bersama komponen lain, seperti CatalogService dan BackgroundProcessor, pada kluster komputasi. HealthService menyediakan REST API yang dipanggil pemeriksaan kesehatan Azure Front Door untuk menentukan ketersediaan stempel. Tidak seperti pemeriksaan keaktifan dasar, Health Service adalah komponen yang lebih kompleks yang memberikan status dependensi selain statusnya sendiri.

Layanan Kesehatan tidak merespons jika kluster AKS tidak berfungsi, yang membuat beban kerja tidak sehat. Ketika layanan berjalan, layanan melakukan pemeriksaan berkala terhadap komponen penting solusi. Semua pemeriksaan dilakukan secara asinkron dan paralel. Jika salah satu pemeriksaan gagal, seluruh stempel tidak tersedia.

Peringatan

Pemeriksaan kesehatan Azure Front Door dapat memberlakukan beban signifikan pada Layanan Kesehatan karena permintaan berasal dari beberapa lokasi titik kehadiran (PoP). Untuk mencegah kelebihan beban komponen hilir, terapkan penembolokan yang efektif.

Layanan Kesehatan juga digunakan untuk pengujian ping URL yang dikonfigurasi secara eksplisit dengan sumber daya Application Insights setiap stempel.

Untuk informasi selengkapnya tentang HealthService implementasi, lihat Application Health Service.

Langkah selanjutnya

Jaringan dan konektivitas untuk beban kerja misi penting