Документ обсуждает переход от монолитной архитектуры приложений к микросервисной, подчеркивая преимущества использования контейнеров и инструментов, таких как Docker и Kubernetes. Обсуждаются вызовы управления зависимостями, масштабирования и распределения ресурсов, а также использование cgroups для ограничения ресурсов, что позволяет оптимизировать производительность сервисов. В итоге подчеркивается важность правильной настройки и управления архитектурой для обеспечения стабильности и эффективности в облачной инфраструктуре.

1. Эксплуатация
container based
инфраструктур
Николай Сивко
okmeter.io

2. Мир изменился

3. Было
• Монолитное приложение, работающее в гордом одиночестве на
сервере или виртуалке
• БД на отдельных серверах
• Фронтенды
• Вспомогательные инфраструктурные сервисы

4. Dev: есть проблемы
• Монолит сложно разрабатывать толпой разработчиков!
• Сложно управлять зависимостями!
• Сложно релизить!
• Сложно траблшутить!

5. Dev: микросервисы!
• Разделим монолит, каждый сервис будет простой!
• Зависимости больше не проблема!
• Для релизов что-нибудь придумаем!
• Траблшутить каждый сервис просто, они все простые!

6. Сложность системы снизилась?!
“Ежели где-то что-то убыло,
то где-то что-то прибыть должно непременно”
М. Ломоносов

7. Архитектура: было
• Связь – procedure call
• Описание взаимодействия - код

8. Архитектура: стало
• Связь – Remote Procedure (API) call
• По сети
• По пути есть балансеры
• По пути есть service discovery
• Описание взаимодействия - ????

9. Микросервисы: решения
• Infrastructure is a code: если не зафиксируем архитектуру – не
выживем
• Docker: удобная упаковка
• Оркестрация

10. Docker
• Решили проблему упаковки — было сложно собирать rpm/deb
пакеты
• Чтобы не думать про коллизии портов итд – намудрили с сетью
• Linux namespaces + cgroups + layered fs + TOOLING + …

11. Docker и друзья: следствие
• Контейнер легко собрать и запустить
• Контейнер легче VM, можно плотнее деплоить

12. Docker и друзья: следствие
• Контейнер легко собрать и запустить
• Контейнер легче VM, можно плотнее деплоить
• Убрали барьеры в порождении микросервисов

13. Счастливое облачное будущее
• Не хотим думать про ДЦ, серверы, сеть — всё это облако, мы
запускаем там контейнеры
• Масштабировать будем просто докидывая ресурсы (серверов/
инстансов)

14. Облачное настоящее: под нагрузкой
• Есть серверы docker-*, kube-* на каждом из них 20-50
контейнеров
• Базы работают на отдельных железках и как правило общие
• Resource-intensive сервисы на отдельных железках
• Latency-sensitive сервисы на отдельных железках

15. Почему некоторые инстансы медленнее?

16. Почему некоторые инстансы медленнее?
• Может там серверы слабее?
• Может кто-то ресурсы съел?
• Нужно найти, на каких серверах работают инстансы
• dc1d9748-30b6-4acb-9a5f-d5054cfb29bd
• 7a1c47cb-6388-4016-bef0-4876c240ccd6
и посмотреть там на соседние контейнеры и потребление ресурсов

17. Почему некоторые инстансы медленнее?
• Как оказалось, мы хотим знать топологию!
• Следующим шагом мы захотим управлять топологией!

18. Почему некоторые инстансы медленнее?
• Как оказалось, мы хотим знать топологию!
• Следующим шагом мы захотим управлять топологией!
• Есть ли способ не думать про это???

19. Попробуем подсмотреть
Google Container Engine, Amazon EC2 Container Service:
• Это всего лишь dedicated k8s поверх купленных вами VM
• Никаких готовых рецептов они не предлагают

20. Попробуем подсмотреть
Google Container Engine, Amazon EC2 Container Service:
• Это всего лишь dedicated k8s поверх купленных вами VM
• Никаких готовых рецептов они не предлагают
Google App Engine:
• Вы выбираете класс инстанса
• Класс = CPU (Mhz) + Memory
• Mhz = CPU Shares
• Платим за instance/hour

21. Лимиты ресурсов
• Ресурсы нужно ограничивать – вводить классы как в GAE
• Docker, k8s и аналоги поддерживают лимиты, но не настаивают
на их настройке

22. Формулируем задачу
• Хотим распределить ресурсы между сервисами
• Нагрузка на соседние сервисы не должна влиять
• Хотим понимать, сколько ресурсов осталось, когда пора
добавлять
• Не хотим, чтобы ресурсы простаивали

23. Cgroups — control groups
• Начали разработку в google (2006)
• Первый merge в ядро 2.6.24 (2008)
• Cобираем процессы в группу, на неё навешиваем ограничения
ресурсов
• Все потомки автоматически включаются в группу родителя
• Запущенный docker* контейнер = всегда отдельная cgroup, даже если
ресурсы не ограничивали

