Xtring's Blog

Space-based architecture

웹 기반 비즈니스 애플리케이션은 대부분 일반적인 요청 흐름을 따라감
- 브라우저에서 요청을 보내면 웹서버 > 애플리케이션 서버 > 데이터베이스 서버 순서로 진행됨
- 고 트레픽이 발생하면 점점 병목현상이 발생하게 됨
  - 처음에는 웹서버, 그 다음에는 애플리케이션, 데이터베이스 서버 레이어에서도 나타남
- 웹 서버의 확장을 통해 병목 현상을 해결가능
  - 비교적 쉽고 저렴, 효과적으로 병목을 제거할 수 있음
  - 하지만, 웹서버 확장 후 애플리케이션, 데이터베이스 쪽으로 다시 병목이 발생함
    - 삼각형 토폴로지(triangle-shaped topology) 형태가 그려짐
동시 유저 부하가 많은 대용량 애플리케이션
- 데이터베이스의 동시 처리 가능한 트랜잭션 수가 최종 제약조건이 되는 경우가 많음
- 다양한 캐시 기술과 데이터베이스 확장 제품으로 문제 해결이 가능
  - 하지만, 부하가 엄청날게 밀려 들어오는 상황에서 여느 애플리케이션을 확장하는 작업은 쉽지 않음

위에서 설명한 일반적인 레이드 아키텍처 스타일의 한계과 대용량 애플리케이션 운영의 어려움에 따라 공간 기반 아키텍처 스타일이 탄생(확장성, 탄력성, 동시성을 해결, 동시 유저 수가 매우 가변적이라서 예측조차 곤란한 애플리케이션에서 유용)

극단적, 가변적인 확장성 문제는 데이터베이스를 확장하거나, 확장성이 떨어지는 아키텍처에 맞게 캐시 기술을 적용하는 것보다 아키텍처적으로 해결하는 것이 좋다.

토폴로지

공간 기반 아키텍처(space-based architecture) 라는 명칭은 튜플 공간(tuple space; 병렬/분산 컴퓨팅을 위한 연관 메모리 패러다임의 구현, 동시에 액세스할 수 있는 튜플의 저장소를 제공)

튜플 공간은 공유 메모리를 통해 통신하는 다중 병렬 프로세서를 사용하는 기술 시스템에서 동기 제약조건인 데이터베이스를 없애는 대신 복제된 인메모리 데이터 그리드(in-memory data grid)를 활용 - 확장성, 탄력성, 성능을 높일 수 있음
애플리케이션 데이터는 메모리에 둔 상태로 모든 활성 처리 장치들이 데이터를 복제
처리 장치는 데이터를 업데이트할 때 퍼시스턴스 큐(persistent queue)에 메시지를 보내는 식으로 데이터베이스에 데이터를 비동기 전송
- 공간 기반 아키텍처의 장점
  - 가변적인 확장 : 유저부하의 증감에 따라 처리 장치는 동적으로 시작/종료할 수 있음
  - 중앙 데이터베이스가 애플리케이션의 표준 트랜잭션 처리에 관여하지 않음
    - 병목 현상이 사라짐
    - 무한에 가까운 확장성
공간 기반 아키텍처의 구성(공간 기반 아키텍처의 기본 토폴로지 참고, p.267/그림 15-2)
- 처리 장치(processing unit) : 애플리케이션 코드가 구현됨
- 가상 미들웨어(virtualized middleware) : 처리 장치를 관리/조정
- 데이터 펌프(data pump) : 업데이트된 데이터를 데이터베이스에 비동기 전송함
- 데이터 라이터(data writer) : 데이터 펌프에서 데이터를 받아 업데이트를 수행
- 데이터 리더(data reader) : 처리 장치가 시작되자마자 데이터베이스의 데이터를 읽어 (처리 장치에)전달

처리 장치

애플리케이션 로직(또는 로직의 일부분)을 갖고 있음 - 보통 웹 기반 컴포넌트와 백엔드 비즈니스 로직 - 애플리케이션의 종류마다 내용물이 달라짐

(그림 15-3)

애플리케이션 사이즈에 따른 배포방식
- 작은 웹 기반 애플리케이션: 단일 처리 장치에 배포
- 대규모 애플리케이션: 기능별로 여러 처리 장치에 나누어 배포
마이크로서비스처럼 규모가 작은 단일 목적의 서비스도 처리 장치에 포함시킬 수 있음
애플리케이션 로직 이외에도 인메모리 데이터 그리드 및 복제 엔진도 처리장치에 포함됨
- 인메모리 데이터 그리드 및 복제 엔진 제품 : 헤이즐캐스트(Hazelcast), 아파치 이그나이트(Apache Ignite), 오라클 코히어런스(Oracle Coherence) 등

