2018.05.02

벤더 기고 | 멀티클라우드 환경의 가시성을 확보하는 방법

Alex Henthorn-Iwane, Ameet Naik | InfoWorld
멀티클라우드는 일반적으로 단일 클라우드 환경의 시작 단계를 넘어 클라우드 서비스에 대한 '동급 최강' 접근방식을 추구하는 기업이 선택하는 진화 단계로 여겨지고 있다. 멀터클라우드에는 다양한 요인이 관련되어 있다. 경우에 따라 플랫폼 별 기능이 필요한 워크로드의 다양성이 영향을 미칠 수도 있고, 현실적인 여정 또는 인수 합병의 결과도 영향을 미칠 수 있다.

최근에는 기업이 처음부터 멀티클라우드를 주된 클라우드 우선 전략으로 선택하고 있다. 플랫폼 업체들이 서비스에 대한 구속력을 강화하면서 단일 업체에 대한 의존성을 줄이기 위한 이유도 있다. 또한 워크로드 특성에 따른 비용 최적화가 목적인 경우도 있다. 이들 측면에 모두에 대한 요구가 강한 편이며, 이는 하드웨어 플랫폼에서 보았던 것과 다르지 않다.

하지만 멀티클라우드를 선택한 이유에 상관 없이 복잡성은 발생하며, 이를 제대로 관리하지 않을 경우 멀티클라우드 전략의 비용 절감 요소가 무용지물이 되고 성과 목표에 지장을 초래할 수 있다.

이 때문에 가시성이 매우 중요하다. 하지만 운영 가시성을 확보하려면 멀티클라우드 자체로의 변화와 마찬가지로 온프레미스 네트워크 외에 WAN, 인터넷, 클라우드, SaaS 서비스 업체 영역의 건전성과 성과를 측정하기 위한 데이터 세트의 변화가 필요하다. 여기서는 멀티클라우드 배치와 관련된 몇 가지 핵심 용어를 분석하고 클라우드에서 전통적인 가시성 접근방식의 문제, 멀티클라우드 가시성을 확보하기 위해 필요한 접근방식을 살펴본다.

Image Credit : GettyImagesBank

하이브리드 클라우드 vs. 멀티클라우드

하이브리드 클라우드는 기존의 레거시 데이터센터와 클라우드에서 소비하는 일부 서비스의 결합을 의미한다. 오늘날 대부분 애플리케이션은 인증, 결제, 물류 등을 위해 하나 이상의 외부 API 기반 서비스를 이용하기 때문에 하이브리드라 할 수 있다. 내부 관리 앱이 인증을 위해 애저 액티브 디렉토리 또는 옥타(Okta)를 호출하는 경우 실제로는 하이브리드 클라우드를 운용하고 있는 것이다. 웹사이트에 페이팔(Paypal) 또는 비자(Visa) 결제 위젯이 있다면, 하이브리드 클라우드를 이용하고 있는 것이다.

애플리케이션이 구성 서비스로 세분화되고 구조화된 API 호출을 통해서만 통신하면서 각 구성 요소를 별도로 배치하고 확장하는 것이 가능해졌다. 이 때문에 AWS 등의 인프라 및 플랫폼 서비스가 매우 매력적이다. 일부 핵심 자산과 기능은 온프레미스 환경으로 유지하면서 소속이 없는 구성 요소를 독립적으로 확대하고 사용자에 더 가까운 클라우드에 상주시킬 수 있게 된 것이다.

VM웨어는 엔터프라이즈 클라우드 부문의 선두주자로, AWS와의 협력을 통한 실행 가능한 하이브리드 클라우드 서비스를 제공한다. VM웨어 CoAWS(Cloud on AWS)를 통해 VM 워크로드 및 가상 네트워크를 아마존 클라우드로 손쉽게 확대하면서 모든 것을 v스피어(vSphere)를 통해 관리할 수 있다.

한편, 멀티클라우드는 레거시 데이터센터와 2개 이상 클라우드 서비스 업체의 조합을 의미한다. 멀티클라우드에는 IaaS, PaaS, SaaS 등의 모든 외부 클라우드 서비스 유형이 포함된다. 여러 기질이 있고 저마다 조율 특징이 다른 훨씬 복잡한 환경이다. 그 목적은 비용 경제성과 "동급 최강"을 기준으로 워크로드를 최적의 클라우드에 배치하는 것이다. 관리 측면에서는 일정 수준의 예측 불가성과 변화의 속도에 대응하기 때문에 어려울 수 있다. 또한 이제 호출 흐름에 훨씬 많은 순열이 포함되기 때문에, 특히 성과 조정과 문제 해결이 어려워진다.

