Рейтинг
0.00

G-Core Labs Хостинг

1 читатель, 6 топиков

Приглашаем на бесплатный вебинар «Выбор CDN в 2021 году»

Вебинар будет полезен
  • разработчикам игр и SaaS‑приложений
  • техническим директорам и специалистам E‑commerce
  • финтеха
  • ритейла
  • онлайн-медиа
  • индустрии развлечений и других сфер




www.webinar.gcorelabs.com/#registration

Доктор в облаке: как мы создали сервис телемедицины для борьбы с коронавирусом в Люксембурге



Разработкой платформы мы занялись… случайно. Всё началось с пандемии, из-за которой правительство Люксембурга и распорядилось создать сервис онлайн-консультаций с врачами. Чтобы выжать из платформы максимум пользы, в неё решили добавить всё, что только нужно для полноценной работы врачей с пациентами. Обмен всевозможными медицинскими документами и даже выдача рецептов на лекарства исключениями не стали — старый вендор всё и сразу заложил в сервис. А затем, чтобы всё добро было в сохранности, к нам и обратились с уже готовым продуктом — нам всего-то и требовалось, что развернуть платформу в защищённой точке присутствия облака.

Через полтора месяца сервис успешно работал в люксембургском дата-центре EDH Tier IV, но ещё при первом знакомстве мы признали в нём слабое звено всего проекта: в отличие от точки присутствия, платформа защищённостью похвастаться не могла и обладала десятком других недостатков. Решение было очевидным — сервис нужно было делать с нуля. Оставалась убедить в этом правительство Люксембурга.



Этот доктор сломался, несите нового: почему мы решили делать новую платформу
Чтобы предложить поставить на старой платформе жирную точку, нам достаточно было бегло осмотреть её. Вместо исправления всех возможных проблем безопасности и обновления дизайна сервис было проще сделать с нуля, и на то у нас были три веских довода.

1. Систему разрабатывали без фреймворка
Из-за этого проблем в платформе было немыслимое количество. Если бы для создания сервиса использовался какой-нибудь популярный фреймворк — Symfony, Laravel, Yii или что-то ещё, — то даже посредственные разработчики избежали бы большинства проблем безопасности, ведь ORM умеют подготавливать запросы к базе, шаблонизаторы — эндкодить полученный от пользователя контент, а формы по умолчанию защищены CSRF-токенами, да и авторизация и аутентификация, как правило, доступны практически из коробки. В этом же случае платформа заставила нашего разработчика ностальгировать по студенческим временам — код выглядел почти так же, как его первая лабораторная работа в университете.

Вот, например, как было реализовано подключение к базе данных. Учётные данные для подключения были захардкожены выше в том же файле.
if (!isset($db)) {
	$db = new mysqli($db_info['host'], $db_info['user'], $db_info['pass'], $db_info['db']);
	if ($db->connect_errno) {
		die("Failed to connect to MySQL: " . $db->connect_errno);
	}
	if (!$db->set_charset("utf8")) {
		die("Error loading character set utf8 for MySQL: " . $db->connect_errno);
	}
	$db->autocommit(false);
}


2. В платформе было множество проблем безопасности
После аудита мы поняли, что с такими недоработками выходить в production нельзя даже с простым блогом, не то что с платформой с конфиденциальными данными. Приведём некоторые из них.

SQL-инъекции. В 90% запросов попадали введенные пользователями данные без их предварительной подготовки.
$sql = "
	UPDATE user
	SET firstname='%s', lastname='%s', born='%s', prefix='%s', phone='%s', country_res='%s', extra=%s
	WHERE id=%d
;";
$result = $db->query(sprintf($sql,
	$_POST['firstname'],
	$_POST['lastname'],
	$_POST['born'],
	$_POST['prefix'],
	$_POST['phone'],
	$_POST['country'],
	isset($_POST['extra']) ? "'".$_POST['extra']."'" : "NULL",
	$_SESSION['user']['id']
));


XSS-уязвимости. Пользовательский код никак не фильтровался перед выводом:
<button id="btn-doc-password" class="btn btn-primary btn-large pull-right" data-action="<?= $_GET['action'] ?>"><i class="fas fa-check"></i> <?= _e("Valider") ?></button>


