title: Алекс Сюй, «System Design. Подготовка к сложному интервью» (Vol. 1, рус. изд.) — глава 15: Проектирование Google Drive source: materials/System Design. Подготовка к сложному интервью.pdf, стр. 273–296 конспект: TASK-45.38, извлечено pymupdf 2026-09-17; ниже полный «грязный» текст главы + выжимка статус: выжимка и перенос в knowledge-base.md / methodology.md / classic-designs.md — см. _map.md

Глава 15. Проектирование Google Drive

Выжимка

Облачное файловое хранилище + синхронизация: загрузка/скачивание/синхронизация, история версий, шеринг, уведомления. НФТ: надёжность (потеря файлов недопустима), быстрая синхронизация, экономия трафика, масштабируемость, HA. Оценки: 50 млн юзеров × 10 ГБ = 500 ПБ; upload 240 QPS (пик 480).

Эволюция (педагогичный ход главы): один сервер (Apache + MySQL + диск с пространствами имён) → шардирование по user_id % 4 → S3 (репликация внутри региона и между регионами; бакеты) + LB + вынесенные веб-серверы и БД метаданных.

Блочная модель (ядро): файл → блоки (у Dropbox 4 МБ) → сжатие (по типу файла) → шифрование → S3; в БД метаданных — блоки с хешами. Дельта-синхронизация: передаются только изменённые блоки; дедупликация — одинаковые хеши = один блок.

Строгая согласованность: недопустимо, чтобы файл выглядел по-разному на разных клиентах → реплики синхронны с мастером, кэш инвалидируется при записи; выбор — реляционная БД (ACID) для метаданных (в NoSQL ACID пришлось бы реализовывать вручную). Таблицы: user, device (push_id), namespace, file, file_version (immutable, история), block.

Конфликты: побеждает обработанная первой версия; второму клиенту отдаются обе версии (его локальная + серверная) — слияние/выбор вручную.

Уведомления об изменениях: сервис уведомлений (publisher–subscriber); выбран длинный HTTP-опрос (как Dropbox): взаимодействие одностороннее (сервер→клиент), уведомления редкие — WebSocket избыточен; оффлайн-клиент → очередь автономной архивации, раздача при подключении.

Экономия места: дедуп блоков, лимит версий + хранение «важных», холодное хранилище (Glacier) для неактивного. Обработка сбоев по каждому узлу: LB — пара с heartbeat; блочный сервер — подхват заданий; S3 — мультирегион; API — stateless; БД — master/slave failover; сервис уведомлений — переподключение клиентов.

Перенос: KB §14.10 (блочная модель, дельта-синхронизация, конфликты, long polling выбор), classic-designs — сверка логики уведомлений.

Полный текст (грязная выгрузка)

15 ПРОЕКТИРОВАНИЕ GOOGLE DRIVE В последние годы большой популярностью пользуются такие облачные сервисы хранения данных, как Google Drive, Dropbox, Microsoft OneDrive и Apple iCloud. В этой главе вам предлагается спроектировать Google Drive. Прежде чем переходить к проектированию, давайте немного подумаем о том, что собой представляет эта система. Google Drive — это файловое хранилище и сервис синхронизации, который позволяет хранить до­ кументы, фотографии, видео и другие файлы в облаке. Доступ к своим файлам можно осуществлять с любого компьютера, смартфона и план­ шета. Вы можете легко делиться этими файлами с друзьями, членами семьи и коллегами [1]. На рис. 15.1 и 15.2 показаны браузерная и, соот­ ветственно, мобильная версии Google Drive. Рис. 15.1

274      ГЛАВА 15 Рис. 15.2 ШАГ 1: ПОНЯТЬ ЗАДАЧУ И ОПРЕДЕЛИТЬ МАСШТАБ РЕШЕНИЯ Проектирование Google Drive — масштабный проект, поэтому сначала необходимо определиться с объемом работ. Кандидат: «Какие функции самые важные?» Интервьюер: «Загрузка, скачивание и синхронизация файлов, а также уведомления». Кандидат: «Это приложение должно быть мобильным, браузерным или и тем и другим?» Интервьюер: «И тем и другим». Кандидат: «Какие форматы файлов поддерживаются?» Интервьюер: «Любые типы файлов». Кандидат: «Должны ли файлы шифроваться?»

