Escalando
Horizon permite diferentes niveles lógicos que pueden escalarse independientemente para aumentar el rendimiento, la separación y la disponibilidad. Los siguientes componentes pueden escalarse de forma independiente:
- API de servicio web (sirviendo)
- Núcleo cautivo (ingestión y envío de transacciones)
- Base de datos (almacenamiento)
Despliegue de una sola instancia
Se recomienda comenzar con un despliegue de una sola instancia, y escalar según las necesidades de tu caso de uso particular.
Este despliegue está destinado a usarse con retención mínima de historial (<= 30 días) y volumen mínimo de solicitudes.
En esta configuración, una sola instancia de Horizon realiza los tres roles; ingestión, envío de transacciones y solicitudes de API de usuario final.
Escalando a múltiples instancias
Hay varias razones por las que puedes optar por escalar a múltiples instancias de Horizon.
- El escalado horizontal te permite atender más solicitudes de API y a un ritmo más rápido
- La redundancia permite cero tiempo de inactividad en los casos donde Horizon requiere tiempo de inactividad para la actualización (migraciones, reconstrucción de estado, etc.)
- Protección contra posibles retrasos en la ingestión, que podrían resultar en tiempo de inactividad para los usuarios finales
Se pueden configurar múltiples instancias de Horizon para apuntar a la misma base de datos, y el proceso de ingestión no realizará trabajo redundante en estos casos.
Al escalar Horizon, es importante tener en cuenta que se debe deshabilitar el control de tasa de Horizon y que el control de tasa debe ser gestionado externamente a Horizon dentro de la infraestructura. La implementación del control de tasa de Horizon se gestiona en memoria, por lo que no funciona con múltiples instancias.
Aislamiento lógico de la ingestión
La ingestión es el proceso por el cual los nuevos ledgers se propagan en la base de datos de Horizon. Su salud es crítica, ya que las degradaciones en el rendimiento pueden resultar en retrasos con respecto al último ledger cerrado, dejando a tus usuarios finales sin conocer el estado actual de la red, y sin poder enviar nuevas transacciones con éxito. Cualquier retraso en la ingestión probablemente se consideraría tiempo de inactividad para tu servicio
Horizon te permite configurar de manera independiente los diferentes roles que desempeña, incluida la ingestión. El diagrama a continuación ilustra cómo podrías separar lógicamente las instancias que atienden solicitudes de API de las instancias que realizan la ingestión, e introducir una base de datos de réplica de solo lectura para aislar aún más estos componentes. Esta configuración tiene varias ventajas:
- Cada "rol" que juega Horizon puede escalarse de forma independiente
- Las instancias de API son significativamente más ligeras desde la perspectiva de los requisitos de hardware, ya que no necesitan ejecutar el núcleo cautivo
- Las instancias de API pueden escalarse horizontalmente o escalarse dinámicamente, en función de las necesidades específicas de tus usuarios finales
- La ingestión y su rendimiento están aislados de la actividad de la API, por lo que los picos en la actividad del usuario no pueden degradarlo y causar un retraso en la ingestión. La salud de la ingestión es crítica, ya que las degradaciones en el rendimiento pueden resultar en retrasos con respecto al último ledger cerrado, dejando a tus usuarios finales sin conocer el estado actual de la red, y sin poder enviar nuevas transacciones con éxito
El rol de la API de Horizon requiere solo permisos de solo lectura a una base de datos para todas las acciones que realiza. Sin embargo, las instancias de API necesitarán delegar todas las solicitudes de envío de transacciones a una instancia que ejecute el núcleo cautivo. Se podrían agregar más réplicas de base de datos si es necesario para admitir más solicitudes.
Aislamiento lógico de la presentación de transacciones
En el ejemplo anterior, la ingestión está aisladamente separada de la mayor parte del tráfico de la API, que históricamente ha sido la gran mayoría del tráfico. Sin embargo, la presentación de transacciones aún necesita ser atendida por una instancia principal, por lo que las instancias de API deben pasar sus solicitudes de presentación de transacciones a una instancia de ingestión.
El diagrama a continuación ilustra cómo podríamos aislar (y escalar) aún más la presentación de transacciones, utilizando instancias de observadores del núcleo, en lugar de instancias de Horizon que ejecuten el núcleo cautivo. Esto nos permite proteger aún más la ingestión, previniendo el tiempo de inactividad y el retraso en la ingestión. También hace posible escalar horizontalmente la presentación de transacciones en sí, independientemente del resto del tráfico de la API.
