И хоть графики нормализованы по максимальным значениям, но по абсолютным данным видно, что просмотры упали в 4 раза.

В итоге я смахнул пыль с домена http://nikolaymatrosov.ru и развернул там копию этого блога. В качестве движка выбрал https://docusaurus.io/ второй версии.

Standalone блог даст возможность пользоваться более выразительными средствами, чем Medium, если мне захочется вставить D3 графики или еще какого-то интерактива добавить.

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

Я пока еще не решил, стоит ли продолжать публиковать новые посты или полностью заморозить этот блог.

Но вот туда я уже выложил новый пост с рассуждениями о том почему вам может быть не нужен API Gateway перед legacy-приложением развернутым на одной VM.

Начиная с версии 2.0 FluentBit поддерживает фильтры скомпилированные в WASM. При этом вы можете писать код на любом языке. У них в документации есть примеры на C, TinyGo и Rust.

Зачем вам может понадобиться свой фильтр?

Ну, например, вы можете захотеть описать маппинг полей. Да, вы можете описать его цепочкой фильтров modify, но это будет длинный и не самый читаемый конфиг.

Еще одна альтернатива — Lua. Но это не так прикольно. Если честно, я решил использовать, WASM именно потому, что мне давно хотелось его попробовать применить где-нибудь, а не потому что я провел глубокие сравнительные исследования WASM и Lua.

Установка инструментов.

Для начала нам понадобится поставить TinyGo. Он как зависимость хочет go. Ставить я буду через brew. Другие способы установки вы можете найти здесь.

brew install tinygo

У меня установилась версия tinygo version 0.27.0 darwin/amd64 (using go version go1.20.2 and LLVM version 15.0.0).

Код фильтра

Фильтр получается максимально простым.

1. Сначала мы вычитываем запись лога record. (L12–14)
2. Парсим полученную строку в JSON-объект. (L15–25)
3. Читаем значение нужного нам поля L27
4. Маппим его на новое значение.
5. И записываем обратно в объект L48–50

На что нужно обратить внимание.

1. Комментарий //export level_mapper на 10 строке важен. Без него компилятор не сохранит имя функции и мы не сможем вызвать ее из FluentBit.
2. На 52 строке мы дописываем в конец строки null byte. Он просигнализирует FluentBit об окончании возвращаемой из фильтра записи лога.

Теперь мы можем скомпилировать наш фильтр.

tinygo build --no-debug -scheduler=none -target=wasi -o filter.wasm ./filter.go

В итоге получается файл filter.wasm размером 123Kb. Не сказать, что мало, но и не много по сравнению с обычными go бинарными файлами. При помощи wasm-opt можно оптимизировать его еще немного, в итоге получив 118Kb. Оптимизированная версия фильтра, написанная на Rust и скомпилированная под WASM весит 161Kb.

И проверить его работоспособность запустив FluentBit со следующим конфигом.

[SERVICE]
    Flush        1
    Daemon       Off
    Log_Level    info


[INPUT]
    Name dummy
    Tag dummy.local
    Dummy {"level": "4", "message": "warn"}

[FILTER]
    Name wasm
    Match dummy.*
    WASM_Path filter.wasm
    Function_Name level_mapper
    Accessible_Paths .

[OUTPUT]
    Name  stdout
    Match *

Полный код https://github.com/nikolaymatrosov/fb-wasm-filter

На сегодняшний день Yandex Cloud Logging предоставляет возможность хранения логов в течение 3 дней. И даже если срок хранения расширят до месяца, это все равно не будет покрывать многие сценарии. Так как же организовать долгосрочное хранение логов? Для этого нам понадобится создать Data Stream, лог группу, которая будет в него писать, а так же Data Transfer, которы сможет перекладывать данные в какое-то долгосрочное хранилище. В этом примере я буду использовать Yandex Cloud Object Storage (аналог AWS S3). Это самый дешевый из возможных вариантов, при этом обеспечивающий не только хранение, но и с выходом Yandex Query и возможность анализа хранимых логов.

А теперь давайте по порядку.

Создаем инфраструктуру

Создадим serverless базу YDB

Она нам понадобится для того, чтобы в ней создать поток Data Stream.

В параметрах укажем только что созданную базу. Если же выбрать минимальную конфигурацию потока, то он может быть вообще бесплатным, но не более одного такого потока привязанного к платежному аккаунту, далее платно.

Теперь создадим бакет, куда мы будем писать логи.

Теперь можно создать лог-группу в сервисе Cloud Logging. Ее мы сможем указывать в функции, serverless контейнере, API Gateway или любом другом месте откуда мы собираемся писать логи.

Теперь нам нужно создать эндпоинты Data Transfer: источник данных из стрима logs и приемник данных — наш бакет sls-log-to-s3.

А теперь объединить их в трансфер.

Теперь трансфер нужно активировать.

Вот в принципе и все. Теперь остается только создать функцию, передать в нее лог-группу и погенерировать логов, чтобы убедиться, что всё работает.

import logging
import random
from pythonjsonlogger import jsonlogger


class YcLoggingFormatter(jsonlogger.JsonFormatter):
    def add_fields(self, log_record, record, message_dict):
        super(YcLoggingFormatter, self).add_fields(log_record, record, message_dict)
        log_record['logger'] = record.name
        log_record['level'] = str.replace(str.replace(record.levelname, "WARNING", "WARN"), "CRITICAL", "FATAL")

logHandler = logging.StreamHandler()
logHandler.setFormatter(YcLoggingFormatter('%(message)s %(level)s %(logger)s'))

logger = logging.getLogger('MyLogger')
logger.propagate = False
logger.addHandler(logHandler)
logger.setLevel(logging.DEBUG)

def handler(event, context):
    val = random.random()
    if val > .8:
        logger.error("some error log", extra={"val": val})
    elif val > .5:
        logger.info("test logging", extra={"val": val})
    else:
        logger.debug("everything is fine", extra={"val": val})

    
    return {
        'statusCode': 200,
        'body': 'Hello World!',
    }

И в requirements.txt добавить python-json-logger==2.0.4

Анализ

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

Давайте теперь попробуем проанализировать их при помощи Yandex Query. Для этого создадим новое соединение, нажав на кнопку «Обработать в YQ».

Начать можно с простого запроса

SELECT *
FROM `sls-log-to-s3-2023/04/18/`.`2023/04/18/`
WITH
(
    format=json_as_string, 
    SCHEMA
        (
            Data Json
        )
)
LIMIT 100

Тут мы указываем, что будем обращаться к созданному ранее источнику `sls-log-to-s3–2023/04/18/` по пути `2023/04/18/`. Таким образом YQ возьмет все файлы за день и будет использовать данные из них при выполнении запроса.

Далее мы указываем формат json_as_string. Подробнее про форматы можно прочитать в документации.

Отлично, теперь мы видим, шейп данных.

Для того чтобы обратиться к вложенным полям JSON-объекта мы будем использовать JSON_VALUE. К сожалению напрямую в GROUP BY его мы использовать не можем, но можем завернуть извлечение данных в подзапрос, а группировку вынести выше.

Вот пример чуть более сложного запроса с аггрегациями.

