QCon San Francisco에서 Greg Young이 근래에 시스템에 적용한 아키텍처에 대해 흥미로운 대화를 나눴다. Greg은 대단한 Domain Driven Design 팬인데, 이번에는 다량의 거래 처리를 하고, 수많은 사용자에게 데이터를 제공하는 시스템이었다. 나는 그의 설계에서 많은 흥미로운 사실을 발견했다. 특히, 그가 Event
Sourcing를 사용한 방식이지만, 여기서는 단 한 가지 측면에 대해서만 집중하길 원한다. 바로 Eager Read Derivation에 대해서다.
도메인 모델(Domain Model)은 복잡한 도메인 로직(domain logic)을 포함할 때 사용한다. 이러한 도메인 로직의 분류는 도움을 줄 수 있다:
- validations: 입력이 사리에 맞고, 객체를 앞으로 있을 행위에 맞게 적절히 준비했는지 확인
- consequences: 세상을 바꿀(?) 어떤 행위를 시작1
- derivations: 이미 보유한 정보를 바탕으로 새로운 정보를 끌어냄2
이러한 도메인 로직 유형은 조회보다는 갱신에 대해 다르게 적용한다. 우리가 족보 시스템을 갖고 있고, 출생 기록 개정이 있다고 가정하자.
이름: Bilbo Baggins
부: Bungo Baggins
모: Belladonna Took
이 데이터를 도메인 모델에 제출하면, '부모를 같이 입력하지 않았는가?' 등의 validation 을 한다. 이제 consequence를 낼 수 있다. Bungo가 Bilbo에게 줄 상당한 유산을 갖는다. 또한, derivation을 행할 수 있다. 그러나 대개는 validation 혹은 consequence만 지원한다. 가계도에 순환 관계가 없음을 확인하기 위해 Bilbo의 조상 목록이 필요할 수 있다.
대개 데이터를 읽을 때 derivation 로직이 쓰인다. Bilbo의 친할아버지 데이터 조회를 요청했다고 해보자. 필요한 도메인 로직은 친할아버지가 아버지의 아버지라는 지식이다. 시스템 대부분에서는 조회 요청을 받을 때 유도 로직을 동반한 조회를 수행한다. 본래 조회 요청이 있으면, 데이터베이스 호출을 통해 처리 이전의 데이터를 꺼내서, 필요한 유도 로직을 수행하고 결과를 반환한다. (이를 줄이려고 캐시를 쓰기도 한다.)
Eager read derivation은 다르다. 주요 데이터베이스 접근이 일절 없다. 대신 조회 요청과 동일하게 구성한 하나 이상의 보고 데이터베이스(ReportingDatabases)를 갖는다. 조회 요청은 도메인 로직 개입 없이 보고 데이터베이스에 접근해서 바로 데이터를 꺼낸다.
다시 출생 기록을 도식화한다.
- UI에서 출생 기록을 제출했다.
- 도메인 모델은 모든 validation 및 consequences 로직을 수행한다.
- 도메인 모델은 핵심 정보를 반영해 데이터베이스 레코드를 갱신한다.
- 도메인 모델은 개별 UI 출력을 포함해 모든 조회에 필요한 derivation logic을 실행하여 갱신 메시지를 메시지 큐를 통해 보고 데이터베이스로 보낸다.
- 친할아버지 관련 UI에서 요청한 조회는 보고 데이터베이스에서 친할아버지 테이블 접근으로 바로 해결할 수 있다.
Greg의 경우 모두가 비동기 메시지로 처리하고, 모든 입력은 이벤트로 포착하며(Event Sourcing), 도메인 모델은 입력 큐에서 메시지를 처리하고 출력 큐로 출력 이벤트를 공시에 보고 데이터베이스에서 데이터를 적재한다. 모두 비동기로 처리하여 전체적인 성능과 규모가변성 향상에 도움을 준다. 여기에는 불일치가 발생하는 순간이 존재함을 의미하기도 한다. 갱신을 처리하는 순간 조회가 이뤄지면, 메시지 처리보다 빨리 클릭이 이뤄져 갱신 결과를 보지 못할 수 있다. 이러한 비동기 계획은 완벽하게 일관적이지 않지만, 결국 일관성이 있긴 하다. 그러나 이를 거스를 수는 없다. 분산 시스템이라면 일관성을 택하거나 가용성을 택하거나 둘 중 하나다.
이제 분산환경이 아니어도 완벽하게 일관성을 유지하는 방법으로 eager read derivation을 할 수 있다. 그런 상황을 목격했었는지 확실치 않다. 내 생각엔 eager read derivation은 주로 높은 분산 요구에 적합하다.
eager evaluation은 전혀 새로운 내용이 아니다. 나보다 오래되었고, 어쩌면 Ron Jeffries 이전에도 있었을지 모른다. 그리고 대부분의 대용량 웹 사이트(high-volume websites)에서는 항상 파생 데이터(derived data)도 데이터베이스에 저장한다. 그러나 종래의 기법이 권장할만한 것은 아니며, 나는 Greg의 설계처럼 적극적인 방법을 좋아한다.
이올린에 북마크하기
이올린에 추천하기