Реляционный сервис Google Cloud SQL на самом деле не что иное, как СУБД MySQL, предоставляемая по схеме Database-as-a-Service. Он дает все типовые облачные преимущества: быстрый старт без накладных ресурсов, автоматическое сопровождение и администрирование, создание копий, установку обновлений СУБД и мониторинг работы через веб-консоль. Особо надо отметить хорошее обеспечение безопасности — вся информация записывается в базы серверов Google в зашифрованном виде, доступ разрешен только с авторизованных IP-адресов и производится через SSL-протокол. Вдобавок можно настраивать внутренние политики безопасности MySQL, а базы физически реплицируются между несколькими ЦОДами. Google Cloud SQL хорошо стыкуется с другими облачными корпоративными сервисами — App Engine, Compute Engine и Cloud Storage, и хотя гибкости конструктора Amazon достичь все же удается не всегда, данный реляционный сервис смотрится весьма зрело.
Создаем сервер БД
Создание РСУБД в облаке Google выполняется из раздела Cloud SQL веб-консоли нажатием кнопки New Instance. В дополнение к названию серверного экземпляра (рис. 1) и региона, где он будет работать (США или Европа), надо выбрать доступный размер ОЗУ (от него напрямую зависит стоимость сервиса) и вариант биллинга (почасовой либо ежемесячный; в последнем случае поле Tier укажет стоимость одних суток работы). Можно также ввести желательный временной промежуток, в рамках которого будет формироваться копия базы (если она большая, система в момент архивирования может подтормаживать), включить поддержку двоичного лога MySQL, выбрать вариант репликации (синхронную — более надежную, но снижающую скорость операций записи, либо менее надежную, но зато более быструю асинхронную). MySQL-серверу можно присвоить IP-адрес, что позволит обращаться к нему из внешних сетей посредством типовых инструментов. Полезна на этапе запуска РСУБД возможность выбора приложений из PaaS-сервиса Google App Engine, которые будут взаимодействовать с данным экземпляром СУБД.
Обслуживаем SQL-сервер
Краткие сведения о СУБД будут показаны в веб-консоли, где выводится имя серверного экземпляра, рабочий статус, технические параметры, доступное дисковое пространство и список приложений, авторизованных для доступа к базе. Тут же можно просмотреть графики нагрузки по объемам эксплуатируемых данных и операций ввода-вывода (рис. 2). Правда, строятся они подчас довольно долго — так, детализация за последний час у меня постоянно зависала.
Вкладка Operations демонстрирует историю выполненных действий, вкладка Access Control предлагает настроить различные политики безопасности (IP-адреса, с которых можно обращаться к серверу; пароль к БД; авторизованные сети и приложения; до десяти SSL-сертификатов). Форма биллинга и иные параметры, задававшиеся в начальном окне, можно изменить и при запущенной СУБД с помощью кнопки Edit. Перезапуск сервера выполняется кнопкой Restart, удаление — кнопкой Delete.
Доступ к облачной СУБД можно предоставить и другим участникам проекта (рис. 3). Они подключаются через раздел Permissions, идентифицируются своим регистрационным аккаунтом в Google либо электронным адресом, а в качестве форм доступа возможны три варианта: полный с добавлением новых пользователей, редактирование (все возможности полного варианта за исключением добавления пользователей) и только просмотр.
Подключаемся к Google Cloud SQL извне
Основное использование облачного SQL-сервера Google организуется из внешних приложений, потому что веб-консоль не предлагает практически никаких возможностей для прямой работы с базой. Скажем, перенос данных как в облако Google Cloud SQL, так и из него поддерживается типовым MySQL-инструментарием — например, утилитой mysqldump или через протоколы MySQL Wire Protocol и JDBC. Для обращения к базе данных извне необходимо присвоить серверу статичный IP-адрес на вкладке Access Control, при этом будет дополнительный запрос по поводу внешней сети (Authorized Network), из которой разрешено обращаться к этому адресу. В простом случае достаточно ввести IP-адрес собственного компьютера. Подключение к экземпляру MySQL будет выполняться типовым пользователем root, который имеет административные привилегии для манипуляций с базой. Этому пользователю в веб-консоли задается пароль — в поле Set Root Password.
С помощью мастера типового клиента MySQL Workbench тестовая база sakila из стандартной поставки MySQL 5.5 (55 тыс. записей) экспортируется в облачную БД Google Cloud SQL около минуты, а полный цикл экспорта с учетом пользовательских манипуляций занимает времени лишь в два раза больше (рис. 4). Из клиента MySQL Workbench в дальнейшем возможна обычная работа с облачной базой (рис. 5).
Выгрузка всей облачной базы кнопкой Export веб-консоли производится в облачное хранилище Google Cloud Storage (надо указать нужное “ведро” и каталог внутри него), куда база помещается в виде обычного двоичного файла (рис. 6). Для данного тестового примера процесс экспорта занял десять секунд.
Возможно и программное управление серверами. Оно реализуется через JDBC, с использованием серверных сценариев Google Apps Script, из приложений, созданных с помощью PaaS-услуги Google App Engine, через библиотеки Python (возможна поддержка Django) и Java SDK, посредством подключаемого модуля Google для Eclipse, из PHP и с помощью оригинального языка Go, созданного в Google.
Сколько стоит Google Cloud SQL
Сервис Google Cloud SQL доступен в двух тарифных планах: пакетном (фактически оплачивается полный месяц бесперебойной работы) и почасовом (плата взимается только за часы реальной эксплуатации). Пакетный микровариант D0 (ОЗУ 125 Мб, диск 500 Мб) будет стоить около 10 долл. в месяц, самый мощный D32 (16 Гб ОЗУ, 10 Гб на диске) — почти 150 долл. Если объем БД превышает минимально доступный, придется доплатить 0,24 долл. в месяц за каждый дополнительно задействованный гигабайт.
В почасовом режиме D0 обойдется в 0,025 долл./ч, D32 — в 3,08 долл./ч. При этом если серверу БД присвоен IP-адрес (например, для доступа к нему из внешних сетей), то со счета будет списываться 0,01 долл. за каждый час простоя сервера (когда к базе нет обращений). Исходящий трафик сервиса обойдется в 0,12 долл. за гигабайт.
Почасовой режим лично у меня вызвал некоторое подозрение (см. рис. 7). Я совершенно точно не работал с базой пять часов — только один раз подключился к ней на два часа без перерыва. И даже с учетом того, что несколько минут случайного разового доступа к БД после многих часов перерыва будут учтены как один час работы и, возможно, процесс автоматической архивации также был засчитан как платное обращение к ней, все равно пять часов смотрятся странно. Поэтому если вы решите использовать почасовой вариант, поэкспериментируйте несколько дней с тестовой базой и оцените количество реально оплачиваемого времени.
Выводы
На первый взгляд по количеству слабостей Google Cloud SQL заметно проигрывает своему прямому конкуренту Amazon RDS. Если SQL-сервис Google — это фактически только MySQL, то Amazon предлагает на выбор еще и Oracle, PostgreSQL и Microsoft SQL Server. Из веб-консоли Google Cloud SQL нельзя посмотреть схему базы или выполнить простые запросы. Программистам доступно расширение для Eclipse, а вот прямая поддержка платформы Windows и Visual Studio в отличие от Amazon отсутствует, и это, конечно, существенный минус. И в ценовом плане Amazon как минимум предлагает более гибкую схему: типовой мощный RDS-сервер стоит 0,64 долл./ч, оптимизированный под обработку данных в ОЗУ — 4,75 долл./ч, а 60 минут работы самого скоростного и надежного варианта Multi-AZ стоит аж 8 долл. Google же предлагает из мощных серверов лишь D32, хотя и не очень дорого — за 3 долл./ч.
Реальный потенциал сервисов Google Cloud SQL и Amazon RDS для крупных проектов подобным поверхностным анализом, конечно, не выявить. Однако не исключено, что Google Cloud SQL в среднем будет работать быстрее, нежели RDS, — как, впрочем, и практически все остальные сервисы Googe. Тестовая лаборатория InfoWorld изучила облачные сервисы Amazon, Google и Microsoft с помощью свободного инструментария DaCapo, анализирующего, сколь быстро будут работать Java-приложения в облаках. В итоге Google победил в тринадцати тестах из четырнадцати, Microsoft — в одном, а Amazon оказался медленнее всех. Разница, впрочем, невысока и составляет 3—5%, и тем не менее эту особенность надо учитывать и в случае масштабного и длительного проекта предварительно поэкспериментировать с обоими сервисами под максимально планируемой нагрузкой.
