Load Balancing

API 로드 밸런싱은 현대 웹 아키텍처와 분산 시스템의 필수적인 구성 요소로, 트래픽을 여러 서버에 효율적으로 분산하여 성능, 가용성, 안정성을 극대화한다.

API 로드 밸런싱의 기본 개념

로드 밸런싱은 들어오는 네트워크 트래픽을 여러 서버에 분산하는 프로세스로, 단일 서버의 과부하를 방지하고 애플리케이션의 응답성과 가용성을 향상시킨다. API 컨텍스트에서 로드 밸런싱은 특히 중요한데, API가 종종 높은 동시 요청 수와 일관된 응답 시간을 유지해야 하는 미션 크리티컬한 애플리케이션의 기반이 되기 때문이다.

로드 밸런싱이 필요한 이유

  1. 성능 최적화: 여러 서버에 부하를 분산하여 응답 시간을 최소화한다.
  2. 고가용성: 서버 장애 시에도 서비스 중단 없이 트래픽을 다른 정상 서버로 리디렉션한다.
  3. 확장성: 수요 증가에 따라 서버를 추가하고 부하 분산 풀에 통합할 수 있다.
  4. 유연성: 서버 유지보수를 위해 일부 서버를 오프라인으로 전환하고 나머지 서버로 트래픽을 라우팅할 수 있다.
  5. 효율성: 자원 활용도를 최적화하여 비용을 절감한다.

로드 밸런싱의 유형

API 로드 밸런싱은 여러 수준에서 구현될 수 있다:

  1. L4(전송 계층) 로드 밸런싱:
    • IP 주소와 포트 정보를 기반으로 트래픽 분산
    • 패킷 내용을 검사하지 않고 빠른 처리 가능
    • TCP/UDP 레벨에서 작동
  2. L7(애플리케이션 계층) 로드 밸런싱:
    • HTTP 헤더, 쿠키, URL 등 애플리케이션 레벨 데이터 기반 라우팅
    • 더 지능적인 라우팅 결정 가능
    • 콘텐츠 기반 라우팅 지원 (예: 특정 API 엔드포인트를 특정 서버로 라우팅)
  3. 글로벌 서버 로드 밸런싱(GSLB):
    • 지리적으로 분산된 서버 간에 트래픽 분산
    • 사용자와 가장 가까운 데이터 센터로 라우팅
    • 지역 서버 장애 시 자동 페일오버 제공

로드 밸런싱 알고리즘

적절한 로드 밸런싱 알고리즘 선택은 API 성능에 큰 영향을 미친다.

주요 알고리즘은 다음과 같다:

라운드 로빈(Round Robin)

각 서버에 순차적으로 요청을 분배하는 가장 단순한 방식.

1
2
3
4
5
6
7
8
9

# 라운드 로빈 알고리즘의 의사 코드
servers = ["server1", "server2", "server3", "server4"]
current_index = 0

def get_next_server():
    global current_index
    server = servers[current_index]
    current_index = (current_index + 1) % len(servers)
    return server

장점: 구현이 간단하고 모든 서버가 동일한 사양일 때 효과적.
단점: 서버 용량이나 현재 부하를 고려하지 않는다.

가중 라운드 로빈(Weighted Round Robin)

각 서버에 가중치를 할당하여 더 강력한 서버가 더 많은 요청을 처리하도록 한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# 가중 라운드 로빈 알고리즘의 의사 코드
servers = [
    {"name": "server1", "weight": 5},
    {"name": "server2", "weight": 3},
    {"name": "server3", "weight": 2}
]

def get_servers_by_weight():
    weighted_servers = []
    for server in servers:
        for i in range(server["weight"]):
            weighted_servers.append(server["name"])
    return weighted_servers

weighted_server_list = get_servers_by_weight()
current_index = 0

def get_next_server():
    global current_index
    server = weighted_server_list[current_index]
    current_index = (current_index + 1) % len(weighted_server_list)
    return server

장점: 서버 용량 차이를 고려한다.
단점: 실제 서버 부하를 동적으로 반영하지 않는다.

최소 연결(Least Connections)

현재 가장 적은 활성 연결을 가진 서버로 새 요청을 라우팅한다.

1
2
3
4
5
6
7
8
9

