소프트웨어 아키텍처 101 - CHAPTER 15 공간 기반 아키텍처 스타일

공간 기반 아키텍처 스타일(space-based architecture style)은 높은 확장성, 탄력성, 동시성 및 이와 관련된 문제를 해결하기 위해 설계된 아키텍처 스타일입니다. 동시 유저 수가 매우 가변적이라서 예측조차 곤란한 애플리케이션에서도 유용합니다. 극단적이고 가변적인 확장성 문제는 데이터베이스를 확장하거나, 확장성이 떨어지는 아키텍처에 맞게 캐시 기술을 적용하는 것보다 아키텍처적으로 해결하는 것이 더 낫습니다.

15.1 토폴로지

공간 기반 아키텍처라는 명칭은 튜플 공간(tuple space)에서 유래됐습니다. 튜플 공간은 공유 메모리를 통해 통신하는 다중 프로세서를 사용하는 기술입니다. 시스템에서 동기 제약조건인 중앙 데이터베이스를 없애는 대신, 복제된 인메모리 데이터 그리드(in-memory data grid)를 활용하면 확장성, 탄력성, 성능을 높일 수 있습니다. 애플리케이션 데이터는 메모리에 둔 상태로 모든 활성 처리 장치들이 데이터를 복제합니다. 처리 장치는 데이터를 업데이트할 때 퍼시스턴스 큐(persistent queue)에 메시지를 보내는 식으로 데이터베이스에 데이터를 비동기 전송합니다. 유저 부하의 증가/감소에 따라 처리 장치는 동적으로 시작/종료할 수 있어 가변적으로 확장할 수 있습니다. 중앙 데이터베니스가 애플리케이션의 표준 트랜젝션 처리에 관여하지 않으므로 데이터베이스 병목 현상이 사라지고 애플리케이션은 거의 무한에 가까운 확장성이 보장됩니다.

공간 기반 아키텍처는 애플리케이션 코드가 구현된 장치(processing unit), 처리 장치를 관리/조정하는 가상 미들웨어(virualized middleware), 업데이트된 데이터를 데이터베이스에 비동기 전송하는 데이터 펌프(data pump), 데이터 펌프에서 데이터를 받아 업데이트를 수행하는 데이터 라이터(data writer), 처리 장치가 시작되자마자 데이터베이스의 데이터를 읽어 전달하는 데이터 리더(data reader) 컴포넌트로 구성됩니다[그림 15-2].

15.1.1 처리 장치

처리 장치는 애플리케이션 로직(또는 로직의 일부분)을 갖고 있습니다.

15.1.2 가상 미들웨어

가상 미들웨어는 아키텍처 내부에서 데이터 동기화 및 요청 처리의 다양한 부분을 제어하는 인프라를 담당합니다. 가상 미들웨어는 메시징 그리드(messaging grid), 데이터 그리드(data grid), 처리 그리드(processing grid), 배포 관리자(deployment manager) 등의 컴포넌트로 구성됩니다.

메시징 그리드

메시징 그리드(messaging grid)는 입력 요청과 세션 상태를 관리합니다. 가상 미들웨어에 요청이 유입되면 메시징 그리드는 어느 활성 처리장치가 요청을 받아 처리할지 결정하여 해당 처리 장치로 요청을 전달합니다.

데이터 그리드

데이터 그리드(data grid)는 이 아키텍처 스타일에서 가장 중요하고 필수적인 컴포넌트입니다. 요즘은 데이터 그리드가 거의 대부분 복제 캐시로서 처리 장치에만 구현되어 있지만, 외부 컨트롤러가 필요한 복제 캐시 구현체나 분산 캐시(distributed cache)를 사용할 경우, 데이터 그리드는 가상 미들웨어 내부의 데이터 그리드 컴포넌트와 처리 장치 모두에 위치합니다.

데이터는 이름이 동일한 데이터 그리드가 포함된 처리 장치 간에 동기화됩니다.

처리 그리드

처리 그리드(processing grid)는 가상 미들웨어에서 필수 컴포넌트는 아니지만, 다수의 처리 장치가 단일 비즈니스 요청을 처리할 경우 요청 처리를 오케스트레이드하는 일을 합니다. 또 종류가 다른 처리 장치 사이에 조정이 필요한 요청이 들어오면 처리 그리드가 두 처리 장치 사이에서 요청을 중재/조정합니다.

배포 관리자

배포 관리자(deployment manager)는 부하 조건에 따라 처리 장치 인스턴스를 동적으로 시작/종료하는 컴포넌트입니다. 응답 시간, 유저 부하를 계속 모니터링하다가 부하가 증가하면 새로운 처리 장치를 기동하고 반대로 감소하면 기존 처리 장치를 종료합니다.

15.1.3 데이터 펌프

데이터 펌프(data pump)는 데이터를 다른 프로세서에 보내 데이터베이스를 업데이트하는 장치입니다. 공간 기반 아키텍처에서는 처리 장치가 데이터를 데이터베이스에(서) 직접 읽고 쓰지 않으므로 데이터 펌프는 반드시 필요합니다. 또 데이터 펌프는 항상 비동기로 동작하면서 메모리 캐시와 데이터베이스의 최종 일관성을 실현합니다. 처리 장치 인스턴스가 요청을 받고 캐시를 업데이트하면 처리 장치가 그 업데이트의 소유자가 되므로 데이터베이스 역시 데이터 펌프를 통해 최종 일관적으로 업데이트되도록 업데이트를 전송해야 합니다.

대부분의 경우 데이터 펌프는 도메인이나 그 서브도메인 별로 여러 개를 사용합니다. 캐시 종류 별로 전용 데이터 펌프를 두거나, 이보다 훨씬 더 크고 일반적인 캐시를 포함한 처리 장치 도메인 별로 배정할 수도 있습니다.

데이터 펌프는 계약 데이터와 연관된 액션(추가, 삭제, 수정)을 포함합니다. 계약 포맷은 JSON 스키마, XML 스키마, 객체, 값 기반 메시지(value-driven message, 이름-값 쌍이 포함된 메시지 매핑) 등 다양합니다. 업데이트 데이터는 보통 데이터 펌프 안에 새 데이터 값만 보관합니다.

15.1.4 데이터 라이터

데이터 라이터(data writer)는 데이터 펌프에서 메시지를 받아 그에 맞게 데이터베이스를 업데이트하는 컴포넌트입니다.

도메인 기반의 데이터 라이터는 데이터 펌프 수와 무관하게 특정 도메인의 전체 업데이트를 처리하는 데 필요한 모든 데이터베이스 로직을 갖고 있습니다.

15.1.5 데이터 리더

데이터 리더(data reader)는 데이터베이스에서 데이터를 읽어 리버스 데이터 펌프(reverse data pump)를 통해 처리 장치로 실어 나르는 컴포넌트 입니다. 공간 기반 아키텍처에서 데이터 리더는 세가지 경우에만 작동됩니다. 첫째, 동일한 이름의 캐시를 가진 모든 처리 장치 인스턴스가 실패하는 경우, 둘째, 동일한 이름의 캐시 안에서 모든 처리 장치를 재배포하는 경우, 셋째, 복제 캐시에 들어있지 않은 아카이브 데이터를 조회하는 경우입니다.

인스턴스가 모조리 다운되면 데이터는 데이터베이스에서 읽어올 수밖에 없습니다. 처리 장치 인스턴스가 하나 둘 살아나기 시작하면서 각 인스턴스는 캐시에서 락을 획득하려고 합니다. 락을 손에 넣은 첫 번째 인스턴스는 임시 캐시 소유자가 되고 한발 늦은 나머지 인스턴스들은 락이 해제될 때까지 마냥 기다립니다. 임시 캐시 소유자가 된 인스턴스는 데이터를 요청하는 큐에 메시지를 보내 캐시를 로드립니다. 그러면 데이터 리더가 읽기 요청을 받아 데이터베이스를 쿼리하여 처리 장치에 필요한 데이터를 검색하고 그 결과 데이터를 다른 큐(리버스 데이터 펌프)로 보냅니다. 임시 캐시 소유자인 처리 장치는 리버스 데이터 펌프에서 데이터를 받아 캐시를 로드하는데, 이 작업이 모두 끝나면 임시 소유자는 캐시 락을 해제하고 다른 모든 인스턴스가 동기화되면 처리를 개시합니다.

데이터 리더도 데이터 라이터처럼 도메인 기반으로 할 수 있지만 특정 처리 장치의 클래스 전용으로 사용하는 게 보통입니다.

데이터 라이터와 데이터 리더는 본질적으로 데이터 추상 레이어(data abstraction layer)(또는 어떤 경우에는 데이터 액세스 레이어(data access layer))를 형성합니다. 두 레이어의 차이점은 처리 장치가 데이터베이스의 테이블(또는 스키마) 구조를 얼마나 자세히 알고 있는가, 입니다. 데이터 액세스 레이어는 처리 장치가 데이터베이스의 하부 데이터 구조와 커플링 되어 있으므로 데이터 리더/라이터만 사용해서 간접적으로 데이터베이스에 액세스합니다. 이와 달리, 데이터 추상 레이러는 처리 장치가 별도로 계약에 의해 하부 데이터베이스의 테이블 구조와 분리되어 있습니다. 일반적으로 공간 기반 아키텍처는 데이터 추상 레이어 모델에 기반하므로 처리 장치마다 복제 캐시 스키마는 하부 데이터베이스의 테이블 구조와 다를 수 있고, 따라서 처리 장치에 영향을 미치지 않고서도 데이터베이스 증분 변경(incremental change)이 가능하며, 데이터 리더/라이터에 이미 변환 로직이 포함되어 있기 때문에 이런 증분 변경이 더 용이합니다.

15.2 데이터 충돌

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

데이터 충돌 발생 빈도는 동일한 캐시를 포함한 처리 장치 인스턴스 수, 캐시 업데이트율(update rate), 캐시 크기, 캐시 제품의 복제 레이턴시 등 여러 팩터가 영향을 미칩니다. 데이터 충돌률을 수학적으로 계산하는 공식은 다음과 같습니다.

\[충돌률 = N * \frac{UR^2}{S}*RL\]

• N: 동일한 이름의 캐시를 사용하는 서비스 인스턴스 수
• UR: 밀리초 당 업데이트 율
• S: 캐시 크기(로우 개수)
• RL: 캐시 제품의 복제 대기 시간

15.3 클라우드 대 온프레미스 구현

공간 기반 아키텍처는 배포 환경 측면에서 독자적인 선택지가 있습니다. 처리 장치, 가상 미들웨어, 데이터 펌프, 데이터 리더/라이터, 데이터베이스 등 전체 토폴로지는 클라우드 기반의 환경이나 온프레미스(’온프렘’)에 배포할 수 있습니다. 하지만 이 두 환경 사이에 어중간하게 배포할 수도 있는데, 이것이 다른 아키텍처 스타일에서는 찾아볼 수 없는 이 아키텍처의 특징입니다.

물리 데이터베이스와 데이터를 온프레미스에 그대로 둔 상태로, 클라우드 기반의 매니지드(managed, 관리형) 환경에서 처리 장치와 가상 미들웨어를 통해 애플리케이션을 배포하는 하이브리드 클라우드가 가능하다는 것이 공간 기반 아키텍처의 강점입니다.

이러한 토폴로지는 트랜잭션은 탄력적인 동적 클라우드 기반의 환경에서 처리하되, 물리적인 데이터 관리, 리포팅, 데이터 분석 데이터는 안전한 로컬 온프레미스 환경에 보관할 수 있습니다.

15.4 복제 캐시 대 분산 캐시

공간 기반 아키텍처는 캐시 기술을 활용하여 애플리케이션 트랜잭션을 처리하고 데이터베이스에 직접 읽기/쓰기를 할 필요가 없어서 확장성, 탄력성, 성능이 우수합니다. 대부분의 공간 기반 아키텍처는 복제 캐시를 사용하지만 분산 캐시도 사용할 수 있습니다.

복제 캐시를 사용할 경우 각 처리 장치는 이름이 동일한 캐시를 사용하는 모든 처리 장치 간에 동기화되는 자체 인메모리 데이터 그리드를 갖고 있습니다. 한 처리 장치에서 캐시가 업데이트되면 다른 처리 장치도 새로운 데이터로 자동 업데이트되는 구조입니다.

복제 캐시는 속도가 매우 빠르고 높은 수준의 내고장성을 지원하며 중앙 서버에서 캐시를 갖고 있는 형태가 아니므로 단일 장애점이 없습니다.