Кроме того, попавшая в БД информация, вроде причины консультации с врачом, не фильтровалась ни перед записью в базу, ни перед рендерингом на странице.
Отсутствие проверки прав доступа. Достаточно было иметь аккаунт пациента и подобрать автоинкрементный ID другого пациента, чтобы без труда получить список приёмов и другой информации из профиля. Те же проблемы были и на стороне приложения доктора. Более того, зная ID врача не составляло проблем получить доступ к его приёмам.
Отсутствие проверки загружаемых файлов. Через форму добавления документов можно было загрузить какой угодно файл в любую из папок, доступных для записи пользователям веб-сервера. Помимо того, поиграв с quеry-string запроса на загрузку документа можно было даже скачать файлы с исходным кодом.
$file_dir = $settings['documents']['dir'] . $_SESSION['client']['id'] . DIRECTORY_SEPARATOR . $_GET['id_user'];


Устаревшие сторонние библиотеки. У старого вендора никто не следил за версиями сторонних библиотек, которые, кстати, вместо использования того же Composer просто копировались в проект. Более того, в некоторые из таких сторонних зависимостей вносились изменения «под себя».
Небезопасное хранение паролей пользователей. Для хранения паролей использовались ненадёжные криптографические функции.
$sql = "
	SELECT id, firstname, lastname
	FROM user
	WHERE id=%d AND password=PASSWORD('%s')
;";
$result = $db->query(sprintf($sql, $_SESSION['user']['id'], $_POST['pass']));


Уязвимость CSRF. Ни одна форма не была защищена CSRF-токеном.
Отсутствие защиты от brute-force атак. Её просто не было. Никакой.

Тут можно было бы продолжить и дальше, но уже этих проблем достаточно, чтобы понять: либо у системы были серьёзные проблемы, либо она сама была серьёзной проблемой.

3. Код было сложно поддерживать и расширять
Проблемами безопасности всё не ограничилось. К нашему удивлению, на проекте отсутствовала система контроля версий. Код был совершенно не структурирован. В root-директории web-сервера находились файлы вроде ajax-new.php, ajax2.php и все они использовались в коде. Отсутствовало и чёткое разграничение на слои (presentation, application, data). В подавляющем большинстве случаев файл с кодом представлял собой смешение PHP, HTML и JavaScript.

Всё это привело к тому, что когда нас попросили сделать примитивный backoffice для этой системы, лучшим решением стало развернуть рядом Symfony 4 в связке с Sonata Admin и вообще не касаться существующего кода. Понятно, что если бы нас попросили добавить новые возможности для врачей или пациентов, это отняло бы у нас кучу сил и времени. А поскольку об автоматических тестах речи не шло, вероятность сломать при этом что-нибудь была бы крайне велика.

Всего перечисленного правительству Люксембурга оказалось достаточно — нам дали зелёный свет на разработку новой платформы.

Доктор едет-едет: как мы разрабатывали новую платформу

Готовиться к разработке новой платформы мы начали с самого начала — ещё когда увидели детище старого вендора. Поэтому, когда нам дали добро на разработку новой платформу, мы сразу приступили к созданию её MVP-версии. С этой задачей команда из четырёх PHP- и трёх фронтенд-разработчиков справилась за какие-то три с половиной недели. Все работы велись на Symfony 5, а делегировать удалось только видеозвонки и чаты — их реализовали с помощью нашего сервиса G-Core Meet. Пригодился и backoffice для старой системы: его удалось адаптировать к МVP всего за пару дней. В результате MVP-версия системы на 80% закрывала функционал старой платформы. Сейчас она, кстати, используется и для ещё одной задачи — в один момент мы клонировали MVP для хелпдеска агентства электронного здравоохранения Люксембурга, чтобы администраторы там могли созваниваться с пользователями.

Когда MVP был готов, мы приступили к разработке полноценной новой платформы. В качестве основы для API использовали API Platform и ReactJS в связке с Next.js для client-side. Без интересных задач не обошлось.

1. Реализуем уведомления
Одна из сложностей возникла с уведомлениями. Поскольку клиентами API могли быть как мобильный приложения, так и наши SPA, требовалось комбинированное решение.
Сначала мы выбрали Mercure Hub, с которым клиенты взаимодействуют через SSE (Server Sent Event). Но как бы это решение не пиарили сами создатели API Platform, наша мобильная команда его забраковала, так как с ним получать уведомления приложение могло только в активном состоянии.

Так мы пришли к Firebase, с помощью которого удалось добиться поддержки нативных пушей на мобильных устройствах, а для браузерных приложений оставили Mercure Hub. Теперь, когда в системе происходило какое-то событие, мы уведомляли пользователя об этом через нужный нам private-канал в Mercure Hub и, помимо этого, отправляли пуш ещё и на Firebase для мобильного устройства.

