쿠버네티스와 결별했더니 달라진 것들

학습 차원에서 틈틈이 해외 전문가들이 블로그나 미디어 그리고 책에서 쓴 글을 번역 또는 요약 정리하고 있습니다. 이번 포스팅도 그중 하나고요. 거칠고 오역된 부분이 있을 수 있습니다. 제대로 번역되지 않은 부분은 확인 주시면 반영토록 하겠습니다. 의미 전달이 애매한 문장은 삭제했습니다. 이번에는 Crafting-Code가 미디엄에 올린 내용을 정리한 것입니다.

6개월 전 우리 DevOps 팀은 복잡성의 늪에 빠져 있었다. 3개 클라우드 업체들 47개 Kubernetes 클러스터를 관리하고 있었다. 엔지니어들은 주말에도 근무했다. 그러다가 당시에는 미친 짓처럼 보였던 결정을 내렸다. 스택에서 Kubernetes를 제거하기 시작했다. 지금 우리 배포 성공률은 89%까지 상승했다. 인프라 비용은 62% 감소했다. 그리고 2년 만에 처음으로 DevOps 팀이 중단 없이 휴가를 가기도 했다. 

우리는 3년 전 확장성, 유연성, 자동화에 대한 약속에 이끌려 Kubernetes를 사용하기 시작했다.처음에는 잘 작동했지만 플랫폼이 성장하면서 몇 가지 문제에 직면했다.

Kubernetes의 꿈 vs 현실

많은 기업들과 마찬가지로 우리도 3년 전에 Kubernetes 흐름에 뛰어들었다. 그 약속은 매력적이었다:

대규모 컨테이너 오케스트레이션

클라우드 네이티브 아키텍처

코드형 인프라

자동화된 확장 및 복구

그리고 Kubernetes는 이러한 약속을 이행했다. 하지만 아무도 말하지 않았던 숨겨진 비용이 발생했다.

한계

2023년 블랙 프라이데이에 한계가 왔다. 아래 같은 환경이었음에도

8명 선임 DevOps 엔지니어

3개 전담 SRE 팀

연중무휴 24시간 당직 근무

엔터프라이즈 지원 계약

광범위한 모니터링 설정

여전히 이런 것들을 경험했다:

중대한 중단 3건

오탐 알림 147건

긴급 배포 23건

팀원 2명이 번아웃을 이유로 퇴사

뭔가 바뀌어야 했다.

Kubernetes 실제 비용

실제 비용을 분석해 보니 그 수치는 충격적이었다:

인프라 오버헤드

 Kubernetes 구성 요소를 실행하는 노드들 중 40%

컨트롤 플레인 비용만 월 $25,000

고가용성을 위한 3배 이중화

인적 비용:

신규 데브옵스 채용 시 적절한 교육에 3개월 소요

유지보수에 소요되는 데브옵스 시간 중 60%

대기 중 인시던트 30% 증가

12개월 동안 숙련된 엔지니어 4명 퇴사

숨겨진 복잡성:

기본 배포를 위한 200개 이상 YAML 파일

5개에 달하는 서로 다른 모니터링 도구

3개 개별 로깅 솔루션

지속적인 버전 호환성 문제

대안

소규모로 시작했다. 가장 중요도가 낮은 서비스를 골라 더 간단한 스택으로 옮겼다:

컨테이너 오케스트레이션을 위한 AWS ECS

인프라를 위한 CloudFormation

가능한 경우 관리형 서비스

배포를 위한 간단한 셸 스크립트

결과는 바로 나타났다:

배포 시간: 15분 → 3분

인프라 파일: 200+ → 20

월 비용: $12,000 → $3,200

알림 소음: 80% 감소

전체 마이그레이션

초기 결과에 고무되어 4개월 마이그레이션 계획을 수립했다:

1단계: 감사 및 평가

모든 서비스 및 종속성 매핑

중요 워크로드와 중요하지 않은 워크로드 식별

실제 운영 비용 계산

문제점 문서화

2단계: 대안 아키텍처

각 워크로드에 적합한 도구를 선택했다:

단순 앱 → AWS ECS/Fargate

스테이트풀 서비스 → Docker가 포함된 EC2

배치 작업 → AWS 배치

이벤트 중심 → 람다

3단계: 점진적 마이그레이션

중요하지 않은 서비스부터 시작

