[Kubernetes] 컨테이너 오케스트레이션의 표준과 미래

 

1.  쿠버네티스: 컨테이너 오케스트레이션의 표준

- 구글과 컨테이너 오케스트레이션

 구글은 오래전부터 대규모 컨테이너를 기반으로 한 인프라를 운영해 왔다. 지메일, 구글 검색, 구글 지도와 같은 서비스는 모두 컨테이너 위에서 실행되며, 이를 효율적으로 관리하기 위해 자체적으로 컨테이너 오케스트레이터를 개발했다.

 

(1) 보그에서 쿠버네티스로

구글은 수백만 대의 서버에서 글로벌 서비스를 실행하기 위해 보그(Borg)라는 내부 오케스트레이터를 개발했다. 보그는 컨테이너 스케줄링 및 관리를 중앙에서 처리했지만, 구글 내부 시스템에 종속적이고 외부 공개가 어려웠다.

 

2014년, 구글은 보그와 후속 프로젝트인 오메가(Omega)의 경험을 바탕으로 쿠버네티스(Kubernetes)라는 오픈 소스 오케스트레이터를 발표했다. 쿠버네티스는 무료이면서도 강력한 기능을 제공하며 빠르게 업계 표준으로 자리 잡았다.

 

2017년, 쿠버네티스는 "오케스트레이터 전쟁"에서 승리하며 컨테이너 관리의 사실상 표준으로 자리 잡았다.

 

(2) 쿠버네티스의 주요 장점

자동화와 효율성	- 쿠버네티스는 자동화된 장애 복구, 중앙 집중식 로깅, 모니터링 등 데브옵스의 모범 사례를 반영해 설계되었음. - 이는 시스템 관리 작업의 상당 부분을 자동화하여 팀이 중요한 작업에 집중할 수 있도록 도움.
무중단 배포와 확장성	- 롤링 업데이트: 새로운 컨테이너가 준비될 때까지 이전 버전을 유지하여 서비스 중단을 방지함. - 카나리아 배포 및 블루/그린 배포: 신중한 배포 전략을 통해 리스크를 줄임. - 오토스케일링: 수요 급증 시 컨테이너를 자동으로 늘리고, 수요 감소 시 리소스를 회수함.
비용 효율성	- 유휴 상태의 서버 리소스를 줄이고, 활용도를 극대화함. - 각 클라우드 플랫폼의 로드 밸런서를 활용해 애플리케이션의 이식성과 효율성을 보장함.

 

(3)  쿠버네티스의 한계와 대안

스테이트풀 워크로드의 제약	- 쿠버네티스는 데이터베이스와 같은 스테이트풀 애플리케이션을 처리할 수 있지만, 이를 안정적으로 운영하려면 많은 시간과 엔지니어링 노력이 필요함. - 이 경우, 관리형 서비스가 더 적합할 수 있음.
서버리스 플랫폼의 부상	- FaaS(Function as a Service): AWS 람다와 같은 서버리스 플랫폼은 코드 배포와 인프라 관리를 단순화하며, 짧고 독립적인 작업에 적합함. - 펀테이너(Funtainer): 컨테이너와 서버리스 함수의 혼합 모델로, 쿠버네티스 클러스터 위에서도 실행 가능함.

 

(4) 쿠버네티스의 미래

 쿠버네티스는 이제 클라우드 네이티브 애플리케이션의 필수 요소로 자리 잡았으며, 점차 보편화될 것으로 보인다. 미래에는 관리형 쿠버네티스 서비스가 주류가 되고, 쿠버네티스는 우리가 별도로 인지하지 않는 표준 인프라 기술로 자리 잡을 가능성이 높다.

 

 또한 Knative와 같은 프로젝트는 컨테이너와 함수 간 경계를 흐리며, 클라우드 네이티브 애플리케이션의 새로운 가능성을 열고 있다.

 

2. 클라우드 네이티브란?

 클라우드 네이티브는 클라우드 환경에서 컨테이너, 오케스트레이션, 오픈 소스 소프트웨어를 활용하여 애플리케이션과 서비스를 설계하고 운영하는 방식을 뜻한다. 이 개념은 현대 IT 환경의 핵심으로 자리 잡았으며, 클라우드 네이티브 컴퓨팅 재단(CNCF)을 중심으로 발전해 왔다.

 

(1) CNCF와 클라우드 네이티브 생태계

설립 목적	CNCF는 2015년 클라우드 네이티브 기술과 마이크로서비스 아키텍처를 지원하기 위해 만들어졌음.
주요 역할	오픈 소스 프로젝트를 육성하며 개발자, 클라우드 서비스 제공자, 최종 사용자를 연결하는 커뮤니티를 형성함.
주요 프로젝트	- 쿠버네티스: 컨테이너 오케스트레이션 도구. - 프로메테우스: 모니터링 및 경고 도구. - 엔보이: 서비스 프록시. - 헬름, 플루언트디, GRPC 등 다양한 생태계 구성 요소.

 

(2) 클라우드 네이티브 특징

