Pasar a la producción es un acontecimiento al mismo tiempo emocionante y aterrador.
Hacerlo con una aplicación sin servidor puede ser aún más aterrador si no tienes en cuenta todas las advertencias.
Este blog cubrirá mi lista de verificación de productividad personal para aplicaciones sin servidor.
Sin embargo, algunos elementos de la lista de verificación son relevantes para las aplicaciones SaaS en general.
Categorías
La lista de verificación se divide en cinco categorías:
Actuación
Seguridad
Prácticas de CI/CD
Recuperación de la crisis
Observabilidad y disponibilidad de apoyo
Actuación
Ejecutar pruebas de rendimiento
Su aplicación sin servidor funciona y todas las pruebas están en verde.
Genial, pero ¿examinaste el rendimiento general y los cuellos de botella ocultos que pueden hacer que tu aplicación se bloquee?
No espere a que surjan problemas de rendimiento; resuélvalos lo antes posible:
1. Utilice el seguimiento de AWS X-Ray para encontrar cuellos de botella en su código y refactorizarlos.
2. Utilice AWS Lambda Power Tuning para equilibrar el costo y el rendimiento.
3. Considere cambiar a la CPU Graviton para sus funciones Lambda.
Lea más sobre el seguimiento y la supervisión del rendimiento aquí .
Cache
Mejore los cuellos de botella en el rendimiento agregando mecanismos de almacenamiento en caché.
Muchos mecanismos de almacenamiento en caché pueden proporcionar un aumento sustancial del rendimiento de su aplicación.
Para AWS Lambda, una tabla de caché en memoria ( memoización ) o de caché DynamoDB (con o sin DAX ) generalmente se consideran opciones fáciles de lograr y pueden brindar un aumento inmediato del rendimiento.
Lea más sobre esto en la publicación de Yan Cui.
Seguridad
Pruebas de penetración
Las pruebas de penetración son una obviedad y son obligatorias en cualquier servicio, especialmente en un servicio sin servidor.
Ejecute pruebas de penetración en una cuenta de AWS dedicada con una configuración que coincida con su cuenta de producción.
Revisión de seguridad interna
Realice una revisión de seguridad interna de la aplicación con un experto en seguridad de AWS para identificar puntos de falla y tomar medidas para resolverlos.
AWS WAF
Utilice AWS Web Application Firewall (WAF): use reglas administradas por AWS en sus API Gateways y distribuciones de CloudFront.
Inspección de AWS Lambda
Habilite Amazon Inspector en sus funciones y capas de AWS Lambda.
"Amazon Inspector escanea funciones y capas inicialmente durante la implementación y las vuelve a escanear automáticamente cuando hay cambios en las cargas de trabajo, por ejemplo, cuando se actualiza una función Lambda o cuando se publica una nueva vulnerabilidad ( CVE )".
Obtenga más información sobre ello aquí .
Escáner de vulnerabilidades de CI/CD
Utilice un escáner de vulnerabilidades en su canalización de CI/CD. Si bien Amazon Inspector verifica las capas y funciones de Lambda implementadas en busca de vulnerabilidades, siempre es bueno "desplazarse a la izquierda" y realizar estas comprobaciones lo antes posible en la canalización de CI/CD.
He utilizado herramientas como Snyk, que cumplen su función. Lea más sobre esto aquí .
Prácticas recomendadas de seguridad de IAC
Utilice los permisos de AWS IAM y las pautas de mejores prácticas de AWS en su marco de implementación.
Desea evitar violaciones de seguridad, como una API Gateway sin protección, un bucket S3 abierto o una función de IAM demasiado permisiva.
Si usa CDK, debe implementar CDK nag; de lo contrario, utilice cfn-nag .
Consulte un ejemplo de código nag de CDK en funcionamiento en mi publicación de blog sobre las mejores prácticas de CDK según las pautas de seguridad .
Prácticas de CI/CD
Implementación de Canary para funciones de AWS Lambda
Implementación canaria para AWS Lambda: para un entorno de producción, utilice implementaciones canarias con reversiones automáticas al ver los registros de errores de AWS Lambda o las alarmas de AWS CloudWatch activadas.
Las implementaciones de Canary cambian gradualmente el tráfico a su nueva versión de AWS Lambda y revierten el cambio ante la primera detección de errores.
Una forma de lograrlo es utilizar AWS Code Deploy con AWS Lambda.
Lea más sobre esto aquí .
Implementación de Canary para configuración dinámica de Lambda
Las implementaciones de Canary también son relevantes en el dominio de la configuración dinámica de aplicaciones.
Los indicadores de funciones son un tipo de configuración dinámica y le permiten cambiar rápidamente el comportamiento de su función de AWS Lambda. Una forma de mejorar la confianza en el lanzamiento de funciones es poder activar o desactivar una función rápidamente.
Recomiendo utilizar AWS AppConfig con la utilidad de indicadores de características de AWS Lambda Powertools para obtener la mejor experiencia con indicadores de características.
Concurrencia aprovisionada
Los arranques en frío de AWS Lambda pueden convertirse en un problema en casos de uso críticos para la empresa o en tiempo real. Por ejemplo, servicios críticos como el inicio de sesión del cliente y la carga de la página principal.
Para esos casos de uso, y solo en la cuenta de producción, sugeriría habilitar la simultaneidad aprovisionada, para que su servicio esté siempre activo y listo para funcionar.
Lea más sobre esto aquí .
Concurrencia reservada
El servicio AWS Lambda escala sus funciones según la carga.
Sin embargo, cada cuenta y región de AWS tiene una cantidad máxima de lambdas simultáneas , que se comparten entre TODAS las funciones lambda.
Si se implementan dos funciones lambda en la misma cuenta y región, una función puede escalar drásticamente y provocar la inanición y limitación de la otra función (error HTTP 429) ya que la cuenta completa alcanza la cuota simultánea máxima.
Definir simultaneidad reservada por función lambda puede evitar esto.
Lea más sobre esto aquí .
Recuperación de la crisis
Debes aceptar que es sólo cuestión de tiempo hasta que suceda algo terrible.
No puedes prepararte para todo, pero puedes tener pólizas de seguro y preparar tus servicios para todas las catástrofes.
Repasemos algunos elementos que pueden preparar su servicio para lo peor.
Ingeniería del caos
Este es un tema complicado. Hay que esperar lo inesperado. Se producirán cortes y errores en el servidor, incluso en entornos sin servidor.
Tienes que estar preparado
Utilice la simulación de inyección de fallas de AWS para crear caos en su cuenta de AWS, hacer que sus llamadas a la API de AWS fallen y ver cómo se comporta su servicio.
Intente diseñar para el fracaso lo más temprano posible en su recorrido hacia Serverless.
Copias de seguridad
Realice una copia de seguridad de sus datos y de los de sus clientes.
Habilite las copias de seguridad cada hora de sus tablas de DynamoDB, bases de datos Aurora, índices de OpenSearch o cualquier otra entidad de base de datos. Es mejor prevenir que curar.
Algunos servicios, como DynamoDB, ofrecen copias de seguridad automáticas y facilidad de restauración.
Consulte más prácticas recomendadas de copia de seguridad de CDK aquí .
Restaurar desde copia de seguridad
Cree un proceso para restaurar datos de producción desde la copia de seguridad.
Crear una copia de seguridad es una cosa, pero restaurar desde una copia de seguridad cuando el tiempo avanza y hay clientes molestos en su puerta es otra.
Debe crear un proceso bien definido para restaurar cualquier base de datos de forma rápida y segura.
Desarrolle los scripts necesarios, defina el proceso de restauración (quién lo ejecuta, cuándo, cómo), pruébelo en entornos que no sean de producción y capacite a su personal de soporte para usarlo.
Acciones ad hoc de producción
Cree un proceso para realizar cambios, secuencias de comandos y correcciones ad hoc en la cuenta de producción. A veces, no puede esperar a que se implemente una corrección de errores desde la cuenta de desarrollo a la de producción, y puede llevar demasiado tiempo pasar por todas las etapas de la cadena de suministro de CI/CD.
A veces es necesario contar con una forma rápida, auditada y segura de modificar datos de producción.
Asegúrese de que esté auditado, requiera aprobaciones adicionales y no infrinja ninguna normativa a la que esté obligado.
Redundancia de datos
Diseño para redundancia de datos. Las regiones de AWS pueden caerse. Sí, sucede .
Sin embargo, no es posible que todo el servicio se caiga con él.
Diseño para copias de seguridad de múltiples regiones como se explica aquí .
Simular la interrupción en la región principal y verificar que la aplicación funcione en la región secundaria.
Una vez que la región principal esté activa nuevamente, valide que los datos del cliente estén sincronizados con la región secundaria.
Observabilidad y preparación para el apoyo
Las buenas prácticas de observación y registro harán felices a sus desarrolladores y equipos de soporte.
Identificación de correlación
En mi opinión, la sesión de depuración perfecta es aquella en la que puedo rastrear una única actividad de usuario en múltiples servicios con una sola identificación: el infame valor de identificación de correlación .
Una forma de lograr esta experiencia es inyectar un valor de identificación de correlación en los registros de servicio.
Además, debe pasar este valor a cualquier llamada posterior a los servicios a través de encabezados de solicitud/evento (atributos de AWS SNS/encabezados HTTP, etc.).
Vea un ejemplo aquí con AWS Lambda Powertools Logger.
Paneles de observación
Cree paneles de AWS CloudWatch que proporcionen una descripción general de alto nivel del estado de su servicio para su equipo de SRE.
Debe contener registros de errores manejables e información de servicio, para que los no desarrolladores puedan identificar rápidamente los errores y su causa raíz.
Deje los paneles complicados que contienen métricas de servicio de bajo nivel de CloudWatch a los paneles de los desarrolladores.
Trabaje en estrecha colaboración con el equipo de SRE, agregue mensajes de registro precisos que describan los problemas de servicio y cree el tablero.
Lea más sobre observabilidad y CloudWatch aquí .
Alertas
Defina alertas de CloudWatch sobre registros de errores críticos o métricas de CloudWatch que se correlacionen con una deficiencia grave del servicio o una denegación de servicio.
Estos pueden incluir fallas de la función Lambda, problemas de latencia, tiempos de espera de la función Lambda, errores de DynamoDB, problemas de inicio de sesión de Cognito, etc.
Cada alarma debe investigarse y mitigarse rápidamente.
Capacitación
Invierta tiempo y esfuerzo en la formación de soporte para desarrolladores y SRE.
Cada registro de error del panel o métrica de CloudWatch debe tener una acción predefinida que el SRE debe tomar.
Incluya pautas como "Si ve 'X' e 'Y', lo más probable es que Z sea un problema; siga estos pasos para mitigar Z".
Asegúrese de que los SRE comprendan la arquitectura impulsada por eventos de alto nivel del servicio para que puedan respaldarlo de manera más eficiente.
Métricas de KPI
Agregar métricas KPI: los indicadores clave de rendimiento son métricas "especiales" que, en teoría, pueden predecir el éxito de su servicio.
Los KPI sirven como medio para predecir el futuro de la empresa. Están diseñados estratégicamente para respaldar el caso de uso empresarial. Requieren un conocimiento profundo de su empresa y de sus usuarios y, como tal, requieren una definición cuidadosa.
Si no logra cumplir con los KPI bien definidos, su servicio fracasará. Si logra cumplir con los KPI, su servicio tendrá más posibilidades de tener éxito.
Aprenda aquí cómo implementar KPI en su servicio Serverless con métricas personalizadas de AWS CloudWatch.