컨테이너와 쿠버네티스 환경에 대한 이해

안녕하세요. yeTi입니다.
오늘은 오픈나루에서 진행하는 클라우드 네이티브 비대면 워크샵에 참여한 후기를 공유하고자 합니다.

진행자 : 클라우드 사업팀 박준영, 클라우드 서비스팀 이홍구

컨테이너 기술의 이해

컨테이너 기술은 표준화된 방식으로 서비스를 포장할 수 있는 기술입니다.

Container vs Virtualization 직접도 비교

VM은 부팅시 하드웨어 및 OS 부팅이 필요하기 때문에 분 단위의 시간이 필요하지만, 컨테이너의 경우에는 프로세스만 시작하면 되기 때문에 초단위의 시간만 있으면 됩니다.

따라서 버스팅 이벤트 발생시 컨테이너가 더 빠르게 대응할 수 있는 장점이 있습니다.

가상서버의 고질적인 문제는 거대한 이미지 사이즈, 느린 시작 시간, VM간의 환경 불일치가 있습니다.
이러한 문제를 컨테이너를 통하여 해결할 수 있습니다.

예로 VM상에서는 톰캣을 16개의 인스턴스를 띄울 수 있지만 동일한 환경에서 컨테이너는 40개의 인스턴스를 띄울 수 있습니다.

컨테이너의 역사

컨테이너는 2013년 docker에 의해 시작되었는데요.
이후 구글에서 kubernetes를 개발하고 오픈소스로 제공하면서 급격히 사용되기 시작했습니다.

Google & Kubernetes

구글에서는 이미 대부분의 서비스가 컨테이너로 관리되고 있고 일주일에 20억개의 컨테이너가 배포되고 있습니다.

Container 파일 시스템 (UFS)

컨테이너 이미지는 레이어 구조로 구성되어 있고 변경분만 기록합니다.
이미지간 공통으로 사용하는 레이어는 공유가능하여 디스크 용량을 줄일 수 있습니다.

Immutable Infrastructure

서비스를 운영함에 있어서 잦은 배포, 부하 대응, 시스템 관리 이력에 대한 부담을 가지고 있습니다.

예로 컨피그레이션 드리프트(Configuration Drift)가 있는데요.
운영자가 관리하는 시스템의 엔트로피가 시간이 갈 수록 증가하여 초기 설정과 다른 상태가 되는 현상이 있습니다.

이러한 문제는 지속적인 서비스의 유지보수나 서비스 확장에 있어서 잠재적인 이슈를 발생할 위험이 있는데요.

Immutable Infrastructure를 가져감으로써 해결할 수 있습니다.
요즘 Devops 팀에서 흔하게 요구하는 IaC(Infrastructure as Code)도 이를 기반하여 나온 환경입니다.

즉, 인프라를 코드로 정의하고 서비스의 환경을 컨테이너화 함으로써 다수 서버에 대한 환경을 동일하게 관리할 수 있고 동일한 컨테이너를 사용하여 서비스를 유지할 수 있습니다.
머신 중심의 인프라에서 애플리케니션 중심의 인프라로 전환하는 근간이 됩니다.

개발자와 컨테이너 기술

개발자는 컨테이너 기술을 활용하여 개발환경을 일관성을 유지하고, 배포시에도 동일할 환경을 유지할 수 있습니다.

Auto Healing

Auto Healing이란? 컨테이너 환경에서 애플리케이션 장애가 발생할 때 자체적으로 장애를 감지하고 자동으로 복구하는 것을 의미합니다.

Kubernetes에서는 Control loop 메카니즘을 가지고 있어 현재 상태를 모니터링하면서 설정한 상태로 유지할 수 있습니다.
Pod이 불능상태로 변하거나 Pod내 프로세서가 불능상태가 되면 kubernetes controller는 이를 감지하여 pod을 재구동해줍니다.

멀티 애플리케이션 환경에서 부하에 따른 자동 리소스 할당

Kubernetes에서는 pod의 리소스 상태에 따른 Auto-Scaling 기능을 제공하는데요.
CPU 사용량과 pod의 수를 정의함으로써 리소스의 부하증가에 따라 pod의 자동으로 증가하도록 할 수 있습니다.

컨테이너 상에서의 서비스 무중단 배포 방법

Kubernetes에서는 스케쥴러가 pod을 노드에 할당하면, kubelet이 컨테이너 런타임으로 컨테이너를 만들기 시작합니다.
이 때, 컨테이너는 waiting, running, terminated 상태를 가집니다.

readinessProbe(waiting에서 running으로 넘어가는 설정)와 lifecycle(terminate를 위한 설정) 옵션을 적절하게 설정하면 트래픽을 끊기지 않고 서비스를 배포할 수 있습니다.

MSA 적용 예시

쿠팡의 개선사례를 예로 들 수 있습니다.

기존 서비스의 문제점은 다음과 같았습니다.

• 부분 장애가 전체 서비스 장애로 이어지는 경우가 있음
• 서비스를 부분적 scale-out하기 어려움
• 서비스 변경이 어렵고, 수정시 영향도를 파악하기 어려움
• 작은 변경에도 많은 테스트가 필요함
• 조직이 성장할수록 배포 대기시간이 비약적으로 증가함

MSA로 전환 후 장점은 다음과 같습니다.

• 부분 장애가 전체 서비스 장애가 되지 않음
• 서비스를 부분적 Scale-out하기 쉬움
• 신기술 적용이 쉬움(각 팀별로 별도 진행)
• 각 팀별로 변경사항을 빠르게 적용할 수 있음

MSA로 전환 후 단점은 다음과 같습니다.

• 테스트가 어려움(다른 팀 API 테스트 필요)
• 장애 추적이 어려움(비동기 처리시 더 어려움)
• 트랜잭션 관리가 어려움
• 담당자를 찾기 어려움

MSA 트래픽 관리

Route설정을 통하여 특정 사용자에게 특정 버전의 API를 사용하도록 가능합니다.

이를 응용하여 카나리 배포나 점진적 배포를 할 수 있습니다.