Elastic (탄력적) | KAITRUST AI 백과사전

상세 설명

Elastic(탄력성)은 클라우드 컴퓨팅의 핵심 특성 중 하나로, 워크로드 수요에 따라 컴퓨팅 리소스를 자동으로 확장(Scale Out/Up)하거나 축소(Scale In/Down)하는 능력을 의미합니다. 이를 통해 성능을 유지하면서도 비용을 최적화할 수 있습니다.

탄력성의 두 가지 방식:

수평 확장(Horizontal Scaling / Scale Out): 인스턴스 개수를 늘림. 예: EC2 3대 → 10대
수직 확장(Vertical Scaling / Scale Up): 인스턴스 사양을 높임. 예: t3.small → t3.xlarge

클라우드에서의 탄력성 구현 서비스:

AWS Auto Scaling: EC2, ECS, DynamoDB 등 자동 스케일링
Kubernetes HPA/VPA: Pod 수평/수직 자동 확장
서버리스: Lambda, Cloud Functions는 요청 단위로 자동 확장
관리형 서비스: RDS, Aurora, DynamoDB 등 자동 용량 조절

AWS 서비스명에 "Elastic"이 붙은 경우(EC2, ELB, EBS, EKS 등)는 이 탄력성을 핵심 특성으로 제공한다는 의미입니다.

코드 예제

# AWS Auto Scaling Group 생성
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name my-asg \
  --launch-template LaunchTemplateId=lt-0123456789abcdef0 \
  --min-size 2 \
  --max-size 10 \
  --desired-capacity 3 \
  --vpc-zone-identifier "subnet-1234,subnet-5678" \
  --target-group-arns arn:aws:elasticloadbalancing:region:account:targetgroup/my-tg/xxx

# CPU 기반 Target Tracking 정책 (자동 Scale In/Out)
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-asg \
  --policy-name cpu-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    },
    "TargetValue": 50.0
  }'

# 예약 스케일링 (야간 축소)
aws autoscaling put-scheduled-action \
  --auto-scaling-group-name my-asg \
  --scheduled-action-name scale-down-night \
  --recurrence "0 22 * * *" \
  --min-size 1 \
  --max-size 2 \
  --desired-capacity 1

# 주간 확장
aws autoscaling put-scheduled-action \
  --auto-scaling-group-name my-asg \
  --scheduled-action-name scale-up-day \
  --recurrence "0 8 * * 1-5" \
  --min-size 2 \
  --max-size 10 \
  --desired-capacity 3

# DynamoDB 테이블 자동 스케일링
aws application-autoscaling register-scalable-target \
  --service-namespace dynamodb \
  --resource-id "table/my-table" \
  --scalable-dimension "dynamodb:table:ReadCapacityUnits" \
  --min-capacity 5 \
  --max-capacity 100

# Kubernetes Horizontal Pod Autoscaler (HPA)
# CPU 기반 자동 스케일링
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
    # CPU 50% 기준
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50
    # 메모리 70% 기준
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    # 빠른 Scale Up
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100
          periodSeconds: 15
    # 느린 Scale Down (안정성)
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60

---
# Vertical Pod Autoscaler (VPA) - 리소스 요청량 자동 조정
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  updatePolicy:
    updateMode: "Auto"  # 자동 Pod 재시작하며 조정
  resourcePolicy:
    containerPolicies:
      - containerName: "*"
        minAllowed:
          cpu: 100m
          memory: 128Mi
        maxAllowed:
          cpu: 4
          memory: 8Gi

---
# KEDA - 이벤트 기반 스케일링 (Kafka, SQS 등)
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-consumer-scaler
spec:
  scaleTargetRef:
    name: kafka-consumer
  minReplicaCount: 1
  maxReplicaCount: 50
  triggers:
    - type: kafka
      metadata:
        bootstrapServers: kafka:9092
        consumerGroup: my-group
        topic: my-topic
        lagThreshold: "100"  # 메시지 지연 100개당 스케일

# Terraform으로 탄력적 인프라 구성
# Auto Scaling Group
resource "aws_autoscaling_group" "web" {
  name                = "web-asg"
  vpc_zone_identifier = var.private_subnets
  target_group_arns   = [aws_lb_target_group.web.arn]

  min_size         = 2
  max_size         = 20
  desired_capacity = 3

  # 혼합 인스턴스 정책 (온디맨드 + 스팟)
  mixed_instances_policy {
    instances_distribution {
      on_demand_base_capacity                  = 2    # 최소 2개 온디맨드
      on_demand_percentage_above_base_capacity = 25   # 나머지 25% 온디맨드
      spot_allocation_strategy                 = "capacity-optimized"
    }

    launch_template {
      launch_template_specification {
        launch_template_id = aws_launch_template.web.id
        version            = "$Latest"
      }

      override {
        instance_type = "t3.medium"
      }
      override {
        instance_type = "t3a.medium"
      }
      override {
        instance_type = "m5.large"
      }
    }
  }

  # 인스턴스 새로고침 (무중단 배포)
  instance_refresh {
    strategy = "Rolling"
    preferences {
      min_healthy_percentage = 75
    }
  }
}

