Arquitectura Serverless : Análisis de sentimiento de tweets en tiempo real
El análisis de sentimientos, es un área de investigación dentro del campo del procesamiento del lenguaje natural cuyo objetivo fundamental es el tratamiento computacional de opiniones, sentimientos y subjetividad en textos. En este contexto una opinión es una valoración positiva o negativa acerca de un producto, servicio, organización, persona o cualquier otro tipo de ente sobre lo que expresa un texto determinado.
Comprender las emociones de las personas es esencial para las empresas, ya que los clientes pueden expresar sus pensamientos y sentimientos de manera más abierta que nunca. Al analizar automáticamente los comentarios de los clientes, desde las respuestas de la encuesta hasta las conversaciones en las redes sociales, las marcas pueden escuchar atentamente a sus clientes y adaptar los productos y servicios para satisfacer sus necesidades.
¿Por qué realizar análisis de sentimientos?
Se estima que el 80% de los datos del mundo no están estructurados , en otras palabras, no están organizados. Se crean enormes volúmenes de datos de texto (correos electrónicos, tickets de soporte, chats, conversaciones en redes sociales, encuestas, artículos, documentos, etc.) todos los días, pero es difícil de analizar, comprender y clasificar, sin mencionar que es costoso y requiere mucho tiempo.
Las ventajas de recopilar datos en tiempo real son innumerables, pero explicaremos algunos de ellos. Primero, nos permite tener acceso inmediato a toda la información sobre las conversaciones de Twitter . Gracias a esta velocidad, podemos tener un control total sobre cómo está evolucionando nuestra campaña. También tendremos la información para tomar decisiones o modificar nuestro discurso si está pasando por caminos inesperados.
¿Qué realizaremos?
En este breve post, explicaremos como realizar una arquitectura serverless, que obtenga los tweets de un determinado hashtag en Twitter y los analice para detectar el sentimientos de los usuarios, y envíe alertas mediante correo los tweets negativos para tomar acción.
Para esta arquitectura serverless, usaremos varios servicios de AWS:
- Comprehend (Servicio de procesamiento de lenguaje natural)
- Fargate (Despliega contenedores serverles)
- Lambda (Ejecuta cómputo a demanda)
- DynamoDB (Base de datos NoSQL con latencia de milisegundos)
- ECR (Registro de contenedores Docker)
- SNS (Servicio de mensajería)
- Kinesis Data Streams (Procesa datos en tiempo real)
- Secrets Manager (Almacena secretos, ej. Token de Twitter)
Arquitectura Serverless
Una arquitectura sin servidor es una manera de crear y ejecutar aplicaciones y servicios sin tener que administrar infraestructura. Su aplicación continúa ejecutándose en servidores, pero AWS se encarga de toda la administración de los servidores. Ya no tiene que aprovisionar, escalar ni mantener servidores para ejecutar sus aplicaciones, bases de datos y sistemas de almacenamiento.
¿Qué beneficios tiene usar arquitecturas serverless?
Mediante el uso de una arquitectura sin servidor, los desarrolladores se pueden enfocar en el producto principal en lugar de preocuparse por la administración y el funcionamiento de los servidores, o los tiempos de ejecución, tanto en la nube como en las instalaciones. Gracias a esta reducción de carga, los desarrolladores pueden emplear su tiempo y energía en desarrollar productos increíbles que sean de confianza y se puedan escalar.
Implementando la arquitectura
Lo primero que se debe realizar es la creación del contenedor en Docker, para esto podemos hacer uso del servicio de Cloud9 para testear el código antes de subirlo al ECR.
El código del proyecto lo pueden encontrar en el siguiente repositorio de GitHub: https://github.com/luisgradossalinas/aws-serverless-analytics-tweet
Para subir el contenedor al ECR debemos ubicarnos en la carpeta docker, tal cual se muestra en la imagen anterior, y ejecutar los siguientes comandos.
Crea un repositorio en ECR
aws ecr create-repository — repository-name ecr-getting-tweets
Realiza la creación de una imagen de Docker a partir de un Dockerfile
docker build -t ecr-getting-tweets:v1 .
Creamos un tag a nuestro contenedor
docker tag ecr-getting-tweets:v1 XXXXXXXX.dkr.ecr.us-east-1.amazonaws.com/ecr-getting-tweets:v1
Nos logueamos al ECR
aws ecr get-login-password — region us-east-1 | docker login — username AWS — password-stdin XXXXXXXX.dkr.ecr.us-east-1.amazonaws.com
Subimos la imagen al ECR
docker push XXXXXXXX.dkr.ecr.us-east-1.amazonaws.com/ecr-getting-tweets:v1
Creamos un secreto en Secrets Manager
Almacenaremos los siguientes valores que lo obtendremos de Twitter (sino se tiene, crearlo en este link https://developer.twitter.com/en).
Lo puedes realizar siguiente este otro post: https://medium.com/@luisgradossalinas/generaci%C3%B3n-de-tokens-en-twitter-51e61417d917
api_key
api_secret_key
access_token
access_token_secret
Creando un recurso en Kinesis Data Streams
El recurso en Kinesis Data Streams, solo tendrá un shard asignado.
Creando función Lambda
El código de la función Lambda se encuentra en el siguiente link, y la asociar al rol de la función Lambda el siguiente json.
Añadir un desencadenador a la función Lambda, para que obtenga los datos de Kinesis Data Streams.
Creando un tema en SNS para el envío de notificaciones
Añadimos un tema, y creamos una suscripción con nuestro correo para recibir correos.
Creando tabla en DynamoDB para persistir los tweets
La tabla se debe llamar tweet y debe tener una clave de partición y una clave de ordenación.
Clave de partición : id_tweet = String
Clave de ordenación : id_user = Int
Por último crearemos el Task Definition en Fargate
Creamos un nuevo Task Definition con Fargate
Crearemos un rol para asociarlo al Task Definition, en la opción Task Role, debe tener las políticas administradas:
- SecretsManagerReadWrite
- AmazonKinesisFullAccess.
Ejecutamos la tarea y listo
Ya podemos obtener los tweets en tiempo real, y persistirlos en DynamoDB.
En caso se detecte que hay tweets negativos, recibiremos una notificación por correo.
IMPORTANTE: Al finalizar esta solución, eliminar elstream de Kinesis Data Streams, la tabla de DynamoDB y detener el Task Definition de Fargate, esto es para que AWS no nos cobre.
En un próximo post realizaré una nueva solución IoT, usando los servicios que ofrece Google Cloud Platform.
Si te pareció interesante este post, puedes compartirlo.
#aws #serverless#realtime #analytics