# 최소 연결 알고리즘의 의사 코드
servers = [
    {"name": "server1", "active_connections": 10},
    {"name": "server2", "active_connections": 15},
    {"name": "server3", "active_connections": 5}
]

def get_server_with_least_connections():
    return min(servers, key=lambda x: x["active_connections"])["name"]

장점: 서버 부하를 고려하여 더 효율적인 분배가 가능하다.
단점: 연결 수가 항상 부하를 정확히 반영하지는 않는다.

IP 해시(IP Hash)

클라이언트 IP 주소를 해싱하여 항상 동일한 서버로 요청을 라우팅한다.

1
2
3
4
5
6
7
8
9

# IP 해시 알고리즘의 의사 코드
import hashlib

servers = ["server1", "server2", "server3", "server4"]

def get_server_for_ip(ip_address):
    hash_value = int(hashlib.md5(ip_address.encode()).hexdigest(), 16)
    server_index = hash_value % len(servers)
    return servers[server_index]

장점: 세션 유지에 유용하며 같은 클라이언트는 항상 같은 서버에 연결된다.
단점: 트래픽이 고르게 분산되지 않을 수 있다.

최소 응답 시간(Least Response Time)

응답 시간이 가장 짧은 서버로 요청을 라우팅한다.

1
2
3
4
5
6
7
8
9

# 최소 응답 시간 알고리즘의 의사 코드
servers = [
    {"name": "server1", "response_time": 120},  # 밀리초
    {"name": "server2", "response_time": 95},
    {"name": "server3", "response_time": 180}
]

def get_server_with_least_response_time():
    return min(servers, key=lambda x: x["response_time"])["name"]

장점: 실제 성능을 기반으로 가장 반응성 좋은 서버를 선택한다.
단점: 응답 시간을 지속적으로 모니터링해야 하므로 오버헤드가 있다.

API 로드 밸런싱 구현 방법

하드웨어 로드 밸런서

물리적 장치를 사용하여 트래픽을 분산한다.

장점:

단점:

주요 제품: F5 BIG-IP, Citrix ADC, A10 Networks 등

소프트웨어 로드 밸런서

소프트웨어 애플리케이션을 통해 트래픽을 분산한다.

장점:

단점:

주요 제품: NGINX, HAProxy, Apache Traffic Server 등

클라우드 기반 로드 밸런서

클라우드 제공업체의 관리형 로드 밸런싱 서비스를 활용한다.

장점:

단점:

주요 서비스: AWS Elastic Load Balancing, Google Cloud Load Balancing, Azure Load Balancer 등

컨테이너 오케스트레이션 기반 로드 밸런싱

Kubernetes와 같은 컨테이너 오케스트레이션 플랫폼의 내장 기능을 활용한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Kubernetes 서비스 예시
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  selector:
    app: api
  ports:
  - port: 80
    targetPort: 8080
  type: LoadBalancer

장점:

단점:

API 로드 밸런싱의 고급 기능

상태 확인(Health Checks)

로드 밸런서는 주기적으로 백엔드 서버의 상태를 확인하여 비정상 서버로의 트래픽 라우팅을 방지한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# NGINX 상태 확인 구성 예시
http {
    upstream api_servers {
        server backend1.example.com:80 max_fails=3 fail_timeout=30s;
        server backend2.example.com:80 max_fails=3 fail_timeout=30s;
        server backend3.example.com:80 max_fails=3 fail_timeout=30s;
    }

    server {
        listen 80;
        
        location / {
            proxy_pass http://api_servers;
            health_check interval=10 fails=3 passes=2;
        }
    }
}

세션 유지(Session Persistence)

특정 클라이언트의 모든 요청이 동일한 백엔드 서버로 라우팅되도록 보장한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# HAProxy 세션 유지 구성 예시
frontend http
    bind *:80
    default_backend api_servers

backend api_servers
    balance roundrobin
    stick-table type ip size 200k expire 30m
    stick on src
    server server1 192.168.1.101:80 check
    server server2 192.168.1.102:80 check
    server server3 192.168.1.103:80 check

SSL 종료(SSL Termination)

