Приключения с Go и YDB Serverless: как я уложился в бесплатный тир Yandex Cloud после Spring Boot и PostgreSQL

Долгое время я пытался научиться слепому десятипальцевому методу печати, но всегда это заканчивалось поражением. Учился на Keybr — на нём освоил английский. Частотный метод, когда ты печатаешь настоящие слова из самых частых букв, мне подошёл. Но столкнулся с тем, что заглавные буквы, пунктуация и цифры спрятаны за кучей настроек. Подумал — зачем это прятать, если можно сделать структурированные этапы и дать чёткий путь прохождения? Так я начал разработку TypeStep — тренажёра слепой печати с частотным методом и этапами прохождения. А теперь — про то, на чём это всё построено и с чем пришлось столкнуться.

Выбор стека: почему Go, а не Spring Boot

Мой основной опыт в разработке — это стек Java и Spring Boot. Да, вначале это были EJB и application-серверы, но в мире, где все используют микросервисную архитектуру, в Java почти все сидят на Spring Boot. Также был опыт использования облаков, в основном AWS.

В этот раз я решил использовать Yandex Cloud и посмотреть, что же происходит на российском рынке и где мы сейчас в плане облачной инфраструктуры.

Сразу скажу: вкладываться и платить за виртуальные серверы я не хотел. Бюджет ограничен, хотел создать максимально экономичное приложение — и в плане производительности, и в плане денег. Это добавило дополнительной сложности, потому что будь у меня возможность — я бы выбрал что-то типа ECS Fargate + Spring Boot + PostgreSQL. В Яндексе прямого аналога Fargate нет, поэтому выбор пал на Serverless Containers и YDB.

Для Serverless Containers Spring Boot не подходит — долгое время старта и проблема прогрева. Проще говоря, первые запросы после деплоя будут тормозить. Скажу честно: на одном из прошлых проектов я пробовал засунуть уже работающий Spring Boot в GraalVM — с наскока не получилось, это требует времени, чтобы разобраться. Поэтому для бессерверной архитектуры я решил попробовать Go, хотя знаний и опыта в нём не было.

Почитав немного и попробовав hello world и REST с GET /health, я был удивлён временем компиляции и холодного запуска. Go компилируется в один статический бинарник — никакой JVM, никакого прогрева JIT-компилятора, никаких зависимостей в рантайме. Контейнер с Go-бинарником стартует за миллисекунды, а не за секунды, как со Spring Boot. Для бессерверных контейнеров, где контейнер может подниматься на каждый запрос, это критично.

YDB вместо PostgreSQL: экономика

Дальше — СУБД. Да, в Яндексе есть Serverless PostgreSQL, но для меня это была слишком большая стоимость. Поэтому решил попробовать YDB. Быстро прочитал статьи, как стартануть, и вот я уже пишу первые SQL-запросы. Выглядело очень сладко — 1 млн магических Request Units в месяц бесплатно. Я не сделал большого исследования (о чём впоследствии пожалел, но не очень сильно) и не вдавался в то, как же на самом деле они считаются. Даже до сих пор это немного магия для меня, с учётом прочитанных статей и документации.

В этой статье я опишу, с чем сталкивался как Java-разработчик и как решал проблемы. Не претендую на то, что все решения оптимальны и соответствуют лучшим практикам этих технологий, но надеюсь, что статья будет полезна людям, которые будут использовать похожий стек.

Архитектура

Всё максимально просто и не добавляет дополнительной стоимости. Фронтенд — Next.js со статической генерацией, лежит в Object Storage и отдаётся напрямую. Бэкенд — Go в Docker-контейнере на Serverless Containers. База — YDB Serverless. Браузер загружает статику из Object Storage, а API-запросы отправляет в Serverless Container. Без API Gateway, без лишних прослоек.

Первые шаги с Go и YDB

И вот я уже пишу SQL, используя Go и YDB. Да, после того как долгое время используешь JPA и Repository, переходить на чистое написание и проектирование DB-слоя кажется немного странным. Но ничего — было время, когда я писал на JDBC и jOOQ, так что быстро справился.

Создаю слой DB-сущностей, для них — репозитории, где использую YQL. С первыми запросами пришлось повозиться: не получалось написать с первого захода, но используя примеры с Яндекса, всё-таки преодолел.

Было непривычно делать такие вещи — например, для колонки перечислений. После Java, где enum просто работает из коробки с JPA, в Go приходится писать руками:

type StageType string

const (
    Lowercase   StageType = "lowercase"
    Uppercase   StageType = "uppercase"
    Punctuation StageType = "punctuation"
    Numbers     StageType = "numbers"
)

А затем добавлять преобразование для сканирования из базы и обратно:

func (s *StageType) Scan(value interface{}) error {
    return ScanStringEnum(s, value, "StageType")
}

