Somaz의 IT 공부 일지

2022.02.13 - [AWS] - AWS S3 (Simple Storage Service) 개요 및 활용 방법

2023.03.30 - [AWS] - AWS Secrets Manager란?(OAuth, SSO)

2023.03.30 - [AWS] - AWS Cloudfront란? / Canary 및 Blue-Green 배포

2023.05.26 - [AWS] - AWS IRSA(IAM Roles for Service Accounts)란?

2024.11.16 - [AWS] - AWS Network ACL vs Security Group

2024.11.21 - [AWS] - ALB access Log 활성화 → S3 권한 설정 및 로그 저장

2025.09.02 - [AWS] - AWS EFS와 Kubernetes를 활용한 영구 스토리지 구축 가이드

2025.09.05 - [AWS] - AWS CDN 구축 가이드: Kubernetes + AWS CloudFront로 API와 정적 파일 서빙 최적화

2025.09.05 - [AWS] - AWS 네트워크 연결 방식 완전 비교: VPC Peering vs Transit Gateway vs VPN

2025.09.04 - [AWS] - AWS Load Balancer 완전 비교 가이드

2025.09.10 - [AWS] - EKS Fargate vs EC2 Node Groups 완전 분석 - Kubernetes 워커 노드 옵션

AWS CDN: CloudFront vs Global Accelerator

CloudFront: 전통적인 CDN의 진화

주요 특징 및 작동 원리

CloudFront는 AWS의 대표적인 CDN 서비스로, 전 세계 400개 이상의 엣지 로케이션과 13개의 리전별 엣지 캐시를 통해 콘텐츠를 배포한다. 사용자가 콘텐츠를 요청하면, CloudFront는 지리적으로 가장 가까운 엣지 로케이션에서 캐시된 콘텐츠를 제공하거나, 캐시에 없는 경우 오리진 서버에서 가져와 캐시한 후 제공한다.

CloudFront의 핵심 장점은 캐싱 메커니즘에 있다. HTTP 헤더, 쿠키, 쿼리 스트링 등을 기반으로 세밀한 캐싱 정책을 설정할 수 있으며, 이를 통해 오리진 서버의 부하를 현저히 줄일 수 있다. 또한 Lambda@Edge를 통해 엣지에서 직접 코드를 실행할 수 있어, 개인화된 콘텐츠 제공이나 실시간 이미지 리사이징 등의 고급 기능을 구현할 수 있다.

CloudFront의 성능 최적화 전략

CloudFront의 성능을 극대화하기 위해서는 적절한 캐싱 전략 수립이 핵심이다. TTL(Time To Live) 설정을 통해 콘텐츠 유형별로 차별화된 캐싱 정책을 적용하는 것이 중요하다. 정적 자산의 경우 긴 TTL을, 동적 콘텐츠의 경우 짧은 TTL을 설정하여 최적의 성능과 콘텐츠 신선도를 보장할 수 있다.

압축 기능을 활성화하면 전송되는 데이터 크기를 줄여 대역폭 사용량을 최적화하고 로딩 속도를 개선할 수 있다. 특히 텍스트 기반 콘텐츠에 대해서는 Gzip 압축을 통해 70-80%의 크기 절감 효과를 얻을 수 있다.

Origin Request Policy와 Cache Policy를 통해 세밀한 캐싱 제어가 가능하다. 이를 통해 사용자의 위치, 디바이스 타입, 언어 설정 등에 따른 개인화된 캐싱 전략을 구현할 수 있다.

Content Delivery Flow

Global Accelerator: 네트워크 최적화의 새로운 접근

핵심 기능 및 작동 메커니즘

Global Accelerator는 애플리케이션 성능을 개선하기 위해 AWS의 글로벌 네트워크 인프라를 활용하는 네트워크 서비스이다. 사용자 트래픽을 AWS의 글로벌 백본 네트워크로 빠르게 유입시켜, 공용 인터넷의 혼잡과 지연을 우회하는 방식으로 작동한다.

Global Accelerator는 두 개의 정적 Anycast IP 주소를 제공한다. 이 IP 주소들은 전 세계 어디서나 접근 가능하며, 사용자와 가장 가까운 AWS 엣지 로케이션으로 자동 라우팅된다. 이후 트래픽은 AWS의 고성능 네트워크를 통해 최종 목적지인 Application Load Balancer, Network Load Balancer, 또는 EC2 인스턴스로 전달된다.

특히 실시간 애플리케이션이나 TCP/UDP 기반 서비스에 최적화되어 있으며, 게임, VoIP, 스트리밍과 같은 지연 시간에 민감한 애플리케이션에서 뛰어난 성능을 발휘한다.

Global Accelerator의 성능 최적화 요소

Global Accelerator의 가장 큰 장점은 AWS 글로벌 네트워크의 일관된 성능이다. 공용 인터넷을 통한 라우팅은 여러 ISP를 거치면서 예측 불가능한 지연과 패킷 손실을 경험할 수 있지만, Global Accelerator는 AWS의 사설 네트워크를 통해 안정적이고 예측 가능한 성능을 제공한다.

헬스 체크와 장애 조치 기능을 통해 높은 가용성을 보장한다. 엔드포인트 중 하나에 문제가 발생하면 자동으로 정상적인 엔드포인트로 트래픽을 재라우팅하여 서비스 중단을 최소화한다.

트래픽 다이얼 기능을 통해 엔드포인트 간 트래픽 분산을 세밀하게 제어할 수 있어, 블루-그린 배포나 카나리 배포와 같은 고급 배포 전략을 안전하게 구현할 수 있다.

Network Acceleration Flow

성능 비교 분석

지연 시간 최적화

CloudFront는 캐싱을 통한 지연 시간 단축에 특화되어 있다. 캐시 적중률이 높은 콘텐츠의 경우 엣지에서 직접 응답하므로 매우 낮은 지연 시간을 제공한다. 반면 캐시 미스가 발생하면 오리진까지 왕복해야 하므로 상대적으로 높은 지연 시간을 경험할 수 있다.

Global Accelerator는 모든 요청이 AWS 글로벌 네트워크를 통과하므로 일관된 성능을 제공한다. 캐시 개념이 없기 때문에 모든 요청이 백엔드까지 전달되지만, 최적화된 네트워크 경로를 통해 일반적으로 공용 인터넷 대비 15-60%의 성능 개선을 달성한다.

처리량 및 동시 연결

CloudFront는 HTTP/HTTPS 트래픽에 최적화되어 있으며, 캐싱을 통해 오리진 서버의 부하를 대폭 줄일 수 있다. 이는 특히 트래픽이 급증하는 상황에서 시스템 안정성을 보장하는 핵심 요소가 된다.

Global Accelerator는 TCP 및 UDP 트래픽을 모두 지원하며, 연결 재사용과 멀티플렉싱을 통해 네트워크 효율성을 높인다. 실시간 통신이나 게임과 같은 애플리케이션에서 특히 우수한 성능을 보인다.

비용 효율성 분석

CloudFront 비용 구조

CloudFront의 비용은 주로 데이터 전송량과 요청 수를 기반으로 계산된다. 캐시 적중률이 높을수록 오리진으로의 요청이 줄어들어 비용 효율성이 증가한다. 특히 정적 콘텐츠가 많은 웹사이트의 경우 매우 경제적인 선택이 될 수 있다.

리전별 요금제를 통해 주요 사용자 기반에 따른 비용 최적화가 가능하다. 예를 들어, 북미와 유럽 사용자가 주를 이루는 서비스라면 해당 리전만 활성화하여 비용을 절감할 수 있다.

Global Accelerator 비용 구조

Global Accelerator는 고정 시간당 요금과 데이터 전송 요금으로 구성된다. 시간당 요금은 사용 여부와 관계없이 발생하므로, 트래픽이 적은 서비스에서는 상대적으로 높은 비용 부담이 될 수 있다.

그러나 높은 트래픽을 처리하는 서비스에서는 안정적인 성능과 가용성으로 인한 비즈니스 가치가 비용을 상쇄할 수 있다. 특히 실시간 서비스나 미션 크리티컬한 애플리케이션에서는 투자 대비 효과가 매우 높다.

비용 최적화 전략

두 서비스를 함께 사용하는 하이브리드 접근 방식이 가장 효율적일 수 있다. 정적 콘텐츠는 CloudFront를 통해 제공하고, 동적 API나 실시간 통신은 Global Accelerator를 활용하는 방식으로 각 서비스의 장점을 최대화할 수 있다.

Reserved Capacity를 통해 예상 사용량에 대해 사전 약정하면 상당한 할인 혜택을 받을 수 있으며, 이는 안정적인 트래픽 패턴을 가진 서비스에서 유용한 전략이다.

실제 구현을 위한 Terraform 코드

CloudFront 배포 코드

# CloudFront Distribution 구성
resource "aws_cloudfront_distribution" "main_distribution" {
  origin {
    domain_name = aws_lb.main_alb.dns_name
    origin_id   = "main-origin"
    
    custom_origin_config {
      http_port              = 80
      https_port             = 443
      origin_protocol_policy = "https-only"
      origin_ssl_protocols   = ["TLSv1.2"]
    }
  }

  enabled             = true
  is_ipv6_enabled     = true
  comment             = "Main CloudFront Distribution"
  default_root_object = "index.html"

  # 캐싱 동작 설정
  default_cache_behavior {
    allowed_methods        = ["DELETE", "GET", "HEAD", "OPTIONS", "PATCH", "POST", "PUT"]
    cached_methods         = ["GET", "HEAD"]
    target_origin_id       = "main-origin"
    compress               = true
    viewer_protocol_policy = "redirect-to-https"

    forwarded_values {
      query_string = false
      cookies {
        forward = "none"
      }
    }

    min_ttl     = 0
    default_ttl = 3600
    max_ttl     = 86400
  }

  # 추가 캐싱 동작 (API 엔드포인트용)
  ordered_cache_behavior {
    path_pattern           = "/api/*"
    allowed_methods        = ["DELETE", "GET", "HEAD", "OPTIONS", "PATCH", "POST", "PUT"]
    cached_methods         = ["GET", "HEAD", "OPTIONS"]
    target_origin_id       = "main-origin"
    compress               = true
    viewer_protocol_policy = "redirect-to-https"

    forwarded_values {
      query_string = true
      headers      = ["Authorization", "CloudFront-Forwarded-Proto"]
      cookies {
        forward = "all"
      }
    }

    min_ttl     = 0
    default_ttl = 0
    max_ttl     = 0
  }

  # 지리적 제한 설정
  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  # SSL 인증서 설정
  viewer_certificate {
    cloudfront_default_certificate = true
  }

  # 로깅 설정
  logging_config {
    include_cookies = false
    bucket          = aws_s3_bucket.cloudfront_logs.bucket_domain_name
    prefix          = "cloudfront-logs/"
  }

  tags = {
    Name        = "main-cloudfront"
    Environment = "production"
  }
}

# CloudFront 로그용 S3 버킷
resource "aws_s3_bucket" "cloudfront_logs" {
  bucket        = "my-cloudfront-logs-${random_string.suffix.result}"
  force_destroy = true

  tags = {
    Name        = "CloudFront Logs"
    Environment = "production"
  }
}

resource "aws_s3_bucket_public_access_block" "cloudfront_logs" {
  bucket = aws_s3_bucket.cloudfront_logs.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

# Lambda@Edge 함수 (선택적)
resource "aws_lambda_function" "edge_function" {
  filename         = "edge_function.zip"
  function_name    = "cloudfront-edge-function"
  role            = aws_iam_role.lambda_edge_role.arn
  handler         = "index.handler"
  source_code_hash = filebase64sha256("edge_function.zip")
  runtime         = "nodejs18.x"
  publish         = true

  tags = {
    Environment = "production"
  }
}

# Lambda@Edge용 IAM 역할
resource "aws_iam_role" "lambda_edge_role" {
  name = "lambda-edge-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = [
            "lambda.amazonaws.com",
            "edgelambda.amazonaws.com"
          ]
        }
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "lambda_edge_basic" {
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
  role       = aws_iam_role.lambda_edge_role.name
}

Global Accelerator 배포 코드

# Global Accelerator 구성
resource "aws_globalaccelerator_accelerator" "main_accelerator" {
  name            = "main-global-accelerator"
  ip_address_type = "IPV4"
  enabled         = true

  attributes {
    flow_logs_enabled   = true
    flow_logs_s3_bucket = aws_s3_bucket.accelerator_logs.bucket
    flow_logs_s3_prefix = "flow-logs/"
  }

  tags = {
    Name        = "main-accelerator"
    Environment = "production"
  }
}

# Global Accelerator 리스너 구성
resource "aws_globalaccelerator_listener" "main_listener" {
  accelerator_arn = aws_globalaccelerator_accelerator.main_accelerator.id
  client_affinity = "SOURCE_IP"
  protocol        = "TCP"

  port_range {
    from = 80
    to   = 80
  }

  port_range {
    from = 443
    to   = 443
  }
}

# 엔드포인트 그룹 구성 (주 리전)
resource "aws_globalaccelerator_endpoint_group" "main_endpoint_group" {
  listener_arn = aws_globalaccelerator_listener.main_listener.id

  endpoint_group_region = "us-west-2"
  traffic_dial_percentage = 100

  health_check_interval_seconds = 30
  health_check_path            = "/health"
  health_check_protocol        = "HTTP"
  health_check_port            = 80
  healthy_threshold_count      = 3
  unhealthy_threshold_count    = 3

  endpoint_configuration {
    endpoint_id = aws_lb.main_alb.arn
    weight      = 100
  }
}

# 백업 엔드포인트 그룹 구성 (보조 리전)
resource "aws_globalaccelerator_endpoint_group" "backup_endpoint_group" {
  listener_arn = aws_globalaccelerator_listener.main_listener.id

  endpoint_group_region = "us-east-1"
  traffic_dial_percentage = 0  # 평상시에는 비활성화

  health_check_interval_seconds = 30
  health_check_path            = "/health"
  health_check_protocol        = "HTTP"
  health_check_port            = 80
  healthy_threshold_count      = 3
  unhealthy_threshold_count    = 3

  endpoint_configuration {
    endpoint_id = aws_lb.backup_alb.arn
    weight      = 100
  }
}

# Global Accelerator 로그용 S3 버킷
resource "aws_s3_bucket" "accelerator_logs" {
  bucket        = "my-accelerator-logs-${random_string.suffix.result}"
  force_destroy = true

  tags = {
    Name        = "Global Accelerator Logs"
    Environment = "production"
  }
}

# Application Load Balancer (주 리전)
resource "aws_lb" "main_alb" {
  name               = "main-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb_sg.id]
  subnets           = aws_subnet.public[*].id

  enable_deletion_protection = false

  access_logs {
    bucket  = aws_s3_bucket.alb_logs.bucket
    prefix  = "main-alb"
    enabled = true
  }

  tags = {
    Name        = "main-alb"
    Environment = "production"
  }
}

# 타겟 그룹 구성
resource "aws_lb_target_group" "main_tg" {
  name     = "main-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id

  health_check {
    enabled             = true
    healthy_threshold   = 2
    interval            = 30
    matcher             = "200"
    path                = "/health"
    port                = "traffic-port"
    protocol            = "HTTP"
    timeout             = 5
    unhealthy_threshold = 2
  }

  tags = {
    Name        = "main-tg"
    Environment = "production"
  }
}

# ALB 리스너 구성
resource "aws_lb_listener" "main_listener" {
  load_balancer_arn = aws_lb.main_alb.arn
  port              = "80"
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.main_tg.arn
  }
}

# 보안 그룹 구성
resource "aws_security_group" "alb_sg" {
  name        = "alb-security-group"
  description = "Security group for Application Load Balancer"
  vpc_id      = aws_vpc.main.id

  ingress {
    description = "HTTP"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "HTTPS"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name        = "alb-sg"
    Environment = "production"
  }
}

하이브리드 구성 및 모니터링

# CloudWatch 대시보드 구성
resource "aws_cloudwatch_dashboard" "cdn_performance" {
  dashboard_name = "CDN-Performance-Dashboard"

  dashboard_body = jsonencode({
    widgets = [
      {
        type   = "metric"
        x      = 0
        y      = 0
        width  = 12
        height = 6

        properties = {
          metrics = [
            ["AWS/CloudFront", "Requests", "DistributionId", aws_cloudfront_distribution.main_distribution.id],
            ["AWS/CloudFront", "BytesDownloaded", "DistributionId", aws_cloudfront_distribution.main_distribution.id],
            ["AWS/CloudFront", "CacheHitRate", "DistributionId", aws_cloudfront_distribution.main_distribution.id]
          ]
          period = 300
          stat   = "Sum"
          region = "us-east-1"
          title  = "CloudFront Performance Metrics"
        }
      },
      {
        type   = "metric"
        x      = 0
        y      = 6
        width  = 12
        height = 6

        properties = {
          metrics = [
            ["AWS/GlobalAccelerator", "ProcessedBytesIn", "Accelerator", aws_globalaccelerator_accelerator.main_accelerator.id],
            ["AWS/GlobalAccelerator", "ProcessedBytesOut", "Accelerator", aws_globalaccelerator_accelerator.main_accelerator.id]
          ]
          period = 300
          stat   = "Sum"
          region = "us-west-2"
          title  = "Global Accelerator Traffic Metrics"
        }
      }
    ]
  })
}

# CloudWatch 경보 설정
resource "aws_cloudwatch_metric_alarm" "cloudfront_error_rate" {
  alarm_name          = "cloudfront-high-error-rate"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = "2"
  metric_name         = "ErrorRate"
  namespace           = "AWS/CloudFront"
  period              = "300"
  statistic           = "Average"
  threshold           = "5"
  alarm_description   = "This metric monitors CloudFront error rate"
  alarm_actions       = [aws_sns_topic.alerts.arn]

  dimensions = {
    DistributionId = aws_cloudfront_distribution.main_distribution.id
  }

  tags = {
    Environment = "production"
  }
}

# SNS 토픽 (알림용)
resource "aws_sns_topic" "alerts" {
  name = "cdn-alerts"

  tags = {
    Environment = "production"
  }
}

# 랜덤 문자열 생성 (버킷 이름 고유성 보장)
resource "random_string" "suffix" {
  length  = 8
  special = false
  upper   = false
}

# 출력값 정의
output "cloudfront_domain_name" {
  description = "CloudFront Distribution domain name"
  value       = aws_cloudfront_distribution.main_distribution.domain_name
}

output "global_accelerator_dns_name" {
  description = "Global Accelerator DNS name"
  value       = aws_globalaccelerator_accelerator.main_accelerator.dns_name
}

output "global_accelerator_ips" {
  description = "Global Accelerator static IP addresses"
  value       = aws_globalaccelerator_accelerator.main_accelerator.ip_sets[0].ip_addresses
}

적절한 사용 사례 및 선택 가이드

CloudFront 최적 사용 사례

CloudFront는 웹사이트, 이미지 갤러리, 동영상 스트리밍 서비스와 같이 캐싱 가능한 콘텐츠가 많은 서비스에 최적화되어 있다. 특히 정적 자산이 전체 트래픽의 상당 부분을 차지하는 경우 매우 높은 비용 효율성을 제공한다.

또한 Lambda@Edge를 활용한 엣지 컴퓨팅이 필요한 경우에도 CloudFront가 유일한 선택이다. 이미지 리사이징, A/B 테스팅, 보안 헤더 추가 등의 작업을 엣지에서 처리하여 오리진 서버의 부하를 줄이고 응답 속도를 개선할 수 있다.

Global Accelerator 최적 사용 사례

Global Accelerator는 게임 서버, VoIP 애플리케이션, IoT 데이터 수집과 같이 실시간성이 중요하고 TCP/UDP 프로토콜을 사용하는 서비스에 적합하다. 또한 지역별로 복잡한 장애 조치 시나리오가 필요한 글로벌 서비스에서 그 진가를 발휘한다.

API 서비스의 경우 캐싱이 어려운 동적 콘텐츠가 주를 이루므로, Global Accelerator를 통한 네트워크 최적화가 더 효과적일 수 있다. 특히 데이터베이스 쿼리나 복잡한 비즈니스 로직이 포함된 API 호출에서 안정적인 성능 개선을 기대할 수 있다.

하이브리드 접근 방식

많은 현실적인 시나리오에서는 두 서비스를 함께 사용하는 것이 최적의 결과를 낳는다. 예를 들어, 웹 애플리케이션의 정적 자산(CSS, JavaScript, 이미지)은 CloudFront를 통해 전송하고, API 엔드포인트는 Global Accelerator를 통해 최적화하는 방식이다.

이러한 접근 방식은 각 서비스의 장점을 최대한 활용하면서도 전체적인 비용 효율성을 유지할 수 있는 균형잡힌 솔루션을 제공한다.

성능 측정 및 모니터링

CloudFront 성능 지표

CloudFront의 성능을 평가하기 위한 핵심 지표로는 캐시 적중률, 오리진 응답 시간, 엣지 응답 시간이 있다. 캐시 적중률이 높을수록 사용자 경험과 비용 효율성이 개선되므로, 이를 지속적으로 모니터링하고 최적화해야 한다.

Real User Monitoring(RUM)을 통해 실제 사용자가 경험하는 성능을 측정하는 것도 중요하다. CloudWatch RUM을 활용하면 페이지 로딩 시간, 자바스크립트 오류, 사용자 상호작용 등을 상세히 분석할 수 있다.

Global Accelerator 성능 지표

Global Accelerator의 성능 측정에는 네트워크 지연 시간, 패킷 손실률, 연결 성공률이 핵심 지표가 된다. AWS CloudWatch를 통해 이러한 지표들을 실시간으로 모니터링할 수 있으며, 특히 지역별 성능 차이를 분석하여 최적화 포인트를 찾을 수 있다.

Flow Logs를 활성화하면 트래픽 패턴과 엔드포인트별 성능을 상세히 분석할 수 있다. 이를 통해 트래픽 분산 정책을 조정하고 장애 조치 시나리오를 개선할 수 있다.

통합 모니터링 전략

두 서비스를 함께 사용하는 경우, 통합된 모니터링 대시보드를 구성하여 전체적인 성능 트렌드를 파악하는 것이 중요하다. CloudWatch 대시보드를 통해 CloudFront와 Global Accelerator의 주요 지표를 한 곳에서 확인할 수 있으며, 이를 통해 문제 발생 시 신속한 대응이 가능하다.

보안 고려사항

CloudFront 보안 기능

CloudFront는 다양한 보안 기능을 제공하여 콘텐츠와 애플리케이션을 보호한다. AWS WAF(Web Application Firewall)를 연동하여 SQL 인젝션, XSS 공격 등을 차단할 수 있으며, 지리적 제한을 통해 특정 국가나 지역에서의 접근을 제어할 수 있다.

Origin Access Control(OAC)을 통해 S3 버킷에 대한 직접 접근을 차단하고 CloudFront를 통해서만 콘텐츠에 접근할 수 있도록 설정할 수 있다. 또한 Signed URL과 Signed Cookie를 활용하여 프리미엄 콘텐츠에 대한 접근 제어를 구현할 수 있다.

Global Accelerator 보안 고려사항

Global Accelerator는 네트워크 계층에서 작동하므로 DDoS 공격에 대한 기본적인 보호 기능을 제공한다. AWS Shield Standard가 자동으로 적용되며, 필요에 따라 Shield Advanced를 통해 고급 DDoS 보호 기능을 활용할 수 있다.

엔드포인트로 사용되는 Load Balancer나 EC2 인스턴스의 보안 그룹 설정을 통해 추가적인 네트워크 레벨 보안을 구현할 수 있다. 특히 Global Accelerator의 IP 주소 범위만 허용하도록 설정하여 보안을 강화할 수 있다.

마이그레이션 및 구현 전략

단계적 마이그레이션 접근법

기존 인프라에서 CloudFront나 Global Accelerator로 마이그레이션할 때는 단계적 접근법을 사용하는 것이 안전하다. 먼저 트래픽의 일부분만 새로운 서비스로 라우팅하고, 성능과 안정성을 확인한 후 점진적으로 비율을 늘려가는 방식을 권장한다.

DNS 가중치 기반 라우팅을 활용하면 트래픽을 단계적으로 이전할 수 있으며, 문제 발생 시 빠른 롤백이 가능하다. Route 53의 헬스 체크 기능과 연동하면 자동 장애 조치도 구현할 수 있다.

성능 테스트 및 검증

마이그레이션 전에는 반드시 충분한 성능 테스트를 수행해야 한다. 다양한 지역에서의 접속 테스트, 부하 테스트, 장애 시뮬레이션 등을 통해 예상 성능을 검증하고 잠재적 문제점을 미리 파악해야 한다.

특히 캐싱 정책이나 TTL 설정과 같은 구성 요소들은 실제 운영 환경에서의 동작을 정확히 예측하기 어려우므로, 프로덕션과 유사한 환경에서의 테스트가 필수적이다.

미래 발전 방향 및 신기술 동향

Edge Computing의 확산

CloudFront의 Lambda@Edge와 CloudFront Functions는 엣지 컴퓨팅의 새로운 가능성을 열어주고 있다. 앞으로는 더 복잡한 비즈니스 로직을 엣지에서 처리하여 지연 시간을 줄이고 사용자 경험을 개선하는 방향으로 발전할 것으로 예상된다.

특히 개인화 서비스, 실시간 이미지 처리, A/B 테스팅과 같은 기능들이 엣지에서 더욱 효율적으로 구현될 것이며, 이는 중앙 서버의 부하를 크게 줄이는 동시에 응답 속도를 향상시킬 것이다.

5G와 IoT 환경에서의 활용

5G 네트워크의 확산과 IoT 디바이스의 급증은 CDN과 네트워크 가속화 서비스에 새로운 요구사항을 제시하고 있다. 초저지연 통신이 필요한 자율주행, 증강현실, 원격수술과 같은 애플리케이션에서 CloudFront와 Global Accelerator의 역할이 더욱 중요해질 것이다.

특히 Global Accelerator의 경우 TCP 및 UDP 트래픽 최적화 기능을 통해 IoT 디바이스 간의 실시간 통신을 효율적으로 지원할 수 있으며, 이는 스마트 시티나 인더스트리 4.0과 같은 대규모 IoT 생태계에서 핵심적인 역할을 할 것으로 전망된다.

업계 사례 분석

대규모 서비스 사례

Netflix는 CloudFront와 자체 CDN을 조합하여 전 세계 사용자에게 고품질 스트리밍 서비스를 제공하고 있다. 특히 캐싱 최적화와 Lambda@Edge를 활용한 개인화 추천 시스템을 통해 사용자별 맞춤 콘텐츠를 효율적으로 전달하고 있다.

게임 업계에서는 Global Accelerator를 활용한 사례가 늘어나고 있다. 실시간 멀티플레이어 게임에서 지연 시간은 사용자 경험에 직접적인 영향을 미치므로, AWS 글로벌 네트워크를 통한 최적화된 라우팅이 핵심 경쟁 요소가 되고 있다.

중소기업 적용 사례

중소기업의 경우 비용 효율성이 매우 중요한 요소이다. CloudFront의 무료 티어를 활용하면 월 1TB의 데이터 전송과 1000만 건의 HTTP 요청을 무료로 처리할 수 있어, 스타트업이나 중소기업에서도 부담 없이 CDN 서비스를 시작할 수 있다.

또한 사용한 만큼만 비용을 지불하는 종량제 요금 체계를 통해 트래픽 변동이 큰 서비스에서도 예측 가능한 비용 관리가 가능하다.

최적화 팁과 베스트 프랙티스

CloudFront 최적화 전략

HTTP/2와 HTTP/3 프로토콜을 활성화하면 다중화와 헤더 압축을 통해 성능을 크게 개선할 수 있다. 특히 많은 작은 파일을 전송하는 웹 애플리케이션에서 뚜렷한 성능 향상을 경험할 수 있다.

Origin Request Policy를 활용하여 불필요한 헤더나 쿠키를 제거하면 캐시 효율성을 높일 수 있다. 예를 들어, 정적 자산에 대해서는 인증 관련 헤더를 제거하여 캐시 적중률을 향상시킬 수 있다.

Global Accelerator 최적화 방법

엔드포인트 그룹의 트래픽 다이얼 설정을 통해 단계적 배포나 A/B 테스팅을 안전하게 수행할 수 있다. 이를 통해 새로운 기능이나 성능 개선사항을 점진적으로 적용하면서 위험을 최소화할 수 있다.

클라이언트 어피니티 설정을 적절히 조정하면 세션 유지나 캐시 효율성을 개선할 수 있다. SOURCE_IP 설정을 통해 동일한 사용자의 요청을 일관된 엔드포인트로 라우팅할 수 있다.

마무리

CloudFront와 Global Accelerator는 각각 고유한 강점과 적용 분야를 가진 보완적인 서비스이다. CloudFront는 캐싱을 통한 콘텐츠 전송 최적화에 특화되어 있어 웹사이트, 미디어 스트리밍, API 응답 캐싱 등에 탁월한 성능을 발휘한다.

반면 Global Accelerator는 네트워크 계층에서의 최적화를 통해 실시간 애플리케이션, 게임, IoT 서비스 등에 안정적이고 예측 가능한 성능을 제공한다.

두 서비스의 선택은 애플리케이션의 특성, 트래픽 패턴, 비용 고려사항을 종합적으로 평가하여 결정해야 한다. 많은 경우 두 서비스를 조합하여 사용하는 하이브리드 접근 방식이 최적의 결과를 낳으며, 이를 통해 사용자 경험 향상과 비용 효율성을 동시에 달성할 수 있다.

글로벌 서비스의 성공을 위해서는 단순한 기술 도입을 넘어서 지속적인 모니터링, 최적화, 그리고 사용자 피드백 반영이 필요하다. CloudFront와 Global Accelerator는 이러한 요구사항을 충족하기 위한 강력한 도구이며, 적절한 구성과 운영을 통해 세계적 수준의 서비스 품질을 달성할 수 있다.

Reference

AWS CloudFront Developer Guide - https://docs.aws.amazon.com/cloudfront/
AWS Global Accelerator Developer Guide - https://docs.aws.amazon.com/global-accelerator/
AWS Well-Architected Framework - Performance Efficiency Pillar - https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/
"Content Delivery Networks: Web Caching and Beyond" - Buyya et al., IEEE Internet Computing
AWS re:Invent 2023 - NET301: Accelerate your applications with AWS Global Accelerator
CloudFront Pricing - https://aws.amazon.com/cloudfront/pricing/
Global Accelerator Pricing - https://aws.amazon.com/global-accelerator/pricing/
AWS CDN Performance Best Practices Whitepaper
Terraform AWS Provider Documentation - https://registry.terraform.io/providers/hashicorp/aws/latest/docs
"High Performance Browser Networking" - Ilya Grigorik, O'Reilly Media

Somaz | DevOps Engineer | Kubernetes & Cloud Infrastructure Specialist

EKS Fargate vs EC2 Node Groups 완전 분석 - Kubernetes 워커 노드 옵션

Somaz — Tue, 17 Feb 2026 00:00:12 +0900

Overview

Amazon EKS에서 제공하는 두 가지 컴퓨팅 옵션의 기술적 차이점, 비용 구조, 운영 고려사항을 종합적으로 비교 분석한다.

컨테이너 오케스트레이션 영역에서 Amazon EKS는 기업들이 Kubernetes 클러스터를 관리하는 방식을 혁신적으로 변화시켰다. 특히 워커 노드를 운영하는 방식에서 두 가지 근본적으로 다른 접근법을 제시하며, 각각이 현대 클라우드 네이티브 아키텍처의 서로 다른 요구사항을 해결한다.

Fargate는 서버리스 컨테이너 플랫폼으로서, 인프라 관리의 복잡성을 완전히 추상화한다. 개발자와 DevOps 엔지니어들이 애플리케이션 로직에만 집중할 수 있도록 하며, AWS가 모든 인프라 레이어를 투명하게 관리한다. 이는 특히 스타트업이나 개발 팀이 제한적인 운영 리소스로 복잡한 Kubernetes 환경을 구축해야 할 때 매력적인 옵션이다.

반면 EC2 Node Groups는 전통적이면서도 강력한 접근법으로, 엔터프라이즈급 애플리케이션이 요구하는 세밀한 제어와 최적화를 가능하게 한다. 이 방식은 특히 금융, 제조업, 대규모 e-커머스와 같이 성능 최적화와 비용 효율성이 핵심인 산업에서 선호된다.

현재 클라우드 네이티브 생태계에서 이 두 옵션 사이의 선택은 단순한 기술적 결정을 넘어서, 조직의 성숙도, 운영 철학, 그리고 장기적인 기술 전략과 밀접하게 연결되어 있다. 많은 기업들이 실제로는 두 접근법을 전략적으로 조합하여 각 워크로드의 특성에 가장 적합한 컴퓨팅 환경을 제공하는 하이브리드 모델을 채택하고 있다.

이 분석에서는 실제 운영 환경에서의 경험을 바탕으로, 각 옵션의 기술적 세부사항부터 비즈니스 임팩트까지 포괄적으로 다룬다. 또한 단순한 기능 비교를 넘어서, 실무진이 직면하는 실제 의사결정 상황에서 고려해야 할 요소들을 구체적으로 제시한다.

2022.02.13 - [AWS] - AWS IAM (Identity and Access Management) 개요 및 설정 방법

2022.02.13 - [AWS] - AWS S3 (Simple Storage Service) 개요 및 활용 방법

2023.03.30 - [AWS] - AWS Secrets Manager란?(OAuth, SSO)

2023.03.30 - [AWS] - AWS Cloudfront란? / Canary 및 Blue-Green 배포

2023.05.26 - [AWS] - AWS IRSA(IAM Roles for Service Accounts)란?

2024.11.16 - [AWS] - AWS Network ACL vs Security Group

2024.11.21 - [AWS] - ALB access Log 활성화 → S3 권한 설정 및 로그 저장

2025.09.02 - [AWS] - AWS EFS와 Kubernetes를 활용한 영구 스토리지 구축 가이드

2025.09.05 - [AWS] - AWS CDN 구축 가이드: Kubernetes + AWS CloudFront로 API와 정적 파일 서빙 최적화

2025.09.05 - [AWS] - AWS 네트워크 연결 방식 완전 비교: VPC Peering vs Transit Gateway vs VPN

2025.09.04 - [AWS] - AWS Load Balancer 완전 비교 가이드