로드 밸런서에서 SSL 연결을 종료하고 백엔드 서버로는 암호화되지 않은 트래픽을 전송하여 백엔드 서버의 부하를 줄인다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# NGINX SSL 종료 구성 예시
http {
    upstream api_servers {
        server backend1.example.com:8080;
        server backend2.example.com:8080;
    }

    server {
        listen 443 ssl;
        ssl_certificate /etc/nginx/cert.pem;
        ssl_certificate_key /etc/nginx/cert.key;
        
        location / {
            proxy_pass http://api_servers;
        }
    }
}

동적 가중치 조정

서버의 현재 부하, 성능 메트릭을 기반으로 가중치를 동적으로 조정한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# 동적 가중치 조정 의사 코드
def update_server_weights():
    for server in servers:
        # CPU 사용률, 메모리 사용률, 응답 시간 등 메트릭 수집
        metrics = collect_server_metrics(server["name"])
        
        # 메트릭을 기반으로 새 가중치 계산
        new_weight = calculate_weight(
            metrics["cpu_usage"], 
            metrics["memory_usage"],
            metrics["response_time"]
        )
        
        # 서버 가중치 업데이트
        server["weight"] = new_weight
    
    # 가중 서버 목록 재생성
    regenerate_weighted_server_list()

API 로드 밸런싱 아키텍처 패턴

단일 티어 로드 밸런싱

로드 밸런서가 클라이언트와 API 서버 사이에서 직접 요청을 분산한다.

1

클라이언트 → 로드 밸런서 → API 서버 풀

장점: 단순하고 구현이 쉽다.
단점: 로드 밸런서가 단일 장애 지점이 될 수 있다.

멀티 티어 로드 밸런싱

여러 계층의 로드 밸런서를 사용하여 복잡한 인프라를 처리한다.

1

클라이언트 → 글로벌 로드 밸런서 → 지역 로드 밸런서 → API 서버 풀

장점: 더 높은 확장성과 복원력을 제공한다.
단점: 더 복잡하고 여러 구성 요소가 필요하다.

마이크로서비스 아키텍처의 로드 밸런싱

서비스 간 통신에도 로드 밸런싱을 적용한다.

1
2
3

클라이언트 → API 게이트웨이(LB) → 서비스 A(LB) → 서비스 A 인스턴스 풀
                               → 서비스 B(LB) → 서비스 B 인스턴스 풀
                               → 서비스 C(LB) → 서비스 C 인스턴스 풀

장점: 세밀한 확장성과 장애 격리를 제공한다.
단점: 많은 로드 밸런싱 지점으로 인한 복잡성 증가

서비스 메시(Service Mesh)

프록시 네트워크를 통해 마이크로서비스 간 통신을 관리한다.

1
2

클라이언트 → 인그레스 게이트웨이 → 서비스 A(사이드카 프록시) ↔ 서비스 B(사이드카 프록시)
                                 ↔ 서비스 C(사이드카 프록시)

장점: 로드 밸런싱, 관찰성, 보안을 통합적으로 제공한다.
단점: 사이드카 프록시로 인한 약간의 오버헤드가 발생한다.

실제 구현 예시

NGINX를 사용한 API 로드 밸런싱

NGINX는 API 로드 밸런싱에 널리 사용되는 고성능 웹 서버 및 리버스 프록시이다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

# NGINX 로드 밸런싱 구성 예시
http {
    # 업스트림 서버 정의
    upstream api_backend {
        least_conn;  # 최소 연결 알고리즘 사용
        server api1.example.com:8080 weight=3;
        server api2.example.com:8080 weight=2;
        server api3.example.com:8080 weight=1 backup;  # 백업 서버
        
        keepalive 32;  # 유지 연결 풀 크기
    }
    
    # 상태 페이지 (모니터링용)
    server {
        listen 8081;
        location /nginx_status {
            stub_status on;
            allow 127.0.0.1;
            deny all;
        }
    }
    
    # API 프록시 서버
    server {
        listen 80;
        server_name api.example.com;
        
        location / {
            proxy_pass http://api_backend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            
            # 타임아웃 설정
            proxy_connect_timeout 5s;
            proxy_send_timeout 10s;
            proxy_read_timeout 10s;
            
            # 버퍼 설정
            proxy_buffering on;
            proxy_buffer_size 16k;
            proxy_buffers 4 16k;
        }
        
        # API 경로별 다른 백엔드 서버 그룹 사용
        location /v2/ {
            proxy_pass http://api_v2_backend;
        }
        
        # 속도 제한 적용
        location /api/limited {
            limit_req zone=api_limit burst=5;
            proxy_pass http://api_backend;
        }
    }
}

