Shartli chaqiruvlar yordamida API xarajatlarini kamaytirish

1. Umumiy ko‘rinish

Avvalgi maqolada MyData xizmatidan foydalanish jarayonida asosiy ekran javoblarida yuzaga kelgan kechikishni cache-first render qilish va fonda yangilash strategiyasi, boshqacha aytganda, amaldagi Stale-While-Revalidate (SWR) modeliga mos yondashuv yordamida qanday hal qilganimni yoritgan edim. Ushbu maqolada ayni xizmatdan foydalanish davomida duch kelgan keyingi muammo haqida so‘z yuritiladi. Bu safar muammo unumdorlikda emas, balki xarajatda edi.

Tashqi muassasalarni qidirish API'lari uchun billing tuzilmasi o‘zgargach, qo‘ng‘iroqlar sonining o‘zi operatsion xarajatga aylandi va avvalgi “zarur bo‘lganda hamma narsani qidirish” yondashuvini davom ettirish qiyinlashdi. Buni hal qilish uchun qidiruv vaqt belgilaridan foydalanib, vaqt belgisiga asoslangan shartli qo‘ng‘iroqlarni qo‘lladim va qo‘ng‘iroqlar bajariladigan vaqtni qayta taqsimladim (batch yangilash + Lazy Loading). Orqaga qarab, o‘sha paytda nomini bilmagan bu yondashuv uzoq vaqtdan beri HTTP protokoli tomonidan standart sifatida taqdim etib kelinayotgan mexanizm — shartli so‘rovlar bilan bir xil g‘oyaga asoslanganini ko‘raman. Ushbu maqolada muammo, uni hal qilish jarayoni va standart mexanizmlar nuqtayi nazaridan qayta talqin qilish ketma-ket yoritiladi.

2. Muammo: Qo‘ng‘iroqlar soni xarajatga aylanadi

MyData xizmati bir nechta tashqi moliyaviy muassasalarning standart API'larini chaqirish orqali foydalanuvchilarning aktivlari va tranzaksiyalari haqidagi ma’lumotlarni to‘playdi. Hatto bitta yangilash jarayonining o‘zida ham muassasalar ro‘yxatini qidirish, hisoblar ro‘yxatini qidirish, muayyan hisob tafsilotlarini qidirish va tranzaksiyalar tarixini qidirish kabi quyi API'lar ketma-ket chaqiriladi. Natijada, hatto bitta foydalanuvchi ma’lumotlarini bir marta yangilashda ham ancha ko‘p qo‘ng‘iroqlar yuzaga keladi.

Xizmatning dastlabki bosqichlarida bu qo‘ng‘iroqlar hajmi sezilarli yuk bo‘lmagan, ammo billing tuzilmasi qo‘ng‘iroqlar soniga asoslangan shaklga o‘tgach, vaziyat o‘zgardi. Har bir yangilashda biror narsa o‘zgargan-o‘zgarmaganidan qat’i nazar hamma narsani qayta qidirish yondashuvi saqlanib qolgani sababli, amalda o‘zgarmagan ma’lumotlarni qaytargan qo‘ng‘iroqlar uchun ham xuddi shunday xarajat qilindi. Foydalanuvchilar soni oshgani sari bu isrofgarchilik ham ortib bordi.

Avvalgi maqolada muhokama qilingan javob kechikishi foydalanuvchilar bevosita sezadigan muammo bo‘lgan bo‘lsa, bu muammo foydalanuvchilarga ko‘rinmas, ammo operatsiyalarning barqarorligiga bevosita bog‘liq edi. Muammoni quyidagicha qayta ifodalash mumkin: “Baribir o‘zgarmagan ma’lumotlarni tekshirish uchungina har safar hamma narsani qayta olishimiz haqiqatan ham kerakmi?” Oxir-oqibat, yechim qo‘ng‘iroqlarni butunlay yo‘q qilish emas, balki keraksiz qo‘ng‘iroqlarni aniqlab, ularni o‘tkazib yuborishdan iborat bo‘ldi.

