Bluetab

an IBM Company

Bluetab

5 errores comunes en Redshift

by

5 errores comunes en Redshift

Alvaro Santos

Senior Cloud Solution Architect​

Amazon Redshift se puede considerar como unos de los data warehouse más importantes de la actualidad y que ofrece AWS en su nube. Trabajando en Bluetab, hemos tenido el placer de usarlo en muchas ocasiones con nuestros momentos buenos / malos al igual que este año 2020. Por ello, hemos creado una lista con los errores más comunes que debéis evitar y que esperemos os sirvan de gran ayuda.

En Bluetab llevamos desde hace más de 10 años trabajando alrededor del dato. En muchos de los cuales, hemos ayudado en la evolución tecnológica de muchas empresas migrando sus entornos tradicionales analíticos y BI de Data Warehouse a entornos de Big Data.

Además desde la Práctica Cloud hemos participado en migraciones a la nube y nuevos desarrollos de proyectos de Big Data la nube de Amazon Web Services y Google Cloud. Toda esta experiencia nos ha permitido crear un grupo de personas muy cualificadas que piensan/trabajan por/para la nube.

Para ayudaros con vuestros trabajos en la nube, os queremos presentar los errores más comunes que hemos encontrado a la hora de trabajar con Redhisft, la herramienta de DW más importante que ofrece AWS.

Aquí tenéis la lista de ellos:

  1. Trabajar como si fuera un PostgreSQL.
  2. Cargar datos de aquella manera.
  3. Dimensionar mal el cluster.
  4. No hacer uso de workload management (WLM).
  5. Desentenderse del mantenimiento

Qué es Redshift

Amazon Redshift es un base de datos analítica (OLAP) en la nube muy rápida y totalmente administrada por AWS. Con ella se simplifica y mejora el análisis de datos utilizando SQL estándar compatible con la mayoría de las herramientas de BI existentes.

Las características más importantes de Amazon Redshift son:

  • Almacenamiento de datos en columnas: en lugar de almacenar datos como una serie de filas, Amazon Redshift organiza los datos por columna. Dado que solo se procesan las columnas involucradas en las consultas y los datos en columnas se almacenan secuencialmente en los medios de almacenamiento, los sistemas basados ​​en columnas requieren muchas menos I/O, lo que mejora enormemente el rendimiento de las consultas.
  • Compresión avanzada: las bases de datos columnares se pueden comprimir mucho más que las basados ​​en filas porque los datos similares se almacenan secuencialmente en el disco.
  • Procesamiento masivo paralelo (MPP): Amazon Redshift distribuye automáticamente la carga de datos y consultas en todos los nodos.
  • Redshift Spectrum: Redshift Spectrum le permite ejecutar consultas en exabytes de datos almacenados en Amazon S3.
  • Vistas materializadas: las consultas posteriores que hacen referencia a las vistas materializadas utilizan los resultados pre.calculados para ejecutarse mucho más rápido. Las vistas materializadas se pueden crear en base a una o más tablas de origen utilizando filtros, proyecciones, combinaciones internas, agregaciones, agrupaciones, funciones y otras construcciones SQL.
  • Escalabilidad: Redshift tiene la capacidad de escalar su procesamiento y almacenamiento aumentado el tamaño de cluster a cientos de nodos.

Amazon Redshift no es igual que otros sistemas SQL de base de datos. Para aprovechar adecuadamente todos sus beneficios es necesario que se sigan una buenas practicas, de esa manera el cluster funcionará de manera óptima.

1. Trabajar como si fuera un PostgreSQL

Un error muy común que cometemos al comenzar a usar Redshift, es suponer que Redshift es simplemente un PostgreSQL vitaminado y que partiendo de un schema compatible con él puedes empezar a trabajar con Redshift. Sin embargo, no podrías estar más equivocado.

Aunque es cierto que Redshift se basó en una versión antigua de PostgreSQL 8.0.2, su arquitectura ha cambiado radicalmente y ha sido optimizada durante años para mejorar el redimiendo para su estrictamente analítico. Por ellos es necesario:
  • Diseñar las tablas de manera adecuada.
  • Lanzar consultas optimizadas para entornos MPP.

Diseñar las tablas de manera adecuada

