2021.04.22

매니지드 쿠버네티스로 전환해야 하는 6가지 이유

Scott Carey | InfoWorld
쿠버네티스 클러스터를 매니지드 서비스 업체에 넘기는 것은 아이를 대학에 보내는 것과 비슷하다. 처음에는 걱정도 되지만, 결국 집안에서 할 일이 확 줄어든다. 

빅 3 퍼블릭 클라우드 서비스 업체인 아마존 웹 서비스(AWS), 구글 클라우드, 마이크로소프트 애저의 매니지드 쿠버네티스 옵션(또는 서비스형 쿠버네티스, KaaS)은 모두 지난 몇 년 동안 큰 발전을 이루었다. 이제 기업은 복잡한 YAML 구성 파일, 자동 확장, 업데이트, 클러스터 관리에 대한 부담 없이 컨테이너화된 워크로드를 실행하고 조율할 수 있다. 
 
ⓒ Getty Images Bank

개발자 중심의 시장 분석 업체 레드몽크(RedMonk)의 공동 창업자인 스티븐 오그레이디는 “기업은 전략적인 것을 고려할 때 처음에는 스스로 하려는 경향이 있다. 이후 시간이 지나면서 이 방식이 아무런 경쟁 우위를 제공하지 않으며, 서비스 업체에 맡기는 편이 낫다는 사실을 인식한다. 모든 기업이 서비스형으로 전환하고 있을까? 아직은 아니지만 전환을 향한 욕구와 방향은 명확해 보인다”고 말했다. 

매니지드 쿠버네티스 서비스를 고려해야 할 6가지 이유를 알아보자. 
 

1. 낮은 관리 부담 

명백한 이유부터 시작해 보자. 여행 기술 업체 아마데우스의 기술 플랫폼 및 엔지니어링 부문 수석 부사장인 실베인 로이는 “할 일이 더 적다는 것은 명확하다. 알아서 운영된다는 것은 우리 회사에 중요하다. 쿠버네티스를 직접 운영하려면 필요한 모든 인력을 확보해야 한다는 어려움이 있다”고 지적했다. 

건설업체 스트라백(Strabag)의 소규모 엔지니어 그룹은 2006년부터 자체적으로 컨테이너를 운영해오고 있으며 지난 4년 동안은 자체 관리 오픈소스 도커(Docker) 및 쿠버네티스로 전환 중이다. 현재 이 그룹은 기존 앱을 현대화하고 기반이 되는 쿠버네티스 클러스터 관리를 구글 클라우드에 맡기거나, 개발자가 클라우드나 하이브리드 환경에서 안토스(Anthos) 서비스를 사용해 새로운 애플리케이션을 실행할 수 있도록 하는 방법으로(특히 온프레미스 데이터 전송이 필요한 경우) 클러스터 관리의 최대한 많은 부분을 자동화하는 중이다. 

스트라백의 클라우드 서비스 부문 팀장인 마리오 클라이나서는 “덜어내는 편이 더 나은 작업은 덜어내는 쪽으로 가고 있다”고 말했다. 

마찬가지 이유로 블룸버그의 컴퓨팅 인프라 책임자 안드레이 리브카는 “SRE(Software Reliability Engineering)팀 또는 쿠버네티스 릴리즈 사이클을 관리하는 팀이 없고 쿠버네티스 관리를 원하지 않고 앱 실행에 초점을 두려는 기업이라면, 서비스 업체를 활용하는 편이 합리적”이라고 설명했다. 블룸버그는 쿠버네티스 워크로드의 대부분을 여전히 온프레미스에서 실행 중이지만, 적절한 부분에서 매니지드 워크로드를 위해 최근부터 3대 클라우드 서비스 업체를 모두 사용하고 있다. 
 

2. 전문가 필요성 감소 

쿠버네티스 관리 기술은 어렵고 관련 인건비도 높다. 특히 YAML 구성 파일을 직접 작성하는 경우는 더 어렵다. 쿠버네티스 클러스터를 수동으로 튜닝할 기술력을 갖춘 인력이 있다면, 일반적인 워크로드를 위한 클러스터 관리를 위탁해서 이들에게 내부 플랫폼 또는 특별히 중요하거나 까다로운 워크로드를 관리할 시간 여유를 확보해 주는 것이 좋다. 