복제 캐시는 공간 기반 아키텍처의 표준 캐시 모델이지만, 데이터량(캐시 크기)이 엄청나게 많거나 캐시 데이터가 너무 빈번하게 업데이트 되는 등 복제 캐시를 사용할 수 없는 경우도 있습니다. 캐시 데이터 업데이트율이 매우 높은 경우에는 모든 처리 장치 인스턴스에서 데이터 일관성이 보장되도록 업데이트로 신속하게 이루어져야 하지만 데이터 그리드가 미처 이 속도를 따라잡지 못할 수도 있습니다. 바로 이럴 때 분산 캐시를 사용하면 도움이 됩니다.

분산 캐시를 구현하려면 중앙 캐시를 갖고 있는 전용 외부 서버 또는 서비스가 필요합니다. 모든 데이터가 한 곳에 있고 복제할 필요가 없으니 분산 캐시는 높은 수준의 데이터 일관성을 보장하지만, 캐시 데이터를 원격에서 가져와야 하므로 복제 캐시보다 성능이 낮고 시스템 전체 레이턴시가 증가합니다. 내고장성도 문제입니다. 데이터를 갖고 있는 캐시 서버가 다운되면 처리 장치에서 데이터를 액세스, 업데이트할 수 없기 때문에 모든 작동이 중단됩니다. 분산 캐시를 미러링하면 어느 정도 내고장성을 확보할 수 있지만, 예기치 않게 메인 캐시 서버가 다운되고 데이터가 미러링된 캐시 서버로 제때 이동하지 못하면 일관성에 문제가 생길 것입니다.

캐시 크기가 비교적 작고(100MB 미만) 캐시 업데이트율이 낮은 편이라서 캐시 제품의 복제 엔진이 캐시 업데이트를 충분히 따라올 수 있다면, 복제 캐시냐 분산 캐시냐의 선택은 결국 데이터 일관성이냐, 성능/내고장성이냐의 문제입니다.

공간 기반 아키텍처에서 캐시 모델을 선정할 때에는 애플리케이션 전체적으로 일관된 단일 캐시 모델을 통해 타협점을 모색하되 각 모델의 장점을 최대한 활용해야 합니다.

15.5 니어 캐시

니어 캐시(near-cache, 준캐시)는 분산 캐시와 인메모리 데이터 그리드를 접합한 이종의 하이브리드 캐시 모델입니다. 이 모델에서 분산 캐시는 풀 백킹 캐시(full backing cache), 각 처리 장치에 포함된 인메모리 데이터 그리드는 프런트 캐시(front cache)라고 합니다. 프론트 캐시는 항상 풀 백킹 캐시보다 작은 서브세트를 담고 있고, 방출 정책(eviction policy)를 통해 옛 항목을 삭제한 다음 최근 항목을 추가합니다.

프런트 캐시는 항상 풀 백킹 캐시와 동기화 되지만 각 처리 장치에 포함된 프런트 캐시는 동일한 데이터를 공유하는 다른 처리 장치와 동기화되지 않습니다. 즉, 처리 장치마다 상이한 데이터를 프론트 캐시에 갖게 되고 처리 장치 간 성능과 응답성의 일관성이 결여됩니다.

15.6 구현 예시

공간 기반 아키텍처는 유저 수나 요청량이 갑자기 폭증하는 애플리케이션이나 10,000명이 넘는 동시 유저를 처리해야 하는 종류의 애플리케이션에 적합합니다.

15.6.1 콘서트 티켓 판매 시스템

15.6.2 온라인 경매 시스템

15.7 아키텍처 특성 등급

공간 기반 아키텍처는 탄력성, 확장성, 성능의 끝판왕입니다. 이 아키텍처는 인메모리 데이터 캐시를 활용하고 제약조건에 해당된느 데이터베이스를 없앴기 때문에 이 세가지 특성을 높은 수준으로 달성할 수 있습니다.

이 아키텍처의 탄력성, 확장성, 성능은 주요 강점으로 꼽히지만, 전체적인 단순성과 시험성 측면에서는 트레이드오프가 있습니다. 공간 기반 아키텍처는 주요 데이터 저장소에서 캐시를 사용하고 최종 일관성이라는 개념을 적용하기 때문에 구조가 매우 복잡한 아키텍처 입니다.

요약

15.1 토폴로지

• 튜플 공간에서 유래된 아키텍처 스타일로, 공유 메모리를 통해 다중 프로세서 간 통신을 수행함.
• 중앙 데이터베이스를 제거하고, 복제된 인메모리 데이터 그리드를 활용하여 확장성, 탄력성, 성능을 향상시킴.
• 구성 요소: 처리 장치, 가상 미들웨어, 데이터 펌프, 데이터 라이터, 데이터 리더.