Cuando se diseña la base de datos ten en cuenta que algunas decisiones clave sobre el diseño de las tablas influyen considerablemente en el rendimiento general de la consulta. Unas buenas practicas son:
  • Seleccionar el tipo de distribución de datos óptima:
    • Para las tablas de hechos (facts) elige el tipo DISTKEY. De esta manera los datos se distribuirán en los diferentes nodos agrupados por los valores de la clave elegida. Esto te permitirá realizar consultas de tipo JOIN sobre esa columna de manera muy eficiente.
    • Para las tablas de dimensiones (dimensions) con un pocos de millones de entradas elige el tipo ALL. Aquellas tablas que son comúnmente usadas en joins de tipo diccionario es recomendable que se copien a todos los nodos. De esta manera la sentencia JOIN realizada con tablas de hechos mucho más grandes se ejecutará mucho más rápido.
    • Cuando no tengas claro como vas a realizar la consulta sobre una tabla muy grande o simplemente no tenga ninguna relación con el resto, elige el tipo EVEN. De esta forma los datos se distribuirán de manera aleatoria.
  • Usa la compresión automática permitiendo a Redshift que seleccione el tipo más optimo para cada columna. Esto lo consigue realizando un escaneo sobre un número limitado de elementos.

Usar consultas optimizadas para entornos MPP

Puesto que Redshift es un entorno MPP distribuido, es necesario maximizar el rendimiento de las consultas siguiendo unas recomendaciones básicas. Unas buenas practicas son:
  • Las tablas tiene que diseñarse pensando en las consultas que se van a realizar. Por lo tanto, si una consulta no encaja es necesario que revises el diseño de las tablas que participan.
  • Evite usar SELECT *. e incluye solo las columnas que necesites.
  • No uses cross-joins a no ser que sea necesario.
  • Siempre que puedas, usa la sentencia WHERE para restringir la cantidad de datos a leer.
  • Use claves de ordenación en las cláusulas GROUP BY y SORT BY para que el planificador de consultas pueda usar una agregación más eficiente.

2. Cargar datos de aquella manera

Cargar conjuntos de datos muy grandes puede tomar mucho tiempo y consumir gran cantidad de recursos del cluster. Además si esta carga se realiza de manera inadecuada también puede afectar el rendimiento de las consultas.

Por ello, es recomendable seguir estas pautas:

  • Usa siempre el comando COPY para cargar los datos en paralelo desde Amazon S3, Amazon EMR, Amazon DynamoDB o desde distintos orígenes de datos en hosts remotos.

 copy customer from 's3://mybucket/mydata' iam_role 'arn:aws:iam::12345678901:role/MyRedshiftRole';

  • Si es posible, lanza un solo comando en vez de varios. Puedes usar un fichero manifest o patrones para cargar varios ficheros de una sola vez.

  • Divide los archivos de datos de carga de tal modo que sean:

    • De igual tamaño, entre 1 MB y 1 GB, después de la compresión.
    • Un múltiplo del número de slices de tu cluster.

  • Para actualizar los datos e insertar datos nuevos de manera eficiente al cargarlos usa una tabla provisional.

  -- Crea una tabla provisional y, luego, complétala con los datos que se fusionarán.
  create temp table stage (like target); 

  insert into stage 
  select * from source 
  where source.filter = 'filter_expression';

  -- Usa una combinación interna con la tabla provisional para eliminar las filas de la tabla destino que se están actualizando.
  begin transaction;

  delete from target 
  using stage 
  where target.primarykey = stage.primarykey; 

  -- Inserta todas las filas de la tabla provisional.
  drop table stage;
  insert into target 
  select * from stage;

  end transaction;

  -- Elimina la tabla provisional.
  drop table stage;

3. Dimensionar mal el cluster

A lo largo de los años hemos visto muchos clientes que tenían graves problemas de rendimiento con Redshift debido a fallos de diseño de sus BBDD. Muchos de ellos habían intentado resolverlos añadiendo más recursos al cluster en vez de intentar solucionar el problema de raíz.

Por ellos te propongo que sigas el siguiente flujo para dimensionar tu cluster:

  • Recolecta información sobre el tipo de consultas a realizar, tamaño de los datos, concurrencia esperada, etc.

  • Diseña tus tablas en base a las consultas que se vayan a realizar.

  • Dependiendo del tipo de consultas (sencillas, largas, complejas…), selecciona el tipo de instancia de Redshift (DC2, DS2 o RA3).

  • Teniendo en cuenta el tamaño del dataset, calcula el número nodos de tu cluster.

# of  Redshift nodes = (uncompressed data size) * 1.25 / (storage capacity of selected Redshift node type)

« Para el cálculo del tamaño de almacenamiento, se recomienda tener además un margen mayor para realizar tareas de mantenimiento. »

  • Realizar pruebas de carga para comprobar el rendimiento.

  • En el caso de no funcionar adecuadamente, optimiza las queries modificando el diseño de las tablas incluso si fuera necesario.

  • Finalmente, si no fuera suficiente, itera hasta encontrar el dimensionamiento adecuado de nodos y tamaños.

4. No hacer uso de workload management (WLM)

