컨테이너화, 인프라의 미래

오늘날 대부분의 기술 회사와 스타트업은 클라우드에서 운영되고 있지만 여전히 많은 기업이 클라우드 컴퓨팅의 이점을 아직 깨닫지 못했습니다. 클라우드에 있지만 Kubernetes를 사용하지 않는다면 자체 보조 커스텀 도구를 구축하고 유지관리하면서 독점 솔루션을 활용하고 있을 것입니다. 또한 효율성 면에서 많은 것을 포기하여 자체 워크로드를 활용도가 낮은 가상 머신(VM)에서 실행하고 공급업체에 종속되어 있을 가능성이 높습니다. 

현재 VM 관리 및 패치 적용을 위해 얼마나 많은 도구를 사용하고 있나요? 애플리케이션을 어떻게 업그레이드하나요? VM 사용률은 어떻게 되나요? 지금 사용하고 있는 도구의 효율성이 그리 높지 않을 수도 있습니다. VM 아키텍처의 취약점으로 인해 문제(서비스 중단, 확장성 문제 등)가 발생하거나, 비용이 통제할 수 없는 수준으로 증가하거나, 인프라가 다음과 같이 비즈니스에 필요한 여러 작업을 지원하도록 설정되어 있지 않을 수 있습니다.

• MVP를 확장 가능한 솔루션으로 리팩터링/재설계
• 추가 클라우드 제공업체로 확장하여 규제 준수 또는 고객 기대 충족
• 지리적으로 확장하여 지연 시간을 줄이고 광범위한 고객층에 더 나은 경험 선사
• 엔드 투 엔드 보안 상태 개선
• 고객 경험 개선(예: 서비스 가용성)

기존 시스템과 기술 부채로 인해 속도가 느려질 수 있습니다. 이것이 바로 Google에서 Kubernetes로의 대규모 전환을 예상하는 이유입니다. 관리형 컨테이너로 구성된 최신 아키텍처에서 안정적이고 안전한 인프라를 실행하기 위한 검증된 패턴에 액세스할 수 있습니다. TTM(time to market)을 단축하고 안정성과 보안을 희생하지 않고도 생산성을 높일 수 있습니다. 이와 동시에 혁신을 이룰 수 있는 최고의 기술 인재를 유치하는 데 도움이 되는 추가적인 이점도 누릴 수 있습니다.

또한 안정적인 혁신 기술을 토대로 오늘날의 업계 표준과 권장사항을 정의하는 Kubernetes 커뮤니티와 주변 생태계에서 소외되지 않도록 신경을 써야 합니다. 궁극적으로는 엔지니어가 인프라 유지보수와 커스텀 도구의 빌드 및 유지보수에 매몰될지 아니면 비즈니스 발전을 위해 우선순위 목록을 점검할지와 같이 엔지니어의 시간 활용에 대한 결정을 내려야 합니다. 오늘날 채용과 관련한 어려움을 고려하면 이는 더욱 중요한 문제입니다. 지금은 문제 없이 기능하더라도 로드맵에 기술 부채 상환, 다음과 관련한 플랫폼 격차 해소와 같이 원치 않는 항목이 포함되어 있을 수도 있습니다.

• 엔드 투 엔드 암호화
• 관측 가능성(로그, 측정항목, 자동 로깅)
• 정책 관리 및 시행
• 고가용성 및 자동 장애 조치
• 비용 절감

Kubernetes는 오픈소스이며 플랫폼 제약을 받지 않고, 빌드 및 배포 수명 주기의 각 단계에서 안전성과 속도를 높여주는 일반적인 모든 도구를 즉시 제공합니다. 이는 대부분의 시스템 관리자가 시간이 지남에 따라 함께 짜맞추어 만든 모든 bash 스크립트와 권장사항의 총체이며, 선언적 API 집합의 기반이 되는 하나의 시스템으로 나타납니다. 모든 기능이 자동화되어 있으며 세부적인 정보가 숨겨져 있고 바로 사용할 수 있습니다. Kubernetes는 플랫폼을 데이터형 인프라로 전환하면서 코드형 인프라의 대부분을 삭제할 수 있습니다. 사용자는 코드를 작성하거나 유지할 필요가 없으며 Kubernetes에 수행해야 할 작업이 아닌 원하는 작업을 알려주기만 하면 됩니다. 관리 오버헤드 측면에서 많은 시간을 절약할 수 있는 것입니다. 

