API Connectivity Manager 를 통해 API Gateway 고가용성 유지

다음 튜토리얼에서는 F5 NGINX Management Suite의 일부인 API Connectivity Manager 를 사용하는 방법을 단계별로 안내합니다. 이 튜토리얼은 두 번째 시나리오에서 진행되며, 고가용성을 위해 동일한 서비스를 여러 환경에 배포하는 것을 다룹니다. 이를 통해 멀티 클라우드 또는 하이브리드 프로덕션 환경에서 단일 장애 지점을 제거할 수 있습니다. 즉, 하나의 Gateway 인스턴스가 실패하면 다른 Gateway 인스턴스가 이를 대신하고 고객은 중단 없이 서비스를 이용할 수 있습니다. 심지어 하나의 클라우드가 다운되어도 문제가 발생하지 않습니다.

API Connectivity Manager 는 클라우드 네이티브이며 런타임에 중립적인 솔루션으로 API를 배포, 관리 및 보안하는 데 사용됩니다. 단일 대시보드에서 공용 클라우드, 온프레미스 및 엣지 환경에 배포된 NGINX Plus API Gateway 및 개발자 포털의 모든 API 작업을 관리할 수 있습니다. 이를 통해 플랫폼 운영팀은 API 트래픽에 대한 전체적인 가시성을 확보하고 모든 환경에 일관된 거버넌스 및 보안 정책을 적용하기 쉽게 할 수 있습니다.

목차

1. 개요
2. Multi-cloud 배포에서 API Gateway에 대한 고가용성 활성화
 2-1. API Connectivity Manager 설치 및 구성
 2-2. NGINX Plus 인스턴스를 API Gateway로 배포
 2-3. 인프라 작업 공간 설정
 2-4. API Connectivity Manager 를 통해 Environment 및 API Gateway 클러스터 생성
  2-4-1. 하나의 API Gateway 클러스터가 있는 환경 배포
  2-4-2. 여러 API Gateway 클러스터가 있는 환경 배포
 2-5. API Connectivity Manager 를 통해 전역 정책 적용
3. 결론

1. 개요

멀티 클라우드 배포는 계속해서 성장하고 있습니다. F5의 2022년 애플리케이션 전략 현황 보고서에 따르면, 기업의 77%가 여러 클라우드에 걸쳐 애플리케이션을 운영하고 있습니다. 멀티 클라우드 및 하이브리드 아키텍처의 채택은 향상된 효율성, 장애 위험 감소 및 벤더 락인 회피와 같은 중요한 이점을 제공합니다. 그러나 이러한 복잡한 아키텍처는 독특한 도전과제도 함께 제시합니다.

F5가 조사한 소프트웨어 및 IT 리더들은 다음을 멀티 클라우드의 주요 도전 과제로 지목했습니다.

  • 가시성 (응답자의 45%)
  • 보안 (44%)
  • 애플리케이션 이전 (41%)
  • 성능 최적화 (40%)

멀티 클라우드 환경에서 마이크로서비스의 API 관리는 특히 복잡합니다. 종합적인 API 전략이 없는 상태에서는 플랫폼 운영팀이 보안 및 관리를 할 수 있는 속도보다 API가 공용 클라우드, on-premises 및 edge 환경에 더 빠르게 증가합니다. 이러한 문제를 API 확산이라고 하며, 이전 포스트에서 왜 이런 심각한 위협인지 설명했습니다.

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

  • 멀티 클라우드/하이브리드 환경에서 다른 서비스 – 서로 다른 위치에서 다양한 애플리케이션과 API를 운영해야 할 수도 있습니다. 비용 효율성을 위해서이거나 서로 다른 서비스가 다른 사용자 그룹에게 관련이 있는 경우일 수 있습니다.
  • 멀티 클라우드/하이브리드 환경에서 동일한 서비스 – 서로 다른 위치에 배포된 동일한 애플리케이션의 고가용성을 보장해야 할 수도 있습니다.

2. Multi-cloud 배포에서 API Gateway에 대한 고가용성 활성화

앞서 언급한 대로, 이 자습서에서는 다중 배포 환경에서 서비스의 고가용성을 위해 API 연결 관리자를 구성합니다. 구체적으로, 우리는 NGINX Plus를 API Gateway로 배포하여 두 개의 서비스, 서비스 A와 서비스 B를 라우팅하고 있습니다. 이 서비스들은 Google Cloud Platform (GCP)와 Amazon Web Services (AWS)라는 두 개의 공용 클라우드에서 실행됩니다. (이 설정은 Microsoft Azure 및 온프레미스 데이터 센터를 포함한 모든 배포 환경의 혼합에도 동일하게 적용됩니다.)

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

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

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

