REUNIÓN CON SSDD

Arquitectura en el GRUPO DIA, duda frecuentes,

roadmap colaboración con Ricoh en SSDD, etc.

In strict confidence – datos de SSDD del Grupo DIA para Ricoh

Índice
1. Introducción........................................................................................................................................................2
2. Regiones y zonas de disponibilidad en Amazon...................................................................................................2
2.1 Aplicado a DIA............................................................................................................................................4
3. Esquema de la Arquitectura.................................................................................................................................4
4. Base de datos.......................................................................................................................................................5
4.1 Transaccional:............................................................................................................................................5
4.2 Configuración activo – pasivo.....................................................................................................................5
4.3 Oracle en AWS (Amazon Web Services).....................................................................................................5
5. Cómo se levanta la arquitectura..........................................................................................................................6
5.1 La AMI de Ubuntu......................................................................................................................................6
5.2 Hacerlo a mano o mediante scripts............................................................................................................6
5.3 Ansible.......................................................................................................................................................6
5.4 Sysdiff.........................................................................................................................................................8
6. Ansible Tower......................................................................................................................................................8
6.1 Qué hay en Ansible Tower.........................................................................................................................8
6.2 Cómo se gestionan los datos del Tower...................................................................................................12
7. Despliegues en frío vs en caliente......................................................................................................................12
8. Jenkins............................................................................................................................................................... 13
8.1 Jenkins que tienen montados en DIA.......................................................................................................13
9. Jenkins y DevOps (con Ansible)..........................................................................................................................13
10. Monitorización de la Arquitectura................................................................................................................14
10.1 Cloudwatch..............................................................................................................................................14
10.2 Sensu........................................................................................................................................................14
10.3 Kibana:.....................................................................................................................................................14
10.4 Pingdom...................................................................................................................................................15
10.5 Dynatrace.................................................................................................................................................15
11. Problemas recurrentes..................................................................................................................................16
11.1 Alertas......................................................................................................................................................16
11.2 Pruebas....................................................................................................................................................16
11.3 Consultas que negocio quiere hacer contra BD en tiempo real................................................................16
11.4 Cuáles son los límites de nuestro sistema................................................................................................18
11.5 Nginx vs apache........................................................................................................................................18
11.6 Redirecciones...........................................................................................................................................19
11.7 Seguridad.................................................................................................................................................19
12. Cambios en la arquitectura...........................................................................................................................19
13. Notas............................................................................................................................................................. 20
13.1 Las pizarras con las explicaciones:............................................................................................................20
13.2 Herramientas...........................................................................................................................................21
 1. Introducción
A raíz de la incipiente colaboración de Germán con SSDD, se hizo una reunión para resumir el
estado actual de la arquitectura y las tareas más importantes que quedan por hacer.

Os resumo lo que entendí, que puede distar mucho de lo que realmente dijera Justo. Cogedlo
con pinzas, por favor. Es un documento informal, aunque también confidencial. He incluido los
enlaces que he ido consultando para descifrar lo que nos contó. Los textos copiados van en
cursiva.

2. Regiones y zonas de disponibilidad en Amazon

Zonas de disponibilidad y regiones de AWS

La infraestructura de la nube de AWS está compuesta de regiones y zonas de disponibilidad.

Las regiones de AWS proporcionan varias zonas de disponibilidad físicamente independientes
y aisladas que se encuentran conectadas mediante redes de alto desempeño y redundancia, y
baja latencia. […]

https://aws.amazon.com/es/about-aws/global-infrastructure/
 2.1 Aplicado a DIA
DIA tiene una cuenta en Amazon para cada proyecto, así que hay una para eCommerce
(bueno, realmente hay tres, una para DEV: dev-dia-ecommerce, otra para STAG: sta-dia-
ecommerce y otra para PRO: pro-dia-ecommerce).

- Irlanda fue el primero CPD (centro de procesamiento de datos) abierto en Europa y es