Почему мы сразу не реализовали всё на Firebase? Тут всё просто: несмотря на поддержку web-клиентов, браузеры без Push API — тот же Safari и большинство мобильных браузеров — с ним не работают. Однако, мы ещё планируем реализовать пуш-уведомления от Firebase для тех пользователей, которые используют поддерживаемые браузеры.

2. Функциональные тесты
Другая интересная ситуация возникла, когда мы занимались функциональными тестами для API. Как известно, каждый из них должен работать в чистом окружении. Но каждый раз поднимать базу и заполнять в ней базовые fixtures + fixtures, необходимые для тестирования, оказалось накладно с точки зрения производительности. Чтобы этого избежать, мы решили на начальном этапе поднимать базу данных на основании маппинга сущностей (bin/console doctrine:schema:create) и уже затем добавлять базовые fixtures (bin/console doctrine:fixtures:load).

Затем с помощью расширения dama/doctrine-test-bundle мы добились того, чтобы выполнение каждого теста оборачивалось в транзакцию и в конце тест-кейса откатывало её без фиксации. Благодаря этому, даже если в ходе тестирования в базу вносятся изменения, они не фиксируются, а база после прогона остаётся в том же состоянии, что и до запуска PHPUnit.
Чтобы на каждый эндпоинт был написан хотя бы один тест, мы сделали auto review тест. Он обнаруживает все зарегистрированные роуты и проверяет наличие тестов для них. Так, например, для роута app_appointment_create он проверяет, есть ли в папке tests/Functional/App/Appointment файл CreateTest.php.

Дополнительно за качеством кода следят PHP-CS-Fixer, php-cpd и PHPStan c расширениями типа phpstan-strict-rules.

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

Такой подход позволяет в одном пул-реквесте создать фичу (библиотеку) и интегрировать её во все нужные приложения. Это преимущество и привело к использованию монорепозитория вместо реализации фич в отдельных npm-библиотеках и проектов в разных репозиториях.
Для конфигурации монорепозитория используется библиотека ns.js, которая с коробки позволяет собирать библиотеки и приложения React и Next.js, а именно этот стек и используется в проекте. Чтобы следить за качеством кода, мы используем ESLint и Prettier, для написания unit-тестов — Jest, а для тестирования компонентов React — React Testing Library.

Доктор прибыл: что получилось в итоге
Всего за пять месяцев все проблемы были разрешены, а новая платформа стала доступна пользователям любых устройств: мы подготовили веб-версию сервиса, а также мобильные приложения для iOS и Android.

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

Платформа доступна для всех медицинских профессионалов, жителей и работников Люксембурга. Сейчас она работает в 2-х крупнейших учреждениях здравоохранения страны — в Больнице им. Роберта Шумана (Hôpitaux Robert Schuman) и Больничном центре им. Эмиля Мэйриша (Centre Hospitalier Emile Mayrisch). Сервис развёрнут в защищённой точке присутствия облака G-Core Labs в люксембургском дата-центре EDH Tier IV, где для него настроена виртуальная среда в соответствии с нужными спецификациями.

https://gcorelabs.com

Приглашаем на бесплатный вебинар: выбор облака в 2021 году


Вебинар будет полезен разработчикам игр и приложений, техническим руководителям, финансовым директорам и специалистам из финтеха, ретейла, СМИ, финансового сектора и других сфер.




www.webinar.gcorelabs.com

Локация Cloud в Хабаровске и другие новости G-Core Labs


Как интегрировать видеозвонки в платформу для офлайн- и онлайн-мероприятий: опыт Momento Solutions
gcorelabs.com/ru/cases/momentosolutions

Новый регион G-Core Labs Cloud: Хабаровск
Точки присутствия G‑Core Labs Cloud уже открыты в Люксембурге, Москве, Манассасе и Сингапуре.
Мы запускаем новую edge-локацию нашего облака в Хабаровске.
Новая точка поможет развивать бизнес на Дальнем Востоке России и в азиатском регионе в целом, сократить задержки для конечных пользователей.
Масштабируйте IT-инфраструктуру, ускоряйте процессы разработки, тестирования и вывода новых продуктов на рынок с помощью наших сервисов.


БЛИЖАЙШИЕ ПЛАНЫ
Скоро мы добавим автоматическое развёртывание Kubernetes-кластеров для оркестрации контейнеров.

Следующую edge-локацию мы планируем запустить в Амстердаме.

