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는 수평/수직확장을 최소한의 코드변경(심지어는 환경설정변경만으로)만으로 목표를 이루어냅니다.


Local전송 Vs Remote 전송

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

...

네트워크 전송에서는 Serialization/Deserializtion 과정을 통해 Object를 복원합니다. ( Object → Btyes → Object ) 

닷넷에서는 이기종끼리통신을 하기위해 필요한 단계를 마샬링이라고 합니다. 단어의 기원은 모르겠습니다.

이부분에 대해 더 깊은 학습을 하고싶으면 필자가 작성한 다음 코드를 참고하세요

이기종 통신을 위한 마샬링

이것은 추후 C++프레임웍이랑 AkkaStream을 통한 고성능 메시지 처리에 활용될수 있습니다.

이기종간 개발 플래폼간에 메시지 클래스/구조체를 변환,복원하는 과정을 마샬링이라고도 합니다.


대표적 전송방법

  • at-most-once delivery ( 한번에 한번씩 배달 )
  • message ordering per sender - recceiver pair  ( 메시지 순서를 고려하여 작은단위 지속적 배달 )

...

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

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

Image Removed

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

풍전등화 앞 제국의 운명 적군과의 일전을 앞두고, 메시지 전달 보증을 위해 가짜전령을 썩어서 보냄



Higher-level abstractions

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

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

...

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

Higher-level abstractions

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가 소멸될시 (종료요청) 스스로 작동을 멈출수도 있는 전략 선택의 문제입니다.