Pendikitan, Cache dan Pelan Penggunaan

Tanpa pengehad kadar, satu klien yang bermasalah atau lonjakan trafik boleh membebankan perkhidmatan bahagian belakang anda—keserentakan Lambda, sambungan RDS atau API hiliran. Pengehad kadar dalam API Gateway mengehadkan bilangan permintaan sesaat dan membenarkan lonjakan singkat melebihi kadar keadaan mantap. Permintaan yang dihadkan menerima respons 429 Too Many Requests serta-merta tanpa sampai ke bahagian belakang, sekali gus melindungi sumber hiliran daripada beban berlebihan.

Pengehad kadar beroperasi pada beberapa peringkat. Had peringkat akaun ialah 10,000 permintaan sesaat (RPS) dengan lonjakan 5,000 permintaan (had lembut yang boleh ditingkatkan). Pada peringkat tahap, anda boleh menetapkan kadar pengehad lalai (RPS) dan had lonjakan yang terpakai pada semua kaedah dalam tahap tersebut. Pada peringkat kaedah, anda boleh mengatasi lalai tahap untuk titik akhir tertentu—contohnya, memberikan titik akhir GET yang banyak membaca kadar lebih tinggi berbanding titik akhir POST yang banyak menulis.

Pengehad kadar API Gateway menggunakan algoritma baldi token. Token terkumpul dalam baldi sehingga had lonjakan (kapasiti segera maksimum). Setiap permintaan menggunakan satu token. Token diisi semula pada had kadar (RPS keadaan mantap). Jika baldi kosong, permintaan dihadkan. Contoh: lonjakan=5000, kadar=1000 RPS. Pada permulaan, anda boleh mengendalikan 5000 permintaan serentak; baldi diisi semula dengan 1000 token sesaat. Ini membolehkan lonjakan trafik singkat diserap sambil menguatkuasakan had kadar jangka panjang.

Penyimpanan cache respons (tersedia pada tahap REST API) menyimpan respons bahagian belakang dalam cache yang diuruskan oleh API Gateway supaya permintaan yang sama boleh disediakan daripada cache tanpa menghubungi bahagian belakang. Ini mengurangkan beban bahagian belakang, menurunkan kependaman dan boleh mengurangkan kos pemanggilan Lambda dengan ketara bagi API yang banyak membaca. Cache ditentukan berdasarkan permintaan (kaedah, laluan, rentetan pertanyaan dan pengepala mengikut konfigurasi). TTL cache boleh dikonfigurasikan daripada 0 hingga 3600 saat (lalai 300 saat).

Secara lalai, kunci cache ialah URL permintaan penuh. Anda boleh menyesuaikan elemen yang menyumbang kepada kunci cache: sertakan parameter rentetan pertanyaan tertentu (contohnya, pageSize, filter) tetapi kecualikan parameter yang tidak berkaitan (contohnya, cap masa). Anda juga boleh menyertakan pengepala tertentu dalam kunci cache. Kecualikan pengepala sensitif daripada kunci cache untuk mengelakkan data peribadi mencemari entri cache dikongsi. Gunakan penalaan kunci cache untuk memaksimumkan kadar cache hit sambil memastikan permintaan logik yang berbeza menerima respons cache yang berbeza.

Klien boleh membatalkan cache untuk permintaan tertentu dengan menyertakan pengepala Cache-Control: max-age=0. Anda juga boleh mengosongkan keseluruhan cache peringkat daripada konsol atau API. Konfigurasikan sama ada klien dibenarkan membatalkan cache—hadkan keupayaan ini dalam persekitaran produksi untuk menghalang klien daripada sengaja memintas caching. Untuk memberikan kebenaran mengosongkan cache secara terpilih, lampirkan dasar sumber atau gunakan pengesah Lambda yang menyemak sama ada pemanggil mempunyai kebenaran untuk mengosongkan cache.