https://gcorelabs.com

Стражи публичных облаков: как мы внедряли анклавы Intel SGX для защиты чувствительных данных

Как развеять предубеждения потенциальных пользователей относительно безопасности публичных облаков? На помощь приходит технология Intel Software Guard Extensions (Intel SGX). Рассказываем, как мы внедрили её в своём облаке и какие преимущества от нашего решения получила компания Aggregion.


Кратко об Intel SGX и его роли в облаке
Intel Software Guard Extensions (Intel SGX) — набор инструкций ЦП, с помощью которых в адресном пространстве приложения создаются частные защищённые области (анклавы), где размещается код уровня пользователя. Технология обеспечивает конфиденциальность и целостность чувствительных данных. Путём изоляции в анклаве они получают дополнительную защиту как от несанкционированного внешнего доступа, в том числе со стороны провайдера облачных услуг, так и от внутренних угроз, включая атаки со стороны программного обеспечения привилегированного уровня.

Принципы работы. Для хранения кода и данных анклавов технология Intel SGX выделяет область памяти – Processor Reserved Memory (PRM). ЦП защищает её от всех внешних обращений, в том числе от доступа со стороны ядра и гипервизора. В PRM содержится Enclave Page Cache (EPC), состоящий из блоков страниц объёмом 4 КиБ, при этом каждая страница должна принадлежать только одному анклаву, а их состояние фиксируется в Enclave Page Cache Metadata (EPCM) и контролируется ЦП.

Безопасность EPC обеспечивается за счёт Memory Encryption Engine (MEE), который генерирует ключи шифрования, хранящиеся в ЦП. Предполагается, что страницы могут быть расшифрованы только внутри физического ядра процессора.

Преимущества. Intel SGX позволяет повысить уровень доверия к публичному облаку со стороны организаций, использующих в своей работе чувствительные данные (пароли, ключи шифрования, идентификационные, биометрические, медицинские данные, а также информацию, относящуюся к интеллектуальной собственности). Речь идёт о представителях самых разных отраслей — финансового сектора, медицины и здравоохранения, ритейла, геймдева, телекома, медиасферы.

Наш подход к внедрению Intel SGX
Чтобы в публичном облаке G-Core Labs появилась возможность выделять виртуальные машины с анклавами Intel SGX, нам пришлось пройти путь от компиляции патченного ядра KVM и QEMU до написания Python-скриптов в сервисах OpenStack Nova. Вычислительные узлы, которые планировалось использовать для выделения виртуальных машин повышенной безопасности, мы решили определить в отдельный агрегатор — тип вычислительных ресурсов, требующий дополнительной настройки. На таких узлах было необходимо:

Включить поддержку Intel SGX на уровне BIOS.


Поставить патченные QEMU/KVM.
Изначально у нас не было понимания, как это должно работать и что в итоге мы должны прикрутить, чтобы получить ВМ нужной конфигурации. Разобраться с этим вопросом нам частично помогло руководство Intel для разработчиков. С его помощью мы узнали, как подготовить вычислительный узел для работы с SGX и какими дополнительными параметрами должен обладать конфигурационный XML-файл виртуальной машины. Здесь же мы нашли исчерпывающую информацию, как с помощью виртуализации KVM сделать гостевую машину с использованием Intel SGX. Чтобы убедиться, что мы смогли обеспечить поддержку данной технологии, мы использовали два способа:

Проверили секцию /dev/sgx/virt_epc в файле /proc/$PID/smaps:
[root@compute-sgx ~]# grep -A22 epc /proc/$PID/smaps
7f797affe000-7f797b7fe000 rw-s 00000000 00:97 57466526		/dev/sgx/virt_epc
Size:               8192 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
Rss:                   0 kB
Pss:                   0 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:            0 kB
Anonymous:             0 kB
LazyFree:              0 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
FilePmdMapped:         0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                0 kB
THPeligible:	0
VmFlags: rd wr sh mr mw me ms pf io dc dd hg

И воспользовались данным shell-скриптом, предварительно поставив SGX-драйвер (все действия осуществлялись внутри ВМ):
[root@sgx-vm ~]# cat check_sgx.sh
#!/bin/bash

METRICS="sgx_nr_total_epc_pages \
    sgx_nr_free_pages \
    sgx_nr_low_pages \
    sgx_nr_high_pages \
    sgx_nr_marked_old \
    sgx_nr_evicted \
    sgx_nr_alloc_pages \
    "
