Ingénierie du chaos pour Rust : comment rendre une application incassable

Votre serveur Rust est-il parfait ? Vérifions-le

Vous avez écrit en Rust un serveur qui traite des milliers de requêtes par seconde. Le compilateur est satisfait, clippy ne dit rien, les tests passent. Mais que se passe-t-il si la base de données se déconnecte soudainement ? Ou si la carte réseau commence à « dysfonctionner » ? Ou si le disque est plein ?

Dans les tests traditionnels, nous vérifions que le code fonctionne comme prévu. Le Chaos engineering, c'est autre chose : nous vérifions que le système survit malgré tout. Et Rust, avec son accent sur la fiabilité et la performance, est un terrain idéal pour ce genre d'expériences.

Cet article n'est pas une redite ennuyeuse de la documentation. Nous passerons de la théorie à la pratique : je montrerai comment intégrer le chaos engineering pour les applications Rust à l'aide d'outils et de code concrets.

Qu'est-ce que le Chaos Engineering et pourquoi en tant que développeur Rust ?

Le Chaos engineering est une discipline d'expérimentation sur les systèmes distribués visant à identifier leurs points faibles avant qu'ils ne se manifestent en production. Netflix, considéré comme le pionnier de cette approche, utilise l'outil Chaos Monkey pour désactiver aléatoirement des serveurs.

Pourquoi est-ce important spécifiquement pour Rust ? Parce que Rust est souvent choisi pour les systèmes critiques :

• Services réseau (proxy, équilibreurs de charge, passerelles API)
• Systèmes embarqués (IoT, automobiles)
• Nœuds blockchain et systèmes financiers
• Traitement de flux de données

Dans tous ces cas, le coût d'une erreur est élevé. Le Chaos engineering permet de s'assurer que votre application Rust survivra non seulement à la charge normale, mais aussi au chaos du monde réel.

Outils pour le Chaos Engineering dans l'écosystème Rust

Bien que l'écosystème Rust soit plus jeune que celui de Java ou Go, nous disposons déjà de plusieurs bibliothèques matures pour introduire le chaos.

Nous allons nous concentrer sur un exemple pratique utilisant fault-injection et l'émulation de problèmes réseau.

Exemple pratique : « Éteindre l'incendie » dans un service Rust

Supposons que nous ayons un serveur HTTP simple basé sur axum qui fait quelque chose (par exemple, appelle une API externe). Nous voulons vérifier comment il se comportera si le service externe devient indisponible ou commence à répondre avec un délai.

Étape 1 : Serveur de base avec une « faille »

Écrivons un serveur qui effectue une requête vers httpbin.org (simulation d'un service externe) :

use axum::{Router, routing::get, response::Json};use reqwest::Client;use std::sync::Arc;use serde_json::Value;

#[tokio::main]async fn main() {    let client = Arc::new(Client::new());

    let app = Router::new()        .route("/fetch", get(handler))        .with_state(client);

    axum::Server::bind(&"0.0.0.0:3000".parse().unwrap())        .serve(app.into_make_service())        .await        .unwrap();}

async fn handler(client: Arc<Client>) -> Result<Json<Value>, (StatusCode, String)> {    let resp = client.get("https://httpbin.org/uuid")        .timeout(std::time::Duration::from_secs(5))        .send()        .await        .map_err(|e| (StatusCode::SERVICE_UNAVAILABLE, e.to_stri