가상 미들웨어

아키텍처 내부에서 데이터 동기화 및 요청 처리의 다양한 부분을 제어하는 인프라를 담당(처리 장치를 관리/조정) 구성 컴포넌트

메시징 그리드(messaging grid)

데이터 그리드(data grid)

처리 그리드(processing grid)

배포 관리자(deployment manager) 이렇게 구성된 컴포넌트는 직접 작성하거나 서드파티 제품으로 구매할 수 있음

(1) 메시징 그리드(messaging grid)

입력 요청과 세션 상태를 관리
- 가상 미들웨어에 요청이 유입되면 어느 활성 처리가 요청을 받아 처리할지 결정하여 해당 처리 장치로 요청을 전달
처리 복잡도 는 다양함
- 단순 라운드 로빈 알고리즘 ~ 처리 장치가 요청 처리 상태를 추적하는 복잡한 알고리즘
보통 부하 분산이 가능한 일반 웹 서버로 구현됨
- HA poxy, Nginx 등

(2) 데이터 그리드(data grid)

처리 장치 간의 데이터 동기화를 위한 역할
- 실제로 데이터 동기화는 비동기 방식
- 매우 신속하게, 대개 100ms초 미만으로 이루어짐
이 아키텍처 스타일에서 가장 중요하고 필수적인 컴포넌트
- 요즘은 거의 대부분 복제 캐시로서 처리 장치에만 구현
- 외부 컨트롤러가 필요한 복제 캐시 구현체나 분산 캐시(distributed cache)를 사용하는 경우, 데이터 그리드는 가상 미들웨어 내부의 데이터 그리드 컴포넌트와 처리 장치 모두에 위치
데이터는 이름이 동일한 데이터 그리드가 포함된 처리 장치 간에 동기화
- 캐시 변경이 일어나면
  - 동일한 이름의 캐시가 포함된 다른 모든 처리 장치에 변경된 데이터가 복제됨
  - 처리 장치는 작업을 마치는데 필요한 만큼의 복제 캐시를 소유할 수 있음
  - 캐시 동기화 컨트롤 방식
    - 하나의 처리 장치가 다른 처리 장치를 원격 호출해서 데이터를 요청(코레오그래피)
    - 처리 그리드를 이용해서 요청을 오케스트레이트
      - 처리 그리드는 다수의 처리 장치가 단일 비즈니스 요청을 처리할 경우 요청 처리를 오케스트레이트함
      - 종류가 다른 처리 장치 사이에 조정이 필요한 요청이 들어오면 처리 그리드가 두 처리 장치 사이에서 요청을 중재/조정
각 처리 장치는 멤버 리스트(member list)를 사용해 다른 모든 처리 장치 인스턴스를 인지
- 멤버 리스트에는 동일한 이름의 캐시를 사용하는 다른 모든 처리 장치의 IP 주소 및 포트가 들어있음
- 다른 처리 장치에서 동일한 이름의 캐시가 기동되면 두 서비스의 멤버 리스트가 업데이트
  - 그리고 각 처리 장치의 IP 주소 및 포트가 반영
- 세 인스턴스 모두(자신을 포함해서) 상대방의 존재를 알고 있음
  - Instance 1 데이터를 업데이트(cache.put())하게되면 데이터 그리드(ex: 헤이즐캐스트)는 다른 복제 캐시도 똑같이 비동기 업데이트하는 식으로 세 인스턴스의 캐시를 동일하게 맞춤

Instance 1:
Memeber {size: 3, ver: 3} [
	Member [172.19.248.89]:5701 - 2f8s76fs-xc876-s87xc68f7-xd87f6s8 this
	Member [172.19.248.90]:5702 - 65kjh6lk5-56k8jh-3lsd4lkh6-k34jg5
	Member [172.19.248.91]:5703 - 1k2jh37m-l97kffj-76lkh8j-34j65hg2
]

Instance 2:
Memeber {size: 3, ver: 3} [
	Member [172.19.248.89]:5701 - 2f8s76fs-xc876-s87xc68f7-xd87f6s8
	Member [172.19.248.90]:5702 - 65kjh6lk5-56k8jh-3lsd4lkh6-k34jg5 this
	Member [172.19.248.91]:5703 - 1k2jh37m-l97kffj-76lkh8j-34j65hg2
]

