NGINX에서 APISIX로 – 항공사 게이트웨이 역학의 재정의

January 24, 2024

Case Study

개요

소개

Skytrax에서 세계 5성급 항공사로 선정된 이 선도적인 항공사는 30년 동안 안전하게 운영되어 왔으며, 정기 여객 운송, 업무 및 학교 재개를 위한 전세기, 그리고 아시아, 유럽, 아프리카, 북미, 오세아니아 등에서의 여객 운항을 포함한 총 약 1,900개의 국제 노선을 운항하고 있습니다.

급성장하는 항공사로서, 이 선도적인 항공사는 효율적인 항공 예약 프로세스를 촉진하고, 다양한 시스템 및 서비스와의 통합 및 연결을 지원하며, 고동시나리오와 금융 및 위험 데이터를 처리하기 위해 API 게이트웨이가 필요했습니다.

도전 과제

  • 마이크로서비스와 컨테이너화된 배포의 증가로 인해 증가하는 NGINX 인스턴스와 다양한 도메인 설정을 관리하는 데 어려움이 있습니다.
  • 너무 많은 버전의 NGINX가 공존함으로써 플러그인의 업그레이드, 컴파일, 적응이 복잡해졌습니다.
  • 이전 API 게이트웨이는 이 선도적인 항공사의 기본 요구사항만 충족할 수 있었지만, 서킷 브레이커, 카나리 릴리스 등과 같은 고급 기능은 제공하지 못했습니다.

결과

  • APISIX의 핫 리로딩 기능 덕분에 다중 노드 설정이 간소화되어 개발 효율성이 크게 향상되고 관리 비용이 절감되었습니다.
  • 이 선도적인 항공사는 APISIX의 포괄적인 플러그인 생태계를 활용하여 더 고급 기능을 수행함으로써 플러그인 및 시스템 업그레이드를 간소화했습니다.
  • 이 업그레이드는 게이트웨이의 효율성과 유지보수성을 향상시켰으며, 이는 체계적이고 모듈화된 재사용 가능한 설정 관리로의 중요한 전환을 의미합니다.

배경

이 선도적인 항공사는 상당 기간 동안 NGINX를 북-남 게이트웨이로 사용해 왔습니다. 그러나 비즈니스와 제품 포트폴리오가 확장됨에 따라 트래픽 요구를 효과적으로 처리했음에도 불구하고, 다양한 측면에서 점점 더 많은 문제점에 직면했습니다.

1. 다중 NGINX 인스턴스와 도메인

이 회사 내에는 여러 NGINX 인스턴스와 다양한 도메인 세트가 있었으며, 이 복잡성은 관리 난이도를 증가시켰습니다. NGINX의 핵심은 설정 파일에 있습니다. NGINX 인스턴스의 수가 증가함에 따라, SCP를 통해 파일을 복사하는 방식만으로 설정을 관리하는 것이 점점 더 어려워졌습니다. 특히 백엔드에서 마이크로서비스와 컨테이너화된 배포가 널리 사용되면서, 리버스 프록시 설정에 대한 유연성 요구가 높아져 설정 일관성을 유지하는 작업량이 크게 증가했습니다.

2. 다양한 NGINX 버전과 번거로운 플러그인 업그레이드

역사적인 이유로, 팀은 여러 버전의 NGINX와 수많은 NGINX 플러그인을 동시에 사용하고 있었습니다. NGINX 자체를 업그레이드하는 것은 큰 문제가 없었지만, 다양한 플러그인을 업그레이드, 컴파일, 적응하는 데 어려움이 있었습니다. 이들 중 많은 부분이 비공식적이어서 컴파일 중 문제 해결이 어려웠습니다. 또한 NGINX 버전과의 호환성을 보장할 수 없었습니다.

3. NGINX 설정에 대한 표준 부재

다양한 팀으로부터 시스템을 상속받으면서, NGINX 설정 방법이 다양하게 나타났으며, 표준화된 설정이 없었습니다. 통일된 설정 표준의 부재는 팀 간 구현 방법의 다양성을 강조하며, NGINX 설정에 대한 일관적이고 표준화된 접근 방식의 필요성을 강조했습니다.