마이크로서비스 API
최근 몇 년 동안 마이크로서비스 아키텍처가 큰 인기를 얻으며 애플리케이션을 새로 구축하는 방법을 근본적으로 바꾸어 놓았다. 우버는 기본적으로 마이크로서비스 생태계에서 구동하는 서비스의 좋은 예이다. 우버는 지도 제작, 결제, 알림, 전화 통신을 위해 서드파티 API에 의존한다. 또한 각 API는 다른 백엔드 API에 의존할 수 있다. 따라서 우버에서 택시를 호출할 때마다 다중 API 흐름, 클라우드 서비스, 네트워크 경로가 제대로 작동해야 택시가 목적지에 도착할 수 있다.

기존에 IT 조직은 이런 수준의 복잡성에 대응할 필요가 없었다. 모든 것이 제대로 작동할 때는 복잡성이 즉각적으로 보이지 않지만 고장 상태를 문제 해결이 매우 복잡하다.

최근의 AWS 정전이 좋은 예이다. 인프라 관점에서 AWS는 사소한 정전이 발생했고 시스템이 꽤 짧은 시간 안에 복구되었다. 하지만 백엔드 흐름을 위해 AWS DC(Direct Connect)에 의존했던 애플리케이션은 초기 사건 후 몇 시간 동안 계속 문제를 일으켰다. 아틀라시안(Atlassian), 슬랙(Slack), 트윌리오(Twilio) 등 여러 애플리케이션 서비스 업체가 여러 클라우드들 사이의 숨겨진 의존성을 고려하지 못했다.
  
아마존의 AWS 동부 리전에 있는 소규모 서비스에 영향을 끼친 3월 2일의 정전이 AWS DC 사용자들에게 중대한 문제를 야기했다. 싸우전드아이즈는 240개 이상의 주요 서비스가 정전의 영향을 받았다고 밝혔다.

보이지 않는 망토
일반적으로 클라우드와 인터넷의 문제점 중 하나는 가시성의 부재이다. 그래서 많은 전통적인 네트워크 모니터링 툴이 SNMP, 흐름, 패킷 캡처 등의 기법에 의존했다. 이 모든 것들은 데이터센터를 구성하는 서버, 스위치, 방화벽, 라우터에 대한 일정 수준의 특권 액세스가 필요하다. 그 어떤 것도 IaaS 또는 PaaS 서비스를 통해 도입할 수 없다. 마이크로소프트의 애저 내부에 도청 장치를 심거나 아마존의 데이터센터에서 얻은 스트림 흐름 기록을 넣을 수 없다. 그 결과, 기업은 클라우드를 보이지 않는 망토 아래에 숨겨진 하나의 블랙 박스라고 생각하기에 이르렀다.

이 접근 방식은 단일 클라우드 또는 하이브리드 클라우드에는 효과가 없으며 분명 멀티클라우드 인프라와도 호환되지 않는다. 경로 조합의 수는 클라우드의 수에 따라 순차 곱셈으로 증가한다. 각 경로에는 여러 예측 불가능한 요소가 있다. 따라서 자릿수에 따라 위험이 증가한다. 이런 클라우드를 계속 블랙박스로 치부하며 수수방관할 수는 없다.

가림막이 없는 클라우드
일부 클라우드는 자체적인 네트워크 가시성 솔루션을 제공한다. 예를 들어, 마이크로소프트 애저에서는 ER(ExpressRoute) 연결을 통해 네트워크에서 Vnet으로의 기업 도메인을 시각화할 수 있다. 하지만 그렇다고 해서 외부적인 상호의존성을 포함한 완전한 엔드 투 엔드 가시성을 제공하지는 않는다. 물론, 이 솔루션은 애저 전용이며 다른 클라우드 또는 사용자의 레거시 데이터센터에 관한 정보를 제공하지 않는다. 멀티클라우드 전략을 통해 워크로드가 이동하면서 가시성 솔루션은 위치에 상관 없이 리소스를 따라야 한다.