Instance 3:
Memeber {size: 3, ver: 3} [
	Member [172.19.248.89]:5701 - 2f8s76fs-xc876-s87xc68f7-xd87f6s8
	Member [172.19.248.90]:5702 - 65kjh6lk5-56k8jh-3lsd4lkh6-k34jg5
	Member [172.19.248.91]:5703 - 1k2jh37m-l97kffj-76lkh8j-34j65hg2 this
]

(3)처리 그리드

가상 미들웨어에서 필수 컴포넌트는 아님
다수의 처리 장치가 단일 비즈니스 요청을 처리할 경우
- 요청 처리를 오케스트레이트
종류가 다른 처리 장치 사이에 조정이 필요한 요청이 들어오는 경우
- 두 처리 장치 사이에서 요청을 중재/조정

(4) 배포 관리자(deployment manager)

부하 조건에 따라 처리 장치 인스턴스를 동적으로 시작/종료하는 컴포넌트
애플리케이션에서 다양한 확장성(탄력성) 요구사항을 구현하는 데 꼭 필요한 컴포넌트
- 응답 시간, 유저 부하를 모니터링
  - 부하 증가 시 새로운 처리 장치를 기동
  - 부하 감소 시 기존 처리 장치를 종료

데이터 펌프

데이터를 다른 프로세서에 보내 데이터베이스를 업데이트하는 장치(; 업데이트된 데이터를 DB에 비동기 전송)

동작방식
- 처리 장치가 데이터를 데이터베이스를 통해 직접 액세스하지 않음
  - 데이터 펌프가 이 역할을 함
- 항상 비동기로 동작
- 메모리 캐시와 데이터베이스의 최종 일관성을 실현
  - 처리 장치 인스턴스가 요청을 받고 캐시를 업데이트한 뒤 데이터 펌프가 최종 일관성을 위해 데이터베이스에 업데이트 전송
구현
- 데이터 펌프는 대개 메시징 기법으로 구현
  - 메시징
    - 비동기 통신을 지원하고 전달을 보장
    - FIFO(선입 선출) 큐를 통해 메시지 순서 유지
    - 처리 장치와 데이터 라이터를 분리할 수 있음
      - 데이터 라이터를 사용할 수 없는 경우 처리 장치에서 무중단 처리가 가능
대부분의 경우 데이터 펌프는 도메인이나 그 서브도메인 별로 여러 개를 사용
- 캐시 종류 별로 전용 데이터 펌프 배정
- 훨씬 더 크고 일반적인 캐시를 포함한 처리 장치 도메인 별로 배정
계약 데이터와 연관 액션(추가, 삭제, 수정)을 포함
- 계약 포맷
  - JSON 스키마, XML 스키마, 객체, 값 기반 메시지(value-driven message) 등 다양함
  - 업데이트 데이터는 보통 데이터 펌프 안에 새 데이터 값만 보관

데이터 라이터

데이터 펌프에서 메시지를 받아 그에 맞게 데이터베이스를 업데이트하는 컴포넌트

서비스, 애플리케이션, 데이터 허프(앱 이니셔; Ab Initio)로 구현
세분도
- 데이터 펌프와 처리 장치의 범위마다 다름
- 도메인 기반 데이터 라이터
  - 데이터 펌프 수와 무관
  - 특정 도메인의 전체 업데이트를 처리하는 데 필요한 모든 데이터베이스 로직을 가지고 있음
  - 예를 들어 고객 관련 처리 장치 4개와 데이터 펌프 4개가 있는 경우 하나의 데이터 라이터를 통해 데이터베이스에 업데이트
    - 고객 데이터 라이터 하나가 4개의 데이터 펌프를 모두 리스닝
    - 데이터베이스에 있는 고객 관련 테이블 레코드를 업데이트하는 로직(SQL)을 가지고 있음
- 처리 장치 클래스마다 자체 전용 데이터 라이터를 두는 경우
  - 각 데이터 라이터가 자신의 전용 데이터 펌프를 소유하고 해당 처리 장치의 데이터베이스 로직을 처리
  - 단점: 데이터 라이터가 너무 많음
  - 장점: 처리 장치, 데이터 펌프, 데이터 라이터가 나란히 정렬되어 확장성, 민첩성이 좋음

데이터 리더

데이터베이스에서 데이터를 읽어 리버스 데이터 펌프(reverse data pump)를 통해 처리 장치로 실어 나르는 컴포넌트

