Serverless në Shkallë: Si Funksionojnë Aplikacionet Arsimore për Arabisht në AWS Lambda
Lexim: 5 minMohammad Shaker

Serverless në Shkallë: Si Funksionojnë Aplikacionet Arsimore për Arabisht në AWS Lambda

Alphazed përdor AWS Lambda për të shërbyer 95,000+ nxënës me aplikacione edukative arabe, duke përdorur Flask, MySQL 8 dhe analitika të avancuara.

Engineering

Përgjigje e shpejtë

Alphazed përdor AWS Lambda për të shërbyer 95,000+ nxënës me aplikacione edukative arabe, duke përdorur Flask, MySQL 8 dhe analitika të avancuara.

Alphazed operon të gjithë backend-in e saj — duke shërbyer më shumë se 95,000 nxënës në më shumë se 50 vende — në AWS Lambda me Serverless Framework. Arkitektura përdor Flask në Lambda pas API Gateway, MySQL 8 në RDS, S3 për shpërndarjen e përmbajtjes, dhe një analizë të personalizuar (SQS → Kinesis Firehose → S3 → Glue → Athena). Handlerat e hollë Lambda optimizojnë vonesën nga cold-start, dhe sistemi shërben më shumë se 7 aplikacione nga një bazë kodi me konfigurim në kohë ekzekutimi.

Pse Serverless për EdTech?

Aplikacionet edukative kanë modele përdorimi të paparashikueshme:

  • Mëngjeset në ditë jave: Prindërit shkarkojnë aplikacionin para se ta dërgojnë fëmijën në shkollë (rritje trafiku)
  • Pasditet në ditë jave: Sesione praktike pas-shkollore (ngarkesë e qëndrueshme)
  • Fundjavës: Sesione intensive maratonë (2-3 herë ngarkesa normale)
  • Gjatë Ramadanit: Përdorimi në mbrëmje rritet ndjeshëm (sesione familjare të Kuranit)
  • Pushimet shkollore: Model krejt i ndryshëm

Avantazhet Serverless:

  • Pagesë për kërkesë: Paguani vetëm për përdorimin real. Nëse 10 përdorues hyjnë në API, paguani për 10 thirrje. Nëse 100,000 hyjnë në moment viral, skalohet menjëherë.
  • Zero cold start për pikë fundore me frekuencë të lartë: Përdorim shtresa Lambda "gjithmonë të ngrohtë" për pikë fundore shpesh të thirrura.
  • Auto-shkallëzim: Trajtoni 10 përdorues njëkohësisht apo 10,000 pa ndryshime infrastrukturore.
  • Zero mirëmbajtje serverësh: Ekipi fokusohet në planin mësimor dhe AI, jo në klasterë Kubernetes ose balancerë ngarkese.

Detaje të Arkitekturës

API Gateway → Lambda → RDS

[Aplikacioni Klient] (iOS, Android, Web)
    ↓
[API Gateway] (rutimi HTTP, kufizim shpejtësie)
    ↓