2025.09.10 - [AWS] - EKS Fargate vs EC2 Node Groups 완전 분석 - Kubernetes 워커 노드 옵션

개요

Amazon Elastic Kubernetes Service(EKS)는 Kubernetes 워크로드를 실행하기 위해 두 가지 주요 컴퓨팅 옵션을 제공한다.

Fargate와 EC2 Node Groups이다.

각 접근 방식은 운영 오버헤드, 비용 구조, 성능 특성, 배포 유연성 측면에서 고유한 장점과 트레이드오프를 제공한다.

이 글에서는 두 옵션의 기술적 아키텍처, 비용 영향, 운영상 고려사항을 종합적으로 분석하여 최적의 Kubernetes 클러스터 설계 결정을 위한 가이드를 제공한다.

EKS 컴퓨팅 아키텍처 개요

Fargate 아키텍처

Fargate는 서버리스 모델로 각 파드가 전용 컴퓨팅 인프라에서 실행되며, AWS가 완전히 관리한다.

EKS Control Plane → Fargate Profile → Pod (서버리스 실행)

EC2 Node Groups 아키텍처

EC2 Node Groups는 전통적인 접근 방식으로 EC2 인스턴스에서 여러 파드가 실행된다.

EKS Control Plane → Node Group → EC2 Nodes → Multiple Pods

EKS Fargate 심층 분석

핵심 특징

서버리스 인프라

EC2 인스턴스 관리가 필요 없음
파드별 전용 컴퓨팅 리소스 제공
자동 스케일링 및 리소스 할당

보안 격리

파드 수준의 향상된 보안 격리
각 파드가 독립적인 컴퓨팅 환경에서 실행

Fargate profile 구성

Fargate profile 은 어떤 파드가 Fargate 컴퓨팅에서 실행될지 결정한다. 네임스페이스와 라벨 선택자를 기반으로 파드 배치를 결정한다.

# Fargate 호환 배포 예시
apiVersion: apps/v1
kind: Deployment
metadata:
  name: fargate-app
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: fargate-app
  template:
    metadata:
      labels:
        app: fargate-app
        compute-type: fargate  # Fargate profile 선택자
    spec:
      containers:
      - name: app
        image: nginx:latest
        resources:
          requests:
            cpu: 250m
            memory: 512Mi
          limits:
            cpu: 500m
            memory: 1Gi

제한사항

Fargate는 EC2 노드 그룹 대비 몇 가지 운영 제약사항이 있다.

DaemonSets 지원 안 함
권한이 있는 컨테이너 실행 불가
호스트 네트워킹 사용 불가
스토리지 옵션 제한 (임시 스토리지 및 EFS 볼륨만 지원)

Terraform 구현 예시

# EKS 클러스터 (Fargate 포함)
resource "aws_eks_cluster" "main" {
  name     = "main-cluster"
  role_arn = aws_iam_role.eks_cluster.arn
  version  = "1.29"

  vpc_config {
    subnet_ids              = var.subnet_ids
    endpoint_private_access = true
    endpoint_public_access  = true
  }
}

# Fargate 프로필
resource "aws_eks_fargate_profile" "main" {
  cluster_name           = aws_eks_cluster.main.name
  fargate_profile_name   = "main-fargate-profile"
  pod_execution_role_arn = aws_iam_role.fargate_pod_execution_role.arn
  subnet_ids            = var.private_subnet_ids

  selector {
    namespace = "default"
    labels = {
      "compute-type" = "fargate"
    }
  }

  selector {
    namespace = "kube-system"
    labels = {
      "k8s-app" = "kube-dns"
    }
  }
}

EC2 Node Groups 종합 분석

아키텍처 기반

EC2 Node Groups는 EKS 클러스터에 워커 노드로 참여하는 관리형 EC2 인스턴스에서 작동한다. AWS가 AMI 업데이트, 보안 패치, 노드 라이프사이클 관리를 처리하면서 기본 컴퓨팅 인프라에 대한 완전한 액세스를 제공한다.

핵심 기능

완전한 Kubernetes 호환성

DaemonSets를 포함한 모든 Kubernetes 기능 지원
GPU 인스턴스를 포함한 다양한 EC2 인스턴스 유형 제공

스토리지 옵션

영구 볼륨 지원을 위한 완전한 EBS 통합
호스트 네트워킹 및 권한이 있는 컨테이너 지원

노드 그룹 유형

노드 그룹 유형	관리 수준	커스터마이징	사용 사례
관리형 노드 그룹	완전 관리형	제한적	표준 워크로드, 간소화된 운영
자체 관리형 노드 그룹	사용자 관리	완전 제어	커스텀 AMI, 특정 요구사항
스팟 노드 그룹	스팟과 함께 관리	제한적	비용 최적화, 내결함성 워크로드

자동 스케일링 및 리소스 관리

EC2 노드 그룹은 Cluster Autoscaler와 통합되어 파드 리소스 요구사항에 따라 클러스터 용량을 자동으로 조정한다.

# 관리형 노드 그룹
resource "aws_eks_node_group" "main" {
  cluster_name    = aws_eks_cluster.main.name
  node_group_name = "main-node-group"
  node_role_arn   = aws_iam_role.node_group.arn
  subnet_ids      = var.private_subnet_ids
  instance_types  = ["t3.medium", "t3.large"]
  
  scaling_config {
    desired_size = 2
    max_size     = 5
    min_size     = 1
  }

  ami_type       = "AL2_x86_64"
  capacity_type  = "ON_DEMAND"
  disk_size      = 50

  labels = {
    "node-type" = "managed"
  }
}

# 비용 최적화를 위한 스팟 인스턴스 노드 그룹
resource "aws_eks_node_group" "spot" {
  cluster_name    = aws_eks_cluster.main.name
  node_group_name = "spot-node-group"
  node_role_arn   = aws_iam_role.node_group.arn
  subnet_ids      = var.private_subnet_ids
  instance_types  = ["t3.medium", "t3.large", "t3.xlarge"]
  
  scaling_config {
    desired_size = 0
    max_size     = 10
    min_size     = 0
  }

  capacity_type = "SPOT"
  
  taint {
    key    = "node.kubernetes.io/spot"
    value  = "true"
    effect = "NO_SCHEDULE"
  }
}

비용 분석

Fargate 비용 구조

Fargate는 파드에 할당된 vCPU 및 메모리 리소스를 기반으로 청구되며, 1분 최소 단위로 초당 계산된다.

리소스 유형	비용 (USD/시간)	최소 단위	비고
vCPU	$0.04048	0.25 vCPU	vCPU당 시간당
메모리	$0.004445	0.5 GB	GB당 시간당
스토리지	$0.000111	1 GB	임시 스토리지 GB당 시간당

EC2 Node Groups 비용 모델

EC2 노드 그룹은 표준 EC2 가격을 따르며, EBS 스토리지 및 데이터 전송에 대한 추가 고려사항이 있다.

인스턴스 유형	온디맨드 (USD/시간)	스팟 (USD/시간)	vCPU	메모리 (GB)
t3.medium	$0.0416	~$0.0125	2	4
t3.large	$0.0832	~$0.0250	2	8
m5.large	$0.096	~$0.0288	2	8
c5.xlarge	$0.17	~$0.051	4	8

비용 비교 시나리오

리소스 활용률 패턴이 Fargate와 EC2 노드 그룹 간의 비용 효율성에 크게 영향을 미친다.

낮은 활용률 시나리오 (10-30%)

Fargate: $0.20/시간
EC2: $0.50/시간
결과: Fargate 승리

높은 활용률 시나리오 (70-90%)

Fargate: $0.80/시간
EC2: $0.50/시간
결과: EC2 승리

성능 특성 분석

시작 시간 비교

메트릭	Fargate	EC2 Node Groups	영향
파드 시작 시간	30-60초	5-15초	애플리케이션 응답성
콜드 스타트 영향	높음	낮음	스케일링 응답성
리소스 가용성	온디맨드	사전 프로비저닝	즉시 스케줄링

네트워킹 고려사항

Fargate의 네트워킹 제약사항

Fargate는 AWS VPC 내에서 작동하지만 몇 가지 네트워킹 제약사항이 있다.

Host 네트워킹 모드 비지원: 각 파드는 자체 ENI(Elastic Network Interface)를 갖습니다
포트 매핑 제한: 동일한 포트에서 여러 서비스 실행 시 고려사항
로드 밸런서 통합: ALB/NLB와의 직접적인 통합이 간편함

# Fargate에서 ALB Ingress 사용 예시
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: fargate-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: fargate-service
            port:
              number: 80

EC2 Node Groups의 네트워킹 유연성

EC2 노드 그룹은 완전한 네트워킹 제어를 제공한다.

Host 네트워킹 지원: 성능이 중요한 애플리케이션에 유리
포트 바인딩 자유도: 동일 노드에서 여러 서비스의 동일 포트 사용 가능
CNI 플러그인 선택권: Calico, Weave 등 다양한 CNI 옵션

스토리지 옵션 상세 비교

Fargate 스토리지 제한사항

# Fargate에서 EFS 사용 예시
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: efs-claim
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: efs-sc
  resources:
    requests:
      storage: 5Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: fargate-efs-app
spec:
  template:
    spec:
      containers:
      - name: app
        image: nginx
        volumeMounts:
        - mountPath: "/data"
          name: efs-storage
      volumes:
      - name: efs-storage
        persistentVolumeClaim:
          claimName: efs-claim

EC2 Node Groups 스토리지 옵션

EBS 볼륨: 고성능 블록 스토리지
Instance Store: 임시 고성능 스토리지
EFS: 네트워크 파일 시스템
FSx: 고성능 파일 시스템

보안 아키텍처 심화

Fargate 보안 모델

# Fargate에서 Pod Security Context
apiVersion: v1
kind: Pod
metadata:
  name: secure-fargate-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: app
    image: nginx:alpine
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL

EC2 Node Groups 보안 강화

# 보안 그룹 설정
resource "aws_security_group" "worker_nodes" {
  name        = "eks-worker-nodes"
  description = "Security group for EKS worker nodes"
  vpc_id      = var.vpc_id

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = [var.admin_cidr]
  }

  ingress {
    from_port = 10250
    to_port   = 10250
    protocol  = "tcp"
    self      = true
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

파드 스케줄링 전략

Fargate 스케줄링 메커니즘

Fargate는 프로필을 사용하여 파드 배치를 결정하며, 네임스페이스 및 라벨 선택자를 기반으로 스케줄링 결정을 내린다.

EC2 Node Group 스케줄링 전략

EC2 노드 그룹은 정확한 워크로드 배치를 위해 노드 선택자, 어피니티 규칙, 테인트/톨러레이션을 포함한 고급 스케줄링 기법을 지원한다.

# 노드 어피니티를 사용한 고급 스케줄링
apiVersion: apps/v1
kind: Deployment
metadata:
  name: compute-intensive-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: compute-intensive-app
  template:
    metadata:
      labels:
        app: compute-intensive-app
    spec:
      nodeSelector:
        node-type: compute-optimized
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: instance-type
                operator: In
                values: ["c5.large", "c5.xlarge"]
      tolerations:
      - key: "high-compute"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"
      containers:
      - name: app
        image: compute-app:latest
        resources:
          requests:
            cpu: 1
            memory: 2Gi
          limits:
            cpu: 2
            memory: 4Gi

하이브리드 스케줄링 접근법

많은 조직에서 워크로드 특성과 요구사항에 따라 두 컴퓨팅 옵션을 결합한 하이브리드 전략을 구현한다.

실제 워크로드별 사용 사례

마이크로서비스 아키텍처

Fargate에서의 마이크로서비스

# 독립적인 마이크로서비스 배포
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
  namespace: microservices
spec:
  replicas: 3
  selector:
    matchLabels:
      app: user-service
  template:
    metadata:
      labels:
        app: user-service
        compute-type: fargate
    spec:
      containers:
      - name: user-service
        image: user-service:1.2.3
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: 200m
            memory: 256Mi
          limits:
            cpu: 500m
            memory: 512Mi
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-secret
              key: url

EC2에서의 마이크로서비스

# 리소스 집약적인 마이크로서비스
apiVersion: apps/v1
kind: Deployment
metadata:
  name: analytics-service
spec:
  replicas: 2
  selector:
    matchLabels:
      app: analytics-service
  template:
    metadata:
      labels:
        app: analytics-service
    spec:
      nodeSelector:
        workload-type: compute-intensive
      containers:
      - name: analytics-service
        image: analytics-service:2.1.0
        resources:
          requests:
            cpu: 2
            memory: 4Gi
          limits:
            cpu: 4
            memory: 8Gi

배치 처리 워크로드

Fargate Job 패턴

# Fargate에서 배치 작업
apiVersion: batch/v1
kind: Job
metadata:
  name: data-processing-job
spec:
  template:
    metadata:
      labels:
        compute-type: fargate
    spec:
      restartPolicy: Never
      containers:
      - name: data-processor
        image: data-processor:latest
        command: ["python", "process_data.py"]
        resources:
          requests:
            cpu: 1
            memory: 2Gi
          limits:
            cpu: 2
            memory: 4Gi
        env:
        - name: S3_BUCKET
          value: "data-processing-bucket"

ML/AI 워크로드 고려사항

GPU 지원 비교

# EC2에서 GPU 워크로드
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ml-training
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ml-training
  template:
    metadata:
      labels:
        app: ml-training
    spec:
      nodeSelector:
        accelerator: nvidia-tesla-k80
      containers:
      - name: ml-trainer
        image: tensorflow/tensorflow:latest-gpu
        resources:
          limits:
            nvidia.com/gpu: 1
            cpu: 4
            memory: 16Gi

모니터링 및 로깅 전략

CloudWatch 통합

Fargate 모니터링

# Fargate에서 사이드카 패턴을 통한 로깅
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-with-logging
spec:
  template:
    spec:
      containers:
      - name: app
        image: my-app:latest
        volumeMounts:
        - name: log-volume
          mountPath: /var/log
      - name: log-shipper
        image: fluent/fluent-bit:latest
        volumeMounts:
        - name: log-volume
          mountPath: /var/log
        - name: fluent-bit-config
          mountPath: /fluent-bit/etc/
      volumes:
      - name: log-volume
        emptyDir: {}
      - name: fluent-bit-config
        configMap:
          name: fluent-bit-config

EC2 Node Groups 모니터링

# DaemonSet을 통한 노드 레벨 모니터링
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      hostNetwork: true
      hostPID: true
      containers:
      - name: node-exporter
        image: prom/node-exporter:latest
        ports:
        - containerPort: 9100
          hostPort: 9100
        volumeMounts:
        - name: proc
          mountPath: /host/proc
          readOnly: true
        - name: sys
          mountPath: /host/sys
          readOnly: true
      volumes:
      - name: proc
        hostPath:
          path: /proc
      - name: sys
        hostPath:
          path: /sys

비용 최적화 고급 전략

Fargate 비용 최적화

리소스 요청 최적화

# 비용 분석 스크립트 예시
import boto3
import pandas as pd
from datetime import datetime, timedelta

def analyze_fargate_costs():
    """Fargate 비용 분석 및 최적화 권장사항"""
    
    # CloudWatch 메트릭 수집
    cloudwatch = boto3.client('cloudwatch')
    
    # CPU 및 메모리 사용률 조회
    end_time = datetime.utcnow()
    start_time = end_time - timedelta(days=7)
    
    cpu_metrics = cloudwatch.get_metric_statistics(
        Namespace='AWS/ECS',
        MetricName='CPUUtilization',
        Dimensions=[
            {'Name': 'ServiceName', 'Value': 'my-fargate-service'}
        ],
        StartTime=start_time,
        EndTime=end_time,
        Period=3600,
        Statistics=['Average', 'Maximum']
    )
    
    # 비용 최적화 권장사항 생성
    avg_cpu = sum(d['Average'] for d in cpu_metrics['Datapoints']) / len(cpu_metrics['Datapoints'])
    
    if avg_cpu < 30:
        print("권장사항: CPU 요청을 25% 감소시킬 수 있습니다.")
    elif avg_cpu > 80:
        print("권장사항: CPU 요청을 증가시켜 성능을 개선하세요.")
    
    return cpu_metrics

EC2 Node Groups 비용 최적화

스팟 인스턴스 활용 전략

# 혼합 인스턴스 정책
resource "aws_eks_node_group" "mixed_instances" {
  cluster_name    = aws_eks_cluster.main.name
  node_group_name = "mixed-instance-group"
  node_role_arn   = aws_iam_role.node_group.arn
  subnet_ids      = var.private_subnet_ids

  scaling_config {
    desired_size = 3
    max_size     = 10
    min_size     = 1
  }

  # 혼합 인스턴스 사용
  instance_types = ["m5.large", "m5a.large", "m4.large"]
  capacity_type  = "SPOT"

  # 스팟 인스턴스 중단 처리
  taint {
    key    = "node.kubernetes.io/spot"
    value  = "true"
    effect = "NO_SCHEDULE"
  }

  labels = {
    "node-type"     = "spot"
    "instance-type" = "mixed"
  }
}

재해 복구 및 고가용성

다중 AZ 배포 전략

Fargate 고가용성

# 다중 AZ에 걸친 Fargate 배포
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ha-fargate-app
spec:
  replicas: 6
  selector:
    matchLabels:
      app: ha-fargate-app
  template:
    metadata:
      labels:
        app: ha-fargate-app
        compute-type: fargate
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - ha-fargate-app
              topologyKey: topology.kubernetes.io/zone
      containers:
      - name: app
        image: my-app:latest
        resources:
          requests:
            cpu: 500m
            memory: 1Gi

EC2 Node Groups 고가용성

# 다중 AZ 노드 그룹 설정
resource "aws_eks_node_group" "ha_nodes" {
  cluster_name    = aws_eks_cluster.main.name
  node_group_name = "ha-node-group"
  node_role_arn   = aws_iam_role.node_group.arn
  
  # 다중 AZ 서브넷 지정
  subnet_ids = [
    var.private_subnet_1a,
    var.private_subnet_1b,
    var.private_subnet_1c
  ]

  scaling_config {
    desired_size = 6  # AZ당 2개씩
    max_size     = 15
    min_size     = 3   # AZ당 최소 1개
  }

  # 인스턴스 다양성 확보
  instance_types = ["m5.large", "m5a.large", "m5n.large"]
}

운영 고려사항

관리 오버헤드

운영 작업	Fargate	EC2 Node Groups	영향
OS 패치	AWS에서 관리	관리 필요	보안 규정 준수
용량 계획	자동	수동 계획 필요	리소스 효율성
노드 모니터링	필요 없음	완전한 모니터링 필요	운영 복잡성
스케일링 관리	자동	Cluster Autoscaler 설정	응답성

보안 영향

Fargate는 파드 수준 격리를 통해 향상된 보안을 제공하는 반면, EC2 노드 그룹은 더 세분화된 보안 제어를 제공하지만 추가 구성이 필요하다.

모니터링 및 관찰 가능성

두 컴퓨팅 옵션 모두 CloudWatch Container Insights와 통합되지만, EC2 노드 그룹은 추가적인 노드 수준 메트릭 및 모니터링 기능을 제공한 다.

의사결정 프레임워크

Fargate 최적 시나리오

배치 처리: 예측할 수 없는 리소스 요구사항을 가진 단기, 가변 워크로드
마이크로서비스: 최소한의 리소스 요구사항을 가진 소규모 독립 서비스
개발/테스트: 신속한 프로비저닝 및 해체가 필요한 환경
보안 중요: 향상된 격리 및 규정 준수가 필요한 워크로드

EC2 Node Groups 최적 시나리오

장시간 실행 애플리케이션: 일관된 리소스 활용률을 가진 지속적인 서비스
고성능 컴퓨팅: 전용 리소스가 필요한 CPU 또는 메모리 집약적 워크로드
시스템 서비스: DaemonSets, 모니터링 에이전트 및 인프라 구성 요소
비용 최적화: 리소스 활용률이 60-70%를 초과하는 환경

하이브리드 아키텍처 장점

대부분의 엔터프라이즈 환경은 두 컴퓨팅 옵션을 전략적으로 활용하는 하이브리드 접근법의 이점을 얻는다.

하이브리드 EKS 아키텍처 예시

Fargate 워크로드:
- 배치 작업
- 개발 서비스  
- API 게이트웨이

EC2 Node Groups:
- 시스템 노드: 모니터링 스택, Ingress 컨트롤러
- 애플리케이션 노드: 데이터베이스, 캐싱 레이어
- 컴퓨팅 노드: ML 학습, GPU 워크로드

모범 사례 및 권장사항

리소스 최적화 전략

적정 크기 조정: 실제 워크로드 요구사항에 맞는 컴퓨팅 리소스 매칭
프로필 설계: 특정 워크로드 패턴을 위한 대상화된 Fargate 프로필 생성
노드 다양화: 유연성을 위한 EC2 노드 그룹에서 여러 인스턴스 유형 사용
스팟 통합: 내결함성 워크로드를 위한 스팟 인스턴스 활용

비용 관리 접근법

리소스 모니터링: 포괄적인 비용 추적 및 할당 구현
스케줄링 최적화: 활용률 극대화를 위한 적절한 스케줄링 전략 사용
예약 용량: 예측 가능한 워크로드에 대한 예약 인스턴스 고려
자동 스케일링 구성: 비용 효율성을 위한 스케일링 매개변수 세밀 조정

보안 강화

# Pod 보안 표준 구현
apiVersion: v1
kind: Namespace
metadata:
  name: secure-workloads
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: secure-workloads
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

마무리

Amazon EKS에서 Fargate와 EC2 Node Groups 사이의 선택은 현대 클라우드 인프라 전략의 핵심적인 결정 중 하나이다. 이 글을 통해 살펴본 바와 같이, 각 옵션은 고유한 강점과 제약사항을 가지고 있으며, 최적의 선택은 조직의 구체적인 요구사항과 컨텍스트에 따라 달라진다.

운영의 단순성 vs 제어의 유연성이라는 근본적인 트레이드오프가 존재한다. Fargate는 인프라 관리의 복잡성을 제거하여 개발팀이 비즈니스 로직에 집중할 수 있게 하는 반면, EC2 Node Groups는 세밀한 최적화와 커스터마이제이션을 통해 최대 성능과 비용 효율성을 달성할 수 있게 한다.

클라우드 네이티브 생태계는 지속적으로 발전하고 있으며, 서버리스와 컨테이너 기술의 융합은 더욱 정교해지고 있다. Fargate는 서버리스 컴퓨팅의 미래를 보여주는 한편, EC2 Node Groups는 여전히 엔터프라이즈급 워크로드의 백본 역할을 수행하고 있다.

실제 프로덕션 환경에서는 대부분의 조직이 두 접근법을 전략적으로 조합하여 사용한다. 이는 각 워크로드의 특성에 가장 적합한 컴퓨팅 환경을 제공하면서도, 운영 복잡성과 비용을 균형있게 관리할 수 있는 현실적인 솔루션이다.

Kubernetes와 서버리스 기술의 지속적인 혁신을 고려할 때, 앞으로는 더욱 정교한 워크로드 배치 전략과 자동화된 최적화 도구들이 등장할 것으로 예상된다. 머신러닝 기반의 리소스 예측과 동적 스케줄링, 그리고 멀티 클라우드 환경에서의 워크로드 분산이 새로운 표준이 될 가능성이 높다.

이 분석을 바탕으로 조직에서 고려해야 할 구체적인 액션 아이템들을 제시한다.

현재 워크로드 프로파일링: 기존 애플리케이션들의 리소스 사용 패턴, 스케일링 요구사항, 보안 제약사항을 체계적으로 분석
파일럿 프로젝트 실행: 대표적인 워크로드를 선정하여 두 옵션 모두에서 테스트 실행 후 성능, 비용, 운영성 비교
비용 모델링 구축: 실제 사용 패턴을 기반으로 한 정확한 TCO(Total Cost of Ownership) 계산
운영 프로세스 정의: 각 컴퓨팅 옵션에 맞는 모니터링, 배포, 문제 해결 프로세스 수립
팀 역량 개발: DevOps 팀의 Kubernetes 및 서버리스 기술 숙련도 향상을 위한 교육 계획 수립

클라우드 환경에서는 "설정하고 잊어버리는" 접근법이 통하지 않는다. 비즈니스 요구사항의 변화, 새로운 AWS 서비스의 출시, 그리고 애플리케이션 사용 패턴의 진화에 따라 컴퓨팅 전략을 지속적으로 재평가하고 조정해야 한다. 정기적인 비용 리뷰, 성능 벤치마킹, 그리고 보안 감사를 통해 최적의 상태를 유지하는 것이 핵심이다.

Kubernetes와 AWS 생태계는 활발한 오픈소스 커뮤니티에 의해 지원된다. 지속적인 학습과 커뮤니티 참여를 통해 새로운 베스트 프랙티스와 도구들을 파악하고 적용하는 것이 중요하다. CNCF(Cloud Native Computing Foundation)의 프로젝트들과 AWS의 새로운 서비스 발표를 주시하며, 조직의 기술 스택을 현대적으로 유지해야 한다.

결론적으로, EKS Fargate와 EC2 Node Groups는 상호 보완적인 기술로 이해되어야 한다. 성공적인 클라우드 네이티브 전환을 위해서는:

단계적 접근: 복잡성이 낮은 워크로드부터 시작하여 점진적으로 확장
데이터 기반 의사결정: 추측이 아닌 실제 메트릭과 비용 데이터를 기반으로 한 선택
지속적인 학습: 기술 발전에 따른 지속적인 역량 개발과 아키텍처 개선
문화적 변화: 기술 도입과 함께 조직 문화와 프로세스의 동반 변화

이러한 접근을 통해 조직은 Kubernetes의 강력한 기능을 최대한 활용하면서도, 각자의 비즈니스 목표에 가장 적합한 컴퓨팅 전략을 구축할 수 있을 것이다.

클라우드 네이티브의 여정은 목적지가 아닌 지속적인 개선과 혁신의 과정임을 기억하며, 변화하는 비즈니스 환경에 유연하게 대응할 수 있는 기술적 기반을 마련하는 것이 무엇보다 중요하다.

Reference

Somaz | DevOps Engineer | Kubernetes & Cloud Infrastructure Specialist

온프레미스 환경에서 Ollama + Open WebUI로 사내 LLM 구축하기

Somaz — Wed, 11 Feb 2026 00:00:44 +0900

Overview

최근 AI 기술의 발전으로 ChatGPT, Claude 같은 상용 LLM 서비스가 대중화되었지만, 보안이 중요한 기업 환경에서는 민감한 데이터를 외부 API로 전송하기 어려운 경우가 많다. 이러한 상황에서 온프레미스 환경에 자체 LLM을 구축하면 데이터 보안을 유지하면서도 AI의 이점을 활용할 수 있다.

이번 글에서는 NVIDIA GPU가 장착된 물리 서버에 Ollama를 설치하고, Open WebUI를 통해 웹 인터페이스를 제공하는 사내 LLM 시스템을 구축하는 전체 과정을 다룬다.

NFS를 활용한 스토리지 관리와 Docker Compose를 이용한 컨테이너 오케스트레이션까지 포함하여 실무에 바로 적용 가능한 완전한 솔루션을 제시한다.

시스템 구성 및 사전 요구사항

하드웨어 환경

본 구성에서 사용한 시스템 스펙은 다음과 같다.

GPU 서버 (192.168.1.20)

CPU: Intel Xeon 6코어
RAM: 32GB
GPU: NVIDIA GeForce RTX 3060 12GB
OS: Ubuntu 24.04 LTS
용도: Ollama 서버

웹 서버 (192.168.1.21)

CPU: 4코어
RAM: 16GB
OS: Ubuntu 24.04 LTS
용도: Open WebUI

스토리지 서버 (192.168.1.25)

NFS 서버: /storage/ai-data 공유

GPU 호환성 확인

먼저 설치된 GPU의 스펙을 확인한다.

lspci | grep -iE "vga|display|3d"
# 01:00.0 VGA compatible controller: NVIDIA Corporation GA106 [GeForce RTX 3060]

RTX 3060의 주요 스펙

아키텍처: Ampere (GA106)
CUDA 코어: 3,584개
VRAM: 12GB GDDR6
CUDA Compute Capability: 8.6
권장 드라이버: 525+ (535 안정적)

1단계: NVIDIA 드라이버 설치

Secure Boot 상태 확인

mokutil --sb-state
# SecureBoot disabled 또는 SecureBoot enabled 확인

Secure Boot이 활성화되어 있으면 드라이버 설치 후 MOK(Machine Owner Key) 등록 과정이 필요하다.

사용 가능한 드라이버 버전 확인

# 저장소에서 사용 가능한 버전 확인
apt-cache search nvidia-driver

# 특정 버전의 상세 정보 확인
apt-cache show nvidia-driver-535 | grep Version
# Version: 535.288.01-0ubuntu0.24.04.1

또는 NVIDIA 공식 웹사이트에서 최신 버전 확인

URL: https://www.nvidia.com/Download/index.aspx
Product Type: GeForce
Product Series: GeForce RTX 30 Series
Product: GeForce RTX 3060
Operating System: Linux 64-bit

드라이버 설치 및 확인

# 시스템 업데이트
sudo apt update

# NVIDIA 드라이버 설치
sudo apt install -y nvidia-driver-535

# 시스템 재부팅
sudo reboot

재부팅 후 Secure Boot이 활성화되어 있다면 파란색 MOK 관리 화면이 나타난다.

"Enroll MOK" 선택
"Continue" 선택
설치 시 설정한 비밀번호 입력
"Reboot" 선택

설치 확인

nvidia-smi

# 정상 설치 시 GPU 정보와 드라이버 버전이 출력된다.


Wed Feb  5 10:15:23 2026       
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.288.01             Driver Version: 535.288.01   CUDA Version: 12.2     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|=========================================+======================+======================|
|   0  NVIDIA GeForce RTX 3060        Off | 00000000:01:00.0 Off |                  N/A |
|  0%   35C    P8              15W / 170W |      0MiB / 12288MiB |      0%      Default |
+-----------------------------------------+----------------------+----------------------+

2단계: Docker 및 NVIDIA Container Toolkit 설치

Docker 설치

# Docker 설치 확인
docker --version

# 없을 경우 설치
sudo apt update
sudo apt install -y docker.io
sudo systemctl enable --now docker

# 현재 사용자를 docker 그룹에 추가 (선택사항)
sudo usermod -aG docker $USER

NVIDIA Container Toolkit 설치

Docker 컨테이너에서 GPU를 사용하기 위해 NVIDIA Container Toolkit이 필요하다.

# GPG 키 추가
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \
  sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

# 저장소 추가
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

# 패키지 설치
sudo apt update
sudo apt install -y nvidia-container-toolkit

Docker 런타임 설정

# Docker에 NVIDIA 런타임 설정
sudo nvidia-ctk runtime configure --runtime=docker

# Docker 서비스 재시작
sudo systemctl restart docker

GPU 접근 테스트

docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi

정상적으로 GPU 정보가 출력되면 설정 완료이다.

3단계: NFS 스토리지 구성

여러 서버에서 모델 파일과 데이터를 공유하기 위해 NFS를 구성한다.

클라이언트 설치 및 마운트

# NFS 클라이언트 설치
sudo apt install -y nfs-common

# 마운트 포인트 생성
sudo mkdir -p /data/llm-models
sudo mkdir -p /data/webui-storage

# NFS 마운트
sudo mount -t nfs4 192.168.1.25:/storage/ai-data/models /data/llm-models
sudo mount -t nfs4 192.168.1.25:/storage/ai-data/webui /data/webui-storage

# 확인
df -h | grep nfs

영구 마운트 설정

재부팅 후에도 자동으로 마운트되도록 `/etc/fstab` 을 설정한다.

sudo nano /etc/fstab

# 다음 줄 추가
192.168.1.25:/storage/ai-data/models  /data/llm-models     nfs4  defaults,_netdev,rw  0  0
192.168.1.25:/storage/ai-data/webui   /data/webui-storage  nfs4  defaults,_netdev,rw  0  0

설정 확인

sudo mount -a
df -h | grep nfs

권한 설정

# Ollama 데이터 디렉토리
sudo chown -R root:root /data/llm-models
sudo chmod 755 /data/llm-models

# Open WebUI 데이터 디렉토리
sudo chown -R root:root /data/webui-storage
sudo chmod 755 /data/webui-storage

4단계: Docker 네트워크 구성

Ollama와 Open WebUI가 통신할 수 있도록 공유 네트워크를 생성한다.

# Docker 브리지 네트워크 생성
docker network create ai_network

# 확인
docker network ls
# NETWORK ID     NAME         DRIVER    SCOPE
# abc123def456   ai_network   bridge    local

5단계: Ollama 서버 구축 (GPU 서버)

Docker Compose 파일 생성

cat > /opt/ollama/docker-compose.yml << 'EOF'
version: '3.8'

services:
  ollama:
    image: ollama/ollama:0.15.4
    container_name: ollama-server
    restart: unless-stopped
    runtime: nvidia
    
    ports:
      - "11434:11434"
    
    volumes:
      - /data/llm-models:/root/.ollama
    
    environment:
      # 모델 메모리 유지 시간 설정
      # -1: 영구 유지 (언로드 안 함, 항상 메모리에 상주)
      # 0: 즉시 언로드 (사용 후 바로 메모리 해제)
      # 5m: 5분 후 언로드 (기본값)
      # 30m: 30분 후 언로드
      # 1h: 1시간 후 언로드
      # 
      # -1 설정 시:
      #   장점: 첫 응답 이후 매번 빠른 응답 (로딩 시간 없음)
      #   단점: VRAM 계속 점유 (qwen2.5-coder:14b = ~8GB 상시 사용)
      # 
      # 권장: 자주 사용하면 -1, 가끔 사용하면 30m
      - OLLAMA_KEEP_ALIVE=-1
      - NVIDIA_VISIBLE_DEVICES=all
      - OLLAMA_ORIGINS=*
    
    networks:
      - ai_network

networks:
  ai_network:
    name: ai_network
    external: true
EOF

환경변수 설명

OLLAMA_KEEP_ALIVE: 모델 메모리 유지 시간
- -1: 영구 유지 (첫 로딩 후 항상 메모리에 상주)
- 5m: 5분 후 자동 언로드 (기본값)
- 30m: 30분 후 언로드 (권장)
- 0: 즉시 언로드
NVIDIA_VISIBLE_DEVICES=all: 모든 GPU 사용
OLLAMA_ORIGINS=*: CORS 허용 (선택사항)

KEEP_ALIVE 설정 가이드

자주 사용 (1일 10회 이상): -1 (영구 유지) → 빠른 응답
가끔 사용 (1일 3~10회): 30m 또는 1h → 균형
드물게 사용 (1일 1~2회): 5m (기본값) → 메모리 절약

컨테이너 실행

# 디렉토리 이동
cd /opt/ollama

# 컨테이너 실행
docker-compose up -d

# 로그 확인
docker-compose logs -f

# 상태 확인
docker-compose ps

GPU 사용 확인

# 컨테이너 내부에서 nvidia-smi 실행
docker exec -it ollama-server nvidia-smi

# NFS 마운트 확인
docker exec -it ollama-server df -h /root/.ollama

LLM 모델 다운로드

Ollama는 https://ollama.com/library 에서 다양한 모델을 제공한다.

RTX 3060 12GB 기준 권장 모델은 다음과 같다.

1) DeepSeek-Coder-V2 16B (코딩 특화, 10GB)