SELECT message, COUNT(*) as message_count, AVG(val) as avg_val
from (
    SELECT
    JSON_VALUE(Data, "$.resource.id") as resource_id, 
    JSON_VALUE(Data, "$.message") as message,
    Cast(JSON_VALUE(Data, "$.jsonPayload.val") as Double) as val,
    FROM `sls-log-to-s3-2023/04/18/`.`2023/04/18/`
    WITH
    (
        format=json_as_string, 
        SCHEMA
            (
                Data Json
            )
    )
)
GROUP BY message
HAVING COUNT(*) > 1
ORDER by message_count DESC

В завершении хочу добавить, что вы можете также настроить политики хранения данных в Object Storage, чтобы перекладывать старые логи по истечении какого-то времени в другие классы хранения или вообще удалять их.

Для начала создадим проект на основе примера Web API.

Базовое приложение

Отлично. Теперь пройдемся по изменениям, которые нужно внести в проект, чтобы он «взлетел» в Serverless Containers.

Как я писал в посте про запуск контейнера по триггеру на необходимо реализовать интерфейс HTTP сервера. К счастью, dotnet core Web API именно его и реализует и нам остается только добавить несколько настроек, чтобы выполнить главное условие — запускать сервер на порту, переданном приложение через переменную окружения PORT. Для этого в Program.cs добавим следующее:

var port = Environment.GetEnvironmentVariable("PORT") ?? "8080";
builder.WebHost.UseKestrel(
    serverOptions =>
    {
        serverOptions.ListenAnyIP(int.Parse(port));
    });

Теперь, нам нужно удалить еще одну настройку:

app.UseHttpsRedirection();

Она нам не понадобится так как вызов контейнера идет по HTTP, а в логах мы будем видеть следующие предупреждения, ведь порт для HTTPS мы не задаем:

warn: Microsoft.AspNetCore.HttpsPolicy.HttpsRedirectionMiddleware[3]
      Failed to determine the https port for redirect.

Еще я бы убрал из Dockerfile строки EXPOSE, чтобы не вводить в заблуждение, ведь наше приложение больше не использует эти порты.

EXPOSE 80
EXPOSE 443

Также можно почистить %project%/Properties/launchSettings.json от лишних параметров.

Теперь можно развернуть приложение и убедиться, что все работает. Я репозитории с примером буду делать это при помощи Terraform CDK. Работа с ним выходит за рамки этого туториала, но у меня есть отдельная статья про TF CDK. И так я перейду в папку cdk и выполню следующую команду.

TF_VAR_folderId=b1g*** TF_VAR_token=`yc iam create-token` \
  cdktf deploy --output ../cdktf.out

В результате будет собран docker image, запушен в облачный репозиторий и из него будет развернут serverless контейнер.

Авторизация

Если вы попробуете добавить авторизацию в ваше приложение развернутое в YC Serverless Containers вас ждет неприятный сюрприз: как сказано в документации заголовки Authorization и Cookie из запроса вырезаются, как и некоторые другие.

Что же делать? Ставить контейнер за API Gateway. Кроме возможности использовать авторизацию нормально, он также, например, позволит использовать свой собственный домен.

API Gateway

Для того чтобы создать API GW, нам понадобится OpenAPI спецификация описывающая наше API. Её можно написать руками, а можно сгенерировать на основе кода. Тем более в базовом примере и так уже используется пакет Swashbuckle для генерации спеки для Swagger. Установим CLI которую, будем вызывать при билде.

dotnet tool install SwashBuckle.AspNetCore.Cli --global

Теперь мы можем добавить в csproj команду для вызова этой утилиты.

<Target Name="OpenAPI" AfterTargets="Build" Condition="'$(Configuration)' == 'Debug'">
    <Exec Command="swagger tofile --output ./swagger.yaml --yaml $(OutputPath)$(AssemblyName).dll v1" WorkingDirectory="$(ProjectDir)" />
</Target>

В итоге мы получим swagger.yaml где будет OpenAPI 3.0 документ, описывающий наше API. Чтобы использовать его в API Gateway нам понадобится лишь одна доработка: нам нужно разметить объекты операций расширением спецификации x-yc-apigateway-integration, которе скажет гейтвею, что для этого запроса нужно вызвать контейнер.

Для этого нам понадобится написать класс имплементирующий интерфейс IOperationFilter. Его метод Apply будет вызываться для каждого объекта операций в OpenAPI спецификации и в нем мы сможем модифицировать операцию как захотим.

using Microsoft.OpenApi.Any;
using Microsoft.OpenApi.Models;
using Swashbuckle.AspNetCore.SwaggerGen;

namespace ServerlessContainerDemo.OpenAPI.Filters;

public class YcExtensionsFilter : IOperationFilter
{
    public void Apply(OpenApiOperation operation, OperationFilterContext context)
    {
        operation.Extensions.Add("x-yc-apigateway-integration", new OpenApiObject()
        {
            ["type"] = new OpenApiString("serverless_containers"),
            ["container_id"] = new OpenApiString("${container_id}"),
            ["service_account_id"] = new OpenApiString("${container_service_account_id}"),
        });
    }
}

Значения ${container_id} и ${container_service_account_id} мы подставим в шаблонизаторе в Terraform.

Теперь зарегистрируем фильтр в Program.cs.

builder.Services.AddSwaggerGen(c =>
{
    c.EnableAnnotations();
    c.SwaggerDoc("v1", new OpenApiInfo() {Title = "Serverless Container Demo", Version = "v1"});
    c.OperationFilter<YcExtensionsFilter>();
});

Добавляем авторизацию

Этот хэндлер приведен только для демонстрационных целей.

namespace ServerlessContainerDemo.Auth;

using System.Security.Claims;
using System.Text;
using System.Text.Encodings.Web;
using Microsoft.AspNetCore.Authentication;
using Microsoft.Extensions.Options;

public class BasicAuthenticationHandler : AuthenticationHandler<AuthenticationSchemeOptions>
{
    public BasicAuthenticationHandler(
        IOptionsMonitor<AuthenticationSchemeOptions> options,
        ILoggerFactory logger,
        UrlEncoder encoder,
        ISystemClock clock
    ) : base(options, logger, encoder, clock)
    {
    }

    protected override Task<AuthenticateResult> HandleAuthenticateAsync()
    {
        var authHeader = Request.Headers["Authorization"].ToString();
        if (authHeader != null && authHeader.StartsWith("basic", StringComparison.OrdinalIgnoreCase))
        {
            var token = authHeader.Substring("Basic ".Length).Trim();
            System.Console.WriteLine(token);
            var credentialString = Encoding.UTF8.GetString(Convert.FromBase64String(token));
            var credentials = credentialString.Split(':');
            if (credentials[0] == "admin" && credentials[1] == "admin")
            {
                var claims = new[] {new Claim("name", credentials[0]), new Claim(ClaimTypes.Role, "Admin")};
                var identity = new ClaimsIdentity(claims, "Basic");
                var claimsPrincipal = new ClaimsPrincipal(identity);
                return Task.FromResult(
                    AuthenticateResult.Success(new AuthenticationTicket(claimsPrincipal, Scheme.Name)));
            }

            Response.StatusCode = 401;
            Response.Headers.Add("WWW-Authenticate", "Basic");
            return Task.FromResult(AuthenticateResult.Fail("Invalid Authorization Header"));
        }
        else
        {
            Response.StatusCode = 401;
            Response.Headers.Add("WWW-Authenticate", "Basic");
            return Task.FromResult(AuthenticateResult.Fail("Invalid Authorization Header"));
        }
    }
}