2-1. API Connectivity Manager 설치 및 구성

  1. NGINX Management Suite의 평가판 또는 유료 구독을 획득하세요. 이에는 Instance Manager와 API Connectivity Manager, NGINX Plus API Gateway 및 NGINX App Protect로 API를 보호하는 기능이 포함되어 있습니다. NGINX Management Suite의 무료 30일 평가판을 시작하여 시작하세요.
  2. NGINX Management Suite를 설치하세요. “Install Management Suite Modules” 섹션에서 API Connectivity Manager (및 선택적으로 다른 모듈)에 대한 지침을 따르세요.
  3. 각 설치된 모듈에 라이선스를 추가하세요. (선택 사항) TLS 종료 및 mTLS를 설정하여 클라이언트 연결을 NGINX Management Suite와 Data Plane의 NGINX Plus 인스턴스 간의 트래픽을 보호하세요.

2-2. NGINX Plus 인스턴스를 API Gateway로 배포

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

  1. 지원되는 운영 체제에 NGINX Plus를 설치합니다.
  2. NGINX JavaScript 모듈 (njs)을 설치합니다.
  3. /etc/nginx/nginx.conf 의 기본(최상위) 컨텍스트에 다음 지시문을 추가합니다.
    load_module modules/ngx_http_js_module.so;
    load_module modules/ngx_stream_js_module.so;
  4. 예를 들어 다음 명령을 실행하여 NGINX Plus를 다시 시작합니다.
    $ nginx -s reload

2-3. 인프라 작업 공간 설정

API Connectivity Manager 에서는 여러 인프라 Workspace (현재 최대 10개까지)를 생성할 수 있습니다. 분리된 Workspace를 사용하면 비즈니스 라인, 개발팀, 외부 파트너, 클라우드 등에 특정한 정책 및 인증/인가 요구사항을 적용할 수 있습니다.

API Connectivity Manager GUI에서 새로운 Workspace를 생성하는 방법은 다음과 같습니다.

  1. 왼쪽 탐색 열에서 “Infrastructure“를 클릭합니다.
  2. 그림 2와 같이 새로운 Workspace를 생성하기 위해  + Create  버튼을 클릭합니다.
Screenshot of `Workspaces` page with `Create Workspace` button on API Connectivity Manager `Infrastructure` tab

그림 2: 새 Infrastructure 작업 공간 만들기

3. “Workspace 생성” 패널이 열리면, Name 필드 (그림 3에서는 demo로 표시)에 값을 입력합니다. 원하는 경우, Description 필드와 Workspace Contact Information 섹션의 필드도 채워 넣을 수 있습니다. 인프라 관리자 (예: 플랫폼 운영팀)는 사용자들에게 Workspace에 대한 상태나 문제에 대한 업데이트를 제공하기 위해 연락처 정보를 사용할 수 있습니다.

API Connectivity Manager '인프라' 탭의 '데모'에 대한 '작업공간 만들기' 패널의 스크린샷
그림 3: 새 인프라 작업 공간 이름 지정 및 연락처 정보 추가

4.  Create  버튼을 클릭합니다.

2-4. API Connectivity Manager 를 통해 Environment 및 API Gateway 클러스터 생성

API Connectivity Manager 에서 환경은 API Gateway나 API 개발자 포털과 같은 전용 리소스의 논리적인 그룹화입니다. Workspace 당 여러 환경을 생성할 수 있으며 (현재 기준 최대 25개), 일반적으로 코딩, 테스트 및 Production과 같은 앱 개발 및 배포의 다른 단계에 해당하지만, 원하는 목적에 따라 사용할 수 있습니다.

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

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

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

“NGINX Plus 인스턴스를 API Gateway로 배포“에서는 AWS와 GCP에 각각 하나의 NGINX Plus 인스턴스를 배포했습니다. 이 튜토리얼에서는 환경 유형(단일 API Gateway 클러스터 또는 다중 API Gateway 클러스터)을 설명하기 위해 동일한 인스턴스를 사용합니다. 하나의 작업 공간에서 두 가지 환경 유형을 모두 배포하려면 두 번째 환경을 위해 추가적인 NGINX Plus 인스턴스를 생성해야합니다.

2-4-1. 하나의 API Gateway 클러스터가 있는 환경 배포

단일 API Gateway 클러스터를 가진 환경에서는 그림 4에 표시된대로 모든 NGINX Plus API Gateway 인스턴스에 동일한 보안 정책이 적용됩니다.

Diagram showing how the same security policies apply to API gateways deployed in one API Gateway Cluster
그림 4: 동일한 보안 정책이 하나의 API Gateway 클러스터에 배포된 API Gateway에 적용됩니다.

1. 그림 5와 같이 Workspace로 이동하여
 Create Environment  버튼을 클릭합니다.

