ERPC масштабно обновляет сетевую инфраструктуру Solana и без простоя развёртывает Rust-прокси во всех регионах
ERPC, развиваемый ELSOUL LABO B.V. (штаб-квартира — Амстердам, Нидерланды; CEO — Fumitake Kawasaki) и Validators DAO, завершил масштабное обновление сетевой инфраструктуры Solana.
Это обновление уже применено ко всем регионам и ко всем общим точкам доступа, предоставленным ERPC (Solana RPC, Geyser gRPC и Shredstream). Мы обновили как единую систему те аспекты инфраструктуры, которые напрямую влияют на реальные результаты, включая инициирование соединения, обработку TLS, управление кэшем, транспорт HTTP/1.1 и HTTP/2, поведение долговременного соединения, а также метрики для наблюдаемости и устранения неполадок.
Сохраняя обычную скорость отклика в качестве базового уровня, мы также реорганизовали базовое поведение сети, чтобы снизить вероятность перекосов и нестабильности в сценариях, где результаты имеют тенденцию к ухудшению, таких как пиковая нагрузка, длительная работа и каскады, вызванные отключениями и повторными подключениями. В результате среда теперь лучше структурирована для обеспечения как производительности, так и стабильности в практической эксплуатации инфраструктуры Solana.
Кроме того, мы перешли на операционную архитектуру, которая позволяет вносить изменения в конфигурацию сети и обновлять платформу без какого-либо простоя. Никаких изменений в ценах, технических характеристиках, аутентификации или ограничениях скорости не происходит, а существующие клиенты ERPC получают преимущества обновления без каких-либо дополнительных настроек или эксплуатационных изменений.
Предпосылки
В практической эксплуатации инфраструктуры Solana среднее время отклика и нормальная задержка являются важнейшими базовыми требованиями. В то же время существуют сценарии, в которых поведение базовой сетевой инфраструктуры само по себе определяет результаты — например, моменты концентрированной нагрузки, долгоживущие соединения и периоды, когда происходят отключения и повторные подключения.
В частности, общие точки доступа должны обеспечивать как всплески отправки транзакций в короткие промежутки времени, так и постоянные соединения через WebSocket и gRPC. В этих условиях поведение на уровне инфраструктуры — инициирование соединения, рукопожатия TLS, поведение транспорта, обработка кэша и выход из состояния простоя — напрямую отражается на пользовательском опыте и результатах выполнения.
Учитывая среднюю скорость реагирования в качестве явного базового уровня, реальные результаты всё равно могут определяться различными факторами во время пиковых нагрузок или в условиях продолжительной работы. Таким образом, практическая эксплуатация требует, чтобы повседневное удобство использования и непрерывность в сценариях, подверженных сбоям, достигались одновременно.
ERPC разработал и эксплуатирует собственную высокопроизводительную прокси-платформу Rust в качестве основы для связи Solana, поддерживая архитектуру, которая применяет один и тот же подход во всех регионах, одновременно постоянно развивая платформу. Это обновление пересматривает наблюдаемые в ходе эксплуатации проблемы как единую систему — от инициации соединения до длительной работы — и соответствующим образом реорганизует всю основу сети.
Что изменилось для клиентов ERPC
Благодаря этому обновлению клиенты ERPC прежде всего заметят более стабильное поведение при инициации соединения. Во время установления соединения, включая TLS, вероятность несогласованных состояний и ненужных повторных попыток снижается, что облегчает надёжную обработку транзакций и потоков с самого начала.
Затем мы реорганизовали поведение инфраструктуры, которое обычно приводит к нестабильности во время пиковой нагрузки. Сочетая раннюю фильтрацию ненужных подключений с одновременным обновлением согласованности транспорта и тайм-аутов HTTP/1.1 и HTTP/2, работоспособности пула соединений, поведения кэша при конкуренции запросов, а также показателей для наблюдения и устранения неполадок, мы усилили условия, которые помогают предотвратить перекосы даже при концентрации нагрузки.
Для долгоживущих потоков WebSocket и gRPC и постоянно работающих рабочих нагрузок мониторинга непрерывность соединения улучшилась. Частота событий отключения/повторного подключения/повторной синхронизации — и вероятность того, что эти события повлияют на результаты — была уменьшена, что упрощает построение эксплуатации в предположении устойчивого времени выполнения.
Улучшения в управлении кэшем и поведении транспорта также снижают вероятность ненужных запросов и ненужной обработки во время перегрузки. Повышается вероятность сохранить доступную пропускную способность и стабильный запас вычислительных ресурсов, а расширенные метрики и средства наблюдаемости упрощают выявление первопричин и сокращение времени восстановления.
Кроме того, обеспечив возможность изменения конфигурации и обновления платформы без простоев, мы создали условия эксплуатации, позволяющие чаще повышать производительность, стабильность и общее качество платформы. Возможность продолжать совершенствоваться, не приостанавливая платформу, ещё больше укрепляет непрерывность работы для клиентов.
Подробности улучшений
Это обновление не представлено как выпуск, основанный на конкретных названиях функций или номерах версий. Вместо этого оно разбирает сценарии, которые имеют тенденцию доминировать в реальных результатах Solana, на следующие уровни — инициирование соединения, TLS, граница L4/HTTP, транспорт H1/H2, кэш, наблюдаемость, поведение при сбоях и долгосрочные эксплуатационные предпосылки — и обновляет платформу, чтобы эти уровни соединялись без противоречий.
Ниже мы объясняем внесённые улучшения с точки зрения того, как они способствуют повышению качества обслуживания клиентов и операционным результатам.
Улучшения в инициировании соединения и обработке TLS
Мы расширили контекст TLS, обрабатываемый во время установления соединения, и обновили структуру, чтобы требуемое состояние можно было сохранить и применить соответствующим образом. Это снижает вероятность несогласованных состояний и ненужных повторных попыток при инициировании соединения.
Мы также реорганизовали обработку TLS, включая проверку сертификата и проверку имени хоста, чтобы можно было удовлетворить требования безопасности, уменьшая при этом количество случаев, когда сбои при подтверждении связи или несогласованная обработка вызывают проблемы на этапе установления соединения, а их последствия каскадно влияют на результаты. Это не просто повышение безопасности; это способствует стабилизации поведения от начала соединения до входа в обработку для рабочих нагрузок Solana.
Мы дополнительно усилили механизмы, которые упрощают наблюдение за связанным с TLS поведением и устранение неполадок. В сценариях, где исход зависит прежде всего от инициации соединения, качество пользовательского опыта определяется тем, насколько быстро удаётся воспроизвести проблему, найти причину и внедрить исправление.
Сохранение запаса за счёт ранней фильтрации ненужных подключений
Мы представили механизм фильтрации соединений TCP на раннем этапе, обновив платформу, чтобы неправомерные или ненужные соединения с меньшей вероятностью оказывали давление на законный трафик. На общих точках доступа количество запросов на подключение может резко увеличиться из-за внешних факторов или временных перекосов.
Фильтрация на ранней стадии помогает гарантировать, что легитимные соединения с меньшей вероятностью остановятся при инициировании, повышая вероятность того, что запас останется доступным во время пиковой нагрузки. В результате снижается вероятность перекосов в работе даже при концентрированной нагрузке, а условия для стабильного распределения задержек улучшаются.
Уточнение модели соединения путём реорганизации границы L4/HTTP
Сетевая инфраструктура не заканчивается на HTTP. Установление и непрерывность соединения зависят от условий L4, и нестабильность на этом уровне распространяется на протокол более высокого уровня.
В этом обновлении мы абстрагировали обработку потока L4 и реорганизовали структуру, чтобы модель соединения можно было обрабатывать более явно. Это позволяет платформе поддерживать единообразное поведение в сценариях, где число соединений продолжает расти, реализации клиентов различаются, а длительная работа приводит к смене состояний.
Поведение повторных попыток также было реорганизовано, чтобы уменьшить количество случаев, когда кратковременная волатильность влияет на взаимодействие с пользователем. Практическая стабильность зависит не столько от устранения изолированных сбоев, сколько от предотвращения каскада сбоев.
Улучшения в транспорте и долгосрочном поведении HTTP/1.1 и HTTP/2
Мы добавили измерения, которые позволяют последовательно отслеживать объём передаваемых данных на HTTP/1.1 и HTTP/2. Это облегчает выявление сбоев или узких мест в транспортном тракте, улучшая как устранение неполадок, так и скорость их устранения.
Мы также реорганизовали поведение тайм-аута записи тела HTTP/2, чтобы снизить вероятность нештатных задержек и зависаний во время концентрированной нагрузки или длительной потоковой передачи. В долгосрочной перспективе важна не максимальная производительность в идеальных состояниях, а способность предотвратить сбой поведения во время переходов между состояниями.
Также были пересмотрены поведение таймаута простоя и обработка пула соединений, что позволило устранить факторы нестабильности, которые имеют тенденцию накапливаться во время продолжительной работы. На стороне HTTP/1.1 мы реорганизовали безопасное завершение соединений с неполными запросами, уменьшив источники нестабильности как в использовании ресурсов, так и в поведении соединений.
Улучшения в управлении кэшем и качестве работы
Мы улучшили возможность отслеживать, почему ресурс не попадает в кэш, что повышает объяснимость поведения кэша. На практике доминирует не то, существует ли кэширование, а при каких условиях оно применяется и при каких условиях кэш перестаёт использоваться.
Мы реорганизовали поведение блокировок, обработку устаревших данных и схемы повторной валидации, чтобы снизить вероятность каскадного ухудшения качества при возникновении конфликтов при пиковой нагрузке. Мы также организовали контроль вытеснения для случаев, когда количество кэшированных ресурсов растёт, и усовершенствовали поведение частичного контента (включая запросы Range), усилив условия, которые уменьшают ненужные повторные выборки и задержки при реальных рабочих нагрузках.
Эти улучшения уменьшают количество случаев, когда поведение кэша превращается в источник аномалий, что снижает вероятность того, что клиентам придётся проектировать эксплуатацию с учётом неопределённости на уровне инфраструктуры.
Улучшения поведения при сбоях, ведения журнала и наблюдаемости
Поведение при сбоях и ведение журнала были реорганизованы, чтобы было легче понять, что происходит при возникновении проблем. Сокращается число сценариев, в которых ошибки нижестоящих компонентов влияют на поведение кэша и транспорта и ухудшают работу, что упрощает локализацию области воздействия.
Улучшения наблюдаемости и средств устранения неполадок не предназначены для утверждения «нулевых инцидентов», а для сокращения времени восстановления в случае возникновения инцидентов. Это снижает риск в сценариях пиковой нагрузки и устойчивой эксплуатации.
Обновления зависимостей и исправления безопасности как необходимые условия для долгосрочной работы
Мы включили обновления зависимостей и исправления безопасности, чтобы обеспечить необходимые условия для долгосрочной работы платформы. Сюда входят обновления, связанные с минимально поддерживаемой версией Rust (MSRV) и согласованием CI, укрепляющие основу, необходимую для постоянного развития платформы.
Возможность безопасного обновления сама по себе является требованием для обеспечения долгосрочного качества.
Переход к работе с нулевым временем простоя
Ранее кратковременные простои могли возникать при изменении конфигурации сети или обновлении платформы. Благодаря этому обновлению мы перешли на архитектуру, в которой эти изменения можно применять с нулевым простоем.
Общие эндпоинты обслуживают постоянные соединения, и критичные по времени операции происходят непрерывно. Даже кратковременный простой может вызвать каскады отключений, повторных подключений и повторной синхронизации, и эти затраты могут отразиться на результатах. Обновления с нулевым временем простоя уменьшают вероятность этих каскадов и предотвращают разрыв долговременных процессов.
В то же время ERPC теперь располагает эксплуатационной архитектурой, которая позволяет быстро отразить обнаруженные проблемы в улучшениях. Более высокая частота итераций позволяет нам постоянно устранять волатильность и нестандартное поведение в производственной эксплуатации.
Влияние по сервису
Solana RPC (HTTP / WebSocket)
Улучшения в инициировании соединения, TLS, управлении кэшем и поведении транспорта влияют как на чтение данных, так и на отправку транзакций. При сохранении удобства повседневного использования факторы, влияющие на результаты во время пиковой нагрузки, уменьшаются, а условия для сохранения запаса во время перегрузок усиливаются.
Geyser gRPC
Непрерывность соединения улучшена для длительного использования потоковой передачи. Транспорт HTTP/2, согласованность тайм-аутов, работоспособность пула соединений и расширенные измерения транспорта работают вместе, чтобы снизить вероятность того, что затраты на повторное подключение и повторную синхронизацию повлияют на результаты.
ShredStream (Direct Shreds)
Благодаря улучшениям в управлении соединениями и инициации, предназначенным для непрерывной доставки, условия улучшаются, поэтому вероятность отсутствия данных или задержки в условиях перегрузки снижается. Стабильную непрерывность обнаружения и отслеживания становится легче поддерживать.
Объединение исследований и разработок и производственных операций
Платформа распределённых систем, включающая ERPC, была признана научно-исследовательским проектом в рамках программы правительства Нидерландов WBSO. Создаётся структура, в которой наблюдаемые в ходе эксплуатации проблемы могут быть включены в качестве предметов исследования и улучшены посредством проверки и итерации.
Это обновление основы сети является одной из таких итераций, применяемых во всех регионах, что отражается на практической производительности и стабильности. Непрерывная связь эксплуатации с исследованиями и разработками позволяет переносить наблюдения из рабочей среды в следующие обновления, а не останавливаться на разовых улучшениях.
В рамках ERPC фактические модели использования, изменчивость нагрузки и поведение в режимах сбоев включены в повторяющиеся циклы проверки и улучшения, которые постепенно повышают качество основы сети. Это обновление было выполнено в рамках интегрированной структуры исследований, разработок и производственной эксплуатации.
Информация для клиентов
Это обновление уже применено ко всем регионам и ко всем общим точкам доступа. Существующим клиентам ERPC не нужно менять конфигурацию или эксплуатационные процессы. Никаких изменений в ценах, спецификациях, аутентификации или ограничениях скорости не произошло.
Поскольку общие точки доступа должны одновременно поддерживать как короткие всплески, так и долговременные соединения, инфраструктура была переработана так, чтобы снизить вероятность перекосов при таких смешанных рабочих нагрузках. Даже если изменения конфигурации или обновления платформы происходят во время эксплуатации, изменения применяются без простоя, поэтому клиентам не нужно планировать разрывы соединений или обязательную повторную синхронизацию.
По вопросам архитектуры, оптимизации для конкретной рабочей нагрузки или отзывам об эксплуатации обращайтесь через официальный Discord-сервер Validators DAO.
Постоянно превращая наблюдения из рабочей среды и обратную связь в улучшения, ERPC постепенно повышает качество своей инфраструктурной основы. Мы продолжим накапливать улучшения без простоев и предоставлять сетевую инфраструктуру, обеспечивающую реальные результаты Solana.
Официальный Discord-сервер Validators DAO: https://discord.gg/C7ZQSrCkYR
Официальный сайт ERPC: https://erpc.global/ru
