인프라의 미래는 컨테이너화
기술 기업과 스타트업은 인프라 유지보수에 소비되는 엔지니어링 리소스를 절감하고 성장, 경쟁력, 수익성 증가와 같이 비즈니스 성과를 도출하는 로드맵 우선순위에 리소스를 더 많이 투입할 수 있도록 관리형 컨테이너 플랫폼을 빠르게 도입하고 있습니다.
인프라 관리를 간소화하여 출시 속도를 높이는 방법
오늘날 대부분의 기술 회사와 스타트업은 클라우드에서 운영되고 있지만 여전히 많은 기업이 클라우드 컴퓨팅의 이점을 아직 깨닫지 못했습니다. 클라우드에 있지만 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 조정 서비스만큼 간극을 메웁니다. Tau VM의 VM 프로비저닝에서 완전히 통합된 IaaS를 제공하며 동급의 다른 범용 제품보다 42% 더 우수한 가격 대비 성능을 제공합니다.1 여러 영역 및 업그레이드에 걸친 자동 확장으로 GPU, 머신러닝용 TPU, 스토리지 볼륨, 보안 사용자 인증 정보를 주문형으로 생성하고 관리합니다. 애플리케이션을 컨테이너에 넣고 필요에 따라 시스템을 선택하기만 하면 됩니다.
VM을 위한 클라우드 제공업체로 AWS를 선택한 경우 어떻게 해야 하나요? EKS를 계속 유지해야 하나요? 개략적으로 Kubernetes는 모든 클라우드 제공업체와 동일합니다. Kubernetes API를 사용하게 됩니다. 하지만 이 API 아래에는 클러스터, 워커 노드, 보안 정책, 모든 것이 있습니다. 이것이 GKE가 돋보이는 이유입니다.
예를 들어 다른 클러스터가 아직 필요하면 GKE Connect에 연결하면 됩니다. 그러면 한 곳에서 모든 클러스터를 관리하고 확인하고 문제 해결하고 디버그할 수 있으며 사용자 인증 정보와 같은 항목을 중앙에서 관리할 수 있습니다. GKE는 제어 영역, 멀티 리전 또는 멀티 영역 고가용성 측면에서뿐만 아니라 엔드 투 엔드 관리 가능성으로 인해 최고 수준의 Kubernetes입니다. 또한 GKE는 여러 클러스터와 여러 리전에서 중앙 관리형 멀티 클러스터 인그레스를 사용하여 전역 부하 분산기를 활용할 수 있습니다.
Kubernetes API를 사용하고 싶지만 클러스터 프로비저닝, 확장, 업그레이드에 대한 책임은 없다면 어떻게 해야 할까요? GKE Autopilot은 대부분의 워크로드에서 노드와 노드 풀을 포함한 클러스터의 기본 인프라를 추상화하며 워크로드에 대한 비용만 지불합니다. GKE Autopilot은 강력한 보안 기본값을 갖춘 표준 Kubernetes API를 제공하므로 클러스터가 아닌 워크로드에 집중할 수 있습니다.
__________________________
1 결과는 다른 두 주요 클라우드 공급업체의 프로덕션 VM과 공급업체 추천 컴파일러를 사용하는 사전 프로덕션 Google Cloud Tau VM에서 실행되는 예상 SPECrate®2017_int_base를 기반으로 합니다. SPECrate는 Standard Performance Evaluation Corporation의 상표입니다. 자세한 내용은 www.spec.org에서 확인하세요.
서버리스를 통해 앱 배포 간소화
Kubernetes는 조직을 VM에서 새로운 추상화 집합으로 이전하여 운영을 자동화하고 애플리케이션에 집중할 수 있습니다. 하지만 더 구체적인 워크로드(예: 웹 및 모바일 앱, REST API 백엔드, 데이터 처리, 워크플로 자동화)의 경우 서버리스 모델을 활용하여 훨씬 더 간소화하고 배포를 최적화할 수 있습니다.
서비스로서의 기능을 작성하고 모든 종류의 이벤트에 연결할 수 있는 인기 서버리스 플랫폼인 AWS Lambda를 사용 중일 수도 있습니다. 그러나 데이터베이스에 연결하고 이러한 보안 문제를 처리하기 때문에 이러한 함수는 점점 더 복잡해지며, 일부 경우 실제 애플리케이션보다 더 큰 경향이 있습니다. 그렇다면 서비스로서의 기능의 단순함을 능가하는 애플리케이션이나 서버리스 방식으로 실행하려는 기존 애플리케이션이 있으면 어떨까요?
애플리케이션을 다시 작성해야 하는 기존의 서버리스 플랫폼과 달리 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%에 불과합니다. 낭비된 리소스가 너무 많습니다. 많은 팀에서 자동 확장 및 적재와 같은 기능을 구현하여 이 간극을 메우는 훨씬 더 많은 커스텀 도구를 제작하기 때문에 운영 시간을 더 많이 낭비하고 있습니다. 이로 인해 과다 지출과 놀라울 정도로 많은 Cloud 청구서가 발생합니다.
자체 조정 플랫폼을 성공적으로 빌드할 수 있는 조직은 거의 없습니다. 따라서 Kubernetes, Mesos, Nomad와 같은 오픈소스 플랫폼을 활용하는 것이 일반적입니다. 하지만 유지보수 감소, 업계 표준 권장사항, 다른 클라우드 제공업체와의 긴밀한 통합과 같은 이점을 실현할 수 있는 플랫폼을 원한다면 GKE와 같은 관리형 서비스를 통해 컨테이너의 잠재 가치를 극대화합니다.
올바른 마이그레이션을 위한 기본사항
이 시점에서 다음과 같이 질문할 수도 있습니다. 컨테이너로 마이그레이션하는 것이 실제로 아무런 가치가 없는 다운타임에 해당하나요? 마지막으로 하고 싶은 일은 향후 개발 시 일시중지 버튼을 누르는 것일 겁니다. 그렇죠?
질문에 답하기 위해 지금까지의 클라우드 경험을 활용하는 방법으로 올바르게 접근하는 방법을 살펴보겠습니다.
특히 VM에서 컨테이너로 애플리케이션을 마이그레이션하는 것은 버겁게 느껴질 수 있습니다. 특히 모든 컴퓨팅을 새로운 클라우드 제공업체로 이전해야 하는 경우에는 더욱 그렇습니다. 하지만 실제로는 대규모로 이동할 필요가 없습니다. 한 번에 하나의 애플리케이션을 VM에서 시작하여 1~2개의 애플리케이션을 Kubernetes로 옮길 수 있는데, 이 경우 동일한 네트워크에서 나란히 두고 실시간으로 VM과 통신할 수 있습니다. 모든 것을 포괄하는 전환을 시작할 필요는 없습니다. 한 플랫폼에서 다른 플랫폼으로 천천히 이동하면 됩니다.
Kubernetes의 이점이 거의 없는 크고 무거운 데이터베이스와 같은 몇 가지 앱에서는 VM을 계속 사용하는 것이 합리적일 수 있습니다. 그것도 상관없습니다. 적절히 혼합하면 됩니다. 하지만 확인한 바와 같이 대부분의 고객은 애플리케이션 및 오픈소스 프로젝트를 Kubernetes 환경으로 이전하여 상당히 많은 이점을 얻습니다. GKE로 전환하여 가장 큰 수익을 얻을 수 있는 애플리케이션의 우선 순위를 지정하세요. 한 번에 모든 것을 이전할 필요는 없습니다.
Kubernetes는 현재 사용 중인 것과 동일한 Linux VM에서 실행됩니다. 실제로 얻을 수 있는 이점은 자체 개발한 스크립트 및 자동화 모음이 아니라 인프라 로드맵에 있어야 하는 많은 것을 통합하는 보다 능률적이고 일관된 워크플로입니다. 또한 Kubernetes와 같은 업계 표준 도구를 사용하면 새로운 팀원에게 온보딩 시킬 때 회사에서 사용하는 모든 커스텀 방법을 가르쳐야 하는 것보다 훨씬 쉬워집니다.
이 시점에서 컨테이너를 느리지만 실질적으로 채택할 수 있는 방법이 있으므로 관리 오버헤드 측면에서 팀 시간을 절약하고 컴퓨팅 비용에 대한 회사 비용을 절감할 수 있습니다.
다음 단계로 나아갈 준비가 되셨나요?
마이그레이션, 혁신, 성장
Kubernetes에 올인하여 더 나은 서비스를 찾고 있든 기존 애플리케이션 및 로드맵에 맞는 다른 접근 방식을 원하든 상관없이 여기에서는 컨테이너 및 클라우드 마이그레이션에 대해 많은 이야기를 했습니다.
앱 개발 경로가 무엇이든 관리형 컨테이너 옵션을 사용하면 인프라 비용을 최소화하면서도 팀이 우수한 제품 개발에 집중할 수 있는 역량을 극대화합니다. 인프라의 미래는 컨테이너화입니다. 엔지니어와 비즈니스가 성공할 수 있는 환경인지 확인해야 할 때입니다.
아이디어를 얻었다면 당면 과제를 Google과 함께 해결해보세요.
양식을 작성하시면 연락드리겠습니다. 양식 보기