MODPATH="/sys/module/isgx/parameters/"

for metric in $METRICS ; do
    echo "$metric= `cat $MODPATH/$metric`"
done

[root@sgx-vm ~]# curl -fsSL https://raw.githubusercontent.com/scontain/SH/master/install_sgx_driver.sh | bash -s - install -p metrics -p page0

[root@sgx-vm ~]# ./check_sgx.sh
sgx_nr_total_epc_pages= 2048
sgx_nr_free_pages= 2048
sgx_nr_low_pages= 32
sgx_nr_high_pages= 64
sgx_nr_marked_old= 0
sgx_nr_evicted= 0
sgx_nr_alloc_pages= 0

Стоит учитывать, что, если одна страница занимает 4 КиБ, то для 2048 страниц требуется 8 МиБ (2048 x 4 = 8192).

Трудности разработки и их преодоление
Отсутствие какой-либо технической документации по интеграции Intel SGX в OpenStack было нашей основной трудностью на момент внедрения. Поиск привел нас к статье проекта SecureCloud, где был представлен способ управления виртуальными машинами с анклавами SGX.

Найденная информация помогла понять, над чем именно нам предстоит работать. В результате мы сформировали следующие задачи:
  • Добиться от сервиса OpenStack Nova генерации XML-файла с дополнительными параметрами для виртуальных машин с поддержкой Intel SGX.
  • Написать фильтр планировщика OpenStack Nova с целью определения доступной памяти для анклавов на вычислительных узлах и осуществления некоторых других проверок.

Их выполнения было достаточно для интеграции Intel SGX в наше публичное облако.

Кроме того, мы дописали сбор статистики с учетом EPC:
# openstack usage show
Usage from 2020-11-04 to 2020-12-03 on project a968da75bcab4943a7beb4009b8ccb4a:
+---------------+--------------+
| Field         | Value        |
+---------------+--------------+
| CPU Hours     | 47157.6      |
| Disk GB-Hours | 251328.19    |
| EPC MB-Hours  | 26880.02     |
| RAM MB-Hours  | 117222622.62 |
| Servers       | 23           |
+---------------+--------------+


Безопасная среда для запуска контейнеризированных приложений


Научившись выделять виртуальные машины с поддержкой Intel SGX, мы использовали платформу SCONE компании Scontain, чтобы обеспечить возможность безопасного запуска контейнеризированных приложений в случае угроз со стороны привилегированного программного обеспечения. При использовании данного решения для прозрачной защиты файловых систем в средах Docker, Kubernetes и Rancher достаточно наличия процессора Intel с поддержкой SGX и драйвера Linux SGX.

Запуск каждого из контейнеров возможен лишь при наличии файла конфигурации, создаваемого клиентским расширением платформы SCONE. В нём содержатся ключи шифрования, аргументы приложения и переменные среды. Файлы, сетевой трафик и стандартные потоки ввода/вывода (stdin/stdout) прозрачно зашифрованы и недоступны даже для пользователей с правами root.

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

С помощью драйвера SGX для каждого анклава в виртуальном адресном пространстве резервируется до 64 ГБ памяти. Платформа SCONE поддерживает языки программирования C/C++/C#/Rust/Go/Python/Java. За счёт специального компилятора исходный код автоматически (без необходимости дополнительных модификаций) подготавливается к использованию совместно с Intel SGX.

Кейс Aggregion
Завершив все необходимые работы по интеграции Intel SGX, мы подключили к нашему публичному облаку платформу управления распределёнными данными компании Aggregion.

Она предназначена для реализации совместных маркетинговых проектов представителями различных отраслей — финансовых и страховых услуг, государственного управления, телекоммуникаций, ритейла. Партнёры анализируют поведение потребителей, развивают таргетированное продвижение товаров и услуг, разрабатывают востребованные программы лояльности, обмениваясь и обрабатывая обезличенные массивы данных на платформе Aggregion. Поскольку утечка конфиденциальной информации крайне не желательна и грозит серьёзными репутационными рисками, компания уделяет особое внимание вопросам безопасности.

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

Принципы безопасной работы на платформе Aggregion. В контуре каждого поставщика чувствительные данные изолируются в анклавы Intel SGX, которые фактически представляют собой чёрные ящики: что происходит внутри, недоступно никому, в том числе и провайдеру облачной инфраструктуры. Проверка первоначального состояния анклава и возможности его использования для хранения конфиденциальной информации осуществляется за счёт удалённой аттестации, когда MrEnclave определяет хеш-значение.

