[Kubernetes] 컨테이너를 쓰는 이유?

대부분의 기업에서 컨테이너 & Kubernetes를 거의 표준처럼 도입하고 있습니다. 이유가 뭘까요?

컨테이너의 이점

기존 온프렘(VM) 환경에서는 개발자들이 개발한 산출물을 (WAR 또는 classes) 파일을 톰캣 같은 WAS에 집어넣고 재기동 했습니다.

이 과정에서 서비스를 막기 위해 사람이 수동으로 L4에서 라우팅을 빼거나, web 서버를 내리고 was만 재기동 하는식으로 재기동하기도 합니다.

그리고 결국 이 모든건 사람이 개입하게 되고 이 과정에서 서버의 설정 또는 산출물 누락 등.. 환경에 따른 이슈가 필연적으로 생깁니다.

작업이 복잡하기에 휴먼 에러를 방지하기 위해 배포작업서 같은 추가 절차(?)를 도입하는 등 배포는 날이 갈수록 무거워지는 경향이 있습니다..

급변하는 IT 업계에서 이런 무거운 배포는 시장의 흐름에 따라가기 매우 힘든 것도 사실입니다.

이를 극복하기 위해 컨테이너 & Kubernetes를 도입합니다.

컨테이너 & Kubernetes 도입 효과

1. 내 PC에서는 됐는데요? 방지

컨테이너는 안에 소스 코드 + 라이브러리 + JDK + 실행에 필요한 프로그램이 모두 묶여 있습니다. 어느 환경에서든지 실행가능한 높은 이식성을 가지고 있습니다.

개발자의 로컬 PC 검증, 개발 서버 검증, 운영 서버 검증까지 모두 같은 이미지로 검증이 되어 산출물 누락이나 환경 설정 오류 등 휴먼 에러가 발생할 확률이 급감합니다.

2. 배포 야근 생략

배포 중 무중단을 보장하기 위해 수동으로 WEB 서버 또는 L4를 고쳐 재기동 서버에는 고객 트래픽이 흐르지 않게 작업하고, 배포 후 서비스가 이상이 있다면 급하게 개발자가 코드를 수정하여 다시 배포를 해야합니다. 이 과정에서 혹시나 고객 영향을 최소화 하기 위해 배포는 반드시 야간/새벽에 집중됩니다.

컨테이너의 경우 배포는 rollout restart 한 방을 통해 무중단 배포가 됩니다. 또한 개발자가 급하게 수정을 하지 않고 이전 image로 롤백을 하면 됩니다. (이 또한 무중단)

더이상 배포로 밤을 지내지 않아도 됩니다.

3. 초병 근무 생략

24시간 제공되는 IT 서비스는 언제 이슈가 터져도 이상하지 않습니다.

기존에는 프로세스가 죽거나 응답이 없으면 인프라 및 IT 담당자가 언제나 노트북을 소지한 채로 있다가 재기동을 해줬어야 했습니다.

쿠버네티스 환경에서는 기본적으로 비정상 종료시 자동적으로 재시작을 합니다. 또한 probe가 지속적으로 Pod에 health check를 합니다. 트래픽을 처리 못하거나 응답이 없을 경우 트래픽을 보내지 않거나(readinessProbe) 컨테이너(pod)를 재기동(livenessProbe)하는 시스템을 가지고 있습니다.

startupProbe: Spring 같이 기동시간이 오래걸리는 서비스들은 livenessProbe가 멋대로 재시작시키는것을 방지하기 위해 설정 시간동안 다른 probe 영향을 막아줍니다.

이게 가능한 이유?

컨테이너가 이런 강점을 제공하는 이유 중 하나는 격리와 경량화입니다.

호스트와 커널은 공유하면서 프로세스는 격리하는 이 기술은 Linux Namespace로 프로세스는 분리하고 cgroup으로 자원 사용량을 제한하는 식으로 하나의 독립된 VM처럼 보이게 합니다.

그렇기에 마치 VM 같지만 게스트 OS를 띄우는 기존의 VM 보다 훨씬 빠르게 기동합니다.

다만 이런 장점을 갖추면서 파일 시스템이 별도로 없는 휘발성을 가지게 되었기에, Redis 같은 외부 저장소에 상태를 저장하고 로그는 별도의 중앙 수집 처리 장치가 필수적입니다.

그리고 컨테이너가 많아지면 결국 운영 난이도가 높아지는데 이때 등장한 오케스트레이션 서비스가 쿠버네티스입니다.

그래서 필수인가?

등가교환의 법칙처럼.. 얻는게 있으면 치르는 비용이 있습니다.

배포, 복구, 자동화를 얻음으로써 이를 관리해야하는 비용이 있습니다. 얼마나 권한을 줘야할지 RBAC 문제와 장애시 앱이 문제인지 플랫폼 문제인지 관리해야할 포인트가 더 늘어납니다.

또한 새로운 기술 도입으로 러닝 커브가 높아집니다. 쿠버네티스의 개념 및 YAML 관리 그리고 휘발성에 따른 로그 유실로 이슈 발생시 추적 난이도가 더 높아집니다.

즉 정리하면 서비스 안정성을 얻는 대신 이에 대한 관리에 대한 비용이 커집니다. 워크로드가 작고 배포가 잦지 않다면 기존의 온프레미스 환경이나 PaaS 서비스를 이용하는게 더 적절하여 보입니다.