Akka

Akka는 Open Source Tool Kit으로 JVM 상에서 동시성과 분산 애플리케이션을 단순화하는 런타임이다. Erlang(범용 병렬 프로그래밍 언어 / 함수형 언어)으로부터 영향을 받아 Actor 기반의 동시성이 두드러진다.Actor Model액터 모델은 얼랭

핑퐁 액터는 액터를 만들과 실행하기 위한 가장 기본적인 방법이다. 이는 Akka의 Hello World와 같은 예제이다.예제 코드를 먼저 작성하고, 이들을 분석하면서 정리해나갈 예정이다.우리는 다음과 같은 Akka 프로그램을 설계할 것이다.(1) "핑"이라는 액터와 "

우리는 이전 게시물의 예제에서 Actor라는 trait를 상속 받아 원하는 액터 객체를 생성했다. 그리고, Actor trait 안에 있는 receive 메서드를 사용하여 액터의 행위를 선언하였다.이번 포스트에서는 이외에도 많은 Actor API들을 알아보려고 한다.만

각 Actor들은 고유한 논리적인 경로를 가지고 있다. 이러한 논리적 경로는 자식 액터부터 부모 액터로 타고 올라가 최후에는 액터 시스템의 루트, 즉 액터 시스템의 최상위까지 갈 수 있다.이러한 경로들은 액터들을 찾기위해 사용된다. 예를 들어 메시지 수신자를 찾을 때,

메시지들은 어떠한 종류의 객체도 가능하나, 반드시 불변(immutable)해야 한다. 스칼라는 강제로 immutability를 집행할 수 없으므로 컨벤션으로 immutability를 지킨다.추천하는 접근 방법은 Scala case class들을 사용하여 immutabl

메시지들은 Scheduler를 직접적으로 사용함으로써 미래에 보내지도록 설정할 수 있다. 하지만, 스케줄링 기간이나 액터에서의 개별 메시지들은 named timer들을 사용하는 것이 더 편리하고 안전하다.스케줄링된 메시지들의 라이프사이클은 액터가 재시작되고 타이머로부터