Потенциальная польза для клиентов. Комбинирование баз данных нескольких поставщиков позволяет повысить эффективность совместных рекламных кампаний. При выделении целевой аудитории по заданным параметрам мэтчинг (сопоставление) сегментов выполняется непосредственно внутри контейнеров с поддержкой анклавов Intel SGX. За пределы выводится только конечный результат: например, численность пользователей, соответствующих выбранным атрибутам. Аналогичным образом оценивается эффективность проведенных кампаний: в анклавы выгружаются данные о рекламных показах и совершённых продажах для вычисления прироста покупок целевой группы относительно контрольной, который и выдаётся наружу для дальнейшего использования.


Выводы
Мы понимаем, что Intel SGX не является панацеей по защите данных и можно найти ряд статей, порицающих эту технологию, в том числе и на Хабре. Периодически появляются сообщения об атаках, способных извлечь конфиденциальные данные из анклавов: так, в 2018 году бреши в SGX пробили Meltdown и Spectre, в 2020 году – SGAxe и CrossTalk. В свою очередь компания Intel устраняет выявленные уязвимости с помощью обновлений микрокода процессоров.

Почему же мы всё-таки решили внедрить данную технологию? Мы видим в применении Intel SGX возможность сократить потенциальную область кибератак за счёт создания дополнительного контура защиты облачной инфраструктуры G-Core Labs наряду с уже задействованными технологиями информационной безопасности и тем самым повысить доверие наших пользователей к хранению и обработке конфиденциальных данных. Надеемся, что в будущем нам ещё предстоит поделиться с вами успешными клиентскими кейсами, хотя и не берёмся утверждать, что наши статьи не будут основаны на историях обнаружения и устранения новых уязвимостей.

https://gcorelabs.com

Облачный десант: как мы интегрировали публичное облако с CDN и что из этого получилось

Когда в вашем распоряжении одновременно оказывается мощное облако с инфраструктурой в США, Евросоюзе, СНГ, Азии и Австралии и CDN со 100 точками присутствия в 70+ городах на пяти континентах, решение приходит само собой — нужно их интегрировать! Такая синергия очевидно расширит возможности инфраструктуры. Конечно же, мы не могли упустить такую возможность, но в то же время столкнулись с целым рядом челленджей.

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



Зачем вообще интегрировать облако с CDN
В первую очередь публичное облако — это масштабируемые мощности. Их можно использовать как угодно: для разработки и тестирования сервисов, а также хранения и обработки данных. Мы в G-Core Labs запустили облако в прошлом году и уже успели задействовать его в высоконагруженных проектах. Например, наш давний клиент — Wargaming — использует это решение сразу для нескольких задач:
  • Тестирование новых фич и сервисов разных проектов;
  • Подготовка тестовых прототипов с внешними разработчиками, которым нужен доступ к изолированным настраиваемым и контролируемым ресурсам;
  • Работа онлайн-игры «Калибр» на виртуальных машинах.

Со всем перечисленным облако справляется на ура, но работа на этом не заканчивается. Для чего бы ни были задействованы те или иные мощности, результат их работы ещё нужно доставить до точки назначения. О чём бы ни шла речь — об онлайн-игре или настоящих военных соединениях — тут-то и возникает проблема: что многотонную боевую технику, что тяжёлые данные быстро доставлять в удалённые регионы крайне непросто. Упростить эту задачу позволяет интеграция облака с сетью доставки контента. С помощью CDN транспортабельную часть — статические данные — можно забросить «по воздуху» прямо к точке назначения, а из облака лишь останется отправить «негабаритные» динамические данные. С таким подходом можно смело начинать работу даже на других континентах, так как интеграция позволяет быстрее конкурентов доставлять тяжёлый контент по всему миру.



Сокращай, распределяй, ускоряй: как CDN помогает облаку
Перейдём к конкретике. Мы не понаслышке знаем, что доставлять тяжёлый контент в удалённые регионы прямо из облака выходит долго, а постоянно увеличивать мощность инфраструктуры согласно росту нагрузки бывает накладно. К счастью, помимо публичного облака у нас оказалась и своя CDN, которая даже вошла в Книгу рекордов Гиннеса, обеспечив бесперебойный опыт игры в World of Tanks в период пиковой нагрузки.

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

