Header Ads Widget

Ticker

6/recent/ticker-posts

6 técnicas para un 99,999% de tiempo de actividad

 

6-técnicas-para-99.999-uptime-nordic-apis

Un sistema solo es útil si se puede utilizar. Si no se puede acceder a un sistema, es posible que no exista. En lo que respecta a las API, este principio de disponibilidad se denomina tiempo de actividad .

El tiempo de actividad es el estado de un servidor o servicio y la fiabilidad del mismo. Aumentar el tiempo de actividad tiene varios beneficios, la mayoría de los cuales son una bendición para la usabilidad. Agregue a esto una reputación de estabilidad, mayor seguridad, experiencia de desarrollador y servicio al cliente, y los beneficios de un alto tiempo de actividad se vuelven claros.

Tener un tiempo de actividad constante y sólido es el elemento vital de una API eficaz . Afortunadamente, existen algunas soluciones muy efectivas para implementar, mantener y asegurar un alto tiempo de actividad.

Seis técnicas para aumentar el tiempo de actividad

Técnica 1 - Sea consciente de sus activos físicos

Una de las formas más sencillas de garantizar un elevado tiempo de actividad es conocer los activos físicos de un sistema. Al saber cuáles son los puntos de falla potencial, se pueden monitorear las responsabilidades y los desarrolladores pueden reaccionar rápidamente cuando llega un problema.

Este nivel de conciencia varía según la escala del servicio prestado. Por ejemplo, en los primeros días del espacio de las API, cuando las API estaban reservadas para grandes empresas con salas de servidores físicos, estas preocupaciones se centraban casi por completo en las amenazas ambientales e internas inmediatas.

Esto todavía es válido para muchos clientes corporativos: un desarrollador de API que utiliza recursos corporativos necesita conocer la antigüedad de los servidores que manejan el código, sus números de tiempo de actividad particulares, cualquier problema de temperatura en la pila del servidor, etc.

Sin embargo, para el desarrollador promedio en el espacio moderno, esto no es realmente una preocupación. Muchos desarrolladores utilizan computación en la nube, PaaS, Saas e IaaS para alojar sus funcionalidades API.

Las preocupaciones del espacio corporativo son tan válidas como lo fueron antes, pero se han trasladado al espacio virtual en una escala general mucho mayor. No necesita preocuparse tanto por las rutas de calor de sus servidores, claro, pero tenga en cuenta que un proveedor de nube con sede en países propensos a terremotos tiene una mayor probabilidad de fallas en el tiempo de actividad que un proveedor en un país con condiciones geológicas relativamente estables.

Asimismo, tenga en cuenta la distancia entre su cliente y su servicio. Si bien se pueden hacer grandes avances para optimizar las API y disminuir el ping , el hecho es que la transmisión de datos lleva tiempo, y muchos sistemas pueden agotar el tiempo de espera a pedido si la solicitud se envía a un servidor distante de carga pesada.

Relacionado: Aprenda a optimizar las API para aplicaciones móviles

Esto se reduce a conocer la ubicación de los clientes de API finales y sus requisitos, para hacer coincidir los servidores de datos sobre la mesa con estas calificaciones. El tamaño de la base de usuarios y el volumen promedio de solicitudes, la proximidad a los centros de datos, la capacidad del servidor, la ubicación de los activos físicos y las consideraciones relevantes deben realizarse para garantizar que los requisitos proyectados coincidan con los activos reales. Comprenda las limitaciones de su hardware físico.

Técnica 2 - Sobreestimar los límites de capacidad del servidor

Una de las peores cosas que puede hacer un desarrollador de API es establecer límites de capacidad del servidor demasiado bajos.

Un gran ejemplo del mundo real de por qué se llama "Reddit Hug of Death". Cualquiera que frecuenta Reddit sabe cómo funciona esto: un sitio web con una imagen increíble, un gran juego o incluso una publicación de blog que pasa atrae la atención de cientos de miles de usuarios que convierten el contenido en viral. En poco tiempo, el sitio que aloja este contenido se pone de rodillas, primero con un tráfico lento y luego con una falla en la conexión.

Esto es exactamente lo que sucede cuando una base de usuarios proyectada no coincide con los recursos disponibles. Este tipo de falla contribuye a un bajo tiempo de actividad y es algo que debe tenerse en cuenta para cualquier "X-as-a-service" en la web, donde el alto tráfico siempre es un potencial.

Para evitar un temido error HTTP 503, haga que sus limitaciones sean escalables desde el principio: adopte servidores en la nube o soluciones de administración de API que ofrezcan planes de escalado flexibles que respondan automáticamente al aumento del tráfico.

Técnica 3: creación de rutas lógicas de respaldo

