Serve assetlinks su edge/Rails, documenta overflow Hetzner e bumpa l'AAB a 28 con simboli nativi per Play.
Co-authored-by: Cursor <cursoragent@cursor.com>
**Contesto:** produzione attuale su host dedicato (es. Proxmox/Hetzner) con MediaMTX + Sidekiq sullo stesso box; obiettivo >10 live YouTube contemporanee senza abbandonare il middle-tier.
Se cade solo il tratto telefono→MediaMTX, YouTube resta in onda (slate).
Se il telefono andasse diretto a YouTube (o a un ingest cloud senza hold), la live pubblica cadrebbe con la rete mobile. Inoltre YouTube non è pensato come “Go Live dall’app mobile” senza vincoli di canale: noi usiamo API + RTMPS dal server.
### Problema di capacità
Ogni diretta `platform=youtube` avvia un processo `ffmpeg` in Sidekiq (`Streams::YoutubeRelay`: video **copy**, audio **AAC**).
Il carico scala con **N processi**, non con gli spettatori HLS.
Sul box attuale (~4 CPU / 8 GB, stack completo sullo stesso host):
**Obiettivo:** mantenere MediaMTX (e Rails) sul dedicated; quando N supera la soglia comoda, **accendere capacità Hetzner Cloud solo per i relay**, per il tempo del picco, poi spegnerla.
### Cosa NON è questo piano
- Non sostituisce MediaMTX con Mux/AWS MediaLive.
- Non sposta l’ingest RTMP del telefono sul cloud (cold start e sticky URL sono incompatibili con “zero nodi a riposo”).
- Non è autoscaling del monolite Docker Compose intero.
---
## 2. Principio di progettazione
| Componente | Dove resta | Perché |
|------------|------------|--------|
| MediaMTX (RTMP ingest + slate + HLS) | **Dedicated sempre acceso** | URL stabile per l’app; continuità YouTube via slate |
| Rails / Postgres / Redis / Garage / edge | **Dedicated** (o gestiti fissi) | Stato, auth, replay; non sono il collo di bottiglia video live |
| `YoutubeRelay` (ffmpeg) | **Dedicated fino a soglia + overflow Cloud** | Unico pezzo che moltiplica CPU con N live YT |
| Job Sidekiq non-video (mail, ops, post-process) | Dedicated (coda separata) | Non devono competere con ffmpeg sui worker overflow |
intake RTMP/HLS │ (rete privata / tunnel / IP allowlist)
│
┌───────────────┼───────────────┐
▼ ▼ ▼
[relay-local] [overflow-1] [overflow-N]
Sidekiq+ffmpeg Hetzner Cloud Hetzner Cloud
YOUTUBE_RELAY=1 a ore a ore
│ │ │
└───────────────┴───────────────┘
│
▼
YouTube RTMPS
```
### Ruolo delle VM overflow
Immagine minimale (o Compose snello):
- Sidekiq con `YOUTUBE_RELAY_WORKER=1`
-`ffmpeg` disponibile
- Connessione a **Redis** del dedicated (coda + lock `youtube_relay:owner:*`)
- Lettura intake da MediaMTX (RTMP preferito, HLS fallback come oggi)
- **Niente** Postgres scrittura diretta obbligatoria se i job relay usano già Redis + API; in pratica oggi Rails/Sidekiq legge Postgres → le VM overflow devono raggiungere anche DB **oppure** si isola una coda “relay-only” con worker che riceve payload già risolto (vedi §5.2)
Stato attuale del codice: `YoutubeRelay` gira in processo Sidekiq Rails completo (accesso a `StreamSession`, MediaMTX client, Redis PID/owner). Le VM overflow sono quindi **worker Sidekiq Rails**, non demoni ffmpeg nudi — almeno nella fase 1.
---
## 4. Colli di bottiglia (cosa può rompersi comunque)
Anche con overflow infinito di CPU, restano limiti. Ordine di probabilità/impatto:
### 4.1 MediaMTX sul dedicated (alto)
- N publisher RTMP + N reader (HLS siti + N ffmpeg che rileggono lo stesso path).
- Ogni relay in più è un **reader** su MediaMTX (RTMP pull o HLS).
- Sintomi: path `ready` flaky, HLS a scatti sul sito, relay che rientrano in fallback HLS, CPU MediaMTX alta anche con relay scarichi.
**Mitigazione futura (fuori da questo overflow):** secondo nodo MediaMTX o sharding path; per ora monitorare `readers`, CPU `mediamtx`, bitrate aggregato.
### 4.2 Uplink Internet del dedicated (alto)
- Telefoni → dedicated (ingresso RTMP).
- Dedicated → YouTube **se** i relay restano locali.
- Con overflow Cloud: il dedicated manda **copia dello stream** verso le VM (pull dalle VM = traffico **uscita** dal dedicated verso Hetzner Cloud), poi le VM mandano a YouTube.
Attenzione al verso:
| Dove gira il relay | Traffico tipico |
|--------------------|-----------------|
| Sul dedicated | In: telefoni. Out: N× verso YouTube |
| Su Hetzner Cloud | Out dedicated → Cloud (intake). Out Cloud → YouTube |
Se l’uplink casa/datacenter verso Internet è stretto, spostare i relay sul Cloud **sposta** il carico out YouTube fuori dal dedicated, ma **aggiunge** out dedicated→Cloud (stesso ordine di grandezza del video).
Vantaggio reale solo se:
- l’uplink del dedicated satura soprattutto per **CPU** (oggi sì), oppure
- dedicated e Cloud sono in **stessa regione Hetzner con rete privata** (traffico interno economico/veloce) e l’uscita verso YouTube esce dalla rete Hetzner Cloud (migliore peering).
**Decisione di rete obbligatoria prima di implementare** (vedi §6).
### 4.3 Redis / lock owner (medio)
Oggi:
-`youtube_relay:pid:%s` — PID locale al worker
-`youtube_relay:owner:%s` — `HOSTNAME` del worker
-`running?` considera attivo un owner remoto se TTL > 30s
Con più worker:
- Due ensure concorrenti possono avviare due ffmpeg (debounce 5s aiuta poco cross-host).
-`stop` da Rails manda job: deve raggiungere il worker **owner**, non un overflow a caso.
- Kill del PID funziona solo sulla macchina owner (`/proc`).
Serve disciplina di coda / routing (§5.3).
### 4.4 Cold start VM (medio)
Creare una CPX/CCX Hetzner: ordine di **30–90+ secondi** (API + boot + pull image + Sidekiq ready).
Se la 15ª live parte e non c’è capacità, la broadcast YouTube resta “in attesa” finché non c’è worker.
**Requisito prodotto:** overflow **a caldo** = pool minimo già acceso nei weekend / fasce note, non “da zero al fischio”.
- Limiti API, token OAuth, ban temporanei, ingest RTMPS rifiutato.
- Non risolvibili con più CPU; restano nel runbook ops esistente.
### 4.6 Post-process replay (basso in live, alto a fine giornata)
`UploadFromSession` / thumbnail competono su Sidekiq e disco.
I worker overflow **non** devono prendere coda `default` di merge se sono pensati solo per relay — altrimenti spegnendo le VM a fine picco uccidete job a metà.
### 4.7 Costo e idle (operativo)
VM dimenticate accese = bolletta. Serve TTL, scale-in aggressivo, alert “overflow acceso da >Xh con 0 relay”.
---
## 5. Complessità di implementazione
### 5.1 Rete: come le VM leggono MediaMTX
Opzioni (sceglierne **una** in fase 0):
| Opzione | Pro | Contro |
|---------|-----|--------|
| **A. Stessa location Hetzner + private network** (dedicated Robot + Cloud nella stessa rete) | Bassa latenza, traffico interno, modello pulito | Richiede che il dedicated sia (o diventi) in ecosistema Hetzner collegabile |
| **B. WireGuard/Tailscale** dedicated ↔ Cloud | Funziona anche da Proxmox casa | Ops tunnel, MTU, failover; latenza |
| **C. Esporre RTMP/HLS intake in lettura** (IP allowlist VM overflow) | Semplice | Superficie attacco; non esporre senza auth/TLS dove possibile |
| **D. Relay locale che pusha a Cloud** | Dedicated controlla egress | Doppia hop, più pezzi |
Raccomandazione di piano: **A se il dedicated è/andrà su Hetzner; altrimenti B**. Evitare C in chiaro su WAN.
Variabili da prevedere sulle VM:
-`MEDIAMTX_INTERNAL_RTMP_URL` → URL raggiungibile dalle VM (non `rtmp://mediamtx:1935` Docker-locale)
-`MEDIAMTX_HLS_URL` → idem
- MediaMTX API (`:9997`) raggiungibile in privato per `intake_available?` / PublisherOnline, **mai** su Internet aperto
### 5.2 Accesso Postgres e segreti
Worker Sidekiq Rails oggi necessitano:
-`DATABASE_URL` (o replica read + job che non scrivono — irrealistico all’inizio)
-`REDIS_URL`
-`SECRET_KEY_BASE` / credenziali YouTube via DB
- stessi env di produzione (ridotti)
Complessità: ogni overflow è un **nodo fidato** della rete app.
Immagine Docker identica a `sidekiq` prod, env da secret manager o file scp/cloud-init, **nessuna** porta Rails pubblica sulle VM.
### 5.3 Code Sidekiq e affinità relay
Stato oggi: ensure/stop via job + processo locale con owner in Redis.
Per multi-host serve esplicitare:
1.**Coda dedicata**`youtube_relay` (solo worker con `YOUTUBE_RELAY_WORKER=1`).
2.**Cap locale**: ogni worker ha `RELAY_MAX_CONCURRENT` (es. cores−1).
3.**Scheduling**:
- Fase 1 (manuale): overflow sempre in ascolto sulla coda; Sidekiq distribuisce i job; `ensure_on_worker!` no-op se a cap (re-enqueue o lascia ad altro worker).
- Fase 2: controller di capacità che alza/abbassa N VM in base a `relay_attivi` e profondità coda.
4.**Stop**: job `YoutubeRelayStopJob` deve eseguire **solo sull’owner** (Sidekiq unique + check `owner == HOSTNAME`, altrimenti requeue con delay breve).
Nota: i PID in Redis non sono globalmente killabili — il modello owner è già abbozzato; va reso robusto cross-host.
| ≤6 | Tutto locale | 0 | Situazione attuale “comoda” se box dedicato ai relay |
| 10–15 | soft cap 4–6 | 1× VM 4–8 vCPU | Warm consigliato in giornata evento |
| 20–30 | soft cap 4–6 | 2–4× VM | MediaMTX e uplink diventano critici |
| 50+ | softire anche ingest | N VM + 2° MediaMTX | Fuori scope overflow-only |
Questi numeri vanno **calibati** con un load test (N sessioni fake + ffmpeg contro slate MediaMTX) prima di promettere SLA commerciali.
---
## 8. Piano a fasi (pronti a reagire, non a over-build)
### Fase 0 — Misura e soglie (1–2 giorni ops)
- [ ] Dashboard/manuale: N live YT, CPU `sidekiq`, CPU `mediamtx`, uplink
- [ ] Definire `RELAY_SOFT_CAP` empirico sul dedicated
- [ ] Chiudere **D1** (rete)
- [ ] Load test controllato: 8–12 relay solo slate (senza telefoni) per vedere dove rompe
**Criterio go/no-go overflow:** saturazione CPU Sidekiq/ffmpeg **prima** di MediaMTX/uplink. Se saturano prima rete o MediaMTX, overflow Cloud non basta.
### Fase 1 — Overflow manuale “a caldo” (MVP ops)
- [ ] Snapshot/immagine Sidekiq relay-ready su Hetzner Cloud
- [ ] cloud-init: env, WireGuard o private net, `docker compose up sidekiq`
- [ ] Soft cap sul dedicated: nuovi ensure preferiscono coda se locali pieni (anche patch minima)
- [ ] Alert se VM overflow up da >3h con 0 owner keys
**Reazione a incident:** operatore umano accende/spegne; nessun autoscaler ancora.
### Fase 2 — Routing coda robusto
- [ ] Coda `youtube_relay` isolata
- [ ] Heartbeat owner Redis
- [ ] Stop/ensure sticky all’owner
- [ ] Cap per worker + requeue
### Fase 3 — Autoscaling controllato
- [ ] Job/cron: se saturazione → `hcloud server create` fino a `OVERFLOW_MAX`
- [ ] Scale-in solo se idle e fuori warm window
- [ ] Budget mensile + kill switch
### Fase 4 — Solo se necessario
- Secondo MediaMTX / sharding
- Audio copy se l’encoder telefono è già YouTube-compatibile (meno CPU)
- Dedicated più grosso come baseline (spesso più economico dell’overflow cronico ogni weekend)
---
## 9. Runbook di reazione (anche prima dell’autoscaler)
### Sintomo: YouTube “in programma” / niente video con molte live
1.`docker stats` / CPU Sidekiq sul dedicated
2. Contare relay: log `[YoutubeRelay] started` vs sessioni `platform=youtube` live
3. Se CPU ~100% e MediaMTX ok → **accendere overflow** (Fase 1) o abbassare nuove live YT
4. Se MediaMTX alto / path non ready → overflow **non** aiuta; ridurre reader o spostare HLS, non aggiungere pull Cloud ciechi
### Sintomo: live YT che si spezza solo sulle VM Cloud
1. RTT e packet loss dedicated↔VM
2. Verificare che intake usi RTMP interno, non HLS pubblico via Internet
3. Controllare doppio owner / due ffmpeg sulla stessa key
### Sintomo: bolletta Cloud anomala
1. Lista server con label `matchlivetv-overflow`
2. Destroy idle
3. Abbassare warm pool
### Sintomo: job replay morti dopo scale-in
1. Verificare che overflow **non** consumi coda `default` / `recordings`
2. Riprocessare dead set Sidekiq
---
## 10. Criteri di successo
| Criterio | Misura |
|----------|--------|
| Picco gestito | ≥15 live YT contemporanee stabili in test |
| Continuità prodotto | Drop telefono → slate YouTube ancora attiva (invariato) |
| Costo | Overflow acceso solo in finestre picco; €/h documentato |
| Ops | Runbook Fase 1 eseguibile in <10 min da operatore |
| Non regressione | Live solo-sito (`matchlivetv`) e replay invariati |
---
## 11. Riepilogo esecutivo
Il pezzo che manca oltre ~10 live YouTube è **CPU dei relay**, non l’idea MediaMTX.
Hetzner Cloud è la leva economica giusta se:
1. scalate **solo** i worker `YoutubeRelay`,
2. tenete MediaMTX caldo sul dedicated,
3. risolvete **rete privata** dedicated↔Cloud,
4. partite da **warm pool + runbook manuale**, poi automate.
Il rischio principale non è “creare una VM”, è **leggere N volte MediaMTX e saturare uplink/MediaMTX** mentre pensate di aver risolto solo la CPU. La Fase 0 (misura) decide se l’overflow è sufficiente o se serve anche più ingest/baseline hardware.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Cursor