자동화	- 애플리케이션 배포와 관리 작업을 표준화하고 자동화함. - 운영자의 개입을 최소화하며, 쿠버네티스가 이를 지원하는 대표적인 도구임.
이식성	- 클라우드와 물리적 자원에 구애받지 않고 컨테이너화된 애플리케이션을 다른 노드나 클러스터로 쉽게 이동 가능함.
탄력성 및 확장성	- 분산 아키텍처를 통해 장애를 극복하고 성능 저하를 최소화함. - 오토스케일링을 통해 수요 변화에 따라 애플리케이션을 확장하거나 축소함.
관측가능성	- 분산 시스템 특성상 모니터링과 디버깅이 어려워진다. 이를 보완하기 위해 로깅, 추적, 메트릭 수집 도구를 사용함.
역동성	- 쿠버네티스와 같은 도구를 활용해 무중단 롤링 업데이트, 최적의 리소스 활용 등을 실현함.
분산 아키텍처	- 클라우드 네이티브 애플리케이션은 독립된 마이크로서비스로 구성되며, 이들이 협력해 전체 시스템을 구성함.

 

(3) 클라우드 네이티브와 마이크로서비스

마이크로서비스의 장점	독립적인 서비스로 구성되어 애플리케이션 확장 및 유지보수가 용이함.
단점	분산 시스템의 복잡성으로 인해 설계, 관찰, 장애 관리가 어려워짐.
모놀리스를 클라우드 네이티브로 전환	기존 모놀리스 애플리케이션도 클라우드 환경에서 실행되며 점진적으로 마이크로서비스로 전환할 수 있음.

 

(4) 클라우드 네이티브의 비즈니스 가치

효율성	클라우드 네이티브 기술은 비용 효율성과 리소스 최적화를 통해 비즈니스 가치를 극대화함
유연성	기업은 모놀리스와 마이크로서비스 접근법을 상황에 맞게 조합해 최적의 시스템을 설계할 수 있음.

 

3. 운영의 미래: 변화와 적응

 운영, 인프라 엔지니어링, 시스템 관리는 클라우드 네이티브 시대에도 여전히 필수적인 역할을 한다. 다만, 기술적 요구와 환경이 변화함에 따라 운영 업무는 단순 반복 작업에서 고도화된 문제 해결과 설계 중심으로 변화하고 있다.

 

(1) 운영의 변화 방향

자동화와 고급 문제 해결	- 반복적인 수작업은 자동화 도구가 대체하지만, 이는 운영자가 더 복잡한 문제를 다루는 데 집중할 기회를 제공함. - 분산 시스템의 설계와 분석, 네트워크 및 컨테이너 오케스트레이터에 대한 깊은 이해는 여전히 필수적임.
운영 기술과 코딩 능력의 중요성	- 과거에는 운영 업무가 간단한 스크립트 작업으로 유지될 수 있었으나, 클라우드 환경에서는 소프트웨어 정의 인프라를 이해하고 코드를 다룰 수 있는 능력이 요구됨. - 새로운 기술을 배우지 않으면 뒤처질 가능성이 큼.

 

(2) 분산 데브옵스와 팀 구조의 변화

분산 데브옵스	- 운영 지식의 분산: 운영 팀의 역할이 단일 조직에 집중되지 않고, 각 개발 팀에 운영 전문가가 포함되는 방식으로 전환됨. - 운영 전문가는 네트워킹, 성능 최적화, 장애 복구 등의 지식을 갖춘 개발자 겸 도메인 전문가 역할을 수행해야 함.
데브옵스의 진화	- 개발자와 운영자의 역할 구분이 모호해지면서 두 분야의 협력과 융합이 필수적임. - 소규모 기업이나 스타트업에는 순수한 데브옵스 모델이 적합하지만, 조직이 커질수록 전문화된 중앙 운영 팀이 필요해짐.

 

(3) 중앙 집중식 운영의 지속성

중앙화의 필요성	- 모든 팀이 자체적으로 문제를 해결하거나 도구를 개발하는 것은 비효율적이다. - 공통적인 인프라와 도구를 구축하고 운영하는 중앙 IT 팀이 여전히 필수적이다.
중앙 팀의 역할 변화	- 중앙 팀은 개발 팀이 불필요한 작업에 시간을 소모하지 않도록 지원, 교육, 문제 해결에 중점을 둠. - 중앙 팀의 한계: 중앙 팀은 무한정 확장할 수 없으며, 이를 보완하기 위해 분산된 전문가 그룹이나 컨설턴트를 활용함.

 

(4) 개발자 생산언 엔지니어링(DPE)와 새로운 운영 모델

DPE의 역할	- DPE(Developer Productivity Engineering) 팀은 운영 업무를 지원하며, 개발자가 보다 효율적으로 작업할 수 있는 환경을 제공함. - 주요 업무:   · 인프라 유지보수.   ·  도구 및 플랫폼 구축.   ·  운영 문제 해결.
대규모 조직의 접근 방식	- 중앙 팀과 각 팀 내 사이트 신뢰성 엔지니어(SRE) 배치를 조합한 모델이 대규모 조직에서 효과적임. - SRE는 각 팀의 컨설턴트 역할을 수행하며, 제품 개발과 인프라 운영 사이에서 조율 역할을 함.

 

(5) 맷 클라인의 인사이트

 

• 소규모 팀에서는 중앙 인프라 팀이 효과적으로 기능하지만, 조직이 커질수록 중앙 팀이 모든 인프라를 책임지는 것은 비효율적이다.
• 결론: 중앙 팀과 분산된 운영 전문가의 조화가 중요하다.