Авторизацию включили чуть раньше, но действительно было время, когда общего решения действительно не было. И приходилось контролировать, что туда не попадут персональные данные и другая чувствительная информация.
Вместо того, чтобы отправлять эти данные приходилось, например, отправлять только идентификатор события, а сами данные отдавать синхронно по gRPC. Редко применялись такие методики, как шифрование данных или подпись каждого сообщения.
Ну и некоторые данные доставлялись в отдельных кластерах Kafka. Так есть и сейчас, например, общая кафка, конечно, никак не касается банковского контура.
У нас довольно много партиций в кластере (более 100 000) и во время отключения/включения датацентра нагрузка на него очень существенная. Мы хотели как можно меньше нагружать ZK дополнительно. В моменте — это была главная причина.
Если говорить о стратегии, то мы отказываемся от kafka на ZK в пользу kraft. Кроме того, уходим от концепции единого кластера, к концепции нескольких инстоляций под единым прокси-сервисом. Так, чтобы для пользователей это все еще была единая большая кафка. Не могу сказать, что в этом случае, ваш вариант нельзя использовать. Но там сложность так же вырастает.
Ну и третья причина, которую я не стал описывать в статье — в Озоне есть единый подход к внутренней аутентификации сервисов друг в друга и в инфраструктуру и мы хотели, чтобы с кафкой он был таким же.
Но спасибо вам большое за комментарий — кому-то из читателей он может оказаться очень полезным.
Мы используем Kafka с ZooKeeper" - действительно, зачем современные подходы с KRaft
KRAFT — не решает те проблемы о которых я писал в статье. Но решаеттт другие. Поэтому да, мы в процессе миграции. Об этом, возможно, будет другая статья.
Те действия по аутентификации и авторизации, которые были предприняты, все равно оставляют у клиента монопольный доступ к топику
Все верно, доступы каждого клиента мы делим только на RO/RW для всего топика целиком. При этом, стоит пояснить, что «клиент» — это сервис в кубере. Никто больше не может представится этим клиентом. На продакшен окружении в эти поды нет доступа у разработчиков. То есть разработчик доступ к данным получить не может (этим механизмом). Код же клиента мы считаем доверенным, т.к. он прошел все нужные процедуры до попадания в продакшен.
Но у Озона вроде как есть даже Банк? Ну понятен теперь уровень этого "Банка".
У банка отдельный контур и отдельная кафка. Но я все еще не совсем понимаю какую дополнительную безопасность обеспечивает подпись каждого сообщения в общем случае.
"TLS-клиентская аутентификация даёт overhead на потребление CPU" - ну это примерно то же самое, что сказать "https даёт overhead на потребление CPU". Короче, другими словами Озон "не смог в TLS".
Причем тут «смог» или «не смог». В этом блоке я просто перечислял плюсы и минусы разных подходов. Выбранный подход имеет ряд преимуществ.
Если бы вы делали все по правильному, то надо было настроить автоматическую ротацию TLS-сертификатов, и сделать у них маленький срок жизни.
Действительно, так можно было сделать. Буду рад, если приведете какие-то дополнительные аргументы «правильности» такого подхода. Нам он показался существенно более сложным и дающим дополнительные риски.
это стандартный вопрос на собеседовании "соотношение консьюмеров и партиций в кафка", и стандартный ответ, что одних должно быть в 10 раз больше, чем других, из соображений перебалансировки.
Очень спорное утверждение. Количество подов сервиса — это сложны баланс между стабильностью, балансировкой и потреблением ресурсов. Да, периодически делают количество консьюмеров больше, чем число партиций для того, чтобы не возникло проблем при временной недоступности части подов. Но это имеет смысл тогда, когда основаная нагрузка сервиса — обработка асинхронных сигналов.
Зачем нужен запас x10 мне точно не понятно. Наоборот, ребаланс группы будет происходить значительно дольше, т.к. при стандартном ассайменте каждый вход/выход клиента из консьюмер-группы будет приводить к полному ребалансу группы и простою чтения.
Вот, честно, прочитайте про "Staging-production Deployment", и при выкладке на продакшен ни у кого никаких капель пота с лица стекать не будет.
Рад, что вас так захватило повествование, что вы не заметили моего художественного вымысла в этом месте. Но поясню — эта сцена была мной добавлена для того, чтобы статья чуть легче читалась к концу.
Короче, совет Озону, возьмите в штат нормального архитектора (с ЗП от 500К), и большей части проблем избежите.
Спасибо за совет. Но более конструктивно было бы обсудить то, а какие, собственно, проблемы мы не решили. Предлагаю продолжить диалог о них.
В целом, можно представить себе автоматизацию такого переезда: синхронизировать текущее состояние ACL с ролями во внешней IAM системе. И дальше аналогично описанному переключать клиентов.
Но, на самом деле, в нашей конфигурации и объемах ACL могли бы вообще не завестись, как основное решение, т.к. это создало бы большую нагрузку на ZK, который очень ограниченно масштабируется.
Другими словами, в условиях кадрового голода ваша команда, во-первых, не должна размениваться на мелочи — только фокусироваться на самых ценных задачах; во-вторых, вы должны быть уверены, что ваше производство эффективно.
Я бы тут несколько иначе сформулировал: Вам придется выбирать приоритеты. Если раньше вы могли сделать все, что вам поручают. То теперь команда не может сделать абсолютно все, что от нее хотят. И отказываться от чего-то — важная часть вашей работы.
По количеству брокеров. Во-первых, у нас нагрузка на которую рассчитан кластер в rps не полтора миллиона, а на порядок больше. По трафику так же нужно смотреть — как правило пишут большими батчами, а не по одному сообщению. Это наша общая рекомендация для сервисов. Размеры батчей до 50Мб доходят. Во-вторых, у нас все рассчитано на падения одного из трех ДЦ, в которых расположена Кафка. Третий момент — нужно смотреть конфигурацию, например у нас довольно много ресурсов заложено на TLS, на работу внутренних экспортеров. Ну и последний момент, число 75 условное.
Потому что мы все еще хотим предоставлять шину данных с гарантиями at least once. И она все еще должна уметь хорошо горизонтально масштабироваться, для того, чтобы быть общим ресурсом для огромного количества сервисов. И, конечно, поддерживать возможность горизонтального масштабирования самих сервисов.
Я специально писал статью про DnD, как самый популярный представитель жанра. Чтобы было понятнее широкому кругу читателей. И да, как правило, я использую свою систему dnd-based.
Но статья совсем не про это. А про мой опыт использования Настольных ролевых игр для разных команд. Обратите внимания, что в статье нет абсолютно ничего Dnd-специфичного. Я пробовал адаптировать и другие системы. Или брать конкретные механики из разных систем и даже из настольных игр. С точки зрения методологии все работает так же.
В статье речь шла о разовых играх. Для того чтобы собраться один раз на 2,5 часа, на мой взгляд, не нужно бросать все свои остальные занятия и даже сильно двигать приоритеты. В конце концов, я каждый год вижу, как почти все собираются на новогодний корпоратив на 4-6 часов без зазрения совести.
Регулярные игры — другой разговор. Но это и совсем другой инструмент. Возможно, достойный отдельной статьи.
По поводу времени — это все вопрос договоренностей. Конечно, если речь о каком-то аврале или самом разгаре сезона, то рабочее время на вес золота, а в нерабочее нужно дать команде отдохнуть. Но бо́льшую часть времени такого нет. И с любым руководителем можно договориться, чтобы он выделили время на командную активность. Собственно, так ведь работает с любыми тимбилдингами/мероприятиями, разве нет?
Я говорил в статье, что метод подходит не всем. Никакой обязаловки. Да, я могу предложить. А любой член команды может отказаться. Это нормально. У нас же нет «игр в D&D» в должностной инструкции.
Отвечу по пунктам: 1) Я не могу сказать, что у меня всегда получается с первого раза. Для статьи я отобрал удачные и разнообразные кейсы. Но были и менее удачные, если честно. И да, конечно опыт помогает — с каждым разом вероятность успеха все выше.
2) Если вы хотите конкретных рекомендаций, то для sci-fi мой фаворит Starfinder, для п/а Точка отсчета(Мутанты) Но вариантов много. В том числе, существуют соответствующие модификации D&D
Ну, или это могут быть разные люди — мастер игры и тот, кто дает обратную связь. Хотя на моей практике, обе роли всегда я играю. Поэтому тут мне трудно советовать.
Да, можно. Но важно, чтобы и у команды было такое желание. «Втихую» никого научить не выйдет. Можно без дополнительного обсуждения с помощью игры показать человеку, что тот или иной мягкий навык важен. Например, часто инженеры недооценивают возможности решения проблем с помощью переговоров.
А если член вашей команды сам готов развиваться в эту сторону, то стоит обратить особое внимание на обратную связь после игры — рассказать человеку что он мог бы сделать лучше, а что у него получилось хорошо во время игры, но не всегда так выходит в рабочей жизни.
Для того, чтобы не было таких конфузов, я заранее общаюсь с ребятами. Ну и, конечно, даже если я заранее этого не сделал, всегда можно поправить на ходу. Если видно, что человеку не ловко из-за чего-то, то убрать или поправить этот элемент игры.
Конечно, невозможно предусмотреть всего. И ненароком задеть человека. Но так бывает и в других ситуациях. Действия тоже вполне понятны. Исправить свою оплошность, извиниться.
Именно поэтому я не рекомендую никого «усиленно заставлять» — это во-первых. Во-вторых, не все любят настолки, не все любят сидеть в баре с пивом, не все любят играть в волейбол, не все любят дискотечно-ориентированные корпоративы, не все готовы на байдарках преодолевать речные пороги и так далее. Я только предлагаю еще один инструмент, но не утверждаю, что он универсален. К каждой команде свой подход.
И в-третьих, если кто-то кого-то просит поднажать, то это уже менеджерский косяк, если не сказать более грубо. В этой ситуации управленец должен признать проблему, сам перейти в антикризисный режим и пытаться выйти из сложившейся ситуации как можно скорее и с меньшими потерями.
К сожалению, совсем уж насильно не выйдет. Но можно попробовать с ним договориться, пояснив почему вы считаете, что это важно. Можно предоставить социальное доказательство — сыграть сначала без него и показать что это нормально и всем все понравилось, фоточку выложить.
Решение вашего вопроса лежит не в плоскости Кафки. Кафка не создана для того чтобы ограничивать потоки, наоборот, ее задача прогонять через себя как можно больше и как можно надежнее.
Из вашего сообщения непонятно где вы хотите избежать пика нагрузки на вторую базу или на вашу систему аналитики и преобразований? Если первое, то ковыряйте настройки debezium. Если не выйдет — придумывайте костыли с дополнительной табличкой в первой базе, куда перекладывайте из первой, например, процедурами. Мне такой подход совершенно не нравится, но это можно реализовать. На крайняк, троттлите сеть. Но лучше, конечно, свой продюсер написать, на котором вы будете контролировать скорость вычитки из базы и записи в Кафку.
Если вы хотите избежать нагрузки на вашу систему обработки. Тогда именно там это и нужно делать. Сделайте так, чтобы ваша система обработки/аналитики не забирала сразу все, а делала это постепенно.
А можете подробнее пояснить какая у вас проблема, какую задачу вы решаете? Зачем понадобилось лимитировать?
В мире Кафки принято решать все логические вопросы на стороне клиента. Соответственно, вы можете ограничить скорость вычитывания на консьюмере. Но непонятно зачем это нужно.
linger.ms и batch.size нужны для того, чтобы отправлять сообщения не по одному, а батчами. На суммарное количество/объем сообщений от продюссера не влияют.
Авторизацию включили чуть раньше, но действительно было время, когда общего решения действительно не было. И приходилось контролировать, что туда не попадут персональные данные и другая чувствительная информация.
Вместо того, чтобы отправлять эти данные приходилось, например, отправлять только идентификатор события, а сами данные отдавать синхронно по gRPC. Редко применялись такие методики, как шифрование данных или подпись каждого сообщения.
Ну и некоторые данные доставлялись в отдельных кластерах Kafka. Так есть и сейчас, например, общая кафка, конечно, никак не касается банковского контура.
У нас довольно много партиций в кластере (более 100 000) и во время отключения/включения датацентра нагрузка на него очень существенная. Мы хотели как можно меньше нагружать ZK дополнительно. В моменте — это была главная причина.
Если говорить о стратегии, то мы отказываемся от kafka на ZK в пользу kraft. Кроме того, уходим от концепции единого кластера, к концепции нескольких инстоляций под единым прокси-сервисом. Так, чтобы для пользователей это все еще была единая большая кафка. Не могу сказать, что в этом случае, ваш вариант нельзя использовать. Но там сложность так же вырастает.
Ну и третья причина, которую я не стал описывать в статье — в Озоне есть единый подход к внутренней аутентификации сервисов друг в друга и в инфраструктуру и мы хотели, чтобы с кафкой он был таким же.
Но спасибо вам большое за комментарий — кому-то из читателей он может оказаться очень полезным.
Хороший вопрос. Мы подумаем про это )
Спасибо за подробный разбор. Отвечу по пунктам.
KRAFT — не решает те проблемы о которых я писал в статье. Но решаеттт другие. Поэтому да, мы в процессе миграции. Об этом, возможно, будет другая статья.
Все верно, доступы каждого клиента мы делим только на RO/RW для всего топика целиком. При этом, стоит пояснить, что «клиент» — это сервис в кубере. Никто больше не может представится этим клиентом. На продакшен окружении в эти поды нет доступа у разработчиков. То есть разработчик доступ к данным получить не может (этим механизмом). Код же клиента мы считаем доверенным, т.к. он прошел все нужные процедуры до попадания в продакшен.
У банка отдельный контур и отдельная кафка. Но я все еще не совсем понимаю какую дополнительную безопасность обеспечивает подпись каждого сообщения в общем случае.
Причем тут «смог» или «не смог». В этом блоке я просто перечислял плюсы и минусы разных подходов. Выбранный подход имеет ряд преимуществ.
Действительно, так можно было сделать. Буду рад, если приведете какие-то дополнительные аргументы «правильности» такого подхода. Нам он показался существенно более сложным и дающим дополнительные риски.
Очень спорное утверждение. Количество подов сервиса — это сложны баланс между стабильностью, балансировкой и потреблением ресурсов. Да, периодически делают количество консьюмеров больше, чем число партиций для того, чтобы не возникло проблем при временной недоступности части подов. Но это имеет смысл тогда, когда основаная нагрузка сервиса — обработка асинхронных сигналов.
Зачем нужен запас x10 мне точно не понятно. Наоборот, ребаланс группы будет происходить значительно дольше, т.к. при стандартном ассайменте каждый вход/выход клиента из консьюмер-группы будет приводить к полному ребалансу группы и простою чтения.
Рад, что вас так захватило повествование, что вы не заметили моего художественного вымысла в этом месте. Но поясню — эта сцена была мной добавлена для того, чтобы статья чуть легче читалась к концу.
Спасибо за совет. Но более конструктивно было бы обсудить то, а какие, собственно, проблемы мы не решили. Предлагаю продолжить диалог о них.
В целом, можно представить себе автоматизацию такого переезда: синхронизировать текущее состояние ACL с ролями во внешней IAM системе. И дальше аналогично описанному переключать клиентов.
Но, на самом деле, в нашей конфигурации и объемах ACL могли бы вообще не завестись, как основное решение, т.к. это создало бы большую нагрузку на ZK, который очень ограниченно масштабируется.
Я бы тут несколько иначе сформулировал: Вам придется выбирать приоритеты.
Если раньше вы могли сделать все, что вам поручают. То теперь команда не может сделать абсолютно все, что от нее хотят. И отказываться от чего-то — важная часть вашей работы.
По количеству брокеров. Во-первых, у нас нагрузка на которую рассчитан кластер в rps не полтора миллиона, а на порядок больше. По трафику так же нужно смотреть — как правило пишут большими батчами, а не по одному сообщению. Это наша общая рекомендация для сервисов. Размеры батчей до 50Мб доходят. Во-вторых, у нас все рассчитано на падения одного из трех ДЦ, в которых расположена Кафка. Третий момент — нужно смотреть конфигурацию, например у нас довольно много ресурсов заложено на TLS, на работу внутренних экспортеров. Ну и последний момент, число 75 условное.
Про повторы. Вероятно, вы путаете нашу статью с аналогичной от Авито. У них похожий подход и они пишут о нем периодически, например, тут
https://habr.com/ru/companies/avito/articles/655553/
Не скрою, мы вдохновлялись этими материалами, прежде чем разрабатывать свою систему.
Потому что мы все еще хотим предоставлять шину данных с гарантиями at least once. И она все еще должна уметь хорошо горизонтально масштабироваться, для того, чтобы быть общим ресурсом для огромного количества сервисов. И, конечно, поддерживать возможность горизонтального масштабирования самих сервисов.
Я специально писал статью про DnD, как самый популярный представитель жанра. Чтобы было понятнее широкому кругу читателей. И да, как правило, я использую свою систему dnd-based.
Но статья совсем не про это. А про мой опыт использования Настольных ролевых игр для разных команд. Обратите внимания, что в статье нет абсолютно ничего Dnd-специфичного. Я пробовал адаптировать и другие системы. Или брать конкретные механики из разных систем и даже из настольных игр. С точки зрения методологии все работает так же.
В статье речь шла о разовых играх. Для того чтобы собраться один раз на 2,5 часа, на мой взгляд, не нужно бросать все свои остальные занятия и даже сильно двигать приоритеты. В конце концов, я каждый год вижу, как почти все собираются на новогодний корпоратив на 4-6 часов без зазрения совести.
Регулярные игры — другой разговор. Но это и совсем другой инструмент. Возможно, достойный отдельной статьи.
По поводу времени — это все вопрос договоренностей. Конечно, если речь о каком-то аврале или самом разгаре сезона, то рабочее время на вес золота, а в нерабочее нужно дать команде отдохнуть. Но бо́льшую часть времени такого нет. И с любым руководителем можно договориться, чтобы он выделили время на командную активность. Собственно, так ведь работает с любыми тимбилдингами/мероприятиями, разве нет?
Я говорил в статье, что метод подходит не всем. Никакой обязаловки. Да, я могу предложить. А любой член команды может отказаться. Это нормально. У нас же нет «игр в D&D» в должностной инструкции.
Отвечу по пунктам:
1) Я не могу сказать, что у меня всегда получается с первого раза. Для статьи я отобрал удачные и разнообразные кейсы. Но были и менее удачные, если честно. И да, конечно опыт помогает — с каждым разом вероятность успеха все выше.
2) Если вы хотите конкретных рекомендаций, то для sci-fi мой фаворит Starfinder, для п/а Точка отсчета(Мутанты)
Но вариантов много. В том числе, существуют соответствующие модификации D&D
Ну, или это могут быть разные люди — мастер игры и тот, кто дает обратную связь. Хотя на моей практике, обе роли всегда я играю. Поэтому тут мне трудно советовать.
Да, можно. Но важно, чтобы и у команды было такое желание. «Втихую» никого научить не выйдет. Можно без дополнительного обсуждения с помощью игры показать человеку, что тот или иной мягкий навык важен. Например, часто инженеры недооценивают возможности решения проблем с помощью переговоров.
А если член вашей команды сам готов развиваться в эту сторону, то стоит обратить особое внимание на обратную связь после игры — рассказать человеку что он мог бы сделать лучше, а что у него получилось хорошо во время игры, но не всегда так выходит в рабочей жизни.
Для того, чтобы не было таких конфузов, я заранее общаюсь с ребятами. Ну и, конечно, даже если я заранее этого не сделал, всегда можно поправить на ходу. Если видно, что человеку не ловко из-за чего-то, то убрать или поправить этот элемент игры.
Конечно, невозможно предусмотреть всего. И ненароком задеть человека. Но так бывает и в других ситуациях. Действия тоже вполне понятны. Исправить свою оплошность, извиниться.
Именно поэтому я не рекомендую никого «усиленно заставлять» — это во-первых. Во-вторых, не все любят настолки, не все любят сидеть в баре с пивом, не все любят играть в волейбол, не все любят дискотечно-ориентированные корпоративы, не все готовы на байдарках преодолевать речные пороги и так далее. Я только предлагаю еще один инструмент, но не утверждаю, что он универсален. К каждой команде свой подход.
И в-третьих, если кто-то кого-то просит поднажать, то это уже менеджерский косяк, если не сказать более грубо. В этой ситуации управленец должен признать проблему, сам перейти в антикризисный режим и пытаться выйти из сложившейся ситуации как можно скорее и с меньшими потерями.
К сожалению, совсем уж насильно не выйдет. Но можно попробовать с ним договориться, пояснив почему вы считаете, что это важно. Можно предоставить социальное доказательство — сыграть сначала без него и показать что это нормально и всем все понравилось, фоточку выложить.
А пока бот в разработке/отладке вы переключаете вебхук на локальную машину? Или каждый раз деплоитесь, чтобы протестировать?
Решение вашего вопроса лежит не в плоскости Кафки. Кафка не создана для того чтобы ограничивать потоки, наоборот, ее задача прогонять через себя как можно больше и как можно надежнее.
Из вашего сообщения непонятно где вы хотите избежать пика нагрузки на вторую базу или на вашу систему аналитики и преобразований? Если первое, то ковыряйте настройки debezium. Если не выйдет — придумывайте костыли с дополнительной табличкой в первой базе, куда перекладывайте из первой, например, процедурами. Мне такой подход совершенно не нравится, но это можно реализовать. На крайняк, троттлите сеть. Но лучше, конечно, свой продюсер написать, на котором вы будете контролировать скорость вычитки из базы и записи в Кафку.
Если вы хотите избежать нагрузки на вашу систему обработки. Тогда именно там это и нужно делать. Сделайте так, чтобы ваша система обработки/аналитики не забирала сразу все, а делала это постепенно.
А можете подробнее пояснить какая у вас проблема, какую задачу вы решаете? Зачем понадобилось лимитировать?
В мире Кафки принято решать все логические вопросы на стороне клиента. Соответственно, вы можете ограничить скорость вычитывания на консьюмере. Но непонятно зачем это нужно.
linger.ms и batch.size нужны для того, чтобы отправлять сообщения не по одному, а батчами. На суммарное количество/объем сообщений от продюссера не влияют.