컨테이너 및 Kubernetes

Agent Sandbox 소개: Kubernetes 및 GKE 기반 에이전트 AI를 위한 강력한 보호장치

Tue, 11 Nov 2025 12:00:00 +0000

* 본 아티클의 원문은 2025년 11월 12일 Google Cloud 블로그(영문)에 게재되었습니다.

Google과 클라우드 네이티브 커뮤니티는 최신 애플리케이션을 지원하기 위해 지속적으로 Kubernetes를 강화해 왔습니다. 올해 초 KubeCon EU 2025에서 Google Cloud는 AI 추론을 더 잘 지원하기 위한 일련의 Kubernetes 개선 사항을 발표한 바 있습니다. 그리고 오늘 KubeCon NA 2025에서는 Agent Sandbox를 새롭게 선보이며 Kubernetes를 AI 에이전트를 위한 가장 개방적이고 확장 가능한 플랫폼으로 만드는 데 집중하고자 합니다.

AI 에이전트가 제시하는 과제를 생각해 보세요. AI 에이전트는 애플리케이션이 단순한 쿼리에 답하는 것을 수준을 넘어 사용자의 목표를 달성하기 위해 복잡한 다단계 작업을 수행하도록 돕습니다. 예를 들어 '지난 분기 매출 데이터를 시각화해 줘'와 같은 요청을 받으면 에이전트는 데이터를 쿼리하고 해당 데이터를 그래프로 처리한 다음 사용자에게 반환해야 합니다. 기존 소프트웨어는 예측 가능한 반면, AI 에이전트는 코드 생성, 컴퓨터 터미널 사용, 심지어 브라우저 활용까지 포함하여 사용자의 목표를 달성하기 위해 언제 어떻게 도구를 사용할지 자체적으로 결정을 내릴 수 있습니다.

강력한 보안 및 운영 가드레일 없이는 이처럼 강력하고 예측 불가능한(Non-deterministic) 강력한 에이전트를 조정하는 데 심각한 리스크를 초래할 수 있습니다. 코드와 명령어를 실행하는 에이전트에 커널 수준 격리(Kernel-level isolation)를 제공하는 것은 필수입니다. AI 및 에이전트 기반 워크로드는 기존 애플리케이션과 다른 추가적인 인프라 요구사항을 가집니다. 가장 눈에 띄는 점은 수천 개의 샌드박스를 임시 환경으로 조정해야 한다는 것입니다. 필요에 따라 빠르게 생성하고 삭제해야 하며 동시에 네트워크 액세스를 제한되어야 한다는 것입니다.

성숙도, 보안성, 확장성을 고려할 때 Kubernetes는 AI 에이전트를 실행하기에 가장 적합한 기반입니다. 하지만 에이전트 코드 실행 및 컴퓨터 사용 시나리오를 완벽히 충족하기 위해서는 진화가 필요합니다. Agent Sandbox는 이 방향으로 나아가는 강력한 첫걸음입니다.

대규모 환경에서의 강력한 격리

에이전트 기반 코드 실행 및 컴퓨터 사용을 위해서는 각 작업마다 격리된 샌드박스를 프로비저닝해야 합니다. 또한 사용자는 수천 개의 샌드박스가 병렬로 스케줄링되더라도 인프라가 그 속도를 따라잡기를 기대합니다.

Agent Sandbox는 Kubernetes 커뮤니티와 함께 빌드한 새로운 Kubernetes 기본 요소(primitive)로, 에이전트 코드 실행 및 컴퓨터 사용을 위해 특별히 설계되어 차세대 에이전트 AI 워크로드에 필요한 성능과 규모를 제공합니다. Agent Sandbox는 런타임 격리를 위해 Kata 컨테이너를 추가로 지원하는 gVisor를 기반으로 빌드되었으며, 데이터 손실, 유출 또는 프로덕션 시스템 손상으로 이어질 수 있는 취약점의 위험을 줄이는 안전한 경계를 제공합니다. Google Cloud는 Agent Sandbox를 Kubernetes 커뮤니티 내의 CNCF(Cloud Native Computing Foundation) 프로젝트로 빌드하며 오픈소스에 대한 약속을 이어가고 있습니다.

GKE를 통한 성능 향상

에이전트를 확장할 때 최저 비용으로 최고의 사용자 경험을 제공하려면 성능을 최적화해야 합니다. GKE(Google Kubernetes Engine)에서 Agent Sandbox를 사용하면 GKE Sandbox의 관리형 gVisor와 컨테이너 최적화 컴퓨팅 플랫폼을 활용하여 샌드박스를 더 빠르게 수평 확장할 수 있습니다. 또한 관리자가 미리 준비된 샌드박스 풀(Pre-warmed pools)을 구성할 수 있게 하여 지연 시간이 짧은(Low-latency) 샌드박스 실행을 지원합니다. 이 기능을 통해 Agent Sandbox는 완전히 격리된 에이전트 워크로드에 대해 서브 세컨드 수준의 지연 시간을 제공하며 콜드 스타트 대비 최대 90%의 성능 향상을 이끌어냅니다.

샌드박스를 안전하게 만드는 격리 속성은 역설적으로 컴퓨팅 리소스의 활용도 저하를 야기하기 쉽습니다. 각 샌드박스 환경을 스크립트로 매번 초기화하는 것은 불안정하고 느릴 수 있으며, 유휴 상태의 샌드박스는 종종 귀중한 컴퓨팅 사이클을 낭비하곤 합니다. 이상적인 환경이라면 실행 중인 샌드박스 환경의 스냅샷을 찍어 특정 상태에서 바로 시작할 수 있어야 합니다.

Pod Snapshots은 실행 중인 포드(Pod)의 전체 체크포인트 및 복원을 지원하는 새로운 GKE 전용 기능입니다. Pod snapshots은 에이전트 및 AI 워크로드의 시작 지연 시간을 획기적으로 줄여줍니다. Pod snapshots을 Agent Sandbox와 결합하면 팀은 스냅샷에서 샌드박스 환경을 프로비저닝하여 몇 초 만에 시작할 수 있습니다. GKE Pod Snapshots은 CPU 기반 워크로드와 GPU 기반 워크로드의 스냅샷과 복원을 모두 지원하여 포드 시작 시간을 몇 분에서 몇 초로 단축합니다. 이를 통해 유휴 샌드박스를 스냅샷으로 저장하고 일시 중단할 수 있어 최종 사용자에게 중단 없이 컴퓨팅 사이크를 크게 절약할 수 있습니다.

AI 엔지니어를 위한 빌드

오늘날의 에이전트 AI나 강화 학습(RL) 시스템을 빌드하는 팀이 인프라 전문가일 필요는 없습니다. Google Cloud는 AI 엔지니어를 염두에 두고 Agent Sandbox를 빌드했으며 이들이 기본 인프라에 대한 걱정 없이 샌드박스의 수명 주기를 관리할 수 있도록 API와 Python SDK를 설계했습니다.

