HighLoad++ 2017 Зал «Кейптаун», 7 ноября, 17:00 Тезисы: http://www.highload.ru/2017/abstracts/2897.html Нашей группе было поручено создать новый самостоятельный “регион” для всех продуктов New Relic, предназначенный для обслуживания европейских клиентов, подпадающих под ограничения GDPR. Здесь следует отметить, что так как наша компания предоставляла свои услуги исключительно через “облако” (SaaS), то хорошо выработанных процессов для настройки всей инфраструктуры “с нуля” у нас не было. ...

1. Разработка портируемой
инфраструктуры New Relic -
контейнеры, CoreOS и
прочие приключения
Михаил Панченко

2. Кратко О Себе

3. Кратко О Себе
Отдел «Скорость Разработки» в New Relic
Смертный враг технического долга
Бородач-любитель

4. Кратко О Себе
Отдел «Скорость Разработки» в New Relic
Смертный враг технического долга
Бородач-любитель

5. Постановка Задачи
Что такое New Relic? Зачем его портировать, и куда?

6. Мониторинг
производительности,
от инфраструктуры до
браузера и мобильного
приложения.

8. По цифрам
• 300+ программистов
• 40+ команд
• 6 продуктов, многочисленные общие компоненты (Alerts, Radar)
• 400-500 сервисов, смотря что считать сервисом
• 1 «регион»
• 3 ДЦ + AWS
• 9,5 лет разработки

10. В Чем Задача?

11. В 2018ом Году, запустить
второй «регион» в Европе
Точное число еще не объявили; из-за этого умолчания о сроках. Простите.

12. GDPR осложняет жизнь
Данные о пользователях из Европы не должны покидать Европу

13. US Region
Accounts DB
Login/Auth Services
Billing Services
Customer Data DBs
Application Services
newrelic.com user

14. US Region
Accounts DB
Login/Auth Services
Billing Services
Customer Data DBs
Application Services
EU Region
Customer Data DBs
Application Services
replication
newrelic.com user eu.newrelic.com user

15. (конечно, состав не
удваивается…)

16. Подозреваем что и третий
регион тоже не далеко

17. В сторону:
Никогда не говорите боссу что вам скучно

18. Итак, 9,5 лет…

19. «Органически» выращенная
инфраструктура

20. Отстроена «с нуля» раз в год
«Готовность к ЧП»

21. Что-то в ДЦ, что-то в AWS

22. Смешанная Инфраструктура
CentOS 7, CentOS 6, CoreOS (новое)
Puppet, Ansible, Capistrano

23. Деплоймент и конфигурация
зависят от команды и года
разработки
Новое в контейнерах, старое нет
Контейнеры – под Centurion (старое) или Marathon (новое)
Базы данных в контейнерах, но не все

24. Чем старше и важнее сервис,
тем сложнее его запускать

25. Зависимость от железа
Базы данных и другие ключевые системы очень любят SSDs и быструю сеть
Многие системы плохо реагируют на задержки в сети, «шумных соседей»
Предположения о специфическом железе глубоко впитались в дизайн систем

26. Итак, параметры задачи…
• За [...] месяцев возвести второй «регион» всех приложений
• Сделать это в «cloud»
• Бизнес хочет двигаться со временем туда
• Нанимать людей и отстраивать ДЦ в Европе нет ни времени ни бюджета
• Да и слишком рискованно
• … но что бы хорошо работало
• Не тормозить всю компанию!

29. Три Важных Характеристики

30. 1. Воспроизводимость
характеристика результатов испытаний, определяемая взаимной близостью
результатов повторных испытаний объекта

31. Воспроизводимость
https://www.flickr.com/photos/xstc/14394455377
https://www.flickr.com/photos/thebricktime/12562072535
https://www.flickr.com/photos/coweater/4727185794
VS

32. “You’re only good at the things
you do every day.”
Unknown
(забыл кто сказал, и никак не могу найти)

33. 2. Согласованность
Внутреннее соответствие убеждений и действий, поведения индивида

34. Согласованность
https://www.flickr.com/photos/sillygwailo/4545296980 https://www.flickr.com/photos/dsundesigns/36359861566
VS

35. 3. Гибкость
склонность к уступкам, компромиссам

36. Гибкость
https://www.flickr.com/photos/mark6mauno/14209903504
VS

37. Все три у нас имеются в изобилии
… но только локально и никогда все вместе

38. Вопрос 1: Где строить, и как?

39. AWS – идеальный вариант
… но только с точки зрения нашей группы

40. AWS и другие “clouds” отпадают
Слишком много неконтролируемых задержек и вариаций

41. Гибкость ✖
В отношении железа ее практически нет, и очень дорого ее развить

42. Свой ДЦ Отпадает
Слишком дорого и рискованно

43. Остаются «MSP»
Но тогда в страдают воспроизводимость и согласованность

44. Vendor X
Опять не могу назвать по имени