Es bastante probable que vuestro caso de uso necesite que existan varias sesiones o usuarios que estén ejecutando consultas al mismo tiempo. En estos casos, algunas consultas pueden consumir recursos del clúster durante periodos de tiempo prolongados y afectar al rendimiento de las otras consultas. En esta situación, es posible que las consultas sencillas tendrán que esperar hasta que se complete las consultas más largas.

Mediante el uso de WLM, vamos a poder administrar la prioridad y capacidad de los diferentes tipos de ejecuciones creando diferente colas de ejecución.

Es posible configurar la WLM de Amazon Redshift para su ejecución de dos maneras diferentes:

  • Automatic WLM: la manera más recomendada es habilitar Amazon Redshift para que administre cómo se dividen los recursos para ejecutar consultas simultáneas con WLM automático. El usuario gestiona la prioridad de las colas y Amazon Redshift determina cuántas consultas se ejecutan simultáneamente y cuánta memoria se asigna a cada consulta enviada.
  • Manual WLM: alternativamente, se puede configurar de manera manual el uso de recursos de diferente colas. En tiempo de ejecución, se pueden enviar consultas a diferentes colas con diferentes parámetros de concurrencia y memoria gestionados por el usuario.


Cómo funciona WLM

Cuando un usuario ejecuta una consulta, WLM asigna la consulta a la primera cola coincidente, en función de las reglas de asignación de cola de WLM.

  • Si un usuario inició sesión como superusuario y ejecuta una consulta en el grupo de consultas con la etiqueta super usuario, la consulta se asigna a la cola superusuario.
  • Si un usuario pertenece a un grupo de usuarios de la lista o ejecuta una consulta dentro del grupo de consultas de la lista, la consulta se asigna a la primera cola coincidente.
  • Si una consulta no cumple con ningún criterio, la consulta se asigna a la cola predeterminada, que es la última cola definida en la configuración de WLM.

5. Desentenderse del mantenimiento

El mantenimiento de la base de datos es un término que usamos para describir un conjunto de tareas que se ejecutan con la intención de mejorar la base de datos. Existen rutinas destinadas a ayudar al rendimiento, liberar espacio en disco, verificar errores de datos, verificar fallos de hardware, actualizar estadísticas internas y muchas otras cosas oscuras (pero importantes).

En el caso de Redshift, se tiene la falsa sensación de que al ser un servicio totalmente administrado por Amazon no es necesario realizar ninguna. De esta manera creas el cluster y te olvidas de él. Aunque es cierto que AWS te facilita muchas tareas de administración (crear, parar, arrancar, destruir o realizar backups), esto no podría ser más erróneo.

Las tareas de mantenimiento más importantes que debes de llevar a cabo en Redshift son:

  • Motorización del sistema: es necesario que se monitorize el cluster 24/7 y realices revisiones periódicas para comprobar que el sistema funciona correctamente (sin consultas erróneas o bloqueos, espacio libre, tiempos de respuesta adecuados, etc). Además es necesario crear alarmas para poder anticiparse ante cualquier futura caída del servicio.
  • Compactación de las BBDD: Amazon Redshift no realiza todas las tareas de compactación en todas las situaciones automáticamente y otras veces vas a necesitar ejecutarlas de manera manual. Este proceso es denominado VACUUM y es necesario ejecutarlo manualmente para poder hacer uso de SORT KEYS de tipo INTERLEAVED. Este es un proceso bastante largo y costoso que va a tener que hacerlo a poder ser, en las ventanas de mantenimiento.
  • Integridad de los datos: como en toda carga de datos es necesario revisar que los procesos de ETL han funcionado adecuadamente. Redshift dispone de tablas de sistema como STV_LOAD_STATE en las que es posible encontrar información acerca del estado actual de las instrucciones COPY en curso. Debes de revisarlas a menudo para comprobar que no hay errores en la integridad de los datos.
  • Detección de consultas pesadas: Redshift monitoriza continuamente todas aquellas consultas que están tardando más de lo previsto y que podrían estar afectando negativamente el rendimiento del servicio. Para que puedas analizar e investigar esas consultas es posible encontrarlas en tablas de sistema como STL_ALERT_EVENT_LOG o a través de la misma consola web de AWS.
¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB
Álvaro Santos
Senior Cloud Solution Architect​

Mi nombre es Álvaro Santos y ejerzo como Solution Architect desde hace más de 5 años. Estoy certificado en AWS, GCP, Apache Spark y alguna que otras más. Entré a formar parte en Bluetab en octubre de 2018 y desde entonces estoy involucrado en proyectos cloud de Banca y Energía y además participo como Cloud Master Partitioner. Soy un apasionado de las nuevas patrones distribuidos, Big Data, Open-source software y cualquier otra cosa de mundo IT que mole.

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