docker exec -it ollama-server ollama pull deepseek-coder-v2:16b

2) Qwen2.5-Coder 14B (코딩, 9.7GB)

docker exec -it ollama-server ollama pull qwen2.5-coder:14b

3) Qwen3 14B (범용, 11GB)

docker exec -it ollama-server ollama pull qwen3:14b

4) Qwen2.5-Coder 32B (고성능 코딩, 21GB - CPU 오프로딩)

docker exec -it ollama-server ollama pull qwen2.5-coder:32b

모델 다운로드 확인

ls -lh /data/llm-models/models/

모델 테스트

# DeepSeek 16B 테스트
docker exec -it ollama-server ollama run deepseek-coder-v2:16b
>>> Write a Python function to reverse a string

# 종료: Ctrl+D 또는 /bye

모델별 성능 비교 (RTX 3060 12GB 기준)

DeepSeek-Coder-V2 16B (10GB)

docker exec -it ollama-server ollama ps

NAME                     ID              SIZE     PROCESSOR    CONTEXT
deepseek-coder-v2:16b    63fb193b3a9b    10 GB    100% GPU     4096


## 메모리 사용량
|   0  NVIDIA GeForce RTX 3060        Off | 00000000:01:00.0 Off |                  N/A |
|  0%   49C    P2              26W / 170W |   9898MiB / 12288MiB |      0%      Default |

Qwen2.5-Coder 14B (9.7GB)

NAME                 ID              SIZE      PROCESSOR    CONTEXT
qwen2.5-coder:14b    9ec8897f747e    9.7 GB    100% GPU     4096


## 메모리 사용량:
|   0  NVIDIA GeForce RTX 3060        Off | 00000000:01:00.0 Off |                  N/A |
|  0%   50C    P2              44W / 170W |   9482MiB / 12288MiB |      0%      Default |

Qwen2.5-Coder 32B (21GB - CPU 오프로딩)

NAME                 ID              SIZE     PROCESSOR          CONTEXT
qwen2.5-coder:32b    b92d6a0bd47e    21 GB    45%/55% CPU/GPU    4096


## 메모리 사용량:
|   0  NVIDIA GeForce RTX 3060        Off | 00000000:01:00.0 Off |                  N/A |
|  0%   60C    P2              60W / 170W |  11476MiB / 12288MiB |     17%      Default |

성능 분석 및 권장사항

모델	크기	VRAM	처리 방식	속도추천	용도
DeepSeek 16B	10GB	9.9GB	100% GPU	★★★★★	실시간 코딩 지원 (가장 빠름)
Qwen2.5 14B	9.7GB	9.5GB	100% GPU	★★★★☆	일반 코딩 작업
Qwen3 14B	11GB	11GB	100% GPU	★★★★☆	복잡한 추론/논리 작업
Qwen2.5 32B	21GB	11.5GB	45% CPU 55% GPU	★★☆☆☆	고품질 결과 필요 시 (속도 5배 이상 느림)

핵심 포인트

VRAM 12GB 이하 모델 → 100% GPU 처리 → 빠른 응답
VRAM 12GB 초과 모델 → CPU 오프로딩 → 매우 느린 응답
실무 권장: DeepSeek 16B (속도와 성능의 균형)

모델 관리 명령어

# 실행 중인 모델 확인
docker exec -it ollama-server ollama ps

# 모델 언로드 (메모리 확보)
docker exec -it ollama-server ollama stop deepseek-coder-v2:16b
docker exec -it ollama-server ollama stop qwen2.5-coder:32b

# 모델 삭제
docker exec -it ollama-server ollama rm qwen2.5-coder:32b

# 설치된 모든 모델 목록
docker exec -it ollama-server ollama list

6단계: Open WebUI 구축 (웹 서버)

Open WebUI는 ChatGPT와 유사한 웹 인터페이스를 제공하는 오픈소스 프로젝트다.

Docker Compose 파일 생성

cat > /opt/open-webui/docker-compose.yml << 'EOF'
version: '3.8'

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped
    
    ports:
      - "8080:8080"
    
    volumes:
      - /data/webui-storage:/app/backend/data
    
    environment:
      - OLLAMA_BASE_URL=http://192.168.1.20:11434
      - WEBUI_SECRET_KEY=your-random-secret-key-change-this
      - WEBUI_NAME=Company AI Assistant
      - DEFAULT_MODELS=deepseek-coder-v2:16b,qwen2.5-coder:14b
    
    networks:
      - ai_network

networks:
  ai_network:
    name: ai_network
    external: true
EOF

환경변수 설명

OLLAMA_BASE_URL: Ollama 서버 주소 (컨테이너 간 통신 시 서비스명 또는 IP 사용)
WEBUI_SECRET_KEY: 세션 암호화 키 (랜덤 문자열로 변경 필수)
WEBUI_NAME: 웹 UI 타이틀
DEFAULT_MODELS: 기본 표시 모델 목록

주의사항

같은 Docker 네트워크 내에서는 http://ollama-server:11434 형식으로 통신 가능
다른 물리 서버에 있다면 IP 주소 사용 (http://192.168.1.20:11434)

컨테이너 실행

# 디렉토리 이동
cd /opt/open-webui

# 실행
docker-compose up -d

# 로그 확인
docker-compose logs -f

# 상태 확인
docker-compose ps

웹 인터페이스 접속

브라우저에서 `http://192.168.1.21:8080` 접속한다.

초기 설정

회원가입 (첫 사용자는 자동으로 관리자)
설정 → 모델 → Ollama 연결 확인
대화 시작

7단계: API 연동 및 활용

Open WebUI는 OpenAI 호환 API를 제공하여 프로그래밍 방식으로 접근할 수 있다.

API 키 발급

웹 UI 로그인
설정 → Account → API Keys
"Create new secret key" 클릭
생성된 키 복사 (예: sk-abc123def456...)

API 호출 예제

cURL 테스트

curl -X POST http://192.168.1.21:8080/api/chat/completions \
  -H "Authorization: Bearer sk-abc123def456..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-coder-v2:16b",
    "messages": [
      {
        "role": "user",
        "content": "파이썬으로 피보나치 수열 함수를 작성해줘"
      }
    ],
    "stream": false
  }'

Python 예제

import requests
import json

API_URL = "http://192.168.1.21:8080/api/chat/completions"
API_KEY = "sk-abc123def456..."

headers = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json"
}

payload = {
    "model": "deepseek-coder-v2:16b",
    "messages": [
        {
            "role": "system",
            "content": "당신은 파이썬 전문 코딩 어시스턴트다."
        },
        {
            "role": "user",
            "content": "이진 탐색 알고리즘을 구현해줘"
        }
    ],
    "temperature": 0.7,
    "max_tokens": 2000
}

response = requests.post(API_URL, headers=headers, json=payload)
result = response.json()

print(result['choices'][0]['message']['content'])

스트리밍 응답 예제

import requests
import json

payload = {
    "model": "qwen2.5-coder:14b",
    "messages": [
        {"role": "user", "content": "REST API란 무엇인지 설명해줘"}
    ],
    "stream": True
}

response = requests.post(
    API_URL, 
    headers=headers, 
    json=payload, 
    stream=True
)

for line in response.iter_lines():
    if line:
        decoded = line.decode('utf-8')
        if decoded.startswith('data: '):
            data = json.loads(decoded[6:])
            if 'choices' in data:
                content = data['choices'][0]['delta'].get('content', '')
                print(content, end='', flush=True)

8단계: 모니터링 및 유지보수

GPU 모니터링

실시간 GPU 사용량 확인

watch -n 1 nvidia-smi

로그 기반 모니터링

# GPU 사용률 로그
nvidia-smi --query-gpu=timestamp,name,temperature.gpu,utilization.gpu,utilization.memory,memory.used,memory.total \
  --format=csv -l 5 >> /var/log/gpu-usage.log

# 분석
tail -f /var/log/gpu-usage.log

Docker 컨테이너 관리

# Ollama 재시작
cd /opt/ollama
docker-compose restart

# Open WebUI 재시작
cd /opt/open-webui
docker-compose restart

# 로그 확인 (최근 100줄)
docker-compose logs --tail 100 ollama
docker-compose logs --tail 100 open-webui

# 리소스 사용량 확인
docker stats

백업 전략

모델 파일 백업

# NFS 디렉토리 백업
sudo rsync -avz /data/llm-models/ /backup/llm-models-$(date +%Y%m%d)/

Open WebUI 데이터 백업

# 사용자 설정 및 대화 내역
sudo rsync -avz /data/webui-storage/ /backup/webui-storage-$(date +%Y%m%d)/

자동 백업 스크립트

cat > /usr/local/bin/backup-ai-system.sh << 'EOF'
#!/bin/bash

BACKUP_DIR="/backup/ai-system"
DATE=$(date +%Y%m%d_%H%M%S)

# 백업 디렉토리 생성
mkdir -p ${BACKUP_DIR}/${DATE}

# 모델 백업 (심볼릭 링크 사용)
ln -sf /data/llm-models ${BACKUP_DIR}/${DATE}/models

# WebUI 데이터 백업
rsync -az /data/webui-storage/ ${BACKUP_DIR}/${DATE}/webui/

# 7일 이상 된 백업 삭제
find ${BACKUP_DIR} -type d -mtime +7 -exec rm -rf {} +

echo "Backup completed: ${BACKUP_DIR}/${DATE}"
EOF

chmod +x /usr/local/bin/backup-ai-system.sh

# Cron 등록 (매일 새벽 2시)
(crontab -l 2>/dev/null; echo "0 2 * * * /usr/local/bin/backup-ai-system.sh >> /var/log/ai-backup.log 2>&1") | crontab -

트러블슈팅

GPU 인식 안됨

증상: `docker exec -it ollama-server nvidia-smi` 실패

해결

# 드라이버 재설치
sudo apt purge -y nvidia-*
sudo apt install -y nvidia-driver-535
sudo reboot

# Container Toolkit 재설정
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Ollama 응답 느림 (32B 모델)

증상: 응답이 매우 느림, GPU 메모리 부족

해결: 작은 모델 사용 또는 GPU 업그레이드

# 메모리 효율적인 모델로 전환
docker exec -it ollama-server ollama stop qwen2.5-coder:32b
docker exec -it ollama-server ollama run deepseek-coder-v2:16b

NFS 마운트 실패

증상: mount.nfs4: Connection timed out

해결

# NFS 서버 확인
showmount -e 192.168.1.25

# 방화벽 확인 (NFS 서버에서)
sudo ufw allow from 192.168.1.0/24 to any port nfs

# 재마운트
sudo umount /data/llm-models
sudo mount -a

Open WebUI 연결 오류

증상: "Failed to connect to Ollama"

해결

# Ollama API 테스트
curl http://192.168.1.20:11434/api/tags

# 네트워크 확인
docker network inspect ai_network

# 환경변수 수정
cd /opt/open-webui
docker-compose down
# docker-compose.yml에서 OLLAMA_BASE_URL 수정 후
docker-compose up -d

모델 로딩 시간 길어짐

증상: 첫 요청 시 응답까지 10~30초 소요

해결: OLLAMA_KEEP_ALIVE 설정 조정

# docker-compose.yml 수정
environment:
  - OLLAMA_KEEP_ALIVE=-1  # 영구 유지로 변경

# 재시작
cd /opt/ollama
docker-compose down
docker-compose up -d

보안 고려사항

리버스 프록시 설정 (Nginx)

외부 접근 시 HTTPS 적용을 권장한다.

