Space Based Architecture

Space Based Architecture

---

공간 기반 아키텍처는 확장성과 탄력성, 동시성의 문제를 해결하기 위해 등장한 아키텍처입니다. 많은 웹 기반 애플리케이션은 보통 웹 서버(NGINX), 애플리케이션 서버, 데이터베이스 서버로 구성되어 있으며 하나의 요청은 이 순서대로 도달하게 됩니다. 이때 사용자가 많지 않으면 별 문제가 발생하지 않지만 사용자가 증가함에 따라 병목 현상이 발생하게 됩니다. 

병목 현상의 일반적인 해결 방법은 웹 서버를 확장하고 이후 애플리케이션 서버, 데이터베이스 서버 순으로 확장할 수 있지만 뒤로 갈수록 확장하는데 비용도 많이 들고 점차 복잡해져 갑니다. 그리고 최종적으로 데이터베이스의 동시 처리 가능한 트랜잭션 수가 최종 제약조건이 되는 경우가 많습니다.

 

확장 구조

 

토폴로지

---

공간 기반 아키텍처라는 명칭은 튜플 공간에서 유래되었습니다. 튜플 공간은 공유 메모리를 통해 통신하는 다중 병렬 프로세스를 사용하는 기술입니다. 시스템에서 동기 제약조건인 데이터베이스를 없애는 대신 복제된 인메모리 데이터 그리드를 활용하면 확장성, 탄력성, 성능을 높일 수 있습니다. 애플리케이션 데이터는 메모리에 둔 상태로 모든 활성 애플리케이션에 데이터를 복제합니다. 애플리케이션은 데이터를 업데이트할 때 큐에 메시지를 보내서 비동기로 데이터베이스를 업데이트합니다. 또한 애플리케이션은 사용자의 수에 따라 가변적으로 시작/종료할 수 있습니다.

 

 

Space Based Architecture의 구조

---

공간 기반 아키텍처의 구조는 애플리케이션 코드가 구현된 처리 장치, 처리 장치를 관리/조정하는 가상 미들웨어, 업데이트된 데이터를 데이터베이스에 비동기로 전송하는 데이터 펌프, 데이터 펌프에서 데이터를 받아 업데이트를 수행하는 데이터 라이터, 처리 장치가 시작되자마자 데이터베이스의 데이터를 읽어 전달하는 데이터 리더로 구성되어 있습니다.

 

Space Based Architecture 구조

💡 처리 장치

 

• 처리 장치는 애플리케이션의 로직을 가지고 있습니다. 보통 웹 기반 컴포넌트와 백엔드 비즈니스 로직이 포함되어 있고 애플리케이션의 크기에 따라 레이어드 구조 및 마이크로 서비스 구조로 구성할 수 있습니다. 
• 애플리케이션 로직 외에도 헤이즐캐스트, 아파치 이그나이트 등의 제품에 있는 인메모리 데이터 그리드 및 복제 엔진도 포함됩니다.

 

💡 가상 미들웨어

 

• 가상 미들웨어는 아키텍처 내부에서 데이터 동기화 및 요청 처리의 다양한 부분을 제어하는 인프라를 담당합니다. 여기에는 메시징 그리드, 데이터 그리드, 처리 그리드, 배포 관리자가 포함됩니다.

 

메시징 그리드

 

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

데이터 그리드

 

• 데이터 그리드는 아키텍처에서 가장 중요한 부분입니다.
• 데이터 그리드는 각 처리 장치의 데이터 복제 엔진과 상호 작용하여 데이터 업데이트 이벤트가 발생할 때 처리 장치 간의 데이터 복제를 관리합니다. 
• 메시징 그리드는 가용한 모든 처리 장치에 요청을 전달할 수 있으므로 각 처리 장치는 자신의 인메모리 데이터 그리드에 정확히 동일한 데이터를 가지고 있어야 합니다.

처리 그리드

 

• 처리 그리드는 애플리케이션의 일부를 처리하는 여러 처리 장치가 있을 때 분산 요청 처리를 관리하는 역할을 수행합니다. 
• 예시로 주문 처리 장치와 고객 처리 장치 간의 조율이 필요한 요청이 들어온 경우 두 처리 장치 간의 요청을 중재하고 조율하는 역할을 합니다.

배포 관리자

 

• 배포 관리자는 부하 조건에 따라 처리 장치 인스턴스를 동적으로 시작/종료하는 컴포넌트입니다.

 

💡 데이터 펌프

 

• 데이터 펌프는 데이터를 다른 프로세스에 보내 데이터베이스를 업데이트 하는 장치입니다. 
• 공간 기반 아키텍처에서는 처리 장치가 데이터를 데이터베이스에서 직접 읽고 쓰지 않으므로 데이터 펌프는 필수입니다.
• 데이터 펌프는 항상 비동기로 동작하면서 메모리 캐시와 데이터베이스의 최종 일관성을 실현합니다.
• 공간 기반 아키텍처에서 메시징은 데이터 펌프를 구현하는데 효과적인 방법이고, 메시징은 비동기 통신을 지원하고 전달을 보장하며, FIFO 큐를 통해 순서도 유지할 수 있습니다.

 

💡 데이터 라이터

 