Imagínese que está conduciendo hacia el trabajo, utilizando su ruta diaria típica. Cuando empiece a incorporarse a una carretera conocida, la verá: construcción de carreteras y una señal luminosa de desvío con una flecha.

¿Dónde estarías sin esa señal? ¿Sin un desvío en su lugar? ¿Qué pasaría si los grandes proyectos de construcción no cambiaran de ruta y le dijeran que "esto ya no es una carretera, buena suerte para encontrar el camino correcto"

Eso es exactamente lo que sucederá con su API si no se establecen rutas lógicas . Ningún sistema es perfecto y ningún camino es permanente. A medida que se eliminan rutas para reparaciones, actualizaciones y mejoras, los usuarios obtienen su tráfico denegado y descartado sin ceremonias, a menos que haya una ruta adicional para compensar.

La forma de resolver esto es simple: mantenga la conmutación por error . La conmutación por error es la idea de que los datos deben tener rutas alternativas para tener siempre un conducto para el intercambio. La implementación de más interfaces de red, la distribución de la carga del servidor mediante diversas técnicas de equilibrio de carga y el establecimiento de la redundancia y la abstracción a través de implementaciones como una puerta de enlace de API o un contenedor de Docker pueden ser de gran ayuda para inocular un servicio de problemas de conmutación por error.

Afortunadamente, el espacio de desarrollo de API moderno proporciona muchas soluciones de conmutación por error para el desarrollador moderno. Debido a que los centros de datos son la principal fuente de manejo de datos en el entorno moderno, muchas de estas soluciones son baratas, rápidas y sencillas de implementar y mantener.

Tomemos, por ejemplo, el concepto de servidor de respaldo . En los viejos tiempos, implementar un servidor de respaldo tenía un costo enorme para cada unidad física, además del mayor costo administrativo y de personal, así como los mayores problemas en el ámbito de la seguridad relacionados con un nodo adicional en la red.

En el enfoque del centro de datos , se puede virtualizar un servidor, eliminando la restricción física. Los servidores virtualizados funcionan exactamente igual que los servidores físicos, pero pueden activarse independientemente de otros nodos según el capricho del operador por un costo bajo o nulo.

Con una solución tan barata en forma de servidores virtuales, los desarrolladores de API pueden crear servidores redundantes detrás de una puerta de enlace API que a su vez se clona en varios servidores virtuales en nodos independientes en el centro de datos. Esto significa que si un servidor físico falla, las múltiples copias de seguridad virtuales pueden ponerse en marcha, distribuyendo el tráfico a los clones del servidor y creando una experiencia de cliente perfecta.

Blog-Post-Wide-CTA-API-Stack

Técnica 4 - Codifique de forma proactiva

El espacio del servidor es solo la mitad de la batalla cuando se trata de lo que podría causar fallas en el tiempo de actividad. El código en sí es un gran competidor, aquí: crear un sistema que permita detectar errores antes de que entren en las compilaciones de producción es tan importante como asegurarse de que esas compilaciones sean accesibles, ya que un error de este tipo podría hacer que el sistema falle. Del mismo modo, las excepciones, los fallos de memoria e incluso los desbordamientos del búfer tienen un papel muy importante que desempeñar en el tiempo de actividad y deben tratarse como tales. Hacer "lo suficiente" para salir adelante es muy ineficaz e improductivo.

Existe una amplia variedad de soluciones que podrían implementarse. Una de las formas más efectivas de manejar de manera inteligente las excepciones es utilizar dominios como método para detectar errores. En Node.js, el siguiente fragmento de código puede hacer precisamente eso:

var d = require('domain').create();

d.on('error', function (err) {
  console.log("domain caught", err);
});