5 common errors in Redshift

by

5 common errors in Redshift

Alvaro Santos

Senior Cloud Solution Architect​

Amazon Redshift can be considered to be one of the most important data warehouses currently and AWS offers it in its cloud. Working at Bluetab, we have had the pleasure of using it many times during our good/bad times as well as this year 2020. So we have created a list with the most common errors you will need to avoid and we hope this will be a great aid for you.

At Bluetab we have been working around data for over 10 years. In many of them, we have helped in the technological evolution of numerous companies by migrating from their traditional Data Warehouse analytics and BI environments to Big Data environments.

Additionally, at Cloud Practice we have been involved in cloud migrations and new developments of Big Data projects with Amazon Web Services and Google Cloud. All this experience has enabled us to create a group of highly qualified people who think/work in/for the cloud

To help you with your work in the cloud, we want to present the most common mistakes we have found when working with Redshift, the most important DW tool offered by AWS.

Here is the list:

  1. Working as if it were a PostgreSQL.
  2. Load data wrongly.
  3. Dimensioning the cluster poorly.
  4. Not making use of workload management (WLM).
  5. Neglecting maintenance.

What is Redshift?

Amazon Redshift is a very fast, cloud-based analytical (OLAP) database, fully managed by AWS. It simplifies and enhances data analysis using standard SQL compatible with most existing BI tools.

The most important features of Amazon Redshift are:

  • Data storage in columns: instead of storing data as a series of rows, Amazon Redshift organises the data by column. Because only the columns involved in queries are processed and the data in columns are stored sequentially on storage media, column-based systems require much less I/O, which greatly improves query performance.
  • Advanced compression: column-based databases can be compressed much more than row-based databases because similar data is stored sequentially on disk.
  • Massively Parallel Processing (MPP): Amazon Redshift automatically distributes the data and query load across all nodes.
  • Redshift Spectrum: lets you run queries against exabytes of data stored in Amazon S3.
  • Materialized views: subsequent queries that refer to the materialized views use the pre-calculated results to run much faster. Materialized views can be created based on one or more source tables using filters, projections, inner joins, aggregations, groupings, functions and other SQL constructs.
  • Scalability: Redshift has the ability to scale its processing and storage by increasing the cluster size to hundreds of nodes.

Amazon Redshift is not the same as other SQL database systems. Good practices are required to take advantage of all its benefits, so that the cluster will perform optimally.

1. Working as if it were a PostgreSQL

A very common mistake made when starting to use Redshift is to assume that it is simply a vitamin-enriched PostgreSQL and that you can start working with Redshift based on a schema compatible with that. However, you could not be more wrong.

Although it is true that Redshift was based on an older version of PostgreSQL 8.0.2, its architecture has changed radically and has been optimised over the years to improve performance for its strictly analytical use. So you need to:

  • Design the tables appropriately.
  • Launch queries optimised for MPP environments.


Design the tables appropriately

When designing the database, bear in mind that some key table design decisions have a considerable influence on overall query performance. Some good practices are:

  • Select the optimum data distribution type: 
    • For fact tables choose the DISTKEY type. This will distribute the data to the various nodes grouped by the chosen key values. This will enable you to perform JOIN type queries on that column very efficiently.
    • For dimension tables with a few million entries, choose the ALL type. It is advisable to copy those tables commonly used in joins of dictionary type to all the nodes. In that way the JOIN statement with much bigger fact tables will execute much faster.
    • When you are not clear on how you are going to query a very large table or it simply has no relation to the rest, choose the EVEN type. The data will be distributed randomly in this way.
  • It uses automatic compression, allowing Redshift to select the optimal type for each column. It accomplishes this by scanning a limited number of items.

 

Use queries optimised for MPP environments

As Redshift is a distributed MPP environment, query performance needs to be maximised by following some basic recommendations. Some good practices are:

  • The tables need to be designed considering the queries that will be made. Therefore, if a query does not match, you need to review the design of the participating tables.
  • Avoid using SELECT *. and include only the columns you need.
  • Do not use cross-joins unless absolutely necessary.
  • Whenever you can, use the WHERE statement to restrict the amount of data to be read.
  • Use sort keys in GROUP BY and SORT BY clauses so that the query planner can use more efficient aggregation.

2. Loading data in that way

Loading very large datasets can take a long time and consume a lot of cluster resources. Moreover, if this loading is performed inappropriately, it can also affect query performance.

