2021.03.25

'성숙기 들어섰지만...' 클라우드의 문제점 7가지

Andrew C. Oliver | InfoWorld
일찌기 한 현명한 클라우드 설계자는 “나에게는 99가지 문제가 있지만 클라우드는 거기에 끼지도 못한다”는 말을 했다. 클라우드가 등장하면서 애플리케이션과 서비스의 대규모 운영이 훨씬 더 쉬워졌다. 그러나 클라우드 컴퓨팅에도 나름의 문제는 있다.
 
온프레미스 시절에는 코드 일부에 문제가 있어도 ‘고작해야’ 성능 저하나 중단을 초래했을 뿐이다. 지금은 버그가 있으면 AWS가 사용자의 주머니를 뒤진 다음 거꾸로 매달아 마지막 동전 하나까지 탈탈 털어내 가져간다고 할 만큼의 비용이 발생한다.
 
아마존 키네시스나 애저 코스모스 DB 또는 구글 클라우드 빅테이블을 사용하기는 아주 쉽다. 그러나 호텔 캘리포니아의 가사처럼 언제든 체크아웃할 수는 있을지 몰라도 절대로 클라우드를 떠날 수는 없을 것이다. 순수 인프라 서비스 비용은 시간이 지나면서 하락했지만, 클라우드 제공업체의 전반적인 가격은 별다른 변화가 없다(납득할 수도 없다).
 
