칼럼 | 챗GPT가 아직 알려주지 않는 쿠버네티스 관리 방법 10가지

생성형 AI는 이미 여러 유즈 케이스에서 유용하게 쓰이고 있다. 하지만 생성형 AI에게 더 기술적인 지침을 요청할 때는 어떻게 작동할까?
 

챗GPT가 출시됐을 때 우리(편집자 주: 필자는 제이프로그(JFrog)의 개발 담당 부사장)는 기술적인 질문을 던지고 특정 콘텐츠를 요청하는 실험을 진행했다. 그 답변을 일반적인 웹 검색 결과와 비교하고 싶었기 때문이다. 모든 답변이 효율적이거나 정확하지는 않았으나 챗GPT가 답변을 개선하기 위해 피드백을 학습하는 기능은 높이 평가할 만했다.

이후 요청 사항을 좀 더 구체화해 챗GPT에 쿠버네티스(Kubernetes) 사용에 대한 조언을 구했다. 챗GPT는 프로덕션 환경에서 쿠버네티스를 사용하는 12가지 모범 사례 목록을 언급했다. 대부분이 정확하고 관련성이 있었다. 그러나 목록을 50가지로 확장하라고 요청하자 부족한 결과물이 나왔다. 다시 말해 기술적인 지침을 처리하는 데는 여전히 사람의 의견이 필요한 셈이다.

쿠버네티스 사용 방법
제이프로그는 6년 이상 전체 플랫폼을 쿠버네티스에서 운영해 왔다. AWS, 애저 및 구글 클라우드 등 주요 클라우드 제공업체의 관리형 쿠버네티스 서비스를 활용하고 있다. 전 세계 30개 이상 지역에서 운영되며 각 지역마다 쿠버네티스 클러스터를 여러 개 보유하고 있다.

제이프로그의 경우 스토리지보다 워크로드 및 런타임 작업에 쿠버네티스를 주로 활용한다. 관리형 데이터베이스와 객체 스토리지 서비스는 클라우드 제공업체에서 관리하고 있다. 쿠버네티스 인프라는 수천 개의 노드로 구성되며, 자동 확장(auto scaling) 설정에 맞춰 노드 수가 동적으로 확장 또는 축소된다.

현재 자사 프로덕션 환경에는 쿠버네티스의 가장 작은 배포 단위인 파드(Pod)가 수십만 개 포함돼 있다. 정확한 숫자는 파드가 생성되거나 끝날 때마다 달라진다. 프로덕션 환경에서는 전 세계적으로 약 30만 개 파드가 실행되고 있다. 관리해야 할 워크로드 규모가 상당하다.

제이프로그는 새 애플리케이션 버전, 패치, 버그 수정을 자주 릴리스한다. 이러한 업데이트를 배포하기 위해 내장(built-in) 시스템을 갖췄다. 여기에는 정식 배포 전 카나리아(canary) 테스트도 포함된다. 이를 통해 지속적인 릴리스 주기를 유지하고 서비스 안정성을 보장하고 있다. 

챗GPT를 사용해 봤다면 알겠지만, 답변에는 데이터가 최신 상태가 아니라고 명시된다. 이러한 사실과 위 배경을 고려해, 프로덕션 환경에서 쿠버네티스를 관리하는 데 있어 챗GPT가 아직 알려주지 않는(오픈AI가 데이터와 알고리즘을 업데이트하기 전까지) 10가지 사항을 소개한다. 

섬세한 노드 크기 조정
노드 크기 조정은 작은 노드를 사용해 ‘폭발 반경(blast radius)’을 줄이는 것과 더 큰 노드를 사용해 애플리케이션 성능을 향상시키는 것 사이에서 균형을 찾는 과정이다. 핵심은 CPU 또는 메모리 최적화 같은 워크로드 요구 사항에 따라 다양한 노드 유형을 활용하는 데 있다. 노드의 CPU 대 메모리 비율에 맞게 컨테이너 리소스를 조정해야 리소스 활용을 최적화할 수 있다. 

노드당 적절한 수의 파드를 찾는 작업은 각 애플리케이션 또는 서비스의 여러 리소스 소비 패턴을 고려해 균형을 맞추는 일이다. 리소스 사용량을 최적화하기 위해 파드 토폴로지 분배 제약 또는 파드 안티어피니티(anti-affinity) 같은 기술로 노드 간 부하를 분산하면 워크로드 강도 변화폭을 수용하는 데 도움이 된다. 로드 밸런싱(load balancing)과 로드 분산(load spreading)은 쿠버네티스 기반 클라우드 서비스를 사용하는 대기업에 필수적이다.