• 데이터 라이터는 데이터 펌프에서 메시지를 받아 그에 맞는 데이터베이스를 업데이트하는 컴포넌트입니다.
• 데이터 라이터는 도메인마다 또는 처리 장치 클래스마다 자체 전용 데이터 라이터를 가질 수 있습니다.

💡 데이터 리더

 

• 데이터 리더는 데이터베이스에서 데이터를 읽어 데이터 펌프를 통해 처리 장치로 실어 나르는 컴포넌트입니다. 

데이터 리더가 동작되는 경우

 

1. 동일한 이름의 캐시를 가진 모든 처리 장치 인스턴스가 실패하는 경우입니다.
2. 동일한 이름의 캐시 안에서 모든 처리 장치를 재배포하는 경우입니다.
3. 복제 캐시에 들어있지 않은 아카이브 데이터를 조회하는 경우입니다.

 

 

데이터 충돌

---

이름이 동일한 캐시가 포함된 애플리케이션에서 업데이트가 발생하는 active/active 상태에서 복제 캐시를 사용하면 복제 레이턴시 때문에 데이터 충돌이 발생할 수 있습니다.  

 

상황

 

1. 노트북의 재고는 100개입니다.
2. 애플리케이션 A는 노트북의 재고 캐시를 90(10개 판매)로 업데이트합니다.
3. 캐시를 복제하는 동안 애플리케이션 B는 노트북의 재고 캐시를 85(15개 판매)로 업데이트합니다.
4. 애플리케이션 A의 데이터를 애플리케이션 B로 복제했기 때문에 애플리케이션 B의 노트북 재고 캐시는 90개입니다.
5. 애플리케이션 B의 데이터를 애플리케이션 A로 복제했기 때문에 애플리케이션 A의 노트북 재고 캐시는 85개입니다.
6. 애플리케이션 A, B 두 캐시 값이 동일하지 않아 동기화가 어긋납니다. (노트북 재고는 75개가 되어야 함)

 

 

복제 캐시 vs 분산 캐시

---

공간 기반 아키텍처는 캐시 기술을 사용하여 애플리케이션 트랜잭션을 처리하고 데이터베이스에서 직접 읽기/쓰기를 할 필요가 없으므로 확장성, 탄력성, 성능이 좋습니다. 캐시 기술에는 복제 캐시와 분산 캐시를 사용할 수 있습니다. 또한 캐시 모델을 선정할 때 아래 두 모델을 모두 적용할 수 있습니다.

 

💡 복제 캐시

 

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

 

장점

 

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

단점

 

• 복제 캐시는 공간 기반 아키텍처의 표준 캐시 모델이지만 캐시의 크기가 큰 경우나 캐시 데이터가 너무 빈번히 업데이트되는 등 복제 캐시를 사용할 수 없는 경우도 있습니다. 또한 복제 캐시의 공간은 애플리케이션의 메모리에 따라 달라집니다. 
• 캐시 데이터 업데이트율이 매우 높은 경우 모든 처리 장치 인스턴스에서 데이터 일관성이 보장되도록 업데이트되어야 하지만 데이터 그리드가 이 속도를 못 따라갈 수 있습니다. 따라서 이럴 때 분산 캐시를 사용해야 합니다.

복제 캐시 구조

💡 분산 캐시

 

• 분산 캐시를 사용하면 중앙 캐시를 가지고 있는 전용 외부 서비스(Redis)가 필요합니다. 처리 장치는 인메모리 데이터 그리드를 가지고 있는 대신 전용 프로토콜을 통해 전용 캐시 서버에 접근합니다. 

장점

 

• 모든 데이터가 한 곳에 있으므로 데이터의 일관성을 보장할 수 있습니다. 

단점

 

• 캐시 데이터를 원격에서 가져와야 하므로 복제 캐시보다는 성능이 낮고 레이턴시가 증가합니다.
• 데이터를 가지고 있는 캐시 서버가 다운되면 모든 처리 장치의 작동이 중단되므로 문제가 있지만 클러스트링을 사용하면 괜찮지 않을까 생각합니다.

분산 캐시 구조

 

 

니어 캐시

---

니어 캐시는 분산 캐시와 처리 장치의 인메모리 데이터 그리드를 합친 하이브리드 캐시 모델입니다. 분산 캐시는 풀 백킹 캐시이고 각 처리 장치에 포함된 인메모리 데이터 그리드는 프런트 캐시라 합니다. 프런트 캐시는 항상 풀 백킹 캐시보다 작은 서브세트를 담고 있고, 방출 정책을 통해 예전의 항목을 삭제합니다.(MRU, MFU, RR 등의 알고리즘)

 

프런트 캐시는 항상 풀 백킹 캐시와 동기화되지만 각 처리 장치에 포함된 프런트 캐시는 동일한 데이터를 공유하는 다른 처리 장치와 동기화 되지 않습니다. 따라서 동일한 데이터 콘텍스트를 공유하는 여러 처리 장치가 동일하지 않은 데이터를 각자의 프런트 캐시로 소유하고 있을 수 있습니다. 따라서 데이터 일관성이 떨어질 수 있습니다.

 

니어 캐시 구조

 

 

 

 

 

참고

• https://medium.com/the-pragmatic-tech-review/understanding-space-based-architecture-15281953c24c
• https://medium.com/nerd-for-tech/is-space-based-pattern-only-for-cloud-based-hosted-5a633eb74c2
• https://umairsaeed.com/space-based-architecture/