Автор: Джордан Ситкин
В пятницу, 29 января, между 4:25 и 9:31 по тихоокеанскому времени на api.coinbase.com произошел сбой. В течение этого времени многие пользователи сталкивались с ошибками при попытке использовать приложение Coinbase, а функции покупки, продажи и торговли криптовалютами периодически были доступны. Доступ к торговле на pro.coinbase.com остался без изменений. В этом сообщении подробно описывается сбой, объясняется его причина и описываются изменения, которые мы внесли для предотвращения подобных сбоев в будущем.
Отключение
Группа Инженеры oncall собрались после того, как им было отправлено сообщение о высоком уровне ошибок на многих конечных точках. Это было быстро диагностировано как проблема с кластером Redis, используемым для хранения спотовых курсов для конвертации валют. Эти спотовые курсы используются для предполагаемых конверсий между валютами, что ставит их на критический путь для ряда функций, таких как отображение стоимости вашего портфеля в местной валюте. Загрузка процессора в этом кластере Redis внезапно достигла 100%, что приводило к сбою нескольких конечных точек API и фоновых заданий. Мы немедленно приступили к снижению нагрузки на этот кластер, чтобы он мог восстановиться. Наш мониторинг показал, что большая часть нагрузки на этот кластер приходилась на фоновые задания, поэтому мы начали отключать их, ожидая увидеть падение пропускной способности запросов.
После нескольких циклов отключения заданий нагрузка на кластер снизилась. все еще высокий, поэтому была предпринята попытка переключения кластера, чтобы выяснить, не вызван ли отказ аппаратной проблемой. Это тоже не подействовало. Нам также не удалось развернуть изменение кода, призванное смягчить проблему, поскольку неработоспособный кластер Redis препятствовал загрузке новых серверов приложений. Попытка вертикального масштабирования кластера на месте также не смогла снизить нагрузку на ЦП.
Наконец, мы решили подготовить новый, гораздо более крупный кластер Redis, чтобы заменить перегруженный. Как только он загрузился, мы направили на него новое развертывание приложения и, наконец, восстановили обслуживание наших клиентов. Однако на данный момент некоторые вопросы остаются без ответа, что побуждает нас углубиться и выявить настоящую первопричину.
Анализ первопричин
За несколько дней после отключения мы восстановили ясная картина того, что произошло в течение первой минуты.
2. 00: 02с — скачок количества одновременных запросов Redis и переполнение пулов соединений. Одновременные промахи в кэше из-за перезапуска узла Memcached вызвали панику запросов на базовые данные, хранящиеся в кластере Redis. Увеличение количества одновременных запросов потребовало увеличения в 50 раз количества подключений Redis для их обслуживания.
3. 00: 07с — Мы наблюдаем высокий уровень ошибок тайм-аута клиента Redis. Внезапный приток соединений замедлил работу движка Redis. Загрузка ЦП подскочила до 100%, и он перестал отвечать на запросы в течение 1 секунды. На данный момент частота ошибок на наших конечных точках API данных о ценах составляла около 90%. Эти тайм-ауты не позволили memcached пополнить свой кеш, поэтому нагрузка на этот кластер Redis с этого момента оставалась высокой.
4. 00: 13s — Срок действия 5-секундного кеша в CDN для всех общедоступных ценовых данных истек. Обычно нагрузка на приложение для этих конечных точек стабильна благодаря кешу CDN. За это время он вырос до 5-кратного обычного объема, потому что CDN начал пересылать запросы в приложение для пополнения своего кеша для всех данных о ценах на активы. Из-за частоты ошибок 90% на этих конечных точках не удалось успешно обновить кеш для подавляющего большинства ключей. Код приложения попал в Redis, чтобы загрузить эти данные из-за промахов Memcached, что еще больше увеличило нагрузку на уже перегруженный кластер.
Коды ответа CDN
В этот момент кластер Redis получал пропускную способность запросов, во много раз превышающую его обычную нагрузку, а уровни кеша над ним (Memcached и CDN) не удалось пополнить из-за тайм-аутов клиента Redis и сбоев подключения. Любые запросы, основанные на данных о курсах валют, не выполнялись, и поэтому пользователи не могли получить доступ к критически важным функциям на нашем сайте. Цикл промахов кеша и тайм-аутов клиента держал этот кластер Redis перегруженным на время простоя, несмотря на несколько попыток снизить нагрузку.
Взгляд в будущее
Оглядываясь назад, мы: Мы выявили некоторые слепые зоны в нашем мониторинге, которые мешали нам быстро понять сбой.
- Наш клиентский мониторинг Redis не включал запросы с истекшим временем ожидания. Это лишило нас возможности увидеть, что приложение перегружало Redis, поскольку мы смотрели только на успешные вызовы, которые уменьшились во время простоя.
- Наш серверный мониторинг Redis не включал неудачные вызовы. Это создавало сбивающую с толку панель мониторинга, которая показывала резкое увеличение сетевой активности, но без явной активности запросов. Наши метрики получены из вывода Redis INFO commandstats и не включают failed_calls или rejected_calls .
- Перезапуск узла Memcached был обнаружен только после инцидента потому что эта информация не отображалась ни на одной из наших информационных панелей.
Кроме того, наше приложение было настроено таким образом, чтобы первоначальный небольшой сбой перерастал в полномасштабный сбой.
- Пулы клиентских соединений выросли до 50-кратного размера почти мгновенно, переполнив Redis новыми соединениями. Чтобы противостоять этому, мы настроили размеры пулов соединений, чтобы установить более щедрые минимумы и разумные максимумы.
- Кластер Redis был недостаточно подготовлен. Мы заменили его кластером подходящего размера и проверили остальные кластеры, чтобы убедиться, что они правильно масштабированы.
- Мы не использовали реплики только для чтения в этом кластере. Мы изучаем более широкое использование вторичного чтения Redis, чтобы лучше масштабировать этот и аналогичные варианты использования.
Еще одно важное наблюдение: сбой в одной области нашего API мог прервать обслуживание всех Это. В настоящее время мы работаем над разделением нашего монолитного сервера приложений на отдельные службы, чтобы предотвратить подобные сбои в будущем. Объединение этой части API в отдельно масштабируемую единицу позволит нам изолировать ее от проблем в других местах и предотвратить нарушение других функций.
Мы очень серьезно относимся к времени безотказной работы и производительности нашей инфраструктуры, и мы ‘ Мы прилагаем все усилия, чтобы поддержать миллионы клиентов, которые выбирают Coinbase для управления своей криптовалютой. Если вы заинтересованы в решении проблем масштабирования, подобных представленным здесь, приходите поработать с нами.
Сообщение о происшествии от 29 января 2021 г. было первоначально опубликовано в блоге Coinbase на Medium, где люди продолжают беседу, выделяя эту историю и отвечая на нее.