donde estamos nosotros. Concretamente nuestra región: es eu-west-1 (Irlanda)

- Y las máquinas están repartidas en 3 zonas de disponibilidad.

La gracia de esto cada zona de disponibilidad está completamente aislada. Por tanto, si se
cae una zona de disponibilidad, las otras no deberían verse afectadas, lo que hace que el
servicio sea más robusto.

o Entendemos que el ELB es un servicio con una robustez garantizada por Amazon.
o Son los servidores de aplicación que uno declara (las máquinas) ya se pueden
repartir en la zona de disponibilidad que se quiera. Por eso para las APPs un cada
uno de los 3 servidores está en una zona de disponibilidad diferente.

3. Esquema de la Arquitectura
 4. Base de datos
Nuestra BD de Oracle es transaccional configurada en activo – pasivo. Por si también tenéis
que hacer memoria:

4.1 Transaccional:
A transactional database is a database management system (DBMS) that has the capability to
roll back or undo a database transaction or operation if it is not completed appropriately.

Whenever information or data is stored, manipulated, or “managed” in a database, the operation

is considered to be a database transaction. The term indicates that there has been work
accomplished within the database management system or in the database itself. In order to
ensure security, a database transaction occurs separately from other transactions within the
system to ensure that all information stored remains accessible, secure, and coherent.

http://www.tech-faq.com/transactional-database.html

4.2 Configuración activo – pasivo

Muy resumido:

Esto da para un libro. Si alguien tiene curiosidad un sitio donde hay más detalle:
https://docs.oracle.com/cd/B28359_01/server.111/b28281/architectures.htm#i1008366

4.3 Oracle en AWS (Amazon Web Services)

Por lo visto AWS tiene capadas las interfaces de Oracle. Lo que ofrece, son paquetes para que
interactuemos mediante AWS, pero no directamente contra Oracle. Esto a veces dificulta las
cosas, como por ejemplo hacer dumps (volcados) de la base de datos. La solución pasa por
usar “procedimientos almacenados” (scripts).

Por ejemplo, para el caso de los dumps, Justo ha hecho un script en Pearl que hace lo
siguiente:

- Guarda la copia en claro (sin comprimir)

- Luego hay que comprimir la copia
- Y enviarla (de PRO a STAG o DEV o RED80…) Importante: el envío tiene un coste
- Cuando se recibe en el destino, hay que lanzar otro script para descomprimirlo
- Y otro script para cargarlo
- Etc.

Total, que al final ser tarda varios días en hacer esto, razón por la que en SSDD no son muy
favorables a hacer dumps con frecuencia.
 5. Cómo se levanta la arquitectura
Lo que apunté: Se arranca desde la AMI de Ubuntu 16.04 (esto es levantar una máquina vacía
con sólo un Linux instalado). A esto se le pasa un script, que se usa para automatizar el resto
del proceso de configuración de la arquitectura. El script lo primero que hace es crear un
usuario Ansible. Luego crea el grupo Sysdiff… Después se le da permisos (le crea la SUDO al
usuario Ansible), para finalmente poder ejecutar todos los Jobs desde el Tower con este
usuario Ansible.

Nota: Una vez está configurado el usuario Ansible lo que hacía antes es ir al Tower para
realizar una serie de procesos. Pero lo están cambiando (pdte. actualización).

Para quienes no sabemos de arquitectura, esto suena algo abstracto. Pero buscado más
información de algunos puntos más o menos se acaba entendiendo la idea:

5.1 La AMI de Ubuntu

As Ubuntu cloud images are uploaded and registered on the Amazon EC2 [Amazon Elastic
Compute] cloud, they are referred to as AMI (Amazon Machine Images). Each AMI is a
machine template from which you can instantiate new servers. Each AMI has its own
unique ID. In order to launch an instance on the EC2 cloud, you first need to locate its ID. This
page helps you quickly locate an AMI ID. Here’s how to use it [..]

https://cloud-images.ubuntu.com/locator/ec2/

