2020.03.03

'복잡해도 불가피한' 멀티클라우드 전략의 최소 요건

Andrew C. Oliver | InfoWorld
덴마크(사실상 유럽 전체)에서 뭔가 썩고 있는데, 아마존은 아무 말이 없다. 상황을 보면 해킹 또는 대규모 서비스 거부 공격이 발생한 것 같다. 필자가 인지한 시점은 지난 10월이지만 구글에서 “AWS DDoS attack”을 검색해 보면 자동 완성으로 뒤에 연도가 붙는다. 빈번하게 일어나는 일이라는 뜻이다.

서비스 거부 공격은 인터넷 자체와 역사를 같이할 만큼 오래된 공격이며, 데이터센터 운영업체 또는 호스팅 제공업체의 숨기는 습관 역시 그에 못지않게 오래된 관행이다. 예나 지금이나 전체 네트워크가 다운되지 않도록 보호해주는 것은 ‘복수의 제공업체가 운영하는 복수의 데이터센터’, 즉 멀티클라우드다.
 
ⓒ GettyImagesBank

물론 멀티클라우드 전략의 시작은 여러 업체의 클라우드에 워크로드를 배치하는 것이다. 또는 배치할 수 있는 역량을 유지하는 것이다. 이 말은 AWS와 애저, 때에 따라 구글 클라우드 플랫폼에도 소프트웨어를 유지한다는 것을 의미한다. 옮기지 못하도록 하는 서비스가 있다면 버리고, 여러 데이터센터에 걸쳐 확장이 가능한 데이터 아키텍처를 추구한다.
 

단일 클라우드의 장단점

단일 업체의 클라우드에 의존할 경우 해당 클라우드 서비스 업체가 제공하는 저렴한 대안을 뷔페처럼 고를 수 있다. 이런 서비스를 추가하는 일은 보통 아주 매끄럽게 이루어진다. 예를 들어 AWS 고객이라면 자체 검색 클러스터를 구축하는 대신 아마존 일래스틱서치 서비스(Amazon Elasticsearch Service)를 사용하면 된다. 구글 고객이라면 문서 데이터베이스를 직접 운영할 필요 없이 구글 문서 데이터베이스인 구글 클라우드 데이터스토어(Google Cloud Datastore)를 사용한다.

그러나 모든 업체의 플랫폼 전략이 그렇듯이 그 대가로 자유를 희생해야 한다. 과장처럼 느끼겠지만, 잘 생각해 보자. 물론 해당 클라우드 서비스 업체가 지금 당장은 더 저렴하다. 하지만 앞으로도 그럴까? 게다가 클라우드 업체가 전략을 변경하면서 어느 날 갑자기 사라지지 않는다고 보장할 수 있을까? 없애고 발표조차 하지 않는 경우도 있다. 해당 지역의 AWS 데이터센터가 장시간 다운되거나 속도가 느려지거나 불안정하게 된다면? 그에 따르는 손실을 감당할 수 있는가?

클라우드 서비스 업체(특히 아마존)가 제공하는 서비스 중에는 API 호환성을 유지해야 하는 오픈소스 버전의 분기 버전이 종종 있다. 그러나 잘 알려진 바와 같이 이러한 분기 버전은 발표 속도가 오픈소스에 비해 한두 릴리즈 뒤처진다. 일반적으로 규모가 크고 업그레이드 속도가 느린 대기업에서는 이것이 문제가 되지 않을 수 있지만, “일반적”이라는 말은 그렇지 않은 경우도 있음을 의미한다.

대기업이라도 해도 상황에 따라서는 빠르게 움직여야 한다. 예를 들어 현재 릴리스에서 패치가 불가능한 큰 보안 결함이 발견되는 경우 릴리스를 전환해야 한다. 또한 다음 릴리스에 더 높은 확장성을 위해 반드시 필요한 기능이 있고, 기업에 그 기능이 필요하거나 기업의 자체 다음 릴리스를 위해 필요한 기능이 있다면 클라우드 서비스 업체의 일정에 따라 움직일 경우 원하는 속도보다 뒤처지게 된다.