# /etc/nginx/sites-available/ai-assistant
server {
    listen 443 ssl http2;
    server_name ai.company.com;
    
    ssl_certificate /etc/letsencrypt/live/ai.company.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ai.company.com/privkey.pem;
    
    location / {
        proxy_pass http://192.168.1.21:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        
        # WebSocket 지원
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

사용자 접근 제어

Open WebUI 관리자 페이지에서 다음을 설정한다:

Settings → Users → User Permissions
사용자별 모델 접근 권한 설정
일일 요청 제한 설정

성능 최적화 팁

1. 모델 사전 로딩

자주 사용하는 모델을 미리 메모리에 로드한다.

# systemd 서비스 생성
cat > /etc/systemd/system/ollama-preload.service << 'EOF'
[Unit]
Description=Ollama Model Preloader
After=docker.service
Requires=docker.service

[Service]
Type=oneshot
ExecStart=/usr/bin/docker exec ollama-server ollama run deepseek-coder-v2:16b ""
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl enable ollama-preload
sudo systemctl start ollama-preload

2. Context Window 조정

긴 대화 시 성능 저하를 방지한다.

# API 호출 시 max_tokens 제한
payload = {
    "model": "deepseek-coder-v2:16b",
    "messages": messages,
    "max_tokens": 1024,  # 적절한 값으로 제한
    "temperature": 0.7
}

3. 배치 처리

여러 요청을 동시에 처리해야 할 경우 설정을 조정한다.

# docker-compose.yml에 추가
environment:
  - OLLAMA_NUM_PARALLEL=2
  - OLLAMA_MAX_LOADED_MODELS=2

4. KEEP_ALIVE 최적화 전략

사용 패턴에 따른 권장 설정

시나리오 1: 개발팀 전용 (하루 종일 사용)

environment:
  - OLLAMA_KEEP_ALIVE=-1  # 영구 유지

시나리오 2: 부서 공유 (업무 시간만 사용)

environment:
  - OLLAMA_KEEP_ALIVE=1h  # 1시간 유지

시나리오 3: 간헐적 사용 (가끔 필요)

environment:
  - OLLAMA_KEEP_ALIVE=5m  # 기본값

마무리

이번 글에서는 온프레미스 환경에서 Ollama와 Open WebUI를 활용한 사내 LLM 시스템을 구축하는 전체 과정을 다뤘다. NVIDIA GPU 드라이버 설치부터 Docker Compose를 이용한 컨테이너 오케스트레이션, NFS 스토리지 연동, 그리고 실제 운영에 필요한 모니터링과 백업 전략까지 실무에 바로 적용 가능한 내용으로 구성했다.

핵심 요약

RTX 3060 12GB 기준: DeepSeek 16B 모델이 속도와 성능 면에서 최적
Docker Compose 활용: 컨테이너 관리를 선언적으로 정의하여 유지보수 용이
KEEP_ALIVE 설정: 사용 패턴에 맞춰 -1, 30m, 5m 중 선택
NFS 활용: 여러 서버 간 모델 파일 공유로 스토리지 효율 극대화
API 연동: OpenAI 호환 API로 기존 워크플로우 통합 가능

특히 보안이 중요한 금융, 헬스케어, 정부 기관 등에서는 데이터를 외부로 전송하지 않고도 AI의 이점을 활용할 수 있다는 점에서 온프레미스 LLM 구축이 큰 가치를 제공한다. 초기 구축 비용이 들지만 장기적으로는 API 사용료 절감과 데이터 주권 확보라는 두 마리 토끼를 잡을 수 있다.

향후에는 모델 파인튜닝, RAG(Retrieval-Augmented Generation) 시스템 통합, 그리고 Kubernetes 환경에서의 오케스트레이션 등 고급 주제로 시리즈를 이어가겠다.

Reference

Ollama 공식 문서: https://github.com/ollama/ollama
Open WebUI 공식 저장소: https://github.com/open-webui/open-webui
NVIDIA Container Toolkit: https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/

Somaz | DevOps Engineer | Kubernetes & Cloud Infrastructure Specialist

Docker 이미지 최적화 실전 가이드

Somaz — Tue, 10 Feb 2026 00:00:13 +0900

Overview

개인적으로 이 주제를 깊이 파보고 싶었다. DevOps 엔지니어로 일하면서 비대한 Docker 이미지가 늘 골칫거리였기 때문이다. 특히 Python의 머신러닝 스택이나 Go의 개발 도구들이 포함된 이미지들은 종종 1GB를 넘어가곤 한다.

최근 개인 프로젝트로 다양한 최적화 기법들을 실험해 봤는데, 초기 이미지 크기가 너무 커서 로컬 개발 환경의 디스크 공간을 많이 차지하는 문제가 있었다.

배포 시간: 긴 이미지 빌드 및 전송 시간
개발 환경: 로컬 디스크 공간 부족
보안 취약점: 불필요한 패키지로 인한 잠재적 위험

몇 주간 다양한 최적화 기법을 실험한 결과, 개인 프로젝트의 Python FastAPI 서비스를 1.96GB에서 305MB로, Go API 서버를 1.54GB에서 30MB로 줄이는 데 성공했다.

이번 글에서는 개인적으로 검증해본 Docker 이미지 최적화 전략을 두 언어로 나누어 소개하겠다.

Docker 이미지 최적화 실전 가이드

왜 이미지 크기가 중요한가?

실제 운영에서 마주친 문제들

배포 지연 문제

1.2GB 이미지 → 새 인스턴스 시작까지 8분 소요
오토스케일링 시 급격한 트래픽 증가에 대응 불가
장애 발생 시 복구 시간 증가

인프라 비용 폭증

AWS ECR 비용: 월 $300 → $1,200 (4배 증가)
EKS 노드 디스크 풀 문제로 인한 스케일 아웃 필요
네트워크 비용 증가 (이미지 pull 트래픽)

보안 위험 증대

불필요한 패키지로 인한 CVE 취약점 300개 이상
컨테이너 스캔 시간 10분 → CI/CD 속도 저하
런타임 공격 표면 확대

최종 결과 미리보기

언어	단계	이미지 크기	감소율	누적 감소율
Python	기본 (python:latest)	1.96GB	-	-
	slim 버전	703MB	64%	64%
	alpine 버전	352MB	50%	82%
	멀티스테이지	305MB	13%	84%
Go	기본 (golang:latest)	1.54GB	-	-
	alpine 버전	628MB	59%	59%
	멀티스테이지	30MB	95%	98%
	scratch 베이스	15.3MB	49%	99%

Python FastAPI 최적화 단계별 가이드

예제 애플리케이션 준비

실제 운영 환경과 유사한 FastAPI 애플리케이션을 만들어보겠다.

# main.py
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import pandas as pd
import numpy as np
from datetime import datetime
import uvicorn
import os

app = FastAPI(title="ML Prediction API", version="1.0.0")

# 데이터 모델
class PredictionRequest(BaseModel):
    features: list[float]
    model_name: str = "linear"

class PredictionResponse(BaseModel):
    prediction: float
    confidence: float
    timestamp: str

# 간단한 ML 모델 시뮬레이션
class SimpleModel:
    def __init__(self):
        # 실제로는 pickle로 로드된 모델일 것
        self.weights = np.random.randn(10)
        
    def predict(self, features):
        if len(features) != len(self.weights):
            raise ValueError("Feature dimension mismatch")
        
        prediction = np.dot(features, self.weights)
        confidence = min(0.95, abs(prediction) / 10)
        return prediction, confidence

model = SimpleModel()

@app.get("/")
async def root():
    return {
        "service": "ML Prediction API",
        "status": "healthy",
        "timestamp": datetime.now().isoformat()
    }

@app.get("/health")
async def health_check():
    return {
        "status": "ok",
        "memory_usage": pd.DataFrame({"test": [1, 2, 3]}).memory_usage(deep=True).sum()
    }

@app.post("/predict", response_model=PredictionResponse)
async def predict(request: PredictionRequest):
    try:
        if len(request.features) != 10:
            raise HTTPException(status_code=400, detail="Expected 10 features")
            
        prediction, confidence = model.predict(request.features)
        
        return PredictionResponse(
            prediction=float(prediction),
            confidence=float(confidence),
            timestamp=datetime.now().isoformat()
        )
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

if __name__ == "__main__":
    port = int(os.getenv("PORT", 8000))
    uvicorn.run(app, host="0.0.0.0", port=port)

# requirements.txt
fastapi==0.104.1
uvicorn[standard]==0.24.0
pandas==2.2.0  # Python 3.13 호환 버전
numpy==1.26.0   # 최신 버전
pydantic==2.5.0

1단계: 기본 베이스라인 (1.42GB)

# Dockerfile.step1
FROM python:3.12

WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .

EXPOSE 8000
CMD ["python", "main.py"]

docker build -f Dockerfile.step1 -t ml-api:step1 .
docker images | grep ml-api
# ml-api    step1    1.96GB

문제점: 전체 Debian 시스템 + Python 개발 도구 + 컴파일러 모두 포함

2단계: Slim 베이스 이미지 (703MB, 64% 감소)

# Dockerfile.step2  
FROM python:3.12-slim

WORKDIR /app

# 시스템 의존성 최소화
RUN apt-get update && apt-get install -y \
    --no-install-recommends \
    gcc \
    && rm -rf /var/lib/apt/lists/*

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8000
CMD ["python", "main.py"]

docker build -f Dockerfile.step2 -t ml-api:step2 .
docker images | grep ml-api
# ml-api    step2    703MB

개선점: Debian 슬림 버전으로 불필요한 패키지 제거

3단계: Alpine 베이스 (352MB, 추가 50% 감소)

# Dockerfile.step3
FROM python:3.12-alpine

WORKDIR /app

# Alpine에 필요한 빌드 도구들
RUN apk add --no-cache \
    gcc \
    g++ \
    musl-dev \
    linux-headers \
    gfortran \ 
    openblas-dev 

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 빌드 도구 정리
RUN apk del gcc g++ musl-dev linux-headers gfortran openblas-dev

COPY . .

EXPOSE 8000
CMD ["python", "main.py"]

docker build -f Dockerfile.step3 -t ml-api:step3 .
docker images | grep ml-api
# ml-api    step3    352MB

주의사항: pandas와 numpy는 Alpine에서 컴파일 시간이 오래 걸림

4단계: 멀티스테이지 빌드 (305MB, 추가 13% 감소)

# Dockerfile.step4
FROM python:3.12-alpine AS builder  

WORKDIR /app

RUN apk add --no-cache \
    gcc \
    g++ \
    musl-dev \
    linux-headers \
    gfortran \
    openblas-dev

COPY requirements.txt .
RUN pip install --no-cache-dir --user -r requirements.txt

# 런타임 스테이지
FROM python:3.12-alpine

WORKDIR /app

RUN apk add --no-cache libstdc++

COPY --from=builder /root/.local /root/.local
COPY . .

ENV PATH=/root/.local/bin:$PATH

EXPOSE 8000
CMD ["python", "main.py"]

docker build -f Dockerfile.step4 -t ml-api:step4 .
docker images | grep ml-api
# ml-api    step4    305MB

최종 결과: 305MB는 실무에서 실용성과 최적화의 균형점. pandas/numpy가 포함된 ML 애플리케이션에서는 이 정도가 현실적인 최적값이다.

Go API 서버 최적화 단계별 가이드

예제 애플리케이션 준비

실제 운영 환경에서 사용하는 Go REST API 서버를 만들어보겠다.

// main.go
package main

import (
    "encoding/json"
    "fmt"
    "log"
    "net/http"
    "os"
    "strconv"
    "time"

    "github.com/gorilla/mux"
    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)

type User struct {
    ID        int       `json:"id"`
    Name      string    `json:"name"`
    Email     string    `json:"email"`
    CreatedAt time.Time `json:"created_at"`
}

type APIResponse struct {
    Status  string      `json:"status"`
    Message string      `json:"message,omitempty"`
    Data    interface{} `json:"data,omitempty"`
}

// Prometheus metrics
var (
    httpRequestsTotal = prometheus.NewCounterVec(
        prometheus.CounterOpts{
            Name: "http_requests_total",
            Help: "Total number of HTTP requests",
        },
        []string{"method", "endpoint", "status"},
    )
    httpRequestDuration = prometheus.NewHistogramVec(
        prometheus.HistogramOpts{
            Name: "http_request_duration_seconds",
            Help: "HTTP request duration in seconds",
        },
        []string{"method", "endpoint"},
    )
)

// Mock database
var users = []User{
    {ID: 1, Name: "Alice", Email: "alice@example.com", CreatedAt: time.Now()},
    {ID: 2, Name: "Bob", Email: "bob@example.com", CreatedAt: time.Now()},
}

func init() {
    prometheus.MustRegister(httpRequestsTotal)
    prometheus.MustRegister(httpRequestDuration)
}

func loggingMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        log.Printf("%s %s %s", r.Method, r.RequestURI, r.RemoteAddr)
        next.ServeHTTP(w, r)
        duration := time.Since(start)
        log.Printf("Request completed in %v", duration)
    })
}

func metricsMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        start := time.Now()
        next.ServeHTTP(w, r)
        duration := time.Since(start).Seconds()
        
        httpRequestsTotal.WithLabelValues(r.Method, r.URL.Path, "200").Inc()
        httpRequestDuration.WithLabelValues(r.Method, r.URL.Path).Observe(duration)
    })
}

func healthHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    response := APIResponse{
        Status: "healthy",
        Data: map[string]interface{}{
            "timestamp": time.Now(),
            "service":   "User API",
            "version":   "1.0.0",
        },
    }
    json.NewEncoder(w).Encode(response)
}

func getUsersHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    response := APIResponse{
        Status: "success",
        Data:   users,
    }
    json.NewEncoder(w).Encode(response)
}

func getUserHandler(w http.ResponseWriter, r *http.Request) {
    vars := mux.Vars(r)
    id, err := strconv.Atoi(vars["id"])
    if err != nil {
        w.WriteHeader(http.StatusBadRequest)
        response := APIResponse{
            Status:  "error",
            Message: "Invalid user ID",
        }
        json.NewEncoder(w).Encode(response)
        return
    }

    for _, user := range users {
        if user.ID == id {
            w.Header().Set("Content-Type", "application/json")
            response := APIResponse{
                Status: "success",
                Data:   user,
            }
            json.NewEncoder(w).Encode(response)
            return
        }
    }

    w.WriteHeader(http.StatusNotFound)
    response := APIResponse{
        Status:  "error",
        Message: "User not found",
    }
    json.NewEncoder(w).Encode(response)
}

func createUserHandler(w http.ResponseWriter, r *http.Request) {
    var user User
    if err := json.NewDecoder(r.Body).Decode(&user); err != nil {
        w.WriteHeader(http.StatusBadRequest)
        response := APIResponse{
            Status:  "error",
            Message: "Invalid JSON",
        }
        json.NewEncoder(w).Encode(response)
        return
    }

    user.ID = len(users) + 1
    user.CreatedAt = time.Now()
    users = append(users, user)

    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(http.StatusCreated)
    response := APIResponse{
        Status: "success",
        Data:   user,
    }
    json.NewEncoder(w).Encode(response)
}

func main() {
    r := mux.NewRouter()
    
    // Middleware
    r.Use(loggingMiddleware)
    r.Use(metricsMiddleware)
    
    // Routes
    r.HandleFunc("/health", healthHandler).Methods("GET")
    r.HandleFunc("/users", getUsersHandler).Methods("GET")
    r.HandleFunc("/users/{id:[0-9]+}", getUserHandler).Methods("GET")
    r.HandleFunc("/users", createUserHandler).Methods("POST")
    r.Handle("/metrics", promhttp.Handler())

    port := os.Getenv("PORT")
    if port == "" {
        port = "8080"
    }

    log.Printf("Server starting on port %s", port)
    log.Fatal(http.ListenAndServe(fmt.Sprintf(":%s", port), r))
}

// go.mod
module user-api

go 1.21

require (
    github.com/gorilla/mux v1.8.1
    github.com/prometheus/client_golang v1.17.0
)

`go.sum` 생성

go mod tidy

1단계: 기본 베이스라인 (1.54GB)

# Dockerfile.step1
FROM golang:1.24

WORKDIR /app

COPY go.mod go.sum ./
RUN go mod download

COPY . .
RUN go build -o main .

EXPOSE 8080
CMD ["./main"]

docker build -f Dockerfile.step1 -t user-api:step1 .
docker images | grep user-api
# user-api    step1    1.54GB

문제점: Go 개발 환경 전체 + 빌드 도구 + Git 등 불필요한 도구들 포함

2단계: Alpine 베이스 (628MB, 59% 감소)

# Dockerfile.step2
FROM golang:1.24-alpine

WORKDIR /app

# Git 설치 (go mod download에 필요할 수 있음)
RUN apk add --no-cache git

COPY go.mod go.sum ./
RUN go mod download

COPY . .
RUN go build -o main .

EXPOSE 8080
CMD ["./main"]

docker build -f Dockerfile.step2 -t user-api:step2 .
docker images | grep user-api
# user-api    step2    628MB

개선점: Alpine Linux로 기본 OS 크기 대폭 감소

3단계: 멀티스테이지 빌드 (30MB, 92% 감소)

# Dockerfile.step3
FROM golang:1.24-alpine AS builder

WORKDIR /app

# 의존성 캐싱을 위한 레이어 분리
COPY go.mod go.sum ./
RUN go mod download

COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-w -s" -o main .

# 런타임 스테이지
FROM alpine:latest

WORKDIR /root/

# SSL 인증서와 타임존 정보 추가
RUN apk --no-cache add ca-certificates tzdata
COPY --from=builder /app/main .

EXPOSE 8080
CMD ["./main"]

docker build -f Dockerfile.step3 -t user-api:step3 .
docker images | grep user-api
# user-api    step3    30MB

개선점

`CGO_ENABLED=0`: C 라이브러리 의존성 제거
`-ldflags="-w -s"`: 디버그 정보와 심볼 테이블 제거
Alpine 런타임으로 최소한의 환경만 포함

4단계: Scratch 베이스 (8.2MB, 71% 추가 감소)

# Dockerfile.step4
FROM golang:1.24-alpine AS builder

WORKDIR /app

# Alpine에 필요한 패키지 설치
RUN apk --no-cache add ca-certificates tzdata

COPY go.mod go.sum ./
RUN go mod download

COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -ldflags="-w -s" -o main .

# 최종 스테이지: scratch (빈 이미지)
FROM scratch

# SSL 인증서 복사 (HTTPS 요청을 위해 필요)
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/

# 타임존 정보 복사 (Alpine의 경우)
COPY --from=builder /usr/share/zoneinfo /usr/share/zoneinfo

COPY --from=builder /app/main /main

EXPOSE 8080
ENTRYPOINT ["/main"]

docker build -f Dockerfile.step4 -t user-api:step4 .
docker images | grep user-api
# user-api    step4    15.3MB

최종 최적화

scratch: 완전히 빈 베이스 이미지
-a -installsuffix cgo: 완전한 정적 빌드
필수 파일만 선별적 복사 (SSL 인증서, 타임존 정보)

최적화 전략 비교 및 선택 가이드

Python vs Go 최적화 특성

특성	Python	Go
최적화 한계	305MB (의존성 때문)	15.3MB (정적 빌드)
복잡도	중간 (의존성 관리)	낮음 (간단한 빌드)
빌드 시간	길음 (numpy/pandas 컴파일)	빠름 (네이티브 컴파일)
디버깅 용이성	좋음	제한적 (scratch 사용 시)

실무 권장사항

Python 프로젝트

멀티스테이지 Alpine (305MB)까지가 실용적
ML 라이브러리가 없다면 더 작게 가능 (~50MB)
Distroless는 복잡성 대비 이득 적음

Go 프로젝트

Scratch 베이스 (15.3MB) 적극 권장
외부 C 라이브러리 사용 시 Alpine 고려 (30MB)
디버깅이 필요한 개발 환경에서는 Alpine 사용

고급 최적화 기법

`.dockerignore` 활용

# .dockerignore
.git
.gitignore
README.md
Dockerfile*
.DS_Store
node_modules
npm-debug.log
coverage/
.nyc_output
*.log
.env.local
.env.development.local
.env.test.local
.env.production.local

불필요한 파일들을 빌드 컨텍스트에서 제외하여 빌드 속도와 이미지 크기를 개선한다.

결론

Docker 이미지 최적화는 단순히 크기를 줄이는 것을 넘어, 배포 속도 개선, 로컬 개발 환경 효율 증대, 보안 강화라는 세 가지 핵심 가치를 동시에 달성하는 전략이다.

핵심 원칙

언어 특성에 맞는 접근: Python은 의존성 관리, Go는 정적 빌드가 핵심이다.
단계적 최적화: 한 번에 모든 것을 바꾸려 하지 말고 단계별로 접근해야 한다.
실용성 우선: 복잡성 대비 효과를 고려하여 최적점을 찾는 것이 중요하다.
지속적 모니터링: CI/CD에 이미지 크기 체크를 자동화하는 것이 좋다.

이런 최적화를 통해 배포 속도를 크게 개선하고, 로컬 개발 환경의 디스크 공간도 절약할 수 있었다. 무엇보다 보안 취약점이 대폭 감소하여 더 안전한 컨테이너 환경을 구축할 수 있었다.

개인 프로젝트에서 시작한 작은 최적화 실험이었지만, 지속적인 개선을 통해 큰 성과를 얻을 수 있었다. 여러분의 프로젝트에도 이런 최적화 전략이 도움이 되기를 바란다.

Reference

https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

https://github.com/GoogleContainerTools/distroless

https://hub.docker.com/_/python

https://pythonspeed.com/articles/smaller-python-docker-images/

Somaz | DevOps Engineer | Kubernetes & Cloud Infrastructure Specialist

네트워크 토폴로지 모델 완전 가이드: 허브-스포크부터 메시까지

Somaz — Tue, 3 Feb 2026 00:00:10 +0900

Overview

네트워크 토폴로지는 컴퓨터 네트워크에서 노드들 간의 물리적 또는 논리적 연결 구조를 의미한다.

올바른 토폴로지 선택은 네트워크의 성능, 확장성, 비용, 관리 복잡성에 직접적인 영향을 미친다.

본 글에서는 현대 네트워크 설계에서 핵심적인 토폴로지 모델들을 비교 분석하고, 각각의 특성과 적용 시나리오를 심층적으로 탐구한다. 특히 클라우드 환경에서 주목받는 허브-스포크 모델을 중심으로 실무적 관점에서 살펴본다.

네트워크 토폴로지 모델 완전 가이드

허브-스포크부터 메시까지

네트워크 토폴로지의 기본 이해

토폴로지 분류 체계

네트워크 토폴로지는 크게 물리적 토폴로지와 논리적 토폴로지로 구분된다.

물리적 토폴로지 (Physical Topology)

실제 케이블과 장비의 물리적 배치
하드웨어 연결 구조
지리적 위치와 거리 고려

논리적 토폴로지 (Logical Topology)

데이터 흐름과 통신 경로
프로토콜과 알고리즘에 의해 결정
물리적 구조와 독립적으로 설계 가능

토폴로지 설계 원칙

효과적인 네트워크 토폴로지 설계를 위해서는 다음 원칙들을 고려해야 한다.

확장성 (Scalability): 노드 추가 시 복잡성 증가율
신뢰성 (Reliability): 장애 허용 능력과 복구 메커니즘
성능 (Performance): 지연시간, 대역폭, 처리량
비용 효율성 (Cost Efficiency): 구축 및 운영 비용
관리 복잡성 (Management Complexity): 운영 및 유지보수 난이도

허브-스포크 모델 (Hub-and-Spoke Model)

기본 구조와 개념

허브-스포크 모델은 중앙의 허브(Hub)를 통해 여러 스포크(Spoke)들이 연결되는 구조다. 이 모델은 자전거 바퀴의 중심축과 바퀴살 형태에서 이름을 따왔으며, 중앙집중식 네트워크 아키텍처의 대표적인 패턴이다.

핵심 특징

모든 통신이 중앙 허브를 경유
스포크 간 직접 통신 불가
중앙집중식 제어 및 관리
계층적 구조 구현

허브-스포크의 수학적 분석

허브-스포크 모델의 효율성을 수학적으로 분석해보면

연결 복잡도

n개 노드 연결 시: n개의 링크 필요
시간 복잡도: O(n)
공간 복잡도: O(n)

비교 분석

메시 토폴로지: n(n-1)/2 = O(n²)
허브-스포크: n = O(n)

예시로 10개의 노드를 연결할 경우

메시 토폴로지: 45개의 연결
허브-스포크: 10개의 연결

허브-스포크의 장점

1. 확장성 우수

새로운 노드 추가 시 기존 연결에 영향 없이 허브에만 연결하면 된다. 이는 선형적 확장성을 제공하여 대규모 네트워크 구축에 유리하다.

2. 중앙집중식 관리

모든 트래픽이 허브를 경유하므로 다음과 같은 이점을 제공한다:

통합 보안 정책 적용
중앙화된 모니터링과 로깅
일관된 라우팅 정책
간소화된 네트워크 관리

3. 비용 효율성

연결 수의 선형적 증가로 인해 비용 예측이 용이하고, 중복 인프라를 제거할 수 있다.

4. 정책 일관성

중앙 허브에서 모든 정책을 관리하므로 네트워크 전반에 걸쳐 일관된 보안 및 접근 제어 정책을 적용할 수 있다.

허브-스포크의 단점

1. 단일 장애점 (Single Point of Failure)

허브 장애 시 전체 네트워크가 마비될 수 있다. 이를 완화하기 위한 방법들:

허브 이중화 구성
클러스터링을 통한 고가용성 확보
자동 페일오버 메커니즘 구현

2. 성능 병목

모든 트래픽이 허브를 경유하므로 다음과 같은 성능 이슈가 발생할 수 있다:

허브의 처리 능력에 의한 성능 제한
추가 홉으로 인한 지연시간 증가
대역폭 병목 현상

3. 확장성 제한

허브의 물리적 한계로 인해 연결 가능한 스포크 수에 제한이 있을 수 있다.

메시 토폴로지 (Mesh Topology)

풀 메시 (Full Mesh)

풀 메시에서는 모든 노드가 서로 직접 연결된다.

특징

최대 신뢰성 제공
최단 경로 통신 가능
단일 장애점 없음
높은 구축 비용

연결 수 계산: n개 노드의 풀 메시: n(n-1)/2개의 연결

부분 메시 (Partial Mesh)

일부 노드들만 직접 연결되는 형태로, 풀 메시와 다른 토폴로지의 절충안이다.

장점

풀 메시 대비 비용 절약
중요한 경로는 직접 연결로 성능 보장
유연한 설계 가능

단점

복잡한 라우팅 계획 필요
부분적 단일 장애점 존재 가능

스타 토폴로지 (Star Topology)

기본 구조

스타 토폴로지는 중앙 노드 하나에 모든 다른 노드들이 연결되는 구조다. 허브-스포크와 유사하지만 더 단순한 형태다.

특징

가장 간단한 중앙집중형 구조
중앙 노드를 통한 모든 통신
쉬운 설치와 관리
제한된 확장성

장단점 분석

장점

간단한 설치와 구성
쉬운 문제 해결
중앙집중식 관리
케이블 소요량 최소화

단점

중앙 노드 의존성
확장성 제한
성능 병목 가능성

링 토폴로지 (Ring Topology)

구조와 동작 원리

각 노드가 인접한 두 노드와 연결되어 고리 형태를 이루는 구조다.

특징

단방향 또는 양방향 데이터 전송
토큰 패싱 방식 주로 사용
예측 가능한 성능
제한된 장애 허용성

종류

단일 링: 한 방향으로만 데이터 전송
이중 링: 양방향 데이터 전송 지원

버스 토폴로지 (Bus Topology)

기본 개념

모든 노드가 하나의 공통 전송 매체(백본)에 연결되는 구조다.

특징

단순한 구조
비용 효율적
쉬운 확장
충돌 도메인 공유

프로토콜

CSMA/CD (Carrier Sense Multiple Access with Collision Detection)
충돌 감지 및 재전송 메커니즘

트리 토폴로지 (Tree Topology)

계층적 구조

트리 토폴로지는 계층적 구조를 가지며, 루트 노드에서 시작하여 브랜치가 뻗어나가는 형태다.

특징

계층적 관리 구조
확장성과 관리성의 균형
부분적 단일 장애점
스케일링 용이

하이브리드 토폴로지 (Hybrid Topology)

복합 구조의 필요성

현실적인 네트워크 환경에서는 단일 토폴로지보다는 여러 토폴로지를 조합한 하이브리드 형태가 더 효과적인 경우가 많다.

일반적인 조합

스타-버스: LAN에서 스타, WAN에서 버스
스타-링: 백본은 링, 접근은 스타
메시-허브스포크: 코어는 메시, 엣지는 허브-스포크

클라우드 환경에서의 토폴로지 구현

AWS에서의 허브-스포크 구현

AWS Transit Gateway를 활용한 허브-스포크 모델 구현

# 중앙 허브 역할의 Transit Gateway
resource "aws_ec2_transit_gateway" "central_hub" {
  description                     = "Central Hub for Enterprise Network"
  default_route_table_association = "disable"
  default_route_table_propagation = "disable"
  dns_support                     = "enable"
  vpn_ecmp_support               = "enable"
  
  tags = {
    Name = "enterprise-hub-tgw"
    Pattern = "hub-spoke"
  }
}

# 환경별 라우팅 테이블 생성
resource "aws_ec2_transit_gateway_route_table" "production" {
  transit_gateway_id = aws_ec2_transit_gateway.central_hub.id
  
  tags = {
    Name = "production-route-table"
    Environment = "production"
  }
}

resource "aws_ec2_transit_gateway_route_table" "development" {
  transit_gateway_id = aws_ec2_transit_gateway.central_hub.id
  
  tags = {
    Name = "development-route-table" 
    Environment = "development"
  }
}

resource "aws_ec2_transit_gateway_route_table" "shared_services" {
  transit_gateway_id = aws_ec2_transit_gateway.central_hub.id
  
  tags = {
    Name = "shared-services-route-table"
    Environment = "shared"
  }
}

# VPC 어태치먼트 (스포크 역할)
resource "aws_ec2_transit_gateway_vpc_attachment" "production_spoke" {
  subnet_ids                                      = [aws_subnet.prod_tgw.id]
  transit_gateway_id                              = aws_ec2_transit_gateway.central_hub.id
  vpc_id                                          = aws_vpc.production.id
  transit_gateway_default_route_table_association = false
  transit_gateway_default_route_table_propagation = false
  
  tags = {
    Name = "production-spoke-attachment"
    Role = "spoke"
  }
}

# 네트워크 세분화를 위한 라우팅 연결
resource "aws_ec2_transit_gateway_route_table_association" "prod_association" {
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.production_spoke.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.production.id
}

# 선택적 통신을 위한 라우트 설정
resource "aws_ec2_transit_gateway_route" "prod_to_shared_dns" {
  destination_cidr_block         = "10.100.0.0/24"  # DNS 서브넷
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.shared_services.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.production.id
}

Azure에서의 허브-스포크 구현

Azure Virtual WAN을 활용한 구현

# Virtual WAN 생성 (허브 역할)
resource "azurerm_virtual_wan" "enterprise_wan" {
  name                = "enterprise-vwan"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  type               = "Standard"
  
  tags = {
    Environment = "production"
    Pattern     = "hub-spoke"
  }
}

# Virtual Hub 생성
resource "azurerm_virtual_hub" "main_hub" {
  name                = "main-hub"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  virtual_wan_id      = azurerm_virtual_wan.enterprise_wan.id
  address_prefix      = "10.0.0.0/24"
  
  tags = {
    Role = "hub"
  }
}

# 스포크 VNet 연결
resource "azurerm_virtual_hub_connection" "spoke_connection" {
  name                      = "spoke-vnet-connection"
  virtual_hub_id            = azurerm_virtual_hub.main_hub.id
  remote_virtual_network_id = azurerm_virtual_network.spoke_vnet.id
  
  routing {
    associated_route_table_id = azurerm_virtual_hub_route_table.custom.id
  }
}

GCP에서의 허브-스포크 구현

GCP Network Connectivity Center와 VPC Peering을 활용한 구현

# Network Connectivity Center Hub 생성 (허브 역할)
resource "google_network_connectivity_hub" "enterprise_hub" {
  name        = "enterprise-hub"
  description = "Central hub for enterprise network connectivity"
  project     = var.project_id
  
  labels = {
    environment = "production"
    pattern     = "hub-spoke"
  }
}

# 허브 VPC 네트워크 생성
resource "google_compute_network" "hub_network" {
  name                    = "hub-network"
  auto_create_subnetworks = false
  routing_mode           = "GLOBAL"
  project                = var.project_id
}

# 허브 서브넷 생성
resource "google_compute_subnetwork" "hub_subnet" {
  name          = "hub-subnet"
  ip_cidr_range = "10.0.0.0/24"
  region        = var.region
  network       = google_compute_network.hub_network.id
  project       = var.project_id
}

# Production 스포크 VPC 생성
resource "google_compute_network" "production_spoke" {
  name                    = "production-spoke"
  auto_create_subnetworks = false
  routing_mode           = "REGIONAL"
  project                = var.project_id
}

resource "google_compute_subnetwork" "production_subnet" {
  name          = "production-subnet"
  ip_cidr_range = "10.1.0.0/16"
  region        = var.region
  network       = google_compute_network.production_spoke.id
  project       = var.project_id
}

# Development 스포크 VPC 생성
resource "google_compute_network" "development_spoke" {
  name                    = "development-spoke"
  auto_create_subnetworks = false
  routing_mode           = "REGIONAL"
  project                = var.project_id
}

resource "google_compute_subnetwork" "development_subnet" {
  name          = "development-subnet"
  ip_cidr_range = "10.2.0.0/16"
  region        = var.region
  network       = google_compute_network.development_spoke.id
  project       = var.project_id
}

# 허브-스포크 VPC Peering 연결 (Production)
resource "google_compute_network_peering" "hub_to_production" {
  name         = "hub-to-production"
  network      = google_compute_network.hub_network.self_link
  peer_network = google_compute_network.production_spoke.self_link
  
  export_custom_routes = true
  import_custom_routes = true
  
  export_subnet_routes_with_public_ip = false
  import_subnet_routes_with_public_ip = false
}

resource "google_compute_network_peering" "production_to_hub" {
  name         = "production-to-hub"
  network      = google_compute_network.production_spoke.self_link
  peer_network = google_compute_network.hub_network.self_link
  
  export_custom_routes = true
  import_custom_routes = true
  
  export_subnet_routes_with_public_ip = false
  import_subnet_routes_with_public_ip = false
}

# 허브-스포크 VPC Peering 연결 (Development)
resource "google_compute_network_peering" "hub_to_development" {
  name         = "hub-to-development"
  network      = google_compute_network.hub_network.self_link
  peer_network = google_compute_network.development_spoke.self_link
  
  export_custom_routes = true
  import_custom_routes = false  # Development는 제한된 라우트만 허용
  
  export_subnet_routes_with_public_ip = false
  import_subnet_routes_with_public_ip = false
}

resource "google_compute_network_peering" "development_to_hub" {
  name         = "development-to-hub"
  network      = google_compute_network.development_spoke.self_link
  peer_network = google_compute_network.hub_network.self_link
  
  export_custom_routes = false  # Development에서 허브로의 라우트 내보내기 제한
  import_custom_routes = true
  
  export_subnet_routes_with_public_ip = false
  import_subnet_routes_with_public_ip = false
}

# Network Connectivity Center Spoke 등록
resource "google_network_connectivity_spoke" "production_spoke_registration" {
  name     = "production-spoke"
  location = "global"
  hub      = google_network_connectivity_hub.enterprise_hub.id
  
  linked_vpc_network {
    uri                              = google_compute_network.production_spoke.self_link
    exclude_export_ranges            = ["10.2.0.0/16"]  # Development 네트워크 제외
    include_export_ranges            = ["10.1.0.0/16"]  # Production 네트워크만 포함
  }
  
  labels = {
    environment = "production"
    role        = "spoke"
  }
}

resource "google_network_connectivity_spoke" "development_spoke_registration" {
  name     = "development-spoke"
  location = "global"
  hub      = google_network_connectivity_hub.enterprise_hub.id
  
  linked_vpc_network {
    uri                              = google_compute_network.development_spoke.self_link
    exclude_export_ranges            = ["10.1.0.0/16"]  # Production 네트워크 제외
    include_export_ranges            = ["10.2.0.0/16"]  # Development 네트워크만 포함
  }
  
  labels = {
    environment = "development"
    role        = "spoke"
  }
}

# 공유 서비스를 위한 별도 VPC (DNS, 모니터링 등)
resource "google_compute_network" "shared_services" {
  name                    = "shared-services"
  auto_create_subnetworks = false
  routing_mode           = "GLOBAL"
  project                = var.project_id
}

resource "google_compute_subnetwork" "shared_services_subnet" {
  name          = "shared-services-subnet"
  ip_cidr_range = "10.100.0.0/24"
  region        = var.region
  network       = google_compute_network.shared_services.id
  project       = var.project_id
}

# 공유 서비스 VPC와 허브 연결
resource "google_compute_network_peering" "hub_to_shared" {
  name         = "hub-to-shared-services"
  network      = google_compute_network.hub_network.self_link
  peer_network = google_compute_network.shared_services.self_link
  
  export_custom_routes = true
  import_custom_routes = true
}

resource "google_compute_network_peering" "shared_to_hub" {
  name         = "shared-services-to-hub"
  network      = google_compute_network.shared_services.self_link
  peer_network = google_compute_network.hub_network.self_link
  
  export_custom_routes = true
  import_custom_routes = true
}

# Cloud Router 및 Cloud NAT 설정 (아웃바운드 인터넷 접근)
resource "google_compute_router" "hub_router" {
  name    = "hub-router"
  region  = var.region
  network = google_compute_network.hub_network.id
  project = var.project_id
  
  bgp {
    asn = 64512
  }
}

resource "google_compute_router_nat" "hub_nat" {
  name                               = "hub-nat"
  router                            = google_compute_router.hub_router.name
  region                            = var.region
  nat_ip_allocate_option            = "AUTO_ONLY"
  source_subnetwork_ip_ranges_to_nat = "ALL_SUBNETWORKS_ALL_IP_RANGES"
  project                           = var.project_id
  
  log_config {
    enable = true
    filter = "ERRORS_ONLY"
  }
}

# 방화벽 규칙 - 환경별 트래픽 제어
resource "google_compute_firewall" "allow_hub_to_spokes" {
  name    = "allow-hub-to-spokes"
  network = google_compute_network.hub_network.name
  project = var.project_id
  
  allow {
    protocol = "tcp"
    ports    = ["22", "80", "443"]
  }
  
  allow {
    protocol = "icmp"
  }
  
  source_ranges = ["10.0.0.0/24"]  # 허브 서브넷
  target_tags   = ["spoke-vm"]
  
  description = "Allow traffic from hub to spokes"
}

resource "google_compute_firewall" "deny_cross_spoke" {
  name     = "deny-cross-spoke-communication"
  network  = google_compute_network.hub_network.name
  project  = var.project_id
  priority = 1000
  
  deny {
    protocol = "all"
  }
  
  source_ranges = ["10.1.0.0/16", "10.2.0.0/16"]  # Production, Development
  target_tags   = ["cross-spoke-deny"]
  
  description = "Deny direct communication between spokes"
}

성능 및 확장성 비교 분석

정량적 비교 지표

토폴로지	연결 복잡도	지연시간	신뢰성	확장성	비용
허브-스포크	O(n)	중간	중간	높음	중간
풀 메시	O(n²)	낮음	높음	낮음	높음
스타	O(n)	중간	낮음	중간	낮음
링	O(n)	높음	중간	중간	낮음
버스	O(n)	높음	낮음	제한적	낮음

트래픽 패턴에 따른 선택 기준

East-West 트래픽이 많은 경우

메시 토폴로지 선호
직접 연결을 통한 지연시간 최소화

North-South 트래픽이 주된 경우

허브-스포크 모델 적합
중앙집중식 게이트웨이 활용

혼합 트래픽 패턴

하이브리드 접근법
중요 경로는 직접 연결, 일반 트래픽은 허브 경유

보안 관점에서의 토폴로지 분석

허브-스포크의 보안 이점

1. 중앙집중식 보안 제어

단일 지점에서 모든 보안 정책 관리
일관된 보안 정책 적용
중앙화된 로깅 및 모니터링

2. 네트워크 세분화 (Segmentation)

환경별 트래픽 격리
제로 트러스트 아키텍처 구현
최소 권한 원칙 적용

3. 트래픽 검사 및 필터링

중앙 허브에서의 심층 패킷 검사
침입 탐지/방지 시스템 통합
데이터 손실 방지 (DLP) 적용

보안 설계 패턴

# 보안 강화를 위한 허브-스포크 설계
resource "aws_ec2_transit_gateway_route_table" "security_inspection" {
  transit_gateway_id = aws_ec2_transit_gateway.central_hub.id
  
  tags = {
    Name = "security-inspection-route-table"
    Purpose = "traffic-inspection"
  }
}

# 보안 VPC (방화벽/IDS 포함)
resource "aws_ec2_transit_gateway_vpc_attachment" "security_vpc" {
  subnet_ids         = [aws_subnet.security_inspection.id]
  transit_gateway_id = aws_ec2_transit_gateway.central_hub.id
  vpc_id            = aws_vpc.security.id
  
  tags = {
    Name = "security-inspection-attachment"
    Role = "security-hub"
  }
}

# 트래픽을 보안 VPC로 라우팅
resource "aws_ec2_transit_gateway_route" "inspect_traffic" {
  destination_cidr_block         = "0.0.0.0/0"
  transit_gateway_attachment_id  = aws_ec2_transit_gateway_vpc_attachment.security_vpc.id
  transit_gateway_route_table_id = aws_ec2_transit_gateway_route_table.security_inspection.id
}

모니터링 및 운영 전략

성능 모니터링 지표

1. 허브-스포크 모델

허브 성능 지표: CPU 사용률, 메모리 사용률, 처리량
네트워크 지표: 지연시간, 패킷 손실률, 대역폭 사용률
연결 상태: 어태치먼트 상태, 라우팅 테이블 상태

2. 메시 토폴로지

링크별 성능: 각 직접 연결의 상태와 성능
경로 최적화: 최단 경로 vs 실제 사용 경로
로드 밸런싱: 트래픽 분산 상태

자동화된 모니터링 구현

# CloudWatch 메트릭을 활용한 허브-스포크 모니터링
import boto3
import json

def monitor_transit_gateway_performance():
    cloudwatch = boto3.client('cloudwatch')
    ec2 = boto3.client('ec2')
    
    # Transit Gateway 목록 조회
    tgws = ec2.describe_transit_gateways()
    
    for tgw in tgws['TransitGateways']:
        tgw_id = tgw['TransitGatewayId']
        
        # 데이터 처리량 메트릭 조회
        response = cloudwatch.get_metric_statistics(
            Namespace='AWS/TransitGateway',
            MetricName='BytesIn',
            Dimensions=[
                {
                    'Name': 'TransitGateway',
                    'Value': tgw_id
                }
            ],
            StartTime=datetime.now() - timedelta(hours=1),
            EndTime=datetime.now(),
            Period=300,
            Statistics=['Sum', 'Average']
        )
        
        # 임계값 체크 및 알림
        for datapoint in response['Datapoints']:
            if datapoint['Sum'] > THRESHOLD_BYTES:
                send_alert(f"TGW {tgw_id} high traffic detected: {datapoint['Sum']} bytes")

def check_spoke_connectivity():
    """스포크 연결 상태 확인"""
    ec2 = boto3.client('ec2')
    
    attachments = ec2.describe_transit_gateway_attachments()
    
    for attachment in attachments['TransitGatewayAttachments']:
        if attachment['State'] != 'available':
            send_alert(f"Spoke attachment {attachment['TransitGatewayAttachmentId']} is {attachment['State']}")

비용 최적화 전략

토폴로지별 비용 분석

1. 허브-스포크 모델

고정 비용: 허브 인프라 (Transit Gateway, Virtual WAN)
변동 비용: 어태치먼트별 시간당 요금, 데이터 전송 비용
최적화 방안: 불필요한 어태치먼트 정리, 트래픽 최적화

2. 메시 토폴로지

고정 비용: 다수의 직접 연결 (VPC Peering, Express Route)
변동 비용: 연결별 데이터 전송 비용
최적화 방안: 트래픽 패턴 분석 후 불필요한 연결 제거

비용 모니터링 자동화

# 비용 알림을 위한 CloudWatch 알람
resource "aws_cloudwatch_metric_alarm" "tgw_cost_alarm" {
  alarm_name          = "transit-gateway-high-cost"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = "2"
  metric_name         = "EstimatedCharges"
  namespace           = "AWS/Billing"
  period              = "86400"  # 24 hours
  statistic           = "Maximum"
  threshold           = "1000"   # $1000
  alarm_description   = "This metric monitors Transit Gateway costs"
  
  dimensions = {
    Currency = "USD"
    ServiceName = "AmazonVPC"
  }
  
  alarm_actions = [aws_sns_topic.cost_alerts.arn]
}

# 비용 최적화를 위한 Lambda 함수
resource "aws_lambda_function" "cost_optimizer" {
  filename         = "cost_optimizer.zip"
  function_name    = "network-cost-optimizer"
  role            = aws_iam_role.lambda_role.arn
  handler         = "index.handler"
  runtime         = "python3.9"
  
  environment {
    variables = {
      SNS_TOPIC_ARN = aws_sns_topic.cost_alerts.arn
    }
  }
}

미래 기술 동향과 토폴로지 진화

SD-WAN과 토폴로지

Software-Defined WAN은 기존 토폴로지 개념을 혁신하고 있다.

동적 경로 선택: 실시간 성능 기반 라우팅
하이브리드 연결: 다양한 연결 방식의 동적 조합
중앙집중식 정책 관리: 소프트웨어 기반 네트워크 제어

클라우드 네이티브 아키텍처

컨테이너와 마이크로서비스 환경에서의 토폴로지

서비스 메시: 애플리케이션 레벨의 네트워크 토폴로지
CNI 기반 네트워킹: Kubernetes 네트워크 플러그인
멀티 클라우드 연결: 클라우드 간 네트워크 토폴로지

5G와 엣지 컴퓨팅

차세대 네트워크 기술이 토폴로지에 미치는 영향

엣지-클라우드 하이브리드: 분산된 허브-스포크 모델
초저지연 요구사항: 새로운 토폴로지 패러다임 필요
동적 네트워크 슬라이싱: 가상화된 토폴로지 구현

토폴로지 선택 가이드라인

의사결정 프레임워크

토폴로지 선택을 위한 체계적 접근법

1단계: 요구사항 분석

트래픽 패턴 분석: East-West vs North-South
성능 요구사항: 지연시간, 대역폭, 가용성
보안 요구사항: 격리 수준, 규정 준수
확장 계획: 예상 성장률, 지리적 확장

2단계: 제약사항 평가

예산 제약: 구축 비용, 운영 비용
기술적 제약: 기존 인프라, 기술 역량
시간적 제약: 구축 일정, 마이그레이션 기간

3단계: 토폴로지 매칭

허브-스포크: 중앙집중식 관리, 확장성 중시
메시: 성능 최우선, 고가용성 요구
하이브리드: 복합적 요구사항, 단계적 진화

실무 적용 사례

대기업 환경

요구사항: 글로벌 다중 사이트, 엄격한 보안, 중앙 관리
선택: 계층적 허브-스포크
- 리전별 허브 구성
- 글로벌 허브 간 메시 연결
- 사이트별 스포크 연결

스타트업 환경

요구사항: 빠른 구축, 비용 최적화, 간단한 관리
선택: 단순 허브-스포크
- 클라우드 Transit Gateway 활용
- 최소 어태치먼트로 시작
- 성장에 따른 점진적 확장

금융 기관

요구사항: 최고 수준 보안, 규정 준수, 고가용성
선택: 보안 강화 하이브리드
- 중요 시스템 간 직접 메시 연결
- 일반 시스템은 보안 허브 경유
- 다중 백업 경로 구성

마무리

네트워크 토폴로지는 단순한 연결 방식을 넘어서 전체 IT 인프라의 성능, 보안, 확장성을 결정하는 핵심 요소다. 허브-스포크 모델은 현대적인 클라우드 환경에서 확장성과 관리 효율성의 균형을 제공하는 강력한 아키텍처 패턴으로 자리잡고 있다.

효과적인 토폴로지 선택을 위해서는 비즈니스 요구사항과 기술적 제약사항을 종합적으로 고려해야 한다.

또한 정적인 설계보다는 변화하는 요구사항에 유연하게 대응할 수 있는 진화 가능한 아키텍처를 설계하는 것이 중요하다.

특히 허브-스포크 모델은 클라우드 시대의 네트워크 아키텍처에서 중앙집중식 관리의 이점과 확장성을 동시에 제공하는 최적의 선택지 중 하나다. 하지만 단일 장애점과 성능 병목의 가능성을 항상 염두에 두고, 적절한 이중화와 모니터링 체계를 구축해야 한다.

미래의 네트워크는 더욱 동적이고 지능적인 형태로 진화할 것이며, 기존의 물리적 토폴로지 개념을 넘어서 소프트웨어 정의 네트워크와 AI 기반 자동화가 핵심 역할을 할 것이다.

이러한 변화에 대비하여 현재의 토폴로지 설계 시에도 미래 기술과의 호환성과 확장성을 고려한 전략적 접근이 필요하다.

궁극적으로 최적의 네트워크 토폴로지는 조직의 특성과 요구사항에 맞춘 맞춤형 설계를 통해서만 달성될 수 있으며, 지속적인 모니터링과 최적화를 통해 진화시켜 나가야 한다.

Reference

AWS Load Balancer 완전 비교 가이드

Somaz — Tue, 27 Jan 2026 00:00:18 +0900

Overview

AWS는 다양한 유형의 로드 밸런서를 제공하여 애플리케이션의 가용성, 확장성, 보안을 향상시킨다. 각 로드 밸런서는 고유한 특성과 최적화된 사용 사례를 가지고 있어, 올바른 선택이 시스템 성능과 비용에 큰 영향을 미친다.

본 가이드에서는 AWS의 4가지 주요 로드 밸런서(ALB, NLB, CLB, Gateway Load Balancer)의 특징, 성능, 사용 사례를 심층 분석하고, Terraform을 활용한 실제 구현 방법과 비용 최적화 전략을 제시한다.

이를 통해 여러분의 아키텍처에 가장 적합한 로드 밸런서를 선택하고 효율적으로 운영할 수 있는 실무 지식을 제공하겠다.

2022.02.13 - [AWS] - AWS IAM (Identity and Access Management) 개요 및 설정 방법

2022.02.13 - [AWS] - AWS S3 (Simple Storage Service) 개요 및 활용 방법

2023.03.30 - [AWS] - AWS Secrets Manager란?(OAuth, SSO)

2023.03.30 - [AWS] - AWS Cloudfront란? / Canary 및 Blue-Green 배포

2023.05.26 - [AWS] - AWS IRSA(IAM Roles for Service Accounts)란?

2024.11.16 - [AWS] - AWS Network ACL vs Security Group

2024.11.21 - [AWS] - ALB access Log 활성화 → S3 권한 설정 및 로그 저장

2025.09.02 - [AWS] - AWS EFS와 Kubernetes를 활용한 영구 스토리지 구축 가이드

2025.09.05 - [AWS] - AWS CDN 구축 가이드: Kubernetes + AWS CloudFront로 API와 정적 파일 서빙 최적화

2025.09.05 - [AWS] - AWS 네트워크 연결 방식 완전 비교: VPC Peering vs Transit Gateway vs VPN

2025.09.04 - [AWS] - AWS Load Balancer 완전 비교 가이드

AWS Load Balancer 완전 비교 가이드

1. AWS Load Balancer 종류별 특징

Application Load Balancer (ALB)

Layer 7 HTTP/HTTPS 트래픽을 위한 고급 로드 밸런서

핵심 특징

HTTP/HTTPS 프로토콜 지원 (Layer 7)
경로 기반, 호스트 기반 라우팅
웹소켓 및 HTTP/2 지원
컨테이너 및 람다 함수 지원
SSL/TLS 터미네이션
WAF 통합 가능
고급 헬스체크 옵션

성능 특성

처리량: 초당 수십만 요청 처리 가능
지연시간: 평균 1-5ms 추가 레이턴시
자동 확장: 트래픽에 따른 동적 확장

Network Load Balancer (NLB)

Layer 4 고성능 TCP/UDP 트래픽 로드 밸런서

핵심 특징

TCP, UDP, TLS 프로토콜 지원 (Layer 4)
초고성능 및 초저지연
고정 IP 주소 지원
Preserve client IP
Cross-zone 로드 밸런싱
PrivateLink 엔드포인트 지원

성능 특성

처리량: 초당 수백만 요청 처리 가능
지연시간: 100 마이크로초 미만
연결 처리: 초당 수백만 동시 연결

Classic Load Balancer (CLB)

레거시 EC2-Classic을 위한 기본 로드 밸런서

핵심 특징

Layer 4 (TCP) 및 Layer 7 (HTTP/HTTPS) 지원
EC2-Classic 및 VPC 지원
기본적인 헬스체크
SSL 터미네이션
제한된 라우팅 기능

현재 상태

AWS에서 사용 중단 권장
기존 워크로드 유지보수 목적으로만 사용
신규 프로젝트에서는 ALB 또는 NLB 권장

Gateway Load Balancer (GWLB)

네트워크 보안 어플라이언스를 위한 투명한 로드 밸런서

핵심 특징

Layer 3 (IP) 레벨에서 동작
GENEVE 프로토콜 사용
투명한 네트워크 게이트웨이
써드파티 보안 어플라이언스 통합
VPC 엔드포인트 서비스 지원

성능 특성

처리량: 수백만 패킷 처리 가능
지연시간: 극도로 낮은 레이턴시
확장성: 자동 확장 및 고가용성

2. 사용 사례별 최적 선택 가이드

ALB 최적 사용 사례

웹 애플리케이션 및 API 서비스
마이크로서비스 아키텍처
컨테이너 기반 애플리케이션 (ECS, EKS)
서버리스 아키텍처 (Lambda)
경로 기반 라우팅이 필요한 경우
고급 보안 기능 (WAF) 연동
A/B 테스팅 및 카나리 배포

실제 시나리오 예시

전자상품몰에서 `/api/products` 는 상품 서비스로, `/api/users` 는 사용자 서비스로 라우팅
React 프론트엔드와 Node.js API 서버 간 로드 밸런싱
쿠버네티스 클러스터의 서비스 노출

NLB 최적 사용 사례

초고성능이 필요한 애플리케이션
게임 서버 및 실시간 스트리밍
IoT 및 센서 데이터 처리
고정 IP가 필요한 서비스
TCP/UDP 기반 애플리케이션
온프레미스와의 VPN/DirectConnect 연결
극도로 낮은 지연시간이 요구되는 서비스

실제 시나리오 예시

온라인 게임의 게임 서버 클러스터
금융 거래 시스템의 실시간 데이터 처리
화상회의 시스템의 미디어 스트리밍 서버

Gateway Load Balancer 최적 사용 사례

방화벽 어플라이언스 배포
IDS/IPS 시스템 통합
DDoS 보호 솔루션
네트워크 모니터링 및 분석
써드파티 보안 도구 통합
네트워크 가상화 환경

실제 시나리오 예시

Palo Alto Networks 방화벽을 통한 트래픽 검사
Fortinet 보안 어플라이언스 클러스터 운영
네트워크 패킷 분석 및 로깅 시스템

3. Terraform 구현 예제 및 Kubernetes 사용 시 구현 예제

ALB Terraform 구현

# Application Load Balancer
resource "aws_lb" "main_alb" {
  name               = "main-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb_sg.id]
  subnets            = var.public_subnet_ids

  enable_deletion_protection = false
  
  access_logs {
    bucket  = aws_s3_bucket.alb_logs.id
    prefix  = "alb-logs"
    enabled = true
  }

  tags = {
    Environment = var.environment
    Name        = "main-alb"
  }
}

# Target Group
resource "aws_lb_target_group" "web_tg" {
  name     = "web-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = var.vpc_id
  
  health_check {
    enabled             = true
    healthy_threshold   = 2
    interval            = 30
    matcher             = "200"
    path                = "/health"
    port                = "traffic-port"
    protocol            = "HTTP"
    timeout             = 5
    unhealthy_threshold = 2
  }
  
  target_type = "instance"
  
  tags = {
    Name = "web-target-group"
  }
}

# Listener
resource "aws_lb_listener" "web_listener" {
  load_balancer_arn = aws_lb.main_alb.arn
  port              = "443"
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-TLS-1-2-2017-01"
  certificate_arn   = var.ssl_certificate_arn

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.web_tg.arn
  }
}

# Path-based routing
resource "aws_lb_listener_rule" "api_rule" {
  listener_arn = aws_lb_listener.web_listener.arn
  priority     = 100

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.api_tg.arn
  }

  condition {
    path_pattern {
      values = ["/api/*"]
    }
  }
}

# Security Group
resource "aws_security_group" "alb_sg" {
  name_prefix = "alb-sg"
  vpc_id      = var.vpc_id

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "alb-security-group"
  }
}

NLB Terraform 구현

# Network Load Balancer
resource "aws_lb" "main_nlb" {
  name               = "main-nlb"
  internal           = false
  load_balancer_type = "network"
  subnets            = var.public_subnet_ids

  enable_deletion_protection = false
  
  # Static IP allocation
  subnet_mapping {
    subnet_id     = var.public_subnet_ids[0]
    allocation_id = aws_eip.nlb_eip_1.id
  }
  
  subnet_mapping {
    subnet_id     = var.public_subnet_ids[1]
    allocation_id = aws_eip.nlb_eip_2.id
  }

  tags = {
    Environment = var.environment
    Name        = "main-nlb"
  }
}

# Elastic IPs for static IPs
resource "aws_eip" "nlb_eip_1" {
  vpc = true
  tags = {
    Name = "nlb-eip-1"
  }
}

resource "aws_eip" "nlb_eip_2" {
  vpc = true
  tags = {
    Name = "nlb-eip-2"
  }
}

# Target Group for TCP
resource "aws_lb_target_group" "tcp_tg" {
  name     = "tcp-tg"
  port     = 8080
  protocol = "TCP"
  vpc_id   = var.vpc_id
  
  health_check {
    enabled             = true
    healthy_threshold   = 2
    interval            = 30
    port                = "traffic-port"
    protocol            = "TCP"
    timeout             = 6
    unhealthy_threshold = 2
  }
  
  target_type = "instance"
  
  # Preserve client IP
  preserve_client_ip = true
  
  tags = {
    Name = "tcp-target-group"
  }
}

# Listener for TCP
resource "aws_lb_listener" "tcp_listener" {
  load_balancer_arn = aws_lb.main_nlb.arn
  port              = "80"
  protocol          = "TCP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.tcp_tg.arn
  }
}

Gateway Load Balancer Terraform 구현

# Gateway Load Balancer
resource "aws_lb" "gateway_lb" {
  name               = "gateway-lb"
  load_balancer_type = "gateway"
  subnets            = var.private_subnet_ids

  enable_deletion_protection = false

  tags = {
    Name = "gateway-load-balancer"
  }
}

# Target Group for GWLB
resource "aws_lb_target_group" "gwlb_tg" {
  name     = "gwlb-tg"
  port     = 6081
  protocol = "GENEVE"
  vpc_id   = var.vpc_id
  
  health_check {
    enabled             = true
    healthy_threshold   = 2
    interval            = 30
    port                = "80"
    protocol            = "HTTP"
    path                = "/health"
    timeout             = 5
    unhealthy_threshold = 2
  }
  
  target_type = "instance"
  
  tags = {
    Name = "gwlb-target-group"
  }
}

# GWLB Listener
resource "aws_lb_listener" "gwlb_listener" {
  load_balancer_arn = aws_lb.gateway_lb.arn

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.gwlb_tg.arn
  }
}

# VPC Endpoint Service
resource "aws_vpc_endpoint_service" "gwlb_endpoint_service" {
  acceptance_required        = false
  gateway_load_balancer_arns = [aws_lb.gateway_lb.arn]
  
  tags = {
    Name = "gwlb-endpoint-service"
  }
}

# VPC Endpoint
resource "aws_vpc_endpoint" "gwlb_endpoint" {
  vpc_id              = var.vpc_id
  service_name        = aws_vpc_endpoint_service.gwlb_endpoint_service.service_name
  vpc_endpoint_type   = "GatewayLoadBalancer"
  subnet_ids          = var.private_subnet_ids

  tags = {
    Name = "gwlb-endpoint"
  }
}

고급 ALB 구성 예제 (컨테이너 환경)

# ECS Service용 ALB 타겟 그룹
resource "aws_lb_target_group" "ecs_tg" {
  name                 = "ecs-service-tg"
  port                 = 80
  protocol             = "HTTP"
  vpc_id               = var.vpc_id
  target_type          = "ip"
  deregistration_delay = 30
  
  health_check {
    enabled             = true
    healthy_threshold   = 2
    interval            = 15
    matcher             = "200,404"
    path                = "/health"
    port                = "traffic-port"
    protocol            = "HTTP"
    timeout             = 5
    unhealthy_threshold = 3
  }
  
  tags = {
    Name = "ecs-target-group"
  }
}

# Lambda 함수용 타겟 그룹
resource "aws_lb_target_group" "lambda_tg" {
  name        = "lambda-tg"
  target_type = "lambda"
  
  health_check {
    enabled             = true
    healthy_threshold   = 2
    interval            = 30
    matcher             = "200"
    path                = "/health"
    timeout             = 5
    unhealthy_threshold = 2
  }
}

# Lambda 권한
resource "aws_lambda_permission" "allow_alb" {
  statement_id  = "AllowExecutionFromALB"
  action        = "lambda:InvokeFunction"
  function_name = var.lambda_function_name
  principal     = "elasticloadbalancing.amazonaws.com"
  source_arn    = aws_lb_target_group.lambda_tg.arn
}

Kubernetes Ingress 사용하여 구현

AWS Load Balancer Controller 설치

# Helm을 통한 AWS Load Balancer Controller 설치
helm repo add eks https://aws.github.io/eks-charts
helm repo update

helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  -n kube-system \
  --set clusterName=your-cluster-name \
  --set serviceAccount.create=false \
  --set serviceAccount.name=aws-load-balancer-controller

기본 Ingress 구성 예제

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-app-ingress
  namespace: default
  annotations:
    # ALB 생성 지정
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    
    # SSL/HTTPS 설정
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:123456789012:certificate/your-cert-arn
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/ssl-redirect: "443"
    
    # 로드 밸런서 이름 지정
    alb.ingress.kubernetes.io/load-balancer-name: web-app-alb
    
    # 헬스체크 설정
    alb.ingress.kubernetes.io/healthcheck-path: /health
    alb.ingress.kubernetes.io/healthcheck-interval-seconds: "30"
    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: "5"
    alb.ingress.kubernetes.io/healthy-threshold-count: "2"
    alb.ingress.kubernetes.io/unhealthy-threshold-count: "3"
    
    # External DNS 통합
    external-dns.alpha.kubernetes.io/hostname: webapp.example.com
  labels:
    app: web-app
spec:
  ingressClassName: alb
  rules:
  - host: webapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-app-service
            port:
              number: 80
---
apiVersion: v1
kind: Service
metadata:
  name: web-app-service
  namespace: default
spec:
  selector:
    app: web-app
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP

다중 서비스 라우팅 예제

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: microservices-ingress
  namespace: production
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:123456789012:certificate/your-cert-arn
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/ssl-redirect: "443"
    alb.ingress.kubernetes.io/load-balancer-name: microservices-alb
    
    # WAF 연결
    alb.ingress.kubernetes.io/wafv2-acl-arn: arn:aws:wafv2:us-west-2:123456789012:regional/webacl/your-waf/12345
    
    # 태그 지정
    alb.ingress.kubernetes.io/tags: Environment=production,Team=backend
  labels:
    app: microservices
spec:
  ingressClassName: alb
  rules:
  - host: api.example.com
    http:
      paths:
      # 사용자 서비스
      - path: /api/users
        pathType: Prefix
        backend:
          service:
            name: user-service
            port:
              number: 80
      # 상품 서비스
      - path: /api/products
        pathType: Prefix
        backend:
          service:
            name: product-service
            port:
              number: 80
      # 주문 서비스
      - path: /api/orders
        pathType: Prefix
        backend:
          service:
            name: order-service
            port:
              number: 80
      # 기본 경로
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80

공유 ALB 사용 예제 (제공해주신 파일 기반)

# 첫 번째 애플리케이션
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: alpha-game-app
  namespace: gameservice
  annotations:
    # 공유 ALB 그룹 설정
    alb.ingress.kubernetes.io/group.name: luckyday-shared-alb
    alb.ingress.kubernetes.io/group.order: "10"
    
    # 기본 ALB 설정
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/load-balancer-name: luckyday-shared-alb-loadbalancer
    
    # SSL/HTTPS 설정
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:eu-central-1:010339071704:certificate/14eeaf2b-e34e-416d-a1bb-fbfb18c9f59b
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/ssl-redirect: "443"
    
    # External DNS
    external-dns.alpha.kubernetes.io/hostname: alpha-game.luckyday.soulssvc.com
    
    # ArgoCD 추적
    argocd.argoproj.io/tracking-id: alpha-luckyday-game:networking.k8s.io/Ingress:luckyday/alpha-luckyday-game
  labels:
    app.kubernetes.io/instance: alpha-luckyday-game
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: alpha-luckyday-game
    app.kubernetes.io/version: 1.16.0
    helm.sh/chart: base-aws-0.1.0
spec:
  ingressClassName: alb
  rules:
  - host: alpha-game.luckyday.soulssvc.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: alpha-luckyday-game
            port:
              number: 80

---
# 두 번째 애플리케이션 (같은 ALB 공유)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: beta-game-app
  namespace: gameservice
  annotations:
    # 동일한 ALB 그룹 사용
    alb.ingress.kubernetes.io/group.name: luckyday-shared-alb
    alb.ingress.kubernetes.io/group.order: "20"
    
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/load-balancer-name: luckyday-shared-alb-loadbalancer
    
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:eu-central-1:010339071704:certificate/14eeaf2b-e34e-416d-a1bb-fbfb18c9f59b
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/ssl-redirect: "443"
    
    external-dns.alpha.kubernetes.io/hostname: beta-game.luckyday.soulssvc.com
spec:
  ingressClassName: alb
  rules:
  - host: beta-game.luckyday.soulssvc.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: beta-luckyday-game
            port:
              number: 80

고급 설정 예제 (실제 운영 환경)

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: production-app-ingress
  namespace: production
  annotations:
    # 기본 ALB 설정
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/load-balancer-name: production-app-alb
    
    # SSL/보안 설정
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:123456789012:certificate/your-cert-arn
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/ssl-redirect: "443"
    alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS-1-2-2017-01
    
    # 헬스체크 커스터마이징
    alb.ingress.kubernetes.io/healthcheck-path: /api/health
    alb.ingress.kubernetes.io/healthcheck-protocol: HTTPS
    alb.ingress.kubernetes.io/healthcheck-interval-seconds: "15"
    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: "5"
    alb.ingress.kubernetes.io/healthy-threshold-count: "2"
    alb.ingress.kubernetes.io/unhealthy-threshold-count: "3"
    
    # 성능 및 연결 설정
    alb.ingress.kubernetes.io/target-group-attributes: |
      deregistration_delay.timeout_seconds=30,
      slow_start.duration_seconds=60,
      stickiness.enabled=true,
      stickiness.lb_cookie.duration_seconds=86400
    
    # WAF 및 보안
    alb.ingress.kubernetes.io/wafv2-acl-arn: arn:aws:wafv2:us-west-2:123456789012:regional/webacl/production-waf/12345
    alb.ingress.kubernetes.io/security-groups: sg-12345678,sg-87654321
    
    # 서브넷 및 네트워크 설정
    alb.ingress.kubernetes.io/subnets: subnet-12345678,subnet-87654321
    
    # 로깅 및 모니터링
    alb.ingress.kubernetes.io/load-balancer-attributes: |
      access_logs.s3.enabled=true,
      access_logs.s3.bucket=my-alb-logs-bucket,
      access_logs.s3.prefix=production-app,
      deletion_protection.enabled=true
    
    # 태깅
    alb.ingress.kubernetes.io/tags: |
      Environment=production,
      Application=main-app,
      Team=platform,
      CostCenter=engineering
    
    # External DNS
    external-dns.alpha.kubernetes.io/hostname: app.example.com,www.example.com
  labels:
    app: production-app
    environment: production
spec:
  ingressClassName: alb
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: production-app-service
            port:
              number: 80
  - host: www.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: production-app-service
            port:
              number: 80

External DNS로 CDN 도메인도 관리

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cdn-integrated-ingress
  namespace: production
  annotations:
    # ALB 설정
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/load-balancer-name: cdn-origin-alb
    
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:123456789012:certificate/your-cert-arn
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/ssl-redirect: "443"
    
    # External DNS - 여러 도메인 관리
    external-dns.alpha.kubernetes.io/hostname: |
      origin.example.com,
      cdn.example.com
    
    # CDN 친화적 헤더 설정
    alb.ingress.kubernetes.io/load-balancer-attributes: |
      routing.http2.enabled=true,
      idle_timeout.timeout_seconds=60
    
    # Origin용 캐시 헤더 설정을 위한 커스텀 응답 헤더
    nginx.ingress.kubernetes.io/configuration-snippet: |
      more_set_headers "Cache-Control: public, max-age=31536000" if ($uri ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$);
      more_set_headers "Cache-Control: no-cache" if ($uri !~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$);
spec:
  ingressClassName: alb
  rules:
  - host: origin.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: webapp-service
            port:
              number: 80
  - host: cdn.example.com  # CDN 도메인도 같은 ALB로 처리 (CDN 없이 직접 접근 시)
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: webapp-service
            port:
              number: 80

CDN + External DNS를 위한 완전한 설정

# 1. Origin 전용 Ingress (CDN에서 사용)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: origin-ingress
  namespace: production
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/load-balancer-name: origin-alb
    
    # Origin 전용 인증서
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:us-west-2:123456789012:certificate/origin-cert
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS": 443}]'
    
    # Origin 도메인 - External DNS로 자동 생성
    external-dns.alpha.kubernetes.io/hostname: origin-api.example.com
    
    # CDN 최적화 설정
    alb.ingress.kubernetes.io/target-group-attributes: |
      deregistration_delay.timeout_seconds=10,
      stickiness.enabled=false
    
    # Origin 식별을 위한 태그
    alb.ingress.kubernetes.io/tags: "Purpose=CDN-Origin,Environment=production"
spec:
  ingressClassName: alb
  rules:
  - host: origin-api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

---
# 2. CDN Distribution (Terraform으로 생성되지만 참조용)
# terraform에서 다음과 같이 생성:
# resource "aws_cloudfront_distribution" "main" {
#   origin {
#     domain_name = "origin-api.example.com"  # 위 Ingress에서 생성된 도메인
#     origin_id   = "ALB-Origin"
#   }
#   aliases = ["api.example.com", "www.api.example.com"]
# }

---
# 3. CDN 도메인을 위한 External DNS 설정 (별도 관리)
apiVersion: v1
kind: Service
metadata:
  name: cdn-external-dns
  namespace: production
  annotations:
    # CloudFront Distribution 도메인을 External DNS로 관리
    external-dns.alpha.kubernetes.io/hostname: api.example.com
    external-dns.alpha.kubernetes.io/cloudfront-distribution-id: E1234567890123
spec:
  type: ExternalName
  externalName: d123456789.cloudfront.net  # CloudFront 도메인

4. 성능 비교 및 벤치마크

처리량 비교

로드 밸런서	최대 RPS	동시 연결	대역폭
ALB	~100,000 RPS	~25,000	~25 Gbps
NLB	~3,000,000 RPS	수백만	~100 Gbps
CLB	~10,000 RPS	~55,000	~10 Gbps
GWLB	패킷 기준	수백만	~100 Gbps

지연시간 비교

로드 밸런서	P50 지연시간	P99 지연시간	추가 홉
ALB	1-3ms	5-10ms	1 홉
NLB	0.1ms	0.5ms	투명
CLB	2-5ms	10-15ms	1 홉
GWLB	0.1ms	0.3ms	투명

기능 비교 매트릭스

기능	ALB	NLB	CLB	GWLB
Layer 7 라우팅	O	X	O	X
고정 IP	X	O	X	O
WebSocket	O	O	O	X
HTTP/2	O	X	X	X
SNI	O	O	X	X
WAF 통합	O	X	X	X
Lambda 지원	O	X	X	X
Cross-zone LB	기본값	옵션	옵션	기본값

5. 비용 최적화 전략

5.1 비용 구조 이해

ALB 비용 구성요소

시간당 요금: $0.0225/시간
LCU(Load Balancer Capacity Unit): $0.008/LCU
데이터 전송: 표준 EC2 요금

NLB 비용 구성요소

시간당 요금: $0.0225/시간
NLCU(Network Load Balancer Capacity Unit): $0.006/NLCU
데이터 전송: 표준 EC2 요금

GWLB 비용 구성요소

시간당 요금: $0.0225/시간
GWLCU(Gateway Load Balancer Capacity Unit): $0.004/GWLCU
VPC 엔드포인트: $0.01/시간

5.2 비용 최적화 기법

1. 적절한 로드 밸런서 선택

# 비용 효율적인 선택 로직
locals {
  # 트래픽이 적고 HTTP만 사용하는 경우 ALB
  use_alb = var.avg_requests_per_second < 1000 && var.protocol == "HTTP"
  
  # 고성능이 필요한 TCP 트래픽의 경우 NLB
  use_nlb = var.avg_requests_per_second > 10000 || var.protocol == "TCP"
  
  # 보안 어플라이언스 통합이 필요한 경우 GWLB
  use_gwlb = var.security_appliance_required
}

2. Cross-Zone 로드 밸런싱 최적화

# NLB에서 Cross-zone 로드 밸런싱 비용 고려
resource "aws_lb" "cost_optimized_nlb" {
  name               = "cost-optimized-nlb"
  load_balancer_type = "network"
  
  # Cross-zone 로드 밸런싱 비활성화로 데이터 전송 비용 절약
  # (단, 고가용성 고려 필요)
  enable_cross_zone_load_balancing = false
  
  subnets = var.subnet_ids
}

3. 타겟 그룹 최적화

# 효율적인 헬스체크 설정
resource "aws_lb_target_group" "optimized_tg" {
  name     = "optimized-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = var.vpc_id
  
  health_check {
    enabled             = true
    healthy_threshold   = 2
    interval            = 30  # 기본값, 더 짧게 하면 비용 증가
    matcher             = "200"
    path                = "/health"
    timeout             = 5
    unhealthy_threshold = 3
  }
  
  # 빠른 연결 해제로 비용 절약
  deregistration_delay = 30
}

4. 로그 및 모니터링 최적화

# 선택적 로그 활성화
resource "aws_lb" "log_optimized_alb" {
  name               = "log-optimized-alb"
  load_balancer_type = "application"
  subnets            = var.subnet_ids
  
  # 로그를 필요한 경우에만 활성화
  access_logs {
    bucket  = var.enable_access_logs ? aws_s3_bucket.alb_logs[0].id : ""
    enabled = var.enable_access_logs
  }
}

# S3 버킷 라이프사이클 정책으로 로그 비용 관리
resource "aws_s3_bucket_lifecycle_configuration" "alb_logs_lifecycle" {
  count  = var.enable_access_logs ? 1 : 0
  bucket = aws_s3_bucket.alb_logs[0].id

  rule {
    id     = "log_retention"
    status = "Enabled"

    expiration {
      days = 30  # 30일 후 삭제
    }

    transition {
      days          = 7
      storage_class = "STANDARD_IA"
    }

    transition {
      days          = 14
      storage_class = "GLACIER"
    }
  }
}

5.3 비용 모니터링 및 알람

# CloudWatch 비용 알람
resource "aws_cloudwatch_metric_alarm" "lb_cost_alarm" {
  alarm_name          = "lb-monthly-cost-alarm"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = "2"
  metric_name         = "EstimatedCharges"
  namespace           = "AWS/Billing"
  period              = "86400"  # 1일
  statistic           = "Maximum"
  threshold           = var.monthly_cost_threshold
  alarm_description   = "This metric monitors lb monthly charges"
  alarm_actions       = [var.sns_topic_arn]

  dimensions = {
    Currency = "USD"
    ServiceName = "AmazonEC2"  # 로드 밸런서는 EC2 서비스에 포함
  }
}

# LCU 사용량 모니터링
resource "aws_cloudwatch_metric_alarm" "alb_lcu_alarm" {
  alarm_name          = "alb-lcu-usage-high"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = "2"
  metric_name         = "ConsumedLCUs"
  namespace           = "AWS/ApplicationELB"
  period              = "300"
  statistic           = "Average"
  threshold           = var.lcu_threshold
  alarm_description   = "ALB LCU usage is too high"
  
  dimensions = {
    LoadBalancer = aws_lb.main_alb.arn_suffix
  }
}

5.4 예상 비용 계산 도구

# 변수 정의
variable "monthly_requests" {
  description = "Monthly request count"
  type        = number
  default     = 1000000
}

variable "avg_request_size" {
  description = "Average request size in KB"
  type        = number
  default     = 10
}

variable "avg_response_size" {
  description = "Average response size in KB"
  type        = number
  default     = 50
}

# 비용 계산 로컬 값
locals {
  # ALB 비용 계산
  alb_hourly_cost = 0.0225
  alb_monthly_hours = 24 * 30
  alb_base_cost = local.alb_hourly_cost * local.alb_monthly_hours
  
  # LCU 계산 (4가지 차원 중 최대값)
  new_connections_per_second = var.monthly_requests / (30 * 24 * 3600)
  requests_per_second = local.new_connections_per_second
  bandwidth_mbps = (var.avg_request_size + var.avg_response_size) * local.requests_per_second / 1024
  rule_evaluations_per_second = local.requests_per_second * 2  # 평균 2개 룰 평가
  
  max_lcu = max(
    local.new_connections_per_second / 25,    # 25 new connections/sec per LCU
    local.requests_per_second / 1000,         # 1000 requests/sec per LCU
    local.bandwidth_mbps / 1,                 # 1 Mbps per LCU
    local.rule_evaluations_per_second / 1000  # 1000 rule evaluations/sec per LCU
  )
  
  lcu_cost = local.max_lcu * 0.008 * local.alb_monthly_hours
  total_alb_cost = local.alb_base_cost + local.lcu_cost
}

# 비용 출력
output "estimated_monthly_cost" {
  value = {
    alb_base_cost = local.alb_base_cost
    lcu_cost = local.lcu_cost
    total_cost = local.total_alb_cost
    estimated_lcu = local.max_lcu
  }
}

6. 모니터링 및 트러블슈팅

6.1 핵심 메트릭 모니터링

# ALB 핵심 메트릭 대시보드
resource "aws_cloudwatch_dashboard" "alb_dashboard" {
  dashboard_name = "ALB-Monitoring-Dashboard"

  dashboard_body = jsonencode({
    widgets = [
      {
        type   = "metric"
        x      = 0
        y      = 0
        width  = 12
        height = 6

        properties = {
          metrics = [
            ["AWS/ApplicationELB", "RequestCount", "LoadBalancer", aws_lb.main_alb.arn_suffix],
            [".", "TargetResponseTime", ".", "."],
            [".", "HTTPCode_Target_2XX_Count", ".", "."],
            [".", "HTTPCode_Target_4XX_Count", ".", "."],
            [".", "HTTPCode_Target_5XX_Count", ".", "."],
            [".", "HealthyHostCount", "TargetGroup", aws_lb_target_group.web_tg.arn_suffix],
            [".", "UnHealthyHostCount", ".", "."]
          ]
          period = 300
          stat   = "Sum"
          region = var.aws_region
          title  = "ALB Key Metrics"
        }
      }
    ]
  })
}

# 중요 알람 설정
resource "aws_cloudwatch_metric_alarm" "high_response_time" {
  alarm_name          = "alb-high-response-time"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = "2"
  metric_name         = "TargetResponseTime"
  namespace           = "AWS/ApplicationELB"
  period              = "60"
  statistic           = "Average"
  threshold           = "1.0"  # 1초
  alarm_description   = "ALB response time is too high"
  alarm_actions       = [var.sns_topic_arn]

  dimensions = {
    LoadBalancer = aws_lb.main_alb.arn_suffix
  }
}

resource "aws_cloudwatch_metric_alarm" "high_error_rate" {
  alarm_name          = "alb-high-5xx-error-rate"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = "2"
  metric_name         = "HTTPCode_Target_5XX_Count"
  namespace           = "AWS/ApplicationELB"
  period              = "300"
  statistic           = "Sum"

마무리

핵심 선택 기준 요약

Application Load Balancer (ALB)는 HTTP/HTTPS 기반 웹 애플리케이션과 마이크로서비스에 최적화되어 있으며, 경로 기반 라우팅과 고급 보안 기능이 필요한 경우 최고의 선택이다. Kubernetes 환경에서 Ingress Controller를 통한 통합도 매우 원활하다.
Network Load Balancer (NLB)는 극도의 성능과 낮은 지연시간이 요구되는 TCP/UDP 애플리케이션에 이상적입니다. 게임 서버, 실시간 스트리밍, IoT 환경에서 탁월한 성능을 발휘한다.
Gateway Load Balancer (GWLB)는 네트워크 보안 어플라이언스의 투명한 통합을 위한 특수 목적 로드 밸런서로, 엔터프라이즈 보안 환경에서 필수적인 역할을 한다.

성공적인 구현을 위한 권장사항

아키텍처 설계 단계에서는 트래픽 패턴, 성능 요구사항, 보안 정책을 충분히 분석하여 적절한 로드 밸런서를 선택하고, Terraform과 같은 IaC 도구를 활용하여 일관되고 재현 가능한 인프라를 구축하자.
비용 최적화는 지속적인 모니터링과 조정을 통해 달성할 수 있습니다. LCU/NLCU 사용량을 정기적으로 검토하고, 불필요한 기능은 비활성화하며, 적절한 헬스체크 간격을 설정하여 비용을 절감하자.
운영 관리에서는 CloudWatch 메트릭과 알람을 통한 proactive 모니터링을 구축하고, 액세스 로그 분석을 통해 트래픽 패턴을 이해하며, 정기적인 성능 검토를 통해 지속적으로 최적화하자.

AWS 로드 밸런서는 단순한 트래픽 분산 도구를 넘어 현대적 애플리케이션 아키텍처의 핵심 구성 요소이다. 이 가이드의 모범 사례를 적용하여 안정적이고 확장 가능한 시스템을 구축하시기 바란다.

Reference

AWS Application Load Balancer 사용자 가이드
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/

AWS Network Load Balancer 사용자 가이드
https://docs.aws.amazon.com/elasticloadbalancing/latest/network/

AWS Gateway Load Balancer 사용자 가이드
https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/

Elastic Load Balancing 요금
https://aws.amazon.com/elasticloadbalancing/pricing/

AWS Load Balancer Controller 공식 가이드
https://kubernetes-sigs.github.io/aws-load-balancer-controller/
EKS 사용자 가이드 - Application Load Balancing
https://docs.aws.amazon.com/eks/latest/userguide/alb-ingress.html
AWS Load Balancer Controller Annotations
https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/ingress/annotations/

Terraform AWS Provider - ALB 리소스
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lb
Terraform AWS Provider - ALB Target Group
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lb_target_group
Terraform AWS Load Balancer 예제
https://github.com/terraform-aws-modules/terraform-aws-alb

CloudWatch 메트릭 - Application Load Balancer
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html
ALB 액세스 로그
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html
로드 밸런서 성능 최적화 가이드
https://aws.amazon.com/premiumsupport/knowledge-center/elb-latency-troubleshooting/

WAF와 ALB 통합
https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-associating-aws-resource.html
ALB 보안 정책
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies

Somaz | DevOps Engineer | Kubernetes & Cloud Infrastructure Specialist

Jenkins 서버 정전 후 복구 - 플러그인 버전 불일치 해결 가이드

Somaz — Fri, 23 Jan 2026 00:00:03 +0900

Overview

갑작스러운 서버 정전은 Jenkins 환경에 예상치 못한 문제를 일으킬 수 있다. 특히 정전 전에 개발자가 플러그인을 업데이트한 경우, 재시작 후 플러그인 버전 불일치로 인해 Jenkins가 정상적으로 작동하지 않을 수 있다.

이번 글에서는 서버 정전 후 Jenkins가 깨져서 Job이 보이지 않는 문제를 Jenkins 업그레이드를 통해 해결한 경험을 공유하겠다. macOS, Linux, Docker 컨테이너, Kubernetes 환경 등 다양한 플랫폼별 해결 방법을 다룬다.

문제 상황

발생한 문제

갑작스러운 서버 정전으로 Jenkins가 비정상 종료
정전 전 개발자가 플러그인을 업데이트했고, 재시작 과정에서 플러그인 버전이 상승
Jenkins 재시작 후 UI가 깨지면서 Job 목록이 전혀 보이지 않음
플러그인 버전 불일치로 인한 호환성 문제 발생

증상

Jenkins 웹 UI 접속은 가능하지만 Job 리스트가 표시되지 않음
플러그인 관리 페이지에서 경고 메시지 발생
일부 플러그인이 로드되지 않거나 오류 발생

해결 방법

1. Jenkins 백업 (필수!)

문제 해결을 시도하기 전에 반드시 현재 상태를 백업해야 한다.

# Jenkins 전체 백업
tar -czf ~/jenkins-backup-$(date +%Y%m%d).tar.gz ~/.jenkins

# 또는 중요한 설정만 백업
cd ~/.jenkins
tar -czf ~/jenkins-config-backup.tar.gz \
  config.xml \
  jobs/ \
  credentials.xml \
  secrets/ \
  users/

2. Homebrew로 설치한 경우 (권장)

macOS에서 Homebrew로 Jenkins를 설치한 경우 다음 절차를 따른다.

# 1. Jenkins 중지
brew services stop jenkins-lts

# 2. Java 21 설치 (의존성)
brew install openjdk@21

# 3. Homebrew 업데이트
brew update

# 4. Jenkins 업그레이드
brew upgrade jenkins-lts

# 5. Jenkins 시작
brew services start jenkins-lts

# 6. 버전 확인
brew info jenkins-lts

간소화된 버전

# Jenkins 중지
brew services stop jenkins-lts

# Homebrew 업데이트
brew update

# Jenkins 업그레이드
brew upgrade jenkins-lts

# Jenkins 재시작
brew services start jenkins-lts

# 버전 확인
brew info jenkins-lts

3. WAR 파일로 직접 설치한 경우

WAR 파일을 직접 다운로드하여 실행하는 경우

# 현재 Jenkins 중지 (실행 중인 터미널에서 Ctrl+C)

# 기존 WAR 파일 백업
cd ~/jenkins  # 또는 jenkins.war가 있는 디렉토리
mv jenkins.war jenkins.war.backup

# 최신 LTS 버전 다운로드
wget https://updates.jenkins.io/download/war/2.528.3/jenkins.war

# 또는 curl 사용
curl -L https://updates.jenkins.io/download/war/2.528.3/jenkins.war -o jenkins.war

# Jenkins 재시작
java -jar jenkins.war --httpPort=8080

4. Installer(.pkg)로 설치한 경우

macOS Installer 패키지로 설치한 경우

# 최신 Jenkins LTS Installer 다운로드
curl -L https://www.jenkins.io/download/thank-you-downloading-osx-installer-stable/ -o jenkins-installer.pkg

# 설치 (기존 버전 위에 덮어씀)
sudo installer -pkg jenkins-installer.pkg -target /

# Jenkins 재시작
sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
sudo launchctl load /Library/LaunchDaemons/org.jenkins-ci.plist

5. Linux - 패키지 관리자로 설치한 경우

Ubuntu/Debian

# 1. 현재 Jenkins 백업
sudo tar -czf /backup/jenkins-backup-$(date +%Y%m%d).tar.gz /var/lib/jenkins

# 2. Jenkins 중지
sudo systemctl stop jenkins

# 3. APT 업데이트
sudo apt update

# 4. Jenkins 업그레이드
sudo apt upgrade jenkins -y

# 5. Jenkins 시작
sudo systemctl start jenkins

# 6. 상태 확인
sudo systemctl status jenkins

# 7. 버전 확인
jenkins --version

CentOS/RHEL

# 1. 현재 Jenkins 백업
sudo tar -czf /backup/jenkins-backup-$(date +%Y%m%d).tar.gz /var/lib/jenkins

# 2. Jenkins 중지
sudo systemctl stop jenkins

# 3. YUM 업데이트
sudo yum update

# 4. Jenkins 업그레이드
sudo yum upgrade jenkins -y

# 5. Jenkins 시작
sudo systemctl start jenkins

# 6. 상태 확인
sudo systemctl status jenkins

# 7. 버전 확인
rpm -qa | grep jenkins

6. Docker 컨테이너 환경

단일 Docker 컨테이너

# 1. 현재 컨테이너 상태 확인
docker ps -a | grep jenkins

# 2. Jenkins 데이터 백업 (볼륨 백업)
docker run --rm \
  -v jenkins_home:/source \
  -v $(pwd):/backup \
  alpine tar -czf /backup/jenkins-backup-$(date +%Y%m%d).tar.gz -C /source .

# 3. 현재 컨테이너 중지 및 제거
docker stop jenkins
docker rm jenkins

# 4. 최신 Jenkins 이미지 Pull
docker pull jenkins/jenkins:lts

# 5. 새 컨테이너로 재시작 (기존 볼륨 재사용)
docker run -d \
  --name jenkins \
  -p 8080:8080 -p 50000:50000 \
  -v jenkins_home:/var/jenkins_home \
  jenkins/jenkins:lts

# 6. 로그 확인
docker logs -f jenkins

Docker Compose 사용

`docker-compose.yml` 업데이트

version: '3.8'

services:
  jenkins:
    image: jenkins/jenkins:lts  # 또는 jenkins/jenkins:2.528.3
    container_name: jenkins
    privileged: true
    user: root
    ports:
      - "8080:8080"
      - "50000:50000"
    volumes:
      - jenkins_home:/var/jenkins_home
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - JAVA_OPTS=-Djenkins.install.runSetupWizard=false
    restart: unless-stopped

volumes:
  jenkins_home:
    driver: local

업그레이드 실행

# 1. Jenkins 데이터 백업
docker run --rm \
  -v jenkins_home:/source \
  -v $(pwd):/backup \
  alpine tar -czf /backup/jenkins-backup-$(date +%Y%m%d).tar.gz -C /source .

# 2. 현재 컨테이너 중지
docker-compose down

# 3. 최신 이미지 Pull
docker-compose pull

# 4. 새 버전으로 재시작
docker-compose up -d

# 5. 로그 확인
docker-compose logs -f jenkins

7. Kubernetes 환경

Helm Chart 사용

# 1. 현재 Jenkins 상태 확인
kubectl get pods -n jenkins
helm list -n jenkins

# 2. Jenkins PVC 백업
kubectl get pvc -n jenkins
JENKINS_POD=$(kubectl get pod -n jenkins -l app.kubernetes.io/component=jenkins-controller -o jsonpath='{.items[0].metadata.name}')

# PVC 데이터를 로컬로 백업
kubectl exec -n jenkins $JENKINS_POD -- tar czf /tmp/jenkins-backup.tar.gz -C /var/jenkins_home .
kubectl cp jenkins/$JENKINS_POD:/tmp/jenkins-backup.tar.gz ./jenkins-backup-$(date +%Y%m%d).tar.gz

# 3. Helm Repository 업데이트
helm repo update

# 4. 현재 values.yaml 백업
helm get values jenkins -n jenkins > jenkins-values-backup.yaml

# 5. Jenkins Chart 업그레이드
helm upgrade jenkins jenkins/jenkins \
  -n jenkins \
  -f jenkins-values-backup.yaml \
  --version 5.1.0  # 최신 Chart 버전 지정

# 6. Rollout 상태 확인
kubectl rollout status statefulset/jenkins -n jenkins

# 7. Pod 상태 확인
kubectl get pods -n jenkins
kubectl logs -f $JENKINS_POD -n jenkins

`values.yaml` 예시 (이미지 버전 업데이트)

controller:
  image:
    repository: jenkins/jenkins
    tag: "2.528.3-lts"  # 최신 LTS 버전으로 업데이트
  
  # 리소스 설정
  resources:
    requests:
      cpu: "500m"
      memory: "2Gi"
    limits:
      cpu: "2000m"
      memory: "4Gi"
  
  # 백업 설정
  backup:
    enabled: true
    schedule: "0 2 * * *"
  
  # JVM 옵션
  javaOpts: "-Xmx2048m -Xms512m"
  
persistence:
  enabled: true
  size: 20Gi
  storageClass: "gp3"  # 환경에 맞게 수정

Kubernetes Manifest 사용

1. Deployment 업데이트

# jenkins-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: jenkins
  namespace: jenkins
spec:
  replicas: 1
  selector:
    matchLabels:
      app: jenkins
  template:
    metadata:
      labels:
        app: jenkins
    spec:
      containers:
      - name: jenkins
        image: jenkins/jenkins:2.528.3-lts  # 최신 버전으로 업데이트
        ports:
        - containerPort: 8080
        - containerPort: 50000
        volumeMounts:
        - name: jenkins-home
          mountPath: /var/jenkins_home
        resources:
          requests:
            memory: "2Gi"
            cpu: "500m"
          limits:
            memory: "4Gi"
            cpu: "2000m"
      volumes:
      - name: jenkins-home
        persistentVolumeClaim:
          claimName: jenkins-pvc

2. 업그레이드 실행

# 1. 현재 PVC 백업
JENKINS_POD=$(kubectl get pod -n jenkins -l app=jenkins -o jsonpath='{.items[0].metadata.name}')
kubectl exec -n jenkins $JENKINS_POD -- tar czf /tmp/jenkins-backup.tar.gz -C /var/jenkins_home .
kubectl cp jenkins/$JENKINS_POD:/tmp/jenkins-backup.tar.gz ./jenkins-backup-$(date +%Y%m%d).tar.gz

# 2. Deployment 업데이트 적용
kubectl apply -f jenkins-deployment.yaml

# 3. Rollout 상태 모니터링
kubectl rollout status deployment/jenkins -n jenkins

# 4. 새 Pod 확인
kubectl get pods -n jenkins

# 5. 로그 확인
NEW_POD=$(kubectl get pod -n jenkins -l app=jenkins -o jsonpath='{.items[0].metadata.name}')
kubectl logs -f $NEW_POD -n jenkins

StatefulSet으로 운영하는 경우

# 1. 현재 StatefulSet 백업
kubectl get statefulset jenkins -n jenkins -o yaml > jenkins-statefulset-backup.yaml

# 2. PVC 백업
JENKINS_POD=$(kubectl get pod -n jenkins -l app=jenkins -o jsonpath='{.items[0].metadata.name}')
kubectl exec -n jenkins $JENKINS_POD -- tar czf /tmp/jenkins-backup.tar.gz -C /var/jenkins_home .
kubectl cp jenkins/$JENKINS_POD:/tmp/jenkins-backup.tar.gz ./jenkins-backup-$(date +%Y%m%d).tar.gz

# 3. StatefulSet 이미지 업데이트
kubectl set image statefulset/jenkins jenkins=jenkins/jenkins:2.528.3-lts -n jenkins

# 또는 직접 편집
kubectl edit statefulset jenkins -n jenkins

# 4. Rollout 상태 확인
kubectl rollout status statefulset/jenkins -n jenkins

# 5. Pod 재시작 확인
kubectl get pods -n jenkins -w

업그레이드 후 확인 사항

1. Jenkins 접속 확인

브라우저에서 Jenkins URL에 접속하여 정상 작동을 확인한다.

각 환경별 기본 URL

macOS/Linux: `http://localhost:8080`
Docker: `http://localhost:8080`
Kubernetes: Service/Ingress에 설정된 URL

2. Job 목록 확인

Dashboard에서 모든 Job이 정상적으로 표시되는지 확인
각 Job의 설정이 유지되었는지 점검

3. 플러그인 업데이트

Jenkins가 정상적으로 작동하면 모든 플러그인을 최신 버전으로 업데이트한다.

플러그인 업데이트 절차

Jenkins 관리 → Plugin Manager 접속
"Updates" 탭에서 업데이트 가능한 플러그인 확인
"Select All" 선택 후 "Download now and install after restart" 클릭
재시작 체크박스 선택하여 자동 재시작

4. 최종 검증

macOS/Linux

# Jenkins 로그 확인
# Homebrew 설치
tail -f /opt/homebrew/var/log/jenkins-lts/jenkins.log

# Linux systemd
sudo journalctl -u jenkins -f

# Linux 전통 방식
tail -f /var/log/jenkins/jenkins.log

Docker

# 컨테이너 로그 확인
docker logs -f jenkins

# Docker Compose
docker-compose logs -f jenkins

Kubernetes

# Pod 로그 확인
kubectl logs -f <jenkins-pod-name> -n jenkins

# 실시간 이벤트 모니터링
kubectl get events -n jenkins --watch

# Pod 상태 확인
kubectl describe pod <jenkins-pod-name> -n jenkins

문제 해결 팁

플러그인 버전 불일치 방지

정기적인 Jenkins 및 플러그인 업데이트: 최신 버전을 유지하여 호환성 문제 예방
업데이트 전 백업: 모든 업데이트 전에 백업 수행
점진적 업데이트: 한 번에 모든 플러그인을 업데이트하지 말고 중요도에 따라 단계적으로 진행
테스트 환경 활용: 가능하면 프로덕션 환경 적용 전 테스트 환경에서 먼저 검증

서버 정전 대비

인프라 레벨

UPS(무정전 전원 공급 장치) 사용: 갑작스러운 정전으로부터 보호
클라우드 환경 활용: AWS/GCP/Azure 등의 고가용성 인프라 사용
Multi-AZ 배포: Kubernetes 환경에서 여러 가용 영역에 분산 배치

애플리케이션 레벨

정기적인 백업 자동화

# Cron job으로 일일 백업 설정 (Linux)
0 2 * * * tar -czf ~/jenkins-backups/jenkins-$(date +\%Y\%m\%d).tar.gz /var/lib/jenkins

Kubernetes CronJob을 이용한 백업

apiVersion: batch/v1
kind: CronJob
metadata:
  name: jenkins-backup
  namespace: jenkins
spec:
  schedule: "0 2 * * *"  # 매일 새벽 2시
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: alpine
            command:
            - /bin/sh
            - -c
            - |
              tar czf /backup/jenkins-$(date +%Y%m%d).tar.gz -C /var/jenkins_home .
              # S3나 다른 스토리지로 업로드하는 로직 추가 가능
            volumeMounts:
            - name: jenkins-home
              mountPath: /var/jenkins_home
            - name: backup
              mountPath: /backup
          restartPolicy: OnFailure
          volumes:
          - name: jenkins-home
            persistentVolumeClaim:
              claimName: jenkins-pvc
          - name: backup
            persistentVolumeClaim:
              claimName: jenkins-backup-pvc

Jenkins Configuration as Code (JCasC) 사용

# jenkins.yaml
jenkins:
  systemMessage: "Jenkins configured automatically by JCasC"
  numExecutors: 5
  mode: NORMAL
  securityRealm:
    local:
      allowsSignup: false
  authorizationStrategy:
    loggedInUsersCanDoAnything:
      allowAnonymousRead: false
  
  crumbIssuer:
    standard:
      excludeClientIPFromCrumb: false

unclassified:
  location:
    url: "https://jenkins.yourdomain.com"
    adminAddress: "admin@yourdomain.com"

컨테이너 환경 특화 팁

Docker

Named Volume 사용: 데이터 영속성 보장
Health Check 설정: 컨테이너 상태 모니터링

services:
  jenkins:
    image: jenkins/jenkins:lts
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:8080/login || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 60s

Kubernetes

PersistentVolume 백업: 정기적인 스냅샷 생성
ReadinessProbe/LivenessProbe 설정: 자동 복구 기능
StorageClass 선택: 백업/스냅샷 기능을 지원하는 스토리지 사용 (AWS EBS, GCP PD 등)

livenessProbe:
  httpGet:
    path: /login
    port: 8080
  initialDelaySeconds: 90
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 5

readinessProbe:
  httpGet:
    path: /login
    port: 8080
  initialDelaySeconds: 60
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3

마무리

Jenkins는 DevOps 파이프라인의 핵심 도구이지만, 갑작스러운 장애 상황에서 취약할 수 있다. 특히 서버 정전과 같은 예기치 않은 상황에서는 플러그인 버전 불일치로 인한 심각한 문제가 발생할 수 있다.

이번 트러블슈팅에서 핵심은 Jenkins 자체를 최신 버전으로 업그레이드하여 플러그인 호환성을 확보하는 것이었다. 업그레이드 후 모든 플러그인을 최신 버전으로 업데이트하고 재부팅하니 정상적으로 작동했다.

교훈

항상 백업을 우선시하세요
Jenkins와 플러그인을 최신 상태로 유지하세요
정전과 같은 장애 상황에 대비한 예방책을 마련하세요
문제 발생 시 단계적으로 접근하세요 (백업 → 업그레이드 → 플러그인 업데이트)

플랫폼별 권장사항

macOS: Homebrew를 통한 관리로 의존성 자동 해결
Linux: 패키지 관리자를 활용한 안정적인 업데이트
Docker: 이미지 버전 관리와 볼륨 백업 전략 수립
Kubernetes: Helm Chart 사용과 자동화된 백업 CronJob 구성

Jenkins 환경을 안정적으로 운영하기 위해서는 정기적인 유지보수와 백업 전략이 필수적이다. 특히 컨테이너 오케스트레이션 환경에서는 선언적 구성 관리(IaC)와 자동화된 백업 시스템이 더욱 중요하다. 이번 경험이 비슷한 문제를 겪는 분들께 도움이 되기를 바란다.

Reference

Somaz | DevOps Engineer | Kubernetes & Cloud Infrastructure Specialist

Supermicro 서버 IPMI 설정 및 팬 제어 가이드

Somaz — Tue, 20 Jan 2026 00:07:09 +0900

Overview

서버 관리에서 하드웨어 모니터링과 원격 관리는 필수적인 요소다. 특히 Supermicro 서버의 경우 IPMI(Intelligent Platform Management Interface)를 통해 강력한 하드웨어 관리 기능을 제공한다.

이번 글에서는 실제 서버 환경에서 IPMI 설정과 팬 제어를 시도했던 과정을 단계별로 살펴보고, 각 단계에서 마주친 문제점과 해결 방법을 공유하겠다.

Supermicro 서버 IPMI 설정 및 팬 제어 가이드

서버 환경 확인

먼저 서버의 기본 정보를 확인해보았다.

sensors
... (정상적인 온도 출력) ...

sensors | grep -i fan
# 아무런 결과도 나오지 않음

sudo pwmconfig
# pwmconfig version 3.6.0
...
/usr/sbin/pwmconfig: There are no pwm-capable sensor modules installed

sensors가 팬 속도 정보를 보여주지 않았고, pwmconfig는 "pwm-capable sensor modules이 없다"는 메시지를 반환했다.
이는 운영체제(소프트웨어)가 팬을 직접 제어할 수 있는 하드웨어 인터페이스를 찾지 못했다는 의미이다.
대부분의 엔터프라이즈 서버는 BMC(Baseboard Management Controller) 칩을 통해 팬, 전원, 온도 등을 관리하며, 이 BMC는 IPMI 프로토콜을 사용한다.
즉, 팬 제어가 소프트웨어가 아닌 하드웨어 레벨에서 이루어지고 있었던 것이다.

IPMI를 통한 하드웨어 정보 확인

서버급 하드웨어에서는 IPMI를 통해 더 정확한 하드웨어 정보를 얻을 수 있다.

sudo ipmitool sdr list | grep -i fan
...
FAN1             | no reading        | ns
FAN2             | 3360 RPM          | ok
FANA             | 2240 RPM          | ok
FANB             | 2100 RPM          | ok
FANC             | no reading        | ns

sudo ipmitool sensor list | grep -i fan
...
FAN1             | na         |            | na    | na        | na        | na        | na        | na        | na        
FAN2             | 3220.000   | RPM        | ok    | na        | 420.000   | na        | na        | na        | na        
FANA             | 2240.000   | RPM        | ok    | na        | 420.000   | na        | na        | na        | na        
FANB             | 2100.000   | RPM        | ok    | na        | 420.000   | na        | na        | na        | na        
FANC             | na         |            | na    | na        | na        | na        | na        | na        | na

IPMI를 통해 확인한 팬 정보는 다음과 같았다.

FAN1: 측정값 없음 (no reading)
FAN2: 약 2800-3220 RPM
FANA: 약 1400-2240 RPM
FANB: 약 1400-2100 RPM
FANC: 측정값 없음 (no reading)

IPMI 네트워크 설정 및 웹 접근 활성화

IPMI 네트워크 정보 확인

sudo ipmitool lan print 1
...
Set in Progress         : Set Complete
Auth Type Support       : NONE MD2 MD5 PASSWORD 
Auth Type Enable        : Callback : MD2 MD5 PASSWORD 
                        : User     : MD2 MD5 PASSWORD 
                        : Operator : MD2 MD5 PASSWORD 
                        : Admin    : MD2 MD5 PASSWORD 
                        : OEM      : MD2 MD5 PASSWORD 
IP Address Source       : Static Address
IP Address              : 10.10.10.14
Subnet Mask             : 255.255.255.0
MAC Address             : 90:5a:08:74:a9:13
SNMP Community String   : public
IP Header               : TTL=0x00 Flags=0x00 Precedence=0x00 TOS=0x00
BMC ARP Control         : ARP Responses Enabled, Gratuitous ARP Disabled
Default Gateway IP      : 10.10.10.1
Default Gateway MAC     : 00:00:00:00:00:00
Backup Gateway IP       : 0.0.0.0
Backup Gateway MAC      : 00:00:00:00:00:00
802.1q VLAN ID          : Disabled
802.1q VLAN Priority    : 0
RMCP+ Cipher Suites     : 3,17
Cipher Suite Priv Max   : aaXXXXXXXXXXXXX
                        :     X=Cipher Suite Unused
                        :     c=CALLBACK
                        :     u=USER
                        :     o=OPERATOR
                        :     a=ADMIN
                        :     O=OEM
Bad Password Threshold  : 3
Invalid password disable: yes
Attempt Count Reset Int.: 300
User Lockout Interval   : 300

서버의 BMC는 다음과 같이 설정되어 있었다.

IP 주소: 10.10.10.14
서브넷 마스크: 255.255.255.0
MAC 주소: 90:5a:08:74:a9:13

사용자 계정 웹 접근 활성화

IPMI 웹 인터페이스에 접근하기 위해 기존 계정들의 웹 접근을 활성화했다.

sudo ipmitool user list 1
ID  Name             Callin  Link Auth  IPMI Msg   Channel Priv Limit
1                    true    false      false      Unknown (0x00)
2   ADMIN            false   false      true       ADMINISTRATOR
3   somazxc          true    false      true       ADMINISTRATOR
4   fwupd            true    false      false      Unknown (0x00)

# ADMIN 계정의 웹 접근 활성화
sudo ipmitool channel setaccess 1 2 link=on ipmi=on callin=on privilege=4

# somazxc 계정의 웹 접근도 활성화
sudo ipmitool channel setaccess 1 3 link=on ipmi=on callin=on privilege=4

확인해본다.

sudo ipmitool user list 1
ID  Name             Callin  Link Auth  IPMI Msg   Channel Priv Limit
1                    true    false      false      Unknown (0x00)
2   ADMIN            true    true       true       ADMINISTRATOR
3   somazxc          true    true       true       ADMINISTRATOR
4   fwupd            true    false      false      Unknown (0x00)

BMC 재시작과 안정성 문제

BMC 재시작 시도

설정 변경사항을 적용하기 위해 BMC를 재시작했다.

sudo ipmitool mc reset warm

재시작 후 불안정성

팬 속도를 조절하기 위해 몇 가지 IPMI 명령어를 시도했지만, `Unable to send RAW command` 와 같은 오류가 발생했다. 이는 IPMI 컨트롤러 자체에 일시적인 문제가 있거나 통신이 원활하지 않다는 신호였다.

sudo ipmitool mc info
Get Device ID command failed: Unspecified error

`mc reset warm` 명령어로 컨트롤러를 재시작했지만 문제가 해결되지 않았다. 그러다가 IPMI 통신을 초기화하는 raw 명령어를 발견하고 실행했다.

sudo ipmitool raw 0x06 0x02
sudo ipmitool mc info
Device ID          : 32
...
Device ID                 : 32
Device Revision           : 1
Firmware Revision         : 1.03
IPMI Version              : 2.0
Manufacturer ID           : 10876
Manufacturer Name         : Supermicro
Product ID                : 7290 (0x1c7a)
Product Name              : Unknown (0x1C7A)
Device Available          : yes
Provides Device SDRs      : no
Additional Device Support :
    Sensor Device
    SDR Repository Device
    SEL Device
    FRU Inventory Device
    IPMB Event Receiver
    IPMB Event Generator
    Chassis Device
Aux Firmware Rev Info     : 
    0x05
    0x03
    0x00
    0x00

명령어를 실행한 후 IPMI 컨트롤러가 정상적으로 응답하기 시작했다. Supermicro 서버의 경우, 이 raw 명령어가 내부 통신 문제를 해결하는 데 효과적이었던 것으로 보인다.

최종 결과: 팬 소음의 감소

IPMI 컨트롤러와의 통신을 정상화한 후 다시 팬 상태를 확인했다.

sudo ipmitool sdr list | grep -i fan
FAN1             | no reading      | ns
FAN2             | 2800 RPM        | ok
FANA             | 1400 RPM        | ok
FANB             | 1400 RPM        | ok
FANC             | no reading      | ns

놀랍게도 FAN2, FANA, FANB의 RPM이 초기 상태보다 훨씬 낮아진 것을 확인할 수 있었다. 팬 소음은 즉시 확연히 줄어들었다.

이는 IPMI 컨트롤러가 통신 문제 해결 후 자동 모드로 돌아가서, 현재 시스템 온도에 맞춰 필요한 만큼만 팬 속도를 조절하기 시작했기 때문이다.

센서 오류로 인한 팬 제어 문제 해결

문제 발견: 이중 온도 센서의 모순

IPMI 통신을 정상화한 후에도 팬 소음이 계속 지속되는 상황이 발생했다. 온도를 다시 확인해보니 흥미로운 사실을 발견할 수 있었다.

Linux sensors 출력

sensors
nct6798-isa-0a30
Adapter: ISA adapter
...
CPUTIN:                +127.5°C  (high = +80.0°C, hyst = +75.0°C)  ALARM  sensor = CPU diode
...

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +30.0°C  (high = +87.0°C, crit = +95.0°C)
Core 0:        +28.0°C  (high = +87.0°C, crit = +95.0°C)
Core 1:        +26.0°C  (high = +87.0°C, crit = +95.0°C)

IPMI 센서 출력

sudo ipmitool sdr type temperature
CPU Temp         | 01h | ok  |  3.1 | 29 degrees C
PCH Temp         | 0Ah | ok  |  7.1 | 38 degrees C
System Temp      | 0Bh | ok  |  7.2 | 27 degrees C

두 시스템이 완전히 다른 CPU 온도를 보고하고 있었다.

nct6798 센서: 127.5°C (과열 상태)
IPMI 센서: 29°C (정상 상태)
coretemp 센서: 26-30°C (정상 상태)

문제 분석

이는 메인보드의 nct6798 센서 칩이 CPU 온도를 잘못 읽고 있는 상황이었다. 시스템의 팬 제어 로직이 이 잘못된 127.5°C 값을 기준으로 작동하여 팬을 최대 속도로 돌리고 있었던 것이다.

실제로는

CPU 온도: 정상 (26-30°C)
시스템 부하: 낮음
팬 속도: 불필요하게 최대

해결 방법 1: 센서 설정 파일로 무시

가장 깔끔한 해결책은 잘못된 센서를 무시하도록 설정하는 것이다.

sudo nano /etc/sensors.d/supermicro.conf

설정 파일에 다음 내용을 추가한다.

chip "nct6798-*"
    # CPUTIN 센서 무시 (잘못된 127.5°C 값 출력)
    ignore temp2
    
    # 필요시 다른 문제 센서도 무시
    ignore temp1

설정을 적용한다.

sudo sensors -s

해결 방법 2: 모듈 완전 비활성화

더 확실한 방법은 문제가 있는 센서 모듈을 아예 비활성화하는 것이다.

sudo nano /etc/modprobe.d/blacklist-sensors.conf

다음 내용을 추가한다

# nct6798 센서 모듈 비활성화 (잘못된 온도 값 출력)
blacklist nct6798

현재 로드된 모듈을 제거한다.

sudo modprobe -r nct6798

결과 확인

설정 적용 후 sensors 명령어를 다시 실행하면

sensors
# nct6798 섹션에서 CPUTIN: +127.5°C 라인이 사라짐
# 또는 nct6798 섹션 전체가 사라짐 (모듈 비활성화 시)

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +30.0°C  (high = +87.0°C, crit = +95.0°C)
# 정상적인 온도만 표시됨

팬 상태 재확인

sudo ipmitool sdr type fan
FAN1             | 41h | ns  | 29.1 | No Reading
FAN2             | 42h | ok  | 29.2 | 2800 RPM  # 이전 3360 RPM에서 감소
FANA             | 47h | ok  | 29.7 | 1400 RPM  # 이전 2100 RPM에서 감소  
FANB             | 48h | ok  | 29.8 | 1400 RPM  # 이전 2100 RPM에서 감소
FANC             | 49h | ns  | 29.9 | No Reading

결과

이중 센서 시스템: 최신 서버는 여러 온도 센서를 가지고 있으며, 각각 다른 값을 보고할 수 있다.
센서 우선순위: 시스템이 어떤 센서를 팬 제어 기준으로 사용하는지 파악하는 것이 중요하다.
하드웨어 vs 소프트웨어: IPMI(하드웨어)와 lm-sensors(소프트웨어)가 서로 다른 센서에서 정보를 가져올 수 있다.
선택적 비활성화: 잘못된 센서는 무시하고 정확한 센서만 사용하도록 설정할 수 있다.

이 경험을 통해 서버 관리에서는 단순히 명령어 하나로 해결되지 않는 복합적인 문제들이 존재하며, 각 센서의 역할과 시스템 간의 상호작용을 이해하는 것이 얼마나 중요한지 알 수 있었다.

추가 내용

Fan Mode 변경

sensors-detect가 Nuvoton NCT6798D Super IO Sensors를 찾았음
이 칩은 팬 제어가 가능한 하드웨어 모니터링 칩

sudo sensors-detect
# sensors-detect version 3.6.0
# System: Supermicro Super Server [0123456789]
# Board: Supermicro X13SRA-TF
# Kernel: 5.15.0-153-generic x86_64
# Processor: Intel(R) Xeon(R) w5-2465X (6/143/8)

This program will help you determine which kernel modules you need
to load to use lm_sensors most effectively. It is generally safe
and recommended to accept the default answers to all questions,
unless you know what you're doing.

Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no):  yes  
Module cpuid loaded successfully.
Silicon Integrated Systems SIS5595...                       No
VIA VT82C686 Integrated Sensors...                          No
VIA VT8231 Integrated Sensors...                            No
AMD K8 thermal sensors...                                   No
AMD Family 10h thermal sensors...                           No
AMD Family 11h thermal sensors...                           No
AMD Family 12h and 14h thermal sensors...                   No
AMD Family 15h thermal sensors...                           No
AMD Family 16h thermal sensors...                           No
AMD Family 17h thermal sensors...                           No
AMD Family 15h power sensors...                             No
AMD Family 16h power sensors...                             No
Hygon Family 18h thermal sensors...                         No
Intel digital thermal sensor...                             Success!
    (driver `coretemp')
Intel AMB FB-DIMM thermal sensor...                         No
Intel 5500/5520/X58 thermal sensor...                       No
VIA C7 thermal sensor...                                    No
VIA Nano thermal sensor...                                  No

Some Super I/O chips contain embedded sensors. We have to write to
standard I/O ports to probe them. This is usually safe.
Do you want to scan for Super I/O sensors? (YES/no): yes
Probing for Super-I/O at 0x2e/0x2f
Trying family `National Semiconductor/ITE'...               No
Trying family `SMSC'...                                     No
Trying family `VIA/Winbond/Nuvoton/Fintek'...               Yes
Found `Nuvoton NCT6798D Super IO Sensors'                   Success!
    (address 0xa30, driver `nct6775')

Module을 로드한다.

sudo modprobe nct6775
sudo modprobe coretemp

Sensors 명령어로 확인해본다.

sensors

nct6798-isa-0a30
Adapter: ISA adapter
in0:                     1.83 V  (min =  +0.00 V, max =  +1.74 V)  ALARM
in1:                     1.25 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                     3.34 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                     3.36 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                     1.80 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                   1000.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                     1.81 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in7:                     3.34 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                     3.04 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                   496.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                  896.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                  576.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                    1.06 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                    1.08 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                    1.06 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                     0 RPM  (min =    0 RPM)
fan2:                     0 RPM  (min =    0 RPM)
fan3:                     0 RPM  (min =    0 RPM)
fan4:                     0 RPM  (min =    0 RPM)
fan5:                     0 RPM  (min =    0 RPM)
fan7:                     0 RPM  (min =    0 RPM)
SYSTIN:                 +29.0°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
CPUTIN:                +127.5°C  (high = +80.0°C, hyst = +75.0°C)  ALARM  sensor = CPU diode
AUXTIN0:                -23.5°C    sensor = thermistor
AUXTIN1:                -23.0°C    sensor = thermistor
AUXTIN2:                +18.0°C    sensor = thermistor
AUXTIN3:                +23.0°C    sensor = thermistor
PCH_CHIP_CPU_MAX_TEMP:   +0.0°C  
PCH_CHIP_TEMP:           +0.0°C  
PCH_CPU_TEMP:            +0.0°C  
PCH_MCH_TEMP:            +0.0°C  
intrusion0:            ALARM
intrusion1:            ALARM
beep_enable:           disabled

eno2-pci-0500
Adapter: PCI adapter
PHY Temperature:  +43.0°C  
MAC Temperature:  +43.0°C  

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +30.0°C  (high = +87.0°C, crit = +95.0°C)
Core 0:        +27.0°C  (high = +87.0°C, crit = +95.0°C)
Core 1:        +26.0°C  (high = +87.0°C, crit = +95.0°C)
Core 2:        +30.0°C  (high = +87.0°C, crit = +95.0°C)
Core 3:        +26.0°C  (high = +87.0°C, crit = +95.0°C)
Core 4:        +26.0°C  (high = +87.0°C, crit = +95.0°C)
Core 5:        +28.0°C  (high = +87.0°C, crit = +95.0°C)
Core 6:        +28.0°C  (high = +87.0°C, crit = +95.0°C)
Core 7:        +26.0°C  (high = +87.0°C, crit = +95.0°C)
Core 8:        +27.0°C  (high = +87.0°C, crit = +95.0°C)
Core 9:        +25.0°C  (high = +87.0°C, crit = +95.0°C)
Core 10:       +28.0°C  (high = +87.0°C, crit = +95.0°C)
Core 11:       +27.0°C  (high = +87.0°C, crit = +95.0°C)
Core 12:       +25.0°C  (high = +87.0°C, crit = +95.0°C)
Core 13:       +27.0°C  (high = +87.0°C, crit = +95.0°C)
Core 14:       +28.0°C  (high = +87.0°C, crit = +95.0°C)
Core 15:       +28.0°C  (high = +87.0°C, crit = +95.0°C)

IPMI 팬 모드 변경한다.

sudo ipmitool raw 0x30 0x45 0x00
02

sudo ipmitool raw 0x30 0x45 0x01 0x00

sudo ipmitool raw 0x30 0x45 0x00
00

`0x02 (Optimal)` 에서 `0x00 (Standard)` 로 성공적으로 변경됨

현재 상태 분석할 수 있다.

sudo ipmitool raw 0x30 0x70 0x66 0x00  # 결과: 2f
sudo ipmitool raw 0x30 0x45 0x00        # 결과: 00

`0x2f` (47 decimal) = 현재 팬 속도가 약 **18%**로 설정되어 있음
`0x00` = Standard 자동 모드가 아직 활성화되어 있다.

또는 수동 모드로 변경도 가능하다.

# 12% 속도 (0x20 = 32 decimal)
sudo ipmitool raw 0x30 0x70 0x66 0x01 0x00 0x20

# 20% 속도 (0x33 = 51 decimal)
sudo ipmitool raw 0x30 0x70 0x66 0x01 0x00 0x33

# 25% 속도 (0x40 = 64 decimal) 
sudo ipmitool raw 0x30 0x70 0x66 0x01 0x00 0x40

# 30% 속도 (0x4D = 77 decimal)
sudo ipmitool raw 0x30 0x70 0x66 0x01 0x00 0x4D

다시 자동모드로 변경하는 방법은 아래와 같다.

# 자동 팬 제어 모드로 복원
sudo ipmitool raw 0x30 0x30 0x01 0x01

# 그 다음 Standard 모드로 설정
sudo ipmitool raw 0x30 0x45 0x01 0x00

# 현재 모드 확인
sudo ipmitool raw 0x30 0x45 0x00

마무리: 하드웨어 관리의 중요성

`lm-sensors` 나 `fancontrol` 로 해결되지 않는 팬 소음은 대부분 하드웨어 레벨의 문제이며, 이럴 땐 IPMI(또는 벤더사에서 제공하는 관리 도구)를 사용해야 한다.

이 경험을 통해 얻은 교훈은 다음과 같다.

IPMI 우선: 서버 팬 제어는 소프트웨어보다 IPMI를 통한 하드웨어 제어가 기본 방식일 수 있다.
IPMI 통신 점검: `ipmitool` 을 사용해 `mc info` 가 정상 작동하는지 확인하고, 문제가 있다면 초기화 명령어를 시도하자.
팬 속도 자동 조절: IPMI 통신이 정상화되면 대부분의 BMC는 시스템 부하에 따라 팬 속도를 자동으로 최적화한다.

최종적으로 잘못된 nct6798 센서를 비활성화한 후

팬 소음이 현저히 감소
CPU 온도 모니터링은 정확한 IPMI와 coretemp 센서로 유지
시스템 안정성과 사용자 경험 모두 개선

서버 환경에서는 이처럼 하드웨어와 소프트웨어가 복합적으로 작용하는 문제들이 자주 발생한다. 각 컴포넌트의 역할을 정확히 파악하고 문제의 근본 원인을 찾아 해결하는 것이 효과적인 서버 관리의 핵심이다.

Reference

https://www.supermicro.com/en/

https://www.intel.com/content/www/us/en/servers/ipmi/ipmi-second-gen-interface-spec-v2-rev1-1.html

https://linux.die.net/man/1/ipmitool

https://hwmon.wiki.kernel.org/lm_sensors

Somaz | DevOps Engineer | Kubernetes & Cloud Infrastructure Specialist

Claude 4.5 Sonnet vs Gemini 3 Pro 비교: 2026년 최신 AI 모델 대결

Somaz — Sat, 17 Jan 2026 00:00:49 +0900

Overview

2025년 말부터 2026년 초까지, AI 업계에서 가장 주목받는 두 모델이 등장했다. Anthropic의 Claude 4.5 Sonnet과 Google의 Gemini 3 Pro는 각각 2025년 9월과 11월에 출시되어 AI 모델의 새로운 기준을 제시하고 있다. 개발자 관점에서 이 두 모델을 심층 비교해보겠다.

1. 기본 스펙 비교

Claude 4.5 Sonnet

출시일: 2025년 9월 29일
학습 데이터 기준: 2025년 4월
컨텍스트 윈도우: 200K 토큰 (기본), 1M 토큰 (베타)
가격: 입력 $3/M 토큰, 출력 $15/M 토큰
특징: 코딩 특화, 에이전트 워크플로우 최적화

Gemini 3 Pro

출시일: 2025년 11월 18일
학습 데이터 기준: 2025년 1월
컨텍스트 윈도우: 1M 토큰 (기본), 출력 64K 토큰
가격: 입력 $127/M 토큰, 출력 $12/M 토큰 (약 42배 비쌈)
특징: 멀티모달 추론, 광범위한 벤치마크 우수성

2. 코딩 성능: 실전 벤치마크 분석

SWE-bench Verified (실제 GitHub 이슈 해결)

Claude 4.5 Sonnet: 77.2% (역대 최고 점수)

실제 오픈소스 프로젝트의 버그 수정 능력 측정
코드베이스 이해, 버그 재현, 수정 구현, 테스트 통과 필요
Replit 내부 벤치마크에서 0% 에러율 달성

Gemini 3 Pro: 76.2%

Claude와 거의 대등한 성능
1%p 차이는 실무에서 큰 차이는 아님

개발자 관점: 실제 코드 수정 작업에서는 두 모델 모두 우수하나, Claude가 약간 앞선다.

LiveCodeBench Pro (알고리즘 코딩)

Gemini 3 Pro: 2,439 Elo (압도적 우위)

Codeforces 스타일의 경쟁 프로그래밍
GPT-5.1(2,243 Elo)보다 196점 높음
알고리즘 설계와 엣지 케이스 처리에 탁월

Claude 4.5 Sonnet: 1,418 Elo

Gemini보다 1,000점 이상 낮음
알고리즘 경진 문제에서는 명확히 약세

개발자 관점: 알고리즘 문제 해결이나 코딩 테스트 준비에는 Gemini가 월등히 우수하다.

Terminal-Bench 2.0 (터미널 에이전트 코딩)

Claude 4.5 Sonnet: 61.3% (Extended Thinking 모드)

최초로 60% 돌파
터미널 도구 사용, 파일 편집, 멀티스텝 작업에 강점

Gemini 3 Pro: 54.2%

선방했지만 Claude에 밀림

개발자 관점: CLI 기반 워크플로우나 자동화 스크립트 작성에는 Claude가 더 적합하다.

3. 에이전트 성능 비교

장시간 자율 작업

Claude 4.5 Sonnet

30시간 이상 자율 작업 실증
멀티스텝 추론과 코드 실행 유지
Computer Use 기능: OSWorld 벤치마크 61.4% (최고 기록)

Gemini 3 Pro

τ2-bench: 85.4% (Claude 84.7%)
Vending-Bench 2: $5,478.16 (Claude $3,838.74)
장기 의사결정 프로세스에서 더 안정적

개발자 관점

복잡한 자동화 워크플로우: Claude (Computer Use 우수)
장기 실행 에이전트: Gemini (더 높은 안정성)

4. 멀티모달 능력

Gemini 3 Pro의 압승

MMMU-Pro: 81% (Claude 68%)
Video-MMMU: 87.6% (Claude 77.8%)
ScreenSpot-Pro: 72.7% (Claude 36.2%)
텍스트, 이미지, 비디오, 오디오, 코드 통합 처리

Claude 4.5 Sonnet

주로 텍스트와 이미지에 집중
멀티모달 벤치마크에서 전반적으로 열세

개발자 관점: UI/UX 관련 작업, 비디오 분석, 멀티모달 데이터 처리는 Gemini가 필수이다.

5. 추론 및 수학 능력

Humanity's Last Exam (PhD 수준 추론)

Gemini 3 Pro: 37.5% (도구 미사용)

Deep Think 모드: 41.0%
철학, 수학, 생물학 등 다양한 도메인

Claude 4.5 Sonnet: 13.7%

Gemini 대비 약 3배 낮은 점수

GPQA Diamond (전문가 수준 과학)

Gemini 3 Pro: 91.9% (인간 전문가 ~89.8% 초과)

Deep Think: 93.8%

Claude 4.5 Sonnet: 83.4%

MathArena Apex (최고난도 수학)

Gemini 3 Pro: 23.4%
Claude 4.5 Sonnet: 1.6%
GPT-5.1: 1.0%

개발자 관점: 과학 계산, 복잡한 수학 문제, 연구 수준 추론이 필요하면 Gemini를 선택해야 한다.

6. 프론트엔드 개발

Claude 4.5 Sonnet

기능적이고 실용적인 디자인
빠른 반복 편집에 적합
IDE 스타일 워크플로우에 최적화

Gemini 3 Pro

시각적으로 세련되고 상호작용적인 출력
복잡한 UI 애니메이션과 WebGL 작업 우수
Figma 목업에서 HTML/CSS 변환 탁월
프로덕션 수준의 폴리시

실제 사례: Gemini는 레이 트레이싱 씬, 인터랙티브 비주얼라이제이션 등 창의적 작업에서 압도적 우위

개발자 관점

기본 CRUD 앱, 내부 툴: Claude (빠르고 실용적)
고급 UI, 마케팅 사이트, 인터랙티브 경험: Gemini (시각적 품질)

7. 가격 대비 성능

Claude 4.5 Sonnet

입력: $3/M 토큰
출력: $15/M 토큰
Opus 4.1의 1/5 가격으로 동등 이상 성능
프롬프트 캐싱과 배치 실행으로 추가 절감

Gemini 3 Pro

입력: $127/M 토큰 (Claude의 42배)
출력: $12/M 토큰 (Claude의 0.8배)
전반적으로 훨씬 비쌈

100M 토큰/월 사용 시 비용 비교

Claude: 입력 $300 + 출력 $1,500 = $1,800
Gemini: 입력 $12,700 + 출력 $1,200 = $13,900

개발자 관점: 예산이 제한적이거나 대규모 서비스라면 Claude가 압도적으로 유리하다.

8. 컨텍스트 윈도우 및 속도

컨텍스트 윈도우

Gemini 3 Pro: 1M 토큰 기본 제공 (입력), 64K 토큰 (출력)
Claude 4.5 Sonnet: 200K 토큰 기본, 1M 토큰 베타

활용 사례

전체 코드베이스 분석: Gemini (1M 기본)
대용량 PDF, 내부 위키: Gemini
일반 개발 작업: Claude (200K로 충분)

응답 속도

Claude: 상대적으로 빠른 응답
Gemini: 복잡한 추론 시 지연 발생 가능 (Deep Think 모드는 더 느림)

9. 안전성 및 정렬

Claude 4.5 Sonnet

유해 응답률: 1.29% → 0.71% 개선
과도한 거부율: 0.15% → 0.02% (7.5배 감소)
ASL-3 보안 수준 (CBRN 위험 자동 차단)
"가장 정렬된 프론티어 모델"

Gemini 3 Pro

강력한 안전 필터 적용
상세한 안전성 벤치마크는 미공개

10. 실제 사용 사례별 추천

Claude 4.5 Sonnet을 선택해야 하는 경우

실무 코딩 어시스턴트 (IDE 통합)
CI/CD 파이프라인, 인프라 자동화
버그 수정, 리팩토링, 코드 리뷰
CLI 기반 워크플로우
비용 효율적인 대규모 서비스
30시간 이상 장시간 자율 작업
컴퓨터 사용 (브라우저, 터미널 제어)

Gemini 3 Pro를 선택해야 하는 경우

알고리즘 경진 대회, 코딩 테스트 준비
복잡한 수학, 과학 연구
PhD 수준 추론이 필요한 작업
멀티모달 데이터 처리 (비디오, 오디오)
고급 UI/UX 개발
전체 코드베이스 분석 (1M 토큰)
비주얼 디자인에서 코드 생성
장기 의사결정 에이전트

하이브리드 전략

많은 개발자들이 실제로 두 모델을 병행 사용하고 있다.

계획 및 아키텍처 설계: Claude (논리적 사고)
알고리즘 최적화: Gemini (알고리즘 강점)
일반 코딩: Claude (비용 효율)
UI/비주얼 작업: Gemini (디자인 품질)

11. 2026년 전망

Claude의 과제

알고리즘 코딩 능력 개선 필요 (LiveCodeBench)
멀티모달 능력 강화 필요
컨텍스트 윈도우 1M 정식 출시 필요

Gemini의 과제

응답 속도 개선 (특히 반복 작업)
실무 코딩에서 Claude 수준으로 개선

업계 트렌드

에이전트 중심 개발: 두 모델 모두 에이전트 워크플로우에 집중
멀티모달 표준화: 텍스트+이미지+비디오+코드 통합이 기본이 될 전망
가격 경쟁: 고성능 모델의 가격 하락 압력 증가
특화 vs 범용: Claude는 코딩 특화, Gemini는 범용 전략

마무리

2026년 초 현재, Claude 4.5 Sonnet과 Gemini 3 Pro는 서로 다른 강점을 가진 최고 수준의 모델이다.

DevOps 엔지니어 관점에서의 최종 추천

실무 개발 환경에서는 Claude 4.5 Sonnet

SWE-bench에서 최고 점수 (77.2%)
비용 효율성 (42배 저렴)
터미널 작업에 강점
장시간 자율 작업 능력
즉각적인 프로덕션 투입 가능

연구, 알고리즘, 멀티모달 작업에는 Gemini 3 Pro

알고리즘 코딩 압도적 우위 (LiveCodeBench 2,439 Elo)
PhD 수준 추론 능력
멀티모달 작업에서 타의 추종 불허
1M 토큰 기본 제공

개인적 경험을 토대로 한 조언: Kubernetes 클러스터 관리, CI/CD 파이프라인 구축, 인프라 자동화 같은 DevOps 작업에는 Claude 4.5 Sonnet이 더 적합했다. 실용적이고, 빠르며, 비용 효율적이다.

반면, 복잡한 알고리즘 최적화나 멀티모달 데이터를 다루는 특수한 경우에는 Gemini 3 Pro가 탁월했다.

결론: 대부분의 실무 개발자에게는 Claude 4.5 Sonnet이 현재 최선의 선택이며, 특정 도메인(알고리즘, 멀티모달)에서 필요할 때만 Gemini 3 Pro를 활용하는 전략이 가장 합리적이다.

Reference

Anthropic. (2025). "Introducing Claude Sonnet 4.5". https://www.anthropic.com/news/claude-sonnet-4-5
Google DeepMind. (2025). "Gemini 3: Introducing the latest Gemini AI model". https://blog.google/products/gemini/gemini-3/
Caylent. (2025). "Claude Sonnet 4.5: Highest-Scoring Claude Model Yet on SWE-bench". https://caylent.com/blog/claude-sonnet-4-5-highest-scoring-claude-model-yet-on-swe-bench
DataCamp. (2025). "Gemini 3: Google's Most Powerful LLM". https://www.datacamp.com/blog/gemini-3
Simon Willison. (2025). "Trying out Gemini 3 Pro with audio transcription and a new pelican benchmark". https://simonwillison.net/2025/Nov/18/gemini-3/
Vellum AI. (2025). "Google Gemini 3 Benchmarks (Explained)". https://www.vellum.ai/blog/google-gemini-3-benchmarks
AceCloud. (2025). "Claude Opus 4.5 Vs Gemini 3 Pro Vs Sonnet 4.5 Comparison Guide". https://acecloud.ai/blog/claude-opus-4-5-vs-gemini-3-pro-vs-sonnet-4-5/
CometAPI. (2025). "Gemini 3 Pro vs Claude 4.5 Sonnet for Coding: Which is Better in 2025". https://www.cometapi.com/gemini-3-pro-vs-claude-4-5-sonnet-for-coding/
InfoQ. (2025). "Claude Sonnet 4.5 Tops SWE-Bench Verified, Extends Coding Focus beyond 30 Hours". https://www.infoq.com/news/2025/10/claude-sonnet-4-5/
VentureBeat. (2025). "Google unveils Gemini 3 claiming the lead in math, science, multimodal, and agentic AI benchmarks". https://venturebeat.com/ai/google-unveils-gemini-3-claiming-the-lead-in-math-science-multimodal-and
JDuncan.io. (2025). "Gemini 3 Pro vs Claude Sonnet 4.5: Antigravity IDE Review". https://jduncan.io/blog/2025-11-20-google-antigravity-gemini-3-first-impressions/
SWE-bench Official Leaderboard. https://www.swebench.com/
LiveCodeBench Leaderboard. https://livecodebench.github.io/leaderboard.html

Somaz | DevOps Engineer | Kubernetes & Cloud Infrastructure Specialist

Claude Code 완벽 가이드: Mac에서 시작하기

Somaz — Thu, 15 Jan 2026 00:00:16 +0900

Overview

터미널에서 바로 AI와 코딩하는 시대가 왔다. Claude Code는 Anthropic에서 만든 CLI 기반 에이전틱 코딩 도구로, IDE를 벗어나 터미널에서 직접 Claude와 대화하며 코드를 작성하고, 수정하고, 디버깅할 수 있다.

Claude Code란?

Claude Code는 단순한 코드 자동완성 도구가 아니다. 터미널에서 실행되는 에이전트로, 프로젝트의 컨텍스트를 이해하고 파일을 직접 읽고 쓰며, 쉘 명령어까지 실행할 수 있다. 개발자가 자연어로 지시하면 Claude가 알아서 코드를 수정하고 테스트까지 돌려준다.

설치 방법

사전 요구사항

macOS 10.15 이상
Node.js 18 이상

Node.js가 없다면 먼저 설치한다.

# Homebrew로 Node.js 설치
brew install node

# 버전 확인
node --version

Claude Code 설치

npm install -g @anthropic-ai/claude-code

설치가 완료되면 claude 명령어를 사용할 수 있다.

트러블 슈팅

만약 npm registry를 offical로 사용하고 있지 않다면 아래의 명령어를 사용해서 변경해준다.

npm config get registry

공식 npm 레지스트리로 변경

npm config set registry https://registry.npmjs.org/

또는 일시적으로 레지스트리 지정해서 설치할 수도 있다.

npm install -g @anthropic-ai/claude-code --registry https://registry.npmjs.org/

이렇게 하면 기존 설정 건드리지 않고 설치 가능하다.

시작하기

인증

Pro 요금제를 사용 중이라면 별도의 API 키 없이 Anthropic 계정으로 바로 인증할 수 있다.

# 프로젝트 디렉토리로 이동
cd ~/projects/my-app

# Claude Code 실행
claude

처음 실행하면 브라우저가 열리면서 계정 인증을 진행한다. 인증이 완료되면 바로 대화형 모드로 진입한다.

기본 사용법

Claude Code는 크게 세 가지 방식으로 사용할 수 있다.

# 1. 대화형 REPL 모드
claude

# 2. 일회성 질문
claude "이 프로젝트의 구조를 설명해줘"

# 3. 이전 대화 이어서 계속
claude -c

주요 명령어 정리

터미널 명령어

명령어	설명
claude	대화형 REPL 모드 시작
claude "질문"	한 번만 질문하고 종료
claude -c	마지막 대화 이어서 계속
claude -p "질문"	파이프라인 모드 (스크립트 연동용)
claude config	설정 메뉴 열기
claude update	최신 버전으로 업데이트

REPL 모드 슬래시 명령어

대화형 모드에서 사용할 수 있는 명령어들이다.

명령어	설명
/help	전체 도움말 보기
/clear	대화 내역 초기화
/compact	컨텍스트 압축 (토큰 절약)
/cost	현재 세션 토큰 사용량 확인
/doctor	설치 및 환경 진단
/init	프로젝트 설정 파일 생성
/quit	종료 (Ctrl+C 두 번도 가능)
/model	모델 변경

web console 사용량을 공유한다.

실전 활용 예시

코드 이해 및 설명

claude "src/api/auth.ts 파일이 어떤 역할을 하는지 설명해줘"

버그 수정

claude "npm run build 하면 타입 에러가 나. 고쳐줘"

리팩토링

claude "이 함수를 더 읽기 쉽게 리팩토링해줘"

테스트 작성

claude "UserService 클래스에 대한 Jest 테스트 코드 만들어줘"

Git 작업

claude "변경사항 확인하고 적절한 커밋 메시지로 커밋해줘"

문서화

claude "이 프로젝트의 README.md를 작성해줘"

프로젝트 설정

프로젝트 루트에 CLAUDE.md 파일을 만들어두면 Claude가 프로젝트 컨텍스트를 더 잘 이해한다.

claude /init

`CLAUDE.md` 에 담으면 좋은 내용은 다음과 같다.

프로젝트 개요 및 기술 스택
주요 디렉토리 구조
빌드 및 실행 방법
코딩 컨벤션
자주 쓰는 명령어

Pro 요금제 사용 팁

Pro 플랜은 월간 사용량 제한이 있다. 효율적으로 사용하려면 다음을 참고하자.

`/cost` 명령어로 현재 세션의 토큰 사용량을 수시로 확인한다.
`/compact` 명령어로 긴 대화의 컨텍스트를 압축해 토큰을 절약한다.
단순한 질문은 웹 버전 Claude를 활용하고, 코드 작업이 필요할 때 Claude Code를 사용한다.

사용량이 많아지면 일시적으로 속도 제한이 걸릴 수 있다.

문제 해결

설치나 실행에 문제가 있다면 진단 명령어를 실행해본다.

claude /doctor

자주 발생하는 문제와 해결법은 다음과 같다.

permission denied 에러: `sudo npm install -g @anthropic-ai/claude-code` 또는 npm 권한 설정 확인
Node.js 버전 문제: `node --version` 으로 18 이상인지 확인
인증 실패: `claude config` 에서 계정 다시 연결

Claude Code 활용

Claude Code는 단순히 코드를 작성하는 것 이상으로, 개발 워크플로우 전반에 걸쳐 활용할 수 있다.

코드베이스 이해하기

새로운 프로젝트에 투입되었을 때 가장 먼저 해야 할 일은 코드베이스를 파악하는 것이다.

# 프로젝트 전체 구조 파악
claude "이 프로젝트의 아키텍처를 설명해줘"

# 특정 파일의 역할 이해
claude "src/services/payment.ts가 어떤 로직을 처리하는지 알려줘"

# 함수 간 의존관계 분석
claude "handleCheckout 함수가 호출하는 다른 함수들을 다이어그램으로 보여줘"

코드 작성 및 수정

자연어로 원하는 기능을 설명하면 Claude가 직접 파일을 생성하거나 수정한다.

# 새 기능 구현
claude "사용자 프로필 이미지 업로드 API를 만들어줘. S3에 저장하고 URL을 반환해야 해"

# 기존 코드 개선
claude "이 함수에 에러 핸들링 추가해줘"

# 타입 정의 생성
claude "API 응답에 맞는 TypeScript 인터페이스 만들어줘"

디버깅 및 문제 해결

에러 메시지를 복사해서 붙여넣으면 원인 분석부터 해결까지 도와준다.

# 에러 분석
claude "이 에러 메시지가 왜 나오는 거야? [에러 내용 붙여넣기]"

# 로그 분석
claude "이 로그에서 문제가 되는 부분을 찾아줘"

# 성능 이슈 진단
claude "이 쿼리가 왜 느린지 분석해줘"

테스트 및 품질 관리

테스트 코드 작성부터 코드 리뷰까지 자동화할 수 있다.

# 단위 테스트 생성
claude "UserService에 대한 테스트 코드 작성해줘"

# 테스트 커버리지 개선
claude "커버리지가 낮은 부분에 테스트 추가해줘"

# 코드 리뷰
claude "이 PR의 변경사항을 리뷰해줘"

Git 워크플로우 자동화

커밋, 브랜치 관리, PR 생성까지 터미널에서 처리할 수 있다.

# 커밋 메시지 자동 생성
claude "변경사항 보고 커밋 메시지 작성해서 커밋해줘"

# PR 설명 작성
claude "이 브랜치의 변경사항으로 PR 설명을 작성해줘"

# 충돌 해결
claude "merge conflict 해결해줘"

Infrastructure as Code 작업

DevOps 작업에도 유용하게 활용할 수 있다.

# Terraform 코드 작성
claude "AWS EKS 클러스터를 생성하는 Terraform 코드 만들어줘"

# Kubernetes 매니페스트 생성
claude "이 애플리케이션을 위한 Deployment와 Service YAML 만들어줘"

# CI/CD 파이프라인 구성
claude "GitHub Actions로 빌드, 테스트, 배포 파이프라인 만들어줘"

프로젝트 관리

Claude Code는 프로젝트별로 컨텍스트를 관리할 수 있어 여러 프로젝트를 효율적으로 다룰 수 있다.

CLAUDE.md 설정

프로젝트 루트에 `CLAUDE.md` 파일을 생성하면 Claude가 프로젝트 컨텍스트를 자동으로 인식한다.

# 자동 생성
claude /init

# 또는 직접 생성
touch CLAUDE.md

CLAUDE.md 예시

# 프로젝트: MyApp API Server

## 기술 스택
- Node.js 20 + TypeScript
- Express.js
- PostgreSQL + Prisma ORM
- Jest for testing

## 디렉토리 구조
- src/controllers: API 엔드포인트 핸들러
- src/services: 비즈니스 로직
- src/repositories: 데이터 접근 계층
- src/middlewares: 인증, 로깅 등 미들웨어

## 명령어
- npm run dev: 개발 서버 실행
- npm run build: 프로덕션 빌드
- npm run test: 테스트 실행
- npm run migrate: DB 마이그레이션

## 컨벤션
- 커밋 메시지는 Conventional Commits 형식 사용
- 함수명은 camelCase, 클래스명은 PascalCase
- API 응답은 { success, data, error } 형식 통일

프로젝트별 설정 관리

여러 프로젝트를 오가며 작업할 때는 각 프로젝트 디렉토리에서 Claude Code를 실행하면 된다.

# 프로젝트 A 작업
cd ~/projects/frontend-app
claude

# 프로젝트 B로 전환
cd ~/projects/backend-api
claude

각 디렉토리의 `CLAUDE.md` 를 읽어 해당 프로젝트에 맞는 컨텍스트로 동작한다.

대화 히스토리 관리

# 이전 대화 이어서 작업
claude -c

# 새로운 대화 시작 (기존 컨텍스트 초기화)
claude

# REPL 모드에서 대화 초기화
/clear

# 컨텍스트가 너무 길어졌을 때 압축
/compact

팀 프로젝트에서 활용

`CLAUDE.md` 를 Git에 커밋해두면 팀원 모두 동일한 컨텍스트로 Claude Code를 사용할 수 있다.

# .gitignore에 추가하지 않음
git add CLAUDE.md
git commit -m "docs: add CLAUDE.md for AI-assisted development"

팀 컨벤션, 자주 쓰는 명령어, 프로젝트 특이사항 등을 문서화해두면 온보딩에도 도움이 된다.

마무리

Claude Code는 터미널 기반 개발 워크플로우를 완전히 바꿔놓을 도구다. 기존에 IDE 플러그인 형태로 제공되던 AI 코딩 도구들과 달리, CLI에서 직접 동작하기 때문에 SSH로 접속한 원격 서버에서도, CI/CD 파이프라인에서도, 심지어 Vim이나 Neovim만 쓰는 환경에서도 활용할 수 있다.

특히 DevOps 엔지니어 입장에서 보면 Terraform 코드 작성, Kubernetes 매니페스트 수정, 쉘 스크립트 디버깅 같은 작업을 터미널을 벗어나지 않고 처리할 수 있다는 점이 매력적이다. `kubectl get pods` 결과를 보면서 바로 "이 에러 원인이 뭐야?"라고 물어볼 수 있고, Claude가 직접 YAML 파일을 수정해주기도 한다.

아직 발전 중인 도구라 가끔 불안정할 수 있지만, 터미널 중심으로 작업하는 개발자라면 한 번쯤 도입을 고려해볼 만하다. Pro 요금제를 이미 사용 중이라면 추가 비용 없이 바로 시작할 수 있으니, 오늘 설치해서 직접 경험해보자.

Reference

Somaz | DevOps Engineer | Kubernetes & Cloud Infrastructure Specialist

Kubernetes Redis 클러스터 장애 처리 및 복구 가이드

Somaz — Tue, 13 Jan 2026 00:00:39 +0900

Overview

Redis 클러스터는 고가용성과 확장성을 제공하는 강력한 분산 캐시 솔루션이다. 하지만 Kubernetes 환경에서 운영하다 보면 네트워크 분할, 노드 재시작, 설정 문제 등으로 인해 클러스터 상태가 불안정해질 수 있다.

본 글에서는 Redis 클러스터에서 자주 발생하는 "ClusterAllFailedError"와 "Cluster state changed: fail" 문제를 진단하고 해결하는 실무적인 방법을 다룬다.

특히 `slots cache` 갱신 실패 문제부터 클러스터 완전 복구까지의 단계별 접근법을 상세히 알아보겠다.

2022.09.26 - [Open Source Software] - Redis(Remote Dictionary Server)란?

2025.04.02 - [CS 지식] - [CS 지식20.] OS 캐시와 디스크 I/O: MySQL, Redis 퍼포먼스 분석

장애 증상 분석

애플리케이션 레벨 에러

Redis 클라이언트(ioredis)에서 다음과 같은 에러가 발생한다.

[ioredis] Unhandled error event: ClusterAllFailedError: Failed to refresh slots cache.
    at tryNode (/app/node_modules/.pnpm/ioredis@5.7.0/node_modules/ioredis/built/cluster/index.js:323:31)
    at /app/node_modules/.pnpm/ioredis@5.7.0/node_modules/ioredis/built/cluster/index.js:340:21
    at Timeout.<anonymous> (/app/node_modules/.pnpm/ioredis@5.7.0/node_modules/ioredis/built/cluster/index.js:699:24)

이 에러는 다음을 의미한다.

클라이언트가 Redis 클러스터의 slots 정보를 갱신할 수 없음
모든 클러스터 노드에 대한 연결이 실패
클러스터 토폴로지 정보 동기화 문제

Redis 서버 레벨 증상

각 Redis 노드의 로그에서 확인되는 패턴

# 초기 시작 시
1:M 02 Sep 2025 05:58:10.944 * Cluster state changed: ok

# 몇 초 후 상태 변화
1:M 02 Sep 2025 05:58:26.645 # Cluster state changed: fail

정상 시작 후 실패로 전환되는 원인

클러스터 노드 간 네트워크 통신 문제
노드 검색 실패 (node discovery)
slots 할당 불일치
클러스터 구성 정보 불일치

단계별 진단 및 해결

1단계: 클러스터 상태 진단

먼저 현재 클러스터 상태를 정확히 파악한다.

# 기본 클러스터 정보 확인
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli cluster info

# 노드 구성 및 상태 확인
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli cluster nodes

# 각 노드별 상태 확인
kubectl exec -it -n gameserver-cache redis-main-1 -- redis-cli cluster info
kubectl exec -it -n gameserver-cache redis-main-2 -- redis-cli cluster info

주요 확인 포인트:

`cluster_state`: ok/fail 상태
`cluster_slots_assigned`: 16384개 slots 할당 상태
`cluster_known_nodes`: 인식된 노드 수
`cluster_size`: 실제 클러스터 크기

2단계: 네트워크 연결성 검증

클러스터 노드 간 통신이 정상적인지 확인한다.

# 노드 간 ping 테스트
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli ping
kubectl exec -it -n gameserver-cache redis-main-1 -- redis-cli ping
kubectl exec -it -n gameserver-cache redis-main-2 -- redis-cli ping

# 서비스 DNS 해상도 확인
kubectl exec -it -n gameserver-cache redis-main-0 -- nslookup redis-main-1.redis-main.gameserver-cache.svc.cluster.local
kubectl exec -it -n gameserver-cache redis-main-0 -- nslookup redis-main-2.redis-main.gameserver-cache.svc.cluster.local

# 클러스터 버스 포트 연결 테스트 (Redis 포트 + 10000)
kubectl exec -it -n gameserver-cache redis-main-0 -- nc -zv redis-main-1.redis-main.gameserver-cache.svc.cluster.local 16379
kubectl exec -it -n gameserver-cache redis-main-0 -- nc -zv redis-main-2.redis-main.gameserver-cache.svc.cluster.local 16379

3단계: Slots 할당 상태 점검

Redis 클러스터의 핵심인 해시 슬롯 분배 상태를 확인한다.

# 각 노드의 slots 할당 정보 확인
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli cluster slots

# 할당되지 않은 slots 확인
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli cluster check redis-main-0.redis-main.gameserver-cache.svc.cluster.local:6379

일반적인 slots 문제

중복 할당된 slots
할당되지 않은 slots
노드 간 slots 정보 불일치

4단계: 클러스터 복구 실행

진단 결과에 따라 적절한 복구 방법을 선택한다.

소프트 리셋을 통한 복구

클러스터 구성 정보만 리셋하고 데이터는 유지한다.

# 모든 노드에서 소프트 리셋 실행
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli cluster reset soft
kubectl exec -it -n gameserver-cache redis-main-1 -- redis-cli cluster reset soft
kubectl exec -it -n gameserver-cache redis-main-2 -- redis-cli cluster reset soft

클러스터 재생성

# 클러스터 재구성 (replicas 없는 3-master 구성)
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli --cluster create \
  redis-main-0.redis-main.gameserver-cache.svc.cluster.local:6379 \
  redis-main-1.redis-main.gameserver-cache.svc.cluster.local:6379 \
  redis-main-2.redis-main.gameserver-cache.svc.cluster.local:6379 \
  --cluster-replicas 0 --cluster-yes

성공 시 예상 출력은 아래와 같다.

[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

5단계: 복구 검증

클러스터 복구 후 반드시 기능 검증을 수행한다.

# 클러스터 상태 재확인
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli cluster info

# 데이터 읽기/쓰기 테스트
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli set test-key "recovery-test"
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli get test-key

# 다른 노드에서도 데이터 접근 확인
kubectl exec -it -n gameserver-cache redis-main-1 -- redis-cli get test-key
kubectl exec -it -n gameserver-cache redis-main-2 -- redis-cli get test-key

# 클러스터 키 분산 확인
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli set key1 "value1"
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli set key2 "value2" 
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli set key3 "value3"

고급 문제 해결

부분 노드 장애 시 복구

일부 노드만 문제가 있는 경우

# 문제 노드 식별
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli cluster nodes | grep fail

# 해당 노드를 클러스터에서 제거
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli cluster forget <NODE-ID>

# 새 노드로 교체 후 클러스터에 추가
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli cluster meet redis-main-X.redis-main.gameserver-cache.svc.cluster.local 6379

Slots 재분배

노드 추가/제거 후 slots 균등 분배

# 자동 리밸런싱
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli --cluster rebalance redis-main-0.redis-main.gameserver-cache.svc.cluster.local:6379

# 수동 slots 이동
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli --cluster reshard redis-main-0.redis-main.gameserver-cache.svc.cluster.local:6379

데이터 일관성 검증

# 모든 노드의 키 개수 확인
for i in {0..2}; do
  echo "Node redis-main-$i:"
  kubectl exec -it -n gameserver-cache redis-main-$i -- redis-cli dbsize
done

# 클러스터 전체 키 검증
kubectl exec -it -n gameserver-cache redis-main-0 -- redis-cli --cluster check redis-main-0.redis-main.gameserver-cache.svc.cluster.local:6379 --cluster-search-multiple-owners

예방 및 모니터링

헬스체크 설정

Redis 클러스터 상태 모니터링을 위한 헬스체크 구성한다.

# redis-healthcheck.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: redis-healthcheck
  namespace: gameserver-cache
data:
  healthcheck.sh: |
    #!/bin/bash
    # 클러스터 상태 확인
    CLUSTER_STATE=$(redis-cli cluster info | grep cluster_state | cut -d: -f2)
    if [ "$CLUSTER_STATE" != "ok" ]; then
      echo "Cluster state is not ok: $CLUSTER_STATE"
      exit 1
    fi
    
    # 기본 ping 응답 확인
    redis-cli ping | grep -q PONG
    if [ $? -ne 0 ]; then
      echo "Redis ping failed"
      exit 1
    fi
    
    echo "Redis cluster is healthy"
    exit 0

프로메테우스 메트릭 수집

Redis 클러스터 상태를 지속적으로 모니터링

# redis-exporter.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-exporter
  namespace: gameserver-cache
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis-exporter
  template:
    metadata:
      labels:
        app: redis-exporter
    spec:
      containers:
      - name: redis-exporter
        image: oliver006/redis_exporter:latest
        env:
        - name: REDIS_ADDR
          value: "redis://redis-main-0.redis-main.gameserver-cache.svc.cluster.local:6379"
        - name: REDIS_IS_CLUSTER
          value: "true"
        ports:
        - containerPort: 9121

알림 규칙 설정

중요한 메트릭에 대한 알림 구성

# redis-alerts.yaml
groups:
- name: redis-cluster
  rules:
  - alert: RedisClusterDown
    expr: redis_up == 0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Redis cluster node is down"
      
  - alert: RedisClusterSlotsFail
    expr: redis_cluster_slots_fail > 0
    for: 30s
    labels:
      severity: warning
    annotations:
      summary: "Redis cluster has failed slots"
      
  - alert: RedisClusterStateNotOK
    expr: redis_cluster_state != 1
    for: 30s
    labels:
      severity: critical
    annotations:
      summary: "Redis cluster state is not OK"

성능 최적화 고려사항

네트워크 설정

# redis-statefulset.yaml 최적화
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis-main
  namespace: gameserver-cache
spec:
  template:
    spec:
      containers:
      - name: redis
        # 네트워크 버퍼 크기 조정
        command:
        - redis-server
        - /etc/redis/redis.conf
        - --tcp-keepalive
        - "60"
        - --tcp-backlog
        - "511"
        # 클러스터 통신 최적화
        - --cluster-node-timeout
        - "5000"
        - --cluster-announce-bus-port
        - "16379"

메모리 및 디스크 최적화

resources:
  requests:
    cpu: 200m
    memory: 512Mi
  limits:
    cpu: 1000m
    memory: 2Gi
    
# 영구 볼륨 설정
volumeClaimTemplates:
- metadata:
    name: data
  spec:
    accessModes: ["ReadWriteOnce"]
    storageClassName: fast-ssd
    resources:
      requests:
        storage: 20Gi

마무리

Redis 클러스터 장애는 분산 시스템의 특성상 완전히 피하기는 어렵지만, 체계적인 진단과 복구 절차를 통해 신속하게 해결할 수 있다. 본 글에서 소개한 단계별 접근법을 통해 다음과 같은 효과를 얻을 수 있다.

핵심 성과

장애 발생 시 평균 복구 시간(MTTR) 단축
데이터 손실 없는 안전한 클러스터 복구
체계적인 모니터링을 통한 사전 장애 예방

운영 노하우

정기적인 클러스터 상태 점검으로 잠재적 문제 조기 발견
백업 및 복구 절차의 정기적 테스트 실시
네트워크 정책 및 보안 설정 최적화

Redis 클러스터는 올바르게 구성하고 모니터링한다면 안정적이고 확장 가능한 캐시 솔루션으로 활용할 수 있다. 장애 발생 시 당황하지 말고 본 가이드의 절차를 차근차근 따라 실행하면, 대부분의 클러스터 문제를 효과적으로 해결할 수 있을 것이다.

무엇보다 중요한 것은 장애 발생 전 미리 모니터링 체계를 구축하고, 복구 절차를 숙지하여 신속한 대응이 가능하도록 준비하는 것이다. 이를 통해 서비스 중단 시간을 최소화하고 사용자 경험을 보호할 수 있다.

Reference

Somaz | DevOps Engineer | Kubernetes & Cloud Infrastructure Specialist

Claude와 Claude Code: AI 기반 개발 환경의 새로운 패러다임

Somaz — Sat, 10 Jan 2026 00:00:45 +0900

Overview

AI 기술이 소프트웨어 개발 프로세스를 혁신하고 있는 가운데, Anthropic의 Claude는 단순한 챗봇을 넘어 실질적인 개발 파트너로 자리잡고 있다. 특히 최근 출시된 Claude Code는 커맨드라인 환경에서 직접 코딩 작업을 위임할 수 있는 에이전트 도구로, DevOps 엔지니어와 개발자들에게 새로운 가능성을 제시하고 있다.

이 글에서는 Claude의 최신 모델 패밀리인 Claude 4 시리즈와 터미널 기반의 AI 코딩 어시스턴트인 Claude Code의 특징, 활용 방법, 그리고 실무에서의 적용 사례를 살펴보겠다.

Claude 4 모델 패밀리 소개

현재 제공되는 모델

Claude 4 패밀리는 현재 다음과 같은 모델들로 구성되어 있다.

Claude Opus 4.5: 가장 강력한 성능의 모델
Claude Sonnet 4.5: 일상적인 사용에 최적화된 가장 스마트한 모델
Claude Haiku 4.5: 빠르고 효율적인 경량 모델

Opus의 성능이 어마무시하지만, 토큰을 많이 잡아먹는 이슈가 있다. 간단한 코딩은 Sonnet으로도 충분하다!

Claude Sonnet 4.5의 특징

Claude Sonnet 4.5는 성능과 효율성의 균형이 뛰어나 다음과 같은 작업에 적합하다.

복잡한 코드 리뷰 및 리팩토링
인프라 설정 파일 작성 (Kubernetes, Terraform 등)
기술 문서 작성 및 번역
디버깅 및 문제 해결
API 설계 및 구현

Claude 접근 방법

Claude는 다양한 채널을 통해 접근할 수 있다.

1. 웹 인터페이스 (claude.ai)

브라우저를 통해 직접 접속하여 대화형 방식으로 사용할 수 있다. 다음과 같은 기능을 제공한다.

Artifacts: 코드, 문서 등을 별도 패널에서 실시간으로 확인
Web Search: 최신 정보 검색 기능
Code Execution and File Creation: 코드 실행 및 파일 생성
Search and Reference Past Chats: 이전 대화 검색 및 참조
Memory Generation: 대화 히스토리로부터 자동 메모리 생성

2. 모바일 및 데스크톱 앱

iOS, Android, macOS, Windows 등 다양한 플랫폼에서 네이티브 앱을 통해 사용 가능하다.

3. API 및 개발자 플랫폼

프로그래밍 방식으로 Claude를 통합할 수 있다.

import anthropic

client = anthropic.Anthropic(api_key="your-api-key")

message = client.messages.create(
    model="claude-sonnet-4-5-20250929",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "Kubernetes Deployment YAML 예제를 작성해줘"}
    ]
)

print(message.content)

4. Claude Code

터미널에서 직접 코딩 작업을 위임할 수 있는 커맨드라인 도구이다.

상당히 귀염뽀짝하다?

Claude Code: 터미널 기반 AI 코딩 어시스턴트

Claude Code란?

Claude Code는 개발자가 터미널에서 직접 Claude에게 코딩 작업을 위임할 수 있는 에이전트 도구이다. 파일 생성, 코드 수정, 디버깅, 테스트 작성 등의 작업을 자연어 명령으로 수행할 수 있다.

주요 특징

1. 컨텍스트 인식

현재 작업 중인 프로젝트의 구조를 이해
기존 코드베이스와 일관된 스타일로 코드 생성
Git 히스토리 및 변경사항 추적

2. 멀티스텝 작업 수행

복잡한 리팩토링 작업을 단계별로 진행
여러 파일에 걸친 변경사항을 일관되게 처리
테스트 작성 후 자동으로 실행 및 검증

3. 대화형 워크플로우

작업 진행 중 추가 질문 및 확인 요청
변경사항에 대한 설명 제공
사용자 피드백을 반영한 수정

자세한 내용은 아래의 글을 참고하길 바란다.

2025.12.29 - [AI/AI Tool] - Claude Code 완벽 가이드: Mac에서 시작하기

Claude vs 다른 AI 모델 비교

AI 코딩 어시스턴트 시장에는 여러 경쟁자들이 있다. 각 모델의 특징과 Claude의 차별점을 살펴보자.

주요 AI 모델 비교표

특징	Claude Sonnet 4.5	GPT-4o	Gemini 2.0 Flash	GitHub Copilot
컨텍스트 윈도우	200K 토큰	128K 토큰	1M 토큰	제한적
코드 생성 품질	매우 우수	우수	우수	우수
추론 능력	매우 우수	우수	우수	보통
터미널 통합	Claude Code	없음	없음	VS Code 중심
DevOps 특화	강함	보통	보통	약함
가격 (API)	$3/1M 입력 토큰	$2.5/1M 입력 토큰	$0.075/1M 입력 토큰	$10/월 구독
한국어 지원	우수	우수	우수	제한적

벤치마크 비교

HumanEval (Python 코딩 테스트)

Claude Sonnet 4.5: 92%
GPT-4o: 90.2%
Gemini 2.0 Flash: 88.5%
GPT-3.5: 48.1%

SWE-bench (실제 GitHub 이슈 해결)

Claude Sonnet 4.5: 49.0%
GPT-4o: 38.4%
Gemini Pro: 34.2%

이 벤치마크는 Claude가 실제 소프트웨어 엔지니어링 작업에서 우위를 보인다는 것을 시사한다.

최신 벤치마크 결과는 각 모델 제공사의 공식 문서를 참고하길 바란다.

마무리

Claude와 Claude Code는 단순한 AI 도구를 넘어 DevOps 엔지니어의 강력한 파트너로 자리잡고 있다.

반복적인 작업의 자동화, 복잡한 설정의 간소화, 빠른 프로토타이핑이 가능하며, 무엇보다 자연어로 의도를 표현하는 것만으로 전문적인 인프라 코드와 설정을 생성할 수 있다는 점이 혁신적이다.

특히 Claude Code는 터미널에서 직접 작업을 위임할 수 있어 기존 워크플로우에 자연스럽게 통합된다. Kubernetes 매니페스트 작성, Terraform 모듈 개발, CI/CD 파이프라인 구성 등 복잡한 DevOps 작업을 대화형으로 수행할 수 있다.

하지만 AI는 도구일 뿐이며, 최종 책임과 판단은 엔지니어의 몫이다. 생성된 코드와 설정을 항상 검토하고, 보안 및 성능 측면에서 검증하는 습관을 유지해야 한다. Claude를 효과적으로 활용하면 더 높은 수준의 아키텍처와 전략적 의사결정에 집중할 수 있는 시간을 확보할 수 있다.

앞으로 AI 기반 개발 도구는 계속 진화할 것이며, Claude는 그 선두에서 DevOps 워크플로우의 패러다임을 바꾸고 있다. 여러분의 일상적인 개발 작업에 Claude를 통합하여 생산성을 높이고, 더 창의적이고 전략적인 업무에 집중해보시기 바란다.

Reference

Somaz | DevOps Engineer | Kubernetes & Cloud Infrastructure Specialist

GCP Load Balancer 완전 비교 가이드

Somaz — Thu, 8 Jan 2026 00:00:10 +0900

Overview

클라우드 환경에서 로드밸런서는 애플리케이션의 가용성과 성능을 보장하는 핵심 구성 요소이다. Google Cloud Platform(GCP)은 다양한 로드밸런싱 솔루션을 제공하여 각기 다른 요구사항과 아키텍처에 최적화된 선택지를 제공한다.

최근 몇 년간 GCP의 로드밸런서 서비스들은 크게 발전했다. 특히 HTTP(S) Load Balancer의 경우 Certificate Manager를 통한 여러 도메인 지원이 강화되었고, SSL 인증서 관리 방식도 다양해졌다. Certificate Map 기능을 통해 도메인별로 다른 인증서를 할당할 수 있게 되어, 과거의 제약이 크게 완화되었다.

하지만 GKE 환경에서는 여전히 중요한 제약사항이 있습니다. GKE ManagedCertificate는 하나의 인증서당 하나의 도메인만 지원하며, AWS ALB Ingress Group과 같은 기능이 없어 하나의 Ingress가 하나의 Load Balancer를 생성한다.

이 글에서는 GCP의 주요 로드밸런서 유형들을 심층 분석하고, 각각의 특성과 적절한 사용 사례를 살펴보겠습니다. 또한 실제 운영 환경에서 활용할 수 있는 Terraform 코드와 GKE Ingress 구성 예제, 그리고 최적화 전략도 함께 제시하겠다.

2023.04.06 - [GCP] - GCP란? - 서비스 계정 & Project 생성 / SDK(gcloud) 설치

2023.04.06 - [GCP] - GCP IAM이란?

2023.04.12 - [GCP] - GCP - SDK(gcloud) 계정 2개 등록하기

2023.05.05 - [GCP] - GCP vs AWS 리소스 비교

2023.05.19 - [GCP] - GCP BigQuery란? & Data Warehouse

2023.09.23 - [GCP] - BigQuery와 DataFlow를 활용한 Data ETL(GCP)

2023.10.03 - [GCP] - Shared VPC를 사용하여 GKE 클러스터 생성시 IAM 설정

2023.12.18 - [GCP] - GCP를 활용한 데이터 자동화(MongoDB, CloudSQL, GA, Dune)

2024.01.20 - [GCP] - Terraform 으로 GCS 생성후 Cloud CDN 생성(GCP)

2024.03.04 - [GCP] - GCP에서 딥러닝을 위한 GPU VM 서버 만들기(GCP)

2024.04.24 - [Migration] - AWS에서 GCP로 마이그레이션하는 방법 및 고려사항

GCP Load Balancer 유형별 특성 분석

HTTP(S) Load Balancer

HTTP(S) Load Balancer는 GCP의 가장 강력하고 유연한 로드밸런싱 솔루션이다. 글로벌 범위에서 동작하며, 레이어 7(애플리케이션 계층)에서 트래픽을 처리한다.

주요 특징

글로벌 애니캐스트 IP: 전 세계 어디서나 가장 가까운 백엔드로 라우팅
Cloud CDN 통합: 정적 콘텐츠 캐싱으로 성능 향상
URL 기반 라우팅: 경로, 헤더, 쿠키에 따른 정교한 트래픽 분산
SSL 터미네이션: Google-managed 또는 사용자 관리 인증서 지원

SSL 인증서 관리 옵션

1. Certificate Manager (권장 - 여러 도메인 가능)

# Certificate Manager를 통한 Google 관리형 인증서 (여러 도메인 지원)
resource "google_certificate_manager_certificate" "default" {
  name        = "example-cert"
  description = "Multi-domain certificate"
  scope       = "DEFAULT"

  managed {
    domains = [
      "example.com",
      "www.example.com", 
      "api.example.com"
    ]
    dns_authorizations = [
      google_certificate_manager_dns_authorization.example.id,
      google_certificate_manager_dns_authorization.www.id,
      google_certificate_manager_dns_authorization.api.id
    ]
  }
}

# DNS 승인 (각 도메인별)
resource "google_certificate_manager_dns_authorization" "example" {
  name   = "example-dns-auth"
  domain = "example.com"
}

resource "google_certificate_manager_dns_authorization" "www" {
  name   = "www-dns-auth"
  domain = "www.example.com"
}

resource "google_certificate_manager_dns_authorization" "api" {
  name   = "api-dns-auth"
  domain = "api.example.com"
}

# Certificate Map
resource "google_certificate_manager_certificate_map" "default" {
  name        = "cert-map"
  description = "Multi-domain certificate mapping"
}

resource "google_certificate_manager_certificate_map_entry" "default" {
  name         = "cert-map-entry"
  map          = google_certificate_manager_certificate_map.default.name
  certificates = [google_certificate_manager_certificate.default.id]
  hostname     = "example.com"
}

2. Compute Engine Managed SSL (여러 도메인 가능)

resource "google_compute_managed_ssl_certificate" "default" {
  name = "example-cert"
  managed {
    domains = [
      "example.com",
      "www.example.com",
      "api.example.com"
    ]
  }
}

3. GKE ManagedCertificate (도메인당 하나씩 제한)

# 각 도메인마다 별도의 ManagedCertificate 필요
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: main-cert
spec:
  domains:
    - example.com

---
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: api-cert
spec:
  domains:
    - api.example.com

4. GKE에서 Certificate Manager 사용 (새로운 방식)

Certificate Manager는 GKE에서도 사용할 수 있으며, 더 유연한 인증서 관리를 제공한다.

Certificate Manager 기반 GKE 인프라

# GKE용 Certificate Manager 인증서 생성
resource "google_certificate_manager_certificate" "gke_cert" {
  name        = "gke-certificate"
  description = "Certificate for GKE services"
  scope       = "DEFAULT"

  managed {
    domains = [
      "example.com",
      "api.example.com",
      "admin.example.com"
    ]
    dns_authorizations = [
      google_certificate_manager_dns_authorization.example.id,
      google_certificate_manager_dns_authorization.api.id,
      google_certificate_manager_dns_authorization.admin.id
    ]
  }
}

# Certificate Map 생성
resource "google_certificate_manager_certificate_map" "gke_cert_map" {
  name        = "gke-cert-map"
  description = "Certificate map for GKE"
}

# Certificate Map Entry
resource "google_certificate_manager_certificate_map_entry" "main_entry" {
  name         = "main-cert-entry"
  map          = google_certificate_manager_certificate_map.gke_cert_map.name
  certificates = [google_certificate_manager_certificate.gke_cert.id]
  hostname     = "example.com"
}

resource "google_certificate_manager_certificate_map_entry" "api_entry" {
  name         = "api-cert-entry"
  map          = google_certificate_manager_certificate_map.gke_cert_map.name
  certificates = [google_certificate_manager_certificate.gke_cert.id]
  hostname     = "api.example.com"
}

GKE Ingress에서 Certificate Manager 사용

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cert-manager-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "gke-static-ip"
    kubernetes.io/ingress.class: "gce"
    # Certificate Manager 사용 (ManagedCertificate 대신)
    networking.gke.io/certificate-map: "gke-cert-map"
    networking.gke.io/v1beta1.FrontendConfig: "frontend-config"
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80
      - path: /static/*
        pathType: Prefix
        backend:
          service:
            name: static-service
            port:
              number: 80
  - host: api.example.com
    http:
      paths:
      - path: /v1/*
        pathType: Prefix
        backend:
          service:
            name: api-v1-service
            port:
              number: 8080
      - path: /v2/*
        pathType: Prefix
        backend:
          service:
            name: api-v2-service
            port:
              number: 8080

5. GKE Ingress에서 기존 ManagedCertificate 사용

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    networking.gke.io/managed-certificates: "main-cert,api-cert"
spec:
  rules:
  - host: example.com
    # 웹사이트 라우팅
  - host: api.example.com
    # API 라우팅

인증서 관리 방식 비교

방식	도메인 수	인증 방법	관리 방식	권장 사용처
Certificate Manager	여러 도메인	DNS 승인	Certificate Map	복잡한 도메인 구성
Compute Engine Managed SSL	여러 도메인	HTTP 승인	Terraform	Compute Engine 환경
GKE ManagedCertificate	도메인당 1개	HTTP 승인	Kubernetes	단순한 GKE 환경

Network Load Balancer (TCP/UDP)

Network Load Balancer는 레이어 4에서 동작하는 고성능 로드밸런서로, TCP 및 UDP 트래픽을 처리한다.

주요 특징

초고성능: 레이어 4 처리로 낮은 지연시간 제공
원본 IP 보존: 클라이언트의 실제 IP 주소를 백엔드에 전달
프로토콜 지원: TCP, UDP, ESP, GRE, ICMP 등 다양한 프로토콜
지역적 로드밸런싱: 리전 내에서만 동작

적합한 사용 사례

게임 서버
IoT 디바이스 통신
VPN 게이트웨이
실시간 스트리밍 서비스

Internal Load Balancer

Internal Load Balancer는 VPC 내부 트래픽을 위한 로드밸런서로, 외부에서 직접 접근할 수 없는 내부 서비스들 간의 통신을 담당한다.

주요 특징

내부 전용: VPC 내부에서만 접근 가능한 프라이빗 IP 사용
마이크로서비스 아키텍처 지원: 서비스 간 통신 최적화
고가용성: 여러 가용 영역에 걸친 백엔드 분산
비용 효율성: 외부 IP 사용료 없음

GKE와 GCP Load Balancer의 차이점

GCP에는 두 가지 주요 로드밸런싱 환경이 있다.

Compute Engine 기반 Load Balancer: Terraform으로 직접 관리
GKE Ingress: Kubernetes 리소스로 관리되며 내부적으로 GCP Load Balancer 생성

중요한 제약사항

GKE ManagedCertificate: 하나의 인증서당 하나의 도메인만 가능
AWS ALB Ingress Group과 같은 기능은 GKE에 없음: 하나의 Ingress = 하나의 Load Balancer
여러 서비스를 하나의 Load Balancer로 처리하려면: 하나의 Ingress에서 여러 rule 정의 필요

GKE Ingress 실전 예제

실제 운영 환경에서의 GKE Ingress 구성

# 1. 각 도메인별 ManagedCertificate 생성
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: somaz-main-cert
spec:
  domains:
    - somaz.link

---
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: somaz-api-cert
spec:
  domains:
    - api.somaz.link

---
# 2. FrontendConfig (선택적 - 보안 헤더, 리다이렉트 등)
apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: somaz-frontend-config
spec:
  redirectToHttps:
    enabled: true
    responseCodeName: MOVED_PERMANENTLY_DEFAULT
  sslPolicy: somaz-ssl-policy

---
# 3. 통합 Ingress 구성
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: somaz-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "somaz-gke-lb-ip"
    networking.gke.io/managed-certificates: "somaz-main-cert,somaz-api-cert"
    kubernetes.io/ingress.class: "gce"
    networking.gke.io/v1beta1.FrontendConfig: "somaz-frontend-config"
    cloud.google.com/backend-config: '{"default": "somaz-backend-config"}'
spec:
  rules:
  # 메인 웹사이트
  - host: somaz.link
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80
      - path: /static/*
        pathType: Prefix
        backend:
          service:
            name: static-service
            port:
              number: 80
  
  # API 서비스
  - host: api.somaz.link
    http:
      paths:
      - path: /v1/*
        pathType: Prefix
        backend:
          service:
            name: api-v1-service
            port:
              number: 8080
      - path: /v2/*
        pathType: Prefix
        backend:
          service:
            name: api-v2-service
            port:
              number: 8080
      - path: /health
        pathType: Exact
        backend:
          service:
            name: health-service
            port:
              number: 8080

---
# 4. BackendConfig for CDN and optimization
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: somaz-backend-config
spec:
  cdn:
    enabled: true
    cachePolicy:
      includeHost: true
      includeProtocol: true
      includeQueryString: false
    negativeCaching: true
    negativeCachingPolicy:
    - code: 404
      ttl: 120
  connectionDraining:
    drainingTimeoutSec: 60
  healthCheck:
    checkIntervalSec: 10
    timeoutSec: 5
    healthyThreshold: 2
    unhealthyThreshold: 3
    type: HTTP
    requestPath: /health
    port: 8080

Terraform으로 구현하는 GKE 지원 인프라

GKE Ingress를 위한 기반 인프라 구성

# GKE Ingress에서 사용할 글로벌 정적 IP
resource "google_compute_global_address" "gke_ingress_ip" {
  name = "somaz-gke-lb-ip"
}

# SSL Policy 정의 (TLS 버전 및 암호화 설정)
resource "google_compute_ssl_policy" "modern_tls" {
  name    = "somaz-ssl-policy"
  profile = "MODERN"
  min_tls_version = "TLS_1_2"
}

# 출력 값으로 Kubernetes에서 사용할 정보 제공
output "gke_ingress_ip" {
  description = "Static IP for GKE Ingress"
  value       = google_compute_global_address.gke_ingress_ip.address
}

output "ssl_policy_name" {
  description = "SSL Policy name for FrontendConfig"
  value       = google_compute_ssl_policy.modern_tls.name
}

Compute Engine 기반 완전한 Load Balancer 구현

# 글로벌 IP 주소
resource "google_compute_global_address" "main_lb_ip" {
  name = "main-lb-global-ip"
}

# SSL 인증서 (여러 도메인 지원)
resource "google_compute_managed_ssl_certificate" "main_ssl_cert" {
  name = "main-ssl-certificate"
  managed {
    domains = [
      "example.com",
      "www.example.com",
      "api.example.com",
      "admin.example.com"
    ]
  }
}

# 인스턴스 그룹
resource "google_compute_instance_group" "web_servers" {
  name        = "web-server-group"
  description = "Instance Group for web servers"
  zone        = "${var.region}-a"
  instances   = [google_compute_instance.web_server.self_link]

  named_port {
    name = "http"
    port = 80
  }

  named_port {
    name = "https"
    port = 443
  }

  named_port {
    name = "api"
    port = 8080
  }
}

# Health Check for Web Service
resource "google_compute_health_check" "web_health_check" {
  name               = "web-service-health-check"
  check_interval_sec = 5
  timeout_sec        = 3
  healthy_threshold  = 2
  unhealthy_threshold = 3

  http_health_check {
    port         = 80
    request_path = "/health"
  }
}

# Health Check for API Service
resource "google_compute_health_check" "api_health_check" {
  name               = "api-service-health-check"
  check_interval_sec = 5
  timeout_sec        = 3
  healthy_threshold  = 2
  unhealthy_threshold = 3

  http_health_check {
    port         = 8080
    request_path = "/api/health"
  }
}

# Backend Service for Web
resource "google_compute_backend_service" "web_backend_service" {
  name        = "web-backend-service"
  description = "Backend Service for Web Application"
  protocol    = "HTTP"
  port_name   = "http"
  timeout_sec = 30

  backend {
    group = google_compute_instance_group.web_servers.self_link
  }

  health_checks = [google_compute_health_check.web_health_check.self_link]

  # CDN 활성화 (정적 콘텐츠용)
  enable_cdn = true
  cdn_policy {
    cache_mode  = "CACHE_ALL_STATIC"
    default_ttl = 3600
    max_ttl     = 86400
  }
}

# Backend Service for API
resource "google_compute_backend_service" "api_backend_service" {
  name        = "api-backend-service"
  description = "Backend Service for API"
  protocol    = "HTTP"
  port_name   = "api"
  timeout_sec = 30

  backend {
    group = google_compute_instance_group.web_servers.self_link
  }

  health_checks = [google_compute_health_check.api_health_check.self_link]

  # API는 CDN 비활성화
  enable_cdn = false
}

# URL Map (메인 라우팅 설정)
resource "google_compute_url_map" "main_url_map" {
  name            = "main-url-map"
  description     = "Main URL map for multi-domain routing"
  default_service = google_compute_backend_service.web_backend_service.self_link

  # API 도메인 라우팅
  host_rule {
    hosts        = ["api.example.com"]
    path_matcher = "api-matcher"
  }

  path_matcher {
    name            = "api-matcher"
    default_service = google_compute_backend_service.api_backend_service.self_link

    path_rule {
      paths   = ["/v1/*"]
      service = google_compute_backend_service.api_backend_service.self_link
    }

    path_rule {
      paths   = ["/v2/*"]
      service = google_compute_backend_service.api_backend_service.self_link
    }
  }

  # Admin 도메인 라우팅
  host_rule {
    hosts        = ["admin.example.com"]
    path_matcher = "admin-matcher"
  }

  path_matcher {
    name            = "admin-matcher"
    default_service = google_compute_backend_service.web_backend_service.self_link
  }

  depends_on = [
    google_compute_backend_service.web_backend_service,
    google_compute_backend_service.api_backend_service
  ]
}

# HTTPS Target Proxy
resource "google_compute_target_https_proxy" "main_https_proxy" {
  name             = "main-https-proxy"
  description      = "HTTPS proxy for main load balancer"
  url_map          = google_compute_url_map.main_url_map.self_link
  ssl_certificates = [google_compute_managed_ssl_certificate.main_ssl_cert.self_link]
}

# HTTPS Global Forwarding Rule
resource "google_compute_global_forwarding_rule" "main_https_forwarding_rule" {
  name       = "main-https-forwarding-rule"
  target     = google_compute_target_https_proxy.main_https_proxy.self_link
  ip_address = google_compute_global_address.main_lb_ip.address
  port_range = "443"
}

# HTTP to HTTPS Redirect URL Map
resource "google_compute_url_map" "http_to_https_redirect" {
  name = "http-to-https-redirect"
  
  default_url_redirect {
    https_redirect         = true
    redirect_response_code = "MOVED_PERMANENTLY_DEFAULT"
    strip_query           = false
  }
}

# HTTP Target Proxy
resource "google_compute_target_http_proxy" "main_http_proxy" {
  name    = "main-http-proxy"
  url_map = google_compute_url_map.http_to_https_redirect.self_link
}

# HTTP Global Forwarding Rule (리다이렉트용)
resource "google_compute_global_forwarding_rule" "main_http_forwarding_rule" {
  name       = "main-http-forwarding-rule"
  target     = google_compute_target_http_proxy.main_http_proxy.self_link
  ip_address = google_compute_global_address.main_lb_ip.address
  port_range = "80"
}

# 출력값
output "load_balancer_ip" {
  description = "Load Balancer Global IP Address"
  value       = google_compute_global_address.main_lb_ip.address
}

output "ssl_certificate_status" {
  description = "SSL Certificate Status"
  value       = google_compute_managed_ssl_certificate.main_ssl_cert.managed
}

트러블슈팅 가이드

1. 일반적인 문제와 해결책

ManagedCertificate가 Provisioning 상태에서 멈춤

# 문제 진단
kubectl describe managedcertificate <cert-name>

# 일반적인 원인:
# 1. DNS가 Load Balancer IP를 가리키지 않음
# 2. 도메인 소유권 확인 실패
# 3. Ingress에서 올바르게 참조되지 않음

# 해결:
# 1. DNS 설정 확인
nslookup your-domain.com

# 2. Ingress 어노테이션 확인
kubectl get ingress -o yaml

Load Balancer가 생성되지 않음

# 이벤트 확인
kubectl describe ingress <ingress-name>

# 일반적인 원인:
# 1. 정적 IP가 다른 리소스에서 사용 중
# 2. 백엔드 서비스가 정상적이지 않음
# 3. Health Check 실패

# 해결:
# 1. 정적 IP 상태 확인
gcloud compute addresses list --global

# 2. 백엔드 서비스 상태 확인
kubectl get services

Health Check 실패

# Pod 상태 확인
kubectl get pods -o wide

# 서비스 상태 확인
kubectl describe service <service-name>

# Health Check 경로 테스트
kubectl exec -it <pod-name> -- curl localhost:8080/health

2. 성능 튜닝 팁

BackendConfig 최적화

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: performance-backend-config
spec:
  timeoutSec: 30
  connectionDraining:
    drainingTimeoutSec: 300
  sessionAffinity:
    affinityType: "CLIENT_IP"
    affinityCookieTtlSec: 3600
  healthCheck:
    checkIntervalSec: 5
    timeoutSec: 3
    healthyThreshold: 2
    unhealthyThreshold: 2
    type: HTTP
    requestPath: /health
    port: 8080

CDN 캐시 최적화

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: cdn-optimized-config
spec:
  cdn:
    enabled: true
    cachePolicy:
      includeHost: true
      includeProtocol: true
      includeQueryString: false
      queryStringBlacklist: ["utm_source", "utm_medium", "utm_campaign"]
    negativeCaching: true
    negativeCachingPolicy:
    - code: 404
      ttl: 300
    - code: 500
      ttl: 60

비용 최적화 전략

GKE Ingress 비용 구조

Global Load Balancer: $18/월 (첫 5개 규칙)
추가 규칙: $7/월당
데이터 처리: $0.008/GB

최적화 방법

# 하나의 Ingress에 여러 서비스 통합
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: unified-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api/v1
        pathType: Prefix
        backend:
          service:
            name: api-v1-service
            port:
              number: 8080
      - path: /api/v2
        pathType: Prefix
        backend:
          service:
            name: api-v2-service
            port:
              number: 8080
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

Global vs Regional 로드밸런싱 전략

Global Load Balancing

글로벌 로드밸런싱은 전 세계 사용자에게 최적의 성능을 제공하기 위한 전략이다.

장점

지연시간 최소화: 사용자와 가장 가까운 백엔드로 자동 라우팅
장애 조치: 리전 장애 시 자동으로 다른 리전으로 트래픽 전환
스케일링: 글로벌 트래픽 증가에 유연하게 대응

Regional Load Balancing

리전별 로드밸런싱은 특정 지역에 집중된 사용자나 규정 준수 요구사항이 있는 경우에 적합하다.

적용 시나리오

데이터 주권 요구사항
지역별 서비스 제공
비용 최적화 (특정 리전만 사용)
내부 서비스 통신

Cloud CDN 통합 및 성능 최적화

Cloud CDN 설정

Cloud CDN을 HTTP(S) Load Balancer와 연동하면 정적 콘텐츠의 전송 속도를 크게 향상시킬 수 있다.

resource "google_compute_backend_service" "website" {
  name        = "website-backend"
  protocol    = "HTTP"
  timeout_sec = 10

  backend {
    group = google_compute_instance_group.web.id
  }

  health_checks = [google_compute_http_health_check.default.id]

  # Cloud CDN 활성화
  enable_cdn = true

  cdn_policy {
    cache_mode                   = "CACHE_ALL_STATIC"
    default_ttl                 = 3600
    max_ttl                     = 86400
    negative_caching            = true
    negative_caching_policy {
      code = 404
      ttl  = 120
    }
    
    # 캐시 키 설정
    cache_key_policy {
      include_host         = true
      include_protocol     = true
      include_query_string = false
      query_string_whitelist = ["version", "locale"]
    }
  }
}

마무리

GCP의 로드밸런서는 각각 고유한 특성과 장점을 가지고 있어, 적절한 선택과 구성이 매우 중요하다. 특히 SSL 인증서 관리에서는 다음과 같은 선택지가 있다.

Certificate Manager: 최신 방식으로 여러 도메인을 하나의 인증서에 포함 가능하며, DNS 승인을 통한 자동화된 관리
Compute Engine Managed SSL: Terraform으로 관리하기 쉽고 여러 도메인 지원
GKE ManagedCertificate: GKE 환경에서 간단하지만 도메인당 별도 인증서 필요

핵심 포인트

인증서 관리 전략: Certificate Manager를 활용하면 여러 도메인을 효율적으로 관리할 수 있으며, GKE에서는 도메인별 ManagedCertificate를 사용하거나 Certificate Manager를 통한 Certificate Map 방식을 선택할 수 있다.
목적에 맞는 선택: 웹 애플리케이션에는 HTTP(S) Load Balancer, 고성능 TCP/UDP 서비스에는 Network Load Balancer, 내부 서비스 통신에는 Internal Load Balancer를 선택하자.
글로벌 vs 리전별 전략: 사용자 분포와 규정 준수 요구사항을 고려하여 적절한 범위의 로드밸런싱을 구현하자.
Cloud CDN 활용: 정적 콘텐츠가 많은 서비스라면 Cloud CDN을 적극 활용하여 성능과 비용을 동시에 최적화하자.
지속적인 모니터링: Cloud Monitoring을 통해 성능 지표를 추적하고, 임계값 기반 알림을 설정하여 문제를 사전에 예방하자.
비용 최적화: 백엔드 서비스 구성과 CDN 캐시 정책을 최적화하여 불필요한 비용을 절감하자.

GCP의 로드밸런서는 AWS와 달리 Ingress Group 같은 기능이 없어 하나의 Ingress가 하나의 Load Balancer를 생성하지만, Certificate Manager와 Certificate Map을 통해 복잡한 도메인 관리가 가능하다.

적절한 로드밸런서 아키텍처는 애플리케이션의 가용성, 성능, 그리고 비용 효율성을 크게 좌우하므로, 이 가이드에서 제시한 전략과 예제를 바탕으로 여러분의 서비스에 최적화된 로드밸런싱 솔루션을 구축하시기 바란다.

Reference

Somaz | DevOps Engineer | Kubernetes & Cloud Infrastructure Specialist

AWS EFS와 Kubernetes를 활용한 영구 스토리지 구축 가이드

Somaz — Tue, 6 Jan 2026 00:00:01 +0900

Overview

AWS Elastic File System(EFS)은 확장 가능하고 완전 관리형 NFS 파일 시스템으로, 여러 EC2 인스턴스에서 동시에 접근할 수 있는 공유 스토리지를 제공한다. 특히 Kubernetes 환경에서는 여러 Pod가 동일한 데이터를 공유해야 하는 경우에 매우 유용하다.

본 글에서는 Terraform을 사용하여 EFS를 구성하고, Kubernetes에서 이를 활용하여 영구 스토리지를 구현하는 방법을 상세히 알아보겠다.

2022.02.13 - [AWS] - AWS IAM (Identity and Access Management) 개요 및 설정 방법

2022.02.13 - [AWS] - AWS S3 (Simple Storage Service) 개요 및 활용 방법

2023.03.30 - [AWS] - AWS Secrets Manager란?(OAuth, SSO)

2023.03.30 - [AWS] - AWS Cloudfront란? / Canary 및 Blue-Green 배포

2023.05.26 - [AWS] - AWS IRSA(IAM Roles for Service Accounts)란?

2024.11.16 - [AWS] - AWS Network ACL vs Security Group

2024.11.21 - [AWS] - ALB access Log 활성화 → S3 권한 설정 및 로그 저장