이를 어떻게 달성할 수 있을까? 애플리케이션 가용성과 응답 시간뿐만이 아니라 이런 애플리케이션을 제공하기 위해 사용하는 기본 네트워크와 클라우드 인프라를 파악하기 위한 특수하게 구성된 애플리케이션 호출을 사용하는 능동형 모니터링 기법이 존재한다. 여기에는 클라우드 인프라의 권한 정보가 필요 없기 때문에 클라우드와 서비스 업체를 가리지 않을 수 있다. 일반적으로 이 모든 것들을 위해서는 리소스의 대상 URL이 필요하다.

싸우전드아이즈에서는 이런 접근방식으로 인터넷 인식 네트워크 모니터링을 수행하는 광범위한 소프트웨어 에이전트를 운용한다. 싸우전드아이즈는 여러 시점에서 인터넷 전반의 필수 서비스를 모니터링하고 서비스 영향을 파악하기 위해 알고리즘을 통해 데이터를 상호 연계한다. AWS DC에 의존하는 240개 이상의 필수 서비스가 3월 2일 정전에 영향을 받았다고 판단할 수 있었던 것은 이 때문이다.

클라우드에는 정상 상태라는 것이 없다. 모든 IaaS 및 PaaS 서비스 업체는 데브옵스 및 자동화 툴을 많이 활용하기 때문에 사전 고지 없이 변화가 빠르게 이루어진다. 이와 동시에 멀티클라우드 도입 시 워크로드를 최적 클라우드 플랫폼으로 이동하기 위해 쿠버네티스 등의 컨테이너화 및 자동화 서비스를 사용하는 경우가 많다. 이렇게 빠르게 변화하는 세상에서는 완전한 최신 상황 파악을 위해 애플리케이션 제공 경로의 변화를 반영하는 연속적인 가시성이 필요하다.

*Alex Henthorn-Iwane과 Ameet Naik는 싸우전드아이즈(ThousandEyes)의 제품 마케팅 담당 부사장과 기술 마케팅 매니저다. editor@itworld.co.kr



2018.05.02

벤더 기고 | 멀티클라우드 환경의 가시성을 확보하는 방법

Alex Henthorn-Iwane, Ameet Naik | InfoWorld
멀티클라우드는 일반적으로 단일 클라우드 환경의 시작 단계를 넘어 클라우드 서비스에 대한 '동급 최강' 접근방식을 추구하는 기업이 선택하는 진화 단계로 여겨지고 있다. 멀터클라우드에는 다양한 요인이 관련되어 있다. 경우에 따라 플랫폼 별 기능이 필요한 워크로드의 다양성이 영향을 미칠 수도 있고, 현실적인 여정 또는 인수 합병의 결과도 영향을 미칠 수 있다.

최근에는 기업이 처음부터 멀티클라우드를 주된 클라우드 우선 전략으로 선택하고 있다. 플랫폼 업체들이 서비스에 대한 구속력을 강화하면서 단일 업체에 대한 의존성을 줄이기 위한 이유도 있다. 또한 워크로드 특성에 따른 비용 최적화가 목적인 경우도 있다. 이들 측면에 모두에 대한 요구가 강한 편이며, 이는 하드웨어 플랫폼에서 보았던 것과 다르지 않다.

하지만 멀티클라우드를 선택한 이유에 상관 없이 복잡성은 발생하며, 이를 제대로 관리하지 않을 경우 멀티클라우드 전략의 비용 절감 요소가 무용지물이 되고 성과 목표에 지장을 초래할 수 있다.

이 때문에 가시성이 매우 중요하다. 하지만 운영 가시성을 확보하려면 멀티클라우드 자체로의 변화와 마찬가지로 온프레미스 네트워크 외에 WAN, 인터넷, 클라우드, SaaS 서비스 업체 영역의 건전성과 성과를 측정하기 위한 데이터 세트의 변화가 필요하다. 여기서는 멀티클라우드 배치와 관련된 몇 가지 핵심 용어를 분석하고 클라우드에서 전통적인 가시성 접근방식의 문제, 멀티클라우드 가시성을 확보하기 위해 필요한 접근방식을 살펴본다.

Image Credit : GettyImagesBank

