Gitaly에서의 트랜잭션 관리

#### 직렬 가능성

직렬 가능성은 강력한 정확성 보증입니다. 동시 트랜잭션의 결과가 그것들의 순차 실행과 동일함을 보증합니다. 직렬 가능성을 보장함으로써 트랜잭션 사용자들의 삶을 쉽게 만들어줍니다. 그들은 시스템의 유일한 사용자인 것처럼 변경을 수행할 수 있으며 어떤 동시 활동이 있더라도 결과가 올바르다고 믿을 수 있습니다.

트랜잭션 관리자는 낙관적인 잠금을 통해 직렬 가능성을 제공합니다.

각 읽기와 쓰기는 리포지터리의 스냅샷에서 작동합니다. Git이 획득한 잠금은 서로 다른 스냅샷 리포지터리를 대상으로 하고 있으며, 이를 통해 모든 트랜잭션이 공유 리소스를 사용하지 않고 동시에 진행되어 변경 사항을 스테이징할 수 있습니다.

트랜잭션을 커밋할 때, 트랜잭션 관리자는 업데이트되거나 읽히는 리소스가 해당 트랜잭션보다 늦게 커밋된 중복 트랜잭션에 의해 변경되었는지 확인합니다. 만약 그런 경우가 있다면, 후속 트랜잭션은 직렬화 위반으로 거부됩니다. 만약 충돌이 없다면, 트랜잭션은 로그에 추가됩니다. 트랜잭션이 로깅되면, 성공적으로 커밋됩니다. 트랜잭션이 로깅되면 로깅된 내용을 사용하여 리포지터리에 최종적으로 적용됩니다. 이러한 잠금 메커니즘은 커밋까지 모든 트랜잭션이 블록되지 않고 진행되도록 허용합니다. 이는 모든 리소스의 쓰기 충돌을 식별하기에 충분합니다.

실제 직렬 가능성을 위해서는 수행된 읽기를 추적해야 합니다. 이것은 한 트랜잭션이 동시 트랜잭션에 의해 업데이트된 다른 값을 기반으로 그것의 업데이트를 시도하는 쓰기 편향을 방지하기 위한 것입니다. Git은 명령어의 일부로 읽은 참조를 추적할 수 있는 방법을 제공하지 않습니다. 우리가 명령의 일부로 읽은 참조를 추적할 일반적인 방법이 없기 때문에, 쓰기 편향이 허용됩니다.

고정 잠금은 트랜잭션에서 명시적으로 획득될 수 있습니다. 이러한 것은 사용될 경우 쓰기 편향을 방지할 수 있도록 트랜잭션 관리자에게 힌트를 제공합니다.

#### Write-ahead 로그

트랜잭션 이전에 쓰기는 디스크의 대상 데이터를 직접 업데이트했습니다. 만약 쓰기가 수행 중에 중단된다면 문제가 발생합니다.

예를 들어, 다음과 같은 쓰기가 주어졌다면:

- `ref-a new-oid old-oid`
- `ref-b new-oid old-oid`

프로세스가 `ref-a`를 업데이트한 후에 `ref-b`를 아직 업데이트하지 않은 상태에서 충돌이 발생한다면, 이 상태는 부분적으로 적용된 트랜잭션을 포함하게 됩니다. 이는 원자성을 위반합니다.

트랜잭션 관리자는 원자성과 내구성을 제공하기 위해 쓰기-전 로그를 사용합니다. 트랜잭션의 변경 사항은 로그에 커밋되기 전에 먼저 쓰기-전 로그에 기록됩니다. 만약 충돌이 발생하면, 트랜잭션은 로그로부터 복구되어 완료됩니다.

파티션의 모든 쓰기는 쓰기-전 로그를 통해 이루어집니다. 한 번 트랜잭션이 로깅되면, 그것은 다음과 같은 곳으로부터 적용됩니다:

- Git 리포지터리. 리포지터리의 현재 상태는 로그된 트랜잭션으로부터 구성됩니다.
- 리포지터리의 모든 파티션에서 공유되는 내장된 데이터베이스. 쓰기-전 로깅 관련된 부연적인 상태는 여기에 유지됩니다.

