Compréhension des besoins en disponibilité

Il est fréquent de considérer initialement la disponibilité d’une application comme un objectif unique à atteindre pour l’application dans son ensemble. Toutefois, en y regardant de plus près, on constate souvent que certains aspects d’une application ou d’un service présentent différentes exigences en matière de disponibilité. Par exemple, certains systèmes peuvent prioriser la possibilité de recevoir et de stocker de nouvelles données, au détriment de la récupération de données existantes. D’autres systèmes vont privilégier les opérations en temps réel sur les opérations qui modifient la configuration ou l’environnement d’un système. Les services peuvent avoir des exigences de disponibilité très élevées à certains moments de la journée, mais tolérer des périodes de perturbation beaucoup plus longues le reste du temps. Voici quelques-unes des manières dont vous pouvez diviser une même application en différents éléments constitutifs, afin d’évaluer les exigences de disponibilité pour chaque partie. Cette façon de procéder a pour avantage de permettre de concentrer vos efforts (et dépenses) sur la disponibilité en fonction de besoins spécifiques, plutôt que de concevoir l’ensemble du système sur la base de l’exigence la plus stricte.

Chez AWS, nous divisons souvent les services en deux, avec un « plan de données » et un « plan de contrôle ». Le plan de données vise à fournir un service en temps réel, tandis que les plans de contrôle servent à configurer l’environnement. Par exemple, les instances Amazon EC2, les bases de données Amazon RDS et les opérations de lecture/écriture sur les tables Amazon DynamoDB sont autant d’opérations qui relèvent du plan de données. En revanche, le lancement de nouvelles instances EC2 ou bases de données RDS, ou l’ajout ou la modification des métadonnées de table dans DynamoDB sont considérés comme des opérations de plan de contrôle. Tandis que de hauts niveaux de disponibilité sont importants pour l’ensemble de ces fonctionnalités, les plans de données ont généralement des objectifs de conception de disponibilité plus élevés que les plans de contrôle. Par conséquent, les charges de travail avec des exigences de haute disponibilité doivent éviter la dépendance d’exécution vis-à-vis des opérations du plan de contrôle.

La plupart des clients AWS adoptent une approche similaire pour évaluer leurs applications avec un esprit critique et identifier les sous-composants avec différents besoins de disponibilité. Les objectifs de conception de disponibilité sont ensuite adaptés aux différents aspects et les efforts de travail appropriés sont mis en œuvre pour concevoir le système. AWS a accumulé une expérience importante dans l’ingénierie d’applications avec un éventail d’objectifs de conception de disponibilité, y compris des services avec une disponibilité de 99,999 % ou plus. AWS Les architectes de solution peuvent vous aider à concevoir de manière appropriée en fonction de vos objectifs de disponibilité. Impliquer AWS de manière précoce dans votre processus de conception nous permet de vous aider à atteindre vos objectifs de disponibilité. La planification pour la disponibilité ne se fait pas uniquement avant le lancement de votre charge de travail. Elle s’effectue également en continu de manière à affiner votre conception à mesure que vous accumulez de l’expérience opérationnelle, tirez des enseignements des événements réels et êtes confronté à différents types de défaillances. Vous pouvez ensuite appliquer l’effort de travail approprié pour améliorer votre mise en œuvre.

Les besoins en disponibilité requis pour une charge de travail doivent être alignés sur les besoins et la criticité de l’entreprise. En commençant par définir un cadre de criticité commerciale avec une RTO, un RPO et une disponibilité spécifiques, vous pouvez évaluer chaque charge de travail. Une telle approche exige que les personnes impliquées dans la mise en œuvre de la charge de travail connaissent le cadre et l’impact de leur charge de travail sur les besoins de l’entreprise.