들어가며: 셀룰러 아키텍처의 덫

AWS에서 대규모 상태 유지(Stateful) 서비스를 운영해 본 분이라면 ‘셀룰러 아키텍처(Cellular Architecture)’라는 말을 들어보셨을 거예요. 테넌트마다 AWS 계정, VPC, ALB, ECS 클러스터를 통째로 할당하는 방식입니다. 격리 수준은 확실하지만, 운영 효율은 바닥을 칩니다.

실제 광고 서빙 인프라 사례를 보면 충격적인 수치가 나옵니다.

  • CPU 사용률 3%, 메모리 사용률 19% → 서버가 98% 이상을 ‘기다리는’ 데 쓰고 있음
  • 신규 테넌트 온보딩에 52일 소요 (계정 생성 2주, VPC/네트워크 3주, IAM 1주, 연동 테스트 2주)
  • 동시 라이브 이벤트 불가 → 트래픽을 다른 시스템으로 돌려야 함
  • 노이지 네이버(Noisy Neighbor) 문제 → 같은 인프라를 공유하면 성능 저하 발생

이런 문제를 해결하기 위해 등장한 것이 바로 하이브리드 멀티테넌트 아키텍처입니다. AWS 공식 블로그에 소개된 이 아키텍처는 테넌트 격리 수준은 유지하면서도 온보딩 시간을 86%나 줄인 혁신적인 설계입니다.

이 글은 AWS Architecture Blog의 원문을 바탕으로, 국내 개발자분들이 실무에 바로 적용할 수 있도록 핵심만 추려서 정리했습니다.

AWS multi-tenant architecture diagram showing Route 53, ALB, ECS clusters and PrivateLink connections Development Concept Image

핵심 설계: 3단계 계층 구조

이 아키텍처의 가장 중요한 포인트는 **‘종속성 설정과 테넌트 온보딩의 분리’**입니다. 기존에는 테넌트가 들어올 때마다 VPC, IAM, PrivateLink를 새로 만들었다면, 이제는 티어(Tier) 생성 시점에 모든 다운스트림 연결을 미리 구성해 둡니다.

3단계 계층

  1. Tier (티어) – 테넌트를 논리적으로 그룹화한 최상위 단위. High TPS / Standard TPS / Low TPS 등 트래픽 패턴별로 분류합니다.
  2. Cell (셀) – AWS 계정 단위의 수평 확장 단위. 한 계정이 ENI, VPC 엔드포인트 등 한계에 도달하면 새 셀을 추가합니다.
  3. Infra Group (인프라 그룹) – 실제 인프라가 구동되는 단위. VPC 1개, ALB 1개, ECS 클러스터 N개로 구성됩니다.

이 구조가 주는 이점은 두 개의 독립적인 확장 레버를 제공한다는 점입니다.

  • ALB 타겟 그룹 한도(약 50개)에 도달 → 인프라 그룹 추가 (같은 계정 내)
  • AWS 계정 한도(ENI, VPC 엔드포인트)에 도달 → 셀 추가 (새 계정)

Route 53 가중치 라우팅

모든 트래픽은 Route 53 가중치 라우팅(Weighted Routing)을 통해 여러 ALB로 분산됩니다. 테넌트는 DNS 변경 없이도 트래픽이 자동으로 분배되므로, 확장 시 클라이언트 측 수정이 전혀 필요 없습니다.

# Route 53 가중치 레코드 생성 예시 (AWS CLI)
aws route53 change-resource-record-sets \
  --hosted-zone-id Z35S****K \
  --change-batch '{
    "Changes": [
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "tier-1.us-east-1.example.com",
          "Type": "A",
          "SetIdentifier": "account-1",
          "Weight": 50,
          "AliasTarget": {
            "HostedZoneId": "Z35S****K",
            "DNSName": "dualstack.account-1-alb-123456789.us-east-1.elb.amazonaws.com",
            "EvaluateTargetHealth": true
          }
        }
      }
    ]
  }'

테넌트 전용 ECS 클러스터

각 테넌트는 자신만의 ECS 클러스터를 가집니다. 클러스터 이름에는 티어, 셀, 인프라 그룹, 테넌트 식별자를 모두 포함시켜 운영 중 혼선을 방지합니다.

# ECS 클러스터 생성 예시 (AWS CLI)
aws ecs create-cluster \
  --cluster-name tier-1-cell-1-ig-1-tenant-a \
  --capacity-providers FARGATE

ECS 태스크 정의에서는 테넌트 ID를 환경 변수로 전달하여, 애플리케이션이 시작 시 해당 테넌트의 데이터만 로드하도록 합니다.

{
  "family": "tier-1-tenant-a-task",
  "containerDefinitions": [
    {
      "name": "ad-server",
      "image": "your-ecr-image:latest",
      "environment": [
        {
          "name": "TENANT_ID",
          "value": "tenant-a"
        }
      ]
    }
  ]
}