하이브리드 클라우드 vs. 멀티클라우드

하이브리드 클라우드는 기존의 레거시 데이터센터와 클라우드에서 소비하는 일부 서비스의 결합을 의미한다. 오늘날 대부분 애플리케이션은 인증, 결제, 물류 등을 위해 하나 이상의 외부 API 기반 서비스를 이용하기 때문에 하이브리드라 할 수 있다. 내부 관리 앱이 인증을 위해 애저 액티브 디렉토리 또는 옥타(Okta)를 호출하는 경우 실제로는 하이브리드 클라우드를 운용하고 있는 것이다. 웹사이트에 페이팔(Paypal) 또는 비자(Visa) 결제 위젯이 있다면, 하이브리드 클라우드를 이용하고 있는 것이다.

애플리케이션이 구성 서비스로 세분화되고 구조화된 API 호출을 통해서만 통신하면서 각 구성 요소를 별도로 배치하고 확장하는 것이 가능해졌다. 이 때문에 AWS 등의 인프라 및 플랫폼 서비스가 매우 매력적이다. 일부 핵심 자산과 기능은 온프레미스 환경으로 유지하면서 소속이 없는 구성 요소를 독립적으로 확대하고 사용자에 더 가까운 클라우드에 상주시킬 수 있게 된 것이다.

VM웨어는 엔터프라이즈 클라우드 부문의 선두주자로, AWS와의 협력을 통한 실행 가능한 하이브리드 클라우드 서비스를 제공한다. VM웨어 CoAWS(Cloud on AWS)를 통해 VM 워크로드 및 가상 네트워크를 아마존 클라우드로 손쉽게 확대하면서 모든 것을 v스피어(vSphere)를 통해 관리할 수 있다.

한편, 멀티클라우드는 레거시 데이터센터와 2개 이상 클라우드 서비스 업체의 조합을 의미한다. 멀티클라우드에는 IaaS, PaaS, SaaS 등의 모든 외부 클라우드 서비스 유형이 포함된다. 여러 기질이 있고 저마다 조율 특징이 다른 훨씬 복잡한 환경이다. 그 목적은 비용 경제성과 "동급 최강"을 기준으로 워크로드를 최적의 클라우드에 배치하는 것이다. 관리 측면에서는 일정 수준의 예측 불가성과 변화의 속도에 대응하기 때문에 어려울 수 있다. 또한 이제 호출 흐름에 훨씬 많은 순열이 포함되기 때문에, 특히 성과 조정과 문제 해결이 어려워진다.

마이크로서비스 API
최근 몇 년 동안 마이크로서비스 아키텍처가 큰 인기를 얻으며 애플리케이션을 새로 구축하는 방법을 근본적으로 바꾸어 놓았다. 우버는 기본적으로 마이크로서비스 생태계에서 구동하는 서비스의 좋은 예이다. 우버는 지도 제작, 결제, 알림, 전화 통신을 위해 서드파티 API에 의존한다. 또한 각 API는 다른 백엔드 API에 의존할 수 있다. 따라서 우버에서 택시를 호출할 때마다 다중 API 흐름, 클라우드 서비스, 네트워크 경로가 제대로 작동해야 택시가 목적지에 도착할 수 있다.

기존에 IT 조직은 이런 수준의 복잡성에 대응할 필요가 없었다. 모든 것이 제대로 작동할 때는 복잡성이 즉각적으로 보이지 않지만 고장 상태를 문제 해결이 매우 복잡하다.

최근의 AWS 정전이 좋은 예이다. 인프라 관점에서 AWS는 사소한 정전이 발생했고 시스템이 꽤 짧은 시간 안에 복구되었다. 하지만 백엔드 흐름을 위해 AWS DC(Direct Connect)에 의존했던 애플리케이션은 초기 사건 후 몇 시간 동안 계속 문제를 일으켰다. 아틀라시안(Atlassian), 슬랙(Slack), 트윌리오(Twilio) 등 여러 애플리케이션 서비스 업체가 여러 클라우드들 사이의 숨겨진 의존성을 고려하지 못했다.
  
아마존의 AWS 동부 리전에 있는 소규모 서비스에 영향을 끼친 3월 2일의 정전이 AWS DC 사용자들에게 중대한 문제를 야기했다. 싸우전드아이즈는 240개 이상의 주요 서비스가 정전의 영향을 받았다고 밝혔다.

