Рассмотренные ранее сервисы Amazon (виртуальное хранилище данных S3, виртуальные серверы EC2, средства оптимизации и балансировки нагрузки — см. “Оптимизируем прикладную Amazon-систему”) относятся к базовой облачной модели IaaS (“инфраструктура как сервис”). В её рамках предоставляются низкоуровневые, системные ресурсы (фактически “голая” ОС), и задача пользователя при этом — не только грамотно их настроить, но и самостоятельно установить весь дополнительный системный и прикладной софт. Но когда пользовательская система сложна (например, используются базы данных), процесс развёртывания и конфигурирования комплекса из сотен и тысяч виртуальных серверов займёт непозволительно длительное время.
Более “дружелюбная” модель PaaS (“платформа как сервис”) подразумевает предоставление клиенту уже настроенной системы с профильными прикладными пакетами. Однако пока PaaS востребована в основном программистами, нуждающимися в скоростном развёртывании под очередной проект десятков и сотен рабочих мест с большим количеством долго и сложно настраиваемых сред разработки. На данный момент Amazon не позиционирует свои сервисы как PaaS; тем не менее интерес к ОС с хотя бы минимально сконфигурированным прикладным и системным ПО столь высок, что под широкий спектр типовых задач обработки данных предоставляется несколько сервисных линеек (нечто промежуточное между IaaS и PaaS). Одна из наиболее популярных подобных услуг — Amazon Relational Database Service (RDS). Пользователю напрямую будет доступна реляционная СУБД в облаке (MySQL, PostgreSQL, Oracle или Microsoft SQL Server), при этом обеспечиваются автоматические бэкапы баз данных, репликация БД между экземплярами серверов Amazon, а также мониторинг текущего состояния базы и сбор различных метрик функционирования СУБД.
Запускаем экземпляр RDS
Запуск RDS — это фактически созидание уже знакомого виртуального сервера EC2, на который установлена нужная реляционная СУБД. Собственно, и при создании экземпляра EC2 можно выбрать, например, дистрибутив Windows, включающий SQL Server, однако RDS отличается от такого подхода наличием упомянутой выше специализированной функциональности, ориентированной на сопровождение БД.
Создание экземпляра RDS выполняется из консоли RDS Dashboard с помощью единственной кнопки Launch a DB Instance. Вам будет предложено выбрать подходящую СУБД (рис. 1). Если разворачивается экземпляр, предназначенный для промышленной эксплуатации, то на следующем шаге желательно оставить включёнными онлайновый репликатор на несколько серверов Multi-AZ Deployment и OLTP-оптимизатор Provisioned IOPS Storage, но они будут доступны только в платном режиме. На третьем шаге детализируется выбранная СУБД: определяются лицензия и версия, указывается необходимое дисковое пространство, вводятся идентификаторы и пароли для доступа к СУБД (рис. 2). Далее определяются характеристики самой базы данных: ей даётся пользовательское название и вводятся иные параметры, специфичные для выбранной модели СУБД (рис. 3). Пятый шаг служит для настроек резервного копирования: будет ли этот режим использоваться (включать его желательно всегда), как часто формируется копия БД, и когда надо выполнять действия по обновлению СУБД (рис. 4). Теперь экземпляр RDS-сервера запускается и вскоре становится виден в главном списке консоли (рис. 5).
Специфика сервиса RDS в том, что пользователь даже не знает, под какой ОС выполняется нужная СУБД, и не забоится о её сопровождении — ему предоставляется исключительно прямой интерфейс к СУБД. Кроме того, практически все функции RDS, начиная с создания серверного экземпляра, доступны и через специальный программный интерфейс.
Подключаемся к MySQL в облаке
После того как СУБД в сервисе Amazon будет запущена, к ней можно обращаться типовым образом: в данном случае, например, через стандартный клиент MySQL. Но для этого надо подготовить отдельную политику безопасности, чтобы она разрешала взаимодействие с экземпляром RDS через конкретный порт. Нужная политика создаётся как обычная группа безопасности в консоли виртуальных серверов EC2. Группы безопасности, уже подготовленные для других задач, в данном случае скорее всего не подойдут, потому что дистанционное взаимодействие с СУБД требует подчас весьма экзотических портов, которые далеко не всегда желательно открывать в массовых проектах. Так, в случае с MySQL необходимо создать группу безопасности, в которой достаточно открыть порт 3306 (создать разрешающие правила на входящий и исходящий TCP-трафик для этого порта).
В типовом клиенте MySQL Workbench при создании нового соединения с СУБД указываются (рис. 6): обычный метод соединения TCP/IP; адрес из поля Endpoint консоли RDS (это будет не IP-адрес, который в данном случае будет динамическим и может изменяться при каждой перезагрузке RDS, а DNS-имя, например “pcweekins.cgcaffui998h.us-east-1.rds.amazonaws.com”); порт 3306; имя пользователя БД, заданное на шаге 3 (Master Username); пароль доступа (Master Password). Дальнейшие манипуляции с облачной базой данных выполняются стандартными средствами клиента MySQL. На рис. 7 видно, как в облачной базе pcweekdb ведётся редактирование содержимого таблицы pcweek_readers в реальном времени.
Последняя версия сервиса RDS поддерживает весьма развитый функционал взаимодействия с СУБД даже посредством подобных типовых клиентов — например, появилась прежде недоступная возможность создания хранимых процедур. Кроме того, в случае использования MySQL можно воспользоваться встроенным в эту СУБД режимом внутренней репликации (так называемая read replica) — создание “реплики” осуществляется командой Create Read Replica локального меню консоли RDS.
Повышаем надёжность до максимума
Amazon по умолчанию ежедневно созидает резервные копии пользовательской базы, которые хранятся определённый период времени, но не более 35 суток (то есть автоматически будет создано не больше 35 бэкапов). Состояние RDS-экземпляра в любой момент можно откатить к одной из резервных копий — для этого в консоли RDS для выбранной СУБД надо дать из локального меню команду Restore to Point in Time и указать нужную дату (рис. 8). Amazon предупреждает, что процесс восстановления базы может занять несколько часов, однако длительное время потребуется скорее всего только для объёмных БД.
Ещё одна удобная схема работы с бэкапами — создание слепка (snapshot) текущего состояния базы. Данная операция схожа с предыдущей: также устанавливается периодичность создания слепков, но их в любой момент можно сформировать вручную командой локального меню Take DB Snapshot. Просмотр слепков выполняется из консоли RDS в разделе Snapshots. При этом в зависимости от выбранного фильтра будут показаны либо слепки, сделанные вручную, либо слепки, подготовленные автоматически (рис. 9). К любому слепку можно откатиться, выбрав его в списке и нажав кнопку Restore Snapshot. Полезной возможностью можно считать и создание копий слепков (кнопка Copy Snapshot) — это востребовано, например, для перемещения важных слепков в ЦОД иного географического региона, что повышает общую надёжность хранения.
Командами локального меню параметры RDS-экземпляра легко редактируются, а сам он перезагружается или удаляется, причём вместе со всеми слепками и бэкапами, — впрочем, при удалении на всякий случай будет навязчиво предложено сформировать финальный слепок базы про запас. По нажатии кнопки Show Monitoring доступна весьма подробная статистика мониторинга работы RDS-сервера: нагрузка на процессор, число операций ввода-вывода, свободное дисковое пространство и объём ОЗУ.
Цена реляционного сервиса
Стоимость одного часа эксплуатации RDS-экземпляра зависит от технических параметров виртуального сервера, в котором выполняется выбранная СУБД, примерно как и в случае с сервисом EC2. Так, платить придётся от 0,035 долл./ч за самый слабый до 0,68 долл./ч за самый мощный экземпляр MySQL под сверхбольшие базы данных. СУБД Oracle обойдётся в 0,05—1,32 долл./ч, PostgreSQL в 0,038—0,712 долл./ч, а Microsoft SQL Server в 0,043—1,638 долл./ч. Эти цены выработаны на основании объёмной статистики эксплуатации и наверняка достаточно точно отражают пропорции между потребностями упомянутых СУБД в ресурсах (вычислительная мощность и ОЗУ).
При приобретении RDS-сервера на длительный срок (1—3 года) в рамках услуги Reserved DB предоставляются значительные скидки — цены будут снижены в разы.
