Clústeres: la implementación de referencia, el descubrimiento y la vigilancia

Con el protocolo del sistema en la mano, la pregunta pasa a ser práctica: quién ha escrito ya uno serio. La respuesta es swift-distributed-actors, el paquete de Apple que aporta ClusterSystem, un transporte sobre TCP y, sobre todo, las tres piezas que ningún transporte trae de fábrica y que todo despliegue real necesita: saber quiénes forman el grupo en cada momento, encontrar a un actor cuya identidad no conocías de antemano y enterarte de que alguien ha dejado de existir. Ese trío —membresía, descubrimiento y vigilancia— es lo que separa un canal de mensajes de un sistema distribuido, y merece estudiarse aunque nunca despliegues un clúster, porque son los mismos problemas que aparecen entre dos procesos de un mismo portátil.

Unirse al grupo y ser considerado vivo

Un nodo es un proceso con un ClusterSystem escuchando en un puerto. Formar clúster consiste en decirle a uno la dirección de otro; a partir de ahí la información se propaga sola.

import DistributedCluster

let sistema = await ClusterSystem("nodoA") { ajustes in
    ajustes.endpoint = Cluster.Endpoint(host: "127.0.0.1", port: 7337)
}

sistema.cluster.join(endpoint: Cluster.Endpoint(host: "127.0.0.1", port: 7338))
try await sistema.cluster.joined(endpoint: semilla, within: .seconds(10))

La propagación usa gossip: cada nodo comparte periódicamente con unos pocos vecinos lo que cree saber sobre todos, y esa creencia converge sin ningún coordinador central. Sobre ese sustrato corre SWIM, un detector de fallos que combina sondeo directo con sondeo indirecto a través de terceros, precisamente para no declarar muerto a quien solo era inalcanzable desde un vecino concreto.

stateDiagram-v2
[*] --> joining
joining --> up: aceptado por el grupo
up --> leaving: salida ordenada
leaving --> down: retirada confirmada
up --> down: declarado inalcanzable
down --> removed: expulsado del clan
removed --> [*]

Los estados no son decorativos: definen a quién se le envía y a quién no. Un nodo up recibe tráfico; uno down queda excluido y no puede volver, tiene que reiniciarse con una identidad nueva. Esa regla es dura a propósito, porque readmitir a un nodo que estuvo aislado significaría admitir su estado, que puede haber divergido.

La membresía no es un dato que se consulta, es un flujo que se observa. El sistema publica los cambios como secuencia asíncrona, con lo que la reacción a la topología se escribe con las mismas herramientas del nivel anterior.

for await evento in sistema.cluster.events {
    switch evento {
    case .membershipChange(let cambio) where cambio.status == .up:
        await repartidor.incorporar(nodo: cambio.member)
    case .membershipChange(let cambio) where cambio.status == .down:
        await repartidor.retirar(nodo: cambio.member)
    default:
        break
    }
}

Los tiempos que gobiernan ese flujo son parámetros, no constantes del universo, y elegirlos es una decisión de producto: un plazo de sospecha corto detecta caídas antes y produce más falsos positivos; uno largo es estable y deja peticiones colgando más tiempo. En una red local con latencias de microsegundos y en un despliegue entre regiones las cifras razonables difieren en un orden de magnitud.

Encontrar sin conocer la identidad

resolve sirve cuando ya tienes una identidad. El problema real es el anterior: quieres hablar con «algún operario disponible» y no sabes ni cuántos hay ni en qué nodo viven. Para eso está el recepcionista, un registro replicado por el clúster con claves tipadas.

extension DistributedReception.Key {
    static var operarios: DistributedReception.Key<Operario> { "operarios" }
}

// En el nodo que lo aloja
let operario = Operario(actorSystem: sistema)
await sistema.receptionist.checkIn(operario, with: .operarios)

// En cualquier otro nodo
for await op in await sistema.receptionist.listing(of: .operarios) {
    await balanceador.registrar(op)
}

Dos rasgos hacen que esto sea más que un directorio. La clave está tipada, de modo que la búsqueda devuelve referencias del tipo correcto sin conversiones ni cadenas mágicas. Y el resultado es una secuencia asíncrona, no una consulta puntual: el listado sigue emitiendo a medida que aparecen nuevos actores y a medida que otros se retiran, lo que convierte el descubrimiento en un flujo que tu código puede consumir con las mismas herramientas del nivel anterior.

Vigilar la desaparición

Aquí conviene ser preciso, porque el vocabulario de Erlang y de Akka genera expectativas que Swift no cumple. swift-distributed-actors no trae árboles de supervisión con políticas de reinicio automático heredadas por los hijos. Lo que trae es el ingrediente sobre el que aquello se construye: la notificación fiable de terminación.

distributed actor Coordinador: LifecycleWatch {
    typealias ActorSystem = ClusterSystem
    private var activos: Set<Operario> = []

    distributed func incorporar(_ op: Operario) {
        watchTermination(of: op)
        activos.insert(op)
    }

    func terminated(actor id: ActorSystem.ActorID) async {
        activos = activos.filter { $0.id != id }
        await reponerCapacidad()
    }
}

watchTermination(of:) funciona tanto si el actor vigilado muere en tu proceso como si desaparece con su nodo entero, y esa uniformidad es la que hace que la política de recuperación se escriba una sola vez. El contrato incluye un detalle que rara vez se subraya: si el actor ya había terminado cuando lo vigilas, la notificación llega igualmente. Sin esa garantía existiría una carrera que dejaría al vigilante esperando para siempre.

Con esa pieza, la supervisión se escribe a mano y en Swift ordinario: al recibir terminated, decides si reponer, si degradar el servicio, si propagar el fallo hacia arriba o si abrir un cortacircuitos. La ventaja de no tener un marco de políticas es que la decisión queda donde está el conocimiento del dominio; la desventaja es que hay que tomarla siempre, y omitirla produce sistemas que se vacían en silencio.

Merece la pena distinguir dos preguntas que la notificación deja abiertas. La primera es qué se hace con el actor: reponerlo en otro nodo suele ser fácil, porque basta con crear uno nuevo y registrarlo. La segunda es qué se hace con su estado, y ahí no hay atajo: si el actor tenía información que solo vivía en su memoria, esa información se ha perdido, y la única salida es haberla persistido antes o poder reconstruirla desde otra fuente. La reposición ciega de actores con estado volátil produce un sistema que parece sano y sirve datos incompletos.

// Reponer no es restaurar: el estado hay que traerlo de algun sitio
func terminated(actor id: ActorSystem.ActorID) async {
    activos = activos.filter { $0.id != id }
    guard let ultima = try? await instantaneas.ultima(de: id) else {
        await alertar(.estadoPerdido(id))
        return
    }
    let sustituto = Operario(actorSystem: actorSystem, restaurando: ultima)
    await actorSystem.receptionist.checkIn(sustituto, with: .operarios)
    watchTermination(of: sustituto)
    activos.insert(sustituto)
}