AWS PrivateLink로 공유 종속성 연결

이 아키텍처의 진짜 묘수는 티어 생성 시 PrivateLink 엔드포인트를 미리 만들어 두는 것입니다. 테넌트가 온보딩되면 자동으로 이 엔드포인트를 통해 다운스트림 서비스에 접근할 수 있습니다.

# VPC 인터페이스 엔드포인트 생성 예시
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345678 \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.vpce.us-east-1.vpce-svc-xxxxxxxx \
  --subnet-ids subnet-12345678 subnet-87654321 \
  --security-group-ids sg-12345678

비용은 엔드포인트당 월 약 $7.30 + 데이터 전송비($0.01/GB)로, 50개 테넌트가 공유하면 테넌트당 15센트 수준이라 무시할 만합니다.

Server rack in a data center representing the infrastructure cost savings from hybrid multi-tenant design Programming Illustration

국내 적용 시 고려사항

이 아키텍처는 대규모 글로벌 서비스에 최적화되어 있지만, 국내 환경에서도 충분히 적용할 수 있습니다. 다만 몇 가지 주의할 점이 있습니다.

국내 SI/클라우드 환경에서의 적용 맥락

  • 계정 제한 완화: 국내에서도 AWS Organizations + SCP를 활용하면 계정 생성 자동화가 가능합니다. 다만, 50개 이상의 계정을 운영하는 기업은 아직 드물기 때문에, 셀 확장보다는 인프라 그룹 확장을 먼저 고려하는 것이 현실적입니다.
  • PrivateLink 비용: 국내 리전(ap-northeast-2)의 PrivateLink 가격은 us-east-1과 비슷하지만, 트래픽 양이 적다면 VPC Peering이나 Transit Gateway가 더 저렴할 수 있습니다. 트래픽 패턴에 따라 선택하세요.
  • 온보딩 자동화: 52일 → 7일로 줄인 핵심은 ‘설정 기반 온보딩’입니다. 국내에서도 Terraform 또는 AWS CDK로 인프라를 코드화하면 동일한 효과를 볼 수 있습니다.

이 기술의 한계 또는 주의사항

  • 상태 유지 서비스에 특화: 이 아키텍처는 인메모리 데이터를 로드하는 상태 유지 서비스(광고 서빙, 게임 서버, 실시간 분석 등)에 최적화되어 있습니다. 무상태(Stateless) 서비스라면 오히려 오버엔지니어링일 수 있습니다.
  • 운영 복잡성: 3단계 계층 구조는 확장성은 뛰어나지만, 초기 구축과 운영에 상당한 노력이 필요합니다. 10개 미만의 테넌트를 운영한다면 ECS Service Connect나 App Mesh 같은 단순한 대안을 먼저 검토하세요.
  • 비용 추적: 테넌트별로 전용 ECS 클러스터를 사용하므로, 공유 클러스터보다 EC2 인스턴스 비용이 증가할 수 있습니다. 빈 패킹(Bin-packing) 분석을 통해 일부 테넌트를 같은 인스턴스에 배치하는 최적화를 고려해야 합니다.

다음 단계 학습 방향

  1. AWS Well-Architected Framework – SaaS Lens를 읽고 멀티테넌트 설계 원칙을 익히세요.
  2. Terraform 또는 AWS CDK로 이 아키텍처를 코드화해 보세요. 실제로 프로비저닝해보는 것이 가장 좋은 학습입니다.
  3. Amazon ECS Anywhere나 EKS를 사용하는 하이브리드 환경으로 확장하는 방법도 연구해 보세요.

Network topology illustration of tier-based isolation with multiple cells and infra groups on AWS Developer Related Image

결론: 52일 걸리던 일을 7일로 만든 비결

이 하이브리드 멀티테넌트 아키텍처가 주는 교훈은 명확합니다.

“종속성 설정을 테넌트 온보딩에서 분리하라.”

PrivateLink 연결, IAM 역할, 원격 캐시 엔드포인트를 티어 생성 시점에 미리 구성해 두면, 온보딩은 단순한 설정 변경으로 바뀝니다. 그 결과:

  • 온보딩 시간: 52일 → 7일 (86% 감소)
  • 인프라 설정 단계: 80% 감소
  • 엔지니어링 노력: 80% 감소
  • 기능 출시 시간: 2~3일 → 1일

AWS 계정 하나로 최대 100개 테넌트를 강력한 격리 수준으로 운영할 수 있게 된 것입니다.

이 아키텍처를 도입할 계획이시라면, 소규모 파일럿(티어 1개, 테넌트 23개)으로 시작해 24주간 모니터링한 후 점진적으로 확장하는 것을 추천드립니다.

함께 보면 좋은 글

참고 자료

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.