Рубрика «Анализ и проектирование систем» - 113

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

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

Упрощенно задача выглядела так — нужно соединить микроконтроллер с мобильным приложением через интернет. Пример — нажимаем кнопку в приложении зажигается светодиод на микроконтроллере. Тушим светодиод на микроконтроллере и кнопка в приложении соответственно меняет статус.

Так как мы стартовали проект на кикстартере, перед запуском сервера в продакшене у нас уже была довольно большая база первых пользователей — 5000 человек. Наверное многие из Вас слышали про известный хабра эффект, который положил в прошлом многие веб ресурсы. Мы, конечно же, не хотели повторять эту участь. Поэтому это отразилось на подборе технического стека и архитектуре приложения.

Сразу после запуска вся наша архитектура выглядела так:

12 млрд реквестов в месяц за 120$ на java - 1

Это была 1 виртуалка от Digital Ocean за 80$ в мес (4 CPU, 8 GB RAM, 80 GB SSD). Взяли с запасом. Так как “а вдруг лоад пойдет?”. Тогда мы действительно думали, что, вот, запустимся и тысячи пользователей ринут на нас. Как оказалось — привлечь и заманить пользователей та еще задача и нагрузка на сервер — последнее о чем стоит думать. Из технологий на тот момент была лишь Java 8 и Netty с нашим собственным бинарным протоколом на ssl/tcp сокетах (да да, без БД, spring, hibernate, tomcat, websphere и прочих прелестей кровавого энтерпрайза).

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

try (BufferedWriter writer = Files.newBufferedWriter(fileTo, UTF_8)) {
  writer.write(user.toJson());
}

Читать полностью »

Кэш глазами «чайника»:

Кэши для «чайников» - 1

Кэш – это комплексная система. Соответственно, под разными углами результат может лежать как в действительной, так и в мнимой области. Очень важно понимать разницу между тем, что мы ждем и тем, что есть на самом деле.

Давайте прокрутим полный оборот ситуаций.

Tl;dr: добавляя в архитектуру кэш важно явно осознавать, что кэш может быть средством дестабилизации системы под нагрузкой. Смотрите конец статьи.
Читать полностью »

Задача: Компания (далее Компания) разрабатывает и выпускает некоторый продукт (далее Продукт). Необходимо создать программное обеспечение для проверки Продукта на сборочной линии (далее Линия) некоторой сторонней или принадлежащей компании фабрике (далее Завод).

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

Цель: Грамотно сгладить ошибки разработки тестового ПО для фабрики, допускаемые в процессе жизненного цикла Продукта.

Примечание: под Продуктом понимается некоторое устройство или его часть, обладающее внутренней логикой, SW / FW / Функционал которого требуется проверить. Пример: сотовый телефон, контроллер, программируемые устройства, материнская плата.
Читать полностью »

Аббревиатуры SDN и NFV в последнее время звучат все чаще и звучат вместе. В тендерах операторы связи требуют от производителей обязательной поддержки SDN и NFV, т.к. уверены, что эти технологии оказывают положительное влияние на OPEX, CAPEX и TTM. Быстрый серфинг интернета показывает, что SDN — это Software-Defined Networking, а NFV — это Network Functions Virtualization. Обе технологии связаны с виртуализацией и с сетями, т.е. на первый взгляд складывается впечатление, что они очень похожие, если не одно и то же. Давайте разбираться, так ли это на самом деле! Проверка по Google Trend сначала подтверждает гипотезу: тренд запроса «SDN and NFV» начинается в 2013 году:

SDN & NFV и при чем тут Облака - 1
Читать полностью »

Новый принцип межсетевого экранирования - 1


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

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

Устройства, реализующие рассмотренный ниже принцип, не требуют настройки, не мешают работе типовых клиентских приложений, устойчивы к деактивации по сети и обеспечивают гарантированный базовый уровень информационной безопасности. Демонстрацию их работы можно увидеть на видео в конце данной статьи.
Читать полностью »