기존 워크로드를 실행하려면 최신 플랫폼에서 Kubernetes를 사용하여 VM에서 앱을 분리하고 컨테이너에 배치하면 됩니다. 컨테이너 이미지를 도입하여 소프트웨어를 패키징하면 VM 업그레이드가 더 쉬워집니다. 이제 VM의 수명 주기 관리와 애플리케이션의 수명 주기 관리를 분리하고 Ruby, Python, 자바와 같은 모든 언어를 삭제함으로써 VM을 간소화할 수 있습니다. 개발자의 애플리케이션 옆에 있는 위치로 옮겨 모든 요소를 한곳에서 제어하고 머신을 베어메탈로 유지할 수 있습니다.

관리형 컴퓨팅 플랫폼은 클라우드 서비스를 Platform as a Service로 전환하여 컨테이너의 성능과 유연성, 서버리스의 편리함을 제공합니다. 서버, 클러스터 구성, 유지보수가 필요하지 않으므로 제어 기능을 유지하면서도 막대한 이점을 누릴 수 있습니다.

클러스터 구성의 제어가 크게 필요하지 않은 워크로드의 경우 서비스에서 노드와 노드 풀 등 클러스터의 기본 인프라를 프로비저닝하고 관리하도록 만들 수 있습니다. 이때 클러스터가 아닌 워크로드에 대해서만 비용을 지불하면 됩니다. 이렇게 하면 클러스터 관리 부담을 없애면서도 보안을 최적화하고 상당한 비용을 절감할 수 있습니다.

클라우드 기반 애플리케이션의 경우 서버리스는 더 적은 노력으로 동일한 작업을 수행하면서 기본 인프라를 없애고 애플리케이션, 데이터, 분석을 위한 엔드 투 엔드 호스트 역할을 합니다. 서버리스 플랫폼을 사용하면 복잡성이 최소화되고 보안, 성능, 확장성, 권장사항이 강화된 완전 관리형 환경에서 컨테이너를 실행할 수 있습니다.

비즈니스에 어떤 영향을 미칠 수 있는지, 어떻게 하면 조직이 효율 곡선에서 유리한 위치를 지킬 수 있는지 살펴보겠습니다.

비즈니스에 따라 여러 클라우드에서 운영해야 하는 경우가 있습니다. 데이터 중력은 실재합니다. 고객층이 전 세계에 퍼져 있다면 데이터가 실제로 위치한 지역 근처에서 컴퓨팅을 유지하여 지연 시간과 네트워킹 비용을 최소화하려는 고객에게 서비스를 제공해야 하는 상황에 직면합니다.

이 경우 멀티 클라우드를 사용하면 대응 가능한 시장을 확대할 수 있습니다. 다만 다른 제공업체의 관리형 서비스와 데이터를 지원하는 상황에 처하게 됩니다. 다른 기업들은 멀티 클라우드를 위험 완화 전략으로 평가합니다. 어떤 경우든 멀티 클라우드를 올바르게 도입하는 것이 중요한데 업계 표준 솔루션이 도움이 될 수 있습니다.

