slides/day9.html

<html lang="en">
	<head>
		<meta charset="utf-8">
		<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">

		<title>Акторы Akka: отказоустойчивость и гарантии. Back pressure. Роутеры.</title>

		<link rel="stylesheet" href="css/reveal.css">
		<link rel="stylesheet" href="css/theme/moon.css">

		<!-- Theme used for syntax highlighting of code -->
		<link rel="stylesheet" href="lib/css/zenburn.css">

		<!-- Printing and PDF exports -->
		<script>
			var link = document.createElement( 'link' );
			link.rel = 'stylesheet';
			link.type = 'text/css';
			link.href = window.location.search.match( /print-pdf/gi ) ? 'css/print/pdf.css' : 'css/print/paper.css';
			document.getElementsByTagName( 'head' )[0].appendChild( link );
		</script>
	</head>

	<body>

		<div class="reveal">

			<!-- Any section element inside of this container is displayed as a slide -->
			<div class="slides">
				<section>
					<h3>Акторы Akka: отказоустойчивость и гарантии. Back pressure. Роутеры.</h3>
					<p><small>Страничка курса: <a href="https://maxcom.github.io/scala-course-2022/">https://maxcom.github.io/scala-course-2022/</small></a>
				</section>

				<section>
					<h2>План</h2>
                                        <ol>
					  	<li>Доставка сообщений и сбои.</li>
					  	<li>CircuitBreaker.</li>
						<li>Back pressure</li>
						<li>Роутеры
					</ol>
				</section>

				<section>
					<h3>Гарантии доставки сообщений</h3>
				</section>

				<section>
					<p>Сообщение теряется при:</p>
					<ul>
						<li>Рестарте актора</li>
						<li class=fragment>Переполнении ограниченного mailbox</li>
						<li class=fragment>Сетевых проблемах</li>
						<li class=fragment>...</li>
					</ul>
				</section>

				<section>
					<p>Что гарантирует Akka?
					<ul>
					  <li>"Доставку" в локальный mailbox
					  <li class=fragment>Получение "Terminated"
					</ul>
				</section>

				<section>
					<p>Только одна попытка доставки:<br>«at most once delivery»</p>
				</section>

				<section>
					<p>Потеря сообщений - проблема "модели"?
					<p>Нет, это часть модели отказоустойчивости.
				</section>

				<section>
					<p>Пример: кофейня готовит кофе и принимает платежи.
					<p>Платежи со счета клиента,<br> счет хранится в БД кофейни.
				</section>

				<section>
					<p>Наша кофейня использует идеальную БД,<br>
					плюс нет параллельных запросов
					<ul>
						<li>A - Atomicity
						<li>C - Consistency
						<li>I - Isolation
						<li>D - Durability
					</ul>
				</section>

				<section>
					<p>Счет каждого посетителя хранится в табличке

					<p>Списания - через UPDATE
				</section>

				<section>
					<p>Согласована ли связка ПО + БД?
				</section>

				<section>
					<p>Наивное предположение:
					<ul>
						<li>Успешная транзакция - деньги списались
						<li>Неуспешная транзакция - не списались
					</ul>
				</section>

				<section>
					<p>Что значит ошибка сети или таймаут?</p>
					<ul>
						<li class="fragment">Не получилось начать транзакцию
						<li class="fragment">Транзакция прошла, но не прошло подтверждение
						<li class="fragment">Процесс еще не окончен
						<li class="fragment">+ ошибки и сбои (которых нет в идеальной БД)
					</ul>
				</section>

				<section>
					<p>Таймаут? Таймаут есть всегда
				</section>

				<section>
					<p>Итог - при сбое мы не знаем, списали деньги или нет.
					<p>Retry - возможно двойное списание, отказ от retry - возможна потеря денег
				</section>

				<section>
					<p>В асинхронной системе похожие проблемы:
					<ul>
						<li class="fragment">Переполненные очереди
						<li class="fragment">Медленные обработчики
						<li class="fragment">Плохо обработанные сбои и ошибки
					</ul>
				</section>

				<section>
					<p>Эти проблемы - проблемы как с акторами, так и без.
				</section>

				<section>
					<p>Решение проблемы</p>
					<ul>
						<li>Таймауты случаются. Нужно их обрабатывать.
						<li class="fragment">Сбои допустимы, сбои всегда частичные.
						<li class="fragment">Механизмы компенсации сбоев обязательны (например, журналы у всех участников операции и процедуры сверки)
					</ul>
				</section>

				<section>
					Компоненты распределенной системы<br>действуют независимо.
				</section>

				<section>
					<ul>
						<li>Блокировки снижают производительность и доступность. Блокировки всегда локальны.
						<li class="fragment">Глобальной консистентности нет, пока идут операции.
						<li class="fragment">Каждая операция консистентна только в конечном счете
					</ul>
				</section>

				<section>
					<h3>Вернемся к акторам</h3>
					<p>Сбой нельзя детектировать (в общем случае).<p>
					<p class=fragment>Сбой и таймаут не отличимы.<br>Таймаут — не конец операции.</p>
				</section>

				<section>
					<p>Потеря сообщения при доставке - это вариант сбоя.

					<p>Не нужно решать проблему ненадежной доставки. Вместо этого
						нужно обеспечить требуемые гарантии при сбоях.</p>
				</section>

				<section>
					<h3>Что обычно можно гарантировать?</h3>
					<p class="fragment">Положительный ответ только после записи в хранилище или выполнения действия</p>
					<p class="fragment">Откладывание выполнения с гарантиями - передача "эстафетной палочки". Похоже на передачу email.
				</section>

				<section>
					<h3>Команды и события</h3>
					<ul>
						<li>Команда: сделай что-то. Выполняем её с гарантиями. Терять нельзя.
						<li class="fragment">Событие: что-то произошло, реагируй на это. Можем пропустить,
							если потом можем это компенсировать.
					</ul>
				</section>

				<section>
					<p>Пример: гарантированное выполнение независимых запросов
				</section>

				<section>
					<p>Повторяем запрос, пока не получим подтверждение
					<pre><code class="scala">
