Pull to refresh
177.54
JUG Ru Group
Конференции для Senior-разработчиков

«Есть плюсы как для админов, так и для разработчиков»: Олег Анастасьев про облако Одноклассников

Reading time 7 min
Views 7.4K


Публичными облаками давно никого не удивить, и про них вряд ли требуется что-то объяснять. С частными другая история: все знают об их существовании, но далеко не всем доводилось иметь с ними дело, так что чужой опыт интереснее.

Поэтому переход Одноклассников от подхода «каждый сервер занимается своей задачей» к облачному подходу «единый пул ресурсов распределяется по необходимости» вызвал у нас вопросы. Мигрировать такой большой проект с 11-летней историей на новую систему непросто — что именно побудило пойти на эти трудозатраты? Чем использование облака в Одноклассниках отличается от использования публичных сервисов? Почему проекту не подходят стандартные решения вроде Mesos и Kubernetes, и было сделано собственное one-cloud?

На эти и другие вопросы нам ответил ведущий разработчик Одноклассников Олег Анастасьев, уже знакомый читателям Хабра.

— Мы помним, что у вас есть «Правило большого З»: любое техническое действие должно отвечать на вопрос «Зачем?». Так вот, зачем вам понадобилось облако?

— Одна из причин в следующем. Оперирование напрямую с железками — это по большей части прерогатива системных администраторов, или system reliability engineers, называй их как хочешь. Мы хотим двигать разработчиков ближе к продакшену. А чтобы это сделать, надо дать им способ общаться с продакшеном таким способом, чтобы избавить людей от ненужной бюрократии, при этом не дав ничего повалить. И это один из способов решения задачи.

Другая причина — возможность обеспечить более плотную загрузку серверов, повысив утилизацию дата-центров.

— Обычно про облака и плотную загрузку серверов говорят в таком контексте: «если у стартапа сегодня тысяча пользователей, а завтра миллион, с облаком можно быстро отмасштабироваться и использовать необходимое количество ресурсов, не переплачивая за неиспользуемое».

Но Одноклассники-то уже не стартап, у вас аудитория не может внезапно удвоиться, её рост медленнее и предсказуемее. Почему тогда без облака не обеспечить плотную загрузку серверов, выделяя их на каждую задачу ровно столько, сколько требуется?


— Здесь есть несколько соображений. Во-первых, да, аудитория более-менее стабильная, но это относится только к количеству пользователей: нагрузка растёт значительно быстрее. Сейчас в связи с тем, что очень быстро увеличивается потребление видео (в частности, лайв-трансляций), с точки зрения нагрузки мы растём в два раза за год — это при том, что у нас и так достаточно большая нагрузка.

Во-вторых, хотя Одноклассники в целом существуют давно, в них запускается довольно много различных новых продуктов: те же трансляции появились относительно недавно, много новых продуктов для администраторов групп, частных объявлений, музыки; наконец, мессенджер ТамТам. Про такие продукты заранее сложно оценить, насколько успешными они окажутся, как быстро их понадобится масштабировать. И если каждый сервер занимается своей задачей, неочевидно, сколько серверов требуется выделять. Это та же стартап-проблематика.

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

— С плюсами стало понятнее. А пришлось ли ради них соглашаться на минусы? Скажем, причиной разделения задач между серверами вы ранее называли изоляцию отказов. Не пострадала ли отказоустойчивость от того, что теперь этого разделения нет?

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

— Почему потребность в облачном подходе ощутили именно сейчас? Что-то изменилось вообще в индустрии, или конкретно в Одноклассниках?

— Я думаю, что тут сошлись три фактора. В мире стали возникать новые более-менее опенсорсные системы управления инфраструктурой, и из подобных широко известных компонентов мы в нашей новой системе используем Docker. При планировании расширения инфраструктуры мы поняли, что место в существующих дата-центрах скоро закончится, и нам надо либо строить новый, либо уплотняться в существующих. И у нас освободились ресурсы, чтобы эту задачу наконец решить.

— В случае с проектом масштаба Одноклассников сложность не только в том, чтобы сделать новую систему, но и в том, чтобы перейти на неё. Насколько для вас трудозатратна такая миграция? Например, по сравнению с ситуацией, когда вы что-то масштабно меняете на сайте для пользователей?

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

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


А с другой стороны, тут требуется и поддержка со стороны разработчиков, они должны что-то менять в коде, делать контейнеры своих приложений (учтём, что всего у нас почти 700 различных микросервисов)… В общем, это большой процесс. Первая версия облака у нас была написана и запущена далеко не один месяц назад, но миграция систем в облако всё ещё идёт.