첫째, 작업을 완료하기 위해 워크플로를 최대한 다시 활용할 수 있어야 합니다. 워크플로란 작업 자동화를 지원하여 데이터베이스와 컴퓨팅 간에 Dataflow 아키텍처를 만드는 것입니다. 이때 오픈소스인지가 중요합니다. 공개되지 않은 데이터베이스를 선택하면 Dataflow 아키텍처와 자동화를 구현하는 데 어려움을 겪게 됩니다. 어떤 클라우드 제공업체를 선택하든 Postgres 프로토콜(예: Cloud Spanner) 또는 관리형 Postgres 데이터베이스(예: Cloud SQL) 등을 사용하는 경우가 좋습니다. 

둘째, 컴퓨팅 측면에서 Kubernetes는 배포 및 자동화에 드는 시간을 크게 절약해 줍니다. 여러 기술을 선택할 때 제공업체가 정한 경계를 넘어 작동하는지 확인하세요. 경계는 서로 다른 리전 또는 영역, 다른 프로젝트 또는 계정일 수도 있고 심지어 온프레미스 또는 클라우드일 수도 있습니다. AWS, Google, Azure 등 클라우드 제공업체마다 별도의 인프라를 빌드하고 유지관리하느라 시간을 낭비하지 마세요. 엔지니어가 각각의 인프라를 동일하게 유지하는 작업에 매몰되고 말 것입니다. 한 번 빌드하여 여러 클라우드에 배포하면 업데이트가 필요할 때 중앙에서 일관성 있게 수행할 수 있습니다. Kubernetes와 같은 컴퓨팅 스택은 고객이 효율적이고 새로운 클라우드 제공업체를 온보딩할 때마다 시간을 낭비할 필요가 없는 방식으로 멀티 클라우드를 사용하기 원하는 경우에 큰 이점을 제공합니다.

셋째는 위험 관리입니다. 다른 환경에서 스택을 실행할 수 있으면 클라우드 제공업체의 서비스가 중단되거나 내 비즈니스와 경쟁을 벌이게 되는 위험을 완화하는 데 도움이 됩니다. 규정 준수를 위해 조직은 비즈니스 연속성을 보장하는 제공업체를 선택할 것입니다. 예를 들어 백업 제공업체가 있으면 한 리전에서 작업이 손실되더라도 다운타임이 발생하지 않습니다.

제대로 작동하는 멀티 클라우드 마이그레이션은 개방형 표준을 활용하는 경우가 많습니다. Kubernetes를 예로 들자면 애플리케이션 실행, 구성, 배포뿐만 아니라 보안 정책, 네트워킹 등의 통합에 모두 제공업체의 제약이 없는 API를 제공합니다. Kubernetes를 멀티 클라우드 운영체제라고 생각해 보겠습니다. Kubernetes가 추상화 레이어가 되면 일반적으로 대부분의 주요 클라우드 제공업체 간 차이점을 가릴 수 있습니다.

Kubernetes를 사용하기로 결정하면 선택권이 생깁니다. 물론, 직접 실행할 수 있습니다. Kubernetes는 오픈소스 프로젝트이므로 다운로드한 다음 몇 년의 시간을 투자하여 클라우드 제공업체 또는 원하는 환경에 통합할 수 있습니다.

하지만 그러한 시간 투자가 적절하지 않다고 판단되면 관리형 Kubernetes 제품을 사용하면 됩니다. AWS를 사용 중이라면 EKS를, Azure를 사용 중이라면 AKS를 선택하면 됩니다. Google Cloud를 사용하는 경우 Google Kubernetes Engine(GKE)을 선택하면 됩니다. 이러한 모든 옵션은 공통 Kubernetes API를 제공하므로, 팀이 도구와 워크플로를 빌드하면 다양한 공급업체에서 이를 재사용할 수 있습니다.

