Zalando

На этой неделе наших соцсетях выступал Евгений Канашевский, экономист из Zalando, Economics Phd университета Штата Пенсильвания.

На работе Женя занимается установлением причинно-следственных связей в онлайн-рекламе с помощью экспериментальных и квазиэкспериментальных методов и моделей машинного обучения.

Делимся с вами расшифровкой эфира.

---

Меня зовут Евгений Канашевский. Сегодня мы поговорим о том, за что IT-компании платят экономистам, о том, чем экономисты отличаются от обычных data scientist-ов, и ответим на интересные вопросы вроде сколько стоит человеческая жизнь?, которыми занимаются экономисты.

Для начала я представлю себя. Я сейчас работаю экономистом/data scientist-ом в большой компании Zalando. Это онлайн-магазин, который продает одежду, обувь, косметику в 16 странах Европы и планирует расширение на новые рынки. До того, как я присоединился к Zalando в 2020 году, я делал PhD по экономике в университете штата Пенсильвания. Я начал интересоваться экономикой задолго до этого, когда учился в МФТИ и потом также в Российской экономической школе.

До того, как поехать на PhD по экономике, я работал 2 года в агентстве контекстной рекламы в Москве; очень сильно хотел узнать больше о том, что такое экономика и как она устроена. Чтобы утолить свою жажду, я поехал в итоге на PhD. Сейчас я надеюсь поделиться с вами этим знанием. Надеюсь, вам будет интересно, и мы поймем, зачем бизнесу экономисты.

Для начала попробуем развенчать некоторые устоявшиеся представления об экономистах, которые, исходя из моего опыта, присутствуют в России. Многие из вас, наверно, брали курсы экономики в университете, и вы помните, что проходили рыночное равновесие, кривые спроса и предложения. Кто-то из вас, может быть, проходил макроэкономический баланс разного рода из чего состоит ВВП, как считать его, что будет с ВВП в случае, если государство потратит столько-то денег, какие налоги собираются с населения. На такие вопросы вы, возможно, отвечали на курсах экономики в университете, и немногие из нас продвигались дальше.

Устоявшееся мнение об экономистах состоит в том, что они работают в научных институтах (РЭШ, ВШЭ) или международных организациях (МВФ, Мировой банк, Организация экономического содействия и развития), и там они помогают странам вырваться из ловушки бедности и провести экономические реформы. Они могут работать в государственных организациях центральных банках, министерствах экономического развития своих стран. Если они супер-амбициозны, то они могут попробовать стать экономическим советником президента США. Стереотипное представление об экономистах в индустрии состоит в том, что в индустрии они работают в банковской сфере и в финансовой сфере.

Я часто встречал такое дефолтное представление об экономистах что они занимаются только этими вещами. На самом деле, экономическая наука гораздо шире. Она занимается самыми разными интересными вопросами, связанными с людьми, и поэтому бизнесы нанимают их.
Давайте посмотрим, какие вопросы задают экономисты. На эти вопросы даются ответы, по ним читаются лекции на курсах экономики, в бакалавриате.

Один из фундаментальных вопросов, на которые ищут ответы экономисты, звучит так: Почему одни страны богатые, а другие бедные. Это вопрос вида что было раньше яйцо или курица? Что было раньше: экономический рост или демократические институты? Страны англосаксонского мира такие богатые, потому что они установили у себя демократические институты (разделение властей, независимая законодательная власть, независимая судебная система, отделенные от исполнительной власти) и поэтому стали такими богатыми впоследствии, смогли расти экономически? Или все наоборот: эти страны росли экономически, и потом, став богатыми, решили установить у себя демократические институты? Это нетривиальный вопрос, на него очень сложно ответить. Этот вопрос существенен для многих стран: например, Китай это страна, чья экономика растет очень быстро. Сможет ли она расти дальше теми же темпами, и нужны ли Китаю эти самые демократические институты, либо Китай сможет продолжать расти в достаточно недемократичной среде?

Этот вопрос был актуален и раньше. В первой половине XX века СССР развивался очень быстро, возможно, быстрее, чем страны западного мира. Экономисты задавались вопросом сможет ли СССР расти так и дальше, этот вопрос был крайне важен стратегически во время Холодной войны. Дальнейшая история показала, что СССР не смог продолжать свое экономическое развитие, и консенсус среди экономистов состоит в том, что это было невозможно из-за отсутствия демократических институтов и рыночных механизмов экономики.

Такими вопросами задаются экономисты. Эти вопросы сложны, потому что в мире не так уж и много стран; невозможно заглянуть в параллельную вселенную, где СССР развивался бы с применением рыночных механизмов экономики и демократических институтов. Помимо вопросов в глобальном масштабе, экономисты задаются и более повседневными вопросами, которые имеют хорошую практическую ценность. Например как выгодно продать радиочастоты в нескольких штатах США. Представьте себе: вы владеете определенным диапазоном радиочастот (вы представляете государство). Вы хотите продать их наиболее выгодным способом так, чтобы максимально принести денег в бюджет. Возникает вопрос: как устроить механизм, с помощью которого вы будете это делать? Экономисты предлагают использовать аукционы, чтобы продавать частоты; это кажется логичным, если вспомнить, как продаются произведения искусства, например. Но тогда возникает следующий вопрос: как оптимально устроить аукцион, чтобы получить в бюджет максимально много денег?

Это звучит абстрактно но подумайте, например, о таких явлениях, как сговор. Покупатели на аукционе могут сговориться у вас за спиной и сказать: давай я куплю эти частоты, а ты эти, и ты поставишь низкую ставку на одни диапазоны, а я на другие. И тогда они заплатят как можно меньше. Задача экономистов в том, чтобы не допускать таких сговоров и обеспечивать государству как можно больше денег в бюджет, который будет использован на благо граждан.

Другой пример интересного вопроса, которым задаются экономисты: Как устроить рынок пересадки почек, чтобы спасти как можно больше людей? Слово рынок здесь звучит не очень хорошо с моральной точки зрения, если вы не экономист; скорее всего, это слово здесь ассоциируется у вас с нелегальным рынком, с продажей почек, что является преступлением. Но, когда я сейчас говорю о рынке, я имею в виду то, что существует спрос на почки: есть люди, которым нужны почки, и есть люди, которые готовы предложить свою почку потому что человек может нормально жить с одной почкой.

Представьте гипотетическую ситуацию: вашей жене (мужу, девушке, парню, родителю) нужна почка, и вы готовы ее отдать. Но дело в том, что необходима совместимость. Вашему близкому человеку может просто не подойти ваша собственная почка. Что можно сделать: можно найти такую же пару людей (может быть, из другого города, региона или страны), которые несовместимы между собой, но при этом ваша почка может подойти нуждающемуся человеку из другой пары и наоборот. И таким образом у двух людей, у которых раньше не было шансов получить почку, либо им нужно было ждать очень длинной очереди на почку (а это может длиться месяцы или годы), появляется этот шанс благодаря тому, что мы нашли две пары, готовые обменяться почками, на этом рынке почек. Мы помогли людям.

Конечно, ситуация может быть гораздо сложнее. Может быть, вам придется провернуть цепочку из очень многих ходов привлечь очень много пар людей, в которых, когда они все вместе, получится найти такие обмены, чтобы все нуждающиеся люди из этих пар получили почку. Необязательно только две пары. Можно представить пример с тремя парами: почка здорового человека из одной пары подходит нуждающемуся человеку из следующей пары и так далее. Такие циклы могут доходить до 70 пар, на самом деле. Это пример случая, в котором экономисты разработали алгоритм для того, чтобы организовать рынок и помочь людям с пересадкой почек. За это была получена Нобелевская премия по экономике в 2012 году профессором Стэнфордского университета Элом Ротом.