Теперь добавим опции в конфигурацию приложения.

builder.Services.AddAuthentication()
    .AddScheme<AuthenticationSchemeOptions, BasicAuthenticationHandler>
        ("BasicAuthentication", null);
builder.Services.AddAuthorization(options =>
{
    var basicAuthenticationSchemePolicyBuilder = new AuthorizationPolicyBuilder("BasicAuthentication");
    options.AddPolicy("BasicAuthentication", basicAuthenticationSchemePolicyBuilder
        .RequireClaim(ClaimTypes.Role, "Admin")
        .Build());
});

И после этого мы можем использовать аннотацию Authorize на хэндлерах нашего контроллера:

[Authorize(Policy = "BasicAuthentication")]
[HttpGet(Name = "GetWeatherForecast")]
public IEnumerable<WeatherForecast> Get()

Теперь если мы вызовем эндпоинт с неправильной авторизацией то получим:

HTTP/2 401
date: Mon, 30 Jan 2023 22:15:54 GMT
content-length: 0
access-control-allow-origin: *
x-content-type-options: nosniff
x-serverless-gateway-path: /WeatherForecast
x-yf-remapped-date: Mon, 30 Jan 2023 22:15:54 GMT
x-yf-remapped-server: Kestrel
x-yf-remapped-www-authenticate: Basic
server: Yandex-API-Gateway/1.0

К сожалению вместо WWW-Authenticate в ответе API Gateway мы получим x-yf-remapped-www-authenticate. Это не позволит браузеру узнать, что ресурс требует Basic-авторизацию и отобразить окно ввода логина и пароля.

Асинхронные задачи

Если в двух словах, то вызов контейнера синхронен. То есть если вы ответите на запрос и поставите асинхронную задачу в надежде, что она выполнится позже, то разочарую вас этого не случится. Процессы которые оркестрируют работу контейнеров ничего не знают про асинхронные таски внутри них и к сожалению нет механизмов, чтобы они о них узнали. Так что вся критичная работа должна быть выполнена до ответа пользователю.

Есть возможность выполнения асинхронных задач через помещение их в очередь и разбор очереди при помощи триггера.

Подробнее про асинхронность в серверлесс средах Облака можно прочитать в отдельном посте.

Логирование

Пользовательские логи, которые пишет контейнер в стандартный поток вывода (stdout) и стандартный поток вывода ошибок (stderr) могут быть простыми и структурированными.

По умолчанию Web API приложение будет писать логи в стандартном формате, что будет восприниматься сервисом Cloud Logging как простые текстовые логи. В таком случае мы не имеем возможности фильтровать логи по уровню критичности, а также передавать дополнительные параметры. Чтобы это все заработало, нужно писать логи в JSON-формате. Тогда поля message или msg будут восприниматься, поле содержащее основной текст записи лога, поле level — как поле, указывающее уровень логирования.

Для того чтобы удобно это настроить мы можем воспользоваться библиотекой Serilog или Nlog. Я выбрал вторую.

И так для того, чтобы добавить библиотеку, нам нужно будет установить пакет NLog.Web.AspNetCore — он обеспечивает легкую интеграцию и конфигурирование логгера в Web API приложении.

builder.Logging.ClearProviders();
builder.Logging.SetMinimumLevel(Microsoft.Extensions.Logging.LogLevel.Debug);
builder.Host.UseNLog();

Теперь добавим в корень проекта файл конфигурации логгера nlog.config, именно по этому стандартному пути конфиг и будет найден при вызовеUseNLog().

<?xml version="1.0" encoding="utf-8"?>

<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

    <!-- куда писать -->
    <targets>
        <target xsi:type="Console" name="ConsoleTarget">
            <!-- Важно добавить includeEventProperties="true".
              Так в логи попадут все дополнительные параметры, что мы передадим.
              Больше инфы тут: https://github.com/NLog/NLog/wiki/JsonLayout
             -->
            <layout xsi:type="JsonLayout" includeEventProperties="true" includeScopeProperties="true">
                <attribute name="time" layout="${longdate}" />
                <!-- Эти два поля нужны, чтобы cloud logging подхватил наши
                структурированные логи -->
                <attribute name="level" layout="${level:upperCase=true}" />
                <attribute name="message" layout="${message}" />
                <!-- Если хотите, чтобы в логи попадали стектрейсы. -->
                <attribute name='exception' layout='${exception}' />
            </layout>
        </target>
    </targets>

    <!-- правила сопоставления логгера и таргета -->
    <rules>
        <!--Output hosting lifetime messages to console target for faster startup detection -->
        <logger name="Microsoft.Hosting.Lifetime" minlevel="Info" writeTo="ConsoleTarget" final="true" />

        <!--Skip non-critical Microsoft logs and so log only own logs (BlackHole) -->
        <logger name="Microsoft.*" maxlevel="Info" final="true" />
        <logger name="System.Net.Http.*" maxlevel="Info" final="true" />

        <logger name="*" minlevel="Trace" writeTo="ConsoleTarget" />
    </rules>
</nlog>

Теперь о том как получить логгер. Есть два пути:

Logger log = LogManager.GetCurrentClassLogger();

Использовать NLog напрямую. Плюсы этого решения:

• Наилучшая производительность
• Больше опций для взаимодействия с API логгера, например Logger.WithProperty(..)
• Работает со всеми платформами
• Не требует Dependency Injection

Второй вариант — Microsoft.Extensions.Logging

ILogger<Т> logger

• Решение полностью интегрировано с ASP.NET Core, то есть логи которые пишутся фреймворком тоже будут обработаны и/или отфильтрованы NLog.
• Не придется писать абстракции связанные с логированием
• Отлично работает с .NET Core Dependency injection
• Можно загрузить конфигурацию NLog из appsettings.json вместо XML файла NLog.config

Использование

using (_logger.BeginScope("{reminder}", reminder))
{
    if (value % 10 == reminder)
    {
        throw new Exception("Random exception");
    }

    _logger.LogInformation("valid {value}", value);
}

Хоть строка message в логе и выглядит как шаблон для подстановки значений, при логировании интерполяция строк не будет производиться. На самом деле значения из фигурных скобок будут использованы как ключи для аргументов переданных после message при записи в объект структурированного лога.

{
  "message": "valid value"
  "value": 3666638874307776000,
  "reminder": 7
}

Как видно выше мы можем задавать именованные области через _logger.BeginScope, рамках которых определять дополнительные параметры для записей лога.

Репозиторий с примером. https://github.com/nikolaymatrosov/yc-sls-container-csharp

В прошлом Serverless Full Text Search я рассмотрел JavaScript библиотеку для in-memory полнотекстового поиска Lyra. Почему я выбрал именно ее? Во-первых, именно на доклад про неё я наткнулся на YouTube. Во-вторых, мне понравилась её универсальность и возможность притащить её в браузер.

Но при этом я могу выделить несколько минусов:

1. In-memory. И хотя именно это и дает ей портабельность и скорость, но загрузку индекса в память на холодном старте уходит значительное время (~5сек) и с этим ничего не сделать.
2. К тому же индекс в памяти занимает значительное место, то есть нам придется выделять функции больше памяти, а значит и платить за эти ресурсы.
3. На текущий момент поддерживаются индексы только по строковым полям, другие типы, например, по числовым, по датам или GeoSpatial индексы не поддержаны.
4. Нет фасетного поиска. Что это такое? Это когда при поиске найденные документы классифицируются по заданным свойствам — фасетам. Эта информация возвращается вместе результатами поиска и у вас есть возможность на фронте отрисовать дополнительные фильтры, чтобы пользователь мог легко уточнить свой запрос. (UPD 2023–01–27: В Lyra добавили фасеты.)

И поискав немного, я нашел новую библиотеку на этот раз на Go.

Bleve

Название не очень благозвучное, но оно происходит от акронима BLEVE — Boiling liquid expanding vapor explosion. Именно поэтому у библиотеки такое лого.

Она поддерживает

• Индексацию любых Go структур, включая JSON;
• Гибкую настройку, при этом имея значения по умолчания, которые позволят вам свести конфигурирование к минимуму;
• Индексы по: Text, Numeric, Datetime, Boolean;
• Разные типы запросов:
  — Термин или фраза с точным или частичным совпадением, Fuzzy-поиск (неточное совпадение по расстоянию Левенштейна);
  — Конъюнкция(«И»), дизъюнкция(«ИЛИ»), Булевы модификаторы (must в поисковом запросе + перед термином, should — уровень по умолчанию и must_not — - перед термином);
  — Term Range, Numeric Range, Date Range;
  — Geo Spatial
• Удобный для людей синтаксис запросов;
• tf-idf скоринг;
• Бустинг (Вы можете повлиять на относительную важность частей запроса, добавив к ним суффикс с помощью оператора ^, за которым следует число.);
• Подсветку найденного в результатах;
• Поддержка агрегации фасетов: по терминам, числовым или временным диапазонам.

Эксперименты

Для того чтобы результаты можно было сравнивать с предыдущей статьёй я буду использовать тот же датасет анекдотов на русском языке на 124к документов.

Построение индекса

Строить индекс можно и программно, но кроме этого bleve предоставляет одноименную консольную утилиту, которая позволит вам работать с индексом.

Установка.

go install github.com/blevesearch/bleve/v2/cmd/bleve@latest

$ bleve --help
Bleve is a command-line tool to interact with a bleve index.

Usage:
  bleve [command]

Available Commands:
  bulk        bulk loads from newline delimited JSON files
  check       checks the contents of the index
  count       counts the number documents in the index
  create      creates a new index
  dictionary  prints the term dictionary for the specified field in the index
  dump        dumps the contents of the index
  fields      lists the fields in this index
  help        Help about any command
  index       adds the files to the index
  mapping     prints the mapping used for this index
  query       queries the index
  registry    registry lists the bleve components compiled into this executable
  scorch      command-line tool to interact with a scorch index

Flags:
  -h, --help   help for bleve

Use "bleve [command] --help" for more information about a command.

Именно при помощи нее я подготовил индекс, загрузив в него документы в формате JSON per line. Но для начала нам нужно будет создать файл с описанием структуры индексируемых документов.

{
  "types": {
    "joke": {
      "fields": [
        {
          "name": "joke",
          "type": "text",
          "analyzer": "ru",
          "store": true,
          "index": true
        }
      ]
    }
  },
  "type_field": "_type",
  "default_type": "film"
}

Далее на основе него создать индекс.

bleve create -m data/mapping.json data/index

Далее индексируем датасет.

bleve bulk data/index data/dataset.jsonl

В директории data/index появится файл с метаданными индекса и директория store со следующим содержимым:

-rw-------  1 nikolay  nikolay    40M Jan  7 21:46 000000000044.zap
-rw-------  1 nikolay  nikolay   9.1M Jan  7 21:46 000000000050.zap
-rw-------  1 nikolay  nikolay   9.1M Jan  7 21:46 000000000059.zap
-rw-------  1 nikolay  nikolay   9.0M Jan  7 21:46 000000000064.zap
-rw-------  1 nikolay  nikolay   8.6M Jan  7 21:46 00000000006e.zap
-rw-------  1 nikolay  nikolay   8.8M Jan  7 21:46 000000000079.zap
-rw-------  1 nikolay  nikolay   9.3M Jan  7 21:46 000000000083.zap
-rw-------  1 nikolay  nikolay   1.2M Jan  7 21:46 000000000084.zap
-rw-------  1 nikolay  nikolay   1.2M Jan  7 21:46 000000000085.zap
-rw-------  1 nikolay  nikolay   1.3M Jan  7 21:46 000000000086.zap
-rw-------  1 nikolay  nikolay   1.2M Jan  7 21:46 000000000087.zap
-rw-------  1 nikolay  nikolay   1.2M Jan  7 21:46 000000000088.zap
-rw-------  1 nikolay  nikolay   1.3M Jan  7 21:46 000000000089.zap
-rw-------  1 nikolay  nikolay   1.3M Jan  7 21:46 00000000008a.zap
-rw-------  1 nikolay  nikolay   1.3M Jan  7 21:46 00000000008b.zap
-rw-------  1 nikolay  nikolay   1.3M Jan  7 21:46 00000000008c.zap
-rw-------  1 nikolay  nikolay   1.3M Jan  7 21:46 00000000008d.zap
-rw-------  1 nikolay  nikolay   1.2M Jan  7 21:46 00000000008f.zap
-rw-------  1 nikolay  nikolay   236K Jan  7 21:46 000000000090.zap
-rw-------  1 nikolay  nikolay    64K Jan  7 21:47 root.bolt

Общий размер файлов 109Mb, что меньше сериализованного в JSON индекса Lyra(130Mb). К сожалению этот индекс гораздо хуже жмется zip’ом — 59Mb против 33. Зато его не нужно будет грузить в память.

Изначально Bleve использовал индекс под названием «upsidedown», который в качестве хранилища использовал Key-Value хранилища BoltDB/RocksDB/LevelDB/Moss. Новый индекс «scorch» работает с диском напрмую. При создании вы можете выбрать тип индекса.

Тесты bleve индекса я проводил на функции со 128Mb, в то время как для Lyra требовалось минимум 1Gb. Вероятно, дело не только в размере памяти, но и в выделяемой доле CPU, которая пропорциональна памяти, потому что при 768Mb запрос к Lyra не укладывался в 15 секунд на «холодном» старте.

То есть bleve версия уже в 8 раз дешевле. Давайте сравним тайминги «холодного» старта.

Что можно заметить? Во-первых, гораздо ниже время холодного старта ~2,5сек против ~7сек. Во-вторых, нет 429 кодов ошибок. Это тоже связано с меньшим временем старта: запросы не успевают переполнить очередь и превысить zone_requests_limit. В остальном значения на 90-персентиле сравнимы, а значит при кванте в 100мс вы будете оплачивать одинаковое время, с упомянутой выше поправкой на размер требуемой памяти.

В итоге экономия в зависимости от количества «холодных» стартов у вас будет от 8 до 23 раз.

Еще мне было интересно посмотреть куда в bleve уходит время.

{
  ...  
  "durations": {
    "checkCache": 372,
    "getObjectInfo": 35617,
    "downloadAndUnzip": 2095123,
    "openIndex": 18213,
    "queryIndex": 2804,
    "closeIndex": 238,
  }
}

