¿Cuál fue el desencadenante empresarial de su proyecto?
Cuál fue el desencadenante empresarial de su proyecto?
Desde 2018, Salesforce Edge ha estado proporcionando servicios de red de entrega de contenido interno (CDN), incorporando aproximadamente 130 000 nombres de dominio web, incluidas algunas de las propiedades web internas más grandes.
Salesforce Edge ha estado proporcionando servicios de red de entrega de contenido interno (CDN)
A lo largo de los años, hemos trabajado para mejorar la estabilidad del servicio, pero ha tenido dificultades para seguir el ritmo de nuestro rápido crecimiento empresarial. Nos dimos cuenta de que nuestra arquitectura de plano de control se estaba acercando a sus límites de escalado en términos de utilización de memoria y latencias visibles. Esta constatación nos brindó la oportunidad de diseñar una nueva arquitectura. Ahora podemos reflexionar sobre las lecciones aprendidas del proyecto inicial, identificando lo que funcionó bien, lo que se pasó por alto, lo que ya no es necesario y lo que no se ha escalado de forma eficaz.
Los cambios en la arquitectura del plano de control nos han ayudado a mejorar la estabilidad del servicio, pero han tenido dificultades para seguir el ritmo de nuestro rápido crecimiento empresarial
Crecimiento del número de clientes incorporados a lo largo del tiempo.
Crecimiento del número de clientes incorporados a lo largo del tiempo.
¿Ha pensado en reescribir su software desde cero?
Sí, nos hemos planteado reescribir nuestro software desde cero por varias razones, como un cambio significativo en las tecnologías subyacentes o la creencia de que empezar de cero sería más rápido que lidiar con las deudas técnicas existentes. En el caso de nuestro software Edge, abordamos la rearquitectura de los componentes del plano de control y del plano de datos de forma diferente.
- Para el servidor del plano de control, tomamos la decisión de cambiar de Python a Java, de Etcd a Aurora, de Docker-compose a Kubernetes y de nube privada a nube pública. Estos cambios drásticos requerían empezar desde cero
- Para el plano de datos, que gestiona el tráfico de Internet, adoptamos un enfoque diferente. Valorábamos la confianza como nuestra máxima prioridad y nos preocupaba perder la interoperabilidad, la conformidad y el refuerzo de la seguridad que habíamos conseguido a lo largo de años de funcionamiento. Por lo tanto, optamos por un ejercicio intensivo de refactorización del código existente.
Al elegir el enfoque de refactorización para el plano de datos, pudimos aprovechar más de 300 pruebas funcionales que se ejecutaban en nuestro CI existente, reduciendo el riesgo de introducir regresiones funcionales. Nuestra estrategia de despliegue incluía el marcado de características del nuevo código refactorizado, lo que permitía un despliegue lento y escalonado de cada característica. Este enfoque también proporcionó la flexibilidad para volver rápidamente al código heredado en caso necesario
¿Cómo iniciaron el proyecto de refactorización?
Seguimos un enfoque sistemático. En primer lugar, identificamos las métricas medibles que queríamos mejorar y acordamos sus valores objetivo. A continuación, recopilamos datos de perfiles del código actual para identificar las áreas que necesitaban mejoras. A continuación, generamos ideas para abordar los puntos débiles identificados, creamos prototipos y medimos su impacto en cada métrica
Además, calculamos el esfuerzo necesario para poner en práctica cada idea y utilizamos estas cifras para calcular una «puntuación de rentabilidad» para cada idea. Al dar prioridad a las ideas con mayor puntuación, nos centramos en los «frutos maduros» que ofrecerían el mayor impacto. Este enfoque garantizó un arranque estructurado y basado en datos para el proyecto de refactorización.
Matriz de priorización de características según su rentabilidad.
¿Cuál era el mayor punto de dolor que necesitaba abordar?
Nuestro mayor punto de dolor era la escala limitada del tamaño de la configuración, específicamente el número de clientes incorporados, que con frecuencia desencadenaba el Out-Of-Memory Killer del kernel. Quedó claro que mantener toda la configuración en memoria no era una solución viable.
Cuidado con la memoria
Para solucionar esto, decidimos cambiar nuestro modelo de procesamiento de la configuración. Adoptamos un enfoque de streaming, en el que cargábamos la configuración de un cliente cada vez, la procesábamos y luego la descartábamos, de forma similar al streaming. Este cambio al modo streaming nos permitió optimizar nuestra huella de memoria y escalar indefinidamente, superando las limitaciones impuestas por el tamaño de la configuración.
Crecimiento de la huella de memoria antes y después de la refactorización.
Crecimiento de la huella de memoria antes y después de la refactorización
¿También ha considerado escalar verticalmente?
Para maximizar la utilización de los núcleos, implementamos el multihilo para el procesamiento de nuestra configuración. En lugar de utilizar bloqueos para serializar el acceso a los recursos compartidos, lo que puede resultar ineficiente, adoptamos un enfoque similar al de map-reduce. Cada subproceso de trabajo opera en su propio recurso local, que posteriormente el subproceso principal combina en el recurso global. Este enfoque minimiza la contención y logra una relación casi lineal entre el número de núcleos de trabajadores y el tiempo de procesamiento de la configuración.
Tiempo de carga de la configuración por el número de config processing workers.
¿Puedes compartir un aprendizaje de la arquitectura original de Edge?
Un aprendizaje clave de la arquitectura Edge original fue la necesidad de priorizar la escalabilidad como un requisito no funcional. Inicialmente, la atención se centró en el desarrollo de nuevas características para atender a una amplia gama de casos de uso de los clientes. Sin embargo, introducir nuevas funciones sin tener en cuenta su impacto en la escalabilidad podría dar lugar a una arquitectura compleja e ineficaz.
Se llegó a la conclusión de que, incluso si una función no se utilizaba mucho, podía tener un impacto negativo en el rendimiento debido a los cambios arquitectónicos que introducía. Esto planteó la cuestión de si limpiar estas características o mantenerlas como parte del proceso de refactorización.
Para abordar esta cuestión, se tomó la decisión de planificar la nueva arquitectura como si estas características no existieran. La máxima prioridad estratégica pasó a ser garantizar que las características predominantes, que requerían escalabilidad, estuvieran bien soportadas. Al adoptar este enfoque, el equipo pretendía crear una arquitectura que diera prioridad a la escalabilidad y evitara la complejidad innecesaria causada por las características menos utilizadas.
Para solucionar esto, se tomó la decisión de planificar la nueva arquitectura como si estas características no existieran
¿Qué tan drástico fue el impacto de la refactorización?
Después de varios meses de iterar sobre el nuevo código, abordamos con éxito todos los puntos de dolor iniciales, optimizamos nuestras métricas de rendimiento y reanudamos la migración masiva de dominios a Edge. Esto se logró a través de la integración continua, con lanzamientos quincenales, despliegue mediado por la salud, y sin tiempo de inactividad. Especialmente, fuimos capaces de incorporar 5 millones de clientes en nuestro laboratorio de pruebas y aumentar nuestra base de clientes de producción de 130.000 a 2 millones.
Edge
