블로그 | NGINX

튜토리얼: 멀티 클라우드 및 하이브리드 환경에서 API 게이트웨이의 고가용성

NGINX-F5-수평-검정-유형-RGB의 일부
아카쉬 아난타나라야난 썸네일
아카쉬 아난타나라야난
2022년 12월 20일 게시

멀티 클라우드 배포는 앞으로도 계속될 것입니다. F5의 2022년 애플리케이션 전략 현황 보고서에 따르면, 기업의 77%가 여러 클라우드에서 애플리케이션을 운영하고 있습니다. 멀티 클라우드와 하이브리드 아키텍처를 도입하면 효율성 향상, 중단 위험 감소, 공급업체 종속성 회피 등 중요한 이점을 얻을 수 있습니다. 하지만 이러한 복잡한 아키텍처는 고유한 과제도 안고 있습니다.

F5가 조사한 소프트웨어 및 IT 리더들은 다음을 최대 멀티 클라우드 과제로 꼽았습니다.

  • 가시성(응답자의 45%)
  • 보안(44%)
  • 앱 마이그레이션(41%)
  • 성능 최적화(40%)

특히 멀티 클라우드 환경에서 마이크로서비스를 위한 API를 관리하는 것은 복잡합니다. 전체적인 API 전략이 없으면 API는 Platform Ops 팀이 보호하고 관리할 수 있는 속도보다 더 빠르게 퍼블릭 클라우드, 온프레미스, 에지 환경 전반으로 확산됩니다. 우리는 이 문제를 API 확산 이라고 부르며, 이전 게시물 에서는 이것이 왜 그토록 심각한 위협인지 설명했습니다.

여러 클라우드에 분산된 마이크로서비스를 통합하는 신중한 접근 방식을 구현하여 엔드투엔드 연결을 보장하려면 멀티 클라우드 API 전략이 필요합니다. 멀티 클라우드 및 하이브리드 배포의 일반적인 시나리오 두 가지는 다음과 같습니다.

  • 멀티 클라우드/하이브리드 환경의 다양한 서비스 – 비용 효율성을 위해 또는 다양한 서비스가 다양한 사용자 그룹에 적합하기 때문에 다양한 위치에서 다양한 애플리케이션과 API를 운영해야 합니다.
  • 멀티 클라우드/하이브리드 환경에서의 동일한 서비스 – 서로 다른 위치에 배포된 동일한 애플리케이션에 대해 높은 가용성을 보장해야 합니다.

다음 튜토리얼에서는 두 번째 시나리오인 고가용성을 위해 여러 환경에 동일한 서비스를 배포하는 경우 F5 NGINX Management Suite 의 일부인 API Connectivity Manager를 사용하는 방법을 단계별로 보여줍니다. 이를 통해 멀티 클라우드 또는 하이브리드 프로덕션 환경에서 단일 장애 지점이 제거됩니다. 게이트웨이 인스턴스 하나가 실패하면 다른 게이트웨이 인스턴스가 작동을 이어받으므로 한 클라우드가 중단되더라도 고객은 중단을 경험하지 않습니다.

API Connectivity Manager는 API를 배포, 관리 및 보호하기 위한 클라우드 기반, 런타임에 독립적인 솔루션입니다. 단일 창에서 퍼블릭 클라우드, 온프레미스 및 엣지 환경에 배포된 NGINX Plus API 게이트웨이와 개발자 포털에 대한 모든 API 작업을 관리할 수 있습니다. 이를 통해 플랫폼 운영 팀은 API 트래픽에 대한 완전한 가시성을 확보하고 모든 환경에 일관된 거버넌스 및 보안 정책을 쉽게 적용할 수 있습니다.

멀티 클라우드 배포에서 API 게이트웨이에 대한 고가용성 활성화

소개에서 언급한 대로 이 튜토리얼에서는 여러 배포 환경에서 실행되는 서비스의 고가용성을 위해 API Connectivity Manager를 구성합니다. 구체적으로, NGINX Plus를 API 게이트웨이로 배포하여 두 서비스인 서비스 A서비스 B 로 트래픽을 라우팅합니다. 이 두 서비스는 두 개의 퍼블릭 클라우드인 Google Cloud Platform(GCP)과 Amazon Web Services(AWS)에서 실행됩니다. (설정은 Microsoft Azure와 온프레미스 데이터 센터를 포함한 모든 배포 환경에 동일하게 적용됩니다.)

