마이크로서비스 고가용성 해독: Apache APISIX를 활용한 API 거버넌스 전략 탐구

March 29, 2024

Technology

소개

마이크로서비스 아키텍처는 현재 IT 아키텍처의 주류 선택이 되었습니다. 그 유연성과 확장성은 기업이 빠르게 변화하는 비즈니스 요구에 대응하기 쉽게 만들어줍니다. 그러나 마이크로서비스의 고가용성을 보장하는 것은 아키텍처 설계에서 핵심적인 문제가 되었습니다. 이러한 맥락에서 API 서비스 거버넌스의 세 가지 핵심 전략 — 속도 제한, 서킷 브레이커, 그리고 서비스 저하 — 는 특히 중요합니다.

마이크로서비스 아키텍처에서 필수적인 기초 구성 요소인 API 게이트웨이는 서비스 거버넌스에서 중요한 역할을 합니다. Apache APISIX는 차세대 클라우드 네이티브 API 게이트웨이로서, 높은 성능과 보안 기능을 자랑할 뿐만 아니라 풍부한 트래픽 관리 기능을 제공합니다. 다음 논의에서는 API 서비스 거버넌스의 "세 가지 접근 방식"을 깊이 있게 탐구하고, 이러한 전략을 APISIX에 적용하여 서비스의 고가용성을 보장하는 방법에 대한 자세한 통찰을 제공할 것입니다.

API 거버넌스 전략

속도 제한

속도 제한은 이름에서 알 수 있듯이 트래픽에 대한 제한 메커니즘입니다. 그 핵심 원리는 과도한 트래픽으로 인한 시스템 과부하 또는 심지어 시스템 다운을 방지하는 데 있습니다. 기본 개념은 특정 시간 간격 내의 요청 양을 규제하여, 특정 제약 조건을 충족하는 요청만 시스템에 접근할 수 있도록 하여 마이크로서비스와 전체 시스템의 안정적인 운영을 보장하는 것입니다. 실제 생활에서도 속도 제한의 개념은 명확히 드러납니다. 예를 들어, 지하철 역의 출퇴근 시간에는 보안 검사를 위해 여러 개의 출입구를 설치하여 질서 있고 원활한 대기열을 유도합니다.

속도 제한은 다양한 방식으로 구현될 수 있으며, 이에는 다음이 포함됩니다:

  • 요청 수 기반: 각 시간대별 요청 수를 추적하고 이를 특정 임계값 내로 제한합니다. 예를 들어, 초당 최대 100개의 요청을 처리합니다.

  • 요청 빈도 기반: 클라이언트 또는 IP 주소당 요청 빈도를 제한하여 과도한 요청을 방지합니다. 예를 들어, 분당 최대 10개의 요청을 허용합니다.

  • 연결 수 기반: 동시에 설정된 연결 수를 제한하여 시스템 자원의 과도한 소비를 방지합니다. 예를 들어, 최대 100개의 동시 연결을 허용합니다.

다양한 속도 제한 전략을 통해 다양한 시나리오 요구를 해결할 수 있습니다. 예를 들어, 가치 있는 API 자원에 대해 분당 요청 수를 10개로 제한할 수 있습니다. 또는 서비스 가용성을 높이기 위해 동시 요청 수를 제한하여 서비스 응답 시간을 줄이는 등의 시나리오가 있습니다. 이러한 속도 제한 전략을 적절히 구현하면 높은 동시성과 갑작스러운 트래픽 급증 상황에서도 서비스의 정상적인 운영을 보장할 수 있습니다.

서킷 브레이커

마이크로서비스 아키텍처에서는 서비스 간 상호 호출이 발생할 수 있습니다. 한 서비스가 실패하면 다른 서비스에 영향을 미치거나, 심지어 전체 시스템의 붕괴로 이어질 수 있습니다. 이러한 현상을 "연쇄적 실패" 또는 "눈사태 효과"라고 합니다. 서킷 브레이커 메커니즘은 마이크로서비스에서 연쇄적 실패를 방지하기 위한 보호 조치로 사용됩니다. 마이크로서비스가 이상 현상이나 지연을 겪을 때, 서킷 브레이커는 해당 서비스에 대한 요청을 일시적으로 차단하여 전체 시스템의 안정성이 훼손되지 않도록 합니다.

서킷 브레이커 메커니즘의 핵심 원리는 서비스 응답 시간 또는 오류율을 실시간으로 모니터링하는 데 있습니다. 이러한 지표가 사전 설정된 임계값을 초과하면, 서킷 브레이커가 자동으로 트리거되어 결함이 있는 서비스에 대한 요청을 신속하게 중단합니다. 서비스가 정상으로 돌아오면, 서킷 브레이커는 자동으로 닫히고 서비스에 대한 접근이 재개됩니다. 이 메커니즘은 전기 회로의 저항기와 유사합니다. 전압이 허용 범위를 초과하면, 저항기는 회로를 자동으로 차단하여 과도한 전류가 다른 전자 부품을 손상시키는 것을 방지합니다. 회로를 점검하고 수리한 후, 저항기는 다시 닫히고 회로는 정상적으로 작동합니다.

서킷 브레이커 메커니즘을 도입함으로써, 마이크로서비스 아키텍처는 서비스 간 상호 호출로 인한 잠재적인 연쇄적 실패 문제에 더 잘 대처할 수 있으며, 특히 고부하 상황에서 시스템의 안정성과 신뢰성을 보장할 수 있습니다.