# Target Tracking 스케일링 정책
resource "aws_autoscaling_policy" "cpu_policy" {
  name                   = "cpu-target-tracking"
  autoscaling_group_name = aws_autoscaling_group.web.name
  policy_type            = "TargetTrackingScaling"

  target_tracking_configuration {
    predefined_metric_specification {
      predefined_metric_type = "ASGAverageCPUUtilization"
    }
    target_value = 50.0
  }
}

# 예약 스케일링 (비용 최적화)
resource "aws_autoscaling_schedule" "night" {
  scheduled_action_name  = "scale-down-night"
  autoscaling_group_name = aws_autoscaling_group.web.name
  min_size               = 1
  max_size               = 5
  desired_capacity       = 2
  recurrence             = "0 22 * * *"  # 매일 22시
}

# Aurora Serverless v2 (자동 용량 조절)
resource "aws_rds_cluster" "aurora" {
  cluster_identifier = "my-aurora"
  engine             = "aurora-mysql"
  engine_mode        = "provisioned"

  serverlessv2_scaling_configuration {
    min_capacity = 0.5   # 최소 0.5 ACU
    max_capacity = 64    # 최대 64 ACU
  }
}

# DynamoDB 자동 스케일링
resource "aws_appautoscaling_target" "dynamodb_read" {
  max_capacity       = 100
  min_capacity       = 5
  resource_id        = "table/${aws_dynamodb_table.main.name}"
  scalable_dimension = "dynamodb:table:ReadCapacityUnits"
  service_namespace  = "dynamodb"
}

실무 대화 예시

아키텍처 설계 회의

"탄력성 있게 설계하려면 어떻게 해야 하나요?" "우선 애플리케이션을 Stateless로 만들어야 합니다. 세션은 Redis, 파일은 S3에 저장하고, DB 연결 풀도 적절히 설정하세요. 그래야 인스턴스를 자유롭게 늘리고 줄일 수 있어요. ALB 뒤에 Auto Scaling Group 두고, CPU 50% 기준 Target Tracking 정책 설정하면 됩니다."

비용 최적화 논의

"Auto Scaling 쓰면 비용이 더 나오는 거 아닌가요?" "잘못 설정하면 그럴 수 있지만, 제대로 쓰면 오히려 절감됩니다. 피크 시간에만 Scale Out하고 야간/주말엔 Scale In하면 평균 인스턴스 수가 줄어요. 저희 서비스는 피크 대비 평균 트래픽이 30%라서 탄력성 적용 후 비용 40% 줄었습니다."

장애 대응 회의

"갑자기 트래픽 폭증했는데 스케일링이 안 됐어요." "몇 가지 확인해봐야 해요. EC2 서비스 한도 초과 아닌지, AMI가 유효한지, 서브넷 IP 고갈 아닌지요. 그리고 스케일링 쿨다운 시간이 너무 길면 반응이 느려요. 긴급 상황 대비해서 예약 용량(Capacity Reservation)이나 온디맨드 최소 개수를 확보해두세요."

면접 질문

"Elasticity와 Scalability의 차이가 뭔가요?" "Scalability는 시스템이 부하 증가를 처리할 수 있는 능력 자체를 말하고, Elasticity는 그 확장/축소가 자동으로 수요에 따라 이루어지는 것을 말합니다. 예를 들어 EC2 인스턴스를 수동으로 10대 늘릴 수 있으면 Scalable하고, Auto Scaling으로 자동 조절되면 Elastic한 거죠."

주의사항

⚠️

Stateful 애플리케이션: 세션을 로컬 메모리에 저장하면 Scale Out 시 세션 유실됩니다. Redis, Memcached 또는 Sticky Session을 사용하세요.

⚠️

스케일링 지연: EC2 부팅, 애플리케이션 시작, 헬스체크 통과까지 수 분 걸립니다. 트래픽 급증 예상 시 Scheduled Scaling으로 미리 확장하세요.

⚠️

Flapping 현상: 스케일링 임계값 설정이 잘못되면 Scale Out → Scale In이 반복됩니다. Cooldown 시간 설정과 stabilization window로 방지하세요.

⚠️

DB 병목: 애플리케이션만 Scale Out해도 DB 연결 수 한계에 걸릴 수 있습니다. Connection Pooling(PgBouncer, ProxySQL)이나 Aurora Serverless 검토하세요.

더 배우기

📚 AWS Auto Scaling 공식 문서 🔧 Kubernetes HPA 가이드 💰 혼합 인스턴스 비용 최적화 ⚡ KEDA - 이벤트 기반 오토스케일링

Elastic

상세 설명

코드 예제

실무 대화 예시

주의사항

관련 용어

더 배우기