대부분의 쓰기는 로그 항목 내에서 완전히 자체 포함됩니다. 새로운 객체를 포함하는 참조 업데이트는 포함되지 않습니다. 새로운 객체는 팩 파일에 로깅됩니다. 팩 파일에 있는 객체들은 리포지터리의 기존 객체에 의존할 수 있습니다. 이것은 두 가지 이유로 문제가 됩니다:

- 팩 파일이 적용을 기다리는 동안 이러한 의존성은 가비지 컬렉션될 수 있습니다.
- 각 트랜잭션이 새로운 객체의 연결성을 그것의 스냅샷과 비교하며 검증할 때 실제 리포지터리의 객체 데이터베이스 안의 의존성이 가비지 컬렉션될 수 있습니다.

이러한 문제들은 로그 엔트리가 가비지 수집될 때까지 팩 파일의 의존성에 대한 내부 참조를 쓰는 것으로 해결될 수 있습니다. 이러한 내부 참조는 로그 엔트리가 가지를 별지면 지울 때 비워질 수 있습니다. 더 많은 정보는 [GitLab의 Git 포크의 문제 154](https://gitlab.com/gitlab-org/git/-/issues/154)를 참조하세요.

### 통합

Gitaly에는 150개가 넘는 RPC가 포함되어 있습니다. 이들 모두를 수정하지 않고도 트랜잭션 관리를 연결할 수 있습니다. 이는 각 핸들러 앞에 트랜잭션을 열고 커밋하는 gRPC 인터셉터를 연결하여 달성할 수 있습니다. 이 인터셉터는 다음을 수행합니다:

1. 트랜잭션을 시작합니다.
1. 요청 안의 리포지터리를 트랜잭션의 스냅샷 리포지터리를 가리키도록 다시 작성합니다.
1. 수정된 리포지터리를 사용하여 RPC 핸들러를 호출합니다.
1. 핸들러가 성공적으로 반환되면 트랜잭션을 커밋하거나 롤백합니다.

핸들러 내의 기존 코드는 이미 요청에서 리포지터리에 대한 액세스 방법을 알고 있습니다. 우리가 리포지터리를 스냅샷을 가리키게 다시 작성함으로써, 그들은 자동으로 스냅샷 격리를 받게됩니다. 왜냐하면 그들의 작업은 스냅샷을 대상으로하기 때문입니다.

`SetCustomHooks`와 같이 Git이외의 쓰기를 수행하는 RPC는 참조 트랜잭션 후크처럼 그들의 쓰기에 대한 방법을 갖고 있지 않기 때문에 적응해야합니다. 그러나 이들은 작은 소수에 불과하며, 명시적으로는 다음과 같습니다:

- 사용자 정의 후크 업데이트.
- 리포지터리 생성.
- 리포지터리 삭제.

이러한 것들을 통합하는 것을 지원하기 위해, 우리는 트랜잭션 안에 데이터를 포함하는 도우미 함수를 제공할 것입니다. 우리는 트랜잭션을 요청 컨텍스트를 통해 파이프라인화할 것입니다.

트랜잭션 관리를 통합하는 가장 큰 걱정은 트랜잭션 논리에 존재하지 않으면서 리포지터리에 쓰기를 하는 위치를 놓치는 것입니다. 우리가 요청의 리포지터리를 스냅샷 리포지터리를 가리키게하고 있기 때문에, 이는 문제가 아닙니다. RPC 핸들러들은 리포지터리의 실제 위치를 알지 못하기 때문에 실수로 거기에 쓰기를 할 수 없습니다. 그들이 수행하는 스냅샷 리포지터리로의 모든 쓰기는 트랜잭션에 포함되지 않는다면 폐기될 것입니다. 이것은 테스트를 실패하게 만들고 우리에게 문제를 알릴 것입니다.

Gitaly에 존재할 수 있는 어떤 위치들은 실제 리포지터리의 상대적 경로를 가지는 것이 유익할 수 있습니다. 예를 들어, 상대적 경로를 캐시하는 캐시(예: 팩 오브젝트 캐시)가 그러한 위치 중 하나일 수 있습니다. 각 트랜잭션이 자신만의 스냅샷 리포지터리와 따라서 다른 상대적 경로를 가짐으로써 문제를 일으킬 것입니다. 필요하다면, 실제 상대적 경로는 요청 컨텍스트를 통해 파이프라인화될 수 있을 것입니다. 스냅샷은 상대적 경로를 안정적으로 유지하면서 여러 읽기 전용 트랜잭션 간에 공유될 수 있습니다. 이것은 최소한 일부 케이스에서 캐시가 데이터가 변경될 때마다 만료되어야 하는 경우에도 작동할 것입니다.

프리펙트와의 하위 호환성 유지를 위해 트랜잭션 관리자는 트랜잭션을 커밋할 때 프리펙트에게 투표를 할 것입니다. 참조 트랜잭션 후크는 그곳에 변경 사항이 실제로 커밋되지는 않지만 트랜잭션에만 포함된다는 사실 때문에 그것을 할 필요가 없을 것입니다.

하우스키퍼링은 트랜잭션 처리와 통합되어야 합니다. 임시 파일을 제거하거나 낡은 잠금들을 제거하는 과정과 관련된 대부분의 정리 관련 하우스키퍼링 작업은 이제 더 이상 필요하지 않습니다. Git이 오류로 남긴 모든 쓰레기는 스냅샷 안에 포함되어 있으며 트랜잭션이 완료될 때 제거됩니다.

이것은 참조와 객체 리팩킹, 객체 가비지 수집, 다양한 인덱스를 구축하는 등의 일부 작업을 남깁니다. 이러한 작업은 모두 트랜잭션 안에서 수행될 수 있습니다. 새로운 팩들은 예를 들어 스냅샷을 통해 계산될 수 있습니다. 커밋할 때, 트랜잭션 관리자는 그들의 변경 사항이 동시에 커밋된 다른 트랜잭션과 충돌하는지 확인할 수 있습니다. 예를 들어, 스냅샷에서 가비지 수집된 객체가 다른 트랜잭션에서 동시에 참조될 수 있습니다. 만약 충돌이 있다면, 트랜잭션 관리자는 충돌을 해결하거나 충돌이 있으면 트랜잭션을 중지하고 하우스키퍼링 업무를 재시도할 것입니다.

트랜잭션 관리자는 리포지터리에 있는 팩 파일과 루즈 참조의 수를 추적하고 필요할 때 리팩킹을 트리거할 것입니다.

위의 내용은 Gitaly의 기존 코드와 거의 투명하게 통합될 수 있습니다. 우리는 데이터를 설정하면 작은 부분에만 조건 로직을 전염시켜서 마이그레이션 기간을 코드 기반 전체에 최소한의 조건 로직으로 관리할 수있습니다.

### 성능 고려 사항

가장 눈에 띄는 걱정은 리포지터리의 스냅샷에 대한 비용입니다. 우리는 요청이 처리되기 전에 리포지터리의 디렉터리 구조를 복사하고 파일을 하드 링크하는 것으로 생각되겠지만, 이것은 처음에 들려야 할 정도로 심각한 문제가 아닐 수 있습니다. 왜냐하면:

- 스냅샷은 본질적으로 디렉터리 항목만 생성합니다. 이것들은 빠른 시스콜입니다. 리포지터리 내 파일 수가 늘어날수록 스냅샷에 생성해야 할 디렉터리 항목과 링크의 수가 늘어납니다. 이것은 객체와 참조를 리팩킹하여 리포지터리를 좋은 상태로 유지함으로써 완화될 수 있습니다. Reftables는 미래에 루즈 참조의 수를 줄이는 데 도움이 될 것입니다. 쓰기-전 로그는 루즈 객체가 미래에 문제가 없을 팩 파일로만 리포지터리로 기록합니다.
- 이들은 메모리 내 작업입니다. 페이지 캐시를 타겟팅하며 fsync할 필요가 없습니다.
- 스냅샷은 읽기 전용 트랜잭션 간에 공유될 수 있습니다. 그들은 스냅샷에서 어떤 변경도 하지 않으므로, 쓰기는 상대적으로 드물게 발생합니다.
- 격리 수준은 성능을 위해 트랜잭션 단위로 설정할 수 있습니다. 단일 블롭을 가지고오는 RPC가 스냅샷 격리가 필요하지 않습니다.

쓰기를 직렬화하는 것은

## 트랜잭션의 생명주기

다음 다이어그램은 일부 참조를 업데이트하는 쓰기 트랜잭션의 흐름을 모델링합니다. 다이어그램은 트랜잭션이 처리되는 방식의 주요 지점을 보여줍니다.

- 각 트랜잭션은 리포지터리의 스냅샷을 가지고 있습니다.
- RPC 핸들러들은 리포지터리 자체에서 작동하지 않습니다.
- 스냅샷에서 수행된 변경 사항은 트랜잭션에서 캡처됩니다.
- 변경 사항은 RPC가 성공적으로 반환된 후에 커밋됩니다.
- 트랜잭션은 로그에서 리포지터리에 비동기적으로 적용됩니다.

트랜잭션의 시작과 커밋은 다른 트랜잭션을 차단할 수 있습니다. 오픈된 트랜잭션은 차단하지 않고 동시에 진행됩니다.

1. 스냅샷을 생성하는 중에 리포지터리에 공유 잠금이 획득됩니다. 동시에 여러 스냅샷을 촬영할 수 있지만 변경 사항은 리포지터리에 기록될 수 없습니다.
1. 트랜잭션은 커밋 호출까지 차단하지 않고 동시에 실행되며, 시리얼라이즈 가능성 검사가 이루어집니다.
1. 로그 적용은 리포지터리에 전용 잠금을 획득하며, 스냅샷팅을 차단합니다.

```mermaid
sequenceDiagram
    autonumber
    gRPC Server->>+트랜잭션 미들웨어: 요청
    트랜잭션 미들웨어->>+트랜잭션 매니저: 시작
    트랜잭션 매니저->>+트랜잭션: 오픈된 트랜잭션
    참가자 리포지터리
    중요 공유 잠금 on 리포지터리
        트랜잭션->>+스냅샷: 스냅샷 생성
    end
    트랜잭션->>트랜잭션 매니저: 트랜잭션 시작됨
    트랜잭션 매니저->>트랜잭션 미들웨어: 시작됨
    트랜잭션 미들웨어->>+RPC 핸들러: 재작성된 요청
    RPC 핸들러->>+git update-ref: 참조 업데이트
    git update-ref->>스냅샷: 준비
    스냅샷->>git update-ref: 준비됨
    git update-ref->>스냅샷: 커밋
    스냅샷->>git update-ref: 커밋됨
    git update-ref->>+참조 트랜잭션 후크: 호출
    참조 트랜잭션 후크->>트랜잭션: 업데이트 캡처
    트랜잭션->>참조 트랜잭션 후크: OK
    참조 트랜잭션 후크->>-git update-ref: OK
    git update-ref->>-RPC 핸들러: 참조 업데이트됨
    RPC 핸들러->>-트랜잭션 미들웨어: 성공
    트랜잭션 미들웨어->>트랜잭션: 커밋
    트랜잭션->>트랜잭션 매니저: 커밋
    중요 시리얼라이즈 가능성 검사
        트랜잭션 매니저->>트랜잭션 매니저: 트랜잭션 확인
    end
    트랜잭션 매니저->>리포지터리: 로그 트랜잭션
    리포지터리->>트랜잭션 매니저: 트랜잭션 로그됨
    트랜잭션 매니저->>트랜잭션: 커밋됨
    트랜잭션->>스냅샷: 스냅샷 제거
    스냅샷 비활성화
    트랜잭션->>-트랜잭션 미들웨어: 커밋됨
    트랜잭션 미들웨어->>-gRPC Server: 성공
    중요 리포지터리에 단독 잠금
        트랜잭션 매니저->>-리포지터리: 트랜잭션 적용
    end