1. Облачные сервисы находились под постоянной нагрузкой. Пользователи высоконагруженных проектов регулярно запрашивали контент из облаков наших клиентов. Это приводило к высокой нагрузке и долгой отдаче данных. Требовалось решение, которое позволило бы легко сократить количество обращений к источнику. Для этого мы интегрировали серверы публичного облака и кеш-серверы CDN, а также сделали единый интерфейс управления этими сервисами. С его помощью пользователи могут выносить статические данные в нужные точки присутствия сети. Благодаря этому обращения к облаку происходят только при первых запросах контента. Работает это стандартно: CDN забирает данные у источника и отправляет их пользователю, а также ближайшему к нему кеш-серверу, откуда контент и раздаётся при последующих запросах;

2. Данные долго передавались между облаком и CDN. Объединив облако с сетью доставки контента, мы заметили, что задержка при доставке данных могла бы быть меньше. Чтобы сохранить как можно больше драгоценных миллисекунд, пришлось реализовать обмен трафиком между кеш-серверами и облаком внутри опорной сети (backbone);



3. Нагрузка на источник оказывалась неравномерно. Даже после подключения CDN оставшиеся обращения к облаку распределялись неэффективно. Мы исправили это с помощью HTTP(S)-балансировщиков. Теперь в момент запроса контента они определяют из какого именно источника (виртуальной машины или бакета облачного хранилища) следует забирать данные для кеширования;

4. Тяжёлый контент долго шёл до пользователей. Чтобы сократить время ожидания, мы постоянно наращивали мощность и географию присутствия CDN. Теперь пользователям уже не приходится ждать, пока контент дойдёт до них через полмира — в момент обращения сеть доставки контента выбирает ближайшую из 100 точек присутствия на пяти континентах. В результате среднее время отклика по всему миру находится в пределах 30 мс.

Разобравшись с этими проблемами, мы уже было посчитали работу законченной. Но у облака с CDN на нас были иные планы.

Так закалялась сталь: модернизируем инфраструктуру
В один момент стало понятно, что эффект от всех наших усилий не мог проявиться в полной мере, пока мы использовали старую аппаратную конфигурацию. Чтобы серверы и размещённые на них приложения работали лучше, а контент передавался быстрей, требовался апгрейд инфраструктуры. Звёзды на небе сошлись в начале этого года: мы принялись за модернизацию, как только вышла линейка масштабируемых процессоров Intel Xeon Scalable второго поколения.

Сейчас стандартная конфигурация серверов выглядит следующим образом:
  • Облачные сервисы работают на процессорах Intel Xeon Gold 6152, 6252 и 5220, имеют до 1 ТБ RAM, а также SSD и HDD с тройной репликацией;
  • Кеш-серверы CDN оснащены Intel Xeon Platinum, виртуальными RAID на CPU и SSD D3-S4610.

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

Шилдинг, шардинг и геораспределение: ускоряем доставку контента в экстремальных условиях
Беда не приходит одна. Это особенно актуально, когда речь идёт о глобальных проектах. Отсутствие географически распределённой инфраструктуры, высокие нагрузки из-за множества пользователей со всего мира и море разнородных данных, которые им нужно быстро доставлять, — одному нашему клиенту, крупному медиаресурсу, нужно было разом разобраться со всеми этими сложностями. Немного подробностей:
  • Контент долго шёл до пользователей, а иногда и вовсе до них не доходил из-за высоких задержек и проблем в сети. Сложность заключалась в том, что весь большой пул серверов с данными размещался в одной географической точке;
  • К источнику контента обращались пользователи со всего мира, что вызывало повышенную нагрузку на инфраструктуру и приводило к дороговизне обслуживания, а также медленной отдаче данных;
  • Пользователям требовалось доставлять огромное количество постоянно пополняемого контента, уникального для каждого региона.

Базовыми возможностями интеграции облака с CDN тут было не обойтись. Мы взялись за разработку дополнительных решений.

Как мы придумали «региональный шилдинг»
Это понятие, а теперь уже и действующую услугу, мы ввели специально для решения проблемы с удалённостью источника контента. Из-за того, что все серверы клиента находились в одной географической точке, данные от них долго добирались до пользователей из разных частей света. Ситуацию усложнял тот факт, что в разные регионы нужно было доставлять разный, постоянно пополняемый контент. Простое кеширование данных на edge-серверах проблему бы не устранило — они бы всё равно часто обращались к источнику через полмира.