Еще один интересный вопрос, который не совсем очевиден с моральной точки зрения сколько стоит человеческая жизнь. Непонятно с моральной точки зрения, как можно ее вообще оценивать ведь человеческая жизнь бесценна. Но мы можем подумать как экономисты прагматично и практически, где нам может понадобиться оценка человеческой жизни.

Представьте, что вы хотите потратить деньги на улучшение дорог в России. Каждый год на дорогах погибает 15 тысяч человек, примерно. Вы думаете, сколько вы готовы инвестировать в улучшение дорог с точки зрения государства. Хороший способ думать об этом это сколько человеческих жизней спасет такое улучшение дорог. Для хорошей оценки издержек на построение дорог и пользы, которую можно получить от построения дорог, нужна как раз цена человеческой жизни.

Это оценки были сделаны; они были сделаны для США, потому что там есть хорошие данные на самом разном уровне. Эти оценки говорят, что цена человеческой жизни колеблется в диапазоне от 4 до 9 миллионов долларов. Такие оценки, конечно, нужно проецировать на Россию мы должны измерить, как цена человеческой жизни отличается в странах, где люди меньше зарабатывают и приносят меньше ценности. Это очень грубый подсчет, но есть правила пересчета. И, как это ни грубо звучит, цена человеческой жизни в России меньше, чем в Америке, просто из-за того, что экономика в России менее производительна. Но, тем не менее, можно получить какие-то оценки и с помощью этого решать практические вопросы например, сколько мы готовы тратить на улучшение безопасности на дорогах, чтобы терять меньше людей.

Итак, надеюсь, примерно стало понятно: экономисты занимаются самыми разными вопросами, но общее в этих вопросах то, что мы везде изучаем не предметы материального мира (как физики, например), а живых людей. Экономисты изучают стимулы людей как устроены люди, какие решения они принимают.

Где работают экономисты помимо международных организаций, научных институтов, госорганизаций и банков? Экономисты работают в отраслевом консалтинге, в основном в разных консалтинговых фирмах. Все больше и больше работают в больших и не очень больших IT-компаниях. Просто чтобы назвать пример самых больших компаний это Google, Amazon, Uber, Facebook; компания, в которой работаю я (Zalando) это e-commerce-компания, у которой есть собственная команда экономистов для решения задач о поведении людей. Netflix пример компании, не очень большой по штату сотрудников, которая при этом нанимает экономистов, которые решают очень интересные задачи.

Рынок компаний, которые нанимают экономистов, не ограничивается этими примерами. Но большие компании, которые нанимают много людей в принципе, нанимают все больше и больше экономистов.

Тогда вопрос: зачем IT-бизнесы нанимают экономистов? Односложный ответ чтобы предложить клиенту ценность. То есть, мы исходим из того, что бизнесы хотят предложить клиенту ценность, и для этого они должны понять, как принимают решения клиенты (если обобщить как это делают люди). Это то, чем экономисты занимаются на протяжении последних 100 лет, как минимум. Они изучают то, как люди принимают решения в самых разных ситуациях. Не только на классических рынках, о которых вы можете подумать из вводных курсов экономики, которые у вас были, но и на самых различных рынках и в самых разных ситуациях.

Чтобы ответить более детально на вопрос почему IT-фирмы набирают именно экономистов, разберем три пункта. Во-первых, почему экономисты исследуют, как принимают решения люди в самых разных ситуациях как так получилось, что они этим занимаются и задают странные вопросы (какова ценность человеческой жизни?, как устроить рынок пересадки почек?). Во-вторых, мы разберем 4 вида задач, для которых бизнесу нужны экономисты. И, наконец, мы обсудим, почему бизнесу нужны именно экономисты, а не обычные data scientist-ы: в чем различия между ними.

Пункт первый: почему экономисты отвечают на вопросы о поведении людей? Здесь не помешает немного истории. Экономисты начали изучать рыночное равновесие еще в XVIII веке (как минимум). Они начали задавать вопросы: как устроены рынки, как формируется спрос, как устроено предложение. Они думали о классических рынках давайте представим рынок хлопка или зерна, например. Это не было связано с такими безумными вопросами вроде ценности человеческой жизни. Однако в этих классических рынках равновесие равновесная цена, количество проданных товаров зависело от решений, принимаемых людьми, и от того, какими стимулами руководствуются люди при покупке и продаже товаров. Когда экономисты изучали рыночное равновесие, то для того, чтобы лучше давать ответы на возникающие вопросы, им приходилось разрабатывать достаточно продвинутые математические методы. К XX веку экономисты и математики разрабатывали математические методы для ответов на вопросы, связанные с рыночным равновесием.

Может быть, вы смотрели фильм Игры разума это отличный пример. Это фильм про Джона Нэша, математика, который получил Нобелевскую премию по экономике за свои статьи по теории игр. Она является исходно математическим концептом, но экономисты применяют очень активно наработки Нэша и других математиков и вообще, очень продвинутую математику в изучении рынка. Отчасти поэтому и получилось так, что экономисты способны решать сложные и странные вопросы.

В начале XX века статистика абстрагировалась от изучения причинно-следственных связей. Статистика умышленно стала заботиться лишь о распределениях данных, об условных распределениях, о том, как устроены данные, о том, как, зная одну переменную, предсказать другую (т.е. сказать, какова вероятность того, что случится одно событие при наблюдении другого события). Статистика абстрагировалась от таких вопросов, как как влияет наличие демократических институтов на экономический рост в стране в следующие 100 лет? или в одной стране люди выращивают сельхозкультуры, у которых очень большой размер плантации, и поэтому их выгодно обрабатывать подневольным трудом как рост в этой стране будет отличаться от роста в тех странах, где выращиваются другие культуры например, зерновые с меньшим размером плантации, из-за чего в этих странах много фермеров, а рабовладельческий труд в них был бы не так выгоден, как на плантациях риса или сахарного тростника; как эти факты повлияют на экономический рост в будущем этих стран? (под влиянием понимается причинно-следственная связь).

Экономистам пришлось разрабатывать собственные методы эконометрические методы для ответов именно на вопросы причины и следствие, а не простые вопросы о корреляциях или условных вероятностях. Это произошло в начале XX века. Мы перематываем в последнюю четверть века и понимаем, что экономисты, начиная с XVIII века, разрабатывали математические методы, строгую математику; экономисты, начиная как минимум с XX века, разрабатывали сложные статистические методы, которые помогают более уверенно ответить на вопросы причины и следствия. И мы понимаем, что экономика это та наука, которая помогает ответить на вопросы о поведении людей, и сделать это максимально строго используя максимально высокие стандарты установления причинно-следственной связи.

Чем особенно поведение людей и его изучение? Дело в том, что здесь мы не можем поставить эксперимент. Мы не можем клонировать человека и проверить, что бы случилось с точно таким же человеком, который поступил бы в другой университет, например, и получил менее качественное образование как бы это повлияло на его заработок в будущем. Поэтому экономистам пришлось разрабатывать математические и статистические методы, чтобы понять, как именно решения людей влияют на их будущее и на то, что с ними произойдет.