서비스 저하

서비스 저하는 높은 시스템 부하를 해결하기 위한 효과적인 전략으로, 일부 비핵심 기능을 일시적으로 비활성화하거나 특정 서비스의 품질을 적당히 낮추어 전체 시스템의 안정적인 운영을 보장합니다. 마이크로서비스 아키텍처에서 서비스 저하 메커니즘을 적용하면, 일부 비핵심적이거나 일시적으로 불필요한 기능을 지능적으로 차단하여 핵심 기능의 지속적이고 안정적인 운영을 보장할 수 있습니다. 예를 들어, 화상 회의 애플리케이션에서 네트워크 대역폭이 제한적일 때, 비디오 전송 품질을 낮추거나 비디오 기능을 일시적으로 비활성화하여 음성 통화가 명확하고 안정적으로 이루어지도록 하여 회의의 기본적인 커뮤니케이션 요구를 충족시킬 수 있습니다.

일반적인 전략에는 다음이 포함됩니다:

  • 기능 저하: 일부 기능을 일시적으로 닫거나 접근을 제한하여 핵심 서비스의 정상적인 운영을 보장합니다. 예를 들어, 소셜 미디어 애플리케이션은 피크 시간에 "좋아요" 또는 "댓글" 기능을 일시적으로 비활성화하여 사용자가 콘텐츠를 정상적으로 탐색할 수 있도록 할 수 있습니다.

  • 품질 저하: 높은 시스템 부하 상황에서 특정 서비스 또는 기능의 품질 요구 사항을 낮춥니다. 예를 들어, 앞서 언급한 바와 같이 비디오 선명도 또는 프레임 속도를 낮추어 원활한 커뮤니케이션을 보장합니다.

APISIX에서의 속도 제한, 서킷 브레이커, 그리고 서비스 저하

APISIX에서 제공하는 위의 세 가지 주요 전략을 활용하여 마이크로서비스의 고가용성을 어떻게 향상시킬 수 있을까요? 아래는 몇 가지 일반적인 적용 예시를 설명하기 위한 것입니다.

limit-count 플러그인을 통한 속도 제한

APISIX는 limit-count, limit-req, 그리고 limit-conn과 같은 다양한 내장 트래픽 관리 플러그인을 제공합니다. 실제 필요에 따라 적절한 방법을 선택하여 트래픽을 제어할 수 있습니다. limit-count 플러그인을 예로 들면, 이는 특정 시간 간격 내의 총 요청 수를 제한하고 HTTP 헤더에 남은 요청 수를 반환합니다.

curl -i http://127.0.0.1:9080/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "uri": "/get",
    "plugins": {
        "limit-count": {
            "count": 3,
            "time_window": 60,
            "rejected_code": 429,
            "key_type": "var",
            "key": "remote_addr"
        }
    },
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "httpbin.org:80": 1
        }
    }
}'

api-breaker 플러그인을 통한 서킷 브레이커

APISIX의 api-breaker 플러그인은 사전 설정된 임계값에 따라 서킷 브레이커 메커니즘을 자동으로 트리거하여 연쇄적 실패를 방지합니다. 예를 들어, 업스트림 서비스가 3번 연속으로 500 또는 503 상태 코드를 반환하면 서킷 브레이커를 시작하고, 200 상태 코드를 받으면 접근을 재개합니다.

curl "http://127.0.0.1:9180/apisix/admin/routes/1" \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
        "api-breaker": {
            "break_response_code": 502,
            "unhealthy": {
                "http_statuses": [500, 503],
                "failures": 3
            },
            "healthy": {
                "http_statuses": [200],
                "successes": 1
            }
        }
    },
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "httpbin.org:80": 1
        }
    },
    "uri": "/get",
}'

fault-injection 플러그인을 통한 서비스 저하

APISIX의 fault-injection 및 mocking 플러그인은 높은 시스템 부하 상황에서 일부 기능을 일시적으로 비활성화하거나 사전 설정된 데이터를 직접 반환하는 서비스 저하 전략을 설정하여 시스템 안정성을 보장합니다. 예를 들어, fault-injection 플러그인은 지정된 HTTP 상태 코드와 본문 값을 클라이언트에 직접 반환할 수 있습니다.

curl http://127.0.0.1:9180/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
       "fault-injection": {
           "abort": {
              "http_status": 200,
              "body": "Fault Injection!"
           }
       }
    },
    "upstream": {
       "nodes": {
           "httpbin.org:80": 1
       },
       "type": "roundrobin"
    },
    "uri": "/get"
}'

결론

속도 제한, 서킷 브레이커, 그리고 서비스 저하는 마이크로서비스 아키텍처에서 중요한 서비스 거버넌스 조치로서, 마이크로서비스의 고가용성을 향상시키는 데 있어서 대체할 수 없는 역할을 합니다. 이들은 마이크로서비스 아키텍처를 다양한 잠재적 위험과 도전으로부터 방어하는 견고한 방패 역할을 합니다. 다양한 비즈니스 시나리오에 직면하여, 우리는 이러한 조치를 유연하고 신중하게 적용하여 마이크로서비스 아키텍처의 안정성과 신뢰성이 최적으로 보장되도록 해야 합니다.

Tags:
API Governance
APISIX Basics