그림 1은 튜토리얼에서 사용된 토폴로지를 보여줍니다.

두 클라우드에 배포된 고가용성 API 게이트웨이에 클라이언트가 액세스하는 토폴로지
그림 1: API Connectivity Manager는 API 게이트웨이 및 서비스의 멀티 클라우드 HA 배포를 지원합니다.

튜토리얼을 완료하려면 다음 섹션의 단계를 따르세요.

API Connectivity Manager 설치 및 구성

  1. NGINX Management Suite에 대한 평가판이나 유료 구독을 받으세요. 이 제품군에는 Instance Manager와 API Connectivity Manager가 포함되어 있으며, API 게이트웨이로 NGINX Plus를 제공하고, API를 보호하기 위해 NGINX App Protect도 제공됩니다. 시작하려면 NGINX Management Suite의 무료 30일 체험판을 시작하세요 .
  2. NGINX 관리 제품군을 설치합니다. 관리 제품군 모듈 설치 섹션에서 API 연결 관리자(및 선택적으로 다른 모듈)에 대한 지침을 따릅니다.
  3. 설치된 각 모듈에 대한 라이센스를 추가합니다 .
  4. (선택 과목.) TLS 종료 및 mTLS 설정데이터 플레인에서 각각 NGINX Management Suite에 대한 클라이언트 연결과 API Connectivity Manager 및 NGINX Plus 인스턴스 간 트래픽을 보호합니다.

NGINX Plus 인스턴스를 API 게이트웨이로 배포

멀티 클라우드 또는 하이브리드 인프라를 구성하는 환경을 선택하세요. 이 튜토리얼에서는 AWS와 GCP를 선택하고 각 클라우드에 하나의 NGINX Plus 인스턴스를 설치합니다. 각 환경에서 API 게이트웨이 역할을 할 각 데이터 평면 호스트에서 다음 단계를 수행합니다.

  1. 지원되는 운영 체제NGINX Plus를 설치하세요 .
  2. NGINX JavaScript 모듈(njs)을 설치합니다 .
  3. /etc/nginx/nginx.conf 의 기본(최상위) 컨텍스트에 다음 지침을 추가합니다.

    로드_모듈 모듈/ngx_http_js_module.so; 로드_모듈 모듈/ngx_stream_js_module.so;
    
  4. 예를 들어 다음 명령을 실행하여 NGINX Plus를 다시 시작합니다.

    $ nginx -s 다시 로드
    

인프라 작업 공간 설정

API Connectivity Manager에서 여러 개의 Infrastructure Workspace(이 글을 쓰는 시점에는 최대 10개)를 만들 수 있습니다. 분리된 작업 공간을 사용하면 다양한 사업부, 개발자 팀, 외부 파트너, 클라우드 등에 맞게 정책과 인증/권한 부여 요구 사항을 적용할 수 있습니다.

API Connectivity Manager GUI에서 작업하여 새 작업 공간을 만듭니다.

  1. 왼쪽 탐색 열에서 인프라를 클릭합니다.
  2. 그림 2와 같이 + 만들기 버튼을 클릭하여 새 작업 공간을 만듭니다.

    그림 2: 새로운 인프라 작업 공간 만들기
  3. 열리는 작업 공간 만들기 패널에서 이름 필드(그림 3의 demo )를 입력합니다. 선택적으로 설명 필드와 작업 공간 연락처 정보 섹션의 필드를 입력합니다. 인프라 관리자(예: 플랫폼 운영 팀)는 연락처 정보를 사용하여 작업 공간 사용자에게 상태나 문제에 대한 업데이트를 제공할 수 있습니다.

    그림 3: 새 인프라 작업 공간 이름 지정 및 연락처 정보 추가
  4. 만들기 버튼을 클릭하세요.

환경 및 API 게이트웨이 클러스터 생성