Значения в микросекундах (10⁻⁶). Проверка наличия кэша, получение данных про индекс(необходимо знать размер для распаковки zip) скачивание и распаковка, открытие индекса, запрос и закрытие индекса.

Если индекс не закрыть, то на «горячем» старте функция повиснет в ожидании доступа к базе.

Фасеты и язык запросов

Подготовка данных и измерения

Так как на анекдотах строить фасеты не на чем, для этого эксперимента я взял датасет с сайта открытых данных министерства культуры. В нем 97k документов про выданные прокатные удостоверения.

Когда я пробовал построить индекс используя все поля у меня не хватало места в директории /tmp, хотя формально я не превышал указанные в документации 512mb. Но разбираться в чем там проблема мне не очень хотелось, поэтому я выкинул часть полей, получив индекс меньшего размера — 189Mb. Именно для него будут приведены следующие измерения.

Отсюда видно, что 7z дает наилучшее сжатие в этом случае, но если посмотреть на время распаковки, то станет понятно, почему я бы не стал его рекомендовать для использования в serverless варианте.

Как видно из графика 7z в разы медленнее остальных алгоритмов. Замеры времени распаковки проводились локально, в функции со 128Мб памяти время может быть больше.

Победитель тут Tar архив сжатый при помощи Zstd (степень сжатия 11). И если посмотреть на замеры скачивания архивов из S3 в функцию, то можем увидеть, что при потоковой распаковке этот вариант не должен вносить сильных дополнительных расходов.

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

Стоит конечно упомянуть, что время создания .tar.zst архива на порядок больше чем .tar.gz. Но для статических индексов (количество поисков >>> количества обновлений), я считаю, это все равно оптимальный вариант.

Увеличение ресурсов функции (128 → 1024Мб) не дало значительного снижения времени холодного старта. Разница составила не более 10%. Это меньшее влияние, чем выбор оптимального алгоритма сжатия.

Построение фасетов

Для того чтобы запрос вернул фасеты, вам нужно описать их в поисковом запросе.

searchRequest := bleve.NewSearchRequest(query)
 
// для построения фасета по годам мы добаляем числовые дипазоны 
yearFacet := &bleve.FacetRequest{
  Size:  20,
  Field: "crYearOfProduction",
}

for i := 2000; i < 2020; i++ {
  minY := float64(i)
  maxY := float64(i + 1)
  yearFacet.AddNumericRange(strconv.Itoa(i), &minY, &maxY)
}

searchRequest.Facets = bleve.FacetsRequest{
  "year": yearFacet,
// фасет по странам будет содержать не более 5 наиболее популярных вариантов
  "country": &bleve.FacetRequest{
    Size:  5,
    Field: "countryOfProduction",
  },
}

В ответе сервера мы получим следующее.

{  
  ...
  "total_hits": 23,
  "took": 24200091, // 24ms
  "facets": {
    "country": {
      "field": "countryOfProduction",
      "total": 25,
      "missing": 0,
      "other": 3,
      "terms": [
        {
          "term": "россия",
          "count": 11
        },
        {
          "term": "индия",
          "count": 5
        },
        {
          "term": "канада",
          "count": 3
        },
        {
          "term": "великобритания",
          "count": 2
        },
        {
          "term": "австралия",
          "count": 1
        }
      ]
    },
    "year": {
      "field": "crYearOfProduction",
      "total": 23,
      "missing": 0,
      "other": 0,
      "numeric_ranges": [
        {
          "name": "2004",
          "min": 2004,
          "max": 2005,
          "count": 23
        }
      ]
    }
  }
}

Внимательный читатель обратит внимание, что total в фасетах различается. Всего поиск вернул 23 результата, а для стран количество 25. Это потому что у двух документов в этом поле указано 2 страны.

Вообще хотел бы отметить, что хоть документация для этой библиотеки и существует, но вы довольно быстро перейдете к чтению исходных кодов. Если вас это не пугает, то bleve очень мощный и относительно простой инструмент.

Как обычно ссылка не репозиторий с кодом.

Если вы для своего проекта выбрали serverless стек, то наверняка вы заметили, что в Яндекс Облаке для него нет решения обеспечивающего полнотекстовый поиск. Ну, то есть вы конечно можете поднять кластер ElasticSearch. Но при его минимальной стоимости и выделяемых ресурсах это наверняка будет стрельбой из пушки по воробьям.

Но что же делать, если хочется сохранить низкие расходы на инфраструктуру и получить быстрый полнотекстовый поиск?

Построить индекс и работать с ним из функций. Для этого мы возьмем js библиотеку Lyra. Это библиотека in-memory полнотекстового поиска, которая работает как на клиенте, так и на сервере.

Upd: Авторы переименовали библиотеку в Orama

Благодаря использованию оптимизированного префиксного дерева и некоторым хакам Lyra может выполнять поиск по миллионам записей за миллисекунды.

Использование

Для начала вам нужно будет создать индекс. Для этого нужно описать схему документа. Поля, не описанные в схеме, не будут индексироваться, но будут доступны в результатах поиска.

import { create, insert } from '@lyrasearch/lyra'; 

const movieDB = create({
  schema: {
    title: 'string',
    director: 'string',
    plot: 'string',
    year: 'number',
    isFavorite: 'boolean'
  }
});

На текущий момент Lyra версии 0.3 умеет искать только по строковым полям, так что остальные поля описывать в схеме бесполезно. Если верить официальной документции то такая возможность может появиться в будущем.

То есть в описании схемы можно ограничиться только следующим.

import { create, insert } from '@lyrasearch/lyra'; 

const movieDB = create({
  schema: {
    title: 'string',
    director: 'string',
    plot: 'string',
  }
});

Далее вставить в него документы.

const { id: thePrestige } = insert(movieDB, {
  title: 'The prestige',
  director: 'Christopher Nolan',
  plot: 'Two friends and fellow magicians become bitter enemies after a sudden tragedy. As they devote themselves to this rivalry, they make sacrifices that bring them fame but with terrible consequences.',
  year: 2006,
  isFavorite: true
});

const { id: bigFish } = insert(movieDB, {
  title: 'Big Fish',
  director: 'Tim Burton',
  plot: 'Will Bloom returns home to care for his dying father, who had a penchant for telling unbelievable stories. After he passes away, Will tries to find out if his tales were really true.',
  year: 2004,
  isFavorite: true
});

Также есть метод для пакетной вставки документов insertBatch.

Для поиска по подготовленному индексу можно воспользоваться методом search. Подробнее про параметры поиска можно прочитать в документации.

const searchResult = search(movieDB, {
  term: "Harry",
  properties: "*",
});

Эксперимент

Для того чтобы потестировать эту библиотеку я нашел датасет русских анекдотов на 26Мб, 124155 документов. Мне показалось, что это неплохой размер данных для serverless поиска. Если у вас данных больше, то наверняка вам стоит задуматься об использовании нормального инструмента, а не мастерить велосипеды.

Итак, для начала я импортировал датасет в индекс Lyra и посмотрел, сколько он будет занимать в сериализованном виде.