Kubernetes에서의 API 로드 밸런싱

Kubernetes는 컨테이너화된 API를 위한 강력한 로드 밸런싱 솔루션을 제공한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

# API 배포 구성
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 5
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
      - name: api
        image: my-api:1.0
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        resources:
          limits:
            cpu: "1"
            memory: "1Gi"
          requests:
            cpu: "0.5"
            memory: "512Mi"

---
# API 서비스 (내부 로드 밸런서)
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  selector:
    app: api
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP

---
# 외부 인그레스 (외부 로드 밸런서)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
  tls:
  - hosts:
    - api.example.com
    secretName: api-tls-secret

AWS 환경에서의 API 로드 밸런싱

AWS Application Load Balancer(ALB)를 사용한 구성이다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

// AWS CloudFormation 템플릿 예시
{
  "Resources": {
    "ApiLoadBalancer": {
      "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer",
      "Properties": {
        "Name": "api-load-balancer",
        "Subnets": ["subnet-12345", "subnet-67890"],
        "SecurityGroups": ["sg-12345"],
        "Scheme": "internet-facing",
        "Type": "application",
        "IpAddressType": "ipv4"
      }
    },
    "ApiTargetGroup": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "Name": "api-target-group",
        "Port": 80,
        "Protocol": "HTTP",
        "VpcId": "vpc-12345",
        "HealthCheckPath": "/health",
        "HealthCheckIntervalSeconds": 30,
        "HealthCheckTimeoutSeconds": 5,
        "HealthyThresholdCount": 3,
        "UnhealthyThresholdCount": 2,
        "TargetType": "instance"
      }
    },
    "ApiListener": {
      "Type": "AWS::ElasticLoadBalancingV2::Listener",
      "Properties": {
        "LoadBalancerArn": {"Ref": "ApiLoadBalancer"},
        "Port": 443,
        "Protocol": "HTTPS",
        "Certificates": [
          {"CertificateArn": "arn:aws:acm:region:account-id:certificate/certificate-id"}
        ],
        "DefaultActions": [
          {
            "Type": "forward",
            "TargetGroupArn": {"Ref": "ApiTargetGroup"}
          }
        ]
      }
    },
    "ApiListenerRule": {
      "Type": "AWS::ElasticLoadBalancingV2::ListenerRule",
      "Properties": {
        "ListenerArn": {"Ref": "ApiListener"},
        "Priority": 1,
        "Conditions": [
          {
            "Field": "path-pattern",
            "Values": ["/api/*"]
          }
        ],
        "Actions": [
          {
            "Type": "forward",
            "TargetGroupArn": {"Ref": "ApiTargetGroup"}
          }
        ]
      }
    }
  }
}

API 로드 밸런싱의 모니터링 및 관리

주요 모니터링 지표

API 로드 밸런싱 시스템의 건강 상태를 평가하기 위한 핵심 지표이다:

  1. 요청 처리량(Throughput): 초당 처리되는 요청 수
  2. 응답 시간(Response Time): 요청 처리에 소요되는 시간
  3. 오류율(Error Rate): 총 요청 중 실패한 요청의 비율
  4. 활성 연결 수(Active Connections): 현재 열린 연결 수
  5. 백엔드 서버 상태(Backend Server Health): 각 서버의 상태 및 가용성
  6. 세션 지속성(Session Persistence): 세션이 유지되는 정도
  7. 대기열 길이(Queue Length): 처리 대기 중인 요청 수

로깅 및 분석

효과적인 로드 밸런싱을 위한 로깅 전략:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# NGINX 액세스 로깅 구성 예시
http {
    log_format lb_log '$remote_addr - $remote_user [$time_local] '
                      '"$request" $status $body_bytes_sent '
                      '"$http_referer" "$http_user_agent" '
                      '$request_time $upstream_response_time $pipe '
                      '$upstream_addr $upstream_status';
    
    access_log /var/log/nginx/access.log lb_log;
    
    # 나머지 구성…
}

로그 분석 도구:

자동 확장(Auto Scaling)