API Connectivity Manager에서 환경은 전용 리소스(API 게이트웨이 또는 API 개발자 포털 등)의 논리적 그룹입니다. 작업 공간당 여러 개의 환경을 만들 수 있습니다(이 글을 쓰는 시점에는 최대 25개). 일반적으로 환경은 코딩, 테스트, 프로덕션과 같은 앱 개발 및 배포의 여러 단계에 해당하지만 원하는 모든 목적에 활용할 수 있습니다.

환경 내에서 API 게이트웨이 클러스터는 API 게이트웨이 역할을 하는 NGINX Plus 인스턴스의 논리적 그룹입니다. 단일 환경에는 동일한 호스트 이름을 공유하는 여러 API 게이트웨이 클러스터가 있을 수 있습니다(예: 이 튜토리얼의 경우 api.nginx.com ). API 게이트웨이 클러스터의 NGINX Plus 인스턴스는 여러 클라우드와 같이 여러 유형의 인프라에 위치할 수 있습니다.

API 게이트웨이의 활성-활성 고가용성을 위해 API Connectivity Manager에서 환경을 구성하는 방법은 두 가지가 있습니다.

여러 API Gateway 클러스터를 배포하는 주된 이유는 각 클러스터에 다른 보안 정책 세트를 적용할 수 있기 때문입니다.

Deploy NGINX Plus Instances as API Gateways 에서 두 개의 NGINX Plus 인스턴스를 배포했습니다. 하나는 AWS에, 다른 하나는 GCP에 배포했습니다. 이 튜토리얼에서는 두 가지 환경 유형(단일 API 게이트웨이 클러스터 또는 여러 API 게이트웨이 클러스터)을 설명하기 위해 동일한 인스턴스를 사용합니다. 두 가지 환경 유형을 단일 작업 공간에 배포하려면 두 번째 환경에 대한 추가 NGINX Plus 인스턴스를 만들어야 합니다.

하나의 API Gateway 클러스터로 환경 배포

그림 4에서 볼 수 있듯이 하나의 API Gateway 클러스터가 있는 환경의 경우 동일한 보안 정책이 모든 NGINX Plus API Gateway 인스턴스에 적용됩니다.

API Connectivity Manager의 하나의 API Gateway 클러스터에 배포된 API Gateway에 동일한 보안 정책이 적용되는 방식을 보여주는 다이어그램
그림 4: 하나의 API Gateway 클러스터에 배포된 API Gateway에 동일한 보안 정책이 적용됩니다.
환경 및 API 게이트웨이 클러스터 생성
  1. 그림 5와 같이 작업 공간으로 이동하여 환경 만들기 버튼을 클릭합니다.

    그림 5: 인프라 작업 공간에서 새 환경 만들기
  2. 열리는 환경 만들기 패널에서 이름 필드(그림 6의 prod )와 선택적으로 설명 필드를 입력하고 환경 유형을 선택합니다(여기서는 Prod를 선택했습니다).

    그림 6: 새 환경 이름 지정 및 해당 환경에 API Gateway 클러스터 할당
  3. API Gateway Clusters 섹션에서 이름호스트 이름 필드(그림 6의 api-clusterapi.nginx.com )를 입력합니다.
  4. 만들기 버튼을 클릭하세요.

    환경 생성 패널이 열리고 API Gateway 클러스터에 할당하기 위해 각 NGINX Plus 인스턴스에서 실행해야 하는 명령이 표시됩니다. 편의상 아래 7단계 의 명령을 표시하겠습니다.

API Gateway 인스턴스를 API Gateway 클러스터에 할당

