Akka는 기본적으로 탑레벨 아키텍쳐의 설계방식으로 Actor를 위치시키고 접근을 하며 (최상위부터 생성하여 구조화하는 방식 )
트리구조이지만, FullName을 알고있을시 최하위 자식노드에게 직접 리모트 메시지전송이 가능하며 , 부모를 통해 대리 접근도 가능하다.( 접근의 유연성)
성능 전략에따라 다양한 라우트(ex>라운드로빈)를 선택할수있고 기존 서비스코드의 변경이 거의 없다. ( 로컬객체의 확장 유연성)
또한 클러스터 룰정의를 통해 코드의 수정및 서비스 Down없이 스케일아웃 배포에대한 문제해결도 가능합니다. ( 유연한 스케일아웃)
장애 처리 관점에서 자식의 예외는 부모가 처리하는것을 1원칙으로, 부모의 예외를 자식노드에게 전가시키 지 않습니다.
이로써 상위 감독자에게 장애에대한 룰을 각각 적용할수가 있습니다. ( 장애를 허용하고 최상위 감독자를 통한 장애대책 )
접근이 용이하다란 말은 Actor가 어디에 있던 메시지를 전송시킬수 있다란 의미이지, 객체 자체를 접근할수 있다란 의미는 아닙니다.( 객체 공유는 액터모델에 위배됨 )
Actor의 기본 생성과 Child Actor 생성
class PrintMyActorRefActor extends Actor { override def receive: Receive = { case "printit" => val secondRef = context.actorOf(Props.empty, "second-actor") //자식의 생성에 대한 책임은 부모가 가진다. ( 생성하고 자식노드로 런타임 이동하는 형태의 방법 제한) println(s"Second: $secondRef") } } val firstRef = system.actorOf(Props[PrintMyActorRefActor], "first-actor") // actorOf 는 Actor생성시 사용됩니다. println(s"First : $firstRef") firstRef ! "printit" // !는 스칼라에서 Input을 위한 키워드이며, c++의 cout >> 과 유사한 키워드 , //C#또는 JAVA에서는 명시적으로 firstRef.Tell("printit") 이렇게 사용하면 됩니다. //액터 생성 순서 first-actor <= second-actor 가 parent <= child 관계가 된다. First : Actor[akka://testSystem/user/first-actor#1053618476] Second: Actor[akka://testSystem/user/first-actor/second-actor#-1544706041]
아래와같이, rest의 endpoint 와 접근법이 유사합니다.
어떠한 의미에서 RESAPI 설계도 Top-Level 아키텍쳐를 따른다고 볼수 있습니다. ( 상위에서 하위기능으로 분류)
var parentActor= system.ActorSelection("akka://testSystem/user/first-actor"); var childActor= system.ActorSelection("akka://testSystem/user/first-actor/second-actor");
RestAPI에서는 호출을 한번하면 내부적으로 ( 접속-요청-응답-접속해제) 의 과정을 거치지만
원격 Actor의 경우 이미 연결된 객체(TCP피어투피어) 를 사용하며 ,새로운 연결에대한 오버헤드가 없기때문에
대량의 호출시, 호출시마다 HTTP의 무지막지한 헤더값이 없을뿐더러
CPU/메모리/네트워크자원 을 훨씬 작게 사용합니다. ( 성능적으로 약 100배 이상 차이 )
사용자에게 제공하는 ResAPI를 대체하는 의미는 아니며, 미들웨어간 정보를 주고받을때 RestAPI를 사용하고 있다면 고성능 정보교환 문제를 해결할수 있습니다.
액터의 소멸
이런 구조적인 설계로, 부모의 액터를 정지시키면 자식의 액터를 모두 종류후 마지막에 부모 액터가 종료가됩니다.
이것은 부모가 자식을 책임지는 AKKA의 기본 예외 처리모델과도 부합하며, OOP방식의 소멸순서와도 유사합니다.
다만 부모에게 발생한 예외를 자식에게 전가시키지 않습니다. ( 예외처리모델에 더 상세하게 설명)
class StartStopActor1 extends Actor { override def preStart(): Unit = { println("first started") context.actorOf(Props[StartStopActor2], "second") } override def postStop(): Unit = println("first stopped") override def receive: Receive = { case "stop" => context.stop(self) } } class StartStopActor2 extends Actor { override def preStart(): Unit = println("second started") override def postStop(): Unit = println("second stopped") // Actor.emptyBehavior is a useful placeholder when we don't // want to handle any messages in the actor. override def receive: Receive = Actor.emptyBehavior } val first = system.actorOf(Props[StartStopActor1], "first") first ! "stop" //OutPut //first started //second started //second stopped //first stopped
Supervision을 통한 장애처리
Child 액트가 장애발생시, 디양한 복구전략( 3초간 30초동안시도)을 통해 Child액트의 복구가 가능하다.
var supervisor = BackoffSupervisor.Props( Backoff.OnFailure( childProps, childName: "supervised-actor", minBackoff: TimeSpan.FromSeconds(3), maxBackoff: TimeSpan.FromSeconds(30), randomFactor: 0.2) );
이 섹션은 아래와 같은 실습코드를 통해 좀더 살펴보겠습니다.
- Actor시스템 구축및 구동
- Actor를 기능적으로 분산배치
- Remote Actor간 메시지 처리
- 특정 Node를 임의로 다운시키거나, 특정 Actor에 예외발생시킴