부하에 따라 자동으로 백엔드 API 서버 수를 조정한다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

# Kubernetes Horizontal Pod Autoscaler 예시
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-deployment
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  - type: Pods
    pods:
      metric:
        name: requests_per_second
      target:
        type: AverageValue
        averageValue: 1000

재해 복구 및 장애 조치

로드 밸런싱 시스템의 복원력을 보장하기 위한 전략:

  1. 다중 가용 영역(Multi-AZ) 배포: 지리적으로 분산된 데이터 센터에 로드 밸런서 배포
  2. 로드 밸런서 클러스터링: 로드 밸런서의 고가용성 클러스터 구성
  3. 자동 장애 조치: 기본 로드 밸런서 실패 시 보조 로드 밸런서로 자동 전환
  4. 백업 및 복원 절차: 로드 밸런서 구성의 정기적인 백업 및 복원 테스트

API 로드 밸런싱의 보안 고려사항

DDoS 방어

분산 서비스 거부 공격으로부터 API를 보호한다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# NGINX DDoS 보호 구성 예시
http {
    # 연결 속도 제한
    limit_conn_zone $binary_remote_addr zone=conn_limit_per_ip:10m;
    limit_conn conn_limit_per_ip 10;
    
    # 요청 속도 제한
    limit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=5r/s;
    
    server {
        # API 엔드포인트에 속도 제한 적용
        location /api/ {
            limit_req zone=req_limit_per_ip burst=10 nodelay;
            
            # 나머지 구성…
        }
    }
}

SSL/TLS 구성

안전한 API 통신을 보장한다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

# NGINX 보안 SSL 구성 예시
http {
    server {
        listen 443 ssl http2;
        server_name api.example.com;
        
        # SSL 인증서 설정
        ssl_certificate /etc/nginx/ssl/api.example.com.crt;
        ssl_certificate_key /etc/nginx/ssl/api.example.com.key;
        
        # SSL 프로토콜 및 암호화 설정
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_prefer_server_ciphers on;
        ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
        
        # HSTS 설정 (HTTP Strict Transport Security)
        add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
        
        # SSL 세션 캐싱
        ssl_session_timeout 1d;
        ssl_session_cache shared:SSL:10m;
        ssl_session_tickets off;
        
        # OCSP 스테이플링
        ssl_stapling on;
        ssl_stapling_verify on;
        resolver 8.8.8.8 8.8.4.4 valid=300s;
        resolver_timeout 5s;
        
        # 나머지 구성…
    }
}

API 인증 및 권한 부여

로드 밸런서 수준에서 API 접근 제어를 구현한다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

# NGINX API 인증 구성 예시
http {
    server {
        # API 키 검증
        location /api/ {
            auth_request /validate-api-key;
            
            # 나머지 구성…
        }
        
        # API 키 검증 내부 엔드포인트
        location = /validate-api-key {
            internal;
            proxy_pass http://auth-service/validate;
            proxy_pass_request_body off;
            proxy_set_header Content-Length "";
            proxy_set_header X-Original-URI $request_uri;
            proxy_set_header X-API-Key $http_x_api_key;
        }
        
        # JWT 검증이 필요한 엔드포인트
        location /api/secure/ {
            auth_request /validate-jwt;
            
            # 나머지 구성…
        }
        
        # JWT 검증 내부 엔드포인트
        location = /validate-jwt {
            internal;
            proxy_pass http://auth-service/validate-jwt;
            proxy_pass_request_body off;
            proxy_set_header Content-Length "";
            proxy_set_header X-Original-URI $request_uri;
            proxy_set_header Authorization $http_authorization;
        }
    }
}

WAF(웹 애플리케이션 방화벽) 통합

로드 밸런서와 WAF를 통합하여 API 보안 강화:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# ModSecurity WAF와 NGINX 통합 예시
load_module modules/ngx_http_modsecurity_module.so;

http {
    server {
        # ModSecurity WAF 활성화
        modsecurity on;
        modsecurity_rules_file /etc/nginx/modsecurity/main.conf;
        
        # OWASP ModSecurity Core Rule Set 적용
        location /api/ {
            # 로드 밸런싱 구성
            proxy_pass http://api_backend;
            
            # WAF 로깅
            modsecurity_transaction_id "$remote_addr-$request_id";
            
            # 나머지 구성…
        }
    }
}

