Okta está en constante evolución de nuestra infraestructura de nube para satisfacer las necesidades de nuestros clientes. Colocamos la confiabilidad y la escalabilidad en el centro de nuestras decisiones de diseño para los servicios que procesan miles de millones de autenticaciones por mes. Este artículo profundiza en cómo un proyecto reciente para eliminar uno de nuestros servicios con mayor tráfico produjo mejoras significativas en la operación y la confiabilidad.
Un vistazo al borde de Okta
En el pasado, tres servicios principales recibieron y facilitaron la mayor parte del tráfico de clientes a Workforce Identity Cloud de Okta en el perímetro: un Application Load Balancer para proteger contra las inundaciones de solicitudes, un servicio basado en Apache para la terminación SSL y un servicio basado en Nginx para el enrutamiento y la lógica empresarial.
Estos servicios se implementan globalmente y se escalan para manejar grandes volúmenes de tráfico que Okta procesa diariamente. Si bien es eficiente, el estrecho acoplamiento de estos servicios se ha convertido gradualmente en un desafío operativo. Siempre buscando mejorar nuestra infraestructura, un equipo multifuncional se propuso reevaluar estos servicios.
¿Una de más?
Los clientes de Okta esperan un servicio disponible y de buen rendimiento, y es fundamental que cumplamos con estas expectativas. Si bien procesamos de forma rutinaria innumerables flujos de inicio de sesión, estar en la internet pública invita a lo inesperado. Ya sea iniciada por el cliente o no, Okta a veces recibe grandes afluencias de tráfico en un corto período de tiempo.
Al examinar de cerca los servicios que operamos, determinamos que el cuello de botella por subproceso de Apache limitaba nuestra capacidad para manejar grandes afluencias de tráfico sin impacto y decidimos eliminar este servicio de nuestro perímetro por completo. Esto impulsaría la arquitectura basada en eventos de Nginx en nuestra pila como un mejor medio para manejar patrones de tráfico impredecibles.
Con una mayor confiabilidad como el principal factor motivador, la oportunidad de finalizar varios cientos de servidores Apache permitiría una reducción significativa en el esfuerzo operativo. Entre mejorar la confiabilidad del servicio, reducir nuestro volumen de agregación de registros del sistema, eliminar el esfuerzo operativo y ahorrar costos, nos beneficiaríamos enormemente al dar de baja nuestro servicio Apache.
Nuestro equipo desarrolló una coreografía sólida para desviar el tráfico del servicio Apache y directamente a Nginx, lo que nos permitió iterar rápidamente en los problemas descubiertos en entornos de prueba antes de aplicar gradualmente este cambio a nuestros entornos de producción globales.
En pruebas
El servicio Apache de Okta ejecuta una aplicación Java ligera con configuraciones personalizadas para procesar las solicitudes entrantes antes de pasarlas a nuestro servicio Nginx. Al eliminar Apache, tuvimos que asegurar que cualquier funcionalidad proporcionada por el servicio se recreara dentro de Nginx. A través de pruebas sintéticas, nuestro equipo identificó rápidamente varios patrones de solicitudes entrantes que ya no se manejaban correctamente con el servicio Apache eliminado.
El problema de la "doble barra diagonal"
Debido a que Apache una vez sirvió como la aplicación inicial para recibir el tráfico de los clientes, contenía lógica desarrollada a lo largo de los años para identificar y responder adecuadamente a las solicitudes mal formadas. A medida que la infraestructura perimetral de Okta maduró a lo largo de los años, esta funcionalidad se movió en gran medida antes en la pila. Aún así, un problema con la eliminación de Apache se identificó rápidamente: ya no podíamos manejar correctamente las solicitudes que contenían //.
En entornos de prueba sin el servicio Apache, Nginx devolvió códigos de estado incorrectos para cualquier solicitud que contuviera //. Como ejemplo artificioso, las llamadas API para /api/v1/users continuaron comportándose como se esperaba, pero se observó que las llamadas a //api/v1/users devolvían respuestas HTTP de error del cliente.
Nuestro servicio Apache manejó estas solicitudes con una simple regla de reescritura, pero Nginx devolvería códigos de error para las solicitudes sin la reescritura, por lo que tuvimos que introducir una nueva regla de reescritura para restaurar esta funcionalidad.
Observando RFC 3986, este sería nuestro primer encuentro con La Ley de Hyrum.
El problema de la “cadena de consulta”
Con un sólido conjunto de pruebas sintéticas para validar la resolución del problema de la "doble barra diagonal", comenzamos una implementación gradual de la eliminación del servicio Apache en nuestros entornos de ensayo. A medida que la cantidad de tráfico procesado sin Apache aumentaba gradualmente, observamos nuevamente que Nginx devolvía códigos de respuesta incorrectos para ciertas solicitudes procesadas previamente por Apache sin problemas.
Como antes, descubrimos un caso en el que Apache reescribía previamente las solicitudes con formato incorrecto en un formato que Nginx podía procesar. En contra de RFC 1738, Apache había estado reescribiendo cadenas de consulta codificadas en valores decodificados. Como ejemplo, las solicitudes a /api/v1/users%3Flimit=1 se estaban decodificando y pasando a Nginx como /api/v1/users?limit=1. Sin Apache en la ruta de la solicitud, Nginx no pudo procesar las cadenas de consulta codificadas y devolvió un error al cliente que originó la solicitud. Para abordar esto, se introdujo una regla de reescritura adicional en nuestra configuración de Nginx y pudimos continuar con la implementación.
Varias iteraciones después
Eliminar un servicio tan prominente no resultó una tarea sencilla, pero finalmente se logró sin un impacto sostenido en el cliente. Este esfuerzo tuvo varias iteraciones a lo largo del tiempo, pero el enfoque en el resultado siguió siendo el mismo:
- Eliminar un cuello de botella de rendimiento
- Mejorar la fiabilidad del servicio
- Reducir el trabajo operativo
Habiendo completado este esfuerzo en todos los entornos, los beneficios se han hecho evidentes rápidamente y el equipo ya está planeando nuestras próximas mejoras.
¿Tiene preguntas sobre esta publicación de blog? Contáctenos en eng_blogs@okta.com.
Explore más blogs de ingeniería de Okta para ampliar sus conocimientos. de Okta para ampliar sus conocimientos.
¿Listo para unirte a nuestro apasionado equipo de ingenieros excepcionales? Visita nuestra página de empleos.
Libere el potencial de la gestión de identidades moderna y sofisticada para su organización. Contacte a ventas para obtener más información.