Проектирование Google Drive      275 Интервьюер: «Да, файлы в хранилище должны быть зашифрованы». Кандидат: «Ограничен ли размер файлов?» Интервьюер: «Да, размер файла не должен превышать 10 Гб». Кандидат: «Сколько пользователей у этого продукта?» Интервьюер: «10 миллионов DAU». В этой главе мы сосредоточимся на следующих возможностях.

Добавление файлов. Самый простой способ добавить файл — это перетащить его в Google Drive.

Скачивание файлов.

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

Просмотр истории изменений файлов.

Обмен файлами с друзьями, семьей и коллегами.

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

Редактирование и совместная работа над документами Google Docs. Google Docs позволяет редактировать один и тот же документ сразу нескольким людям. Эта функция не входит в нашу архитектуру. Помимо уточнения требований необходимо как следует понять нефункцио­нальные характеристики системы.

Надежность. Чрезвычайно важна для систем хранения. Потеря данных недопустима.

Быстрая синхронизация. Если файлы синхронизируются слиш­ ком долго, пользователи теряют терпение и отказываются от продукта.

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

276      ГЛАВА 15

Масштабируемость. Система должна справляться с большими объемами трафика.

Высокая доступность. Пользователи не должны терять доступ к системе, даже если некоторые из ее серверов выходят из строя, демонстрируют низкую производительность или испытывают проблемы с сетью. Приблизительные оценки

Предположим, что система имеет 50 миллионов зарегистрирован­ ных пользователей и 10 миллионов DAU.

Каждый пользователь получает 10 Гб свободного места.

Допустим, пользователи загружают в среднем по 2 файла в день. Средний размер файла составляет 500 Кб.

Чтение и запись имеют равное соотношение.

Общий размер выделенного пространства: 50 миллионов * 10 Гб = = 500 петабайтов.

QPS для API загрузки: 10 миллионов * 2 загрузки / 24 часа / 3600 секунд = ~240.

Пиковый показатель QPS: QPS * 2 = 480. ШАГ 2: ПРЕДЛОЖИТЬ ОБЩЕЕ РЕШЕНИЕ И ПОЛУЧИТЬ СОГЛАСИЕ Вместо того чтобы демонстрировать общую диаграмму архитектуры с са­ мого начала, мы пойдем другим путем. Начнем с простого: разместим все на одном сервере. Затем постепенно расширим систему для поддержки миллионов пользователей. Это упражнение позволит вам освежить зна­ ния некоторых важных тем, рассмотренных в книге. Изначально наша конфигурация будет состоять из одного сервера и иметь такой вид:

веб-сервер для загрузки и скачивания файлов;

Проектирование Google Drive      277

БД для хранения таких метаданных, как информация о пользова­ телях, аутентификации, файлы и т. д.;

система хранения файлов. Мы выделим для нее 1 Тб. Мы потратим несколько часов на настройку веб-сервера Apache и базы данных MySQL. Загружаемые файлы будут храниться в директории drive/, внутри которой находится ряд других директорий, которые на­ зываются пространствами имен. Каждое пространство имен содержит все файлы, загруженные конкретным пользователем. Копии файлов на сервере имеют те же имена, что и оригиналы. Для однозначной иденти­ фикации файла или папки достаточно объединить пространство имен и относительный путь. На рис. 15.3 показан пример директории drive/ (слева) и ее развернутое представление (справа). expand Рис. 15.3 API Нам в первую очередь нужно три API: для загрузки, скачивания и полу­ чения истории изменений файлов. 1. Загрузка файлов в Google Drive. Поддерживаются два типа загрузки:

простая загрузка. Предназначена для маленьких файлов;

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

278      ГЛАВА 15 Пример API для возобновляемой загрузки: https://api.example.com/files/ upload?uploadType=resumable. Параметры:

uploadType=resumable;