func (s *StageType) Value() (driver.Value, error) {
    return string(*s), nil
}

В JPA тоже есть возможность кастомизировать маппинг enum’ов, но если строковое представление совпадает с именем — это просто работает из коробки.

Методы в репозиториях получаются примерно такие — покажу на упрощённом примере:

func (r *ItemRepository) CreateItem(ctx context.Context, item Item) (*Item, error) {
    var result *Item
    err := r.txManager.DoTx(ctx, func(ctx context.Context, tx table.TransactionActor) error {
        res, err := tx.Execute(ctx, `
            DECLARE $id AS Utf8;
            DECLARE $name AS Utf8;
            DECLARE $status AS Utf8;
            DECLARE $created_at AS Datetime;

            INSERT INTO items (id, name, status, created_at)
            VALUES ($id, $name, $status, $created_at)
            RETURNING id, name, status, created_at;
        `,
            table.NewQueryParameters(
                table.ValueParam("$id", types.UTF8Value(item.Id)),
                table.ValueParam("$name", types.UTF8Value(item.Name)),
                table.ValueParam("$status", types.UTF8Value(string(item.Status))),
                table.ValueParam("$created_at", types.DatetimeValueFromTime(item.CreatedAt)),
            ),
        )
        if err != nil {
            return fmt.Errorf("failed to execute CreateItem: %w", err)
        }
        defer res.Close()

        // ... scan result into &result
        return res.Err()
    })
    return result, err
}

Суть в том, что каждое поле нужно объявить через DECLARE, передать как типизированный параметр и не забыть просканировать при чтении. Добавляешь новую колонку — и начинается: добавь DECLARE, добавь параметр, добавь поле в Scan при чтении, при обновлении, при вставке. После привычного JPA, где ты просто добавляешь поле в Entity и всё подхватывается автоматически, это ощущается как шаг назад. Но зато видишь каждый запрос, который уходит в базу.

Многие ругают JPA и Hibernate за то, что генерируется много запросов и не всегда понятно, как оно работает. Но лично мне разрабатывать приложения с не очень сложной структурой куда приятнее на JPA. Да, если есть узкое место, где именно JPA мешает, стоит переписать на более низком уровне, используя JDBC. Но я не сторонник преждевременной оптимизации — делай простые вещи просто.

Транзакции без @Transactional

Следующая проблема: YDB — распределённая база и не поддерживает foreign keys. Ладно, не проблема — есть транзакции, и YDB позволяет их использовать.

В Spring Boot я бы сделал примерно так:

@Transactional
public User createUser(User user) {
    UserEntity entity = userMapper.toEntity(user);
    entity = userRepository.save(entity);

    ProgressionEntity progression = new ProgressionEntity();
    progression.setUserEntity(entity);
    progressionRepository.save(progression);

    return userMapper.toDto(entity);
}

Повесил @Transactional, вызвал два репозитория — и если что-то упадёт, всё откатится. В Go так не получится.

Первый подход: транзакции внутри каждого метода репозитория. Но тогда нельзя объединить два репозитория в одну транзакцию — каждый коммитит сам по себе.

Второй подход: вынести создание транзакции в сервис, а в репозитории передавать tx как параметр. Работает, но появляются дублирующиеся методы — CreateUser (сам создаёт транзакцию) и CreateUserTx (принимает существующую). Дублирование множится с каждым новым методом.

В итоге я ввёл простой Transaction Manager:

func (t *TransactionManager) DoTx(ctx context.Context, fn func(ctx context.Context, tx table.TransactionActor) error) error {
    if tx, ok := TxFromContext(ctx); ok {
        return fn(ctx, *tx)
    }
    return t.ydb.NativeDriver.Table().DoTx(ctx, func(ctx context.Context, tx table.TransactionActor) error {
        ctx = context.WithValue(ctx, txKey{}, &tx)
        return fn(ctx, tx)
    })
}

Суть: если в контексте уже есть транзакция — переиспользуем её, если нет — создаём новую. Примерно как пропагация транзакций в Spring, только руками. Теперь и сервисы, и репозитории инжектят этот менеджер, дублирование ушло, и можно спокойно объединять несколько операций в одну транзакцию.

IoC и DI без фреймворка

Ещё одна вещь — IoC-контейнер, который в Spring Boot воспринимается как само собой разумеющееся. Навесил @Component, @Autowired — и фреймворк сам разруливает граф зависимостей через рефлексию, проксирование и BeanFactory. В Go ничего этого нет. Захотел заинжектить зависимость — будь добр, добавь параметр в конструктор сам. Все зависимости собираются руками в main.go, в нужном порядке: сначала создаёшь подключение к базе, потом репозитории, потом сервисы, потом хэндлеры. Никакой магии — но зато точно знаешь, что куда идёт, и не получишь циклическую зависимость в рантайме.