데이터 리더는 세 가지 경우에서만 동작
- 첫째, 동일한 이름의 캐시를 가진 모든 처리 장치 인스턴스가 실패하는 경우
- 둘째, 동일한 이름의 캐시 안에서 모든 처리 장치를 재배포하는 경우
- 셋째, 복제 캐시에 들어있지 않은 아카이브 데이터를 조회하는 경우
인스턴스가 모조리 다운되면 데이터는 데이터베이스에서 읽어올 수 밖에 없음
- 인스턴스 다운 케이스 : 시스템 전체 장애, 전체 인스턴스를 재배포하는 경우
- 공간 기반 아키텍처에서는 크리티컬함
- 케이스 시뮬레이션
  - (1) 처리 장치 인스턴스가 하나 둘 살아나기 시작하면서 각 인스턴스는 캐시에서 락을 획득하려고 함
  - (2) 락을 얻은 첫번째 인스턴스는 임시 캐시 소유자가 되고 한발 늦은 나머지 인스턴스들은 락이 해제될 때까지 대기(캐시 구현체마다 로직은 조금씩 다르지만 여기서는 캐시 소유자가 하나라고 가정)
  - (3) 임시 캐시 소유자가 된 인스턴스는 데이터를 요청하는 큐에 메시지를 보내 캐시를 로드
  - (4) 데이터 리터가 읽기 요청을 받아 데이터베이스를 쿼리하여 처리 장치에 필요한 데이터를 검색
  - (5) 데이터를 다른 큐(리버스 데이터 펌프)로 보냄
  - (6) 임시 캐시 소유자인 처리 장치는 리버스 데이터 펌프에서 데이터를 받아 캐시를 로드
  - (7) 캐시 로드 완료 후 임시 소유자는 캐시 락을 해제하고 다른 모든 인스턴스가 동기화되면 처리를 개시
세분도
- 데이터 라이터와 같이 도메인 기반으로 구분할 수 있음
- 그러나 특정 처리 장치의 클래스 전용으로 사용하는 것이 보통
- 서비스, 애플리케이션, 데이터 허브 모두 구현체는 데이터 라이터와 동일
데이터 라이터와 데이터 리더는 본질적으로
- 데이터 추상 레이어(data abstraction layer; 또는 어떤 경우에는 데이터 액세스 레이어)를 형성
  - 데이터 추상 레이어와 데이터 액세스 레이어의 차이점
    - 처리 장치가 데이터베이스의 테이블(또는 스키마) 구조를 얼마나 자세히 알고 있는가
    - 데이터 액세스 레이어
      - 처리 장치가 데이터베이스의 하부 데이터 구조와 커플링
      - 그래서 데이터 리더/라이터만 사용해서 간접적으로 데이터베이스에 액세스
    - 데이터 추상 레이어
      - 처리 장치가 별도의 계약에 의해 하부 데이터베이스의 테이블 구조와 분리
  - 일반적으로 공간 기반 아키텍처는 데이터 추상 레이어 모델(data abstraction layer)에 기반
    - 처리 장치마다 복제 캐시 스키마는 하부 데이터 베이스의 테이블 구조와 다를 수 있음
    - 처리 장치에 영향을 미치지 않고서도 데이터베이스 증분 변경(incremental change)이 가능
      - 데이터 리더/라이터에 이미 변환 로직이 포함되어 있기 때문에 증분 변경이 더 용이함
      - 가령, 컬럼 타입이 변경되거나 컬럼/테이블이 삭제될 때에도 변경분이 처리 장치 캐시에 반영될 때까지 데이터 리더/라이터는 데이터베이스 변경을 버퍼링할 수 있음

데이터 충돌

이름이 동일한 캐시가 포함된서비스 인스턴스에 시시각각 업데이트가 일어나는 active/active 상태에서 복제 캐시를 사용하면 복제 레이턴시(replication latency) 때문에 데이터 충돌(data collision)이 발생할 수 있다.

한 캐시 인스턴스(캐시 A)에서 데이터가 업데이트되어 다른 캐시 인스턴스(캐시 B)에 복제하는 도중에 동일한 데이터가 해당 캐시(캐시 B)에서 업데이트되는 현상을 말한다. 결국, 캐시 B의 로컬 업데이트는 캐시 A에서 복제된 이전 데이터 때문에 덮어씌워지고, 반대로 캐시 A에서는 동일한 데이터가 캐시 B에서 발생한 업데이트 때문에 덮어씌워지는 불상사가 발생한다.