24. Cgroups: CPU
• Shares: пропорции выделения процессорного времени
• Quota: жесткое ограничение количества процессорного времени
в единицу реального времени
• Cpusets: привязка процессов к конкретным cpu (+NUMA)

25. Попробуем разобраться на тестах
• Тестовый сервер 8 ядер/32Gb (hyper-threading выключен для
простоты)
• Сервис: 50:50% cpu:wait
• Нагрузку подает yandex.tank
• Задержки будем оценивать по гистограмме

26. Отправная точка
docker run -d --name service1 --net host -e HTTP_PORT=8080 httpservice
docker run -d --name service2 --net host -e HTTP_PORT=8081 httpservice

28. perf stat -p <pid> sleep 10
Медленно Быстро

29. perf stat -p 28115 sleep 10
Медленно Быстро
task-clock (msec) 17193.092339
1.719 CPUs utilized
8378.433503
0.838 CPUs utilized
cycles 21,937,352,637
1.276 GHz
21,319,855,536
2.545 GHz

30. perf stat -p 28115 sleep 10
Медленно Быстро
task-clock (msec) 17193.092339
1.719 CPUs utilized
8378.433503
0.838 CPUs utilized
cycles 21,937,352,637
1.276 GHz
21,319,855,536
2.545 GHz

31. Чиним
for i in `seq 0 7`
do
echo “performance” > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor
done

33. Что это было?
• По факту у нас были cpu shares 1024:1024
• Процессы не ограничены в процессорном времени пока нет
конкуренции
• Пока на service2 не будет нагрузки, service1 сможет
утилизировать больше ресурсов
• Если мы хотим стабильности, нам нужен стабильный худший
случай

34. CPU quotes
• period – реальное время
• quota – сколько процессорного времени можно потратить за
period
• Если хотим отрезать 2 ядра: quota = 2 * period
• Если процесс потратил quota, процессорное время ему не
выделяется (throttling), пока не кончится текущий period

35. Пробуем квоты
2ms cpu за 1ms = 2 ядра
docker run -d --name service1 --cpu-period=1000 --cpu-quota=2000 …

37. Стабильность с квотами
• Знаем предел производительности сервиса при квоте
• Можем посчитать в % утилизацию cpu сервисом:
• Факт: /sys/fs/cgroup/cpu/docker/<id>/cpuacct.usage
• Лимит: period/quota
• Триггер: [service1] cpu usage > 90%
• Если уперлись в quota — растёт nr_throttled и throttled_time из
• /sys/fs/cgroup/cpu/docker/<id>/cpu.stat

38. Распределяем ресурсы
• Делим машину на ”слоты” без overselling для latency-sensitive сервисов
(quota)
• Если готовимся к повышению нагрузки – запускаем каждого сервиса
столько, чтобы потребление было < N %
• Если есть умный оркестратор и желание – делаем это динамически
• Количество свободных слотов – наш запас, держим его на
комфортном уровне

40. Добиваем машины фоновой нагрузкой
• Слотам проставляем максимальный --cpu-shares
• Свободное процессорное время “отдаем” (ставим минимальный
--cpu-shares) некритичным сервисам: второстепенные сервисы,
обработка фоновых задач, аналитика, …

41. Тестируем
docker run --name service1
--cpu-shares=262144 --cpu-period=1000 --cpu-quota=2000 ...
docker run --name=stress1
--rm -it --cpu-shares=2
progrium/stress --cpu 12 --timeout 300s

43. CFS — completely fair scheduler
• Достаточно дискретен, процессорное время выделяется слотами
(slices)
• Можно крутить разные ручки: sysctl –a |grep kernel.sched_
• Я все тестировал на дефолтовых настройках и крутить не было
желания

44. CFS — completely fair scheduler
• Достаточно дискретен, процессорное время выделяется слотами
(slices)
• Можно крутить разные ручки: sysctl –a |grep kernel.sched_
• Я все тестировал на дефолтовых настройках и крутить не было
желания
• Мы поставили квоту 2ms/1ms, это уменьшило размер слота,
который может потратить наш сервис

45. Пробуем 20ms/10ms
• 2ms / 1ms мало
• 200ms / 100ms много
• 8 ядер: 200ms сможем потратить за 200/8 = wall 50ms
• В пределе будет throttling 50ms – слишком ощутимая задержка

46. Пробуем 20ms/10ms
docker run --name service1
--cpu-shares=262144 --cpu-period=10000 --cpu-quota=20000 ...
docker run --name=stress1
--rm -it --cpu-shares=2
progrium/stress --cpu 12 --timeout 300s

48. CPU: результаты
• Мы догрузили машину до 100% cpu usage, но время ответа
сервиса осталось на приемлемом уровне
• Нужно тестировать и подбирать параметры
• “Слоты” + фоновая нагрузка – рабочая модель распределения
ресурсов