This makes it advisable to follow these guidelines:

  • Always use the COPY command to load data in parallel from Amazon S3, Amazon EMR, Amazon DynamoDB or from different data sources on remote hosts.

 copy customer from 's3://mybucket/mydata' iam_role 'arn:aws:iam::12345678901:role/MyRedshiftRole';

  • If possible, launch a single command instead of several. You can use a manifest file or patterns to upload multiple files at once.

  • Split the load data files so that they are:

    • Of equal size, between 1 MB and 1 GB after compression.
    • A multiple of the number of slices in your cluster.

  • To update data and insert new data efficiently when loading it, use a staging table.

  -- Create an staging table and load it with the data to be updated
  create temp table stage (like target); 

  insert into stage 
  select * from source 
  where source.filter = 'filter_expression';

  -- Use an inner join with the  staging table to remove the rows of the target table to be updated

  begin transaction;

  delete from target 
  using stage 
  where target.primarykey = stage.primarykey; 

  -- Insert all rows from the of the staging table.
  insert into target 
  select * from stage;

  end transaction;

  -- Drop the staging table.
  drop table stage;

3. Dimensioning the cluster poorly

Over the years we have seen many customers who had serious performance issues with Redshift due to design failures in their databases. Many of them had tried to resolve these issues by adding more resources to the cluster rather than trying to fix the root problem.

Due to this, I suggest you follow the flow below to dimension your cluster:

  • Collect information on the type of queries to be performed, data set size, expected concurrency, etc.

  • Design your tables based on the queries that will be made.

  • Select the type of Redshift instance (DC2, DS2 or RA3) depending on the type of queries (simple, long, complex…).

  • Taking the data set size into account, calculate the number of nodes in your cluster.

# of  Redshift nodes = (uncompressed data size) * 1.25 / (storage capacity of selected Redshift node type)

« For storage size calculation, having a larger margin for performing maintenance tasks is also recommended »

  • Perform load tests to check performance.

  • If it does not work adequately, optimise the queries, even modifying the design of the tables if necessary.

  • Finally, if this is not sufficient, iterate until you find the appropriate node and size dimensioning.

4. Not making use of workload management (WLM)

It is quite likely that your use case will require multiple sessions or users running queries at the same time. In these cases, some queries can consume cluster resources for extended periods of time and affect the performance of the other queries. In this situation, simple queries may have to wait until longer queries are complete.

By using WLM, you will be able to manage the priority and capacity of the different types of executions by creating different execution queues.

You can configure the Amazon Redshift WLM to run in two different ways:

  • Automatic WLM: the most advisable manner is to enable Amazon Redshift so that it manages how resources are split to run concurrent queries with automatic WLM. The user manages queue priority and Amazon Redshift determines how many queries run simultaneously and how much memory is allocated to each query submitted.
  • Manual WLM: alternatively, you can configure resource use for different queues manually. At run time, queries can be sent to different queues with different user-managed concurrency and memory parameters.


How WLM works

When a user runs a query, WLM assigns the query to the first matching queue, based on the WLM queue assignment rules.

 
  • If a user is logged in as a superuser and runs a query in the query group labelled superuser, the query is assigned to the superuser queue.
  • If a user belongs to a listed user group or runs a query within a listed query group, the query is assigned to the first matching queue.
  • If a query does not meet any criterion, the query is assigned to the default queue, which is the last queue defined in the WLM configuration.

5. Neglecting maintenance.

Database maintenance is a term we use to describe a set of tasks executed with the intention of improving the database. There are routines to help performance, free up disk space, check data errors, check hardware faults, update internal statistics and many other obscure (but important) things.

In the case of Redshift, there is a mistaken feeling that as it is a service fully managed by Amazon, there is no need for any. So you create the cluster and forget about it. While AWS makes it easy for you to manage numerous tasks (create, stop, start, destroy or perform back-ups), this could not be further from the truth.

The most important maintenance tasks you need to perform in Redshift are:

  • System monitoring: the cluster needs monitoring 24/7 and you need to perform periodic checks to confirm that the system is functioning properly (no bad queries or blocking, free space, adequate response times, etc.). You also need to create alarms to be able to anticipate any future service downtimes.
  • Compacting the DB: Amazon Redshift does not perform all compaction tasks automatically in all situations and you will sometimes need to run them manually. This process is called VACUUM and it needs to be run manually to be able to use SORT KEYS of the INTERLEAVED type. This is quite a long and expensive process that will need to be performed, if possible, during maintenance windows.
  • Data integrity: as with any data loading, you need to check that the ETL processes have worked properly. Redshift has system tables such as STV_LOAD_STATE where you can find information on the current status of the COPY instructions in progress. You should check them often to confirm that there are no data integrity errors.
  • Detection of heavy queries: Redshift continuously monitors all queries that are taking longer than expected and that could be negatively impacting service performance. So that you can analyse and investigate those queries, you can find them in system tables as STL_ALERT_EVENT_LOG or through the AWS web console itself.