Это подводит нас к тому, почему IT-компании нанимают экономистов. Я выделил 4 большие области, где работают экономисты в IT-компаниях; это не полный список экономисты занимаются и другими вещами, но эти области уже сформировались.

Первая область оценка спроса на товары или услуги. Здесь можно подумать о многих бизнесах, но я приведу самые яркие примеры. Amazon один из крупнейших онлайн-магазинов (не могу сказать, кто самый крупный Amazon или Alibaba), огромная компания с огромным штатом, которой очень важно оценивать спрос: сколько товаров будет продано, как изменение цен повлияет на продажи. Uber рай для экономистов, потому что у него очень много данных: можно оценивать спрос на такси, можно отвечать на вопросы типа как установить цены на Uber в час пик в центре Манхэттена, как эти цены должны отличаться от цен в другое время в этом же месте; как сделать так, чтобы Uber получил выручку, и при этом люди могли заказать такси и такси к ним приехало. То есть, мы видим, что здесь много людей, и у них разные стимулы: у клиента стимул как можно быстрее и дешевле поехать на такси, Uber и таксист хотят заработать денег.

Второй пример задачи это аукционы. Здесь самые яркие примеры это Google и Yandex, рынки онлайн-рекламы. Каждый раз, когда вы вбиваете в поиск что-либо, проводится маленький аукцион, и кто-то платит за то, чтобы показать вам рекламу. От 70 до 90% выручки материнской компании Google Alphabet приходится на эти аукционы, то есть, Google живет за счет рекламы (Yandex тоже). Экономисты работают над тем, как спроектировать эти аукционы таким образом, чтобы бизнесы не тратили на рекламу лишние деньги, а пользователи получали релевантную рекламу. Все эти стимулы учитываются в проектировании аукционов экономистами.
Третий пласт задач это эксперименты и квазиэксперименты (A/B-тесты). A/B-тестирование проводится рутинно, постоянно в больших компаниях. Экономисты здесь занимаются проектированием систем для A/B-тестирования; на самом деле, провести его легко, сложно сделать это хорошо. Как правильно провести A/B-тестирование, подсчитать результаты, затратить минимум ресурсов и получить максимальную выгоду этим всем занимаются экономисты в таких компаниях, как Google, Facebook или Zalando. Компания Netflix хорошо известна своей платформой для экспериментов и A/B-тестов.

Четвертый пласт это измерение downstream impact: как продукт влияет на, допустим, lifetime value, которые вы получаете от одного клиента. Представьте, что вы хотите оценить, сколько должен стоить подписочный сервис вроде Amazon Prime: какую цену просить у подписчиков, чтобы максимизировать количество подписок, чтобы люди не отписывались? Для этого нужно оценить, сколько ценности Amazon Prime приносит клиенту не за день или месяц, а годами. И такие задачи, когда есть долгосрочное планирование и прогнозирование, долгосрочная оценка, решают экономисты для бизнеса.

Мы видим эти задачи, и вроде бы все хорошо, но возникает вопрос: чем экономисты отличаются от обычных data scientist-ов, ведь они тоже решают похожие задачи? Почему экономисты особенные, в чем их сравнительное преимущество? Объясним на примере лестницы причинно-следственных связей (ladder of causality). У нее три уровня. На примере трех вопросов в контексте оффлайн-магазина я попытаюсь объяснить, почему бизнесу нужны экономисты.

Представьте, что вы владелец обыкновенного магазина на углу, и вы хотите предсказать спрос на пиво и чипсы. Вы хотите пополнить запас товаров для продажи на следующую неделю для этого нужно предсказание спроса. Представим первый случай: следующая неделя не отличается существенно от предыдущей. Тогда на основании истории предыдущих покупок мы сможем построить модель, которая предсказывает спрос на чипсы и пиво на следующую неделю. Вопрос, который вы задаете, таков: сколько пива и чипсов люди купят при текущих ценах в нашем магазине, или в других похожих магазинах? Здесь очень важно словосочетание при текущих ценах то есть, мы смотрим на статус-кво.

Это мы назовем вопросом первого уровня: нам не важно, почему спрос на товары был именно таким на прошлой неделе. Хорошая предсказательная модель, которую мы будем строить, не обязана давать объяснения того, почему люди покупали столько пива и чипсов она должна на основе прошлых данных предсказать будущее с достаточной точностью. Примеры таких моделей: распознавание визуальных образов (отличить кошку от собаки на фото), определение спам-сообщений в e-mail, определение кредитного рейтинга потенциального клиента. В предсказательных моделях не важны причинно-следственные связи; основываясь на данных, которые у вас уже есть, вы хотите сделать предсказание для нового объекта картинки, сообщения, клиента. Здесь методы машинного обучения замечательно работают. Мы можем обучить продвинутые методы и сделать очень хорошее предсказание.

Перейдем ко второму вопросу и второму уровню лестницы. Допустим, мы захотели изменить цену на пиво на следующую неделю. Вопрос, который мы задаем, звучит так: что произойдет на следующей неделе с продажами пива, если поднять цену? А что произойдет с продажами чипсов, которые, возможно, связаны с продажами пива? Почему мы не можем просто использовать случаи из прошлого, когда в прошлом менялась цена на пиво? Именно потому, что, возможно, в прошлом цена менялась по другим причинам. Сейчас мы хотим сами поднять цену; в прошлом, может быть, все магазины автоматически подняли ее одновременно, из-за изменения акцизов. Или это могло случиться по иным причинам. Но предсказательная модель не способна знать этих причин, и здесь мы не можем просто методом машинного обучения подкрутить цену на пиво, увеличить ее как-то и предсказать, что будет с продажами пива и чипсов. Модели машинного обучения не работают в терминах причин и следствий. Они просто видят корреляции, которые были в данных в прошлом, и видят условные вероятности: например, вероятность того, что человек купит чипсы, если он уже купил пиво.

Что делать в таком случае? Мы можем провести эксперимент. Мы можем поднять цену на пиво лишь в отдельном магазине нашей сети (предположим, у нас имеется сеть магазинов) и посмотреть, что в этом магазине произойдет на следующей неделе с продажами пива и чипсов и в других магазинах тоже. Здесь мы проводим простейший A/B-тест. Как его правильно провести именно такими задачами задаются экономисты в компаниях. Это второй уровень вопросов по причинно-следственным связям. Здесь, в отличие от первого уровня, мы хотим узнать, что произойдет, если мы внесем изменение то есть, мы можем пощупать причину и следствие, изменение, которое мы вносим, и конечный результат (продажи пива и чипсов).

Третий уровень еще сложнее. Допустим, мы подняли цены на пиво и видим, что упали продажи чипсов. Почему упали продажи чипсов? Потому ли, что пиво стало дороже или, может быть, потому, что мы теперь продаем кукурузные палочки дешевле, чем чипсы? Вот мы взяли, не подумали и изменили цену на палочки. Или мы просто не можем контролировать все: у нас есть и кальмары, и фисташки, и кукурузные палочки, и цена на них тоже меняется. Нам сложно провести эксперимент, подобный эксперименту из второго уровня: меняются цены на очень много товаров, какие-то из них заменяют, какие-то дополняют чипсы (как пиво). И тогда перед нами стоит такой вопрос: Что бы случилось с продажами чипсов на этой неделе, если бы мы не изменяли цены на пиво? Тут мы хотим понять, что бы случилось при условии, если бы все другие изменения произошли, кроме изменения цены на пиво. Нужно помыслить себе параллельную реальность, в которой было так, и как-то сконструировать ее.