하지만 모든 관리형 서비스 제품이 동일하게 제작되는 것은 아닙니다. Kubernetes의 성능은 실행되는 인프라의 성능에 비례할 수밖에 없는데, GKE는 성숙한 완전 관리형 Kubernetes 조정 서비스로서 간극을 메워줍니다. 동급의 다른 범용 제품보다 42% 더 우수한 가격 대비 성능을 제공하는 Tau VM의 VM 프로비저닝부터¹ 여러 영역 및 업그레이드에 걸친 자동 확장, 그리고 GPU, 머신러닝용 TPU, 스토리지 볼륨, 보안용 사용자 인증 정보의 주문형 생성 및 관리에 이르기까지 완전 통합형 IaaS를 제공합니다. 사용자는 애플리케이션을 컨테이너에 넣고 필요에 따라 시스템을 선택하기만 하면 됩니다.

VM을 위한 클라우드 제공업체로 AWS를 선택한 경우 어떻게 해야 하나요? EKS를 계속 사용해야 하나요? 개괄적으로 보면 Kubernetes는 모든 클라우드 제공업체에서 동일하며 Kubernetes API를 사용하게 됩니다. 하지만 API에서 한 발 더 들어가면 클러스터, 워커 노드, 보안 정책을 비롯한 모든 요소가 있으며, 바로 이 지점에서 GKE가 돋보입니다.

예를 들어 다른 클러스터가 계속 필요한 경우 GKE Connect에 연결하면 됩니다. 그러면 한곳에서 모든 클러스터를 관리하고, 확인하고, 문제를 해결하고, 디버그할 수 있으며 사용자 인증 정보 등을 중앙에서 관리할 수 있습니다. GKE는 제어 영역 또는 멀티 리전이나 멀티 영역 고가용성 측면에서뿐만 아니라 엔드 투 엔드 관리 가능성으로 인해 업계 최고의 Kubernetes라고 할 수 있습니다. 또한 GKE는 여러 클러스터와 여러 리전에서 중앙 관리형 멀티 클러스터 인그레스를 사용하여 전역 부하 분산기를 활용할 수 있습니다.

Kubernetes API를 사용하고 싶지만 클러스터 프로비저닝, 확장, 업그레이드에 대한 책임은 원하지 않는다면 어떻게 해야 할까요? GKE Autopilot은 대부분의 워크로드에서 노드와 노드 풀을 포함한 클러스터의 기본 인프라를 추상화하며 사용자는 워크로드에 대한 비용만 지불하면 됩니다. GKE Autopilot은 강력한 보안을 기본적으로 갖춘 표준 Kubernetes API를 제공하므로 클러스터가 아닌 워크로드에 집중할 수 있습니다.

__________________________

¹ 다른 주요 클라우드 공급업체 두 곳의 프로덕션 VM과 공급업체 추천 컴파일러를 사용하는 사전 프로덕션 버전 Google Cloud Tau VM에서 실행되는 예상 SPECrate®2017_int_base를 기반으로 도출된 결과입니다. SPECrate는 Standard Performance Evaluation Corporation의 상표입니다. 자세한 내용은 www.spec.org에서 확인하세요.

Kubernetes는 조직을 VM에서 새로운 추상화 집합으로 이전하므로 운영을 자동화하고 애플리케이션에 집중할 수 있습니다. 하지만 보다 구체적인 워크로드(예: 웹 앱 및 모바일 앱, REST API 백엔드, 데이터 처리, 워크플로 자동화)의 경우 서버리스 모델을 활용하면 한층 더 간소화하고 배포를 최적화할 수 있습니다.

Functions as a Service을 작성하고 모든 종류의 이벤트에 연결할 수 있는 인기 서버리스 플랫폼인 AWS Lambda를 사용 중일 수도 있습니다. 그러나 데이터베이스에 연결하고 보안 문제를 처리해야 하기 때문에 이러한 기능이 점점 더 복잡해지고 일반 애플리케이션보다 더 복잡해지는 경우도 있습니다. 애플리케이션이 Function as a Service의 단순함을 능가하게 되거나 기존 애플리케이션을 서버리스 방식으로 실행하고 싶다면 어떤 일이 발생할까요?