Do you want to know more about what we offer and to see other success stories?
DISCOVER BLUETAB
Álvaro Santos
Senior Cloud Solution Architect​

My name is Álvaro Santos and I have been working as Solution Architect for over 5 years. I am certified in AWS, GCP, Apache Spark and a few others. I joined Bluetab in October 2018, and since then I have been involved in cloud Banking and Energy projects and I am also involved as a Cloud Master Partitioner. I am passionate about new distributed patterns, Big Data, open-source software and anything else cool in the IT world.

SOLUTIONS, WE ARE EXPERTS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

You may be interested in

Hashicorp Boundary

by

Hashicorp Series Boundary

Javier Pérez

DevOps Engineer

Javier Rodriguez

Cloud DevOps

Jorge de Diego

Cloud DevOps Engineer

Después de la última HashiConf Digital, desde la Práctica Cloud os queremos enseñar una de las principales novedades que fueron presentadas: Boundary. En este post vamos a comentar qué es esta nueva herramienta, por qué es interesante, qué nos ha parecido y cómo lo hemos probado.

¿Qué es Hashicorp Boundary?

Hashicorp Boundary es, como ellos mismos declaran, una herramienta que permite acceder a cualquier sistema utilizando la identidad como pieza fundamental. ¿Esto qué significa? Tradicionalmente, cuando un usuario adquiere el permiso de acceder a un servicio remoto, también obtiene el permiso explícito a la red donde se encuentra ubicado. Sin embargo, Boundary nos proporcionará un sistema basado en el mínimo privilegio posible cuando los usuarios necesitan acceder a aplicaciones o máquinas. Por ejemplo, es una forma de acceder mediante SSH a un único servidor utilizando como método de autenticación unas claves efímeras.

Esto quiere decir que Boundary limita a qué recursos te puedes conectar y además gestiona los diferentes permisos y accesos a los recursos con una autenticación.

Es especialmente interesante porque en el futuro va a estar marcado por la fuerte integración que tendrá con otras herramientas de Hashicorp, especialmente con Vault para la gestión de credenciales, así como con sus funciones de auditoria.

Por si tenéis curiosidad, Hashicorp ha liberado el código fuente de Boundary el cual tenéis disponible en Github y la documentación oficial la podréis leer en su pagina web: boundaryproject.

¿Cómo hemos puesto a prueba Boundary?

Partiendo de un proyecto de Hashicorp de ejemplo, se ha desarrollado una pequeña prueba de concepto que despliega Boundary en un escenario hybrid-cloud en AWS y GCP. Aunque la arquitectura de referencia no decía nada con respecto a este diseño, nosotros hemos querido darle una vuelta y montar un pequeño escenario multi-cloud para ver cómo se comporta este nuevo producto.

La arquitectura final a grandes rasgos es:

Una vez desplegada la infraestructura y configurada la aplicación hemos probado a conectarnos a las instancias mediante SSH. Todo el código fuente se basa en terraform 0.13 y lo podréis encontrar en Bluetab-boundary-hybrid-architecture, en donde también encontraréis un README detallado que especifica las acciones que tenéis que seguir para reproducir el entorno, en particular:

  1. Autenticación con vuestro usuario (previamente configurado) en Boundary. Para ello apuntamos al endpoint correspondiente a los controladores de Boundary y ejecutamos el comando boundary authenticate.

  2. Ejecutar el comando boundary connect ssh con los argumentos necesarios para apuntar a nuestro target (El target representa una o más máquinas o endpoints).

En este escenario particualr, el target se compone de dos máquinas diferentes: una en AWS y otra en GCP. Si a Boundary no se le indica a qué máquina en concreto se quiere acceder de ese target, Boundary proporcionará acceso de forma aleatoria a una de ellas. De manera automática una vez seleccionada la máquina a la que se quiere acceder, Boundary enrutará la petición hacia el worker adecuado, que es el que tiene acceso a dicha máquina.

¿Qué nos ha gustado?

  • La facilidad de configuración. Boundary sabe perfectamente a qué worker tiene que dirigir la petición teniendo en cuenta a qué servicio o máquina se está solicitando el acceso. Como todo el despliegue (tanto infraestructura como aplicación) se ha hecho desde terraform, la salida de un despliegue sirve como entrada del otro y está todo perfectamente integrado.

  • Ofrece tanto interfaz gráfica como acceso CLI. Aunque aún está en una fase muy temprana del desarrollo, el mismo binario de Boundary ofrece (cuando es configurado como controller) una interfaz gráfica muy limpia, con el mismo estilo que las diferents herramientas de Hashicorp. Sin embargo, no todas las funcionalidades se pueden realizar actualmente desde la interfaz, por lo que es necesario utilizar la CLI.