data: локальный файл, который нужно загрузить. Процесс возобновления загрузки состоит из следующих трех шагов [2]:

отправить начальный запрос для получения возобновляемого URL-адреса;

загрузить данные и отследить состояние загрузки;

возобновить загрузки в случае прерывания. 2. Скачивание файла из Google Drive. Пример API: https://api.example.com/files/download. Параметры:

path: путь к скачиваемому файлу. Пример: { "path": "/recipes/soup/best_soup.txt" } 3. Получение истории изменений файла. Пример API: https://api.example.com/files/list_revisions. Параметры:

path: путь к файлу, историю изменений которого вы хотите полу­ чить;

limit: максимальное количество версий файла, которые нужно вернуть. Пример: { "path": "/recipes/soup/best_soup.txt", "limit": 20 }

Проектирование Google Drive      279 Все API используют HTTPS и требуют аутентификации пользователя. SSL (Secure Sockets Layer — «слой защищенных сокетов») защищает передачу данных между клиентом и серверами системы. Отказываемся от архитектуры с одним сервером Файлов загружается все больше и больше, и в какой-то момент мы полу­ чим предупреждение о нехватке места, как показано на рис. 15.4. 10 MB free of 1 TB /drive Рис. 15.4 У нас осталось всего 10 Мб свободного места! Это чрезвычайная ситуация, так как пользователи больше не могут загружать свои файлы. Первое, что приходит на ум, это сегментировать данные так, чтобы они хранились на разных серверах. На рис. 15.5 показан пример шардинга на основе user_id. Сервер 1 user_id % 4 Сервер 2 Сервер 4 Сервер 3 Рис. 15.5

280      ГЛАВА 15 Вы проработали всю ночь, чтобы настроить шардинг и подробный мо­ ниторинг базы данных. Все опять работает как следует. Вы потушили пожар, но вам не дает покоя мысль о том, что перебои в работе сервера хранилища могут привести к потере данных. Вы начали интересоваться мнением своих коллег, и один ваш друг, гуру в области серверных систем, сказал, что многие ведущие компании вроде Netflix и Airbnb используют для хранения данных Amazon S3. «Amazon S3 (Simple Storage Service — “простой сервис хранения данных”) — это объектное хранилище, лиди­ рующее в сферах масштабируемости, доступности данных, безопасности и производительности» [3]. Вы решаете исследовать эту технологию, чтобы понять, подходит ли она вам. После продолжительного чтения вы как следует разобрались в системе хранения S3 и решили разместить в ней файлы своей системы. Amazon S3 поддерживает репликацию в рамках одного или нескольких регио­ нов. Регион — это географическая область, в которой находятся центры обработки данных AWS. Как видно на рис. 15.6, данные могут реплици­ роваться как в одном регионе (слева), так и между разными регионами (справа). Резервные копии файлов хранятся в нескольких регионах, чтобы предотвратить потерю данных и обеспечить их доступность. Ба­ кет — это аналог папки в файловой системе. репликация репликация репликация Регион A Бакет репликация репликация репликация Регион A Регион B Бакет Репликация внутри региона Репликация между регионами Рис. 15.6 Разместив файлы в S3, вы, наконец, можете спать спокойно, не волнуясь о потере данных. Чтобы подобные проблемы не возникали в будущем, вы проводите углубленное исследование в поиске участков системы, которые можно улучшить. Вот к каким выводам вы пришли.

Проектирование Google Drive      281

Балансировщик нагрузки. Добавление балансировщика нагрузки позволяет равномерно распределить сетевой трафик. Если сервер выходит из строя, трафик распределяется автоматически.

Веб-серверы. Благодаря наличию балансировщика нагрузки веб- серверы можно легко добавлять/удалять в зависимости от нагрузки.

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

Хранилище файлов. Для хранения файлов используется Amazon S3. Чтобы обеспечить доступность и устойчивость, файлы репли­ цируются в двух разных географических регионах. После внесения перечисленных выше улучшений вы успешно вынесли веб-серверы, БД метаданных и хранилище файлов за пределы единого сервера. Обновленная архитектура показана на рис. 15.7. Серверы API Мобильное приложение Веб-браузер Пользователь БД метаданных Файловое хранилище Балансировщик нагрузки Рис. 15.7

