Восемь лет я руководил SRE-командой, обслуживавшей систему хранения данных объёмом в экзабайты. Со временем дашборд, который я открывал каждое утро, сжался до нескольких цифр. Вот семь показателей, по которым я судил о здоровье сервиса.
Доступность (availability) говорит о том, работает ли система. Надёжность хранения (durability) — о том, на месте ли ваши данные. Это не одно и то же.
Краткая сводка:
| Метрика | Что измеряет | Как отслеживали |
|---|---|---|
Availability |
Процент успешных запросов |
99,99% по каждому региону и сервису |
Durability |
Вероятность сохранности данных |
11 девяток (10-11 потерь в год) |
TTFB |
Время до первого байта |
Латентность p50, p95, p99 по размерам объектов |
Canaries |
Синтетический тестовый трафик |
Непрерывные PUT/GET из каждого региона |
Hotspots |
Перекос нагрузки между узлами |
Нагрузка на Top-N узлов vs медиана по кластеру |
IOPS |
Операций в секунду |
Операции чтения/записи на шард и на диск |
DB Shards |
Состояние разделов метаданных |
CPU шарда, лаг репликации, перекос по горячим ключам |
Доступность и надёжность хранения — два абсолютных требования
Доступность — это время безотказной работы. Надёжность — это сохранность данных. Система может быть доступна на 100% и при этом терять данные; может надёжно хранить всё что угодно и при этом быть недоступна. Клиентам важно и то и другое. Одиннадцати девяток надёжности мы добились, записывая каждый объект сразу в несколько зон доступности с использованием стирающего кодирования (erasure coding), и ежемесячно подтверждали это учениями по восстановлению.
TTFB — это то, что пользователь ощущает напрямую
Агрегированная доступность скрывает медленные хвосты. Сервис с доступностью 99,99%, у которого p99 TTFB равен двум секундам, ощущается сломанным. Всегда отслеживайте латентность в разбивке по размерам объектов. Чтение 10 МБ не должно иметь общий SLO с HEAD-запросом на 100 байт.
Канарейки — ваш источник правды
Клиенты не сообщают вам, когда им плохо. Они просто уходят. Канарейки (canaries) — это синтетические запросы PUT/GET/LIST, которые непрерывно идут из каждого региона. Если канарейка падает на 30 секунд, вы узнаёте об этом раньше, чем у клиента сработает пейджер.
Горячие точки и IOPS обнажают скрытые сбои
Кластер хранения может демонстрировать 99,99% доступности, пока один из узлов горит. Отслеживайте IOPS и объём отдаваемых данных на каждый узел и настройте алерты на расхождение нагрузки Top-N узлов с медианой по кластеру. Горячие точки (hotspots) — это ранний признак того, что диапазон ключей одного клиента перегружает шард.
Шарды базы данных — то, о чём никто не говорит
Объектное хранилище выглядит как stateless-система, но за ним стоит шардированная база метаданных. Один перегретый шард, одна неудачная ребалансировка — и плоскость управления (control plane) встаёт колом. Следите за CPU шардов, лагом репликации и перекосом по горячим ключам так же внимательно, как за плоскостью данных (data plane).
Плоскость данных масштабируется. Плоскость управления кусается.
Эти семь цифр в совокупности давали мне почти всё, что нужно было знать о состоянии сервиса.