3. Yechim strategiyasi 1: Vaqt belgisiga asoslangan shartli qo‘ng‘iroqlar

MyData standart API spetsifikatsiyasida qidiruv uchun vaqt bo‘yicha tayanch nuqtani boshqarish maqsadida Timestamp tushunchasi mavjud. Undan foydalanib, avvalgi qidiruvdan beri biror narsa o‘zgargan-o‘zgarmaganini tekshirishimiz va hech narsa o‘zgarmagan bo‘lsa, avval saqlangan ma’lumotlardan o‘z holicha foydalanib, quyi darajadagi API' chaqiruvlarini o‘tkazib yuborishimiz mumkin. Batafsil qidiruvlar faqat o‘zgarish aniqlangandagina bajariladi.

Qayta ishlash jarayonini quyidagi psevdokod bilan umumlashtirish mumkin.

function 자산정보갱신(사용자ID, 기관ID):
  이전조회시점 = 조회이력.최근조회시점(사용자ID, 기관ID)
  변경여부 = 외부기관API.변경확인(사용자ID, 이전조회시점)
 
  if 변경여부 == 없음:
     return 저장소.기존데이터(사용자ID, 기관ID)
 
  최신데이터 = 외부기관API.상세조회(사용자ID)  // 과금 대상 호출
  저장소.갱신(사용자ID, 기관ID, 최신데이터)
  조회이력.기록(사용자ID, 기관ID, 현재시각)
  return 최신데이터

Ushbu tuzilmaning kaliti “so‘rash xarajati past, olish xarajati esa yuqori” degan nomutanosiblikdan foydalanishdir. Biror narsa o‘zgargan-o‘zgarmaganini tekshirish uchun avval yengil qo‘ng‘iroq orqali saralab olamiz va to‘liq ma’lumotni qaytaradigan og‘irroq qo‘ng‘iroqni faqat o‘zgarish tasdiqlangan holatlar bilan cheklaymiz. Bu tuzilma ma’lumotlari tez-tez o‘zgarmaydigan foydalanuvchilar uchun yanada katta tejamkorlikni ta’minlaydi.

4. Yechim strategiyasi 2: Qo‘ng‘iroqlar bajariladigan vaqtni qayta taqsimlash

Agar shartli qo‘ng‘iroqlar “qo‘ng‘iroq qilish yoki qilmaslik”ni filtrlash mexanizmi bo‘lgan bo‘lsa, ikkinchi strategiya “qo‘ng‘iroqni qachon qilish”ni qayta loyihalashdan iborat edi. Biz ikki yondashuvni birlashtirdik.

Birinchisi — davriy batch yangilashlar. Foydalanuvchi tanlagan yangilash oralig‘iga asoslanib, foydalanuvchi ekranga kirish-kirmasligidan qat’i nazar, ma’lumotlar oldindan belgilangan vaqtlarda yangilanadi. Yangilash vaqtlari oldindan ma’lum bo‘lgani sababli, qo‘ng‘iroqlar hajmi muayyan vaqtlarda to‘planib qolmaydi va allaqachon yangilangan ma’lumotlar foydalanuvchi ekranga kirishi bilan darhol ko‘rsatilishi mumkin.

Ikkinchisi — batafsil ma’lumotlar uchun Lazy Loading. Alohida hisoblarning tranzaksiyalar tarixi kabi batafsil ma’lumotlar faqat foydalanuvchi ularni amalda ochgandagina mazmunli bo‘ladi. Shu sababli ularni asosiy yangilash jarayonining bir qismi sifatida oldindan olish o‘rniga, tegishli batafsil ekran ochilganda so‘raladigan qilib ajratdik. Har bir foydalanuvchi har bir hisob tafsilotlarini tekshirmagani sababli, amalda hech qachon ko‘rilmaydigan batafsil ma’lumotlar uchun qo‘ng‘iroqlarni tizimli ravishda yo‘q qila oldik.