282      ГЛАВА 15 Конфликты синхронизации В такой крупной системе хранения данных, как Google Drive, время от времени случаются конфликты синхронизации. Это происходит, когда два пользователя одновременно изменяют один и тот же файл или пап­ ку. Как разрешить такой конфликт? Вот наша стратегия: побеждает та версия, которая обрабатывается первой, а обработка другой завершается конфликтом. Пример конфликта синхронизации показан на рис. 15.8. Наша система Наша система синхронизирован Наша система конфликт синхронизирован Пользо- ватель 1 Пользо- ватель 1 Пользо- ватель 2 Пользо- ватель 2 Пользо- ватель 2 Пользо- ватель 1 Рис. 15.8 Как видно на рис. 15.8, пользователь 1 и пользователь 2 одновременно пытаются обновить один и тот же файл, но наша система обрабатывает файл пользователя 1 первым. Операция обновления, выполненная поль­ зователем 1, принимается, а аналогичная операция пользователя 2 приво­ дит к конфликту синхронизации. Как разрешить этот конфликт? Наша система предлагает пользователю 2 обе версии файла: его локальную копию и последнюю версию, взятую с сервера (рис. 15.9). Пользователь 2 может выполнить слияние файлов или выбрать одну из версий. Рис. 15.9 Когда один документ редактируется сразу несколькими пользователями, это затрудняет его синхронизацию. Заинтересованные читатели могут обратиться к справочным материалам [4] [5].

Проектирование Google Drive      283 Общая архитектура На рис. 15.10 проиллюстрирована предложенная нами общая архитекту­ ра. Давайте проанализируем каждый ее компонент. Серверы API Пользователь Балансировщик нагрузки Облачное хранилище Сервис уведомлений Блочные системы хранения данных Холодное хранилище Очередь автономной архивации БД метаданных Длинный HTTP-опрос Кэш метаданных КЭШ КЭШ КЭШ Рис. 15.10

Пользователь. Взаимодействует с системой с помощью браузера или мобильного приложения.

Блочные системы хранения данных. Загружают блоки данных в облачное хранилище. Блочное хранилище — это технология хра­ нения файлов в облачных окружениях. Файл может быть разделен на несколько блоков, каждый из которых имеет уникальный хеш и хранится в нашей БД метаданных. Каждый блок обрабатывается как независимый объект и записывается в нашу систему хранения (S3). Чтобы восстановить файл, блоки соединяются в определен­ ном порядке. Что касается размера блоков, мы возьмем за пример сервис Dropbox, в котором блок не может превышать 4 Мб [6].

284      ГЛАВА 15

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

Холодное хранилище. Компьютерная система, предназначенная для хранения неактивных данных (файлов, к которым не обраща­ ются на протяжении длительного времени).

Балансировщик нагрузки. Равномерно распределяет запросы между серверами API.

Серверы API. Отвечают почти за все, кроме процесса загрузки. Их используют для аутентификации пользователей, управления поль­ зовательскими профилями, обновления метаданных файлов и т. д.

БД метаданных. Хранит метаданные пользователей, файлов, бло­ ков, версий и т. д. Пожалуйста, обратите внимание на то, что в этой БД находятся только метаданные, а сами файлы хранятся в облаке.

Кэш метаданных. Некоторые метаданные кэшируются для бы­ строго доступа.

Сервис уведомлений. Система типа «издатель–подписчик», кото­ рая передает данные клиентам при возникновении определенных событий. В нашем случае этот сервис оповещает соответствующих пользователей о добавлении/редактировании/удалении файла кем-то другим, чтобы они могли просмотреть последние изменения.