5.2 Hacerlo a mano o mediante scripts

Cuando se lanza una instancia en Amazon EC2, tiene la opción de transmitir los datos de
usuario a la instancia que se pueden utilizar para realizar tareas de configuración automáticas
comunes e incluso ejecutar scripts después de que se inicie la instancia. Puede transferir dos
tipos de datos de usuario a Amazon EC2: scripts de shell y directivas cloud-init.
https://docs.aws.amazon.com/es_es/AWSEC2/latest/UserGuide/user-data.html

5.3 Ansible
Según su propia web, Ansible sirve para:
Ansible is a radically simple IT automation engine that automates cloud provisioning,
configuration management, application deployment, intra-service orchestration, and many other
IT needs. Designed for multi-tier deployments since day one, Ansible models your IT
infrastructure by describing how all of your systems inter-relate, rather than just managing one
system at a time.It uses no agents and no additional custom security infrastructure, so it's easy
to deploy - and most importantly, it uses a very simple language (YAML, in the form of Ansible
Playbooks) that allow you to describe your automation jobs in a way that approaches plain
English. http://docs.ansible.com/ansible/latest/become.html
Y el SUDO lógicamente es el tema de los permisos:
Ansible allows you to ‘become’ another user, different from the user that logged into the
machine (remote user). This is done using existing privilege escalation tools, which you
probably already use or have configured, like sudo, su, pfexec, doas, pbrun, dzdo, ksu and
others. http://docs.ansible.com/ansible/latest/become.html

El programa sudo (del inglés super user) es una utilidad de los sistemas operativos tipo Unix,
como Linux, BSD, o Mac OS X, que permite a los usuarios ejecutar programas con los
privilegios de seguridad de otro usuario (normalmente el usuario root) de manera segura,
convirtiéndose así temporalmente en superusuario.

5.3.1 Ansible vs otros sistemas

Hay más herramientas como Ansible, de las que nos hablaron en el evento de DevOps: Puppet,
SaltStack, etc. Por lo visto Puppet está muy bien para hacer cosas sencillas y SaltStack no
parecía tener tanta documentación. En cambio, vieron que en la comunidad “Galaxy” de
Ansible hay documentación para todo, por eso optaron por usar esta solución.
http://docs.ansible.com/ansible/latest/galaxy.html

5.3.2 Variantes de Ansible

Dentro del porfolio de Red Hat hay dos variantes de Ansible:
The Ansible project has grown over time, moving from just managing Linux servers to managing
different types of devices: servers, virtual machines, containers, networking hardware, Windows
platforms… even smart light bulbs. With the breadth of abilities to automate highly
heterogeneous environments we received more requests for additional Red Hat offerings for
diverse automation use cases. Red Hat Ansible Engine is now available for individuals and
small teams to receive support for their Ansible environment, even if they do not need enterprise
scalability via Ansible Tower. […]

1. Red Hat Ansible Engine

Product and support offering based on the Ansible project that leverages a simple,
powerful, agentless automation framework for most IT environments.
2. Red Hat Ansible Tower
Product and support offering that helps teams manage complex multi-tier deployments
by adding control, knowledge, and delegation to Ansible-powered environments.
Es la que utilizan en DIA, por ahora – están barajando pasar a Engine.

https://www.ansible.com/blog/red-hat-ansible-automation-engine-vs-tower
 5.4 Sysdiff
Cloning and Alternate Rollout Methods

One of the most popular ways of performing mass Windows rollouts (typically hundreds of
computers) in corporate environments is based on the technique of disk cloning. A system
administrator installs the base operating system and add-on software used in the company on a
template computer. After configuring the machine for operation in the company network,
automated disk or system duplication tools […] are used to copy the template computer's drives
onto tens or hundreds of computers. These clones are then given final tweaks, such as the
assignment of unique names, and then used by company employees.