클라우드 서비스 업체의 전용 서비스를 사용할 때는 “이들의 의도가 무엇인가?”를 묻는 것이 중요하다. 물론 IaaS 상품보다 30% 더 높은 가격을 원할 수도 있지만, 그보다는 고객을 업체의 플랫폼에 묶어 두고 고객이 컴퓨팅에 쓰는 모든 비용을 마지막 한 푼까지 쓸어가는 것이 이들의 목적이다.

각 클라우드 서비스 업체는 안정적인 수준까지 발전했지만 완벽하지는 않다. 매년 지역별로, 때로는 여러 지역에 걸친 중단 사고가 일어난다. 그 중에서는 꽤 오랜 기간 불안정한 상태로 유지되는 경우도 있다. 이럴 때 다른 곳에 코드를 설치해 구동할 수 없다면(또는 다른 곳에 이미 예비로 갖춰 두지 않으면) 재해가 들이닥친 상황에서 아무것도 하지 못한 채 기다리는 수밖에 없다. 

마지막으로, 기업이 해당 클라우드 서비스 업체에 이른바 ‘록인’되어 다른 곳으로 떠날 수 없다는 사실을 그 업체가 안다면, 가격 협상력 측면에서도 절대적으로 불리하다.

참고로 필자는 카우치베이스(Couchbae)에서 일하는데, 카우치베이스는 아마존을 포함한 여러 클라우드 서비스 업체와 협력관계를 맺고 있다.
 

멀티클라우드의 장단점

멀티클라우드 전략을 위해서는 업체 중립성과 더 탄력적인 아키텍처 선택, 두 가지가 모두 필요하다. 즉, 처음에는 복잡성이 더 높다. 또한 종종 여러 서비스 업체와 협상해야 하며, 기술 간 통합 지점이 필요하고 통합 지점의 보안도 유지해야 한다.




2020.03.03

'복잡해도 불가피한' 멀티클라우드 전략의 최소 요건

Andrew C. Oliver | InfoWorld
덴마크(사실상 유럽 전체)에서 뭔가 썩고 있는데, 아마존은 아무 말이 없다. 상황을 보면 해킹 또는 대규모 서비스 거부 공격이 발생한 것 같다. 필자가 인지한 시점은 지난 10월이지만 구글에서 “AWS DDoS attack”을 검색해 보면 자동 완성으로 뒤에 연도가 붙는다. 빈번하게 일어나는 일이라는 뜻이다.

서비스 거부 공격은 인터넷 자체와 역사를 같이할 만큼 오래된 공격이며, 데이터센터 운영업체 또는 호스팅 제공업체의 숨기는 습관 역시 그에 못지않게 오래된 관행이다. 예나 지금이나 전체 네트워크가 다운되지 않도록 보호해주는 것은 ‘복수의 제공업체가 운영하는 복수의 데이터센터’, 즉 멀티클라우드다.
 
ⓒ GettyImagesBank

물론 멀티클라우드 전략의 시작은 여러 업체의 클라우드에 워크로드를 배치하는 것이다. 또는 배치할 수 있는 역량을 유지하는 것이다. 이 말은 AWS와 애저, 때에 따라 구글 클라우드 플랫폼에도 소프트웨어를 유지한다는 것을 의미한다. 옮기지 못하도록 하는 서비스가 있다면 버리고, 여러 데이터센터에 걸쳐 확장이 가능한 데이터 아키텍처를 추구한다.
 

단일 클라우드의 장단점

단일 업체의 클라우드에 의존할 경우 해당 클라우드 서비스 업체가 제공하는 저렴한 대안을 뷔페처럼 고를 수 있다. 이런 서비스를 추가하는 일은 보통 아주 매끄럽게 이루어진다. 예를 들어 AWS 고객이라면 자체 검색 클러스터를 구축하는 대신 아마존 일래스틱서치 서비스(Amazon Elasticsearch Service)를 사용하면 된다. 구글 고객이라면 문서 데이터베이스를 직접 운영할 필요 없이 구글 문서 데이터베이스인 구글 클라우드 데이터스토어(Google Cloud Datastore)를 사용한다.

