Как эффективно управлять шлюзом API

IAM (управление идентификацией и доступом) сводится к двум основным аспектам:

• аутентификация, или "Кто вы?"
• авторизация, или "Что вам разрешено делать?"

В основе IAM находятся такие сущности, как пользователи, роли и разрешения. Может показаться удивительным, что команда IAM также управляет API-шлюзом. Есть ли в этом смысл?

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

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

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

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

Трафик клиентов продолжал расти. Появились ошибки HTTP 502/503 и высокая задержка ответа API.

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

Для модернизации архитектуры IAM, как планировалось, нужно было глубоко интегрироваться с API-шлюзом. Любые изменения в Kong требовали активной поддержки и одобрения команды владельцев. Запросы, которые отправляли платформенной команде, не обрабатывались из-за приоритетности других задач и ограниченности ресурсов. Пришло время пересмотреть подход.

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

Ситуация в платформенной команде не менялась. Когда старший инженер IAM взял на себя полную ответственность за API-шлюз, это помогло:

• Вернуть контроль для приоритизации операционного совершенства.
• Сократить количество инцидентов с API-шлюзом.
• Уточнить и прояснить долгосрочную стратегию API-шлюза.
• Устранить зависимости и ускорить переосмысление IAM-стека.

Другие инженеры не были в восторге от управления Kong. У них уже был крупный проект по реорганизации IAM. Зачем добавлять больше сложностей? Были обсуждения о фокусировании на основной области. В конце концов, API-шлюз — это инфраструктурный компонент, которым должны управлять платформенные команды, верно?

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

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

Команда IAM собралась вместе и приоритизировала список задач для Kong. Они договорились сосредоточиться на улучшениях с высоким воздействием, которые не займут много времени. Таким образом, смогли заработать доверие как команда и доказать, что способны управлять таким критическим компонентом. В течение первых шести месяцев мы достигли замечательных результатов:

Каждое из этих достижений выделяется само по себе. Однако самым важным стало то, что в команде не было ни одного инцидента с тех пор, как они начали управлять Kong. Страх перед оперативной нагрузкой не оправдался. Вместо этого они уверенно обслуживают сотни миллионов ежемесячных запросов.