4. 현대적인 게이트웨이 기능 부족

NGINX는 리버스 프록시와 로드 밸런싱과 같은 기본적인 북-남 게이트웨이 요구사항을 효율적으로 충족시켰지만, 회사의 동적인 비즈니스 요구사항은 고급 기능을 필요로 했습니다. 서킷 브레이커, 보안 제어, 카나리 릴리스와 같은 서비스를 구현하는 것은 NGINX에만 의존할 때 어려움이 있었으며, 이로 인해 더 강력한 솔루션을 탐색하게 되었습니다.

정확한 비즈니스 요구사항을 위한 게이트웨이 선택

NGINX와 관련된 도전 과제를 해결하기 위해, 이 선도적인 항공사는 새로운 게이트웨이 솔루션에 대한 세 가지 주요 기본 요구사항을 신중하게 정리했습니다:

  1. 관리 및 설정의 용이성: 여러 게이트웨이 노드에서 경로 및 업스트림 서비스와 같은 설정을 쉽고 통합적으로 관리하고 배포할 수 있는 솔루션이 필요합니다.
  2. API 게이트웨이의 더 고급 기능: 새로운 게이트웨이는 서킷 브레이커, 보안 제어, 카나리 릴리스와 같은 현대적인 API 게이트웨이 비즈니스 요구사항을 충족해야 합니다.
  3. 사용 편의성과 낮은 학습 곡선: 관리 비용을 낮추기 위해, 팀은 새로운 게이트웨이 솔루션이 대부분의 기본 요구사항을 설정 및 로우 코드 방법을 통해 쉽게 충족할 수 있기를 기대합니다.

기존 북-남 게이트웨이에 대한 반복적인 업그레이드와 기본 요구사항을 명확히 한 후, 회사는 시장에서 다양한 인기 제품을 조사하고 최종적으로 APISIX를 새로운 게이트웨이로 선택했습니다.

왜 OpenResty가 아닌가

조사 과정에서 OpenResty가 먼저 고려되었으며, 일부 회사에서 널리 채택된 솔루션이었습니다. 주요 장점은 설정 파일이 NGINX와 완전히 호환된다는 점이었습니다. NGINX에서 OpenResty로의 마이그레이션은 복잡한 도메인 설정이 있었음에도 불구하고 그리 어렵지 않았습니다.

그러나 Kong과 APISIX와 비교했을 때, OpenResty의 오픈소스 버전은 포괄적인 플러그인과 시각적 설정을 위한 대시보드가 부족했습니다. 사용자는 일부 기본 기능을 충족하기 위해 코딩을 해야 했습니다.

왜 Kong이 아닌가

항공사는 Kong을 대안으로 고려했습니다. 기본 플러그인이 대부분의 요구사항을 충족시켰지만, 오픈소스 버전의 시각적 인터페이스(대시보드)가 몇 년 동안 변경되지 않아 더 최신이고 사용자 친화적인 인터페이스를 가진 솔루션을 선호하게 되었습니다.

스트레스 테스트에서 APISIX는 Kong보다 더 나은 성능을 보였으며, 플러그인 없이 Kong보다 두 배, 속도 제한 및 Prometheus 플러그인이 활성화된 상태에서는 최대 열 배 더 나은 성능을 보였습니다. 또한 APISIX는 OpenResty를 기반으로 하여 우수한 라우팅 기능을 보여주어 팀의 신뢰를 높였습니다.

왜 Envoy가 아닌가

Envoy의 인상적인 기능에도 불구하고, C++ 언어와 더 가파른 학습 곡선, 특히 기술 팀의 한계로 인해 Envoy를 선호하는 게이트웨이 솔루션으로 선택하지 않기로 결정했습니다.

결국 기술 팀은 APISIX의 인정받은 기능과 성능으로 인해 새로운 게이트웨이로 APISIX를 선택했습니다.

APISIX가 돋보이는 이유는 무엇인가?