Это вопрос третьего уровня: что было бы, если бы. Наша предсказательная модель не способна ответить на него, не способна сконструировать параллельную реальность. На этот вопрос зачастую нельзя ответить и с помощью экспериментов. Здесь как раз нужны экономисты: в течение последнего полувека они изучают поведение людей и задают как раз такие вопросы чтоб было бы, если бы этого не произошло.

Пример такого вопроса: в 70-е годы XX века в Стране басков регионе Испании было сильное сепаратистское движение, происходило много терактов. Экономисты хотели оценить, что было бы со Страной басков как бы она развивалась экономически если бы этих терактов не было. Как экономисты это делают? Они строят параллельную реальность, в которой они строят воображаемую мирную Страну басков, и смотрят, как она развивается, какой в ней экономический рост. Результаты говорят о том, что террористическая активность в Стране басков уменьшила ее экономический рост на 10%. Тут мы можем понять, что именно такие вопросы экономиста задают уже давно, и они разработали много методов для ответа на такие вопросы. Именно этим они ценны бизнесу.

Итак, мы попробовали объяснить, чем экономисты ценны бизнесу и как они отличаются от обычных data scientist-ов. Последний вопрос нашего вебинара: Почему бизнесы будут нанимать все больше экономистов?; ответим с помощью примера онлайн-рекламы.

Компании тратят огромные деньги на рекламу онлайн и оффлайн. Если говорить в двух словах на самом деле, никто не знает, как именно работает реклама. Статус-кво среди маркетологов в том, что реклама работает. Многие экономисты имеют другое мнение, они считают, что в 90% случаев она не работает но статус-кво состоит в том, что она работает как-то (и никто не может сказать, как именно). Вопрос как именно работает реклама это как раз вопрос из 2-3 уровней лестницы причинно-следственных связей, и ответить на него хорошо с помощью предсказательных моделей невозможно.

Более конкретные примеры вопросов, которыми задаются бизнесы: Что будет с продажами, если в следующем месяце потратить на рекламу в 2 раза больше? Конечно, мы можем провести эксперимент потратить в 2 раза больше на рекламу. Но как понять потом, что новые продажи принесла именно реклама? Это могло произойти благодаря сезонным распродажам в том же месяце, или благодаря другой рекламной активности. У компании может быть много каналов рекламы, особенно у такой большой, как Zalando, и бюджеты могут меняться по многим из них. Допустим, мы хотим увеличить бюджет в одном из них и понять, что происходит с продажами но как понять, что именно это изменение привело к дополнительным продажам? Что, если продажи отложенные пользователь увидел рекламу, но покупку совершил только через месяц?
Следующий вопрос: как отвечать на такие сложные вопросы при условии, что пользователи в Европе и в других странах все меньше и меньше готовы делиться своими данными cookies и прочими? Бизнесам все сложнее отслеживать пользователей. Отслеживание пользователей за пределами вашего сайта на индивидуальном уровне невозможно в большинстве случаев; вы не можете знать, что пользователь делал на той платформе, где была ваша реклама в Facebook или Instagram. Такими вопросами задаются бизнесы, и ради таких вопросов они нанимают экономистов.

В завершение разговора про экономистов в бизнесе я хочу рассказать одну итальянскую притчу. У владельца пиццерии было два сына, и он отправил их раздавать купоны на бесплатный кофе просто чтобы привлечь больше покупателей в свою пиццерию. И он устроил соревнование между сыновьями. Сказал: я вам даю синие и красные купоны, чтобы различать, от кого пришел покупатель с купоном, и я куплю футбольный мяч тому, чьих купонов на кассе окажется больше. Один сын пошел на улицу раздавать купоны, чтобы привлечь посетителей. А другой сын остался в пиццерии и, пока отец готовил пиццу на кухне, стал раздавать купоны людям в очереди, которые уже собирались купить пиццу. Вопрос: кто же из этих сыновей победил?

На самом деле, эта притча работает и в рекламном бизнесе. Тратит ли бизнес деньги на тех людей, которые все равно купили бы тот товар, который вы продаете? Или он тратит деньги на тех людей, которых он действительно привлечет с помощью рекламы, и которые в параллельной реальности, где нет рекламы, не купили бы ваш товар? И вот, когда мы говорим об этих параллельных реальностях, когда нам нужно их помыслить и сконструировать, как раз здесь нам нужны экономисты. Поэтому бизнес их набирает.

Я расскажу, что вам делать, если вы хотите больше знать об экономике. Я могу посоветовать книги и подкасты. Замечательная книга, с которой стоит начать книга бывшего ректора РЭШ Сергея Гуриева, Мифы экономики. Оттуда я сегодня взял пример о стоимости человеческой жизни. Вы можете в этой книге прочитать о мифах, которые существуют о том, что делают экономисты и как устроена экономика, и о развенчании этих мифов. Про то, почему одни страны богатые, а другие нет, какой консенсус у экономистов и сколько работы они проделали, изучая историю стран, вы можете прочитать в книге Why Nations Fail. Про более микроуровневые задачи, когда мы смотрим не на страны, а на поведение отдельных людей, и про то, чем экономисты отличаются от normal data scientists, которые занимаются задачами предсказания или классификации, вы можете прочитать в книге Mostly Harmless Econometrics это про эконометрические методы, специальные статистические методы для изучения причинно-следственных связей. Книга The Book of Why также фокусируется на причинно-следственных связях, как раз оттуда я взял концепцию трехуровневой лестницы причинно-следованных связей; она отлично объясняет, почему бизнесам нужно все больше и больше экономистов.

Также я хотел поделиться подкастами и лекциями. На русском языке есть Экономика на слух отличный подкаст от VTimes. Также подкаст Экономика и жизнь это на YouTube-канале РЭШ; вообще, на нем можно найти много интересных лекций.

Если вы хотите почитать или послушать на английском языке, то я могу для начала порекомендовать Freakonomics это самый популярный подкаст по экономике, очень интересный. Как раз из него можно понять, насколько сумасшедшие вопросы готовы задавать экономисты и отвечать на них с помощью хороших математических и эконометрических методов. У авторов подкаста также есть свой блог на их вебсайте и несколько хороших книг, которые я тоже рекомендую.

Q: сейчас в России потолок зарплат экономистов $1000 в месяц что нужно, чтобы устроиться в Google?

На самом деле, для того, чтобы устроиться в Google экономистом, вам нужен PhD по экономике Google может себе позволить выбирать только из PhD по экономике. Хотя это не значит, что вы совсем не можете заниматься экономическими вопросами в Google: вы можете заниматься ими, будучи data scientist-ом и сотрудничая с экономистами. Это мне известно от моих коллег, которые работают в Google. Это будет не так-то просто, но, я думаю, возможно.

Если у вас будут вопросы по тому, что я рассказал, то я на самые интересные из них отвечу еще позже. Спасибо всем, кто задавал интересные вопросы и кому была интересна эта лекция.

Всё чаще от клиентов поступают такие запросы: Хотим как Amazon RDS, но дешевле; Хотим как RDS, но везде, в любой инфраструктуре. Чтобы реализовать подобное managed-решение на Kubernetes, мы посмотрели на текущее состояние наиболее популярных операторов для PostgreSQL (Stolon, операторы от Crunchy Data и Zalando) и сделали свой выбор.

