Требование целостности означает что
Целостность данных в микросервисной архитектуре — как её обеспечить без распределенных транзакций и жёсткой связности
Всем привет. Как вы, возможно, знаете, раньше я все больше писал и рассказывал про хранилища, Vertica, хранилища больших данных и прочие аналитические вещи. Сейчас в область моей ответственности упали и все остальные базы, не только аналитические, но и OLTP (PostgreSQL), и NOSQL (MongoDB, Redis, Tarantool).
Эта ситуация позволила мне взглянуть на организацию, имеющую несколько баз данных, как на организацию, имеющую одну распределенную гетерогенную (разнородную) базу. Единую распределенную гетерогенную базу, состоящую из кучи PostgreSQL, Redis-ов и Монг… И, возможно, из одной-двух баз Vertica.
Работа этой единой распределенной базы порождает кучу интересных задач. Прежде всего, с точки зрения бизнеса важно, чтобы с данными, движущимися по такой базе, все было нормально. Я специально не использую здесь термин целостность, consistency, т.к. термин это сложный, и в разных нюансах рассмотрения СУБД (ACID и CAP теорема) он имеет разный смысл.
Ситуация с распределенной базой обостряется, если компания пытается перейти на микросервисную архитектуру. Под катом я рассказываю, как обеспечить целостность данных в микросервисной архитектуре без распределенных транзакций и жесткой связности. (А в самом конце объясняю, почему выбрал для статьи такую иллюстрацию).
Согласно Крису Ричардсону (одному из известнейших евангелистов микросервисной архитектуры), в этой архитектуре есть два подхода к работе с базами данных: shared database и database-per-service.
Shared database — это неплохой первый шаг, отличное решение для небольшой компании без амбициозных планов роста. При этом сам по себе этот паттерн является анти-паттерном с точки зрения микросервисной архитектуры, т.к. два сервиса, делящих общую базу, нельзя независимо тестировать и масштабировать. Т.е. эти сервисы скорее — один сервис, тяготеющий к превращению в монолит.
Паттерн database-per-service предполагает, что у каждого сервиса своя база. Сервис может обращаться к данным другого сервиса только через API (в широком смысле), без прямого подключения к его базе.
Паттерн database-per-service позволяет командам соответствующих сервисов выбирать базы, как им нравится. Кто-то умеет в MongoDB, кто-то верит в PostgreSQL, кому-то достаточно Redis (риск потери данных при выключении для этого сервиса приемлем), а кто-то вообще хранит данные в CSV-файлах на диске (а почему бы, собственно, и нет?).
Работа с подобным «зоопарком» баз данных поднимает задачу наведения порядка в данных на абсолютно новый уровень сложности.
ACID и микросервисная архитектура
Давайте посмотрим на задачу наведения порядка через призму классического СУБД-шного набора требований ACID: развернем суть каждой буквы аббревиатуры, и проиллюстрируем сложности с этой буквой в микросервисной архитектуре.
(A) CID — Atomicity. Atomicity — все или ничего.
Согласно требованию Atomicity, нужно обязательно выполнить все шаги (с возможными повторами), при отказе важного шага — отменить выполнившиеся.
В приведенной иллюстрации демонстрируется тестовый процесс покупки услуги VIP: резервируются деньги в биллинге (1), для пользователя подключается бонусная услуга (2), тип пользователя меняется на Pro (3), зарезервированные деньги в биллинге списываются (4). Все четыре шага должны либо выполниться, либо не выполниться.
При этом нельзя зависнуть посередине процесса, поэтому предпочтительнее асинхронность, в крайнем случае — синхронность со встроенным таймаутом.
A(С)ID – Consistency. Consistency – каждый шаг не должен противоречить граничным условиям.
Классические примеры условий для, например, отправки денег от клиента А в сервисе 1 клиенту B в сервисе 2: в результате подобной отправки денег не должно стать меньше (деньги при пересылке не должны пропасть) или больше (недопустимо отправить одни и те же деньги двум пользователям одновременно). Для соблюдения этого требования нужно где-то кодировать условия и проверять данные для условий (в идеале — без дополнительных обращений).
ACI(D) — Durability. Требование Durability означает, что последствия операций не пропадают.
В условиях Polyglot persistence сервис может работать на базе данных, которая штатно может «потерять» записанные в нее данные. Подобный фокус можно получить даже от солидных баз наподобие PostgreSQL, если там включена асинхронная репликация. На иллюстрации демонстрируется, как изменения, записанные в Master, но не доехавшие в Slave по асинхронной репликации, могут быть уничтожены сгоранием сервера Master. Для обеспечения требования Durability требуется уметь штатно диагностировать и восстанавливать подобные потери.
А где же I, спросите вы?
А нигде. Изоляция в среде нескольких независимых асинхронных сервисов — это техническое требование. Современные исследования показали, что реальные бизнес-процессы можно реализовывать без изоляции. Изоляция упрощает мышление тем, что минимизирует параллелизм (разработка параллельных вычислений сложнее для программиста), но микросервисная архитектура по своей сути массивно-параллельная, изоляция в такой среде избыточна.
Существует много подходов, позволяющих добиться соблюдения перечисленных выше требований. Наиболее широко известен алгоритм распределенных транзакций, обеспечиваемых так называемым двухфазным коммитом (2PC). К сожалению, реализация двухфазных коммитов требует переписывания всех вовлеченных сервисов. И самое серьезное: этот алгоритм не очень производителен. Приведенные иллюстрации из недавних исследований показывают, что этот алгоритм показывает определенную производительность на распределенной базе из двух серверов, но при росте количества серверов производительность растет не линейно… А точнее, практически совсем не растет.
Одно из главных достоинств микросервисной архитектуры — возможность около линейно наращивать производительность, просто добавляя больше и больше серверов. Получается, что если для обеспечения распределенной целостности использовать двухфазный коммит, то этот процесс станет узким местом, ограничителем для роста производительности, несмотря на наращивание количества серверов.
Как же можно обеспечить распределенную целостность (требования ACiD) без двухфазных коммитов, с возможностью линейно масштабироваться по производительности?
Современные исследования (например, An Evaluation of Distributed Concurrency Control. VLDB 2017) утверждают, что помочь может так называемый «оптимистический подход». Разницу между двухфазным коммитом и обобщенным «оптимистическим подходом» можно проиллюстрировать разницей между старым советским магазином (с прилавком), и современным супермаркетом, вроде Ашана. В магазине с прилавком каждый покупатель считается подозрительным, и обслуживается с максимальным контролем. Отсюда очереди и конфликты. А в супермаркете покупатель по умолчанию считается честным, ему дают возможность самому подходить к полкам и набивать тележки. Конечно, есть средства мониторинга для ловли жуликов (камеры, охрана), но большинству покупателей никогда не приходится с ними сталкиваться.
Поэтому супермаркет можно масштабировать, расширять, просто ставя больше касс. Аналогично и с микросервисной архитектурой: если распределенная целостность обеспечивается «оптимистическим подходом», когда дополнительно нагружаются проверками только процессы, где что-то пошло не так. А нормальные процессы идут без дополнительных проверок.
Важно. К «оптимистическому подходу» относится несколько алгоритмов. Я хотел бы рассказать вам про сагу — алгоритм поддержания распределенной целостности, рекомендуемый Крисом Ричардсоном.
Саги — элементы алгоритма
Алгоритм саг имеет два варианта. Поэтому сначала я хотел бы универсально описать требуемые элементы алгоритма, чтобы описание подходило для обоих вариантов.
Элемент 1. Надежный персистентный канал доставки событий между сервисами, гарантирующий «at least once delivery». Т.е. если шаг 2 процесса успешно завершился, то извещение (событие) об этом должно достигнуть шага 3 как минимум однажды, повторные доставки допустимы, но потеряться ничего не должно. «Персистентный» означает, что канал должен хранить извещения какое-то время (2-3 дня, неделю), чтобы сервис, потерявший последние изменения из-за потери базы (см. пример про Durability, на иллюстрации это шаг 2), мог восстановить эти изменения, «перепроиграв» события из канала.
Элемент 2. Идемпотентность вызовов сервисов за счет использования уникального ключа идемпотентности. Представим, что я (пользователь) инициирую процесс покупки VIP-пакета (см. пример для Atomicity). В начале процесса мне выдается уникальный ключ, ключ идемпотентности, например, 42. Далее вызов каждого из шагов (1→2→3→4) должен выполняться с указанием ключа идемпотентности. В пункте выше упоминается возможность повторного прихода одинакового сообщения в сервис (в шаг). Сервис (шаг) должен автоматически уметь игнорировать повторный приход обработанного события, проверяя повторность по ключу идемпотентности. Т.е., если все сервисы (шаги процессов) идемпотентные, то для обеспечения требований Atomicity и Durability достаточно переотправить в шаги, соответствующие событиям из каналов. Шаги, пропустившие события, выполнят их, а шаги, уже выполнившие события, проигнорируют их из-за идемпотентности.
Элемент 3. Отменяемость вызовов сервисов (шагов) по ключу идемпотентности.
Для обеспечения Atomicity (см. пример), если процесс с ключем идемпотентности 42, например, остановился/упал на шаге 3, то необходимо отменить успешные выполнения шагов 1 и 2 для ключа 42. Для этого каждый обязательный шаг процесса должен обладать «компенсирующим» шагом, API-методом, отменяющим выполнение обязательного шага для указанного ключа идемпотентности (42). Реализация компенсирующих вызовов — это тяжелый, но необходимый элемент доработки сервисов в рамках внедрения алгоритма саг.
Перечисленные выше три элемента актуальны для обоих вариантов реализации «cаг»: оркестрируемых и хореографических.
Оркестрируемые саги
Более простой и очевидный алгоритм оркестрируемых саг проще для понимания и реализации. В своей отличной статье kevteev описал алгоритм и процесс реализации механизма оркестрируемых саг в Авито. Их алгоритм предполагает существование контролирующего сервиса, «оркестрирующего» вызовы сервисов в рамках обслуживаемых бизнес-процессов. Этот же контролирующий сервис может обладать собственной базой данных (например, PostgreSQL), выступающей в роли надежного персистентного канала доставки событий (элемент 1).
Хореографические саги
С хореографической сагой хитрее. Тут в качестве надежного персистентного канала должна выступать шина данных, реализующая следующие требования: fire-and-forget publishing, publish-subscribe event delivery, at least once delivery. Т.е. каждый шаг каждого процесса должен получать команду на срабатывание из шины, и кидать туда же сообщение об успешном выполнении, о старте следующего шага, чтобы тот тоже прочитал его из шины и продолжил выполнение процесса. При этом на каждое сообщение может быть несколько подписчиков.
В хореографической саге тоже должен быть контролирующий сервис, сервис саг, но существенно более «легковесный». Сервис должен знать о зарегистрированных в системе бизнес-процессах, о составе входящих в каждый процесс шагов. Также он должен слушать шину, мониторить выполнение каждого процесса (каждого ключа идемпотентности), и, только если что-то пошло не так, либо кидать «повторы» конкретных шагов, либо кидать «отмены», «компенсации» для выполнившихся шагов.
Нюансы
Один из самых важных нюансов саг, отличающих их от классических транзакций, является отход от линейности, последовательности, обязательности каждого шага. Сага — это не обязательно линейная цепочка событий, этом может быть направленный граф: событие регистрации нового пользователя может породить несколько шагов в параллель (отправка смс, регистрация логина, генерация пароля, отправка письма), часть из которых может являться необязательными. В первом приближении кажется, что в подобной «разветвленной» саге с необязательными шагами тяжело определить завершение саги (процесса), но, на самом деле, все просто: сага (процесс) завершена, когда завершены все обязательные шаги, в любом порядке.
Второй нюанс, характерный скорее для хореографических саг, но возможный и для оркестрируемых, заключается в выборе подхода к регистрации бизнес-процессов, типов саг в сервисе саг. В примере для Atomicity описан процесс из четырех последовательных обязательных шагов.
Кто зарегистрировал этот процесс, указал все шаги, расставил зависимости и обязательность шагов? Очевидный, но старомодный ответ заключается в том, что регистрация процесса должна выполняться централизованно, в сервисе саг. Но этот ответ не очень соответствует микросервисной архитектуре. В микросервисной архитектуре более перспективно, более производительно и более быстро регистрировать процессы «снизу вверх». Т.е. не прописывать все нюансы процесса в сервисе саг, а дать возможность отдельным сервисам самостоятельно «вписываться» в существующие процессы, указывая свою обязательность/необязательность и обязательных предшественников.
Т.е. процесс регистрации пользователя в сервисе саг может изначально состоять из трёх шагов, а потом, в ходе развития системы, туда впишутся еще семь шагов, а один шаг выпишется, и их станет девять. Подобная «анархическая» и «децентрализованная» схема сложна для тестирования, для реализации строгого согласованного процесса, но она намного удобнее для Agile команд, для непрерывной разнонаправленной эволюции продукта.
Собственно вот. С серьезным изложением, думаю, стоит закончить, а то статья получилась слишком большая.
Вот ссылка на презентацию этого материала, доклад на эту тему я делал на Highload Siberia 2018.
UPD — и видео с конференции:
Эпилог
Напоследок хотел бы попробовать объяснить все, перечисленное выше, более образным языком.
Ведь что такое сага изначально? Это сюжет, это приключение из средних веков… Или из Игры Престолов. Происходит событие (битва, свадьба, кто-то умирает), весть об этом летит по миру через гонцов, через почтовых голубей, через купцов. Когда весть доходит до заинтересованных (через неделю, через месяц, через год), они реагируют: отправляют армии, объявляют войну, кого-то казнят, и летят новые вести.
Нет контролирующего органа, следящего за последовательностью действий. Нет транзакций, нет rollback, в смысле отмены действия, как будто его никогда не было. Все по-взрослому, каждое действие происходит навсегда. Его можно компенсировать, но это именно действие (убийство) и компенсация (плата за голову, вира), а не отмена смерти.
События идут долго, доходят из разных источников, действия происходят параллельно, а не строго последовательно. И довольно часто в сюжете внезапно возникают новые участники, решившие поучаствовать (прилетают драконы ;))… а кое-кто из старых участников внезапно умирает.
Такие дела. Вроде бардак и хаос, но все работает, внутренняя согласованность мира не нарушается, сюжет развивается и непротиворечив… Хотя иногда и непредсказуем.
Информационная безопасность для самых маленьких. Часть 1
Вступление.
Многие слышали про взломы различных платежных систем, про новые стандарты в области информационной безопасности, про то, что государство разрабатывает новые нормативы в области персональных данных. Некоторые даже слышали три таинственных слова «конфиденциальность, целостность и доступность», но не многие понимают, что все это означает и зачем все это нужно. Сюда относятся и многие ИТ — специалисты не говоря уже про людей далеких от ИТ.
Хотя в мире, где все основано на информационных технологиях, должны понимать что такое «информационная безопасность». Информационная безопасность – это не только антивирус и файрвол, информационная безопасность это целый комплекс мер.
На Хабре начинается серия публикаций по информационной безопасности, в этих публикациях будут рассмотрены многие важные аспекты ИБ, такие как:
• конфиденциальность, целостность и доступность;
• уязвимости в программных продуктах (также обсудим черный рынок 0-day уязвимостей и эксплоитов);
• технические меры защиты;
• организационные меры (политики, процедуры, инструкции);
• модели доступа;
• стандарты и законы в области ИБ.
А также обсудим другие очень интересные вещи. Как и любой другой предмет начнем с самых основ, то есть теории.
Недавно в Твитере развернулись нешуточные страсти по «бумажной» и «практической» безопасности. Здесь будут рассмотрены как «бумажная» так и «практическая» безопасность, хотя, по моему мнению, эти две составляющие нельзя делить. Если речь идет о серьезном подходе «практика» не может существовать без «бумаги», так как для начальства, аудиторов в первую очередь важны бумажные отчеты Вашей работы. Не говоря уже про такие стандарты ISO и PCI DSS, которые требуют утвержденные руководством «бумажной безопасности».
Конфиденциальность, целостность и доступность. 
Именно эти три слова служат прочным фундаментом информационной безопасности. Хотя многие считают что эта «триада» уже устарела, но об этом позже. Чтобы лучше понять значение этих слов необходимо представить следующую картину: три человека обхватили друг друга руками, и каждый сильно откинулся назад, если один из них отпустит руку другого то все упадут. Информационная безопасность достигается соотношением именно этих трех свойств, если у информации нету, хотя бы одной из этих свойств о безопасности говорить не приходиться.
Каждая из этих свойств «триады» обеспечивается рядом мер, причем для обеспечения одного свойства необходимо использовать не одно, а несколько мер. Любая информация обладает, так или иначе, всеми тремя свойствами, давайте разберем каждое значение их этой триады.
Конфиденциальность – свойство информации, гарантирующее, что доступ к информации имеет доступ только определенные лица.
Например. В фирме «Рога и копыта» есть информация, а именно отчет о продажах. Доступ имеют только сотрудники отдела продаж и бухгалтерии. Причем сотрудники отдела продаж имеют ко всей информации (более подробно будет описано ниже), а бухгалтерия только к окончательным расчетам (чтобы рассчитать налоги с продаж.).
Таким образом, конфиденциальность означает не только доступ к информации, но и разграничение доступа к информации, то Петров имеет доступ к одной части информации, Сидоров ко второй, а Иванов ко всей информации.
Целостность – свойство информации, гарантирующее, что только определенные лица могут менять информацию.
Например. Продолжим пример с фирмой «Рога и Копыта» и с их отчетом по продажам. Как было ранее сказано Отдел продаж имеет доступ ко всей информации, а бухгалтерия только к определенной части. Но для безопасности это еще мало. Необходимо еще и разграничить доступ среди Отдела продаж. В отделе есть два специалиста Сидоров и Петров, у каждого свой отчет. Необходимо чтобы каждый мог иметь право записи только в свой отчет. Вдруг Петров занизит продажи Сидорова.
Еще хороший пример.
Фирма «Рога и Копыта» создала и отправила платеж по ДБО в свой банка, однако хакер Вася перехватил платеж и в поле получателя вставил номер своего счета. Это прямое нарушение целостности. Чтобы такого не произошло необходимо предпринимать ряд мер, к примеру, ЭЦП.
Доступность – свойство информации, гарантирующее, что лица имеющие доступ к информации в нужный момент смогут получить доступ.
Например. Генеральный директор фирмы «Рога и Копыта» в понедельник утром пришел на работу, включил компьютер и с удивлением обнаружил, что не может открыть базу отдела продаж по продажам. Так что же произошло? Элементарно, Ватсон! В воскресенье ночью в потолке прорвало трубу, вода попала в компьютер, где хранилась база, и жесткий диск благополучно сгорел. Так как директор никогда не слышал про информационную безопасность, а локальная сеть была создана студентом, не было ни резервной копии, ни избыточности в виде RAID. Это самый простой пример, можно привести кучу примеров, сайт компании не был доступен и клиент не смог открыть сайт одной компании, но открыл сайт другой и естественно купил продукт второй компании.
Это было первым выпуском серии «Информационная безопасность для маленьких».
Продолжение следует.
Бухгалтерская (финансовая) отчетность. Ответы на экзаменационные билеты
Данное пособие является вспомогательным материалом для подготовки к экзаменам, зачетам по дисциплине «Бухгалтерская (финансовая) отчетность». Материал книги составлен в соответствии с Государственным образовательным стандартом высшего профессионального образования. Содержательность изложенного материала поможет студентам сдать экзамены на оценку «отлично». Пособие предназначено для студентов высших учебных заведений, обучающихся по специальности 060500 «Бухгалтерский учет, анализ и аудит».
Оглавление
Приведённый ознакомительный фрагмент книги Бухгалтерская (финансовая) отчетность. Ответы на экзаменационные билеты предоставлен нашим книжным партнёром — компанией ЛитРес.
7. Требования к информации, раскрываемой в отчетности
К данным, входящим в состав бухгалтерской отчетности, предъявляются следующие требования:
1) достоверность и полнота;
6) соблюдение отчетного периода;
7) правильность оформления;
Требование достоверности и полноты означает, что бухгалтерская отчетность должна давать достоверное и полное представление об имущественном и финансовом положении организации, а также о финансовых результатах ее деятельности.
При этом достоверной и полной считается бухгалтерская отчетность, сформированная и составленная исходя из правил, установленных нормативными актами системы нормативного регулирования бухгалтерского учета в РФ, при этом в исключительных случаях допускается отступление от правил, установленных ПБУ 4/99.
Требование нейтральности означает, что при формировании бухгалтерской отчетности должна быть обеспечена нейтральность информации, т. е. исключено преимущественное удовлетворение интересов одних групп пользователей бухгалтерской отчетности перед другими.
Требование целостности означает необходимость включения в бухгалтерскую отчетность данных обо всех хозяйственных операциях, осуществленных как организацией в целом, так и ее филиалами, представительствами и иными подразделениями, в т. ч. выделенными на отдельные балансы.
Требование последовательности означает необходимость соблюдения постоянства в содержании и формах бухгалтерского баланса, отчета о прибылях и убытках и пояснений к ним от одного отчетного года к другому.
Изменение принятых содержания и формы бухгалтерского баланса, отчета о прибылях и убытках и пояснений к ним допускается в исключительных случаях. Организацией должно быть обеспечено подтверждение обоснованности каждого такого изменения.
В соответствии с требованием сопоставимости в бухгалтерской отчетности должны содержаться данные, позволяющие осуществить их сравнение с аналогичными данными за годы, предшествовавшие отчетному.
Если организация принимает решение о раскрытии в бухгалтерской отчетности данных более чем за 2 года по каждому числовому показателю, то должна быть обеспечена сопоставимость показателей за все приводимые периоды.
Требование соблюдения отчетного периода означает, что в качестве отчетного года в России принят период с 1 января по 31 декабря включительно, т. е. отчетный год совпадает с календарным. Для составления бухгалтерской отчетности отчетной датой считается последний календарный день отчетного периода.
Датой предоставления отчетности для предприятий считается день фактической ее передачи по принадлежности или дата ее отправления, обозначенная на штемпеле почтовой организации. Если дата предоставления отчетности приходится на нерабочий день, то сроком представления отчетности считается первый следующий за ним рабочий день.
Требование правильного оформления связано с соблюдением формальных принципов отчетности:
1) составление ее на русском языке;
2) исчисление в валюте РФ (в рублях);
3) подписание руководителем организации и специалистом, ведущим бухгалтерский учет.
Требование существенности. Согласно п. 4 Методических рекомендаций существенной признается сумма, отношение которой к общему итогу соответствующих данных за отчетный год составляет не менее 5 %. Однако организация может принять решение о применении иного критерия существенности.
Показатели отдельных активов, обязательств, доходов, расходов и хозяйственных операций в бухгалтерской отчетности:
1) должны приводиться обособленно, если без них невозможна оценка финансового положения организации;
2) могут приводиться общей суммой, если каждый из этих показателей в отдельности несуществен.