포스팅을 앞두고…

포스팅도 뜸했고, 깃 허브의 잔디도 듬성듬성 해졌습니다. 하반기 취업 시즌이라 이력서 이외의 것을 살피기가 어렵네요. 좋은 기업, 많이 배울 수 있는 곳에 가고 싶지만, 경험을 생각하면 조건은 아무렴인가 싶습니다. 되도록 날씨가 더 추워지기 전에 좋은 소식 있었음 좋겠습니다.

쿠버네티스가 인기 있는 이유

저번 포스팅에선 쿠버네티스(Kubernetes)에 대해 간단히 다뤘었는데요. 오늘은 이 쿠버네티스(Kubernetes)라는 기술이 왜 인기가 많은지 얘기해보려 합니다.

마이크로서비스 관리 자동화

우리 FISA 1기(클라우드 엔지니어링) 부트캠프에서 파이널 프로젝트로 마이크로 서비스 아키텍처(Micro Service Architecture)로 애플리케이션을 제작했었는데요. 여러 상황을 고려해서 쿠버네티스(Kubernetes)가 아닌 docker-compose와 Spring Cloud(Eureka, Config, Gateway)를 이용해 마이크로 서비스 아키텍처를 설계 했었습니다.

마이크로 서비스 아키텍처가 떠오르면서 모놀리식 아키텍처에 비해 가지는 장점은 많다고 생각합니다. 하지만, 마이크로 서비스 아키텍처로 어플리케이션을 설계하는 것은 상당히 어려운 일입니다. 마이크로 서비스는 자체적인 개발과 Release 주기를 갖는 별도의 애플리케이션이라는 점이기 때문인데요. 이러한 특징은 마이크로 서비스간 통신과 관련한 모든 문제의 난이도를 높입니다. 응용 프로그램 수가 증가할수록 이 작업이 훨씬 더 어려워집니다.

어플리케이션들이 동일한 컴퓨터에서 실행될 필요가 없다는게 장점이 될수도 있고, 단점이 될수도 있습니다. 장점이 되기 위해선 쿠버네티스(Kubernetes)가 제공하는 자동화를 이용해 시스템이 많은 마이크로서비스의 관리하는 작업을 단순화해야합니다.

클라우드 표준화

지난 10~20년 동안 많은 기업들이 소프트웨어를 로컬 서버에서 클라우드로 옮겼습니다. AWS, GCP 등 클라우드 업체에 어플리케이션이 종속되는 것은 꽤나 두려운일입니다. 물론, 이러한 두려움을 이겨낼만큼의 이점이 충분하고도 넘치긴 합니다.

어플리케이션을 하나의 클라우드 업체에 종속되게 되면, 다른 제공업체로 이동하려는 기업은 기본 클라우드 제공업체의 인프라와 API를 어플리케이션에서 추상화하기 위한 노력을 해야합니다. 보통 비용이나 규정 또는 리스크를 분산하기 위함 등 다양한 이유로 기업들은 클라우드 제공 업체를 변경하게 됩니다.

쿠버네티스(Kubernetes)가 도입이 되고 인기를 얻게 되면서 AWS, IBM, GCP, Azure에서도 쿠버네티스(Kubernetes)를 통합하게 되었는데요. 고객은 Kubernetes에서 제공하는 표준 API를 통해 모든 클라우드 제공업체에 애플리케이션을 배포할 수 있습니다. 따라서 이제는 어플리케이션이 특정 클라우드 공급자의 독점 API에 직접 구축되는 대신 쿠버네티스(Kubernetes)의 API를 기반으로 구축했다면, 비교적 쉽게 다른 클라우드 업체로 이전할 수 있습니다.

글을 마치며

오늘은 쿠버네티스가 인기 있는 이유를 알아봤습니다. 쿠버네티스는 물론이고, 어떤 기술이던 깊이 있게 알면 알수록 기술이 가진 이점을 모두 사용할 수 있는 것 같습니다. 마치 인간의 신체 능력을 100%사용하는 캡틴 아메리카처럼 말이죠. 앞으로도 쿠버네티스 관련 글을 포스팅 하면서 이론적인 부분을 지속히 학습해보려 합니다.