각 NGINX Plus 인스턴스에서 반복 :

  1. ssh를 사용하여 인스턴스에 연결하고 로그인합니다.
  2. NGINX 에이전트가 이미 실행 중이면 중지하세요.

    $ systemctl nginx-에이전트 중지
    
  3. 원하는 명령( curl 또는 wget )을 실행하여 NGINX 에이전트 패키지를 다운로드하고 설치합니다.

    • API Connectivity Manager 설치 및 구성 에서 mTLS를 활성화하지 않은 경우 다음을 추가합니다.

      • curl 명령에 대한 ‑k 플래그
      • wget 명령에 --no-check-certificate 플래그를 추가합니다.
    • 을 위한 <NMS_FQDN>NGINX Management Suite 서버의 IP 주소나 정규화된 도메인 이름으로 대체하세요.
    • 을 위한 <클러스터 이름>, API Gateway 클러스터의 이름을 대체합니다.API 클러스터 (이 튜토리얼에서)
    $ 컬 [-k] https://<NMS_FQDN>/install/nginx-agent > install.sh && sudo sh -install.sh -g <클러스터 이름> && sudo systemctl 시작 nginx-에이전트
    

    또는

    $ wget [--no-check-certificate] https://<NMS_FQDN>/install/nginx-agent --no-check-certificate -O install.sh && sudo sh install.sh -g <클러스터 이름> && sudo systemctl 시작 nginx-에이전트
    

    NGINX Plus 인스턴스는 이제 그림 7에서 보이는 것처럼 api-cluster 에 대한 클러스터 창의 인스턴스 섹션에 나타납니다.

    그림 7: 단일 API Gateway Cluster는 여러 클라우드에 배포된 NGINX Plus 인스턴스를 그룹화합니다.
  4. 글로벌 정책 적용 으로 진행합니다.

여러 API Gateway 클러스터가 있는 환경 배포

여러 API 게이트웨이 클러스터가 있는 환경의 경우 그림 8에서와 같이 서로 다른 NGINX Plus API 게이트웨이 인스턴스에 서로 다른 보안 정책을 적용할 수 있습니다.

API Connectivity Manager의 별도 API Gateway 클러스터에 배포된 API Gateway에 다양한 보안 정책을 적용할 수 있는 방법을 보여주는 다이어그램
그림 8: API 게이트웨이에 배포된 보안 정책은 다양할 수 있습니다.
API 게이트웨이 클러스터 분리
환경 및 API 게이트웨이 클러스터 생성
  1. 그림 9와 같이 작업 공간으로 이동하여 환경 만들기 버튼을 클릭합니다.

    그림 9: 인프라 작업 공간에서 새 환경 만들기
  2. 열리는 환경 만들기 패널에서 이름 필드(그림 10의 prod )와 선택적으로 설명 필드를 입력하고 환경 유형을 선택합니다(여기서는 Prod를 선택했습니다).

    그림 10: 새 환경 이름 지정 및 첫 번째 API 게이트웨이 클러스터 할당
  3. API Gateway Clusters 섹션에서 NameHostname 필드를 입력합니다(그림 10에서는 aws-clusterapi.nginx.com 입니다).
  4. 만들기 버튼을 클릭하세요.

    환경 생성 패널이 열리고 API Gateway 클러스터에 할당하기 위해 각 NGINX Plus 인스턴스에서 실행해야 하는 명령이 표시됩니다. 편의상 아래 10단계 의 명령을 표시하겠습니다.

  5. 그림 11과 같이 환경 탭으로 돌아가서 API Gateway 클러스터 섹션의 오른쪽 상단 모서리에 있는 + 추가 버튼을 클릭합니다.

    그림 11: 환경에 다른 API Gateway 클러스터 추가
  6. API Gateway 클러스터 생성 패널에서 이름 필드에 두 번째 클러스터 이름(그림 12의 gcp-cluster )을 입력하고 호스트 이름 필드에 첫 번째 클러스터와 동일한 호스트 이름( api.nginx.com )을 입력합니다.

    그림 12: 환경에 두 번째 API 게이트웨이 클러스터 추가

그림 13과 같이 두 개의 API 게이트웨이 클러스터가 이제 Prod 환경의 API 게이트웨이 클러스터 에 나타납니다.

그림 13: 여러 클라우드와 별도의 API Gateway 클러스터에 배포된 NGINX Plus 인스턴스 목록
API Gateway 인스턴스를 API Gateway 클러스터에 할당