Мы решили задачу, развернув большой пул кеш-серверов в популярных точках обмена трафика на разных континентах. «Региональные шилдинги» стали своеобразными прослойками между источником и edge-серверами в странах пользователей. Теперь весь востребованный в соответствующих частях света контент сначала попадал на них, а затем передавался кеш-серверам. Таким образом шилдинги разом снизили нагрузку на источник клиента и сократили задержки до конечных пользователей. Клиент, в свою очередь, сэкономил на размещении нескольких пулов серверов с одинаковым контентом в разных частях света, так как при таком принципе работы достаточно было одного источника данных.


Зачем понадобилось шардирование контента
Проблему долгой доставки контента в разные части света региональные шилдинги решили сполна. Однако, теперь возникла новая сложность: поскольку данных у клиента было много и они постоянно обновлялись, их то и дело не оказывалось в кеше edge-серверов, к которым обращались пользователи. Это приводило к тому, что на региональные пулы постоянно сыпалась масса запросов от кеш-серверов, число которых в одной группе достигало 20–30 штук. Чтобы снять с шилдингов часть этой нагрузки и доставлять контент пользователям ещё быстрей, мы добавили возможность забирать нужные данные у ближайшего edge-сервера в пуле.

Теперь кеш-серверы в регионах присутствия начали обращаться к шилдингам лишь тогда, когда данных не оказывалось во всей группе. Причём даже в этих случаях контент сразу же запрашивался именно у того сервера, который его содержал — благодаря шардингу edge-серверы заранее «знали» где лежит конкретный файл, а не опрашивали для этого весь пул региональных шилдингов. Такой принцип работы снизил количество запросов к пулу и позволил эффективно распределять контент по нему вместо того, чтобы хранить копии данных на каждом сервере. В результате шилдинги вмещали больше контента и как следствие оказывали меньшую нагрузку на источник клиента.


Создание такой инфраструктуры не могло не повлечь за собой ещё одной сложности. Учитывая количество кеш-серверов в группах, было бы глупо предположить, что ни один из них не может выйти из строя. В такой ситуации, как и в случае добавления в пул нового сервера, кеш в группах нужно было перераспределять оптимальным образом. Для этого мы реализовали организацию шардированного кеша с алгоритмом консистентного хеширования в блоке upstream в nginx:
upstream cache_servers {
   hash $cache_key consistent;
   server edge1.dc1.gcorelabs.com;
   server edge2.dc1.gcorelabs.com;
   server edge3.dc1.gcorelabs.com;
}


Появление в пуле недоступных серверов также было чревато ещё одной проблемой: другие серверы продолжали посылать к ним запросы и ожидали ответа. Чтобы избавиться от этой задержки, мы написали алгоритм обнаружения таких серверов в пуле. Теперь, благодаря тому что они автоматически переводятся в состояние down в upstream-группе, мы больше не обращаемся к неактивным серверам и не ждём от них данных.

В результате этих работ мы снизили стоимость услуг для клиента, избавили его от серьёзных затрат на организацию собственной инфраструктуры и существенно ускорили доставку данных до пользователей, несмотря на все сложности.

Кому пригодилось облако с CDN
Работы по интеграции позади, а продуктом уже пользуются наши клиенты. Делимся, кто из них получает от этого наибольшую отдачу.

Скажем сразу, что решение пригодилось не всем. Другого мы и не ждали: кому-то достаточно одного лишь хранилища и виртуальных машин, а кому-то — сети доставки контента. Например, когда вся аудитория у проекта находится в одном регионе, CDN к облаку подключать практически незачем. Для минимизации задержек в этом случае хватит сервера, расположенного неподалёку от пользователей.

Во всей красе интеграция раскрывается, когда нужно быстро и далеко отдавать тяжёлый контент большому количеству пользователей. Вот пара примеров того, как облако с CDN помогает разным проектам:
  • Стриминговые сервисы, критичные к задержкам и буферизации, добиваются стабильной работы и высокого качества трансляций;
  • Сервисы онлайн-развлечений быстрее доставляют тяжёлые игры в разные точки мира и снижают нагрузку на серверы, в том числе при пиковых нагрузках;
  • Медиапроекты ускоряют загрузку рекламы и сохраняют доступность при всплесках посещаемости;
  • Интернет-магазины быстрее загружаются в разных странах, в том числе во время акций и распродаж.

Мы продолжаем наблюдать за тем, как именно они используют облако с CDN. Нам, как и вам, интересны цифры: как сильно снижается нагрузка на инфраструктуру, насколько быстрее пользователи получают контент в конкретных регионах и как сильно интеграция помогает сэкономить. Всем этим мы поделимся в будущих кейсах.

https://gcorelabs.com