Эта статья полученный нами опыт и с теоретической точки зрения (обзор решений), и с практической стороны (что было выбрано и что из этого получилось). Но для начала давайте определимся, какие вообще требования предъявляются к потенциальной замене RDS

Что же такое RDS

Когда люди говорят про RDS, по нашему опыту, они подразумевают управляемый (managed) сервис СУБД, которая:

1. легко настраивается;
2. имеет возможность работы со снапшотами и восстанавливаться из них (желательно с поддержкой PITR);
3. позволяет создавать топологии master-slave;
4. имеет богатый список расширений;
5. предоставляет аудит и управление пользователями/доступами.

Если говорить вообще, то подходы к реализации поставленной задачи могут быть весьма разными, однако путь с условным Ansible нам не близок. (К схожему выводу пришли и коллеги из 2GIS в результате своей попытки создать инструмент для быстрого развертывания отказоустойчивого кластера на основе Postgres.)

Именно операторы общепринятый подход для решения подобных задач в экосистеме Kubernetes. Подробнее о них применительно к базам данных, запускаемым внутри Kubernetes, уже рассказывал техдир Фланта, distol, в одном из своих докладов.

NB: Для быстрого создания несложных операторов рекомендуем обратить внимание на нашу Open Source-утилиту shell-operator. Используя её, можно это делать без знаний Go, а более привычными для сисадминов способами: на Bash, Python и т.п.

Для PostgreSQL существует несколько популярных K8s-операторов:

• Stolon;
• Crunchy Data PostgreSQL Operator;
• Zalando Postgres Operator.

Посмотрим на них более внимательно.

Выбор оператора

Помимо тех важных возможностей, что уже были упомянуты выше, мы как инженеры по эксплуатации инфраструктуры в Kubernetes также ожидали от операторов следующего:

• деплой из Git и с Custom Resources;
• поддержку pod anti-affinity;
• установку node affinity или node selector;
• установку tolerations;
• наличие возможностей тюнинга;
• понятные технологии и команды.

Не вдаваясь в детали по каждому из пунктов (спрашивайте в комментариях, если останутся вопросы по ним после прочтения всей статьи), отмечу в целом, что эти параметры нужны для более тонкого описания специализации узлов кластера с тем, чтобы заказывать их под конкретные приложения. Так мы можем добиться оптимального баланса в вопросах производительности и стоимости.

Теперь к самим операторам PostgreSQL.

1. Stolon

Stolon от итальянской компании Sorint.lab в уже упомянутом докладе рассматривался как некий эталон среди операторов для СУБД. Это довольно старый проект: первый его публичный релиз состоялся еще в ноябре 2015 года, а GitHub-репозиторий может похвастать почти 3000 звёздами и 40+ контрибьюторами.

И действительно, Stolon отличный пример продуманной архитектуры:



С устройством этого оператора в подробностях можно ознакомиться в докладе или документации проекта. В целом же, достаточно сказать, что он умеет всё описанное: failover, прокси для прозрачного доступа клиентов, бэкапы. Причем прокси предоставляют доступ через один сервис endpoint в отличие от двух других решений, рассмотренных дальше (у них по два сервиса для доступа к базе).

Однако у Stolon нет Custom Resources, из-за чего его нельзя так деплоить, чтобы просто и быстро как горячие пирожки создавать экземпляры СУБД в Kubernetes. Управление осуществляется через утилиту stolonctl, деплой через Helm-чарт, а пользовательские пароли задаются через ConfigMap.

С одной стороны, получается, что оператор не очень-то является оператором (ведь он не использует CRD). Но с другой это очень гибкая система, которая позволяет настраивать ресурсы в K8s так, как вам удобно.

Но лично для нас не показался оптимальным путь заводить отдельный чарт под каждую БД. Поэтому мы стали искать альтернативы.

2. Crunchy Data PostgreSQL Operator

Оператор от Crunchy Data, молодого американского стартапа, выглядел логичной альтернативой. Его публичная история начинается с первого релиза в марте 2017 года, с тех пор GitHub-репозиторий получил чуть менее 1300 звёзд и 50+ контрибьюторов. Последний релиз от сентября был протестирован на работу с Kubernetes 1.151.18, OpenShift 3.11+ и 4.4+, GKE и VMware Enterprise PKS 1.3+.

Архитектура Crunchy Data PostgreSQL Operator также соответствует нашим требованиям:



Управление происходит через утилиту pgo, однако она в свою очередь генерирует Custom Resources для Kubernetes. Поэтому с точки зрения потенциальных пользователей оператор нас порадовал:

• есть управление через CRD;
• удобное управление пользователями (тоже через CRD);
• интеграция с другими компонентами Crunchy Data Container Suite специализированной коллекции образов контейнеров для PostgreSQL и утилит для работы с ней (включая pgBackRest, pgAudit, расширения из contrib и т.д.).

Однако попытки начать использовать оператор выявили несколько проблем:

• Не оказалось возможности tolerations предусмотрен только nodeSelector.
• Создаваемые podы были частью Deploymentа, несмотря на то, что мы деплоили stateful-приложение. В отличие от StatefulSet, Deploymentы не умеют создавать диски.

Последний недостаток приводит к забавным моментам: на тестовой среде удалось запустить 3 реплики с одним диском localstorage, в результате чего оператор сообщал, что 3 реплики работают (хотя это было не так).

Еще одной особенностью этого оператора является его готовая интеграция с различными вспомогательными системами. Например, легко установить поставить pgAdmin и pgBounce, а в документации рассматриваются преднастроенные Grafana и Prometheus. В недавнем релизе 4.5.0-beta1 отдельно отмечается улучшенная интеграция с проектом pgMonitor, с которой оператор предлагает визуализацию метрик по PgSQL из коробки.

Тем не менее, странный выбор генерируемых Kubernetes-ресурсов привел нас к необходимости найти иное решение.

3. Zalando Postgres Operator

Продукты Zalando нам известны давно: есть опыт использования Zalenium и, конечно, мы пробовали Patroni их популярное HA-решение для PostgreSQL. О подходе компании к созданию Postgres Operator рассказывал один из его авторов Алексей Клюкин в эфире Postgres-вторника 5, и нам он приглянулся.

Это самое молодое решение из рассматриваемых в статье: первый релиз состоялся в августе 2018 года. Однако, даже несмотря на небольшое количество формальных релизов, проект прошёл большой путь, уже опередив по популярности решение от Crunchy Data (1300+ звёзд на GitHub) и максимальное число контрибьюторов (70+). Под капотом этого оператора используются решения, проверенные временем: Patroni и Spilo для управления, WAL-E для бэкапов, PgBouncer в качестве пула подключений.

Вот как представлена архитектура оператора от Zalando:



Оператор полностью управляется через Custom Resources, автоматически создает StatefulSet из контейнеров, которые затем можно кастомизировать, добавляя в pod различные sidecarы. Всё это значительный плюс в сравнении с оператором от Crunchy Data.

Поскольку именно решение от Zalando мы выбрали среди 3 рассматриваемых вариантов, дальнейшее описание его возможностей будет представлено ниже, сразу вместе с практикой применения.

Практика с Postgres Operator от Zalando

Деплой оператора происходит очень просто: достаточно скачать актуальный релиз с GitHub и применить YAML-файлы из директории manifests. Как вариант, можно также воспользоваться OperatorHub.

После установки стоит озаботиться настройкой хранилищ для логов и бэкапов. Она производится через ConfigMap postgres-operator в пространстве имен, куда вы установили оператор. Когда хранилища настроены, можно развернуть первый кластер PostgreSQL.

