[Book] [데이터 엔지니어를 위한 97가지 조언] 001: 서점 재고 관리 시스템으로 알아보는 최종 일관성
선배 개발자가 말해주는 데이터 엔지니어링 조언 모음집 "데이터 엔지니어를 위한 97가지 조언"의 001번 "서점 재고 관리 시스템으로 알아보는 최종 일관성"에 대해 살펴봅니다.
개요
안녕하세요.
이번 글은 선배 개발자가 말해주는 데이터 엔지니어링 조언 모음집 “데이터 엔지니어를 위한 97가지 조언”의 001번 “서점 재고 관리 시스템으로 알아보는 최종 일관성”에 대해 살펴보겠습니다. 또한 ACID와 BASE 원칙을 알아보고 개인적인 사례를 공유하겠습니다.
책의 전문
재고 관리 시스템의 초기: 강한 일관성
![[그림 1] 서점 재고 관리 시스템](/assets/img/develop_story/6001/6001_01_small_bookstore.jpg)
[그림 1] 서점 재고 관리 시스템
여러분이 서점의 주인이고 어느 날 재고 내용을 엄청난 종이 장부 대신 시스템을 통해 관리하고 싶어졌습니다. 한 곳에 약 1,000권의 책을 둘 수 있는 설계가 목표입니다. 고객이 책을 사러 계산대에 오면 재고 관리 시스템은 아래와 같이 동작합니다.
- 원장에 재고 세부 사항을 확인합니다.
- 새 구매를 기록한다.
- 모든 기록을 갱신합니다.
- 고객에게 영수증을 돌려줍니다.
영수증을 통해 고객이 책을 구매하고 재고 관리 시스템이 최신 정보임을 확정합니다. 위의 재고 관리 시스템은 강한 일관성(Strong Consistency)을 가져야 합니다. 강한 일관성은 읽기 요청이 순차적이며 다음에도 재고 관리 시스템이 읽는 상태가 동일함을 의미합니다.
성공적인 서점의 확장!: 최종 일관성
![[그림 2] 여러 점포의 서점 재고 관리 시스템](/assets/img/develop_story/6001/6001_02_bookstore.jpg)
[그림 2] 여러 점포의 서점 재고 관리 시스템
서점이 성공하면서 여러 점포의 재고 관리가 필요해졌습니다. 일단 현재 시스템의 아키텍처를 재설계하죠. 첫 점포에 원본 장부를 두고 각 점포에는 원본 장부와 연결된 장부가 존재합니다.
만약 원본 장부가 꺼진다면 모든 점포의 거래가 불가능해지고 길고 긴 대기줄이 생깁니다. 일 단위로 원장을 갱신하는 방향을 고려해 봅시다. 이 시스템은 영업 종료 이후 점포의 모든 책을 세고, 원하는 책이 예상대로 서가에 있는지 검증하는 방식으로 재고를 갱신합니다.
이 유형에서는 모든 트랙잭션이 최종 일관성(Eventual Consistency)을 갖도록 계획합니다. 점포 재고에 대한 각각의 접근은 병렬적으로 처리되고 재고 관리 시스템을 갱신합니다. 최종적으로 특정 책에 접근하면 항상 가장 최근에 갱신된 값을 알 수 있죠!
일관성이 깨진 상황을 발견했을 때 처리하는 것은 분산 시스템의 읽기 복구와 비슷합니다. 불일치를 발견했을 때만 원장 전체의 상태를 고쳐 쓰는 작업을 시작합니다.
이런 프로세스로 충분할까요? 대용량 처리 능력을 상태 일관성과 맞바꿔야하는 시스템에서는 충분합니다. 시스템이 읽기 복구 방식으로 불일치를 수정해서 최종 일관성을 유지한다면 계산대 앞의 늘어진 대기줄을 피할 수 있습니다. 그리고 데이터베이스 가용성에 대한 부담도 줄어듭니다.
결론: 아키텍처에 정답은 없다
이 2가지 점포 재고 관리 방식은 서로 다른 2가지 아키텍처를 나타냅니다. 하나는 클라이언트-서버 스타일로 아키텍처로 확장하는 강한 일관성을, 다른 하나는 대용량 트랜잭션을 처리하고 상태가 비일관적임을 발견했을 때 해결하는 최종 일관성을 가집니다.
여러분이 직접 시스템을 설계한다면 어떤 관점으로 계획하고 싶나요??
감상평
트랜잭션: 상호작용을 위한 가장 작은 단위
데이터 일관성에 들어가기 앞서 우리는 트랜잭션이라는 개념을 알아야합니다. 위키백과에서는 트랜잭션을 “DBMS 또는 유사한 시스템에서 상호작용의 단위 또는 연산”이라고 정의합니다. 다시 말해 여러 시스템 사이에서 발생하는 작업의 가장 작은 단위의 개념이라고 할 수 있습니다.
데이터 일관성의 종류: 강한 일관성, 약한 일관성, 최종 일관성
하지만 분산 시스템이 적용된다면 다양한 상황이 발생합니다. 이를 방지하기 위해 데이터 일관성이라는 개념이 떠오릅니다. 데이터 일관성은 책에서 다룬 강한 일관성과 최종 일관성 그리고 약한 일관성으로 구분합니다.
| 일관성 유형 | 특징 | 장점 | 단점 |
|---|---|---|---|
| 강한 일관성 (Strong Consistency) | - 모든 읽기 요청이 순차적 - 모든 노드가 동일한 데이터 상태 유지 - 변경사항 즉시 반영 | - 데이터 정확성 보장 - 트랜잭션 안정성 높음 | - 응답 속도 저하 - 가용성 감소 - 확장성 제한 |
| 약한 일관성 (Weak Consistency) | - 일부 노드만 최신 데이터 반영 - 일시적 불일치 허용 - 비동기식 업데이트 | - 빠른 응답 속도 - 높은 가용성 | - 데이터 불일치 가능성 - 복잡한 충돌 해결 |
| 최종 일관성 (Eventual Consistency) | - 시간이 지나면 모든 노드 동기화 - 일시적 불일치 허용 - 비동기식 복제 | - 높은 확장성 - 좋은 성능 - 고가용성 | - 일시적 데이터 불일치 - 복잡한 애플리케이션 로직 |
정리하자면
ACID와 BASE: 데이터를 처리하는 원칙
![[그림 3] ACID와 BASE](/assets/img/develop_story/6001/6001_03_acid_base.png)
[그림 3] ACID와 BASE
지금까지 배운 내용을 트랜잭션과 데이터 일관성을 모델에 적용한 것이 바로 ACID 원칙과 BASE 원칙입니다. 보통 관계형 데이터베이스는 ACID 원칙을 NoSQL 데이터베이스에서는 BASE 원칙을 채택하는데요. ACID 원칙은 순서대로 원자성(Aromicity), 일관성(Consistency), 고립성(Isolation), 지속성(Duration)을 의미합니다. 보다 구체적인 내용은 아래의 표를 참고해보세요!
| 속성 | 의미 | 지켜지지 않은 예시 |
|---|---|---|
| 원자성 (Atomicity) | 트랜잭션은 모두 수행되거나 전혀 수행되지 않아야 함 | 자금 이체 중 돈은 인출됐지만, 입금이 되지 않고 중단됨 |
| 일관성 (Consistency) | 트랜잭션 전후로 데이터의 무결성과 제약 조건이 항상 유지되어야 함 | 잔고가 0원인 통장에서 150원이 인출되어 데이터 무결성이 깨짐 |
| 고립성 (Isolation) | 동시에 실행되는 트랜잭션들이 서로 간섭하지 않도록 해야 함 | 잔액을 업데이트하기 전에 다른 트랜잭션이 인출을 시도해 잔고가 꼬임 |
| 지속성 (Durability) | 트랜잭션이 완료되면, 시스템 장애가 발생해도 그 결과는 영구적으로 보존되어야 함 | 입금 완료 메시지가 떴지만 시스템 장애로 데이터가 저장되지 않음 |
한편 BASE 원칙은 Basically Available, Soft state, Eventual consistency의 약자입니다. 역시 각 속성을 표로 정리봤습니다.
| 구성 요소 | 의미 |
|---|---|
| 기본 가용성 (Basically Available) | 시스템은 항상 응답을 제공해야 함. 일부 노드에서 오류가 발생하더라도 전체 시스템은 사용 가능해야 함. |
| 소프트 상태 (Soft state) | 시스템의 상태는 일시적으로 불안정하거나 일관되지 않을 수 있음. 노드 간의 동기화가 지연될 수 있음. |
| 최종 일관성 (Eventual consistency) | 일정 시간이 지나면 최종적으로 모든 노드가 일관된 상태에 도달함. 즉각적인 일관성은 보장하지 않음. |
나의 사례: Kafka Connect를 이용한 CDC 파이프라인
현재 회사에서는 Kafka Connect을 이용한 CDC 파이프라인이 존재합니다. 분산 시스템이면서 실시간성 데이터를 처리하기 때문에 최종 일관성을 채택한 사례입니다. 때때로 시스템 상의 장애가 발생하지만 Kafka Connect는 여러 메커니즘으로 데이터 일관성을 보장하는데요. 가볍게 살펴보면 다음과 같습니다.
- 오프셋 관리
- 각 파티션별로 마지막으로 처리된 메시지의 오프셋을 저장
- 장애 발생 시 저장된 오프셋부터 재시작하여 데이터 손실 방지
- 오프셋은
__consumer_offsets토픽에 자동 저장
- At least once 전송 보장
- At most once, At least once, Exactly once 중 기본 설정으로 At least once 선택
- 메시지가 최소 한 번은 반드시 처리되도록 보장
- 중복 전송이 발생할 수 있으나, 데이터 손실은 방지
- 자동 복구 메커니즘
- Connector 장애 시 자동 재시작
- 리밸런싱을 통한 워크로드 재분배
마무리하며
이번 글에서는 데이터 일관성을 알아보았습니다. 서점의 사례를 이용해 강한 일관성과 최종 일관성을 서로 비교해봤는데요. 이 두 일관성은 정확성과 안정성, 확장성, 고가용성 등 다양한 속성에서 장단점이 존재합니다. 이러한 일관성을 바탕에 둔 ACID와 BASE 원칙은 보다 상세한 지침을 통해 일관성을 보장하는데 도움을 줍니다.
요구사항이 단순하며 처리량이 적은 초기 시스템에서는 강한 일관성을 유지할 수 있지만 점차 복잡하고 많아지는 데이터를 처리하기에 한계가 있습니다. 반면 확장성과 고가용성을 위해 처음부터 최종 일관성을 채택하는 것 역시 오버 엔지니어링이 될 여지가 있습니다. 따라서 데이터 일관성을 설계할 때는 요구사항에 맞는 일관성을 선택하는 것이 중요하지 않을까 싶습니다!
이 글이 조금이나마 도움이 되었기를 바랍니다.
감사합니다. 😀
참고 문헌
- “ACID”, Wikipedia, https://en.wikipedia.org/wiki/ACID
- “Database transaction”, Wikipedia, https://en.wikipedia.org/wiki/Database_transaction
- 김상욱, “데이터 일관성(Data Consistency)을 보장하는 방법은 무엇인가요?”, ouk.log, https://velog.io/@ouk/데이터-일관성Data-Consistency을-보장하는-방법은-무엇인가요
- 궁금하면 500원, “분산 시스템에서 데이터 일관성 설계 시 고려해야 할 요소들 이해하기”, 거북이처럼 꾸준하게 욕심많은 개발자, https://velog.io/@sleekydevzero86/distributed-system-data-consistency