Честно, вначале я гуглил что-то типа «Spring Boot and Go transaction» и находил на Reddit и Stack Overflow топики, где спрашивали «есть ли на Go что-то похожее на Spring Boot?», а ответы были из разряда «БОЖЕ УПАСИ». Это, конечно, улыбнуло.

Обработка ошибок

Go, как и Java, не блещет синтаксическим сахаром, и базовый синтаксис достаточно прост. Горутины мне не понадобились — своя конкурентность в приложении попросту не нужна.

Было сложно привыкнуть к обработке ошибок. В Java кинул исключение — и в стектрейсе видишь всю цепочку вызовов: какой файл, какая строка, что вызывало что. В Go ошибки — это просто значения, и стектрейса по умолчанию нет. Получаешь что-то вроде failed to execute query: connection refused — и гадай, из какого метода это прилетело.

В итоге пришёл к подходу с уникальными метками в каждом fmt.Errorf. Каждый уровень оборачивает ошибку со своим контекстом:

func (s *ItemService) ProcessItem(ctx context.Context, id string) error {
    item, err := s.repo.FindById(ctx, id)
    if err != nil {
        return fmt.Errorf("ProcessItem: failed to find item %s: %w", id, err)
    }

    if err := s.repo.UpdateStatus(ctx, item, "processed"); err != nil {
        return fmt.Errorf("ProcessItem: failed to update status for %s: %w", id, err)
    }

    return nil
}

func (r *ItemRepository) FindById(ctx context.Context, id string) (*Item, error) {
    // ...
    if err != nil {
        return nil, fmt.Errorf("ItemRepository.FindById: query failed: %w", err)
    }
    // ...
}

В логах это разворачивается в цепочку: ProcessItem: failed to find item abc123: ItemRepository.FindById: query failed: connection refused. Не полноценный стектрейс, но по уникальным меткам сразу видно, где именно упало. Главное — не лениться и писать осмысленные сообщения, а не просто failed.

Оптимизация Request Units: как я сжёг бесплатный тиер и починил это

Когда я начинал разработку на YDB, я проектировал схему так, как делал бы это с PostgreSQL. Это было ошибкой.

Статистику по буквам я хранил каждую в отдельной строке. Когда приходили данные по уроку, происходило следующее: детальная статистика по каждой клавише вставлялась в одну таблицу, а агрегированные данные по тем же клавишам обновлялись в другой. Всё это в цикле — сколько клавиш пришло, столько INSERT’ов и UPDATE’ов.

Какого же было моё удивление, когда я задеплоил этот код в облако и посмотрел на потребление. Распределённая СУБД не любит таких операций. На практике я увидел, что метод, который обрабатывал результаты одного урока, обходился примерно в 500 RU.

Схематично это выглядело так:

func saveLessonResults(ctx context.Context, lesson Lesson, stats map[string]KeyStats) error {
    return txManager.DoTx(ctx, func(ctx context.Context, tx table.TransactionActor) error {
        // 1. Сохранить сессию урока
        lessonId, err := saveSession(ctx, tx, lesson)

        // 2. INSERT статистики по каждой клавише — в цикле!
        for letter, keyStats := range stats {
            saveSingleLetterStat(ctx, tx, lessonId, letter, keyStats)
        }

        // 3. UPDATE агрегатов по каждой клавише — тоже в цикле!
        for letter := range changedLetters {
            updateSingleLetterAggregate(ctx, tx, letter)
        }

        // 4. UPDATE прогресса пользователя
        updateProgression(ctx, tx, progression)

        return nil
    })
}

Немного о том, как считаются RU в YDB. Для YQL-запросов вычисляются две стоимости — CPU и ввод-вывод — и берётся максимальная. Чтение тарифицируется блоками по 4 КБ: одна операция чтения = 1 RU. Запись — блоками по 1 КБ: одна операция записи = 2 RU. При этом берётся максимум между количеством строк и количеством блоков. Даже маленькая строка — это минимум 2 RU на запись.

Шаг 1: батчи вместо циклов

Классических батчей в YDB нет, но можно передать все данные списком и выполнить один запрос, сэкономив на создании плана выполнения:

// Вместо цикла с отдельными INSERT — один запрос со списком
func saveLetterStatsBatch(ctx context.Context, tx table.TransactionActor, rows []LetterStat) error {
    _, err := tx.Execute(ctx, `
        DECLARE $rows AS List<Struct<
            lesson_id: Int64,
            letter: Utf8,
            correct: Int32,
            speed_wpm: Int32
        >>;

        INSERT INTO letter_stat (lesson_id, letter, correct, speed_wpm)
        SELECT lesson_id, letter, correct, speed_wpm
        FROM AS_TABLE($rows);
    `, buildListParams(rows))
    return err
}