아마데우스의 로이는 “이와 같은 기술을 가진 인력을 구하기도, 유지하기도 쉽지 않다. 확실히 어려운 일”이라고 덧붙였다. 
 

3. 더 높은 안정성 

간단히 말하자면, 거대 클라우드 서비스 업체는 엔지니어링팀의 규모, 광범위한 고객 기반 환경과 이러한 환경에 대한 텔레메트리 접근성 등 기업보다 쿠버네티스 클러스터를 관리하기에 더 유리한 조건을 갖추고 있다. 

레드몽크의 오그레이디는 “대부분의 경우 서비스 업체가 더 잘 운영할 수 있다. 텔레메트리가 있고, 자체 모델 하나만 다루는 기업과 달리 쿠버네티스를 실행하는 모든 고객을 볼 수 있다는 점도 유리하다”고 강조했다.

블룸버그의 경우 쿠버네티스가 아직 알파 릴리즈에 불과했던 2015년의 어수선한 시점에 쿠버네티스를 채택했고, 필요한 지속적 통합과 모니터링 및 테스트가 검증된 후 2017년 프로덕션으로 전환했다. 온프레미스 애플리케이션을 위한 쿠버네티스 클러스터의 대부분은 여전히 블룸버그 엔지니어가 자체 관리하고 있지만, 워크로드가 퍼블릭 클라우드에 있는 경우 특히 “안정성 관점에서” 매니지드 옵션을 사용할 만한 이유가 갈수록 커지고 있다. 
 

4. 업그레이드와 패치에 대한 걱정 끝 

업그레이드와 패치는 자체 쿠버네티스를 관리하는 모두가 가장 기피하는 두 가지 일이다. 그래서 매니지드 서비스 업체는 이 두 가지 작업을 최우선 순위에 둔다. AWS의 컴퓨팅 서비스 부문 무사장인 디팩 싱은 “쿠버네티스를 직접 패치, 업데이트, 관리하는 것은 복잡하고 힘들면서 차별화와는 전혀 무관한 일”이라고 지적했다.
 




2021.04.22

매니지드 쿠버네티스로 전환해야 하는 6가지 이유

Scott Carey | InfoWorld
쿠버네티스 클러스터를 매니지드 서비스 업체에 넘기는 것은 아이를 대학에 보내는 것과 비슷하다. 처음에는 걱정도 되지만, 결국 집안에서 할 일이 확 줄어든다. 

빅 3 퍼블릭 클라우드 서비스 업체인 아마존 웹 서비스(AWS), 구글 클라우드, 마이크로소프트 애저의 매니지드 쿠버네티스 옵션(또는 서비스형 쿠버네티스, KaaS)은 모두 지난 몇 년 동안 큰 발전을 이루었다. 이제 기업은 복잡한 YAML 구성 파일, 자동 확장, 업데이트, 클러스터 관리에 대한 부담 없이 컨테이너화된 워크로드를 실행하고 조율할 수 있다. 
 
ⓒ Getty Images Bank

개발자 중심의 시장 분석 업체 레드몽크(RedMonk)의 공동 창업자인 스티븐 오그레이디는 “기업은 전략적인 것을 고려할 때 처음에는 스스로 하려는 경향이 있다. 이후 시간이 지나면서 이 방식이 아무런 경쟁 우위를 제공하지 않으며, 서비스 업체에 맡기는 편이 낫다는 사실을 인식한다. 모든 기업이 서비스형으로 전환하고 있을까? 아직은 아니지만 전환을 향한 욕구와 방향은 명확해 보인다”고 말했다. 

매니지드 쿠버네티스 서비스를 고려해야 할 6가지 이유를 알아보자. 
 

1. 낮은 관리 부담 

명백한 이유부터 시작해 보자. 여행 기술 업체 아마데우스의 기술 플랫폼 및 엔지니어링 부문 수석 부사장인 실베인 로이는 “할 일이 더 적다는 것은 명확하다. 알아서 운영된다는 것은 우리 회사에 중요하다. 쿠버네티스를 직접 운영하려면 필요한 모든 인력을 확보해야 한다는 어려움이 있다”고 지적했다. 