한 번에 한 서비스 그룹씩 이동

초기에는 병렬 시스템 실행

성능 메트릭 수집

4단계: 팀 재구성

전문화된 역할 축소

팀원 교차 교육

당직 교대 간소화

문서 업데이트

6개월 후 결과

기술적 개선:

인프라 비용 58% 절감

평균 배포 시간 89% 단축

프로덕션 인시던트 73% 감소

알림 노이즈 91% 감소

팀 혜택

주말 배포 제로

대기 중 인시던트 82% 감소

번아웃 관련 퇴사자 없음

새로운 팀원의 빠른 온보딩

비즈니스 영향

47% 더 빠른 기능 제공

99.99% 가동 시간 유지

DevOps 채용 시간 60% 단축

연간 $432,000 인프라 비용 절감

Kubernetes를 사용해야 할 때와 사용하지 말아야 할 때

Kubernetes는 나쁘지 않다. 다만 지나치게 처방된 것일 뿐이다. 다음과 같은 경우에 Kubernetes가 필요할 수 있다:

수천 개 마이크로서비스를 실행하는 경우

복잡한 자동 확장이 필요한 경우

멀티클라우드 요구 사항이 있는 경우

고급 배포 패턴이 필요한 경우

다음과 같은 경우에는 Kubernetes가 필요하지 않을 수 있다:

서비스가 20개 미만인 경우

규모를 예측할 수 있는 경우

주로 관리형 서비스를 사용하는 경우

팀 규모가 작은 경우(DevOps 5명 미만)

이제 우리가 집중하는 건 다음과 같다.:

가능한 경우 관리형 서비스 사용

유연성보다 단순성을 선택

필요한 부분만 자동화하기

투명한 운영 유지

중요한 포인트들

기본에 의문을 제기하라:

거대 기술 기업이 사용한다고 해서 여러분도 사용해야 한다는 의미는 아니다.

복잡한 솔루션은 종종 해결하는 것보다 더 많은 문제를 야기한다.

팀 복지를 포함한 전체 비용을 고려하라.

도구 크기를 적절히 조정하라:

간단하게 시작하고 필요할 때 확장하라.

지루한 문제에 지루한 기술 사용

팀 규모와 전문성 고려

팀의 행복을 중시하라:

행복한 팀이 생산적인 팀이다.

단순한 시스템은 유지 관리가 쉬운 시스템

화재 진압에 소요되는 시간을 줄이면 혁신에 더 많은 시간을 투자할 수 있다. 때로는 복잡성을 추가하는 것보다 제거하는 것이 엔지니어링적으로 가장 좋은 결정일 때가 있다. Kubernetes를 떠나기로 한 “미친” 결정은 우리가 내린 최고의 기술적 선택 중 하나였다. Kubernetes가 나쁘다는 말인가? 아니다. 우리를 포함한 많은 팀에서 Kubernetes가 가져다주는 복잡성이 그 이점보다 더 크다는 말이다. 그리고 때로는 이 단순한 진실을 인정하는 것만으로도 엔지니어링 조직 전체가 변화할 수 있다.

Kubernetes에서 벗어난 경험을 공유했을 때 촉발된 토론에 놀랐다. 많은 독자분들이 아키텍처, 비용, 접근 방식에 대해 타당한 질문들을 제기했다. 아래 수정본은 누락된 맥락을 제공하고, 오해를 바로잡고, 결정이 어떻게 발전했는지 명확히 설명하기 위해 작성했다.

왜 47클러스터인가?

가장 많이 받는 질문 중 하나가 바로 이 질문이다: 왜 47개 클러스터인가? 그 숫자가 많아 보일 수도 있지만, 이렇게 많은 클러스터를 보유하게 된 이유는 다음과 같다:

1. 보안과 안정성을 위한 격리

중요한 서비스를 위한 각 환경(개발, 스테이징, 프로덕션)에는 자체 전용 Kubernetes 클러스터가 들이 있었따. 네임스페이스를 사용하지 않는 이유? 처음에는 클러스터가 더 나은 내결함성과 보안을 제공할 것이라고 믿고 격리를 위해 클러스터를 사용했다.. 돌이켜보면 이는 불필요하고 지나치게 복잡했다.

2. 멀티 클라우드 전략

