t4 소개

출처: Dev.to

인프라 시스템은 종종 작고 신뢰할 수 있는 장소에 컨트롤 플레인 상태를 보관해야 합니다: 설정, 서비스 메타데이터, 락, 임대, 리비전 히스토리, 그리고 변경 알림 등.
t4는 객체 스토리지를 기반으로 한 오픈소스 키‑밸류 데이터베이스로, 내구성 있는 인프라 상태를 저장합니다. 원래는 Kubernetes 스토리지를 단순화하려는 시도로 시작되었습니다. Kubernetes는 컨트롤 플레인 상태를 위해 etcd에 의존하는데, etcd는 전체 Raft 클러스터 모델이 필요할 때는 뛰어납니다. 하지만 etcd는 전체 합의 클러스터, 멤버십 관리, 스냅샷, 복구, 그리고 작은 클러스터, 엣지 환경, 실험 환경에서는 항상 편하지 않은 운영 습관을 함께 가져옵니다.

Kubernetes는 대형 서버에서 신중하게 관리되는 거대한 컨트롤 플레인에서, 보다 단순하고 일회성인 호스팅 컨트롤 플레인으로 이동하고 있습니다. 그런 환경에서는 스토리지 레이어가 교체와 복구가 더 쉬워야 합니다. t4를 만들게 된 초기 질문은 간단했습니다: 객체 스토리지를 통해 복구가 이루어진다면 Kubernetes‑스타일 스토리지는 어떻게 보일까?

많은 인프라 프로젝트가 일반적인 SQL 시스템보다 작지만, 단순 로컬 파일보다 강력한 데이터베이스를 필요로 합니다:

• 설정은 프리픽스 읽기, 조건부 업데이트, 그리고 워치 스트림이 필요합니다.
• 스케줄러와 컨트롤 플레인은 임대, 락, 그리고 단조롭게 증가하는 리비전이 필요합니다.
• 운영자는 노드 손실 후 스냅샷을 손으로 복사하지 않고 복구할 수 있어야 합니다.
• 테스트와 마이그레이션 워크플로는 실시간 상태의 시점 복사본을 활용하면 유리합니다.

보통의 답은 별도의 코디네이션 데이터베이스를 운영하는 것입니다. 이는 동작은 가능하지만, 자체 클러스터 멤버십, 스냅샷, 복구 절차, 장애 모드, 성능 프로파일 등을 가진 또 하나의 운영 객체를 추가하게 됩니다.

특히 이미 S3 호환 스토리지를 내구성 경계로 신뢰하고 있는 시스템에게는, 중요한 소량의 상태를 위해 과도한 장비를 도입하는 느낌이 들 수 있습니다.

객체 스토리지는 이제 지루하지만 견고한 기반이 되었습니다. 저렴하고, 널리 사용 가능하며, 지역적으로 내구성이 보장되고, 이미 많은 플랫폼의 운영 모델에 포함돼 있습니다.

t4는 그 기반을 직접 활용합니다:

• WAL 세그먼트가 모든 변경을 기록합니다.
• 체크포인트가 빠른 복구 지점을 제공합니다.
• 콘텐츠 주소화된 SST 파일은 변경되지 않은 데이터를 다시 업로드하지 않게 합니다.
• 브랜치는 전체 데이터베이스를 복사하는 대신 기존 체크포인트 파일을 공유합니다.
• 리더 선출은 별도의 코디네이션 서비스가 아니라 객체 스토어의 조건부 쓰기를 사용합니다.

핫 리드는 여전히 로컬 스토리지에서 이루어집니다. t4는 활성 작업 집합을 위해 로컬 Pebble 데이터베이스를 유지하고, 복구 스토리는 객체 스토리지를 사용합니다. 노드가 사라지거나 디스크를 잃어버리거나 교체될 경우, S3‑호환 스토리지에 있는 체크포인트와 WAL 세그먼트를 통해 재구축할 수 있습니다.

이 모델은 “etcd를 다르게 구현한 것”이 아니라, 장애 후 진실 소스로 이미 객체 스토리지를 사용하는 워크로드를 위한 전혀 다른 내구성 모델입니다.

데이터베이스가 객체 스토리지에서 복구될 수 있게 되면, 다른 워크플로도 훨씬 자연스러워집니다.

• 복구 연습이 특별한 이벤트가 아니라 일상적인 작업이 됩니다. 새 노드를 만들고 버킷과 프리픽스를 지정하면 자동으로 재구축됩니다.
• 마이그레이션 실험은 알려진 체크포인트에서 시작할 수 있습니다.
• 일회성 테스트 환경은 모든 객체를 복사하지 않고 실제 상태에서 포크할 수 있습니다.

브랜칭 기능은 바로 이 점에서 탄생했습니다. t4 체크포인트는 콘텐츠 주소화된 SST 파일을 사용하므로, 브랜치는 동일한 불변 파일을 소스로 재사용하고 자신만의 변경만 기록하면 됩니다. 이는 시점 복사본을 저렴하게 만들어, 비상 상황뿐 아니라 리허설, 디버깅, 업그레이드 테스트에도 활용할 수 있게 합니다.

전통적인 코디네이션 데이터베이스와 가장 차이가 나는 부분은 “상태를 저장하는 것에 그치지 않고, 상태를 복제·검사·폐기하기 쉽게 만든다”는 점입니다.

t4가 목표로 하는 것은 다음과 같습니다:

• 내구성 있는 인프라 상태
• Kubernetes‑스타일 컨트롤 플레인 스토리지 단순화
• 실패하거나 일시적인 노드의 간단한 교체
• 임베디드 혹은 독립 프로세스에서의 로컬 읽기
• 호환성이 중요한 기존 etcd v3 클라이언트
• 복구 연습, 마이그레이션, 테스트를 위한 복사 없는 브랜치

t4는 운영 복잡성을 해소하기 위한 도구이며, 모든 etcd 배치를 대체하려는 것이 아닙니다. 가장 성숙한 운영 생태계, 전체 클러스터 관리 API, 혹은 작은 순차 쓰기 워크로드에 대한 최저 지연 시간이 필요하다면 etcd를 사용하세요. 벤치마크 노트는 etcd가 아직 앞서는 부분과 t4의 클러스터 모델이 강점인 부분을 명확히 구분해 두었습니다.

코드는 https://github.com/t4db/t4 에서 오픈소스로 제공되며, 문서는 https://t4db.github.io/t4 에서 시작됩니다. 여기에는 시작 가이드, 아키텍처 노트, 그리고 etcd 마이그레이션 가이드가 포함되어 있습니다.