멀티 클라우드 배포의 5가지 과제와 해결 방법

F5 에코시스템 | 2020년 11월 19일

요즘 기술 블로그를 읽다 보면 멀티 클라우드 아키텍처의 장점을 극찬하는 글을 쉽게 접할 수 있습니다. 그럴 만한 이유가 있습니다. 멀티 클라우드는 비용 절감부터 안정성 향상에 이르기까지 다양한 이점을 제공하기 때문입니다.

하지만 멀티 클라우드 전략에는 여러 과제도 따르며, 특히 애플리케이션 배포와 관련해서는 더욱 그렇습니다. 멀티 클라우드 흐름에 뛰어들기 전에 멀티 클라우드 아키텍처가 배포 전략에 어떤 영향을 미칠지 평가하고, 이러한 문제점에 대응할 준비가 되어 있는지 확인하는 것이 중요합니다.

이 글에서는 멀티 클라우드 환경에서 흔히 발생하는 배포 문제와 이를 완화하기 위한 팁을 살펴봅니다.

과제 1: 프로비저닝

클라우드를 두 개 이상 사용하는 경우, 애플리케이션을 배포하려면 먼저 각 클라우드에 맞는 환경을 프로비저닝해야 합니다.

어느 정도는 코드형 인프라(Infrastructure-as-Code, IaC) 도구를 사용하여 이 프로세스를 간소화할 수 있습니다. 하나의 IaC 템플릿을 사용해 여러 클라우드를 동일한 방식으로 프로비저닝할 수 있습니다.

하지만 이 문제를 해결하는 데 IaC가 제공할 수 있는 도움에는 한계가 있습니다. 특정 클라우드 공급업체가 제공하는 IaC 도구를 사용하면 다른 클라우드와의 호환성이 거의 또는 전혀 없을 수 있습니다. 따라서 클라우드마다 서로 다른 IaC 도구를 사용해야 할 수도 있는데, 이는 IaC의 취지를 어느 정도 퇴색시킵니다. 모든 클라우드에서 작동하는 IaC 도구가 있더라도 각 클라우드에 완전히 동일한 템플릿을 사용할 수는 없으므로 구성을 수동으로 조정해야 할 가능성이 높습니다.

IaC로 멀티 클라우드 프로비저닝 문제를 해결할 수 없는 경우에는 워크로드를 기반 클라우드로부터 완전히 추상화하는 솔루션을 사용하는 것이 더 나은 접근 방식입니다. 그러면 각 클라우드를 개별적으로 프로비저닝할 필요가 없습니다.

과제 2: 애플리케이션 배포

프로비저닝과 마찬가지로 여러 클라우드에 인스턴스를 배포하는 경우, 애플리케이션을 실제로 배포하는 과정이 복잡해질 수 있습니다. 클라우드마다 서로 다른 배포 프로세스가 필요합니다.

사용 중인 각 클라우드에 애플리케이션 인스턴스를 자동으로 배포하기 위해 타사 릴리스 자동화 도구를 사용해 볼 수 있습니다. 이렇게 하면 프로세스가 간소화되지만, IaC 도구의 경우와 마찬가지로 각 클라우드에 완전히 동일한 구성을 사용해 배포할 수는 없으므로 일부 사항을 수동으로 변경해야 할 가능성이 큽니다.

여기서도 워크로드를 이를 호스팅하는 클라우드로부터 추상화하고 여러 클라우드에서 완전히 일관된 배포 프로세스를 제공하는 솔루션은 멀티 클라우드 아키텍처의 배포 문제를 완화하는 데 있어 릴리스 자동화 도구보다 한 단계 더 나아갑니다.

과제 3: 부하 분산

여러 클라우드에서 애플리케이션 인스턴스를 여러 개 호스팅하는 경우, 각 인스턴스가 적정량의 트래픽을 처리하도록 하려면 어떻게 해야 할까요? 한 클라우드는 유휴 상태인데 다른 클라우드로 너무 많은 트래픽이 몰리는 상황을 어떻게 방지할 수 있을까요? 인스턴스를 추가하거나 제거해야 할 시점은 어떻게 알 수 있을까요?

이는 중요한 질문입니다. 멀티 클라우드 아키텍처 전반에서 부하를 적절히 분산하지 못하면 성능 문제가 발생하고 비용이 낭비될 수 있습니다. 이는 멀티 클라우드 아키텍처가 제공해야 할 이점과 정반대입니다.

