객체 스토리지, 트랜잭션 처리 어떻게 할까?
객체 스토리지(Object Storage)를 활용한 트랜잭션 처리 프로토콜 설계에 대한 심층 분석이 이루어짐
원자적 쓰기(Atomic Writes), 조건부 쓰기(Conditional Writes), 원자적 읽기(Atomic Reads) 등 객체 스토리지의 기본 연산을 활용한 프로토콜 소개
베이스라인 프로토콜(Baseline Protocol), 시퀀스 쓰기 프로토콜(Sequenced Write Protocol) 등 다양한 프로토콜의 장단점 및 트레이드오프(Trade-offs) 제시
SlateDB의 트랜잭션 쓰기 모듈 구현을 예시로, 실제 프로덕션 환경에서의 적용 사례를 설명
객체 스토리지의 기본 연산과 트랜잭션 프로토콜
게시물에서는 객체 스토리지 시스템이 제공하는 원자적 쓰기(Atomic Writes), 조건부 쓰기(Conditional Writes), 원자적 읽기(Atomic Reads), 조건부 읽기(Conditional Reads), 일관성 있는 목록(Consistent Listing)과 같은 기본 연산을 활용하여 트랜잭션 프로토콜을 구축하는 방법을 설명한다. 특히, PUT If-None-Match와 PUT If-Match를 사용한 조건부 쓰기는 메타데이터 충돌을 해결하는 데 유용하며, S3의 경우 LIST 연산 비용이 GET 연산보다 12배 높다는 점을 언급하며 성능 트레이드오프(Trade-offs)를 제시한다.
베이스라인 프로토콜(Baseline Protocol)의 이해
베이스라인 프로토콜은 객체 스토리지에 직접 원자적 PUT을 사용하여 구현되는 간단한 데이터베이스 구현 방식이다. 이 프로토콜은 일관성(Consistency)을 보장하지만, 객체 스토리지의 높은 지연 시간으로 인해 성능 저하가 발생할 수 있다. 게시물에서는 이 프로토콜이 객체 스토리지에서도 일관성 있는 프로토콜 구현이 가능하다는 것을 보여주는 예시로 제시하며, 데이터 격리 아키텍처(Data Isolation Architecture)를 통해 안전성을 확보하는 방법을 설명한다.
시퀀스 쓰기 프로토콜(Sequenced Write Protocol)의 장단점
시퀀스 쓰기 프로토콜은 각 파일이 시스템의 전체 내용을 나타내는 경우에 사용되며, 파일 이름을 증가시켜 충돌을 방지한다. 이 프로토콜은 충돌 해결을 위한 GET 요청을 줄여 성능을 향상시키지만, 가비지 컬렉션(Garbage Collection) 메커니즘이 필요하다는 단점이 있다. 게시물에서는 이 프로토콜이 S3에서 3번의 왕복(round trips) 대신 2번의 왕복으로 충돌을 해결할 수 있다고 설명하며, 데이터 미저장 정책(Zero-Retention Policy)을 통해 안전성을 확보하는 방법을 제시한다.
SlateDB의 단일 라이터(Single Writer) 전략
SlateDB는 단일 라이터(Single Writer) 전략을 통해 트랜잭션 보장을 제공하고, 충돌 발생 시 라이터를 펜싱(fencing)하는 방식을 사용한다. 이 방식은 충돌을 줄이고, 쓰기 작업에 대한 트랜잭션 보장을 제공한다. 게시물에서는 각 역할(main writer, garbage collector, compactor)이 자체적인 epoch 필드를 사용하여 충돌을 감지하고 해결하는 방법을 설명하며, 멀티모달 분석(Multimodal Analysis)을 통해 시스템의 안정성을 높이는 방법을 제시한다.