액터를 사용한 신뢰성있는 메시지 전송 전략

Local전송 Vs Remote 전송

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

액터처리방식에서는 동일하지만, Remote로 작동시 네트워크로인한 몇가지 차이점이 존재합니다.

• Remote의 경우 처리 대역폭에따라 네트워크 지연발생할수 있음
• Local에서는 제한없는 메시지 크기가 Remote에서는 크기제한 필요
• Remote의 경우 전송성능을 위해 TCP처리모듈, 바이너리데이터 해석을위해 Serialization 등의 모듈이 선택이가능합니다.(옵션선택사항)
• Local에서의 전송장애는 실제 네트워크사용은 없기때문에 메모리(메모리풀)문제로 인해 발생할수 있으며, Remote의 경우는 네트워크 단절(Disconnect)에의해 발생할수 있습니다. 

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

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

대표적 전송방법

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

at-most-once delivery 의 세부적 의미

• at-most-once : 한번만 전송하기 때문에 메시지가 유실될수 있습니다.
• at-least-once : 적어도 한번 보내려고, 여러번 보낼수 있기때문에 유실은 없지만, 중복 발생할수 있습니다.
• exactly-once : 정확하게 한번 보내려는 메카니즘으로, 중복이나 유실이 없습니다.
  
  

메시지 배달 보장을 위한 체크포인트

• 메시지가 네트워크에서 전송여부?
• 다른 호스트에서 수신여부?
• 수신이 되었고 메시지가 처리 큐에 저장이 되었는지 여부?
• 처리큐에서 메시지를 빼서 성공적으로 처리가 되었는지 여부?

이들 각각은 해결을 위해 서로 다른 비용을 지불하게되며,  메시지 전달라이브러리가

준수할수 없는 조건이 있다는것은 명백합니다. 보낸 사람이 성공적으로 상호작용이 성공했는지

여부를 알수 있는 유일한 방법은 비지니스수준의 승인 메시지를 확인하는 것이며 

AKKA자체로 만회할수 있는 것이 아닙니다. AKKA는 분산 컴퓨팅을 채택하고  메시지전달을통해

명시적으로 통신의 오류를 체크하며, 전달 보증을 위해 추상화된 거짓처리를 하지 않습니다. 

메시지 전달은 항상 보장되는게 아니며, AKKA는 메시지전달에 최소한 "보증"및 체크 수준을 제공해주고

사용자가 그것을 응용프로그램에 설계를 해야합니다.

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

Higher-level abstractions

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

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

전송순서 체크 시나리오:

CaseA

• Actor1이 Actor2에게 M1,M2,M3 메시지를 보낸다.
• Actor3가 Actor2에게 M4,M4,M5 메시지를 보낸다.

This means that:

• M1 메시지는 M2,M3 보다 먼저도착 되는게 보장된다.
• M5 메시지는 M6보다 먼저 도착 되는게 보장된다.
• 보낸 Actor가 틀린 메시지 M2,M5는 누가 먼저 도착할지 모른다.
• 어느 메시지이던, 전송 보장이 없기때문에 드롭이 될수가 있다.

Case B

• ActorA가 M1메시지를 ActorC 에게보낸다
• ActorA가 ActorB에게 M2메시지를 보내고, ActorB는 다시 ActorC에게 M2메시지를 포워드해서 보낸다.
  
  

장애감지 메시지(Communication of failure)

• Child Actor인 B가 부모액터A에게 메시지 M을 전송한다.
• Child Actor B에 어떠한 F(장애메시지)가 발생하여 ActorA에게 전송되었다

 이경우 M,F 또는 F,M 순서로 받을수 있으며 순서가 보장되지 않습니다. 부모액터는 자식의 장애를 감시하고

처리하는 메카니즘이 있어서 관련된 장애메시지를 받고 처리가능하지만

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

Messaging Patterns

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

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

Dead Letters(전송실패 메시지)

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

DeadLetter라는 액터로 전달을 합니다. 신뢰할수없는 네트워크 전송은 데드레터로 표시되지않고

손실됩니다.

데드레터는 어떻게 활용이 되는가?

데드레터의 주요 용도는 디버깅을 위한 것입니다. 목적지를 잘못설정하거나, 방화벽으로 막힌 목적지에

보낸다거나할때 DeadLetter는 이러한 사실을 감지하게 됩니다. 여러가지 문제를 제거하여

디버그 출력 선명도를 높일수 있지만,  데드레터를 피하려고 종료된 액터로 메시지전송을 일부러 

막는것은 송신자의 코드가 복잡해질수 있음으로 신중해야합니다. 

일반적으로 액터종료가 의도되는 사항이라면, 종료처리를 통해 이사실을 알리고 전송을 중단 시켜야할것입니다.

데드레터를 원격지에서 수신받을수 있는가?

데드레터는 네트워크를 통해 전달되지 않음으로, 한위치에 수집하려면 네트워크 하나당 액터를 구독하고

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

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