Прекращение поддержки PostgreSQL 13 в AWS RDS выявило пятилетнюю несовместимость с AWS Glue из-за новой схемы аутентификации. "Никогда не приписывайте злому умыслу то, что можно адекватно объяснить одной очень большой оргструктурой". — theregister.com
Ранее в этом месяце AWS прекратила стандартную поддержку PostgreSQL 13 в RDS. Клиентам, желающим оставаться на поддерживаемой базе данных — а AWS активно призывает их к этому — необходимо обновиться до PostgreSQL 14 или более поздней версии.
Это имеет смысл, поскольку PostgreSQL (произносится ПОСТ-гру-СКЬЮЛ, если вы, как и я, хотите довести до белого каления всех в пределах слышимости) 13 достиг конца жизненного цикла сообщества в конце прошлого года.
PostgreSQL 14, выпущенный в 2021 году, по умолчанию использует более безопасную схему аутентификации паролей (SCRAM-SHA-256, для тех гиков, которые дочитали до этого места, не схватившись за клавиатуру, чтобы исправить мое предыдущее замечание в скобках). Случается также, что это ломает AWS Glue, их управляемый сервис ETL (извлечение-преобразование-загрузка), который не может работать с этой схемой аутентификации. Если вы обновляете свою базу данных RDS, следуя собственным рекомендациям AWS по безопасности, собственный инструмент AWS для конвейеров данных отвечает сообщением “Authentication type 10 is not supported” и перестает работать.
Учитывая, что оба этих сервиса обычно используются в среде, которую большинство компаний называют “production”, это не очень хорошо!
Вывод из эксплуатации не создал этой проблемы. Он лишь устранил возможность избежать проблемы, которая существует уже пять лет, если только вы не возьмете на себя дополнительное бремя обслуживания или не заплатите налог за Расширенную поддержку.
Вот техническая суть этой дилеммы, сведенная к сути: когда вы переходите на более новую версию PostgreSQL в RDS, инфраструктура тестирования соединений Glue использует внутренний драйвер, который предшествует поддержке новой аутентификации. Кнопка “Test Connection” — та, которую вы нажимаете, чтобы убедиться, что ваша настройка работает, прежде чем доверять ей производственные данные, — просто не работает. Эксперт сообщества на форуме поддержки AWS три года назад признал, что “тестеру требуется обновление драйвера”, и заверил пользователей, что краулеры используют свои собственные драйверы и должны работать нормально. Пользователи в той же ветке сообщили, что краулеры также выходят из строя. Использование Glue с RDS PostgreSQL — это стандартная модель инженерии данных, а не крайний случай — это хорошо проторенная дорога, которую AWS позволила прийти в упадок.
Несовместимость известна с момента выпуска PostgreSQL 14 в 2021 году. Сроки вывода PG13 из эксплуатации были объявлены заранее. Обе команды — RDS и Glue — предположительно следят за отраслевыми разработками. Ни одна из них, по-видимому, не озаботилась отслеживанием друг друга.
Самое благожелательное объяснение того, как это происходит, является и правильным: в AWS работают десятки тысяч инженеров, организованных в сотни полуавтономных сервисных команд. Команда RDS выпускает уведомления о прекращении поддержки в соответствии с жизненным циклом RDS, команда Glue поддерживает зависимости драйверов в дорожной карте Glue, и никто явно не несет ответственности за пробел между ними. Клиент обнаруживает несовместимость в продакшене, как правило, в неудобное время.
Это не заговор, поскольку AWS не обладает достаточной внутренней сплоченностью, чтобы его осуществить. Это также не тщательно продуманный механизм увеличения дохода, поскольку доходы от Расширенной поддержки, скорее всего, являются погрешностью в балансе AWS по сравнению с вызванным этим недовольством клиентов. Вместо этого это просто организационная сложность делает то, что она умеет. Это та же причина, по которой внутренние инструменты вашей компании не взаимодействуют друг с другом; AWS просто делает это в таком масштабе, что радиус поражения приходится на производственную базу данных кого-то другого. Интеграционное тестирование через границы сервисов действительно сложно, когда эти границы охватывают несколько многомиллиардных предприятий, которые случайно имеют общую материнскую компанию. Никто не просыпался с намерением сломать Glue. Он таким вышел с завода.
Я хочу быть ясным, что я искренне в это верю, потому что альтернатива, которую я собираюсь описать, не связана с намерениями.
Проблема с благожелательным прочтением в том, что это не имеет значения
Если вы смотрите на сломанный конвейер в вашей среде в 2 часа ночи, причина академическая. Вам нужно исправление. AWS предоставила три варианта, и все они ужасны. Вы можете понизить уровень шифрования паролей на вашей базе данных до старого, менее безопасного стандарта: того, от которого вы только что отказались, согласно собственным рекомендациям AWS. Вы можете использовать собственный драйвер JDBC, что отключает тестирование соединений и может не поддерживать все нужные вам функции. Или вы можете переписать свои рабочие процессы ETL в виде заданий оболочки Python.
Каждый выход означает отказ от всего ценностного предложения управляемого сервиса — предположительно, по какой причине вы вообще попали в эту передрягу, — или отказ от улучшения безопасности, которое вам только что посоветовали сделать.
Для клиентов, которые остались на PG13, чтобы избежать этой конкретной проблемы, Расширенная поддержка теперь включается автоматически, если вы не отказались от нее при создании кластера — деталь, которую легко упустить из виду. Это $0,10 за vCPU-час в течение первых двух лет, с удвоением на третий год. Инстанс Multi-AZ с 16 vCPU обходится почти в $30 000 в год только за сборы за Расширенную поддержку. Это не вымогательство. Но это сумма, которая появляется в счете от компании, которая также контролирует сроки устранения проблемы, а все варианты реагирования клиента плохи.
AWS не нужно устраивать вымогательство. Им просто нужно быть достаточно большими, чтобы результат был неотличим от него.
Эта модель не уникальна для AWS, и она никуда не денется. Каждый крупный облачный провайдер — и, по сути, каждый крупный технологический провайдер — представляет собой портфель полуавтономных команд, дорожные карты которых иногда сталкиваются в средах их клиентов. Это повторится снова, с другими сервисами, другими протоколами аутентификации и другими строками в счетах. Вопрос не в том, породит ли оргструктура еще один подобный пробел. Породит. Вопрос в том, что произойдет после появления этого пробела: будет ли реакция выглядеть как подотчетность — признание несовместимости до крайнего срока вывода из эксплуатации, а не после — или как пожимание плечами и три платных альтернативы?
Никогда не приписывайте злому умыслу то, что можно адекватно объяснить одной очень большой оргструктурой. Просто не забывайте проверять счет. ®
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Corey Quinn