API Rate Limiting & Scalability Patterns · 강의

전역 속도 제한과 서비스별 속도 제한

에지에서 적용되는 전역 속도 제한과 개별 마이크로서비스에 적용되는 특정 제한의 차이와 상호 작용을 이해합니다.

레슨 2/411개 단계

전역 속도 제한과 서비스별 속도 제한은(는) CoddyKit의 무료 API Rate Limiting & Scalability Patterns 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 API Rate Limiting & Scalability Patterns 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. API Rate Limiting & Scalability Patterns 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Global vs. Per-Service Limits

APIs often handle diverse traffic, from general users to specific internal systems. To manage this, we need different rate limiting strategies.

Today, we'll explore two key approaches: global rate limiting and per-service rate limiting. Understanding their differences helps build robust and fair APIs.

Guarding the Gates Globally

Global rate limiting is applied at the very edge of your system, before requests even reach individual services. Think of it as a bouncer at the club entrance.

It protects your entire infrastructure.
Often implemented in API Gateways, load balancers, or edge proxies.
Focuses on overall request volume to prevent system overload or DDoS attacks.

Global Limit Configuration

Here's a simplified example of how a global rate limit might be configured in an API Gateway like Nginx. It limits requests across all endpoints.

http {
  limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

  server {
    location / {
      limit_req zone=mylimit burst=20 nodelay;
      proxy_pass http://backend_services;
    }
  }
}

Why Global Limits Matter

Implementing global rate limits offers several advantages:

DDoS Protection: Blocks malicious traffic before it impacts your services.
Overall Stability: Ensures your entire system isn't overwhelmed by sudden traffic spikes.
Centralized Control: Easy to manage and modify limits for the whole API landscape.
Resource Efficiency: Less work for individual services to do for basic filtering.

Fine-Grained Service Control

Per-service rate limiting happens inside a specific microservice. It's like individual rules for different rooms within the club.

It applies to particular endpoints or operations within that service.
Implemented directly in the service's code or via a sidecar proxy.
Focuses on protecting specific service resources and enforcing business logic.

Per-Service Limit Code

Here's a tiny Java example illustrating a basic per-service rate limit for a specific endpoint. This uses a simple in-memory counter for demonstration.

import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicInteger;
import java.time.Instant;

public class Main {
  private static final int MAX_REQUESTS_PER_MINUTE = 3;
  private static final long WINDOW_MILLIS = 60 * 1000; // 1 minute
  private static ConcurrentHashMap<String, Long> lastResetTime =
    new ConcurrentHashMap<>();
  private static ConcurrentHashMap<String, AtomicInteger> requestCounts =
    new ConcurrentHashMap<>();

  public static boolean allowRequest(String userId) {
    long currentTime = Instant.now().toEpochMilli();
    lastResetTime.computeIfAbsent(userId, k -> currentTime);
    requestCounts.computeIfAbsent(userId, k -> new AtomicInteger(0));

    // Reset if window passed
    if (currentTime - lastResetTime.get(userId) > WINDOW_MILLIS) {
      lastResetTime.put(userId, currentTime);
      requestCounts.get(userId).set(0);
    }

    if (requestCounts.get(userId).get() < MAX_REQUESTS_PER_MINUTE) {
      requestCounts.get(userId).incrementAndGet();
      return true;
    }
    return false;
  }

  public static void main(String[] args) {
    String userA = "user123";
    System.out.println("User A requests:");
    for (int i = 0; i < 5; i++) {
      System.out.println("Request " + (i + 1) + ": " +
        (allowRequest(userA) ? "Allowed" : "Denied"));
    }
    System.out.println("\nUser B requests:");
    String userB = "user456";
    for (int i = 0; i < 2; i++) {
      System.out.println("Request " + (i + 1) + ": " +
        (allowRequest(userB) ? "Allowed" : "Denied"));
    }
  }
}

Why Per-Service Limits are Key

Per-service rate limits provide more granular control:

Resource Protection: Prevents one endpoint from exhausting a service's specific resources (e.g., database connections).
Business Logic: Enforces limits based on specific user tiers or API functionality (e.g., "premium users get 1000 calls/min to this endpoint").
Isolation: A limit breach in one service doesn't necessarily bring down others.

Working Together: Layered Defense

The most robust systems use both global and per-service rate limits. They act as a layered defense:

Global limits: Act as a first line of defense, filtering out bulk traffic and protecting the entire system's entry point.
Per-service limits: Provide fine-tuned control within individual services, protecting specific resources and enforcing business rules.

Think of it as multiple checkpoints, each with a different purpose.

When to Use Which?

When designing your rate limiting strategy, consider:

Global: Best for broad protection, anonymous traffic, and preventing DDoS. Easy to implement at the infrastructure level.
Per-service: Ideal for protecting specific backend resources, enforcing user-specific quotas, or handling authenticated traffic with distinct access levels. Requires more application-level logic.

Often, a combination is the best approach.

Test Your Knowledge

Consider an API with a global rate limit of 1000 requests/second and a specific microservice endpoint that has a per-user limit of 10 requests/minute. A user makes 50 requests in 30 seconds to this specific endpoint.

인터랙티브 레슨에서 답해보세요

Global vs. Per-Service Recap

We've explored the critical differences and synergy between global and per-service rate limiting:

Global limits: Act at the system's edge, protecting overall infrastructure from high-volume attacks.
Per-service limits: Provide fine-grained control within microservices, protecting specific resources and enforcing business rules.

Combining both strategies creates a robust, multi-layered defense for your APIs. Next, we'll dive into handling rate limit exceedance gracefully.

무료로 시작

AI 튜터와 함께 API Rate Limiting & Scalability Patterns을(를) 배우세요 — 무료

브라우저에서 실제 코드를 작성하고 실행하며, 24/7 AI 튜터로부터 즉각적인 도움을 받고, 웹이나 앱에서 중단한 부분부터 계속 학습하세요.

코스: 12
레슨: 48

무료로 학습 시작 전체 코스 보기

자주 묻는 질문

“전역 속도 제한과 서비스별 속도 제한” 강의는 무료인가요?

네 — “전역 속도 제한과 서비스별 속도 제한” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 API Rate Limiting & Scalability Patterns 강의 전체를 잠금 해제할 수 있습니다. API Rate Limiting & Scalability Patterns 강의에는 총 4개의 강의가 포함되어 있습니다.

“전역 속도 제한과 서비스별 속도 제한”에서 뭘 배우나요?

에지에서 적용되는 전역 속도 제한과 개별 마이크로서비스에 적용되는 특정 제한의 차이와 상호 작용을 이해합니다. 브라우저에서 직접 실행하는 실습 코드로 API Rate Limiting & Scalability Patterns을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

API Rate Limiting & Scalability Patterns을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 API Rate Limiting & Scalability Patterns은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.

“전역 속도 제한과 서비스별 속도 제한” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 API Rate Limiting & Scalability Patterns 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 API Rate Limiting & Scalability Patterns 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← API Rate Limiting & Scalability Patterns(으)로 돌아가기