Post
KO

Akka (1)

Akka** 프로세스 코어와 네트워크를 망라하는 확장 가능하고 탄련적인 시스템을 설계하기 위한 오픈소스 라이브러리임.

Akka에서는 다음과 같은 기능을 제공해준다.

다중쓰레드 동작에서 저수준의 동시성 구조 동기화처리 없이 동작한다.

메모리 가시성 문제에 관련하여 생각 할 필요가 없다.

시스템과 컴포넌트 사이의 투명한 원격 통신. 네트워크 코드를 얼렵게 유지보수 하거나 작성할 필요가 없다.

요구에 따라 탄력적이고 확장성이 뛰어난 클러스터 된 고 가용성 아키텍처 입니다.

Akka와 Actor 모델을 학습하면, 어려운 분산/병렬/시스템의 문제를 알맞게 프로그래밍 할 수 있고 어떤 것이든지 알맞고 효율적인 것에 접근할 수 있게 될 것 입니다..

액터 모델이란?** 액터 모델은 대규모 조직의 사람들과 달리 의사소통 코드를 생각할 수 있는 추상화 기능을 제공해줍니다.

액터의 기본적인 특징은 세계의 stateful한 객체들이 각각의 명확한 메시지를 통하여 의사소통을 하는 것을 모델링 할 수 있다.

특징. 메시지 호출 대신에 비동기적인 메시지를 통하여 의사소통을 합니다. 자신의 상태를 관리 합니다. 메시지를 응답할 때 그들은 다음과 같이 할 수 있습니다.  Create Other (child)Actor  Send message to other Actors.  Stop (child) actors or themselves

Actor모델은 어떤 문제를 풀 수 있는가?** Akka 는 Actor 모델을 사용하여 OOP 프로그래밍 모델과 고도로 분산 처리 시스템의 전통적인 제한을 극복합니다.

완벽하게 이해하기 위해서는 Actor 모델이 필요합니다. 이것은 전통적인 프로그래밍 접근과 현실적인 동시성과 분산 처리 사이의 불일치를 확인할 수 있도록 도와줍니다.

객체 지향 언어에서는 일반적으로 스레드 또는 선형 실행 경로를 거의 고려하지 않습니다. 우리는 종종 메소드 호출에 반응하고, 내부 상태를 수정 한 다음 메소드 호출을 통해 서로 통신하여 전체 어플리케이션 상태를 앞으로 유도하는 객체 인스턴스 네트워크로 시스템을 구상합니다.

![](/assets/images/posts/221033636275/625ba534d775.png)

그러나 다중 스레드 분산 환경에서 스레드는 실제로 메소드 호출에 따라 객체 인스턴스의 네트워크를 “트래버스 (traverse)”합니다. 결과적으로 스레드는 실제로 실행을 유도합니다.

![](/assets/images/posts/221033636275/ef4c3635da3b.png)

요약**객체는 단일 스레드 접근에도 불구하고 캡슐화 (불변성 보호)를 보장 할 수 있습니다. 다중 스레드 실행은 거의 항상 내부 상태가 손상되게합니다. 모든 불변 값은 동일한 코드 세그먼트에 두 개의 경합하는 스레드를 가짐으로써 위반 될 수 있습니다.

잠금장치는 여러 스레드로 캡슐화를 유지하는 자연스러운 치료법 인 것처럼 보이지만 실용적으로는 실효성이 떨어지며 실세계 적용시 교착 상태로 이어질 수 있습니다.

잠금은 로컬에서 작동하고 배포를 시도하지만 스케일 아웃 가능성은 제한적입니다.

액터 모델과 기존 아키텍처 모델의 차이점?** 객체지향언어에서 사용하는 아키텍처 특성상 멀티 쓰레드 환경에서 완벽한 분리를 할 수 없고, 분산시스템을 구축한다고 해도 복잡하다.

멀티쓰레드 환경에서는 공유 자원 문제를 해결하기 위해서 thread safe한 코드를 작성해야 하는 것과

비동기 메시지 처리 (Spring reactor)와 같은 방식의 main thread와 별도 thread로 나뉘어져 있는 아키텍쳐에서. 기존에 아키텍쳐로는 별도 Thread ( worker Thread로 하겠다)로 던진 뒤 거기에서 발생되는 장애 사항에 대해서는 Main Thread에서는 처리할 수 없었다.

(이것은 비동기적 처리에서 동기적으로 응답값을 반환받을 수 없다는 것과 같은 맥락?? 이라고 여겨진다.)

![](/assets/images/posts/221033636275/d8bb9eee4d0b.png)

이러한 상황에서는 main thread에게 메시지가 알림이 전달되지 않고 메시지가 손실되는 것이

이것은 네트워크 시스템에서 메시지/요청이 통지 없이 손실되거나 실패할 수 있는 작업과 놀랍도록 유사하다. 이러한 상황에서는 일이 정말로 잘못 될 때 악화되고 쓰레드가 지원하는 작업자는 버그가 발생하여 복구 할 수 없는 상황에 처하게 됩니다.

요약**객체는 단일 스레드 접근에도 불구하고 캡슐화 (불변성 보호)를 보장 할 수 있습니다. 다중 스레드 실행은 거의 항상 내부 상태가 손상되게합니다. **모든 불변 값은 동일한 코드 세그먼트에 두 개의 경합하는 스레드를 가짐으로써 위반 될 수 있습니다.**잠금은 여러 스레드로 캡슐화를 유지하는 자연스러운 치료법 인 것처럼 보이지만 실용적으로는 실효성이 떨어지며 실세계 적용시 교착 상태로 이어질 수 있습니다.**잠금은 로컬에서 작동하고 배포를 시도하지만 스케일 아웃 가능성은 제한적입니다.**

현재 시스템에서 의미있는 동시성과 성능을 얻기 위해 스레드는 차단하지 않고 효율적인 방식으로 서로간에 작업을 위임해야합니다. 이러한 유형의 작업 - 동시성 위임 (네트워크 / 분산 컴퓨팅의 경우 더욱 그렇다)으로 호출 스택 기반의 오류 처리가 중단되고 새로운 명시 적 오류 신호 메커니즘이 도입되어야합니다. 실패는 도메인 모델의 일부가됩니다.

작업 위임이있는 동시 시스템은 서비스 결함을 처리하고 복구해야 할 원칙적 수단이 있어야합니다. 이러한 서비스의 클라이언트는 다시 시작하는 동안 작업 / 메시지가 손실 될 수 있음을 인식해야합니다. 손실이 발생하지 않더라도 이전에 대기열에 포함 된 작업 (긴 대기열), 가비지 수집으로 인한 지연 등으로 인해 응답이 임의로 지연 될 수 있습니다. 이와 같은 상황에서 동시 시스템은 제한 시간 형태로 응답 마감 시간을 처리해야합니다. 네트워크 / 분산 시스템과 유사합니다.

어떻게 액터 모델이 동시,분산 시스템을 충족시키는가****일반적인 프로그래밍 방법으로는 최신 동시성과 분산시스템을 충족시킬 수 없다는 것을 위의 섹션에서 설명했었다.

고맙게도 우리는 우리가 알고 있던 것들을 버릴 필요가 없다.

대신에, 액터 모델은 이러한 단점들에 대해 시스템에 더 알맞는 개념적인 모델에 행동을 할 수 있도록 허락한다.

액터 모델은 다음과 같이 하고 싶습니다.

  • 잠금에 의존하지 않고 캡슐화 한다.
  • 협력적인 객체의 신호를 통해 반응하고, 상태를 변경하고 신호를 다른 전체 application 에게 전달한다.
  • 우리들 세계관이 불일치한 실행 메카니즘에 대해서 걱정할 필요가 없다.

 액터는 메서드 호출하는 대신 서로에게 메시지를 보냅니다. 메시지를 보는 것은 실행 스레드를 보낸 사람에서 대상으로 전송하지 않습니다. 액터는 메시지를 보내고 차단하지 않고 계속 할 수 있습니다. 따라서 더 많은 일을 하고 메시지를 보내고 받을 수 있습니다.

객체를 메소드에서 리턴할때 실행중인 스레드에서 반환됩니다.

이 경우에 액터의 동작은 객체와 더 비슷합니다. 액터들은 메시지들에 반응하며 현재 메시지가 처리될때 실행을 반환합니다.

![](/assets/images/posts/221033636275/8339266af7fa.png)

메서드를 호출하는 대신 메시지를 전달하는 중요한 차이점은 메시지에 반환값이 없다는 것이다. 메시지를 보내서 다른 액터에게 작업을 위임합니다. 콜 스택의 환영 섹션 처럼 리턴 값을 기대한다면, 보내는 액터는 다른 액터의 작업을 동일한 스레드에서 잠금을 걸어 실행해야 합니다. 대신 메시지를 수신한 액터는 결과를 응답 메시지로 전달 합니다.

두번째로 캡슐화 형태로 우리의 모델을 복원하는 것입니다. 액터는 객체와 마찬가지로 메시지에 반응하여 객체에서 호출 된 메소드에 “반응”합니다. 차이점은 액터 안에서의 멀티쓰레드가 튀어나와 내부 상태와 불변성을 파괴하고 혼란스럽게 하는 것 대신에 액터는 발신자의 메시지로 독립적으로 실행한다. 그리고 액터들은 순식간에 순차적으로 메시지를 받아들여서 반응한다.

각 액터가 순차적으로 보낸 메시지를 처리하는 동안 서로 다른 액터가 동시에 작동하므로 액터 시스템은 많은 프로세서 코어를 동시에 처리 할 수 있으므로 많은 수의 프로세서 코어를 사용할 수 있습니다. 액터 당 항상 하나의 메시지만 처리되기 때문에 액터의 불변식은 동기화 없이 유지될 수 있다. 잠금을 사용하지 않고 자동으로 발생된다.

![](/assets/images/posts/221033636275/c6314d60f279.png)
  1. 액터는 대기열의 끝에 메시지를 추가합니다.
  2. 액터가 실행되도록 예약되지 않은 경우 실행 준비가 완료된 것으로 표시됩니다.
  3. 스케줄러 엔티티 (숨겨진)가 액터를 가져 와서 실행을 시작합니다.
  4. 액터는 대기열의 정면에서 메시지를 선택합니다.
  5. 액터는 내부 상태를 수정하고 메시지를 다른 액터로 보냅니다.
  6. 액터가 예정에 없습니다.
  • 우편함 (메시지가 끝나는 대기열).
  • 행동 (액터의 상태, 내부 변수 등).
  • 메시지 (메서드 호출 및 매개 변수와 유사한 신호를 나타내는 데이터 조각).
  • Execution Environment (실행 환경) (반응하는 메시지가있는 액터를 사용하여 메시지 처리 코드를 호출하는 기계류)
  • 주소 (자세한 내용은 나중에 설명).

mailbox 관련하여 처리 부분을 설명

  1. 캡슐화는 신호로부터 실행을 분리해서 보존합니다 (메서드 콜 교환 실행, 메시지 전달은 아닙니다.)
  2. 잠금장치는 필요 없습니다. 액터의 내부 상태는 메시지를 통해서만 수정이 가능합니다. 불변형이 유지되는 중에는 제거되는 경주는 한개씩 처리됩니다.
  3.  어디서든 잠금은 사용되지 않습니다. 발신자도 차단되지 않습니다. 수백만 명의 액터가 수십 개의 스레드에서 효율적으로 스케줄되어 최신 CPU의 잠재력을 최대한 발휘할 수 있습니다.작업 위임은 행위자를위한 자연스러운 운영 모드입니다.
  4. 액터의 상태는 지역적이고 공유되지 않습니다. 변경 및 데이터는 메시지를 통해서 전파됩니다. 이것은 최신 메모리 계층이 동작하는지 알 수 있습니다. 대부분의 경우 로컬 상태와 데이터를 원래의 코어에 캐시 된 상태로 유지하면서 메시지의 데이터가 포함 된 캐시 라인 만 전송합니다. 동일한 모델은 상태가 컴퓨터의 RAM에 보관되고 변경 / 데이터가 패킷을 통해 네트워크를 통해 전파되는 원격 통신과 정확히 매핑됩니다.

Actor는 오류 상황을 정상적으로 처리합니다.

액터가 보낸 메시지는 콜스택을 더이상 공유하지 않으며 각 액터들에게 전달됩니다. 에러를 다루는 경우는 각각 다르게 처리해야 합니다.

첫 번째 경우는 작업의 오류로 인해 대상 액터의 위임 된 작업이 실패한 경우입니다 (일반적으로 존재하지 않는 사용자 ID와 같은 일부 유효성 검사 문제). 이 경우, 대상 액터에 의해 캡슐화 된 서비스는 손상되지 않습니다. 그 자체가 잘못된 태스크 일뿐입니다. 서비스 액터는 오류 케이스를 나타내는 메시지와 함께 발신자에게 회신해야합니다. 여기에 특별한 것은 없으며, 오류는 도메인의 일부이므로 일반 메시지가됩니다. 두 번째 경우는 서비스 자체에서 내부 오류가 발생하는 경우입니다. Akka는 모든 액터가 나무와 같은 계층 구조로 구성되도록합니다. 즉, 다른 액터를 만드는 액터가 새로운 액터의 부모가됩니다. 이는 운영 체제가 프로세스를 트리로 구성하는 방법과 매우 유사합니다. 프로세스와 마찬가지로 액터에 장애가 발생하면 상위 액터에 알리고 실패에 대응할 수 있습니다. 또한 부모 액터가 중지되면 모든 자식도 재귀 적으로 중지됩니다. 이 서비스는 감독이라고하며 Akka의 핵심입니다.

![](/assets/images/posts/221033636275/08b1b0d6b34a.png)

관리자 (상위)는 특정 유형의 실패에 대해 하위 액터를 다시 시작하거나 다른 액터에서 완전히 중단하도록 결정할 수 있습니다. 아이들은 조용히 죽지 않고 (무한 루프에 들어간 예외적 인 경우를 제외하고) 실패하고 대신 부모가 잘못에 반응 할 수도 있고 멈추게 될 수도 있습니다 (이 경우 이해 관계자에게 자동으로 통지됩니다). 액터를 관리하는 책임있는 주체는 항상 부모입니다. 재시작은 외부에서 볼 수 없습니다. 공동 작업자는 대상 액터가 다시 시작되는 동안 계속 메시지를 보낼 수 있습니다.

This article is licensed under CC BY 4.0 by the author.