var f = d.bind(function() {
  console.log(domain.active === d); // <-- data-preserve-html-node="true" true="" throw="" new="" error="" uh-oh="" settimeout="" f="" 100="" code="">

Si bien el código es diferente en otros idiomas, el concepto es el mismo: aislar los dominios de error y proporcionar una respuesta inteligente ayuda a la disponibilidad del servicio en general. Como parte de esto, la prevención de inundaciones, específicamente la limitación de inundaciones, también se puede implementar como una solución, reduciendo el impacto del tráfico y las solicitudes inesperadas.

No tener un código adaptativo es una sentencia de muerte: no adaptarse a situaciones de falla y desbordamiento de la memoria significa que incluso una solicitud mal formada y prolíficamente incorrecta podría derribar un sistema completo. Además, la seguridad y la funcionalidad de la API es responsabilidad exclusiva del codificador , y la codificación evita de forma proactiva el cambio de culpa que suele ocurrir con las API más grandes.

Usabilidad del desarrollador: diseñe su API para que sea más que funcional

Técnica 5 - Sé el enemigo

Una de las mejores formas de garantizar que su API tenga el mayor tiempo de actividad posible es "ser el enemigo". Conviértete en un sombrero blanco y considera qué aprovecharía tu enemigo con la API en cuestión.

Para encontrar estas vulnerabilidades, abuse del sistema lo más que pueda; aquellos que planean atacar su sistema ciertamente no serán amigables con la API en el mundo real . Pruebe la integridad y el saneamiento de su base de datos e intente romper todo. Algunas cosas para probar:

  • Verifique la API en busca de errores
  • Revise sus estados y situaciones de desbordamiento
  • Considere cómo la API se ocuparía de un tráfico elevado
  • Comprenda cómo ocurrieron sus errores durante la escritura inicial y las pruebas, y fíjese francamente si los parcheó correctamente o simplemente hizo un trabajo "suficientemente bueno".
  • Ejecute pruebas poco realistas. Bombardea tu API con dos o tres veces el tráfico que esperabas obtener,
  • Envíe solicitudes mal formadas con errores simples y errores complejos
  • ¡Abuso!

Es un amor duro, pero cuanto más duro esté en la API ahora, más probabilidades tendrá de detectar un error potencialmente fatal antes de que destruya su tiempo de actividad.

Seguridad de API: Seguridad de  API: profundización en OAuth y OpenID Connect

Técnica 6 - Adoptar una estrategia de desarrollo de dos vertientes

Finalmente, una de las cosas más efectivas que puede hacer un proveedor de API para asegurar un alto tiempo de actividad es segregar y aislar los problemas potenciales entre las compilaciones. Cuando hablamos de estas compilaciones, a menudo usamos el término "beta" para referirnos a contenido que aún no está en "estado utilizable", o al menos contenido que es inestable.

El problema aquí es un reino de extremos. Si preferimos la estabilidad en una estrategia de desarrollo de una sola vertiente, nos quedaríamos con soluciones probadas e implementaciones estables. En consecuencia, nuestra API tendría un gran tiempo de actividad, pero sería fundamentalmente no progresiva.

Por otro lado, podríamos tener una estrategia de desarrollo de una sola vertiente en la que estemos revisando, actualizando constantemente y actualizándonos constantemente. El problema con este enfoque es que renuncia a la estabilidad para la experimentación, lo que resulta en un menor tiempo de actividad.

Entonces, ¿cuál es la solución? Simple: implemente una estrategia de dos vertientes en lugar de una de una. Este tipo de desarrollo se denomina TI de dos velocidades y se basa en las discrepancias entre los dos enfoques para crear un ecosistema de desarrollo eficaz.

Al crear un canal para la construcción "beta" y la prueba de funciones secundario a un canal principal de "versión estable", permite la integración de nuevas funciones a la vez que permite una usabilidad estable y un mayor tiempo de actividad. Esto también tiene el beneficio adicional de permitir el monitoreo y la prueba en tiempo real de posibles puntos de falla a medida que se desarrollan las características.

Más específicamente, este enfoque tiene el beneficio adicional de dar como resultado un ecosistema para desarrolladores donde las debilidades de una característica determinada se pueden probar en una naturaleza de escala. Debido a que las API pueden incluir usuarios en la lista blanca para ciertas funciones de compilación, estas funciones se pueden probar primero en grupos pequeños de usuarios y luego se pueden incluir en la lista blanca para usuarios adicionales a medida que se borra cada nivel.

Al hacerlo, los desarrolladores pueden reducir la base de usuarios para la cual es propenso a fallar el tiempo de actividad en una compilación beta, y cuando ocurre una falla inevitable, desviar ese tráfico a través de canales establecidos anteriormente, lo que permite pruebas útiles y transparentes.

El tiempo de actividad como componente de seguridad

Si bien un alto tiempo de actividad es intrínsecamente bueno, no implementar el mayor tiempo de actividad posible dadas las limitaciones de hardware y presupuesto no solo conlleva una variedad de inconvenientes, sino también una falla única y evidente: la seguridad .

La seguridad en el espacio de la tecnología de la información a menudo hace referencia al concepto de "CIA", es decir, confidencialidad, integridad y disponibilidad, mientras que la confidencialidad (mantener la información privada) y la integridad (asegurarse de que la información no se pueda cambiar a menos que el desarrollador lo permita) son muy importantes. aspectos importantes de la seguridad de la API, la disponibilidad (la capacidad de acceder a un servicio) es igualmente vital.

alto tiempo de actividad para el tiempo de ejecución de la API

Si bien el bajo tiempo de actividad puede tener impactos económicos desastrosos, el componente de seguridad es quizás la más importante de las preocupaciones sobre el tiempo de actividad. Los problemas de tiempo de actividad se pueden dividir en dos temas: "capacidad para aceptar tráfico" y "capacidad para enrutar el tráfico con éxito". Estos dos conceptos tienen un gran cruce, pero son distintos en su impacto en la seguridad de una API.

La capacidad de aceptar tráfico es lo primero que viene a la mente cuando se habla de tiempo de actividad, y con razón: la accesibilidad y la usabilidad van de la mano con un alto tiempo de actividad. Esta capacidad se puede cortar de diversas formas, desde ataques DDOS (denegación de servicio distribuida) hasta fallas de hardware y de puerta de enlace.

Esta es en gran medida una discusión "extrínseca", es decir, la disponibilidad cuando se trata de aceptar tráfico se decide casi en su totalidad por factores extrínsecos a la API misma, ya sea el hardware del servidor, los ataques coordinados o los factores ambientales.

Sin embargo, el segundo tema es en gran parte "intrínseco": la capacidad de enrutar el tráfico. Si bien el enrutamiento posiblemente se relaciona con el enrutamiento de hardware que utiliza conmutadores y concentradores, este tema trata el problema de una manera más interna, centrándose en la función del código y las directivas diseñadas por el desarrollador de la API.

Al ser capaz de reconocer, limitar, redirigir y enrutar el tráfico internamente en un servidor, un desarrollador de API puede " detener la inundación ", por así decirlo, reducir el flujo de datos a un nivel manejable y nivelar la tasa en múltiples servidores. Además, la mejora del enrutamiento permite la capacidad de alojar ciertos recursos y funciones en un servidor y otros en otro, creando un equilibrio de carga de facto y asegurando que los servicios no se afecten entre sí en situaciones de gran volumen.

Relacionado: Detener la inundación: cómo limitar la tasa de una API

Costo económico de un tiempo de actividad deficiente

Desde un punto de vista económico, tener poca disponibilidad y tiempo de actividad es increíblemente dañino.En 1998, un informe de IBM Global Services estimó que solo en 1996, las empresas estadounidenses perdieron $ 5.540 millones en ingresos y productividad debido a la escasa disponibilidad , y esto fue durante una era en la que El uso de la API era limitado, en comparación con la World Wide Web actual, pero dependía de las API externas.

Para ver un ejemplo más reciente, podemos ver las fallas en el mostrador de reservas de septiembre de 2010 en las aerolíneas Virgin Blue. La falla, que canceló 130 vuelos y retrasó a más de 60,000 pasajeros, resultó en daños entre $ 15 y $ 20 millones de dólares .

Las pérdidas de Virgin Blue tampoco fueron solo monetarias: su reputación se vio afectada dramáticamente. Al igual que con Virgin Blue, tener fallas de disponibilidad de rutina y un tiempo de actividad general bajo pueden tener efectos desastrosos en la reputación de su API.

Es increíblemente difícil obtener una base de usuarios, pero es igualmente difícil mantener una base de usuarios. Tener un historial de tiempo de actividad deficiente puede hacer que los usuarios se alejen de lo que perciben como un sistema inestable propenso a fallas. Si un desarrollador de API ni siquiera puede asegurar las conexiones más básicas, ¿qué quiere decir que mantienen mis datos seguros o los datos de mis clientes?

En pocas palabras, todo esto se puede corregir de forma económica antes de que se convierta en un problema de producción; sin embargo, cuando entra en el ámbito de la producción, el problema se vuelve exponencialmente más caro de reparar, especialmente cuando comienza a afectar a los usuarios.

Relacionado: Fomente una cultura de seguridad en toda su plataforma

Conclusión

Asegurar el tiempo de actividad es un asunto complicado. Hay empresas enteras cuyo objetivo es vender a los desarrolladores sus últimas y mejores soluciones para un alto tiempo de actividad, y uno podría gastar miles de dólares en una multitud de nueves . El 99% de tiempo de actividad puede parecer genial, ¡pero eso es casi 15 minutos sin conexión cada día!

gráfico de tiempo de actividad

Para las corporaciones, los segundos sin conexión pueden equivaler a millones perdidos. Pero para la mayoría de los proveedores de API, llegar a "nueve nueves" es un poco extremo. Las técnicas sugeridas en este documento están diseñadas específicamente para aumentar el tiempo de actividad con los recursos disponibles. Al conocer los sistemas físicos subyacentes, establecer umbrales de alta capacidad, crear rutas lógicas variables, codificar posibles puntos de falla, embrutecer la API y adoptar soluciones de TI de dos vertientes, los desarrolladores de API pueden garantizar un alto nivel básico de tiempo de actividad.

Publicar un comentario

0 Comentarios