Another popular way of rolling out is by using the Microsoft sysdiff utility (part of the Windows
Resource Kit). This tool requires that the system administrator perform a full install (usually a
scripted unattended installation) on each computer, and then sysdiff automates the application
of add-on software install images.
https://docs.microsoft.com/en-us/sysinternals/downloads/newsid

6. Ansible Tower
6.1 Qué hay en Ansible Tower
A continuación, Justo nos explicó cómo tienen configurado todo en Ansible Tower.

La definición oficial es:

Ansible Tower
Red Hat® Ansible® Tower helps you scale IT automation, manage complex deployments and
speed productivity. Centralize and control your IT infrastructure with a visual dashboard, role-
based access control, job scheduling, integrated notifications and graphical inventory
management. And Ansible Tower's REST API and CLI make it easy to embed Ansible Tower
into existing tools and processes.
https://www.ansible.com/products/tower
https://www.ansible.com/products/tower/demo

Por lo que entendí, dentro del Tower hay estos elementos relevantes para nosotros:

1. Inventarios
2. Job Templates
3. Jobs

+ Variables
 6.1.1 Inventarios
An inventory is a collection of hosts against which jobs may be launched. Inventories are
divided into groups and these groups contain the actual hosts.[…]
http://docs.ansible.com/ansible-tower/2.3.0/html/userguide/inventories.html

Aquí se registran máquinas, grupos de máquinas, etc. Para DIA lo han estructurado en este
orden: 1º País, 2º Proyecto, etc.

Además, en el Tower se pueden declarar variables a diferentes niveles (la numeración es mía).
Un ejemplo de un dato que está en variable es la versión de Hybris.
 6.1.2 Job Templates
A job template is a definition and set of parameters for running an Ansible job. Job
templates are useful to execute the same job many times. While the REST API allows
executing jobs directly, Tower requires first creating a job template.[…]. The Job Templates
tab also enables the user to launch, schedule, modify, and remove a job template.
http://docs.ansible.com/ansible-tower/2.3.0/html/userguide/job_templates.html

Al definir Job Templates se pueden especificar una serie de propiedades. Ejemplos:

6.1.2.1 Limit
Por ejemplo, en el campo “limit” se puede indicar a qué host aplicar la Job Template.
Limit: A host pattern to further constrain the list of hosts managed or affected by the playbook.
Multiple patterns can be separated by colons (”:”). As with core Ansible, “a:b” means “in group a
or b”, “a:b:&c” means “in a or b but must be in c”, and “a:!b” means “in a, and definitely not in b”.

6.1.2.2 Playbook
Otro campo importante es el de “Playbook”. Los Playbooks básicamente son guiones paso a
paso sobre cómo hacer una tarea.
Playbook: Choose the playbook to be launched with this job template from the available
playbooks. This menu is automatically populated with the names of the playbooks found in the
project base path for the selected project. For example, a playbook named “jboss.yml” in the
project path appears in the menu as “jboss”.

Simply put, playbooks are the basis for a really simple configuration management and multi-
machine deployment system, unlike any that already exist, and one that is very well suited to
deploying complex applications.

Playbooks can declare configurations, but they can also orchestrate steps of any manual
ordered process, even as different steps must bounce back and forth between sets of machines
in particular orders. They can launch tasks synchronously or asynchronously.
http://docs.ansible.com/ansible/latest/playbooks_intro.html

En DIA utilizan dos tipos de Templates:

1) Templates de instalación
install-hybris.app
install-hybris.cas
etc.

Un ejemplo sería una receta para instalar Hybris:

1. Conéctate a la máquina…
2. Instala la jdk 1.8
3. Instala la jce (Java Cryptography Extension)
4. Ve al backend del deploy y bájate el .tgz (los binables de Hybris)…
5. Lo descomprime
6. Etc.

2) Templates de deploy (despliegue)