Qisqacha aytganda, yondashuv — qo‘ng‘iroqlarni “zarur vaqtda va faqat zarur darajada” bajarishdir. Tez-tez ko‘riladigan umumiy ma’lumotlar davriy batch'lar orqali oldindan tayyorlandi, vaqti-vaqti bilan ko‘riladigan batafsil ma’lumotlar Lazy Loading orqali talab asosida olindi va har bir qo‘ng‘iroqdan oldin shartli tekshiruv joylashtirildi. Natijada uch qismdan iborat tuzilma shakllandi.

4-1. Tuzilmaviy taqqoslash

[1-jadval] Takomillashtirishdan oldingi va keyingi qo‘ng‘iroqlar tuzilmasi taqqoslanishi

5. Orqaga nazar: HTTP shartli so‘rovlari bilan bog‘liqlik

5-1. HTTP allaqachon ega bo‘lgan mexanizm

HTTP'da shartli so‘rov deb ataladigan standart mexanizm mavjud. Mijoz avvalgi javob bilan birga olingan o‘zgartirish vaqtini (Last-Modified) yoki versiya identifikatorini (ETag) keyingi so‘rovning If-Modified-Since yoki If-None-Match sarlavhasiga qo‘shganda, agar o‘shandan beri hech narsa o‘zgarmagan bo‘lsa, server tanasiz faqat 304 Not Modified javobini qaytaradi. G‘oya shundan iborat: “Avval biror narsa o‘zgargan-o‘zgarmaganini so‘rash, o‘zgarmagan bo‘lsa, tanani uzatmaslik.”

Bu holatdagi vaqt belgisiga asoslangan shartli qo‘ng‘iroqlar ham ayni mexanizm bilan bir xil g‘oyaga asoslangan. Avvalgi qidiruv vaqtiga asoslanib, avval o‘zgarishlarni tekshirish If-Modified-Since'ga o‘xshash vazifani bajaradi, hech narsa o‘zgarmaganida quyi darajadagi API' chaqiruvlarini o‘tkazib yuborish va saqlangan ma’lumotlardan qayta foydalanish esa 304 javobiga o‘xshash ta’sir ko‘rsatadi. Biroq avvalgi maqolada keltirilgan farqlashdagi kabi, qatlamlar turlicha, chunki bu jarayon HTTP sarlavhalari orqali protokol darajasida avtomatik boshqarilmagan; aksincha, standart API'ning Timestamp spetsifikatsiyasidan foydalanib, bevosita dastur kodida amalga oshirilgan. Bu protokol taqdim etgan mexanizmni o‘zlashtirish emas, balki ayni g‘oyani dastur darajasida mustaqil ravishda amalga oshirish misoli edi.

6. Avvalgi maqola bilan bog‘liqlik: Bir xil keshlash modelining ikki o‘qi

Qizig‘i shundaki, avvalgi maqoladagi SWR strategiyasi va ushbu maqoladagi shartli qo‘ng‘iroqlar HTTP keshlash modelida birga mavjud bo‘ladigan ikki o‘qdir. Ularning yo‘nalishlari qarama-qarshi. SWR “avval eskirgan ma’lumotlarni ko‘rsatish, keyin esa fonda tekshirish” strategiyasiga amal qilib, javob tezligini ustuvor qo‘yadi. Shartli so‘rovlar esa “avval tekshirish va hech narsa o‘zgarmagan bo‘lsa, umuman hech narsa uzatmaslik” orqali uzatish va qo‘ng‘iroqlar xarajatini kamaytirishni ustuvor qo‘yadi.

[2-jadval] Ikki keshlash strategiyasining taqqoslanishi

Amaldagi xizmatda bu ikki strategiya turli nuqtalarda birgalikda mavjud edi. Foydalanuvchilar duch keladigan ekran javoblarida SWR ga yo‘naltirilgan strategiyani, tashqi so‘rovlarda esa shartli chaqiruvlarni qo‘lladik. Yagona keshlash nazariyasi doirasida qarama-qarshi yo‘nalishda harakat qiluvchi strategiyalar “nimani saqlash kerakligi”ga qarab o‘z joylarida ishlatildi.

7. Cheklovlar va murosali tanlovlar