Например, стандартный деплой у нас выглядит следующим образом:

apiVersion: acid.zalan.do/v1kind: postgresqlmetadata: name: staging-dbspec: numberOfInstances: 3 patroni:   synchronous_mode: true postgresql:   version: "12" resources:   limits:     cpu: 100m     memory: 1Gi   requests:     cpu: 100m     memory: 1Gi sidecars: - env:   - name: DATA_SOURCE_URI     value: 127.0.0.1:5432   - name: DATA_SOURCE_PASS     valueFrom:       secretKeyRef:         key: password         name: postgres.staging-db.credentials   - name: DATA_SOURCE_USER     value: postgres   image: wrouesnel/postgres_exporter   name: prometheus-exporter   resources:     limits:       cpu: 500m       memory: 100Mi     requests:       cpu: 100m       memory: 100Mi teamId: staging volume:   size: 2Gi

Данный манифест деплоит кластер из 3 экземпляров с sidecar в виде postgres_exporter, с которого мы снимаем метрики приложения. Как видите, всё очень просто, и при желании можно сделать буквально неограниченное количество кластеров.

Стоит обратить внимание и на веб-панель для администрирования postgres-operator-ui. Она поставляется вместе с оператором и позволяет создавать и удалять кластеры, а также позволяет работать с бэкапами, которые делает оператор.


Список кластеров PostgreSQL


Управление бэкапами

Другой интересной особенностью является поддержка Teams API. Данный механизм автоматически создаёт роли в PostgreSQL, исходя из полученного списка имён пользователей. После этого API позволяет вернуть список пользователей, для которых автоматически создаются роли.

Проблемы и их решение

Однако использование оператора вскоре выявило несколько весомых недостатков:

1. отсутствие поддержки nodeSelector;
2. невозможность отключить бэкапы;
3. при использовании функции создания баз не создаются привилегии по умолчанию;
4. периодически не хватает документации или же она находится в неактуальном состоянии.

К счастью, многие из них могут быть решены. Начнём с конца проблем с документацией.

Скорее всего вы столкнетесь с тем, что не всегда ясно, как прописать бэкап и как подключить бэкапный бакет к Operator UI. Об этом в документации говорится вскользь, а реальное описание есть в PR:

1. нужно сделать секрет;
2. передать его оператору в параметр pod_environment_secret_name в CRD с настройками оператора или в ConfigMap (зависит от того, как вы решили устанавливать оператор).

Однако, как оказалось, на текущий момент это невозможно. Именно поэтому мы собрали свою версию оператора с некоторыми дополнительными сторонними наработками. Подробнее о ней см. ниже.

Если передавать оператору параметры для бэкапа, а именно wal_s3_bucket и ключи доступа в AWS S3, то он будет бэкапить всё: не только базы в production, но и staging. Нас это не устроило.

В описании параметров к Spilo, что является базовой Docker-обёрткой для PgSQL при использовании оператора, выяснилось: можно передать параметр WAL_S3_BUCKET пустым, тем самым отключив бэкапы. Более того, к большой радости нашёлся и готовый PR, который мы тут же приняли в свой форк. Теперь достаточно просто добавить enableWALArchiving: false в ресурс кластера PostgreSQL.

Да, была возможность сделать иначе, запустив 2 оператора: один для staging (без бэкапов), а второй для production. Но так мы смогли обойтись одним.

Ок, мы научились передавать в базы доступ для S3 и бэкапы начали попадать в хранилище. Как заставить работать страницы бэкапов в Operator UI?



В Operator UI потребуется добавить 3 переменные:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

После этого управление бэкапами станет доступно, что в нашем случае упростит работу со staging, позволив доставлять туда срезы с production без дополнительных скриптов.

В качестве еще одного плюса называлась работа с Teams API и широкие возможности для создания баз и ролей средствами оператора. Однако создаваемые роли не имели прав по умолчанию. Соответственно, пользователь с правами на чтение не мог читать новые таблицы.

Почему так? Несмотря на то, что в коде есть необходимые GRANT, они применяются далеко не всегда. Есть 2 метода: syncPreparedDatabases и syncDatabases. В syncPreparedDatabases несмотря на то, что в секции preparedDatabases есть есть условие defaultRoles и defaultUsers для создания ролей, права по умолчанию не применяются. Мы в процессе подготовки патча, чтобы данные права автоматически применялись.

И последний момент в актуальных для нас доработках патч, добавляющий Node Affinity в создаваемый StatefulSet. Наши клиенты зачастую предпочитают сокращать расходы, используя spot-инстансы, а на них явно не стоит размещать сервисы БД. Этот вопрос можно было бы решить и через tolerations, но наличие Node Affinity даёт большую уверенность.

Что получилось?

По итогам решения перечисленных проблем мы форкнули Postgres Operator от Zalando в свой репозиторий, где он собирается со столь полезными патчами. А для пущего удобства собрали и Docker-образ.

Список PR, принятых в форк:

• сборка в Docker безопасного легкого образа для оператора;
• отключение бэкапов;
• обновление версий ресурсов для актуальных версий k8s;
• внедрение Node Affinity.

Будет здорово, если сообщество поддержит эти PR, чтобы они попали в следующую версию оператора (1.6).

Бонус! История успеха с миграцией production

Если вы используете Patroni, на оператор можно мигрировать живой production с минимальным простоем.

Spilo позволяет делать standby-кластеры через S3-хранилища с Wal-E, когда бинарный лог PgSQL сначала сохраняется в S3, а затем выкачивается репликой. Но что делать, если у вас не используется Wal-E в старой инфраструктуре? Решение этой проблемы уже было предложено на хабре.

На помощь приходит логическая репликация PostgreSQL. Однако не будем вдаваться в детали, как создавать публикации и подписки, потому что наш план потерпел фиаско.

Дело в том, что в БД было несколько нагруженных таблиц с миллионами строк, которые, к тому же, постоянно пополнялись и удалялись. Простая подписка с copy_data, когда новая реплика копирует всё содержимое с мастера, просто не успевала за мастером. Копирование контента работало неделю, но так и не догнало мастер. В итоге, разобраться с проблемой помогла статья коллег из Avito: можно перенести данные, используя pg_dump. Опишу наш (немного доработанный) вариант этого алгоритма.

Идея заключается в том, что можно сделать выключенную подписку, привязанную к конкретному слоту репликации, а затем исправить номер транзакции. В наличии были реплики для работы productionа. Это важно, потому что реплика поможет создать консистентный dump и продолжить получать изменения из мастера.

В последующих командах, описывающих процесс миграции, будут использоваться следующие обозначения для хостов:

1. master исходный сервер;
2. replica1 потоковая реплика на старом production;
3. replica2 новая логическая реплика.

План миграции

1. Создадим на мастере подписку на все таблицы в схеме public базы dbname:

psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"

2. Cоздадим слот репликации на мастере:

psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"

3. Остановим репликацию на старой реплике:

psql -h replica1 -c "select pg_wal_replay_pause();"

4. Получим номер транзакции с мастера:

psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"

5. Снимем dump со старой реплики. Будем делать это в несколько потоков, что поможет ускорить процесс:

pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname

6. Загрузим dump на новый сервер:

pg_restore -h replica2 -F d -j 8 -d dbname dump/

7. После загрузки дампа можно запустить репликацию на потоковой реплике:

psql -h replica1 -c "select pg_wal_replay_resume();"