Un ejemplo sería:
1. Bájate …
2. Descomprime…
3. Conviértete en usuario de Hybris
4. Ejecuta el ant (por ahora esto sólo está para despliegues en frío)
6.1.3 Jobs
A job is an instance of Tower launching an Ansible playbook against an inventory of hosts.
The Jobs link displays a list of jobs and their status–shown as completed successfully or failed,
or as an active (running) job.
http://docs.ansible.com/ansible-tower/2.3.0/html/userguide/jobs.html
Un Job es la ejecución, en un momento dado, de un Job Template, con las variables y los
límites que le indiques.

Cuando el Job se ejecuta se puede ir trazando por todas las máquinas que va pasando.

6.2 Cómo se gestionan los datos del Tower

6.2.1 Las variables del Tower
Todas las variables están centralizadas en un repositorio GIT: git.lares.ssdd.es.tower
Que tiene su develop y su master.

En los ficheros de configuración de Hybris hacemos referencia a una variable. Parece que
utilizan un script de Phyton para resolver estas referencias.

6.2.2 Los templates del Tower

Todos los templates están centralizadas en otro repositorio GIT: git.lares.ssdd.ansibleplaybook

7. Despliegues en frío vs en caliente

Tocamos el tema de refilón. Actualmente sólo tiene automatizado el despliegue en frío. La
diferencia principal es:

- Despliegue en frío
1. Saca TODAS las máquinas del ELB
2. Hace la instalación, etc.

- Despliegue en caliente
o Saca una máquina del ELB
o Para el Tomcat
o Ejecuta el ant (de despliegue, entiendo) en esa máquina
o Arranca el Tomcat
o Hace un health check contra una URL y mira si está levantado el servicio. Si está
bien continúa al siguiente paso. Si no, tiene 60 reintentos, uno cada 10 segundos,
durante los cuales vuelve a intentar el health check.

Si el health check ha ido bien, meta la máquina otra vez en el ELB.

8. Jenkins
8.1 Jenkins que tienen montados en DIA
En DIA tienen montados 2 Jenkins:
 1. El de compilación / calidad / etc.
Este es el conocemos nosotros, donde se lanzan las métricas de Sonar de Pablo H, etc.
2. El de ejecución de DevOps (para Ansible)

Lo que les falta por hacer es, cuando termine la ejecución del Jenkins de Ansible se vuelque
toda la información en los logs del Jenkins de Compilación para que los podamos ver nosotros.

9. Jenkins y DevOps (con Ansible)

Desde el Jenkins de QA se lanza el job del formulario. Éste llama a otros Jobs. Esto se hace así,
porque si programas un único job monolítico y cambia algo tendrías que tocar en todos los
jobs monolíticos afectados. Como con todo código, vamos.

El caso es que el job de despliegue ya llama al Jenkins de DevOps. La gracia de este es que está
en la misma máquina que el Tower de Ansible. La razón es que el Tower sólo escucha al
interfaz interno, por eso no pueden poner un cliente del Tower en el Jenkins de Calidad. Así
que el cliente del Tower está junto al Jenkins de DevOps y el Tower en la misma máquina.

Nota: Obviamente cuando se lanzan los Jobs estos afectan a las máquinas, así que están
viendo cómo mejorar esto.
Hay un proyecto en marcha para cambiar esto. Pablo H. está convirtiendo los Jobs en librerías
de groovy y después convertirá al formulario en un pipeline.

10. Monitorización de la Arquitectura

Como en todo, hay montones de herramientas para monitorizar la arquitectura y el uso que se
hace de esta. En DIA utilizan, entre otras:

10.1 Cloudwatch
Para monitorizar la infraestructura. Saca gráficas, pero no tienen puestas alarmas.
https://aws.amazon.com/es/cloudwatch/?
sc_channel=PS&sc_campaign=acquisition_ES&sc_publisher=google&sc_medium=english_clou
dwatch_b&sc_content=cloudwatch_e&sc_detail=cloudwatch&sc_category=cloudwatch&sc_seg
ment=165202476905&sc_matchtype=e&sc_country=ES&s_kwcid=AL!4422!3!165202476905!
e!!g!!cloudwatch&ef_id=WoPyrwAAAMfhXzRz:20180216072129:s