¿Qué hemos echado en falta?

  • La integración con Vault y los indentity providers (IdPs) todavía esta en el roadmap y hasta siguientes versiones no es seguro que se incluya.

  • La gestión actual del JWT token del cliente de Boundary hacia el control-plane que implica instalar una herramienta para la gestión de secretos.

¿Qué nos falta por probar?

Teniendo en cuenta el nivel de avance del desarrollo del producto actual, nos faltaría por entender y probar para:

  • Gestión de accesos modificando políticas a diferentes usuarios.

  • Realizar una investigación más profunda en los componentes que sirven para gestionar los recursos (scopes, organizations, host sets, etc.)

¿Por qué creemos que este producto tiene potencial?

Una vez que el producto vaya cumpliendo fases en el roadmap que Hashicorp ha declarado, simplificará muchísimo la gestión de accesos a máquinas a través de bastiones en las organizaciones. Se podrá gestionar el acceso a una máquina simplemente añadiendo o modificando los permisos que un usuario posee, sin tener que distribuir claves ssh, realizar operaciones manuales en las máquinas, etc.

En resumen, este producto nos brinda una nueva forma de gestionar accesos a diferentes recursos. No solamente mediante SSH, sino que será una forma de gestionar accesos mediante roles a máquinas, bases de datos, portales, etc. minimizando el posible vector de ataque cuando se dan permisos a contratistas. Además se presenta como una herramienta gratuita y opensource, que se integrará muy eficazmente si se tiene el ecosistema de Hashicorp desplegado, pero también servirá en caso contrario sin necesidad del resto de herramientas de esta compañía.

Y una cosa más...

Nos surgió un problema causado por la forma en la que se persistía la información sobre las direcciones de red de los controllers y los workers para su posterior comunicación. Después de hacer funcionar la prueba de concepto mediante un workaround basado en iptables decidimos abrir una https://github.com/hashicorp/boundary/issues/758 en Github. En literalmente un día, nos resolvieron la incidencia actualizando su código. Nos descargamos la nueva versión del código, lo probamos y funcionó a la perfección. Punto a favor para Hashicorp por la rapidez de respuesta y la eficiencia que demostraron. Además, recientemente ha sido liberada la nueva release de Boundary, la cual incluye entre muchas otras cosas, el fix a esta issue Boundary v0.1.2.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Hashicorp Boundary

by

Hashicorp Series Boundary

Javier Pérez

DevOps Engineer

Javier Rodriguez

Cloud DevOps

Jorge de Diego

Cloud DevOps Engineer

After the last HashiConf Digital, the Cloud Practice wants to present you one of the main innovations that were presented: Boundary. In this post we are going to discuss what offers this new tool, why it is interesting, what we have found and how we have tested it.

What is Hashicorp Boundary?

Hashicorp Boundary is, as themselves claim, a tool that allows access any system using identity as a fundamental piece. What does this really mean?
Traditionally, when a user acquires the permission to access a remote service, he or she also gets explicit permission to the network where the service resides. However, Boundary, following the minimum privilege principle, provides us with an identity-based system for users who need access to applications or machines. For example, it is an easy way of access to a server via SSH using ephemeral keys as authentication method.

This means that Boundary limits what resources you can connect to and also manages the different permissions and accesses to resources with an authentication.

It is especially interesting because in the future it will be marked by the strong integration that it will have with other Hashicorp tools, especially Vault for credentials management and audit capabilities.

In case you are curious, Hashicorp has released the source code of Boundary which you have available at Github and the official documentation can be read on their website:
boundaryproject.

How have we tested Boundary?

BBased on an example project from Hashicorp, we have developed a small proof of concept that deploys Boundary in a hybrid-cloud scenario in AWS and GCP. Although the reference architecture does not said nothing about this design, we wanted to complete the picture and
set up a small multi-cloud stage to see how this new product.

The final architecture in broad terms is:

Once the infrastructure has been deployed and the application configured, we have tested connecting to the instances through SSH. All the source code is based on terraform 0.13 and you can find it in Bluetab-boundary-hybrid-architecture, where you will also find a detailed README that specifies the actions you have to follow to reproduce the environment, in particular:

  • Authentication with your user (previously configured) in Boundary. To accomplish this, you have to set the Boundary controllers endpoint and execute the following command: boundary authenticate.
  • Execute: boundary connect ssh with the required parameters to point to the selected target (this target represents one or more instances or endpoints)