APISIX는 Kong과 비교했을 때 두 가지 주요 이유로 돋보였습니다.

  • APISIX 대시보드

    대시보드를 통해 기술 팀은 다양한 경로와 플러그인 설정을 편리하게 관리할 수 있습니다. 특히 APISIX 대시보드는 프로젝트의 오픈소스 부분으로, APISIX의 개발과 함께 지속적으로 업데이트되어 향상된 관리 경험을 제공합니다.

  • Apache 오픈소스 프로젝트

    Apache 소프트웨어 재단의 최상위 프로젝트인 APISIX는 Kong과 비교했을 때 사용자가 관련 기술 문서를 더 쉽게 찾을 수 있게 했습니다. Apache 커뮤니티의 지원은 문제에 직면했을 때 신뢰할 수 있는 기술 지원을 제공하여 APISIX가 항공사에 더 적합한 선택이 되게 했습니다.

또한 APISIX는 앞서 언급한 NGINX와 관련된 문제점을 효과적으로 해결합니다.

  • APISIX는 설정을 etcd에 저장하여 개발자가 단일 etcd 클러스터를 배포함으로써 다양한 도메인에 대한 여러 APISIX 노드를 쉽게 관리할 수 있게 합니다.

  • APISIX는 일반적인 플러그인을 포함하고 있으며, 이는 NGINX와 관련된 호환성 및 업그레이드 문제를 걱정하지 않아도 됩니다.

  • APISIX는 다양한 보안 및 트래픽 제어 플러그인을 포함하고 있어 서킷 브레이커, 보안 제어, 카나리 릴리스 등의 기능을 쉽게 활성화할 수 있습니다.

전반적으로 APISIX는 기술 팀에게 가장 적합한 제품으로 돋보입니다.

NGINX에서 APISIX로의 마이그레이션: 고급이지만 더 간단한 솔루션 탐색

NGINX에서 도메인 관리와 기능 구현은 주로 NGINX 설정 파일을 통해 이루어집니다. 여전히 NGINX와 OpenResty를 기반으로 하지만, APISIX는 완전히 다른 접근 방식을 채택하여 더 이상 NGINX 설정 파일을 사용하여 도메인을 관리하고 기능을 구현하지 않습니다.

대신 APISIX는 도메인 이름을 기반으로 경로와 업스트림을 설정하고, 이러한 경로에 다양한 추가 기능을 플러그인을 통해 구현합니다. APISIX의 내장 CORS 플러그인을 채택하여 크로스 리전 설정을 달성할 수 있으며, 이를 통해 라인별로 변환할 필요가 없습니다.

아래는 NGINX와 APISIX에서 설정하는 코드 비교입니다.

#   NGINX  conf
    add_header 'Access-Control-Allow-Origin' $corsHost;
    add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS';
    add_header 'Access-Control-Allow-Credentials' 'true';
    add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept,Authorization,appver';
    if ($request_method = 'OPTIONS') {
            return 204;
     }

#  APISIX  plugins config
    "cors": {
      "allow_credential": true,
      "allow_headers": "DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept,Authorization,appver",
      "allow_methods": "GET,POST,PUT,OPTIONS",
      "allow_origins": "https://wap.test.com,http://wap.test.com,",
    },
    "response-rewrite": {
      "status_code": 204,
      "vars": [
        [
          "request_method",
          "==",
          "OPTIONS"
        ]
      ]
    }

NGINX와 APISIX를 비교해보면, NGINX 설정이 더 간결해 보일 수 있지만, NGINX와 CORS에 익숙하지 않은 사람들에게는 그 의미를 이해하기가 쉽지 않을 수 있습니다. 반면 APISIX는 다양한 기능을 플러그인으로 캡슐화하여 설정을 더 모듈화합니다. 따라서 기능을 찾고 이해하는 것이 더 명확해집니다. NGINX에서 APISIX로 설정을 마이그레이션하는 유사한 예시는 WebSocket 설정과 같은 다양한 시나리오에서도 존재합니다.

성과

다중 노드 설정 관리 간소화

