스냅샷은 앞장 이벤트소싱에서도 부분적으로 사용이되었습니다. 스냅샷은 성능상의 목적으로 다양한곳에서 혼합되어 사용될수 있으며
그 컨셉은 간단합니다. 무수히 발생하는 이벤트로 인해 우리가 설계한 어떠한 객체의 상태는 지속적으로 변경된다는 점이며
모든 상태변화를 기록하는것은 불필요할수도 있으며, 필요한 순간의 청사진만 찍어서 그것을 활용할수 있다란 것입니다.
상태를 기록하는 범위와 주기에따라 세가지로 구분되며, 그 차이를통해 스냅샷을 이해할수가 있습니다.
- 이벤트저장 : 상태복원은 연속된 이벤트 재생만을 통해가능하며 리플레이와같은 구현을 위해 이벤트 자체를 모두 기록
- 상태 히스토리 저장 : 모든 이벤트를 기록할필요없이 특정시점의 상태를 복원을 하면되기 때문에, 원하는 만큼 상태를 기록함
- 마지막 상태만 저장 : 마지막 저장값만 유지함으로, 별도의 저장 히스토리 기능을 만들지 않는다고하면, 단 1건의 변경 이력을 보는것이 불가합니다.
AKKA에서의 스냅샷은 실시간 이벤트 모두를 저장해야 요구와, 중요한 최근 몇건은 꼭 저장해야 하는 Persitence 각기 다른 요구 요건에서
중간쯤에 위치하여 조율을하는 장치로 활용할수가 있습니다. 예를 들어 최근 이벤트 100개를 유지하는것과 ( 순수 Persist기능)
1000번째마다 스냅샷을 찍어서 100개를 유지하는것은 각각 요구하는 성능이 다르며 다른 목적으로 활용이 될수가 있으나 함께 작동한다란것입니다.
연관 키워드 : difference between redo and snapshot
스냅샷 구현
@Component @Scope("prototype") public class SnapShotActor extends AbstractPersistentActor { private final LoggingAdapter log = Logging.getLogger(getContext().system(), "AbstractPersistentActor"); private Object state; private int snapShotInterval = 5; private int msgCnt = 0; @Override public String persistenceId() { return "ExamplePersistentActor-id-1"; } @Override public Receive createReceiveRecover() { return receiveBuilder(). match(SnapshotOffer.class, s -> { state = s.snapshot(); //상태복원 log.info("상태복원"); // ... }). match(String.class, s -> {/* ...*/}).build(); } @Override //복구전략(스냅샷을 무시할수도 있음) public Recovery recovery() { return Recovery.create(SnapshotSelectionCriteria.none()); /* return Recovery.create( SnapshotSelectionCriteria .create(457L, System.currentTimeMillis()));*/ } // 스냅샷을 지원하는 메시지 정의 @Override public Receive createReceive() { return receiveBuilder(). match(SaveSnapshotSuccess.class, ss -> { SnapshotMetadata metadata = ss.metadata(); // ... }). match(SaveSnapshotFailure.class, sf -> { SnapshotMetadata metadata = sf.metadata(); // ... }). match(String.class, cmd -> { log.info("EventFired:"+cmd); if(cmd.indexOf("print") ==0 ) { log.info("상태확인:"+state); }else { msgCnt++; state = cmd + "을 먹은 상태"; //커멘드에따른 상태변화 if (msgCnt % snapShotInterval == 0 ) { //이벤트가 ?회 발생할때만 스냅샷을 찍음 ( 스냅샵이 없을시 유실될수있습니다. ) log.info("SaveSnapShot:" + state); saveSnapshot(state); } } }) .build(); } }
이벤트를 받게되면, 상태가 변경되게되며 자신이 원하는 타이밍에
카메라 셔터(saveSnapshot) 를 누르기만 하면됩니다.
여기서는 수많은 이벤트를 모두 저장하는것은 비효율적이니, 매 5번째 상태의 스냅샷정보를 유지하기로 하였다고 가정하였습니다.
실제, 앞장 샘플에서는 persist기능과 연동되어 스냅샷과 상관없이 최근 X개 유지기능을 통해 , 마지막 상태복구가가능합니다.
스냅샷 복원
private Object state; @Override public Receive createReceiveRecover() { return receiveBuilder(). match(SnapshotOffer.class, s -> { state = s.snapshot(); // ... }). match(String.class, s -> {/* ...*/}).build(); } 또는 @Override public Recovery recovery() { return Recovery.create( SnapshotSelectionCriteria .create(457L, System.currentTimeMillis())); }
마지막 상태를 복원(SnapshotOffer - 추천복원 )할수도 있고,
스냡샷은 히스토리 관리가 되기때문에
특정 시간의 스냅샷(SnapshotSelectionCriteria)을 복원할수도 있습니다.
스냅샷 테스트
protected void persistenceSnapShot() { new TestKit(system) {{ ActorRef probe = getRef(); Props snapShotActorProp = ext.props("snapShotActor"); System.out.println("snapShotActor 액터생성"); ActorRef snapShotActor = system.actorOf(snapShotActorProp, "snapShotActor"); System.out.println("event 생성"); snapShotActor.tell("커피", ActorRef.noSender()); snapShotActor.tell("사탕", ActorRef.noSender()); snapShotActor.tell("커피", ActorRef.noSender()); snapShotActor.tell("스테이크", ActorRef.noSender()); snapShotActor.tell("라면", ActorRef.noSender()); // <-- 복구기대 상태 snapShotActor.tell("사탕", ActorRef.noSender()); snapShotActor.tell("커피", ActorRef.noSender()); System.out.println("상태확인"); snapShotActor.tell( "print" , ActorRef.noSender()); expectNoMessage(java.time.Duration.ofSeconds(1)); System.out.println("snapShotActor 종료또는 비정상종료"); snapShotActor.tell( akka.actor.PoisonPill.getInstance() , ActorRef.noSender()); expectNoMessage(java.time.Duration.ofSeconds(1)); System.out.println("snapShotActor 마지막 상태 확인"); ActorRef snapShotActo2 = system.actorOf(snapShotActorProp, "eventActor"); System.out.println("상태 복원확인"); snapShotActo2.tell( "print" , ActorRef.noSender()); expectNoMessage(java.time.Duration.ofSeconds(1)); }}; }
샘플은 모든 이용자가 먹을때마다 이벤트가 발생하고,그 시식 결과에의해 어떠한 상태로 변경이 됩니다.
이벤트드리븐 의 예를 간단하게 설명하는것으로 대단한 기능이 있는것은 아닙니다.
단지 이벤트는 무수히 발생하며 모든것을 기록하고 이용하기 어려우니, 스냅샷은 특정한 이벤트 조건에따라(여기서는 단순하게 5번째)
사진을 찍게되며 , 모든 사용자의 청사진을 최근 몇개까지 운영할것인가를 성능과 복원을 고려하여 설계에 반영할수 있다란것입니다..
최근 메시지를 유지하는것과 변경된 상태의 청사진을 오랫동안 유지하는것은 각각 다른 성능비용이 발생합니다.
스냅샷 시도에따른 반응 메시지
Method | Success | Failure message |
---|---|---|
saveSnapshot(Any) | SaveSnapshotSuccess | SaveSnapshotFailure |
deleteSnapshot(Long) | DeleteSnapshotSuccess | DeleteSnapshotFailure |
deleteSnapshots(SnapshotSelectionCriteria) | DeleteSnapshotsSuccess | DeleteSnapshotsFailure |
스냅샷은 다양한 이유로(디스크풀및 메모리풀등) 실패가 있을수 있으며
그에 대응하는 코드작성도 가능합니다.
참고Link :
- 스냅샷 : https://doc.akka.io/docs/akka/2.5/persistence.html#snapshots
- 액터상태를 DB객체와 일치화 시키는방법 : https://doc.akka.io/docs/akka/current/persistence-schema-evolution.html