42 lines
2.6 KiB
Markdown
42 lines
2.6 KiB
Markdown
# mockupAWS - Backend Profiler & Cost Estimator
|
|
|
|
## Obiettivo del Progetto
|
|
`mockupAWS` è un ambiente di simulazione locale (homelab) progettato per replicare i layer di ingestion ed elaborazione cloud del progetto LogWhispererAI.
|
|
|
|
Lo scopo principale non è analizzare i log, ma **profilare il traffico e calcolare i driver di costo** dei servizi AWS (SQS, Lambda, Bedrock/LLM) prima del deploy in produzione. Inviando log tramite Logstash a questo mockup, è possibile ottenere una stima precisa della fatturazione basata su traffico simulato o reale.
|
|
|
|
## Architettura e Metriche Misurate
|
|
Il mockup espone endpoint che simulano il comportamento dei servizi AWS, raccogliendo metriche essenziali:
|
|
|
|
* **Simulazione Ingestion (Amazon SQS / API Gateway):**
|
|
* Misurazione delle richieste HTTP al secondo (RPS).
|
|
* Calcolo della dimensione media dei payload (monitorando i blocchi di fatturazione da 64KB).
|
|
* *Principio applicato: Safety First* - Validazione dell'integrità del payload in ingresso e verifica dell'avvenuta sanitizzazione dei dati (assenza di PII/Secreti).
|
|
|
|
* **Simulazione Compute (AWS Lambda):**
|
|
* Profilazione dell'efficacia del batching e della deduplicazione.
|
|
* *Principio applicato: Little Often* - Test del processamento a piccoli batch per simulare la lettura ottimizzata dalle code.
|
|
|
|
* **Simulazione LLM (Amazon Bedrock):**
|
|
* Conteggio esatto dei token in ingresso (Input Tokens) tramite tokenizer (es. `tiktoken`).
|
|
* *Principio applicato: Double Check* - Validazione finale del prompt generato prima del calcolo dei costi simulati.
|
|
|
|
## Requisiti
|
|
* Docker / Docker Compose
|
|
* Node.js (v20+) o Python (3.11+) [A seconda dello stack scelto per lo script]
|
|
* Logstash (configurato per puntare agli endpoint esposti da questo mockup)
|
|
|
|
## Flusso di Sviluppo (Spec-Driven & TDD)
|
|
Questo repository adotta un approccio rigoroso allo sviluppo:
|
|
|
|
1. **Spec-Driven**: Nessuna implementazione senza prima aver definito le specifiche di input/output.
|
|
2. **Test-Driven Development (TDD)**: I test per il calcolo delle metriche e la validazione dei payload (es. conteggio token, validazione limiti SQS) devono essere scritti *prima* della logica di routing.
|
|
3. **Gestione del Codice**:
|
|
* Flusso Git basato su **Conventional Commits** (`feat:`, `fix:`, `chore:`, `test:`).
|
|
* Commit atomici e mirati.
|
|
* Compilazione del file `CHANGELOG.md` aderente allo standard **Common Changelog**.
|
|
4. **Pull Requests**: Le PR devono includere l'esito dei test e la descrizione chiara del driver di costo AWS che si sta andando a simulare o correggere.
|
|
|
|
## Come avviare la simulazione
|
|
*(Da completare una volta definito lo stack esatto e i comandi di avvio, es. `docker-compose up --build`)*
|