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

Akash Ananthanarayanan기술 마케팅 매니저 | F5 NGINX

멀티 클라우드 배포는 이제 거스를 수 없는 흐름입니다. F5의 2022년 애플리케이션 전략 현황 보고서에 따르면, 기업의 77%가 여러 클라우드에서 애플리케이션을 운영하고 있습니다. 멀티 클라우드 및 하이브리드 아키텍처를 도입하면 효율성 향상, 서비스 중단 위험 감소, 특정 공급업체에 대한 종속 방지와 같은 중요한 이점을 얻을 수 있습니다. 하지만 이러한 복잡한 아키텍처에는 고유한 과제도 따릅니다.

F5가 설문 조사한 소프트웨어 및 IT 리더들은 다음을 멀티 클라우드의 주요 과제로 꼽았습니다:

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

멀티 클라우드 환경에서 마이크로서비스용 API를 관리하는 일은 특히 복잡합니다. 종합적인 API 전략이 마련되어 있지 않으면 API가 퍼블릭 클라우드, 온프레미스 및 엣지 환경 전반에서 플랫폼 운영 팀이 보안을 유지하고 관리할 수 있는 속도보다 더 빠르게 확산됩니다. 이러한 문제를 API 스프롤이라고 하며, 이전 게시물에서 이것이 왜 그토록 심각한 위협인지 설명했습니다.

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

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

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

API Connectivity Manager는 API를 배포, 관리 및 보호하기 위한 클라우드 네이티브 런타임 독립형 솔루션입니다. 단일 통합 화면에서 퍼블릭 클라우드, 온프레미스 및 엣지 환경에 배포된 NGINX Plus API 게이트웨이와 개발자 포털의 모든 API 운영을 관리할 수 있습니다. 이를 통해 플랫폼 운영 팀은 API 트래픽을 완벽하게 파악하고 모든 환경에 일관된 거버넌스 및 보안 정책을 손쉽게 적용할 수 있습니다.

멀티 클라우드 배포 환경에서 API 게이트웨이의 고가용성 지원

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

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

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

• API Connectivity Manager 설치 및 구성
• NGINX Plus 인스턴스를 API 게이트웨이로 배포
• 인프라 워크스페이스 설정
• 환경 및 API 게이트웨이 클러스터 만들기
• 글로벌 정책 적용

API Connectivity Manager 설치 및 구성

1. Instance Manager와 API Connectivity Manager뿐만 아니라 API 게이트웨이로 사용되는 NGINX Plus와 API 보안을 위한 NGINX App Protect가 포함된 NGINX Management Suite의 평가판 또는 유료 구독을 신청하세요. NGINX Management Suite의 30일 무료 평가판을 시작해 보세요.
2. Install NGINX Management Suite를 설치합니다. Management Suite 모듈 설치 섹션에서 API Connectivity Manager(및 선택적으로 다른 모듈)에 대한 지침을 따르세요.
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:

load_module modules/ngx_http_js_module.so;load_module modules/ngx_stream_js_module.so;

1. 예를 들어 다음 명령을 실행하여 NGINX Plus를 다시 시작합니다:

$ nginx -s reload

인프라 워크스페이스 설정

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

API Connectivity Manager GUI에서 새 Workspace를 생성합니다:

1. 왼쪽 탐색 열에서 Infrastructure를 클릭합니다.
2. Click the + 만들기 버튼을 클릭하여 그림 2와 같이 새 워크스페이스를 만듭니다.
   
   그림 2: 새 인프라 워크스페이스 만들기
3. 열리는 워크스페이스 만들기 패널에서 이름 필드에 값을 입력합니다(그림 3에서는 demo). 필요에 따라 설명 필드와 워크스페이스 연락처 정보 섹션의 필드도 입력합니다. 인프라 관리자(예: 플랫폼 운영팀)는 연락처 정보를 사용하여 워크스페이스 사용자에게 상태 또는 문제에 관한 업데이트를 제공할 수 있습니다.
   
   그림 3: 새 인프라 워크스페이스 이름 지정 및 연락처 정보 추가
4. Click the 만들기 버튼을 클릭합니다.

환경 및 API 게이트웨이 클러스터 만들기

API Connectivity Manager에서 환경(Environment)은 전용 리소스(예: API 게이트웨이 또는 API 개발자 포털)를 논리적으로 그룹화한 것입니다. 워크스페이스당 여러 환경을 만들 수 있으며(이 글을 작성하는 시점에는 최대 25개), 일반적으로 코딩, 테스트, 프로덕션과 같은 앱 개발 및 배포의 여러 단계에 대응하지만 원하는 어떤 용도로든 사용할 수 있습니다.

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

API 게이트웨이의 액티브-액티브 고가용성을 위해 API Connectivity Manager에서 환경을 구성하는 방법은 두 가지입니다:

• 하나의 API 게이트웨이 클러스터 사용
• 여러 API Gateway 클러스터 사용

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

In NGINX Plus 인스턴스를 API 게이트웨이로 배포에서는 NGINX Plus 인스턴스 두 개를 배포했습니다. 하나는 AWS에, 다른 하나는 GCP에 배포했습니다. 이 튜토리얼에서는 동일한 인스턴스를 사용하여 두 가지 환경 유형(단일 API 게이트웨이 클러스터를 사용하는 환경과 여러 API 게이트웨이 클러스터를 사용하는 환경)을 모두 설명합니다. 두 환경 유형을 하나의 워크스페이스에 배포하려면 두 번째 환경을 위한 NGINX Plus 인스턴스를 추가로 생성해야 합니다.

하나의 API 게이트웨이 클러스터로 환경 배포

API 게이트웨이 클러스터가 하나인 환경에서는 그림 4와 같이 모든 NGINX Plus API 게이트웨이 인스턴스에 동일한 보안 정책이 적용됩니다.

환경 및 API 게이트웨이 클러스터 만들기

1. 워크스페이스로 이동하여 환경 만들기 버튼을 클릭합니다(그림 5 참조).
   
   그림 5: 인프라 워크스페이스에서 새 환경 만들기
2. 열리는 환경 생성 패널에서 이름 필드(그림 6에서는 prod)와 선택적으로 설명 필드를 입력한 다음 환경 유형을 선택합니다(여기서는 프로덕션을 선택합니다).
   
   그림 6: 새 환경의 이름 지정 및 API 게이트웨이 클러스터 할당
3. In the API Gateway Clusters 섹션에서 Name 및 Hostname 필드에 값을 입력합니다(그림 6의 api-cluster 및 api.nginx.com).
4. Click the 생성 버튼을 클릭합니다. 그러면 환경 생성 완료 패널이 열리고, 각 NGINX Plus 인스턴스를 API 게이트웨이 클러스터에 할당하기 위해 실행해야 하는 명령이 표시됩니다. 편의를 위해 해당 명령은 아래 7단계에 나와 있습니다.

API 게이트웨이 인스턴스를 API 게이트웨이 클러스터에 할당

각 NGINX Plus 인스턴스에서 다음 단계를 반복합니다:

1. Use ssh를 사용하여 인스턴스에 연결하고 로그인합니다.
2. NGINX Agent가 이미 실행 중인 경우 중지합니다:

$ systemctl stop nginx-agent

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

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

1. 또는

$ 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

1. 이제 NGINX Plus 인스턴스가 인스턴스 섹션에 표시됩니다. 이 섹션은 클러스터 창의 api-cluster에 있으며, 그림 7과 같습니다.
   
   그림 7: 단일 API 게이트웨이 클러스터가 여러 클라우드에 배포된 NGINX Plus 인스턴스를 그룹화
   • 다음에서 mTLS를 사용 설정하지 않았다면 API Connectivity Manager 설치 및 구성, 다음을 추가합니다:
     • The ‑k 플래그를 curl 명령에 추가합니다
     • The --no-check-certificate 플래그를 wget 명령에 사용
   • For <NMS_FQDN>에는 NGINX Management Suite 서버의 IP 주소 또는 정규화된 도메인 이름을 입력합니다.
   • For <cluster_name>에는 API 게이트웨이 클러스터의 이름을 입력합니다(이 튜토리얼에서는 api-cluster 사용).
2. 다음으로 이동합니다: 전역 정책 적용.

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

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

환경 및 API 게이트웨이 클러스터 만들기

1. 워크스페이스로 이동하여 환경 생성 버튼을 클릭합니다(그림 9 참조).
   
   그림 9: 인프라 워크스페이스에서 새 환경 생성
2. 열리는 환경 생성 패널에서 이름 필드(그림 10에서는 prod)와 선택적으로 설명 필드를 입력한 다음 환경 유형을 선택합니다(여기서는 프로덕션을 선택함).
   
   그림 10: 새 환경의 이름을 지정하고 첫 번째 API 게이트웨이 클러스터 할당
3. In the API Gateway Clusters 섹션에서 Name 및 Hostname 필드를 입력합니다(그림 10에서는 각각 aws-cluster와 api.nginx.com입니다).
4. Click the 만들기 버튼을 클릭합니다. 그러면 환경 생성됨 패널이 열리고, 각 NGINX Plus 인스턴스를 API 게이트웨이 클러스터에 할당하기 위해 실행해야 하는 명령이 표시됩니다. 편의를 위해 아래 10단계에 해당 명령을 제시합니다.
5. 다시 환경 탭으로 이동한 다음, 그림 11과 같이  + 추가 버튼을 API 게이트웨이 클러스터 섹션의 오른쪽 상단에서 클릭합니다.
   
   그림 11: 환경에 다른 API 게이트웨이 클러스터 추가