[Handlerat Lambda] (aplikacion Flask, 512MB memorie, 28s kufi)
  • Rrugët e aplikacionit: /app/* (pika fundore mobile)
  • Rrugët e përdoruesit: /user/* (pika autentikuese)
  • Rrugët admin: /boss/* (panel administrativ)
    ↓
[MySQL 8 në RDS] (të dhëna të qëndrueshme)
    ↓
[Përgjigje] (JSON përsëri tek klienti)

Handlerat e Hollë Lambda për Shpejtësi

Shumica e handlerave Lambda janë minimalë me qëllim:

# Handler i hollë (~100KB)
import json
import pymysql

def get_user_progress(event, context):
    user_id = event['pathParameters']['user_id']
    
    # Lidhje e drejtpërdrejtë me DB (pa overhead ORM)
    conn = pymysql.connect(host='rds.aws.com', user='app', password='...', database='amal')
    cursor = conn.cursor()
    cursor.execute(
        'SELECT concept_id, accuracy FROM user_memory WHERE user_id = %s',
        (user_id,)
    )
    rows = cursor.fetchall()
    conn.close()
    
    return {
        'statusCode': 200,
        'body': json.dumps([{'concept': r[0], 'accuracy': r[1]} for r in rows])
    }

Pa import Flask, pa SQLAlchemy ORM, pa middleware. Rezultati: ~500ms cold start krahasuar me 5-10s për aplikacionin e plotë Flask.

Endpoint-e të rëndësishme (gjenerim përmbajtjeje, përpunim analitikash) përdorin Flask të plotë:

# Handler i rëndë (~30MB me Flask, SQLAlchemy, numpy)
from flask import Flask, jsonify
from models import UserMemory
import numpy as np

app = Flask(__name__)

@app.route('/content_duo/generate', methods=['POST'])
def generate_content_duo():
    # Logjikë komplekse që kërkon ORM
    user = UserMemory.query.filter_by(user_id=request.json['user_id']).first()
    # ... gjenero sesion të personalizuar ...
    return jsonify(session_data)

Kompromis: cold start-et janë më të ngadalta, por këto përdoren më rrallë.

Parafjalët e Tabelave për Çdo Aplikacion

Një instancë RDS shërben më shumë se 7 aplikacione me izolim në nivel database:

-- Aplikacioni Amal
CREATE TABLE amal_users (...)
CREATE TABLE amal_content_bytes (...)
CREATE TABLE amal_user_memory (...)

-- Aplikacioni Thurayya
CREATE TABLE thurayya_users (...)
CREATE TABLE thurayya_content_bytes (...)
CREATE TABLE thurayya_user_memory (...)

-- Aplikacionet e tjera: qais_*, kidelite_*, etj.

Gjatë deploy, variabla mjedisore APP_NAME zgjedh parafjalën:

app_name = os.getenv('APP_NAME', 'amal')  # 'amal', 'thurayya', 'qais', etj.

# Kërkesat përdorin dinamish parafjalën
table_name = f'{app_name}_users'
cursor.execute(f'SELECT * FROM {table_name} WHERE id = %s', (user_id,))

Liqeni i Analitikës

Problem: Pyetjet direkte në bazën e të dhënave për analitika ngadalësojnë prodhimin. Raportet bllokojnë tabelat.

Zgjidhja: Vepër analitike asinkrone

[Aplikacioni Mobile]
    ↓ (dërgon event)
[API Endpoint] → [Rruga SQS] (asinkrone)
    ↓ (përgjigjet menjëherë klientit)
    ↓ (nuk pret analitikën)
[Kinesis Firehose] (grumbullon event-e çdo 5 minuta ose 100MB)
    ↓
[S3] (ndarë sipas direktorieve: s3://analytics-lake/amal/2026/03/28/events.parquet)
    ↓
[AWS Glue] (exploron S3, nxjerr skemën)
    ↓
[Athena] (pyetje SQL përmes Presto)
    ↓
[Panel Kontrolli] (shfaq të dhëna në kohë reale)

Pattern-i i Dead Letter Queue (DLQ)

Nëse analitika dështon:
SQS → [Firehose dështon]
  ↓
  [DLQ merr mesazhet e dështuara]
  ↓
  [Alert dërgohet te ops]
  ↓
  [API i prodhimit nuk ndikohet]

Analitika kurrë nuk bllokon kërkesat e përdoruesve. Fëmijët mund të mësojnë edhe nëse pipeline analitike nuk funksionon.

Strategjitë për Optimizim të Kostove

  • Handlera të hollë për endpoint-at me frekuencë të lartë: Aplikacioni mesatar bën 10-20 thirrje API për sesion; 95,000 përdorues aktivë × 3 sesione/ditë × 15 thirrje = 4.275 milionë thirrje në ditë. Çmimi për thirrje (~0.0000002$) jep rreth 0.86$ në ditë. Kursimi i vonesës cold start me 10s kursen rreth 500$ në muaj.
  • Instanca të rezervuara RDS: Rezervim 3-vjeçar me ulje 60% kundrejt përdorimit të menjëhershëm. Përdorim db.r6i.xlarge: 2800$/muaj i rezervuar vs 6500$/muaj on-demand. Kursim vjetor: rreth 50,000$.
  • Caching: Të dhëna të shpeshta (curriculum, byte përmbajtjeje) ruhen në ElastiCache (Redis). Ul pyetjet në RDS me 70%. Kosto: 800$/muaj, kursim në RDS: 2000$/muaj.

Shërbimi i 7+ Aplikacioneve nga Një Bazë Kodi

AplikacioniPrefiksiTabelat DBStack LambdaStatusi
Amalamal_40+ tabelaI përbashkëtProduksion
Thurayyathurayya_40+ tabelaI përbashkëtProduksion
Qaisqais_35+ tabelaI përbashkëtBeta
KidElitekidelite_40+ tabelaI përbashkëtProduksion
Alphazed Schoolschool_50+ tabelaI përbashkëtBeta
Alphazed Montessorimontessori_45+ tabelaI përbashkëtIntern

Një backend, një pipeline deploy-i, 6 aplikacione aktive. Lansim i aplikacionit të ri brenda javësh, jo muajsh.

Pyetje të Shpeshta (FAQ)

Q: A ka Lambda kufi prej 15 minutash për ekzekutim?
A: Lambda ka maksimum 15 minuta timeout, por ne rrallë kemi nevojë për ekzekutime të gjata. Punët e rënda (gjenerim përmbajtjeje, eksportet e mëdha) bëhen me pune asinkrone me SQS + Step Functions.

Q: Çfarë ndodh nëse baza e të dhënave bie?
A: RDS ka failover Multi-AZ (kopje kryesore + rezervë). Failover është automatike dhe zgjat rreth 60 sekonda. Klientët përjetojnë vonesa të shkurtra, por rikuperimi është i shpejtë.

Q: Si menaxhohet pool-i i lidhjeve me bazën e të dhënave në Lambda stateless?
A: Secila instancë Lambda ruan pool lidhjesh (ri-përdoret gjatë thirrjeve të ngrohta). Cold start merr lidhje të reja. RDS Proxy është ndërmjet Lambda dhe RDS për menaxhimin e limiteve të lidhjeve.

Artikuj të Ngjashëm