Aplikasi web tanpa server

Microsoft Entra ID

Azure API Management

Azure Blob Storage

Azure Content Delivery Network

Azure Functions

Azure Monitor

Arsitektur referensi ini menunjukkan aplikasi web tanpa server. Aplikasi menyajikan konten statik dari Azure Blob Storage, dan menerapkan API menggunakan Azure Functions. API membaca data dari Azure Cosmos DB dan mengembalikan hasilnya ke aplikasi web.

Logo GitHub Dua implementasi referensi untuk arsitektur ini tersedia di GitHub: Aplikasi Pengiriman Drone (ARM & Azure Pipelines) dan To Do App (Bicep & GitHub Actions).

Sistem

Diagram memperlihatkan arsitektur referensi untuk aplikasi web tanpa server.

Unduh file Visio arsitektur ini.

Istilah tanpa server memiliki dua arti yang berbeda tetapi terkait:

Backend as a service (BaaS). Layanan cloud back-end, seperti database dan penyimpanan, menyediakan API yang memungkinkan aplikasi klien terhubung langsung ke layanan ini.
Functions as a service (FaaS). Dalam model ini, "function" adalah bagian dari kode yang disebarkan ke cloud dan berjalan di dalam lingkungan hosting yang sepenuhnya memisahkan server yang menjalankan kode.

Kedua definisi memiliki kesamaan gagasan bahwa pengembang dan personel DevOps tidak perlu menyebarkan, mengonfigurasi, atau mengelola server. Arsitektur referensi ini berfokus pada FaaS menggunakan Azure Functions, meskipun menyajikan konten web dari Azure Blob Storage dapat menjadi contoh BaaS. Beberapa karakteristik penting dari FaaS adalah:

Sumber daya komputasi dialokasikan secara dinamis sesuai kebutuhan platform.
Harga berbasis konsumsi: Anda hanya dikenakan biaya untuk sumber daya komputasi yang digunakan untuk menjalankan kode Anda.
Sumber daya komputasi menskalakan sesuai permintaan berdasarkan lalu lintas, tanpa pengembang perlu melakukan konfigurasi apa pun.

Fungsi dijalankan saat pemicu eksternal terjadi, seperti permintaan HTTP atau pesan yang datang di antrean. Hal ini membuat gaya arsitektur berbasis peristiwa alami untuk arsitektur tanpa server. Untuk mengoordinasikan pekerjaan antara komponen dalam arsitektur, pertimbangkan untuk menggunakan perantara pesan atau pola pub/sub. Untuk bantuan dalam memilih antara teknologi olahpesan di Azure, lihat Memilih antara layanan Azure yang mengirimkan pesan.

Komponen

Arsitektur terdiri dari komponen-komponen berikut:

Blob Storage. Konten web statis, seperti file HTML, CSS, dan JavaScript, disimpan di Azure Blob Storage dan disajikan kepada klien dengan menggunakan hosting situs web statis. Semua interaksi dinamis terjadi melalui kode JavaScript yang membuat panggilan ke API back-end. Tidak ada kode sisi server untuk merender halaman web. Hosting situs web statik mendukung dokumen indeks dan halaman kesalahan 404 kustom.

CDN. Gunakan Azure Content Delivery Network (CDN) untuk menyimpan konten untuk latensi yang lebih rendah dan pengiriman konten yang lebih cepat, serta menyediakan titik akhir HTTPS.

Aplikasi Fungsi. Azure Functions adalah opsi komputasi tanpa server. Azure Functions menggunakan model berbasis peristiwa, di mana kode ("function") dipanggil oleh pemicu. Dalam arsitektur ini, fungsi dipanggil saat klien membuat permintaan HTTP. Permintaan selalu dirutekan melalui gateway API, yang dijelaskan di bawah ini.

API Management. Azure API Management menyediakan gateway API yang berada di depan fungsi HTTP. Anda dapat menggunakan API Management untuk menerbitkan dan mengelola API yang digunakan oleh aplikasi klien. Menggunakan gateway membantu memisahkan aplikasi front-end dari API back-end. Misalnya, API Management dapat menulis ulang URL, mengubah permintaan sebelum mencapai back end, mengatur header permintaan atau respons, dan sebagainya.