— А насколько легко добиться этой «поддержки со стороны разработчиков» — не приходится ли сталкиваться с «нам тут фичи пилить надо, не хочется отвлекаться на инфраструктурные вопросы, лучше мы в облако попозже перейдём»?

— У меня есть чёткое убеждение, что если люди сами не хотят пользоваться новой системой, если она не даёт им каких-то плюсов по сравнению со старой, то их туда палкой не загонишь. И у нового облака есть плюсы как для админов, так и для разработчиков.

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

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

— Многие крупные компании по всему миру делают свои облака. А почему они не готовы просто пользоваться условным Amazon AWS — потому что своё получается дешевле, потому что переживают о безопасности, или потому что хотят большой уровень контроля и доступа?

— Есть и те, кто идут в Amazon — так делают Netflix, пионеры облачных вычислений. Но они там поверх AWS запускают свою собственную систему автоматического управления инфраструктурой, они уже дошли до того, что им удобнее иметь свою надстройку над AWS.

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

— А для тех сотрудников Одноклассников, которые будут пользоваться вашим облаком, чем это будет отличаться от использования того же AWS?

— Amazon — немного другая система. Она более старая: хотя они пытаются идти в ногу со временем, делать вещи вроде AWS Lambda, использовать современный софт, там много легаси. И у нас это по-другому выглядит, потому что нет этого легаси.

Кроме того, AWS — универсальный продукт, который подходит для хостинга самых разных вещей. Как и любой универсальный продукт, он не очень удобен в контексте конкретной задачи, там много всяких штук, которые нам не нужны и только путают.

А поскольку мы делаем конкретный продукт для нас, нам работать с ним проще, управление понятнее, и его можно естественным образом положить на то, как у нас принято делать какие-то штуки. И так не только с хостингом, но и с другими составляющими облака, где тоже уходили от универсальных решений к собственным — например, one-cloud.

— Конкретно про one-cloud вы осенью собираетесь рассказывать подробно на наших конференциях Joker и DevOops, а пока тогда расскажите кратко: что это вообще?

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

— А использовать в этом случае популярные опенсорсные решения вроде Kubernetes не стали тоже из-за их универсальности?

— Да. Мы рассматривали и Kubernetes, и Mesos. Было ясно, что и первый, и второй в своём обычном виде не ложатся на то, что мы хотим. Мы могли бы дотянуть и тот, и другой до того, что нам необходимо. Но мы оценили работу, которую нужно было бы проделать, и работу на то, чтобы написать своё, и оказалось, что объём работы приблизительно одинаковый. В итоге решили написать своё, которое получится более удобным и понятным, более надёжным, более заточенным под нас, под наши требования и инфраструктуру.

— Поскольку про one-cloud будете рассказывать и на Java-конференции, и на DevOps-конференции, хочется узнать: эти доклады будут различаться?

— Да. На DevOops доклад будет в большей степени про процессы: как построить DevOps-процессы, когда у вас есть облака или своя система управления дата-центром, и как при этом не потерять отказоустойчивость. И об обеспечении изоляции задач на одной машине. Поскольку для такой большой распределённой системы очень важна отказоустойчивость, большая часть доклада будет именно о том, как она обеспечивается.

На Joker планируется сделать меньше про процессы обеспечения отказоустойчивости, а больше про то, как облако устроено внутри, что отказоустойчивость с этой стороны обеспечивает. Кроме того, есть идея рассказать больше об эксплуатации Java-приложений в контейнерах. Потому что наше облако — наверное, единственное, у которого сто процентов запускаемых задач написаны на языке Java, и есть опыт, полезный тем, кто на Java пишет.

— В случае с Joker ваш предварительный план доклада состоит из пунктов «содом», «гоморра» и «кишки». Там ожидать хардкора?

— Честно говоря, мне сложно судить, потому что у меня как у одного из авторов one-cloud искажённое восприятие. Мне вообще кажется, что всё очень просто, но другие люди не всегда оказываются с этим согласны. Мне самому интересно, что получится в итоге.



Обе упомянутых конференции, DevOops и Joker, состоятся осенью в Санкт-Петербурге: DevOops 20 октября, а Joker — 3-4 ноября. На сайтах обеих можно увидеть, что ещё там будет, помимо доклада Олега — и на сайтах обеих уже можно приобрести билеты.
Tags:
Hubs:
+21
Comments 6
Comments Comments 6

Articles

Information

Website
jugru.org
Registered
Founded
Employees
51–100 employees
Location
Россия
Representative
Алексей Федоров