49. Cgroups: memory
• Можем ограничить размер суммарной памяти, используемой
группой
• Получаем статистику
/sys/fs/cgroup/memory/<cgroup>/memory.stat

50. Cgroups: memory
• Можем ограничить размер суммарной памяти, используемой
группой
• Получаем статистику
/sys/fs/cgroup/memory/<cgroup>/memory.stat
• Самое крутое — можем узнать, кто сколько page cache съел
(засчитывается той группе, которая первая использовала
страницу)

51. Зачем ограничивать память?
• Сервис с утечкой может съесть всю память, а OOM killer может
прибить не его, а соседа
• Сервис с утечкой или активно читающий с диска может вымыть
кэш соседнего сервиса

52. Тестируем
Создаем файл 20Gb:
dd if=/dev/zero of=datafile count=20024 bs=1048576 # 20GB
Запускаем сервис:
docker run -d --name service1 .. DATAFILE_PATH=/datadir/datafile …
На каждый запрос читаем N байт со случайного offset

53. Тестируем
Прогреваем кэш (от cgroup сервиса)
cgexec -g memory:docker/<id> cat datafile > /dev/null
Проверяем, что файл в кэше:
pcstat /datadir/datafile

54. Проверяем, что кэш засчитался сервису

55. Вымывание кэша
• docker run --rm -ti --name service2 ubuntu cat datafile1 > /dev/null

57. Ограничиваем
docker run --rm -ti --memory=1G
--name service2 ubuntu cat datafile1 > /dev/null

59. Memory: результаты
• Ограничения работают
• Отличный способ не вымывать кэш у критичных сервисов (можно
использовать при обслуживании)
• Метрики cgroups:mem более детальны, чем метрики процессов
(cache usage)

60. Cgroups: blkio
• Все по аналогии с CPU
• Есть возможность задать вес (приоритет)
• Лимиты по iops/traffic на чтение/запись
• Можно настроить для конкретных дисков

61. Подход
• Поступим так же, как с CPU
• Отрезаем квоту по iops критичным сервисам, но ставим большой
приоритет
• Фоновые процессы запускаем с минимальным приоритетом

62. Лимиты
• В случае с CPU есть понятный предел – 100% времени всех ядер
• Нагрузим диск и посмотрим примерный предел по iops на чтение

64. Ограничим 100 iops на чтение
docker run -d --name service1
-m 10M --device-read-iops /dev/sda:100 …

66. Мониторинг
• Знаем лимит каждой cgroup для каждого device
• Можем снять факт из
• /sys/fs/cgroup/blkio/<id>/blkio.throttle.io_serviced
• Триггер вида:
• [service1] /dev/sda read iops > 90%

67. Нагрузим диск фоновой задачей
docker run -d --name service1 -m 10M …
docker run -d --name service2 -m 10M ubuntu cat datafile1 > /dev/null

69. Настраиваем приоритеты
docker run -d --name service1 -m 10M
--blkio-weight 1000
docker run -d --name service2 -m 10M
--blkio-weight 10 ubuntu cat datafile1 > /dev/null

71. IO scheduler
• cfq у меня настроить не получилось, но там есть, что покрутить
• Говорят, что deadline лучше подходит, когда важно latency
• echo deadline > /sys/block/sda/queue/scheduler
• echo 1 > /sys/block/sda/queue/iosched/fifo_batch
• echo 250 > /sys/block/sda/queue/iosched/read_expire

73. Blkio: результаты
• Лимиты работают достаточно точно
• Работа приоритетов сильно зависит от планировщика io и его
настроек
• Можно добиться приемлемого уровня latency

74. Выводы (филосовские)
• DevOps придумали разработчики, чтобы админы больше
работали :)

75. Выводы (филосовские)
• DevOps придумали разработчики, чтобы админы больше
работали :)
• Работы еще много!

76. Выводы (технические)
• В linux все достаточно хорошо с планировщиками (cpu, io), можно
добиться приемлемых показателей

77. Выводы (технические)
• В linux все достаточно хорошо с планировщиками (cpu, io), можно
добиться приемлемых показателей
• Есть достаточно много экспериментальных патчей с более
точными* планировщиками (нужно следить)

78. Выводы (главные)
• Бенчмаркать сложно, долго, муторно, но очень интересно

79. Выводы (главные)
• Бенчмаркать сложно, долго, муторно, но очень интересно
• Perf очень крутой :)

80. Выводы (главные)
• Бенчмаркать сложно, долго, муторно, но очень интересно
• Perf очень крутой :)
• Если очень захотеть, можно запускать hadoop рядом с боевой БД
в prime time

81. Выводы (главные)
• Бенчмаркать сложно, долго, муторно, но очень интересно
• Perf очень крутой :)
• Если очень захотеть, можно запускать hadoop рядом с боевой БД
в prime time
• Доклад был не про docker :)

82. Вопросы?
Николай Сивко
nsv@okmeter.io