Хаос-инжиниринг для Kotlin: ломаем приложение, чтобы спасти продакшн

Хаос-инжиниринг для Kotlin: ломаем приложение, чтобы спасти продакшн

Представьте: ваше Kotlin-приложение работает идеально. Все тесты зелёные, latency в норме, пользователи довольны. Вы выкатываете релиз в пятницу вечером и... через час прод лежит. База данных не отвечает, Kafka-кластер перегружен, а микросевис аутентификации упал из-за race condition, который не ловился в тестах. Знакомая боль?

Chaos engineering (или «инжиниринг хаоса») — это не про саботаж. Это про уверенность. Мы намеренно ломаем систему, чтобы понять, как она поведёт себя в реальной аварии. Kotlin с его coroutines, Flow и строгой типизацией даёт отличную базу для внедрения chaos engineering. В этой статье мы разберём, как привнести хаос в Kotlin-приложение, не сломав продакшн окончательно, и напишем реальный код для тестирования отказов.

Почему chaos engineering важен для Kotlin-разработчика?

Kotlin всё чаще выбирают для backend-микросервисов, особенно в связке с Ktor, Spring Boot или http4k. Эти системы распределённые: десятки сервисов, очереди сообщений, базы данных. Чем сложнее архитектура, тем выше вероятность каскадного отказа. Chaos engineering помогает ответить на вопросы:

• Что будет, если Redis упадёт на 30 секунд?
• Как поведёт себя coroutine-пул при внезапном всплеске трафика?
• Выдержит ли приложение потерю сети между сервисами?
• Есть ли у нас «чёрные лебеди» — скрытые зависимости, о которых все забыли?

Внедрение chaos engineering в Kotlin-проекты — это инвестиция в resilience. Вы не ждёте, пока баг упадёт на пользователя, а создаёте условия, при которых он проявится в безопасной среде.

Базовые принципы: не ломайте всё сразу

Chaos engineering — это не «удалить базу данных и смотреть, что будет». Это научный метод. Следуйте четырём шагам:

1. Определите steady state — метрики нормальной работы (latency p99, throughput, error rate).
2. Сформулируйте гипотезу — «При отказе сервиса X система продолжит отвечать на запросы с задержкой не более 500 мс».
3. Внедрите хаос — отключите сервис, задержите трафик, загрузите CPU.
4. Сравните результат — если steady state нарушен, гипотеза неверна, нужно фиксить.

Kotlin позволяет автоматизировать эти шаги с помощью корутин и библиотек.

Инструменты для chaos engineering в Kotlin-экосистеме

Не нужно изобретать велосипед. Вот что стоит взять на вооружение:

• Chaos Monkey for Spring Boot — если вы используете Spring, этот инструмент умеет случайным образом отключать инстансы. Работает и с Kotlin.
• Resilience4j — библиотека для circuit breaker, rate limiter, retry и bulkhead. Отлично подходит для эмуляции отказов на уровне кода.
• Gremlin — коммерческий сервис, поддерживающий JVM-приложения. Позволяет внедрять хаос на уровне сети, CPU, памяти.
• Kotlin Coroutines + Flow — собственные эксперименты с задержками и ошибками.
• TestContainers — поднимает контейнеры с БД, очередями и эмулирует их падение.

Пишем код: эмуляция хаоса с помощью Resilience4j

Давайте создадим простой сервис на Kotlin с Ktor, который обращается к внешнему API (гипотетическому сервису погоды). Мы добавим circuit breaker и искусственно вызовем сбой.

// build.gradle.kts
dependencies {
    implementation("io.github.resilience4j:resilience4j-circuitbreaker:2.1.0")
    implementation("io.github.resilience4j:resilience4j-kotlin:2.1.0")
    implementation("io.ktor:ktor-server-core:2.3.0")
    implementation("io.ktor:ktor-server-netty:2.3.0")
    implementation("io.ktor:ktor-client-core:2.3.0")
    implementation("io.ktor:ktor-client-cio:2.3.0")
}

Теперь напишем конфигурацию circuit breaker и симуляцию отказа:

import io.github.resilience4j.circuitbreaker.CircuitBreakerConfig
import io.github.resilience4j.circuitbreaker.CircuitBreakerRegistry
import io.github.resilience4j.kotlin.circuitbreaker.decorateFunction
import kotlinx.coroutines.delay
import java.time.Duration

// Настраиваем circuit breaker
val circuitBreakerConfig = CircuitBreakerConfig.custom()
    .failureRateThreshold(50.0) // 50% ошибок
    .waitDurationInOpenState(Duration.ofSeconds(10))
    .slidingWindowSize(5)
    .build()

val registry = CircuitBreakerRegistry.of(circuitBreakerConfig)
val circuitBreaker = registry.circuitBreaker("weatherService")

// Функция, которая эмулирует внешний вызов
suspend fun fetchWeather(city: String): String {
    // Имитация хаоса: случайный отказ
    if (Math.random() < 0.3) {
        delay(2000) // задержка
        throw RuntimeException("Service unavailable")
    }
    return "Weather in $city: sunny, +25°C"
}

// Декорируем функцию circuit breaker'ом
val decoratedFetchWeather = circuitBreaker.decorateFunction(
    function = { fetchWeather(it) }
)

Теперь добавим Ktor-роутинг и вызовем декорированную функцию:

import io.ktor.server.application.*
import io.ktor.server.response.*
import io.ktor.server.routing.*
import io.ktor.server.engine.*
import io.ktor.server.netty.*

fun main() {
    embeddedServer(Netty, port = 8080) {
        routing {
            get("/weather/{city}") {
                val city = call.parameters["city"] ?: "unknown"
                try {
                    val result = decoratedFetchWeather(city)
                    call.respondText(result)
                } catch (e: Exception) {
                    call.respondText("Fallback: weather data unavailable", status = io.ktor.http.HttpStatusCode.ServiceUnavailable)
                }
            }
        }
    }.start(wait = true)
}

Запустите приложение и пошлите несколько запросов. Вы увидите, как circuit breaker открывается после 50% ошибок и начинает возвращать fallback. Это и есть chaos engineering в действии — мы не ждём, пока сломается прод, а проверяем реакцию системы на отказ.

Тестирование хаоса с Kotlin Coroutines

Иногда нужно проверить поведение coroutine-диспетчеров при высокой нагрузке. Допустим, у вас есть пул потоков, и вы хотите узнать, что будет, если один из потоков «зависнет».

import kotlinx.coroutines.*
import kotlinx.coroutines.flow.*

// Эмуляция "зависшего" корутинного контекста
suspend