API Connectivity Manager `Infrastructure | 작업 공간` 탭
그림 5: 인프라 Workspace에서 새 환경 만들기

2. 열리는 Create Environment 패널에서 Name 필드(그림 6의 prod)와 Description 필드(선택 사항)를 입력하고 Environment 유형(Prod 선택)을 선택합니다.

API Connectivity Manager `Infrastructure | 작업 공간` 탭
그림 6: 새 환경 이름 지정 및 여기에 API Gateway 클러스터 할당

3. API Gateway 클러스터 섹션에서, Name 필드와 Host name 필드 (그림 6에서는 api-cluster 및 api.nginx.com)를 입력하십시오.

4.  Create  버튼을 클릭합니다.

생성한 Environment 패널이 열리고, 각 NGINX Plus 인스턴스에 할당하기 위해 실행해야 하는 명령이 표시됩니다. 편의를 위해 아래 단계 7에서 명령을 보여줍니다.

5. 인스턴스에 연결하고 로그인하기 위해 ssh를 사용하세요.

6. 만약 NGINX Agent가 이미 실행 중이라면, 다음 명령을 사용하여 중지하세요.

$ systemctl stop nginx-agent

7. NGINX Agent 패키지를 다운로드하고 설치하기 위해 원하는 명령을 실행하세요. (curl 또는 wget 중 선택)

  • curl 명령에 -k flag
  • wget 명령에 --no-check-certificate flag
  • <NMS_FQDN>에는 NGINX Management Suite 서버의 IP 주소 또는 완전한 도메인 이름을 대체
  • <cluster_name>에는 API Gateway Cluster의 이름을 대체하세요 (이 예에서는 api-cluster)
$ curl [-k] https://<NMS_FQDN>/install/nginx-agent > install.sh && sudo sh -install.sh -g <cluster_name> && sudo systemctl start nginx-agent

또는

$ wget [--no-check-certificate] https://<NMS_FQDN>/install/nginx-agent --no-check-certificate -O install.sh && sudo sh install.sh -g <cluster_name> && sudo systemctl start nginx-agent

이제 NGINX Plus 인스턴스가 api-cluster의 Cluster 창의 Instances 섹션에 표시됩니다. (그림 7 참조)

Screenshot of `api-cluster` API Gateway Cluster page on API Connectivity Manager `Infrastructure | Workspace | Environment | Cluster` tab
그림 7: 단일 API Gateway 클러스터는 여러 클라우드에 배포된 NGINX Plus 인스턴스를 그룹화합니다.

8. 전역 정책 적용을 진행합니다.

2-4-2. 여러 API Gateway 클러스터가 있는 환경 배포

여러 API Gateway 클러스터가 있는 환경에서는 그림 8에 나와있는 것처럼 다른 보안 정책이 다른 NGINX Plus API Gateway 인스턴스에 적용될 수 있습니다.

Diagram showing how different security policies can apply to API gateways deployed in separate API Gateway Clusters in API Connectivity Manager
그림 8: 별도의 API Gateway 클러스터에 구축된 API Gateway에 다양한 보안 정책 적용 가능

1. 그림 9와 같이 Workspace로 이동하여  Create Environment  버튼을 클릭합니다.

API Connectivity Manager `Infrastructure | 작업 공간` 탭
그림 9: 인프라 Workspace에서 새 환경 만들기

2. 열리는 Create Environment 패널에서 Name 필드(그림 10의 prod)와 Description 필드(선택 사항)를 입력하고 Environment 유형(Prod 선택)을 선택합니다.

Screenshot of `Create Environment` panel on `Infrastructure | Workspace` tab
그림 10: 새 환경 이름 지정 및 첫 번째 API Gateway 클러스터 할당

3. API Gateway 클러스터 섹션에서 Name 및 Hostname 필드를 입력하세요 (그림 10에서는 aws-cluster 및 api.nginx.com입니다).

4.  Create  버튼을 클릭합니다.

생성된 Environment 패널이 열리고, 각 NGINX Plus 인스턴스에 할당하기 위해 실행해야 하는 명령이 표시됩니다. 편의를 위해 아래 단계 10에서 명령을 보여줍니다.

5. 그림 11에 표시된 대로, Environment 탭으로 돌아가서 API Gateway 클러스터 섹션의 오른쪽 상단에 있는  + Add  버튼을 클릭하세요.

Screenshot of `API Gateway Clusters` page with `+ Add` button on API Connectivity Manager `Infrastructure | Workspace | Environment` tab
그림 11: 환경에 다른 API Gateway 클러스터 추가

6. Create API Gateway Cluster 패널에서 Name 필드에 두 번째 클러스터 이름(그림 12의 gcp-cluster)을 입력하고 Hostname 필드에 첫 번째 클러스터(api.nginx.com)와 동일한 호스트 이름을 입력합니다.

