Cuatro semanas para Shanghái: una app de evento servida a través del Gran Cortafuegos
Para un gran evento internacional de deportes de motor en Shanghái, teníamos cuatro semanas para entregar una app web en la que los participantes, tanto generales como VIP, pudieran consultar sus agendas. Alojarla en China continental era imposible en ese plazo, así que la servimos desde AWS en Hong Kong, a través de CloudFront y cruzando el Gran Cortafuegos. Se puso en marcha a tiempo, el equipo del cliente en China no notó ninguna latencia añadida y la factura de AWS del mes se quedó en un solo dígito.
| Alojar en China continental | Lo que entregamos | |
|---|---|---|
| Requisitos previos | Registro ICP y una cuenta de AWS China | La configuración de AWS que ya tenía el cliente |
| Cabe en cuatro semanas | No | Sí |
| Origen | Una región de China continental | S3 en Hong Kong (ap-east-1) |
| Camino hasta usuarios | Se queda dentro de China | Cruza el Gran Cortafuegos |
| Servidores que operar | Depende del stack | Ninguno: cada página es un archivo estático |
| Factura mensual de AWS | — | Un solo dígito |
Contexto
La app en sí parecía sencilla: un conjunto de páginas de agenda, unas para todos los participantes y otras para los VIP. Los problemas estaban alrededor. El evento era en Shanghái, faltaban cuatro semanas y las vacaciones del Año Nuevo chino empezaban la semana siguiente.
Nuestro cliente opera en China, pero no había tiempo para completar el registro ICP, obligatorio para los servicios de internet alojados en China continental. Además, el cliente quería usar AWS, y las regiones de AWS en China continental requieren una cuenta de AWS China independiente. Tampoco había tiempo para conseguirla.
Restricciones
- Cuatro semanas, una de ellas festiva. Durante el Año Nuevo chino, el equipo del cliente en China no estaba disponible para hacer pruebas.
- Sin registro ICP. Cualquier cosa alojada en China continental, incluidos los puntos de presencia de una CDN allí, quedaba descartada.
- Sin cuenta de AWS China. El cliente quería AWS, así que contábamos con las regiones globales de AWS.
- Acceso fiable desde China continental. Cada petición cruzaría el Gran Cortafuegos, que puede añadir latencia y perder tráfico de forma impredecible.
- Agendas que cambian durante el evento. El cliente quería retirar la agenda de cada día una vez terminado.
Las opciones
| Opción | Requiere ICP | Requiere cuenta de AWS China | Cabe en cuatro semanas | Veredicto |
|---|---|---|---|---|
| Regiones de AWS China (Pekín, Ningxia) | Sí | Sí | No | Descartada |
| Otro proveedor en China continental | Sí | No | No | Descartada: ICP, y el cliente quería AWS |
| AWS fuera de China continental, cerca | No | No | Sí | Elegida, con el Gran Cortafuegos en medio |
Seguir con AWS fuera de China continental resolvía de una vez los problemas de la cuenta y de la normativa. El precio era que la app llegaría a sus usuarios a través del Gran Cortafuegos, así que el resto del diseño consistió en que ese cruce fuera lo más corto, ligero y poco frecuente posible.
Arquitectura
- Build: Next.js con generación de sitios estáticos. Toda la app se construye por adelantado, así que cada página es un archivo.
- Origen: un bucket S3 en la región de AWS de Hong Kong (
ap-east-1), lo más cerca de China continental que permitía nuestra configuración. - Edge: CloudFront delante del bucket. La red global de CloudFront no tiene puntos de presencia en China continental, así que los asistentes reciben el contenido desde edges cercanos fuera de ella.
- Cuenta: una cuenta de AWS dedicada, con AWS Business Support contratado para el evento.
Decisiones clave y compromisos
Generación de sitios estáticos con Next.js
Recomendamos la generación de sitios estáticos (SSG) con Next.js, construyendo y desplegando la app por adelantado. Nos encanta SSG: reduce la carga operativa, facilita una caché eficaz, mejora el SEO y, por lo general, también el rendimiento. Aquí, además, significaba que no había ningún servidor que mantener vivo al otro lado del Gran Cortafuegos, ni nada que escalar cuando todo el evento consultara la agenda a la vez.
- Compromiso: cada cambio es un despliegue. El contenido no puede cambiar por petición, así que cualquier actualización implica reconstruir o subir archivos. Para unas agendas cerradas de antemano, era un compromiso fácil de aceptar.
Un resultado deliberadamente ligero
Limitamos el número de recursos y redujimos al máximo el tamaño de cada uno, sobre todo el de las imágenes. Cada byte y cada petición tienen que cruzar el Gran Cortafuegos, así que una página más ligera es allí una página más rápida, y con menos probabilidades de quedarse atascada por una conexión perdida.
También dejamos fuera de la página los servicios de terceros. Las fuentes, la analítica y los scripts servidos desde fuera de China suelen ir lentos o estar bloqueados allí, y una sola petición bloqueada puede retener toda la página.
Un origen en Hong Kong
CloudFront sirve la mayoría de peticiones desde su caché, pero cada fallo de caché viaja de vuelta al origen. Poner el bucket en Hong Kong, lo más cerca de China continental que podíamos, mantuvo cortos esos viajes.
- Compromiso: una región opcional. Hong Kong tiene que activarse en la cuenta antes de poder usarse. Es un paso pequeño, pero conviene darlo pronto cuando el plazo es de cuatro semanas.
Una ruta por día
Diseñamos la agenda de cada día como una ruta estática independiente. Esa decisión dio sus frutos durante el evento, como se explica más abajo.
Business Support para el evento
Contratamos AWS Business Support para la cuenta de AWS dedicada, para tener respuestas más rápidas si algo fallaba. Un periodo de prueba generoso hizo que la mejora no aumentara el coste del proyecto.
Pruebas a través del Gran Cortafuegos
Durante las vacaciones, usamos servicios de pruebas públicos para confirmar que la app era accesible desde China continental y estimar la latencia adicional. Cuando el equipo del cliente en China volvió del Año Nuevo chino, probó la app con regularidad hasta la puesta en marcha. Todos coincidieron en que la latencia añadida por el Gran Cortafuegos era imperceptible.
Durante el evento
El evento se celebró de viernes a domingo. A petición del cliente, una vez pasada de sobra la medianoche en Shanghái, retirábamos la agenda del día que acababa de terminar. Como cada día era una ruta independiente, solo teníamos que invalidar esa ruta en CloudFront. El resto de rutas seguían en caché, así que la actualización no provocó ni un solo fallo de caché en ninguna otra parte.
Resultados
| Medida | Resultado |
|---|---|
| Tiempo hasta la puesta en marcha | A tiempo: cuatro semanas, incluidas las vacaciones del Año Nuevo chino |
| Registro ICP o cuenta de AWS China | No hizo falta ninguno |
| Latencia añadida por el cortafuegos | Imperceptible, según el equipo del cliente en China |
| Servidores que operar | Ninguno |
| Actualizaciones diarias de agenda | Una invalidación de CloudFront cada una, sin más fallos de caché |
| Factura de AWS del mes del evento | Un solo dígito |
El coste nos sorprendió incluso a nosotros. Para un proyecto de este perfil y un cliente final de esta envergadura, la infraestructura fue prácticamente gratuita. Es un buen recordatorio de que las decisiones técnicas acertadas pueden reducir de forma drástica los costes de infraestructura.
Nos encargamos del desarrollo de software, el despliegue y la infraestructura en la nube. También estudiamos cómo trabajar dentro de las restricciones del Gran Cortafuegos y asesoramos a nuestro cliente y al cliente final sobre las opciones. El proyecto se entregó con éxito, y las valoraciones del cliente, del cliente final y de sus usuarios fueron muy positivas.
Qué haríamos diferente
- Monitorizar desde dentro de China durante el evento. Las pruebas desde dentro de China dependían del equipo del cliente. Una comprobación sintética desde redes de China continental nos habría dado la misma respuesta a cualquier hora.
- Automatizar la retirada diaria. Una tarea programada que retire el día terminado e invalide su ruta evitaría depender de que alguien esté despierto pasada la medianoche en Shanghái.
- Empezar el registro ICP de todos modos. Si el evento vuelve el año que viene, registrarse ahora haría que alojar dentro de China continental fuera una opción y no un deseo.