10.2 Sensu
Para monitorizar aplicaciones y el RDS (Amazon Relational Database Service). Esta
monitorización no la realiza SSDD si no un servicio de 24h que tiene contratado DIA con la
empresa Iconic.

https://sensuapp.org
http://www.iconicgroup.com.mx/

10.3 Kibana:
Para monitorizar el ESB.
Kibana is an open source data visualization plugin for Elasticsearch. It provides visualization
capabilities on top of the content indexed on an Elasticsearch cluster. Users can create bar, line
and scatter plots, or pie charts and maps on top of large volumes of data.
https://www.elastic.co/products/kibana
 10.3.1 Inciso sobre Elasticsearch y cómo está montado en DIA
Elasticsearch is a search engine […]. It provides a distributed, multitenant-capable full-text
search engine with an HTTP web interface and schema-free JSON documents. Elasticsearch is
developed in Java and is released as open source under the terms of the Apache License.
Official clients are available in Java, .NET (C#), PHP, Python, Apache Groovy and many other
languages. [...] Elasticsearch is developed alongside a data-collection and log-parsing engine
called Logstash, and an analytics and visualisation platform called Kibana. The three products
are designed for use as an integrated solution, referred to as the "Elastic Stack" (formerly the
"ELK stack").

Este artículo no está mal: https://qbox.io/blog/what-is-elasticsearch

La cuestión es que por ahora tienen los nodos de Elasticsearch en DIA, no en AWS.
Actualmente tienen 3 nodos que les dan 3 Teras de almacenamiento y están viendo si añadir 3
más. La configuración actual les permite mantener 1 mes de información y a futuro esperan
poder mantener 2 meses. Esta información puede ser consultada en Kibana. (Esto vendrá a
cuento luego, por una petición de negocio).

10.4 Pingdom
[A] web performance monitoring service.

https://www.pingdom.com

Justo utiliza esta herramienta para monitorizar. Actualmente tienen la cuenta mínima, pero
seguramente pasen una mejor. Con esta herramienta se pueden poner reglar tipo “revisa esta
URL y si está caída mándame un SMS”, o revisar la velocidad de carga de una web cada 30 min,
etc.

10.5 Dynatrace
Especialmente en cuanto a Application performance management (APM)
https://www.dynatrace.es/
 11. Problemas recurrentes
11.1 Alertas
Relacionado con el tema de la monitorización, vino el tema de las alertas. La gente de
Auditoría le ha pedido a Diego (PO) fechas y detalles del sistema de alertas que queremos
montar. Esto incluye tanto alertas en Hybris como en los sistemas de DIA, que se podrían fijar
usando las herramientas de monitorización.

11.2 Pruebas
11.2.1 Pruebas de integración
Los famosos “dockers”. La idea es que con Kubernetes y Helm se pueda levantar una instancia
de la BD para hacer sobre esta las pruebas que queramos. Aquí entramos también en el debate
de siempre sobre si los datos deben ser una copia de PRO o un juego de datos reducido (a
ampliar cada vez que subamos un error a PRO y luego detectemos que se nos había escapado
un caso de pruebas por tema de datos).

1.1.1 Pruebas de rendimiento

Tocamos brevemente este tema.

- Cuando SSDD lanza las pruebas de rendimiento lo hace desde la IP privada con la VPN de
DIA.
- Cuando se lanzan desde Asturias hay un paso adicional, lo que genera ruido y puede
afectar a los resultados de las pruebas (el eterno dilema de por qué una vez no salieron
mejoras tiempos cuando había ofertas en la web que cuando no las había).

Justo y Germán lo estuvieron comentando. Una opción podría ser tirar directamente contra el
ELB. Por parte de SSDD también se está valorando poner un esclavo del JMeter. En la RED80 de
Ricoh tenemos ya los JMeter incluidos en el Jenkins. SSDD lo tiene en su roadmap.

11.3 Consultas que negocio quiere hacer contra BD en tiempo real

Negocio querría consultar todo tipo de información en tiempo real, pero tenemos paradas
estas peticiones, porque no queremos hacer un desarrollo que pueda provocar que tiren la
base de datos. Actualmente hay Jobs nocturnos que generan informes semanales, pero
negocio necesita más flexibilidad y datos en tiempo real. Justo explicó que con una BD
transaccional como la nuestra NO podemos tirar NUNCA queries a lo loco contra esta. A partir
de aquí, se barajaron opciones:

- Justo comentó que se podría recuperar información del servidor de tickets, pero las
peticiones de negocio que actualmente tenemos paradas son más bien sobre información
de operaciones.
- Otra posible solución que se planteó es hacer una copia (snapshot) de la BD por la noche,
para que puedan tirar las consultas contra ella. En este caso negocio no contaría con los
datos del día en curso, pero podría consultar datos de hace 3 o 6 meses sin problema. Para
la información del día actual siempre podría entrar en Kibana.
o Justo planteó esto como un snapshot que se desecharía al final del día para crear
uno nuevo, manteniendo siempre toda la información en la BD principal.
o Se le planteó mantener una copia viva que se actualice de forma continuada, pero
la sincronización de ambas BBDD se plantea complicada, por lo que no se va a
hacer.
- También se habló del volumen de datos que mantenemos en nuestra BD, ya que el
histórico va aumentando. La opción de poner el histórico en una BD separada tampoco
convenció. Pero se volvió a hablar de las tablas de histórico dentro de nuestra BD. Es un
tema que deberíamos recuperar.
- Además, se comentó la opción de usar “vistas materializadas”. Como solución para
negocio es ideal, porque podrían tirar sus consultas contra vistas materializadas. El
problema vuelve a ser crear estas vistas. Cada vez que se ejecuta la materialización hay
que tirar contra nuestra BD transaccional, lo que no nos conviene. Si negocio realmente
quiere datos en tiempo real esto supondría lanzar continuamente materializaciones.
- También hablaron de Kafka para hacer un colchón y luego consumir desde allí.
Apache Kafka es un proyecto de intermediación de mensajes de código abierto
desarrollado por la Apache Software Foundation [...]. El proyecto tiene como objetivo
proporcionar una plataforma unificada, de alto rendimiento y de baja latencia para la
manipulación en tiempo real de fuentes de datos. Puede verse como una cola de
mensajes, bajo el patrón publicación-suscripción, masivamente escalable concebida como
un registro de transacciones distribuidas, lo que la vuelve atractiva para las infraestructuras
de aplicaciones empresariales.

https://kafka.apache.org/
- También se habló de Filebeat y Logstash para centralizar logs
- Otro tema que salió es Clickview. Actualmente Pablo Benítez está trabajando en hacer
dashboards y podría hacer uno para negocio.

https://www.qlik.com/us/products/qlikview

Al margen de qué podemos hacer con la BD que tenemos, también se habló de la posibilidad
de cambiar de tipo de BD y usar:

- MySQL

- PostgreSQL
- Aurora
Amazon Aurora es una base de datos relacional compatible con MySQL y PostgreSQL
creada para la nube y que combina el rendimiento y la disponibilidad de las bases de datos
comerciales de gama alta con la simplicidad y la rentabilidad de las bases de datos de
código abierto. Aurora es hasta cinco veces más rápida que las bases de datos de MySQL
estándar y tres veces más rápida que las bases de datos de PostgreSQL estándar.
https://aws.amazon.com/es/rds/aurora/
Por Lo visto en Amazon tienen un maestro y algo llamado “réplicas de lectura” que podría
servir para esto que pide negocio. Pero claro, habría que migrar antes…

La conclusión es:

- Hay que hablar con negocio para ver de qué rango de tiempo son los datos que quieren
consultar.
- SSDD y Germán valorarán las opciones que hay para dar una solución a negocio.

Nota: Como curiosidad, comentó que la BD supone el 60% del importe de la cuenta. Por lo que
explorar alternativas no es mala idea.

11.4 Cuáles son los límites de nuestro sistema

Diego (PO) preguntó algo que inquieta a negocio, y es saber hasta cuántos clientes podría
llegar a comprar en la web en paralelo. La respuesta es:

- Por una parte, tenemos una limitación por la BD, que está sufriendo bloqueos
o que se está resolviendo con el desarrollo del carrito
o mejoras del código
o y las opciones de mejora de la BD comentadas antes

- Por otra parte está la limitación de capacidad de procesamiento, es decir, los nodos.
o Actualmente en PRO tenemos 3 nodos app y 2 nodos adm

o Por lo visto hay debate en cuanto a cómo mejor escalar. Comentaba Justo que
Hybris, por un tema de cluster interno, históricamente no escalaba bien. Lo
habitual es meter más máquinas en paralelo (horizontal), pero entonces hay que
replicar más veces el cluster y eso no estaba fino. Así que la solución pasa más bien
por reforzar las máquinas que se tienen, metiendo más CPUs a cada nodo, en vez
de poner más nodos.

Al parecer hay mejoras en este punto en la versión 6.5, pero habría que analizarlas.

11.5 Nginx vs apache

Actualmente tenemos un problema: cuando el ELB cambia de IP, el Apache no se da cuenta y
empiezan los problemas. Nginx sí lo detectaría, por lo que ponerlo va a ser una de las tareas de
Germán.
 11.6 Redirecciones
Otro tema que tenemos pendiente. Según comentó Justo, un redirect genérico (tipo de
https://www.dia.es a https://www.dia.es/compra-online/) sí puede ir en el servidor de
aplicaciones. Pero la ristra enorme de redirect que tenemos actualmente sería mejor tratarlo
desde Hybris.

11.7 Seguridad
Es una preocupación recurrente.

- Hablaron del AWS WAF (Web Application Firewall) y de ciertos temas que está mirando
seguridad que exceden el ámbito de este documento.
https://aws.amazon.com/es/waf/
- También se comentó la posibilidad de usar eCapsule, que permite definir reglas de negocio
para prevenir el fraude. Por ejemplo puede insertar un Captcha en una pantalla del
checkout si se cumplen ciertas reglas. O bloquear ciertas IPs durante un intervalo de
tiempo, etc. Esto sería una herramienta mucho más potente que la que utiliza el SAC
actualmente, y muy útil en el caso de ataques por bots.

12. Cambios en la arquitectura

Hubo un pequeño error al configurar la arquitectura y ahora no se puede modificar, así que
necesitan rehacerlo todo, tanto para DEV como STAG y PRO. Hay una herramienta que sirve
para crear, modificar y versionar infraestructura que se llama Terraform (está en el resumen
del DevOps).

SSDD actualmente está dejando todo mapeado en Terraform para que rehacerlo (esta y las
veces que haga falta) sea menos costoso.

Una vez hayan hecho el cambio, la nomenclatura de quedará así:

- 10.X.0.0/22 --
- 10.X.0.0/23 –
- Etc.

Lo que está en amarillo sería el número del proyecto.

13. Notas
13.1 Las pizarras con las explicaciones:

 ¡Igualmente, agradecemos la explicación!

 13.2 Herramientas
Si queréis hacer mapas con iconos de los servicios de Amazon, os podéis descargar de aquí las
librerías de iconos: https://aws.amazon.com/es/architecture/icons/ o de aquí:
https://aws.amazon.com/es/blogs/aws/introducing-aws-simple-icons-for-your-architecture-
diagrams/ y usarlas con Microsoft Visio (funciona regular), PPT, etc.

Tenéis también un resumen de iconos aquí:

https://docs.google.com/drawings/d/1cch96MmZxZib_-KC6RcXkM2P6L0k_32kl_NwFFvEtv4/
edit

Otra herramienta, recomendada por Justo:

https://cloudcraft.co/