Что такое системы API Management

Зачем они нужны и какие функции они выполняют.

Всем привет! Меня зовут Антон, я – инженер команды, отвечающей за развитие централизованных IT-сервисов, которыми пользуются продуктовые команды в X5 Retail Group.

В этой статье я расскажу о системах класса API Management и в частности о APIM Gravitee (https://www.gravitee.io), том, что это за класс систем, как они используются для обеспечения потребностей команд разработки. Статья не погружает в технические аспекты, но может быть полезна архитекторам и менеджерам, которые думают о том, чтобы попробовать использовать данный класс систем, но не знают, подойдут ли они для их задач, а также разработчикам, которые могут открыть для себя новые инструменты для удобной работы с API.

Что такое системы API Management

Определение

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

С другой стороны, API Management — это набор инструментов и сервисов, которые позволяют разработчикам и компаниям создавать, анализировать, применять и масштабировать интерфейсы API в безопасных средах.

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

Зачем еще один огород городить?

Необходимость этого класса систем возникла в связи с увеличением количества сервисов, которые могут предоставлять свое API как конечный продукт для других сервисов. Ничего не напоминает? Правильно — микросервисная архитектура. Для организации это возможность ускорения «цифровизации». Владельцы продукта публикуют API, документацию к ней и прочие документы типа: планов развития, лимиты и т.д. Также всем хочется контролировать качество работы API, а это уже анализ производительности, статистика использования, проведение все возможных маркетинговых исследований и простой мониторинг. Для коллег из информационной безопасности будет интересно осуществлять наблюдение за использованием API в части контроля доступа: авторизация, аутентификация, аудит, проверка по черным/белым спискам IP. Для аналитиков и тестировщиков возможно будет интересна функциональность проверки корректности запросов, проверка корректности JSON или динамическое изменение запросов, для DevOps инженеров возможность установки rate limit, чтобы не было DoS конечного сервиса, настройка кэша и возможность оптимизации сервиса под микросервисную архитектуру: Service Discovery, Load Balancing, Blue/Green или Canary deploy. 

Архитектура сервиса

В архитектуру сервиса API Management обычно входят (см. рис. 1):

1. Management Core: ядро системы, которое отвечает за формирование политик, планов, работу точками входа и выхода, настроек API Gateways и API, настройку CORS, Failover, Healthcheck, формирование запросов на отображение статистики использования API и логов.

2. Web/Development Portal: отвечает за UI, отображение настроек, статистики использования API, healthcheck и логов, а также позволяет общаться разработчикам, администраторам и владельцам API.

3. API Gateways: шлюзы или прокси, они отвечают за обработку запросов от клиентов сервиса согласно установленных настроек и политик, ведение логов запросов и ответов, а также запуск healthcheck по Backend API.

4. Backend API: отвечает за обработку запросов согласно бизнес-логике конечного сервиса.

5. Databases: в части сервиса API Management, хранят данные по настройке API, API Gateways, логи запросов клиентов и ответы backend, healthcheck, данные мониторинга практически всех компонентов API Management.

Плюсы и минусы систем API Management

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

• Абстракция: система упрощает сложность сервисов под ним и предоставляет клиентам единый опыт.

• Аутентификация: система позволяет пройти аутентификацию, в том числе и через сторонние службы, например Keycloak.

• Управление трафиком: система регулирует входящий и исходящий трафик API.

• Мониторинг API: система может помочь в мониторинге запросов/ответов клиента.

• Преобразования: система позволяет преобразовать запросы/ответы API.

К минусам можно отнести:

• Увеличение Latency: шлюзу необходимо время для обработки запросов/ответов согласно настроенным политикам.

• TCO: Совокупная стоимость владения для всей цепочки поставки ценности, естественно будет больше, чем просто установить nginx и выставить его наружу. 

API Gateways

API Gateways работают как единая точка входа в ЦОД (центр обработки данных), группу распределенных служб или сервисов (см. рис. 2). Также API Gateways могут использоваться для связи между двумя продуктами/сервисами, развернутыми в одном ЦОД. API Gateways принимают вызовы от клиентов, обрабатывают их согласно политикам/правилам и направляют их в соответствующие сервисы. Чтобы API Gateways могли максимально быстро обрабатывать запросы от клиентов их делают максимально легковесными, с использованием асинхронных фреймворков. API Gateways, как правило, работают только на седьмом уровне (L7) модели OSI.

Типы API Gateways

С точки зрения расположения есть два места установки API Gateways:

• Local API Gateways работают как шлюз для сервисов внутри организации.

• DMZ API Gateways работают как шлюз для внешних потребителей и клиентов сервисов.

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

Наиболее распространенные системы

Централизованный сервис Gravitee

В X5 Retail Group в свое время выбрали для использования систему APIM Gravitee (https://www.gravitee.io). Основной сценарий использования нашими командами – публикация API в локальной сети и в DMZ.

Немного цифр об этом сервисе на текущий момент:

• 23 продуктивных команд зарегистрировано

• 69 API Gateways для обслуживания запросов

• 400 Гб логов за сутки

• 350 RPS в среднем по больнице за сутки

• 30 000 000+ запросов обрабатывается за сутки

Функциональность

Рассмотрим базовую функциональность, предоставленную системой APIM Gravitee.

1. Identity provider: Аутентификация внешних пользователей можешь осуществляться на основе следующих систем и сервисов:

1. MongoDB (по умолчанию для новых пользователей, которые приглашаются);

2. In-memory (по умолчанию для пользователя admin);

3. LDAP / Active Directory;

4. OpenID Connect IdP (Azure AD, Google);

2. Fetchers: стянуть настройки для новой версии API и документацию можно через:

2. File (Swagger, OpenAPI);

3. HTTP;

4. GIT;

3. Policies: политики предназначены для изменения поведения, обрабатываемых шлюзом запросов и ответов. Каждый запрос и ответ обрабатывается согласно настроенной цепочке политик. Политики можно рассматривать как прокси-контроллер, гарантирующий выполнение данного бизнес-правила во время обработки. Примеры политик:

3. API Key — политика авторизации с использованием API-ключа;

4. Rate-limiting — политика ограничения скорости или квот для предотвращения флудинга backend;

5. Transform Headers/Transform Query Parameters — политика преобразований параметров заголовка или запроса;

6. etc.

Политик обработки запросов в Gravitee Gateway более 30 штук и с каждой версией их число увеличивается. Так же можно сделать свои политики. Но стоит учитывать, что чем больше политик «навешано», тем медленнее будет обрабатываться запрос и тем больше ресурсов будет использовано. 

4. Reporters: сборщики логов используются экземпляром шлюза для сообщения о событиях. Типы сборщиков логов:

4. Reporter file;

5. Elasticsearch;

6. Accesslog;

Типы событий, которые можно собрать:

4. Метрики запроса/ответа — например, время ответа, длина содержимого, api-ключ;

5. Мониторинг метрик — например, процессора, использования кучи, кол-во открытых файлов и т.д.;

6. Показатели проверки работоспособности — например, состояние, код ответа;

5. Repositories: репозиторий — это подключаемый компонент хранилища для настройки API, конфигураций политик, аналитики, аудита и так далее. Можно использовать следующие репозитории:

5. MongoDB (по умолчанию);

6. Redis;

7. Elasticsearch;

8. PostgreSQL (коннектор через JDBC и надо использовать другой дистрибутив);

6. Resources: ресурсы, которые можно использовать при работе:

6. OAuth2 (подключение к OAuth2 как источнику данных для аутентификации);

7. Cache (создание локального кэша на шлюзе);

8. LDAP (подключение к LDAP как источнику данных для аутентификации);

7. Services: сервисы, которые может предоставлять сам шлюз:

7. Sync (Синхронизация состояния шлюза с конфигурацией из репозитория управления);

8. local-registry (Локальный реестр используется для загрузки API в формате json из файловой системы. Таким образом, вам не нужно настраивать свой API с помощью веб-консоли или rest API (но вам нужно знать и понимать формат json API, чтобы он работал.));

9. health-check (Сервис для проверки состояния других сервисов);

10. monitor (Сервис извлекает метрики, такие как метрики os / process / jvm, и отправляет их в базовую службу отчетов);

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

8. Email;

9. Alerts: оповещение используется для отправки триггеров или событий в механизм оповещений, которые могут быть обработаны для отправки уведомления с помощью настроенного плагина Notifier.

9. Vertx;

А так как система с открытыми исходниками: https://github.com/gravitee-io, то при знании Java, можно написать свои собственные плагины и использовать как вздумается.

Настройки API

Настройка нового API проходит несколько этапов:

1. Создание API

2. Настройка планов

3. Привязываем API к шлюзам

Создание API

На странице создания API можно выбрать, как и из чего создать скелет нового API

Вариантов немного, но выбор есть:

1. Вручную накликал и можно работать!

2. Импортировать из swagger файла.

3. Импортировать из Gitа/URLа.

Рассмотрим ручной вариант настройки, выбираем «->»

Ручное создание API проходит 5 шагов

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

Второй шаг может быть в двух модификациях:

В Simple mode указываем только адрес нашего backend api, например: https://msk-dpro-sre000.x5.ru:8443/testbackend/ 

В Advanced mode необходимо указать адрес нашего backend api, используемые tenant и sharding tags.

tenant — область выделенная в Elasticsearch для логов запросов и событий.

sharding tags — теги, согласно которым связываются API и Gateways

На третьем шаге можно указать Plan

Plan — это указание ограничений, которые будут влиять на обработку запросов, проходящих через данный Gateway.

Name — имя плана

Security type — тип плана: Keyless(public), API Key, JWT, OAuth2

Description — просто описание плана и его особенностей

Rate limit — ограничение кол-ва запросов в секунду/минуту

Quota — ограничение кол-ва запросов в час/день/неделя/месяц

Path authorization — черный и белый список путей и методов к ним

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

На четвертом шаге можно загрузить файл документации по API

Поддерживается формат swagger.json

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

На пятом шаге мы проверяем все что заполнили

И выбираем либо «Создать API без установки на шлюз», либо «Создать и запустить API»

Нажимаем CREATE и получаем частично настроенный API для работы.

Настройки планов 

План предоставляет собой уровень обслуживания и доступа между API и приложениями. У одного API может быть несколько планов, но только один без ключевой — «keyless». План определяет ограничения доступа, режимы проверки подписи и другие настройки для адаптации к конкретному приложению.

Основные настройки:

1. Планы привязываются к конкретному шлюзу или группе шлюзов через Tags (см. рис. 3)

2. В плане указывается какой тип Аутентификации будет использован (см. рис. 4)

3. Можно сразу указать Rate и Quota лимиты и определить список разрешенных путей для запроса (см. рис. 5)

4. В последней вкладке можно указать политики, которые будут отрабатывать на начальном этапе обработки запросов (см. рис. 6)

Заключение

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