45. Vendor X
• Удовлетворяет нужды по производительности
• Сеть общая, но со строгими гарантиями
• Поставляет железо с удаленным управлением
• Имеет API
• Легко запрашивать инвентарь
• Заказывать серверов по API; установка занимает 3-5 часов
• Terraform и т.д. не поддерживается

46. Воспроизводимость? ✖
Заказы делаются путем посылки сложной структуры на API
API императивное, не декларативное
API явно смоделированно под UI

47. Согласованность? ✖
Добавляется третий способ эксплуатации ресурсов – ни как ДЦ, ни как в AWS

48. Решение – Закатать Рукава!
Пишем свои «providers» для Terraform!

49. Кратко о Terraform
Длиннее – отличный пост на блоге Selectel
https://blog.selectel.ru/gostevoj-post-upravlyaem-virtualnym-privatnym-oblakom-s-pomoshhyu-
terraform/

50. Terraform: Утилита и язык для
моделирования инфраструктуры
“Infrastructure As Code”

52. https://adamcod.es/2015/10/22/a-pracitcal-introduction-
to-terraform-tutorial.html

54. Декларативный Синтаксис
Ввод в Terraform – это конечное желаемое состояние системы

55. Полностью подключаемая
архитектура
Если Terraform чего-то не делает, это только потому что вы, читатель, еще не
заставили его это делать

58. Module “private_host”:

59. Логическое Разделение
Заказ сервера отделен от Настройки Функции, “imaging”

61. Воспроизводимость? ✔
Terraform дает автоматизацию взвода инфраструктуры, даже с железом

62. Согласованность? ✔
Раздел заказа серверов от «imaging» - привычный паттерн

63. Бонус: все через Git + Jenkins
Центральный контроль и журнал действий – никаких недомолвок

64. На будущее: анализ состояния
Terraform
Состояние хранится в S3 – скачивай и делай что хочешь

65. Вопрос 2: Как не перегрузить и
не запугать всю компанию?

66. Вспомним – много вариантов
Разные языки, платформы, CM, паттерны

67. Каждый вариант добавляет
сложность и хрупкость
То есть нагрузку на задействованные команды во время взвода

68. Согласованность? ✖
Это самое важное место где ее не хватает

69. Решение: доделываем переход
на контейнеры и переменные
окружения начатый в 2013ом
От многих команд требуется начальный вклад; потом – свобода!

70. Бонус: только CoreOS в новом
регионе
Если все хорошо – перегоняем старый и имеем общие основы
Если плохо, вернуться на CentOS легко когда все в контейнерах!

71. Погашение огромного
технический долга
Превращаем тактическую задачу в стратегическую

72. Большие перемены требуют
внимательного надзора
Такие задачи могут вызвать страх, нервы, и сопротивление

73. Требуется точность в
изъяснениях и запросах
“In a container” != “In a container running in Marathon”

74. Помогает только опыт
Ищем и внедряем локальных «чемпионов»

75. Воспроизводимость? ✔
Все сервисы запущены либо через Marathon или Centurion
Вся конфигурация – в коде
Ее даже можно анализировать!

76. Согласованность? ✔
Все запускается и получает конфигурацию одним и тем же методом

77. Гибкость? ✔
Контейнеры теперь можно запускать на любой каркас или “orchestrator”
Конечно, зависимость от железа остается на следующий раунд

78. Симуляция идеального запуска региона

79. Вопрос 3: Что делать с
балансировщиками?

81. Заменять нет ни времени ни
желания
Работы у сетевой группы и так полно

82. Делать что-то новое только в
новом регионе – пугает
В «раздвоенной» инфраструктуре значительно возрастает риск ошибки

83. Но! Есть «виртуальная» версия!
OS балансировщиков доступен в виде разных VM images
Гипервизор мы запускать не собираемся, но есть *.qcow2
Можно просто запустить на Linux под qemu-kvm!

84. (это модифицированный Linux)

85. Итак, заходим на сервер
CoreOS и запускаем qemu-kvm…
Ах да! Нет менеджера пакетов…

86. Устанавливаем from source!

87. $ ./configure
bash: command not found: python

88. Нет менеджера пакетов, но…

89. … есть Docker!

90. $ docker run centos:7 ... /bin/bash
# yum install qemu-kvm
# qemu-kvm …. BIGIP-13.0.0.0.qcow2

91. https://gfycat.com/gifs/detail/ornerywanfly

95. Даем доступ к сети “host”
Прямой доступ к NIC, не через Docker

96. Сам qcow2 image оставляем на
файловой системе; контейнеру
доступ через bind-mount
Конечно внутри контейнера это бы работало очень медленно.

97. Забивает NIC на 80-85%!

98. Авто-настройка
Балансировщик готов к работе как только контейнер загрузился

99. Воспроизводимость? ✔

100. Согласованность? ✔
Все работает так же как и в первом регионе!

101. … а дальше – увидим!

102. Вопросы?

103. Спасибо!
m@mihasya.com @mihasya