Очередь автономной архивации. Если клиент находится вне сети и не может получить последние изменения, соответствующая информация попадает в очередь автономной архивации. Это поз­ воляет синхронизировать изменения, когда пользователь снова подключается к сети. Мы обсудили общую архитектуру Google Drive. Некоторые из ее ком­ понентов довольно сложные и заслуживают отдельного внимания; мы подробно рассмотрим их в следующем разделе. ШАГ 3: ПОДРОБНОЕ ПРОЕКТИРОВАНИЕ В этом разделе мы подробно рассмотрим такие темы: блочные системы хранения данных, БД метаданных, процесс загрузки, процесс скачивания, сервис уведомлений, экономия места в хранилище и обработка сбоев.

Проектирование Google Drive      285 Блочные системы хранения данных Если большой файл, который регулярно изменяется, передавать целиком при каждом обновлении, на это будет уходить много трафика. Чтобы сэкономить трафик, предлагаем две оптимизации.

Синхронизация изменений. При редактировании файла синхро­ низируются только измененные блоки. Для этого используется алгоритм синхронизации [7] [8].

Сжатие. Сжатие блоков может существенно уменьшить размер данных. Следовательно, к блокам применяется алгоритм сжатия с учетом типа файла. Например, gzip и bzip2 используются для сжатия текстовых файлов. Для сжатия изображений и видеофайлов требуются другие алгоритмы. В нашей системе блочные системы хранения данных берут на себя основ­ ную работу по загрузке файлов. Они обрабатывают файлы, переданные клиентами, разбивая их на блоки, каждый из которых затем сжимается и шифруется. В систему хранения загружается не весь файл целиком, а лишь измененные блоки. На рис. 15.11 показано, что делает блочная система хранения при до­ бавлении нового файла. Блок 1 Блок 2 Блок N .... сжатие шифрование сжатие шифрование сжатие шифрование разделение разделение разделение Облачное хранилище Блочные серверы Рис. 15.11

286      ГЛАВА 15

Файл разделяется на блоки меньшего размера.

Каждый блок сжимается с помощью алгоритмов сжатия.

Чтобы обеспечить безопасность, перед отправкой в облачное хра­ нилище каждый блок шифруется.

Блоки загружаются в облачное хранилище. На рис. 15.12 проиллюстрирована дельта-синхронизация — процесс, в ходе которого в облачное хранилище передаются только измененные блоки, 2 и 5 (выделены на диаграмме). Блок 1 Блок 2 Блок 7 Облачное хранилище Блочные серверы только измененные Блок 2 Блок 6 Блок 5 Блок 4 Блок 3 Блок 8 Блок 10 Блок 9 Блок 5 Рис. 15.12 Блочные системы хранения данных позволяют сэкономить сетевой тра­ фик за счет синхронизации изменений и сжатия. Требование строгой согласованности Наша система должна поддерживать строгую согласованность по умол­ чанию. Нельзя допустить, чтобы один файл одновременно выглядел

Проектирование Google Drive      287 по-разному на разных клиентах. Система должна обеспечивать строгую согласованность уровней кэша и БД метаданных. Системы кэширования на основе оперативной памяти по умолчанию ис­ пользуют модель отложенной согласованности; это означает, что разные реплики могут хранить разные данные. Ради строгой согласованности мы должны сделать следующее:

позаботиться о согласованности реплик и ведущего узла;

аннулировать кэш при записи в базу данных, чтобы закэширован­ ные значения совпадали с теми, которые находятся в БД. Реляционные базы данных обладают свойствами ACID (Atomicity, Consistency, Isolation, Durability — «атомарность, согласованность, изо­ лированность, прочность»), поэтому в них легко достичь строгой согла­ сованности [9]. А вот в NoSQL свойства ACID по умолчанию не поддерживаются, поэтому их необходимо внедрять в логику синхронизации программным образом. Мы выбрали для нашей архитектуры реляционные базы данных, так как они изначально поддерживают ACID. БД метаданных На рис. 15.13 показана схема базы данных. Пожалуйста, имейте в виду, что это крайне упрощенный вариант, в котором указаны только самые важные таблицы и интересующие нас поля.

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

device. Таблица device хранит сведения об устройстве. Поле push_id используется для отправки и получения мобильных push- уведомлений. Обратите внимание на то, что у пользователя может быть несколько устройств.

namespace. Это пространство имен — корневая директория поль­ зователя.

file. Таблица file содержит все, что относится к последней версии файла.