API 로드 밸런싱의 성능 최적화

연결 처리 최적화

대량의 API 요청을 효율적으로 처리하기 위한 연결 최적화:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

# NGINX 연결 최적화 구성 예시
worker_processes auto;
worker_rlimit_nofile 65535;

events {
    worker_connections 16384;
    multi_accept on;
    use epoll;
}

http {
    # 타임아웃 설정
    keepalive_timeout 65;
    keepalive_requests 100000;
    
    # 클라이언트 버퍼 설정
    client_body_buffer_size 128k;
    client_max_body_size 10m;
    client_body_timeout 12;
    client_header_timeout 12;
    
    # 파일 디스크립터 캐싱
    open_file_cache max=200000 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;
    
    # 업스트림 연결 최적화
    upstream api_backend {
        server api1.example.com:8080;
        server api2.example.com:8080;
        
        keepalive 100;
        keepalive_requests 1000;
        keepalive_timeout 60s;
    }
    
    server {
        # 연결 유지 헤더 설정
        location /api/ {
            proxy_pass http://api_backend;
            proxy_http_version 1.1;
            proxy_set_header Connection "";
        }
    }
}

압축 및 캐싱

대역폭 사용 최적화 및 응답 시간 개선:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

# NGINX 압축 및 캐싱 구성 예시
http {
    # 정적 콘텐츠 압축
    gzip on;
    gzip_comp_level 5;
    gzip_min_length 256;
    gzip_proxied any;
    gzip_types application/json application/xml application/javascript text/plain text/css text/xml;
    gzip_vary on;
    
    # 캐싱 설정
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api_cache:10m inactive=60m max_size=1g;
    
    server {
        # API 응답 캐싱
        location /api/ {
            proxy_pass http://api_backend;
            
            # 캐싱 활성화 (GET 요청만)
            proxy_cache api_cache;
            proxy_cache_methods GET;
            proxy_cache_valid 200 302 10m;
            proxy_cache_valid 404 1m;
            proxy_cache_key $scheme$request_method$host$request_uri;
            
            # 캐시 재검증
            proxy_cache_revalidate on;
            proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
            proxy_cache_background_update on;
            
            # 캐시 상태 헤더
            add_header X-Cache-Status $upstream_cache_status;
            
            # 조건부 캐싱 (인증 요청은 캐시하지 않음)
            proxy_cache_bypass $http_authorization;
            proxy_no_cache $http_authorization;
            
            # 나머지 구성…
        }
        
        # 캐시 무효화 엔드포인트
        location ~ /purge/(.+) {
            allow 127.0.0.1;
            deny all;
            
            proxy_cache_purge api_cache $scheme$request_method$host$1;
        }
    }
}

HTTP/2 및 HTTP/3 지원

최신 HTTP 프로토콜을 활용한 성능 향상:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# NGINX HTTP/2 및 HTTP/3 구성 예시
http {
    server {
        listen 443 ssl http2;
        listen 443 quic reuseport; # HTTP/3 지원
        
        http2_max_concurrent_streams 128;
        http2_push_preload on;
        
        # QUIC 및 HTTP/3 설정
        quic_retry on;
        quic_gso on;
        
        # Alt-Svc 헤더 설정 (HTTP/3 광고)
        add_header Alt-Svc 'h3=":443"; ma=86400';
        
        # SSL 설정
        ssl_certificate /etc/nginx/ssl/api.example.com.crt;
        ssl_certificate_key /etc/nginx/ssl/api.example.com.key;
        
        # HTTP/2 서버 푸시 (정적 리소스용)
        location /api/v1/products {
            http2_push /api/v1/categories;
            http2_push /api/v1/recommendations;
            proxy_pass http://api_backend;
        }
    }
}

비동기 및 스트리밍 API 지원

장기 실행 요청 및 이벤트 스트림을 위한 최적화:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

