En esta publicación, abordaremos la configuración de un servidor ElastiCache con acceso a Internet mediante los servicios de AWS. Aprenda a eludir la limitación del servicio ElastiCache de «aislamiento mediante VPC» y, al mismo tiempo, a utilizarlo para aprovechar sus sólidas capacidades. Este tutorial requiere un conocimiento básico de AWS y es ideal para quienes desean aprovechar Redis como algo más que una simple memoria caché. Redis no solo es una caché en memoria de alto rendimiento, sino también un almacén de estructuras de datos que admite varios tipos: listas, conjuntos, hashes, transmisiones y más. Ofrece funciones como la persistencia, el pub/sub y la agrupación en clústeres, lo que lo hace versátil para una variedad de aplicaciones más allá del almacenamiento en caché.
Redis es una base de datos de valores clave en memoria de código abierto, diseñada para actividades de lectura/escritura de baja latencia. Por lo general, se usa como caché, pero no es su única aplicación posible. También se puede usar como base de datos NoSQL.
Si te encontraste con esta publicación, es probable que desees implementar un servidor Redis. Y consideraste conveniente evitar ocuparte del mantenimiento rutinario, las medidas de seguridad y las actualizaciones que implica disponer de un activo de este tipo. Aquí es donde los proveedores de nube se vuelven más convenientes, por lo que probablemente pensó que el servicio gestionado ElastiCache de AWS podría ser una buena opción.
Por diseño, los clústeres de ElastiCache solo pueden conectarse a los recursos de la VPC en la que se ejecuta. En esta solución, se podrá acceder a la base de datos de Redis desde cualquier lugar de Internet.
Por supuesto, esto tiene algunas implicaciones que deben tenerse en cuenta antes de implementar esta solución en su carga de trabajo.
El objetivo de este blog es ilustrar cómo sería una arquitectura de este tipo, así como proporcionar plantillas de CloudFormation para probarla usted mismo. Estas plantillas se pueden encontrar en este Repositorio GitHub.
Para resolver esta limitación de acceso, se puede implementar una instancia de proxy expuesta a Internet. Esto tiene sus propios desafíos y limitaciones, pero la idea es usar un proxy de Redis. Hay varias opciones de proxy de Redis disponibles de forma gratuita en Internet: Proxy de clúster de Redislabs/Redis-Cluster, Twitter/TWEMProxy, Nginx entre otros.
Twitter (o ahora) twemproxy se utilizará, como se sugiere en esta publicación técnica de Trivago, para poder gestionar conexiones persistentes con la base de datos de Redis. Esto es especialmente útil en contextos en los que la actividad de escritura es tan alta como la de lectura, y ayuda a reducir la latencia al reducir la cantidad de conexiones que se abren y cierran.
Estas instancias de proxy no se expondrán directamente a Internet, sino que estarán detrás de un balanceador de carga de red (NLB) de AWS.
El balanceador de cargas desempeña una función de seguridad principal, ya que termina las conexiones TLS y permite tener instancias de twemproxy en una subred privada. La descarga de paquetes cifrados mediante NLB evita el descifrado en las instancias de Redis, lo que reduce el rendimiento. AWS afirma que su NLB escala «infinitamente». Por supuesto, esto tiene un precio acorde. La comunicación entre twemproxy y ElastiCache se realiza a través de TCP. Las instancias de Twemproxy las lanza un grupo de escalado automático (ASG), lo que proporciona tolerancia a errores y alta disponibilidad al escalar horizontalmente. El ASG permite especificar cuántas instancias van a estar activas en un momento dado y cuánto se puede ampliar o reducir.
En cuanto a la configuración de ElastiCache, esta arquitectura permite tanto el modo de clúster activado como el desactivado (puede encontrar la comparación entre ellos). aquí), ya que la configuración de twemproxy requiere cualquier cantidad de nodos de Redis y tiene varias opciones de fragmentación consistentes. En el ámbito de este artículo, el clúster de ElastiCache se ejecutará en el modo clúster desactivado.
Los recursos se dividirán en tres pilas diferentes de Cloudformation (CFN), que separarán los recursos de VPC, ElastiCache y NLB/ASG.
Para seguir este tutorial es necesario disponer de los siguientes recursos:
Es importante tener en cuenta que tener un certificado ACM implica que eres propietario de un nombre de dominio. Deberá especificarlo durante la creación de la pila NLB/ASG. El certificado SSL es necesario para la terminación de TLS; de lo contrario, tendrá que utilizar una comunicación TCP simple a través de Internet, lo cual es peligroso y no se recomienda.
Primero necesitamos implementar las fuentes de red necesarias en nuestra cuenta de AWS. Cargue la plantilla de pila de VPC en CloudFormation y especifique los rangos de IP de las subredes públicas y privadas, así como el rango de IP de la VPC.
Esta plantilla creará una puerta de enlace NAT, necesaria para proporcionar acceso a Internet a las instancias sin IP públicas. Este recurso se cobra según el uso por hora, así que recuerda apagarlo después de la prueba.
Para iniciar el clúster de ElastiCache, utilizaremos una pila de CFN que ya está configurada para Redis 7.0. Puede cambiar esta pila para modificar algunas de las configuraciones del clúster. Por ahora, especificaremos un total de 2 nodos con un tamaño de instancia pequeño y usaremos las subredes privadas que acabamos de crear.
El aprovisionamiento de clústeres es bastante lento, así que tenga paciencia mientras AWS configura su base de datos. Una vez hecho esto, necesitamos recopilar información de los recursos creados. Necesitamos obtener la siguiente información:
Una vez que haya anotado estos parámetros, estará listo para implementar la pila NLB/ASG. Estos valores se pueden exportar como salidas en una pila que contenga estos recursos; esto no se hizo por motivos de simplicidad.
Por último, necesitamos implementar la pila twemproxy, utilizando los parámetros recopilados en el paso anterior. Esta plantilla lanzará un balanceador de carga de red, cuyo nombre de dominio será el especificado como nombre de subdominio, que termina las conexiones TLS a las instancias del grupo de escalado automático. Estas instancias serán réplicas exactas de una determinada Plantilla de lanzamiento, una especie de modelo que define la configuración y el inicio de EC2. Habrá tantos casos como se indica en el Instancias deseadas parámetro.
Una vez que se lance la pila, podremos acceder a la base de datos de Redis, utilizando el nombre del servidor que definimos. El siguiente es un ejemplo de un cliente de Redis inicializado en Ruby para conectarse a través de TLS.
Creamos un script Ruby simple para probar el rendimiento de la conexión, utilizando un EC2 ubicado en una VPC diferente en la misma región. Esto simula el caso en el que la conexión pasa por Internet. Alcanzó una latencia promedio de ~ 0.26 ms
Se debe tener en cuenta la siguiente lista de consideraciones por servicio para calcular los costos operativos de esta solución:
Durante la creación de esta solución, tuvimos un gasto diario de aproximadamente 4 USD, mientras que ElastiCache fue de aproximadamente 1,5 USD. Esto explica lo siguiente alrededor de 100 USD por mes en costos fijos. Por supuesto, según sus necesidades y capacidad, el gasto se ampliará en consecuencia. Se puede calcular un importe de gasto más detallado utilizando Calculadora de precios de AWS.
En esta exploración, hemos demostrado cómo superar las limitaciones inherentes del servicio ElastiCache de AWS para hacer que un servidor Redis sea accesible a través de Internet. Si bien el hecho de que ElastiCache esté vinculado a las VPC proporciona una sólida capa de aislamiento, ciertas aplicaciones y escenarios requieren una accesibilidad más amplia. Al utilizar los servicios de AWS con prudencia, junto con twemproxy, hemos creado con éxito una solución que mantiene las características de seguridad y rendimiento fundamentales para las operaciones de Redis.
Para aquellos que desean aprovechar las capacidades de Redis más allá de sus casos de uso tradicionales, este tutorial sirve como punto de partida e ilustra el potencial y la flexibilidad de combinar servicios nativos de la nube con soluciones de código abierto. Como siempre, la evolución de la tecnología exige un aprendizaje y una adaptación continuos para maximizar los beneficios de este tipo de integraciones.
En esta publicación, abordaremos la configuración de un servidor ElastiCache con acceso a Internet mediante los servicios de AWS. Aprenda a eludir la limitación del servicio ElastiCache de «aislamiento mediante VPC» y, al mismo tiempo, a utilizarlo para aprovechar sus sólidas capacidades. Este tutorial requiere un conocimiento básico de AWS y es ideal para quienes desean aprovechar Redis como algo más que una simple memoria caché. Redis no solo es una caché en memoria de alto rendimiento, sino también un almacén de estructuras de datos que admite varios tipos: listas, conjuntos, hashes, transmisiones y más. Ofrece funciones como la persistencia, el pub/sub y la agrupación en clústeres, lo que lo hace versátil para una variedad de aplicaciones más allá del almacenamiento en caché.
Redis es una base de datos de valores clave en memoria de código abierto, diseñada para actividades de lectura/escritura de baja latencia. Por lo general, se usa como caché, pero no es su única aplicación posible. También se puede usar como base de datos NoSQL.
Si te encontraste con esta publicación, es probable que desees implementar un servidor Redis. Y consideraste conveniente evitar ocuparte del mantenimiento rutinario, las medidas de seguridad y las actualizaciones que implica disponer de un activo de este tipo. Aquí es donde los proveedores de nube se vuelven más convenientes, por lo que probablemente pensó que el servicio gestionado ElastiCache de AWS podría ser una buena opción.
Por diseño, los clústeres de ElastiCache solo pueden conectarse a los recursos de la VPC en la que se ejecuta. En esta solución, se podrá acceder a la base de datos de Redis desde cualquier lugar de Internet.
Por supuesto, esto tiene algunas implicaciones que deben tenerse en cuenta antes de implementar esta solución en su carga de trabajo.
El objetivo de este blog es ilustrar cómo sería una arquitectura de este tipo, así como proporcionar plantillas de CloudFormation para probarla usted mismo. Estas plantillas se pueden encontrar en este Repositorio GitHub.
Para resolver esta limitación de acceso, se puede implementar una instancia de proxy expuesta a Internet. Esto tiene sus propios desafíos y limitaciones, pero la idea es usar un proxy de Redis. Hay varias opciones de proxy de Redis disponibles de forma gratuita en Internet: Proxy de clúster de Redislabs/Redis-Cluster, Twitter/TWEMProxy, Nginx entre otros.
Twitter (o ahora) twemproxy se utilizará, como se sugiere en esta publicación técnica de Trivago, para poder gestionar conexiones persistentes con la base de datos de Redis. Esto es especialmente útil en contextos en los que la actividad de escritura es tan alta como la de lectura, y ayuda a reducir la latencia al reducir la cantidad de conexiones que se abren y cierran.
Estas instancias de proxy no se expondrán directamente a Internet, sino que estarán detrás de un balanceador de carga de red (NLB) de AWS.
El balanceador de cargas desempeña una función de seguridad principal, ya que termina las conexiones TLS y permite tener instancias de twemproxy en una subred privada. La descarga de paquetes cifrados mediante NLB evita el descifrado en las instancias de Redis, lo que reduce el rendimiento. AWS afirma que su NLB escala «infinitamente». Por supuesto, esto tiene un precio acorde. La comunicación entre twemproxy y ElastiCache se realiza a través de TCP. Las instancias de Twemproxy las lanza un grupo de escalado automático (ASG), lo que proporciona tolerancia a errores y alta disponibilidad al escalar horizontalmente. El ASG permite especificar cuántas instancias van a estar activas en un momento dado y cuánto se puede ampliar o reducir.
En cuanto a la configuración de ElastiCache, esta arquitectura permite tanto el modo de clúster activado como el desactivado (puede encontrar la comparación entre ellos). aquí), ya que la configuración de twemproxy requiere cualquier cantidad de nodos de Redis y tiene varias opciones de fragmentación consistentes. En el ámbito de este artículo, el clúster de ElastiCache se ejecutará en el modo clúster desactivado.
Los recursos se dividirán en tres pilas diferentes de Cloudformation (CFN), que separarán los recursos de VPC, ElastiCache y NLB/ASG.
Para seguir este tutorial es necesario disponer de los siguientes recursos:
Es importante tener en cuenta que tener un certificado ACM implica que eres propietario de un nombre de dominio. Deberá especificarlo durante la creación de la pila NLB/ASG. El certificado SSL es necesario para la terminación de TLS; de lo contrario, tendrá que utilizar una comunicación TCP simple a través de Internet, lo cual es peligroso y no se recomienda.
Primero necesitamos implementar las fuentes de red necesarias en nuestra cuenta de AWS. Cargue la plantilla de pila de VPC en CloudFormation y especifique los rangos de IP de las subredes públicas y privadas, así como el rango de IP de la VPC.
Esta plantilla creará una puerta de enlace NAT, necesaria para proporcionar acceso a Internet a las instancias sin IP públicas. Este recurso se cobra según el uso por hora, así que recuerda apagarlo después de la prueba.
Para iniciar el clúster de ElastiCache, utilizaremos una pila de CFN que ya está configurada para Redis 7.0. Puede cambiar esta pila para modificar algunas de las configuraciones del clúster. Por ahora, especificaremos un total de 2 nodos con un tamaño de instancia pequeño y usaremos las subredes privadas que acabamos de crear.
El aprovisionamiento de clústeres es bastante lento, así que tenga paciencia mientras AWS configura su base de datos. Una vez hecho esto, necesitamos recopilar información de los recursos creados. Necesitamos obtener la siguiente información:
Una vez que haya anotado estos parámetros, estará listo para implementar la pila NLB/ASG. Estos valores se pueden exportar como salidas en una pila que contenga estos recursos; esto no se hizo por motivos de simplicidad.
Por último, necesitamos implementar la pila twemproxy, utilizando los parámetros recopilados en el paso anterior. Esta plantilla lanzará un balanceador de carga de red, cuyo nombre de dominio será el especificado como nombre de subdominio, que termina las conexiones TLS a las instancias del grupo de escalado automático. Estas instancias serán réplicas exactas de una determinada Plantilla de lanzamiento, una especie de modelo que define la configuración y el inicio de EC2. Habrá tantos casos como se indica en el Instancias deseadas parámetro.
Una vez que se lance la pila, podremos acceder a la base de datos de Redis, utilizando el nombre del servidor que definimos. El siguiente es un ejemplo de un cliente de Redis inicializado en Ruby para conectarse a través de TLS.
Creamos un script Ruby simple para probar el rendimiento de la conexión, utilizando un EC2 ubicado en una VPC diferente en la misma región. Esto simula el caso en el que la conexión pasa por Internet. Alcanzó una latencia promedio de ~ 0.26 ms
Se debe tener en cuenta la siguiente lista de consideraciones por servicio para calcular los costos operativos de esta solución:
Durante la creación de esta solución, tuvimos un gasto diario de aproximadamente 4 USD, mientras que ElastiCache fue de aproximadamente 1,5 USD. Esto explica lo siguiente alrededor de 100 USD por mes en costos fijos. Por supuesto, según sus necesidades y capacidad, el gasto se ampliará en consecuencia. Se puede calcular un importe de gasto más detallado utilizando Calculadora de precios de AWS.
En esta exploración, hemos demostrado cómo superar las limitaciones inherentes del servicio ElastiCache de AWS para hacer que un servidor Redis sea accesible a través de Internet. Si bien el hecho de que ElastiCache esté vinculado a las VPC proporciona una sólida capa de aislamiento, ciertas aplicaciones y escenarios requieren una accesibilidad más amplia. Al utilizar los servicios de AWS con prudencia, junto con twemproxy, hemos creado con éxito una solución que mantiene las características de seguridad y rendimiento fundamentales para las operaciones de Redis.
Para aquellos que desean aprovechar las capacidades de Redis más allá de sus casos de uso tradicionales, este tutorial sirve como punto de partida e ilustra el potencial y la flexibilidad de combinar servicios nativos de la nube con soluciones de código abierto. Como siempre, la evolución de la tecnología exige un aprendizaje y una adaptación continuos para maximizar los beneficios de este tipo de integraciones.
Lorem ipsum dolor sit amet consectetur. Sit sit vel eu sed proin. Arcu bibendum in mauris urna erat magna volutpat eget. Lectus commodo consectetur egestas quis ut lobortis nunc.
.png)
Lorem ipsum dolor sit amet consectetur. Sit sit vel eu sed proin. Arcu bibendum in mauris urna erat magna volutpat eget. Lectus commodo consectetur egestas quis ut lobortis nunc.
.jpeg)