288      ГЛАВА 15 Рис. 15.13

file_version. Хранит историю изменений файла. Имеющиеся стро­ ки доступны только для чтения, благодаря чему поддерживается неизменность истории изменений файла.

block. Хранит все, что связано с блоком файла. Файл любой версии можно воссоздать путем объединения всех его блоков в правильном порядке. Процесс загрузки Давайте посмотрим, что происходит, когда клиент загружает файл. Чтобы лучше понять этот процесс, воспользуемся диаграммой последователь­ ности, представленной на рис. 15.14. На рис. 15.14 показана параллельная отправка двух запросов: «добавить метаданные файла» и «загрузить файл в облачное хранилище». Оба они исходят от клиента 1.

Добавить метаданные файла.

Проектирование Google Drive      289 Блочные системы хранения данных Облачное хранилище Серверы API БД мета- данных Сервис уведомлений 4. Уведомить об изменениях 2. Состояние загрузки: ожидается 2.2. Загрузить файл 2.5. Уведомить об изменениях Клиент 2 Клиент 1 1. Добавить мета- данные файла 2.1. Загрузить файл 3. Уведомить об изменениях 2.3. Загрузить метаданные файла 2.4. Состояние загрузки: загружено 2.6. Уведомить об изменениях Рис. 15.14 1. Клиент 1 отправляет запрос на добавление метаданных нового файла. 2. Система сохраняет метаданные нового файла в БД метаданных и присваивает загружаемому файлу состояние «ожидается». 3. Система оповещает сервис уведомлений о том, что файл будет загружен. 4. Сервис уведомлений оповещает заинтересованные клиенты (клиент 2) о том, что файл загружается.

Загрузить файлы в облачное хранилище. 2.1. Клиент 1 загружает содержимое файла на блочные системы хранения данных. 2.2. Блочные системы хранения данных разбивают файл на блоки, которые затем сжимаются, шифруются и загружаются в облачное хранилище. 2.3. Как только файл загружен, облачное хранилище инициирует обратный вызов завершения загрузки. Запрос передается серверам API.

290      ГЛАВА 15 2.4. В БД метаданных состояние файла меняется на «загружено». 2.5. Система оповещает сервис уведомлений о том, что состояние файла поменялось на «загружено». 2.6. Сервис уведомлений оповещает заинтересованные клиенты (клиент 2) о том, что файл полностью загружен. При проектировании файла применяется аналогичный процесс, так что мы не станем повторяться. Процесс скачивания Процесс скачивания инициируется при добавлении или редактировании файла на другом устройстве. Откуда клиент узнает, что файл добавляет­ ся или редактируется другим клиентом? Это может происходить двумя способами.

Если клиент A находится в сети в момент, когда файл изменяется другим клиентом, сервис уведомлений оповестит его об этих из­ менениях и необходимости скачать последние данные.

Если клиент A находится не в сети в момент, когда файл изменяется другим клиентом, данные сохраняются в кэш. Когда клиент A снова появляется в сети, он скачивает последние изменения. Узнав об изменении файла, клиент сначала запрашивает его метаданные у серверов API, а затем загружает соответствующие блоки, чтобы восста­ новить его содержимое. Детали процесса показаны на рис. 15.15. Отметим, что на этой диаграмме показаны лишь самые важные компоненты, чтобы уместить ее на страницу. 1. Сервис уведомлений информирует клиент 2 о том, что файл был изменен в другом месте. 2. Поскольку клиенту 2 известно о доступных обновлениях, он шлет запрос на скачивание метаданных. 3. Серверы API обращаются к БД за метаданными изменений. 4. Метаданные возвращаются серверам API. 5. Клиент 2 получает метаданные.