API Management juga dapat digunakan untuk menerapkan masalah lintas sektoral seperti:

Menerapkan kuota penggunaan dan batas tarif
Memvalidasi token OAuth untuk autentikasi
Mengaktifkan permintaan lintas asal (CORS)
Menyimpan cache respons
Memantau dan mencatat permintaan

Jika Anda tidak memerlukan semua fungsi yang disediakan oleh API Management, opsi lainnya adalah menggunakan Proksi Fungsi. Fitur Azure Functions ini memungkinkan Anda menentukan satu permukaan API untuk beberapa aplikasi fungsi, dengan membuat rute ke fungsi back-end. Proksi fungsi juga dapat melakukan transformasi terbatas pada permintaan HTTP dan respons. Tetapi, proksi fungsi tidak menyediakan kemampuan berbasis kebijakan yang sama dari API Management.

Azure Cosmos DB. Azure Cosmos DB adalah layanan database multi-model. Untuk skenario ini, aplikasi fungsi mengambil dokumen dari Azure Cosmos DB sebagai respons terhadap permintaan HTTP GET dari klien.

ID Microsoft Entra (ID Microsoft Entra). Pengguna masuk ke aplikasi web dengan menggunakan kredensial ID Microsoft Entra mereka. MICROSOFT Entra ID mengembalikan token akses untuk API, yang digunakan aplikasi web untuk mengautentikasi permintaan API (lihat Autentikasi).

Azure Monitor. Azure Monitor mengumpulkan metrik performa tentang layanan Azure yang disebarkan dalam solusi. Dengan memvisualisasikan ini di dasbor, Anda bisa mendapatkan visibilitas ke dalam kesehatan solusi. Monitor juga mengumpulkan log aplikasi.

Azure Pipelines. Azure Pipelines adalah layanan integrasi berkelanjutan (CI) dan pengiriman berkelanjutan (CD) yang membangun, menguji, dan menyebarkan aplikasi.

GitHub Actions. Alur kerja adalah proses otomatis (CI/CD) yang Anda siapkan di repositori GitHub. Anda dapat membangun, menguji, mengemas, merilis, atau menyebarkan proyek apa pun di GitHub dengan alur kerja.

Detail skenario

Kemungkinan kasus penggunaan

Solusi pengiriman drone ini sangat ideal untuk industri pesawat terbang, penerbangan, dirgantara, dan robotika.

Rekomendasi

Paket Aplikasi Fungsi

Azure Functions mendukung dua model hosting. Dengan paket konsumsi, daya komputasi dialokasikan secara otomatis saat kode Anda berjalan. Dengan paket App Service, satu set mesin virtual dialokasikan untuk kode Anda. Paket App Service menentukan jumlah Mesin Virtual dan ukuran Mesin Virtual.

Perhatikan bahwa paket App Service tidak benar-benar tanpa server, sesuai dengan definisi yang diberikan di atas. Tetapi, model pemrogramannya sama — kode fungsi yang sama dapat berjalan di paket konsumsi dan paket App Service.

Berikut adalah beberapa faktor yang perlu dipertimbangkan saat memilih jenis paket yang akan digunakan:

Cold start. Dengan paket konsumsi, fungsi yang belum dipanggil baru-baru ini akan dikenakan beberapa latensi tambahan saat dijalankan berikutnya. Latensi tambahan ini disebabkan oleh pengalokasian dan persiapan lingkungan runtime. Biasanya pada urutan detik tetapi tergantung pada beberapa faktor, termasuk jumlah dependensi yang perlu dimuat. Untuk informasi selengkapnya, lihat Memahami Cold Start Tanpa Server. Cold start biasanya lebih menjadi perhatian untuk beban kerja interaktif (pemicu HTTP) daripada beban kerja berbasis pesan asinkron (pemicu antrean atau event hub), karena latensi tambahan diamati langsung oleh pengguna.
Periode batas waktu. Dalam paket konsumsi, waktu eksekusi fungsi habis setelah jangka waktu yang dapat dikonfigurasi (hingga maksimum 10 menit)
Isolasi jaringan virtual. Menggunakan paket App Service memungkinkan fungsi berjalan di dalam Lingkungan App Service, yang merupakan lingkungan hosting khusus dan terisolasi.
Model harga. Paket konsumsi ditagih berdasarkan jumlah eksekusi dan konsumsi sumber daya (memori × waktu eksekusi). Paket App Service ditagih per jam berdasarkan SKU instans mesin virtual. Sering kali, paket konsumsi dapat lebih murah daripada paket App Service, karena Anda hanya membayar untuk sumber daya komputasi yang Anda gunakan. Hal ini benar jika lalu lintas Anda mengalami peningkatan dan penurunan. Tetapi, jika aplikasi mengalami throughput volume tinggi yang konstan, paket App Service mungkin lebih murah daripada paket konsumsi.
Penskalaan. Keuntungan besar dari model konsumsi adalah model konsumsi menskalakan secara dinamis sesuai kebutuhan, berdasarkan lalu lintas masuk. Meskipun penskalaan ini terjadi dengan cepat, masih ada periode peningkatan. Untuk beberapa beban kerja, Anda mungkin perlu menyediakan mesin virtual secara berlebihan, sehingga Anda dapat menangani lonjakan lalu lintas dengan mudah. Dalam kasus ini, pertimbangkan paket App Service.

Batasan Aplikasi Fungsi

Aplikasi fungsi menghosting eksekusi satu atau beberapa fungsi. Anda dapat menggunakan aplikasi fungsi untuk mengelompokkan beberapa fungsi bersama sebagai unit logis. Dalam aplikasi fungsi, fungsi berbagi pengaturan aplikasi, paket hosting, dan siklus hidup penyebaran yang sama. Setiap aplikasi fungsi memiliki nama host sendiri.

Gunakan aplikasi fungsi untuk mengelompokkan fungsi yang memiliki siklus hidup dan pengaturan yang sama. Fungsi yang tidak memiliki siklus hidup yang sama harus dihosting di aplikasi fungsi yang berbeda.

Pertimbangkan untuk mengambil pendekatan layanan mikro, di mana setiap aplikasi fungsi mewakili satu layanan mikro, mungkin terdiri dari beberapa fungsi terkait. Dalam arsitektur layanan mikro, layanan harus memiliki keterikatan longgar dan kohesi fungsional yang tinggi. Diikat secara longgar berarti Anda dapat mengubah satu layanan tanpa mengharuskan layanan lain diperbarui secara bersamaan. Kohesif berarti layanan memiliki satu tujuan yang jelas. Untuk diskusi selengkapnya tentang gagasan ini, lihat Merancang layanan mikro: Analisis domain.

Pengikatan fungsi

Gunakan Pengikatan fungsi jika memungkinkan. Pengikatan menyediakan cara deklaratif untuk menghubungkan kode Anda ke data dan berintegrasi dengan layanan Azure lainnya. Pengikatan input mengisi parameter input dari sumber data eksternal. Pengikatan output mengirimkan nilai pengembalian fungsi ke sink data, seperti antrean atau database.

Misalnya, GetStatus fungsi dalam implementasi referensi menggunakan pengikatan input Azure Cosmos DB. Pengikatan ini dikonfigurasi untuk mencari dokumen di Azure Cosmos DB, menggunakan parameter kueri yang diambil dari string kueri dalam permintaan HTTP. Jika dokumen ditemukan, dokumen akan diteruskan ke fungsi sebagai parameter.

[Function("GetStatusFunction")]
public IActionResult Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req,
        [CosmosDBInput(
           databaseName: "%COSMOSDB_DATABASE_NAME%",
           containerName:"%COSMOSDB_DATABASE_COL%",
           Connection  = "COSMOSDB_CONNECTION_STRING",
           Id = "{Query.deviceId}",
           PartitionKey = "{Query.deviceId}")] DeviceState? deviceStatus)
{
  ...
}

Dengan menggunakan pengikatan, Anda tidak perlu menulis kode yang berbicara langsung ke layanan, yang membuat kode fungsi lebih sederhana dan juga memisahkan detail sumber data atau sink. Tetapi, dalam beberapa kasus, Anda mungkin memerlukan logika yang lebih kompleks daripada yang disediakan oleh pengikatan. Dalam kasus ini, gunakan SDK klien Azure secara langsung.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Skalabilitas