In this particular scenario, the target is composed by two different machines:
one in AWS and one in GCP. If Boundary is not told which particular instance you want to access from that target, it will provide access to one of them randomly. Automatically, once you have selected the machine you want to access, Boundary will route the request to the appropriate worker, who has access to that machine.

What did we like?

  • The ease of configuration. Boundary knows exactly which worker has to address the request taking into account which service or machine is being requested.
    As the entire deployment (both infrastructure and application) has been done using terraform, the output of one deployment serves as the input of the other and everything is perfectly integrated.

  • It offers both graphic interface and CLI access. Despite being in a very early stage of development, the same binary includes (when configured as controller) a very clean graphical interface, in the same style as the rest of the Hashicorp tools. However, as not all functionality is currently implemented through the interface it is necessary to make configuration using the CLI.

What would we have liked to see?

  • Integration with Vault and indentity providers (IdPs) is still in the roadmap and until next versions it is not sure that it will be included.

  • The current management of the JWT token from the Boundary client to the control plane which involves installing a secret management tool.

What do we still need to test?

Considering the level of progress of the current product development, we would be missing for understanding and trying to:

  • Access management by modifying policies for different users.

  • Perform a deepest research on the components that manage resources (scopes, organizations, host sets, etc.)

Why do we think this product has great future?

Once the product has completed several phases in the roadmap that Hashicorp has established, it will greatly simplify resources access management through bastions in organizations. Access to instances can be managed simply by adding or modifying the permissions that a user has, without having to distribute ssh keys, perform manual operations on the machines, etc.

In summary, this product gives us a new way to manage access to different resources. Not only through SSH, but it will be a way to manage access through roles to machines, databases, portals, etc. minimizing the possible attack vector when permissions are given to contractors. In addition, it is presented as a free and open source tool, which will not only integrate very effectively if you have the Hashicorp ecosystem deployed, but will also work seamlessly without the rest of Hashicorp’s tools.

One More Thing…

We encountered a problem caused by the way in which the information about the network addresses of controllers and workers for subsequent communication was stored. After running our scenario with a workaround based on iptables we decided to open a issue on Github. In only one day, they solved the problem by updating their code. We downloaded the new version of the code, tested it and it worked perfectly. Point in favour for Hashicorp for the speed of response and the efficiency they demonstrated. In addition, recently it has been published a new release of Boundary, including this fix along with many other features Boundary v0.1.2.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Calidad del dato de la información de seguros

by

Calidad del dato de la información de seguros

Nuestro cliente es una de las mayores entidades financieras con presencia principalmente en Europa y América; entre las tres mayores aseguradoras del mercado en México y líder también en las geografías que opera. En los últimos años ha emprendido una transformación digital logrando crear una plataforma tecnológica de última generación.

En Bluetab México somos uno de los principales partners del grupo y hemos colaborado con ellos,  realizando un profundo análisis, para poder identificar los problemas de calidad de datos en los activos informacionales de su rama de Seguros; realizando reingeniería de raíz de algunos procesos para asegurar la calidad de la información, así como también en el desarrollo y automatización de procesos para estructurar la información del día a día, de forma que cumpla con los estándares marcados en la plataforma de Big Data de nuestro cliente.

El alcance de este proyecto es brindar a nuestro cliente mecanismos que le permitan aprovechar una de sus ventajas competitivas utilizando la información que posee sobre sus clientes, que es una de las carteras más grandes del país y transformarla en conocimiento para ofrecer a éstos una mejor experiencia a través de una oferta personalizada.

Un beneficio adicional es que cuenta con información fiable, disponible y ordenada que le permite cumplir con la calidad adecuada para sus procesos regulatorios y de toma de decisiones.

CASOS DE ÉXITO

Quality of insurance information data

by

Quality of insurance information data

Our client is a major financial institution with presence mainly in Europe and America; among the three largest insurers in the market in Mexico and also a leader in the regions where it operates. It has undertaken a digital transformation in recent years, creating a state-of-the-art technology platform.

We at Bluetab Mexico are one of the group’s main partners and we collaborated with them by carrying out a thorough analysis to identify data quality problems in IT assets in their Insurance arm; performing re-engineering from the root of some processes to ensure information quality; as well as developing and automating processes to structure day-to-day information so that this meets the standards set in our client’s Big Data platform.

The scope of this project is to provide our client with mechanisms to let them take advantage of one of their competitive advantages, using the information they have about their clients in one of the largest portfolios in the country, and transform it into knowledge to offer them a better experience through a personalised offering.

An additional benefit is having reliable, available, ordered information of adequate quality to meet their needs for their regulatory and decision-making processes.

SUCCESS STORIES

© 2025 Bluetab Solutions Group, SL. All rights reserved.