15.1.1 처리 장치

• 애플리케이션 로직을 담고 있는 유닛.
• 데이터를 업데이트하고, 메시지를 통해 비동기적으로 데이터베이스에 전송함.

15.1.2 가상 미들웨어

• 데이터 동기화 및 요청 처리를 제어하는 인프라.
• 구성 요소:
  • 메시징 그리드: 입력 요청과 세션 상태를 관리하며, 요청을 적절한 처리 장치로 라우팅함.
  • 데이터 그리드: 처리 장치 간 데이터 동기화를 담당하는 복제 캐시.
  • 처리 그리드: 다수의 처리 장치가 단일 요청을 처리할 때 오케스트레이션을 수행함.
  • 배포 관리자: 부하에 따라 처리 장치를 동적으로 시작하거나 종료함.

15.1.3 데이터 펌프

• 데이터를 다른 프로세서에 보내 데이터베이스를 업데이트하는 역할.
• 도메인이나 서브도메인별로 여러 개를 사용하여 효율적인 데이터 전송을 수행함.

15.1.4 데이터 라이터

• 데이터 펌프에서 받은 메시지를 기반으로 데이터베이스를 업데이트.
• 도메인 기반으로 구성되며, 필요한 모든 데이터베이스 로직을 포함함.

15.1.5 데이터 리더

• 데이터베이스에서 데이터를 읽어 처리 장치로 전달하는 컴포넌트.
• 다음 세 가지 경우에 작동함:
  • 모든 처리 장치 인스턴스가 실패한 경우.
  • 처리 장치가 재배포되는 경우.
  • 아카이브 데이터를 조회하는 경우.

15.2 데이터 충돌

• 복제 캐시 사용 시 데이터 충돌 가능성 존재.
• 데이터 충돌은 복제 레이턴시로 인해 발생하며, 데이터 일관성에 영향을 미칠 수 있음.
• 충돌률 계산 공식:
  • 충돌률 = N × (UR² / S) × RL
    • N: 동일한 캐시를 사용하는 서비스 인스턴스 수
    • UR: 밀리초당 업데이트율
    • S: 캐시 크기(로우 개수)
    • RL: 복제 대기 시간

15.3 클라우드 대 온프레미스 구현

• 클라우드와 온프레미스 환경 모두에 배포 가능.
• 하이브리드 클라우드 구현: 처리 장치와 가상 미들웨어는 클라우드에서, 데이터는 온프레미스에 보관하여 보안과 성능을 모두 충족함.

15.4 복제 캐시 대 분산 캐시

• 복제 캐시:
  • 각 처리 장치가 자체 인메모리 데이터 그리드를 보유.
  • 높은 성능과 내고장성, 단일 장애점 없음.
• 분산 캐시:
  • 중앙 캐시 서버 사용.
  • 데이터 일관성은 높지만, 성능 저하와 내고장성 문제 발생 가능.

15.5 니어 캐시

• 분산 캐시와 인메모리 데이터 그리드를 결합한 하이브리드 캐시 모델.
• 구성:
  • 풀 백킹 캐시: 중앙의 분산 캐시.
  • 프론트 캐시: 각 처리 장치에 포함된 인메모리 캐시로, 최근 데이터를 보관함.
• 처리 장치 간 성능과 응답성의 일관성이 부족할 수 있음.

15.6 구현 예시

15.6.1 콘서트 티켓 판매 시스템

• 동시 접속자가 매우 많은 시스템에서 공간 기반 아키텍처 활용.
• 급격한 트래픽 증가에도 안정적인 서비스 제공 가능.

15.6.2 온라인 경매 시스템

• 유저 수와 요청량이 급증하는 애플리케이션에 적합.
• 실시간 경매 상황에서도 높은 확장성과 성능 유지.

15.7 아키텍처 특성 등급

• 장점:
  • 탄력성, 확장성, 성능에서 최고 수준의 등급을 보임.
  • 인메모리 데이터 캐시 활용과 데이터베이스 제거로 우수한 성능 달성.
• 단점:
  • 단순성과 시험성은 낮은 편으로, 구조의 복잡성이 높음.
  • 복잡한 아키텍처로 인해 관리와 테스트에 어려움이 있을 수 있음.