Functions. Untuk paket konsumsi, pemicu HTTP menskalakan berdasarkan lalu lintas. Ada batasan jumlah instans fungsi bersamaan, tetapi setiap instans dapat memproses lebih dari satu permintaan pada satu waktu. Untuk paket App Service, pemicu HTTP diskalakan sesuai dengan jumlah instans mesin virtual, yang dapat berupa nilai tetap atau dapat diskalakan otomatis berdasarkan serangkaian aturan penskalaan otomatis. Untuk informasi, lihat Skala dan hosting Azure Functions.

Azure Cosmos DB. Kapasitas throughput untuk Azure Cosmos DB diukur dalam Unit Permintaan (RU). Throughput 1-RU sesuai dengan kebutuhan throughput untuk MENDAPATKAN dokumen 1KB. Untuk menskalakan kontainer Azure Cosmos DB melewati 10.000 RU, Anda harus menentukan kunci partisi saat membuat kontainer dan menyertakan kunci partisi di setiap dokumen yang Anda buat. Untuk informasi selengkapnya tentang kunci partisi, lihat Partisi dan penskalaan di Azure Cosmos DB.

API Management. API Management dapat meluaskan skala dan mendukung penskalaan otomatis berbasis aturan. Proses penskalaan memerlukan waktu setidaknya 20 menit. Jika lalu lintas melonjak, Anda harus memprovisikan lalu lintas lonjakan maksimum yang Anda harapkan. Tetapi, penskalaan otomatis berguna untuk menangani variasi lalu lintas per jam atau harian. Untuk informasi selengkapnya, lihat Menskalakan instans Azure API Management secara otomatis.

Pemulihan dari bencana

Penyebaran yang ditampilkan di sini berada di satu wilayah Azure. Untuk pendekatan yang lebih tangguh terhadap pemulihan bencana, manfaatkan fitur geo-distribusi di berbagai layanan:

API Management mendukung penyebaran multi-wilayah, yang dapat digunakan untuk mendistribusikan satu instans API Management di sejumlah wilayah Azure. Untuk informasi selengkapnya, lihat Cara menerapkan instans layanan API Management Azure ke beberapa wilayah Azure.
Gunakan Traffic Manager untuk merutekan permintaan HTTP ke wilayah utama. Jika Aplikasi Fungsi yang berjalan di wilayah tersebut menjadi tidak tersedia, Traffic Manager dapat mengalihkan ke wilayah sekunder.
Azure Cosmos DB mendukung beberapa wilayah tulis, yang memungkinkan penulisan ke wilayah mana pun yang Anda tambahkan ke akun Azure Cosmos DB Anda. Jika Anda tidak mengaktifkan fitur multi-penulisan, Anda masih dapat melakukan failover ke wilayah penulisan utama. SDK klien Azure Cosmos DB dan pengikatan Azure Function secara otomatis menangani failover, sehingga Anda tidak perlu memperbarui pengaturan konfigurasi aplikasi apa pun.

Keamanan

Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keamanan.

Autentikasi

GetStatus API dalam implementasi referensi menggunakan ID Microsoft Entra untuk mengautentikasi permintaan. MICROSOFT Entra ID mendukung protokol Koneksi OpenID, yang merupakan protokol autentikasi yang dibangun di atas protokol OAuth 2.

Dalam arsitektur ini, aplikasi klien adalah aplikasi satu halaman (SPA) yang berjalan di browser. Jenis aplikasi klien ini tidak dapat menjaga rahasia klien atau kode otorisasi tetap tersembunyi, sehingga alur pemberian implisit sesuai. (Lihat Alur OAuth 2.0 mana yang harus saya gunakan?). Berikut alur keseluruhannya:

Pengguna mengklik tautan "Masuk" di aplikasi web.
Browser dialihkan ke halaman masuk Microsoft Entra.
Pengguna masuk.
MICROSOFT Entra ID mengalihkan kembali ke aplikasi klien, termasuk token akses di fragmen URL.
Saat aplikasi web memanggil API, aplikasi web menyertakan token akses di header Autentikasi. ID aplikasi dikirim sebagai klaim audiens ('aud') di token akses.
API back-end memvalidasi token akses.

Untuk mengonfigurasi autentikasi:

Daftarkan aplikasi di penyewa Microsoft Entra Anda. Hal ini menghasilkan ID aplikasi, yang disertakan klien dengan URL masuk.
Aktifkan autentikasi Microsoft Entra di dalam Aplikasi Fungsi. Untuk informasi selengkapnya, lihatAutentikasi dan otorisasi di Azure App Service.
Tambahkan kebijakan validate-jwt ke API Management untuk melakukan pra-otorisasi permintaan dengan memvalidasi token akses.

Untuk detail selengkapnya, lihat GitHub readme.

Disarankan untuk membuat pendaftaran aplikasi terpisah di ID Microsoft Entra untuk aplikasi klien dan API back-end. Berikan izin aplikasi klien untuk memanggil API. Pendekatan ini memberi Anda fleksibilitas untuk menentukan beberapa API dan klien serta mengontrol izin untuk API dan klien.

Dalam API, gunakan cakupan untuk memberi aplikasi kontrol mendetail atas izin apa yang mereka minta dari pengguna. Misalnya, API mungkin memiliki cakupan Read dan Write, dan aplikasi klien tertentu mungkin meminta pengguna untuk mengotorisasi izin Read saja.

Authorization

Di banyak aplikasi, API back-end harus memeriksa apakah pengguna memiliki izin untuk melakukan tindakan tertentu. Disarankan untuk menggunakan otorisasi berbasis klaim, di mana informasi tentang pengguna disampaikan oleh Penyedia Identitas (dalam hal ini, ID Microsoft Entra) dan digunakan untuk membuat keputusan otorisasi. Misalnya, saat mendaftarkan aplikasi di MICROSOFT Entra ID, Anda dapat menentukan serangkaian peran aplikasi. Saat pengguna masuk ke aplikasi, ID Microsoft Entra menyertakan roles klaim untuk setiap peran yang telah diberikan pengguna, termasuk peran yang diwarisi melalui keanggotaan grup.

Token ID yang dikembalikan ID Microsoft Entra ke klien berisi beberapa klaim pengguna. Dalam aplikasi fungsi, klaim ini tersedia di header permintaan X-MS-CLIENT-PRINCIPAL. Tetapi, lebih mudah untuk membaca informasi ini dari data pengikatan. Untuk klaim lain, gunakan Microsoft Graph untuk mengkueri ID Microsoft Entra. (Pengguna harus menyetujui tindakan ini saat masuk.)

Untuk informasi selengkapnya, lihat Bekerja dengan identitas klien.

CORS

Dalam arsitektur referensi ini, aplikasi web dan API tidak berbagi asal yang sama. Itu berarti ketika aplikasi memanggil API, itu adalah permintaan lintas asal. Keamanan browser mencegah halaman web untuk membuat permintaan AJAX ke domain lain. Pembatasan ini disebut kebijakan asal yang sama dan mencegah situs berbahaya membaca data sensitif dari situs lain. Untuk mengaktifkan permintaan lintas asal, tambahkan kebijakan Berbagi Sumber Daya Lintas Asal (CORS) ke gateway API Management:

<cors allow-credentials="true">
    <allowed-origins>
        <origin>[Website URL]</origin>
    </allowed-origins>
    <allowed-methods>
        <method>GET</method>
    </allowed-methods>
    <allowed-headers>
        <header>*</header>
    </allowed-headers>
</cors>

Dalam contoh ini, atribut allow-credentials adalah true. Hal ini mengotorisasi browser untuk mengirim kredensial (termasuk cookie) dengan permintaan. Jika tidak, secara default browser tidak mengirim kredensial dengan permintaan lintas asal.

Catatan

Berhati-hatilah dalam mengatur allow-credentials ke true, karena hal tersebut berarti situs web dapat mengirimkan kredensial pengguna ke API Anda atas nama pengguna, tanpa sepengetahuan pengguna. Anda harus mempercayai asal yang diizinkan.

Menerapkan HTTPS

Untuk keamanan maksimum, HTTPS diperlukan di seluruh alur permintaan:

CDN. Azure CDN mendukung HTTPS pada subdomain *.azureedge.net secara default. Untuk mengaktifkan HTTPS di CDN untuk nama domain kustom, lihat Tutorial: Mengonfigurasi HTTPS di domain kustom Azure CDN.
Hosting situs web statik. Aktifkan opsi "Diperlukan transfer aman" di Akun penyimpanan. Jika opsi ini diaktifkan, akun penyimpanan hanya mengizinkan permintaan dari koneksi HTTPS yang aman.

API Management. Konfigurasikan API untuk menggunakan protokol HTTPS saja. Anda dapat mengonfigurasi ini di portal Microsoft Azure atau melalui template Resource Manager:

{
    "apiVersion": "2018-01-01",
    "type": "apis",
    "name": "dronedeliveryapi",
    "dependsOn": [
        "[concat('Microsoft.ApiManagement/service/', variables('apiManagementServiceName'))]"
    ],
    "properties": {
        "displayName": "Drone Delivery API",
        "description": "Drone Delivery API",
        "path": "api",
        "protocols": [ "HTTPS" ]
    },
    ...
}

Fungsi-fungsi Azure. Aktifkan pengaturan "Hanya HTTPS".

Mengunci aplikasi fungsi

Semua panggilan ke fungsi harus melalui gateway API. Anda dapat mencapai hal ini sebagai berikut:

Konfigurasikan aplikasi fungsi agar memerlukan kunci fungsi. Gateway API Management akan menyertakan kunci fungsi saat memanggil aplikasi fungsi. Hal ini mencegah klien memanggil fungsi secara langsung, melewati gateway.
Gateway API Management memiliki alamat IP statik. Batasi Azure Function untuk hanya mengizinkan panggilan dari alamat IP statik tersebut. Untuk informasi selengkapnya, lihat Pembatasan IP Statik Azure App Service. (Fitur ini hanya tersedia untuk layanan tingkat Standar.)

Melindungi rahasia aplikasi

Jangan simpan rahasia aplikasi, seperti kredensial database, dalam kode atau file konfigurasi Anda. Sebagai gantinya, gunakan pengaturan Aplikasi, yang disimpan yang dienkripsi di Azure. Untuk informasi selengkapnya, lihat Keamanan di Azure App Service dan Azure Functions.

Atau, Anda dapat menyimpan rahasia aplikasi di Key Vault. Hal ini memungkinkan Anda memusatkan penyimpanan rahasia, mengontrol distribusinya, dan memantau bagaimana dan kapan rahasia diakses. Untuk informasi selengkapnya, lihat Mengonfigurasi aplikasi web Azure untuk membaca rahasia dari Key Vault. Tetapi, perhatikan bahwa pemicu dan pengikatan Functions memuat pengaturan konfigurasinya dari pengaturan aplikasi. Tidak ada cara bawaan untuk mengonfigurasi pemicu dan pengikatan untuk menggunakan rahasia Key Vault.

DevOps

Penyebaran front-end

Ujung depan arsitektur referensi ini adalah aplikasi satu halaman, dengan JavaScript yang mengakses API back-end tanpa server, dan konten statik yang memberikan pengalaman pengguna yang cepat. Berikut ini adalah beberapa pertimbangan penting untuk aplikasi semacam itu:

Sebarkan aplikasi secara seragam kepada pengguna di area geografis yang luas dengan CDN yang siap secara global, dengan konten statik yang dihosting di cloud. Hal ini menghindari kebutuhan akan server web khusus. Baca Mengintegrasikan akun penyimpanan Azure dengan Azure CDN untuk memulai. Amankan aplikasi Anda dengan HTTPS. Baca Praktik terbaik untuk menggunakan jaringan pengiriman konten untuk rekomendasi tambahan.
Gunakan layanan CI/CD yang cepat dan andal seperti Azure Pipelines atau GitHub Actions, untuk membangun dan menyebarkan setiap perubahan sumber secara otomatis. Sumber harus berada dalam sistem kontrol versi online. Untuk detail selengkapnya tentang Azure Pipelines, baca Membuat alur pertama Anda. Untuk mempelajari selengkapnya tentang GitHub Actions untuk Azure, lihat Menyebarkan aplikasi ke Azure.
Padatkan file situs web Anda untuk mengurangi penggunaan bandwidth pada CDN dan meningkatkan performa. Azure CDN memungkinkan pemadatan dengan cepat di server edge. Atau, alur penyebaran dalam arsitektur referensi ini memadatkan file sebelum menyebarkannya ke penyimpanan Blob. Hal ini mengurangi persyaratan penyimpanan, dan memberi Anda lebih banyak kebebasan untuk memilih alat pemadatan, terlepas dari batasan CDN apa pun.
CDN harus dapat menghapus menyeluruh cache CDN untuk memastikan semua pengguna mendapatkan konten terbaru. Pembersihan cache diperlukan jika proses build dan deploy tidak atomik, misalnya, jika mereka mengganti file lama dengan yang baru dibuat di folder asal yang sama.
Strategi cache yang berbeda seperti penerapan versi menggunakan direktori, mungkin tidak memerlukan penghapusan menyeluruh oleh CDN. Alur pembangunan di aplikasi front-end ini membuat direktori baru untuk setiap versi yang baru dibangun. Versi ini diunggah sebagai unit atomik ke penyimpanan Blob. Azure CDN mengarah ke versi baru ini hanya setelah penyebaran selesai.
Tingkatkan TTL cache dengan menyimpan file sumber untuk durasi yang lebih lama, hingga beberapa bulan. Untuk memastikan file yang di-cache diperbarui saat berubah, sidik jari nama file saat dibuat ulang. Aplikasi front-end ini memindai sidik jari semua file kecuali untuk file umum seperti index.html. Karena index.html sering diperbarui, ini mencerminkan nama file yang diubah yang menyebabkan penyegaran cache. Lihat Mengelola kedaluwarsa konten web di Azure CDN untuk informasi selengkapnya.

Penyebaran back-end

Untuk menyebarkan aplikasi fungsi, sebaiknya gunakan file paket ("Jalankan dari paket"). Dengan menggunakan pendekatan ini, Anda mengunggah file zip ke kontainer Blob Storage dan runtime Functions memasang file zip sebagai sistem file baca-saja. Ini adalah operasi atomik, yang mengurangi kemungkinan penyebaran yang gagal akan membuat aplikasi dalam status tidak konsisten. Hal ini juga dapat meningkatkan waktu cold start, terutama untuk aplikasi Node.js, karena semua file ditukar sekaligus.

Penerapan versi API

API adalah kontrak antara layanan dan klien. Dalam arsitektur ini, kontrak API ditentukan pada lapisan API Management. API Management mendukung dua konsep penerapan versi yang berbeda tetapi saling melengkapi:

Versi memungkinkan konsumen API memilih versi API berdasarkan kebutuhan mereka, seperti v1 versus v2.
Revisi memungkinkan administrator API membuat perubahan yang tidak merusak dalam API dan menyebarkan perubahan tersebut, bersama dengan log perubahan untuk memberi tahu konsumen API tentang perubahan tersebut.

Jika Anda membuat perubahan yang merusak di API, terbitkan versi baru di API Management. Sebarkan versi baru secara berdampingan dengan versi asli, di Aplikasi Fungsi terpisah. Hal ini memungkinkan Anda memigrasikan klien yang ada ke API baru tanpa merusak aplikasi klien. Akhirnya, Anda dapat menghentikan versi sebelumnya. API Management mendukung beberapa skema penerapan versi: jalur URL, header HTTP, atau string kueri. Untuk informasi selengkapnya tentang penerapan versi API secara umum, lihat Menerapkan versi API web RESTful.

Untuk pembaruan yang tidak melanggar perubahan API, sebarkan versi baru ke slot penahapan di Aplikasi Fungsi yang sama. Pastikan penyebaran berhasil, lalu tukar versi bertahap dengan versi produksi. Terbitkan revisi di API Management.

Pengoptimalan biaya

Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.

Gunakan kalkulator harga Azure untuk memperkirakan biaya. Pertimbangkan poin-poin ini untuk mengoptimalkan biaya arsitektur ini.

Azure Functions

Azure Functions mendukung dua model hosting.

Paket konsumsi.

Daya komputasi dialokasikan secara otomatis saat kode Anda berjalan.
Paket Azure App Service.

Satu set mesin virtual dialokasikan untuk kode Anda. Paket ini menentukan jumlah mesin virtual dan ukuran mesin virtual.

