c

Author: Udalov Igor

case-study.md

@@ -2,13 +2,15 @@
 
 ## Что за проект
 
-Команда `Unity` в `Rambler&Co`. Мы занимаемся разработкой продуктов, обеспечивающих работу редакций интернет-изданий - таких как [ferra.ru](https://www.ferra.ru/), [secretmag.ru](https://secretmag.ru/) и др.
+Команда `Unity` в `Rambler&Co`.
 
-Сайты разрабатываются отдельно группой фронтенда. На бэкенде есть набор сервисов, ключевые это:
+Мы занимаемся разработкой продуктов, обеспечивающих работу редакций интернет-изданий - таких как [ferra.ru](https://www.ferra.ru/), [secretmag.ru](https://secretmag.ru/) и др.
+
+Сайты разрабатываются отдельно группой фронтенда. На бэкенде есть набор приложений и сервисов, ключевые это:
 
 ### krang
 
-`CMS` на `postgres`, админка в которой работают редакции.
+`CMS` на `postgres`, админка в которой работают редакции (фронт разрабатывается отдельной командой).
 
 ### bebop
 
@@ -22,23 +24,27 @@
 
 ### krang
 
-Некоторые операции, такие как создание топика и др. могут занимать существенное время. Наверное, в рамках ДЗ мы попытаемся сконцентрировться на этом приложении.
+Некоторые операции, такие как создание топика и др., могут занимать существенное время.
+
+В рамках ДЗ мы попытаемся сконцентрировться на этом приложении.
 
 ### bebop
 
 Думаю, часть апи практически никогда не играет роль боттлнека по времени. Как обсуждалось на лекциях, сайты СМИ как правило тяжеловесны, и на их фоне выдача подготовленных данных из `mongoDB` не будет играть существенной роли.
 
 ## Есть ли мониторинг
 
-`New Relic` (подключен `krang`, `bebop` - планируется), `Kibana` с дашбордами и наверное, что-то еще чего пока не видел.
+- `New Relic` (подключен `krang`, `bebop` - планируется);
+- `Kibana` с дашбордами;
+- что-то еще, чего пока не видел.
 
 ## Можете ли вы навскидку предположить где в проекте есть что оптимизировать
 
-Когда получил доступ в `NewRelic` заметил на распухающее время `Redis zscan` за последнее 3 месяца - абсолютный лидер в числе тяжеловесных операций в данный момент, задача в работе.
+Когда получил доступ в `NewRelic` обратил внимание на распухающее время `Redis zscan`, за последнее 3 месяца - это абсолютный лидер среди тяжеловесных операций. Задача в работе.
 
 ## Какова ваша роль в проекте, как давно работаете, чем занимаетесь
 
-Инженер-разработчик группы бэкенд, в компании 1.5 года. Занимаюсь разработкой приложений/сервисов на `Ruby`, вкл. написание тестов, исправление багов и пр.
+Инженер-разработчик `Ruby` группы бэкенд, в компании 1.5 года. Занимаюсь разработкой приложений/сервисов на `Ruby`, вкл. написание тестов, исправление багов и пр.
 
 # Оптимизация Redis zscan
 
@@ -50,7 +56,7 @@
 
 <img src="/screenshots/top_20_db_operations_before.png" width="200" />
 
-Абсолютно большая часть нагрузки обусловлена выполнением `Sidekiq/Social::CountUpdaterJob`:
+Абсолютно большая часть нагрузки приходится на джобу `Sidekiq/Social::CountUpdaterJob`:
 
 <img src="/screenshots/redis_zscan_time_consumption_by_caller.png" width="200" />
 
@@ -60,9 +66,11 @@
 
 Задача данной джобы заключается в сборе данных о репостах из социальных сетей (в нашем случае `vk` и до недавнего времени - `facebook`).
 
-Наличие `redis zscan` в джобе обусловлено тем, что при постановке джобы мы ищем дубликаты по объектам - с целью минимизации общего кол-ва запросов. Требование связано с действющим на текущий момент ограничением `не более 1 запроса в 20 секунд`.
+Наличие `redis zscan` в джобе обусловлено тем, что при постановке джобы мы ищем дубликаты по объектам - с целью минимизации общего кол-ва запросов: требование связано с действующим на текущий момент ограничением `не более 1 запроса в 20 секунд`.
 
-Так в связи с подключением новых проектов база за последние 3 месяца выросла, пропорциональным образом (`O(N)`) возросло и время ее ответа.
+В связи с подключением новых проектов, база за последние 3 месяца выросла - пропорциональным образом (`O(N)`) возросло и время ответа `redis zscan`.
+
+Главной целью стал поиск путей отказа от проверки дублирования и как следствие - использования `redis zscan`.
 
 Первая мысль была в том, чтобы найти ручку `vk`, которая собирает данные по многим топикам сразу, пакетно: возможно, с момента нашего последнего обновления такая возможность появилась, но такая ручка не нашлась.
 
@@ -89,3 +97,37 @@
 <img src="/screenshots/redis.png" width="200" />
 
 Мы планируем еще понаблюдать за ситуацией, и после финализации решения установим защитный алерт для защиты метрики.
+
+# Профит
+
+Ориентировочный срок окупаемости - 3 месяца.
+
+```ruby
+# стоимость разработчика
+dev_cost_rub_month = 4_000 * 100
+=> 400000 # (руб/месяц)
+dev_cost_rub_day = dev_cost_rub_month / 20
+=> 20000  # (руб/день)
+
+# стоимоть требуемого увеличения мощностей (руб)
+# NOTE. сейчас redis работает на двух инстансах,
+#       таким образом, для увеличения мощностей пропорционально возросшей нагрузки,
+#       нам нужно 2 дополнительных сервера
+server_cost_rub_month = 3_000
+=> 3000
+redis_cost_rub_month = server_cost_rub_month * 2
+=> 6000
+
+# стоимость оптимизации (руб)
+task_cost_rub = dev_cost_rub_day * 1
+=> 20000
+
+# срок окупаемости (месяц)
+time_to_profit_month = task_cost_rub / redis_cost_rub_month
+=> 3
+```
+
+Без учета того, что:
+- общая нагрузка на `redis`, по сравнению с показателями 3-месячной давности, спала примерно в 2.5 раза;
+- ввод дополнительного сервера не защитил бы нас от возможного возвращения проблемы в будущем;
+- не только `CountUpdaterJob`, но и другие операции, использующие `redis`, стали выполняться быстрее.