Cell-based Architecture

셀 기반 아키텍처(Cell-based Architecture)^[각주:1]는 선박을 구성하는 격벽(Bulkhead)^[각주:2] 컨셉으로부터 왔다. 격벽은 선박, 또는 항공기 내부에 세우는 수직 벽인데, 선박 손상 시 바닷물 침수 범위를 줄이고 선체에 추가적인 강성을 제공하는 목적을 갖고 있다. 비행기의 경우, 감압을 버텨내는 역할을 하며 비행 도중에 파손된다면 정상적인 운항은 불가능하게 된다. 같은 원리를 착안한 셀 기반 아키텍처는 장애가 더 전파되지 않도록 격리(Fault-isolation)하기 위해서, 서비스를 더 작은 단위로 나누고 세밀하게 관리하는 아키텍처다.^[각주:3]

By Andy Dingley (scanner) - Scan from by Authority of the Lords Commissioners of the Admiralty (June 1943) A Seaman's Pocket-Book, London: HMSO, pp. p. 11,fig. 9, Public Domain, https://commons.wikimedia.org/w/index.php?curid=110882274

 
서비스 개발 초기에는 많은 기능을 하나의 서버에 담는 방법이 함수간 통신, 라이브러리 호출 등에서 많은 장점이 있다. 하지만 서비스의 규모가 커지고 조직이 커지면, 조직간 소통 비용 및 배포 의존성, 광범위한 데이터 관리 범위, 의존성으로 인한 장애 여파 등의 문제로 인해 소프트웨어 개발과 개선 효율이 떨어지는 문제가 생긴다. 이를 해결하기 위해 마이크로서비스 아키텍처(Microservices Architecture)^[각주:4], 이벤트 기반 아키텍처(Event-Driven Architecture) 등이 등장해서 대규모 분산 시스템이 유기적으로 잘 동작하도록 만들어 왔다. 이러한 시도들은 많은 문제들을 해결해왔고 충분히 안정적이라고 할 수 있다. 셀 기반 아키텍처는 여기에 장애 격리라는 장점을 추가하였다.
 
장애는 다양한 원인으로 발생할 수 있다. 하드웨어에 문제가 생길 수도 있고, 정상적인 사용이든 악의적인 공격이든 갑작스럽게 네트워크에 트래픽이 몰려서 서비스가 불가능해 질 수도 있다. 소프트웨어 버그로 인해서 메모리 누수가 생기거나 기능이 오동작할 수도 있다. 충분한 검증을 거치지 않은 소프트웨어가 문제를 일으킬 수도 있고, 운영자가 실수로 설정을 잘못 변경할 수도 있다. 이러한 장애에 내성이 있는(Fault-tolerant) 시스템을 구성하기 위한 전략들이 있었다. 먼저 가상화와 하드웨어 다중 구성을 통해 하드웨어로 인한 문제를 해결했다. AWS의 기준으로 본다면 EC2(Elastic Cloud Compute)를 통해 서버 단위의 장애 복구를 가능하게 했고, 가용 영역(Availability Zone)^[각주:5]을 통해 데이터센터 단위의 장애에 대해 대응할 수 있도록 했다.
 
다음으로, 트래픽으로 인한 장애를 대비하기 위해 안전 장치들을 구성해서 해결했다. AWS 기준으로는 각 서비스는 세분화된 API(Application Programming Interface)를 통해 기능을 제공하고 있으며, 각 API는 스트레스 테스트(Stress Test)^[각주:6]를 통해 얻은 값을 기준으로 스스로를 보호하기 위해 Rate Limiting과 Throttling을 설정하여 과도한 요청에 대응하고 있다. 또한, Sheild 서비스처럼 악의적인 공격을 식별해서 자동으로 차단하는 기능을 구성해서 제공하고 있고, 방화벽 설정을 통한 규칙기반 네트워크 통제를 하고 있다.
 
다음으로, 소프트웨어 변경으로 인해 발생한 문제들을 해결하기 위해 자동화된 절차를 통한 관리와 위험 요소 최소화를 위한 배포 전략을 활용해왔다. 소프트웨어가 완벽하게 문제가 없다고 장담할 수는 없다. 하지만 우리는 QA(Qualtiy Assurance)를 통해 품질에 대한 자신감을 가질 수 있다. 이 과정은 장기적 관점에서 접근해야 하고 지루한 절차이지만, 매우 중요한 과정이다. 버전 관리^[각주:7], 테스트 자동화, 인프라스트럭처 코드^[각주:8], 베타 테스트, 프리뷰(Preview), 블루/그린 배포(Blue/Green Deployment), 카나리 배포(Canary Release)등의 방법들도 고객 만족을 위해 서비스 품질을 높이는 QA의 일환이라고 할 수 있다.^{[각주:9] [각주:10]}

하지만, 여전히 사람의 실수로 인해서 문제가 생길 수 있다. 또한, 미처 생각하지 못해서 테스트에 반영하지 못했던 문제가 발생할 수 있다. 셀 기반 아키텍처는 앞 서 언급한 많은 시도와 해결책에 더해 하드웨어로 인한 장애, 소프트웨어 버그로 인한 장애, 사람의 실수로 인한 장애 등 다양한 원인으로 인한 장애가 발생하더라도 특정 셀 범위 안에서만 허용하도록 만들어 준다. 1/ 셀 단위로 롤링아웃(Rolling-out)을 하기때문에 문제가 있는 코드는 셀 안에서만 발생한다. 2/ 운영자의 실수가 있다 하더라도 전면 적용이 아닌 셀 단위 적용이기 때문에 장애로 인한 고객 영향 범위가 셀로 한정된다. 3/ 트래픽이 몰려 들더라도 셀을 늘려가면서 대응할 수 있다. 4/ 특정 사용자의 과도한 자원 점유로 인해 같은 자원을 공유하는 다른 사용자에게 영향을 끼치는 경우^[각주:11]라도 범위를 셀로 한정시킬 수 있다. 5/ 가용 영역을 넘어서 데이터를 복제할 경우에도 비교적 적은 크기의 셀 단위로 동작하기 때문에 고가용성 확보에 유리하다.

Cell-based Architecture (https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/)

 

먼저 클라이언트는 라우팅 레이어(Routing Layer)에 접속한다. 여기서 클라이언트는 HTTP 재전송(Redirection)을 이용해서 할당받은 셀로 연결된다. 어떤 셀로 연결시킬 지 (예를 들어 사용자-셀 연동 정보)는 Amazon DynamoDB에 저장한다. 대규모 트래픽의 처리와 데이터 저장을 위해 수평 확장이 가능하고, 셀 연동 정보를 동시 다발적으로 저장하거나 조회할 수 있는 데이터베이스가 필요하다. 데이터 사본을 저장하는 고정된 수의 독립 클러스터가 존재하며, 새로운 사용자의 경우 셀 라우터는 새 사용자 정보를 모든 클러스터에 기록한다. 라우팅을 통해 할당된 셀은 고정된 크기의 수 많은 독립된 셀이다. 셀에는 모든 기능을 수행하기 위한 애플리케이션과 스토리지가 포함되어 있다.

 

각 셀은 Amazon CloudWatch와 같은 중앙집중식 관측(Observability) 도구를 사용해서 상태를 측정한다. 중앙 집중식 대시보드에서는 오류가 있는 셀과 없는 셀의 수와 같은 정보를 수집한다. 만약, 문제를 감지했다면 경고 알림을 발생해서 자동 대응 또는 수동 대응^[각주:12]할 수 있도록 구성한다. 각 셀의 생성 및 변경 관리는 자동화를 통해서 관리하며, 인프라스트럭처 코드, 배포 파이프라인, 오케스트레이션 도구를 사용한다. 셀의 변경이 필요한 경우 카나리 셀에 먼저 배포하고, 문제가 없다면 가용 영역 단위로 롤 아웃 배포를 수행하여 고객 영향을 최소화 한다. 비슷한 방식으로 셀에 대한 재해 복구(Disaster Recovery)를 자동화 한다. 셀 관리 자동화를 위해 Amazon StepFuntions, AWS CloudFormation 등의 관리형 서비스를 사용할 수도 있으며, Terraform, ArgoCD 등의 조합을 활용할 수 있다.

 