object Requester {
  sealed trait Protocol

  case class Request(id: UUID, query: String, 
                     replyTo: ActorRef[String]) extends Protocol

  private implicit val timeout: Timeout = 10.seconds

  def behavior(worker: ActorRef[Protocol]): Behavior[Protocol]
}
					</code></pre>
				</section>

				<section>
					<pre><code class="scala">private case class Finished(request: Request, response: String) 
  extends Protocol
private case class Failed(id: UUID, ex: Throwable) 
  extends Protocol

Behaviors.setup { ctx =&gt;
  def start(rq: Request) = {
    ctx.ask(worker, Request(rq.id, rq.query, _)) {
      case Success(r) =&gt; Finished(rq, r)
      case Failure(ex) =&gt; Failed(rq.id, ex)
    }

    rq.id -&gt; rq
  }
  ...</code></pre>
				</section>

				<section>
					получение запроса
					<pre><code class="scala">
def process(processing: Map[UUID, Request]) = 
  Behaviors.receive[Protocol] {
    case (ctx, rq: Request) =&gt;
      process(processing + start(ctx)(rq))
  ...
					</code></pre>
				</section>

				<section>
					обработка ответа
					<pre><code class="scala">
case (_, Finished(rq, response)) =&gt;
  rq.replyTo ! response
  process(processing - rq.id)
case (_, Failed(id, ex)) =&gt;
  process(start(processing(id))
  Behaviors.same // logging?
					</code></pre>
				</section>

				<section>
					<p>Таймаут?
					<ul>
						<li>Нет общего таймаута на запрос. 
						<li>Нет "защиты" получателя.
					</ul>
				</section>
	
				<section>
					<p>Итог: "At least once delivery"
				</section>

				<section>
					<p>Проблема - дублирование действий.
					<p>Хорошо, когда действия идемпотентны.
				</section>

				<section>
					<p>Другой вариант: фильтруем дубли в worker по id.

					<p>Итог: "Exactly once delivery"
				</section>

				<section>
					<p>Еще проблема - порядок не сохраняется

					<p>Реализуем очередь
				</section>

				<section
					<p>Akka 2.6.4+: <a href="https://doc.akka.io/docs/akka/current/typed/reliable-delivery.html" target=_blank>готовая реализация</a> для нескольких сценариев
				</section>

				<section>
					<h3>Пример дизайна сервиса индексации сообщений</h3>

					<p>Перегоняем данные СУБД в Elasticsearch и Clickhouse
				</section>

				<section>
					<p>Требования:
					<ul>
						<li>Индексация не мешает укладке
						<li class=fragment>Когда все хорошо - индексируем новое сразу
						<li class=fragment>Когда плохо - индексируем, когда можем
						<li class=fragment>Иногда нужна переиндексация
					</ul>
				</section>

				<section>
					<p>Первый подход - нужна гарантированная очередь.

					<p>Это порождает массу проблем.
				</section>

				<section>
					<p>Появление нового в БД - событие, а не команда.
				</section>

				<section>
					<p>«Happy path &amp; self heal»</p>
					<p class="fragment">«Happy path» — новые сообщения индексируем сразу; игнорируем сбои</p>
					<p class="fragment">«Self heal» – периодически проводим сверку и запускаем в обработку то, что
					не смогли обработать ранее.</p>
				</section>

				<section>
					В прошлом году была еще лекция<br>про Event Sourcing и CQRS.
				</section>

				<section>
					<h3>Circuit Breaker</h3>
					<p>Паттерн, реализованный в Akka.<br>Есть другие реализации.
				</section>

				<section>
					<p>Проблема: каскадные сбои при перегрузках запросами. Безумные политики retry.
					<p class=fragment>Проблема: медленное восстановление после нормализации потока.
				</section>

				<section>
					Не только в акторах: очереди есть везде
				</section>

				<section>
					<p>«Предохранитель», который можно вставлять между подсистемами.</p>
					<p class="fragment">«Разрывает цепь» при серии сбоев</p>
					<div class="fragment">
					<p>«Замыкает цепь» после паузы и успешных пробных запросов.</p>
					</div>
				</section>

				<section>
					<p>В Akka реализован для Future.
					<p>Реализация требует ActorSystem
				</section>

				<section>
					<p>Пример:
					<pre><code class="scala">
  private val breaker = new CircuitBreaker(
    scheduler = scheduler, // context.system.scheduler
    maxFailures = 5,
    callTimeout = 10.seconds,
    resetTimeout = 1.minute
  )

  def process(task: Task): Future[Result] = {
    breaker.withCircuitBreaker {
      askAnotherService(task) // :Future[Result]
    }
  }
	</code></pre>
				</section>

				<section>
					<p>Это защитный механизм.
					<p>Не используем для регулировки скорости!
				</section>

				<section>
					<h3>Регулировка скорости обработки</h3>
					<p>Проблема: быстрый producer + медленный consumer = Out Of Memory</p>
					<ul>
					<li class="fragment">выбрасываем то, что не успеваем обработать
					<li class="fragment">замедляем producer'а (back pressure)
					</ul>
				</section>

				<section>
					<p>При синхронных вызовах проблемы нет
				</section>

				<section>
					<h3>Back pressure</h3>
					<p>Обратная связь от consumer к procuder.
				</section>

				<section>
					<p>Раньше делали сами - считали подтверждения для 
					оценки размера очереди.</p>

					<p>Это сильно усложняет актор.

					<p class="fragment">Сейчас используем Akka Streams:<br>
					об этом на 10-й лекции.
				</section>

				<section>
					<h3>Роутеры</h3>
				</section>

				<section>
					<p>Раздаем задачи пулу акторов

					<p>Похожи на акторы, low level реализация
				</section>

				<section>
					<p>Два механизма использования:
					<ul>
						<li>Pool - "рабочие" акторы являются дочерними
						<li>Group - распределяет нагрузку по существующим акторам
					</ul>
				</section>

				<section>
					<p>Простые стратегии:
					<ul>
						<li>RoundRobinRouting - для долгих задач
						<li>RandomRouting - для коротких
					</ul>
				</section>

				<section>
					пример
					<pre><code class="scala">
object Calculator {
  case class Calc(x: Long, replyto: ActorRef[Long])

  def worker: Behavior[Calc] = Behaviors.receiveMessage {
    case Calc(x, replyto) =&gt;
      replyto ! doWork(x) 
      Behaviors.same
  }

  ...
}
					</code></pre>
				</section>
				<section>
					<pre><code class="scala">
def calculator: Behavior[Calc] = Behaviors.setup[Calc] { ctx =&gt;
  // round-robin по умолчанию
  val pool = Routers.pool(poolSize = 16)(
    Behaviors.supervise(worker)
      .onFailure[Exception](SupervisorStrategy.restart))

  val router = ctx.spawn(pool, "worker-pool")

  Behaviors.receiveMessage[Calc] { msg =&gt;
    router ! msg
    Behaviors.same
  }
}
					</code></pre>
				</section>

				<section>
					<p>Проблема - сообщения перемешиваются
					<p>Актор - это не только вычисления, но и модель доступа
					к данным.
				</section>

				<section>
					<p>Пример - хранилище данных учетных записей
					<ul>
						<li>Один актор на всех - медленно
						<li>Каждому по актору - слишком много акторов
						<li>Группа акторов - случайное распределение задач
					</ul>
				</section>

				<section>
					<p>ConsistentHashingRouting - роутинг по ключу на основе сообщения

					<ul>
						<li class="fragment">сохраняет порядок для сообщений с одним ключем
						<li class="fragment">сохраняет обработчика для сообщений с одним ключем
						<li class="fragment">Consistent - определенная логика resize пула
					</ul>
				</section>

				<section>
					<p>В классической Akka есть еще интересные роутеры
				</section>

				<section>
					<p>ScatterGatherFirstCompletedRouting

					<p>Отправляем всем, используем первый ответ.

					<p class="fragment">Улучшаем время отклика, но выполняем работу N раз
				</section>

				<section>
					<p>TailChoppingRouting

					<p>Отправляем первому, через короткий таймаут второму и продолжаем, пока не
					получим первый ответ.

					<p class="fragment">Улучшаем худшие времена отклика.
				</section>


				<section>
					<p>Напоминаю:
					<ul>
						<li>Страничка курса:<br> <a href="https://maxcom.github.io/scala-course-2022/">https://maxcom.github.io/scala-course-2022/</a>
					</ul>
				</section>
			</div>

		</div>

		<script src="lib/js/head.min.js"></script>
		<script src="js/reveal.js"></script>

		<script>
			// More info about config & dependencies:
			// - https://github.com/hakimel/reveal.js#configuration
			// - https://github.com/hakimel/reveal.js#dependencies
			Reveal.initialize({
                                controls: true,
                                progress: true,
                                history: true,
                                center: true,

                                transition: 'slide', // none/fade/slide/convex/concave/zoom

				dependencies: [
					{ src: 'plugin/markdown/marked.js' },
					{ src: 'plugin/markdown/markdown.js' },
					{ src: 'plugin/notes/notes.js', async: true },
					{ src: 'plugin/highlight/highlight.js', async: true, callback: function() { hljs.initHighlightingOnLoad(); } }
				]
			});
		</script>

	</body>
</html>