멀티 클라우드 배포는 앞으로도 계속될 것입니다. F5의 2022년 애플리케이션 전략 현황 보고서에 따르면, 기업의 77%가 여러 클라우드에서 애플리케이션을 운영하고 있습니다. 멀티 클라우드와 하이브리드 아키텍처를 도입하면 효율성 향상, 중단 위험 감소, 공급업체 종속성 회피 등 중요한 이점을 얻을 수 있습니다. 하지만 이러한 복잡한 아키텍처는 고유한 과제도 안고 있습니다.
F5가 조사한 소프트웨어 및 IT 리더들은 다음을 최대 멀티 클라우드 과제로 꼽았습니다.
특히 멀티 클라우드 환경에서 마이크로서비스를 위한 API를 관리하는 것은 복잡합니다. 전체적인 API 전략이 없으면 API는 Platform Ops 팀이 보호하고 관리할 수 있는 속도보다 더 빠르게 퍼블릭 클라우드, 온프레미스, 에지 환경 전반으로 확산됩니다. 우리는 이 문제를 API 확산 이라고 부르며, 이전 게시물 에서는 이것이 왜 그토록 심각한 위협인지 설명했습니다.
여러 클라우드에 분산된 마이크로서비스를 통합하는 신중한 접근 방식을 구현하여 엔드투엔드 연결을 보장하려면 멀티 클라우드 API 전략이 필요합니다. 멀티 클라우드 및 하이브리드 배포의 일반적인 시나리오 두 가지는 다음과 같습니다.
다음 튜토리얼에서는 두 번째 시나리오인 고가용성을 위해 여러 환경에 동일한 서비스를 배포하는 경우 F5 NGINX Management Suite 의 일부인 API Connectivity Manager를 사용하는 방법을 단계별로 보여줍니다. 이를 통해 멀티 클라우드 또는 하이브리드 프로덕션 환경에서 단일 장애 지점이 제거됩니다. 게이트웨이 인스턴스 하나가 실패하면 다른 게이트웨이 인스턴스가 작동을 이어받으므로 한 클라우드가 중단되더라도 고객은 중단을 경험하지 않습니다.
API Connectivity Manager는 API를 배포, 관리 및 보호하기 위한 클라우드 기반, 런타임에 독립적인 솔루션입니다. 단일 창에서 퍼블릭 클라우드, 온프레미스 및 엣지 환경에 배포된 NGINX Plus API 게이트웨이와 개발자 포털에 대한 모든 API 작업을 관리할 수 있습니다. 이를 통해 플랫폼 운영 팀은 API 트래픽에 대한 완전한 가시성을 확보하고 모든 환경에 일관된 거버넌스 및 보안 정책을 쉽게 적용할 수 있습니다.
소개에서 언급한 대로 이 튜토리얼에서는 여러 배포 환경에서 실행되는 서비스의 고가용성을 위해 API Connectivity Manager를 구성합니다. 구체적으로, NGINX Plus를 API 게이트웨이로 배포하여 두 서비스인 서비스 A 와 서비스 B 로 트래픽을 라우팅합니다. 이 두 서비스는 두 개의 퍼블릭 클라우드인 Google Cloud Platform(GCP)과 Amazon Web Services(AWS)에서 실행됩니다. (설정은 Microsoft Azure와 온프레미스 데이터 센터를 포함한 모든 배포 환경에 동일하게 적용됩니다.)
그림 1은 튜토리얼에서 사용된 토폴로지를 보여줍니다.
튜토리얼을 완료하려면 다음 섹션의 단계를 따르세요.
멀티 클라우드 또는 하이브리드 인프라를 구성하는 환경을 선택하세요. 이 튜토리얼에서는 AWS와 GCP를 선택하고 각 클라우드에 하나의 NGINX Plus 인스턴스를 설치합니다. 각 환경에서 API 게이트웨이 역할을 할 각 데이터 평면 호스트에서 다음 단계를 수행합니다.
/etc/nginx/nginx.conf 의 기본(최상위) 컨텍스트에 다음 지침을 추가합니다.
로드_모듈 모듈/ngx_http_js_module.so; 로드_모듈 모듈/ngx_stream_js_module.so;
예를 들어 다음 명령을 실행하여 NGINX Plus를 다시 시작합니다.
$ nginx -s 다시 로드
API Connectivity Manager에서 여러 개의 Infrastructure Workspace(이 글을 쓰는 시점에는 최대 10개)를 만들 수 있습니다. 분리된 작업 공간을 사용하면 다양한 사업부, 개발자 팀, 외부 파트너, 클라우드 등에 맞게 정책과 인증/권한 부여 요구 사항을 적용할 수 있습니다.
API Connectivity Manager GUI에서 작업하여 새 작업 공간을 만듭니다.
그림 2와 같이 + 만들기 버튼을 클릭하여 새 작업 공간을 만듭니다.
열리는 작업 공간 만들기 패널에서 이름 필드(그림 3의 demo )를 입력합니다. 선택적으로 설명 필드와 작업 공간 연락처 정보 섹션의 필드를 입력합니다. 인프라 관리자(예: 플랫폼 운영 팀)는 연락처 정보를 사용하여 작업 공간 사용자에게 상태나 문제에 대한 업데이트를 제공할 수 있습니다.
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 인스턴스를 만들어야 합니다.
그림 4에서 볼 수 있듯이 하나의 API Gateway 클러스터가 있는 환경의 경우 동일한 보안 정책이 모든 NGINX Plus API Gateway 인스턴스에 적용됩니다.
그림 5와 같이 작업 공간으로 이동하여 환경 만들기 버튼을 클릭합니다.
열리는 환경 만들기 패널에서 이름 필드(그림 6의 prod )와 선택적으로 설명 필드를 입력하고 환경 유형을 선택합니다(여기서는 Prod를 선택했습니다).
만들기 버튼을 클릭하세요.
환경 생성 패널이 열리고 API Gateway 클러스터에 할당하기 위해 각 NGINX Plus 인스턴스에서 실행해야 하는 명령이 표시됩니다. 편의상 아래 7단계 의 명령을 표시하겠습니다.
각 NGINX Plus 인스턴스에서 반복 :
ssh를
사용하여 인스턴스에 연결하고 로그인합니다.NGINX 에이전트가 이미 실행 중이면 중지하세요.
$ systemctl nginx-에이전트 중지
원하는 명령( 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 에 대한 클러스터 창의 인스턴스 섹션에 나타납니다.
여러 API 게이트웨이 클러스터가 있는 환경의 경우 그림 8에서와 같이 서로 다른 NGINX Plus API 게이트웨이 인스턴스에 서로 다른 보안 정책을 적용할 수 있습니다.
그림 9와 같이 작업 공간으로 이동하여 환경 만들기 버튼을 클릭합니다.
열리는 환경 만들기 패널에서 이름 필드(그림 10의 prod )와 선택적으로 설명 필드를 입력하고 환경 유형을 선택합니다(여기서는 Prod를 선택했습니다).
만들기 버튼을 클릭하세요.
환경 생성 패널이 열리고 API Gateway 클러스터에 할당하기 위해 각 NGINX Plus 인스턴스에서 실행해야 하는 명령이 표시됩니다. 편의상 아래 10단계 의 명령을 표시하겠습니다.
그림 11과 같이 환경 탭으로 돌아가서 API Gateway 클러스터 섹션의 오른쪽 상단 모서리에 있는 + 추가 버튼을 클릭합니다.
API Gateway 클러스터 생성 패널에서 이름 필드에 두 번째 클러스터 이름(그림 12의 gcp-cluster )을 입력하고 호스트 이름 필드에 첫 번째 클러스터와 동일한 호스트 이름( api.nginx.com )을 입력합니다.
그림 13과 같이 두 개의 API 게이트웨이 클러스터가 이제 Prod 환경의 API 게이트웨이 클러스터 에 나타납니다.
각 NGINX Plus 인스턴스에서 반복 :
ssh를
사용하여 인스턴스에 연결하고 로그인합니다.NGINX 에이전트가 이미 실행 중이면 중지하세요.
$ systemctl nginx-에이전트 중지
원하는 명령( 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)에 대한 클러스터 창의 인스턴스 섹션에 나타납니다.
이제 API Gateway 클러스터의 모든 NGINX Plus 인스턴스에 적용되는 글로벌 정책을 추가할 수 있습니다. 예를 들어, API에 대한 클라이언트 액세스를 보호하려면 OpenID Connect 신뢰 당사자 또는 TLS 인바운드 정책을 적용할 수 있습니다. API 게이트웨이와 API를 노출하는 백엔드 서비스 간의 연결을 보호하려면 TLS 백엔드 정책을 적용합니다. TLS 정책에 대한 자세한 내용은 API Connectivity Manager 설명서를 참조하세요.
정책을 적용하려는 API Gateway의 클러스터 탭으로 이동합니다(그림 16의 api-cluster ). 정책 표의 오른쪽 위에 있는 관리 버튼을 클릭합니다.
왼쪽 탐색 열에서 글로벌 정책을 클릭한 다음 정책 행의 가장 오른쪽 열에 있는 ... 아이콘을 클릭합니다(그림 17의 TLS 백엔드 ). 드롭다운 메뉴에서 + 정책 추가를 선택합니다.
멀티 클라우드와 하이브리드 아키텍처를 관리하는 것은 쉬운 일이 아닙니다. 이러한 환경은 빠르게 변화하는 애플리케이션을 갖춘 복잡한 환경으로, 관찰하고 보호하기 어려운 경우가 많습니다.
하지만 적절한 도구를 사용하면 공급업체에 대한 종속성을 피하는 동시에 새로운 기능을 더 빠르게 시장에 출시하는 데 필요한 민첩성과 유연성을 유지할 수 있습니다. 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 콘텐츠로 리디렉션됩니다."