Screenshot of `Create API Gateway Cluster` panel for `gcp-cluster` on API Connectivity Manager `Infrastructure| Workspace | Environment` tab

그림 12: 환경에 두 번째 API Gateway 클러스터 추가

그림 13에 표시된 대로, 두 개의 API Gateway 클러스터가 이제 Prod 환경의 API Gateway 클러스터에 나타납니다.

Screenshot of `API Gateway Clusters` page listing 2 clusters on API Connectivity Manager `Infrastructure | Workspace | Environment` tab
그림 13: 여러 클라우드와 별도의 API Gateway 클러스터에 구축된 NGINX Plus 인스턴스 목록

7. ssh를 사용하여 인스턴스에 로그인 합니다.

8. NGINX Agent가 이미 실행 중이라면, 다음 명령어를 사용해 중지합니다.

$ systemctl stop nginx-agent

9. 원하는 명령(curl 또는 wget)을 실행하여 NGINX Agent 패키지를 다운로드하고 설치합니다:

API Connectivity Manager 설치 및 구성에서 mTLS를 사용하도록 설정하지 않은 경우 다음을 추가합니다.

curl 명령에 대한 -k flag
wget 명령에 대한 --no-check-certificate flag
<NMS_FQDN>의 경우 NGINX Management Suite 서버의 IP 주소 또는 정규화된 도메인 이름을 대체
<cluster_name>의 경우 적절한 API Gateway 클러스터의 이름으로 대체 (이 예에서는 AWS에 배포된 인스턴스의 경우 aws-cluster, GCP에 배포된 인스턴스의 경우 gcp-cluster).

$ curl [-k] https://<NMS_FQDN>/install/nginx-agent > install.sh && sudo sh -install.sh -g <cluster_name> && sudo systemctl start nginx-agent

또는

$ wget [--no-check-certificate] https://<NMS_FQDN>/install/nginx-agent --no-check-certificate -O install.sh && sudo sh install.sh -g <cluster_name> && sudo systemctl start nginx-agent

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

Screenshot of `aws-cluster` API Gateway Cluster page on `Infrastructure | Workspace | Environment | Cluster` tab
그림 14: 여러 클라우드에 걸쳐 있는 환경의 두 API Gateway 클러스터 중 첫 번째 클러스터
Screenshot of `gcp-cluster` API Gateway Cluster page on `Infrastructure | Workspace | Environment | Cluster` tab
그림 15: 여러 클라우드에 걸쳐 있는 환경의 두 API Gateway 클러스터 중 두 번째 클러스터

2-5. API Connectivity Manager 를 통해 전역 정책 적용

이제 API Gateway 클러스터의 모든 NGINX Plus 인스턴스에 적용되는 전역 정책을 추가할 수 있습니다.
예를 들어, API에 대한 클라이언트 액세스를 보호하기 위해 OpenID Connect Relying Party 또는 TLS Inbound 정책을 적용할 수 있습니다.
API를 노출하는 백엔드 서비스와 API Gateway 간의 연결을 보호하려면 TLS Backend 정책을 적용하세요.

1. 적용할 정책을 원하는 API Gateway의 클러스터 탭(그림 16에 있는 api-cluster)으로 이동하세요. 정책 테이블 오른쪽 상단에 있는 Manage 버튼을 클릭하세요.

Screenshot of `api-cluster` API Gateway Cluster page on `Infrastructure | Workspace | Environment | Cluster` tab
그림 16: API Gateway 클러스터에 대한 정책 관리

2. 왼쪽 탐색 열에서 “전역 정책(Global Policies)”을 클릭한 다음, 정책 행의 가장 오른쪽 열에 있는 “…” 아이콘을 클릭하세요 (그림 17에서는 “TLS Backend” 정책입니다). 드롭다운 메뉴에서 “+ Add Policy”를 선택하세요.

Screenshot of API Connectivity Manager `Cluster` window with drop-down menu reading `+ Add Policy`
그림 17: API Gateway 클러스터에 글로벌 정책 추가

3. 결론

멀티 클라우드 및 하이브리드 아키텍처를 관리하는 것은 쉬운 일이 아닙니다. 이들은 빠르게 변화하는 어플리케이션을 포함한 복잡한 환경이며, 종종 관찰하고 보안하는 것이 어렵습니다.

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

NGINX Management Suite의 30일 무료 평가판을 시작하기 위해 NGINX STORE에 문의하세요.
이 평가판에는 API Connectivity Manager, API Gateway로서의 NGINX Plus, 그리고 API를 보호하기 위한 NGINX App Protect에 대한 액세스 권한이 포함되어 있습니다.

아래 뉴스레터를 구독하고 NGINX와 NGINX STORE의 최신 정보들을 빠르게 전달 받아보세요.