# NGINX 스트리밍 API 구성 예시
http {
    upstream api_backend {
        server api1.example.com:8080;
        server api2.example.com:8080;
    }
    
    server {
        # 표준 API 요청
        location /api/ {
            proxy_pass http://api_backend;
            
            # 표준 프록시 설정
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
        
        # 이벤트 스트리밍 엔드포인트
        location /api/stream/ {
            proxy_pass http://api_backend;
            
            # 스트리밍 최적화
            proxy_buffering off;
            proxy_cache off;
            
            # 타임아웃 증가
            proxy_read_timeout 300s;
            proxy_connect_timeout 300s;
            proxy_send_timeout 300s;
            
            # 청크 전송 설정
            chunked_transfer_encoding on;
            
            # SSE(Server-Sent Events) 지원
            proxy_set_header Connection '';
            proxy_http_version 1.1;
            
            # 나머지 구성…
        }
        
        # 웹소켓 엔드포인트
        location /api/ws/ {
            proxy_pass http://api_backend;
            
            # 웹소켓 설정
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            
            # 웹소켓 타임아웃
            proxy_read_timeout 3600s;
            proxy_send_timeout 3600s;
        }
    }
}

다양한 환경에서의 API 로드 밸런싱 전략

온프레미스 환경

자체 데이터센터에서 API 로드 밸런싱 구현하기:

권장 아키텍처:

고가용성 전략:

클라우드 네이티브 환경

클라우드 환경에 최적화된 API 로드 밸런싱:

AWS 아키텍처 예시:

1

Route 53 (DNS) → CloudFront (CDN) → API Gateway → ALB → ECS/EKS 클러스터

Azure 아키텍처 예시:

1

Azure Front Door → Azure API Management → Azure Load Balancer → AKS 클러스터

Google Cloud 아키텍처 예시:

1

Cloud CDN → Cloud Load Balancing → Cloud Run/GKE

주요 이점:

하이브리드 및 멀티 클라우드 환경

다양한 환경에 걸친 API 로드 밸런싱:

아키텍처 접근법:

  1. 중앙 집중식 라우팅:
    • 글로벌 로드 밸런서가 각 환경의 로드 밸런서로 트래픽 라우팅
    • 단일 엔트리 포인트, 정책 일관성
  2. 분산형 라우팅:
    • 각 환경에 독립적인 엔트리 포인트
    • 지역 최적화, 환경 간 독립성

기술 스택:

주요 고려사항:

엣지 컴퓨팅 환경

엣지 위치에서의 API 로드 밸런싱:

아키텍처 접근법:

  1. 엣지 캐싱: 주로 읽기 작업을 위한 CDN 기반 캐싱
  2. 엣지 컴퓨팅: 엣지 로케이션에서 API 비즈니스 로직 실행
  3. 하이브리드 엣지: 캐싱 + 간단한 처리는 엣지에서, 복잡한 처리는 백엔드에서

기술 스택:

주요 이점:

API 로드 밸런싱의 실제 사례 연구

대규모 전자상거래 API 플랫폼

도전 과제:

구현 솔루션:

  1. 다계층 로드 밸런싱:
    • 글로벌 계층: Cloudflare + AWS Global Accelerator
    • 지역 계층: ALB(Application Load Balancer)
    • 서비스 계층: 서비스 내 로드 밸런싱
  2. 고급 라우팅 전략:
    • 콘텐츠 기반 라우팅: 제품 API vs 주문 API
    • 지리적 라우팅: 가장 가까운 데이터 센터로
    • 가중치 기반 카나리 배포
  3. 자동 확장 정책:
    • 예측적 확장: 과거 트래픽 패턴 기반
    • 이벤트 기반 확장: 마케팅 이벤트 전에 미리 확장
    • 다중 지표 확장: CPU, 메모리, 요청 대기열 기반

결과:

금융 서비스 API 게이트웨이

도전 과제:

구현 솔루션:

  1. 보안 중심 로드 밸런싱:
    • mTLS(상호 TLS) 종단간 인증
    • 요청/응답 암호화
    • FIPS 140-2 준수 하드웨어 로드 밸런서
    • WAF 통합
  2. 장애 없는 배포 전략:
    • 블루-그린 배포
    • 점진적인 트래픽 전환
    • 자동 롤백 기능
  3. 고급 상태 확인:
    • 딥 헬스 체크: API 기능 테스트
    • 회로 차단기 패턴 구현
    • 상태 메트릭 기반 가중치 조정

결과:

글로벌 미디어 스트리밍 API

도전 과제:

구현 솔루션:

  1. 글로벌 분산 아키텍처:
    • 모든 대륙에 API 엔드포인트 배포
    • 지능형 DNS 라우팅
    • 로컬 캐싱 및 에지 컴퓨팅
  2. 스트리밍 최적화:
    • 롱 폴링 및 웹소켓 지원
    • 적응형 비트레이트 API
    • 프로그레시브 콘텐츠 전송
  3. 맞춤형 로드 밸런싱 알고리즘:
    • 콘텐츠 인기도 기반 캐싱
    • 지연 시간 기반 라우팅
    • 인식 추천 엔진 라우팅

결과:

API 로드 밸런싱 구현 전략

API 로드 밸런싱을 효과적으로 구현하기 위한 전체적인 접근 방법을 제시합니다.

계층적 로드 밸런싱 아키텍처

멀티 티어 아키텍처 설계:

  1. 티어 1: 글로벌 엣지
    • CDN 및 글로벌 로드 밸런서
    • DDoS 방어 및 WAF
    • 지역 기반 라우팅
    • TLS 종료
  2. 티어 2: 지역 API 게이트웨이
    • 요청 검증 및 제한
    • 인증 및 권한 부여
    • 요청/응답 변환
    • API 버전 관리
  3. 티어 3: 서비스 로드 밸런서
    • 마이크로서비스 간 라우팅
    • 서비스 검색 통합
    • 내부 TLS 종료
    • 헬스 체크 및 회로 차단기
  4. 티어 4: 클러스터 로드 밸런서
    • 컨테이너/Pod 수준 라우팅
    • 스테이트풀 워크로드 라우팅
    • 프로토콜 인식 로드 밸런싱

알고리즘 선택 결정 트리

API 유형 및 요구사항에 따른 로드 밸런싱 알고리즘 선택 가이드:

  1. 쿼리 집약적 API:
    • 쿼리 실행 시간에 큰 차이가 있는가? → 최소 연결
    • 서버 용량이 다른가? → 가중 라운드 로빈
    • 캐시 친화적인가? → 일관된 해싱
    • 기타 → 라운드 로빈
  2. 상태 유지 API:
    • 세션 상태가 중요한가? → 소스 IP 해싱
    • 사용자별 처리가 필요한가? → URL 해싱
    • 지연 시간이 중요한가? → 최소 응답 시간
    • 기타 → 가중 라운드 로빈
  3. 고성능 실시간 API:
    • 초저지연이 중요한가? → 최소 응답 시간
    • 트래픽 급증이 있는가? → 최소 연결 + 동적 가중치
    • 지리적으로 분산되어 있는가? → 지연 시간 기반 라우팅
    • 기타 → 최소 처리 중인 요청
  4. 배치 처리 API:
    • 작업 크기가 다양한가? → 리소스 기반 라우팅
    • 서버 용량이 다른가? → 가중 라운드 로빈
    • 우선순위가 있는가? → 우선순위 기반 큐
    • 기타 → 라운드 로빈

구현 단계별 접근법

API 로드 밸런싱 시스템 구축을 위한 단계별 접근법:

  1. 요구사항 분석:
    • API 트래픽 패턴 분석
    • 성능 및 확장성 목표 정의
    • 고가용성 요구사항 식별
    • 보안 요구사항 문서화
  2. 아키텍처 설계:
    • 로드 밸런싱 계층 정의
    • 알고리즘 선택
    • 페일오버 전략 설계
    • 모니터링 및 알림 계획
  3. 프로토타입 개발:
    • 소규모로 로드 밸런싱 구성 테스트
    • 다양한 알고리즘 비교
    • 성능 벤치마킹
    • 페일오버 테스트
  4. 확장 구현:
    • 프로덕션 환경 설정
    • 구성 자동화
    • CI/CD 파이프라인 통합
    • 점진적 트래픽 전환
  5. 최적화 및 튜닝:
    • 실제 트래픽 기반 알고리즘 조정
    • 리소스 활용도 최적화
    • 성능 병목 제거
    • 구성 검증 및 강화
  6. 지속적인 개선:
    • 정기적인 성능 검토
    • 새로운 기술 평가
    • 보안 취약점 스캐닝
    • 용량 계획 업데이트

용어 정리

용어설명

참고 및 출처