Escalar
Horizon permite diferentes capas lógicas que se pueden escalar de forma independiente para aumentar el rendimiento, el aislamiento y la disponibilidad. Los siguientes componentes se pueden escalar de forma independiente:
- API de servicio web (servicio)
- Captive Core (ingestión y envío de transacciones)
- Base de datos (almacenamiento)
Despliegue de instancia única
Se recomienda comenzar con un despliegue de instancia única, y escalar según las necesidades de tu caso de uso particular.
Este despliegue está destinado para su uso con retención mínima de historial (<= 30 días) y volumen mínimo de solicitudes.
En esta configuración, una instancia única de Horizon desempeña los tres roles; ingestión, envío de transacciones y solicitudes de API de usuarios finales.
Escalar a Múltiples Instancias
Hay varias razones por las que podrías elegir escalar a múltiples instancias de Horizon.
- La escalabilidad 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 un tiempo de inactividad en la actualización (migraciones, reconstrucciones de estado, etc.)
- Protección contra posibles retrasos en la ingestión, que podrían resultar en tiempo de inactividad para los usuarios finales
Múltiples instancias de Horizon se pueden configurar para apuntar a la misma base de datos, y el proceso de ingestión no realizará trabajos redundantes en estos casos.
Al escalar Horizon, es importante notar que la limitación de velocidad de Horizon debe estar deshabilitada y la limitación de velocidad debe gestionarse externamente a Horizon dentro de la infraestructura. La implementación de la limitación de velocidad de Horizon se gestiona en memoria, por lo que no funciona con múltiples instancias.
Aislar Lógicamente 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 respecto al último ledger cerrado, dejando a tus usuarios finales inconscientes del estado actual de la red y incapaces de 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 independientemente 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 replica de solo lectura para aislar aún más estos componentes. Esta configuración tiene varias ventajas:
- Cada "rol" que desempeña Horizon se puede escalar de forma independiente
- Las instancias de API son significativamente más ligeras en términos de requisitos de hardware, ya que no necesitan ejecutar captive core
- Las instancias de API se pueden escalar horizontalmente o escalar dinámicamente, según las necesidades específicas de tus usuarios finales
- La ingestión y su rendimiento están aislados de la actividad de API, por lo que los picos en la actividad del usuario no pueden degradarlo y causar 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 respecto al último ledger cerrado, dejando a tus usuarios finales inconscientes del estado actual de la red y incapaces de enviar nuevas transacciones con éxito
El rol de la API de Horizon solo requiere permisos de solo lectura en 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 captive core. Se podrían agregar más réplicas de base de datos si es necesario para soportar más solicitudes.
Aislar Lógicamente el Envío de Transacciones
En el ejemplo anterior, la ingestión está aislada de manera segura del tráfico de API, que ha sido históricamente la gran mayoría del tráfico. Sin embargo, el envío de transacciones aún necesita ser atendido por una instancia central, y por lo tanto, las instancias de API deben pasar sus solicitudes de envío de transacciones a una instancia de ingestión.
El diagrama a continuación ilustra cómo podríamos aislar aún más (y escalar) el envío de transacciones, utilizando instancias de observación del núcleo, en lugar de instancias de Horizon que ejecutan captive core. 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 el envío de transacciones en sí, independiente del resto del tráfico de API.