Dalam arsitektur ini, fungsi dipanggil saat klien membuat permintaan HTTP. Karena throughput volume tinggi yang konstan tidak diharapkan dalam kasus penggunaan ini, paket konsumsi direkomendasikan karena Anda hanya membayar sumber daya komputasi yang Anda gunakan.

Azure Cosmos DB

Tagihan Azure Cosmos DB untuk throughput yang tersedia dan penyimpanan yang dikonsumsi per jam. Throughput yang tersedia dinyatakan dalam Request Unit per detik (RU/dtk), yang dapat digunakan untuk operasi database biasa, seperti penyisipan, pembacaan. Harga didasarkan pada kapasitas dalam RU/dtk yang Anda pesan.

Penyimpanan ditagih untuk setiap GB yang digunakan untuk data dan indeks yang Anda simpan.

Lihat Model harga Azure Cosmos DB untuk informasi selengkapnya.

Dalam arsitektur ini, aplikasi fungsi mengambil dokumen dari Azure Cosmos DB sebagai respons terhadap permintaan HTTP GET dari klien. Azure Cosmos DB hemat biaya dalam hal ini karena operasi membaca secara signifikan lebih murah daripada operasi tulis yang dinyatakan pada RU/s.

Jaringan Pengiriman Konten

Tarif tagihan mungkin berbeda bergantung pada wilayah tagihan berdasarkan lokasi server sumber yang mengirimkan konten ke pengguna akhir. Lokasi fisik klien bukan wilayah penagihan. Setiap permintaan HTTP atau HTTPS yang mengenai CDN adalah peristiwa yang dapat ditagih, yang mencakup semua jenis respons: sukses, gagal, atau lainnya. Respons yang berbeda dapat menghasilkan jumlah lalu lintas yang berbeda.

Dalam arsitektur referensi ini, penyebaran berada di satu wilayah Azure.

Untuk menurunkan biaya, pertimbangkan untuk meningkatkan TTL cache dengan menyimpan file sumber untuk durasi yang lebih lama dan mengatur TTL terpanjang pada konten Anda.

Untuk informasi selengkapnya, lihat bagian Biaya di Microsoft Azure Well-Architected Framework.

Menyebarkan skenario ini

Guna menyebarkan penerapan referensi untuk arsitektur ini, lihat GitHub readme.

Langkah berikutnya

Dokumentasi produk:

Pelajari modul:

Untuk mempelajari selengkapnya tentang penerapan referensi, baca Panduan kode: Aplikasi tanpa server dengan Azure Functions.

Panduan terkait:

Aplikasi web tanpa server

Sistem

Komponen

Detail skenario

Kemungkinan kasus penggunaan

Rekomendasi

Paket Aplikasi Fungsi

Batasan Aplikasi Fungsi

Pengikatan fungsi

Pertimbangan

Skalabilitas

Pemulihan dari bencana

Keamanan

Autentikasi

Authorization

CORS

Menerapkan HTTPS

Mengunci aplikasi fungsi

Melindungi rahasia aplikasi

DevOps

Penyebaran front-end

Penyebaran back-end

Penerapan versi API

Pengoptimalan biaya

Azure Functions

Azure Cosmos DB

Jaringan Pengiriman Konten

Menyebarkan skenario ini

Langkah berikutnya

Saran dan Komentar

Saran dan Komentar

Sumber Daya Tambahan:

Aplikasi web tanpa server

Sistem

Komponen

Detail skenario

Kemungkinan kasus penggunaan

Rekomendasi

Paket Aplikasi Fungsi

Batasan Aplikasi Fungsi

Pengikatan fungsi

Pertimbangan

Skalabilitas

Pemulihan dari bencana

Keamanan

Autentikasi

Authorization

CORS

Menerapkan HTTPS

Mengunci aplikasi fungsi

Melindungi rahasia aplikasi

DevOps

Penyebaran front-end

Penyebaran back-end

Penerapan versi API

Pengoptimalan biaya

Azure Functions

Azure Cosmos DB

Jaringan Pengiriman Konten

Menyebarkan skenario ini

Langkah berikutnya

Sumber daya terkait

Saran dan Komentar

Saran dan Komentar

Sumber Daya Tambahan: