Comprensión de las necesidades de disponibilidad

Es común pensar inicialmente en la disponibilidad de una aplicación como un solo objetivo para la aplicación en su totalidad. Sin embargo, al analizarlo más detenidamente, con frecuencia encontramos que ciertos aspectos de una aplicación o servicio tienen requisitos de disponibilidad diferentes. Por ejemplo, algunos sistemas podrían dar prioridad a la capacidad de recibir y almacenar nuevos datos antes que a la de recuperar datos ya existentes. Otros sistemas dan prioridad a las operaciones en tiempo real sobre las operaciones que cambian la configuración o el entorno de un sistema. Los servicios pueden tener requisitos de disponibilidad muy elevados durante ciertas horas del día, pero pueden tolerar periodos mucho más largos de interrupción fuera de esas horas. Estas son algunas de las formas en que se puede separar una sola aplicación en las unidades funcionales y evaluar los requisitos de disponibilidad de cada una de ellas. El beneficio de hacerlo consiste en centrar los esfuerzos (y los gastos) en la disponibilidad de acuerdo con las necesidades específicas, en lugar de diseñar todo el sistema según los requisitos de mayor exigencia.

En AWS, normalmente dividimos los servicios en el “plano de datos” y el “plano de control”. El plano de datos se encarga de entregar el servicio en tiempo real mientras que el plano de control se utiliza para configurar el entorno. Por ejemplo, las instancias de Amazon EC2, las bases de datos de Amazon RDS y las operaciones de escritura de tablas de Amazon DynamoDB son operaciones de plano de datos. Por el contrario, el lanzamiento de nuevas instancias de EC2 o bases de datos RDS o agregar o cambiar los metadatos de las tablas en DynamoDB se consideran operaciones de plano de control. Si bien los altos niveles de disponibilidad son importantes para todas estas capacidades, los planos de datos suelen tener objetivos de diseño de disponibilidad más altos que los planos de control. Por lo tanto, las cargas de trabajo con requisitos de alta disponibilidad deben evitar la dependencia en tiempo de ejecución de las operaciones de plano de control.

Muchos clientes de AWS adoptan un enfoque similar para evaluar de forma crítica sus aplicaciones e identificar los subcomponentes con diferentes necesidades de disponibilidad. Los objetivos de diseño de la disponibilidad se adaptan a los diferentes aspectos y se llevan a cabo los debidos estudios de ingeniería del sistema. AWS cuenta con gran experiencia en aplicaciones de ingeniería con un intervalo de objetivos de diseño de disponibilidad, incluidos servicios con una disponibilidad del 99,999 % o mayor. AWS Los arquitectos de soluciones (SA) pueden ayudarle a crear el diseño adecuado para lograr sus objetivos de disponibilidad. Involucrar a AWS en la fase inicial de su proceso de diseño aumenta nuestra capacidad para ayudarle a cumplir sus objetivos de disponibilidad. La planificación de la disponibilidad no solo se hace antes de lanzar la carga de trabajo. También se hace continuamente para perfeccionar su diseño a medida que se adquiere experiencia operativa, se aprende de los eventos reales y se toleran errores de diferentes tipos. De esta forma, podrá aplicar el esfuerzo de trabajo adecuado para mejorar su aplicación.

Las necesidades de disponibilidad que se requieren para una carga de trabajo deben estar alineadas con la necesidad empresarial y la criticidad. Al definir primero el marco de criticidad empresarial con RTO, RPO y disponibilidad definidos, podrá evaluar cada carga de trabajo. Este enfoque requiere que los implicados en la implementación de la carga de trabajo conozcan el marco y el impacto que su carga de trabajo tiene en las necesidades empresariales.