APISIX는 etcd를 통해 설정 저장을 개선하여 다양한 도메인에 걸친 여러 APISIX 노드를 더 쉽게 관리할 수 있게 합니다. 이는 단일 etcd 클러스터를 사용하여 작업을 간소화하며, 특정 도메인 설정과 연결된 다양한 APISIX 인스턴스를 효과적으로 제어할 수 있게 합니다. 또한 중앙 집중식 방법은 복잡성을 줄이고 원활한 관리를 촉진하며, 다양한 도메인 시나리오에서 APISIX의 확장성과 효율성을 향상시킵니다. 결과적으로 항공사에서는 단일 etcd 클러스터를 배포하여 다양한 도메인 설정과 연결된 여러 APISIX 인스턴스를 관리할 수 있습니다.

APISIX 플러그인을 통한 운영 간소화

APISIX는 일반적인 상태 점검과 같은 내장 플러그인을 포함하고 있으며, 이는 NGINX에서 자주 사용되는 플러그인과 유사합니다. 이 기능은 항공사가 업그레이드 및 호환성 문제에 대해 걱정할 필요가 없게 합니다. APISIX에 포함된 이러한 플러그인은 원활한 기능을 보장하고 업그레이드 및 호환성 유지와 관련된 문제를 해결하여 항공사에게 번거로움 없는 경험을 제공합니다.

또한 APISIX에서는 크로스 오리진 리소스 공유(CORS) 및 WebSocket 지원과 같은 기능을 플러그인을 통해 원활하게 구현할 수 있습니다. 이 접근 방식은 개발 프로세스를 간소화할 뿐만 아니라 항공사의 문제를 더 정교하고 효율적으로 해결하는 데 기여합니다.

포괄적인 API 게이트웨이 구축

APISIX는 다양한 보안 및 트래픽 제어 플러그인을 포함하고 있어 서비스 제한, 보안 조치, 점진적 릴리스와 같은 기능을 쉽게 구현할 수 있습니다. 이는 항공사가 더 넓은 범위의 기본 및 고급 기능을 활용할 수 있게 합니다. APISIX의 채택은 항공사에게 향상된 서비스 신뢰성, 강력한 보안 제어, 점진적 릴리스와 같은 효율적인 배포 전략을 가능하게 하여 운영 능력과 성능을 높이는 중요한 성과를 가져왔습니다.

레거시 설정을 재사용 가능한 모듈로 개편

전체 업그레이드 과정에서 기술 팀은 기존 NGINX 설정에서 수많은 구식 설정을 발견했으며, 이 중 많은 부분이 무의미한 복사-붙여넣기로 이루어져 있었습니다. 이 업그레이드는 전체 북-남 게이트웨이를 대대적으로 개편하는 과정이었으며, 특히 APISIX가 제공하는 plugin_config와 같은 기능에 초점을 맞췄습니다. 이러한 기능은 게이트웨이 수준에서 설정의 모듈화된 관리와 재사용을 크게 촉진했습니다. APISIX의 plugin_config 및 관련 기능의 구현은 설정 프로세스를 간소화할 뿐만 아니라 북-남 게이트웨이의 전반적인 효율성과 유지보수성을 향상시켰습니다. 이 업그레이드는 더 체계적이고 모듈화된 재사용 가능한 설정 관리로의 중요한 전환을 의미했습니다.

요약

2023년 4월에 이 선도적인 항공사가 처음으로 APISIX를 접한 이후, 같은 해 7월에 NGINX에서 APISIX로의 성공적인 프로덕션 환경 마이그레이션을 완료하면서 전체 마이그레이션 과정은 만족스러운 결과를 가져왔습니다.

마이그레이션 초기 단계에서 기술 팀은 다양한 역사적 설정을 처리했으며, APISIX 플러그인이 기존 NGINX의 모든 기능을 완전히 복제할 수 있는지에 대한 우려가 있었습니다. 그러나 최종 결과는 APISIX 플러그인이 이 도전을 충분히 충족할 수 있음을 보여주었습니다.

요약하자면, APISIX는 더 우아한 솔루션을 제공하고 이 선도적인 항공사가 새로운 기술 단계로 나아가도록 도왔습니다. APISIX는 NGINX에서 직면한 다양한 문제점을 완벽하게 해결했으며, 풍부한 플러그인 세트를 통해 항공사가 클라이언트가 제기한 다양한 새로운 요구사항을 쉽게 해결할 수 있게 했습니다.

Tags:
Airlines