Optimizar la autorización
Imagínate entrando a un bar. Te piden tu identificación en la entrada y luego cada vez que pides una bebida, debes volver a mostrarla. Así era como la autorización realizaba las comprobaciones en versiones anteriores a la 7.16, en las que cada nodo (entrada) requería una comprobación de autorización y cada shard (pedido de bebida) también requería una comprobación de autorización. ¿Y si una sola comprobación de identificación en la entrada fuera suficiente para ambas cosas? Apliquemos esa misma idea a la autorización en Elasticsearch.
Elasticsearch permite a los usuarios configurar el control de acceso basado en roles/atributos para otorgar un permiso detallado por campo, por documento o por índice. Antes, authorize
se encontraba en muchas fases de una consulta de búsqueda para garantizar que las solicitudes no autorizadas no obtuvieran acceso injustificado a los datos. Sin embargo, la vigilancia de la funcionalidad de autorización tiene un costo, y una parte de la lógica no escala horizontalmente a medida que aumenta el tamaño del cluster. Por ejemplo, obtener capacidades de campo para todos los campos en todos los índices en un cluster grande podría requerir varios segundos o incluso minutos para completarse, además de dedicar casi todo el tiempo de ejecución a trabajos relacionados con la autorización.
La versión 7.16 aborda estos problemas desde dos perspectivas:
- Las mejoras algorítmicas a la autorización aceleran la autorización de solicitudes individuales, tanto al autorizar una solicitud de REST como al autorizar durante la comunicación en la capa de transporte (es decir, toda la red interna de nodo a nodo) entre los nodos dentro de un cluster de Elasticsearch.
- La autorización de solicitudes internas se hereda de las comprobaciones anteriores o se abarata significativamente en muchos casos. Antes de la versión 7.16, Elasticsearch ejecutaba la misma lógica de autorización por la que pasaba la solicitud externa inicial al autorizar las solicitudes de transporte internas dentro del cluster. Esto se hizo para evitar introducir una superficie de ataque en la comunicación de nodo a nodo interna que permitiría que un atacante diseñe solicitudes internas para omitir la lógica de autorización. Ahora resulta mucho más económico gracias a la omisión de la expansión con comodines en subsolicitudes, la omisión de la autorización para solicitudes locales del nodo (dentro del mismo nodo) y la reducción de la cantidad total de solicitudes necesarias para acciones como la búsqueda.
Reducir solicitudes de shard en la fase pre-filter
Se implementó una estrategia de búsqueda nueva en la versión 7.16 en las fases pre-filter
para reducir la cantidad de solicitudes a una vez por nodo que coincida. Antes de la versión 7.16, la primera fase de una búsqueda que intentara filtrar a partir de una búsqueda todos esos shards que se sabe que no contienen datos relevantes requería una solicitud por shard del nodo de coordinación a un nodo de datos. Hacer búsquedas en miles de shards al mismo tiempo implicaba enviar miles de solicitudes por solicitud de búsqueda desde el nodo de coordinación, manejar miles de respuestas en el nodo de coordinación y además gestionar todas estas solicitudes en los nodos de datos y responder a ellas. Escalar el cluster a más nodos de datos mejoraría el rendimiento del manejo de tantas solicitudes en los nodos de datos, pero no ayudaría con el rendimiento de esta operación en el nodo de coordinación.
A partir de la versión 7.16, la estrategia que ejecuta la fase pre-filter
se ajustó para enviar solo una solicitud por nodo en la fase, que abarca todos los shards en el nodo. Esto se puede ver en la Figura 1 a continuación. En un cluster con miles de shards en tres nodos de datos, la cantidad de solicitudes de red en la fase inicial de búsqueda pasaría de miles a tres o menos solicitudes, independientemente de la cantidad de shards en los que se busca. Como las solicitudes por shard enviadas antes de la versión 7.16 contenían en su mayoría los mismos datos en todos los shards, más precisamente la consulta de búsqueda, enviar solo una solicitud por nodo significa que esta información ya no se duplicará en varias solicitudes y, por lo tanto, se reducirá drásticamente la cantidad de bytes que se deben enviar a través de la red.