Проектирование Google Drive      291 Блочные системы хранения данных Облачное хранилище Серверы API БД мета- данных Сервис уведомлений Клиент 2 3. Получить изменения 7. Загрузить блоки 2. Получить изменения 8. Блоки 1. Уведомить об изменениях 5. Вернуть изменения 6. Загрузить блоки 9. Блоки 4. Вернуть изменения Рис. 15.15 6. Получив метаданные, клиент отправляет запрос блочным системам хранения данных, чтобы скачать блоки. 7. Блочные системы сначала скачивают блоки из облачного храни­ лища. 8. Облачное хранилище возвращает блоки блочным системам хра­ нения данных. 9. Клиент 2 скачивает все новые блоки, чтобы восстановить файл. Сервис уведомлений Чтобы поддерживать файлы в согласованном состоянии и уменьшить число конфликтов, любое изменение, вносимое локально, должно быть доступно другим клиентам. Сервис уведомлений создан именно с этой целью. Его основная задача состоит в передаче данных клиентам в от­ вет на определенные события. Это можно организовать несколькими способами.

Длинный HTTP-опрос. Этот метод использует Dropbox [10].

WebSocket. Этот протокол устанавливает постоянное соединение между клиентом и сервером с двунаправленным взаимодействием.

292      ГЛАВА 15 Нам подходят оба варианта, но мы выберем длинный HTTP-опрос по двум причинам.

Взаимодействие с сервисом уведомлений не двунаправленное. Сер­ вер отправляет клиенту информацию о файле, но обратно ничего не возвращается.

WebSocket подходит для двунаправленного взаимодействия в реальном времени, как в случае с чатом. В Google Drive уве­ домления отправляются не так часто и не провоцируют всплески трафика. При использовании длинного HTTP-опроса каждый клиент устанав­ ливает HTTP-соединение с сервисом уведомлений. В случае внесения изменений в файл клиент закрывает соединение. Это означает, что он должен подключиться к серверу метаданных для скачивания последних изменений. После получения ответа или по истечении времени ожида­ ния клиент немедленно отправляет новый запрос, чтобы поддерживать соединение открытым. Экономия места в хранилище Чтобы реализовать историю изменений файлов и сделать систему на­ дежной, мы храним разные версии одного и того же файла в нескольких центрах обработки данных. При частом сохранении каждого изменения свободное место в хранилище может быстро закончиться. Для экономии места можно предложить три способа.

Дедупликация блоков данных. Устранение лишних блоков на уров­ не учетной записи позволяет легко сэкономить место. Два блока являются идентичными, если у них одинаковое значение хеша.

Внедрение интеллектуальной стратегии резервного копирования. Здесь можно применить два подхода: Š Š установить лимит. Мы можем ограничить количество хранимых версий. При достижении лимита самая старая версия заменяется новой; Š Š хранение только важных версий. Некоторые файлы могут ак­ тивно редактироваться. Поэтому, если сохранять каждую изме­

Проектирование Google Drive      293 ненную версию, документ может записываться более 1000 раз за короткий промежуток времени. Чтобы избавиться от лишних копий, мы можем ограничить количество сохраняемых версий. Найти оптимальное значение можно методом проб и ошибок. При этом последние версии получают больший вес.

Перемещать редко используемые данные в холодное хранилище. Холодными называют данные, к которым никто не обращался на протяжении месяцев или даже лет. Холодное хранилище, такое как Amazon S3 Glacier [11], намного дешевле, чем S3. Обработка сбоев В крупномасштабных системах случаются сбои, и, чтобы с ними справ­ ляться, необходимо внедрить подходящие стратегии проектирования. Интервьюеру может быть интересно услышать о том, как вы будете об­ рабатывать следующие сбои системы.

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

Отказ блочного сервера. Если блочный сервер выходит из строя, другие серверы подхватывают незаконченные или ожидающие задания.

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

Отказ сервера API. Этот сервис не хранит свое состояние, поэтому в случае поломки одного сервера API балансировщик нагрузки перенаправит трафик к другим серверам.

Отказ кэша метаданных. Серверы, кэширующие метаданные, ре­ плицируются по нескольку раз. Если один узел выходит из строя,

294      ГЛАВА 15 можно обращаться за данными к другим. Отказавший сервер кэша будет заменен новым.

Отказ БД метаданных: Š Š отказ ведущего узла. Если выходит из строя ведущий узел, его место занимает один из ведомых, после чего активируется новый ведомый узел; Š Š отказ ведомого узла. Если выходит из строя ведомый узел, вы можете направить операции чтения другому ведомому узлу и заменить отказавший сервер базы данных.

