[Tech Report] 멀티 클라우드 환경에서 진화하는 애플리케이션 연결성

[레드햇=사트아 자얀티(Satya Jayanti), 조 오라일리(Joe O'Reilly), 빌긴 이브라얌(Bilgin Ibryam)] 하이브리드 클라우드 환경과 클라우드 네이티브 애플리케이션이 진화를 거듭함에 따라 애플리케이션 연결성에 대한 요구 사항도 함께 진화하고 있다. 요구되는 환경 전반에 걸친 추상화 및 관찰 가능성 제공을 위해선 통합 솔루션이 필요하다. 이를 통해 네트워크 문제와 애플리케이션 연결성 문제를 해결할 수 있다.

◆ 하이브리드 클라우드 연결성의 진화
하이브리드 클라우드는 단일 쿠버네티스 클러스터 또는 단일 클라우드 공급자·호스트를 넘어 다른 영역으로 확장되고 있다. 다양한 분산도 가능하다. 예를 들어 ▲여러 클라우드 공급자 ▲다양한 클러스터 ▲온프레미스 가상 머신(VM) ▲베어메탈 호스트 또는 SaaS 서비스에 애플리케이션을 분산시킬 수 있다.

따라서 클러스터를 영구적인 애플리케이션 경계로 사용해 애플리케이션 ID를 클러스터에 바인딩하는 방법에 의존하면 조직이 멀티 클러스터 및 멀티 클라우드 하이브리드 배포의 이점을 누리기 어려울 수 있다.

하이브리드 클라우드 애플리케이션 연결성 요구를 해결하고, 멀티 클러스터 애플리케이션 배포 토폴로지의 이점을 수용하려면 차세대 연결성 솔루션이 필요하다. 이를 통해 기존 애플리케이션 액세스 제어 및 네트워킹 규칙 조정을 통해 서비스 종속성을 해결해야 한다. 또한 감사 가능성과 관찰 가능성을 유지(preserving auditability and observability)하는 동시에 다수의 클라우드 환경과 클러스터에서 이동 중인 애플리케이션에 원활한 연결성을 제공해야 한다. 

개발자가 애플리케이션 실행 위치를 추상화하고, 애플리케이션을 열어 클러스터 전반에 걸친 투명한 이동과 복제 및 장애 조치를 시행할 수 있게 하려면 쿠버네티스 클러스터를 넘어서는 통합 아키텍처를 제공 솔루션이 필요하다.이는 애플리케이션 연결성 요구의 주요 유형이다.

또한 이 아키텍처는 전 세계 네트워킹을 지원하고, 쿠버네티스 클러스터 간에 쿠버네티스 내에서는 물론이며 서비스, 데이터 및 컨트롤 플레인 간에 트래픽의 흐름을 지원해야 한다. 이 외에 권한 부여·인증·속도 제한·트래픽 관리·관찰 가능성·원격 측정 등의 애플리케이션 및 비즈니스 계층 연결성 문제도 하이브리드 클라우드 환경에서 원활하게 해결해야 한다. 

쿠버네티스에서 실행되고 외부에서 액세스가 가능한 모든 애플리케이션에서는 일종의 인그레스(Ingress) 솔루션이 필요하지만, 인그레스 자체는 핵심 쿠버네티스에 포함돼 있지 않다. 그래서 공급자마다 구현하는 기술과 기능 측면의 솔루션이 다를 수 있다. 애플리케이션이 여러 개의 쿠버네티스 클러스터에 분산돼야 하는 경우에는 단일 클러스터 인그레스를 넘어 해당 클러스터로 트래픽을 라우팅할 수 있는 전역적 인그레스 로드 밸런싱 솔루션(Global Ingress load-balancing solution)을 사용해야 한다. 

각 연결성 영역과 관련해 오늘날 개발자들이 직면한 구체적인 하이브리드 클라우드 사용 사례는 ▲클러스터 간 애플리케이션 이동 ▲투명한 애플리케이션 종속성(Transparent Application Dependencies) ▲클러스터 전반에 걸친 애플리케이션 트래픽을 로드 밸런싱하는 것이 있다. 

먼저, 클러스터 간 애플리케이션 이동은 관리자가 환경 마이그레이션의 일환으로 자신의 애플리케이션을 다른 클러스터로 옮긴 후 이 애플리케이션이 다른 클러스터에 배포하는 상황이다. 관리자가 새 역할과 네임스페이스를 이전 클러스터와 유사하게 설정한다고 가정한다. 소비자에게 제공한 URL 엔드포인트를 변경하지 않은 상태로 소비자에 연결 실패·HTTP 오류·일시 정지 또는 시간 초과 등의 중단 상황을 주지않는 상태로 트래픽을 새로 배포한 애플리케이션으로 자동으로 라우팅할 수 있는 쉬운 방법이 필요하다. 이를 위해서 라우팅과 더불어 자신이 구성한 인증 확인, 속도 제한 규칙 및 기타 정책도 새 쿠버네티스 클러스터의 애플리케이션에 자동으로 적용돼야 한다.

투명한 애플리케이션 종속성의 경우, 자신의 애플리케이션이 다른 클러스터에 재배포되는 동안 이 애플리케이션에서 이용하는 서비스는 이전 클러스터에 그대로 남아 있을 경우의 고려사항이다. 이 애플리케이션은 나머지 부분이 다른 클러스터에 있는 경우에도 쿠버네티스 서비스 참조를 통해 이러한 종속성에 계속 액세스해야 한다. 애플리케이션 사용자는 중단이나 오류를 복구할 여력이 없으므로 연결성이 자동으로 조정돼야 한다. 이를 해결하기 위해서 서비스 전반에서 서비스 메시를 사용 중인 마이크로서비스 애플리케이션이 중앙 집중식 컨트롤 플레인을 통해 멀티 클러스터 서비스 메시 구성을 암묵적으로 지원해야 한다.

마지막으로, 러스터 전반에 걸친 애플리케이션 트래픽을 로드 밸런싱할 때다. 사용자는 복원력을 위해 중요 애플리케이션의 몇몇 인스턴스를 멀티 클러스터 환경에서 실행한다. 또, 여러 개의 URL과 액세스 규칙을 설정하거나 외부 DNS 서비스 또는 로드 밸런서를 사용할 필요 없이 애플리케이션의 모든 인스턴스에서 트래픽 및 로드 밸런싱을 제어할 수 있도록 단일 URL과 전역 게이트웨이 규칙을 사용하려고 한다. 또한 인그레스 및 이그레스 트래픽 모두에 대한 권한 부여 및 속도 제한을 배포된 클러스터에 관계없이 애플리케이션의 모든 인스턴스에 전역적으로 적용하고자 한다.

◆ 애플리케이션 연결성에 대한 고려 사항
컨트롤 플레인 통합 사례
현재 기술들은 이러한 문제를 해결할 접근 방식을 제공하고 있다. 다만 아직 넘어야 할 장벽이 남아 있으며, 개발자가 여러 클라우드 및 클러스터의 컨트롤 플레인과 데이터 플레인의 구성을 이해 및 관리해야 하는 경우가 많다. 애플리케이션 개발자와 관리자의 관점에서, 멀티 클라우드·멀티 클러스터 환경에서 애플리케이션의 배포 및 연결성 문제 처리를 위해 해결할 몇 가지 문제가 있다.

먼저, 개별 클러스터를 타깃으로 하는 개발자 워크플로가 필요하다. 클러스터, 멀티 클러스터, 로컬 개발 또는 클라우드 API 간에 공유되는 추상화 계층이 없기 때문에 현재는 각 클러스터나 클라우드 공급자에게 단발성 접근 방식이 적용되고 있다. 멀티 클라우드 연결성을 위한 표준 API의 부재도 있다. 관리자는 서로 다른 컨트롤 플레인에서 서로 다른 API를 사용해 각 클라우드 공급자와 각 클러스터를 위한 정책을 개별적으로 설정해야 한다.

클라우드 서비스와 클러스터 간 마이그레이션도 중요하다. 애플리케이션을 다른 클러스터나 클라우드 서비스로 이동시키려면 마이그레이션이 필요하다. 클라우드 공급업체마다 서로 다른 API와 네트워크 액세스 설정을 가지고 있기 때문에 다른 클라우드 서비스에 적용하기 위해서는 별도의 워크플로나 마이그레이션 방식이 필요할 수도 있다. 또한 이것은 전역적 정책 관리를 필요로 한다. 애플리케이션과 종속성이 여러 환경에 분산돼 있더라도 권한 부여, 속도 제한, 상호 신뢰 및 서비스 연결성 같은 애플리케이션 수준 정책을 전역적으로 구성할 수 있는 기능이 필요하다.

따라서 공급업체 종속성을 방지하고 애플리케이션의 복원력을 높이는 데 멀티 클라우드 배포를 주로 이용하는 환경에서는 주의가 필요하다. 배포 파이프라인이나 개발 워크플로를 통해 이러한 문제를 해결하는 것이 바람직한 솔루션은 아니기 때문이다.

애플리케이션 및 비즈니스 수준의 문제에 대해서는 API 게이트웨이나 서비스 메시 인그레스 게이트웨이(Service Mesh Ingress gateways)를 사용하면서 네트워크 수준의 문제는 엣지 게이트웨이와 쿠버네티스 인그레스를 통해 처리해야 한다. 문제는 이로 인해 관리자가 트래픽과 액세스를 안전하게 시각화하고 격리하기가 더 어려워졌고, 개발자가 애플리케이션 연결성을 직접 관리하는 것 역시 까다로워졌다. 

애플리케이션 개발자의 관리 작업을 위해서는 원활하거나 일관된 클라우드, 멀티 클러스터, 그리고 단일 클러스터 사용이 관건이다. 서로 다른 클라우드 공급자가 제공하는 여러 개의 클러스터를 처리하는 데 따른 복잡성을 추상화하기 위해 컨트롤 플레인을 한 단계 업그레이드하면 전반적인 흐름을 대폭 간소화할 수 있다. 이 컨트롤 플레인은 배포 플랫폼의 물리적 토폴로지가 아닌 조직 구조에 맞춰 중앙에서 정책을 수립하고 경계를 적용할 수 있다.

개발자 및 관리자 경험을 변경하지 않는 것이 바람직하다. 클러스터를 교체 가능한 일회용 기능으로 취급하는 것이 각각의 개별 클러스터를 필수불가결하고 대체 불가능한 것으로 취급하는 것보다 나은 선택이다. 쿠버네티스 클러스터를 위한 API 및 컨트롤 플레인을 재설계하는 대신, API를 중간 수준에서 적용하고 개별 클러스터에 전파하면 클러스터 관리에 투명성을 제공하면서도 기존 워크플로와 API를 보다 쉽게 유지할 수 있기 때문이다.

예를 들어, 개발자가 단 한 번만 서비스를 정의하면 이러한 서비스가 로컬에서 실행되고, 전역에서 확장되며, 어디에나 도달 가능해진다. 변경이나 중단 없이 데이터 센터에서 클라우드 또는 엣지 환경으로 서비스를 이동시킬 수 있다. 

또한 관리자는 동일한 코드를 사용해 똑같은 방식으로 클러스터, 클라우드 환경 또는 클러스터 세트에 새로운 기능을 추가할 수 있다. 관리자는 조직의 데이터를 통합하고, 여러 클라우드에서 복원이 가능하도록 만들며, 데이터의 위치에 관계없이 보안 정책과 감사를 정의할 수 있다. 모든 워크로드에는 보안 정책이 적용되며, 실행 위치에 관계없이 식별과 감시가 가능하다.

데이터 플레인 인그레스 및 정책
인그레스·라우팅·신원 및 접근 관리(Identity and Access Management, IAM)의 '차기 업그레이드 버전'을 실행하는 것은 고객이 끊임없이 해결해야 할 과제이다. 이를 위해서는 인그레스, 서비스 메시 및 API 게이트웨이 애플리케이션에서 나오는 여러 개의 API와 프록시가 필요하다.

쿠버네티스 서비스에 대한 일반적인 애플리케이션 연결은 DNS 로드 밸런서, 인그레스·라우팅, 이스티오 엔보이(Istio envoy) 프록시 또는 API 게이트웨이를 통해 라우팅되고, 최종적으로 해당 서비스로 라우팅된다. 각각의 프록시는 처리 계층을 추가하고, 응답 시간을 늘리며, 장애 지점 한 개를 추가해 서비스에 도달한다. 각 프록시 계층마다 권한, 규칙 및 정책이 서로 다르기 때문에 서로 다른 컨트롤 플레인에서 이를 관리 및 설정해야 한다. 

단일 프록시를 통해 이동하는 데이터 플레인 트래픽을 통합하고 표준 방식으로 인그레스, 메시 및 게이트웨이 규칙을 쿠버네티스 클러스터에 적용하면 일관성을 보장하고 성능을 개선할 수 있다. 통합 데이터 플레인은 하이 레벨 쿠버네티스 API 및 확장 기능을 통해 이러한 문제들에 종합적으로 접근할 수 있다.

쿠버네티스 게이트웨이 API는 쿠버네티스 서비스에 대한 연결을 제공하는 리소스 모음 인그레스 개선이 가능하다. 개선되는 것은 ▲쿠버네티스 서비스 네트워킹을 사용 및 구성하는 조직 역할을 모델링하는 역할 기반 ▲헤더 기반 매칭, 트래픽 가중치 등의 핵심 기능을 가진 표현성 ▲맞춤형 리소스가 각종 계층에서 연결되는 확장성 등이 있다. 

관리를 위한 중앙 컨트롤 플레인의 집계 작업에서 언급한대로 게이트웨이용으로 집계된 쿠버네티스 API를 사용하면 단일 API와 클러스터의 단일 적용 지점을 통해 네트워크 및 애플리케이션 계층 연결성 문제를 구성할 수 있다.

미래의 클라우드 연결성은 최종 사용자를 위한 추상화 뒤에 네트워크 세부 정보가 숨겨진 애플리케이션 중심 네트워킹이 될 것이다. 강력한 보안 역량을 제공하고 최신 애플리케이션을 효과적으로 지원하기 위해서는 이러한 네트워킹 기반에서 보다 강력한 보안 제어를 통해 워크로드를 격리해야 한다. 또한 참여자 간 제로 트러스트 모델을 도입해 명시적인 최상위 애플리케이션 및 조직 관계를 바탕으로 이러한 모델을 오케스트레이션(orchestration)해야 한다.

애플리케이션 연결성은 이러한 제로 트러스트 모델을 기반으로 워크로드를 올바르게 격리하면서 동시에 환경 전반에서 개별 애플리케이션으로 보안을 확장한다. 이는 권한 부여, 속도 제한, 서비스 ID, 신뢰할 수 있는 통신 등의 애플리케이션 문제도 해결한다. 단일 구성 컨트롤 플레인과 통합 데이터 플레인 액세스를 제공할 수 있는 게이트웨이는 하이브리드 클라우드 환경에서 애플리케이션 연결성을 달성하기 위해 반드시 고려해야 할 요소이다.

◆ 하이브리드 클러스터 관리
레드햇은 ‘쿠버네티스용 레드햇 어드밴스드 클러스터 매니지먼트(Red Hat Advanced Cluster Management for Kubernetes)’을 통해 지원을 돕는다. 대규모 멀티 클라우드 환경에 분산돼 있는 여러 개의 쿠버네티스 클러스터를 단일 창에서 관리한다. 이를 통해 통합 멀티 클러스터 관리, 거버넌스 및 규정 준수, 애플리케이션 수명 주기 관리 및 관찰 가능성을 환경 전반에서 제공 가능하다.

레드햇 하이브리드 클라우드 콘솔(Hybrid Cloud Console)은 고급 클러스터 관리를 위한 컨트롤 플레인을 제공한다. 쿠버네티스 호환 컨트롤 플레인을 통해 이 기능을 확장하면 투명한 멀티 클러스터와 플릿 와이드(fleet-wide) API를 제공할 수 있다. 단일 제어 계층을 구축하면 모든 기능을 최종 사용자에게 노출해 구현 세부 사항과 환경 전반의 물리적 경계를 추상화할 수 있다. 애플리케이션 연결성 문제도 이와 동일한 방식으로 해결할 수 있다.

애플리케이션 연결성을 위한 하이브리드 게이트웨이
하이브리드 게이트웨이에는 네트워크·서비스 메시·API 게이트웨이 및 전역 인그레스 트래픽이 하나로 결합돼 있다. 게이트웨이는 엣지 또는 네트워크 외부에서 애플리케이션으로의 노스-사우스(north-south) 트래픽을 처리할 뿐만 아니라, 포괄적인 연결성 관리 솔루션을 제공한다.

전역 구성을 통한 애플리케이션 연결성 관리는 관리형 하이브리드 컨트롤 플레인을 사용해 실현할 수 있다. 이러한 구성은 개별 클러스터에 전파될 수 있기 때문에 트래픽 및 애플리케이션 정책을 개별 클러스터의 애플리케이션에 제공해 데이터 플레인에 일관되게 적용할 수 있다. 이러한 접근 방식은 클라우드와 클러스터의 물리적 경계를 숨긴다.

클러스터를 확장하거나 이동시키는 애플리케이션은 서비스 중단 없이 도달이 가능하고 상호 연결돼야 한다. 이는 ▲고객이 필요한 모든 곳에서 애플리케이션을 연결 ▲조직이 여러 수준에서 트래픽·보안 정책을 정의 ▲필요에 따라 클라우드와 온프레미스 환경이 연동 ▲API 관리에 대한 통일된 방식의 온프레미스 로우 레벨 네트워킹을 모두 지원해야 한다.

하이브리드 클라우드 게이트웨이 아키텍처는 크게 데이터 플레인과 하이브리드 컨트롤 플레인 두 가지 요소로 구성돼 있다. 

먼저, 데이터 플레인은 이스티오 및 엔보이 확장성을 통해 게이트웨이 API를 제공하는 온클러스터 구성 요소·에이전트의 형태로 제공된다. 인그레스 트래픽을 클러스터에 통합하고, 트래픽을 클러스터로 어디서나 가져와 클러스터 전반의 앱을 상호 연결한다. 개발자가 필요에 따라 점진적으로 권한 부여·속도 제한·모니터링·API 기능와 같은 고급 서비스 기능을 제공할 수 있는 통일된 방법을 제공함으로써 애플리케이션 중심 네트워킹 문제를 해결한다. 또한 데이터 플레인은 기존 클러스터 및 서비스 메시 구성 요소를 통합, 구성 및 교체해 멀티 클러스터 애플리케이션의 상호 연결 및 전역 속도 제한에 필요한 다른 기능들도 제공한다.

하이브리드 제어 플레인(Hybrid Control Plane, HCP)은 여러 쿠버네티스 클러스터 및 클라우드 환경에 분산돼 있는 쿠버네티스 기반의 애플리케이션 컨트롤 플레인이다. 이는 이동·용량 인식·복원력 등의 고유한 네트워킹 기능을 제공한다. 

이 플랫폼은 컨트롤 플레인을 공유하고 최종 사용자 API가 클러스터에 구애받지 않으며, 단일 클러스터 작업으로 자연스럽게 디그레이드(degrade)가 가능하다. 또한 컨트롤 플레인은 해당 클라우드 또는 비클라우드 인프라를 조정해 직접적으로, 또는 고객 계정 내에서 DNS·로드 밸런싱·네트워크 도달 가능성·VPC 등을 통한 멀티 클러스터 및 프라이빗 상호 연결을 지원한다.

◆ 애플리케이션 연결성 결론
하이브리드 클라우드 환경이 지닌 고유한 문제들로 개발자 경험 재구상이 필요하다. 다만 애플리케이션이 여러 클러스터, 클라우드 환경 및 온프레미스 환경에 분산돼 배포되고, 종속성이 증가함에 따라 연결성 문제 관리가 갈수록 복잡해지고 있다.

게다가 자동 로드 밸런싱, 여러 클라우드 환경에서의 장애 조치, 클러스터 간 종속성 해결, 배포된 애플리케이션에서의 액세스 규칙 관리 등으로 인해 멀티 클러스터 환경에서 투명성을 제공해야 할 필요성이 대두되면서 복잡성이 한층 심화되고 있다.

우리는 하이브리드 클라우드 컴퓨팅 덕분에 애플리케이션의 노스 사우스 트래픽 및 이스트-웨스트(east-west) 트래픽을 넘어서 새로운 애플리케이션 연결성 아키텍처가 정의되고 있다고 생각한다. 이 새로운 접근 방식은 전역 구성 기능과 통합 관리 계층을 통해 쿠버네티스 클러스터 및 클라우드 경계를 추상화한다.

관리자의 우려와 개발자의 우려를 모두 해소하기 위해 추상화 및 중앙 집중식 컨트롤 플레인을 사용하는 등 다양한 접근 방식을 통해 애플리케이션 연결성이라는 문제를 해결할 수 있다.