애플리케이션을 다시 작성해야 하는 기존의 서버리스 플랫폼과 달리 Cloud Run은 기존의 컨테이너화된 애플리케이션 투자를 재사용하는 데 도움이 되는 접근 방식을 제공합니다. GKE가 관리형 서비스이긴 하지만 실행할 영역, 로그 저장 위치, 여러 애플리케이션 버전 간의 트래픽을 관리하는 방법, 등록된 도메인 이름, SSL 인증서 관리 등 몇 가지 주요 결정을 내려야 합니다.

Cloud Run은 이러한 결정을 내릴 필요가 없기 때문에 기존 워크로드를 더 많이 실행하고 Scale-to-zero를 사용 중지하여 콜드 스타트를 방지할 수 있습니다. 애플리케이션을 항상 실행해야 하는 경우 Cloud Run은 NFS, WebSocket, VPC 통합과 같은 다른 기존 요구사항과 함께 항상 실행을 지원합니다. 하지만 대다수 기존 서버리스 플랫폼과 마찬가지로 Cloud Run은 독자적이며 기본 제공되는 트래픽 관리 및 자동 확장과 같은 기능을 제공합니다.

컨테이너를 전혀 사용하지 않으며 어디서부터 시작해야 할지 고민하는 경우를 생각해 보겠습니다. 컨테이너화를 도입하는 실제적인 방법을 살펴보겠습니다.

컨테이너를 도입하는 첫 번째 이유는 패키징 문제의 해결입니다. 오늘날 재현 가능한 아티팩트를 제작하고 소프트웨어에 실제로 무엇이 포함되어 있는지 이해하는 것과 관련하여 많은 일이 일어나고 있습니다. 또는 업계에서 '보안 소프트웨어 공급망'이라고 부르는 이 방식은 애플리케이션 코드와 런타임 및 해당 종속 항목을 보유하는 컨테이너 이미지를 활용하는 것이 이상적이라고 생각합니다. 컨테이너의 이점 중 하나는 VM에 배포할 수 있어 머신 간 소프트웨어 배포 및 유지보수의 복잡성이 줄어든다는 점입니다.

컨테이너를 도입하는 두 번째 이유는 조정입니다. VM 관리에는 수많은 관리 및 유지보수 오버헤드가 수반됩니다. 대부분의 기업과 마찬가지로 팀은 인프라를 관리하기 위해 수십 또는 수백 단계를 실행합니다. 각 단계가 자동화되어 있더라도 자동화 도구의 지속적인 유지보수가 필요합니다. 이는 Terraform, Puppet, Chef, Ansible과 같은 업계 표준 자동화 도구를 사용한다고 가정할 때의 이야기입니다. 자체 도구나 커스텀 도구를 사용한다면 유지보수 오버헤드 문제가 훨씬 더 심각합니다.

컨테이너를 도입하는 세 번째 이유는 효율성입니다. 유지보수 부담 외에도 대부분 조직에서 CPU 사용률은 5~10%에 불과합니다. 메모리와 스토리지 사용률은 말할 것도 없습니다. 많은 리소스가 낭비되고 있는 것입니다. 많은 팀에서 자동 확장 및 빈 패킹과 같은 기능을 구현하여 이 간극을 메우는 여러 커스텀 도구를 빌드하기 때문에 운영 시간이 더욱 낭비되고 있습니다. 이로 인해 과다 지출이 발생하고 막대한 클라우드 요금이 청구됩니다.

자체 조정 플랫폼을 성공적으로 빌드할 수 있는 조직은 거의 없습니다. Kubernetes, Mesos, Nomad와 같은 오픈소스 플랫폼을 활용하는 것이 일반적인 이유가 여기에 있습니다. 하지만 유지보수 부담 완화, 업계 표준 권장사항 준수, 다른 클라우드 제공업체와의 긴밀한 통합과 같은 이점을 실현할 수 있는 플랫폼을 원한다면 GKE와 같은 관리형 서비스를 통해 컨테이너의 잠재 가치를 극대화하는 방안을 고려하게 됩니다.