단일 클라우드 제공업체에 종속되고 싶지 않았기 때문에 AWS, GCP, Azure에 클러스터를 분산시켰다. 이로 인해 중복성이 증가했고 복잡성도 증가했다.

3. 서비스 성장

마이크로서비스 수가 증가함에 따라 각 서비스마다 전용 클러스터가 생기는 경우가 많았다. 조기에 충분히 통합하지 않아서 활용도가 낮은 리소스를 가진 클러스터가 너무 많은 상황으로 이어졌다. 요컨대, 조직 의사 결정과 리소스 격리에 대한 지나치게 신중한 접근 방식이 지속 불가능한 클러스터 수로 이어진 것이다.

왜 47개 클러스터에 25,000달러를 지불해야 할까? 47개 클러스터에 대해  월 $25,000 비용을 책정하게 된 배경은 다음과 같다:

1. 컨트롤 플레인 비용

우리는 관리형 Kubernetes 서비스 (예: AWS EKS, GKE, AKS)를 사용하고 있었다.

관리형 Kubernetes 서비스는 일반적으로 컨트롤 플레인 관리 비용을 청구합니다. 컨트롤 플레인 관리에 대한 평균 비용은  클러스터당 월 약 $500(대략)이다. 47개 클러스터의 경우, 월 $23,500(대략)이 추가된다.

2. 엔터프라이즈 지원 계획

각 클라우드 제공업체(AWS, GCP, Azure)에 대해 엔터프라이즈급 지원을 사용했다. 이러한 플랜 비용은 사용량에 따라 제공업체당 월 $1,000~$1,500 정도다. 이로 인해 총 비용에  월 2,000~3,000달러가 추가됐다.

3. 고가용성 및 이중화

고가용성과 내결함성을 보장하기 위해 여러 가용성 영역에서 클러스터를 실행하고 다중 지역 배포를 구현했다. 이러한 이중화는 더 많은 인스턴스와 추가 인프라가 필요했기 때문에 비용이 증가했다. 요약하면,  월 25,000달러는 주로 컨트롤 플레인 비용 (약 23,500달러)과 지원 계획 (1,500~2,000달러)과 함께 고가용성 설정 및 멀티 클라우드 배포로 인한 오버헤드에 의해 결정됐다.

인프라 및 기타 비용은 어떻게 되나? 컨트롤 플레인 비용 외에도 추가적인 운영 오버헤드에 직면했다: 

Kubernetes 구성 요소를 실행하는 노드의 40%: 즉, 각 클러스터의 컴퓨팅 리소스 중 거의 절반이 Kubernetes 구성 요소(예: kubelet, etcd 및 기타 시스템 서비스)에 전용으로 사용되었다. 이는 47개 클러스터를 관리해야 하는 복잡성을 고려할 때 특히 높은 수치였다.

높은 컴퓨팅 비용: 중복성을 위해 클러스터당 여러 개 마스터 노드를 실행하고 있었기 때문에 컴퓨팅 비용이 증가하고 시스템을 유지 관리하는 데 더 많은 인스턴스가 필요했다. 평균 인프라 비용(인스턴스, 로드 밸런서, 네트워킹, 스토리지, 컨트롤 플레인 비용 포함)은  월 $92,000 - $100,000였다. 많은 클러스터에서 컴퓨팅 리소스를 효과적으로 활용하지 못해 활용도가 낮은 용량과 리소스 낭비가 발생했다.

Kubernetes에서 벗어나기로 한 결정

Kubernetes에서 벗어나기로 한 결정은 가볍게 내려진 것이 아니었다.  신중한 검토 끝에, 이론적으로는 훌륭하지만 당시에는 필요 이상으로 복잡성을 가중시킨다는 사실을 깨달았다. 다음은 변경을 결정하게 된 이유를 요약한 것이다.:

1. 관리 오버헤드:

Kubernetes를 유지 관리하려면 상당한 인적 자원이 필요합니다. 우리 DevOps 엔지니어들은 패치, 확장, 문제 해결, 고가용성 보장 등 클러스터를 관리하는 데만 약 60% 시간을 보냈다. 이로 인해 실제 개발 작업이나 혁신을 위한 충분한 시간을 확보하지 못했고, 12개월 동안 엔지니어 4명이 스트레스로 인해 퇴사하는 등 번아웃이 발생했다.

2. 높은 운영 복잡성:

기본 배포를 위해 200개 이상 YAML 파일을 관리하고, 호환성 문제를 처리하고, 147개 오탐 알림과 끊임없이 싸우느라 팀원들의 피로가 누적되었다. 엄청난 양의 복잡성이 이점을 상회하는 것처럼 느껴졌다.

3. 비용 대비 혜택:

인프라 복잡성과 47개 클러스터에 대한  월 $100,000의 비용은 Kubernetes를 통해 얻는 이점을 정당화하지 못했다.

전환: 더 단순한 기술로 전환

우리는 질문부터 시작했다. 더 간단한 도구로 우리 요구를 해결할 수 있을까?

레벨 1: 감사 및 평가

리소스 사용률, 비용, 인시던트 기록을 분석했다. 그 결과 동적 확장 및 롤링 업데이트와 같은 Kubernetes 고급 기능 중 20%만이 활발하게 사용되고 있다는 사실을 발견했다..

레벨 2: 적합한 도구 선택

특정 워크로드에 맞는 도구를 선택했습니다:

상태 저장 서비스 → AWS ECS/Fargate로 이동.

스테이트풀 서비스 → 복잡한 오케스트레이션 필요성을 줄이기 위해 Docker를 사용하여 EC2 인스턴스에  배포했다.

배치 작업 → AWS Batch로 처리.

이벤트 중심 워크플로우 → AWS Lambda로 전환.

레벨 3: 점진적 마이그레이션

중요하지 않은 서비스부터 시작하여 한 번에 하나씩 서비스를 마이그레이션했다. 전환하는 동안 안정성을 보장하기 위해 병렬 시스템을 임시로 운영했다.

결과

비용

컨트롤 플레인: 월 $25,000 절감.

총 인프라 비용: 월 $100,000에서 월 $42,000로 감소(58% 감소).

Kubernetes 비용(이전):

컨트롤 플레인: 관리형 Kubernetes 서비스(예: EKS)는 클러스터당 월 $500다. 47개 클러스터의 경우 월 $23,500였다.

컴퓨팅 및 스토리지: 47개 클러스터에 대해 EC2 인스턴스, 스토리지 및 로드 밸런서를 실행하면  월 $70,500이 추가된다.

엔터프라이즈 지원: Kubernetes 지원 플랜으로월 $3,000를 지불하고 있었습니다.

총 Kubernetes 비용: 월 $100,000/월

AWS ECS/Fargate 비용(이후):

ECS/Fargate: ECS와 Fargate를 사용하면 사용한 만큼만 비용을 지불한다. 이에 대한 비용은  월 $30,000 정도다.(필요한 총액에 맞추기 위해).

지원 요금제: 비즈니스 수준 지원을 위한 합리적인 비용인  월 2,000달러로 AWS 지원 요금제를 다운그레이드했다.

네트워킹 및 모니터링: AWS 도구 사용을 간소화하고 외부 모니터링 솔루션 필요성을 줄임으로써  월 약 $10,000를 절약할 수 있다.

총 ECS/파게이트 비용: 42,000달러/월

절감액:  월 $58,000 (또는 58% 절감).

운영 복잡성

구성 파일: 200개 이상 YAML 파일에서 20개 구성 파일로 감소.

모니터링 도구: AWS CloudWatch로 통합돼 노이즈가 70% 감소했다.

배포 시간: 평균 15분에서 5분으로 개선되었다.

YAML 파일 감소(200개 이상에서 20개로):

이전:

서비스, 배포, 인그레스 규칙, 시크릿, 구성 맵 등 시스템 다양한 측면에 대한 수많은 YAML 파일이 Kubernetes 배포에 필요했다. 모든 클러스터에서 구성을 관리하기 위해 200개 이상의 YAML 파일이 필요했다.

이후:

간소화된 설정: 대부분의 구성을 AWS 관리 도구를 통해 직접 관리할 수 있는 ECS와 Fargate로 이전하여 광범위한 YAML 파일이 필요하지 않게 되었다.

중앙 집중식 구성: AWS CloudFormation 및 ECS 작업 정의를 사용하여 더 간단한 구성 관리를 채택했다. 이제 각 배포에 대해 별도 YAML 파일 대신 더 적은 수의 중앙 집중식 스크립트와 구성 파일을 통해 처리할 수 있어 복잡성이 감소했다.