Как видно из графика индекс сериализованный в JSON занимает 130Mb. Lyra предоставляет плагин для сериализации. Кроме json там есть binary(206Mb) и dpack(123Mb) форматы. И вроде dpack чуть меньше, но очевидно, что можно получить результат лучше. Для этого я пожал JSON разными популярными алгоритмами сжатия.

Почему именно они? Потому что они есть в стандартной библиотеке Node.js zlib.

Почему я не стал рассматривать сжатие binary и dpack? Потому что кроме размера получаемого артефакта я также посмотрел на время его десереализации. Данные получены на моем ноутбуке, так что стоит смотреть скорее не на абсолюты, а на относительную разницу.

Как видно большую часть времени занимает именно построение объекта индекса, что даже добавление распаковки из архива не сильно сказывается на общем времени. При этом бинарные форматы проигрывают JSON. Он отлично оптимизирован. Именно поэтому я не стал экспериментировать с дополнительным их сжатием, так как это только увеличило бы их отставание от JSON.

Теперь посмотрим на время сжатия. Эта метрика важна для нас если мы хотим иметь не статический индекс, а обновлять его периодически.

Как видно brotli с минимальной степенью сжатия 0 дает тот же самый размер, что и gzip в режиме приоритета скорости, при этом всё равно выигрывая его в два с половиной раза по скорости. Более высокие степени сжатия хоть и дают меньший размер артефакта сильно проигрывают в скорости. Как вы могли заметить на график не попал brotli11 с максимальной степенью сжатия 11. Это потому что на текущем индексе сжатие занимало 4.5–5 минут, хотя и давало наименьший результат. Этот вариант я могу рекомендовать лишь для статических индексов, где нет необходимости обновления, а значит затрат на их обновление.

Для дальнейших исследований я выберу gzip (как вариант для обновляемых индексов) и brotli11 (вариант для статики), чтобы сравнить, как размер сериализованного индекса скажется на времени холодного старта функции.

Кроме представленных форматов я рассматривал еще и Protobuf. Но к сожалению он не поддерживает вложенные словари, а формат индекса их активно использует. В итоге у меня получилось написать сериализатор, но проигрывал в скорости JSON, требовал дополнительно описывать структуру индекса и в итоге не попал в сравнение.

Функция

Кажется код достаточно понятен. На первом старте индекс будет подгружен из Object Storage и десериализован. Поэтому холодный старт будет, в нашем случае не очень маленького индекса, около 5 секунд.

Подводные камни

Так же я наступил в ошибку: загрузка приводит к ошибке аллокации памяти Reached heap limit Allocation failed — JavaScript heap out of memory. Несмотря на то, что при создании версии ее было выделено достаточно (2Гб), функция падает в районе потребления 256Мб.

<--- Last few GCs --->

[8:0x4cc6180]     3469 ms: Mark-sweep (reduce) 254.6 (256.6) -> 254.3 (256.9) MB, 11.0 / 0.0 ms  (+ 4.0 ms in 228 steps since start of marking, biggest step 2.6 ms, walltime since start of marking 84 ms) (average mu = 0.950, current mu = 0.859) allocation
[8:0x4cc6180]     3486 ms: Mark-sweep (reduce) 255.3 (256.9) -> 255.3 (257.9) MB, 12.3 / 0.0 ms  (average mu = 0.899, current mu = 0.283) allocation failure scavenge might not succeed


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

В принципе, решение этой проблемы довольно легко гуглится: нужно передать node.js флаг --max-old-space-size=2048, где число — количество мегабайт выделяемой памяти. Не самыми очевидными были следующие шаги — как передать его, чтобы он надежно подхватился рантаймом? Скажу честно, их мне подсказали в поддержке:

1. Этот флаг можно передать через переменную окружения NODE_OPTIONS. Но это не решает проблему до конца, так как последняя версия Node-рантайма nodejs16 является предзагружаемой — это значит, что для нее применяются оптимизации, которые позволяют значительно уменьшить время холодного старта. К сожалению, они приводят к тому, что вы можете получить рантайм из пула предсозданных, а значит ключи из NODE_OPTIONS к нему не применятся.
2. Оптимизация холодного старта актуальна в случае обычных функций, у которых время исполнения измеряется десятками миллисекунд. Наша же функция на первом старте в любом случае грузит индекс, так что выигрышем в пары сотен миллисекунд на первом старте мы можем пожертвовать. Они не будут заметны на фоне остального времени старта в 5 секунд. Поэтому мы можем применить второй флаг, отключающий эту оптимизацию: YCF_NO_RUNTIME_POOL=1

Давайте посмотрим на результаты стрельб Танком.

Как видно из результатов, часть рантаймов досталась нам из пула и это привело к 502 ошибкам. Ошибки 429 — это слишком активно отсылаемые Танком запросы в тот момент пока создаются инстансы рантаймов и не было достаточно ресурсов чтобы их обработать.

После отключения рантайм пула картина следующая.

Совсем избавиться от 429 ошибок не получается, зато 502 ошибки ушли.

Теперь если посмотреть на результаты времени поиска в индексе, то типичными значениями будут 30–50мс, а общее время выполнения запроса 250–300мс. На мой взгляд очень неплохо.

Обновление индекса

Перестроение индекса можно организовать в функции вызываемой по cron-триггеру, она будет вычитывать обновления из БД и дописывать их и индекс, а затем заливать его в S3.

В случае же, если вам не нужно обновлять данные, то их можно попробовать положить рядом с кодом функции. Это позволит избавиться от лишних походов в S3, тем самым выиграть еще немного на холодном старте.

Ну и напоследок ссылка на live demo от авторов и репозиторий с кодом примера.

UPD: Если вам, как и мне, казалось, что время «холодного» старта можно улучшить, то про это я расскажу в следующем посте. Правда там будет уже не JavaScript, а Go.

Что такое TF CDK?

Cloud Development Kit позволит вам описывать ресурсы Terraform на привычном вам языке программирования, используя все его нативные конструкции (циклы, условия и т.п.).

Первыми такую концепцию описания ресурсов представили AWS, выпустив в 2018 году первые беты своего CDK.

На самом деле, CDK для Terraform использует концепцию «стека приложения» из библиотеки AWS.

Как же работает TF CDK?