supervision이란 액터들 사이의 의존 관계를 뜻한다. supervision은 task들을 하위 액터에 위임을 한다. 그러므로 supervision은 반드시 실패에 응답을 해야한다. 만약 task를 위임 받고 실행시키다가 실패를 탐지하면(예를 들어 예외를 thro

우리는 각각의 액터들은 그들 자손 액터의 supervisor인 것을 알아보았다. 그리고 그러한 액터들은 supervisor strategy로 failure가 발생했을 시 fault handling 정책 2가지를 앞에서 정리했었다. 하지만 이러한 정책들은 수립되고 나면

Akka의 MessageDispatcher는 Akka 액터들이 말할 수 있게 해준다. 모든 Dispatcher는 ExecutionContext 인터페이스를 implement한다. 따라서 Future를 실행시킬 수 있다. 모든 ActorSystem은 디폴트 디스패처를 가

Akka에서 MailBox는 액터로부터 온 메시지들을 보관하는 곳이다. 보통 모든 액터들은 각자의 메일박스를 가지고 있다. 하지만, BalancingPool은 하나의 메일박스 인스턴스를 공유한다.메일박스가 따로 설정되지 않았다면 디폴트 메일박스가 사용된다. 이 메일박스

Classic Fault Tolerance 1 포스트에서 supervisor strategy를 만들고 적용하는 방법에 대해 정리했었다. 이번 포스트에서는 해당 내용들을 적용하는 것을 실제 예제로 다룰 것이다.가장 먼저 예제를 위한 적당한 supervisor 액터를 선언

이 글은 Akka in action Chapter.5 - Futures를 읽고 작성한 글입니다.Scala에 대해 정리하면서 Future에 대한 정리한 게시물들을 올린 적 있었다. 이 포스트에서는 Future의 문법적인 사용법에서 더 나아가 Akka에서 어떻게 사용되는지

이 글은 Akka in action Chapter.2를 읽고 작성한 글입니다.이 챕터에서는 어떻게 간단한 Akka 앱을 만드는지를 공부할 수 있는 챕터이다. 여기서 사용되는 정확한 인프라들은 추후 책 뒤에서 자세하게 다룬다. 그 전에 어떻게 Akka 코드를 사용하여 R

발신자가 보낸 메시지를 수신자에게로 보낼 때, 노드의 멤버들을 클러스터가 인식할 수 있도록 할 수 있다. 만약 노드에 갈 수 없거나 경로를 떠날 수 없을 때 사용된다. 만약 새로운 노드가 클러스터에 들어온다면 configuration에 근거하여 추가적인 경로가 라우터에

Akka Framework에서 사용하는 스칼라의 Actor는 JVM 상에서 분산적이며 동시성이 있는 프로그램들을 작성하는데 도움을 준다. 이러한 액터들은 독립적이지만, 상당히 가볍다. 200만 개의 액터들이 힙에서 차지하는 메모리 영역은 고작 1GB이다. 이러한 액터들

Akka로 예외처리

PersistentFSM은 FSM으로 들어오는 메시지들을 다룰 때 사용한다. 일련의 변화에 따라 내부 상태가 유지되며, 도메인 이벤트에 의해 인용되어진다. 수신되는 메시지들과 FSM의 상태 및 변화, 도메인 이벤트의 영속성의 관계는 DSL에 의해 정의된다.Persist

Persistent FSM은 Persistence Typed를 사용하여 나타내어진다. 스냅샷 어댑터와 이벤트 어댑터를 사용하는 EventSourcedBehavior를 사용하여 Persistence FSM에 저장된 데이터를 읽을 수 있다.FSM이 유저 데이터를와 스냅샷들

클러스터에 있는 액터 시스템 간 메시지를 보내기 위해서는 직렬화를 꼭 시켜야 한다. Serialization with Jackson은 좋은 선택지 중 하나이다. Cluster API Extension Reference Classic Cluster Usage

Akka의 I/O API는 액터 기반의 API이다. 즉, 모든 연산들은 직접적인 메서드 호출 대신 메시지를 패싱하는 방식으로 이루어진다. TCP나 UDP 같은 모든 I/O 드라이버들은 매니저라고 불리는 특별한 액터를 가지고 있다. 매니저라는 액터는 API의 entry

한 집단의 액터들에게 메시지를 보내는것은 EventBus를 사용하여 일반화한 후 보내도록 한다. > EventBus Reference Akka Classic Event Bus EventBus

Subclassification이라는 trait를 확장하여 classifier가 계층을 이루었을 경우 리프 노드들에서 뿐만 아니라 구독이 가능하기를 원한다면, 이 classification는 딱 맞을 수 있다. 이것은 장르별로 라디오 채널을 튜닝(아마도 여러 개)하는

event stream은 각 액터 시스템의 메인 이벤트 버스이다. 이는 log messages를 옮기거나 Dead Letters를 옮길 때 사용된다. 그리고 다른 목적의 유저 코드를 위해 사용되기도 한다. 이런 event stream은 연관되어 있는 채널들의 세트를 등

Akka에서의 로깅은 특정 로깅 백엔드에 묶여 있지 않다. 기본적으로 로그 메시지는 STDOUT에 출력되지만 SLF4J 로거나 자신의 로거를 플러그인할 수 있다. 로깅은 로깅이 성능에 미치는 영향이 최소가 되도록 비동기적으로 수행된다. 로깅은 일반적으로 I/O와 loc

로깅은 이벤트 버스(event bus)를 통해 비동기적으로 수행된다. 로그 이벤트들은 로그 이벤트들이 방출된 것과 동일한 순서로 수신되는 이벤트 핸들러 액터에 의해 처리된다.이벤트 핸들러 액터는 유계된 받은편지함을 갖지 않고 디폴트 디스패처 상에서 실행된다. 이것은 극

클러스터 싱글톤 패턴은 akka.cluster.singleton.ClusterSingletonManager에 의해 구현된다. 모든 클러스터 노드 또는 특정 역할이 태그된 노드 그룹 중에서 하나의 싱글톤 액터 인스턴스를 관리한다. ClusterSingletonManage

만약 숫자를 세는 actor가 있다고 생각을 해보자.직관적으로 다음과 같은 코드를 작성할 것이다.var로 선언되어 있는 변수 count는 들어오는 메시지에 따라 값이 변화가 될 것이다. 하지만 mutable한 부분을 최대한 줄일 수 있지 않을까? 이를 위해서는 상태가

Actor는 내부에서 액터를 생성할 수도 있다. 간단한 예로 다음과 같은 코드가 될 수 있다.위의 코드를 작성하고 main에서 다음과 같은 메시지를 보낸다면 결과는 다음과 같다.위의 코드를 실행하면 밑과 같이 된다.부모 액터에서 생성한 자식 액터가 제대로 생성되었으며,

Akka에서 테스트 코드를 작성하는 법을 정리하려고 한다.다음과 같은 3개의 액터가 있다고 생각하자.SimpleActorBlackholeActorLabTestActor위의 3개 액터에 대한 테스트 코드를 작성하고자 한다. 이때, asynchronous한 테스트로 작성되

서버 개발을 하며 가장 중요한 것들 중 하나는 로그이다. 로그를 확인하며 잘 동작하고 있는지 확인하는 것이 좋다. 하지만, 로그를 남발하게 된다면 성능 저하와 과도한 로그 사이에서 중요한 로그를 찾기 힘들 수 있다는 단점이 있다.이번 포스트에서는 로그를 설정하기 위한

일정 시간마다 균일하게 특정 작업을 실행하고 싶은 경우가 있을 것이다. 이런 경우 Scheduler와 Timer를 사용하여 일정한 기간 동안 반복하여 실행할 수 있다.스케줄러는 system.scheduler로 접근하여 사용할 수 있다.scheduleOnce(delayP

여러 actor에게 여러 일들을 위임하거나 분산시킬 때, Router를 사용하면 유리하다. 라우터는 다른 액터에게 메시지를 forward하는 중간레벨의 actor이다. 라우터는 바깥에서 생성되거나 그들 자신들로부터 생성된다. 1. pool routes (1) prog

우리는 간혹 먼저 들어온 메시지들의 처리를 미루어야 할 때가 있다. 간단한 예시 상황을 들면 다음과 같다. 만약 어떤 액터 내부의 데이터를 처리하는 DB가 연결되지 않은 상태에서 Read나 Write라는 메시지들이 들어온 경우, 당연히 DB가 연결될 때까지 기다렸다가

다른 액터에게 request를 보내고, 해당 액터로부터 response를 받아야 하는 경우가 많다. 하지면 이 경우에 tell을 사용할 경우 액터의 캡슐화를 깨뜨릴 수 있다. 따라서 비동기적으로 일들을 처리하는 방법에는 ask를 사용하는 방법이 있다.이를 학습하기 위해

우리는 백엔드를 긴 기간 동안 사용하려면 데이터베이스를 사용하거나 cloud-based storage를 사용해야 하는 것은 필연적이다. 이를 위해서는 DB와 상호작용을 하는 Akka Actor가 필요하다.기존 액터들에는 다음과 같은 문제점이 존재한다.1\. 이전 sta

이전 포스트의 코드에 만약 PoisonPill이나 Kill과 같은 메시지를 보내어 액터를 shutdown한다면 어떻게 될까?즉, 메인 오브젝트가 다음과 같다면 어떻게 될까?코드의 순서로만 본다면 Invoice 메시지가 10번 accountant 액터에게 전송된 후 액터

우리는 이전 포스트(https://velog.io/@leesomyoung/Akka-Persistent-Actor답은 간단하다. 저장할 이벤트마다 persist 혹은 persistAll을 실행하면 된다. 다음과 같은 예시를 통해 알아보자.우리는 DiligentA

Akka Persistent Actor의 단점 중 하나는 오랫 동안 살아있는 Persistent Actor의 Recovery 시간이 길다는 점이다. 즉, 오래 살아남을수록 저장되는 이벤트도 계속 누적될 것이고, 이는 회복 시간도 누적된 이벤트 수에 비례하여 증가할 것이

우리는 Akka의 Event Sourcing을 정리하며 persist나 persistAll 메서드를 사용하여 이벤트들을 저장하고 recovery 시 재생될 수 있도록 하였다. (이 포스트(https://velog.io/@leesomyoung/Akka-Persi

snapshot을 정리한 포스트에서 우리는 leveldb를 사용하여 로컬 journal에 데이터들을 저장했었다. 이번 포스트에서는 이에 대해 조금 더 보충할 예정이다. 스냅샷을 위해 다음과 같이 간단한 PersistentActor를 선언하자. 이 액터는 "snapsh

우리는 이전 포스트에서 로컬 스토리지 snapshot을 사용했다. 하지만 이번 포스트에서는 Cassandra를 사용하는 법을 정리해놓으려고 한다.libraryDependencies에 다음과 같은 2가지 dependency를 추가한다.위는 카산드라를 사용하기 위한 dep

Event Adapter는 Schema가 변경되었을 때 자동으로 변환시켜주는 어댑터이다. Event Adapter는 다음과 같은 순서로 동작한다actor -> WriteEventAdapter -> Serializer -> journal -> ReadEventAdapt

Persistent store는 데이터를 읽기 위하여 사용한다. 이때, Persistence Query를 사용한다면 다양한 기능들을 사용할 수 있다.1\. SELECT persistence IDs2\. select events by persistence ID3\. se

우리는 비동기적으로 실행되며 많은 양의 데이터를 처리할 수 있는 시스템을 가지고 싶다. 이를 위해서는 Akka Stream을 사용해야 한다. Akka stream은 reactive distributed system이다. 본격적으로 Akka stream에 대해 공부하기

Stream이 실행 중일 동안 Source(Publisher), Flow(Processor), Sink(Subscriber)는 static하다. 즉, run 메서드가 실행되기 전까지는 아무런 행동을 하지 않는다. 다만 해당 컴포넌트들이 엮여 그래프만 구성되어져 있을 것

Akka Stream은 기본적으로 Stream Operator(Source, Sink)를 하나로 합친다(fuse). 따라서 합쳐진 결과로 생성된 그래프는 같은 액터에서 실행되게 된다. 비동기 메시지의 오버헤드 때문에 하나의 Operator에서 다른 Operator로 데

이전 Akka 포스트들에서 Source, Flow, Sink를 엮어서 graph를 만들었다. 하지만 그전에는 input과 output이 1:1인 그래프만 작성했었다. GraphDSL을 사용하여 1:N 관계가 포함된 복잡한 그래프 역시 작성해 볼 예정이다.fan-infa

우리는 이전 포스트들에서 context.become을 사용하여 상태(핸들러)를 변환했었다. 하지만, context.become은 매우 복잡한 메서드이므로 이를 대체할 수 있는 FSM(Finite State Machine)에 대해 알아보려 한다. FSM은 Finite

이전까지 Akka를 공부하며 Actor는 다음과 같은 특징을 갖는다는 것을 공부했었다.Actor는 메시지 기반으로 소통한다.각각의 Actor는 캡슐화되어 있으며, Reference(ActorRef)를 통해 소통한다.at most once delivery 기반(sende

이번 포스트에서는 Akka Clustering에 대한 간단한 이론을 정리하려고 한다.Akka Clustering은 분산 애플리케이션을 만들 때 매우 효과적이다.decentrailzed, peer to peer에 기반한다.Automatic Node membership과