Одним з найбільш використовуваних сервісів у AWS є база даних під назвою RDS, що розшифровується як Relational Database Service. RDS підтримує кілька різних реляційних баз даних, і зазвичай я помічав, що додатки, розгорнуті в AWS, підключаються до цього сервісу безпосередньо через endpoints, які RDS надає для інстанцій для запису та для інстанцій для читання. Це саме по собі не є поганим, але багато команд розробників не знають про існування RDS Proxy та переваги, які він нам дає.
Метою цієї статті є розглянути ці переваги через серію синтетичних тестів, що порівнюють безпосередній доступ до бази даних і використання Proxy-сервісу як проміжного елемента. Перед тим як приступити до результатів цих тестів, давайте розглянемо, що таке RDS Proxy.
У сучасному світі попит на додатки та сервіси в хмарі зростає експоненційно. Як результат, необхідно мати високодоступні та масштабовані бази даних, щоб забезпечити оптимальну продуктивність та безперервний досвід для користувачів. AWS пропонує ефективне рішення для цієї проблеми: AWS RDS Proxy.
Що таке AWS RDS Proxy?
AWS RDS Proxy — це повністю керований проксі-сервіс, розроблений для покращення масштабованості, доступності та продуктивності керованих баз даних Amazon RDS. Цей сервіс виступає як посередник між додатками та базами даних, покращуючи здатність до обробки підключень та оптимізуючи використання ресурсів, особливо в додатках з численними одночасними підключеннями.
Переваги AWS RDS Proxy
- Покращена продуктивність: Проксі-сервіс автоматично керує та мультиплексує підключення додатка до бази даних, знижуючи навантаження на інстанції бази даних і покращуючи масштабованість. Він надає нам пул підключень до бази даних, зменшуючи обчислювальне навантаження на базу даних, оскільки відкриття підключення вимагає ресурсів CPU та пам'яті. RDS Proxy підтримує постійне підключення до бази даних, що дозволяє ефективно повторно використовувати підключення та знижувати латентність порівняно з традиційним підходом відкриття та закриття підключень з кожним запитом.
- Резильєнтність та висока доступність: RDS Proxy спрощує процес failover у випадку помилок, дозволяючи додатку швидко відновлюватися і мінімізуючи час простою. Згідно з документацією RDS Proxy, час відновлення скорочується до 66%.
- Спрощена аутентифікація: RDS Proxy підтримує аутентифікацію через IAM, що дозволяє легше та безпечніше керувати обліковими даними доступу.
- Повністю керований сервіс: Це повністю керований сервіс без сервера (serverless), тому не потрібно турбуватися про оновлення, патчі та інші завдання, які зазвичай потрібно було б виконувати при розгортанні рішень типу проксі. Крім того, він сумісний з протоколами, що підтримуються базами даних, що означає, що нам не потрібно змінювати код для підключення до цього сервісу; просто вказуємо відповідний endpoint.
Як активувати RDS Proxy?
Давайте використаємо консоль AWS. У лівому меню консолі RDS вибираємо «Proxies» і натискаємо кнопку «Create Proxy».
На наступному екрані вибираємо тип реляційного мотора (у нашому випадку PostgreSQL), ім’я для проксі та час очікування для неактивного підключення (тобто час, який має пройти перед тим, як закрити неактивне підключення).
За замовчуванням це 30 хвилин, але ми можемо налаштувати цей параметр під наші потреби.
Наступним кроком є вибір бази даних або кластера, з яким ми будемо асоціювати проксі. Зверніть увагу, що ми можемо визначити, який відсоток підключень до нашого проксі буде використовувати максимально можливу кількість підключень до кластера. Зазвичай я використовую 100%, але можуть бути випадки, коли деякі процеси або програми підключаються безпосередньо до RDS, і ми не хочемо, щоб вони потенційно не мали доступних підключень. Також ми можемо визначити максимальний час очікування для отримання підключення та SQL для перевірки з’єднання.
Далі вводимо дані для аутентифікації. Зверніть увагу, що можна налаштувати лише IAM аутентифікацію.
Останнім етапом є введення даних для налаштування з’єднання.
Тепер наш RDS Proxy розгорнуто. Залишилося лише записати ‘endpoints’ для запису та читання. Їх можна побачити у деталях проксі, як показано на наступному зображенні. І не хвилюйтеся, до того часу, коли я опублікую цю статтю, як проксі, так і RDS, та VPC будуть знищені.
Пам’ятайте, що якщо ваш додаток налаштований для розділення транзакційного та читального трафіку, вам слід використовувати обидва ‘endpoints’.
Раніше один розробник запитав мене, чи можна всі запити надсилати на endpoint для запису/читання, і чи буде Proxy самостійно маршрутизувати ‘SELECT’ запити до реплік для читання. І це не так. Всі запити будуть відправлені на інстанцію для запису/читання, тому важливо, щоб наші додатки розділяли такі запити і тим самим максимізували використання інфраструктури, яку ми маємо.
Як розраховується вартість RDS Proxy?
Цей сервіс оплачується за кількість vCPU, що асоційовані з нашою базою даних, мінімум 2 vCPU. Якщо ми використовуємо Aurora Serverless v2, вартість розраховується за ACU на годину. Станом на сьогодні, вартість за vCPU складає $0.015 за годину. У нашому випадку ми використовуємо кластер з інстанціями типу db.r6g.large, де кожна інстанція має 2 vCPU, і ми розгортаємо їх у двох зонах. Отже, наша вартість виглядатиме так:
Max (2 vCPUs, 2 ) = 2 vCPUs
2 інстанції x 2 vCPU x 730 годин на місяць x 0.015 USD = 43.80 USD
Місячна вартість RDS Proxy: 43.80 USD
Порівняльні тести з AWS RDS Proxy
Тепер, після цієї вступної частини, я поясню серію порівняльних тестів, які я проводив, використовуючи просту програму, що виконує класичні операції INSERT і SELECT. Метою є оцінити переваги використання AWS RDS Proxy в термінах часу підключення до бази даних і того, як швидко наша програма відновлюється в разі, якщо інстанція запису, яку ми використовуємо, зазнає збою, і RDS має виконати failover на одну з інстанцій для читання.
Перед тим, як розглянути результати, я використовував наступні передумови:
- Ми розгорнули базу даних RDS Aurora PostgreSQL версії 15.4 з шаблоном для продакшн, стандартне зберігання Aurora, інстанції типу db.r6g.large, Multi-AZ, з активованим «Performance Insights».
- Додаток написано на Java 17, без використання JPA або іншого «фреймворку» для управління сутностями та пулом підключень.
- Додаток виконується через командний рядок з інстанції EC2 на операційній системі Amazon Linux 2023.
- Я не застосовував жодних технік оптимізації, які зазвичай використовуються в продакшн навантаженнях. Наприклад, у нас немає шарів кешування.
- Метою не є аналіз поведінки програми чи бази даних під навантаженням.
- Кожен тест був виконаний 10 разів.
Додаток використовує 6 потоків, кожен з яких виконує 10 000 операцій SQL. Результати відповідають середньому значенню цих виконань.
Тест на продуктивність підключень
Для цього випадку ми виконали програму за тими ж умовами, що описані раніше, і перед початком кожного набору тестів я перезавантажив інстанцію запису RDS.
Як ми бачимо з наступної таблиці, отримання підключення через RDS Proxy майже не відрізняється від прямого підключення до RDS. Середнє значення було 39 мс для RDS Proxy та 32 мс для RDS.
Мене здивувала така мала різниця, зважаючи на те, що RDS Proxy додає додатковий шар між нашою системою та базою даних, тому я очікував більшу затримку; різниця виявилася помітно низькою — лише 7 мс додатково.
RDSRDS ProxyСередній час підключення32 мс39 мсСередній час відповіді34 мс41 мс
Переглянувши метрики через Performance Insights, ми побачили, що додаток мав пік з 11 підключень і близько 176 запитів на секунду.
На відміну від цього, при підключенні через RDS Proxy ми одразу помітили, що кількість підключень зросла до 24, і цікаво, що ми досягли 308 запитів на секунду. Тут ми почали помічати, як Proxy підтримує відкритими певну кількість підключень до бази даних і керує цим пулом за нас.
Якщо подивитися на метрики проксі, видно, що є 6 клієнтських підключень (не забувайте, що наша програма використовує 6 потоків) і як ці підключення відповідають від 15 до 17 підключень до бази даних.
Зверніть увагу, що по завершенню тесту кількість клієнтських підключень падає до нуля, але підключення до бази даних залишаються відкритими. Це відбувається через те, що ми налаштували тайм-аут бездіяльності на 30 хвилин для RDS Proxy.
Результат
З RDS Proxy ми спостерігали, що час підключення злегка збільшився порівняно з прямим підключенням до RDS. Однак під час тесту було помітно збільшення кількості запитів на секунду, які вдалося обробити.
Загалом, цей тест не виявив істотних переваг, якщо порівнювати це з ціною, яку потрібно заплатити.
Тест на failover
Для імітації збою ми виконали ‘failover’ через консоль RDS, одночасно запускаючи ту ж саму програму, та виміряли кількість помилок у додатку та середній час підключення та відповіді.
RDSRDS ProxyСередній час підключення39 мс38 мсСередній час відповіді41 мс41 мсКількість збоїв6,116/10,0001/10,000
Результат
Результати наочні: з RDS Proxy ми не тільки зберегли чудовий час для отримання підключення і відповіді, а й фактично не помітили збою бази даних — лише один збій на 10 000 запитів.
Натомість при прямому підключенні до RDS ми отримали 61% помилок. І це має сенс, адже потрібно було дочекатися, поки оновиться внутрішній запис DNS, щоб вказувати на інстанцію репліки, яка була просунута до ролі інстанції запису.
У той час як RDS Proxy зміг ефективно керувати збоями, забезпечуючи нашу програму без необхідності писати складний код для обробки таких сценаріїв.
Очевидно, що в цьому розділі RDS Proxy значно виділяється.
Тест на погану практику програмування
У цьому тесті я перевіряю RDS Proxy для випадків, коли в програмі є помилка в логіці і вона не звільняє підключення до бази даних.
Хоча це не є типовим випадком використання, раніше мені вже доводилось стикатися з такими ситуаціями, коли клієнт стикався з подібними проблемами, і йому було потрібно час, щоб виправити помилки.
Давайте подивимось, як кількість відкритих підключень зросла до 248, нагадаю, що з коректно написаним кодом ми досягали 11 підключень.
Коли додаток підключається до RDS Proxy, ми спостерігаємо постійний пік у 334 підключеннях і, як і раніше, вищу кількість запитів на секунду.
Якщо подивитися на метрики проксі, можна побачити цей пік до 100 клієнтських підключень, хоча раніше їх було лише 6 з коректно написаним додатком.
Висновок
AWS RDS Proxy є надзвичайно корисним інструментом для оптимізації продуктивності та доступності баз даних у хмарних середовищах. Спрощуючи керування підключеннями та удосконалюючи процес failover, це рішення дозволяє програмам підтримувати свою стійкість навіть у складних умовах.
Впровадження RDS Proxy гарантує організаціям можливість ефективно масштабувати свої програми, задовольняючи зростаючі вимоги користувачів та забезпечуючи оптимальний безперервний досвід.
У проведених тестах було відзначено значну схожість у часах підключення між RDS та Proxy. Однак, безсумнівно, перевага RDS Proxy була очевидною в ситуаціях збоїв бази даних. Така ж перевага проявляється при роботі з програмами з "витоками підключень" (connection leaks), де тимчасове рішення стає необхідним, поки не буде знайдено постійне виправлення.
Хоча впровадження цього сервісу пов'язане з додатковими витратами, я вважаю, що для багатьох робочих навантажень ці витрати майже непомітні, якщо порівнювати їх з численними перевагами, які він надає.
Сподіваюся, що ця стаття була корисною для вас.
Перекладено з: AWS RDS Proxy: una comparativa