제어판(Control Plane) 보호 방법
제어판 모니터링은 관리형 쿠버네티스 서비스에서도 매우 중요하다. 클라우드 제공업체가 견고한 제어와 균형을 제공하긴 하지만, 사용자는 그 한계를 알고 있어야 한다. 제어판이 최적 성능을 발휘하려면 모니터링과 경고 설정이 필요하다. 느린 제어판은 스케줄링, 업그레이드, 확장 작업 등 클러스터 동작에 영향을 미칠 수 있다. 관리형 서비스에서도 한계를 고려해야 한다. 

관리형 제어판을 과도하게 사용하면 치명적인 충돌이 일어날 수 있다. 제이프로그도 이러한 일을 여러 차례 겪었다. 제어판을 제대로 모니터링하거나 관리하지 않으면 과부화가 걸릴 수 있음을 기억해야 한다. 

애플리케이션 가동 시간 유지 방법
주요 서비스의 우선순위를 지정하면 애플리케이션 가동 시간도 최적화할 수 있다. 파드 우선순위(Pod Priority)와 서비스 품질 클래스(Pod Quality of Service Classes)는 항상 실행해야 하는 애플리케이션을 식별한다. 우선순위 수준을 이해하면 안정성과 성능을 최적화하는 데 도움이 된다.

파드 안티어피니티는 같은 서비스의 복제본이 동일한 노드에 배포되지 않도록 돕는다. 이렇게 하면 단일 오류 지점을 피할 수 있기 때문에 노드에 문제가 생기더라도 다른 복제본은 영향받지 않는다. 

또한 중요 업무용 애플리케이션을 위해 전용 노드 풀을 만드는 관행을 받아들여야 한다. 예를 들어 인그레스(Ingress) 파드나 프로메테우스(Prometheus) 같은 기타 주요 서비스를 위해 별도 노드 풀을 사용하면 안정성과 최종 사용자 경험을 크게 개선할 수 있다. 

확장 계획이 필요하다
조직이 부정적 영향 없이 필요 용량을 확장하기 위해 2배 이상의 클러스터 구축을 감당할 준비가 돼 있는가? 관리형 서비스의 클러스터 자동 확장은 이런 측면에서 도움이 될 수 있지만, 클러스터 크기 제한을 이해하는 것이 중요하다. 제이프로그의 경우 일반적인 클러스터는 약 100개 노드로 구성된다. 크기 제한에 도달하면 기존 클러스터를 강제로 확장하지 않고 새로운 클러스터를 생성한다. 

애플리케이션의 수평 수직 확장도 고려해야 한다. 핵심은 리소스를 과도하게 소비하지 않고 더 잘 활용할 수 있도록 적절한 균형을 찾는 데 있다. 일반적으로 수평 확장과 워크로드 복제 또는 사본 생성이 바람직하지만, 데이터베이스 연결 및 스토리지에 영향을 미칠 수 있다는 점에 유의해야 한다. 

실패에 대비하는 계획을 세워라
오류에 대한 계획은 애플리케이션 인프라의 여러 측면에서 일상화됐다. 애플리케이션, 노드, 클러스터의 오류 같은 상황에 대비할 수 있는 계획이 필요하다. 가용성이 높은 애플리케이션 파드 및 파드 안티어피니티 같은 전략을 구현하면 오류 발생 시 보호 범위를 보장받을 수 있다.

모든 조직에는 클러스터 오류에 대비한 구체적인 재해 복구 계획이 필요하다. 이 계획을 주기적으로 실행해야 한다. 오류에서 복구할 때는 체계적이고 단계적으로 배포해 리소스 과부화를 피한다. 

배포 파이프라인 보호 방법
소프트웨어 공급망은 계속되는 오류와 악의적 공격에 취약하다. 파이프라인의 각 단계에 대한 제어가 필요하다. 신뢰성을 신중히 검토하지 않고 외부 도구와 공급업체에 의존하는 태도도 지양해야 한다.

외부 소스에 대한 통제를 유지하려면 원격 리포지토리에서 생성된 바이너리를 스캔하고 소프트웨어 구성 분석(SCA, Software Composition Analysis) 솔루션으로 유효성을 검사하는 등 조치가 필요하다. 관련 부서는 파이프라인 전체에 품질 및 보안 게이트를 적용해 사용자와 파이프라인의 신뢰를 확보하고 제공된 소프트웨어의 품질을 보장해야 한다. 

