트래픽이 커진 서비스에서 가장 비싼 장애는 “모두가 동시에 영향을 받는 장애"입니다. DB 한 클러스터, 공용 캐시 한 군데, 전역 메시지 큐 한 묶음으로 운영하면 평소엔 효율적으로 보이지만, 임계 상황에서는 장애 반경이 과도하게 커집니다. 한 컴포넌트의 지연이 전체 API 타임아웃으로 번지고, 다시 재시도 폭증으로 이어져 결국 플랫폼 전체가 흔들립니다.

Cell-Based Architecture는 이 문제를 “성능 최적화"가 아니라 “피해 반경 통제"로 푸는 접근입니다. 핵심은 거대한 공유 리소스를 더 빠르게 만드는 것이 아니라, 실패를 작은 구획에서 멈추게 설계하는 것입니다. 이 글은 셀 아키텍처를 실무에서 도입할 때 필요한 판단 기준, 컷오버 순서, 운영 지표를 중심으로 정리합니다.

이 글에서 얻는 것

  • Cell-Based Architecture가 멀티리전/멀티테넌시와 어떻게 다르고 어떻게 결합되는지 구조적으로 이해할 수 있습니다.
  • “언제 셀 분할을 시작할지"를 감이 아니라 트래픽·장애지표 기반 숫자로 판단할 수 있습니다.
  • 셀 도입 시 가장 자주 실패하는 지점(라우팅, 데이터 경계, 운영 자동화)을 선제적으로 피할 수 있습니다.

핵심 개념/이슈

1) Cell은 리전 분산의 대체가 아니라 장애 반경 제어 레이어다

리전 분산은 지역 단위 가용성을 해결하고, 셀 분할은 같은 리전 안에서 서비스 영향 범위를 줄입니다. 즉 둘 중 하나가 아니라 역할이 다릅니다.

  • 리전 분산: AZ/리전 단위 장애 대응
  • 셀 분할: 애플리케이션/데이터 평면의 부분 장애 격리

예를 들어 ap-northeast-2 리전 하나 안에서도 Cell A/B/C로 분할하면, Cell B에서 락 경합이 폭발해도 Cell A/C의 사용자 경험은 유지할 수 있습니다. 이 기본 구조는 멀티리전 Active-Active 전략을 적용할 때도 운영 복잡도를 낮춰줍니다.

2) 셀 경계는 네트워크가 아니라 “상태 경계"로 정의해야 한다

셀 도입이 실패하는 팀의 공통점은 경계를 LB 규칙 정도로만 잡는 것입니다. 실제로는 아래 3개가 함께 분리돼야 의미가 있습니다.

  1. 연산 경계: 워커/스레드/큐를 셀 단위로 분리
  2. 데이터 경계: DB 스키마 또는 클러스터 접근을 셀 범위로 제한
  3. 운영 경계: 배포/롤백/알람 대응을 셀 단위로 실행

연산만 분리하고 DB를 전역 단일 클러스터로 쓰면, 고부하 셀의 쿼리 폭증이 전체 셀에 영향을 전파합니다. 반대로 DB만 분리하고 공용 큐를 두면 워커 포화가 다시 전체로 퍼집니다.

3) 셀 분할 트리거는 비용이 아니라 “장애 상관도"로 판단한다

셀 도입은 비용이 늘기 때문에 자주 미뤄집니다. 하지만 실무에선 인프라 단가보다 장애 상관도가 더 강한 트리거입니다. 아래 중 2개 이상이면 셀 설계를 본격 검토할 시점입니다.

  • 최근 90일 내 Sev-1/2 장애 중 40% 이상이 공유 리소스(공용 DB·캐시·큐)에서 시작
  • 특정 테넌트/워크로드 급증 시 전체 P99가 2배 이상 동반 상승
  • 장애 복구 평균 시간(MTTR)이 30분을 넘고, 복구 중 전체 트래픽 제한이 반복됨
  • 배포 실패 시 전 사용자 영향이 발생해 롤백이 보수적으로 지연됨

이 판단은 멀티테넌트 격리 전략과 연결해서 봐야 정확합니다. 셀은 테넌트 격리와 별개가 아니라 상호 보완 관계입니다.

4) 라우팅 정책이 셀 아키텍처의 품질을 결정한다

셀 구조를 만들고도 효과를 못 보는 이유는 “어떤 요청을 어느 셀로 보낼지” 규칙이 약하기 때문입니다. 실무에선 아래 우선순위를 권장합니다.

  1. 고정 라우팅(기본값): tenant_id, account_id 해시 기반으로 셀 고정
  2. 정책 라우팅(예외): VIP 고객·규제 데이터는 지정 셀 고정
  3. 비상 라우팅(제한적): 장애 시 읽기 전용·축소 기능으로 임시 우회

중요한 건 비상 라우팅을 “자동 만능 복구"로 기대하지 않는 것입니다. 자동 우회는 셀 간 전이 부하를 만들 수 있어, 전체 포화를 유발할 수 있습니다. 따라서 우회 조건은 숫자로 제한해야 합니다.

  • 우회 허용: cell_error_rate > 5% AND downstream_saturation < 65%
  • 우회 차단: global_p99가 기준의 1.5배 초과 시
  • 우회 TTL: 최대 15분, 이후 운영자 승인 필요

5) 셀별 운영 표준이 없으면 “분할된 단일 장애"가 된다

