Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Résilience dans Amazon Kinesis Data Streams
L'infrastructure AWS mondiale est construite autour des AWS régions et des zones de disponibilité. AWS Les régions fournissent plusieurs zones de disponibilité physiquement séparées et isolées, connectées par un réseau à faible latence, à haut débit et hautement redondant. Avec les zones de disponibilité, vous pouvez concevoir et exploiter des applications et des bases de données qui basculent automatiquement d’une zone de disponibilité à l’autre sans interruption. Les zones de disponibilité sont plus hautement disponibles, tolérantes aux pannes et évolutives que les infrastructures traditionnelles à un ou plusieurs centres de données.
Pour plus d'informations sur AWS les régions et les zones de disponibilité, consultez la section Infrastructure AWS mondiale
Outre l'infrastructure AWS mondiale, Kinesis Data Streams propose plusieurs fonctionnalités pour répondre à vos besoins en matière de résilience et de sauvegarde des données.
Reprise après sinistre dans Amazon Kinesis Data Streams
Un incident peut se produire aux niveaux suivants lorsque vous utilisez une Amazon Kinesis Data Streams pour traiter des données à partir d'un flux :
-
Un processeur d'enregistrements peut échouer
-
Une application de travail peut échouer, ou l'instance de l'application qui a instancié l'application de travail peut échouer
-
Une instance EC2 qui héberge une ou plusieurs instances de l'application peut échouer
Défaillance du processeur d'enregistrement
Le travailleur invoque les méthodes du processeur d'enregistrements à l'aide de ExecutorService
Défaillance du travailleur ou de l'application
Si une application de travail ou une instance de Amazon Kinesis Data Streams échoue, vous devez détecter et gérer la situation. Par exemple, si la méthode Worker.run lève une exception, vous devez l'intercepter et la traiter.
En cas de défaillance de l'application elle-même, vous devez détecter cette défaillance et redémarrer l'application. Lorsque l'application démarre, elle instancie une nouvelle application de travail, qui à on tour instancie de nouveaux processeurs d'enregistrements auxquels sont attribuées automatiquement des partitions à traiter. Il peut s'agir des mêmes partitions que ces processeurs d'enregistrements traitaient avant la défaillance ou de partitions qui sont nouvelles pour ces processeurs.
Dans une situation dans laquelle l'application de travail ou l'application échoue, l'échec n'est pas détecté et d'autres instances de l'application s'exécutent sur d'autres instances EC2, les applications de travail sur ces autres instances gèrent l'échec. Elles créent d'autres processeurs d'enregistrements pour traiter les partitions qui ne sont plus traitées par l'application de travail en échec. La charge de ces autres instances EC2 augmente en conséquence.
Le scénario décrit ici suppose que, malgré la défaillance de l'application de travail ou de l'application, l'instance EC2 hébergeante est encore exécutée et n'est donc pas redémarrée par un groupe Auto Scaling.
Défaillance de l'instance Amazon EC2
Nous vous recommandons d'exécuter les instances EC2 de votre application dans un groupe Auto Scaling. Ainsi, si l'une des instances EC2 a une défaillance, le groupe Auto Scaling lance automatiquement une nouvelle instance pour la remplacer. Vous devez configurer les instances pour lancer votre application Amazon Kinesis Data Streams au démarrage.
