Cell-based Architecture에 대해 알아보자
배경
Micro Service Architecture가 등장하면서 작은 단위의 서비스들을 독립적으로 배포하고 확장할 수 있게 되었기 때문에 특정 서비스에 문제가 발생해도 전체 시스템이 영향을 받지 않을 수 있었다.
예를 들어, youtube에서 영상 추천 서비스에 장애가 발생해도 영상 검색/재생 서비스는 계속 동작할 수 있다.
MSA를 통해 단일 장애점(Single Point of Failure)을 최소화할 수 있었지만 글로벌 서비스를 제공하는 기업들은 더 높은 가용성과 복원력, 유연한 확장성을 필요로 했고 새로운 아키텍쳐를 고민하기 시작했다. 🤔
어떻게 설계하면 될까
선박은 구멍이 나도 침수가 번지지 않도록 하기 위해 격벽(bulkhead)을 통해 수직으로 구획을 분할한다. 각 구획 사이에 위치한 격벽은 구획을 완전히 격리시키는데, 이로 인해 특정 구획에 물이 새더라도 다른 구획으로 침수가 번지지 않을 수 있다.
Cell-based Architecture
격벽 구조를 Micro Service Architecture로 가져온 것이 바로 Cell-based Architecture이다. 선박의 각 구획은 Cell로 표현되고, Cell에는 독립적인 Micro Service 그룹이 운영된다. 그래서 특정 Cell에 장애가 발생해도 Cell들은 각각 격리되어 있기 때문에 장애가 확산되지 않는다.
어떤 애플리케이션이 AWS ECS에 올라가고, 저장소로는 DynamoDB를 사용한다고 가정해보자:
- Cell은 모든 애플리케이션 구성요소를 포함한다
- ALB: ECS에 위치한 애플리케이션을 로드밸런싱한다
- ECS: 애플리케이션
- DynamoDB: 저장소
- CloudWatch: Cell의 상태를 모니터링하고 알림을 받기 위함이다
독립적인 Cell이 N개가 존재한다면 사용자는 어떤 Cell에 요청을 보내서 응답을 받을 수 있을까?
- Routing Layer
- 사용자의 요청을 받아 Cell로 요청을 redirect해준다
- 사용자 경험의 연속성을 보장하기 위해 사용자별 Cell 매핑 정보를 저장하고 있다
- Cell Rebalancer
- 특정 Cell에 장애가 발생했을 때 다른 Cell로 요청을 전달하기 위해 사용자별 Cell 매핑 정보를 업데이트한다
Cell-based Architecture에는 다음과 같은 부가적인 요소들도 필요할 것이다:
- Monitoring Tool: 모든 Cell의 상태를 모니터링할 수 있는 중앙 대시보드
- Deployment Pipeline: Cell별로 배포할 수 있는 배포 파이프라인 (카나리아 배포 및 롤백이 용이하다)
- Central Analytics: Cell에서 발생하는 데이터 변경사항들이 스트리밍되어 저장되는 공간. 전체 Cell의 데이터를 통합해서 분석하고 데이터 기반 의사결정에 활용할 수 있다
정리해보자
1. 사용자는 Routing Layer로 요청을 보낸다
2. Routing Layer는 사용자별 Cell 매핑정보를 확인하고 사용자 요청을 Cell로 redirect 한다
3. 사용자는 Cell로부터 요청에 대한 응답을 받는다
4. 사용자 요청은 CloudWatch에 기록되어 모니터링된다
5. 모든 Cell에서 발생한 요청/오류는 중앙 대시보드에서 확인할 수 있다
6. 중앙 대시보드로부터 Cell이 장애가 발생했다는 걸 확인하거나, 애플리케이션 배포가 필요하면 Deployment Pipeline을 통해 새로운 Cell을 배포할 수 있다
7. Cell에서 발생한 데이터 변경사항들은 중앙 Data Lake로 스트리밍되어 저체 Cell의 데이터를 분석할 수 있다
참고자료