Pelan Penggunaan mentakrifkan had pendikitan dan had kuota untuk sekumpulan klien API. Kaitkan peringkat API dengan pelan penggunaan, kemudian kaitkan kunci API dengan pelan tersebut. Setiap kunci API menguatkuasakan had pelan secara berasingan. Pelan penggunaan membolehkan anda menawarkan akses berperingkat: pelan Percuma pada 100 RPM/10,000 permintaan sehari, dan pelan Pro pada 1,000 RPM/100,000 permintaan sehari. Inilah model untuk API yang dikomersialkan dan integrasi rakan kongsi apabila klien yang berbeza memerlukan had kadar yang berbeza.

Kunci API ialah token rentetan legap yang disertakan oleh klien dalam pengepala permintaan x-api-key. API Gateway mengesahkan kunci tersebut dan mengaitkan permintaan dengan pelan penggunaan yang sepadan. Kunci API BUKAN mekanisme keselamatan—kunci ini hanya mengenal pasti klien untuk tujuan pendikitan dan kuota. Untuk keselamatan, sentiasa gabungkan kunci API dengan kebenaran yang sewajarnya (IAM, pengesah Lambda atau Cognito). Kunci API yang tidak dikaitkan dengan pelan penggunaan tidak akan dikenakan had pendikitan.

Selain kadar pendikitan sesaat, pelan penggunaan menyokong had kuota: jumlah maksimum permintaan dalam suatu tempoh (DAY, WEEK atau MONTH). Setelah klien menghabiskan kuotanya, permintaan seterusnya mengembalikan 429 sehingga kuota ditetapkan semula. Had kuota berguna untuk penguatkuasaan peringkat percuma, mencegah penyalahgunaan API dan menyelaraskan penggunaan API dengan pengebilan. Kaunter kuota akhirnya menjadi konsisten, jadi klien mungkin melebihi kuotanya sedikit sebelum disekat.

Pantau kesihatan API Gateway menggunakan metrik CloudWatch berikut:

• Count: jumlah panggilan API
• 4XXError: ralat klien termasuk pendikitan 429
• 5XXError: ralat bahagian belakang
• Latency: masa permintaan hujung ke hujung
• IntegrationLatency: masa menunggu bahagian belakang
• CacheHitCount / CacheMissCount: keberkesanan cache

Tetapkan penggera pada lonjakan 4XXError untuk mengesan masalah pendikitan sebelum menjejaskan pengguna, dan pada CacheMissCount untuk mengenal pasti masalah konfigurasi cache.

Gunakan cache untuk API yang banyak membaca dan responsnya jarang berubah—seperti carian katalog produk, data rujukan dan konfigurasi statik. Cache tidak berkesan untuk data khusus pengguna atau data yang sangat dinamik. Sentiasa gunakan pendikitan—termasuk untuk API dalaman—untuk melindungi perkhidmatan bahagian belakang daripada beban berlebihan. Gabungkan kedua-duanya: cache data umum untuk mengurangkan beban bahagian belakang dan lakukan pendikitan secara agresif untuk menghalang mana-mana klien daripada menguasai API. Untuk peperiksaan SAA-C03, cache mengurangkan kos dan kependaman; pendikitan memastikan ketersediaan.

Dalam pelajaran ini, anda telah mempelajari bahawa: pendikitan pada peringkat akaun, peringkat dan kaedah melindungi bahagian belakang menggunakan algoritma baldi token dengan had kadar dan letusan yang boleh dikonfigurasikan, cache respons menyimpan respons bahagian belakang untuk TTL yang boleh dikonfigurasikan bagi mengurangkan beban bahagian belakang dan kependaman pada titik akhir yang banyak membaca, manakala pelan penggunaan dengan kunci API menguatkuasakan kadar pendikitan dan kuota bagi setiap klien untuk membolehkan kawalan akses berperingkat bagi API rakan kongsi dan awam. Seterusnya, kita akan meneroka kluster ECS, takrif tugas dan perkhidmatan untuk beban kerja berbekas.