7. Создадим подписку на новой логической реплике:

psql -h replica2 -c "create subscription oldprod connection 'host=replica1 port=5432 user=postgres password=secret dbname=dbname' publication dbname with (enabled = false, create_slot = false, copy_data = false, slot_name='repl');"

8. Получим oid подписки:

psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"

9. Допустим, был получен oid=1000. Применим номер транзакции к подписке:

psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"

10. Запустим репликацию:

psql -h replica2 -d dbname -c "alter subscription oldprod enable;"

11. Проверим статус подписки, репликация должна работать:

psql -h replica2 -d dbname -c "select * from pg_replication_origin_status;"psql -h master -d dbname -c "select slot_name, restart_lsn, confirmed_flush_lsn from pg_replication_slots;"

12. После того, как репликация запущена и базы синхронизированы, можно совершать переключение.

13. После отключения репликации надо исправить последовательности. Это хорошо описано в статье на wiki.postgresql.org.

Благодаря такому плану переключение прошло с минимальными задержками.

Заключение

Операторы Kubernetes позволяют упростить различные действия, сведя их к созданию K8s-ресурсов. Однако, добившись замечательной автоматизации с их помощью, стоит помнить, что она может принести и ряд неожиданных нюансов, поэтому подходите к выбору операторов с умом.

Рассмотрев три самых популярных Kubernetes-оператора для PostgreSQL, мы остановили свой выбор на проекте от Zalando. И с ним пришлось преодолеть определенные трудности, но результат действительно порадовал, так что мы планируем расширить этот опыт и на некоторые другие инсталляции PgSQL. Если у вас есть опыт использования схожих решений будем рады увидеть подробности в комментариях!

P.S.

Читайте также в нашем блоге:

• Базы данных и Kubernetes (обзор и видео доклада);
• Postgres-вторник 5: PostgreSQL и Kubernetes. CI/CD. Автоматизация тестирования;
• Одна история с оператором Redis в K8s и мини-обзор утилит для анализа данных этой БД.

На прошлую статью, где мы рассмотрели три оператора PostgreSQL для Kubernetes (Stolon, Crunchy Data и Zalando), поделились своим выбором и опытом эксплуатации, поступила отличная обратная связь от сообщества*.

Продолжая эту тему, мы добавили в обзор два других решения, на которые нам указали в комментариях: StackGres и KubeDB, и сделали сводную таблицу сравнения. Также за время эксплуатации оператора от Zalando у нас появились новые интересные кейсы спешим поделиться и ими.

* Первую часть статьи заметили даже разработчики Zalando, благодаря чему(?) они решили активизироваться в приёме некоторых PR. Это не может не радовать!



Итак, сначала дополним обзор ещё двумя решениями

KubeDB

Оператор KubeDB разрабатывается командой AppsCode c 2017 года и хорошо известен в Kubernetes-сообществе. Он претендует на звание платформы для запуска различных stateful-сервисов в Kubernetes и поддерживает:

• PostgreSQL;
• Elasticsearch;
• MySQL;
• MongoDB;
• Redis;
• Memcache.

Однако в контексте статьи мы рассмотрим только PostgreSQL.

В KubeDB реализован интересный подход с использованием нескольких CRD, которые содержат в себе различные настройки, такие как:

• версия с образом базы и вспомогательными утилитами за это отвечает ресурс postgresversions.catalog.kubedb.com;
• параметры восстановления ресурс бэкапа <codesnapshots.kubedb.com

собственно, корневой ресурс postgreses.kubedb.com, который собирает в себе все эти ресурсы и запускает кластер PostgreSQL.

Особой кастомизации KubeDB не предоставляет (в отличие от оператора Zalando), но вы всегда можете управлять конфигом PostgreSQL через ConfigMap.

Интересной особенностью является ресурс dormantdatabases.kubedb.com, который предоставляет защиту от дурака: все удалённые базы сначала переводятся в такое архивное состояние и могут быть легко восстановлены в случае необходимости. Жизненный цикл БД в KubeDB описывается следующей схемой:



Что же касается самого технологического стека, то тут используются свои наработки для управления кластерами, а не знакомые всем Patroni или Repmgr. Хотя для полинга соединений используется pgBouncer, который также создается отдельным CRD (pgbouncers.kubedb.com). Кроме того, разработчики предоставляют плагин для kubectl, который позволяет удобно управлять базами через всем привычную утилиту, и это огромный плюс на фоне Stolon или Crunchy Data.

KubeDB интегрируется с другими решениями AppsCode, чем напоминает Crunchy Data. Если вы везде используете решения этого вендора, то KubeDB, безусловно, отличный выбор.

Наконец, хочется отметить отличную документацию этого оператора, которая находится в отдельном репозитории GitHub. В ней есть развернутые примеры использования, включая полные примеры конфигураций CRD.

Есть минусы у KubeDB. Многие возможности: бэкапы, полинг соединений, снапшоты, dormant-базы доступны только в enterprise-версии, а для её использования требуется купить подписку у AppsCode. Кроме того, самой старшей поддерживаемой версией PostgreSQL из коробки является 11.x. Перечеркивают ли эти моменты изящную архитектуру KubeDB решать вам.

StackGres

В твиттере и в комментариях к предыдущей статье нам резонно указали на оператор StackGres. Разработка данного оператора началась совсем недавно, в мае 2019 году. В нем используются известные и проверенные технологии: Patroni, PgBouncer, WAL-G и Envoy.

Общая схема оператора выглядит так:



Кроме того, в комплекте с оператором можно установить:

• веб-панель, как в Zalando;
• систему сбора логов;
• систему мониторинга, аналогичную Crunchy Data, о которой мы говорили в первой части;
• систему сбора бэкапов на основе MinIO, хотя можно подключить и внешнее хранилище.

В целом же, данный оператор использует подход, очень схожий с KubeDB: он предоставляет сразу несколько ресурсов для описания компонентов кластера, создания конфигов и задания ресурсов.

Вкратце про все CRD:

• sgbackupconfigs.stackgres.io, sgpgconfigs.stackgres.io, sgpoolconfigs.stackgres.io описание кастомных конфигов;
• sginstanceprofiles.stackgres.io размер инстанса Postgres, который будет использоваться как limit/request для контейнера с PostgreSQL/Patroni. Для остальных контейнеров лимитов нет;
• sgclusters.stackgres.io когда есть конфигурации для базы, пула коннектов и бэкапа, можно создать кластер PostgreSQL, который описывается этим CRD;
• sgbackups.stackgres.io ресурс, схожий со snapshot у KubeDB и позволяющий обратиться к конкретному бэкапу из кластера K8s.

Однако оператор не позволяет использовать свои кастомные сборки образов или же несколько вспомогательных sidecar для сервера баз данных. Pod c Postgres содержит 5 контейнеров:



Из них мы можем отключить экспортер метрик, пулер коннектов и контейнер со вспомогательными утилитами администратора (psql, pg_dump и так далее). Да, оператор позволяет при инициализации кластера баз данных подключить скрипты с SQL-кодом для инициализации БД или создания пользователей, но не более того. Это сильно ограничивает нас в кастомизации, например, в сравнении с тем же оператором Zalando, где можно добавлять нужные sidecar с Envoy, PgBouncer и любыми другими вспомогательными контейнерами (хороший пример подобной связки будет ниже).