보이지 않는 망토
일반적으로 클라우드와 인터넷의 문제점 중 하나는 가시성의 부재이다. 그래서 많은 전통적인 네트워크 모니터링 툴이 SNMP, 흐름, 패킷 캡처 등의 기법에 의존했다. 이 모든 것들은 데이터센터를 구성하는 서버, 스위치, 방화벽, 라우터에 대한 일정 수준의 특권 액세스가 필요하다. 그 어떤 것도 IaaS 또는 PaaS 서비스를 통해 도입할 수 없다. 마이크로소프트의 애저 내부에 도청 장치를 심거나 아마존의 데이터센터에서 얻은 스트림 흐름 기록을 넣을 수 없다. 그 결과, 기업은 클라우드를 보이지 않는 망토 아래에 숨겨진 하나의 블랙 박스라고 생각하기에 이르렀다.

이 접근 방식은 단일 클라우드 또는 하이브리드 클라우드에는 효과가 없으며 분명 멀티클라우드 인프라와도 호환되지 않는다. 경로 조합의 수는 클라우드의 수에 따라 순차 곱셈으로 증가한다. 각 경로에는 여러 예측 불가능한 요소가 있다. 따라서 자릿수에 따라 위험이 증가한다. 이런 클라우드를 계속 블랙박스로 치부하며 수수방관할 수는 없다.

가림막이 없는 클라우드
일부 클라우드는 자체적인 네트워크 가시성 솔루션을 제공한다. 예를 들어, 마이크로소프트 애저에서는 ER(ExpressRoute) 연결을 통해 네트워크에서 Vnet으로의 기업 도메인을 시각화할 수 있다. 하지만 그렇다고 해서 외부적인 상호의존성을 포함한 완전한 엔드 투 엔드 가시성을 제공하지는 않는다. 물론, 이 솔루션은 애저 전용이며 다른 클라우드 또는 사용자의 레거시 데이터센터에 관한 정보를 제공하지 않는다. 멀티클라우드 전략을 통해 워크로드가 이동하면서 가시성 솔루션은 위치에 상관 없이 리소스를 따라야 한다.

이를 어떻게 달성할 수 있을까? 애플리케이션 가용성과 응답 시간뿐만이 아니라 이런 애플리케이션을 제공하기 위해 사용하는 기본 네트워크와 클라우드 인프라를 파악하기 위한 특수하게 구성된 애플리케이션 호출을 사용하는 능동형 모니터링 기법이 존재한다. 여기에는 클라우드 인프라의 권한 정보가 필요 없기 때문에 클라우드와 서비스 업체를 가리지 않을 수 있다. 일반적으로 이 모든 것들을 위해서는 리소스의 대상 URL이 필요하다.

싸우전드아이즈에서는 이런 접근방식으로 인터넷 인식 네트워크 모니터링을 수행하는 광범위한 소프트웨어 에이전트를 운용한다. 싸우전드아이즈는 여러 시점에서 인터넷 전반의 필수 서비스를 모니터링하고 서비스 영향을 파악하기 위해 알고리즘을 통해 데이터를 상호 연계한다. AWS DC에 의존하는 240개 이상의 필수 서비스가 3월 2일 정전에 영향을 받았다고 판단할 수 있었던 것은 이 때문이다.

클라우드에는 정상 상태라는 것이 없다. 모든 IaaS 및 PaaS 서비스 업체는 데브옵스 및 자동화 툴을 많이 활용하기 때문에 사전 고지 없이 변화가 빠르게 이루어진다. 이와 동시에 멀티클라우드 도입 시 워크로드를 최적 클라우드 플랫폼으로 이동하기 위해 쿠버네티스 등의 컨테이너화 및 자동화 서비스를 사용하는 경우가 많다. 이렇게 빠르게 변화하는 세상에서는 완전한 최신 상황 파악을 위해 애플리케이션 제공 경로의 변화를 반영하는 연속적인 가시성이 필요하다.

*Alex Henthorn-Iwane과 Ameet Naik는 싸우전드아이즈(ThousandEyes)의 제품 마케팅 담당 부사장과 기술 마케팅 매니저다. editor@itworld.co.kr

X