이 시점에서 다음과 같이 질문할 수도 있습니다. 컨테이너로 마이그레이션하는 것은 어떤 가치도 없는 다운타임의 연속일 뿐인가요? 향후 개발 단계에서 일시중지 버튼을 누르는 것은 누구도 원하지 않는 상황입니다.

질문에 답하기 위해 지금까지의 클라우드 경험을 떠올리는 방식으로 접근해 보겠습니다.

특히 VM에서 컨테이너로 애플리케이션을 마이그레이션하는 것은 버겁게 느껴질 수 있습니다. 특히 모든 컴퓨팅을 새로운 클라우드 제공업체로 이전해야 하는 경우에는 더욱 그렇습니다. 하지만 실제로는 대규모로 이동할 필요가 없습니다. 한 번에 하나의 애플리케이션을 VM에서 시작하고 1~2개의 애플리케이션을 Kubernetes로 옮길 수 있습니다. 그러면 동일한 네트워크에서 나란히 위치하고 실시간으로 VM과 통신할 수 있습니다. 모든 것을 포괄하는 전환을 시작할 필요는 없습니다. 한 플랫폼에서 다른 플랫폼으로 천천히 이동하면 됩니다.

Kubernetes의 이점이 거의 없는 규모가 크고 사용량이 많은 데이터베이스와 같은 일부 앱에서는 VM을 계속 사용하는 것이 합리적일 수 있습니다. 그렇더라도 괜찮습니다. 적절히 혼합하여 사용해도 됩니다. 하지만 대부분의 고객이 애플리케이션과 오픈소스 프로젝트를 Kubernetes 환경으로 이전하여 상당한 이점을 얻는 것으로 확인되었습니다. GKE로 이전하여 가장 큰 효과를 볼 수 있는 애플리케이션의 우선순위를 지정하세요. 한 번에 모든 애플리케이션을 이전할 필요는 없습니다.

Kubernetes는 현재 사용 중일 수도 있는 동일한 Linux VM에서 실행됩니다. 실제로 얻을 수 있는 이점은 자체 개발한 스크립트 및 자동화 모음이 아니라, 인프라 로드맵에 포함되어야 하는 많은 요소를 통합하는 보다 간소화되고 일관성 있는 워크플로입니다. 또한 Kubernetes와 같은 업계 표준 도구를 사용하면 회사에서 사용하는 모든 커스텀 방법을 가르쳐야 하는 경우와 비교해 새로운 팀원의 온보딩이 훨씬 쉬워집니다.

지금까지 컨테이너를 점진적이지만 실용적으로 도입할 수 있는 방법을 알아봤습니다. 이제 팀에서 관리 오버헤드와 관련하여 시간을 절약하고 컴퓨팅 비용에 드는 회사 비용을 절감할 수 있습니다.

Kubernetes를 사용하기로 결정하여 더 나은 제품을 찾고 있든 기존 애플리케이션 및 로드맵에 맞는 다른 접근 방식을 원하든 상관없이 도움을 얻을 수 있는 컨테이너 및 클라우드 마이그레이션에 대해 자세히 살펴봤습니다.

앱 개발 경로가 어떻든 관리형 컨테이너 옵션을 사용하면 인프라 비용을 최소화하면서도 팀이 우수한 제품 개발에 집중할 수 있는 역량이 극대화됩니다. 인프라의 미래는 컨테이너화에 있습니다. 엔지니어와 비즈니스가 성공할 수 있는 환경에 있는지 점검해야 할 때입니다. 

Kubernetes부터 클라우드 기반까지: GKE 개발 여정을 바로 시작하기

클라우드의 컨테이너: 애플리케이션을 개발하고 배포하는 더 나은 방법

에릭 브루어와 함께하는 Kubernetes의 과거, 현재, 미래

클라우드 기반으로 재설계: 규모에 맞춘 개발자 생산성 향상을 위한 혁신적인 접근 방식