ⓒ Florent Darrault (CC BY-SA 2.0

게다가 복잡한 것도 많고 안정적으로 안전하게 유지해야 하는 인스턴스도 넘쳐난다. 쿠버네티스 구성은 또 왜 이렇게 긴 것일까?
 
말하자면 끝도 없다. 그래서 인터넷에서 가장 중요한 클라우드 기반 서비스를 책임지는 담당자들이 그동안 어떤 문제에 직면했고 그 문제를 어떻게 해결하거나 완화했는지를 물었다.
 

비용 관리

한때 AWS가 저렴하다고 생각했던 시절이 있었다. 코베오(Coveo)의 공동 창업자이자 기술 부문 선임 부사장인 마크 샌패콘은 “온프레미스에 실제로 존재하는 하드웨어가 있다면 그 하드웨어를 사용한다. 돈을 주고 구매한 내 것이고, 전기료도 내가 내고, 원하는 만큼 사용할 수 있기 때문”라고 말했다. 
 
샌패콘은 이어 “그러나 200명 이상의 개발자가 있는 코베오 같은 기업에서는 새 전화기나 책상 또는 의자를 구매할 때도 회사 정책에 따라 승인을 받아야 한다. 하지만 직원들은 이 정책을 무시하고 AWS 콘솔로 들어가서 시간당 25달러가 청구되는 새 머신을 가동하고, 한 달 동안 그대로 방치하곤 한다. 월말이 되면 누적된 비용에 깜짝 놀라게 된다”라고 말했다.
 
현재 코베오는 예를 들어 오후 8시부터 오전 6시까지, 그리고 주말과 같이 작업하는 사람이 없을 때는 클러스터나 인스턴스를 끈다. 그러나 갑자기 영감이 떠올라 새벽 2시에 일어나 일을 시작하는 개발자도 고려해야 한다.
 
코베오에는 하루 업무 시간의 75%를 클라우드 비용 최적화에 소비하는 전담 직원들이 이미 있다. 그러나 샌패콘은 비용을 관리하고 최적화하는 데 도움이 되는 제품을 생산하는 새로운 핀옵스(FinOps) 기업에 주목한다. 샌패콘은 클라우드 비용 지출을 통제하는 데 사용할 수 있는 툴로 클라우드어빌리티(Cloudability)와 클라우드헬스(CloudHealth)를 언급했다.
 

클라우드별 서비스 독립성 유지하기

샌패콘은 코베오가 씨름 중인 또 다른 클라우드 문제에 대해서도 언급했다. 아마존 서비스에 장애가 발생할 경우 코베오 서비스의 정상 작동을 유지하는 것이다.
 
샌패콘은 “블랙 프라이데이 직전에 AWS에서 키네시스와 관련해 두 번의 큰 사고가 있었다. 키네시스는 코베오가 사용 중인 서비스 중 하나이기도 하지만 AWS 내의 다른 많은 서비스를 위한 중추 서비스이기도 하다”라고 말했다. 이 중단 사고는 코베오의 주 서비스에는 영향을 미치지 않았지만 새 조직을 온보딩하고 일부 유형의 이벤트를 레코딩하는 부분에는 영향을 미쳤다. 코베오는 검색 기업이고 블랙 프라이데이를 전후한 몇 주는 많은 전자상거래 고객이 구매 활동에 나서는 시기다.
 
샌패콘은 코베오의 자체 스트리밍 서비스를 호스팅하는 방법을 고려했지만, 아마존 키네시스 중단 문제로 어려움을 겪는 중에도 과연 코베오가 AWS보다 더 많은 업타임으로, 더 나은 메시징 서비스를, 더 비용 효율적으로 실행할 수 있을지를 자문해야 했다. 가능하다 해도 그것이 과연 효과적인 리소스 사용법일까?
 
고려할 점은 또 있다. 한 클라우드 서비스 제공업체의 서비스를 소비하는 것은 많은 이점이 있지만, 샌패콘은 동시에 구글 클라우드나 마이크로소프트 애저 등의 다른 업체로 쉽게 전환할 수 없음을 의미하기도 한다고 지적했다.
 
가능한 해결책 한 가지는 AWS의 관리형 카프카(Kafka)를 사용하는 것이다. 그러면 코베오는 문제가 발생할 경우 애저의 관리형 카프카 또는 컨플루언트(Confluent)의 구글 클라우드 기반 관리형 카프카로 간단하 전환할 수 있다.
 
아마존 키네시스를 실행하는 편이 아마존의 관리형 카프카를 실행하는 것보다 저렴하므로 클라우드 독립성에는 비용이 따른다. 그러나 혜택도 있다. 특히 많은 전자상거래 사이트의 검색 중추인 기업 관점에서 블랙 프라이데이를 앞둔 시점이나 팬데믹 중에 무언가가 잘못되는 상황을 생각해보면, 그 혜택은 크다.
 
마리아DB(MariaDB)의 스카이SQL(SkySQL) 제품 관리 담당 부사장인 사라바나 크리슈나무르티 역시 어느 클라우드에 특정적인 요소에 의존하지 말아야 한다면서 “솔루션에 내장된 REST API 또는 다른 어떤 API가 있다면 모든 통신이 클라우드 독립적인 API를 거치도록 해야 한다”면서 “이렇게 하면 아마존에서 구글 또는 애저로 전환할 때 애플리케이션과 데이터를 더 편리하게 옮길 수 있다”라고 말했다.
 

클라우드 업체마다 다른 멀티 클라우드 서비스 차이점

코크로치 랩스(Cockroach Labs)의 제품 마케팅 담당 부사장인 짐 워커는 각자 조금씩 다른 방식을 사용하는 클라우드 제공업체들에 의해 발생하는 문제를 지적했다. 코크로치 랩스는 코크로치클라우드(CockroachCloud) 데이터베이스 서비스를 AWS와 구글 클라우드, 양쪽에 구축하면서 둘의 차이점에 대해 많은 것을 알게 됐다.
 
워커는 “서로 전혀 다른 서비스다. 각 플랫폼에서의 사용자 경험을 ‘적절히’ 구현하기 위해 상당한 노력이 필요하다. 컨테이너와 쿠버네티스는 이 복잡성을 간소화하는 데 확실히 도움이 됐지만 여전히 두 플랫폼은 ‘완전히’ 다르게 생각해야 한다”라고 말했다. 워커는 다음과 같이 설명했다.

“예를 들어 쿠버네티스 관리형 서비스는 각 클라우드에서 상당히 다르고 네트워킹의 세세한 부분도 완전히 다르다. 각 클라우드에서 우리가 로드 밸런서를 다루는 방식도 다르다. 또한 한 클라우드에서는 IOPS를 맞춤형으로 설정할 수 있는 데 반해 다른 클라우드에서는 그렇게 할 수 없다. 고객을 위해 VPC(가상 프라이빗 클라우드) 피어링과 같은 기능을 제공하는 경우에도 AWS 프라이빗링크(PrivateLink)를 사용할 때와 기본 클라우드를 사용할 때의 접근 방법이 전혀 다르다. 클라우드 제공업체는 큰 가치를 제공하지만 각 개별 클라우드를 보면 해야 할 일이 많다.”
 

클라우드 보안

마리아DB의 크리슈나무르티 역시 클라우드에서 네트워크 보안의 중요함을 강조하며 “라고객 간 트래픽 간섭을 피해야 한다. 따라서 고객이 퍼블릭 네트워크 및 다른 고객의 트래픽과 격리되는 가상 프라이빗 클라우드를 요구하면 VPC를 격리 수단으로 제공한다”라고 말했다.
 
그러나 누군가가 예를 들어 액티브 디렉터리로 표준화해서 VPC 간에 인증을 할 경우 상황이 복잡해지고, 어려운 구성과 함께 시스템 간에 정책을 역할에 매핑하는 과정이 필요할 수 있다.
 

복잡성, 구성, 규정 준수

소수의 서버를 구성하고 일관성을 유지하는 것만 해도 쉽지 않은 일이다. 데브옵스는 운영과 배포 문제의 간소화를 약속했지만 구성 드리프트(drift)가 발생한다. 또한 구성이 일련의 스크립트로 존재하면서 수백 개의 서버에 적용되는 상황에서는 “누가” 구성을 변경했는지 알기가 어렵다. 일부 업계, 특히 금융 서비스의 경우 이와 같은 감사 증적의 부재가 규정 준수 측면에서 상당한 문제가 된다.
 
깃옵스(GitOps)라는 새로운 기술 및 방법론이 해결책을 제공할 수 있다. 이름에서 알 수 있듯이 깃옵스는 버전 관리 툴인 깃(Git)과 데브옵스를 결합한다. 그러나 깃옵스는 그 이상이다. 구성에 선언적 특성을 부여하고 드리프트를 측정한다. 또한 깃은 감사 증적을 유지한다. 누가 보안을 비활성화했는가? 리포지토리를 보면 그 질문에 답할 수 있다.
 
어느 클라우드 설계자는 “서버가 많을수록 문제도 많아진다”는 말을 했다. 그러나 핀옵스로 비용 효율성을 유지하고 깃옵스로 복잡성에 대처하고 멀티클라우드를 유지해 한 벤더의 장애로 인해 소프트웨어가 멈추는 상황을 방지하고 서비스를 자체 VPC로 격리해서 시스템의 보안과 프라이버시를 지킬 수 있다.
 
CVS를 사용해 유닉스 구성 파일을 확인하는 것이 특별하게 느껴졌던 시대는 지났다(그렇게 하는 모든 유닉스 관리자가 자신은 특별하다고 느꼈다). 지금의 클라우드 세계는 서버와 문제가 모두 늘어났다. 대신 더 좋은 도구도 있다는 점이 위안이다. editor@itworld.co.kr 



2021.03.25

'성숙기 들어섰지만...' 클라우드의 문제점 7가지

Andrew C. Oliver | InfoWorld
일찌기 한 현명한 클라우드 설계자는 “나에게는 99가지 문제가 있지만 클라우드는 거기에 끼지도 못한다”는 말을 했다. 클라우드가 등장하면서 애플리케이션과 서비스의 대규모 운영이 훨씬 더 쉬워졌다. 그러나 클라우드 컴퓨팅에도 나름의 문제는 있다.
 
온프레미스 시절에는 코드 일부에 문제가 있어도 ‘고작해야’ 성능 저하나 중단을 초래했을 뿐이다. 지금은 버그가 있으면 AWS가 사용자의 주머니를 뒤진 다음 거꾸로 매달아 마지막 동전 하나까지 탈탈 털어내 가져간다고 할 만큼의 비용이 발생한다.
 
아마존 키네시스나 애저 코스모스 DB 또는 구글 클라우드 빅테이블을 사용하기는 아주 쉽다. 그러나 호텔 캘리포니아의 가사처럼 언제든 체크아웃할 수는 있을지 몰라도 절대로 클라우드를 떠날 수는 없을 것이다. 순수 인프라 서비스 비용은 시간이 지나면서 하락했지만, 클라우드 제공업체의 전반적인 가격은 별다른 변화가 없다(납득할 수도 없다).
 
ⓒ Florent Darrault (CC BY-SA 2.0

게다가 복잡한 것도 많고 안정적으로 안전하게 유지해야 하는 인스턴스도 넘쳐난다. 쿠버네티스 구성은 또 왜 이렇게 긴 것일까?
 
말하자면 끝도 없다. 그래서 인터넷에서 가장 중요한 클라우드 기반 서비스를 책임지는 담당자들이 그동안 어떤 문제에 직면했고 그 문제를 어떻게 해결하거나 완화했는지를 물었다.
 

비용 관리

한때 AWS가 저렴하다고 생각했던 시절이 있었다. 코베오(Coveo)의 공동 창업자이자 기술 부문 선임 부사장인 마크 샌패콘은 “온프레미스에 실제로 존재하는 하드웨어가 있다면 그 하드웨어를 사용한다. 돈을 주고 구매한 내 것이고, 전기료도 내가 내고, 원하는 만큼 사용할 수 있기 때문”라고 말했다. 
 
샌패콘은 이어 “그러나 200명 이상의 개발자가 있는 코베오 같은 기업에서는 새 전화기나 책상 또는 의자를 구매할 때도 회사 정책에 따라 승인을 받아야 한다. 하지만 직원들은 이 정책을 무시하고 AWS 콘솔로 들어가서 시간당 25달러가 청구되는 새 머신을 가동하고, 한 달 동안 그대로 방치하곤 한다. 월말이 되면 누적된 비용에 깜짝 놀라게 된다”라고 말했다.
 
현재 코베오는 예를 들어 오후 8시부터 오전 6시까지, 그리고 주말과 같이 작업하는 사람이 없을 때는 클러스터나 인스턴스를 끈다. 그러나 갑자기 영감이 떠올라 새벽 2시에 일어나 일을 시작하는 개발자도 고려해야 한다.
 
코베오에는 하루 업무 시간의 75%를 클라우드 비용 최적화에 소비하는 전담 직원들이 이미 있다. 그러나 샌패콘은 비용을 관리하고 최적화하는 데 도움이 되는 제품을 생산하는 새로운 핀옵스(FinOps) 기업에 주목한다. 샌패콘은 클라우드 비용 지출을 통제하는 데 사용할 수 있는 툴로 클라우드어빌리티(Cloudability)와 클라우드헬스(CloudHealth)를 언급했다.
 

클라우드별 서비스 독립성 유지하기

샌패콘은 코베오가 씨름 중인 또 다른 클라우드 문제에 대해서도 언급했다. 아마존 서비스에 장애가 발생할 경우 코베오 서비스의 정상 작동을 유지하는 것이다.
 
샌패콘은 “블랙 프라이데이 직전에 AWS에서 키네시스와 관련해 두 번의 큰 사고가 있었다. 키네시스는 코베오가 사용 중인 서비스 중 하나이기도 하지만 AWS 내의 다른 많은 서비스를 위한 중추 서비스이기도 하다”라고 말했다. 이 중단 사고는 코베오의 주 서비스에는 영향을 미치지 않았지만 새 조직을 온보딩하고 일부 유형의 이벤트를 레코딩하는 부분에는 영향을 미쳤다. 코베오는 검색 기업이고 블랙 프라이데이를 전후한 몇 주는 많은 전자상거래 고객이 구매 활동에 나서는 시기다.
 
샌패콘은 코베오의 자체 스트리밍 서비스를 호스팅하는 방법을 고려했지만, 아마존 키네시스 중단 문제로 어려움을 겪는 중에도 과연 코베오가 AWS보다 더 많은 업타임으로, 더 나은 메시징 서비스를, 더 비용 효율적으로 실행할 수 있을지를 자문해야 했다. 가능하다 해도 그것이 과연 효과적인 리소스 사용법일까?
 
고려할 점은 또 있다. 한 클라우드 서비스 제공업체의 서비스를 소비하는 것은 많은 이점이 있지만, 샌패콘은 동시에 구글 클라우드나 마이크로소프트 애저 등의 다른 업체로 쉽게 전환할 수 없음을 의미하기도 한다고 지적했다.
 
가능한 해결책 한 가지는 AWS의 관리형 카프카(Kafka)를 사용하는 것이다. 그러면 코베오는 문제가 발생할 경우 애저의 관리형 카프카 또는 컨플루언트(Confluent)의 구글 클라우드 기반 관리형 카프카로 간단하 전환할 수 있다.
 
아마존 키네시스를 실행하는 편이 아마존의 관리형 카프카를 실행하는 것보다 저렴하므로 클라우드 독립성에는 비용이 따른다. 그러나 혜택도 있다. 특히 많은 전자상거래 사이트의 검색 중추인 기업 관점에서 블랙 프라이데이를 앞둔 시점이나 팬데믹 중에 무언가가 잘못되는 상황을 생각해보면, 그 혜택은 크다.
 
마리아DB(MariaDB)의 스카이SQL(SkySQL) 제품 관리 담당 부사장인 사라바나 크리슈나무르티 역시 어느 클라우드에 특정적인 요소에 의존하지 말아야 한다면서 “솔루션에 내장된 REST API 또는 다른 어떤 API가 있다면 모든 통신이 클라우드 독립적인 API를 거치도록 해야 한다”면서 “이렇게 하면 아마존에서 구글 또는 애저로 전환할 때 애플리케이션과 데이터를 더 편리하게 옮길 수 있다”라고 말했다.
 

클라우드 업체마다 다른 멀티 클라우드 서비스 차이점

코크로치 랩스(Cockroach Labs)의 제품 마케팅 담당 부사장인 짐 워커는 각자 조금씩 다른 방식을 사용하는 클라우드 제공업체들에 의해 발생하는 문제를 지적했다. 코크로치 랩스는 코크로치클라우드(CockroachCloud) 데이터베이스 서비스를 AWS와 구글 클라우드, 양쪽에 구축하면서 둘의 차이점에 대해 많은 것을 알게 됐다.
 
워커는 “서로 전혀 다른 서비스다. 각 플랫폼에서의 사용자 경험을 ‘적절히’ 구현하기 위해 상당한 노력이 필요하다. 컨테이너와 쿠버네티스는 이 복잡성을 간소화하는 데 확실히 도움이 됐지만 여전히 두 플랫폼은 ‘완전히’ 다르게 생각해야 한다”라고 말했다. 워커는 다음과 같이 설명했다.

“예를 들어 쿠버네티스 관리형 서비스는 각 클라우드에서 상당히 다르고 네트워킹의 세세한 부분도 완전히 다르다. 각 클라우드에서 우리가 로드 밸런서를 다루는 방식도 다르다. 또한 한 클라우드에서는 IOPS를 맞춤형으로 설정할 수 있는 데 반해 다른 클라우드에서는 그렇게 할 수 없다. 고객을 위해 VPC(가상 프라이빗 클라우드) 피어링과 같은 기능을 제공하는 경우에도 AWS 프라이빗링크(PrivateLink)를 사용할 때와 기본 클라우드를 사용할 때의 접근 방법이 전혀 다르다. 클라우드 제공업체는 큰 가치를 제공하지만 각 개별 클라우드를 보면 해야 할 일이 많다.”
 

클라우드 보안

마리아DB의 크리슈나무르티 역시 클라우드에서 네트워크 보안의 중요함을 강조하며 “라고객 간 트래픽 간섭을 피해야 한다. 따라서 고객이 퍼블릭 네트워크 및 다른 고객의 트래픽과 격리되는 가상 프라이빗 클라우드를 요구하면 VPC를 격리 수단으로 제공한다”라고 말했다.
 
그러나 누군가가 예를 들어 액티브 디렉터리로 표준화해서 VPC 간에 인증을 할 경우 상황이 복잡해지고, 어려운 구성과 함께 시스템 간에 정책을 역할에 매핑하는 과정이 필요할 수 있다.
 

복잡성, 구성, 규정 준수

소수의 서버를 구성하고 일관성을 유지하는 것만 해도 쉽지 않은 일이다. 데브옵스는 운영과 배포 문제의 간소화를 약속했지만 구성 드리프트(drift)가 발생한다. 또한 구성이 일련의 스크립트로 존재하면서 수백 개의 서버에 적용되는 상황에서는 “누가” 구성을 변경했는지 알기가 어렵다. 일부 업계, 특히 금융 서비스의 경우 이와 같은 감사 증적의 부재가 규정 준수 측면에서 상당한 문제가 된다.
 
깃옵스(GitOps)라는 새로운 기술 및 방법론이 해결책을 제공할 수 있다. 이름에서 알 수 있듯이 깃옵스는 버전 관리 툴인 깃(Git)과 데브옵스를 결합한다. 그러나 깃옵스는 그 이상이다. 구성에 선언적 특성을 부여하고 드리프트를 측정한다. 또한 깃은 감사 증적을 유지한다. 누가 보안을 비활성화했는가? 리포지토리를 보면 그 질문에 답할 수 있다.
 
어느 클라우드 설계자는 “서버가 많을수록 문제도 많아진다”는 말을 했다. 그러나 핀옵스로 비용 효율성을 유지하고 깃옵스로 복잡성에 대처하고 멀티클라우드를 유지해 한 벤더의 장애로 인해 소프트웨어가 멈추는 상황을 방지하고 서비스를 자체 VPC로 격리해서 시스템의 보안과 프라이버시를 지킬 수 있다.
 
CVS를 사용해 유닉스 구성 파일을 확인하는 것이 특별하게 느껴졌던 시대는 지났다(그렇게 하는 모든 유닉스 관리자가 자신은 특별하다고 느꼈다). 지금의 클라우드 세계는 서버와 문제가 모두 늘어났다. 대신 더 좋은 도구도 있다는 점이 위안이다. editor@itworld.co.kr 

X