Подводя итог, можно сказать, что этот оператор понравится тем, кто хочет просто управлять PostgreSQL в кластере Kubernetes. Отличный выбор для тех, кому нужен инструмент с простой документацией, покрывающей все аспекты работы оператора, и кому не нужно делать сложные связки контейнеров и баз.

Итоговое сравнение

Мы знаем, что наши коллеги нежно любят сводные таблицы, поэтому приводим подобную для Postgres-операторов в Kubernetes.

Забегая вперед: после рассмотрения двух дополнительных кандидатов мы остаёмся при мнении, что решение от Zalando оптимальный для нашего случая продукт, так как позволяет реализовывать очень гибкие решения, имеет большой простор для кастомизации.

В таблице первая часть посвящена сравнению основных возможностей работы с БД, а вторая более специфичным особенностям, следуя нашему пониманию об удобстве работы с оператором в Kubernetes.

Не будет лишним также сказать, что при формулировании критериев для итоговой таблицы использовались примеры из документации KubeDB.

Бонусы про оператор от Zalando

Ежедневно пользуясь решением от Zalando, мы столкнулись с некоторыми сложностями, и этим опытом хотелось бы поделиться с сообществом.

1. Приватные репозитории

Недавно нам потребовалось запустить через оператор наряду с PostgreSQL контейнер с SFTP, который позволил бы получать выгрузки из базы в формате CSV. Сам SFTP-сервер со всеми нужными параметрами был собран в закрытом registry.

И тут стало ясно, что оператор не умеет работать с registry secrets. К счастью, с такой проблемой мы были не одни с такой проблемой: все легко решилось коллегами на GitHub. Оказалось, что достаточно добавить в описание ServiceAccount имя с доступами в registry:

pod_service_account_definition: '{ "apiVersion": "v1", "kind": "ServiceAccount", "metadata": { "name": "zalando-postgres-operator" }, "imagePullSecrets": [ { "name": "my-fine-secret" } ] }'

2. Дополнительные хранилища и init-контейнеры

Для работы SFTP нам также требовалось корректно выставлять права на директории, чтобы заработал chroot. Возможно, не все знают, но OpenSSH-сервер требует особых привилегий на директории. Например, чтобы пользователь видел только свой /home/user, необходимо, чтобы /home принадлежал root с правами 755, а уже /home/user был доступен пользователю. Соответственно, мы решили использовать init-контейнер, который исправлял бы права на директории.

Но оператор не умеет пробрасывать дополнительные диски в init-контейнеры! Благо, есть подходящий PR, которым мы и дополнили свою сборку оператора.

3. Перезапуск PgSQL при проблемах с control plane

В процессе эксплуатации кластеров на основе Patroni в Kubernetes мы получили от клиента странную проблему: ровно в 4 часа ночи по Москве обрывались все подключения PostgeSQL. Разбираясь в ситуации, мы обнаружили следующее в логах Spilo:

2020-10-21 01:01:10,538 INFO: Lock owner: production-db-0; I am production-db-02020-10-21 01:01:14,759 ERROR: failed to update leader lock2020-10-21 01:01:15,236 INFO: demoted self because failed to update leader lock in DCS2020-10-21 01:01:15,238 INFO: closed patroni connection to the postgresql cluster2020-10-21 01:01:15 UTC [578292]: [1-1] 5f8f885b.8d2f4 0     LOG:  Auto detecting pg_stat_kcache.linux_hz parameter...

Согласно issue на GitHub, это означает, что Patoni не смог обработать ошибку Kubernetes API и упал с ошибкой. А проблемы с API были связаны с тем, что в 4 часа стартовали сразу 50 CronJob, что приводило к проблемам в etcd:

2020-10-21 01:01:14.589198 W | etcdserver: read-only range request "key:\"/registry/deployments/staging/db-worker-db1\" " with result "range_response_count:1 size:2598" took too long (3.688609392s) to execute

Ситуация исправлена в версии Patroni 2.0. По этой причине мы собрали версию Spilo из мастера. При сборке стоит учитывать, что требуется взять PR с исправлениями сборки, который на данный момент уже принят в мастер.

4. Пересоздание контейнеров

Напоследок, еще одна интересная проблема. В последнем релизе в оператор была добавлена возможность делать sidecar-контейнеры с их полным описанием в CRD оператора. Разработчики заметили, что базы периодически перезапускаются. В логах оператора было следующее:

time="2020-10-28T20:58:25Z" level=debug msg="spec diff between old and new statefulsets: \nTemplate.Spec.Volumes[2].VolumeSource.ConfigMap.DefaultMode: &int32(420) != nil\nTemplate.Spec.Volumes[3].VolumeSource.ConfigMap.DefaultMode: &int32(420) != nil\nTemplate.Spec.Containers[0].TerminationMessagePath: \"/dev/termination-log\" != \"\"\nTemplate.Spec.Containers[0].TerminationMessagePolicy: \"File\" != \"\"\nTemplate.Spec.Containers[1].Ports[0].Protocol: \"TCP\" != \"\"\nTemplate.Spec.Containers[1].TerminationMessagePath: \"/dev/termination-log\" != \"\"\nTemplate.Spec.Containers[1].TerminationMessagePolicy: \"File\" != \"\"\nTemplate.Spec.RestartPolicy: \"Always\" != \"\"\nTemplate.Spec.DNSPolicy: \"ClusterFirst\" != \"\"\nTemplate.Spec.DeprecatedServiceAccount: \"postgres-pod\" != \"\"\nTemplate.Spec.SchedulerName: \"default-scheduler\" != \"\"\nVolumeClaimTemplates[0].Status.Phase: \"Pending\" != \"\"\nRevisionHistoryLimit: &int32(10) != nil\n" cluster-name=test/test-psql pkg=cluster worker=0

Ни для кого не секрет, что при создании контейнера и podа добавляются директивы, которые не обязательно описывать. К ним относятся:

• DNSPolicy;
• SchedulerName;
• RestartPolicy;
• TerminationMessagePolicy;

Логично предположить, чтобы такое поведение учитывалось в операторе, однако, как оказалось, он плохо воспринимает секцию портов:

    ports:    - name: sftp      containerPort: 22

При создании podа автоматически добавляется протокол TCP, что не учитывается оператором. Итог: чтобы решить проблему, надо или удалить порты, или добавить протокол.

Заключение

Управление PostgreSQL в рамках Kubernetes нетривиальная задача. Пожалуй, на текущий момент на рынке нет оператора, который покрывал бы все потребности DevOps-инженеров. Однако среди уже существующих инструментов есть продвинутые и довольно зрелые варианты, из которых можно выбрать то, что лучше всего соответствует имеющимся потребностям.

Наш опыт говорит о том, что не стоит ждать стремительного и магического решения всех проблем. Тем не менее, мы в целом довольны имеющимся результатом, пусть он и требует периодического внимания с нашей стороны.

Говоря же об операторах, рассмотренных в этой части статьи (KubeDB и StackGres), стоит отметить, что они оснащены уникальными функциями для управления бэкапами из кластера, что может стать одним из факторов роста их популярности в ближайшем будущем.

P.S.

Читайте также в нашем блоге:

• Обзор операторов PostgreSQL для Kubernetes. Часть 1: наш выбор и опыт;
• Базы данных и Kubernetes (обзор и видео доклада);
• Postgres-вторник 5: PostgreSQL и Kubernetes. CI/CD. Автоматизация тестирования;
• Одна история с оператором Redis в K8s и мини-обзор утилит для анализа данных этой БД.