Отказ сервиса уведомлений. Каждый пользователь, находящийся в сети, поддерживает длинные HTTP-соединения с сервером уве­ домлений. Следовательно, к каждому такому серверу подключено много пользователей. Согласно презентации Dropbox 2012 года [6], на каждом компьютере открыто более миллиона соединений. Если сервер выходит из строя, все длинные HTTP-соединения теряются и клиентам приходится переподключаться к другому серверу. Не­ смотря на поддержку большого количества соединений, отдельно взятый сервер не в состоянии установить их все одновременно. Переподключение всех клиентов, которые потеряли связь, про­ ходит довольно медленно.

Отказ очереди автономной архивации. Очереди реплицируются по нескольку раз. Если одна очередь выйдет из строя, ее потребителям, возможно, придется подписаться на другую. ШАГ 4: ПОДВЕДЕНИЕ ИТОГОВ В этой главе мы предложили архитектуру системы для поддержки воз­ можностей Google Drive. Сочетание строгой согласованности, небольшого объе­ма трафика и быстрой синхронизации делает эту архитектуру инте­ ресной. Наша система состоит из двух процессов: управления метаданны­ ми файлов и синхронизации. Еще одним важным компонентом системы является сервис уведомлений. С помощью длинного HTTP-опроса он сообщает клиентам о последних изменениях в файлах. У задач, которые встречаются на интервью по проектированию ИТ- систем, не бывает идеальных решений. У каждой компании есть свои

Проектирование Google Drive      295 уникальные ограничения, и при проектировании их необходимо учиты­ вать. Вы должны понимать сильные и слабые стороны архитектурных и технологических аспектов системы. Если у вас еще остается несколько минут, можете обсудить различные архитектурные решения. Например, файлы из клиента можно загружать напрямую в облачное хранилище, минуя блочные системы хранения данных. Преимущество этого подхода в том, что загрузка файлов становится быстрее, так как их нужно передавать только один раз. В нашей архитектуре файлы сначала передаются блочным системам хранения данных и только затем попада­ ют в облачное хранилище. Тем не менее у альтернативного решения есть несколько минусов.

Во-первых, одну и ту же логику разбиения на блоки, сжатия и шиф­ рования нужно реализовать на разных платформах (iOS, Android, веб). Это чревато ошибками, к тому же на это уходит много време­ ни. В нашем решении вся эта логика централизована и находится в блочных системах хранения данных.

Во-вторых, поскольку клиент подвержен взлому и манипуляциям, реализация логики шифрования на его стороне была бы не самым оптимальным вариантом. Еще одним интересным улучшением было бы вынесение логики управ­ ления сетевым состоянием в отдельный сервис. Назовем его сервисом присутствия в сети. Благодаря нахождению за пределами серверов уве­ домлений этот сервис можно было бы легко интегрировать с другими компонентами системы. Поздравляем, вы проделали длинный путь и можете собой гордиться. Отличная работа! СПРАВОЧНЫЕ МАТЕРИАЛЫ [1]  Google Drive: https://www.google.com/drive/ [2]  Upload file data: https://developers.google.com/drive/api/v2/manage-uploads [3]  Amazon S3: https://aws.amazon.com/s3 [4]  Differential Synchronization https://neil.fraser.name/writing/sync/

296      ГЛАВА 15 [5]  Презентация на YouTube о синхронизации изменений: https://www.youtube. com/watch?v=S2Hp_1jqpY8 [6]  How We’ve Scaled Dropbox: https://youtu.be/PE4gwstWhmc [7]  Tridgell, A., & Mackerras, P. (1996). The rsync algorithm. [8]  Libsync https://github.com/librsync/librsync [9]  ACID: https://ru.wikipedia.org/wiki/ACID [10]  Dropbox security white paper: https://www.dropbox.com/static/business/ resources/Security_Whitepaper.pdf [11]  Amazon S3 Glacier: https://aws.amazon.com/glacier/faqs/