REL05-BP06 Crear servicios sin estado cuando sea posible
Los servicios deben o bien no requerir estado o bien descargar el estado, de forma que entre solicitudes de clientes distintos no haya dependencia en los datos almacenados localmente en disco y en memoria. Esto permite reemplazar los servidores a voluntad sin que la disponibilidad resulte afectada. Amazon ElastiCache y Amazon DynamoDB son buenos destinos para el estado descargado.
Figura 7: En esta aplicación web sin estado, el estado de la sesión se descarga en Amazon ElastiCache.
Cuando los usuarios o los servicios interactúan con una aplicación, suelen realizar una serie de interacciones que constituyen una sesión. Una sesión es un dato único para los usuarios que persiste entre las solicitudes mientras utilizan la aplicación. Una aplicación sin estado es aquella que no necesita conocer las interacciones anteriores y no almacena la información de la sesión.
Una vez se ha diseñado para no tener estado, puede utilizar servicios de computación sin servidor, como AWS Lambda o AWS Fargate.
Además del reemplazo del servidor, otro beneficio de las aplicaciones sin estado es que pueden escalar horizontalmente porque cualquiera de los recursos de computación disponibles (como las instancias EC2 y funciones AWS Lambda) puede dar servicio a cualquier solicitud.
Nivel de riesgo expuesto si no se establece esta práctica recomendada: Mediana
Guía para la implementación
Haga que sus aplicaciones no tengan estado. Las aplicaciones sin estado permiten el escalado horizontal y toleran el error de un nodo individual.
-
Elimine el estado que realmente podría almacenarse en parámetros de solicitud.
-
Tras examinar si el estado es realmente necesario, mueva cualquier seguimiento de estado a una caché o un almacén de datos resilientes de varias zonas como Amazon ElastiCache, Amazon RDS, Amazon DynamoDB o una solución de datos distribuidos de terceros. Almacene el estado que no se pudo mover a almacenes de datos resilientes.
-
Algunos datos (como las cookies) se pueden pasar a encabezados o parámetros de consulta.
-
Refactorice para eliminar el estado que se puede pasar rápidamente a las solicitudes.
-
Algunos datos pueden no resultar realmente necesarios para la solicitud y pueden recuperarse bajo demanda.
-
Elimine los datos que se puedan recuperar asincrónicamente.
-
Elija un almacén de datos que cumpla los requisitos para el estado requerido.
-
Considere la posibilidad de usar una base de datos NoSQL para datos no relacionales.
-
-
Recursos
Documentos relacionados:
