Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info

수많은 노드로 규모를 확장하는것이, AKKA 메시지의 궁극적인 목표입니다.

여러분의 로컬에서만 실행되는 코드를 하나도 바꾸지 않고 분산시스템에서 실행되게 할수 있을까요?

짧게 답하면 '아니오' 입니다. 로컬과 원격의 환경차이를 그냥 추상화해서 없애 버릴수는 없습니다.

다음과 같은 무시할수 없는 네 영역이 있기때문입니다.

  • 지연시간: 노드사이의 네트워크를 통해 전송되는 지연시간을 예측할수 없습니다.
  • 부분실패: 분산 시스템을 이루는 각 부분을 항상 감시할수없으며, 각 부분이 제대로 작동하는지 알아내기가 어렵습니다.
  • 메모리접근: 로컬에서는 메모리 객체에대한 참조를 항상 얻을수 있지만, 원격 노드의 원격객체에대한 참조를 얻는 것은 어럽습니다.
  • 동시성: 원격노드를 조정하는 모든 권한을 가지는 주인이 없으며, 연산순서를 보장받기가 어렵습니다.

이와 같은 문제로 로컬프로그래밍 모델은 분산환경에서의 규모 확장에 실패할 가능성이매우 높습니다.

그래서 아카는 이와 반대되는 접근방법을 선택하게 됩니다. 로컬에서도 원격을 위한 메시지처리기법(액터를통한) 을 사용합니다.

이것은 객체공유를 배제하고 메시지 처리기법만으로 로컬개발과 원격처리 분산처리등의 차이를 줄여 일관성있는 개발을 유도합니다.

이것의 단점도 분명 있습니다. 로컬 시스템에서의 프로그래밍이 불필요하게 어려워질수도 있다란것입니다.

예를들어 A class의 모든 접근수준이 private라고 한다면, B Class는 A class의 값을 어떻게 획득해야 할까요?

하지만 반대로 생각해보십시오, 객체 접근을 통해 구현된 로컬서비스인 A class의 모든 접근 수준이 public이라 할지라도...,

원격에 있는 B Class가 어떻게 A class의 퍼로퍼티에 접근 할수 있을까요?

이러한 관점에서, ACTOR는 로컬에서도 객체공유가아닌 메시지 전송기법을 사용하여 구현을 하게되며 실제로 이렇게

구현된 ACTOR는 수평/수직확장을 최소한의 코드변경(심지어는 환경설정변경만으로)만으로 목표를 이루어냅니다.

Actor의 단점도 분명존재합니다.

모든것은 Actor로 구현및 설계가 가능하지만 이것만 사용하기를 강요하지 않습니다.

어떠한 목적 달성을 위해 Actor 설계가 복잡해지는경우

Akka Persistence/Akka Stream/Akka EventBus 등을 특수한 케이스일때 액터와 연동하여 사용하라고 권장을 합니다.

또는 Kafka/RabitMQ등 좋은 메시지큐시스템이 있기때문에 연동을 하여 사용하거나 그것만 사용할수도 있습니다.


Local전송 Vs Remote 전송

 Actor는 Local처리(전송)과 Remote 전송하는 사용방법이 거의 동일합니다.

...

이것은  Erlang에서 크게 성공을 거둔 기법입니다. ( http://erlang.org/faq/academic.html#idp32880720  - 10.9)

그림으로 살펴본 메시지처리의 거짓 추상화처리

Image Removed

메시지 전송 보장을 위한 추상화된 거짓처리란? :

...



Higher-level abstractions

AKKA의 메시지는 강력하고 높은 수준의 추상화를 제공합니다.

메시지 전송순서(Message Ordering) 보장

...

일반 메시지와 분리된 큐에서 작동을 하기때문에 이 둘의 메시지에대해서는 순서보장이 되지 않습니다.

...

AKKA의 메시지는 강력하고 높은 수준의 추상화를 제공합니다.

Messaging Patterns

안정적 메시지 전달요구사항에 대응이 가능해야합니다.

  • 개별 메시지를 식별하여 메시지와 응답을 연관시키는법
  • 시간내에 확인되지 않으면 다시보내는 재시도 메카니즘
  • 수신기가 중복을 감지하고 버릴수 있는방법

Event Sourcing

이벤트 소싱(및 샤딩) 은 커다란 웹사이트를 수십억명의 사용자 규모로 확장하는 아이디어이며

이아이디어는 매우 간답합니다. 액터가 처리가 될때 명령의 이벤트 목록을 생성하고 저장을 합니다.

이 계획은 이벤트만이 저장소에 추가되고 아무것도 변이되지 않는 점이며 

이를 통해 이벤트 스트림의 소비자를 완벽하게 복제하고 확장할수 있습니다. 

구성요소의 컴퓨터가 고장이나거나 푸시로기능중 손실되는경우 , 이벤트 스트림을 재생하여 쉽게 재구성합니다.

이벤트 소싱은 Akka.net 지속성(Persistence)에서 지원됩니다.  (  참고 소스 : http://getakka.net/articles/persistence/event-sourcing.html )

Mailbox with Explicit Acknowledgement

사용자 지정 사서함 유형 구현하면, 일시적인 오류처리를위해 

...


Dead Letters(전송실패 메시지)

전송시도후 어떠한 이유로 전송이실패가 될시, 전송실패의 이유를 최선의 노력으로 

...

포워드를 하여야합니다. 또한 수신받는 원격지또한 지점간 네트워크 장애가 발생할수 있음으로

해당 데드레터를 수신받지 못할수도 있습니다.

데드레터가 항상 나쁜것은 아니다.

Actor가 자신의 결정에의해 종료되지 않을때, 자신에게 보내는 일부 메시지가 손실될수 있습니다.

어떠한 Actor(ActorA)의 계층구조를 멈추어야할때, 부모 Actor가 소멸시 자신의 Child Actor(ActorB) 를 알수있으며

데드레터를 통해 ActorB에게 메시지를 보내는 다른 액터(ActorC) 를 멈출수가 있습니다물론 ActorC가 ActorB가 소멸될시 (종료요청) 스스로 작동을 멈출수도 있는 전략 선택의 문제입니다.