[Cloud] Kubernetes(쿠버네티스) & DevOps(데브옵스) Intro

이번엔 Kubernetes(쿠버네티스), DevOps가 등장한 이유에 대하여 설명을 해보고자 합니다.

Kubernetes(쿠버네티스)

줄여서 k8s라고도 합니다.

앞글에서 Container(컨테이너)에 대하여 살펴보았습니다. 2013년에 발표된 Docker(도커)는 컨테이너화된 애플리케이션을 패키징하고 배포하기 위한 공개 표준을 제공했습니다.

 

Docker가 기존의 Container(컨테이너) 생태계에 큰 변화를 가져온 것은 사실입니다. 하지만 100개, 1,000개 이렇게 지속적으로 수요가 급증하는 Container(컨테이너)에 대한 관리는 어떻게 조정해야 할까요? 애플리케이션 Container(컨테이너) 간의 네트워킹은 어떤 방식을 사용해야 할까요? Container(컨테이너) Instance(인스턴스)는 과연 확장할 수 있을까요?

 

이러한 문제를 해결하기 위한 Container(컨테이너) Orchestration(오케스트레이션) 도구11개 중 하나가 Kubernetes(쿠버네티스)입니다. Kubernetes(쿠버네티스)는 대규모 클러스터 환경의 수많은 Container(컨테이너)를 쉽고 빠르게 확장, 배포, 관리하는 작업을 자동화해 주는 오픈 소스 플랫폼입니다.

Kubernetes Managed Service

Docker(도커)를 이용한 Container(컨테이너) 기술이 증가하면서 Container(컨테이너) 관리를 위한 도구가 발표되기 시작했습니다. 도커스웜, 아파치 메소스, AWS의 ECS (Elastic Container Service) 등 많은 Orchestration(오케스트레이션) 도구가 나왔고, 그중 하나가 2014년 구글이 자사 서비스 개발을 위한 보그Borg 프로젝트를 통해 얻은 경험을 토대로 만든 Kubernetes(쿠버네티스)입니다.

 

2015년 정식 1.0 버전이 출시되었고, 현재 클라우드 시장은 Kubernetes(쿠버네티스) 중심으로 진행 중이며, 마이크로서비스 아키텍처(Micro Service Architecture), MSA12의 기준도 Kubernetes(쿠버네티스) 사용 여부에 초점을 맞추고 있습니다.

사실상 Container(컨테이너) 화된 애플리케이션에 대한 대규모 배포 작업에 가장 적합한 Orchestration(오케스트레이션) 도구의 표준이라 할 수 있습니다. 이미 대형 퍼블릭 클라우드 공급자들은 ‘Kubernetes Managed Service’를 사용하고 있습니다.

• Amazon Elastic Container Service for Kubernetes(Amazon EKS)

관리형 Kubernetes Service - Amazon EKS - AWS

• Azure Kubernetes Services(AKS)

AKS(관리되는 Kubernetes Service) | Microsoft Azure

• Google Kubernetes Engine(GKE)

https://cloud.google.com/kubernetes-engine

그럼, Kubernetes(쿠버네티스)는 왜 유용할까요? 이유는 아래와 같습니다.

• 온프레미스 환경에서 수행하는 서버 업그레이드, 패치, 백업 등의 작업을 자동화(오토 스케일링, 서비스 디스커버리, 로드 밸런싱 등)하여 인프라 관리보다는 서비스 관리에 집중할 수 있습니다.
• 서비스 사용자는 애플리케이션이 24/7/365 지속되기를 원한다. Container(컨테이너)에 장애 발생 시 자가 회복 self-healing 기능을 통해 곧바로 복제 replica Container(컨테이너)를 생성하여 서비스를 지속할 수 있습니다.
• Container(컨테이너)화를 통해 소프트웨어를 패키지화하면 점진적 업데이트(rolling update)를 통해 다운타임 없이 쉽고 빠르게 릴리스 및 업데이트할 수 있습니다.

이러한 기능 외에도 스토리지 Orchestration(오케스트레이션), 자동화된 빈 패킹(bin packing)등 분산 시스템을 탄력적 으로 운영하기 위한 프레임워크를 제공합니다. Kubernetes(쿠버네티스) 설치와 기능에 대해서는 나중에 자세히 다뤄 보겠습니다.

---

DevOps(데브옵스)

데브옵스(DevOps)는 개발(Development)과 운영(Operations)의 합성어 입니다.

이 두 가지 업무(부서)를 하나의 의미 로 부여한 이유는 무엇일까요? 본인의 업무가 개발이거나 운영을 해본 경험이 있는 사람이라면 이해가 될 수도 있습니다.

 

전통적으로 이러한 업무는 업무 목표와 이해 방향이 다르기 때문에 부딪히는 경우가 많았습니다. 개발 팀은 새로운 서비스 개발 시에 신속하고 빠른 배포에 중점을 두지만, 운영 팀은 안정성, 보안, 고가용성을 유지할 수 있는 서비스 유지가 업무 목표일 것입니다.

 

클라우드 환경에서는 어떨까? 방대한 스케일과 세분화된 서비스를 위해서는 개발과 운영의 협업, 협력 강화가 반드시 필요합니다.

개발 팀은 신규 소프트웨어의 기존 시스템과의 연관성과 의존성에 대한 이해가 필요하고, 운영 팀은 신규 소프트웨어의 동작과 상황에 따른 오류 발생을 이해해야 합니다.

 

즉, 업무 영역을 제한하지 않고 협업과 이해 공유, 책임 공유를 통해 전체 개발 및 Infra(인프라)의 라이프사이클 혁신에 기여할 수 있습니다.

DevOps(데브옵스)는 단순하게 업무, 부서(팀), 방법론, 기술 형태로 제한하지 않습니다. 업무적으로 상충관계 trade-off에 있는 모든 형태에 적용할 수 있습니다.

 

예를 들어, 보안 강화를 위해 암호화 등의 추가 구성을 수행하면 일반적으로 서비스 품질 저하(처리 시간 증가 등)가 발생할 수 있습니다.

보안을 담당하는 사람과 품질 관리를 수행하는 사람 간 소통을 통해 절충과 좋은 서비스의 품질을 보장받을 수 있게 됩니다.

결국, 조직 내의 모든 업무자 간의 소통과 협력은 효율성을 높이고 서비스 품질 향상을 통한 기업의 성장을 가져올 수 있다는 것이 DevOps(데브옵스)의 기본 철학이자 하나의 문화입니다.