Cell-Based Architecture: 왜 우리는 항상 위험과 실패를 완화하려고 하는가
Source: Dev.to
개요
Cell‑Based Architecture는 아직 많이 논의되지 않은 패턴입니다. 동일한 시스템의 인스턴스를 확장하는 대신, 전체 스택을 독립적인 유닛인 cells 로 복제합니다. 각 cell은 사용자 기반의 하위 집합을 담당하며, 자율적으로 운영하는 데 필요한 모든 것을 포함합니다.
마이크로서비스를 수평으로 확장할 때 일반적으로 다음과 같이 합니다:
- 단일 배포 → 버그 하나가 전체 시스템을 다운시킬 수 있습니다.
- 트래픽이 많은 고객 → 모든 사용자의 경험이 저하됩니다 (소위 noisy neighbor).
- 연쇄 장애 → 시스템 전체에 퍼집니다.
수평 확장은 용량 문제는 해결하지만 격리 문제는 해결하지 못합니다.
Cell‑Based Architecture의 장점
1. 장애 범위 제한
Cell 2가 실패하면 1 M~2 M 사이의 사용자만 영향을 받습니다. 나머지는 정상적으로 운영됩니다.
2. noisy neighbor 격리
수백만 건의 요청을 하루에 보내는 기업 고객이 다른 cell에 영향을 주지 못합니다.
3. 자연스러운 카나리 배포
- Cell 1에 배포.
- 약 30분 동안 모니터링.
- 모두 정상이면 나머지 cell에 순차적으로 배포.
복잡한 feature flag가 필요 없으며, 롤백은 한 cell에만 영향을 주기 때문에 간단합니다.
4. 지역별 규정 준수 및 격리
유럽 고객 데이터가 유럽에 머물러야 한다면? 지역별 cell이 구조적으로 이를 해결합니다, 별도의 설정 레이어가 아니라.
Cell Router
유일하게 전역적인 컴포넌트입니다. 요청을 받아 tenant_id → cell_id 매핑을 저장한 가벼운 스토어를 조회하고 올바른 cell로 라우팅합니다:
Request
|
v
Cell Router --> Cell N하지만 이것이 단순히 샤딩인가요?
그렇지는 않습니다. 샤딩은 데이터베이스 파티션 전략이며, Cell‑Based Architecture는 애플리케이션 로직, 캐시 레이어, 워커 등도 격리합니다.
운영상의 도전 과제
- 데이터 집계: 모든 cell의 정보를 결합해야 하는 쿼리는 여러 데이터베이스에 접근해야 하며, 파이프라인 복잡도와 일관성 보장이 어려워집니다.
- cell 과부하: 특정 cell에 예상보다 많은 트래픽이 몰리면, 사용자 마이그레이션이나 다운타임 없이 확장이 복잡합니다. 데이터 재분배는 신중한 계획과 안전한 마이그레이션 메커니즘이 필요합니다.
- 스키마 버전 관리: 스키마, 인덱스, 프로시저 변경을 모든 N개의 데이터베이스에 적용해야 합니다. 이를 위해 자동화, 버전 관리 전략, 점진적 롤아웃이 필요합니다.
요약하면, Cell‑Based Architecture는 견고하고 확장 가능한 솔루션을 제공하지만 새로운 운영상의 도전 과제를 동반합니다. 모든 아키텍처 결정은 일부 문제를 해결하고, 필연적으로 다른 문제를 야기하며, 이를 관리해야 합니다.