액션 트랜잭션의 일관성과 격리

액션(Action)은 온톨로지에서 읽은 값과 로직을 바탕으로 여러 객체(Object) 및 링크(Link)를 변경하는 트랜잭션입니다. 쓰기 모드와 격리 수준은 서로 다른 설정입니다.

ACID 범위

액션이 완료한 뒤 시작하는 액션이나 질의는 완료한 편집을 봅니다. 같은 액션이 실행 중일 때 자신의 편집을 읽는지는 아래 쓰기 모드에 따라 다릅니다.

무엇이 쓰기인가

규칙 기반 액션은 매개변수(Parameter)를 속성에 매핑하면 해당 속성에 씁니다. 함수 기반 액션은 온톨로지 편집으로 속성을 설정하면 쓰기입니다.

OSDK 요청에서 선택 매개변수를 생략하려면 기본값이 구성되어 있어야 합니다. 기본값이 현재 객체 속성값이면 생략한 입력을 그 값으로 채우고 다시 속성에 기록합니다. 요청에서 생략했다는 이유만으로 그 속성을 쓰지 않는 것은 아닙니다.

쓰기 모드

두 모드 모두 마지막에 편집 전체를 원자적으로 커밋하므로 다른 액션은 부분 적용 상태를 보지 않습니다.

충돌 검사 단위

충돌 검사를 하는 격리 수준은 객체 단위의 쓰기 충돌을 확인합니다. 두 액션이 같은 객체의 서로 다른 속성에 써도 하나는 충돌로 실패할 수 있습니다. 실패한 액션의 편집 전체를 버립니다.

기반 데이터셋(Dataset)의 재빌드도 충돌을 일으킬 수 있습니다. 이 충돌은 두 액션의 공통 편집 객체에 한정되는 경우보다 범위가 넓어서 재빌드가 해당 객체 값을 바꾸지 않아도 발생할 수 있습니다. 보통 재빌드가 끝난 뒤 재시도하면 해결됩니다.

격리 수준 선택

Ontology Manager의 액션 Capabilities에서 설정합니다. 변경한 수준은 이후 실행에 적용합니다. 새 Batched writes 액션의 기본값은 Snapshot isolation입니다. Staged writes는 현재 Legacy만 지원합니다.

Legacy

명시적 격리 수준이 도입되기 전 액션의 호환성을 위해 남아 있습니다. 조회가 대체로 한 시점에서 이루어지더라도 저장소 읽기 오류와 데이터 갱신 등의 상황에서는 여러 시점이 섞일 수 있습니다.

Batched writes와 Staged writes 모두 사용할 수 있으며 자신의 편집을 보는지는 쓰기 모드에 따릅니다. 새 Batched writes 구성에는 같은 충돌 검사에 일관된 스냅샷을 더하는 Snapshot isolation을 권장합니다.

Snapshot isolation

직접 수행하는 모든 온톨로지 조회는 액션 시작 시점의 같은 상태를 봅니다. 같은 객체나 검색을 다시 읽어도 다른 액션의 중간 커밋 때문에 결과가 바뀌지 않습니다. Batched writes이므로 자신의 미커밋 편집은 조회에 포함하지 않습니다.

함수가 호출하는 외부 소스(Source)는 이 시점 경계 밖에서 동작합니다. 소스가 다른 시스템이나 온톨로지를 읽어도 다른 시점일 수 있으며 소스의 작업에는 액션의 원자성과 충돌 검사가 적용되지 않습니다.

쓰기 치우침

Snapshot isolation은 쓰기 객체의 충돌만 검사하며 읽기와 다른 객체의 쓰기 사이를 모두 검사하지는 않습니다.

가상의 당직 업무에서 최소 한 명이 남아야 하고 두 명 이상일 때만 나갈 수 있다고 가정합니다. A와 B가 동시에 시작하면 두 스냅샷 모두 당직자 두 명을 봅니다. A는 A.onCall을 false로, B는 B.onCall을 false로 바꿉니다. 다른 객체에 썼으므로 둘 다 커밋할 수 있고 당직자가 사라집니다.

이런 쓰기 치우침(Write skew)을 막으려면 유지할 조건을 공통 객체의 쓰기로 표현합니다. 두 액션이 공유 Rotation.onCallCount도 갱신하도록 구성하면 같은 객체 쓰기 충돌이 발생하고 새 실행에서 조건을 다시 판단할 수 있습니다.

Read committed

이 모드는 출시 예정입니다. 조회마다 최신 커밋 값을 읽으며 고정 스냅샷은 없습니다. Batched writes를 사용하므로 자신의 미커밋 편집은 보지 못합니다.

동시 변경을 대체로 허용합니다. 가상의 Ticket에 status=open과 priority=low가 있다고 가정합니다. A가 status=in progress와 priority=medium을 기록하고, B가 priority=high를 기록하면 A 다음 B 순서의 커밋 후에는 status=in progress와 priority=high가 남습니다. 같은 객체의 다른 속성 변경은 유지하고 공통 속성만 나중 값으로 결정합니다.

같은 실행을 Snapshot isolation에서 수행하면 B는 같은 객체의 충돌 검사에 실패합니다. Read committed에서도 같은 객체에 매우 많은 동시 작업이 있으면 일부 충돌이 발생할 수 있습니다.

이 모드는 안정적인 조회 결과로 쓰기를 결정하지 않고 이미 입력으로 받은 값을 기록하는 경우에 검토합니다. 조회한 현재 상태에 의존하는 업무나 동시 덮어쓰기가 위험한 경우에는 약한 보장을 그대로 적용하지 않습니다.

현재 적용 대기 쓰기의 보장

Staged writes는 Legacy 격리만 지원합니다. 각 조회 시점의 최신 커밋 상태에 자신의 적용 대기 편집을 더하여 읽습니다. 따라서 후속 조회에서 자신의 편집은 보지만 실행 전체가 한 스냅샷인 것은 아닙니다.

다른 액션은 마지막 원자적 커밋 전에는 그 편집을 보지 못합니다. 자신이 쓰는 객체에 대한 충돌을 검사하고 읽기만 한 객체는 충돌 검사에 포함하지 않습니다.

일시 오류의 재시도

플랫폼은 충돌이나 객체 로드 실패 같은 일시 오류에서 액션을 처음부터 다시 실행할 수 있습니다. 총 실행 시도는 최대 5번입니다. 현재 값을 읽는 로직은 새 실행의 데이터로 편집을 다시 계산합니다. 모든 시도가 실패하면 호출자에게 오류를 반환합니다.

Capabilities의 Retry mode on transient errors에서 조정합니다.

외부 호출이 있는 액션의 기본 재시도를 막는 이유는 같은 웹훅 등을 두 번 호출할 수 있기 때문입니다. 자동 재시도는 성공률을 높여 충돌이 보이지 않게 할 수 있지만 완료 시간은 늘어날 수 있습니다.

Batched writes의 일반적인 읽기-수정-쓰기 업무에는 Snapshot isolation을 사용합니다. 기존 Legacy를 바꾸면 같은 시점 보장을 얻지만 오래 실행되고 자주 바뀌는 객체를 수정하는 작업은 더 자주 재시도될 수 있습니다.