Ushbu tuzilmaning asosi shundan iboratki, o‘zgarishlar yuz bergan-yuz bermaganini aniqlash uchun asos sifatida ishlatiladigan Timestamp ishonchli bo‘lishi kerak. Agar tashqi muassasa o‘zgarish vaqti haqida aniq ma’lumot taqdim etmasa, o‘zgarishlar o‘tkazib yuborilishi yoki aksincha, keraksiz qayta olishlar amalga oshirilishi mumkin. Amaliy faoliyatda tashqi muassasalarning spetsifikatsiyaga muvofiqlik darajasi turlicha bo‘ldi, natijada yuzaga kelgan ma’lumotlar sifati bilan bog‘liq muammolarni alohida tarzda yumshatish talab qilindi.

Yangilanish kechikishlarining maqbul diapazoni ham doimiy muvofiqlashtirishni talab qilgan yana bir masala edi. Shartli o‘tkazib yuborishlar va davriy paketli yangilanishlar ko‘paygani sari xarajatlar kamayadi, biroq ma’lumotlarning yangiligi shunga yarasha kechikadi. Avvalgi maqoladagi keshni saqlash muddati mezonlarida bo‘lgani kabi, har bir turdagi ma’lumot uchun qancha kechikishga yo‘l qo‘yishni aniqlash individual mulohazani talab qiladigan soha bo‘ldi; barcha holatlarga mos yagona javob mavjud emas edi. Paketli yangilanishlar chastotasi ham muvozanatni talab qildi: u haddan tashqari yuqori bo‘lsa, tejamkorlik kamayib ketar, haddan tashqari past bo‘lsa, ma’lumotlarning yangiligi yomonlashardi.

8. Operatsion yo‘riqnomalarni belgilash

Avvalgi maqolada ekran tomonidagi keshni saqlash muddatlarini ma’lumot turiga ko‘ra mezonlar jadvaliga tartibga solganimiz kabi, bu safar tashqi chaqiruv strategiyalari mezonlarini ham ma’lumot turiga ko‘ra tartibga soldik. Har safar yangi ma’lumot elementi qo‘shilganda chaqiruv usulini boshidan qayta ko‘rib chiqish o‘rniga, ma’lumot xususiyatlarini mezonlarga moslashtirish orqali qaror qabul qilish imkonini yaratdik.

[3-jadval] Ma’lumot turiga ko‘ra chaqiruv strategiyalari mezonlari (misol)

Ushbu mezonlar jadvali avvalgi maqoladagi kesh bilan ishlash mezonlari jadvalini to‘ldiradi. Ekran tomoni “biz ko‘rsatadigan ma’lumot qanchalik eski bo‘lishi mumkin” mezonini, chaqiruv tomoni esa “qachon va qanday shartlarda chaqirish kerak” mezonini belgilagach, jamoa ma’lumotlarni yig‘ishdan tortib ko‘rsatishgacha bo‘lgan butun jarayon davomida bir xil tildan foydalanib qaror qabul qila oldi.

9. Xulosa

Avvalgi maqolada muhokama qilingan javob kechikishi va ushbu maqolada muhokama qilingan chaqiruv xarajatlari turli muammolardek ko‘rindi, biroq ularni hal qilganimizdan so‘ng, oxir-oqibat ikkalasi ham bir savolga kelib taqalishini aniqladik: “Ayni shu vaqtda bu chaqiruv haqiqatan ham zarurmi?” Ekran tomonida javob keshdan birinchi bo‘lib foydalanib renderlash bo‘lsa, tashqi chaqiruv tomoni uchun bu shartli chaqiruvlar va chaqiruvlarni qayta rejalashtirish edi.

Bu safar ham muammodan kelib chiqib, o‘sha paytda shartli so‘rov deb ataladigan standart mexanizm nomini bilmagan holda, bir xil tuzilmaga yetib bordik. Ushbu ikki tajriba orqali standartlar va andozalar oxir-oqibat bir xil muammolarga avval duch kelgan odamlar tomonidan tizimlashtirilgan javoblar ekanini yanada aniqroq tasdiqlay oldik.

cryss