CDK, основываясь на описании инфраструктуры на одном из поддерживаемых языков (Go, TypeScript, Python, Java и C#), синтезирует JSON документ описанного формата, который в свою очередь может быть использован Terraform’ом для развертывания инфраструктуры.

Для того чтобы начать пользоваться CDK, вам нужно установить его при помощи npm.

npm install -g cdktf-cli

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

1. Для самых популярных провайдеров вы можете установить предкомпилированные пакеты.
2. Во всех остальных случаях нужно лишь указать в cdktf.json список используемых провайдеров и выполнить командуcdktf get. Она скачает нужные провайдеры и сгененрирует на их основе все необходимое.

Архитектура CDK приложения

Приложения написанные с использованием CDKTF представляют собой дерево из конструктов, которые в документации AWS определены как «классы, описывающие “часть состояния системы”».

Тремя основными классами для создания приложения с CDKTF являются App, Stackи Resource.

Каждый проект построенный на CDKTF имеет один или насколько инстансов App— это контейнеры для конфигурации инфраструктуры, которую вы создаете и развертываете. App может содержать несколько Stack, которые представляют наборы связанной инфраструктуры. Stack синтезирует отдельную конфигурацию терраформа, аналог рабочей директории.

Стеки позволяют разделить управление состоянием внутри приложения. Например, вы можете захотеть развернуть отдельные ресурсы инфраструктуры для разработки и тестирования. Подробнее в документации.

Resource описывает отдельный объект инфраструктуры, точно так же как и в обычном терраформе.

В чем же здесь удобство?

Во-первых, вы пишете код не на json или hcl, а на вашем любимом языке программирования. У вас есть вся мощь IDE, которые умеют отлично навигироваться по коду и давать подсказки.

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

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

Например, в вашей организации принято использовать бакеты S3 с включенным шифрованием и версионированием. Для того, чтобы сделать это в обычном терраформе вам нужно не забыть определить эти параметры каждый раз, когда вы описываете бакет. Используя CDK вы же можете описать свой ресурс, который будет основан на Bucket, назвать его EncryptedVersionedBucket, описать для него один раз все необходимые параметры, а затем поделиться им с коллегами.

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

TF CDK vs Serverless Framework

Если рассматривать Serverless Framework только как средство декларативного деплоя функций, то тут на мой взгляд CDK удобнее. Вам не нужно забираться как описать что-то в YAML.

Но Serverless имеет неплохой набор плагинов и пусть они не всегда хорошо совместимы друг с другом, ожидают разное формат конфигурационного файла, но они добавляют функциональность, которой вам может не хватать в CDK.

Пример.

Чтобы продемонстрировать TF CDK, я переписал деплой одного из моих старых примеров из поста про serverless snapshot’ы с использованием CDK.

yc-serverless-snapshot/main.ts at b06b3e360f402af71833d54b63ab7f0930f1d36c · nikolaymatrosov/yc-serverless-snapshot

Еще идеи для вдохновения можно поискать тут. Стоит отметить, что примеры отсюда используют AWS CDK, но так как TF CDK перенял от него все основные концепции, их можно переписать и для него.

GitHub - aws-samples/aws-cdk-examples: Example projects using the AWS CDK

Еще один полезный ресурс по этой теме — https://cdk.dev/. Там можно найти ссылки на статьи и примеры с использованием AWS CDK, Terraform CDK и K8s CDK.

Начиная с версии 8.7 (а в jammy стоит 8.9) OpenSSH считает небезопасными ключи ssh-rsa и отключает их по умолчанию.

В протоколе SSH схема подписи ssh-rsa использует SHA-1
алгоритм хэширования в сочетании с алгоритмом открытого ключа RSA. Сейчас можно выполнять атаки с выбранным префиксом против алгоритма SHA-1 менее чем за 50 тысяч долларов США.

Стоит отметить, что деактивация подписей ssh-rsa необязательно
требует прекращения использования ключей RSA. В протоколе SSH ключи могут быть подписаны с использованием нескольких алгоритмов. В частности, ssh-rsaключи могут подписываться с использованием rsa-sha2–256 (RSA/SHA256), rsa-sha2–512(RSA/SHA512) и ssh-rsa (RSA/SHA1). Так вот по умолчанию отключен только последний из них.

Но так как Packer написан на Go, а в Go до сих пор не поддержаны нормально разрешенные алгоритмы подписи RSA ключей, мой выбор пал на формат ключей ssh-ed25519, так как он входит в список рекомендованных OpenSSH альтернатив и поддерживается в Go.

Одна загвоздка. Go умеет создавать такие ключи. Но совершенно не озаботился включить в стандартную библиотеку метод для сериализации ключа в формат, совместимый с OpenSSH.

Отправной точкой для меня стал метод в SDK Packer’а. К сожалению автор честно признается в комментарии к коду, что его ключи при использовании в OpenSSH выдают ошибку:

PairFromED25519 marshalls a valid pair of openssh pem for ED25519 keypairs.
NewPair can handle ed25519 pairs but generates the wrong format apparently:
`Load key "id_ed25519": invalid format` is the error that happens when I try to ssh with such a key.

В этот момент я попытался найти документацию, как же должен выглядеть валидный формат.

RFC 4253, раздел 6.6 описывает формат открытых ключей OpenSSH, и, следуя этому RFC, довольно легко реализовать синтаксический анализатор и декодировать различные биты, составляющие открытый ключ OpenSSH.

Однако, в отличие от открытых ключей OpenSSH, не существует документа RFC, описывающего бинарный формат закрытых ключей, которые генерируются ssh-keygen.

Ответ, как это не удивительно, был найден в репозитории OpenSSH.

1. Overall format

The key consists of a header, a list of public keys, and
an encrypted list of matching private keys.

#define AUTH_MAGIC      "openssh-key-v1"

 byte[] AUTH_MAGIC
 string ciphername
 string kdfname
 string kdfoptions
 uint32 number of keys N
 string publickey1
 string publickey2
 ...
 string publickeyN
 string encrypted, padded list of private keys

Сначала дан общий обзор формата. Далее подробнее разбирается возможные значения для полей.

2. KDF options for kdfname "bcrypt"

The options:

 string salt
 uint32 rounds

are concatenated and represented as a string.

Кстати, кроме значения bcrypt можно также использовать none(об этом говорится в пункте 5). Что мы и будем делать, так как это проще, а у меня нет цели написать сериализатор, который будет поддерживать все возможные кейсы.

Теперь разберемся как должны быть указаны приватные ключи.

3. Unencrypted list of N private keys

The list of privatekey/comment pairs is padded with the
bytes 1, 2, 3, ... until the total length is a multiple
of the cipher block size.

 uint32 checkint
 uint32 checkint
 byte[] privatekey1
 string comment1
 byte[] privatekey2
 string comment2
 ...
 string privatekeyN
 string commentN
 byte 1
 byte 2
 byte 3
 ...
 byte padlen % 255

where each private key is encoded using the same rules as used for
SSH agent.

Before the key is encrypted, a random integer is assigned
to both checkint fields so successful decryption can be
quickly checked by verifying that both checkint fields
hold the same value.

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

Обратите внимание на паддинг. Мы к нему еще вернемся чуть позже.

Далее приведены опции для шифрованных и нешифрованных ключей. И нам интересна именно последняя.

4. Encryption

The KDF is used to derive a key, IV (and other values required by
the cipher) from the passphrase. These values are then used to
encrypt the unencrypted list of private keys.

5. No encryption

For unencrypted keys the cipher "none" and the KDF "none"
are used with empty passphrases. The options if the KDF "none"
are the empty string.

Как видно функция для сериализации ключа в многом повторяет описанный формат, но есть некоторые отличия.

Для того чтобы наглядно убедиться, что результат работы ssh-keygen и go совпадает, я поставил https://github.com/WerWolv/ImHex. (Про который услышал в последнем выпуске Радио-Т)

Отличия состояли в том, что в файл не записывался публичный ключ отдельным полем, как это описано в п.1. А так же не хватало паддинга приватного ключа.

Оставалось только разобраться, какой же паддинг ожидается. В пункте 3 говорится, что нужно добиться кратности размеру блока шифрования. Но так как у нас нет шифрования, то непонятно какой размер ожидается. К счастью в статье такого же исследователя приватных ed25519 ключей, как и я, я нашел подсказку. Допустимые значения шифров и размеры блоков описаны в cipher.c.

И как видно для нашего none размер блока должен быть 8.

С этими исправлениями у мен получилось собрать рабочее решение.

Ну и напоследок интересный факт: номер в названии алгоритма обозначает кривую на которой он основан — Curve25519. А она в свою очередь так названа, потому что является Кривой Монтгомери над простым полем, определяемым простым числом 2²⁵⁵-19.

Upd: pull request с этими изменениями приняли и он попал в релиз SDK 0.3.2.

Итак, у вас есть цель выполнять какую-то задачу внутри serverless контейнера по расписанию. К сожалению, вы не сможете просто взять положить в контейнер ваш код и надеяться что все заработает просто так.

Тут нужно уточнить детали реализации взаимодействия serverless контейнера и cron-триггера, который будет его запускать. Триггер запускает контейнер просто отправляя ему http-запрос в корень (path /) и ожидая в конце выполнения ответа c HTTP кодом200.

Если же вы в контейнере не реализуете HTTP-сервер, то триггер не может узнать о том, корректно ли завершилось выполнение контейнера. Это будет воспринято как ошибка и триггер попробует запустить контейнер снова. В итоге вы получите много запусков вашего кода, которых вы не ожидали, и большой счёт за их выполнение.

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

Сервер на Go

Давайте напишем простой сервер на go, и добавим его в наш контейнер.

При обработке запроса от триггера мы просто запускаем скрипт command.sh в котором можно описать произвольные команды.

Dockerfile

Теперь надо упаковать это все в докер-контейнер.

Здесь мы используем подход многофазного построения контейнера. На первом шаге мы собираем наш сервер. Назовем этот контейнер build.

На втором шаге просто копируем сервер в чистый образ ubuntu:22.04. Туда же вы можете добавить все необходимое для запуска вашей задачи. А сам процесс запуска описать в command.sh.

Таким образом вы сможете легко корректно обрабатывать вызовы триггера и не получать в логах контейнера сообщений типа:

{"errorMessage":"user container finished with error: exit status 1","errorType":"UserCodeError"}

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

Функции в облаке запускаются синхронно и в один момент времени обрабатывают ровно один запрос.

Это значит, что вы можете быть уверены, что все переменные созданные внутри обработчика будут относиться именно к текущему контексту. Т.е. если вы в обработчике идете в базу, чтобы получить текущего пользователя, это будет именно тот пользователь, чей id пришел в запросе.

Однако, экземпляр рантайма может быть переиспользован для обработки разных запросов. То есть, когда закончится обработка первого запроса, в тот же рантайм может быть передан для обработки следующий запрос. Ему могут быть доступны переменные определенные вне функции-обработчика.

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

Теперь подробнее разберем, что значит синхронность запуска функции.

Для этого возьмем простую функцию на Python, которая будет делать только одно: ждать 1 секунду и возвращать ответ Ok.

Теперь, если мы вызовем ее при помощи curl, то через 1 секунду получим ответ Ok.

curl 'https://functions.yandexcloud.net/d4eic18eqks97gmifd3l'

Но, что будет, если мы будем ждать ответа не 1 секунду, 500мс?

curl -m .5 'https://functions.yandexcloud.net/d4eic18eqks97gmifd3l'

В ответ мы увидим вот что:

curl: (28) Operation timed out after 504 milliseconds with 0 bytes received

А в логах функции:

Что же произошло?

Рантайм функций увидел, что клиент разорвал соединение и больше не ждет ответа, значит функция не сможет вернуть результат своего выполнения, вызвавшему её коду, а значит можно больше не тратить деньги клиента Облака (ведь облачные функции тарифицируются именно за время исполнения) и прервать функцию. В логах такое поведение можно найти по коду ответа 499. Этот нестандартный код ответа говорит, что клиент не дождался и отменил запрос.

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

То есть, например, пользователь решил не ждать загрузки витрины. Отлично, можно отменить этот запрос, ведь нам не понадобится его результат для отрисовки страницы в браузере.

Что же это значит для разработчика, который пишет приложение в serverless модели? Нужно постараться не использовать синхронные вызовы одной функции из другой.

Потому что когда наступит таймаут у внешней функции, то и вызванная из неё функция завершится с ошибкой. И тут либо аккуратно следить за настройками функций, поддерживая таймауты у внешних чуть больше, чем у внутренних, либо использовать асинхронные подходы.

К тому же, вызывая одну функцию из другой, вы заплатите вдвойне, т.к. будет работать два экземпляра рантаймов. Так же придется следить за квотами.

В итоге если функции написаны на одном языке программирования, то проще вызвать код вложенной функции нативно: включив его в сборку внешней функции.

Асинхронность в функциях.

Первое, о чем вы могли подумать: «Точно просто вместо обычной функции-обработчика сделаем её асинхронной!»

Но это не поможет. Да обработчик стал асинхронным, теперь мы можем использовать в нём синтаксический сахар async/await, но вызов функции так и останется синхронным. То есть, если вы вызывая функцию по http, не дождетесь окончания ее исполнения, то она точно так же как и в случае с синхронным обработчиком вернёт 499 код ошибки.

Так что же делать, если вы хотите выполнить в облачной функции какую-то длительную работу и не хотите ждать ее завершения, и вас бы устроило, чтобы например результат был записан в базу данных?

Для этого можно использовать очереди сообщений, таким образом развязать постановку задачи и ее выполнение. А заодно и распараллелить выполнение задач.

Как положить сообщение в очередь?

У нас есть как минимум два похода:

1. Мы можем напрямую взаимодействовать с очередью через AWS SDK (т.к. YMQ поддерживает протокол AWS SQS);

2. Воспользоваться интеграцией API Gateway.

После этого нужно будет лишь настроить триггер, который будет обрабатывать сообщения из очереди и готово.

Таким образом, если у вас есть долгая операция и требование от внешней системы быстро отвечать на запросы, вы сможете выполнить оба условия. В первой функции быстро складывать данные в очередь задач и возможно проверять по ключу в базе готова ли задача, а другой отдельной асинхронной функции (кстати, это может быть даже и не функция, а виртуальная машина, в том случае, если вам не хватает ограничений serverless среды и нужны, например большие ресурсы, вычисления на GPU или доступ к сервисам из внутренней VPC) выполнять отложенные задачи.

Ограничения YMQ.

У вас может возникнуть желание применить описанный выше подход и для FIFO-очередей. К сожалению в текущей реализации триггеров вы не сможете создать триггер для FIFO-очереди YMQ. В таком случае у вас есть опции использовать для разбора очереди приложение развернутое на ВМ, в нём вы сможете читать любые YMQ очереди. Или же, если вы хотите оставаться serverless, вы можете использовать Yandex Data Streams.

Это сервис, который реализует API совместимое с AWS Kinesis. Вы точно так же, как и в случае с YMQ, сможете писать в него при помощи либо AWS SDK, либо интеграции с API Gateway. Yandex Data Streams предоставит вам гарантии порядка обработки сообщений записанных в стрим. Вам лишь нужно будет определить ключ, по которому будут шардироваться сообщения и помнить, что порядок гарантируется только в рамках сегмента, который задается ключом.

То есть, если вы хотите гарантировать, что сообщения относящиеся к одному пользователю обрабатывались в порядке записи, то вам стоит включить в ключ шардирования например идентификатор пользователя, чтобы убедиться, что они попадут в один сегмент.