CHAPTER 10 분산 데이터 액세스
위시리스트 서비스에는 item_id 에 해당하는 item_desc 컬럼이 없습니다.
item_desc는 카날로스 서비스의 경계 콘텍스트에 있기 때문에 item_desc 정보를 가져오는 방법에 대해 파악해 보는 게 이번 챕터를 이해하는 목표입니다.
Figure 10-1. Wishlist Service needs item descriptions but doesn’t have access to the product table containing the data
10.1 서비스 간 통신 패턴Interservice Communication pattern
분산 시스템에서 데이터를 액세스하는 가장 일반적인 패턴입니다.
간단하지만 단점이 많습니다.
그림 10-2는 위스리스트 서비스가 카탈로그 서비스에 item_id를 전달하고 이에 해당하는 item_desc 리스트를 응답하는 동기 원격 호출의 한 장면입니다.
Figure 10-2. Interservice communication data access pattern
이 과정에서 네트워크 레이턴스, 보안 레이턴시, 데이터 레이턴시가 발생하므로 성능이 떨어집니다.
모든 레이턴시를 합하면 item_desc 리스트를 가져오는 데 1초 까지도 걸릴 수 있습니다.
이 패턴의 가장 큰 단점은 서비스 커플링입니다.
두 서비스는 의미상으로, 그리고 정적으로 결합될 수밖에 없습니다.
카탈로그 서비스가 실패하면 위스리스트 서비스도 실패하게 되는게 의미상 결합이며
나중에 사용량이 늘어나 확장을 할 때도 두 서비스 모두 함께 확장해야 하는게 정적인 결합을 의미합니다.
Table 10-1. Trade-offs for the Interservice Communication data access pattern
| Advantages |
Disadvantages |
| Simplicity |
Network, data, and security latency (performance) |
| No data volume issues |
Scalability and throughput issues |
| |
No fault tolerance (availability issues) |
| |
Requires contracts between services |
10.2 컬럼 스키마 복제 패턴Column Schema Replication pattern
컬럼을 여러 테이블에 복제해서 다른 경계 ㅌ콘텍스트에서도 데이터를 복제해 쓸 수 있게 만드는 것입니다.
그림 10-3에서 item_desc 컬럼이 Wishlist 테이블에 있으므로 위시리스트 서비스는 카탈로그 서비스에 데이터를 요청하지 않아도 됩니다.
Figure 10-3. With the Column Schema Replication data access pattern, data is replicated to other tables
이 패턴의 가장 중대한 두 가지 문제점은 데이터 동기화와 데이터 일관성입니다.
제품 정보의 생성/변경/삭제 작업이 발생하면 카탈로그 서비스는 위시리스트 서비스 및 다른 서비스들에게 변경 사실을 알려야 합니다.
보통 큐, 토픽, 이벤트 스트리밍을 응용한 비동기 통신으로 처리합니다.
동기적으로 할 필요까진 없다면 서비스간 디펜던시를 줄일 수 있는 비동기 통신으로 하면 좋습니다.
데이터 오너십을 통제하기 어렵다는 점도 이 패턴의 또 다른 문제입니다.
다른 서비스의 테이블에 복제하므로 데이터 업데이트가 일어나게 되고, 결국 데이터 일관성에 문제가 생길 수 있습니다.
데이터 동기화가 문제지만 데이터를 읽기만 하는 서비스라면 성능, 내고장성, 확장성은 크게 개선됩니다.
이런 단점에도 불구하고 데이터 집계, 리포팅, 대용량 데이터를 처리해야 하면서 높은 응답성, 높은 내고장성이 필요하면 고려해볼 수 있는 패턴입니다.
Table 10-2. Trade-offs for the Column Schema Replication data access pattern
| Advantages |
Disadvantages |
| Good data access performance |
Data consistency issues |
| No scalability and throughput issues |
Data ownership issues |
| No fault-tolerance issues |
Data synchronization is required |
| No service dependencies |
|
10.3 복제 캐싱 패턴Replicated Caching Pattern
각 서비스가 필요로 하는 데이터를 다른 서비스에 매번 요청하지 않고 바로 사용할 수 있도록 메모리 캐시에 데이터를 복제하는 기법입니다.
데이터가 각 서비스의 메모리에 저장되고 모든 서비스가 언제나 정확히 동일한 데이터를 참조하도록 계속 동기화하는게 다른 캐싱 모델과 다른 점입니다.
그림 10-4는 각 서비스가 내부 메모리 캐시를 자체 보유해서 데이터가 서로 다른 캐시간에 동기화 되지 않는 형태입니다.
각 서비스의 응답성과 확장성은 조금 높일 수 있지만, 서비스 간 캐시 동기화가 되지 않으므로 데이터 일관성을 유지하기는 어렵습니다.
Figure 10-4. With a single in-memory cache, each service contains its own unique data
그림 10-5는 데이터를 외부 캐시 서버에 보관하는 분산 캐싱distributed caching 방법입니다.
단일 메모리 캐싱 모델과 달리 서비스간 데이터 공유가 가능하게 됩니다.
Figure 10-5. A distributed cache is external from the services
하지만 효과적인 캐싱 모델이 아닌 세 가지 이유가 있습니다.
- 내고장성 문제는 그대로입니다. 데이터 조회 서비스 대신, 캐시 서버로 디펜던시가 이동했을 뿐입니다.
- 여러 서비스가 데이터 업데이트가 가능하므로 데이터 오너십에 관한 경계 콘텍스트가 무너집니다.
- 어쨌든 원격 호출이므로 네트워크 레이턴시는 발생하게 됩니다.
복제 캐싱 모델은 서비스 간에 동기화된 데이터를 각 서비스 별 메모리에 가지고 있으므로 같은 데이터를 다수의 서비스가 공유하고 있습니다.
그림 10-6과 같이 각 캐시 인스턴스는 서로 끊임없이 통신하면서 한 캐시에서 업데이트가 일어나면 다른 서비스에 동일한 캐시를 사용할 수 있도록 백그라운드에서 비동기적으로 업데이트합니다.
Figure 10-6. With a replicated cache, each service contains the same in-memory data
복제 캐싱을 지원하는 대표적인 제품으로 Hazelcast, Apache Ignite, Oracle Coherence가 있습니다.
그림 10-7에서 카탈로그 서비스는 item_desc 데이터를 메모리에 캐시로 갖고 있으며, 위시리스트 서비스는 동일한 캐시를 읽기 전용 메모리 사본으로 가지고 있는 형태입니다.
Figure 10-7. Replicated caching data access pattern
응답성, 내고장성, 확장성 측면에서 확실히 복제 캐싱 패턴이 월등히 좋습니다.
이 패턴의 첫 번째 트레이드오프는 서비스가 캐시 데이터와 시작 타이밍에 의존하게 된다는 점입니다.
카탈로그 서비스가 사용 불가능한 상태가 되면, 위시리스트 서비스는 대기 상태로 있어야 합니다.
이런 시작 디펜던시startup dependency는 초기 위시리스트 서비스 인스턴스에만 영향을 끼칩니다.
두 번째 트레이드오프는 데이터양data volume입니다.
예시로 500MB 이상의 데이터 크기라면 이 패턴의 실용성은 급격히 떨어집니다.
서비스 인스턴스마다 캐시 데이터를 가지고 있다고 하면, 5개 서비스 인스턴스일 때는 2.5GB의 메모리가 필요하게 됩니다.
세 번째 트레이드오프는 데이터 변경 빈도가 많을 경우 서비스 간에 데이터를 완전히 동기화시키기가 어렵다는 점입니다.
정적인 데이터(제품 설명)에는 맞을 수 있지만 변경이 잦은 데이터(제품 재고 수)에는 적합하지 않습니다.
네 번째 트레이드오프는 구성 및 설정 관리 문제입니다.
복제 캐싱 모델은 TCP/IP 브로드캐스팅, lookup을 통해 서로를 인지합니다.
이 범위가 너무 커지면 소켓 레벨에서 handshake를 하는 시간이 오래 걸리고, 클라우드 환경이라면 동적 IP 주소를 가지므로 제어가 어렵게 됩니다.
Table 10-3. Trade-offs associated with the replicated caching data access pattern
| Advantages |
Disadvantages |
| Good data access performance |
Cloud and containerized configuration can be hard |
| No scalability and throughput issues |
Not good for high data volumes |
| Good level of fault tolerance |
Not good for high update rates |
| Data remains consistent |
Initial service startup dependency |
| Data ownership is preserved |
|
10.4 데이터 도메인 패턴
그림 10-8에서 Wishlist, Product 테이블은 두 서비스 중 어느 쪽도 독적하지 않고 서로 공유해 경계 콘텍스트가 더 넓어졌습니다.
이제 위시리스트 서비스는 두 테이블을 join 해서 item_desc 데이터를 가져올 수 있습니다.
Figure 10-8. Data domain data access pattern
이런 데이터 공유는 분산 아키텍처에 적합하지 않지만, 앞의 세 가지 패턴에 비해 장점이 더 큽니다.
서비스가 완전히 디커플리 되기 때문에 가용성 디펜던시, 응답성, 처리량, 확장성 이슈가 해소됩니다.
트레이드오프는 경계 콘텍스트가 더 넓어졌기에 데이터 도메인 내의 테이블 변경이 일어나면 여러 서비스를 함께 변경해야 합니다.
또 데이터 액세스 보안도 문제가 됩니다.
경우에 따라 데이터 도메인에 접근하는 서비스가 가져가면 안 되는 데이터가 생길 수 있습니다.
서비스 오너십과 경계 콘텍스트를 더 엄격하게 적용해, 계약을 통해 다른 서비스가 특정 데이터를 주고 받지 못하도록 차단하는 방법을 써야 할 수 있습니다.
Table 10-4. Trade-offs associated with the data domain data access pattern
| Advantages |
Disadvantages |
| Good data access performance |
Broader bounded context to manage data changes |
| No scalability and throughput issues |
Data ownership governance |
| No fault tolerance issues |
Data access security |
| No service dependency |
|
| Data remains consistent |
|
10.5 한빛가이버 사가: 티켓 배정 관련 데이터 액세스
ADR: 전문 기사 프로필 데이터 메모리 복제 캐시를 사용
Context
티켓 배정 서비스는 전문 기사 프로필 테이블에 계속 액세스 해야 하지만, 이 테이블은 다른 경계 콘텍스트의 유저 관리 서비스가 소유하고 있기 때문에 저문 기사 프로필 데이터를 가져오려면 서비스간 통신, 메모리 복제 캐시, 공통 데이터 도메인 중 한 가지 방법을 강구해야 한다.
Decision
유자 관리 서비스, 티켓 배정 서비스 간에 복제 캐시를 사용하고, 전문 기사 프로필 테이블의 쓰기 권한 유저 관리 서비스만 가진다.
티켓 배정 서비스는 이미 티켓 데이터 도메인의 공통 스키마에 연결돼 있으므로 추가적인 다른 스키마에 연결할 수 없다.
또한 유저 관리 기능, 코어 티케팅 기능은 별도의 도메인에 있기 때문에 데이터 테이블을 단이르 스키마로 통합하는 것은 좋지 않다.
이런 이유로 공통 데이터 도메인은 적합하지 않다.
메모리 복제 캐시를 사용하면 서비스 간 통신에 의한 성능 및 내고장성 문제가 해결된다.
Consequences
티켓 배정 서비스의 첫 번째 인스턴스를 시작할 때 적어도 하나 이상의 유저 관리 서비스 인스턴스는 실행 중이어야 한다.
복제 캐시 제품에 대한 라이선스 비용이 발생한다.
CHAPTER 10 분산 데이터 액세스
위시리스트 서비스에는 item_id 에 해당하는 item_desc 컬럼이 없습니다.
item_desc는 카날로스 서비스의 경계 콘텍스트에 있기 때문에 item_desc 정보를 가져오는 방법에 대해 파악해 보는 게 이번 챕터를 이해하는 목표입니다.
Figure 10-1. Wishlist Service needs item descriptions but doesn’t have access to the product table containing the data
10.1 서비스 간 통신 패턴Interservice Communication pattern
분산 시스템에서 데이터를 액세스하는 가장 일반적인 패턴입니다.
간단하지만 단점이 많습니다.
그림 10-2는 위스리스트 서비스가 카탈로그 서비스에 item_id를 전달하고 이에 해당하는 item_desc 리스트를 응답하는 동기 원격 호출의 한 장면입니다.
Figure 10-2. Interservice communication data access pattern
이 과정에서 네트워크 레이턴스, 보안 레이턴시, 데이터 레이턴시가 발생하므로 성능이 떨어집니다.
모든 레이턴시를 합하면 item_desc 리스트를 가져오는 데 1초 까지도 걸릴 수 있습니다.
이 패턴의 가장 큰 단점은 서비스 커플링입니다.
두 서비스는 의미상으로, 그리고 정적으로 결합될 수밖에 없습니다.
카탈로그 서비스가 실패하면 위스리스트 서비스도 실패하게 되는게 의미상 결합이며
나중에 사용량이 늘어나 확장을 할 때도 두 서비스 모두 함께 확장해야 하는게 정적인 결합을 의미합니다.
Table 10-1. Trade-offs for the Interservice Communication data access pattern
10.2 컬럼 스키마 복제 패턴Column Schema Replication pattern
컬럼을 여러 테이블에 복제해서 다른 경계 ㅌ콘텍스트에서도 데이터를 복제해 쓸 수 있게 만드는 것입니다.
그림 10-3에서 item_desc 컬럼이 Wishlist 테이블에 있으므로 위시리스트 서비스는 카탈로그 서비스에 데이터를 요청하지 않아도 됩니다.
Figure 10-3. With the Column Schema Replication data access pattern, data is replicated to other tables
이 패턴의 가장 중대한 두 가지 문제점은 데이터 동기화와 데이터 일관성입니다.
제품 정보의 생성/변경/삭제 작업이 발생하면 카탈로그 서비스는 위시리스트 서비스 및 다른 서비스들에게 변경 사실을 알려야 합니다.
보통 큐, 토픽, 이벤트 스트리밍을 응용한 비동기 통신으로 처리합니다.
동기적으로 할 필요까진 없다면 서비스간 디펜던시를 줄일 수 있는 비동기 통신으로 하면 좋습니다.
데이터 오너십을 통제하기 어렵다는 점도 이 패턴의 또 다른 문제입니다.
다른 서비스의 테이블에 복제하므로 데이터 업데이트가 일어나게 되고, 결국 데이터 일관성에 문제가 생길 수 있습니다.
데이터 동기화가 문제지만 데이터를 읽기만 하는 서비스라면 성능, 내고장성, 확장성은 크게 개선됩니다.
이런 단점에도 불구하고 데이터 집계, 리포팅, 대용량 데이터를 처리해야 하면서 높은 응답성, 높은 내고장성이 필요하면 고려해볼 수 있는 패턴입니다.
Table 10-2. Trade-offs for the Column Schema Replication data access pattern
10.3 복제 캐싱 패턴Replicated Caching Pattern
각 서비스가 필요로 하는 데이터를 다른 서비스에 매번 요청하지 않고 바로 사용할 수 있도록 메모리 캐시에 데이터를 복제하는 기법입니다.
데이터가 각 서비스의 메모리에 저장되고 모든 서비스가 언제나 정확히 동일한 데이터를 참조하도록 계속 동기화하는게 다른 캐싱 모델과 다른 점입니다.
그림 10-4는 각 서비스가 내부 메모리 캐시를 자체 보유해서 데이터가 서로 다른 캐시간에 동기화 되지 않는 형태입니다.
각 서비스의 응답성과 확장성은 조금 높일 수 있지만, 서비스 간 캐시 동기화가 되지 않으므로 데이터 일관성을 유지하기는 어렵습니다.
Figure 10-4. With a single in-memory cache, each service contains its own unique data
그림 10-5는 데이터를 외부 캐시 서버에 보관하는 분산 캐싱distributed caching 방법입니다.
단일 메모리 캐싱 모델과 달리 서비스간 데이터 공유가 가능하게 됩니다.
Figure 10-5. A distributed cache is external from the services
하지만 효과적인 캐싱 모델이 아닌 세 가지 이유가 있습니다.
복제 캐싱 모델은 서비스 간에 동기화된 데이터를 각 서비스 별 메모리에 가지고 있으므로 같은 데이터를 다수의 서비스가 공유하고 있습니다.
그림 10-6과 같이 각 캐시 인스턴스는 서로 끊임없이 통신하면서 한 캐시에서 업데이트가 일어나면 다른 서비스에 동일한 캐시를 사용할 수 있도록 백그라운드에서 비동기적으로 업데이트합니다.
Figure 10-6. With a replicated cache, each service contains the same in-memory data
복제 캐싱을 지원하는 대표적인 제품으로 Hazelcast, Apache Ignite, Oracle Coherence가 있습니다.
그림 10-7에서 카탈로그 서비스는 item_desc 데이터를 메모리에 캐시로 갖고 있으며, 위시리스트 서비스는 동일한 캐시를 읽기 전용 메모리 사본으로 가지고 있는 형태입니다.
Figure 10-7. Replicated caching data access pattern
응답성, 내고장성, 확장성 측면에서 확실히 복제 캐싱 패턴이 월등히 좋습니다.
이 패턴의 첫 번째 트레이드오프는 서비스가 캐시 데이터와 시작 타이밍에 의존하게 된다는 점입니다.
카탈로그 서비스가 사용 불가능한 상태가 되면, 위시리스트 서비스는 대기 상태로 있어야 합니다.
이런 시작 디펜던시startup dependency는 초기 위시리스트 서비스 인스턴스에만 영향을 끼칩니다.
두 번째 트레이드오프는 데이터양data volume입니다.
예시로 500MB 이상의 데이터 크기라면 이 패턴의 실용성은 급격히 떨어집니다.
서비스 인스턴스마다 캐시 데이터를 가지고 있다고 하면, 5개 서비스 인스턴스일 때는 2.5GB의 메모리가 필요하게 됩니다.
세 번째 트레이드오프는 데이터 변경 빈도가 많을 경우 서비스 간에 데이터를 완전히 동기화시키기가 어렵다는 점입니다.
정적인 데이터(제품 설명)에는 맞을 수 있지만 변경이 잦은 데이터(제품 재고 수)에는 적합하지 않습니다.
네 번째 트레이드오프는 구성 및 설정 관리 문제입니다.
복제 캐싱 모델은 TCP/IP 브로드캐스팅, lookup을 통해 서로를 인지합니다.
이 범위가 너무 커지면 소켓 레벨에서 handshake를 하는 시간이 오래 걸리고, 클라우드 환경이라면 동적 IP 주소를 가지므로 제어가 어렵게 됩니다.
Table 10-3. Trade-offs associated with the replicated caching data access pattern
10.4 데이터 도메인 패턴
그림 10-8에서 Wishlist, Product 테이블은 두 서비스 중 어느 쪽도 독적하지 않고 서로 공유해 경계 콘텍스트가 더 넓어졌습니다.
이제 위시리스트 서비스는 두 테이블을 join 해서 item_desc 데이터를 가져올 수 있습니다.
Figure 10-8. Data domain data access pattern
이런 데이터 공유는 분산 아키텍처에 적합하지 않지만, 앞의 세 가지 패턴에 비해 장점이 더 큽니다.
서비스가 완전히 디커플리 되기 때문에 가용성 디펜던시, 응답성, 처리량, 확장성 이슈가 해소됩니다.
트레이드오프는 경계 콘텍스트가 더 넓어졌기에 데이터 도메인 내의 테이블 변경이 일어나면 여러 서비스를 함께 변경해야 합니다.
또 데이터 액세스 보안도 문제가 됩니다.
경우에 따라 데이터 도메인에 접근하는 서비스가 가져가면 안 되는 데이터가 생길 수 있습니다.
서비스 오너십과 경계 콘텍스트를 더 엄격하게 적용해, 계약을 통해 다른 서비스가 특정 데이터를 주고 받지 못하도록 차단하는 방법을 써야 할 수 있습니다.
Table 10-4. Trade-offs associated with the data domain data access pattern
10.5 한빛가이버 사가: 티켓 배정 관련 데이터 액세스
ADR: 전문 기사 프로필 데이터 메모리 복제 캐시를 사용
Context
티켓 배정 서비스는 전문 기사 프로필 테이블에 계속 액세스 해야 하지만, 이 테이블은 다른 경계 콘텍스트의 유저 관리 서비스가 소유하고 있기 때문에 저문 기사 프로필 데이터를 가져오려면 서비스간 통신, 메모리 복제 캐시, 공통 데이터 도메인 중 한 가지 방법을 강구해야 한다.
Decision
유자 관리 서비스, 티켓 배정 서비스 간에 복제 캐시를 사용하고, 전문 기사 프로필 테이블의 쓰기 권한 유저 관리 서비스만 가진다.
티켓 배정 서비스는 이미 티켓 데이터 도메인의 공통 스키마에 연결돼 있으므로 추가적인 다른 스키마에 연결할 수 없다.
또한 유저 관리 기능, 코어 티케팅 기능은 별도의 도메인에 있기 때문에 데이터 테이블을 단이르 스키마로 통합하는 것은 좋지 않다.
이런 이유로 공통 데이터 도메인은 적합하지 않다.
메모리 복제 캐시를 사용하면 서비스 간 통신에 의한 성능 및 내고장성 문제가 해결된다.
Consequences
티켓 배정 서비스의 첫 번째 인스턴스를 시작할 때 적어도 하나 이상의 유저 관리 서비스 인스턴스는 실행 중이어야 한다.
복제 캐시 제품에 대한 라이선스 비용이 발생한다.