코드형 인프라: 인프라 관리에는 ECS와 원활하게 통합되는 AWS CloudFormation을 사용했다. 이를 통해 더 적은 수의 구성 파일(20개에 불과)로 인프라 및 애플리케이션 구성의 모든 측면을 처리할 수 있었다. 이러한 간소화 덕분에 YAML 파일 수가 줄어들었을 뿐만 아니라 오류와 잘못된 구성의 가능성도 크게 줄었다.

팀에 미치는 영향

대기 중 인시던트: 75% 감소.

번아웃 관련 퇴사: 지난 6개월 동안 한 건도 없었다.

배포 빈도: 40% 증가하여 더 빠른 기능 제공이 가능해졌다.

기타 질문 및 설명

질문: 많은 클러스터 대신 네임스페이스를 사용하지 않는 이유는 무엇인가?

답변: 이는 설계상 문제였다. 초기에는 클러스터 수준에서 워크로드를 격리하면 보안과 내결함성이 향상될 것이라고 믿었다. 네임스페이스가 훨씬 적은 운영 오버헤드로 비슷한 목표를 달성할 수 있다는 점을 과소평가했다.

질문: 왜 더 일찍 하나의 클라우드 제공업체로 통합하지 않았나?

답변: 멀티 클라우드는 전략적인 결정이었지만 규모에 비해 정당화되지 않았다. 마이그레이션 중에 AWS로 통합함으로써 비용과 복잡성을 크게 줄일 수 있었다.

질문: 모니터링 비용이 왜 그렇게 비쌌나요?

답변: 우리 모니터링 스택에는 여러 클라우드에 분산되어 있는 5개 도구(예: Prometheus, Grafana, DataDog)가 포함되어 있었다. 이러한 중복성으로 인해 높은 비용과 알림 피로도가 발생했다. AWS CloudWatch로 통합하면서 비용과 팀 대역폭을 모두 절약할 수 있었다.

질문: ECS는 어떤가요? 그것도 비싸지 않나?

답변: ECS도 비용이 들긴 하지만 최적화한 후에는 워크로드에 비해 훨씬 저렴해졌다. 상태 비저장 서비스에는 AWS Fargate로, 상태 저장 워크로드에는 Docker가 포함된 EC2로 전환함으로써 비용 효율성을 개선할 수 있었다.

질문: 실제로 컴퓨팅 리소스 40%를 Kubernetes 구성 요소에 사용하고 있었나?

답변: 예. 여기에는 다음이 포함된다:

컨트롤 플레인 오버헤드

로깅, 메트릭, 네트워킹을 위한사이드카 컨테이너

클러스터당 추가 노드가 필요한고가용성 이중화(고가용성 이중화)

Kubernetes를 사용해야 하나?

Kubernetes는 강력한 도구이지만 모든 팀에 적합한 것은 아니다. 도입하기 전에 규모, 팀 규모, 워크로드 복잡성을 고려하라. 다음과 같은 경우 Kubernetes가 필요할 수 있다:

수백 개 마이크로서비스를 관리하고 있는 경우 .

고급 확장 또는 멀티클라우드 이중화가 필요한 경우.

팀에 이를 효과적으로 관리할 수 있는 전문 지식과 대역폭이 있는 경우.

다음과 같은 경우에는 Kubernetes가 필요하지 않을 수 있다:

서비스 수가 20개 미만이거나 예측 가능한 워크로드가 있는 경우.

관리형 서비스(예: ECS, Lambda 또는 Fargate)가 사용자의 요구 사항을 충족하는 경우.

팀의 규모가 작고 유연성보다 단순성을 선호하는 경우.

기술을 선택할 때는 비용, 복잡성, 팀에 미치는 영향 등 전체 상황을 평가하는 것이 필수적이다.. Kubernetes는 강력하지만 비용이 많이 들고 복잡하다. 예측 가능하고 간단한 요구 사항이 있는 많은 소규모 팀이나 팀의 경우 ECS, Lambda, EC2와 같은 더 간단한 솔루션이 오버헤드 없이 상당한 이점을 제공할 수 있다. 궁극적으로 Kubernetes에서 전환한 것은 기술의 실패가 아니라 특정 요구 사항을 충족하기 위해 아키텍처의 규모를 적절히 조정하기 위한 선택이었다.