Пытался найти хоть один график, вдруг сохранился....но большую часть метрик мы уже флашнули. а что не флашнули - timeSeries схлопнула, и стало не очень нагялдно
Наших объемах фон ошибок уменьшился от 10% до 200% (то есть физически ошибок стало до 2х раз меньше)
Я легко могу представить больше одного сценария когда это оправдано. К примеру это требование сертификации при работе с персональными данными. Или желание защитить свои данные когда используешь не свое железо( MIM атаку никто не отменял)
Это вполне себе реальные риски. И прежде чем решить - http\https их надо оценить.
Рассматривали. И даже в ряде сценариев используем.
Но этот способ не очень подходит для интерактивных типов запросов - пока положишь в очередь пока вычитают, поработают, положат обратно, пока прочитаешь ответ.. + нужно вычитать именно свой ответ а не ответ на другой запрос, и оверхед от самой очереди..
Теперь абстратная Я.Недвижимость сможет делать обзвон клиентов абстрактного Cian и легально предлагать им перенос на свою площадку.
Раньше это было на грани законности, теперь-же обретает вполне легальный статус
> Чтобы избежать этого, имеет смысл использовать HPA
все вместе будет требовать определенного тюнинга каждого сервиса.
и доп тюнинга по мере развития проекта. ну и всегда есть шанс словить маркетинговую акцию и тупить пока развернуться до ядра.
В общем — это полезная штука, но использовать надо очень даже с умом.
Конечно можно положит по контейнеру с редисом в каждую реплику-)
Но тогда мы получим независимые кеши на каждой реплике а это не будет принципиально отличаться от memory кеширования в самом GO. Только больше CPU потратим.
Есть ли статистика hit/miss
Вы правы, говоря что каждый из 3-х реплик будет иметь независимый кеш. И что hit\miss считать нужно, дабы понимать эффективность всей этой истории.
И у нас она есть, и мы ее мониторим.
Но в целом — статья про работу планировщика в GO и нюансы профилирования, а не про
1) Коммуникации внутри одного хоста тоже совсем не бесплатные. Хоть они и ничтожны по-сравнению с сетью, но все-же гораздо выше чем inmemory
Второй момент — сервис запущен в нескольких экземплярах на физически-разных машинах (повышаем отказоустойчивость). Отсюда только одна реплика сервиса работает без сетевого оверхеда.
Третий момент k8s — он базово не гарантирует что после раскатки новой версии сервис не окажется на другой машине (на самом деле почти наверняка окажется).
2) Вероятно вы предлагаете использовать tarantool как application вместо GO. Tarantool не сильно cloud native. Готовить его так, чтобы ты мог в любой момент изменить количество реплик сервиса, и не терять стейт при перевыкатке или disaster крайне не просто. Ну и в итоге — мы получим все то-же inmemory хранилище как и в Go. Просто несколько более оптимизированное.
Тут нам на помощи приходит механизм Readiness Probe и градуальная выкатка в k8s
Сначала поднимается одна новая реплика. Она прогревает кое-какой кеш. И только после этого она помечается как Redy, и заменяет одну старую.
Это отличный комментарий, спасибо.
Все рекомендации из The Twelve Factor App — действительно толковые.
Но не стоит их воспринимать и следовать им с библейской точностью.
Кеш, липкие сессии и прочее в среднем нарушают ряд факторов, это верно.
И за нарушение надо платить. К примеру меньшей консистентностью. Но если для бизнес-задачи оно не критично, но позволяет повысить надежность в разы, снизя утилизацию ресурсов…
Почему-бы и нет?
Можно.
Но кажется вся идея k8s как раз про то, чтобы достаточно плотно напихивать сервисы в кластер.
А прибить к сервису пачку ядер, которые и не будут утилизироваться в 50% времени, и все-равно не решить задачу из статьи…
Авито делает микросервисы на PHP, Golang, Python
Может просто вы не умеете PHP готовить?
Ну и исторически - наше монолитное приложение написано на PHP, и портировать код не еняя язык в разы дешевле-)
Пытался найти хоть один график, вдруг сохранился....но большую часть метрик мы уже флашнули. а что не флашнули - timeSeries схлопнула, и стало не очень нагялдно
Наших объемах фон ошибок уменьшился от 10% до 200% (то есть физически ошибок стало до 2х раз меньше)
Все так. Но даже это позволит писать код, более адаптированный для неблокирующих операций. А там выйдет - найдем куда применить-)
Спасибо!
и в правду.
FIXED
Боюсь я сильно конкретных цифр дать не смогу.
Оно все достаточно специфично под объемы нагрузки. Но из того чем могу поделится - уменьшения рейта ошибок до 5-10%, ускорение примерно до 5%.
Все так, не выйдет.
И поэтому я подсветил что эта опция не для всех подойдет.
И у нас все еще остаются другие способы оптимизации.
Привет.
Я легко могу представить больше одного сценария когда это оправдано. К примеру это требование сертификации при работе с персональными данными. Или желание защитить свои данные когда используешь не свое железо( MIM атаку никто не отменял)
Это вполне себе реальные риски. И прежде чем решить - http\https их надо оценить.
Привет.
Рассматривали. И даже в ряде сценариев используем.
Но этот способ не очень подходит для интерактивных типов запросов - пока положишь в очередь пока вычитают, поработают, положат обратно, пока прочитаешь ответ.. + нужно вычитать именно свой ответ а не ответ на другой запрос, и оверхед от самой очереди..
Раньше это было на грани законности, теперь-же обретает вполне легальный статус
все вместе будет требовать определенного тюнинга каждого сервиса.
и доп тюнинга по мере развития проекта. ну и всегда есть шанс словить маркетинговую акцию и тупить пока развернуться до ядра.
В общем — это полезная штука, но использовать надо очень даже с умом.
Но тогда мы получим независимые кеши на каждой реплике а это не будет принципиально отличаться от memory кеширования в самом GO. Только больше CPU потратим.
Вы правы, говоря что каждый из 3-х реплик будет иметь независимый кеш. И что hit\miss считать нужно, дабы понимать эффективность всей этой истории.
И у нас она есть, и мы ее мониторим.
Но в целом — статья про работу планировщика в GO и нюансы профилирования, а не про
Второй момент — сервис запущен в нескольких экземплярах на физически-разных машинах (повышаем отказоустойчивость). Отсюда только одна реплика сервиса работает без сетевого оверхеда.
Третий момент k8s — он базово не гарантирует что после раскатки новой версии сервис не окажется на другой машине (на самом деле почти наверняка окажется).
2) Вероятно вы предлагаете использовать tarantool как application вместо GO. Tarantool не сильно cloud native. Готовить его так, чтобы ты мог в любой момент изменить количество реплик сервиса, и не терять стейт при перевыкатке или disaster крайне не просто. Ну и в итоге — мы получим все то-же inmemory хранилище как и в Go. Просто несколько более оптимизированное.
Сначала поднимается одна новая реплика. Она прогревает кое-какой кеш. И только после этого она помечается как Redy, и заменяет одну старую.
Ничего в процессе не подтормаживает.
Все рекомендации из The Twelve Factor App — действительно толковые.
Но не стоит их воспринимать и следовать им с библейской точностью.
Кеш, липкие сессии и прочее в среднем нарушают ряд факторов, это верно.
И за нарушение надо платить. К примеру меньшей консистентностью. Но если для бизнес-задачи оно не критично, но позволяет повысить надежность в разы, снизя утилизацию ресурсов…
Почему-бы и нет?
Но кажется вся идея k8s как раз про то, чтобы достаточно плотно напихивать сервисы в кластер.
А прибить к сервису пачку ядер, которые и не будут утилизироваться в 50% времени, и все-равно не решить задачу из статьи…
В тему «большинства решений в го» — лично у меня статистики нет. Но популярные библиотеки, в которых такая проблема есть встречаются
sql задач вроде не стоит. Но на пустом месте ловим io нагрузку+сериализация — десериализация.
И чудовищная неэффективность — чисто из-за того что кешируем много маленьких объектов, и порождаем тонну указателей
Когда строгая консистентность не требуется — мемори-кеширование выгоднее