안타깝게도 멀티 클라우드 환경에서는 이러한 질문에 답하기가 매우 어렵습니다. 클라우드 공급업체가 다른 공급업체의 클라우드와 연동되는 로드 밸런싱 솔루션을 제공하지 않기 때문에, 서로 다른 클라우드와 애플리케이션 인스턴스 간에 트래픽을 어떻게 분산할지 결정하려면 각 클라우드를 개별적으로 면밀히 모니터링해야 합니다.

여러 클라우드에 배포할 수 있는 공통 네트워킹 및 모니터링 플랫폼과 자동으로 연결하고 부하를 분산하는 애플리케이션 전송 네트워크를 사용하면 이러한 문제를 피하고 멀티 클라우드 전략이 제공해야 할 이점을 실질적으로 누릴 수 있습니다.

과제 4: 이그레스

클라우드 제공업체들은 탐욕스럽습니다. 이들은 여러분의 워크로드와 데이터가 영원히 자사 클라우드 안에 머물기를 원합니다. 데이터를 외부로 이동하면, 즉 데이터 이그레스를 수행하면 상당한 요금을 부과합니다.

즉, 데이터를 한 클라우드에서 다른 클라우드로 자주 이동해야 하는 멀티 클라우드 아키텍처는 데이터 반출 비용으로 인해 클라우드 컴퓨팅 요금을 크게 증가시킬 수 있습니다.

기본적으로는 서로 다른 클라우드 간에 데이터를 자주 이동할 필요가 없도록 멀티 클라우드 아키텍처를 설계하여 이러한 위험을 줄일 수 있습니다. 예를 들어, 애플리케이션은 한 클라우드에 있지만 애플리케이션이 수집해야 하는 데이터는 다른 클라우드에 호스팅되는 상황은 피해야 합니다. 이러한 구성에서는 클라우드 간에 많은 양의 데이터를 이동해야 하기 때문입니다.

또 다른 유용한 전략은 자주 사용하는 데이터의 일부를 저장하는 애플리케이션 전송 네트워크(Application Delivery Network)를 활용하는 것입니다. 애플리케이션 전송 네트워크는 다양한 보안 및 성능상의 이점을 제공할 뿐만 아니라, 한 클라우드의 애플리케이션이 다른 클라우드로 데이터를 전송하거나 다른 클라우드에서 데이터를 가져와야 하는 빈도를 줄여 줍니다. 대신 애플리케이션 전송 네트워크 내의 데이터 저장소를 사용할 수 있습니다.

과제 5: 모니터링

단일 클라우드의 가시성을 유지하는 것만으로도 충분히 어렵습니다. 여러 클라우드를 함께 사용하면 관련된 모든 서비스와 구성을 모니터링하는 일이 실로 엄청난 과제가 됩니다.

멀티 클라우드 환경을 지원하도록 설계된 애플리케이션 성능 모니터링(APM) 도구는 이 작업에 어느 정도 도움이 될 수 있습니다. 하지만 이러한 도구만으로는 한계가 있습니다. 애플리케이션 중 하나에서 문제가 발생한 것으로 보이면 알림을 보내 주지만, 어떤 클라우드가 문제를 일으키는지 파악한 다음 영향을 받은 각 클라우드의 관련 도구를 사용해 문제를 해결하는 것은 사용자의 몫입니다.

또는 기본 클라우드로부터 워크로드를 추상화하여 하나의 ‘논리적 클라우드’와 단일 배포 도구 세트만 모니터링하는 방안을 고려해 보세요. 이 접근 방식은 애플리케이션과 인프라에 대한 가시성을 유지하기 위해 관리해야 하는 구성 요소의 수를 줄여 줍니다.

결론

멀티 클라우드 아키텍처에서 애플리케이션 배포를 관리하는 일은 본질적으로 어렵습니다. 다양한 자동화 도구를 활용하면 프로비저닝, 배포, 모니터링과 같은 작업을 간소화할 수 있지만, 수작업의 필요성을 완전히 없앨 수는 없습니다.

다양한 도구로 멀티 클라우드 배포 문제를 해결하려 하기보다는 멀티 클라우드 아키텍처 자체의 설계 방식을 바꾸는 것이 더 나은 접근법입니다. VoltMesh와 VoltConsole 같은 솔루션을 활용하면 여러 클라우드에 걸쳐 애플리케이션을 일관된 중앙 집중식 방식으로 배포하고 연결하는 동시에, Volterra의 글로벌 애플리케이션 전송 네트워크를 활용하여 워크로드 성능과 보안을 최적화할 수 있습니다.