그러나 모든 업체의 플랫폼 전략이 그렇듯이 그 대가로 자유를 희생해야 한다. 과장처럼 느끼겠지만, 잘 생각해 보자. 물론 해당 클라우드 서비스 업체가 지금 당장은 더 저렴하다. 하지만 앞으로도 그럴까? 게다가 클라우드 업체가 전략을 변경하면서 어느 날 갑자기 사라지지 않는다고 보장할 수 있을까? 없애고 발표조차 하지 않는 경우도 있다. 해당 지역의 AWS 데이터센터가 장시간 다운되거나 속도가 느려지거나 불안정하게 된다면? 그에 따르는 손실을 감당할 수 있는가?

클라우드 서비스 업체(특히 아마존)가 제공하는 서비스 중에는 API 호환성을 유지해야 하는 오픈소스 버전의 분기 버전이 종종 있다. 그러나 잘 알려진 바와 같이 이러한 분기 버전은 발표 속도가 오픈소스에 비해 한두 릴리즈 뒤처진다. 일반적으로 규모가 크고 업그레이드 속도가 느린 대기업에서는 이것이 문제가 되지 않을 수 있지만, “일반적”이라는 말은 그렇지 않은 경우도 있음을 의미한다.

대기업이라도 해도 상황에 따라서는 빠르게 움직여야 한다. 예를 들어 현재 릴리스에서 패치가 불가능한 큰 보안 결함이 발견되는 경우 릴리스를 전환해야 한다. 또한 다음 릴리스에 더 높은 확장성을 위해 반드시 필요한 기능이 있고, 기업에 그 기능이 필요하거나 기업의 자체 다음 릴리스를 위해 필요한 기능이 있다면 클라우드 서비스 업체의 일정에 따라 움직일 경우 원하는 속도보다 뒤처지게 된다.

클라우드 서비스 업체의 전용 서비스를 사용할 때는 “이들의 의도가 무엇인가?”를 묻는 것이 중요하다. 물론 IaaS 상품보다 30% 더 높은 가격을 원할 수도 있지만, 그보다는 고객을 업체의 플랫폼에 묶어 두고 고객이 컴퓨팅에 쓰는 모든 비용을 마지막 한 푼까지 쓸어가는 것이 이들의 목적이다.

각 클라우드 서비스 업체는 안정적인 수준까지 발전했지만 완벽하지는 않다. 매년 지역별로, 때로는 여러 지역에 걸친 중단 사고가 일어난다. 그 중에서는 꽤 오랜 기간 불안정한 상태로 유지되는 경우도 있다. 이럴 때 다른 곳에 코드를 설치해 구동할 수 없다면(또는 다른 곳에 이미 예비로 갖춰 두지 않으면) 재해가 들이닥친 상황에서 아무것도 하지 못한 채 기다리는 수밖에 없다. 

마지막으로, 기업이 해당 클라우드 서비스 업체에 이른바 ‘록인’되어 다른 곳으로 떠날 수 없다는 사실을 그 업체가 안다면, 가격 협상력 측면에서도 절대적으로 불리하다.

참고로 필자는 카우치베이스(Couchbae)에서 일하는데, 카우치베이스는 아마존을 포함한 여러 클라우드 서비스 업체와 협력관계를 맺고 있다.
 

멀티클라우드의 장단점

멀티클라우드 전략을 위해서는 업체 중립성과 더 탄력적인 아키텍처 선택, 두 가지가 모두 필요하다. 즉, 처음에는 복잡성이 더 높다. 또한 종종 여러 서비스 업체와 협상해야 하며, 기술 간 통합 지점이 필요하고 통합 지점의 보안도 유지해야 한다.


X