测验：检查点、恢复与时间旅行

compile(checkpointer=MemorySaver()) 한 그래프를 같은 thread_id 로 두 번 돌렸다. 두 번째 실행이 보는 것은?

• 매번 빈 상태에서 시작한다. thread_id 는 기록용 이름일 뿐이다
• 첫 실행의 입력만 남고 노드가 쓴 값은 남지 않는다
• 첫 실행이 남긴 상태 위에서 이어 돈다. 리듀서가 붙은 열쇠는 쌓인다
• 첫 실행이 끝났으므로 오류를 내며 새 thread_id 를 요구한다

과거 체크포인트에서 이어 돌리려고 한다. invoke 의 첫 인자로 무엇을 주어야 하는가?

• None — 저장된 그 시점의 상태로 이어서 돌라는 뜻이다
• 그 시점의 상태 딕셔너리를 그대로 다시 준다
• 바꾸고 싶은 열쇠만 담은 딕셔너리를 준다
• 빈 딕셔너리를 준다. 그래야 덮어쓰지 않는다

update_state(snapshot.config, {...}) 가 돌려주는 것은?

• 값만 바뀐 상태 딕셔너리. config 는 그대로다
• 아무것도 돌려주지 않는다. 그 자리를 덮어쓴다
• 그 시점 이후의 체크포인트를 지운 개수를 돌려준다
• 새 checkpoint_id 가 든 config 하나

한 번 돌린 뒤 중간 지점에서 갈래를 쳤다. 이제 thread_id 만 담은 config 로 get_state 를 부르면?

• 원래 갈래의 끝이 나온다. 분기는 따로 보관된다
• 새 갈래의 끝이 나온다. 스레드의 '지금' 이 그리로 옮겨 갔다
• 두 갈래의 끝이 목록으로 함께 나온다
• 갈래가 둘이라 어느 쪽인지 정할 수 없어 오류가 난다

상태에 큰 값 하나를 담았더니 체크포인트 저장량이 크게 늘었다. 무엇이 일어난 것인가?

• 그 값이 압축되지 않아 원래보다 커진 채로 저장되었다
• 리듀서가 없는 열쇠라 값이 매번 복사되어 쌓였다
• 체크포인트마다 상태 전체가 저장되므로 그 값이 여러 번 거듭 저장되었다
• 직렬화가 실패해 예비 형식으로 다시 저장되었다

체크포인트의 비용을 시간이 아니라 바이트로 재라고 하는 이유로 가장 알맞은 것은?

• 같은 상태면 크기는 늘 같지만 시간은 기계와 부하에 따라 달라진다
• 직렬화 시간이 저장 시간보다 늘 짧아 시간 측정이 의미가 없다
• 체크포인터가 시간을 재는 기능을 제공하지 않는다
• 바이트 수가 커질수록 저장 시간이 정확히 비례해 늘어난다