Эта (давно обещанная) заметка завершает рассказ о статье Dynamo: Amazon's Highly Available Key-value Store. Вот предыдущие части:
Amazon’s Dynamo: версионность объектов
Amazon’s Dynamo: распределение объектов по узлам системы
Amazon’s Dymano: репликация объектов и диагностирование сбоев
Здесь я всего лишь перечислю несколько небольших моментов, за которые взгляд зацепился во время чтения, но о которых особо и не расскажешь.
Service Level Agreements (SLA). В статье упоминается, что все службы внутри Dynamo договариваются между собой о качестве предоставления услуг посредством т.н. Service Level Agreement (SLA). Например, сервер в своем SLA может указать, что он гарантирует время отклика в 300ms для 99.9% запросов при пиковой нагрузке в 500 запросов в секунду. При этом подчеркивается, что в Dynamo делают расчет именно исходя из цифры 99.9%. Т.е. если какой-то сервер заявляет свои возможности, то он заявляет их для 99.9% запросов. Так обеспечивается качество обслуживания для подавляющего большинства пользователей Amazon-овских сервисов.
Меня, правда, больше интересует, каким образом SLA используется на программном уровне при построении компонентов. Например, подключается какая-то Amazon-овская служба к нескольким узлам Dynamo и получает от каждого узла SLA. Используются ли эти SLA для распределения запросов по узлам? Или может ли узел Dynamo динамически изменять свой SLA в зависимости от количества подключившихся к нему клиентов? Скажем, первому он обеспечивает отклик в 300ms, второму – всего лишь 450, а третьему – жалкие 800ms? К сожалению, в статье об этом не говорится.
Два способа общения с узлами Dynamo. Когда какой-нибудь сервис хочет воспользоваться услугами Dynamo, он имеет выбор: либо подключиться через Dynamo-вский балансировщик нагрузки, либо использовать специальную клиентскую библиотеку. Если работать через балансировщик, то запрос проходит дополнительную стадию – выбор узла для обработки запроса. А в случае клиентской библиотеки этой стадии нет, и запрос сразу же направляется нужному узлу. Что может уменьшать время выполнения запроса в два и более раз.
Выбор узла для чтения значения. Для того, чтобы оптимизировать распределение запросов между узлами, в Dynamo применяется простой трюк: координатором для операции read назначается узел, который до этого выполнял координацию операции write. Т.е. если клиент записал объект X и координатором выступал узел N, то при последующем чтении объекта X (которое, как правило, сразу же следует за записью), узел N будет координатором операции чтения.
Read repair. Когда координатор операции read принимает ответы от реплик, он не сразу прекращает прием ответов. Вместо этого он еще некоторое время ждет ответы от всех узлов и проверяет полученные версии. Если какой-то узел присылает устаревшую версию (т.е. узел по какой-то причине пропустил обновление объекта), то на узел отсылается новая версия объекта. Эта операция называется read repair и используется она для уменьшения энтропии в случае рассогласования реплик.
Детали реализации. Все службы Amazon’s Dynamo написаны на Java. При реализации использовался событийно-ориентированный подход и организация очередей сообщений между стадиям обработки запросов по образу SEDA. В качестве хранилищ информации используются Berkeley Database Transactional Data Store, Berkeley Database Java Edition, MySQL и in-memory буфера с периодическим сбрасыванием содержимого на диск. BDB используется для хранения объектов, не превышающих размеров более нескольких десятков килобайт, тогда как MySQL задействуется для объектов большего размера. Большинство узлов Dynamo задействуют BDB Transactional Data Store.
Конечные автоматы в рамках Dynamo. Каждый запрос от клиента приводит к запуску нового экземпляра конечного автомата (по сути агента, а это не могло оставить меня равнодушным). Этот КА отслеживает все стадии обработки запроса. Один запрос – один КА. Подозреваю, что такие КА весьма легковесны и на одном узле их можно создавать сотнями тысяч.
PS. Вот, собственно, и все. Приношу читателям свои извинения за то, что рассказ об Amazon’s Dynamo затянулся на два месяца. Надеюсь, что данная серия заметок была интересной.
Комментариев нет:
Отправить комментарий