데이터 충돌 발생 빈도
- 빈도에 영향을 주는 요소들
  - 동일한 캐시를 포함한 처리 장치 인스턴스 수
  - 캐시 업데이트율(update rate)
  - 캐시 크기
  - 캐시 제품의 복제 레이턴시
  - 등 여러 팩터가 영향을 미침
- 공식
  - 충돌률 = N _ UR^2/S _ RL
    - N: 동일한 이름의 캐시를 사용하는 서비스 인스턴스 수
    - UR: 밀리초 당 업데이트
    - S: 캐시 크기(로우 개수)
    - RL: 캐시 제품의 복제 대기 시간
  - 데이터 충돌률(%)을 통해 복제 캐시가 쓸 만한지 미리 파악할 때 유용
- 가변적인 복제 레이턴시(RL)는 데이터 일관성에 중대한 영향을 미침
  - 제대로 측정하는 방법
    - 네트워크 유형, 처리 장치 간 물리적 거리 등 다양한 팩터에 좌우되 때문에 복제 레이턴시 값이 공시되는 경우는 거의 없으니 직접 프로덕션 환경에서 값을 측정해야함
    - 실제 복제 레이턴시를 구하기 어렵다면 예제에서 사용한 100ms 값을 공식에 넣어 데이터 충돌 횟수를 계산
- 동일한 이름의 캐시를 포함한 처리 인스턴스 장치 수
  - 발생 가능한 데이터 충돌 횟수에 비례
- 캐시 크기는 유일하게 충돌률과 반비례 관계인 팩터
  - 캐시가 작을 수록 충동률은 증가
- 대부분의 시스템은 정상적인 경우 오래 꾸준히 업데이트하지 않음
  - 주의할점: 충동률을 계산할 때에는 사용량이 가장 많은 시점의 최대 업데이트율에 따라 최소, 정상, 최대 충돌률을 산출하는 것이 바람직함

Cloude vs On-Promise 구현

공간 기반 아키텍처는 배포환경 측면에서 독자적인 선택지가 있음
- 전체 토폴로지를 클라우드 기반 환경 혹은 온프레미스에 배포할 수 있음
  - 혹은 두 환경 사이에 어중간하게 배포하는 경우도 있음
    - 하이브리드 클라우드
    - 이 방식이 다른 아키텍처 스타일에서는 찾아볼 수 없는 이 아키텍처의 특징
    - 방법
      - 물리적 데이터베이스와 데이터를 온프레미스에 그대로 둔 상태에서 클리우드 기반의 매니지드(managed; 관리형) 환경에서 처리 장치와 가상 미들웨어를 통해 애플리케이션 배포
    - 비동기 데이터 펌프와 이 아키텍처 스타일의 최종 일관성 모델에 대한 이점을 가질 수 있음
      - 효율적인 클라우드 기반의 데이터 동기화 가능
      - 트랜잭션은 탄력적인 동적 클라우드 기반의 환경에서 처리
      - 물리적인 데이터 관리, 리포팅, 데이터 분석 데이터는 안전한 로컬 온프레미스 환경에서 보관이 가능함

복제 캐시 vs 분산 캐시

공간 기반 아키텍처는 캐시 기술을 활용
- 캐시를 통해 애플리케이션 트랜잭션을 처리하고 데이터베이스에 직접 읽기/쓰기를 하지 않음
  - 확정성, 탄력성, 성능이 우수
- 캐싱 방법
  - 복제 캐시
  - 분산 캐시

복제 캐시

각 처리 장치는 이름이 동일한 캐시를 사용하는 모든 처리 장치 간에 동기화되는 자체 인메모리 데이터 그리드를 가짐
동작 방식
- 한 처리 장치에서 캐시가 업데이트
- 다른 처리 장치도 새로운 데이터로 자동 업데이트
- 비동기 방식으로 처리됨
장점
- 속도가 매우 빠름
- 높은 수준의 내고장성 지원
- 단일 장애점이 없음
단점
- 어떤 캐시 구현체를 사용하는지에 따라 이 규칙에도 예외가 있을 수 있음
  - 외부 컨트롤러가 반드시 필요한 캐시 제품이 있음
  - 대부분의 제품 개발사는 이와같은 모델을 지양하는 추세
- 데이터량(캐시 크기)이 엄청 많거나 캐시 데이터가 빈법하게 업데이트되는 경우