런타임을 보호하는 방법
어드미션 컨트롤러(Admission Controller)를 사용해 블랙리스트에 오른 버전의 배포를 차단하는 등 규칙을 적용하면 쿠버네티스 런타임을 보호하는 데 도움이 된다. 배포에 있어 제어된 컨테이너 레지스트리만 허용하는 OPA 게이트키퍼(OPA Gatekeeper) 같은 도구를 정책에 활용할 수도 있다.

역할 기반 액세스 제어(Role-based Access Control)는 쿠버네티스 클러스터에 대한 접근을 보호할 때도 권장된다. 여러 런타임 보호 솔루션이 위험을 실시간으로 식별하고 해결할 수 있다. 네임스페이스 격리 및 네트워크 정책은 측면 이동을 차단하고 네임스페이스 내 워크로드를 보호할 수 있다. 또한 격리된 노드에서 주요 애플리케이션을 실행해 컨테이너 탈출의 위험을 완화하는 방법도 고려할 만하다. 

운영 환경을 보호하는 방법
운영 환경의 보호는 네트워크가 항상 공격을 받고 있다고 가정한다는 의미다. 의심스러운 활동을 감지하기 위해 검사 도구가 권장된다. 완전한 가시성과 워크로드 제어를 갖춘 런타임 보호 기능도 필요하다.

최고의 소프트웨어도 물론 좋지만, 경고 또는 의심스러운 활동이 일어나면 이에 대처할 플레이북을 갖춘 사고 대응 팀이 필요하다. 재해 복구와 마찬가지로 정기 훈련과 연습을 해야 한다. 여러 기관이 버그 포상금을 제공하거나 시스템을 손상시켜 취약점을 찾아낼 역량이 있는 외부 연구원을 고용하기도 한다. 외부의 관점과 객관적 연구로 가치 있는 통찰력을 얻을 수 있다. 

꾸준한 학습이 필수
시스템과 프로세스는 진화하고 있다. 관련 부서는 과거 성능 데이터를 수집해 실행 항목을 평가 및 적용하고 이를 꾸준히 학습해야 한다. 과거에는 중요했으나 현재는 중요하지 않을 수 있는, 작지만 지속적인 개선 사항을 찾아나가야 한다.

성능 데이터를 사전 모니터링하면 메모리나 CPU 누수를 발견하고 서드파티 도구의 성능 버그를 식별하는 데 유용하다. 데이터를 적극적으로 평가해 추세와 이상 징후를 파악하면 시스템에 대한 이해도와 성능을 향상시킬 수 있다. 사전 모니터링과 평가는 실시간 경고에 대응하는 것보다 더 효과적인 결과를 이끌어 낸다. 

사람의 개입을 최소화하라
사람은 보안에 있어 가장 큰 취약점이 될 수 있다. 자동화는 가능한 한 사람의 개입을 최소화하는 것이 바람직하다. 사용할 수 있는 여러 자동화 솔루션을 검토하고 개별 프로세스 및 정의에 가장 적합한 솔루션을 선택하도록 한다. 

깃옵스(GitOps)는 개발에서 프로덕션으로 변경 사항을 적용하는 데 널리 사용되고 있다. 구성 변경을 관리하기 위한 단일 진실 공급원과 인터페이스를 제공한다. 다양한 유형의 구성을 위해 여러 리포지토리를 사용하는 유사 접근 방법이 있다. 개발, 스테이징, 프로덕션 환경이 서로 유사하더라도 이를 명확하게 분리하는 것이 중요하다. 

향후 전망
AI 기반 솔루션은 운영을 덜 복잡하게 하고 환경 관리, 배포 및 문제 해결과 관련된 작업을 자동화한다. 이 때문에 미래의 가능성이 있다고 여겨진다. 하지만 인간의 판단은 쉽게 대체할 수 없다. 이를 항상 고려해야 한다. 

오늘날 AI 엔진은 부정확하거나 오래됐거나 관련 없는 정보를 포함할 수 있는 공개적인 지식에 의존한다. 잘못된 답변이나 권장 사항을 제시할 수도 있다. 이를 잘 사용하려면 상식을 활용하고 AI의 한계를 염두에 두는 것이 가장 중요하다. 

* Stephen Chin은 제이프로그(JFrog)의 개발 담당 부사장이자 CDF 운영위원회 의장, CNCF 운영위원회 의원이다. 저서로는 ‘Java 개발자를 위한 데브옵스 도구(DevOps Tools for Java Developers)’가 있다. ciokr@idg.co.kr