하이브리드 및 멀티 클라우드 API 관리: 도전과 선택
February 6, 2023
1. 멀티 클라우드 & 하이브리드 클라우드
마이크로서비스는 조직이 자신의 비즈니스를 이해하고 도메인 주도 설계와 같은 과학적 방법을 사용하여 제품을 개별 마이크로서비스로 분해하는 인기 있는 소프트웨어 아키텍처 방법이 되었습니다. 조직 구조도 마이크로서비스 아키텍처에 맞게 조정되어 Conway의 법칙에 따라 비즈니스의 반복적 개발을 지원합니다.
과거에는 조직이 제품을 배포하기 위해 자체 데이터 센터를 구축했습니다. 이러한 데이터 센터는 임대 또는 구매한 시설에 위치할 수 있으며, 조직은 스위치, 서버, 스토리지, 랙 및 기타 하드웨어와 같은 복잡한 인프라를 관리해야 했습니다. 또한 정전, 랙 온도 상승, 서버 충돌 등으로 인한 문제를 처리해야 했습니다. 이러한 문제를 처리하는 데는 종종 많은 인적 및 재정적 자원이 소모되지만 좋은 결과를 얻지 못하는 경우가 많습니다. 결과적으로 조직의 자체 제품의 SLA(서비스 수준 계약)는 종종 고객에게 약속한 수준을 충족하지 못해 보상이 발생합니다.
클라우드의 부상으로 사람들은 점점 더 자신의 비즈니스를 퍼블릭 클라우드에 배포하는 데 익숙해졌습니다. 퍼블릭 클라우드는 사용자가 하드웨어 인프라의 세부 사항을 추상화할 수 있도록 도와 엔지니어들이 비즈니스 배포, 유지 및 개발에 집중할 수 있게 합니다. 그러나 클라우드가 제공하는 편의성 외에도, 클라우드의 부상과 사용은 사용자에게 다른 문제를 가져옵니다:
- 잠금(Lock-in): 클라우드 제공업체의 제품이 비즈니스에 깊이 통합되면, 비즈니스를 다른 클라우드로 이동하거나 클라우드를 완전히 떠나는 것이 상당히 어려워집니다. 이는 특히 비즈니스와 강력하게 결합된 PaaS 또는 SaaS 제품에서 흔히 발생합니다. 불행히도 이는 종종 비즈니스가 급성장기에 있을 때 결정권자들이 클라우드 제품 사용의 결합 효과를 간과할 때 발생합니다.
- 가용성 문제: 여기서는 다각화 원칙이 적용됩니다. 즉, 모든 계란을 한 바구니에 담지 않는 것입니다. 비즈니스 확장 단계에서 조직은 종종 제품을 빠르게 출시하고 시장 점유율을 확보하는 데 우선순위를 두고 인프라를 소홀히 합니다. 이는 클라우드 지역에서 정전 또는 케이블 절단이 발생할 경우 비즈니스에 부정적인 영향을 미칠 수 있습니다.
결과적으로 사람들은 앞서 언급한 문제를 피하기 위해 여러 퍼블릭 클라우드를 사용하거나 퍼블릭 클라우드 외에도 프라이빗 클라우드를 구축하는 데 점점 더 익숙해지고 있습니다. 이러한 접근 방식은 일반적으로 "멀티 클라우드"와 "하이브리드 클라우드"라고 불립니다.
"멀티 클라우드"는 여러 퍼블릭 클라우드를 동시에 사용하여 비즈니스를 이러한 클라우드에 미러링 또는 이질적으로 배포하는 것을 의미합니다. 가능한 한 표준 서비스를 사용하여(벤더 잠금을 피하기 위해) 멀티 클라우드를 사용하면 한 클라우드가 사용 불가능해져도 비즈니스에 미치는 영향을 최소화할 수 있으며, DNS 해석을 수정하고 백업 클라우드를 활성화하여 비즈니스 연속성을 보장할 수 있습니다.
"하이브리드 클라우드"는 하나 이상의 퍼블릭 클라우드를 사용하는 것 외에도 자체 프라이빗 클라우드(또는 데이터 센터)를 보유한 조직을 의미합니다. 이 시나리오에서는 일부 서비스가 프라이빗 클라우드에 배포될 수 있고, 다른 서비스는 퍼블릭 클라우드에 배포될 수 있습니다. 또는 모든 서비스가 클라우드에 배포되고 프라이빗 클라우드는 관리 및 모니터링을 담당할 수 있습니다. 어느 경우든 "멀티 클라우드" 또는 "하이브리드 클라우드" 모델을 채택한 후 소프트웨어 배포의 유연성과 가용성이 크게 향상됩니다.
그러나 "멀티 클라우드"와 "하이브리드 클라우드" 전략을 구현하면 클라우드 기반 마이크로서비스 관리가 더 복잡해질 수 있습니다. 일반적인 문제 중 하나는 API 관리입니다. 많은 마이크로서비스가 통신을 위해 API에 의존하기 때문입니다. 따라서 마이크로서비스를 배포할 때 외부와의 연결을 허용하고 서비스를 제공하기 위해 API를 외부에 노출해야 합니다.
2. 멀티 클라우드 & 하이브리드 클라우드 시나리오에서의 API 관리 필요성
우리가 알고 있듯이, 좋은 API 게이트웨이는 마이크로서비스 API를 관리하는 데 중요합니다. API 게이트웨이는 마이크로서비스 API를 안전하고 효율적으로 노출할 수 있게 합니다. 그러나 "멀티 클라우드"와 "하이브리드 클라우드" 전략을 구현할 때 API 게이트웨이의 필요성은 기본 기능을 넘어섭니다. 특히 다음과 같은 고려 사항이 있습니다:
다중 클러스터 관리 지원 여부
앞서 언급했듯이, "멀티 클라우드" 또는 "하이브리드 클라우드" 전략을 구현할 때 각 클라우드 또는 프라이빗 데이터 센터에 배포된 서비스는 크게 다를 수 있습니다. 결과적으로 사용자는 각 클라우드에 별도의 API 게이트웨이 클러스터를 다른 구성, 인증서 및 API 키로 배포해야 할 수 있습니다. 선택한 게이트웨이가 다중 클러스터 관리를 지원하지 않는다면, 특히 비즈니스 확장 기간 동안 게이트웨이 클러스터의 수와 규모가 증가할 때 API 관리에 상당한 어려움을 초래할 수 있습니다.
이러한 경우, 다중 클러스터 관리를 지원하는 API 게이트웨이 제품은 관리자의 관리 비용을 크게 줄일 수 있습니다.
- 사용자는 통합 콘솔을 통해 구성 및 모니터링을 원하는 클러스터를 선택할 수 있습니다. 또한 현재 비즈니스 배포 상황에 따라 게이트웨이 클러스터를 온라인 또는 오프라인으로 전환할 수 있습니다.
- 사용자는 콘솔에서 이러한 모든 API 게이트웨이 클러스터의 실행 상태를 볼 수 있습니다. 일반적인 QPS, 지연 시간, 게이트웨이 클러스터의 CPU 및 메모리 사용량 등이 포함됩니다.
협업 지원 여부
비즈니스의 급속한 발전으로 인해 소수의 API 게이트웨이 관리자가 모든 API 게이트웨이 클러스터를 혼자서 관리하고 유지하는 데 어려움을 겪을 수 있습니다. 동시에, 많은 게이트웨이 구성(예: 경로 추가 및 플러그인 구성)은 개발자가 처리할 수 있으므로 관리자의 광범위한 개입이 필요하지 않습니다. 따라서 "협업"을 지원하는지 여부가 관리에 필수적입니다.
구체적으로, 관리자는 RBAC(역할 기반 액세스 제어) 또는 기타 전략을 사용하여 조직의 다른 구성원을 API 게이트웨이 클러스터 관리에 초대할 수 있습니다. 예를 들어, 관리자에게 Organization Admin(모든 작업 수행 가능) 역할을 설정하고 일반 개발자에게 Service Admin(몇 가지 서비스 및 경로만 유지 가능) 역할을 설정할 수 있습니다. 이 접근 방식은 협업을 구현하면서도 작업의 보안을 보장합니다. 또한 직원 이직 또는 직위 변경 시 계정 복구 또는 권한 수정을 신속하게 수행할 수 있습니다.
모든 인프라에서 실행 가능 여부
컨테이너화 및 컨테이너 오케스트레이션 기술이 성숙함에 따라 많은 마이크로서비스가 가상 머신에서 Kubernetes로 이동하고 있습니다. 이는 사용자가 Kubernetes, 전통적인 가상 머신 또는 심지어 프라이빗 데이터 센터와 같은 물리적 머신을 사용할 수 있음을 의미합니다. 사용자가 선택한 API 게이트웨이 제품이 기능이 풍부하고 비즈니스 요구를 충족하지만 기본 인프라에 의해 제한되거나 성숙한 설치 도구가 부족한 경우, 사용자에게는 이를 사용하지 않거나 특정 인프라에서 실행할 수 있도록 추가 개발을 수행해야 하는 도전이 될 수 있습니다. 어느 쪽이든 이는 추가 사용 비용을 초래할 것입니다.
3. 결정
앞서 논의한 바와 같이, "멀티 클라우드" 및 "하이브리드 클라우드" 시나리오에서 적절한 API 게이트웨이를 선택하는 것은 매우 중요합니다. 일반적인 옵션들이 나열되어 있으며, 사용자는 실제 시나리오와 미래 계획에 따라 이를 분석해야 합니다.
다른 클라우드에서의 다른 솔루션
일반적으로 각 퍼블릭 클라우드 제공업체는 자체 내장된 API 게이트웨이 솔루션을 제공하며, 사용자는 각 클라우드에 대한 API 게이트웨이 솔루션을 구매할 수 있습니다.
장점은 다음과 같습니다:
- 사용 비용이 매우 낮으며, 배포 또는 유지보수가 필요하지 않습니다.
- 일반적으로 종량제를 지원하며, 초기 사용 시 최소 비용만 필요할 수 있습니다.
단점은 다음과 같습니다:
- 다른 클라우드의 API 게이트웨이 사용은 종종 서로 호환되지 않으므로 동일한 구성을 완료하려면 다른 경로가 필요합니다.
- 제품 기능은 제공업체 간에 대칭적이지 않습니다. 예를 들어, 한 제공업체는 mTLS를 지원하지만 다른 제공업체는 지원하지 않을 수 있습니다.
- "하이브리드 클라우드" 시나리오에서는 다른 오픈소스 또는 상용 API 게이트웨이를 선택하고 사용자의 프라이빗 클라우드에 배포해야 할 수 있습니다.
이 접근 방식을 사용할 때, 다른 클라우드 제공업체 간에 일관된 사용자 경험을 달성하려면 제품 사용자 정의, 구성 동기화 도구 개발 및 기본 세부 사항 추상화가 필요할 수 있습니다. 이는 사용자의 추가 연구, 분석 및 개발을 필요로 할 수 있습니다. 사용자는 호환성 문제와 제한된 기능을 겪을 수 있으며, API 게이트웨이 제품의 몇 가지 공통 기능만 사용할 수 있습니다. 또한 동기화 실패 가능성도 고려해야 합니다.
물론, 사용자는 각 클라우드의 각 API 게이트웨이 구성을 수동으로 반복할 수도 있습니다(이를 감수할 수 있다면).
오픈소스 API 게이트웨이 솔루션
다른 클라우드에서 다른 솔루션을 사용하는 대신, 사용자는 Apache APISIX, Kong, Tyk, Traefik 등과 같은 오픈소스 API 게이트웨이 솔루션을 사용할 수 있습니다. 이 접근 방식은 사용자가 모든 클라우드(프라이빗 데이터 센터 포함)에서 동일한 API 게이트웨이를 사용할 수 있게 하여 다른 솔루션 간의 호환성 문제를 피할 수 있습니다. 성숙하고 강력한 오픈소스 API 게이트웨이는 사용자가 다양한 시나리오에서 많은 문제를 해결하는 데 도움을 줄 수 있습니다. 모든 시나리오를 커버하지 못하더라도, 이러한 API 게이트웨이는 일반적으로 사용자가 다양한 방식으로 확장할 수 있도록 허용합니다. 예를 들어, Apache APISIX는 사용자가 Go, Java, Python, Lua, WASM 등의 언어와 기술을 사용하여 확장할 수 있도록 합니다.
그러나 이러한 오픈소스 API 게이트웨이는 일반적으로 Open Core 오픈소스 전략을 채택합니다. 제품의 핵심 기능은 오픈소스이지만, 시각화된 콘솔, 다중 클러스터 관리, 감사, SSO(싱글 사인온) 등과 같은 엔터프라이즈 수준의 관리 기능은 종종 유료입니다(상용 제품에 통합됨). 사용자가 이를 지불하고 싶지 않다면, 이러한 API 게이트웨이를 관리하기 위해 자체 관리 플랫폼(게이트웨이의 컨트롤 플레인)을 개발해야 하며, 이는 사용자가 이 개발 작업을 담당할 전임 엔지니어를 고용해야 함을 의미합니다.
엔터프라이즈 수준 API 게이트웨이 SaaS 서비스 구매
오픈소스 API 게이트웨이가 기능적으로 요구 사항을 충족하지만 자체 연구 비용이 받아들일 수 없는 경우, 사용자는 이러한 오픈소스 소프트웨어의 원래 제조업체(예: Apache APISIX의 API7.ai, Kong의 Kong Inc, Tyk의 Tyk Inc 등)에 연락할 수도 있습니다. 이러한 제조업체는 종종 다양한 엔터프라이즈 수준 API 게이트웨이 제품 및 지원 서비스를 제공합니다. 특히 "멀티 클라우드" 및 "하이브리드 클라우드" 시나리오에서 이러한 제조업체는 SaaS 제품을 출시했습니다. API 게이트웨이의 SaaS 제품은 종종 관리 측면에 초점을 맞추며, API 게이트웨이 인스턴스가 배포된 위치에 대해 걱정할 필요 없이 즉시 사용 가능한 콘솔을 제공합니다(물론 일부 SaaS 서비스는 API 게이트웨이 인스턴스를 호스팅하는 것도 지원하지만, 이는 종종 API 프록시 시 지연과 같은 다른 문제를 초래할 수 있습니다).
SaaS 서비스는 일반적으로 각 테넌트에게 프라이빗 게이트웨이 컨트롤 패널을 제공하며, mTLS와 같은 전략을 사용하여 사용자 배포(또는 SaaS 호스팅) 게이트웨이 인스턴스에 연결하여 데이터 보안 및 개인 정보 보호를 보장하고 관리 기능을 제공합니다. SaaS 서비스를 구매하는 데 투자가 필요할 수 있지만, 전임 엔지니어를 고용하여 API 게이트웨이 및 컨트롤 패널을 유지하는 것보다 비용 효율적일 수 있습니다.
물론, SaaS 서비스를 구매할 때는 주의가 필요합니다. 따라서 주문을 확인하기 전에 사용자는 다음 측면에서 SaaS 서비스를 평가해야 합니다:
- 이 SaaS 서비스가 현재 및 미래의 사용 요구를 충족할 수 있는가?
- SaaS 서비스 제공업체가 전문적이고 신뢰할 수 있는가? 어떤 사용 사례가 있는가?
- 이 SaaS 서비스가 GDPR을 준수하고 SOC2 감사 보고서가 있는가?
- 이 SaaS 서비스에 명확한 SLA 조건이 있는가?
- 이 SaaS 서비스는 어떻게 요금이 부과되는가? 사용자가 1년 또는 몇 년 동안의 미래 지출을 추정할 수 있는가?
완전 자체 개발
오픈소스 API 게이트웨이 솔루션이 사용자의 실제 요구를 충족하지 못하는 경우, 사용자는 자체 전용 API 게이트웨이 제품을 개발하는 것을 고려할 수 있습니다. 이는 시간과 자원이 많이 소모되며, 게이트웨이의 안정성도 주요 문제입니다. API 게이트웨이를 개발하는 것은 관계형 데이터베이스 또는 브라우저를 구현하는 것만큼 어렵지는 않지만, 하룻밤 사이에 할 수 있는 일이 아니므로 자체 개발은 "최악의 전략"으로 간주될 수 있습니다. 결과적으로 이는 종종 최후의 수단으로만 고려됩니다.
4. 결론
클라우드 네이티브 환경에서 "멀티 클라우드" 및 "하이브리드 클라우드" 시나리오에서 API를 관리하는 것은 이러한 전략을 채택하기 전에도 모든 조직에게 도전이 될 것입니다. 따라서 이 글은 다양한 옵션을 제시하지만, 모든 상황에 적합한 단일 솔루션이 없으며 사용자는 특정 비즈니스 요구 및 개발 목표에 가장 적합한 옵션을 선택해야 한다는 점을 명심해야 합니다.