건설업체 스트라백(Strabag)의 소규모 엔지니어 그룹은 2006년부터 자체적으로 컨테이너를 운영해오고 있으며 지난 4년 동안은 자체 관리 오픈소스 도커(Docker) 및 쿠버네티스로 전환 중이다. 현재 이 그룹은 기존 앱을 현대화하고 기반이 되는 쿠버네티스 클러스터 관리를 구글 클라우드에 맡기거나, 개발자가 클라우드나 하이브리드 환경에서 안토스(Anthos) 서비스를 사용해 새로운 애플리케이션을 실행할 수 있도록 하는 방법으로(특히 온프레미스 데이터 전송이 필요한 경우) 클러스터 관리의 최대한 많은 부분을 자동화하는 중이다. 

스트라백의 클라우드 서비스 부문 팀장인 마리오 클라이나서는 “덜어내는 편이 더 나은 작업은 덜어내는 쪽으로 가고 있다”고 말했다. 

마찬가지 이유로 블룸버그의 컴퓨팅 인프라 책임자 안드레이 리브카는 “SRE(Software Reliability Engineering)팀 또는 쿠버네티스 릴리즈 사이클을 관리하는 팀이 없고 쿠버네티스 관리를 원하지 않고 앱 실행에 초점을 두려는 기업이라면, 서비스 업체를 활용하는 편이 합리적”이라고 설명했다. 블룸버그는 쿠버네티스 워크로드의 대부분을 여전히 온프레미스에서 실행 중이지만, 적절한 부분에서 매니지드 워크로드를 위해 최근부터 3대 클라우드 서비스 업체를 모두 사용하고 있다. 
 

2. 전문가 필요성 감소 

쿠버네티스 관리 기술은 어렵고 관련 인건비도 높다. 특히 YAML 구성 파일을 직접 작성하는 경우는 더 어렵다. 쿠버네티스 클러스터를 수동으로 튜닝할 기술력을 갖춘 인력이 있다면, 일반적인 워크로드를 위한 클러스터 관리를 위탁해서 이들에게 내부 플랫폼 또는 특별히 중요하거나 까다로운 워크로드를 관리할 시간 여유를 확보해 주는 것이 좋다. 

아마데우스의 로이는 “이와 같은 기술을 가진 인력을 구하기도, 유지하기도 쉽지 않다. 확실히 어려운 일”이라고 덧붙였다. 
 

3. 더 높은 안정성 

간단히 말하자면, 거대 클라우드 서비스 업체는 엔지니어링팀의 규모, 광범위한 고객 기반 환경과 이러한 환경에 대한 텔레메트리 접근성 등 기업보다 쿠버네티스 클러스터를 관리하기에 더 유리한 조건을 갖추고 있다. 

레드몽크의 오그레이디는 “대부분의 경우 서비스 업체가 더 잘 운영할 수 있다. 텔레메트리가 있고, 자체 모델 하나만 다루는 기업과 달리 쿠버네티스를 실행하는 모든 고객을 볼 수 있다는 점도 유리하다”고 강조했다.

블룸버그의 경우 쿠버네티스가 아직 알파 릴리즈에 불과했던 2015년의 어수선한 시점에 쿠버네티스를 채택했고, 필요한 지속적 통합과 모니터링 및 테스트가 검증된 후 2017년 프로덕션으로 전환했다. 온프레미스 애플리케이션을 위한 쿠버네티스 클러스터의 대부분은 여전히 블룸버그 엔지니어가 자체 관리하고 있지만, 워크로드가 퍼블릭 클라우드에 있는 경우 특히 “안정성 관점에서” 매니지드 옵션을 사용할 만한 이유가 갈수록 커지고 있다. 
 

4. 업그레이드와 패치에 대한 걱정 끝 

업그레이드와 패치는 자체 쿠버네티스를 관리하는 모두가 가장 기피하는 두 가지 일이다. 그래서 매니지드 서비스 업체는 이 두 가지 작업을 최우선 순위에 둔다. AWS의 컴퓨팅 서비스 부문 무사장인 디팩 싱은 “쿠버네티스를 직접 패치, 업데이트, 관리하는 것은 복잡하고 힘들면서 차별화와는 전혀 무관한 일”이라고 지적했다.
 


X