쿠버네티스?

몇 년 전만 하더라도 대부분의 소프트웨어 어플리케이션은 단일 프로세스로 실행되거나 소수의 서버에 분산된 적은 수의 프로세스로 실행되는 거대한 모놀리식 어플리케이션이었다. 이런 레거시 시스템은 릴리즈 주기가 느리고 상대적으로 드물게 업데이트된다. 개발자는 릴리즈 주기가 끝날 때마다 전체 시스템을 패키지로 만들어 운영팀에 넘기고 운영팀은 이를 배포하고 모니터링한다. 하드웨어 장애가 발생하면 운영팀은 사용 가능한 서버로 직접 마이그레이션한다. 

 

현재 거대한 모놀리식 레거시 어플리케이션은 점차 마이크로서비스라는 더 작고 독립적으로 실행 가능한 구성 요소로 쪼개졌다. 마이크로서비스는 서로 분리되어 있기 떄문에 개별적으로 개발, 배치, 업데이트, 확장을 할 수 있다. 따라서 오늘날 급변하는 비즈니스 요구 사항을 충족시킬 수 있을 만큼 자주, 신속하게 구성 요소를 변경할 수 있다. 

 

하지만 배포 가능한 구성 요소의 수가 증가하고 데이터 센터의 규모가 커지면서 전체 시스템을 원활하게 구성, 관리, 유지하는 것이 점점 어려워졌다. 리소스를 효율적으로 사용해 하드웨어 비용을 낮추려먼 각 구성 요소를 어디에 배치해야 하는지 파악하는 것이 훨씬 더 어렵다. 서버의 구성 요소를 자동으로 스케줄링하고, 자동으로 구성하고, 감독하고, 오류를 처리하는 자동화가 필요해진 것이다. 이것이 바로 쿠버네티스가 등장한 이유이다. 

 

쿠버네티스를 사용하면 운영팀의 도움을 받지 않고도 어플리케이션을 원하는 만큼 자주 배포할 수 있다. 그렇다고 해서 쿠버네티스가 개발자에게만 도움이 되는 것은 아니다. 하드웨어 장애 발생 시 해당 어플리케이션을 자동으로 모니터링하고 일정을 조정해 운영팀을 도와주기도 한다. 시스템 관리자의 관심은 개별 어플리케이션을 감독하는 것에서 쿠버네티스와 나머지 인프라를 감독하고 관리하는 것으로 옮겨가고, 그 대신 쿠버네티스가 어플리케이션을 관리해준다. 

 

쿠버네티스는 하드웨어 인프라를 추상화해 전체 데이터 센터를 하나의 거대한 계산된 리소스로 제공한다. 이 기능을 사용하면 실제 서버의 세부 사항을 알 필요 없이 소프트웨어 구성 요소를 배포하고 실행할 수 있다. 쿠버네티스가 여러 컴포넌트로 구성된 어플리케이션을 배포할 떄 각 구성 요소에 맞는 서버를 선택해 배포하고 어플리케이션이 다른 모든 구성 요소를 쉽게 찾고 통신할 수 있게 한다. 

 

쿠버네티스를 대부분의 온프레미스 데이터 센터에 적합하지만, 클라우드 제공 업체가 구축하고 운영하는 것과 같은 대규모 데이터 센터에 사용되는 경우 더욱 큰 효과를 발휘한다. 쿠버네티스는 개발자가 모든 유형의 어플리케이션을 배포하고 실행할 수 있는 간단한 플랫폼을 제공할 수 있으며, 클라우드 제공업체의 시스템 관리자가 하드웨어에서 실행되는 수만 가지의 어플리케이션을 모두 알 필요는 없다. 

 

점점 더 많은 대기업에서 어플리케이션을 실행하는 최선의 방법으로 쿠버네티스 모델을 채택하고 있다. 쿠버네티스는 클라우드와 로컬의 온프레미스 인프라에서 분산된 어플리케이션을 실행하는 표준 방식이 되어 가고 있다.