모든 셀의 변경 내역은 중앙에서 관리하는 데이터 레이크(Data Lake)로 전송해서 분석할 수 있으며, 목적에 따라 분석 도구를 선택해서 활용할 수 있다. 비정형 대규모 데이터 분석을 위해 Apache Spark을 활용할 수도 있고, RedShift Spectrum을 활용해서 데이터웨어하우스와 통합 분석을 할 수도 있다. 간단하게는 Amazon Athena를 사용해서 비정형 데이터에 대해 SQL을 수행해서 분석을 수행할 수도 있다. 하지만, 데이터 분석은 데이터 버전 관리같은 데이터 엔지니어링 영역도 필요하기 때문에 실제 구성은 더 복잡하다. 데이터메시(Data Mesh)와 같은 아키텍처를 도입할 수 있지만, 셀 기반 아키텍처에서는 자세하게 다루지 않는다.

 

마지막으로 셀에서 사용자(또는 셀에서 데이터를 관리하는 기준과 그에 따른 정보들)를 다른 셀로 이동하거나 필요에 따라 신규 셀을 생성하고 데이터를 재배치해야 할 수도 있다. 데이터 이동을 처리하기 위한 리발란서(Rebalancer)는 데이터를 이동하고, 셀 할당 정보를 갱신한다. 이 전에 사용하던 셀은 클라이언트를 새 셀로 리다이렉션 하는 마커를 유지하여 셀 사이의 데이터 이동이 매끄럽게 동작하도록 한다.

 

수 억개의 기계가 연결되어 있는 푸시서비스를 구성하는 방법도 비슷하다. 수 많은 기계가 연동되어 있는 사물인터넷(Internet of Things, IoT)도 비슷한 구성을 갖고 있다. 수 천개에서 수 억개 이상의 통신 연결을 유지해야 한다는 공통적인 요구사항이 있는데, 이를 해결하기 위해서 크게 2가지가 필요하다. 연결 설정 신규 또는 재요청을 받아서 서버에 할당하는 연결 설정 관리 기능과 실제 연결을 맺고 통신을 주고 받는 기능이다. 물론, 실제 시스템을 설계할 때는 보안, 인증, 인가, 관측, 자동 복구 등 더 복잡하고 세부적인 기능이 필요하다.
 
셀 기반 아키텍처는 장애의 여파를 줄이는 것에 목적을 두고 있기 때문에, 여전히, 사용자 실수로 인한 장애를 원천적으로 방지하기에는 한계가 있다. 이 부분은 사후 절차를 통해 지속적으로 개선하는 방법을 통해 해결해야 한다.^{[각주:13] [각주:14]}  

---

 

1. Guidance for Cell-Based Architecture on AWS [본문으로]
2. Bulkhead_(partition)_ Wikipedia [본문으로]
3. Amazon EBS(Elastic Block Store) 서비스를 운영하면서, 모든 사용자가 같은 순간에 서비스를 필요로 하지 않을 수 있다는 것을 발견했다고 한다. 특히 실패를 격리해 둔 경우라면, 특정 정보를 필요로 하는 사람과 해당 정보를 가진 시스템이 동시에 문제가 생길 가능성은 희박해 진다. [본문으로]
4. Microservices, and Hangul(한글) [본문으로]
5. 가용 영역은 1개 이상의 데이터 센터로 구성되어 있으며, 여러 가용 영역은 지진 등의 물리적인 장애 상황의 여파가 영향을 끼칠 수 없을 정도의 거리만큼 떨어져 있지만, 서비스에 영향을 주지 않을 만큼 단일 밀리초 수준의 빠른 통신망으로 연결되어 있다. [본문으로]
6. Stress Test [본문으로]
7. Version Control System [본문으로]
8. Terraform [본문으로]
9. Continuous Delivery [본문으로]
10. CI/CD Pipeline [본문으로]
11. Noisy Neighborhood [본문으로]
12. Runbook [본문으로]
13. Correction of Error (CoE) [본문으로]
14. Poka-yoke [본문으로]