Как Dropbox пришёл к использованию Go
Тэмми цитирует статью Роба Пайка «Go в компании Google: языковой дизайн в службе разработки ПО» от 2012 года, поскольку она в целом хорошо передаёт, почему Go хорошо работает и в Dropbox:
«Go — эффективный, масштабируемый и производительный язык. Некоторые программисты получают удовольствие от работы с ним; другие находят его прозаическим, даже скучным. В этой статье мы расскажем, почему все эти позиции не противоречат друг другу. Go спроектирован для решения проблем, возникающих в софтверной разработке в Google, что привело к созданию языка, который не является прорывным с исследовательской точки зрения, тем не менее это прекрасный инструмент для разработки крупных софтверных проектов». — Роб Пайк, 2012
Масштаб Dropbox впечатляет:
- Более 500 млн пользователей
- 200 000 бизнес-пользователей
- 500 петабайт пользовательских данных
- Многоэкзабайтная система хранения Go
В результате, Dropbox многое требует от своих систем, языков и разработчиков. Ведущие принципы и требования следующие:
- Создавать надёжные системы
- Создавать безопасные системы
- Объединять надёжность и безопасность в изначальной архитектуре
- Надёжность 99,9999999999% (двенадцать девяток)
- Доступность 99,99%
Состояние Go в Dropbox
Сегодня бoльшая часть инфраструктуры Dropbox написана на Go. В частности:
- У сервера репозиториев Go — 150 уникальных контрибуторов (из 500 разработчиков в компании)
- Более 15 групп создают и поддерживают работу сервисов Go в Dropbox
- По всей компании в Dropbox написано 1,3 млн строк на Go
некоторые из ключевых систем, написанных на Go:
- RAT: ограничение скорости и дросселирование (приглушение) трафика
- HAT: замена memcached
- AFS: файловая система для замены глобального Zookeeper
- Edgestore: распределённая база данных
- Bolt: для сообщений
- DBmanager: для автоматизации и мониторинга более 6000 баз данных Dropbox
- Jetstream, Telescope, маршрутизация блоков и многое другое
Многие из них представляют собой преемников предыдущих систем не на Go.
Как Dropbox начал использовать Go?
Тэмми поделилась несколькими историями, как Dropbox естественным путём перешёл на Go.
Прототип ограничителя скорости на Go с хакерской недели
До хакерской недели, которая случилась однажды, разработчики Dropbox внедряли ограничение скорости и дросселирование отдельно для каждого сервиса, где требовалось. Но для этой хакерской недели один инженер Dropbox решил создать единую реализацию этих функций. Так родился RAT (Rate limiting And Throttling).
Первый прототип RAT был создан за четыре дня и показан на пятый. В течение нескольких недель после создания RAT информация о нём распространилась по фирме. Другой инженер Dropbox написал в группу Тэмми предложение посмотреть, как они могут использовать RAT из проекта Python. Интеграция прошла плавно, сервис был принят естественным путём — и вскоре RAT начал приносить пользу. Теперь несколько команд в Dropbox используют RAT.
Dbmanager
В Dropbox более 6000 баз данных, и такая большая система требует автоматизации и мониторинга. В любой данный момент времени проходит репликация баз данных, сбои, перенос из обычной реплики в основную и т. д.
Для управления этим процессом инженер Dropbox разработал Dbmanager — UI в вебе для быстрого просмотра состояния всех более чем 6000 баз данных. Информация о статусе также передаётся в другие системы.
Обновление версий Go в Dropbox
Имея сотни разработчиков, Dropbox аккуратно координирует обновление основных версий Go. Тэмми не упомянула о каких-то определённых проблемах, что указывает на плавный процесс!
Некоторые интересные факты:
- Dropbox недавно закончил миграцию сервисов продакшна с Go 1.5 на 1.6.
- Для отслеживания процесса обновления они создали простой документ Dropbox Paper, где владелец каждого сервиса отчитывается о прогрессе и запрашивает помощь при необходимости.
- Dropbox пропускает версию Go 1.7 и сразу перейдёт на Go 1.8, когда миграция на Go 1.6 полностью завершится (включая сервисы не в продакшне).
Как инженеры Dropbox осваивают Go
Каждый инженер Dropbox проходит через один и тот же строгий процесс освоения Go, который состоит из следующих этапов:
- Чтение инфраструктурной топологии, руководства по стилю Go и руководства по стилю Protobuf
- Строгие, но дружелюбные анализы кода
- Создание маленького приложения (в App Store) на Go
- Изучение Bazel для сборки и тестирования кода Go
Для опытного программиста процесс занимает около недели.
Что прошло гладко с внедрением Go в компании Dropbox? А что нет?
В целом, использование Go в Dropbox’s было очень удачным.
- На Go легко показать высокую производительность труда.
- На Go легко писать и использовать сервисы. (И людям нравится и то, и другое!)
- Стандартная библиотека очень хороша.
- Инструменты отладки (в основном!) работают хорошо.
Здесь один из важных фактов состоит в том, что в Dropbox нет попыток переписать сервисы Go на других языках. Это знак, что люди в целом довольны. (Тэмми выдала интригующую деталь: в Dropbox немного используют Rust. Но его не считают заменой для Go).
Что сложного Dropbox нашёл в Go?
Наибольшей сложностью Тэмми назвала работу с состоянием гонки.
- Состояние гонки данных — самый трудный баг для отладки, для обнаружения, исправления и т. д.
- Несколько инженеров Dropbox особенно хороши в обнаружении таких багов, а остальные опираются на их опыт.
- Детектор состояния гонки в Go не всегда помогает. Нужно понимать, когда он беспомощен.
- Важно аккуратно проектировать программы Go, если требуется одновременный доступ к данным.
Dropbox набирает инженеров, которые заботятся о надёжности и долговечности данных, так что им это было легко понять (хотя одновременный доступ постоянно и везде труден).
Комментарии (28)
arkada38
08.08.2017 08:01Несколько инженеров особенно хорошо понимают как справляться с главной сложностью при работе с языком Go.
И есть несколько инженеров, которые пишут на Rust и не знают проблемы с гонкой данных.
Было бы интересно узнать какие главные сложности у инженеров Dropbox при работе с языком Rust, если его используют совсем немного.
Nakosika
08.08.2017 10:13+1Не не везде с гонками все так плохо, есть Кложур, к примеру — там транзакционная память и иммутабельность. Хотя синтаксис подкачал, читать его — это специальный скилл, я до сих пор не освоил. Вот бы кложур, но со статической типизацией и пайтоновским синтаксисом...
rraderio
09.08.2017 16:38А почему с пайтоновским синтаксисом? Чем он лучше?
Nakosika
09.08.2017 17:56-2Скобочек меньше писать. :)
Пайтоновский синтаксис — это баланс, при котором код читабелен, может иметь статическую типизацию и при этом все еще можно писать настоящие лисповые макросы (и при этом не вывихивать мозг как в скале и без больших ограничений как в расте).
Более сложный синтаксис не всунуть, там есть два ограничения — 1) весь синтаксис должен быть разобран ДО поступления в макрос 2) парсер не должен знать структуры программы, так как макрос может сгенерировать любую программу.
Лисп — самый простой способ сделать парсер максимально тупым, парсер на основе отступов — следующий уровень, а если исхитриться то можно и операторы в парсер засунуть. Я как-то интерпретатор писал такого добра, на уровне хобби.
KirEv
08.08.2017 10:35+6Пытаюсь понять, что только что прочитал…
Эта статья — перевод статьи Tammy Butow? Или вольное мыслеизяснение после прочтения статьи\статей Tammy Butow?
Так почему Dropbox использует Go? В чем профит, ведь до Go Dropbox использовал что-то другое, или нет?
Странная статья…
Мне очень нравится Go, но охота больше видеть примеры конкретных применений, архитектурные решения и т.п., а не «Мы пишем на языке Х потому-что нам нравится на нем писать»…
Caravus
08.08.2017 10:59Ну для конкретных примеров — можно пойти и глянуть код :) Например — вся стандартная библиотека golang (насколько я понимаю) написана на самом golang. Ещё — docker/moby, kubernetes, helm, десятки репозиториев. Я последнее время тоже стал замечать что хабр
не тортпревращается в помойку.KirEv
08.08.2017 11:16Видел здесь несколько замечательных статей посвященных Go, причем очень хороших (как по мне), одна из любимых =) а на офф.сайте го — вообще все в деталях
Информации на самом деле много, но увольте в случае расхождения громкого оглавления статьи с содержанием
Подожду на первоисточник сабжа.
M0sTH8
09.08.2017 03:18Это перевод вольной записи слов с доклада Тэмми с конференции по Go. Вот оригниальный доклад https://www.youtube.com/watch?v=5doOcaMXx08
Вот больше про выбор Go в dropbox https://www.youtube.com/watch?v=EWsXbsUBm-M
lega
08.08.2017 14:47Раньше там была бoльшая часть на питоне, даже Гвидо к ним перешел, а сейчас, значит, после безуспешного «ускорения» питона, они переходят на го… Что будет с Гвидо?
acmnu
08.08.2017 14:55При этом метания у них начались именно с момента выхода Python 3. Врятли он им так сильно мешал, но похоже это заставило их задуматься над выбором языка. Помнится я видел последовательно два или три видео, где они говорят, что переходят, то на Go, то на JVM (не помню какой язык), то клянутся в любви к Python.
lega
08.08.2017 17:09+1Может момент и совпал, но это не причина. Я думаю, наиболее верятно им потребовался более производительный язык, т.к. при их масштабе оно чувствительно, по этой же причине они создали pyston.
sheknitrtch
08.08.2017 17:36Dropbox создала Pyston и забросила его разработку :(
Врядли Pyston будет дальше развиваться.lega
08.08.2017 21:57Да, с самого старта затея выглядела не очень, т.к. они пошли по пути от которого pypy отказался.
acmnu
08.08.2017 18:12+1Ну а как же матра питонистов, что те немногие узкие места надо переписывать на C? Вроде действенный подход. Да, все равно останется беда с математической многопоточностью (GIL и вот это вот все), но в целом то язык неплох.
Я думаю дело не в технических характеристиках, а в политике: просто появилось много людей желающих попробовать что-то новое. А дальше одно за другое: "Вы слышали, вот те ребята с 15го этажа переписали приложуху X на go и получили прирост в стопицот! Давайте и мы тоже так сделаем!"
lega
08.08.2017 22:11Ну а как же матра питонистов, что те немногие узкие места надо переписывать на C?
Так оно, но в dropbox очень много io, а го для этого самое то, в итоге они начали переписывать узкие места не на C, а на go, что выглядит разумно.
grossws
08.08.2017 22:16Ну а где они хотят мучить cpu-bound и хотят достаточных гарантий — они начали использовать rust. Нормальный инженерный подход, выбирают язык/экосистему под конкретную задачу.
evocatus
08.08.2017 23:58-1Легче переписать на Go (он больше похож на Python), чем добавлять код на C.
Hedgar2018
Надеемся, что скоро все догадаются использовать на серверах компилируемые языки. Или не надеемся, конкуренция же :)
wert_lex
Про джавовый HotSpot и другие интересные вещи, которые возможны только в рантайме, уже можно рассказывать?
rraderio
Да, что можно в рантайме?
wert_lex
В рантайме можно спекулятивные оптимизации на основе статистики использования, которые нельзя в compile time.
Вот тут есть довольно общий список: https://wiki.openjdk.java.net/display/HotSpot/PerformanceTechniques
А вот тут пара слов про Profile: https://wiki.openjdk.java.net/display/HotSpot/PerformanceTechniques
Если не углубляться совсем в дебри, то на основе статистики поведения метода в runtime, виртуальная машина может его не только скомпилировать в машинный код, но и например, выкинуть какие-нибудь проверки аргументов, ветки условий, итд.
Более того, эти оптимизации занимают некоторое время, и требуют определенного способа использования приложения. Поэтому иногда для того, чтобы свежезапущенное приложение было молодцом с самого начала, в него профиль оптимизации можно загрузить. Вот так никогда не делал, но на хабре где-то не так давно была статья по этому поводу.
grossws
Строго говоря, в некоторые компилируемые языки уже некоторое время назад вкрутили PGO. Например, у gcc есть набор флагов для сборки приложения для сборки профиля и набор флагов для компиляции с учётом собранной статистики.
Конечно, это не настолько гибко, как сборка в рантайме и deopt и повторный opt при изменении нагрузки.
SirEdvin
Ведь все проблемы программистов от скриптовых языков) И от дженериков.