<div id="readability-page-1" class="page"><article id="post-1865">
			
		<div>
			




<h2 id="aggregate-패턴과-일관성-경계">Aggregate 패턴과 일관성 경계</h2>



<p>이 챕터에선 도메인 모델에서 컬렉션에 대해 일관성을 유지하는 aggregate 패턴과 그와 관련된 용어들을 설명한다.</p>



<h3 id="제약과-불변-조건-일관성-락">제약과 불변 조건, 일관성, 락</h3>



<p>의자를 -350개를 주문하거나 100억 개 이상의 비정상적인 주문이 생기지 않으려면, 도메인 로직에서 이런 제약을 검증할 필요가 있다.</p>



<p>비슷하게 쓰이지만 제약은 도메인 모델이 가질 수 있는 상태에서 제약을 두는 것이고, 불변 조건은 도메인 모델이 항상 참이어야 하는 조건을 의미한다. 이들은 경우에 따라서 ‘잠시’ 지켜지지 않을 수 있지만, 최종적으론 지켜져야 한다. 만약 어떻게 해도 이 제약과 불변 조건을 지키면서 새로 온 입력을 넣을 수 없다면, 오류를 출력하고 입력이 오기 전으로 되돌려야 한다.</p>



<p>이런 일관성은 특히 동시에 접근하는 사람들이 많아질수록 어려워진다. 그러기 위해 락을 쓰지만 사용자가 많으면 한계가 있다. 수십만명의 사용자 요청이 각각 테이블 전체를 락을 걸면 데드락이 생기든 성능에 문제가 생길 수 밖에 없기 때문이다.</p>



<blockquote><p>책 내용 아님: 잠시 지켜지지 않는 말은 NoSQL의 BASE 모델과 연관된 말인 것 같다. NoSQL은 RDB처럼 매 트랜잭션마다 정합성을 보장하지 않고 필요한 순간에 정합성을 보장할 수 있으면 당장은 안 지켜도 되기 때문이다.</p></blockquote>



<h3 id="aggregate와-일관성-경계">Aggregate와 일관성 경계</h3>



<p>Aggregate는 같은 목적을 가지고 변경해야 하는 데이터들의 부분 집합을 만들어서 이 집합이 동시성 제어를 하고 단일 진입점 역할을 하는 걸 말한다. 앞서 말한 동시성은 보장하고 싶지만 매 row마다 수많은 락이 생기는 걸 방지하고 싶을 때 사용한다.</p>



<p>책에 나오는 할당 예제에선 OrderLine을 할당할 Batch를 찾는건 같은 sku를 가진 Batch로 한정된다. 즉, 의자를 주문하면 의자의 재고에서만 고려한다는 말이다. 그럼 의자 Batch들을 하나의 Aggregate로 묶어서 의자를 주문하는 요청들끼리는 같은 락으로 의자 Batch에 대해 일관성을 유지할 수 있다. 그리고 침대나 다른 가구를 주문하는 요청들은 의자 주문에 의해 락이 걸리지 않는다.</p>



<p>일관성 경계는 위에서의 가구 종류처럼 논리적으로 락을 분리해야하는 되는 경계를 의미한다.</p>



<p>만약 위와 같이 aggregate 패턴을 적용하기로 했다면 기존의 Batch는 단일 엔티티는 접근할 수 없게 해야 한다. 오직 aggregate로만 접근해야 한다.</p>



<h3 id="성능에-대한-우려">성능에 대한 우려</h3>



<p>aggregate를 사용하면 하나의 배치를 원하더라도 모든 배치를 읽어오게 된다. 이 방식이 비효율적일 수 있지만 이런 점도 고민해보자.</p>



<ol><li>aggregate는 최대한 질의 한번과 변경을 한번에 반영하려는 패턴이다. 이 패턴을 쓰지 않고 개별적으로 질의한다면 데이터가 많아질수록 트랜잭션은 느려지고 복잡해진다.</li><li>데이터 구조를 최소한으로 사용하며 한 행당 소수의 문자열과 정수만 만들면 많이 불러오더라도 오래 걸리지 않는다.</li><li>배치를 다 쓰면 그 배치를 계산에서 제외하면 되기 때문에 조회할 데이터 양이 예상을 벗어날 일은 없다. (이 부분은 뭐에 대한 우려인지 모르겠다.)</li></ol>



<p>그래도 우려가 된다면 지연 읽기를 적용해서 한번 읽어오는 양을 줄이는 것도 요청 수는 많아지겠지만 좋은 방법이다. 특히 조건에 맞는 행 하나만 찾는 거라면 조금씩 읽다가 조건이 맞으면 더 이상 안 읽어도 된다.</p>



<h3 id="낙관적-동시성">낙관적 동시성</h3>



<p>만약 시스템에서 두 개의 변경 사항이 충돌하는 일이 적다고 판단된다면, 충돌 가능성이 있는 곳에 전부 락을 거는 비관적 동시성보단 일단 변경을 수행하고 충돌이 발생했을 때 조치를 취하는 낙관적 동시성을 시도해볼 만하다.</p>



<p>전제 조건은 실패를 감지할 수 있어야 한다. 책에서는 버전 번호를 도메인 객체에 추가하는 걸 권장한다. 버전 번호를 읽고 번호를 증가시킨 후 커밋하는 것이다. 만약 새 번호로 변경을 시도 했는데 이미 저장소에 올라간 번호가 저장되어 있다면, 충돌했다고 판단하고 재시도를 하든 다른 조치를 취한다.</p>



<p>버전 번호라는 게 도메인에 필요한 속성은 아니다. 하지만 서비스나 저장소 객체가 맡기엔 도메인 객체의 변경을 기록하는 책임과 관심사가 맞지 않기 때문에 결국 도메인 객체에 붙이는 게 낫다.</p>



<h3 id="요약">요약</h3>



<p>애그리게이트와 일관성 경계에 대해 다음을 기억하자.</p>



<ul><li>애그리게이트는 도메인 모델에 대한 진입점이다. 도메인을 직접 제어할 수 없게 해서 도메인의 일부를 감출 수 있다.</li><li>애그리게이트는 일관성 경계를 책임진다. 여러 개의 객체를 묶어서 불변 조건을 검사하고 이를 위배하는 변경(낙관적 동시성의 예시)을 거부할 수도 있다.</li><li>애그리게이트를 쓰는 건 개념적인 설계 뿐만 아니라 동시성과 성능에 대한 고민도 포함된다.</li></ul>
			
			
								</div>
</article></div>

Wraithkim의 지식공방

Aggregate 패턴과 일관성 경계 이 챕터에선 도메인 모델에서 컬렉션에 대해 일관성을 유지하는 aggregate 패턴과 그와 관련된 용어들을 설명한다. 제약과 불변 조건, 일관성, 락 의자를 -350개를 주문하거나 100억 개 이상의 비정상적인 주문이 생기지 않으려면, 도메인 로직에서 이런 제약을 검증할 필요가 있다. 비슷하게 쓰이지만 제약은 도메인 모델이 가질 수 있는 상태에서 제약을 두는 것이고, 불변 조건은 도메인 […]

Architecture Patterns with Python – 8

댓글