Информационная безопасность АСУ ТП: Дон Кихот в эру кибероружия - 1
В данной статье проведена систематизация требований к информационной безопасности (ИБ) АСУ ТП. Требования выбраны из доступных на настоящий момент стандартов, в первую очередь, из NIST SP 800-82 «Guide to Industrial Control Systems (ICS) Security» и разрабатываемой новой редакции серии ISA/IEC 62443 «Security for Industrial Automation and Control Systems».

АСУ ТП взаимодействуют с объектами физического мира и обеспечивают защиту от аварий и катастроф. В англоязычной литературе АСУ ТП называют Industrial Control Systems (ICS) или Industrial Automation and Control Systems (IACS). В мире IT технологий их можно сравнить с Дон Кихотом, который остался верен простым, но не очень модным принципам в уже давно изменившемся мире.

Поэтому, была проведена параллель с функциональной безопасностью и рассмотрен комплекс требований, позволяющих обеспечить обе стороны безопасности АСУ ТП, и функциональную, и информационную.

Похожие проблемы следует решать и для других кибер-физических систем, включая IoT и встроенные управляющие системы.
Читать полностью »

Привет! Я уже давно наблюдаю за тобой, но все никак не решаюсь сделать свой первый шаг. Теперь мне показалось что я готов. Расскажу о своем опыте работы с telegram ботом — последнее время эта тема достаточно популярна на просторах сети, да и на самом Хабре я встречал уже не мало статей. Но по большей части в них рассказывается о принципах создания ботов, и нет ни слова о том, какую практическую пользу можно из этих самых ботов извлечь.
Читать полностью »

Зловреды-вымогатели для IoT опаснее «традиционных» зловредов - 1

Зловреды, используемые для вымогательства (ransomware), в этом году стали одной из серьёзнейших киберугроз. И сегодня все — от обычных пользователей до корпораций и правительственных организаций — стараются обезопасить себя от программ-шифровальщиков. Однако, мы пока игнорируем начало следующей волны атак зловредов-вымогателей, которые нацелены на шифрование не файлов, а устройств, подключённых к интернету вещей. И это может быть куда опаснее и убыточнее, учитывая вездесущую и крайне разнообразную природу IoT.Читать полностью »

Одной из приятных особенностей технологии 1С:Предприятие является то, что прикладное решение, разработанное по технологии управляемых форм, может запускаться как в тонком (исполняемом) клиенте под Windows, Linux, MacOS X, так и как веб-клиент под 4 браузера – Chrome, Internet Explorer, Firefox, Safari, и все это – без изменения исходного кода приложения. Более того – внешне приложение в тонком клиенте и в браузере функционирует и выглядит практически идентично.
Найдите 10 отличий (под катом 2 картинки):
Читать полностью »

Протокол QUIC (название расшифровывается как Quick UDP Internet Connections) — совершенно новый способ передачи информации в интернете, построенный поверх протокола UDP, вместо общепринятого ранее использования TCP. Некоторые люди называют его (в шутку) TCP/2. Переход к UDP — наиболее интересная и мощная особенность протокола, из которой следуют некоторые другие особенности.

Сегодняшний Web построен на протоколе TCP, который был выбран за его надёжность и гарантированность доставки пакетов. Для открытия TCP-соединения используется так называемое «трёхкратное рукопожатие». Это означает дополнительные циклы отправки-приёма сообщений для каждого нового соединения, что увеличивает задержки.

image

Если вы захотите установить защищённое TLS-соединение, придётся переслать ещё больше пакетов.

image

Некоторые инновации, вроде TCP Fast Open, улучшат некоторые аспекты ситуации, но эта технология пока не очень широко распространена.

Протокол UDP, с другой стороны, построен на идее «отправить пакет и забыть о нём». Сообщение, отправленное по UDP, будет доставлено получателю (не гарантированно, с некоторой вероятностью успеха). Яркое преимущество здесь в меньшем времени установки соединения, такой же яркий недостаток — негарантированность доставки или порядка прихода пакетов получателю. Это означает, что для обеспечения надёжности придётся построить некоторый механизм поверх UDP, который гарантирует доставку пакетов.

И здесь на сцену выходит QUIC от Google.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js