각 NGINX Plus 인스턴스에서 반복 :

  1. ssh를 사용하여 인스턴스에 연결하고 로그인합니다.
  2. NGINX 에이전트가 이미 실행 중이면 중지하세요.

    $ systemctl nginx-에이전트 중지
    
  3. 원하는 명령( curl 또는 wget )을 실행하여 NGINX 에이전트 패키지를 다운로드하고 설치합니다.

    • API Connectivity Manager 설치 및 구성 에서 mTLS를 활성화하지 않은 경우 다음을 추가합니다.

      • curl 명령에 대한 ‑k 플래그
      • wget 명령에 --no-check-certificate 플래그를 추가합니다.
    • 을 위한 <NMS_FQDN>NGINX Management Suite 서버의 IP 주소나 정규화된 도메인 이름으로 대체하세요.
    • 을 위한 <클러스터 이름>, 적절한 API Gateway 클러스터의 이름을 대체합니다(이 튜토리얼에서는 aws‑클러스터 AWS에 배포된 인스턴스의 경우 gcp‑클러스터 (GCP에 배포된 인스턴스의 경우)
    $ 컬 [-k] https://<NMS_FQDN>/install/nginx-agent > install.sh && sudo sh -install.sh -g <클러스터 이름> && sudo systemctl 시작 nginx-에이전트
    

    또는

    $ wget [--no-check-certificate] https://<NMS_FQDN>/install/nginx-agent --no-check-certificate -O install.sh && sudo sh install.sh -g <클러스터 이름> && sudo systemctl 시작 nginx-에이전트
    

    이제 적절한 NGINX Plus 인스턴스가 aws‑cluster (그림 14) 및 gcp‑cluster (그림 15)에 대한 클러스터 창의 인스턴스 섹션에 나타납니다.

    그림 14: 여러 클라우드에 걸쳐 있는 환경에서 두 개의 API 게이트웨이 클러스터 중 첫 번째
    그림 15: 여러 클라우드에 걸쳐 있는 환경에서 두 개의 API 게이트웨이 클러스터 중 두 번째

    글로벌 정책 적용

    이제 API Gateway 클러스터의 모든 NGINX Plus 인스턴스에 적용되는 글로벌 정책을 추가할 수 있습니다. 예를 들어, API에 대한 클라이언트 액세스를 보호하려면 OpenID Connect 신뢰 당사자 또는 TLS 인바운드 정책을 적용할 수 있습니다. API 게이트웨이와 API를 노출하는 백엔드 서비스 간의 연결을 보호하려면 TLS 백엔드 정책을 적용합니다. TLS 정책에 대한 자세한 내용은 API Connectivity Manager 설명서를 참조하세요.

    1. 정책을 적용하려는 API Gateway의 클러스터 탭으로 이동합니다(그림 16의 api-cluster ). 정책 표의 오른쪽 위에 있는 관리 버튼을 클릭합니다.

      그림 16: API Gateway 클러스터에 대한 정책 관리
    2. 왼쪽 탐색 열에서 글로벌 정책을 클릭한 다음 정책 행의 가장 오른쪽 열에 있는 ... 아이콘을 클릭합니다(그림 17의 TLS 백엔드 ). 드롭다운 메뉴에서 + 정책 추가를 선택합니다.

      그림 17: API Gateway 클러스터에 글로벌 정책 추가

    결론

    멀티 클라우드와 하이브리드 아키텍처를 관리하는 것은 쉬운 일이 아닙니다. 이러한 환경은 빠르게 변화하는 애플리케이션을 갖춘 복잡한 환경으로, 관찰하고 보호하기 어려운 경우가 많습니다.

    하지만 적절한 도구를 사용하면 공급업체에 대한 종속성을 피하는 동시에 새로운 기능을 더 빠르게 시장에 출시하는 데 필요한 민첩성과 유연성을 유지할 수 있습니다. NGINX의 API Connectivity Manager는 클라우드 기반 도구로서 멀티 클라우드 및 하이브리드 환경에서 API를 관리하는 데 필요한 확장성, 가시성, 거버넌스 및 보안을 제공합니다.

    API Connectivity Manager , API 게이트웨이인 NGINX Plus , API를 보호하기 위한 NGINX App Protect가 포함된 NGINX Management Suite의 30일 무료 평가판을 시작하세요.


"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."