셀을 도입했는데 온콜 체계가 전역 기준 그대로면, 결국 장애 대응이 다시 중앙 집중으로 돌아갑니다. 최소한 아래 운영 표준은 셀 단위로 가져가야 합니다.

  • 셀별 SLI/SLO, 에러버짓
  • 셀별 배포 파이프라인(카나리·롤백)
  • 셀별 런북과 담당 온콜
  • 셀별 장애 격리 스위치(read-only, write-throttle, job-pause)

운영 문서는 “서비스 전체"가 아니라 “셀 n번에서 무엇을 먼저 끌지"를 10분 이내 실행 가능한 문장으로 작성해야 합니다. 관련 템플릿은 배포 런북과 트래픽 컷오버 플레이북을 참고하면 좋습니다.

실무 적용

1) 도입 우선순위: 코어 경로부터, 셀 개수는 작게 시작

권장 순서는 코어 API 경로 → 상태 저장소 → 배치/비동기 워크로드입니다. 처음부터 모든 서비스를 셀 분할하면 운영 복잡도만 증가합니다.

초기 권장 기준:

  • 셀 개수: 2~3개로 시작
  • 트래픽 분배: 70/30(기존/신규) 또는 80/20 카나리
  • 셀 간 트래픽 이동 상한: 10분 내 15%p 이내
  • 셀별 과부하 보호: 큐 길이 worker x 2 초과 시 즉시 shed

2) 의사결정 기준(숫자·조건·우선순위)

우선순위는 가용성 보호 > 데이터 일관성 경계 > 비용 최적화로 둡니다.

  • 도입 Go 조건
    • 전역 장애의 사용자 영향도가 월 1회 이상 반복
    • 공유 자원 병목으로 P99 튐 현상이 주 2회 이상 발생
    • 셀별 SLO/운영 책임자를 지정할 조직 준비가 완료
  • 도입 Hold 조건
    • 셀별 관측지표 분리가 안 되어 원인 귀속이 불가능
    • 라우팅 키(tenant/account) 품질이 낮아 안정적 고정 라우팅 불가
    • 배포 자동화가 약해 셀 단위 롤백이 10분 내 불가능
  • 확장 조건(2개 셀 → n개 셀)
    • 단일 셀 사용률이 70% 이상으로 4주 지속
    • 장애 전파율(한 셀 장애가 다른 셀로 번진 비율)이 5% 미만으로 안정화

3) 8주 롤아웃 예시

1~2주차: 관측 분리

  • 셀 후보별 지표 태깅(지연·에러·포화·큐)
  • 전역/셀 단위 대시보드 분리

3~4주차: 제어면 분리

  • 셀 라우팅 키 고정
  • 셀별 롤백/서킷브레이커 스위치 구현

5~6주차: 데이터 경계 분리

  • 셀별 읽기 저장소 또는 파티션 경계 강제
  • 셀 간 쓰기 금지 정책(예외 API만 허용)

7~8주차: 운영 전환

  • 야간 저부하에서 셀 장애 게임데이 실행
  • 셀 단위 온콜 핸드북 확정, 전역 런북은 에스컬레이션용으로 축소

4) 모니터링 최소 세트

  • cell_request_p95/p99
  • cell_error_rate, cell_timeout_rate
  • cell_queue_wait_p95, cell_inflight
  • cross_cell_reroute_ratio
  • cell_mttr, global_impact_ratio

여기서 global_impact_ratio(전체 사용자 중 영향 받은 비율)가 셀 아키텍처의 핵심 KPI입니다. 성능 개선보다 이 지표 감소가 우선입니다. 임계치 설계는 관측 알람 가이드와 함께 설정하세요.

트레이드오프/주의점

  1. 운영 복잡도는 반드시 증가한다
    셀 분할은 아키텍처 문제가 아니라 운영 체계 문제입니다. 배포, 모니터링, 온콜 구조가 같이 바뀌지 않으면 효과가 나지 않습니다.

  2. 데이터 정합성 경계가 더 엄격해진다
    셀 간 동기 쓰기를 남겨두면 장애 시 교착 상태가 늘어납니다. 가능하면 비동기 복제와 명시적 보상 흐름으로 바꿔야 합니다.

  3. 셀 간 불균형이 생길 수 있다
    특정 셀에 고트래픽 고객이 몰리면 오히려 새로운 핫스팟이 생깁니다. 라우팅 키 재해시와 재배치 절차를 런북으로 준비해야 합니다.

  4. “분할” 자체가 목표가 되면 실패한다
    셀 개수를 늘리는 것이 목표가 아니라, 장애 전파율·MTTR·사용자 영향도를 줄이는 것이 목표여야 합니다.

체크리스트 또는 연습

체크리스트

  • 셀 경계가 연산/데이터/운영 3축에서 모두 정의되어 있다.
  • 셀 라우팅 키와 예외 정책(VIP/규제/비상 우회)이 문서화되어 있다.
  • 셀 단위 롤백·트래픽 차단·읽기 전용 전환이 10분 내 가능하다.
  • 셀별 SLO와 온콜 담당이 명확히 분리되어 있다.
  • global_impact_ratio를 월 단위 핵심 안정성 지표로 관리한다.

연습 과제

  1. 현재 서비스에서 “전역 공유 리소스” 5개(DB, 캐시, 큐, 검색, 파일 스토어)를 적고, 각 리소스의 셀 분리 난이도(낮음/중간/높음)를 평가해보세요.
  2. tenant_id 기준 고정 라우팅을 가정하고, 장애 시 비상 우회 규칙(활성화/비활성화 조건)을 숫자로 정의해보세요.
  3. 최근 6개월 장애 리포트를 기준으로 global_impact_ratio를 추정해, 셀 도입 전후 목표치를 설정해보세요.

관련 글