code_block: <ListValue: [StructValue([('code', 'from agentic_sandbox import Sandbox\r\n\r\n# The SDK abstracts all YAML into a simple context manager \r\nwith Sandbox(template_name="python3-template",namespace="ai-agents") as sandbox:\r\n\r\n # Execute a command inside the sandbox\r\n result = sandbox.run("print(\'Hello from inside the sandbox!\')")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb8d86a90>)])]>

이러한 관심사의 분리(Separation of concern)는 AI 개발자에게 친화적인 경험을 제공하는 동시에 Kubernetes 관리자와 운영자가 기대하는 운영 제어 및 확장성을 보장합니다.

지금 시작하기

에이전트 AI는 소프트웨어 개발팀과 인프라팀에 중대한 변화를 가져다줍니다. Agent Sandbox와 GKE는 에이전트가 필요로 하는 격리와 성능을 제공할 수 있습니다. Agent Sandbox는 오픈소스로 제공되며 지금 바로 GKE에 배포할 수 있습니다. GKE Pod Snapshots은 제한된 프리뷰로 제공되며 올해 말 모든 GKE 고객에게 제공될 예정입니다. 시작하려면 Agent Sandbox 문서와 빠른 시작 가이드를 확인하세요. 여러분이 빌드할 멋진 결과물을 기대하겠습니다.

GKE: 컨테이너에서 에이전트까지, 모든 최신 워크로드를 위한 통합 플랫폼

Tue, 11 Nov 2025 12:00:00 +0000

* 본 아티클의 원문은 2025년 11월 12일 Google Cloud 블로그(영문)에 게재되었습니다.

지난 10년 동안 클라우드 네이티브 인프라는 컨테이너화와 마이크로서비스부터 생성형 AI의 부상에 이르기까지 끊임없는 변화를 겪어왔습니다. 이러한 모든 변화 속에서도 Kubernetes는 변함없이 애플리케이션과 인프라 모두에 안정적이고 통일된, 확장 가능한 운영 모델을 제공해 왔습니다.

올해로 10주년을 맞이한 GKE(Google Kubernetes Engine)와 Kubernetes의 공생 관계는 그 어느 때보다 중요해졌습니다. AI를 최대 규모로 처리하기 위한 Kubernetes의 수요가 증가함에 따라 Google은 Kubernetes의 핵심 기능을 강화하여 AI와 비AI 워크로드 모두를 한 단계 발전시키는 데 지속적으로 투자하고 있습니다. 올해 KubeCon 북미에서 Google Cloud는 다음과 같은 세 가지 포괄적인 접근 방식을 반영한 주요 발전 사항을 발표합니다.

차세대 워크로드를 위한 핵심 Kubernetes OSS 강화 - 보안, 거버넌스, 격리를 위한 새로운 Kubernetes 네이티브 AgentSandbox API를 통해 AI 에이전트의 물결을 선제적으로 지원합니다. 최근에는 Inference Gateway API 및 Inference Perf와 같은 추론 워크로드를 지원하는 기능들도 추가했습니다. 또한 Buffers API 및 HPA와 같은 기능은 모든 워크로드의 프로비저닝 지연 시간을 다각도로 해결하는 데 도움을 줍니다.
관리형 Kubernetes 우수성을 보여주는 참조 구현으로써의 GKE 제공 - Google Cloud는 새로운 기능과 모범 사례를 GKE에 지속적으로 도입하여 Google의 Kubernetes 전문 지식을 완전 관리형의 프로덕션 레디 플랫폼으로 전환하고 있습니다. 이를 통해 강력한 Google Cloud 서비스를 통합하고 비교할 수 없는 규모와 보안을 제공합니다. 우리는 새로운 GKE Agent Sandbox를 발표하게 되어 매우 기쁘게 생각하며 최근 GKE 커스텀 컴퓨팅 클래스, GKE Inference Gateway, GKE Inference Quickstart를 발표한 바 있습니다. 또한 대규모 컴퓨팅 수요를 충족하기 위해 130,000개 노드 클러스터 지원으로 확장성의 한계를 넓히고 있습니다. 올해 Google Cloud는 클러스터 상호 운용성과 이식성 표준으로 Kubernetes 상의 AI/ML을 간소화하는 새로운 CNCF Kubernetes AI Conformance 프로그램에 참여하게 되어 기쁩니다. GKE는 이미 AI 적합 플랫폼으로 인증을 받았습니다.
프레임워크 주도 및 운영 마찰 감소 - Google은 오픈소스 커뮤니티 및 파트너와 적극적으로 협력하여 Kubernetes 상의 Slurm 및 Ray를 비롯한 새로운 프레임워크에 대한 지원을 강화하고 있습니다. 최근 Google Cloud는 Anyscale과 협력하여 Anyscale Platform 및 Runtime을 갖춘 GKE용으로 최적화된 오픈소스 Ray를 발표했습니다. 최근에는 파트너들과 협력하여 대규모 고성능 LLM 추론을 위한 분산형 Kubernetes 네이티브 제어 플레인을 만드는 오픈소스 프로젝트인 llm-d의 창립 기여자로서 참여했습니다.

이제 이러한 발전 사항을 더 자세히 살펴보겠습니다.

AI 에이전트의 부상

AI 에이전트의 물결이 우리 앞에 다가왔습니다. PwC에 따르면 IT 부문 고위 리더의 79%가 이미 AI 에이전트를 도입하고 있으며, 88%는 에이전트형 AI로 인해 향후 12개월 동안 IT 예산을 늘릴 계획이라고 합니다.

Kubernetes는 이미 AI 에이전트를 대규모로 배포하고 관리하기 위한 견고한 기반을 제공하지만, 에이전트 AI 워크로드의 비결정적 특성은 인프라에 새로운 과제를 안겨줍니다. AI 에이전트는 코드를 작성하고, 컴퓨터 인터페이스를 제어하며, 수많은 도구를 호출하는 등의 능력을 갖추게 되면서 격리, 효율성, 거버넌스 측면에서 중요성이 그 어느 때보다 높아졌습니다.

Google Cloud는 Kubernetes의 기본 프리미티브를 발전시키는 동시에 GKE에서 실행되는 에이전트에 고성능과 컴퓨팅 효율성을 제공하여 이러한 과제를 해결하고 있습니다. 오늘 Google Cloud는 Kubernetes 네이티브 에이전트 코드 실행 및 컴퓨터 사용 환경을 위한 새로운 기능 모음인 Agent Sandbox를 프리뷰로 발표했습니다. 처음부터 오픈소스로 설계된 Agent Sandbox는 gVisor를 사용하여 에이전트 환경을 격리하므로 LLM이 생성한 코드를 실행하고 AI 에이전트와 상호작용할 수 있습니다.

더욱 안전하고 효율적인 관리형 경험을 위해 새로운 GKE Agent Sandbox는 통합 Sandbox snapshots, 컨테이너 최적화 컴퓨팅과 같은 내장 기능으로 이 기반을 강화합니다. Agent Sandbox는 완전히 격리된 에이전트 워크로드에 대해 1초 미만의 지연 시간을 제공하며 이는 콜드 스타트 대비 최대 90% 향상된 성능입니다. 자세한 내용은 GKE 기반 에이전트 성능 극대화 관련 상세 공지사항을 참조하세요.

AI 기가와트 시대를 위한 독보적인 확장성

'기가와트 AI 시대'라 불리는 지금, 파운데이션 모델 제작자들은 전례 없는 수준의 컴퓨팅 성능에 대한 수요를 주도하고 있습니다. 이에 Google Cloud는 실험 모드 스택에 대한 내부 테스트 결과,GKE를 사용하여 130,000개의 노드로 구성된, 현재까지 알려진 가장 큰 규모의 Kubernetes 클러스터를 구축했다는 소식을 전해드립니다.

Google Cloud는 긴밀하게 결합된 작업을 위한 단일 클러스터 확장성에 집중하는 동시에, 작업 샤딩(예: MultiKueue)을 위한 멀티 클러스터 오케스트레이션 기능을 개발하고 동적 용량 재할당을 위한 새로운 접근방식을 설계하고 있습니다. 이 모든 과정에서 AI 플랫폼 개발 및 확장을 간소화하기 위해 오픈소스 Kubernetes API를 확장하고 있습니다. Google Cloud는 대규모 AI를 지원하는 오픈소스 도구 생태계(예: Kueue, JobSet, etcd)에 대대적으로 투자하고 있으며, 최고의 성능과 안전성을 제공하기 위해 데이터 센터에 GKE 특화 통합(예: Spanner에서 GKE 컨트롤 플레인 실행)을 수행하고 있습니다. 마지막으로 하드웨어 장애와 저장된 체크포인트로부터의 느린 복구와 관련된 손실 시간을 줄여 대규모 AI 학습 작업의 효율성을 개선하도록 설계된 MTC(Multi-Tier Checkpointing) 솔루션을 오픈소스로 공개하게 되어 기쁩니다.

모든 워크로드를 위한 더 나은 컴퓨팅

Google Cloud가 지난 10년 동안 Kubernetes에 헌신해 온 이유는 모든 워크로드에 대해 Kubernetes의 접근성과 효율성을 높이기 위해서입니다. 하지만 수년 동안 한 가지 주요 과제가 남아 있었습니다. 오토스케일링을 사용할 때 새 노드를 프로비저닝하는 데 수 분이 걸려 대용량의 빠른 확장 애플리케이션에는 충분히 빠르지 않았다는 점입니다. 올해 Google Cloud는 가격과 성능을 최적화하면서 필요할 때 정확하게(near-real-time) 확장 가능한 컴퓨팅 용량을 거의 실시간으로 제공한다는 사명으로 다양한 개선사항을 도입하여 이러한 마찰을 정면으로 해결했습니다.

모두를 위한 Autopilot

Google Cloud는 GKE Autopilot을 위해 완전히 새롭게 설계된 오토스케일링 스택인 컨테이너 최적화 컴퓨팅 플랫폼을 도입했습니다. 권장 운영 모드인 Autopilot은 노드 인프라 관리 및 확장을 완전히 자동화하여 성능과 비용에 획기적인 영향을 미칩니다. LiveX AI의 공동 창립자인 Jia Li는 "LiveX AI는 GKE Autopilot을 통해 TCO를 50% 이상 절감하고 제품 출시 기간을 25% 단축했으며 운영 비용을 66% 절감했습니다."라고 말합니다. 또한 최근 Standard 클러스터용 Autopilot 컴퓨팅 클래스가 정식 버전으로 출시되어 더 많은 개발자가 워크로드별로 Autopilot을 도입하여 이러한 관리 부담 없는 경험을 누릴 수 있게 되었습니다.

모든 각도에서 프로비저닝 지연 시간 해결

Google은 더 빠른 동시 노드 풀 자동 프로비저닝을 도입하여 작업을 비동기화하고 고도로 병렬화했습니다. 이 간단한 변화는 이기종 워크로드의 클러스터 확장을 획기적으로 가속화하여 Google Cloud의 벤치마크에서 배포 지연 시간을 수십 배 개선했습니다. 또한 까다로운 스케일 업 요구사항을 위해 새로운 GKE Buffers API (OSS)를 사용하면 미리 프로비저닝된 준비된 노드의 버퍼를 요청하여 컴퓨팅 용량을 거의 즉시 사용할 수 있습니다. 노드가 준비되면 새로운 버전의 GKE 컨테이너 이미지 스트리밍을 통해 전체 컨테이너 이미지가 다운로드되기 전에 애플리케이션을 시작할 수 이씨어 대규모 AI/ML 및 데이터 처리 워크로드에 결정적인 속도 향상을 제공합니다.

중단 없는 오토스케일링을 통한 리소스 활용률 개선

속도에 대한 요구는 워크로드 수준의 확장으로 이어집니다.

이제 새 GKE Standard 클러스터에서 HPA 성능 프로필이 기본적으로 활성화됩니다. 이를 통해 최대 5,000개의 HPA 객체 지원 및 병렬 처리를 포함한 대규모 확장 개선 사항을 제공하여 더 빠르고 일관된 수평 확장이 가능합니다.
Google Cloud는 VPA with in-place pod resize의 프리뷰를 통해 수직 확장 시 중단 문제를 해결하고 있습니다. 이 기능을 통해 GKE는 포드(Pod)를 재생성할 필요 없이 컨테이너의 CPU 및 메모리 요청 크기를 자동으로 조정할 수 있습니다.

동적 하드웨어 효율성

마지막으로, 동적 효율성에 대한 Google Cloud의 노력은 하드웨어 활용률로 확장됩니다. GKE 사용자는 다음 기능에 액세스할 수 있습니다.

Google Axion 프로세서 기반의 새로운 N4A VM (현재 프리뷰 버전)과 5세대 AMD EPYC 프로세서 기반의 N4D VM (현재 GA) 두 서비스 모두 커스텀 머신 유형(CMT)을 지원하므로 워크로드에 맞는 크기의 노드를 생성할 수 있습니다.
새로운 GKE 커스텀 컴퓨팅 클래스를 사용하면 VM 인스턴스 유형의 우선순위 목록을 정의할 수 있어 수동 개입 없이 워크로드가 가장 최신의 가격 대비 성능이 뛰어난 옵션을 자동으로 사용할 수 있습니다.

AI 추론을 강화하는 플랫폼

생성형 AI 추론의 진정한 과제는 수십억 개의 토큰을 조직의 파산 없이 안정적으로, 빛의 속도로 제공하는 방법입니다.

웹 애플리케이션과 달리 LLM 서빙은 스테이트풀(stateful)이며 계산 집약적입니다. 이를 해결하기 위해 Google Cloud는 LLM 인식 라우팅을 위한 Gateway API Inference Extension, 가속기 및 HPA 확장 측정항목과 임곗값에 대한 정밀한 모델 성능 인사이트에 대한 벤치마킹 표준을 제공하는 Inference performance project, Kubernetes 내에서 포드 및 워크로드에 GPU, TPU 및 기타 기기의 할당 및 일정을 간소화하고 자동화하기 위한 Dynamic Resource Allocation(Intel 등과 협력하여 개발)을 포함하여 Kubernetes에 대한 광범위한 오픈소스 투자를 추진해 왔습니다. 또한 Red Hat 및 IBM과 함께 llm-d 프로젝트를 결성하여 'SOTA 아키텍처에 도달 시간'을 최적화하는 Kubernetes 네이티브 분산 추론 스택을 만들었습니다.

GKE 측면에서는 최근 AI 워크로드 서빙을 위한 Kubernetes 기반 솔루션인 GKE Inference Gateway의 정식 버전 출시를 발표했습니다. 두 가지 워크로드별 최적화가 제공됩니다.

LLM 인지 라우팅: 다중 턴(multi0turn) 채팅과 같은 애플리케이션을 위한 LLM 인지 라우팅은 요청을 동일한 가속기로 라우팅하여 캐시된 컨텍스트를 사용함으로써 지연 시간 급증을 방지합니다.
Disaggregated serving: '프리필(prefill)'(프롬프트 처리) 단계와 및 '디코드(decode)'(토큰 생성) 단계를 분리하여 각각 최적화된 머신 풀에서 실행합니다.

그 결과 GKE Inference Gateway는 다른 관리형 Kubernetes 서비스와 비교했을 때 최대 처리량에서 TTFT(Time-to-First-Token) 지연 시간을 최대 96% 줄이고 토큰 비용을 최대 25% 절감할 수 있게 되었습니다.

AI 추론 서버의 시작 지연 시간은 대규모 모델이 시작하는 데 수십 분이 걸리는 지속적인 과제입니다. 오늘 Google Cloud는 CPU 및 GPU 워크로드를 메모리 스냅샷에서 복원할 수 있도록 하여 시작 지연 시간을 획기적으로 개선하는 GKE Pod Snapshots을 소개합니다. GKE Pod Snapshots은 AI 추론 시작 시간을 최대 80%까지 단축하여 700억(70B)개의 파라미터 모델을 단 80초 만에, 80억(80B) 파라미터 모델을 단 16초 만에 로드합니다.

프로덕션 등급의 AI 인프라 배포에 대한 복잡성, 비용, 어려움을 이야기하지 않고는 추론에 대한 논의를 완료할 수 없습니다. GKE Inference Quickstart는 Google Cloud의 최신 가속기, 최신 오픈 모델, 추론 소프트웨어로 최신 상태를 유지하는 지속적이고 자동화된 벤치마킹 시스템을 제공합니다. 이러한 벤치마킹된 프로필을 사용하여 추론별 성능 측정지표를 검증, 구성, 배포, 모니터링하고 배포를 동적으로 미세 조정하는 데 드는 시간을 크게 절약할 수 있습니다. 이 데이터는 이 Colab 노트북에서 찾을 수 있습니다.

Kubernetes와 GKE의 다음 10년을 위하여

GKE가 지난 10년간의 기반 작업을 기념하는 가운데 Google은 미래를 선도하는 데 기여할 수 있게 되어 자랑스럽습니다. 이 미래는 우리 모두가 함께해야만 만들 수 있다는 사실을 알고 있습니다. 기여자 커뮤니티의 노력이 없었다면 Kubernetes는 오늘날의 위치에 도달하지 못했을 것입니다. 여기에는 기초가 되는 새로운 기능을 작성하는 구성원부터 프로젝트가 번창할 수 있도록 유지하는 데 필수적인 일상적인 작업, 즉 '장작을 패고 물을 긷는(chopping wood and carrying water)' 작업을 수행하는 구성원까지 모두 포함됩니다.

새로운 기능을 살펴보고, Ironwood TPU와 같은 흥미로운 발표에 대해 자세히 알아보고, 심층 세션에 참석하여 오픈소스 인프라의 미래를 함께 만드는 데 동참해 주시기 바랍니다.

Google Kubernetes Engine의 Managed Lustre 관련 5가지 권장사항

Fri, 19 Sep 2025 16:00:00 +0000

* 본 아티클의 원문은 2025년 09월 20일 Google Cloud 블로그(영문)에 게재되었습니다.

Google Kubernetes Engine(GKE)은 확장 가능한 AI 및 고성능 컴퓨팅(HPC) 워크로드를 조정하기 위한 강력한 플랫폼입니다. 하지만 클러스터가 커지고 작업이 더 데이터 집약적으로 변할수록 스토리지 I/O가 병목 현상이 될 수 있습니다. 이로 인해 강력한 GPU와 TPU가 데이터를 기다리느라 유휴 상태가 되어 비용이 증가하고 혁신이 둔화될 수 있습니다.

Google Cloud Managed Lustre는 이러한 문제를 해결하기 위해 설계되었습니다. 많은 온프레미스 HPC 환경에서 이미 병렬 파일 시스템을 사용하고 있으며, Managed Lustre를 사용하면 이러한 워크로드를 클라우드로 더 쉽게 가져올 수 있습니다. 관리형 컨테이너 스토리지 인터페이스(CSI) 드라이버를 통해 Managed Lustre는 GKE 운영과 완전히 통합됩니다.

고성능 병렬 파일 시스템으로의 이전을 최적화하면 첫날부터 투자 효과를 극대화할 수 있습니다.

배포에 앞서 Managed Lustre를 사용해야 하는 경우와 Google Cloud Storage와 같은 다른 옵션을 사용해야 하는 경우를 알아두는 것이 좋습니다. 대부분의 AI 및 ML 워크로드에는 Managed Lustre가 권장되는 솔루션입니다. 학습 및 체크포인팅처럼 지연 시간이 1밀리초 미만으로 매우 짧고 작은 파일에 대해 높은 처리량을 요구하는 시나리오에서 탁월한 성능을 발휘하므로 고가의 가속기를 최대한 활용할 수 있습니다. 반면, 데이터 보관처리 또는 대용량 파일(50MB 초과)을 다루고 지연 시간에 민감하지 않은 워크로드의 경우 Cloud Storage FUSE와 Anywhere Cache 조합이 또 다른 선택지로 고려할 수 있습니다.

초기 고객들과의 협업과 Google Cloud팀의 경험을 바탕으로 GKE에서 Managed Lustre를 최대한 활용하기 위한 5가지 권장사항을 소개합니다.

aside_block: <ListValue: [StructValue([('title', 'Google Cloud 컨테이너 및 Kubernetes를 체험할 수 있는 $300 무료 크레딧 제공'), ('body', <wagtail.rich_text.RichText object at 0x7fdfb852b580>), ('btn_text', ''), ('href', ''), ('image', None)])]>

1. 데이터 지역성을 고려한 설계

성능에 민감한 애플리케이션의 경우 컴퓨팅 리소스와 스토리지가 가능한 한 가까이 있어야 하며, 특정 리전 내 동일한 영역에 있는 것이 이상적입니다. 볼륨을 동적으로 프로비저닝할 때는 StorageClass의 volumeBindingMode 파라미터가 가장 중요한 도구입니다. 이를 WaitForFirstConsumer로 설정하는 것이 좋습니다. GKE는 기본적으로 WaitForFirstConsumer 바인딩 모드를 사용하는 Managed Lustre용 내장 StorageClass를 제공합니다.

생성된 YAML:

code_block: <ListValue: [StructValue([('code', 'apiVersion: storage.k8s.io/v1\r\nkind: StorageClass\r\nmetadata:\r\n name: lustre-regional-wait\r\nprovisioner: lustre.csi.storage.gke.io\r\nvolumeBindingMode: WaitForFirstConsumer\r\n...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb852ba00>)])]>

권장하는 이유: WaitForFirstConsumer를 사용하면 이를 필요로 하는 포드가 예약될 때까지 GKE가 Lustre 인스턴스의 프로비저닝을 지연하도록 지시합니다. 그러면 스케줄러는 포드의 토폴로지 제약 조건(즉, 예약된 영역)을 사용하여 정확히 동일한 영역에 Lustre 인스턴스를 만듭니다. 이렇게 하면 스토리지와 컴퓨팅이 동일한 위치에 배치되어 네트워크 지연 시간이 최소화됩니다.

2. 성능에 맞는 등급 선택

모든 고성능 워크로드가 동일한 것은 아닙니다. Managed Lustre는 여러 성능 등급(스토리지 1TiB당 읽기 및 쓰기 처리량(Mbps))을 제공하므로 성능 요구사항에 맞춰 비용을 제어할 수 있습니다.

1,000 및 500Mbps/TiB: I/O 대역폭이 주된 병목 현상인 파운데이션 모델 학습 또는 대규모 물리 시뮬레이션과 같이 처리량이 중요한 워크로드에 적합합니다.
250Mbps/TiB: 균형 잡힌 비용 효율적인 등급으로, 많은 일반적인 HPC 워크로드와 AI 추론 서빙, 데이터 집약적인 분석 파이프라인에 적합합니다.
125Mbps/TiB: 최대 처리량을 달성하는 것보다 대규모의 POSIX 규격 파일 시스템을 갖추는 것이 더 중요한 대용량 사용 사례에 가장 적합합니다. 또한 컨테이너화된 온프레미스 애플리케이션을 별도의 수정 없이 마이그레이션하는 데도 유용하므로 온프레미스 워크로드를 클라우드 스토리지로 더 쉽게 마이그레이션할 수 있습니다.

권장하는 이유: 무조건 최고 등급을 선택하는 것이 항상 비용 효율적인 전략은 아닙니다. 워크로드의 I/O 프로필을 분석하면 총소유비용을 크게 최적화할 수 있습니다.

3. 네트워킹 기반 구축

병렬 파일 시스템은 네트워크로 연결되는 리소스입니다. 네트워킹을 처음부터 올바르게 설정하면 문제 해결에 드는 시간을 줄일 수 있습니다. 프로비저닝하기 전에 문서의 설정 단계를 따라 VPC가 올바르게 구성되었는지 확인하세요. 이 과정은 문서에 자세히 설명된 아래 세 가지 주요 단계로 이루어져 있습니다.

서비스 네트워킹을 사용 설정합니다.
VPC 피어링의 IP 범위를 만듭니다.
Lustre 네트워크 포트(TCP 988 또는 6988)에서 해당 범위의 트래픽을 허용하도록 방화벽 규칙을 만듭니다.

권장하는 이유: VPC당 한 번만 설정하면 되는 작업으로, GKE 노드가 Managed Lustre 서비스와 통신할 수 있도록 안전한 피어링 연결이 설정됩니다.

4. 단순성을 원한다면 동적 프로비저닝을, 장기 공유 데이터에는 정적 프로비저닝을 사용

Managed Lustre CSI 드라이버는 스토리지와 GKE 워크로드를 연결하는 두 가지 모드를 지원합니다.

동적 프로비저닝: 스토리지가 특정 워크로드나 애플리케이션의 수명 주기가 긴밀하게 연결되어 있는 경우 사용합니다. StorageClass와 PersistentVolumeClaim(PVC)을 정의하면 GKE가 자동으로 Lustre 인스턴스 수명 주기를 관리해 줍니다. 가장 간단하고 자동화된 접근방식입니다.
정적 프로비저닝: 장기 Lustre 인스턴스를 여러 GKE 클러스터와 작업 간에 공유해야 하는 경우에 사용합니다. Lustre 인스턴스를 한 번 만든 후 클러스터에서 마운트하기 위해 PersistentVolume(PV)과 PVC를 만듭니다. 이렇게 하면 스토리지 수명 주기가 단일 워크로드에서 분리됩니다.

권장하는 이유: 데이터 수명 주기를 고려하면 적절한 패턴을 선택하는 데 도움이 됩니다. 단순성을 위해 기본적으로 동적 프로비저닝을 사용하고, 파일 시스템을 조직 전체에서 지속적으로 공유되는 리소스로 취급해야 하는 경우에는 정적 프로비저닝을 선택하세요.

5. Kubernetes 작업으로 병렬 처리 설계

데이터 전처리 또는 일괄 추론과 같은 많은 AI 및 HPC 작업은 병렬 실행에 적합합니다. 하나의 대규모 포드를 실행하는 대신 Kubernetes 작업 리소스를 사용하여 작업을 여러 개의 작은 포드로 나누세요.

다음 패턴을 고려하세요.

Managed Lustre 인스턴스에 대해 단일 PersistentVolumeClaim을 만들어 클러스터에서 사용할 수 있도록 합니다.
병렬 처리 수를 높게 설정한 Kubernetes 작업을 정의합니다(예: 100).
작업에서 생성된 각 포드는 동일한 Lustre PVC를 마운트합니다.
애플리케이션을 설계할 때 각 포드가 데이터의 서로 다른 하위 집합(예: 서로 다른 범위의 파일 또는 데이터 청크 처리)에서 작동하도록 만듭니다.

권장하는 이유: 이 패턴에서는 Lustre 인스턴스에 대해 단일 PVC를 만들고, 작업에서 생성된 각 포드가 동일한 PVC를 마운트하도록 합니다. 각 포드가 데이터의 서로 다른 하위 집합에서 작동하도록 애플리케이션을 설계하면 GKE 클러스터를 강력한 분산 데이터 처리 엔진으로 전환할 수 있습니다. GKE 작업 컨트롤러는 병렬 작업을 조정하는 역할을 하고 Managed Lustre는 고속 데이터 백본 역할을 함으로써, 대규모 집계 처리량을 달성할 수 있습니다.

지금 시작하기

GKE의 조정 기능과 Managed Lustre의 성능을 결합하면 진정으로 확장 가능하고 효율적인 AI 및 HPC 플랫폼을 빌드할 수 있습니다. 이 권장사항을 따르면 강력하면서도 효율적이고 비용 효과적이며 관리하기 쉬운 솔루션을 만들 수 있습니다.

시작할 준비가 되셨나요? Managed Lustre 문서를 살펴보고 지금 바로 첫 번째 인스턴스를 프로비저닝하세요.

클릭에서 클러스터로: Intel TDX를 통해 확장되는 Confidential Computing

Fri, 29 Aug 2025 16:00:00 +0000

해당 블로그의 원문은 2025년 8월 30일 Google Cloud 블로그(영문)에 게재되었습니다.

프라이버시를 보호하는 기밀 컴퓨팅(Confidential Computing)은 저희가 5년 전에 Confidential 가상 머신(VM)을 처음 선보인 이래로 많은 발전을 이루었습니다. 사용 중인 데이터를 보호할 수 있는 이 기술은 데이터가 저장 및 전송 중일 때의 암호화를 넘어선 보안 격차를 강화합니다.

그 이후로 고객들은 Confidential Computing을 사용하여 환자 의료 데이터를 보호하고, GDPR 및 Schrems II의 개인정보 보호 지침을 준수하여 미국-유럽 데이터 전송을 수행하며, HPC(고성능 컴퓨팅) 워크로드를 안전하게 실행해 왔습니다.

하드웨어 기반의 TEE(신뢰 실행 환경)에서 워크로드를 격리함으로써, Confidential Computing은 고객들이 가장 민감한 정보를 퍼블릭 클라우드에서 안심하고 처리할 수 있게 해줍니다.

Confidential Computing의 발전의 일환으로, 작년에 Intel TDX(Trust Domain Extensions)를 활용한 기밀 VM을 도입하여 더욱 강력한 보안 기능을 추가했습니다. Intel TDX는 VM 내에 격리된 신뢰 도메인(TD)을 생성하고, 하드웨어 확장 기능을 사용하여 메모리를 관리 및 암호화하여 클라우드 워크로드를 보호하며, 검증을 위한 하드웨어 기반 원격 증명(remote attestation)을 제공합니다.

구글 클라우드는 크게 확장되고 정식 출시된 Intel TDX 기반 서비스들을 소개합니다. 여기에는 Confidential GKE 노드, 기밀 공간(Confidential Space), Confidential GPU, 그리고 고객들이 Confidential Computing을 사용할 수 있는 더 많은 리전 및 영역이 포함됩니다.

클릭 한 번으로 Confidential VM 생성

이제 Google Cloud Console은 Google Compute Engine(GCE) 고객에게 Intel TDX를 위한 새로운 인터페이스를 제공하며, 코드 변경이 필요 없습니다. 시작하려면 다음 단계를 따르세요.

GCE의 인스턴스 생성 페이지에서 시작합니다.
‘보안’ 탭으로 이동하여 Confidential VM 서비스 아래의 사용 설정(Enable)을 클릭합니다.
드롭다운 메뉴에서 Intel TDX를 선택하고 확인(Confirm)을 클릭합니다.

이렇게 간단한 방법으로 Confidential VM을 만들 수 있습니다.

Google Cloud 콘솔에서 Intel TDX를 사용하여 새로운 기밀 VM을 생성

더 많은 리전 및 영역에서 기밀 컴퓨팅 활용

Intel TDX를 활용한 기밀 VM은 처음에는 3개 리전(9개 영역)에서 지원되었습니다. 늘어나는 수요에 맞춰, C3 머신 시리즈에 대한 Intel TDX 지원을 10개 리전(21개 영역)으로 확장했으며, 앞으로 더 많은 리전 및 영역을 추가할 계획입니다. 전체 목록은 여기에서 확인할 수 있습니다. 리전 가용성 및 확장성은 매우 중요하므로, 고객 계정팀이 고객의 용량 수요를 충족할 수 있도록 조기 계획 수립을 도와드립니다.

Intel TDX를 활용한 Confidential GKE Node 정식 출시

Confidential GKE Nodes는 Confidential VM을 기반으로 구축되었으며, Google Kubernetes Engine(GKE) 클러스터 및 노드 풀에 하드웨어 기반 보호 기능을 제공하여 컨테이너화된 워크로드가 메모리 내에서 암호화되도록 보장합니다. 오늘부터 Confidential GKE Nodes는 GKE Standard 및 GKE Autopilot에서 Intel TDX를 활용하여 정식으로 제공됩니다.

C3 머신 시리즈의 Intel TDX를 활용한 기밀 GKE 노드는 CLI, API, UI, Terraform을 통해 GKE Standard에서 생성할 수 있습니다. 기밀 설정은 코드 변경 없이 클러스터 수준 또는 노드 풀 수준에서 설정할 수 있습니다. 자세한 내용은 여기에서 확인할 수 있습니다.

C3 머신 시리즈의 Intel TDX를 활용한 Confidential GKE Nodes는 GKE Autopilot에서도 생성할 수 있습니다. 이는 맞춤형 컴퓨팅 클래스를 사용하여 활성화할 수 있습니다. GKE에서 컴퓨팅 클래스는 자동 확장 이벤트 중에 워크로드를 실행할 노드를 프로비저닝하는 데 GKE가 사용하는 일련의 노드 속성으로 구성된 프로필입니다. 시작하려면 문서를 확인하세요.

aside_block: <ListValue: [StructValue([('title', 'Google Cloud 보안 제품을 경험해 볼 수 있는 $300의 무료 크레딧을 드립니다.'), ('body', <wagtail.rich_text.RichText object at 0x7fdfb8decd30>), ('btn_text', ''), ('href', ''), ('image', None)])]>

Intel TDX를 활용한 기밀 공간(Confidential Space) 정식 출시

마찬가지로 Confidential VM을 기반으로 구축된 당사의 Confidential Space 서비스는 내부자 위협 해결, 공동 머신러닝 학습 및 비공개 생성형 AI 추론 지원, 민감한 데이터에 대한 다자간 협업 촉진 등 여러 일반적인 문제에 대한 강력한 솔루션입니다. 다음은 고객들이 Confidential Space을 활용하여 구축한 몇 가지 예시입니다.

기밀 매칭: 고객들은 Google Ads 측정 및 잠재고객 솔루션을 위해 자체 퍼스트 파티 데이터를 안전하게 연결할 수 있었습니다.
Symphony: 기밀 클라우드를 통해 SaaS 기업이 고도의 규제가 적용되는 금융 산업에서 권한 있는 내부 관계자로부터 고객 데이터를 격리하는 것을 보장할 수 있음을 보여주었습니다
Duality: 의료, 금융 서비스 및 공공 부문에서 광범위한 사용 사례에 대한 개인정보를 보호하는 학습 솔루션을 제공했습니다
Flare: 블록체인에서 검증 가능한 AI 혁신을 주도했습니다

이전에는 기밀 공간이 AMD 기반 기술 및 하드웨어(N2D, C2D, C3D, C4D 머신 시리즈)에서만 사용 가능했지만, 이제 Intel 기반 기술 및 하드웨어에서도 사용할 수 있습니다. 이는 하드웨어 신뢰점(root of trust)을 통한 증명 보장을 원하는 고객과 Intel의 C3 머신 시리즈에 중점을 둔 고객에게 이상적입니다.

또한, Intel TDX를 활용한 기밀 공간은 RTMR(runtime measurement registers)에 측정값이 기록되며, 이 측정값은 Google Cloud Attestation에 의해 검증됩니다. 참고로, Intel TDX를 활용한 기밀 VM에서도 이제 RTMR이 채워집니다. 기밀 공간의 이점은 NCC Group의 최신 독립 보안 평가에서 강조되었습니다.

NVIDIA H100 GPU를 활용한 기밀 VM 및 기밀 GKE 노드 정식 출시

사용 중인 데이터를 보호하면서 성능과 보안을 모두 원한다면, 가속기 최적화 A3 머신 시리즈에서 NVIDIA H100 GPU를 활용한 Confidential VM 및 Confidential GKE Node가 이제 정식으로 제공됩니다. 이 서비스들은 Google Cloud 최초의 기밀 GPU를 제공하며, 보안 컴퓨팅에 대한 수요를 충족하기 위해 사용 편의성에 중점을 둡니다. 또한, CPU에 Intel TDX를, GPU에 NVIDIA Confidential Computing을 활성화하여 데이터 집약적인 AI 및 ML 워크로드로 보안을 확장합니다. 이제 모델 전반에 걸쳐 추론 및 학습 과정에서 데이터를 성능 저하 없이 안전하게 보호할 수 있습니다.

NVIDIA H100 GPU를 활용한 Confidential VM은 a3-highgpu-1g 머신 유형으로 europe-west4-c, us-central1-a, and us-east5-a 세 가지 영역에서 사용할 수 있습니다. 대부분의 AI 및 ML 워크로드에 대해 코드 변경이 필요 없습니다. 가격에 대한 자세한 내용은 여기를 참조하십시오. NVIDIA H100 GPU를 활용한 Confidential GKE Node는 GKE Standard와 GKE Autopilot(맞춤형 컴퓨팅 클래스를 통해) 모두에서 정식으로 제공됩니다. 시작하려면 여기를 클릭하세요.

또한, NVIDIA H100 GPU를 활용한 Confidential Space도 미리 보기로 제공됩니다.

Intel, 독립 증명을 위한 무료 등급 제공

Intel의 증명 검증 서비스인 Intel Tiber Trust Authority가 이제 무료 등급을 제공합니다. Google Cloud 기밀 VM 및 기밀 공간은 모두 Intel Tiber Trust Authority와 타사 증명 서비스로 통합되어 있었지만, 이제 Intel Tiber Trust Authority는 무료 등급(유료 지원 선택 가능)을 제공하여 모든 사용자가 보안 증명에 더 쉽게 접근할 수 있도록 하고 있습니다.

Confidential VM 및 Confidential Space 고객은 Intel Tiber Trust Authority를 사용하여 더 강력한 권한 분리 보안 보장을 얻을 수 있습니다. 자세히 알아보려면 여기를 클릭하세요.

고객 후기

"Super Protocol, Google Cloud, 그리고 NVIDIA의 공동 노력 덕분에 이제 클라우드 경계 없이 기밀 AI를 구현하는 새로운 가능성의 장이 열렸습니다. NVIDIA H100 GPU 기반의 A3 기밀 VM이 Super의 분산 인프라 및 마켓플레이스에 통합되면서, 기업들은 어떤 환경에서든 민감한 AI 및 데이터를 안전하게 실행하고, 수익화하며, 협업할 수 있습니다. 이를 통해 Google Cloud 고객들은 신뢰를 공유하거나, 수동으로 협의하거나, 타협할 필요 없이 다른 클라우드의 파트너들과 원활하게 협업할 수 있습니다. 더 넓은 시장에서는 A3 인스턴스 규모가 전 세계적인 접근을 가속화하며, Super는 기밀 컴퓨팅에 대한 전문 지식 없이도 완전 자동화된 방식으로 기밀성, 검증 가능성, 그리고 자율성을 보장합니다. 우리는 고객과 파트너가 어디에 있든 작동하도록 구축된 기밀 AI의 다음 장을 열게 되어 매우 기쁩니다." - Super Protocol 창립자 겸 CEO, Nukri Basharuli

"Google Cloud와 협력하여 기밀 컴퓨팅이 활성화된 GPU 솔루션을 검증하게 되어 자랑스럽습니다. 이는 성능이나 확장성 저하 없이 AI 및 머신러닝 워크로드의 민감한 데이터를 보호하는 데 큰 진전입니다. 기밀 컴퓨팅을 통해 조직은 클라우드 제공업체와 조직 내부자 및 내부 위협으로부터 민감한 데이터와 모델을 보호하면서 클라우드에서 민감한 워크로드를 처리할 수 있습니다. 그러나 생성형 AI 및 에이전트형 AI 사용 사례의 경우, CPU만 보호하는 것으로는 충분하지 않습니다. CPU와 GPU 모두 상호 신뢰를 바탕으로 기밀 모드로 실행되어야 합니다. Google Cloud의 새로운 서비스를 통해 Anjuna는 이제 Intel TDX와 NVIDIA H100 GPU를 기밀 모드로 활용하는 기밀 컨테이너를 출시할 수 있습니다. 이는 데이터, 구성, 비밀 및 코드가 모든 신뢰할 수 없는 엔티티로부터 종단간 보호되도록 보장하여 민감한 데이터에 대한 최첨단 보안을 제공합니다." - Anjuna Security CTO, Steve Van Lare

"전 세계적으로 데이터 처리가 그 어느 때보다 세 배나 빠르게 성장하고 6개월마다 두 배로 증가함에 따라, 클라우드 컴퓨팅의 미래는 신뢰를 기반으로 구축되어야 합니다. Google과의 협력을 통해 Modelyo는 NVIDIA H100 GPU가 탑재된 A3 머신 시리즈의 기밀 VM을 활용하여 기밀 컴퓨팅을 원활하고 직관적이며 완전히 통합된 클라우드 경험으로 전환합니다. 이를 통해 우리는 상호 연결된 환경 전반에 걸쳐 종단간 관리형 솔루션을 제공하며, 조직이 모든 단계에서 데이터가 손쉽게 보호된다는 것을 알고 자신 있게 혁신할 수 있도록 지원합니다." - Modelyo CEO, Benny Meir

기밀 컴퓨팅 시작하기

민감한 워크로드에 추가적인 보호 및 개인정보 보호 계층을 더하려면, 지금 Confidential VM 및 Confidential GKE Node 문서를 확인하세요

GKE의 열번째 생일을 기념해 더욱 새로운 기능과 프라이싱을 만나보세요.

Tue, 26 Aug 2025 09:00:00 +0000

* 본 아티클의 원문은 2025년 08월 27일 Google Cloud 블로그(영문)에 게재되었습니다.

"컨테이너를 사용하면 앱을 더 쉽게 패키징할 수 있지만 워크로드를 프로덕션에 적용하려면 강력한 클러스터 관리자와 조정 시스템이 필요합니다."

10년 전, Google Kubernetes Engine(GKE)을 발표하는 블로그 게시물은 이 문장으로 시작되었습니다. 관리형 Kubernetes 플랫폼은 오늘날에도 여전히 필요하며, 특히 워크로드가 점점 더 복잡해지는 요구사항을 충족하도록 진화함에 따라 더욱 중요해지고 있습니다.

GKE가 출시되기 1년 전, Google Cloud는 내부 컨테이너 관리 시스템인 Borg의 상당 부분을 Kubernetes라는 이름으로 오픈소스화했습니다. 이때부터 고객에게 자체 플랫폼을 제공하기 시작했으며, Vertex AI와 같은 주요 서비스를 지원하기 위해 Kubernetes와 GKE를 계속 사용하면서 학습한 내용과 권장사항을 GKE에 적용하고 있습니다. Google Cloud의 글로벌 플랫폼과 서비스의 요구사항을 충족하기 위해 GKE를 혁신하고 발전시킨다는 것은 고객에게 동급 최고의 플랫폼을 제공한다는 의미입니다.

업데이트된 가격으로 유연성 강화

10년간의 진화를 거쳐 또 다른 변화가 찾아왔습니다. 모든 고객이 최대한 효과적으로 효율성, 성능, 비용의 균형을 유지할 수 있도록 GKE를 업데이트하고 있습니다. 2025년 9월부터는 더 많은 기능을 제공하고 필요에 따라 기능을 추가할 수 있는 단일 유료 등급의 GKE로 전환됩니다. 이제 모든 고객이 Fleet, 팀, 구성 관리, 정책 컨트롤러와 같은 멀티 클러스터 관리 기능을 추가 비용 없이 GKE Standard에서 사용할 수 있습니다.

항상 많은 사람들이 유연성과 다재다능함을 원합니다. 새로운 GKE 가격 책정 구조는 모든 클러스터의 구체적인 요구사항을 충족하기 위해 추가 기능에 대한 개별 액세스를 제공합니다. Google Cloud는 고객이 항상 가장 영향력 있는 작업에 리소스를 집중할 수 있도록 지원하고자 하며, 단일 GKE 가격 책정 등급이 워크로드와 예산을 보다 효과적으로 관리하는 데 도움이 될 것이라고 확신합니다.

모든 클러스터에 Autopilot으로 최적화된 컴퓨팅 제공

4년 전 GKE Autopilot을 출시하면서 Kubernetes 전문 지식이 없어도 모든 조직에서 Kubernetes를 사용할 수 있게 되었습니다. 최근에는 고유한 효율성과 성능 이점을 제공하는 새로운 컨테이너 최적화 컴퓨팅 플랫폼을 출시하여 워크로드에 할당된 리소스를 최대한 활용할 수 있도록 지원하고 있습니다. 따라서 동일한 용량으로 더 많은 트래픽을 처리하거나 더 적은 리소스로 기존 트래픽을 처리할 수 있습니다.

이제 기존 GKE Standard 클러스터를 포함한 모든 클러스터에서 임시로 워크로드별로 Autopilot을 사용할 수 있습니다. 조만간 기존의 모든 Standard 클러스터에서 Autopilot을 켜고 끌 수 있게 되어 최고의 가격으로 더 나은 성능의 완전 관리형 Kubernetes를 활용할 수 있게 됩니다.

aside_block: <ListValue: [StructValue([('title', 'Google Cloud 컨테이너 및 Kubernetes를 체험할 수 있는 $300 무료 크레딧 제공'), ('body', <wagtail.rich_text.RichText object at 0x7fdfb8deff10>), ('btn_text', ''), ('href', ''), ('image', None)])]>

고객 성공을 위한 혁신

기술 환경은 빠르게 변화하고 있습니다. 몇 년 전에는 조직에서 스테이트리스(stateless) 마이크로서비스에 대해 고민했지만, 오늘날에는 복잡한 AI 워크로드를 실행하는 데 초점을 맞추고 있습니다. Google Cloud는 혁신적인 기업의 새로운 시나리오에 대한 요구사항을 충족하기 위해 GKE를 지속적으로 조정하고 있습니다.

Google Cloud는 스타트업부터 기업과 AI 기업에 이르기까지 다양한 고객이 GKE를 기반으로 빌드한 수많은 놀라운 제품과 서비스를 자랑스럽게 생각합니다. AI 기반 광고 제공업체인 Moloco는 GKE에서 실행되는 TPU를 사용하여 모델을 학습시키고 실행합니다. Signify는 거의 10년 동안 GKE를 전 세계 Philips Hue 스마트 조명 플랫폼의 기반으로 활용해 왔습니다. AI 유니콘 Anthropic은 모델을 학습시키고 제공하는 데 필요한 규모를 제공하기 위해 GKE를 사용합니다.

"GKE의 대규모 클러스터에 대한 새로운 지원은 AI 혁신의 속도를 높이는 데 필요한 규모를 제공합니다." - James Bradbury, Anthropic 컴퓨팅 부문 책임자

일관된 발전을 위한 기반

AI 시대가 막 시작되었으며, Google Cloud는 GKE가 미래의 워크로드 요구사항을 오늘 바로 충족할 수 있도록 지원하고 있습니다. 고객 인사이트와 Google의 권장사항이 내장된 GKE는 AI를 대규모로 개발하고 배포하기 위한 이상적인 플랫폼입니다.

GKE 여정에 함께해 주신 커뮤니티, 고객, 파트너 여러분께 감사드립니다. GKE 10주년 기념 해커톤에 참여하고 GKE 10주년 기념 eBook을 읽으면서 GKE의 10주년을 함께 축하해 주세요. 미래는 매일 그 모습을 드러내고 있으며, GKE는 AI가 데려가는 곳이 어디든 준비되어 있습니다.

30개 이상의 구글 클라우드 서비스를 지원할 수 있도록 확장된 Custom Org Policy! 클라우드 액세스 제어의 새로운 장 열어...

Wed, 11 Dec 2024 20:00:00 +0000

* 해당 블로그의 원문은 2024년 12월 11일 Google Cloud 블로그(영문)에 게재되었습니다.

클라우드 리소스 보호에 있어, 관리자에게 중요한 도구 중 하나로 환경 전체에 일관성 있게 적용할 수 있고, 중앙 집중식으로 관리할 수 있고, 안전하게 배포할 수 있는 리소스 구성에 대한 가드레일 설정 기능을 꼽습니다. 여기서 말하는 가드레일 설정이란 클라우드 환경에서 리소스를 생성하고 관리할 때, 미리 정의된 규칙이나 제약 조건을 설정하여 시스템이 안전하게 운영될 수 있도록 하는 것을 말합니다.

구글 클라우드(Google Cloud)의 Custom Organization Policy는 클라우드 리소스 보호에 도움이 되는 강력한 도구입니다. 관리자는 Custom Organization Policy로 컴퓨팅 인스턴스, 스토리지, 네트워크 등의 클라우드 리소스를 세밀하게 조절하고 제한하여 보안 강화, 규제 준수, 운영 효율 증대 등을 달성할 수 있습니다. 더불어 일반적으로 보안 설정을 강화하면 시스템의 복잡성이 증가하고 개발 속도가 느려질 수 있지만 Custom Organization Policy를 사용하면 개발 작업에 불편을 끼치지 않습니다.

이처럼 유용한 Custom Org Policy가 30개 이상의 구글 클라우드 서비스를 지원한다는 발표가 2024년 12월 11일에 있었습니다.

이번 지원 확장으로 구글 클라우드를 이용하는 조직은 보안을 강화하는 가운데 클라우드 거버넌스 범위를 넓힐 수 있습니다.

aside_block: <ListValue: [StructValue([('title', '구글 클라우드의 보안 제품을 무료로 체험해보세요: $300 크레딧 제공'), ('body', <wagtail.rich_text.RichText object at 0x7fdfb88892b0>), ('btn_text', 'Start building for free'), ('href', ''), ('image', None)])]>

확장된 Custom Org Policy로 안전하게 액세스 제어 관리

클라우드 활용이 늘면서 보안 팀은 조직 전체에서 발생하는 모든 새로운 액세스 요청을 관리하는 데 어려움을 겪을 수 있습니다. 효과적으로 클라우드 적용을 확장하려면 조직은 개발자의 권한 부여와 보안 및 규제 사이의 균형을 맞추는 액세스 제어 운영 모델을 구축해야 합니다.

Custom Organization Policy와 IAM 정책을 통합하면 구글 클라우드 리소스 계층 구조(조직, 폴더, 프로젝트)의 원하는 수준에서 IAM 정책에 대한 제한을 설정하고, 후속 IAM 정책 관리를 개발자에게 위임할 수 있습니다. 이러한 환경에서 모든 정책 변경은 설정된 제한을 위반하지 않을 것입니다.

이 기능을 사용하여 관리자는 "이 프로젝트의 리소스에 대해 특정 역할만 부여 허용" 또는 "이 폴더에 대한 정책을 통해 특정 멤버에게만 액세스 부여 허용" 또는 "이 조직의 모든 리소스에 대해 "allUsers" 권한 부여 거부"와 같은 조건부 제한을 적용할 수 있습니다.

이와 같이 제한적인 정책을 사용하면 기존에 적용한 허용 규칙과 관련 없이 특정 리소스에 대한 액세스를 명시적으로 금지할 수 있습니다. 다음은 몇 가지 예입니다.

세분화된 제한 정책을 통해 기존의 허용 규칙에 관계없이 특정 리소스에 대한 액세스를 명시적으로 금지

code_block: <ListValue: [StructValue([('code', "resource_types: iam.googleapis.com/AllowPolicy\r\nmethod_types:\r\n - CREATE\r\n - UPDATE\r\ncondition:\r\n resource.bindings.exists(binding,\r\n RoleNameMatches(binding.role, ['roles/owner'])\r\n )\r\naction_type: DENY"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb88896d0>)])]>

조직의 모든 리소스에 대해 "allUsers" 권한 부여 거부

code_block: <ListValue: [StructValue([('code', 'resource_types: iam.googleapis.com/AllowPolicy\r\nmethod_types:\r\n - CREATE\r\n - UPDATE\r\ncondition:\r\n resource.bindings.exists(binding, \r\n RoleNameStartsWith(binding.role, ["roles/storage”]) && \r\n binding.members.exists(member, \r\n MemberSubjectMatches(member, [‘allUsers’, ‘allAuthenticatedUsers’])\r\n )\r\n )\r\naction_type: DENY'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb8889a00>)])]>

또한, Custom Organization Policy는 관리자가 클라우드 환경에서 더욱 세밀하고 유연하게 접근 권한을 관리할 수 있도록 도메인 제한 공유(Domain Restricted Sharing)를 확장합니다. 일례로 조직의 모든 사용자와 특정 파트너 ID, 서비스 계정 또는 서비스 에이전트를 허용하는 정책을 설정할 수 있습니다. 이러한 향상된 유연성을 통해 관리자는 ID를 추가하지 않고도 정책을 더 효과적으로 관리할 수 있습니다.

특정 조직 또는 특정 구성원만 허용

code_block: <ListValue: [StructValue([('code', 'resource_types: iam.googleapis.com/AllowPolicy\r\nmethod_types:\r\n - CREATE\r\n - UPDATE\r\ncondition:\r\n resource.bindings.all(\r\n binding, \r\n binding.members.all(member,\r\n MemberInPrincipalSet(member, \r\n [“//cloudresourcemanager.googleapis.com/organizations/123”,\r\n “//cloudresourcemanager.googleapis.com/organizations/456”]) \r\n || MemberSubjectMatches(binding.member, \r\n ["user:abc@vendor.com”, \r\n "user:xyz@vendor.com”]))\r\n )\r\naction_type: Allow'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb8889790>)])]>

Cloud SQL에 대한 강력한 데이터 거버넌스 구축

데이터 플랫폼 팀은 각 애플리케이션 팀이 다양한 SQL 제품을 사용할 때 보안 모범 사례를 준수하도록 하고 싶어 합니다. Cloud SQL에 대한 Custom Org Policy 지원을 통해 SQL 리소스에 대한 강력한 가드레일을 설정하고 데이터 거버넌스 요구 사항을 해결할 수 있습니다. 다음은 Custom Org Policy와 Cloud SQL의 강력한 조합을 보여주는 사례입니다.

각 애플리케이션 팀이 SQL 인스턴스에 대해 최신 데이터베이스 버전을 사용하도록 보장

code_block: <ListValue: [StructValue([('code', "resource_types: sqladmin.googleapis.com/Instance\r\nmethod_types:\r\n - CREATE\r\n - UPDATE\r\ncondition:\r\n resource.databaseVersion == 'MYSQL_8_4' || \r\n resource.databaseVersion == 'POSTGRES_16' || \r\n resource.databaseVersion == 'SQLSERVER_2022_EXPRESS' ||\r\n resource.databaseVersion == 'SQLSERVER_2022_WEB' || \r\n resource.databaseVersion == 'SQLSERVER_2022_STANDARD' || \r\n resource.databaseVersion == 'SQLSERVER_2022_ENTERPRISE'\r\naction_type: Allow"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb8889850>)])]>

모든 데이터베이스 인스턴스에 복잡한 암호 요구 사항을 적용하도록 보장

code_block: <ListValue: [StructValue([('code', "resource_types: sqladmin.googleapis.com/Instance\r\nmethod_types:\r\n - CREATE\r\n - UPDATE\r\ncondition:\r\n resource.settings.passwordValidationPolicy.enablePasswordPolicy == true && \r\n resource.settings.passwordValidationPolicy.complexity == 'COMPLEX' &&\r\n resource.settings.passwordValidationPolicy.minLength >= 8 &&\r\n resource.settings.passwordValidationPolicy.reuseInterval >= 10\r\naction_type: Allow"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb8889130>)])]>

Yahoo, Custom Org Policy로 보안 강화

Yahoo는 전 세계 수억 명의 사람들에게 서비스를 제공합니다. Yahoo의 클라우드 보안 팀은 보안 및 규제 요구 사항을 충족하기 위해 Org Policy 컨트롤을 적극적으로 사용합니다. Yahoo는 다양한 요구 사항과 인프라를 가지고 있습니다. 이에 따라 Yahoo의 보안 팀은 맞춤형 가드레일을 구축할 수 있는 유연성이 필요했습니다.

2023년 3월 이후 Yahoo의 플랫폼 엔지니어와 정보 보안 팀인 The Paranoids는 구글 클라우드와 협력하여 쿠버네티스 및 기타 클라우드 인프라에 Custom Org Policy를 적용했습니다.

관련해 Yahoo의 시니어 소프트웨어 개발 엔지니어인 Alex Verkhovtsev는 다음과 같이 이야기합니다. "Yahoo는 업계 표준 기준을 초과하는 24개의 Custom Org Policy를 구현하여 GKE 노드에 대한 보안 부팅과 같은 필수 요구 사항을 충족했습니다. Custom Org Policy가 제공하는 향상된 유연성을 활용하는 것 외에도 보안 컨트롤을 안전하게 확장하는 데 도움이 되었습니다. Yahoo의 엔지니어들은 이러한 가드레일이 Yahoo의 많은 정보 보안 정책을 준수하는 것을 자동으로 처리하기 때문에 더 이상 보안 요구 사항에 대해 적극적으로 걱정할 필요가 없습니다. Yahoo의 팀은 이러한 정책을 더욱 강화하고 이제 Cloud SQL, Cloud Run 및 IAM을 커버할 계획입니다. 새로운 제품과 사용 사례가 출시됨에 따라 Yahoo의 플랫폼 팀은 Custom Organization Policy의 추가적인 도입을 계획하고 있습니다. 요약하면, 이를 통해 Yahoo는 보안 태세를 대규모로 강화할 수 있었습니다.”

Custom Org Policy 시작하기

구글 클라우드는 Custom Org Policy를 지원하는 서비스를 지속적으로 확장하고 있으며, 이를 통해 클라우드 리소스를 더욱 효율적이고 유연하게 관리할 수 있습니다.

Custom Org Policy를 시작하려면 사용자 가이드와 개요 비디오를 확인하세요. 지원되는 서비스에 대한 자세한 정보와 사용 가능한 샘플을 확인하려면 링크를 참조바랍니다.

Google Cloud의 관리형 쿠버네티스 서비스 GKE가 컨테이너 환경의 소프트웨어 공급망 보안을 강화하는 방법!

Mon, 20 May 2024 16:00:00 +0000

* 본 아티클의 원문은 2024년 5월 18일 Google Cloud 블로그(영문)에 게재되었습니다.

소프트웨어 공급망은 우선순위 높은 보안 강화 대상입니다. 특히 컨테이너 이미지와 같은 빌드 아티팩트를 보호하는 것은 기업의 전체 시스템 보안을 강화하는 데 있어 매우 중요한 과제입니다. 그 이유는 무엇일까요? 컨테이너 이미지는 다양한 구성 요소로 이루어져 있어 공격자들이 악의적인 코드를 삽입하기 용이합니다. 실제로 공격자들은 컨테이너 이미지와 같은 빌드 아티팩트에 취약점을 심어 놓고, 이를 활용해 대규모 공격을 감행할 수 있습니다. 이처럼 잠재적인 위험이 크지만 기존 보안 도구로는 컨테이너 이미지와 컨테이너 상에서 운영하는 워크로드의 보안 상태를 파악하기 어렵습니다.

이런 현장의 고충을 해결하기 위해 Google Cloud는 GKE Security Posture 대시보드에 컨테이너 이미지와 컨테이너에서 운영하는 워크로드 관련 소프트웨어 공급망 보안 기능을 강화하고 있습니다. 참고로 GKE(Google Kubernetes Engine)는 Google Cloud가 제공하는 관리형 쿠버네티스 서비스입니다.

GKE Security Posture 대시보드의 강화된 보안 기능을 활용하면 효과적으로 컨테이너 이미지의 보안 상태를 파악하고 취약점 문제를 해결할 수 있습니다. 관리자는 대시보드를 참조해 컨테이너 설정의 취약점을 발견하고 보안 강화를 위한 구성 방법을 확인할 수 있습니다. 또한, 어떤 워크로드가 보안 문제의 영향을 받는지 대시보드에 명확히 표시되다 보니 신속하게 조처할 수 있습니다. 대시보드는 문제 해결 방법도 친절히 안내합니다. 관리자는 발견한 보안 문제를 해결하기 위한 지침을 대시보드에서 확인할 수 있습니다.

GKE Security Posture 대시보드로 투명하고 신속하게 위험을 찾아 대처!

소프트웨어 공급망의 투명성과 관리를 개선하기 위해 Google Cloud는 GKE Security Posture 대시보드에 "Supply Chain" 카드를 추가했습니다. 참고로 GKE Security Posture 대시보드에는 다양한 종류의 카드가 있는데, 각 카드는 특정 보안 영역에 대한 정보를 제공합니다. 관리자는 GKE Security Posture 대시보드를 열어 보안 상태를 확인하고자 하는 클러스터나 워크로드를 선택해 카드 내용을 확인할 수 있습니다.

현재 프리뷰 상태인 "Supply Chain" 카드는 GKE 워크로드와 관련된 잠재적인 공급망 위험을 시각화합니다. 초기 상태인 현재 시점을 기준으로 관리자는 다음 두 가지 정보를 카드에서 확인할 수 있습니다.

오래된 이미지: 최근 30일 동안 업데이트가 이루어지지 않은 모든 이미지를 식별해 최신 취약점에 노출될 수 있는 위험을 알려줍니다.
"latest" 태그 사용: 정확한 버전 관리와 침해 발생 시 보안 분석가의 추적을 어렵게 하는 요인 중 하나인 "latest" 태그를 사용하는 이미지를 파악할 수 있습니다.

GKE 클러스터에서 실행되는 이미지는 Binary Authorization 서비스가 검사합니다. 관리자는 "Supply Chain" 카드에서 간략히 문제를 요약한 내용을 볼 수 있으며, GKE Security Posture 대시보드의 "Concerns" 탭에서 더 자세한 내용을 확인할 수 있습니다. 이 과정을 자세히 소개하면 다음과 같습니다.

Google Cloud 콘솔에서 GKE Security Posture 페이지로 이동합니다. 기능을 활성화하지 않았다면 먼저 Security Posture 기능을 활성화합니다.
"Supply Chain" 카드에서 "Enable Binary Authorization API"를 클릭한 다음 기능을 활성화합니다.
팝업 창의 "Supply Chain" 섹션에서 "Enable"을 클릭합니다.

GKE Security dashboard.

4. "image freshness" 또는 "latest tag" 관련 문제가 15분 이내에 "Supply Chain" 카드에 표시됩니다.

5. 문제를 클릭해 세부 정보를 확인하고 "Affected Workloads" 탭에서 선택한 문제에 영향을 받는 워크로드 목록을 확인합니다.

GKE Security dashboard.

지금 바로 활용해 보세요!

GKE Security Posture의 새로운 프리뷰 기능은 소프트웨어 공급망 문제를 해결하고 워크로드 보안을 강화하기 위한 Google Cloud의 지속적인 노력의 하나입니다. 몇 달 내에 Google Cloud는 더 복잡한 소프트웨어 공급망 관련 위험을 검사할 수 있는 기능을 추가할 계획입니다. 이를 통해 Google Cloud는 컨테이너 환경의 보안을 강화하고 애플리케이션과 워크로드의 투명성을 높일 방침입니다.

GKE의 강화된 보안 기능이 궁금하다면? Binary Authorization과 GKE Security Posture 대시보드에 대해 자세히 알아보세요.

Kubernetes 서비스로 GKE를 선택해야 하는 이유

Mon, 18 Dec 2023 01:00:00 +0000

*본 아티클의 원문은 2023년 11월 3일 Google Cloud 블로그(영문)에 게재되었습니다.

Kubernetes는 최신 소프트웨어 개발 환경에서 중요한 역할을 하고 있습니다. 당초 Google에서 개발한 Kubernetes는 현재 역사상 두 번째로 큰 오픈소스 프로젝트로서, 지난 10년간 83,000명이 넘는 기여자가 참여했으며 프로덕션 환경에서 컨테이너화된 애플리케이션을 실행하기 위한 사실상 표준으로 인정받고 있습니다.

Kubernetes는 클라우드의 대중화에 기여했으며, 덕분에 모든 규모의 비즈니스에서 컨테이너화의 이점과 더불어 클라우드를 활용할 수 있게 되었습니다. 다양한 애플리케이션을 실행할 수 있는 강력하고 유연한 플랫폼인 Kubernetes는 모든 규모의 기업에서 사용되고 있으며 세계에서 가장 규모가 크고 복잡한 일부 애플리케이션을 지원합니다. 근래에는 생성형 AI와 대규모 언어 모델(LLM)이 폭증하면서 기업에서 복잡하고 컴퓨팅 집약적인 머신러닝 플랫폼을 실행하고 확장하는 데 Kubernetes의 힘을 빌리고 있습니다.

Kubernetes는 오픈소스 소프트웨어의 위력을 입증한 성공 사례입니다. 극단적일 만큼 개방적인 커뮤니티 중심 프로젝트로서 전 세계 수만 명의 개발자가 Kubernetes의 기능을 향상하고 새로운 사용 사례에 맞게 조율하는 데 참여하고 있습니다. 결과적으로 Kubernetes는 오픈소스에서만 가능한 속도로 계속 진화하고 있습니다.

전체 산업의 기회를 확대한 Kubernetes의 오픈소스 제공

Google에서 개발한 Kubernetes는 2014년에 오픈소스로 출시되었습니다. 그 뿌리는 Google 검색부터 Google 지도, YouTube에 이르는 모든 서비스의 기반이 된 Google 내부의 Borg 시스템(2003~2004년 사이에 출시됨)으로 거슬러 올라갑니다. Google에서 매주 출시하는 컨테이너 수는 평균 40억 개가 넘습니다.

Kubernetes의 오픈소스 제공은 혁신적인 움직임이었습니다. 이를 통해 Cloud Native Computing Foundation(CNCF)이 설립되고 전 세계 기여자와 사용자로 이루어진 커뮤니티가 형성되었습니다. 이 글로벌 커뮤니티가 점점 커짐에 따라 Google은 Kubernetes가 성장을 지속할 수 있도록 관리자 역할을 수행하고 꾸준한 리더십을 발휘하는 등, 그 어느 때보다 Kubernetes에 큰 노력을 기울이고 있습니다.

오늘날 Google은 Kubernetes의 최대 기여자로서 기여 횟수가 100만 건이 넘습니다. 이는 2위부터 5위까지의 조직 4곳을 합친 횟수보다 더 많은 수치입니다. 시간과 개발 리소스를 투자하는 것 외에도 Google Cloud는 매년 수백만 달러를 기부하여 Kubernetes 컨테이너를 호스팅하고 각 출시 버전을 빌드 및 테스트하는 데 필요한 인프라를 지원하고 있습니다.

지난 한 해 동안 클라우드 제공업체만의 기여도를 살펴보면 Google Cloud의 기여도가 2위로 기여한 제공업체보다 3배 더 높았습니다.

출처: Kubernetes 기업 통계 - 지난 한 해

Google Cloud는 Kubernetes에 매우 광범위하게 참여하고 기여합니다.

API Machinery, Autoscaling, Networking, Scheduling, Storage를 비롯한 SIG, Special Interest Groups에서 공동 의장 및 기술 리더로 활약하고 있습니다.
커뮤니티와 Google 고객 모두에게 영향을 주는 복잡한 문제를 파악하고 해결합니다. 예를 들어 Google은 커뮤니티와 더불어 모든 Kubernetes의 업그레이드 및 지원 중단을 개선하는 데 막대한 투자를 해왔으며, 이는 모든 고객에게 훨씬 더 안정적인 플랫폼을 제공하는 데 도움이 되었습니다.
Kubernetes에서 발견된 보안 취약점 중 절반 이상을 해결하고 있습니다. Kubernetes 보안 향상을 위한 이 같은 노력은 사용자를 위해 Kubernetes를 안전하게 보호하고자 하는 Google의 의지를 보여줍니다.
Go 관련 작업을 수행하는 Google 직원과 긴밀하게 협력하여 업데이트된 Go 버전으로 Kubernetes를 안전하게 보호합니다. Go팀은 Kubernetes 코드 작성에 사용되는 Go 프로그래밍 언어를 개발하는 업무를 맡고 있습니다. Google 직원은 Go팀과 긴밀하게 협업하여 Kubernetes가 최신 Go 버전과 호환되도록 하고 Go에서 발견된 모든 보안 취약점을 해결합니다.
Kubernetes 포드 보호를 위한 일련의 권장사항인 포드 보안 표준 개발에 앞장서고 있습니다. Google 직원은 이러한 표준 개발을 주도해 왔으며 사용자가 Kubernetes 포드를 보호하는 데 도움이 되는 여러 가이드와 리소스를 게시하고 있습니다.
컨테이너로 스토리지에 액세스할 수 있는 방법을 정의하는 초기 컨테이너 스토리지 인터페이스(Container Storage Interface, CSI) 사양을 만들었습니다. Google 직원이 CSI의 초기 개발에 참여했으며 초기 사양을 만드는 데 도움을 주었습니다. CSI는 현재 오픈소스 및 상업용 스토리지 공급업체에서 널리 사용되고 있습니다.
정형 데이터에 대해 쿼리와 변환을 표현하기 위한 Common Expression Language(CEL)를 만들었습니다. CEL은 허용 정책 검증과 커스텀 리소스 유효성 검사 표현식을 포함한 다양한 Kubernetes 구성요소에 사용됩니다. CEL은 강력하고 유연한 언어로 Kubernetes의 확장 가능성과 사용성을 개선하는 데 도움이 되었습니다.

Google은 Kubernetes에 상당한 기여를 해왔으며 플랫폼을 더욱 견고하고 확장 가능하며 안전하고 안정적으로 만드는 데 일조했습니다. 더 나아가 Google은 일괄 처리, 머신러닝과 같은 새로운 영역으로 Kubernetes를 확대 적용하면서 Kueue를 사용한 작업 큐잉, Kubeflow를 사용한 ML 작업 및 워크플로 등 CNCF에도 기여하고 있습니다. 이러한 기여는 매우 중요합니다. Kubernetes 커뮤니티가 발전하고 있다면 이는 개인과 회사로 구성된 핵심 그룹이 Kubernetes의 실질적인 발전을 위한 핵심적인 작업에 시간을 투자하고 모두에게 유익한 새로운 기능을 빌드하고 있기 때문입니다. Kubernetes가 AI/ML 같은 새로운 워크로드에도 적합한 플랫폼이 되려면 이러한 워크로드를 처리하는 데 Kubernetes를 활용하고 또 Kubernetes에 기여하는 회사가 더 많아져야 합니다.

고객이 중요한 워크로드에 Google Kubernetes Engine을 믿고 활용하는 이유

Google Kubernetes Engine(GKE)은 가장 확장성이 뛰어나고 완전히 자동화된 Kubernetes 서비스입니다. 업종이나 규모에 관계없이 모든 비즈니스에서 널리 사용되고 있으며 세계에서 가장 크고 복잡한 애플리케이션을 호스팅하는 데에도 사용됩니다. GKE를 사용하면 Google Cloud의 전문성으로 뒷받침되는 안정적이고 확장 가능한 플랫폼에서 애플리케이션이 실행된다는 확신을 가질 수 있습니다. GKE에는 이제 멀티 클러스터 및 분산 팀 관리, 정책 컨트롤러를 사용한 정책 시행, 구성 동기화를 사용한 GitOps 기반 구성, 구성 컨트롤러를 사용한 Google Cloud 리소스의 셀프서비스 프로비저닝, 완전 관리형 Istio 지원 서비스 메시 기능이 포함되어 있습니다. 이 모든 새로운 기능은 GKE Enterprise와 통합되어 있으며, Kubernetes를 사용하기 시작했거나 이미 전 세계에 배포한 고객에게도 이상적입니다.

고객이 중요한 애플리케이션을 실행하는 데 GKE를 사용하는 이유에는 여러 가지가 있습니다.

Kubernetes를 만든 팀보다 내 환경을 더 잘 운영하고 관리할 수 있는 팀이 있을까요? 오픈소스 Kubernetes 프로젝트 전체가 Google Cloud에서 빌드, 테스트, 배포되며 GKE는 Vertex AI와 DeepMind를 비롯한 여러 서비스에 사용되고 있습니다.
GKE는 2023년 Gartner Magic Quadrant의 컨테이너 관리 부문에서 리더로 선정되었습니다.
GKE는 GPU 시간 공유 및 Cloud TPU를 통해 AI/ML 워크로드를 가속화하고 효율적으로 확장합니다.
GKE는 GKE Autopilot을 통해 최초의 완전 관리형 서버리스 Kubernetes 환경을 제공합니다. GKE Autopilot은 기본 컴퓨팅 인프라를 관리하는 핸드오프 작업 모드이자 Kubernetes API의 모든 기능을 제공하고 포드 수준의 SLA와 명성 높은 Google SRE팀의 지원을 받습니다.
GKE는 독보적으로 15,000개의 노드 클러스터까지 확장할 수 있어 가장 크고 까다로운 애플리케이션의 니즈도 충족합니다. 예를 들어 PGS에서는 Cray를 72.02페타플롭스 용량의 GKE 기반 슈퍼컴퓨터로 대체했습니다.
GKE는 잘못 구성된 워크로드와 컨테이너 이미지 취약점을 검사하는 GKE Security Posture, Kubernetes 네트워크 정책이 기본 제공되는 네트워크 정책 시행, 신뢰하지 않는 워크로드를 격리하기 위한 GKE Sandbox, 사용 중인 워크로드 데이터를 암호화하기 위한 Confidential Nodes 같은 기능으로 엔터프라이즈급 보안을 제공합니다.
GKE는 블루-그린 업그레이드, 유지보수 기간 및 유지보수 제외 등 세밀한 제어 도구를 사용해 원활하게 자동 업그레이드할 수 있습니다.
비즈니스, 규제, 규정 준수 관련 니즈 및 요구사항을 충족하는 유연한 배포 옵션입니다. Google Distributed Cloud(완전 관리형 하드웨어 및 소프트웨어 배포 옵션을 통해 Google Cloud를 고객 데이터 센터 또는 에지 위치로 확장), AWS와 Azure로 멀티 클라우드 배포, CNCF와 호환되는 Kubernetes 클러스터를 연결하고 관리하는 기능이 여기에 포함됩니다.
Google Cloud는 최초의 Kubernetes 비용 최적화 상태 보고서를 발행하는 등 비용 최적화된 애플리케이션 실행에 관한 전문 지식을 갖추고 있습니다.
Google Cloud는 새로운 오픈소스 버전을 출시하고 약 30일 후에 이에 상응하는 GKE 마이너 버전을 출시하여 GKE 사용자가 최대한 빨리 최신 보안 패치와 기능에 액세스할 수 있도록 합니다.

마이크로서비스부터 데이터베이스, 가장 까다로운 생성형 AI 워크로드에 이르기까지 무엇을 실행하든 확장 가능하고 안정적인 완전 관리형 Kubernetes 서비스를 찾고 계신다면 GKE가 가장 적합한 선택이 될 것입니다.

Google, 2023년 Gartner® Magic Quadrant™의 컨테이너 관리 부문에서 선두 기업으로 선정

Mon, 27 Nov 2023 01:00:00 +0000

*본 아티클의 원문은 2023년 9월 27일 Google Cloud 블로그(영문)에 게재되었습니다.

Gartner가 Google Cloud를 평가하여 Google을 2023년 Gartner® Magic Quadrant™ 컨테이너 관리 부문의 선두 기업으로 선정했다는 반가운 소식을 알려드립니다. Google은 후보인 모든 컨테이너 공급업체 중 실행 능력(Ability to Execute) 면에서 최고로 선정되었으며 이로써 고객이 어디서든 컨테이너화된 워크로드를 실행할 수 있도록 최적의 환경을 제공하고자 하는 사명을 다하는 데 성공했음을 입증했습니다. Gartner는 '2021년에는 프로덕션 환경에서 컨테이너화된 애플리케이션을 실행하는 조직이 전 세계 조직의 40% 미만에 불과했지만 2027년에는 90% 이상으로 크게 증가할 것'이라고 예측합니다. Google Cloud는 컨테이너가 오늘날 가장 혁신적인 앱과 비즈니스를 지원하고 있으며 수년 내에 비즈니스에 더 큰 변화와 혁신을 가져올 것이라고 기대합니다.

Google Cloud의 여정은 2014년 Kubernetes를 도입하고 Google Kubernetes Engine(GKE)을 출시하면서 시작되었으며 이는 세계 최초의 관리형 Kubernetes 서비스였습니다. GKE는 현재 관련 업계에서 제공하는 Kubernetes 서비스 중 가장 확장성이 좋은 최고 수준의 Kubernetes 서비스입니다. Google Cloud에서는 2019년 컨테이너와 서버리스의 장점을 결합한 첫 번째 플랫폼인 Cloud Run을 출시했습니다. 현재 Cloud Run은 최고의 개발자 환경을 제공하는 클라우드 제공 플랫폼 중 하나입니다. 또한 Google Cloud는 2019년 Anthos를 사용하여 GKE를 하이브리드와 멀티 클라우드 환경으로 확장했고 2021년 GKE에 Autopilot 모드를 도입했습니다. 올해에는 Google Cloud의 컨테이너 관리 플랫폼 범위를 Google Distributed Cloud로 확장했습니다.

Google Cloud에서 다른 클라우드, 데이터 센터, 에지에 이르기까지 고객이 컨테이너를 빌드하고 실행하는 곳이 어디든지 Google Cloud는 모든 워크로드에 가장 단순하고 포괄적이며 안전하고 믿을 만한 컨테이너 플랫폼을 전달하는 것을 목표로 합니다.

Google Cloud는 고객이 컨테이너를 사용하여 비즈니스를 현대화하고 혁신할 수 있도록 돕는다는 사명을 지금도 계속 이어가고 있습니다. Google Cloud는 플래그쉽 행사인 Google Cloud Next '23 컨퍼런스에서 당사 컨테이너 관리 제품에 대해 '컨테이너 플랫폼의 차세대 진화'라고 불리는 강력한 개선사항을 소개했습니다. 주요 변화는 다음과 같습니다.

GKE의 새로운 프리미엄 버전인 GKE Enterprise. GKE Enterprise는 컨테이너와 Kubernetes 부문에서 Google Cloud가 발휘하는 리더십을 기반으로 빌드되어 통합된 콘솔 환경에서 GKE와 Anthos의 장점을 직관적인 통합 컨테이너 플랫폼에 결합합니다. 또한 GKE Enterprise에는 하이브리드와 멀티 클라우드 지원이 포함되므로 어디에서나 컨테이너 워크로드를 실행할 수 있습니다.
차세대 AI 애플리케이션을 개발하는 조직을 위한 GKE의 Cloud TPU v5e 지원. NVIDIA H100 GPU가 탑재된 A3 VM과 GKE용 Cloud Storage Fuse 모두 정식 버전을 발표했습니다.
GKE의 Duet AI와 Cloud Run은 생성형 AI를 활용하여 고객 컨테이너 플랫폼 팀의 생산성과 속도를 높입니다. Google Cloud의 컨테이너 관리 제품 문서에 대해 구체적으로 학습된 Duet AI를 사용하는 고객은 컨테이너화된 애플리케이션을 실행하고 최적화하는 데 소요되는 시간을 줄일 수 있습니다.

Kubernetes에서 AI까지 Next '23에서 발표한 모든 컨테이너 관리 주요 혁신들과 가장 중요한 컨테이너화된 워크로드에 맞게 효율성, 신뢰성, 보안을 개선하기 위해 Google Cloud가 고객을 지원하는 방법을 확인해 보세요.

Google Cloud는 2014년 이후 많은 발전을 이뤄왔고 이번에 Gartner로부터 컨테이너 관리 부문의 선두 기업으로 인정받게 되어 매우 감격스럽습니다. Google Cloud의 컨테이너 관리 제품을 신뢰해 주신 전 세계 고객에게도 감사의 인사를 드립니다. 다음은 몇 가지 고객 사례입니다.

BBC는 Cloud Run을 사용하여 트래픽 급증을 처리하고 150~200개의 컨테이너 인스턴스를 단 몇 분 만에 1,000개 이상으로 확장하며 매주 성인 기준 4억 9,800만 명 이상의 시청자에게 콘텐츠를 제공하고 있습니다.
Carrefour는 GKE와 Cloud Run을 함께 사용하여 새로운 전자상거래 앱을 운영하고 있습니다.
Equifax는 GKE를 전 세계 데이터 패브릭의 기초로 사용하고 있으며 이를 통해 8개 지역에 걸쳐 2,500억 개의 데이터 포인트를 분석하고 전 세계 고객이 최상의 재정 상태를 유지할 수 있도록 지원하고 있습니다.
GKE 최대 고객사 15곳은 이미 이 솔루션을 사용하여 AI 워크로드를 지원하고 있습니다. 실제로 작년 한 해 동안 GKE를 활용한 GPU 사용이 두 배 증가했습니다. grammarly, Lightricks, character.ai가 GKE를 연동하여 대규모 AI 모델을 빌드한 방법을 알아보세요.

Google Cloud는 2023년 Gartner® Magic Quadrant™ 컨테이너 관리 부문의 선두 기업으로 선정된 것을 영광스럽게 생각하며 계속해서 디지털 혁신 여정에서 새로운 방법을 발견하고 고객들과 함께 협력할 수 있기를 기대합니다.

보고서: 2023년 Gartner® Magic Quadrant™ 컨테이너 관리 부문을 무료로 다운로드하세요. 조직에서 Google Cloud의 컨테이너를 활용하여 비즈니스를 혁신하는 방법을 자세히 알아보세요.

GKE용 멀티 클러스터 게이트웨이 컨트롤러 정식 버전 출시

Thu, 23 Nov 2023 01:00:00 +0000

*본 아티클의 원문은 2023년 11월 1일 Google Cloud 블로그(영문)에 게재되었습니다.

Google Kubernetes Engine(GKE)을 사용하는 많은 기업에서는 분산형 애플리케이션 구축이 주류가 되었습니다. 지난 몇 년 동안 Google Cloud는 GKE 사용자의 클러스터 Fleet 관리를 지원하기 위해 멀티 클러스터 인그레스(종방향(North-South) 트래픽용) 및 멀티 클러스터 서비스(횡방향(East-West) 트래픽용)와 같은 기능을 출시해 제공해 왔습니다.

동시에 Kubernetes 커뮤니티는 선언적이고 확장 가능하며 역할 기반의 포팅 가능한 Service Networking API인 Gateway API를 만들었습니다. 2022년 12월에는 단일 클러스터 GKE 배포를 지원하는 Kubernetes Gateway API의 첫 번째 구현을 발표했습니다.

오늘 Google Cloud에서는 Kubernetes Gateway API를 사용하여 GKE 클러스터 Fleet 전체에 대한 통합 애플리케이션 부하 분산기 배포를 지원하는 GKE 용 멀티 클러스터 게이트웨이 컨트롤러의 정식 버전이 출시되었다는 기쁜 소식을 전해드립니다. 이제 GKE 사용자들은 블루-그린 배포 또는 지리적 분산형 애플리케이션과 같은 정교한 패턴을 구현함과 동시에 애플리케이션 부하 분산기와 통합된 고급 보안 기능을 통해 가장 중요한 자원을 보호할 수 있습니다.

GKE 멀티 클러스터 게이트웨이 컨트롤러 소개

GKE Gateway Controller는 Cloud Load Balancing용 Gateway API를 구현한 Google의 제품입니다. 이 게이트웨이 컨트롤러는 다른 Kubernetes 컨트롤러와 마찬가지로 Gateway API 리소스를 감시하고 관리형 Cloud Load Balancing 리소스를 생성하여 게이트웨이 리소스에서 지정한 네트워킹 동작을 구현합니다.

멀티 클러스터 게이트웨이 컨트롤러는 GKE control plane 노드에서 실행되지 않는 멀티 테넌트 서비스를 위해 Google이 호스트하는 컨트롤러로, 대규모 분산형 Google Cloud 인프라를 활용하여 한층 향상된 견고함과 가용성을 제공합니다.

멀티 클러스터 게이트웨이 시작하기

오늘날의 애플리케이션 가용성 요구사항을 충족하기 위해 여러 클러스터에 배포된 서비스(멀티 클러스터 서비스)를 참조한다는 점을 제외하면 멀티 클러스터 게이트웨이는 단일 클러스터 게이트웨이와 근본적으로 다르지 않습니다.

클라이언트에게 서비스를 제공할 수 있는 충분한 용량을 확보하고 싶거나, 블루-그린 배포를 통해 여러 팀에 인프라를 제공하고 싶거나, 리전 다운타임이 발생하더라도 애플리케이션을 계속 사용할 수 있도록 하려면 멀티 클러스터 게이트웨이 및 서비스를 애플리케이션 인프라 설계의 필수 구성요소로 활용해야 합니다.

멀티 클러스터 게이트웨이는 GKE Enterprise에 포함되어 추가 비용 없이 제공되며, GKE Standard 버전을 사용하는 고객도 이를 독립형 솔루션으로 활용할 수 있습니다. 두 버전 모두 GKE Autopilot 및 GKE Standard 클러스터와 함께 멀티 클러스터 게이트웨이를 사용할 수 있습니다.

지원되는 Cloud 부하 분산기

Google Cloud 내에서 Gateway API 리소스를 사용하면 Cloud Load Balancing의 세부정보를 추상화하고 Kubernetes 기반 언어를 사용하여 하나 이상의 애플리케이션에 대한 라우팅을 표현할 수 있습니다.

현재 멀티 클러스터 게이트웨이는 고객이 다양한 사용 사례에 활용할 수 있도록 다음과 같은 애플리케이션 부하 분산기를 지원합니다.

각 GatewayClass 기능에 대해 자세히 알아보려면 이 가이드를 참조하세요.

GKE Fleet에서 전역 및 리전 라우팅 최적화

Gateway API의 이점 중 하나는 라우팅 및 트래픽 관리 측면에서 표현력이 뛰어나다는 점이며, 이는 Google Cloud의 구현에서도 마찬가지입니다. 가중치 또는 라우팅 규칙 필터와 같은 백엔드 속성을 사용하면 특정 HTTP 경로 또는 헤더와 일치하도록 게이트웨이를 맞춤설정하고 여러 클러스터 또는 리전에서 실행되는 백엔드 목록에 정교한 라우팅 정책을 적용할 수 있습니다.

GKE 플랫폼 관리자는 Cloud 부하 분산기의 강력한 기능을 활용하여 애플리케이션팀에 일련의 트래픽 관리 기능을 제공함으로써 서비스의 효율성과 가용성을 높일 수 있습니다. 몇 가지 예를 살펴보겠습니다.

점진적 배포(블루-그린 업그레이드 또는 배포)

플랫폼팀은 새 클러스터에서 새 GKE 버전을 검증하고 워크로드와 서비스를 점진적으로 새 클러스터로 마이그레이션하여 블루-그린 업그레이드를 수행할 수 있습니다. 여러 클러스터에 걸쳐 트래픽 분할을 사용하면 운영이 크게 단순화되고 플랫폼팀과 애플리케이션팀의 원활한 GKE 업그레이드 프로세스가 보장됩니다.

또한 애플리케이션팀은 멀티 클러스터 아키텍처의 이점을 활용하여 애플리케이션의 새 버전에 블루-그린 배포 전략을 사용할 수 있습니다. 이렇게 하면 애플리케이션 버전 1은 '블루' 클러스터에서 실행되고 애플리케이션 버전 2는 '그린' 클러스터에서 실행됩니다. 애플리케이션팀은 애플리케이션이 새 버전으로 완전히 마이그레이션될 때까지 특정 경로나 헤더를 기반으로 v1에서 v2로 트래픽을 전환하는 결정을 내릴 수 있습니다.

마지막으로 첫 번째 클러스터에서 실행되는 서비스로 전송된 트래픽을 다른 클러스터로 미러링해야 하는 경우(예: 규정 준수나 클라이언트 트래픽 분석 또는 문제 해결 목적) 애플리케이션팀은 멀티 클러스터 게이트웨이를 사용하여 해당 트래픽을 미러링하고 프로덕션 클러스터와 '감사' 클러스터로 동시에 트래픽을 전송할 수 있습니다.

이러한 기능은 클러스터가 동일한 리전의 다른 영역에 배포되든 여러 리전에 걸쳐 배포되든 관계없이 리전 및 전역 멀티 클러스터 게이트웨이에서 사용할 수 있습니다.

근접 라우팅을 사용하는 분산형 애플리케이션

여러 리전에서 분산형 애플리케이션을 실행하는 고객은 애니캐스트 IP가 포함된 전역 외부 멀티 클러스터 게이트웨이를 사용하여 클라이언트에서 가장 가까운 Google 에지 접속 지점(PoP)으로 클라이언트 트래픽을 유인하고 Fleet의 모든 클러스터에서 사용할 수 있는 가장 가까운 리전 백엔드로 트래픽을 전달할 수 있습니다.

트래픽을 지역내에 유지해야 하는 규제에 통제 받는 고객은 리전 IP가 있는 리전 외부 멀티 클러스터 게이트웨이를 사용하여 현지 규정을 더욱 잘 준수할 수 있습니다. 이 경우 클라이언트 트래픽은 인터넷을 통해 게이트웨이 IP가 공지되는 대상 리전으로 라우팅되고 트래픽은 리전 백엔드로만 라우팅됩니다.

용량 기반 부하 분산

마지막으로 서비스의 양호한 상태를 보장하기 위해 트래픽 제한이 필요한 애플리케이션을 빌드하는 고객은 서비스 용량(엔드포인트당 최대 요청)을 정의하고 백엔드 파드(pod)로 전송되는 요청 개수에 따라 트래픽 부하를 분산할 수 있습니다. 서비스는 여러 클러스터에 걸쳐 완전히 분산될 수 있으며, 멀티 클러스터 게이트웨이는 모든 백엔드 파드에 걸쳐 최적의 트래픽 분산을 보장할 뿐 아니라 요청 개수가 정의된 서비스 용량보다 많을 때는 다른 리전으로 요청을 넘겨서 수행되게 합니다.

멀티 클러스터 게이트웨이로 노출된 애플리케이션 보호

GKE 클러스터 Fleet에 배포된 인터넷으로 서비스되는 분산형 애플리케이션은 DDoS 공격 및 기타 보안 위협에 취약하므로 트래픽의 개인 정보 보호 및 무결성을 보장하려면 추가 보안 계층이 필요합니다. 애플리케이션 부하 분산기의 GKE 관리형 구현인 멀티 클러스터 게이트웨이를 사용하면 Google Cloud 부하 분산기의 모든 고급 보안 기능을 활용할 수 있습니다. 자세한 내용을 알아보려면 계속 읽어보세요.

기밀성과 무결성을 위한 TLS 암호화

웹 애플리케이션 보안 전략의 첫 번째 단계는 원하지 않는 트래픽이 백엔드 파드가 아닌 게이트웨이 수준에서 종료되도록 SSL 정책을 정의하는 것입니다. 이 단계는 애플리케이션 수준에서 정체를 사전에 방지하는 데 도움이 됩니다.

그런 다음 HTTPS 트래픽을 신뢰할 수 있도록 클라이언트-게이트웨이 및 게이트웨이-백엔드 트래픽에 자체 관리형 또는 Google 관리형 TLS 인증서를 사용할 수 있습니다. 인증서는 선택에 따라 GKE 클러스터에 secret으로 저장하거나(이 경우 Fleet 환경에서 얼마간의 조정이 필요함) 부하 분산기 수준에 직접 저장할 수 있습니다. 멀티 클러스터 게이트웨이는 게이트웨이에 로컬로 저장된 인증서를 최대 15개까지 지원합니다. 그 이상은 최대 1백만 개의 인증서를 지원하는 인증서 관리자를 사용하여 애플리케이션 트래픽을 보호할 수 있습니다.

애플리케이션팀은 정책과 필터의 조합을 사용하여 트래픽을 HTTP에서 HTTPS로 리디렉션함으로써 해당 트래픽이 엔드 투 엔드로 암호화되도록 지원할 수 있습니다..

Cloud Armor로 게이트웨이 백엔드 제어 및 보호

대부분의 경우 보안팀은 원치 않는 인바운드 트래픽을 방지하기 위해 모든 플랫폼과 애플리케이션에 기본 보안 정책을 시행할 것을 요구합니다. 한 지리적 위치에서만 서비스를 제공하는 일부 조직에서는 해당 위치의 IP 주소들만 애플리케이션에 액세스하도록 제한하고 싶을 수 있습니다. 마찬가지로 어떤 조직은 DDoS 공격을 방지하기 위해 악성 IP 주소를 차단하고 싶어 합니다. 또한 인터넷 연결 애플리케이션이 SQLi, XSS 등 정교한 애플리케이션 레이어 공격을 받을 수도 있습니다. 애플리케이션팀에서는 웹 애플리케이션 방화벽을 사용하여 이러한 공격을 완화할 수 있습니다.

다중 계층 웹 애플리케이션 방화벽인 Cloud Armor를 사용하는 조직은 네트워크 수준에서 트래픽을 필터링할 뿐 아니라 세분화된 보안 정책으로 애플리케이션 수준에서 심층 패킷 검사를 수행함으로써 GKE Fleet에서 실행되는 가장 중요한 자원을 제어하고 보호할 수 있습니다.

플랫폼팀과 애플리케이션팀은 멀티 클러스터 게이트웨이를 사용하여 백엔드 정책을 설정하고 게이트웨이를 참조하는 방법으로 애플리케이션에 이 보안 제어를 추가할 수 있습니다.

IAP(Identity-Aware Proxy)로 트래픽 인증 및 승인

적절한 네트워크 수준 제어(예: SSL 정책, TLS 인증서, Cloud Armor)에 더해 애플리케이션팀은 HTTPS 애플리케이션에 대한 사용자 ID를 기반으로 또 다른 인증 및 승인 계층을 추가할 수 있습니다.

IAP(Identity-Aware Proxy)는 멀티 클러스터 게이트웨이 수준에서 이러한 액세스 제어 권한을 제공합니다. 이 기능은 사용자가 누구인지(Google 계정 사용자 인증 정보를 통해), 사용자의 역할과 권한이 무엇인지(Identity and Access Management를 사용하여)를 확인하여 GKE 클러스터 Fleet에서 실행 중인 백엔드에 대한 액세스가 인증되었는지 확인하는 데 도움이 됩니다.

다시 한 번 백엔드 서비스에 연결된 백엔드 정책을 사용하여 애플리케이션팀은 애플리케이션에 대한 적절한 액세스 수준을 설정하고, 최종 사용자 또는 시스템에 애플리케이션을 안전하게 노출하며, 사용자 ID를 기반으로 애플리케이션에 대한 액세스를 로깅할 수 있습니다.

다음 단계

Gateway API와 GKE Fleet의 맥락에서 GKE Gateway Controller를 사용하는 방법에 대해 알아볼 수 있는 리소스가 많이 있습니다. Google 구현과 이를 통해 조직에서 기대할 수 있는 이점에 대해 자세히 알아보려면 다음 링크를 확인하세요.

며칠 후에 열리는 시카고 KubeCon NA에서도 Google Cloud를 만나볼 수 있습니다.

언제든지 Google Cloud팀에 문의해 주시고 부스에도 방문해 주세요. 세션에 대해 알아보고, 상담을 요청하여 사용 사례에 관해 논의하고 Google Cloud가 어떤 도움을 드릴 수 있는지 알아보세요. 11월 8일 수요일 오후 2시에 진행되는 멀티 클러스터 게이트웨이에 대한 강연을 비롯해 멀티 클러스터 게이트웨이로 분산형 애플리케이션의 가용성을 개선하는 방법 등 부스에서 다양한 라이트닝 토크를 진행할 예정입니다.

마지막으로 KubeCon에서는 Kubernetes용 부하 분산기와 관련해서는 물론 서비스 메시 사용 사례 지원을 위한 최신 GAMMA 이니셔티브의 맥락에서 Gateway API를 다루는 많은 소그룹 세션도 찾아볼 수 있습니다. 관련 세션을 확인하고 고도의 공동작업 네트워킹 API에 대해 자세히 알아보세요.

Gateway API: 정식 버전으로 출시된 Kubernetes 역사상 가장 고도화된 공동작업 API - Google의 롭 스캇 및 Isovalent의 닉 영
애플리케이션의 리소스 가용성 및 성능을 향상시키는 최신 부하 부산 - Google의 안토니오 오헤아 및 게릿 드윗
Istio: 프로젝트와 커뮤니티의 과거, 현재, 미래 - solo.io의 루이스 라이언 및 Google의 존 하워드(설명: Gateway API)

AlloyDB의 다운로드 가능한 버전인 AlloyDB Omni 정식 버전 출시

Wed, 15 Nov 2023 06:00:00 +0000

*본 아티클의 원문은 2023년 10월 12일 Google Cloud 블로그(영문)에 게재되었습니다.

Google Cloud에서 PostgreSQL용 AlloyDB를 출시함에 따라 고객 친화적이지 않은 라이선스를 사용하는 고비용의 기존 데이터베이스에 대한 종속에서 벗어나 비용 효율적이고 개방적이며 완벽하게 지원되는 고성능 데이터베이스로 이전하는 데 관심을 보이는 고객이 늘고 있습니다. 그러나 일부 고객의 경우 규제 또는 데이터 주권 요구사항으로 인해 워크로드가 온프레미스 데이터 센터로 제한되거나 에지에서 워크로드를 실행해야 합니다. 지리적 또는 기록상의 이유로 워크로드를 여러 클라우드에서 실행하는 고객도 있습니다.

AlloyDB의 다운로드 가능한 에디션인 AlloyDB Omni 정식 버전이 오늘 발표되었습니다. 이 버전은 기존 데이터베이스보다 훨씬 적은 비용으로 불리한 라이선스 조건 없이 Google 엔터프라이즈 지원 조직의 도움을 받아 환경 전반에서 동일한 엔터프라이즈급 데이터베이스를 실행할 수 있는 유연성을 제공하므로 위와 같은 워크로드에 유용한 선택지가 되어줍니다. AlloyDB는 Google Cloud, AWS, Azure, Google Distributed Cloud Hosted, 온프레미스, 개발자 노트북 등 거의 모든 곳에서 실행됩니다. AlloyDB Omni를 지금 시작하세요.

AlloyDB Omni 정식 버전은 개발자가 자신의 운영 데이터를 사용해 엔터프라이즈급 생성형 AI 애플리케이션을 빌드할 수 있도록 PostgreSQL용 AlloyDB에 기본 제공되는 통합 기능 모음인 AlloyDB AI도 지원합니다. AlloyDB AI는 표준 PostgreSQL보다 10배 더 빠른 벡터 쿼리, SQL을 사용한 간편한 임베딩 생성, Vertex AI Model Garden 및 오픈소스 생성형 AI 도구 등 Google Cloud AI 생태계와의 통합을 제공합니다.

고객이 중요한 애플리케이션에 대해 최상의 지원을 받을 수 있도록 AlloyDB Omni에 표준 지원(Standard Support) 수준(여기 참조)의 Google Cloud Customer Care가 제공됩니다. 고객이 Google Cloud 계정에 선택한 지원 요금제는 해당 계정에서 구매한 AlloyDB Omni SKU에 자동으로 적용됩니다.

미리보기 버전의 AlloyDB Omni Kubernetes Operator도 출시됩니다. 데이터베이스 프로비저닝, 백업, 안전한 연결, 모니터링 및 관찰(Observability)을 포함한 일반적인 데이터베이스 작업을간소화해 주므로 대부분의 Kubernetes 환경에서 AlloyDB Omni를 실행할 수 있습니다. Kubernetes operator의 기능을 확장하여 가장 중요한 데이터베이스 워크로드를 Kubernetes 환경에서 실행하는 데 필요한 기능을 고객에게 제공할 계획입니다.

기존 데이터베이스 비용에 대한 고객 우려를 해소하기 위해 AlloyDB Omni 가격 책정 방식을 단순하고 경제적이고 관리가 간편하며 워크로드 성장에 따라 쉽게 확장할 수 있도록 설계했습니다. AlloyDB Omni는 월 $1,295의 16-vCPU 시작 패키지(Starter Pack) 월간 구독이나 월 $6,995의 100-vCPU 블록 월간 구독으로 사용할 수 있습니다. 1년 약정 및 3년 약정의 경우 기존 엔터프라이즈 할인 요금제(EDP)에 추가로 할인이 적용됩니다. 각 패키지의 vCPU는 필요에 따라 여러 서버 또는 가상 머신에서 사용할 수 있습니다. 한 패키지의 모든 vCPU를 꼭 설정된 수의 서버나 단일 서버에서 사용할 필요는 없습니다. AlloyDB Omni에는 고객이 Google Cloud 계정에 선택한 Google Cloud 지원 요금제가 적용됩니다. 지원에 대한 자세한 내용은 https://cloud.google.com/support에서 확인할 수 있습니다.

기술 파트너, 시스템 통합업체, ISV는 고객이 차별화된 애플리케이션을 현대화하고 빌드하도록 돕는 중요한 역할을 합니다. AlloyDB Omni 정식 버전 출시와 함께 AlloyDB Omni를 포함하도록 AlloyDB Cloud Ready 프로그램을 확장하여 파트너 생태계에서 고객이 AlloyDB Omni의 혜택을 최대한 누리도록 지원할 수 있게 되었습니다. 검증된 파트너는 AlloyDB Omni 제품 사이트와 문서 페이지에 나와 있습니다. 고객은 이러한 검증된 파트너 제품과 AlloyDB Omni가 연동된다는 확신을 얻고, 비즈니스 가치를 창출해줄 데이터베이스 워크로드 및 애플리케이션의 현대화에 역량을 집중할 수 있습니다. 관심이 있는 파트너는 이 접수 양식을 작성하여 Google Cloud Ready - PostgreSQL용 AlloyDB Omni 이니셔티브에 지원해 주시기 바랍니다.

AlloyDB Omni는 지금 바로 사용 가능합니다. 자세히 알아보고 시작하시려면 https://cloud.google.com/alloydb/omni를 방문하세요. AlloyDB Omni 문서는 여기에서, AlloyDB Omni 가격 책정에 관한 자세한 내용은 여기에서 확인하실 수 있습니다.

Firestore에 PITR(point-in-time recovery) 및 예약 백업 추가

Thu, 02 Nov 2023 06:00:00 +0000

*본 아티클의 원문은 2023년 9월 9일 Google Cloud 블로그(영문)에 게재되었습니다.

Firestore에 두 가지 새로운 재해 복구 기능인 PITR(point-in-time recovery)과 예약 백업의 출시 소식을 전하게 되어 기쁩니다. 이러한 기능은 인적 오류와 재해로부터 데이터를 보호합니다.

Firestore의 자동 및 중복 데이터 백업에 추가된 이 기능 덕분에 서비스는 0 RPO와 0 RTO를 보여주는 장애 백업 조치를 통해 SLA 가용성을 최대 99.999% 보장할 수 있습니다.

PITR(point-in-time recovery)은 지난 7일간의 데이터 버전들을 제어 및 쿼리하고 필요한 데이터를 데이터베이스에 다시 직접 작성할 수 있는 기능을 제공하여 실수로 데이터를 삭제하거나 작성하지 못하도록 보호합니다.

예약 백업을 사용하면 매일 또는 매주 선택한 주기로 전체 데이터베이스를 콜드 스토리지에 백업할 수 있습니다. 이러한 백업은 동일한 프로젝트의 새 데이터베이스로 복원하는 데 사용할 수 있습니다.

PITR(point-in-time recovery) 예시 살펴보기

PITR(point-in-time recovery)을 사용 설정하는 상황을 가정해 보겠습니다. Google Cloud 콘솔에서 이 기능을 사용 설정하는 방법은 다음과 같습니다.

PITR(point-in-time recovery)을 사용 설정하려면 'Disaster recovery(재해 복구)' 페이지로 이동한 후 'EDIT' 아이콘을 선택합니다.

'Enable point-in-time recovery' 체크박스를 선택한 후 'SAVE'를 클릭합니다.

현재 'Disaster recovery(재해 복구)' 페이지에는 'Earliest version time(가장 초기 버전)' 및 'Retention period(보관 기간)'이 포함됩니다.

상기의 스텝을 따라오면 이제 PITR(point-in-time recovery)이 사용 설정되어 데이터 저장을 시작합니다. 자세한 내용은 문서를 참조하세요

예약 백업 예시 살펴보기

이제 gcloud 명령어를 사용하여 일일 및 주간 백업 일정을 생성하고 백업 생성을 확인하는 방법을 알려 드리겠습니다.

준비 작업은 다음과 같습니다.

gcloud를 최신 버전으로 업그레이드
백업을 관리할 프로젝트에 대해 'gcloud config set project <project-id>'를 실행

일일 백업 일정을 만들려면 'backups schedules create' 명령어를 사용합니다. 다음은 일일 백업 일정 생성의 예시입니다.

code_block: <ListValue: [StructValue([('code', "$ gcloud alpha firestore backups schedules create --database=''(default)'' --retention='7d' --recurrence='daily'"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfba9e4760>)])]>

주간 백업 일정을 만들려면 'backups schedules create' 명령어를 사용합니다. 주간 백업 일정 생성의 예시는 다음과 같습니다.

code_block: <ListValue: [StructValue([('code', "$ gcloud alpha firestore backups schedules create --database='testdb' --retention='14w' --recurrence=’weekly’ --day-of-week=’MON’"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfba9e3c10>)])]>

백업 일정이 성공적으로 생성되었는지 확인하려면 'backup schedules list' 명령어를 사용합니다.

code_block: <ListValue: [StructValue([('code', '$ gcloud alpha firestore backups schedules list'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfba9e30a0>)])]>

다음 단계

이러한 기능을 설정하고 구성하는 방법에 관한 자세한 내용은 PITR(point-in-time recovery) 및 예약 백업 문서를 확인하세요.

^{본문 작성에 도움을 주신 Firestore Product Manager Lead이신 Minh Nguyen님께 감사의 말을 전합니다.}

GPU 를 지원하는 GKE Autopilot 에서의 TensorFlow

Mon, 21 Aug 2023 07:00:00 +0000

최근 머신러닝과 인공지능에 대한 관심이 높아지면서 AI/ML 워크로드를 실행하기에 가장 적합한 환경이 어디인지 궁금해질 수 있습니다.

그래서 Google Cloud는 GPU가 지원되는 Google Kubernetes Engine(GKE) Autopilot 운영 모드를 만들었습니다. Autopilot이 모든 인프라를 관리하기 때문에 사용자는 추론, 학습, 기타 GPU 작업과 같은 AI/ML 워크로드 실행에만 집중할 수 있습니다. 컨테이너로된 Pod 또는 Job 명세를 Autopilot에 스케줄링하기만 하면 GKE에서 적절한 GPU를 프로비저닝하고 워크로드를 실행합니다. 또한 Job이 실행 중일 때만 비용이 청구 되기 때문에 Job이 완료되거나 수동으로 종료되면 즉시 비용 청구가 중단되며 정리는 GKE가 합니다.

너무 좋아서 믿기 어렵다고요??

이 게시글에서 AI/ML 워크로드의 생성, 실행 및 종료 과정을 보겠습니다. 워크로드는 NVIDIA T4에서 실행되는 Tensorflow-enabledJupyter 노트북으로, 다양한 AI/ML 학습 샘플을실행하는 데 사용할 수 있습니다. Jupyter 노트북은 AI/ML을 익히고 실험하기에 유용합니다. 게다가 Google Cloud에서 영구 디스크를 마운트하면 실행 동안의 작업을 보존할 수도 있습니다.

다음은 저의 데모 동영상입니다.

설정

먼저 GKE Autopilot 클러스터를 만듭니다. GPU를 사용할 수 없는 리전도 있으므로 GPU가 제공되는 리전 중에 원하는 리전을 선택합니다(여기서는 NVIDIA T4 사용). GPU가 제공되는 리전은 Autopilot 가격표에서 확인할 수 있습니다.

클러스터를 만듭니다.

code_block: <ListValue: [StructValue([('code', 'CLUSTER_NAME=test-cluster\r\nREGION=us-west1\r\ngcloud container clusters create-auto $CLUSTER_NAME \\\r\n --region $REGION \\'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb88ddfd0>)])]>

설치

이제 GPU 가속이 적용되는 Tensorflow-enabled Jupyter 노트북을 배포할 수 있습니다.

다음 StatefulSet 정의에서는 TensorFlow 환경에서 Jupyter 노트북을 제공하는 tensorflow/tensorflow:latest-gpu-jupyter 컨테이너의 인스턴스를 생성합니다. 이 인스턴스는 NVIDIA T4 GPU를 프로비저닝하고, /tf/saved 경로에 PersistentVolume을 마운트하여 작업을 저장할 수 있도록 하며 저장된 작업은 다시 시작한 후에도 보존됩니다. 또한 Spot에서 실행되므로 비용이 60~91% 절감됩니다. 작업은 선점된 경우에 저장된다는 점에 유의하세요.

그야말로 오랫동안 사용할 수 있는 제대로 된 Jupyter 노트북입니다.

code_block: <ListValue: [StructValue([('code', '# Tensorflow/Jupyter StatefulSet\r\napiVersion: apps/v1\r\nkind: StatefulSet\r\nmetadata:\r\n name: tensorflow\r\nspec:\r\n selector:\r\n matchLabels:\r\n pod: tensorflow-pod\r\n serviceName: tensorflow\r\n replicas: 1\r\n template:\r\n metadata:\r\n labels:\r\n pod: tensorflow-pod\r\n spec:\r\n nodeSelector:\r\n cloud.google.com/gke-accelerator: nvidia-tesla-t4\r\n cloud.google.com/gke-spot: "true"\r\n terminationGracePeriodSeconds: 30\r\n containers:\r\n - name: tensorflow-container\r\n image: tensorflow/tensorflow:latest-gpu-jupyter\r\n volumeMounts:\r\n - name: tensorflow-pvc\r\n mountPath: /tf/saved\r\n resources:\r\n requests:\r\n nvidia.com/gpu: "1"\r\n ephemeral-storage: 10Gi\r\n## Optional: override and set your own token\r\n# \tenv:\r\n# \t- name: JUPYTER_TOKEN\r\n# \tvalue: "jupyter"\r\n volumeClaimTemplates:\r\n - metadata:\r\n name: tensorflow-pvc\r\n spec:\r\n accessModes:\r\n - ReadWriteOnce\r\n resources:\r\n requests:\r\n storage: 100Gi\r\n---\r\n# Headless service for the above StatefulSet\r\napiVersion: v1\r\nkind: Service\r\nmetadata:\r\n name: tensorflow\r\nspec:\r\n ports:\r\n - port: 8888\r\n clusterIP: None\r\n selector:\r\n pod: tensorflow-pod'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb88ddfa0>)])]>

데스크톱에서 이 노트북에 연결할 수 있도록 부하분산기도 필요합니다.

code_block: <ListValue: [StructValue([('code', '# External service\r\napiVersion: "v1"\r\nkind: "Service"\r\nmetadata:\r\n name: tensorflow-jupyter\r\nspec:\r\n ports:\r\n - protocol: "TCP"\r\n port: 80\r\n targetPort: 8888\r\n selector:\r\n pod: tensorflow-pod\r\n type: LoadBalancer'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb88c3340>)])]>

다음과 같이 배포합니다.

code_block: <ListValue: [StructValue([('code', 'kubectl create -f https://raw.githubusercontent.com/WilliamDenniss/autopilot-examples/main/tensorflow/tensorflow.yaml\r\nkubectl create -f https://raw.githubusercontent.com/WilliamDenniss/autopilot-examples/main/tensorflow/tensorflow-jupyter.yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb88c3220>)])]>

기다리는 동안 클러스터의 이벤트를 보고 다음과 같이 정상 작동하는지 확인할 수 있습니다 (관련 이벤트가 표시되도록 출력을 편집).

code_block: <ListValue: [StructValue([('code', "$ kubectl get events -w\r\nLAST SEEN TYPE \tREASON \tOBJECT \tMESSAGE\r\n5m25s \tWarning FailedScheduling \tpod/tensorflow-0 \t0/3 nodes are available: 2 Insufficient cpu, 2 Insufficient memory, 2 Insufficient nvidia.com/gpu, 3 node(s) didn't match Pod's node affinity/selector. preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling.\r\n4m24s \tNormal\tTriggeredScaleUp \tpod/tensorflow-0 \tpod triggered scale-up: [{https://www.googleapis.com/compute/v1/projects/gke-autopilot-test/zones/us-west1-b/instanceGroups/gk3-test-cluster-nap-1ax02924-9c722205-grp 0->1 (max: 1000)}]\r\n2m13s \tNormal\tScheduled \tpod/tensorflow-0 \tSuccessfully assigned default/tensorflow-0 to gk3-test-cluster-nap-1ax02924-9c722205-lzgj"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb88c3070>)])]>

Kubernetes와 Autopilot이 작동하면서 처음에는 FailedScheduling이 표시되는데, 이는 코드를 배포하는 시점에는 PoD를 처리할 리소스가 없기 때문입니다. 그러나 이후 Autopilot이 리소스를 추가하면서 TriggeredScaleUp이 표시되고, PoD에 리소스가 할당되면 마지막으로 Scheduled가 표시됩니다. GPU 노드는 일반 CPU 노드에 비해 프로비저닝에 시간이 조금 더 걸리므로 이 컨테이너는 부팅하는 데 시간이 약간 걸립니다. 저의 경우 PoD 예약부터 실행까지 약 5분이 소요되었습니다.

노트북 사용

이제 연결할 차례입니다. 먼저 부하 부산기의 외부 IP를 찾습니다.

code_block: <ListValue: [StructValue([('code', '$ kubectl get svc\r\nNAME \tTYPE \tCLUSTER-IP \tEXTERNAL-IP\tPORT(S) \tAGE\r\nkubernetes \tClusterIP \t10.102.0.1 \t<none> \t443/TCP \t20d\r\ntensorflow \tClusterIP \tNone \t<none> \t80/TCP \t9m4s\r\ntensorflow-jupyter LoadBalancer 10.102.2.107 34.127.75.81 80:31790/TCP 8m35s'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb88c33d0>)])]>

해당 IP로 연결합니다.

exec를 사용하여 Kubernetes에서 제안하는 명령을 실행할 수 있습니다.

code_block: <ListValue: [StructValue([('code', '$ kubectl exec -it sts/tensorflow -- jupyter notebook list\r\nCurrently running servers:\r\nhttp://0.0.0.0:8888/?token=e54a0e8129ca3918db604f5c79e8a9712aa08570e62d2715 :: /tf'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb88c3160>)])]>

토큰(저의 경우 e54a0e8129ca3918db604f5c79e8a9712aa08570e62d2715)을 복사하여 넣고 로그인합니다.

참고: 이 단계를 건너뛰려면 설정에서 자체 토큰을 설정한 후 env 줄의 주석 처리를 삭제하고 자체 토큰을 정의하면 됩니다.

몇 가지 샘플이 포함된 폴더와 영구디스크를 마운트 한 “'saved'라는 2개의 폴더가 있습니다. 세션 간에 상태를 유지하려면 'saved' 폴더에서 작업하는 것을 권장하고, 시작하기 전에 'tensorflow-tutorials' 디렉터리를 'saved' 디렉터리로 옮기는 것이 좋습니다. 아래 UI를 사용하여 폴더를 옮기고 자체 노트북을 업로드할 수 있습니다.

포함된 샘플 몇 가지를 실행해 보겠습니다.

classification.ipynb 예시

overfit_and_underfit.ipynb 예시

Tensorflow 문서의 예시와 같이 자체 프로젝트를 업로드할 수 있습니다. 이 문서에서 예제 을 다운로드한 후 jupyter의 saved/ 폴더에 업로드하고 실행합니다.

Tensorflow basics.ipynb 튜토리얼(GPU 가속 활용)

이렇게 해서 NVIDIA T4에서 실행되는 재사용 가능한 TensorFlow Jupyter 노트북이 생성되었습니다. 이것은 단순한 장난감이 아닙니다. PersistentVolume을 연결했으므로 작업이 저장됩니다. 심지어 StatefulSet가 삭제되거나 PoD가 중단된 경우에도 저장됩니다. 비용을 절감하기 위해 Spot 컴퓨팅을 사용합니다. 전체가 YAML 파일 2개로 프로비저닝되었으며, 컴퓨팅 하드웨어에 대해서는 신경을 쓸 필요가 없습니다. 정말 간단합니다.

모니터링 및 문제 해결

'커널이 죽은 것 같습니다. 자동으로 다시 시작됩니다(The kernel appears to have died. It will restart automatically).'와 같은 메시지가 표시된다면 첫 번째 단계로 로그를 살펴봅니다.

code_block: <ListValue: [StructValue([('code', 'kubectl logs tensorflow-0 -f'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb88c3880>)])]>

노트북 2개를 실행할 때 발생하는 일반적인 문제는 GPU 메모리가 소진될 수 있다는 점입니다(로그에서 CUDA_ERROR_OUT_OF_MEMORY). 간단한 해결 방법은 현재 사용하고 있는 노트북을 제외한 나머지 노트북을 모두 종료하는 것입니다.

다음과 같이 GPU 사용률을 관찰할 수 있습니다.

code_block: <ListValue: [StructValue([('code', '$ kubectl exec -it sts/tensorflow -- bash\r\n# watch -d nvidia-smi'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb88c3250>)])]>

어떤 이유로든 설정을 다시 시작해야 하는 경우에는 PoD를 삭제하기만 하면 Kubernetes가 이를 자동으로 다시 생성합니다. Autopilot에서는 이 과정이 매우 빠르게 진행됩니다. GPU 노드 리소스가 클러스터에서 대기하는 시간이 짧기 때문입니다.

code_block: <ListValue: [StructValue([('code', 'kubectl delete pod tensorflow-0'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb88c3760>)])]>

다음 단계

Shell 환경에서 임의의 코드를 실행하려면(즉, 노트북 UI를 사용하지 않고) 다음을 사용할 수 있습니다. 보존하려는 데이터를 /tf/saved/에 저장해야 합니다.

code_block: <ListValue: [StructValue([('code', 'kubectl exec -it sts/tensorflow -- bash'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb88c37c0>)])]>

튜토리얼을 더 보려면 TensorFlow 튜토리얼 및 Keras를 참조하세요.

저는 모든 튜토리얼들을 내 노트북에 저장하기 위해 Keras repo를 나의 영구 볼륨에 클론했습니다.

code_block: <ListValue: [StructValue([('code', '$ kubectl exec -it sts/tensorflow -- bash\r\n# cd /tf/saved\r\n# git clone https://github.com/keras-team/keras-io.git\r\n# pip install pandas'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb88c3700>)])]>

노트북에 추가 Python 모듈이 필요한 경우(예: Pandas)에도 동일한 방법으로 설정할 수 있습니다. 그러나 더 지속성 있는 설정을 만들려면 위에서 사용한 것을 확장하는 자체 Dockerfile이 필요합니다.

몇 가지 다양한 예시를 실행했고 출력은 다음과 같습니다.

Keras timeseries/ipynb/timeseries_weather_forecasting.ipynb 예시의 출력

Keras generative/ipynb/text_generation_with_miniature_gpt.ipynb 예시의 epoch random iteration

정리하기

GPU는 값싼 리소스가 아니므로 작업을 마친 후에는 리소스를 삭제해야 합니다. 다음과 같이 StatefulSet 과 Service를 제거해서 정리하세요.

code_block: <ListValue: [StructValue([('code', 'kubectl delete sts tensorflow\r\nkubectl delete svc tensorflow tensorflow-jupyter'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb88c36d0>)])]>

위에서 언급했듯이, Autopilot의 장점은 Kubernetes 리소스(여기서는 StatefulSet 및 부하분산기)를 삭제하면 관련 비용의 청구가 종료된다는 점입니다.

이제 남은 것은 영구 디스크입니다. 그냥 두거나(이 경우 위의 StatefulSet를 다시 만들면 영구 디스크가 다시 연결되고 작업이 저장됨), 더 이상 필요가 없으면 디스크도 삭제합니다.

code_block: <ListValue: [StructValue([('code', 'kubectl delete persistentvolumeclaim/tensorflow-pvc-tensorflow-0'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb88c35b0>)])]>

클러스터 역시 더 이상 필요 없다면 삭제할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'gcloud container clusters delete $CLUSTER_NAME --region $REGION'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb88c38e0>)])]>

다음 단계

지금까지 Autopilot에서 GPU 워크로드를 얼마나 손쉽게 실행할 수 있는지 살펴봤습니다.

필요한 GPU 리소스를 포함하여 Kubernetes 워크로드를 정의하기만 하면 나머지는 알아서 처리합니다. 작업을 마친 후 워크로드를 삭제하면 비용 청구도 즉각 중단되므로 노드 정리에 대해 신경 쓸 필요가 없습니다.

https://console.cloud.google.com/kubernetes로 이동하면 GKE 클러스터를 시작할 수 있으며, Google Cloud를 처음 사용하는 경우 $300 무료 체험판을 꼭 사용해 보시기 바랍니다.

Artifact Registry 및 컨테이너 스캔을 사용하여 원점 회귀 보안 달성 및 배포 간소화

Tue, 06 Dec 2022 00:00:00 +0000

* 본 아티클의 원문은 2022년 10월 5일 Google Cloud 블로그(영문)에 게재되었습니다.

사이버 범죄로 인한 기업의 피해액은 연간 6조 달러에 달하며, 그중 랜섬웨어로 인한 피해액만 200억 달러에 달합니다.¹ 공격 벡터의 주요 소스는 오픈소스 소프트웨어에 존재하는 취약점인데, 이러한 취약점은 유명한 프로젝트일수록 더 많이 발견됩니다. 2021년 기준 가장 인기 있는 오픈소스 프로젝트 버전의 상위 10%에 알려진 취약점이 포함될 가능성은 평균 29%에 달했습니다. 반면 나머지 90%의 프로젝트 버전에 알려진 취약점이 포함될 가능성은 6.5%에 불과합니다.²Google은 오픈소스 소프트웨어를 활용할 때 부딪힐 수 있는 어려움을 잘 알고 있습니다. 지금까지 수십 년 동안 오픈소스 소프트웨어를 다뤄온 Google은 Google Cloud의 솔루션을 통해 고객에게 일부 권장사항을 제공하고 있습니다. 다음은 아티팩트 관리 플랫폼을 시작하고 활용하기 위한 간단한 세 가지 방법입니다.

Google Cloud 기반 레지스트리 솔루션 사용: Artifact Registry는 차세대 Container Registry이며 이미지 스토리지를 보호하고 최적화하는 데 적합한 옵션입니다. 중앙 집중식 관리가 가능하며 Google Cloud 런타임 및 DevOps 솔루션과 원활하게 통합되어 다양한 아티팩트를 저장할 수 있으므로 애플리케이션을 쉽게 빌드하고 배포할 수 있습니다.
원점 회귀로 심각한 취약점 조기 발견: Artifact Registry에서 컨테이너의 자동 스캔을 사용 설정하면 개발 프로세스 초기에 취약점을 감지할 수 있습니다. 자동 스캔 기능을 사용 설정하면 레지스트리에 푸시된 모든 이미지가 계속해서 증가하는 운영체제 및 언어 패키지 취약점을 감지하는 자동 스캔을 거치게 됩니다. 지속적 분석 기능은 이미지가 사용되는 동안 해당 이미지 관련 취약점 정보를 계속해서 업데이트합니다. 이 간단한 단계를 통해 개발 초기부터 보안을 고려할 수 있으며 운영 중인 애플리케이션의 심각한 취약점을 악의적인 행위자가 포착하기 전에 감지할 수 있습니다.
GKE에 최적화된 간편한 배포: 저장소가 리전화되어 있어 이미지를 Google Cloud 런타임에 빠르고 쉽게 배포할 수 있습니다. 또한 이미지 스트리밍을 통해 GKE에서 실행되는 애플리케이션의 시작 지연 시간을 더욱 줄일 수 있습니다.

Google 기반 아티팩트 관리 솔루션은 IAM 및 Binary Authorization 등 다른 Google Cloud 서비스와 긴밀하게 통합됩니다. Artifact Registry와 함께 자동 스캔을 사용하는 것은 소프트웨어 개발 수명 주기의 보안 상태를 개선하는 중요한 한 걸음입니다.

엔드 투 엔드 소프트웨어 공급망

이러한 Google Cloud 솔루션을 활용하면 컨테이너 워크로드를 최적화하고 조직이 개발 초기부터 보안을 고려하는 데 도움이 됩니다. Artifact Registry 및 자동 스캔 사용 설정에 대해 자세히 알아보세요.

해당 기능은 현재 사용 가능합니다.

1. Cyberwarfare In The C-Suite(최고 책임자의 사이버 전쟁)

2. State of the software supply chain 2021(2021년 소프트웨어 공급망 현황)

Google Kubernetes Engine: 7년의 발자취와 7가지 이점

Mon, 14 Nov 2022 00:00:00 +0000

* 본 아티클의 원문은 2022년 8월 27일 Google Cloud 블로그(영문)에 게재되었습니다.

오늘 Google은 자동화 수준과 확장성이 가장 우수한 관리형 Kubernetes인 Google Kubernetes Engine(GKE)의 정식 버전 출시 7주년을 기념하여 고객이 탁월한 성과를 낼 수 있도록 도움을 제공하는 GKE의 일반적인 7가지 지원 방식을 소개합니다.

개발자 생산성 증가

개발자에게 시간은 무엇보다 소중합니다. GKE는 다양한 통합 도구를 제공하여 출시 속도와 빈도를 높이는 데 도움이 됩니다. 지속적 통합(CI) 관행을 사용하면 개발자가 모든 코드 변경사항을 기본 브랜치에 자주 다시 통합할 수 있으므로 최대한 프로세스 초반에 문제를 드러내 장애를 빠르게 노출할 수 있습니다. CI 파이프라인은 일반적으로 배포 프로세스의 후반 단계에서 지속적 배포(CD)를 사용해 배포할 수 있는 아티팩트를 생성합니다. CD를 사용하면 언제든지 코드를 출시할 수 있습니다.

GKE의 개발자 도구 생태계는 CI 및 CD를 포괄합니다.

개발자가 Cloud Code 및 Cloud Shell을 사용해 빠르게 코드를 작성, 배포, 디버깅할 수 있습니다.
Cloud Build를 사용해 지속적으로 통합하고 업데이트를 제공할 수 있습니다.
Cloud Deploy를 사용하면 GKE에 쉽고 빠르며 안정적으로 지속적 배포를 할 수 있습니다.
Google Cloud 운영 제품군을 사용해 디버깅하고 문제를 해결할 수 있습니다.
원하는 파트너 솔루션을 즉시 사용할 수 있습니다.

또한 GKE Autopilot 클러스터가 앱 배포 속도를 높여 구성 시간이 단축되고 지속적인 개발/테스트 클러스터 관리가 간소화됩니다. 자세한 내용은 GKE Autopilot 시작 방법에서 확인하세요.

"Google Kubernetes Engine은 구성하기 쉽고 확장도 무척 원활합니다. 개발자가 프로덕션에서의 관리를 고민할 필요가 없으며 매개변수만 설정해도 제대로 작동할 것이란 확신을 얻을 수 있습니다."—Vincent Oliveria, Lucky Cart CTO

소프트웨어 공급망 보안 강화

보안은 언제나 모든 조직의 최우선순위입니다. Autopilot 모드로 생성된 Kubernetes 클러스터는 기본적으로 많은 GKE 강화 기능을 구현합니다. 또한 GKE Autopilot은 클러스터 보안을 개선하여 Kubernetes API에 대한 액세스를 제어하고 노드 변경을 막아 강력한 보안 상태를 적용하며 클러스터 보안을 강화하기 위한 추가 안내를 구현할 수 있도록 지원합니다. Binary Authorization은 배포 시점의 보안 제어를 제공하여 GKE에 신뢰할 수 있는 컨테이너 이미지만 배포되도록 합니다. Binary Authorization을 사용하면 확인된 이미지만 빌드 및 출시 프로세스에 통합되므로 컨테이너 환경을 보다 철저하게 관리할 수 있습니다. 자세한 내용은 소프트웨어 공급망 보안 구축 방법을 참고하세요.

"PicnicHealth는 HIPAA 규정을 준수해야 했으나 AWS에서는 쉽지 않을 전망이었습니다. 자체 Kubernetes 클러스터 관리와 운영에서도 벗어나고 싶었습니다."라고 아스토리노 CTO는 회상했습니다. "그러다 GKE(Google Kubernetes Engine)의 이점에 대해 들었습니다. HIPAA 규정 준수에 필요한 많은 기술 요구사항이 Google Cloud에서는 기본적으로 구성된다는 점이 특히 마음에 들었습니다." —Troy Astorino, PicnicHealth 공동 설립자 겸 CTO

플랫폼 접근 방식을 통한 새로운 기회 창출

최신 애플리케이션 플랫폼에서는 창의성을 발휘하고 고객 요구에 빠르게 대응할 수 있습니다. GKE 고객은 Kubernetes를 사용해 조직을 위한 현대적인 엔터프라이즈급 애플리케이션 플랫폼을 빌드합니다. Tau VM/GPU/TPU/로컬 SSD 지원을 통해 다양한 워크로드에서 속도 및 성능 개선을 달성할 수 있는 GKE는 스테이트풀(Stateful) 및 스테이트리스(Stateless), AI 및 ML, Linux 및 Windows 등 다양한 컨테이너화된 애플리케이션을 지원하도록 도와 드립니다. 오직 GKE만 15,000개의 노드 클러스터를 실행해 애플리케이션을 대규모로 효과적이면서도 안정적으로 실행할 수 있습니다. 이는 다른 클라우드 제공업체보다 최대 10배 큰 규모입니다.

"Google Cloud 관리형 서비스는 Noon.com 고객이 필요할 때마다 쇼핑할 수 있도록 지원하는 중요한 역할을 맡고 있습니다. 고객은 지연이나 문제를 겪지 않으며, Noon.com 직원들은 플랫폼이 정상 작동하도록 뜬 눈으로 밤을 새울 필요도 없습니다.”—Alex Nadalin, Noon.com 엔지니어링 SVP

고객에게 상시 사용 가능한 경험 제공

오늘날 소비자는 연중무휴 디지털 경험을 요구합니다. GKE의 세분화된 제어를 사용하면 가용성과 안정성이 우수하며 상시 사용 가능한 앱 및 서비스를 제공할 수 있습니다. 노드 자동 업그레이드를 통해 클러스터 노드를 자동으로 업그레이드하고 패치를 적용하며 항상 Google에서 제어 영역에 패치를 적용하고 업그레이드합니다. 요구사항 및 제약조건에 따라 신속, 일반 또는 정식과 같은 출시 채널을 구독할 수도 있습니다. 출시 채널은 고급 계획에 필요한 수준의 예측 가능성, 그리고 변경이 예정된 경우 커스텀 워크플로를 자동으로 조정하는 유연성을 기업에 제공해줍니다. 출시 채널에 대한 자세

한 내용은 여기에서, 유지보수 기간에 대한 내용은 여기에서 확인하세요.

"E.ON Optimum 출시를 위해 사내 소프트웨어를 확장성과 안정성이 우수한 클라우드 기반 솔루션으로 전환해야 했습니다. 특히 Kubernetes 포드를 대규모로 항시 실행할 수 있는 클라우드 파트너를 찾아나선 끝에 Google Cloud를 선택하게 되었습니다.”—Dennis Noble, E.ON 디지털 제공 관리자

조직의 비용 최적화 및 절감 지원

현재의 거시 경제 환경에서는 적은 리소스로 더 많은 작업을 처리해야 하는 경우가 많습니다. GKE Autopilot은 컴퓨팅 리소스를 동적으로 조정합니다. 따라서 워크로드에 구성해야 할 노드의 크기 및 형태를 파악해야 할 필요가 없습니다. GKE Autopilot을 사용하면 사용한 포드에 대한 요금만 지불하면 되며 vCPU, 메모리, 디스크 리소스 요청 요금이 초 단위로 청구됩니다. 또한 GKE 비용 최적화 통계를 사용하면 차질을 최소화하며 자동으로 GKE 클러스터 및 워크로드에서 규모에 따른 최적화 기회를 찾을 수 있습니다.

"GKE로 마이그레이션한 이후 노드 실행 비용이 절반으로 줄었고 유지보수 작업이 감소했으며 수요에 따라 자동으로 손쉽게 확장 및 축소할 수 있는 역량을 갖추게 되었습니다. 모든 고객 프로덕션 부하 및 개발 환경을 GKE에서 실행하고 있으며 이후로 심각한 사고가 발생한 적이 없습니다.”—Helge Rennicke, Market Logic Software 소프트웨어 개발 책임자

비즈니스 혁신에 중점을 둔 성장 촉진

관리형 클라우드 서비스를 사용하면서 IT 부서가 비용 부문에서 가치 부문으로 전환되고 있습니다. GKE Autopilot은 핸드오프 클러스터 관리 및 SLA를 제공하고 대부분의 2일 차 클러스터 작업을 없애주기 때문에 기업에서는 관리 부담이 사라져 비즈니스 혁신에 집중할 수 있습니다.

GKE는 애플리케이션을 효율적이고 쉽게 운영할 수 있도록 다양한 차원의 자동화 기능을 제공합니다. 완전 관리형 GKE Autopilot과 다차원 자동 확장 기능을 함께 사용하면 몇 분 만에 프로덕션에 즉시 사용 가능한 안전한 클러스터를 시작하고 구성 및 유지보수를 완전하게 제어할 수 있습니다.

”Google Kubernetes Engine의 자동화 기능 덕분에 매우 효율적으로 앱 트래픽을 관리하고 게임을 개발할 수 있게 되었습니다. 현재 단 2명의 엔지니어만 있으면 트래픽 볼륨과 게임 3개의 모든 환경을 모니터링할 수 있어 개발 및 혁신 업무에 더 많은 인력을 투입할 수 있습니다.”—Aries Wang, Yile Technology 연구 개발 부관리자

IT 독점 도구에 대한 종속 방지

멀티 클라우드가 시대가 되었습니다. 독점 도구를 사용하면 전문 기술이 필요하고 막대한 라이선스 요금에서 벗어나지 못할 때가 많습니다. 모든 주요 클라우드 제공업체를 포함한 여러 환경에서 지원되는 규정 준수 Kubernetes를 통해 공급업체 종속을 최소화하고 멀티 클라우드 전략의 이점을 극대화할 수 있습니다. Kubernetes의 워크로드 이식성 덕분에 제약 없이 유연하게 앱을 이동할 수 있습니다.

"MeilleursAgents는 제품 중심의 기업으로서, 시장의 피드백을 받고 프로덕션에서 개선할 수 있도록 새로운 서비스를 최대한 빠르게 제공하는 것을 목표로 합니다. Google Kubernetes Engine은 유연성과 쉬운 확장을 제공하여 이 목표 달성에 도움을 주며, 바로 이러한 이유에서 GKE로의 전환을 결정했습니다."—Thibault Lanternier, MeilleursAgents 웹 엔지니어링 책임자

Kubernetes 여정을 시작하거나 가속화하려면 Kubernetes를 통한 미래 구축에 참여하세요. Kubernetes 서비스, 개발자 도구, 운영 제품군, 보안 솔루션을 자세히 다룬 기술 데모를 이용할 수 있습니다. 귀사의 Kubernetes 여정에 함께할 수 있기를 바랍니다.

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

Fri, 11 Feb 2022 00:00:00 +0000

* 본 아티클의 원문은 2021년 12월 8일 Google Cloud 블로그(영문)에 게재되었습니다.

Kubernetes라는 단어가 기술 업계에 처음 등장한 것은 2014년이었습니다. 그 당시 Kubernetes를 처음 접했을 때 가장 먼저 떠오른 생각은 '도대체 어떻게 발음해야 하지?'였습니다. 그로부터 7년이 지난 후 Kubernetes는 세계 최대 규모의 오픈소스 프로젝트 중 하나가 되었습니다. Kubernetes의 초기 관리자 중 한 명이 Google 펠로우인 에릭 브루어입니다. 지난 10여 년 동안 에릭은 Google 기술의 개발과 외부 출시를 적극 지원하며 주도적으로 이끌어 왔습니다. 현재는 Kubernetes, 서버리스, DevOps, Istio, 기타 서비스와 같은 다양한 Google Cloud 서비스에 주력하고 있으며, 이전에는 컴퓨팅과 스토리지 분리, 대규모 VM 라이브 마이그레이션 보급 추진, 분할을 위한 어플라이언스 사용 정립 등 획기적인 작업에서 중요한 역할을 했습니다. 저는 몇 번의 세션에 걸쳐 수년간 그가 경험한 IT 현장의 이야기를 듣고 에릭이 클라우드 컴퓨팅의 미래를 결정지은 4대 요소로 꼽는 Kubernetes 및 오픈소스 관련 유용한 정보를 상세히 알아보는 시간을 가졌습니다.

1. 오픈소스로 제공되는 Kubernetes는 클라우드 기반 컴퓨팅의 중심축이 되었으며 우리는 오픈소스 기술에 지속적으로 투자해야 합니다.

UC 버클리 학부에 입학한 에릭은 많은 프로세스, 서비스, API를 사용하는 상용 서버 클러스터에 기반한 모델이자 훗날 클라우드 컴퓨팅의 모체가 되는 기술에 큰 관심을 가졌습니다. 2011년, Google에 입사한 후에는 이러한 생각을 토대로 높은 수준의 추상화를 중심으로 한 신종 클라우드를 개발했습니다. 이 신종 클라우드는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하기 위한 오픈소스 시스템인 Kubernetes의 시초가 된 초기 프로토타입과 잘 연동되었습니다.

2010년대 초반 클라우드가 태동하던 시기에 에릭은 Google 내부의 컨테이너에 기반한 접근법이 VM과 디스크보다 훨씬 더 강력한 클라우드를 구현해 낼 수 있음을 알고 있었습니다. Google에서 생각이 같은 사람을 모으는 것은 비교적 쉬웠지만 이제껏 경험해 보지 못한 새롭고 검증되지 않은 아이디어가 업계 전반에 받아들여지기까지는 대개 시간이 오래 걸리기 마련입니다. 선견지명이 있었던 에릭은 프로젝트를 오픈소스로 제공하는 것이 클라우드 컴퓨팅을 혁신할 수 있는 Kubernetes의 잠재력을 실현할 수 있는 단 하나의 방법임을 바로 알아챘습니다.

물론 일부 저항에 부딪히기도 했습니다. 2012년 무렵, Google Cloud는 이미 App Engine과 VM을 제공하고 있었습니다. 비평가들의 공통적인 질문은 '왜 컴퓨팅을 하는 데 제3의 길이 필요하냐?'는 것이었습니다. Kubernetes의 등장 전부터 Google은 이미 매주 수십억 개의 컨테이너를 실행하고 있었으며 에릭은 이 기술을 더욱 발전시킴으로써 산업 전반에 걸쳐 막대한 가치를 창출할 수 있을 것으로 예상했습니다. Kubernetes는 자동화와 유연성을 갖추고 있어 원시 VM 또는 원시 디스크를 사용할 때에 비해 훨씬 더 수월하게 운영할 수 있습니다.

수년 동안 오픈소스 지원이 이루어진 후 Kubernetes는 Knative, Kubeflow와 같이 Kubernetes를 기반으로 실행되는 한층 더 독자적이고 수평적으로 확장 가능한 서비스를 통해 클라우드에서 애플리케이션을 실행하는 실질적인 방법으로 자리 잡았습니다. 클라우드 컴퓨팅이 또 한 번의 전환점을 맞이하는 상황에서도 이 프로젝트는 계속 발전하고 있습니다. 현재 에릭은 Kubernetes의 근본 철학과 보안에 민감한 업계가 요구하는 엄격한 보호 조치를 결합하기 위한 노력을 진두지휘하고 있습니다. 오픈소스 및 소프트웨어 공급망 보안에 중점을 두고, 공격 지점을 최소화하기 위해 소스 코드 작성에서 배포까지 더욱 독자적인 도구를 개발하는 것을 목표로 삼고 있습니다.

2. 소프트웨어 개발에 사용된 종속 항목의 수가 늘어날수록 보안 위험이 급격히 커지게 됩니다. 소프트웨어 공급망 보안에 대한 투자는 필수적이며 자체 관리 솔루션보다 관리형 서비스로 전환하는 것이 실제로는 더 안전합니다.

SolarWinds와 CodeCov 등 최근 발생한 공격을 보면 소프트웨어 산업 전반에서 재사용이 증가하고 개발 속도가 빨라지면서 공격의 여지가 될 만한 보안 허점이 늘어나는 것을 알 수 있습니다. 에릭은 전지구적인 최우선 과제를 해결하기 위한 기반을 닦고 있습니다.

취약점의 99%는 애플리케이션에 작성한 코드가 아니라 깊고 복잡하게 얽혀 있는 종속 항목에 존재하며, 여러분이 잘 알고 있는 것도 있고 전혀 모르는 것도 있습니다. 에릭 브루어

소프트웨어 개발에서 오픈소스 소프트웨어와 종속 항목의 사용이 늘고 있기 때문에 조직이 소프트웨어에서 중점 투자할 부분을 판단하고 그 이유를 이해하는 것이 중요합니다. 검증되지 않은 소프트웨어 종속 항목을 코드에 포함하는 대신, 이 소프트웨어를 평가하고 기준에 부합하지 않거나 제대로 관리되지 않는 요소를 찾아내는 데 시간을 할애해야 합니다.

수백 개의 소프트웨어 종속 항목이 존재하는 Kubernetes에 Google은 어떻게 투자하고 있느냐는 질문에 에릭은 2015년에 Cloud Native Computing Foundation(CNCF)이 설립되기까지 Google Cloud가 크게 기여했다고 설명했습니다. CNCF는 Kubernetes, Prometheus, Envoy 등 빠르게 증가하는 오픈소스 프로젝트의 공급업체 중립적인 발상지 역할을 하고 있습니다. CNCF의 사명은 클라우드 기반 컴퓨팅을 널리 보급하고 생태계 확장을 조성하는 것입니다. CNCF 지원을 기반으로 Google은 2020년에 123,000건이 넘는 항목을 비롯하여 프로젝트에 680,000건 이상을 추가로 기여했습니다.

Google은 오래전부터 오픈소스 분야에 상당한 노력을 기울여 왔으며, 실제로 최근에는 오픈소스 보안을 지원하는 제3자 재단에 1억 달러를 후원하기도 했습니다. 뿐만 아니라 에릭은 조직 보안 책임자들이 일련의 오픈소스 종속 항목에 대한 보안을 이해하고 확인하도록 돕는 오픈소스 보안 도구와 권장사항을 주로 개발하는 Open Source Security Foundation(OpenSSF)을 설립하는 데 큰 역할을 했습니다. 에릭은 선례를 마련한다는 측면에서 이 성과를 중요하게 생각합니다. 오픈소스의 안전성을 최대한 확보하기까지 길고 지루한 과정을 거쳐야 하겠지만 이는 반드시 필요한 작업이며 재정적인 지원이 필요합니다.

오픈소스는 공공 인프라이기도 합니다. 모든 공공 인프라와 마찬가지로 유지보수와 지원이 필요합니다. 에릭 브루어

더 높은 수준의 추상화를 채택하는 서비스가 계속 늘어나면서 관리형 서비스가 안전한 소프트웨어 제공을 보장하는 탄탄한 토대가 되고 있습니다. 관리형 서비스를 이용하면 제공업체가 자동화된 보안 예방 조치와 증명을 사용할 수 있습니다. 예를 들어 GKE Autopilot은 노드와 노드 풀을 포함한 클러스터의 기본 인프라를 프로비저닝 및 관리하여 핸드오프 환경에서 최적의 클러스터를 구현해 줍니다. 클러스터, 워크로드 설정, 보안에 대한 Google Kubernetes Engine(GKE) 권장사항과 추천을 따르는 동시에 보다 효과적으로 컨테이너를 격리하는 설정을 적용합니다. 에릭의 의견에 따르면 이 모델은 앞으로 계속 성장하며 주류로 자리 잡을 것입니다. 시간이 지날수록 보안을 비롯하여 제공업체가 관리하는 기능이 늘어나고 수년에 걸쳐 축적되고 입증된 프로토콜과 권장사항을 이용하여 기업이 직접 관리하고 싶어 하지 않는 기능들을 제공업체가 책임지고 관리하게 될 것입니다.

3. 플랫폼 운영자는 기업이 중시하는 가이드라인을 적용하면서 범용 플랫폼으로 GKE를 실행해야 합니다.

몇 년간 에릭이 꾸준히 받았던 공통적인 질문은 GKE와 같은 관리형 Kubernetes를 기업에서 활용하는방법에 관한 것입니다. 첫 번째로 기억해야 할 사항은 클라우드 제공업체는 여러분이 생각하는 것보다 더 다양하고 많은 요소와 옵션, 기능을 개발자에게 제공한다는 점입니다. 플랫폼 소유자는 이러한 요소를 이용해 최신 앱을 구동하기 위한 안전하고 유지보수 가능한 플랫폼을 구축할 수 있습니다. 예를 들어 백업을 기본적으로 적용하고 루트 파일 시스템 액세스나 백엔드 시스템의 공개 IP 생성을 금지하는 정책을 시행하는 것이 현명합니다. 신용카드 거래를 처리하는 기업이라면 내부 개발자에게 무제한의 권한을 주는 것이 아니라, 서비스 구조에 의하여 거래가 운영 지역의 규정을 준수하도록 보장해 주는 플랫폼을 제공하기를 원할 것입니다.

Kubernetes를 프로젝트 생성과 사용하는 노드, 가져올 라이브러리와 저장소에 대한 제어를 통해 기업이 중시하는 규칙을 적용하는 맞춤 플랫폼을 구축하는 방법이라고 생각해 보세요. 백그라운드 제어는 일반적으로 앱 개발자에 의해 관리된다기보다는, 통제되는 안전한 운영 프레임워크를 개발자에게 제공합니다.

대부분의 관리형 서비스는 플랫폼 운영자가 손쉽게 이용할 수 있는 자동화된 정책 제어와 권장사항을 제공하거나 지원합니다. 예를 들어 Anthos Service Mesh는 서비스 간의 트래픽 흐름과 API 호출을 제어하도록 도와줍니다. 서비스를 자동으로 선언적으로 보호하는 기능을 통해 개발자는 생산성이 향상되는 효과를, 조직은 더 많은 기능을 더 빠르게 제공하는 효과를 누릴 수 있습니다. 동시에 회사 정책이나 정부 규정에 위배되는 기능을 출시하는 것을 방지할 수 있습니다.

Google Cloud는 Dockerfile 없이 소스 코드로 프로덕션에 즉시 사용 가능한 안전한 컨테이너 이미지를 쉽고 빠르게 만들 수 있는 오픈소스 기술인 buildpacks를 지원합니다. Artifact Registry는 Google Cloud에 안전한 비공개 빌드 아티팩트 스토리지를 설정하여 아티팩트를 액세스하거나 조회, 다운로드할 수 있는 사람을 계속 제어할 수 있도록 해 줍니다. 컨테이너 분석은 Artifact Registry 및 Container Registry의 이미지에 대한 취약점 스캔을 제공합니다.

4. Kubernetes는 에지로 계속 확장되고 보조 프로세서를 이용하며 퍼블릭 클라우드와 프라이빗 클라우드에서 효율적으로 실행될 것입니다.

이 시리즈의 마지막 에피소드에서는 에지의 Kubernetes, 보조 프로세서에서 실행되는 Kubernetes, 퍼블릭 클라우드와 프라이빗 클라우드 간 적절한 균형 찾기 등 현장에서 대두된 몇 가지 화두와 관련된 질문들을 간단히 취합했습니다.

에지의 Kubernetes.

Google은 이미 에지에서 Kubernetes의 잠재력이 실현되고 있는 것을 목격하고 있습니다. 예를 들어, 전자통신 및 소매업 분야에서는 에지에 Kubernetes가 사용되고 있습니다. 에지 보안에 대한 우려섞인 견해에 대해 에릭은 Kubernetes를 실질적으로 보호할 수 있으며 중요한 것은 풀 스택이라고 설명합니다. 신뢰할 수 있는 루트를 통해 하드웨어와 하드웨어에서 실행되는 스택에 이르기까지 종합적으로 보호하여 보안을 강화할 수 있습니다.

이 분야는 Google Cloud의 지속적인 투자 대상입니다. Google Cloud는 Next 2021에서 Google Cloud의 인프라와 서비스를 에지로 확장하는 완전 관리형 하드웨어 및 소프트웨어 솔루션 포트폴리오인 Google Distributed Cloud를 발표했습니다. 이 솔루션은 GKE가 주요 구성요소인 Anthos를 기반으로 하며 로컬 데이터 처리, 에지 컴퓨팅, 온프레미스 현대화는 물론이고 주권, 엄격한 데이터 보안 및 개인 정보 보호 요구사항을 충족하는 데 이상적입니다. Kubernetes를 에지에서 안전하게 사용할 수 있도록 Distributed Cloud는 Google 에지 네트워크, 통신사 에지(통신 서비스 업체 파트너가 제공하는 5G 및 LTE 서비스) 또는 소매 매장, 공장 현장, 지사 등 자체 에지에서 클러스터에 대한 중앙화된 구성 및 제어를 제공합니다.

보조 프로세서에서 실행되는 Kubernetes

Google은 에지에서 Anthos를 실행하는 데 필요한 GPU 가속화 컴퓨팅 및 네트워킹 솔루션을 제공하기 위해 NVIDIA와도 협력하고 있습니다. 이러한 협업은 Kubernetes와 관련된 보조 프로세서의 잠재력을 보여줍니다. 에릭은 컴퓨팅의 미래에서 보조 프로세서가 중요한 부분을 차지한다고 생각합니다. 무어의 법칙이 그 유효성을 다해가는 이 시점에 이를 보완하기 위해 업계는 GPU 기반 그래픽 처리, TPU 기반 머신러닝과 같은 사용 사례에 맞게 가속화된 전문 분야별 하드웨어를 채택하고 있습니다.

퍼블릭 클라우드와 프라이빗 클라우드 간의 적절한 균형

이 모든 급격한 혁신에도 불구하고 퍼블릭 클라우드와 독립된 프라이빗 클라우드를 균형감 있게 운영하는 문제는 여전히 회사에 골치 아픈 질문을 던집니다. 에릭은 퍼블릭 클라우드가 왜 더 많은 혜택을 가져다 줄 수 있는지에 대한 명백한 이유를 제시합니다.

개방형 퍼블릭 클라우드는 비용 효율성이 더 우수하기 때문에, 둘 중 하나만 사용할 수 있다면 거의 대부분의 경우 개방형 퍼블릭 클라우드를 사용하는 것이 좋습니다. 혁신의 속도가 빨라지고, 시간이 지날수록 할 수 있는 일이 늘어날 것입니다 에릭 브루어

퍼블릭 클라우드 제공업체를 이용한다면 클라우드 제공업체와 이 업체가 위치한 국가(오늘날은 대개 미국임)의 정부를 신뢰해야 합니다. 그들을 신뢰하지 않거나 너무 많은 위험이 존재한다고 생각하면 독립된 프라이빗 클라우드를 통해 자국에서 운영할 수 있습니다. 이 경우 Kubernetes는 프라이빗 클라우드에서 실행하기에 매우 적합하다는 장점이 있습니다. 에릭이 개발을 지원한 Anthos를 사용하면 Kubernetes를 하이브리드 및 멀티 클라우드 환경의 GKE에서 실행하거나 베어메탈에서 실행할 수 있습니다. 공급업체 종속을 우려하는 기업의 경우, Anthos에서 이전하여 온프레미스에서 Kubernetes 애플리케이션을 계속 실행할 수 있습니다.

Google Cloud의 다음 외부 출시 제품과 클라우드 컴퓨팅의 미래에 대한 에릭의 예측을 들으려면 위의 동영상을 확인하세요. Google에서 에릭의 연구 활동에 대한 최신 소식을 확인하려면 Twitter에서 @eric_brewer를 팔로우하세요.

@stephr_wong을 팔로우하면 최신 콘텐츠를 계속 확인할 수 있습니다.

GKE 개발 여정 바로 시작하기

Thu, 13 Jan 2022 12:00:00 +0000

Kubernetes를 자동으로 배포, 확장, 관리할 방법을 찾고 계신가요? Google Kubernetes Engine(GKE)은 완전 관리형 서비스를 제공하고 오토파일럿 운영 모드로 핸드오프 경험을 제공하는 가장 성숙한 컨테이너 오케스트레이션 서비스입니다.

GKE란 무엇인가요

GKE는 멀티 클러스터 지원, 4방향 자동 확장, 노드 자동 복구 등 업계 최초로 제공되는 다양한 기능들을 자랑하며, 한 클러스터에서 최대 15,000개의 노드를 지원할 수 있습니다. GKE는 기본적으로 개발자 도구 모음, CI/CD, 로깅, 모니터링과 통합되어 엔드 투 엔드 개발자 환경을 제공합니다.

GKE를 사용하는 개발자들이 얻을 수 있는 이점에는 크게 아래와 같은 4가지가 있습니다.

1. Kubernetes 개발 속도 향상

Cloud Code 를 활용하면, 쉽게 Kubernetes 설정 파일을 작성하고 생산성을 높일 수 있어 Kubernetes 개발 속도가 향상됩니다. 개발자들은 익숙한 환경에서 코딩을 할 때 가장 높은 생산성을 발휘합니다. Cloud Code가 기본적으로 제공하는 도구는 개발자 워크플로를 크게 간소화 시킵니다. 이를테면 Cloud Code를 사용하면 여러 도구 간의 컨텍스트 전환을 줄임으로써 개발 생산성을 향상 시킬 수 있고, Cloud Code의 기본 제공 로그 뷰어를 사용하면, 클릭 한 번으로 버전 및 서비스 로그에 액세스할 수 있어 각 버전의 로그를 더욱 쉽게 볼 수 있습니다. 또한 Cloud Code는 인라인 문서, 코드 완성, 스키마 검증, 즉, ‘린트 작업' 등의 설정 파일 작성 지원 기능을 제공하므로 개발자들이 애플리케이션 설정보다 코드 작성에 더 많은 시간을 투자할 수 있게 해줍니다. 그리고 Cloud Code에서는 실시간 디버그가 가능해 개발자들의 소중한 시간을 절약할 수 있습니다.

2. Kubernetes 배포 가속화

Google Cloud CI/CD 도구를 사용해 소스부터 프로덕션까지 엔드 투 엔드 자동화를 구현하면 Kubernetes 빌드 및 배포 시간을 단축할 수 있습니다. 시스템에서 작업하는 개발자가 많을 경우 코드 업데이트를 조정하는 것은 어려운 일이며, 다른 개발자의 변경사항이 호환되지 않을 수도 있습니다. 지속적 통합(CI) 방식을 사용하면 개발자가 모든 코드 변경사항을 메인 브랜치에 자주 통합하여 프로세스 초반에 문제를 드러내 오류를 빠르게 노출할 수 있습니다. 지속적 배포(CD)를 사용하면 언제든지 코드를 출시할 수 있습니다. Google Cloud 에서는 Cloud Source Repositories, Cloud Build, Artifact Registry를 통해 CI/CD 파이프라인을 구축할 수 있는 방법을 제공하고 있습니다.

3. 쉬운 Kubernetes 실행

Kubernetes 클러스터를 직접 실행하고 운영, 관리하는 것은 어려울 수 있습니다. GKE는 Cloud Console을 통해 편리한 클러스터 관리 기능을 UI로 제공하고 있고, 자동 업그레이드, 자동 복구, 자동 확장 등의 기능을 제공함으로써 Kubernetes 클러스터를 관리형 서비스로 쉽게 실행할 수 있도록 합니다. 또한 Kubernetes 클러스터에 원하는 수준의 유연성, 책임, 제어 수준에 따라 GKE Autopilot 또는 Standard 모드를 선택하여 사용할 수 있습니다.

4. Kubernetes 관측 가능성 확장

컨테이너를 선택하는 이유는 애플리케이션 개발 속도를 개선하고 확장을 준비하기 위해서입니다. Google Cloud Operations Suite는 Google Cloud에서 실행되는 애플리케이션 및 시스템에 대한 통합 모니터링, 로깅, 트레이싱을 위한 관리형 서비스입니다. GKE에는 클라우드 모니터링 및 클라우드 로깅과 기본 통합이 포함되어 GKE 클러스터를 만들면 Cloud Operations for GKE가 기본적으로 사용 설정되며, Kubernetes용으로 특별히 설계된 모니터링 대시보드가 제공됩니다.

Google Cloud에서 최근 공개한 eBook에서는 GKE 개발 여정을 시작할 때 참조 가이드로 활용할 내용이 상세히 기술되어 있습니다. 코딩, 빌드, 실행, 운영, 관리에 이르는 모든 것을 다룹니다. GKE를 처음 사용한다면 이 eBook은 중요 고려사항과 권장사항을 소개하는 유용한 자료가 될 것입니다. 지금 바로 다운로드 하시고 GKE와의 여정을 시작해보세요.

새로운 Anthos 및 GKE용 Redis Enterprise

Tue, 27 Jul 2021 02:18:00 +0000

* 본 아티클의 원문은 2021년 4월 22일 Google Cloud 블로그(영문)에 게재되었습니다.

미래 지향적인 개발자들 사이에서 오픈소스 Redis 인메모리 데이터 구조 저장소는 데이터베이스, 캐시, 메시지 브로커가 필요할 때 고려할 만한 인기 있는 옵션입니다. 지난 Google Cloud Next 2019에서 Redis의 제작사인 Redis Labs는 Google Cloud에서 실행되는 완전 관리형 서비스로서의 데이터베이스(DBaaS)를 발표했습니다. 이번 주 RedisConf 2021에서는 지난 협업을 토대로 Anthos 및 Google Kubernetes Engine(GKE)용 Redis Enterprise 비공개 프리뷰 버전을 Google Cloud Marketplace에 선보입니다. 이에 따라 컨테이너 클러스터에서 동일한 위치에 있는 앱과 서비스를 실행해야 하는 Google Cloud 고객이 자체 관리형 Redis Enterprise 솔루션을 사용할 수 있게 됩니다.

Anthos는 GKE의 기본적인 요소를 기반으로 합니다. Google Cloud, 온프레미스, AWS와 더불어 조만간 Azure에서 컨테이너화된 애플리케이션을 배포, 관리, 확장할 수 있는 관리형 하이브리드 및 멀티 클라우드 플랫폼을 제공합니다. 이기종(온프레미스 및 클라우드) 환경을 갖춘 기업 고객은 Anthos를 사용하여 광범위한 배포 토폴로지에서 애플리케이션 자산을 원활하게 조정할 수 있습니다. Redis Labs의 새로운 Kubernetes 기반 데이터 서비스가 추가되면서 보다 간편하게 앱과 데이터 서비스를 결합할 수 있어 Google Cloud를 통한 통합 결제로 전역 제어 영역에서 앱과 데이터 서비스를 운영할 수 있습니다.

"고객에게 더 맞춤화된 경험을 제공하기 위해서는 낮은 오버헤드와 적은 유지보수로 신속하게 확장할 수 있는 솔루션이 필요했습니다."라고 Belk IT 부문 이사인 아브닌드라 아룬은 말했습니다. "GKE와 Redis Enterprise 덕분에 빠르게 배포하고 쉽게 유지보수할 수 있는 뛰어난 조합의 유연하고도 비용 효율적인 솔루션을 얻었습니다."

Anthos on GKE에서 사용하는 Redis Enterprise에 대한 자세한 내용은 Redis Labs 보도 자료를 참조하거나 Redis팀에 문의하세요.

GKE에서 새로운 멀티 인스턴스 NVIDIA GPU로 워크로드 처리 속도 향상

Thu, 08 Jul 2021 16:01:00 +0000

* 본 아티클의 원문은 2021년 4월 28일 Google Cloud 블로그(영문)에 게재되었습니다.

머신러닝, 시각화/렌더링, 고성능 컴퓨팅 등 까다로운 워크로드를 실행하기 위해 Google Kubernetes Engine(GKE)을 사용하여 NVIDIA GPU에 대한 지원을 활용하는 개발자와 데이터 과학자가 점점 많아지고 있습니다. GKE는 유연성, 자동 확장, 간편한 관리를 지원하며 GPU는 우수한 처리 능력을 제공합니다. 오늘 Google Cloud가 GKE의 멀티 인스턴스 GPU에 대한 지원(현재 미리보기 버전)을 선보임에 따라 사용자는 기존의 GPU 투자에서 더 많은 가치를 창출할 수 있게 되었습니다.

오픈소스 Kubernetes는 컨테이너의 워크로드에 GPU 중 일부만 필요로 하더라도 컨테이너마다 전체 GPU를 할당합니다. 이는 리소스 낭비와 비용 초과를 초래할 수 있으며 특히 최신 세대의 강력한 GPU를 사용하고 있는 경우에는 더 그렇습니다. 무엇보다 (수백만 개의 샘플을 대규모 배치로 처리하는 학습 워크로드와 달리) 소수의 샘플만 실시간으로 처리하는 추론 워크로드에서 우려가 더 큽니다. 따라서 추론 및 기타 경량의 GPU 워크로드에서 사용률을 개선하고 비용을 절감하려면 GPU 공유가 필수입니다.

GKE에 멀티 인스턴스 GPU가 출시되면서 이제 단일 NVIDIA A100 GPU를 최대 7개의 인스턴스 파티션으로 나눌 수 있으며 각 인스턴스에는 자체적인 고대역폭 메모리, 캐시, 컴퓨팅 코어가 있습니다. 각 인스턴스를 컨테이너 하나에 할당할 수 있으므로 NVIDIA A100 GPU당 최대 7개 컨테이너에 할당할 수 있습니다. 또한 멀티 인스턴스 GPU는 컨테이너 간에 하드웨어 격리를 제공하며 GPU에서 실행되는 모든 컨테이너에 대해 일관되고 예측 가능한 QoS를 제공합니다.

아울러 Google Cloud에서 가장 큰 GPU 기반 Compute Engine 인스턴스인 A2 VM이 인스턴스당 최대 16개의 A100 GPU를 지원합니다. 즉, 노드당 최대 112개의 예약 가능한 GPU 인스턴스가 지원되며 인스턴스마다 독립적인 단일 워크로드를 실행할 수 있습니다. GKE에서 제공되는 업계 최고 수준의 자동 확장 및 자동 프로비저닝 기능을 활용하면 멀티 인스턴스 GPU를 자동으로 확장 또는 축소하여 저렴한 비용으로 우수한 성능을 제공할 수 있습니다.

CUDA® 애플리케이션에서 멀티 인스턴스 GPU는 대체로 투명하게 표현됩니다. 각 GPU 인스턴스는 일반 GPU 리소스로 표시되며 프로그래밍 모델이 변경되지 않아 멀티 인스턴스 GPU를 쉽고 편리하게 사용할 수 있습니다.

고객 의견

멀티 인스턴스 GPU 노드의 얼리 어답터들은 이 기술을 토대로 까다로운 워크로드에 GKE를 더욱 효과적으로 사용할 수 있습니다. 보험 부문용 자산 통계 및 워크플로 도구 제공업체인 Betterview는 GKE와 NVIDIA GPU를 사용해 항공 이미지를 처리합니다.

"A100을 사용한 멀티 인스턴스 GPU 아키텍처 덕분에 Kubernetes/GKE의 GPU 작업이 한층 더 발전했습니다. Google Cloud와 NVIDIA는 GPU를 리소스에 연결하기 위해 거쳐야 할 구성 절차의 수를 줄여 머신러닝을 대규모로 배포할 때의 장벽을 낮췄습니다. A100을 사용한 NVIDIA의 GPU 추론 성능은 구성의 복잡성을 덜 뿐만 아니라 속도도 매우 빠릅니다. Google Cloud와의 협업을 통해 Betterview에 가장 적합한 방식으로 AI를 배포할 수 있는 여러 탁월한 옵션을 얻었습니다." - 제이슨 야노프스키, Betterview 엔지니어링 부문 부사장 겸 CTO

멀티 인스턴스 GPU 파티션 만들기

A100 GPU는 컴퓨팅 단위 7개와 메모리 단위 8개로 구성되며, 서로 다른 크기의 GPU 인스턴스로 파티션을 나눌 수 있어 워크로드 확장에 필요한 유연성과 선택권이 확보됩니다. 예를 들어 각각 메모리 20GB를 사용하는 인스턴스 2개, 10GB를 사용하는 인스턴스 3개 또는 5GB를 사용하는 인스턴스 7개로 2개의 멀티 인스턴스 GPU를 만들 수 있습니다.

GPU 파티션 인스턴스는 [compute]g.[memory]gb구문을 사용합니다. 예를 들어 1g.5gb의 GPU 파티션 크기는 하나의 컴퓨팅 단위(GPU 스트리밍 멀티프로세서의 1/7)와 하나의 메모리 단위(5GB)가 있는 GPU 인스턴스를 나타냅니다. A100 GPU의 파티션 크기는 GKE 클러스터 또는 노드 풀 API를 통해 지정할 수 있습니다.

멀티 인스턴스 GPU 노드에 컨테이너 배포

한 노드에서 멀티 인스턴스 GPU 인스턴스당 최대 1개의 컨테이너를 배포할 수 있습니다. 파티션 크기가 1g.5gb이면 A100 GPU 1개를 사용하는 노드에 사용할 수 있는 멀티 인스턴스 GPU 파티션은 7개입니다. 따라서 이 노드에 GPU를 요청하는 컨테이너를 최대 7개까지 배포할 수 있습니다.

각 노드에는 사용할 수 있는 GPU 파티션 크기로 라벨이 지정됩니다. 라벨 지정을 통해 워크로드에서 노드 선택기 또는 노드 어피니티로 적절한 크기의 GPU 인스턴스를 요청할 수 있습니다.

시작하기

이제 GKE에서 멀티 인스턴스 GPU를 사용하면 적절한 크기의 리소스로 워크로드 처리 속도 향상 요구에 손쉽게 대응할 수 있습니다. 또한 GKE를 활용하여 인프라를 자동으로 확장해 워크로드 처리 가속화 요구를 효율적으로 지원하는 동시에 우수한 사용자 경험을 제공하고 운영 비용을 최소화할 수 있습니다. 지금 시작하기

예시로 알아보는 Google Kubernetes Engine 서비스 문제 해결

Wed, 14 Apr 2021 00:00:00 +0000

* 본 아티클의 원문은 2021년 2월 27일 Google Cloud 블로그(영문)에 게재되었습니다.

애플리케이션이 실패하고 컨테이너가 비정상 종료되는 일은 흔하게 발생합니다. 이는 SRE 및 DevOps팀도 익히 알고 있는 사실입니다. 앞서 일시적인 장애를 잘 해결할 수 있도록 Google Kubernetes Engine(GKE)에서 실행되는 애플리케이션을 디버깅하는 방법을 알려드린 바 있습니다. 또한 더 쉽게 사용할 수 있는 새로운 문제 해결 흐름으로 GKE 대시보드도 업데이트했습니다. 오늘은 한 단계 더 나아가 이러한 흐름을 사용해 애플리케이션 및 인프라의 문제점을 빠르게 찾아 해결하는 방법을 알려드립니다.

이 블로그에서는 클러스터에 샘플 앱을 배포하고 컨테이너 재시작이 관측되면 알려주는 알림 정책을 구성하는 과정을 살펴보겠습니다. 그런 다음 알림을 트리거하여 새로운 GKE 대시보드에서 얼마나 쉽게 문제를 식별하고 문제의 원인일 수 있는 워크로드 또는 인프라의 상황을 정확히 파악하는지 알아봅니다.

설정

앱 배포

이 예시에서는 'hello world'에 해당하는 /의 엔드포인트와 Go의 os.Exit(1)를 사용해 프로세스를 종료하는 /crashme 엔드포인트를 노출하는 데모 앱을 사용합니다. 앱을 자체 클러스터에 배포하려면 Cloud Build를 사용해 컨테이너 이미지를 만들어 GKE에 배포하세요. 그런 다음 부하 분산기를 사용해 서비스를 노출하시기 바랍니다.

서비스가 배포되면 실행 중인 pod를 확인합니다.

code_block: <ListValue: [StructValue([('code', '✗ kubectl get pods\r\nNAME READY STATUS RESTARTS AGE\r\nrestarting-deployment-54c8678f79-gjh2v 1/1 Running 0 6m38s\r\nrestarting-deployment-54c8678f79-l8tsm 1/1 Running 0 6m38s\r\nrestarting-deployment-54c8678f79-qjrcb 1/1 Running 0 6m38s'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb85ece80>)])]>

각 pod에서 RESTARTS가 처음에는 0인 것에 주목하세요. 브라우저나 curl과 같은 명령줄 도구를 사용해 /crashme 엔드포인트에 액세스합니다. 이번에는 재시작이 표시됩니다.

code_block: <ListValue: [StructValue([('code', '✗ kubectl get pods\r\nNAME READY STATUS RESTARTS AGE\r\nrestarting-deployment-54c8678f79-gjh2v 1/1 Running 1 9m28s\r\nrestarting-deployment-54c8678f79-l8tsm 1/1 Running 0 9m28s\r\nrestarting-deployment-54c8678f79-qjrcb 1/1 Running 0 9m28s'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb85eccd0>)])]>

이 엔드포인트에 대한 각 요청에서 재시작이 발생합니다. 하지만 이 작업을 30초 미만 간격으로 반복하면 컨테이너가 CrashLoopBackOff 상태가 되며 서비스를 다시 사용할 수 있기까지 시간이 걸리므로 주의해야 합니다. 이 단순한 셸 스크립트를 사용하면 필요할 때 재시작을 트리거할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'while true;\r\ndo \r\ncurl http://$IP_ADDRESS:8080/crashme; \r\nsleep 45; \r\ndone'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fdfb85ecdf0>)])]>

여기에서 $IP_ADDRESS는 앞서 만든 부하 분산기의 IP 주소입니다.

컨테이너 재시작이 중요한 이유는 무엇일까요? 재시작은 Kubernetes의 일반적인 컨테이너 수명 주기에서 어느 정도 예상되는 문제입니다. 하지만 컨테이너 재시작이 지나치게 여러 번 발생하고 특히 특정 pod에서 많은 수의 복제본으로 확장되면 서비스 가용성에 영향을 미칠 수 있습니다. 과도한 재시작은 문제의 서비스 성능을 저하시킬 뿐만 아니라 해당 서비스를 종속 항목으로 사용하는 다른 서비스에도 영향을 미칠 위험이 있습니다.

실제로는 잘못 설계된 활성 프로브, 애플리케이션 자체의 교착 상태와 같은 문제 또는 OOMkilled 오류를 발생시키는 잘못 구성된 메모리 요청이 과도한 재시작의 원인일 수 있습니다. 따라서 컨테이너 재시작에 대한 사전 알림을 통해 다수의 서비스로 확산될 수 있는 잠재적 성능 저하를 방지해야 합니다.

경고 구성

이제 재시작이 감지되면 알려주는 알림을 구성할 차례입니다. 알림 정책을 설정하는 방법은 다음과 같습니다.

배포 YAML 파일에 지정되어 있는 특정 컨테이너 이름으로 필터링하여 kubernetes.io/container/restart_count 측정항목을 사용하면 됩니다. 시계열이 0을 초과하는 경우, 즉 컨테이너 재시작이 관측되면 알림이 트리거되도록 구성합니다.

설정을 완료하면 알림을 테스트하여 상황을 파악할 수 있습니다.

알림 테스트

준비가 되면 45초마다 /crashme 엔드포인트에 도달하는 반복 스크립트를 시작합니다. restart_count 측정항목은 60초 간격으로 샘플링되어 있으므로 알림이 대시보드에 표시되는 데 오랜 시간이 걸리지 않습니다.

이슈 위로 마우스를 가져가면 자세한 정보를 확인할 수 있습니다.

그런 다음 '이슈 보기'를 클릭합니다. 그러면 이슈 세부정보 화면으로 이동하여 이슈를 트리거한 특정 리소스를 확인할 수 있습니다. 이 경우에는 컨테이너에서 이슈가 생성되었습니다.

다음으로 '로그 보기'를 클릭하여 새 로그 뷰어에서 로그를 확인합니다. 재시작된 컨테이너에서 알림이 트리거된 것을 바로 확인할 수 있습니다.

이 모든 기능이 효과적으로 연결되어 이슈가 발생했을 때 문제를 훨씬 쉽게 해결할 수 있습니다.

요약

최신 GKE 대시보드는 이전 버전보다 많은 부분이 개선되었습니다. 새로운 알림 타임라인은 직관적이며 이슈가 분명하게 표시되어 상호작용을 통해 정확한 상황에 대한 자세한 정보를 얻을 수 있고, 실질적인 문제를 알려주는 컨테이너 로그도 확인할 수 있습니다.

GKE 대시보드가 GKE에서 실행되는 서비스의 긴급 대기 SRE 또는 DevOps 엔지니어의 역할을 해주기 때문에 이슈에 쉽게 대처할 수 있습니다. 이제 이슈 확인부터 로그 디버깅까지 쉽고 빠르게 처리하여 이슈를 선별하고 완화하는 시간을 단축할 수 있습니다. GKE에서 서비스 문제를 해결하는 방법에 대한 간략한 개요를 이 동영상에서 확인하세요.

^{이 블로그 게시물에 도움을 주신 고객 엔지니어 전문가, 앤서니 부숑에게 감사의 말을 전합니다.}

컨테이너 및 Kubernetes

Agent Sandbox 소개: Kubernetes 및 GKE 기반 에이전트 AI를 위한 강력한 보호장치

대규모 환경에서의 강력한 격리

GKE를 통한 성능 향상

AI 엔지니어를 위한 빌드

지금 시작하기

GKE: 컨테이너에서 에이전트까지, 모든 최신 워크로드를 위한 통합 플랫폼

AI 에이전트의 부상

AI 기가와트 시대를 위한 독보적인 확장성

모든 워크로드를 위한 더 나은 컴퓨팅

AI 추론을 강화하는 플랫폼

Kubernetes와 GKE의 다음 10년을 위하여

Google Kubernetes Engine의 Managed Lustre 관련 5가지 권장사항

1. 데이터 지역성을 고려한 설계

2. 성능에 맞는 등급 선택

3. 네트워킹 기반 구축

4. 단순성을 원한다면 동적 프로비저닝을, 장기 공유 데이터에는 정적 프로비저닝을 사용

5. Kubernetes 작업으로 병렬 처리 설계

지금 시작하기

클릭에서 클러스터로: Intel TDX를 통해 확장되는 Confidential Computing

클릭 한 번으로 Confidential VM 생성

더 많은 리전 및 영역에서 기밀 컴퓨팅 활용

Intel TDX를 활용한 Confidential GKE Node 정식 출시

Intel TDX를 활용한 기밀 공간(Confidential Space) 정식 출시

NVIDIA H100 GPU를 활용한 기밀 VM 및 기밀 GKE 노드 정식 출시

Intel, 독립 증명을 위한 무료 등급 제공

고객 후기

기밀 컴퓨팅 시작하기

GKE의 열번째 생일을 기념해 더욱 새로운 기능과 프라이싱을 만나보세요.

업데이트된 가격으로 유연성 강화

모든 클러스터에 Autopilot으로 최적화된 컴퓨팅 제공

고객 성공을 위한 혁신

일관된 발전을 위한 기반

30개 이상의 구글 클라우드 서비스를 지원할 수 있도록 확장된 Custom Org Policy! 클라우드 액세스 제어의 새로운 장 열어...

확장된 Custom Org Policy로 안전하게 액세스 제어 관리

Cloud SQL에 대한 강력한 데이터 거버넌스 구축

Yahoo, Custom Org Policy로 보안 강화

Custom Org Policy 시작하기

Announcing general availability of Custom Org Policy to help tailor resource guardrails with confidence

Google Cloud의 관리형 쿠버네티스 서비스 GKE가 컨테이너 환경의 소프트웨어 공급망 보안을 강화하는 방법!

GKE Security Posture 대시보드로 투명하고 신속하게 위험을 찾아 대처!

지금 바로 활용해 보세요!

Kubernetes 서비스로 GKE를 선택해야 하는 이유

전체 산업의 기회를 확대한 Kubernetes의 오픈소스 제공

고객이 중요한 워크로드에 Google Kubernetes Engine을 믿고 활용하는 이유

Google, 2023년 Gartner® Magic Quadrant™의 컨테이너 관리 부문에서 선두 기업으로 선정

GKE용 멀티 클러스터 게이트웨이 컨트롤러 정식 버전 출시

GKE 멀티 클러스터 게이트웨이 컨트롤러 소개

멀티 클러스터 게이트웨이 시작하기

지원되는 Cloud 부하 분산기

GKE Fleet에서 전역 및 리전 라우팅 최적화

점진적 배포(블루-그린 업그레이드 또는 배포)

근접 라우팅을 사용하는 분산형 애플리케이션

용량 기반 부하 분산

멀티 클러스터 게이트웨이로 노출된 애플리케이션 보호

기밀성과 무결성을 위한 TLS 암호화

Cloud Armor로 게이트웨이 백엔드 제어 및 보호

IAP(Identity-Aware Proxy)로 트래픽 인증 및 승인

다음 단계

Google Kubernetes Engine Gateway controller is now GA for single cluster deployments

AlloyDB의 다운로드 가능한 버전인 AlloyDB Omni 정식 버전 출시

Firestore에 PITR(point-in-time recovery) 및 예약 백업 추가

PITR(point-in-time recovery) 예시 살펴보기

예약 백업 예시 살펴보기

다음 단계

GPU 를 지원하는 GKE Autopilot 에서의 TensorFlow

설정

설치

노트북 사용

모니터링 및 문제 해결

다음 단계

정리하기

다음 단계

Artifact Registry 및 컨테이너 스캔을 사용하여 원점 회귀 보안 달성 및 배포 간소화

Google Kubernetes Engine: 7년의 발자취와 7가지 이점

개발자 생산성 증가

소프트웨어 공급망 보안 강화

플랫폼 접근 방식을 통한 새로운 기회 창출

고객에게 상시 사용 가능한 경험 제공

조직의 비용 최적화 및 절감 지원