Тот же приём для UPDATE — собираем все изменённые строки в список и делаем UPSERT ... SELECT ... FROM AS_TABLE($rows).

Это уменьшило количество компиляций запросов, но не решило главную проблему — количество добавляемых и изменяемых строк осталось тем же, а каждая строка стоит RU.

Шаг 2: объединить операции в один YQL-запрос

Дальше я объединил INSERT в одну таблицу, UPSERT в другую и UPDATE прогресса — всё в одном YQL-запросе:

func saveLessonWritesBatch(ctx context.Context, tx table.TransactionActor, ...) error {
    _, err := tx.Execute(ctx, `
        DECLARE $detail_rows AS List<Struct<...>>;
        DECLARE $aggregate_rows AS List<Struct<...>>;
        DECLARE $prog_id AS Int32;
        ...

        -- Детальная статистика
        INSERT INTO letter_stat (...)
        SELECT ... FROM AS_TABLE($detail_rows);

        -- Агрегаты
        UPSERT INTO letter_stats (...)
        SELECT ... FROM AS_TABLE($aggregate_rows);

        -- Прогресс
        UPDATE user_progression
        SET target_wpm = $target_wpm, ...
        WHERE id = $prog_id;
    `, params)
    return err
}

Один запрос, один план, одна транзакция. Но строк-то всё равно много — и каждая стоит RU.

Шаг 3: переделать схему — JSON вместо отдельных строк

Морщась, я решил переделать схему. Честно, на PostgreSQL я бы так не стал делать. Но для экономии Request Units пошёл на это.

Там, где раньше каждая буква хранилась отдельной строкой с UPDATE при каждом уроке, я создал одну колонку:

LetterStatsJson string `db:"letter_stats_json"`

Все агрегированные данные по клавишам теперь хранятся в одном JSON-поле. Чтение одной строки — 1 RU (пока данные меньше 4 КБ, это один блок чтения). Запись одной строки с JSON в 3 КБ — 3 блока по 1 КБ = 6 RU. Но это всё равно в разы дешевле, чем обновлять 15 отдельных строк по 2 RU каждая.

Да, это добавило работы в коде: десериализация JSON → проход по нужным клавишам → пересчёт → сериализация обратно → сохранение. Но это миллисекунды по сравнению с тем, сколько стоили отдельные строки в RU.

С историей уроков провернул тот же трюк, но с нюансом. Чтобы чтение укладывалось в один блок (4 КБ), я поставил порог в 3 КБ — выбрал на глаз с запасом, потому что данные в строке не выровнены по границам блоков. Пока JSON меньше 3 КБ — добавляю новую запись в существующую строку. Как только превышает — создаю новую строку с чистым JSON:

func saveLessonSession(ctx context.Context, tx table.TransactionActor,
    progressionId int32, entry SessionEntry) error {
    // Находим последнюю строку
    lastRow := findLatestRow(ctx, tx, progressionId)

    if lastRow != nil && lastRow.JsonSize < maxJsonSize {
        // Добавляем в существующую строку
        sessions := unmarshal(lastRow.SessionsJson)
        sessions = append(sessions, entry)
        updateRow(ctx, tx, lastRow.Id, marshal(sessions))
    } else {
        // Создаём новую строку
        insertRow(ctx, tx, progressionId, marshal([]SessionEntry{entry}))
    }
    return nil
}

Результат

Изначально один урок стоил 500–1000 RU. После всех изменений:

• Холодный контейнер (без закэшированных планов, первый запрос): 50–70 RU

• Прогретый контейнер (планы в кэше): 5–10 RU

Разница между холодным и прогретым контейнером объясняется кэшированием планов — YDB не перекомпилирует запрос, если план уже в кэше, а компиляция тратит CPU, который тоже переводится в RU.

Для мониторинга я использовал системную таблицу YDB:

SELECT IntervalEnd, QueryText, Count, SumRequestUnits, MaxRequestUnits
FROM `.sys/query_metrics_one_minute`
ORDER BY IntervalEnd DESC, MaxRequestUnits DESC
LIMIT 50;

Итоги

Я попробовал Yandex Cloud, написал бэкенд на Go, разобрался с YDB и подключил платёжку через Робокассу.

Честно — проект денег не приносит. Похожих тренажёров много, привлечь пользователей непросто, и будут ли они платить — я не знаю. Потратил на это много времени. Но опыт получил: Go с нуля, YDB, бессерверная архитектура, оптимизация под Request Units. На данный момент всё укладывается в бесплатный тир Яндекса.

Я всегда работал наёмным программистом и всегда хотел написать что-то своё, что приносило бы доход. Пока я далёк от этого, но маленький кирпичик положен.

Если интересно попробовать сам тренажёр — typestep.app.