Yuqori yuklamali IoT platformalar arxitekturasi

14:12 da 200, 14:13 da 20 000: nima uchun IoT yuklamasi keskin o‘sadi

Yuqori yuklamali IoT platformalar veb-saytlar kabi xulq tutmaydi. Veb-loyihada trafik odatda bosqichma-bosqich, marketing kampaniyasi yoki SEO o‘sishi bilan birga ko‘tariladi — sizda reaksiya qilishga vaqt bo‘ladi. IoT esa boshqacha: yuklama qurilmalar sonidan emas, balki hodisalar (event) zichligidan kelib chiqadi. Bitta dispetcherlik buyrug‘i, bitta firmware yangilanishi yoki bitta tarmoq uzilishidan keyingi qayta ulanish to‘lqini sekundlik yuklamani 100 barobarga oshirib yuborishi mumkin.

Misol oddiy: 14:12 da tizim sekundiga 200 ta eventni bemalol qayta ishlaydi, dashboard yashil, hamma narsa tinch. 14:13 da bazaviy stansiya qayta ishga tushadi va unga ulangan 20 000 ta hisoblagich bir vaqtning o‘zida o‘z holatini yuborishni boshlaydi. Sekundiga 200 emas, 20 000 event. Aynan shu daqiqada arxitektura haqidagi barcha qarorlar — to‘g‘ri yoki noto‘g‘ri — o‘zini ko‘rsatadi. Tayyor bo‘lmagan tizim shu yerda ag‘darilib tushadi.

Ikki xil yakun: nega bir xil yuklamadagi platformalar har xil tugaydi

Keskin yuklama oldida har qanday IoT platforma ikki yo‘ldan biriga tushadi. Birinchi yo‘l — nazoratli sekinlashish: tizim navbat to‘lganini sezadi, ortiqcha eventlarni buferga oladi, kerak bo‘lsa ikkilamchi ma’lumotlarni vaqtincha tashlaydi, lekin ishlashda davom etadi va to‘lqin o‘tgach o‘zini tiklaydi. Ikkinchi yo‘l — kaskadli qulash: bitta komponent (odatda baza yoki sinxron API) tiqilib qoladi, undan keyin barcha bog‘liq xizmatlar timeout’ga uchraydi, qurilmalar javob olmay yana qayta urinadi va yuklamani yana oshiradi. Bu o‘z-o‘zini kuchaytiruvchi halqa — “retry storm”.

Farq qaysidir bitta texnologiyada emas. Farq — loyiha boshida yuklama xulqi to‘g‘ri modellashtirilganmi va tizim “to‘lib ketgan” holatga rejalashtirilgan reaksiyaga egami yo‘qmi. Aynan shuning uchun arxitekturani keyin “tuzatib bo‘lmaydi” — uni boshidanoq keskin o‘sishga mo‘ljallab qurish kerak.

Ingestion qatlami: birinchi va eng muhim chegara

IoT platformaning eng zaif nuqtasi — ma’lumot qabul qiluvchi kirish qatlami (ingestion). Agar qurilmalar to‘g‘ridan-to‘g‘ri biznes-mantiqqa yoki bazaga yozadigan bo‘lsa, har qanday tik o‘sish darhol bazaga uriladi. To‘g‘ri yondashuv — qabulni qayta ishlashdan ajratish.

• Protokol tanlash. Minglab kam quvvatli qurilmalar uchun MQTT yoki CoAP HTTP’dan tejamliroq: doimiy ulanish, kichik sarlavhalar, QoS darajalari. HTTP esa kamdan-kam, yirik paketlar yuboradigan stsenariylarga mos.
• Bufer/broker. Kirish va qayta ishlash o‘rtasiga Kafka, NATS yoki shunga o‘xshash log/queue qo‘yiladi. Bu “amortizator” vazifasini bajaradi: 20 000 event/sek kelganda ham qabul davom etadi, qayta ishlash esa o‘z tezligida navbatdan o‘qiydi.
• Backpressure. Tizim navbat to‘lganini sezishi va manbaga “sekinroq” signal berishi yoki ortiqchani ataylab tashlashi kerak — nazoratsiz cheksiz buferlanish xotirani yeb, baribir qulashga olib keladi.

Ma’lumotlar bazasi: yozuv yuklamasi va vaqt qatorlari

IoT’da yozuv (write) o‘qishdan ko‘p marta ko‘p bo‘ladi va u doimo oqim ko‘rinishida keladi. Klassik relyatsion baza har bir eventni alohida INSERT qilganda tez tiqiladi. Yechimlar: eventlarni batch ko‘rinishida yozish, vaqt qatorlari uchun maxsus bazalardan (TimescaleDB, ClickHouse, InfluxDB) foydalanish va ma’lumotni vaqt bo‘yicha bo‘laklarga ajratish (partitioning).

Bundan tashqari, “issiq” va “sovuq” ma’lumotni ajratish kerak: oxirgi soatlardagi tezkor ma’lumot operativ bazada, eski ma’lumot arzon arxivda saqlanadi. Aks holda baza vaqt o‘tib o‘smay, balki shishib boradi va so‘rovlar sekinlashadi.

Gorizontal kengayish va stateless dizayn

Yuqori yuklamada bitta kuchli serverni yana kuchaytirish (vertical scaling) tez chegaraga uriladi. To‘g‘ri yo‘l — gorizontal kengayish: yuklama oshganda yangi ishlovchi nusxalarini avtomatik qo‘shish. Buning sharti — xizmatlar stateless bo‘lishi, ya’ni holatni o‘zida saqlamasligi. Sessiya yoki holat tashqi xotirada (Redis kabi) saqlansa, istalgan nusxa istalgan eventni qayta ishlay oladi va Kubernetes/autoscaler yuklamaga qarab nusxalar sonini erkin o‘zgartiradi.

Shu o‘rinda kuzatuvchanlik (observability) ham arxitekturaning bir qismi: metrikalar (sekundlik event, navbat uzunligi, latency), markazlashgan loglar va tracing bo‘lmasa, 14:13 da nima uchun tizim qulaganini hech qachon bilib bo‘lmaydi.

Tez-tez uchraydigan xatolar

O‘zbekiston konteksti: biznes va davlat sektori uchun amaliy maslahatlar

O‘zbekistonda IoT — bu raqamli hisoblagichlar (suv, gaz, elektr), aqlli shahar sensorlari, logistika va transport telematikasi, qishloq xo‘jaligi monitoringi. Bu loyihalarda bir nechta mahalliy omilni hisobga olish kerak: tarmoq sifati hududlarga qarab har xil, shuning uchun qurilma offline holatda ma’lumotni saqlab, ulanish tiklangach yuborishi (store-and-forward) muhim. Aynan shu tiklanish daqiqasi yuqorida aytilgan keskin to‘lqinni keltirib chiqaradi.

Davlat sektori loyihalarida ma’lumot suvereniteti va xavfsizlik talablari ham arxitekturaga ta’sir qiladi: ma’lumotni mahalliy data-markazlarda saqlash, har bir qurilmani autentifikatsiya qilish (TLS, qurilma sertifikatlari) va kirish qatlamini DDoS’dan himoyalash. Yuqori yuklama nafaqat haqiqiy qurilmalardan, balki buzilgan yoki soxta qurilmalardan ham kelishi mumkin.