6. On the API 게이트웨이 클러스터 생성 패널에서 이름 필드에 두 번째 클러스터 이름(gcp-cluster(그림 12 참조)을 입력하고, 호스트 이름 필드에는 첫 번째 클러스터와 동일한 호스트 이름(api.nginx.com)을 입력합니다.
   
   그림 12: 환경에 두 번째 API 게이트웨이 클러스터 추가

이제 두 API 게이트웨이 클러스터가 API 게이트웨이 클러스터 페이지의 Prod 환경에 표시됩니다(그림 13 참조).

API 게이트웨이 인스턴스를 API 게이트웨이 클러스터에 할당

각 NGINX Plus 인스턴스에서 다음 단계를 반복합니다:

1. Use ssh를 사용하여 인스턴스에 연결하고 로그인합니다.
2. NGINX Agent가 이미 실행 중인 경우 중지합니다:

$ systemctl stop nginx-agent

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

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

1. 또는

$ 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

1. 이제 해당 NGINX Plus 인스턴스가 인스턴스 섹션의 클러스터 창에서 aws‑cluster(그림 14) 및 gcp‑cluster(그림 15)에 표시됩니다.
   
   그림 14: 여러 클라우드에 걸쳐 있는 환경의 두 API 게이트웨이 클러스터 중 첫 번째 클러스터
   
   그림 15: 여러 클라우드에 걸쳐 있는 환경의 두 API 게이트웨이 클러스터 중 두 번째 클러스터 전역 정책 적용 이제 API 게이트웨이 클러스터의 모든 NGINX Plus 인스턴스에 적용되는 전역 정책을 추가할 수 있습니다. 예를 들어 API에 대한 클라이언트 액세스를 보호하려면 OpenID Connect 신뢰 당사자 또는 TLS 인바운드 정책을 적용할 수 있습니다. API 게이트웨이와 API를 제공하는 백엔드 서비스 간의 연결을 보호하려면 TLS 백엔드 정책을 적용하세요. TLS 정책에 대한 자세한 내용은 API Connectivity Manager 설명서를 참조하세요. 결론 멀티 클라우드 및 하이브리드 아키텍처를 관리하는 일은 결코 쉽지 않습니다. 이러한 환경은 빠르게 변화하는 애플리케이션으로 구성된 복잡한 환경이며, 관찰하고 보호하기 어려운 경우가 많습니다. 하지만 적절한 도구를 사용하면 공급업체 종속을 피하면서도 새로운 기능을 시장에 더 빠르게 제공하는 데 필요한 민첩성과 유연성을 유지할 수 있습니다. 클라우드 네이티브 도구인 NGINX의 API Connectivity Manager는 멀티 클라우드 및 하이브리드 환경에서 API를 관리하는 데 필요한 확장성, 가시성, 거버넌스 및 보안을 제공합니다. NGINX Management Suite 30일 무료 평가판을 시작해 보세요. 여기에는 API Connectivity Manager, API 게이트웨이로 사용되는 NGINX Plus, 그리고 API를 보호하는 NGINX App Protect가 포함됩니다.
   • 다음에서 mTLS를 활성화하지 않았다면 API Connectivity Manager 설치 및 구성 다음을 추가합니다:
     • The ‑k 플래그를 curl 명령에 추가합니다
     • The --no-check-certificate flag to the wget 명령어의 플래그
   • For <NMS_FQDN>에는 NGINX Management Suite 서버의 IP 주소 또는 정규화된 도메인 이름을 입력합니다.
   • For <cluster_name>에는 적절한 API 게이트웨이 클러스터의 이름을 입력합니다(이 튜토리얼에서는 AWS에 배포된 인스턴스의 경우 aws‑cluster, GCP에 배포된 인스턴스의 경우 gcp‑cluster를 입력합니다).

1. 정책을 적용하려는 API Gateway의 클러스터 탭으로 이동합니다(그림 16의 api-cluster). 정책 테이블의 오른쪽 상단에 있는 관리 버튼을 클릭합니다.
   
   그림 16: API Gateway 클러스터의 정책 관리
2. 왼쪽 탐색 열에서 Global Policies를 클릭한 다음, 정책 행의 맨 오른쪽 열에 있는 … 아이콘을 클릭합니다(그림 17의 TLS Backend). 드롭다운 메뉴에서 + Add Policy를 선택합니다.
   
   그림 17: API Gateway 클러스터에 전역 정책 추가

작성자 소개

Akash Ananthanarayanan기술 마케팅 매니저 | F5 NGINX

Akash Ananthanarayanan의 다른 블로그 게시물