Infrastructure Modernization

클릭에서 클러스터로: 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 0x7fa3aa1f4f40>), ('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 문서를 확인하세요

클라우드에서의 고객 경험 향상: 디지털 주권, 폭넓은 선택, 강력한 보안으로

Wed, 21 May 2025 08:00:00 +0000

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

대부분의 조직과 마찬가지로 Google Cloud는 고객, 파트너 및 정책 입안자들과 지속적으로 협력하여 그들의 요구를 반영하는 기술 역량을 제공하고 있습니다. 디지털 주권 솔루션에 관해서는 Google Cloud가 거의 10년 동안 고객들과 협력해 왔습니다.

오늘, 저희는 고객을 위한 주권형 클라우드 솔루션에 대한 중요한 기술 및 상업적 업데이트와 함께, 고객이 기능 저하 없이 클라우드에서 어떻게 더 큰 통제권, 선택권 및 보안을 확보할 수 있도록 지원하고 있는지 자세히 발표하게 되어 기쁩니다.

몇 년 전 저희가 처음 선보인 주권 솔루션을 기반으로, 저희는 전 세계적으로 인프라 규모를 대폭 확장했으며, 현재 42개 이상의 클라우드 리전, 127개 영역, 202개 네트워크 에지 로케이션, 33개의 해저 케이블 투자를 포함하고 있습니다.

또한 아시아, 유럽, 중동 및 미국에서 슈바르츠 그룹(Schwarz Group) 및 T-시스템즈(T-Systems, 독일), S3NS(프랑스), 민사이트(Minsait, 스페인), 텔레콤 이탈리아(Telecom Italia, 이탈리아), 클라렌스(Clarence, 벨기에 및 룩셈부르크), CNTXT(사우디아라비아), KDDI(일본), 월드 와이드 테크놀로지(World Wide Technology, 미국) 등 주요 파트너십을 구축하여 이러한 주권 솔루션을 제공하는 데 도움을 주고 있습니다.

고객 선택권에 대한 약속

Digital sovereignty is about more than just controlling encryption keys. At its core, it’s about giving customers the flexibility their global businesses require. It’s about enabling them to operate on multiple clouds. And it’s about securing data with the most advanced technologies.

디지털 주권은 단순히 암호화 키를 제어하는 것 이상입니다. 핵심은 고객의 글로벌 비즈니스에 필요한 유연성을 제공하는 것입니다. 여러 클라우드에서 운영할 수 있도록 지원하는 것입니다. 그리고 가장 진보된 기술로 데이터를 보호하는 것입니다.

저희는 오랫동안 고객이 자신의 필요에 가장 적합한 클라우드 제공업체와 솔루션을 선택할 수 있도록 지원하고 단일 옵션에 얽매이지 않도록 하는 데 전념해 왔습니다. 클라우드에서의 주권은 모든 경우에 적용되는 단일 해결책이 아닙니다. 저희는 고객의 비즈니스 요구, 규제 요건 및 위험 프로필에 부합하는 솔루션 포트폴리오를 제공합니다.

고객에 대한 저희의 강력한 계약상 약속은 현재 모두 사용 가능한 견고한 주권 제어 기능과 솔루션으로 뒷받침됩니다. 저희의 업데이트된 주권형 클라우드 솔루션 포트폴리오에는 다음이 포함됩니다.

Google Cloud Data Boundary는 고객에게 주권형 데이터 경계를 배포하고 콘텐츠가 저장되고 처리되는 위치를 제어할 수 있는 기능을 제공합니다. 이 경계는 또한 고객이 Google 인프라 외부에서 암호화 키를 저장하고 관리할 수 있도록 하여, 고객이 어떤 시장에 있든 특정 데이터 액세스 및 제어 요구 사항을 충족하는 데 도움이 될 수 있습니다.

Google Cloud Data Boundary 고객은 AI 서비스를 포함한 다양한 Google Cloud 제품에 액세스할 수 있으며, 데이터에 대한 액세스를 제어하고 어떤 이유로든 액세스를 거부하기 위해 Confidential Computing 및 외부 키 관리(EKM)와 Key Access Justifications(키 액세스 명분)와 같은 기능을 활성화할 수 있습니다.

또한, Google Workspace 고객은 Google Cloud Data Boundary의 주권 제어 기능을 활용하여 콘텐츠 처리를 미국 또는 EU로 제한하고, 데이터를 로컬에 저장할 국가를 선택하며, 클라이언트 측 암호화를 사용하여 가장 중요한 콘텐츠에 대한 무단 액세스(Google에 의한 액세스 포함)를 방지할 수 있습니다.

오늘 저희는 또한 Google Cloud Data Boundary 위에 구축된 고객 애플리케이션의 보안을 검증하기 위해 Mandiant 서비스를 추가하는 솔루션인 User Data Shield를 발표합니다. User Data Shield는 고객 애플리케이션에 대한 반복적인 보안 테스트를 제공하여 주권 상태를 검증합니다

Google Cloud Dedicated는 독립적인 현지 및 지역 파트너를 통해 지원되는, 현지 주권 요구 사항을 충족하도록 설계된 솔루션을 제공합니다. 예를 들어, Google Cloud는 2021년부터 탈레스(Thales)와 협력하여 유럽을 위한 최초의 S3NS의 신뢰할 수 있는 클라우드(Trusted Cloud)를 구축했습니다.

탈레스와의 이 제안은 AI 워크로드를 지원하기 위한 GPU를 갖춘 풍부한 Google Cloud 서비스 세트를 제공하도록 설계되었으며, 독립적인 프랑스 법인인 S3NS에 의해 운영됩니다. 현재 프리뷰 버전인 S3NS의 솔루션은 프랑스의 SecNumCloud 표준의 엄격한 보안 및 운영 복원력 요구 사항을 충족하도록 설계되었습니다. 저희는 Google Cloud Dedicated의 적용 범위를 전 세계적으로 확장하고 있으며, 다음으로 독일에 출시할 예정입니다.

탈레스의 정보 시스템 및 보안 통신 담당 EVP인 크리스토프 살로몽(Christophe Salomon)은 "프랑스가 진정으로 디지털 주권을 수용하기 위해서는 하이퍼스케일 기술의 엄청난 힘과 가장 엄격한 현지 보안 및 운영 제어를 결합한 클라우드 솔루션이 필수적입니다. S3NS는 프랑스 조직에 중요한 AI 기능을 포함한 고급 클라우드 서비스에 대한 액세스를 제공하기 위해 최선을 다하고 있으며, 이 모든 것은 유럽 운영업체에 의해 프랑스 내에서 운영되어 엄격한 SecNumCloud 표준을 충족하고 초과 달성할 것입니다."라고 말했습니다.
Google Cloud Air-Gapped는 외부 네트워크에 연결할 필요가 없는 완전 독립형 에어갭 솔루션을 제공합니다. 이 솔루션은 엄격한 데이터 보안 및 상주 요건을 가진 정보, 국방 및 기타 부문의 고객을 위해 맞춤 제작되었습니다. 에어갭 솔루션은 Google, 고객 또는 Google 파트너가 배포하고 운영할 수 있습니다.

이는 오픈소스 구성 요소로 구축되었으며 AI, 데이터베이스 및 인프라 서비스의 특정 세트와 함께 제공됩니다. 에어갭 솔루션은 오픈소스 구성 요소에서 실행되므로 서비스 중단 시 비즈니스 연속성과 생존성을 제공하도록 설계되었습니다. Google Cloud Air-Gapped는 2024년에 미국 정부의 일급비밀(Top Secret) 및 비밀(Secret) 수준 데이터를 호스팅할 수 있는 권한을 받았습니다.

액센츄어(Accenture)의 수석 매니징 디렉터 겸 Google 비즈니스 그룹 책임자인 스콧 알피에리(Scott Alfieri)는 "Google Cloud와 협력하여 주권형 제품을 도입하면 공동 고객이 기본 클라우드 아키텍처의 기능을 저해하지 않으면서 클라우드에서 더 큰 통제권, 선택권 및 보안을 확보할 수 있습니다. Google Cloud의 광범위한 글로벌 인프라와 액센츄어의 혁신 및 산업 전문성이 결합되어 조직이 민첩하고 확장 가능한 기반을 구축하여 성장과 지속적인 혁신의 기회를 열 수 있도록 지원합니다."라고 말했습니다.

현지 제어, 글로벌 보안

보안과 주권은 동전의 양면과 같습니다. 데이터 및 운영에 대한 현지 제어는 고객에게 보안에 대한 더 큰 신뢰 수준을 제공할 수 있지만, 레거시 인프라에 대한 의존성으로 인해 데이터가 손실이나 도난에 취약하다면 어떤 조직도 주권을 가진 것으로 간주될 수 없다는 것도 사실입니다.

Google 위협 인텔리전스 그룹(GTIG)과 Google Cloud CISO 사무실의 분석에 따르면, 악의적인 행위자들이 AI 기반 도구와 기술을 활용하여 오래된 소프트웨어 제품, 플랫폼 및 구식 인프라를 공격함에 따라 글로벌 사이버 위협 환경은 더욱 복잡해질 것입니다.

Google Cloud를 통해 고객은 주권 솔루션뿐만 아니라 저희의 선도적인 보안 기능에도 액세스할 수 있습니다. 여기에는 설계 단계부터 보안을 고려하는 기술에 대한 저희의 엄격한 집중과, 전 세계 사이버 분쟁의 최전선에서 활동하며 전 세계 80개국 이상 정부와 신뢰할 수 있는 파트셔십을 유지하고 있는 Google 위협 인텔리전스 그룹 및 Mandiant 컨설팅의 깊은 전문성이 포함됩니다.

또한, Google Cloud CyberShield는 정부가 국가적 규모의 위협으로부터 방어할 수 있도록 AI 및 인텔리전스 기반 사이버 방어를 제공합니다. 그리고 Mandiant Managed Defense 서비스는 전 세계 고객이 저희 보안팀과 함께 보안팀을 쉽게 확장할 수 있도록 합니다.

Google 주권형 클라우드 솔루션은 궁극적으로 고객이 Google Cloud의 안전한 기반을 활용하는 동시에 Confidential Computing, Zero Trust, 양자 내성 암호화 및 AI 기반 플랫폼 방어와 같은 고급 보안 기능을 자체적으로 달성하는 것보다 더 빠르고 비용 효율적으로 이용할 수 있도록 지원합니다.

모든 조직을 위한 주권 솔루션

저희는 고객을 위한 신뢰와 통제의 환경을 조성하는 데 계속 전념하고 있으며, 전 세계 조직이 디지털 주권이라는 복잡한 환경을 자신 있게 헤쳐 나갈 수 있도록 지원합니다. 저희는 주권형 클라우드 제품을 개선하고 고객의 요구를 해결하는 기술을 제공하기 위해 전 세계 고객, 파트너 및 정책 입안자들과 지속적으로 협력하고 있습니다.

저희가 고객의 디지털 주권 역량을 어떻게 지원하고 있는지 자세히 알아보려면 저희 웹 페이지를 방문하거나 계정 관리자에게 문의하십시오.

온프레미스에 Gemini 및 Google Agentspace 도입

Wed, 09 Apr 2025 21:00:00 +0000

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

오늘, Gemini가 Google Distributed Cloud(GDC)에서 제공된다는 소식을 알려드립니다. 2025년 3분기부터 공개 프리뷰를 통해 Google의 가장 강력한 모델을 온프레미스 환경에 도입할 예정입니다. 이를 위해 Google Cloud는 NVIDIA와 협력하여 Google 또는 선호하는 채널을 통해 구매할 수 있는 NVIDIA Blackwell 시스템에 Gemini 모델을 도입했습니다.

GDC는 연결 및 에어 갭 적용 옵션 모두에서 제공되는 완전 관리형 온프렘 및 에지 클라우드 솔루션으로, 단일 서버에서 수백 개의 랙으로 확장할 수 있습니다. Infrastructure as a Service, 보안, 데이터, AI 서비스를 제공하며 풍부한 ISV(독립 소프트웨어 공급업체) 생태계로 확장 가능합니다. 인프라 관리를 담당하는 GDC 덕분에 개발자가 AI의 최대 역량을 활용하는 데 쉽게 집중하여 애플리케이션, 어시스턴트, 에이전트를 빌드할 수 있습니다.

“NVIDIA와 Google Distributed Cloud는 안전한 AI 플랫폼을 제공하여 Gemini 모델을 기업 데이터 센터와 규제 대상 산업에 도입합니다. Google Distributed Cloud는 NVIDIA Blackwell 인프라와 컨피덴셜 컴퓨팅을 통해 개인 정보 보호 및 보안을 강화하고 Dell에서 이용 가능한 DGX B200 및 HGX B200 시스템에서 업계 최고의 성능을 제공합니다.” - Justin Boitano, NVIDIA 기업 AI 소프트웨어 부문 부사장

지금까지 엄격한 규제, 주권, 지연 시간 또는 데이터 볼륨과 같은 문제로 인해 데이터를 온프레미스에 보관해야 하기 때문에 최신 AI 기술을 이용할 수 없었습니다. 오픈소스 모델과 도구만이 유일한 옵션이었습니다. 그리고 대부분의 경우 소프트웨어와 하드웨어를 직접 조합해야 하기 때문에 운영 부담과 복잡성이 증가합니다. GDC 기반 Gemini를 사용하면 AI의 뛰어난 기능과 데이터를 온프레미스 환경에 보관할 필요성 사이에서 타협할 필요가 없습니다.

Google의 GDC 에어 갭 적용 제품으로, 현재 미국 정부의 1급 및 2급 비밀 임무로 승인되었으며 Gemini를 사용할 수 있고 최고 수준의 보안 및 규정 준수 기능을 제공합니다.

aside_block: <ListValue: [StructValue([('title', 'Google Cloud AI 및 ML을 체험할 수 있는 $300 무료 크레딧 제공'), ('body', <wagtail.rich_text.RichText object at 0x7fa3735721c0>), ('btn_text', '무료 빌드 시작하기'), ('href', 'http://console.cloud.google.com/freetrial?redirectPath=/vertex-ai/'), ('image', None)])]>

GDC 기반 Gemini: 어디서나 생성형 AI 활용

Gemini 모델은 획기적인 AI 성능을 제공합니다. 수백만 토큰의 컨텍스트를 분석할 수 있고, 텍스트, 이미지, 오디오, 동영상과 같은 다양한 데이터 형식을 처리할 수 있는 멀티모달이며, 전 세계 100개 이상의 언어로 작동합니다.

또한 Gemini API는 인프라, OS 관리, 모델 수명 주기 관리에 대한 걱정 없이 AI 추론을 제공합니다. 이를 통해 다음과 같은 작업이 가능합니다.

비즈니스 컨텍스트 추가: 검색 증강 생성(RAG)을 사용하여 AI 모델의 출력을 맞춤설정하고 보강하므로 모델의 파인 튜닝 또는 재학습이 필요하지 않습니다.
정보 처리 및 지식 추출 자동화: 생성형 AI를 사용하여 긴 문서를 빠르게 요약하고 보고서 또는 의견의 감정을 분석하고 이미지, 오디오, 동영상 콘텐츠에 자막을 추가하여 직원의 효율성을 높일 수 있습니다.
양방향 대화형 환경 생성: Gemini 기반 고객 지원 에이전트, 자연어를 통한 챗봇, 직원 어시스턴트를 사용 설정하여 고객과의 관계를 강화합니다.
업계 사용 사례에 맞게 에이전트 맞춤설정: 금융 자문가부터 보안 어시스턴트, 로봇공학에 이르기까지 모든 사용자를 위한 맞춤형 에이전트를 개발하여 고도로 전문화된 기능과 워크플로를 활용할 수 있습니다." ServiceNow는 Google Distributed Cloud 기반 Gemini를 사용하여 강력한 API를 통해 기존 시스템에 추론과 같은 강력한 에이전틱 AI 기능을 보강할 수 있을 것입니다. 이러한 전략적 배포를 통해 최첨단 기술을 탐색하고 구현하는 동시에 고객 신뢰와 데이터 보호에 대한 약속을 지킬 수 있습니다." - Pat Casey, ServiceNow 최고 기술 책임자 겸 DevOps 부문 수석 부사장

Vertex AI: 클라우드 및 온프렘을 위한 하나의 플랫폼

오늘날 고객은 Gemini를 Google Distributed Cloud에 도입하는 것 외에도 이미 GDC 기반 Vertex AI 플랫폼을 활용하여 에이전트형 애플리케이션의 개발, 배포, 관리를 앞당기는 이점을 누리고 있습니다.

이 완전한 AI 플랫폼은 다음을 제공합니다.

선행 학습된 API: 번역, 음성 텍스트 변환, 광학 문자 인식(OCR)을 위한 고급 Google 모델을 기반으로 한 선행 학습된 API로 즉시 사용 가능하고 작업에 최적화되어 있습니다. 이러한 API는 맞춤설정 가능한 용어집 및 인플레이스 문서 번역과 같은 고급 기능을 제공합니다.
생성형 AI 빌드 도구: GKE 기반의 최적화된 추론을 사용하는 오픈소스 및 서드 파티 모델로 빠른 시작과 자동 확장을 제공합니다.
검색 증강 생성(RAG): Google Agentspace 검색 및 LLM API 관리를 사용한 그라운딩과 Apigee 온프렘을 사용한 거버넌스를 제공합니다.
기본 제공되는 임베딩 API 및 AlloyDB 벡터 데이터베이스: 맞춤설정 및 추천을 위한 강력한 애플리케이션으로 사용자 경험을 개선합니다.“Google Distributed Cloud, Vertex AI, Agentspace 검색을 활용하면 안전한 AI/ML 플랫폼과 통합 검색으로 Home Team 혁신가의 역량을 강화하여 AI를 사용해 생산성을 높이고 더욱 안전한 미래를 위해 공공 안전을 혁신할 수 있습니다.” - Chee Wee Ang, HTX 최고 AI 책임자

Google Agentspace: 온프렘 데이터에 즉시 액세스

기업은 생성형 AI를 배포하고자 하지만 다양한 저장소에 이미지, PDF, 텍스트와 같은 여러 형식으로 사일로화된 대량의 정보를 연결하는 데 어려움을 겪고 있습니다. 이는 생산성과 혁신을 저해합니다. 게다가 사내 검색 솔루션을 빌드하는 데 비용이 많이 들고 여기에 필요한 AI 전문성은 희소합니다.

2025년 3분기부터 공개 프리뷰 버전으로 GDC에서 Google Agentspace 검색을 사용할 수 있다는 기쁜 소식을 전해드립니다. Google Agentspace 검색은 모든 기업 지식 노동자에게 안전한 권한 인식 방식으로 모든 데이터에 대한 액세스를 통합하는 즉시 사용 가능한 기능을 제공합니다.

Agentspace를 통해 다음을 이용할 수 있습니다.

회사 브랜드의 멀티모달 검색 에이전트: 대화형 검색 인터페이스로, 회사의 고유한 정보에 기반해 복잡한 질문에 답변하고 전체 조직의 기업 지식에 대한 중앙 소스 역할을 합니다.
사전 빌드된 기업 데이터 커넥터: 가장 일반적인 온프렘 기업 시스템(예: Confluence, Jira, ServiceNow, Sharepoint) 데이터의 색인을 생성하는 커넥터입니다.
권한 인식 검색 결과: 검색 결과가 권한을 인식하도록 하여 모든 온프렘 데이터의 보안 및 규정 준수를 유지하는 데 도움이 되는 강력한 액세스 제어 목록(ACL)을 적용합니다.
Agentspace 에이전트: Vertex AI는 즉시 사용 가능하도록 Agentspace와 통합되어 있으며 검색 에이전트부터 시작하여 더 많은 사전 빌드된 에이전트가 출시될 예정이고 사용자가 직접 에이전트를 빌드할 수 있는 기능도 제공됩니다.

GDC 기반 생성형 AI 시작하기

Google은 선도적인 생성형 AI이자 어디서나 배포할 수 있는 최신 애플리케이션 개발 솔루션이 되도록 GDC를 끊임없이 혁신하고 있습니다. Gemini와 생성형 AI를 온프레미스에 도입하려면 Google Cloud 영업팀이나 공인 글로벌 파트너에 문의하세요.

머신러닝으로 더 빨라지는 5세대 분산 컴퓨팅 시대의 도래

Thu, 14 Mar 2024 01:00:00 +0000

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

Editor’s note: 오늘은 ML, 시스템, Cloud AI 부문 부사장 겸 총괄 책임자인 Google 펠로우 Amin Vahdat의 의견을 들어보겠습니다. Amin은 2023년 워싱턴 대학교 Allen School의 특강 시리즈를 위한 기조 연설로 처음 이 내용을 발표했습니다. 이 게시물에서는 분산 컴퓨팅의 역사와 현재 상황, 그리고 차세대 컴퓨팅 서비스에 대해 기대할 수 있는 부분에 대한 Amin의 생각을 살펴봅니다.

지난 50년에 걸쳐 컴퓨팅과 통신은 용량과 효율성, 기능 측면에서 기하급수적인 성장을 이어가며 사회의 혁신을 이끌었습니다. 이 기간 동안 기술 커뮤니티는 CPU당 트랜지스터의 수를 5,000만 배 늘렸고 인터넷 규모는 4노드에서 53억 9,000만 노드로 성장시켰습니다.

그 자체로도 놀라운 발전이지만, 이러한 발전의 결과로 얻게 된 인간의 능력은 더욱 경이로운 수준에 이르렀으며 그중에는 이전까지 공상과학 소설에나 나왔을 법한 능력도 있습니다. 계속 진화하는 인간의 지식에 이제 거의 즉각적으로 액세스할 수 있습니다. 우리가 이해할 수 있는지가 관건일 뿐 그 외에는 한계가 없습니다. 실시간 언어 번역을 통해 인간 의사소통의 근본적인 장벽을 허물고 있습니다. 감지 기술과 네트워크 속도가 이에 상응하는 수준으로 발전하면서 원거리에서도 의미 있는 상호작용을 지원하는 홀로그래픽 프로젝션 기술을 실시간으로 구현할 수 있게 되었습니다. 컴퓨팅 역량의 이 같은 폭발적인 발전은 당대의 가장 어려운 과학 및 엔지니어링 과제를 해결하고 있는 차세대 AI 시스템을 움직이는 근간이 되고 있기도 합니다. 이러한 시스템은 예를 들어 단백질의 3D 구조를 거의 즉각적으로, 원자 단위의 정확도로 예측하거나 첨단 텍스트 이미지 변환 (text-to-image diffusion)기술을 구현하여 사용자의 프롬프트에 맞는 실사 수준의 고품질 출력을 제공할 수 있습니다.

기반이 되는 기술 발전의 속도를 유지하는 일은 쉽지 않습니다. 우리는 10~15년마다 근본적인 과제에 직면하는데, 인프라 효율성과 규모의 기하급수적인 성장을 유지하고 이를 통해 완전히 새로운 범주의 서비스를 가동하기 위해서는 근원적인 발명과 혁신으로 이 과제를 해결해야 합니다. 마치 1,000개의 요소가 모두 갈수록 더 어려운, 극복해야 할 새로운 근본적인 한계를 드러내면서 혁신의 기회를 창출하는 것과 같습니다. 컴퓨팅에 대한 근본적인 수요가 끝없이 높아지고 있는 지금이 바로 그러한 분수령의 순간, 즉 한 세대에 한 번 있을까 말까 한 과제에 직면하는 순간이자 놀라운 발전 속도를 유지하고 가속할 수 있는 기회의 순간입니다.

컴퓨팅의 역사를 간단히 돌아보면 각각 컴퓨팅의 '세대'를 나름대로 정의할 수 있는 중대한 전환의 시기가 지금까지 4번 있었습니다. 이제 5세대 컴퓨팅을 정의하고 이끌어야 할 분명한 필요성을 지적하는 역사적 분류 체계가 있습니다. 5세대 컴퓨팅은 데이터 중심의, 선언적이고 결과 지향적인 소프트웨어 정의 컴퓨팅으로 사람들에게 선제적으로 인사이트를 제공하는 데 중점을 둡니다. 과거의 각 세대가 그 이전까지 상상할 수 없었던 일상을 만들었다면, 이번 5세대는 지식과 기회에 대한 접근을 범용화하는 가장 큰 변화를 가져올 것입니다. 그러나 이를 위해서는 여러 스택에 걸쳐 컴퓨팅에서 본질적으로 가장 어려운 몇 가지 과제를 극복해야 합니다.

먼저 0세대부터 돌아보겠습니다. 순수주의자들은 그보다 수천 년 더 과거까지 거슬러 올라가야 한다고 주장할 수 있고 그 말도 일리가 있지만, 이 글에서는 1947년부터 1969년 사이에 일어나 현대적인 컴퓨팅과 통신의 토대를 마련한 컴퓨터 과학의 획기적이고 근본적인 발전부터 시작해 보겠습니다.

1947년: 바딘, 브래튼, 쇼클리가 최초의 작동하는 트랜지스터를 발명함
1948년: 섀넌이 모든 네트워크 통신의 기반인 정보 이론을 발표함
1949년: 컴퓨터에 저장된 프로그램이 작동 가능해짐
1956년: 수준 높은 프로그래밍 언어가 발명됨
1964년: 다양한 하드웨어 세대에 걸쳐 공통된 명령 집합 아키텍처가 등장함
1965년: 무어의 법칙(집적 회로당 트랜지스터 수가 18~24개월마다 두 배로 증가한다는 법칙)이 발표됨
1967년: 멀티 사용자 운영체제에서 보호되는 리소스 공유 기능을 제공함
1969년: 현대 인터넷의 기반인 ARPANET이 등장함

0세대의 끝에서 이러한 혁신은 현대적 컴퓨팅의 기반을 마련했습니다. 즉, 안정적인 명령 집합 아키텍처를 실행하는 집적 회로 기반의 컴퓨터 4대, 그리고 패킷 교환식 인터넷에 연결된 멀티 사용자 시간 공유 운영체제입니다. 얼핏 대단치 않아 보이는 이 기준이 이후 이어지는 세대에서의 기하급수적인 발전을 위한 토대가 되었습니다.

1세대에서 컴퓨터 네트워크는 주로 비동기식으로 사용되었습니다. 네트워크를 통해(예를 들어 FTP를 통해) 데이터를 전송하고, 이 데이터로 작업을 수행한 다음, 결과를 돌려보내는 식이었습니다.

주요 발전 사항: SQL, FTP, 이메일, 텔넷(telnet)
컴퓨터 간 상호작용 시간: 100밀리초
특징:
• 대역폭은 낮고, 지연 시간은 높은 네트워크
• 고가의 컴퓨터 간에 쌍방 상호작용은 거의 없음
• 사람과의 문자 키 입력 상호작용
• 오픈소스 소프트웨어의 등장
혁신: 개인용 컴퓨터

2세대에 이르러서는 네트워크 속도의 향상, 개인용 컴퓨터/워크스테이션의 보편화, 광범위하고 상호 운용 가능한 프로토콜(IP, TCP, NFS, HTTP) 덕분에 동기식의 투명한 컴퓨팅과 통신이 널리 확산되었습니다.

주요 발전 사항: 리모트 프로시저 호출, 클라이언트/서버 컴퓨팅, LAN, 리더 선출 및 합의
컴퓨터 간 상호작용 시간: 10밀리초
특징:
• 10Mbps 네트워크
• TCP/IP 덕분에 인터넷 아키텍처가 전역적으로 확장
• 완전한 32비트 CPU가 단일 칩에 탑재
• 여러 컴퓨터 간의 공유 리소스
혁신: 월드 와이드 웹(WWW)

3세대에서는 HTTP와 WWW의 진정한 혁신이 네트워크 컴퓨팅의 대중화를 이끌면서 개인 컴퓨팅의 한계를 돌파했습니다. 인터넷의 지속적이고 기하급수적인 발전과 전 세계 사용자의 니즈에 발맞춰 나가는 과정에서 현대 컴퓨팅의 많은 설계 패턴이 이 시기에 확립되었습니다.

3세대를 이끈 동력 중 하나는 단일 CPU 코어의 최대 클록 주파수를 본질적으로 제한했던 데나드 스케일링의 종말이었습니다. 이러한 한계로 인해 업계에서는 멀티코어 아키텍처를 도입하게 되었고 비동기식, 멀티 스레드, 동시 실행 개발 환경으로 전환해야 했습니다.

주요 발전 사항: HTTP, 3계층 서비스, 대규모 클러스터, 웹 검색
컴퓨터 간 상호작용 시간: 1밀리초
특징:
• 100Mbps~1Gbs 네트워크
• 자율 시스템/BGP
• 복잡한 앱이 더 이상 단일 서버에 맞지 않아 다수의 서버로 확장
• 웹 색인 생성 및 검색, 인구 규모의 이메일
혁신: 클러스터 기반 인터넷 서비스, 모바일 우선 설계, 멀티스레딩, 명령어 수준 병렬 처리

4세대는 보편적인 이동통신 기기를 통해 수십억 명의 사람들이 사용할 수 있는 전 세계적 규모의 서비스를 구현했습니다. 이와 함께 머신러닝의 르네상스는 더 많은 실시간 제어와 인사이트를 이끌어냈습니다. 이 모든 것의 근간은 방대한 데이터 세트를 실시간으로 처리하는, 고속 네트워크로 상호 연결된 대규모 상용 컴퓨터 클러스터였습니다.

주요 발전 사항: 전역적인 모바일 데이터 범위, 전 세계적인 규모의 서비스, 동영상의 보편화
컴퓨터 간 상호작용 시간: 100마이크로초
특징:
• 10~100Gbps 네트워크, 플래시
• CPU 소켓당 여러 개의 코어
• 여러 LAN에 걸쳐 확장되는 인프라(예: GFS, MapReduce, Hadoop)
• 모바일 앱, 전역적인 모바일 데이터 범위
혁신: 주류 머신러닝, 특수한 컴퓨팅 하드웨어를 손쉽게 사용 가능, 클라우드 컴퓨팅

이제 5번째 세대로 전환했으며, 이 세대는 두 가지 상반된 추세의 중첩을 특징으로 합니다. 우선, ASIC당 트랜지스터 수는 계속해서 기하급수적인 속도로 증가하는 반면 클록 속도는 정체되어 있으며 각 트랜지스터의 비용도 거의 일정하게 유지되고 있습니다. 이 두 가지 모두 더 작은 피처 크기를 달성하기 위해 필요한 복잡성과 투자 비용의 증가로 인해 제약을 받고 있습니다. 이는 모든 컴퓨팅, DRAM, 스토리지, 네트워크 인프라의 비용 개선 또는 성능 효율로 정규화된 성능이 일정 수준에 머무르고 있음을 의미합니다. 이와 동시에 보편적인 네트워크 범위, 광범위하게 배포된 센서, 막대한 데이터가 필요한 머신러닝 애플리케이션으로 인해 원시 컴퓨팅 인프라에 대한 수요가 기하급수적으로 증가하고 있습니다.

주요 발전 사항: 머신러닝, 생성형 AI, 개인 정보 보호, 지속 가능성, 사회적 인프라
컴퓨터 간 상호작용 시간: 10마이크로초
특징:
• 200Gbps~1+Tb/s 네트워크• 전력 효율적인 고속 무선 네트워크를 어디서나 사용 가능
• 갈수록 전문화되는 가속기: TPU, GPU, 스마트 NIC
• 소켓 수준의 패브릭, 광학 기술, 연합형 아키텍처
• 연결된 공간, 차량, 어플라이언스, 웨어러블 등
혁신: 수많은 혁신이 예상됨

컴퓨팅 설계 및 조직에 대한 근본적인 혁신이 없다면 컴퓨팅 인프라에 대한 사회적 수요를 충족하는 기술 커뮤니티의 능력은 흔들리게 될 것입니다. 이러한 한계를 극복하기 위한 새로운 아키텍처와 함께 새로운 하드웨어, 그리고 갈수록 비중이 커지는 소프트웨어 아키텍처가 컴퓨팅의 5번째 세대를 정의하게 될 것입니다.

이 5번째 컴퓨팅 세대에 어떤 혁신이 이루어질지 예측할 수는 없지만 이전의 각 세대에 걸쳐 보안과 안정성을 개선하면서 규모와 효율성, 가격 대비 성능이 100배 이상 향상되었다는 점은 분명합니다. 규모와 용량에 대한 수요가 계속해서 증가하고 있기 때문에 무어의 법칙과 데나드 스케일링이라는 순풍이 없다면 이러한 성과를 달성하기는 어려울 것입니다. 다만 다음과 같은 폭넓은 움직임이 나타날 것으로 예상됩니다.

선언적 프로그래밍 모델: 전용 프로세서에서 순차적으로 코드를 실행하는 폰 노이만 모델은 수십년 동안 개발자들에게 매우 유용했습니다. 그러나 분산 및 멀티 스레드 컴퓨팅의 부상으로 추상화가 깨지면서 현대의 명령형 코드 대부분은 비동기성, 이기종성, 꼬리 지연 시간, 낙관적 동시 실행, 장애를 관리하기 위해 방어적이고 종종 비효율적인 구조에 집중하게 되었습니다. 앞으로도 복잡성은 계속 증가할 것이므로 의도, 사용자, 비즈니스 로직에 집중하는 새로운 선언적 프로그래밍 모델이 필요합니다. 이와 동시에, 실행 흐름을 관리하고 변화하는 배포 조건에 대응하는 작업은 갈수록 정교해지는 컴파일러와 ML 기반 런타임에 위임해야 합니다.
하드웨어 세분화: 이전 세대에서는 CPU, 메모리, 스토리지, 네트워킹이 균형을 이룬 시스템을 사용한 범용 서버 아키텍처가 데이터 센터 전반의 워크로드 니즈를 효율적으로 충족할 수 있었습니다. 그러나 전문적인 컴퓨팅 니즈와 ML 학습, 추론, 동영상 처리에 맞게 설계하는 경우 스토리지, 메모리 용량, 지연 시간, 대역폭, 통신을 위한 요구사항이 상충하게 되고 이로 인해 이기종 설계가 급격히 확산됩니다. 범용 컴퓨팅 성능이 매년 1.5배씩 개선되었을 때는 워크로드의 10%에 대해 5배의 개선을 추구한다는 것은 복잡성을 감안할 때 타당하지 않았습니다. 그러나 지금은 이러한 개선을 더 이상 무시할 수 없습니다. 이 간극을 해소하기 위해서는 구성 가능한 하드웨어 ASIC 및 메모리 유닛을 몇 년이 아닌 몇 개월 내에 설계, 확인, 검증, 배포하기 위한 새로운 접근 방법이 필요합니다.
소프트웨어 정의 인프라: 기반 인프라가 더 복잡해지고 더 분산되면서 메모리부터 CPU에 이르기까지 여러 가상화 계층이 개별 애플리케이션에 대해 단일 서버 추상화를 유지해 왔습니다. 인프라가 계속해서 수평 확장되고 더욱 이기종화됨에 따라 이러한 추세는 향후 세대에도 계속될 것입니다. 하드웨어 세분화, 선언적 프로그래밍 모델, 수천 개의 서버로 구성된 분산 컴퓨팅 환경의 필연적인 결과로 가상화는 개별 서버의 한계를 넘어 단일 서버, 여러 서버, 스토리지/메모리 배열, 클러스터에서 분산 컴퓨팅을 포함하도록 확장되며, 때에 따라서는 최종 결과를 효율적으로 제공하기 위해 캠퍼스 전체의 리소스를 한데 모으게 될 것입니다.
검증 가능한 보안 컴퓨팅: 지난 세대에서는 컴퓨팅을 효율적으로 유지해야 할 필요성으로 인해 의도하지 않게 보안과 안정성을 희생시켰습니다. 그러나 사람들의 일상이 갈수록 온라인으로 옮겨가면서 개인과 기업, 정부를 불문하고 개인 정보 보호와 기밀 유지에 대한 필요성도 급격히 증가하고 있습니다. 정부 정책을 준수하기 위해서뿐만 아니라 갈수록 증가하는 ML 생성 콘텐츠의 계보를 투명하게 공개하기 위해서도 데이터 주권, 즉 데이터(파생된 데이터까지)의 물리적인 위치를 제한해야 할 필요성이 점점 더 높아질 것입니다. 기본 성능에 얼마간의 희생이 따르더라도 이를 가장 중요한 요구사항이자 제약조건으로 여겨야 합니다.
지속 가능성: 컴퓨팅의 처음 3개 세대에서는 고정 전력 대비 기하급수적인 성능 개선이 이루어졌습니다. 4세대에 이르러 데나드 스케일링이 끝나면서 컴퓨팅과 관련된 전 세계 전력 소비량이 빠르게 증가했고, 이러한 증가분의 일부는 이전의 온프레미스 설계에 비해 전력 효율성이 2~3배 더 높은 클라우드 호스팅 인프라로의 전환을 통해 상쇄되었습니다. 또한 클라우드 제공업체들은 탄소 중립을 먼저 달성한 다음 무탄소 전원으로 전환하기 위한 광범위한 작업에 착수했습니다. 그러나 5세대에서는 데이터와 컴퓨팅에 대한 수요가 계속 증가할 것이며, 그 속도도 더 빨라질 가능성이 높습니다. 따라서 전력 효율성과 탄소 배출이 가장 중요한 시스템 평가 측정항목이 될 것입니다. 특히 인프라 구축과 제공의 수명 주기 전체에 걸친 내재 탄소에 대해 더 나은 가시성과 최적화가 필요하게 됩니다.
알고리즘 혁신: 기하급수적인 성능 향상이라는 순풍으로 인해 이제까지 소프트웨어의 효율성 개선이 무시되는 경우가 많았습니다. 기반 하드웨어 구성요소의 개선 속도가 느려지면서 앞으로는 소프트웨어와 알고리즘 기회로 초점이 옮겨갈 것입니다. 연구에 따르면 시스템 코드에는 소프트웨어 최적화를 2~10배 개선할 기회가 많다고 합니다. 이와 같은 소프트웨어 최적화 기회를 효율적으로 파악하고, 그에 따른 혜택을 프로덕션 시스템에 대규모로 원활하게 안정적으로 전달하기 위한 기법을 개발하는 일이 중요한 기회가 될 것입니다. 최근 코딩 LLM의 혁신을 활용하여 이 작업을 부분적으로 자동화하면 5세대의 큰 촉진제가 될 것입니다.

결국 5세대에서 가장 중요한 것은 MIPS당 비용, DRAM GB당 비용, Gb/s당 비용 등 낮은 수준의 구성요소별 측정값보다는 전체적인 사용자-시스템 효율성(초당 유용한 응답 수)이 될 것입니다. 또한 효율성 단위도 단순히 단위 비용당 성능으로 측정되는 것이 아니라 전력 소비와 탄소 배출을 명시적으로 반영하고 보안과 개인 정보 보호를 주 측정항목으로 사용하면서 사회의 의존도가 갈수록 높아지는 인프라에 대한 신뢰성 요구사항을 반영하게 될 것입니다. 종합적으로 보면 차세대 인프라를 제공하기 위한 아직 활용되지 않은 기회가 많이 있습니다.

하드웨어와 소프트웨어 전반에 분산 인프라의 수평 확장 효율성을 10배 이상 높일 수 있는 기회
소프트웨어 정의 인프라를 통해 애플리케이션 균형점, 즉 컴퓨팅, 가속기, 메모리, 스토리지, 네트워크와 같은 다양한 시스템 리소스 간의 비율을 맞추는 데 있어 또 다른 10배의 기회
기존의 획일적인 범용 컴퓨팅 아키텍처 대비 차세대 가속기 및 세그먼트별 하드웨어 구성요소에서 10배 이상의 기회
마지막으로, 정량화하기 어렵지만 개발자 생산성을 향상시키는 동시에 대폭 개선된 안정성과 보안을 제공하기 위한 절대적으로 중요한 기회

이러한 추세를 종합해 보면 지금은 차세대 인프라 서비스를 정의하고 차세대 컴퓨팅 서비스를 실현할 또 다른 극적인 1,000배의 효율성 향상을 목전에 둔 시점입니다. 그리고 이것은 아마도 멀티모달 모델과 생성형 AI의 혁신을 중심으로 이루어질 가능성이 높습니다. 차세대 컴퓨팅의 의미를 정의, 설계, 배포할 기회는 자주 오지 않습니다. 이 5번째 세대의 구조적 변화는 아마도 역사상 가장 큰 기술적 변화와 과제를 수반할 것입니다. 이에 대응하기 위해서는 컴퓨팅의 초창기 시절부터 지금까지는 볼 수 없었던 수준의 책임감과 협업, 비전이 필요할 것입니다.

소매업과 제조업을 위한 Google Distributed Cloud 소개

Mon, 11 Mar 2024 01:00:00 +0000

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

소매업이나 제조업 분야의 고객들은 POS 시스템, 공장 운영과 같은 애플리케이션의 기존 온프레미스 개발 프로세스를 개선하는 동시에 자동 주문 접수, AI 기반 비전 검사, 무인 계산대 등 새롭고도 풍부한 경험을 구축할 방법을 모색하고 있습니다. 그러나 수십, 수천 개의 리전에서 실행되는 애플리케이션의 상태를 유지하면서 최신 워크로드를 빌드, 배포, 관리하기란 쉽지 않은 일입니다.

오늘 소매점, 레스토랑, 제조 시설에 도입할 수 있도록 최적화된 새로운 구성의 Google Distributed Cloud Edge인 Google Distributed Cloud Edge 서버가 정식 버전으로 출시된다는 소식을 전해드리게 되어 기쁩니다. 한 리전의 네트워크 장비에 직접 연결하는 3개의 소형 폼 팩터 서버로 구성된 Google Distributed Cloud Edge 서버를 사용하면 가용성이 높은 완전 관리형 Google Kubernetes Engine 클러스터를 고객이 수십, 수천 개의 리전은 물론 때에 따라서는 제한적이거나 간헐적인 인터넷 액세스 환경에도 쉽게 배포할 수 있습니다. 이를 통해 AI 비전 검사와 같은 AI 지원 응용 사례를 포함해 비즈니스에 중요한 로컬 운영 지원 애플리케이션을 확장 가능한 방식으로 관리할 수 있습니다.

애플리케이션은 소매업 고객에게 양질의 경험을 제공하고 제조 라인을 계속 가동하는 데 매우 중요합니다. 하지만 여러 개의 제조 공장이나 수천 개의 소매점을 운영하는 기업에서는 이러한 애플리케이션을 대규모로 배포하고 관리하며 고가용성을 보장하는 데 어려움을 겪고 있습니다. 일부 고객은 애플리케이션을 클라우드에서 중앙 집중화하여 관리를 최적화하고 있습니다. 그러나 대역폭이 제한되거나 연결이 간헐적일 때는 애플리케이션 속도가 저하되거나 운영 중단이 발생할 수 있습니다. 서버를 로컬에 배포하는 고객 역시 각 리전을 개별적으로 관리해야 하기 때문에 결국 높은 운영 비용으로 어려움을 겪게 됩니다. 또한 서버가 주요 장애 원인일 때가 많으며 배포 도구가 충분하지 않을 경우 애플리케이션 수정 사항을 모든 리전에 배포하는 데 몇 주에서 몇 달이 걸릴 수 있기 때문에 운영 위험도 커집니다. 마지막으로 새로운 AI 기반 애플리케이션을 추가하면 이러한 애플리케이션에서 추가 컴퓨팅 및 그래픽 기능을 갖춘 신규 서버를 필요로 하기 때문에 플랫폼 확장도 어렵습니다. 도입 결정 시 주요 고려 사항 등에 관한 자세한 내용은 제조업 또는 소매업 IT 리더들을 위한 고객 인사이트 보고서에서 확인할 수 있습니다.

클라우드에서 앱 빌드, 온프레미스에서 배포 및 확장하기

Google Distributed Cloud Edge 서버를 사용하는 고객은 대규모로 애플리케이션을 관리할 수 있는 Google Cloud의 동급 최고 도구를 사용하여 완전 관리형 최신 애플리케이션 플랫폼을 자사의 리전에 배포할 수 있습니다. Google Distributed Cloud Edge 서버는 비즈니스에 중요한 애플리케이션을 로컬에서 실행하도록 설계 및 최적화되어 인터넷 연결이 제한적이거나 간헐적일 때도 운영을 계속할 수 있습니다. 또한 Google Distributed Cloud Edge 서버는 완전 관리형으로서 업계 최고 수준의 Google 자동화와 사이트 안정성 엔지니어링(SRE) 관행을 활용하여 규모와 관계없이 운영 비용을 낮게 유지할 수 있으며, 중복화 기능이 내장되어 있으므로 서버 장애가 발생하더라도 중단 없이 운영을 계속할 수 있습니다. Google Distributed Cloud Edge 서버에는 Google Kubernetes Engine(GKE)은 물론, 고객이 새 애플리케이션과 기존 애플리케이션의 업데이트를 모든 리전에 신속하게 안정적으로 배포할 수 있는 애플리케이션 조정 도구 모음이 기본으로 포함되어 있습니다. 이러한 기능을 통해 고객은 애플리케이션을 클라우드에서 중앙 집중화하는 동시에 로컬에서 애플리케이션을 실행하여 얻는 지연 시간 및 연결상의 이점을 누릴 수 있습니다. 마지막으로 Google Distributed Cloud Edge 서버는 선택 사항인 GPU로 VM과 컨테이너를 모두 지원하므로 고객은 단일 플랫폼에서 기존 및 신규 AI 기반 애플리케이션을 모두 실행할 수 있기 때문에 무분별한 확장이 줄어듭니다. 에지 컴퓨팅이 소매업체에 제공하는 기회와 사용 사례에 대한 자세한 내용은 이 블로그에서 확인할 수 있습니다.

Google Distributed Cloud Edge 서버 구성

견고한 에지 랙 서버

크기(너비x높이x깊이 - 인치): 17 x 1.7(1RU) x 19
온도: -5°C~55°C
음향: 38dBA(일반), 58dBA(최대)

적정 규모의 구성

16c/32vCPU, 64GB RAM, 사용자 디스크 1.6TB
32c/64vCPU, 128GB RAM, 사용자 디스크 3.2TB

“클라우드 컴퓨팅은 다양한 산업 분야에 걸쳐 고객에게 전례 없는 확장성, 직관성, 유연성을 제공하고 있지만 각 리전에서 애플리케이션을 실행해야 할 필요성 때문에 로컬 애플리케이션에 구현되는 데 한계가 있었습니다.”라고 Google Distributed Cloud 엔지니어링 부문 부사장 안쿠르 자인은 말했습니다. “Google Distributed Cloud Edge 서버는 클라우드의 확장성과 유연성을 로컬 처리의 가용성과 결합해 이 둘의 장점을 모두 갖춘 제품입니다.”

클라우드에서 에지에 이르는 소매업 및 제조업 지원

소매점, 레스토랑, 제조 현장에 가까이 배치된 Google Distributed Cloud Edge 서버는 소매업 또는 제조업 IT 의사 결정권자에게 다음과 같은 몇 가지 도움을 줄 수 있습니다.

온프레미스에서 클라우드가 지원되는 최신 인프라로 확장하기 - 클라우드에서 최신 클라우드 기반 애플리케이션을 빌드하여 단일 소매점 또는 창고에서 수천 개의 리전으로 배포 및 확장할 수 있습니다.
운영 비용 절감하기 - Google의 완전 관리형 하드웨어 및 소프트웨어를 사용하여 IT 비용 및 리소스 지출을 개선하고 최적화할 수 있습니다.

지금 바로 시작하려면 Google Cloud에서 직접 하나 이상의 Google Distributed Cloud Edge 서버를 구매하시면 됩니다. 교육을 받은 기술자가 현장에서 초기 설치를 수행하면 이후 Google Cloud에서 소프트웨어 업데이트 설치, 구성 최적화, 하드웨어 모니터링 등 전체 플랫폼을 완벽하게 관리해 드립니다. 개발자는 GKE 구성 동기화와 같이 대규모 클라우드 환경을 관리할 때 사용하는 동일한 Google Cloud 도구를 사용하여 단일 리전, 지역 전체 또는 전 세계에서 제어된 방식으로 컨테이너 또는 VM을 대규모로 시작하고 업데이트할 수 있습니다. 하드웨어에 장애가 발생하면 Google에서 자동으로 기술자를 파견하여 서버를 교체하는 동안에도 시스템은 계속 작동합니다.

Google Distributed Cloud Edge 구성 가격 정책에 관한 자세한 내용은 여기에서 확인할 수 있습니다.

IDC: Google Cloud IaaS 마이그레이션을 통한 ROI 318% 달성의 가능성

Tue, 05 Mar 2024 01:00:00 +0000

전 세계 많은 조직이 지속적인 디지털 혁신을 실현하고 지원하기 위해 계속해서 클라우드 서비스를 도입하고 있습니다. 비용 절감, 민첩성, 탄력성, 확장성을 비롯한 클라우드 인프라의 장점이 널리 알려져 있긴 하지만, 이러한 장점을 수치화하기란 쉽지 않은 일입니다.

Google은 클라우드 인프라로 마이그레이션하는 것의 실질적인 ROI를 더 자세히 파악하기 위해 이와 관련된 IDC 연구 조사를 의뢰했으며 2023년 말에 그 결과를 발표했습니다. 이 연구는 독일, 미국, 영국의 금융 서비스, 정부 기관, 의료, 부동산, 소매, 공공 산업에 속한 조직을 대상으로 진행한 9개의 인터뷰로 구성되어 있습니다. 인터뷰는 Google Cloud Infrastructure as a Service(IaaS)를 채택했으며 그 이점과 비용을 직접 경험한 조직을 선정하여 진행했습니다.

IDC: Extracting more business value from cloud infrastructure

Google Cloud IaaS의 비즈니스 가치에 대해 Google이 의뢰하여 진행한 IDC 연구팀의 조사 결과1를 간단하게 살펴보면 다음과 같습니다.

5년간 ROI 318% 달성
5년간 운영 비용 51% 절감
IT 인프라 관리팀 효율성 57% 향상
75% 더 빠른 새로운 애플리케이션 기능 배포
323만 달러의 추가 수익 창출

IDC 연구 결과를 자세히 살펴보고 조직이 Google Cloud IaaS 도입을 통해 누릴 수 있는 이점을 알아보고 싶으신가요?

IDC 연구 조사 보고서 전문을 다운로드하세요.
IDC 리서치 부사장인 Dave McCarthy와 Google 북미 개발자 지원 Lead이자 베스트셀러 작가인 Priyanka Vergadia가 연구 결과에 대해 심도 있게 논의하는 Firechat에 참여해 보세요.

___

^{1 출처: IDC Business Value Research, Google 후원, The Business Value of Google Cloud IaaS, IDC #US51037323, 2023년 8월.}

^{기업통계 참고:
- 직원 수: 1,500~300,000명
- IT 직원 수: 300~2,000명
- 비즈니스 애플리케이션 수: 20~6,000개
- 수익: 1억 2,630만~590억 달러}

퍼블릭 Docker Hub 콘텐츠 사용 관련 권장사항

Wed, 24 Jan 2024 01:00:00 +0000

최신 개발 환경에서 오픈소스 소프트웨어가 확산됨에 따라 사용자 환경에는 Docker Hub에 저장된 퍼블릭 컨테이너 이미지에 대한 종속 항목이 있을 수 있습니다. 이러한 종속 항목은 적절한 구성과 제어가 없을 경우 CI/CD 파이프라인 내에서 보안 및 안정성에 위험을 초래할 수 있습니다. 이 블로그에서는 이러한 위험을 줄이기 위해 팀에서 따를 수 있는 몇 가지 권장사항을 개략적으로 소개합니다.

퍼블릭 컨테이너의 로컬 사본 저장

가능한 경우 퍼블릭 컨테이너의 로컬 사본을 저장하면 최고의 안정성을 확보하고 더욱 강력한 보안 제어를 실현할 수 있습니다. 자세한 내용은 Open Containers Initiative에서 게시한 퍼블릭 콘텐츠 사용 관련 지침을 참조하세요.

인증을 사용하여 Docker Hub에 액세스

Docker Hub에 액세스할 때는 익명으로 하지 말고 인증된 방식으로 액세스하시기 바랍니다. 익명으로 요청하면 보안 위험 외에도 rate limit에 도달할 위험이 있고, 이는 CI/CD 파이프라인의 안정성에 영향을 줄 수 있습니다. 인증에는 CI/CD 인프라 아키텍처 및 사용하는 Google Cloud 서비스에 따라 몇 가지 옵션이 있습니다.

Artifact Registry 원격 저장소 사용: 빌드 프로세스 내에서 Docker Hub 저장소를 직접 참조하는 대신 Artifact Registry 원격 저장소를 사용하여 Docker Hub로 인증하고 종속 항목의 리전별 캐시를 제공할 수 있습니다. Artifact Registry로 Docker Hub 액세스 토큰을 사용하는 방법에 대한 안내 전문은 Artifact Registry 문서 페이지인 Docker Hub에 대한 원격 저장소 인증 구성에서 확인하세요.

Cloud Build를 사용하여 Docker 이미지와 상호작용: Cloud Build는 빌드 단계 내에서 Docker Hub 이미지를 가져오기 위한 인증 메커니즘을 제공합니다. Docker Hub 이미지를 사용하여 컨테이너 이미지를 빌드하는 경우 이러한 인증 메커니즘을 사용할 수 있습니다.

다음 Cloud Build 구성 파일은 Secret Manager에 저장된 Docker 사용자 이름과 비밀번호로 Docker에 로그인하고 비공개 이미지를 실행하는 방법을 보여줍니다. Cloud Build를 사용하여 Docker Hub와 상호작용하는 방법에 관한 자세한 내용은 Docker Hub 이미지와 상호작용을 참조하세요.

code_block: <ListValue: [StructValue([('code', 'steps:\r\n - name: \'gcr.io/cloud-builders/docker\'\r\n entrypoint: \'bash\'\r\n args: [\'-c\', \'docker login --username=$$USERNAME --password=$$PASSWORD\']\r\n secretEnv: [\'USERNAME\', \'PASSWORD\']\r\n - name: "gcr.io/cloud-builders/docker"\r\n entrypoint: \'bash\'\r\n args: [\'-c\', \'docker run $$USERNAME/REPOSITORY:TAG\']\r\n secretEnv: [\'USERNAME\']\r\n availableSecrets:\r\n secretManager:\r\n - versionName: projects/PROJECT_ID/secrets/DOCKER_PASSWORD_SECRET_NAME/versions/DOCKER_PASSWORD_SECRET_VERSION\r\n env: \'PASSWORD\'\r\n - versionName: projects/PROJECT_ID/secrets/DOCKER_USERNAME_SECRET_NAME/versions/DOCKER_USERNAME_SECRET_VERSION\r\n env: \'USERNAME\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa3a4304c70>)])]>

위에 개략적으로 설명된 권장사항을 따르면 보안 상황을 개선하고 CI/CD 파이프라인 내 안정성 관련 위험을 줄일 수 있습니다. 또한 사용자 환경에 적합한 인증 제어를 구현하여 추후 프로덕션 단계에서 개발을 방해하는 요소를 제거하고 프로세스에서 기업 보안 표준을 충족하거나 초과 달성할 수 있습니다.

다음과 같은 관련 제품 페이지 및 기능도 유용할 수 있습니다.

Vertex AI기반 생성형 AI 비공개 액세스

Wed, 27 Dec 2023 01:00:00 +0000

Vertex AI는 ML 모델과 AI 애플리케이션을 학습 및 배포하고 AI 기반 애플리케이션에서 사용할 대규모 언어 모델(LLM)을 맞춤설정할 수 있게 해주는 Google Cloud의 머신러닝(ML) 플랫폼입니다. Vertex AI는 데이터 엔지니어링, 데이터 과학, ML 엔지니어링 워크플로를 결합하여 팀이 공동작업을 수행하고 Google Cloud의 이점을 활용하여 애플리케이션을 확장할 수 있도록 지원합니다.

Vertex AI는 모델 학습 및 배포를 위한 여러 옵션을 제공합니다. 그중 Vertex AI기반 생성형 AI는 여러 모달(텍스트, 코드, 이미지, 음성)에 대한 Google의 대규모 생성형 AI 모델에 대한 액세스를 제공합니다. 필요에 맞게 Google의 LLM을 조정한 후 AI 기반 애플리케이션에서 사용하도록 배포할 수 있습니다.

본 블로그 문서에서는 멀티 클라우드 및 온프레미스 환경에서 비공개 연결을 통해 Vertex AI기반 생성형 AI에 액세스하는 방법에 대해 살펴봅니다.

Vertex AI 생성형 AI 비공개 액세스 옵션

Vertex AI는 Vertex AI 엔드포인트 및 서비스에 대한 엔터프라이즈 네트워킹 옵션을 지원합니다.

온프레미스 또는 멀티 클라우드 환경에서 Vertex AI 리소스에 안전하게 액세스합니다.
Vertex AI 아티팩트가 유출되지 않도록 보호합니다.
Vertex AI 리소스의 네트워크 트래픽을 구성합니다.

온프레미스 호스트는 Google이 제공하는 다양한 API 서비스에 대해서 (Option 1)퍼블릭 인터넷으로 연결하거나 Cloud VPN이나 Cloud Interconnect를 통하여 (Option 2)비공개(Private) 엔드포인트 연결로 액세스할 수 있습니다. 두가지 옵션 모두 SSL/TLS 암호화를 제공합니다. 다만, Cloud Interconnect 서비스와 같은 네트워크 연결 옵션을 사용하여 비공개 옵션을 구성할 경우 뛰어난 안정성과 일관된 성능 그리고 비용효율적인 구성을 제공하므로 중요한 애플리케이션에는 비공개 옵션이 권장됩니다.

그림 1. Vertex AI 네트워크 옵션 구성

Vertex AI는 외부 공인 IP 주소 없이 Vertex AI 생성형 AI 엔드포인트 및 서비스에 비공개로 액세스하는 다음과 같은 추가 옵션을 지원합니다.

Google API용 Private Service Connect 엔드포인트를 사용하면 Google Cloud 리소스 또는 온프레미스 시스템이 VPC 네트워크의 엔드포인트에 연결하여 Google API 및 서비스로 요청을 전달할 수 있습니다.
비공개 Google 액세스(Private Google Access):
- Google Cloud 리소스가 VPC 네트워크의 기본 인터넷 게이트웨이를 통해 Google API 및 서비스의 표준 외부 IP 주소 또는 비공개 Google 액세스 도메인 및 VIP에 연결하도록 허용합니다.
- 온프레미스 호스트가 비공개 Google 액세스 전용 도메인 및 VIP 중 하나를 사용하여 Cloud VPN 터널 또는 VLAN 연결을 통해 Google API 및 서비스에 연결하도록 합니다.

Google API용 Private Service Connect를 사용하면 VPC 네트워크 내에서 내부 IP 주소를 사용하여 비공개 엔드포인트를 만들 수 있습니다.

기본적으로 Vertex AI 생성형 AI서비스는 기본 DNS 이름(예: asia-northeast3-aiplatform.googleapis.com)을 통해 연결됩니다. Google 서비스의 기본 DNS 이름은 공개적으로 라우팅 가능한 퍼블릭 IP 주소로 확인됩니다.

Private Service Connect를 활용하게 되면 asia-northeast3-gen-ai.p.googleapis.com와 같이 의미 있는 이름을 사용하여 DNS 이름을 이러한 내부 IP 주소에 할당할 수 있습니다. 이러한 이름과 IP 주소는 VPC 네트워크 및 Cloud VPN 터널이나 VLAN 연결을 통해 연결된 온프레미스 네트워크의 내부 이름과 IP 주소입니다. 엔드포인트로 전송되는 트래픽을 비공개로 제어하고 트래픽이 Google Cloud 내로 유지됨을 보여줄 수 있습니다.

VPC 서비스 제어를 사용하는 Vertex AI 생성형AI

Vertex AI 생성형AI의 API는 기본적으로 인터넷에 공개된 엔드포인트이므로 비공개 연결 경로만 허용하고자 한다면, VPC 서비스 제어(VPC-SC)를 활용하여 허용되지 않은 액세스를 제한해야 합니다. VPC 서비스 제어는 Vertex AI에서 데이터 무단 반출 위험을 완화하는 데 도움을 줍니다. VPC 서비스 제어를 사용하여 지정한 리소스 및 데이터를 보호하는 서비스 경계(Service Perimeter)를 만듭니다.

Vertex AI 생성형 AI에서 비공개 연결을 안전하게 구성하기 위해 VPC 서비스 제어를 사용할 수 있습니다.

서비스 경계 구성으로 Google Cloud Vertex AI 생성형 AI 리소스와 네트워크 격리
승인된 VPN 또는 Cloud Interconnect를 이용해서 온프레미스 네트워크로 경계 확장
인터넷에서 Google Cloud 리소스 액세스 제어

그림 2. Vertex AI 네트워크 옵션과 VPC 서비스 제어 구성

앞서 살펴봤던 <그림 1>의 비공개 연결 구성에서 VPC 서비스 제어 기능을 추가하여 <그림 2>의 구성을 가지게 되었습니다. VPC 서비스 제어를 구성했을 때, 인터넷에서 서비스 경계 내에 있는 관리형 리소스에 액세스하는 것은 기본적으로 거부됩니다. 필요한 경우 요청의 컨텍스트에 따라 액세스를 사용 설정할 수 있습니다. 이렇게 하려면 소스 IP 주소, ID, 소스 Google Cloud 프로젝트와 같은 다양한 속성을 기반으로 액세스를 허용하는 인그레스 규칙 또는 액세스 레벨을 만들면 됩니다. 인터넷에서 실행된 요청이 인그레스 규칙 또는 액세스 레벨에 정의된 기준을 충족하지 못하면 해당 요청이 거부됩니다.

비공개 엔드포인트를 통한 접근 경로의 경우 VPN 또는 Interconnect로 경계확장을 구성하여 온프레미스 또는 타 Cloud 워크로드가 서비스 경계 내에 위치해 있다면 해당 비공개 네트워크에서의 요청은 허용됩니다.

마치며

기업용으로 사용되는 생성형 AI 서비스는 매우 민감한 정보를 보호하기 위해 신뢰할 수 있는 네트워크에서만 리소스에 액세스할 수 있도록 조치해야 할 수 있습니다. Google Cloud는 Vertex AI 생성형 AI에 대해 비공개 네트워크 액세스 구성 그리고 VPC 서비스 제어를 이용해, 안전하면서도 뛰어난 성능의 엔터프라이즈 네트워킹 옵션을 제공합니다.

추가자료

생성형 AI을 위한 보안 제어 | Vertex AI | Google Cloud

튜토리얼:Private Service Connect를 사용하여 온프레미스에서 Vertex AI기반 생성형 AI에 액세스 | Google Cloud

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 Cloud로 데이터 디스크를 제대로 그리고 쉽게 마이그레이션하는 방법

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

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

데이터 디스크 마이그레이션은 한 스토리지 기기에서 다른 스토리지 기기로 데이터를 전송하는 프로세스입니다. 실제 기기나 가상 머신 간에 데이터를 이동하거나 온프레미스 솔루션에서 클라우드 기반 플랫폼으로 전환하는 작업도 여기에 포함될 수 있습니다. 데이터 디스크 마이그레이션의 궁극적인 목표는 데이터 무결성, 보안 또는 접근성의 저하 없이 원활하게 전환하는 것입니다. 이 블로그 게시물에서는 Google Cloud 마이그레이션 센터에 내장된 Migrate to Virtual Machines를 사용해 쉽고 빠르게 데이터 디스크를 Google Cloud로 마이그레이션하는 방법을 설명합니다.

데이터 디스크 마이그레이션이 중요한 이유

최신 OS로 업그레이드: 지원되지 않는 운영체제는 공식 업데이트, 보안 패치, 기술 지원이 더이상 제공되지 않기 때문에 심각한 위협이 됩니다. 이로 인해 시스템이 사이버 위협, 호환성 문제, 규정 미준수에 취약해지며, 혁신이 저해되고 기능이 저하됩니다.
디스크 마이그레이션에는 지원되지 않는 오래된 운영체제에서 지원되는 최신 운영체제로 데이터를 전송하는 작업이 포함됩니다.
현대화: 기술이 발전하면서 오래된 스토리지 기기에서 병목 현상이 발생해 성능과 용량이 제한될 수 있습니다. 데이터 디스크 마이그레이션으로 보다 효율적인 최신 하드웨어를 활용할 수 있습니다.
데이터 보호: 오래된 스토리지 기기는 장애 및 데이터 손실에 더 취약합니다. 데이터를 최신 플랫폼으로 마이그레이션하면 이러한 위험을 완화하고 안전을 보장하는 데 도움이 됩니다.
성능 향상: 최신 스토리지 기술은 대체로 개선된 읽기 및 쓰기 속도를 제공하므로 시스템 성능이 향상되고 애플리케이션 액세스 시간이 단축됩니다.
확장성: 데이터 디스크 마이그레이션을 통해 스토리지 인프라를 용이하게 확장할 수 있습니다. 따라서 효율성 저하 없이 데이터 수요 증가에 대응할 수 있습니다.

Google Cloud 디스크 마이그레이션

Google Cloud에서는 마이그레이션 센터에 직접 Migrate to Virtual Machines를 통합하여 디스크 마이그레이션의 부담을 줄여 드립니다. 디스크 마이그레이션을 위한 이 강력하고도 효과적인 솔루션은 클라우드 마이그레이션 기술을 활용하여 클라우드 환경과의 호환성에 관계없이 OS 디스크 또는 데이터 디스크를 원활하게 마이그레이션해 줍니다. 운영체제 업데이트나 하드웨어 업그레이드와 같은 과제에 직면했을 때 적용할 수 있는 최상의 솔루션입니다.

유연성과 개방성을 위한 Google Cloud의 지속적인 노력이 반영된 Migrate to Virtual Machines는 VMware 및 기타 클라우드 서비스 제공업체들을 포함한 늘어나는 마이그레이션 소스들과 연결합니다. 예를 들어 기존 Linux 배포판이나 이전 Windows 버전(W2003, W2008, W2012)에서 실행되는 광범위한 가상 머신을 관리한다고 생각해 보세요. 바로 이런 경우에 Migrate to Virtual Machines의 디스크 마이그레이션 기능이 지닌 강점이 발휘됩니다. 소스 워크로드 디스크를 선택적으로 마이그레이션한 후 지원되는 운영체제에 연결하여 워크로드 인프라를 효과적으로 현대화할 수 있습니다.

작동 방식

디스크 마이그레이션 프로세스의 단계는 다음과 같습니다.

먼저 디스크를 마이그레이션할 VM을 온보딩해야 합니다.

다음 예시는 로컬 VMware 데이터 센터에서 호스팅되는 VM입니다. 이 VM을 선택해 GCP 마이그레이션 서비스에 온보딩합니다.

그런 다음 복제를 시작할 수 있습니다.

VM이 마이그레이션 서비스에 온보딩되는 즉시 소스 VM의 디스크에서 Google Cloud에 있는 Persistent Disk 볼륨으로 데이터 복제를 시작할 수 있습니다. 데이터 복제는 최종 컷오버(cutover)를 수행하거나 마이그레이션을 삭제할 때까지 백그라운드에서 계속 진행되는 프로세스입니다.

Monitoring도 활용할 수 있습니다.

VM을 클릭해 디스크 복제 상태, 예상 완료 시간, 기타 디스크 마이그레이션 관련 세부정보를 확인할 수 있는 상세 뷰를 열어 자세한 내용을 살펴보세요.

복제가 진행되는 동안 미리 디스크의 대상(target) 세부정보를 설정할 수 있습니다. 호스팅 프로젝트(리전 및 영역), 디스크 유형 등 마이그레이션된 디스크의 설정을 구성하세요.

그러면 시간을 절약할 수 있고 컷오버 날짜가 다가올 때 서두르지 않아도 됩니다.

복제 주기를 조정하여 점진적 변경사항의 누적 데이터 피크와 동기화되도록 할 수도 있습니다.

요약

Migrate to Virtual Machines 디스크 마이그레이션 기능은 모든 소스 VM에서 Google Cloud 디스크 스토리지로 컴퓨팅 디스크를 원활하게 마이그레이션할 수 있는 새로운 기능입니다. 이 기능은 Migrate to Virtual Machines의 원활한 에이전트리스 마이그레이션 기능을 활용하므로 소스 워크로드가 중단되지 않으며 정기적인 복제 주기 및 빠른 컷오버 시간과 같은 이점을 제공합니다.

이 기능은 개별 디스크 수준으로 마이그레이션 정밀도를 높이므로 워크로드를 다른 운영체제로 손쉽게 전환하거나 전체 데이터 스토어를 새 플랫폼으로 전송하는 등 혁신적으로 사용할 수 있습니다.

시작할 준비가 되셨나요? 마이그레이션 센터에서 Migrate to Virtual Machines가 포함된 마이그레이션 및 현대화를 위한 Google Cloud의 중앙 집중식 엔드 투 엔드 허브를 살펴보세요. 아직 확신이 생기지 않는다면 마이그레이션 센터에 대한 이 3분 길이의 동영상을 시청하거나 Google Cloud의 무료 IT 탐색 및 평가를 신청하여 귀사의 IT 환경을 정확히 파악하고 성공적인 마이그레이션 방법을 알아보세요.

Google Cloud 랜딩존 네트워크 아키텍처

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

1. 목적 및 활용 방법

구글 클라우드 기반의 랜딩존을 구축할 때, 네트워크 거버넌스 요구사항을 충족하기 위한 아키텍처를 제안합니다. 구글 클라우드의 랜딩존과 그것의 네트워크 아키텍처는 다음의 문서에 기술된 내용에 기반하여 구축하게 됩니다.

이 글에서는 위의 문서에 기술된 내용을 기반으로 하되, 국가별 규정이나 산업별 표준에 따라 추가적으로 필요한 요구사항 그리고 다수의 고객들이 이러한 요구를 만족하기 위해 채용하고 있는 공통적인 네트워크 아키텍처들을 상세히 기술함으로써, 기존 문서들의 부족한 부분들을 보완하고 있습니다. 단, 실제 구축에 필요한 상세한 구성이나 구현 방법을 제시하는 대신, 다양한 요구사항과 기업의 환경에 맞게 사용할 수 있는 공통적인 아키텍처를 제시하는데 초점을 맞추었습니다. 따라서, 실제 구축은 구글의 PSO(Professional Service Organization)나 MSP(Managed Service Partner)의 전문가들과 상의하면서 진행하기를 권고합니다.

이 문서의 구조와 활용하는 방법은 다음과 같습니다.

먼저 각자 필요로 하는 요구사항에 대해 구체적으로 파악 및 정의합니다.
챕터 2: 이 글에서 사용하는 각종 용어들에 설명으로 이미 익숙하다면 지나가도 됩니다.
챕터 3: 도출한 요구사항에 따라 의사 결정 트리에 따른 각각의 구현 방안의 특징을 확인합니다.
챕터 4: 최종적으로 여러 아키텍처 유형 중에서 각자의 요구사항에 맞는 것을 선택합니다.

이 문서에서 VPC 간의 연결은 가장 기본적인 방법인 VPC Peering이나 VPN을 우선적으로 사용할 것입니다. 다만, 최근에 등장한 Private Service Connect(또는 PSC)를 사용하면 VPC 간 연결에 유연성을 높일 수 있으므로, 문서의 마지막에 VPC Peering이나 VPN의 대안으로 사용할 수 있는 아키텍처에 대해 설명할 것입니다. 따라서 위의 과정에 다음의 선택 사항이 추가됩니다.

챕터 5: PSC를 통해 선택한 아키텍처에서 유연성을 개선할 부분이 있다면 해당 부분을 PSC로 변경합니다.

2. 기본적인 기술 개념 및 용어 정의

이 글에서는 기본적으로 구글 클라우드와 네트워크, 보안 분야에서 사용되는 다양한 용어를 사용하고 있습니다. 해당 용어들은 표준화된 경우가 많지만 업계에서 통상 사용하는 관습적인 경우도 있어 이들 간의 혼선을 막기 위해 이 글에서 자주 사용하는 용어와 개념 그리고 차이점에 대해서 설명합니다.

용어 정의

DMZ or Untrusted VPC
외부(인터넷) 네트워크 환경과 직접 연결된 환경을 DMZ(Demilitarized Zone) 구간이라고 말하는 경우가 있습니다. 외부에서 들어오는 트래픽이 먼저 DMZ 구간에서 받아 위험한 침입을 필터링 하고 안전한 트래픽만을 내부 시스템으로 보내는다는 의미에서 이 용어를 사용합니다. 구글 클라우드 네트워크 아키텍처에서는 아래 문서에 Untrusted VPC로 언급이 되어 있습니다.

Centralized network appliances on Google Cloud | Cloud Architecture Center

명시적으로 Untrusted 혹은 DMZ에 대해 의미가 설명되어 있지 않지만, 의미상 외부 인터넷에서 들어오는 트래픽을 직접 내부 Trusted VPC에 연결하지 않고 중간에서 중계하는 역할을 합니다. 여기서는 중계 과정에 가상 네트워크 장비(Virtual Network Appliance)가 배치되어 있는데, 이것의 역할은 다음과 같습니다.

외부 트래픽을 연결 종료(termination)
L7 트래픽에 대한 침입 탐지 및 방어
최종 목적지인 Trusted VPC로 안전한 트래픽을 라우팅

Virtual Network Appliance
라우팅, 로드밸런싱 등 네트워크 기능을 담당하는 소프트웨어를 가상의 컴퓨팅 자원인, VM(Virtual Machine)에서 동작시키는 장비를 말합니다. 이 글에서 언급되는 Virtual Network Appliance는 그 중에서도 차세대 방화벽이라고 말하는 NGFW(Next Generation Firewall)를 가리키고 있습니다. 기존의 방화벽이 L4 레벨에서 IP 패킷 차원이나 포트 단위의 공격을 방어하는 역할을 한데 반해, NGFW는 L7 레이어에서 애플리케이션 패킷의 내용에 기반한 공격까지도 방어하는 일종의 WAF(Web Application Firewall) 기능과 IPS(Intrusion Prevention System), IDS(Intrusion Detection System), 그리고 네트워크 간 라우팅의 역할까지도 같이하는 복합적인 기능을 하는 장비입니다.

Private Service Connect
특정 클라이언트로부터 특정 서비스에 대한 액세스를 가능하게 하는 서비스입니다. 아래 그림처럼 VPC Peering의 경우에는 두 VPC 간에 서로 라우팅으로 연결하고 라우팅 테이블을 서로 교환하기 때문에 해당 VPC 내에 있는 모든 Endpoint 간에 통신이 가능합니다. 반면 PSC(Private Service Connect)는 VPC에 있는 특정 Endpoint(예: Cloud SQL, Compute Engine)에 대한 특정 클라이언트의 액세스를 연결하는 기능을 합니다. 특히 VPC Peering은 기본적으로 양방향 통신인 반면, PSC는 단방향 연결입니다. 즉, Consumer 역할을 하는 클라이언트에서 Producer 역할을 하는 특정 서비스로의 단방향 연결만 가능하고, 양방향 연결이 필요하다면 명시적으로 별도의 PSC 연결을 만들어야 합니다.

PSC에 대한 상세 설명과 그것을 사용한 아키텍처에 대해서는 챕터 5에서 보다 상세하고 설명합니다.

LB Frontend, Backend, Forwarding rule
구글 클라우드의 로드밸런서는 다음과 같은 구조를 가지고 있습니다. 왼쪽에서 트래픽이 들어오면 처음에는 Frontend에서 받습니다. Frontend는 트래픽이 인입하는 지점(URL 혹은 IP, Port. 예: 10.10.10.1:8888)을 가지고 있고, 수신한 트래픽을 실제 서비스를 담당하는 백엔드로 규칙에 따라 포워딩하는 Forwarding rule을 가지고 있습니다. Backend service는 실제 트래픽을 담당하는 백엔드(예: Instance Group, CDN: Content Delivery Network)를 관리하는 역할을 합니다. 백엔드가 살아 있는지(health check), 백엔드가 트래픽을 충분히 처리할 수 있는지 등을 관리하고 조절합니다.

Instance Group
구글 클라우드의 여러 VM들을 하나의 논리적인 단위로 통합한 것입니다. 동일한 역할을 하는 VM들을 하나로 묶어 관리함으로써 이들 간의 로드밸런싱, 스케일링(scale-in, scale-out), 서비스 가능 여부 검사(health-check) 등을 일괄 수행합니다. 주로 애플리케이션 서비스를 VM으로 만들어 로드밸런서의 백엔드로 많이 사용됩니다.

NLB(Network Load Balancer)
구글 클라우드에서 로드밸런서를 생성할 때, 다음과 같은 메뉴를 통해 생성되는 Layer 4, IP 레이어의 로드밸런서를 의미합니다. NLB는 크게 TCP(SSL 포함) 프로토콜을 처리하는 TCP NLB와, UDP 프로토콜을 처리하는 UDP NLB가 있습니다. NLB의 프론트엔드는 L4 레이어의 IP와 Port로 이루집니다.

ALB(Application Load Balancer)
구글 클라우드에서 로드밸런서를 생성할 때 다음과 같은 메뉴를 통해 생성되는 Layer 7, 애플리케이션(HTTP, HTTPS 등) 레이어의 로드밸런서를 의미합니다.

애플리케이션 레이어는 HTTP 프로토콜에서 사용하는 URL, Protocol, URL Path 등을 사용하여, 이것의 프론트엔드는 다음과 같은 방식으로 결정됩니다. IP(Host), Port 뿐만 아니라 뒤에 따라오는 URL Path에 의해서 포워딩 규칙(forwarding rule)이 결정되며, 그에 매핑된 Backend service로 트래픽을 전달합니다.

예: http://10.10.10.1:80/svc1/resource1
예: https://10.10.10.2:443/svc2/resource2

3. 구글 클라우드 네트워크 아키텍처 의사 결정 트리

다음은 각자 필요로 하는 요구사항을 구체화하기 위한 의사 결정 트리입니다.

각각의 의사 결정 과정에 대해 상세히 알아보면 다음과 같습니다.

(1) Untrusted(DMZ) VPC와 Trusted(Internal) VPC의 관리 주체가 다릅니까?

챕터 2의 용어 정의에서 설명했듯이 DMZ(또는 Untrusted)는 외부 트래픽이 인입되는 네트워크를 의미합니다. 이 DMZ 네트워크와 내부 서비스 VPC를 분리해야 하는지 판단합니다. 여기서 중요한 의사 결정 요소는,

외부 트래픽을 처리하는 VPC(통상 DMZ 또는 Untrusted VPC라고 함)와 내부 서비스 트래픽을 처리하는 VPC를 분리해서 “관리” 해야 하는가

입니다. 특히 분리해서 “관리” 하는 부분을 어느 수준까지의 분리로 보느냐도 중요한데,

두 개를 별개의 VPC로 분리만 하면 될지, 또는 해당 VPC를 관리하는 관리자(클라우드의 IAM 계정)가 달라야 하는가

결정해야 합니다. 구글 클라우드에서 VPC를 분리하는 것은 동일한 프로젝트 내에서도 가능하지만, VPC를 관리하는 관리자(IAM 계정)가 달라야 한다면 프로젝트를 분리해서 각각의 VPC를 배치해야 합니다.

일반적으로 VPC나 프로젝트를 분리하면 분리할 수록 관리해야할 컴포넌트의 개수가 많아지고 관리 주체가 달라지기 때문에 복잡도가 올라갑니다. 따라서 특별한 보안적 요구사항이나 업계의 규정이 없다면 동일한 프로젝트나 동일한 VPC를 사용하는 것이 유리합니다. 다만, 업계의 보안 규정상 분리를 해야 한다면 상황에 맞게 적절한 수준(프로젝트 또는 VPC)에서 분리를 합니다.

아래는 세 가지 경우를 다이어그램으로 표현한 것입니다. 이 문서에서는 단일 프로젝트와 프로젝트를 복수로 분리하는 경우를 명시적으로 구분하여 설명할 것입니다. 하지만 단일 프로젝트 내에서의 VPC 분리 여부는 가능하면 단순한 방안(단일 VPC 구조)을 제시하고, 꼭 필요한 경우만 분리하는 방안(VPC를 분리하고 각각을 VPC Peering, VPN 등으로 연결)에 대해 설명할 것입니다.

(2) 온프레미스 또는 다른 클라우드 네트워크 연결이 필요합니까?

구글 클라우드 내에서의 네트워크 트래픽만을 처리하는 것이 아닌 외부의 네트워크 즉, 온프레미스나 다른 클라우드에 연결하기 위해서는 interconnect나 VPN을 구성하여 해당 네트워크에 연결하는 구성이 필요합니다. 둘 중 하나라도 필요하면 선택해야 할 의사 결정 요소입니다. 다만, 물리적인 구성이나 용량 등에서 차이는 있지만 실제 아키텍처적인 동작에서는 거의 유사하므로 이 글에서는 Interconnect를 사용한 온프레미스 연결을 가정하고 설명합니다.

(3) 가상 네트워크 어플라이언스를 사용하는 VPC 간 레이어 7 트래픽 검사가 필요합니까?

여기서 말하는 가상 어플라이언스는 L7 차세대 방화벽(NGFW)를 의미하며, 주요한 용도는 DMZ VPC에서 들어온 트래픽을 내부 VPC로 바로 보내지 않고 안전한지 검사를 하여 위험한 요청을 제외한 안전한 트래픽만을 전달하는 것입니다.

업무의 종류나 업계의 규정에 따라 구글 클라우드가 제공하는 로드밸런서와 그것이 제공하는 웹방화벽(WAF)만으로 요구사항을 준수할 수 있는 경우도 있지만, 그렇지 않은 경우에는 이 의사 결정 요소를 선택해야 합니다.

참고로 NGFW는 구글 클라우드에서는 마켓플레이스를 통해서 배포하거나 별도의 3rd Party 업체의 제품을 Virtual Appliance 형태로 설치를 해야 합니다. NGFW는 트래픽의 안정성을 검사하는 기능과 함께 트래픽 자체를 목적지 VPC를 다음 Hop으로 전달하는 기능도 가지고 있습니다.

(4) 인프라를 관리하는 중앙 집중식 네트워크/보안 팀이 있습니까?

이 의사 결정 요소는 궁극적으로 구글 클라우드가 제공하는 공유 VPC(Shared VPC)와 관련이 있습니다. 공유 VPC는 다음과 같이 실제 워크로드를 처리하는 서비스 프로젝트들은 각자의 VPC를 가지지 않고, 대신 호스트 프로젝트가 가지고 있는 공유 VPC에서 서브넷(subnet)을 할당받아 사용하는 방식을 의미합니다.

따라서 공유 VPC를 사용하게 되면 다음과 같은 특징이 있습니다.

우선 호스트 프로젝트에서 전사 서비스 프로젝트들의 네트워크를 관리하는 중앙 집중식 네트워크 및 보안 관리자(또는 팀)가 있어야 합니다.
서비스 프로젝트를 운영하는 팀에서는 네트워크 구성(외부 연결, 온프레미스 연결, IP 할당 등)에 대해 크게 고민할 필요 없습니다.
로드밸런서의 경우 실제로 동작은 Host Project에 속한 Shared VPC에서 이루어지지만, 구성이나 백엔드 서비스(에: VM) 매핑 등은 Service Project에서 하여 네트워크 관리와 서비스 관리를 분리할 수 있는 장점이 있습니다.
호스트 프로젝트가 제공하는 단일한 공유 VPC를 각 서비스 프로젝트가 공유하므로 서비스 간의 트래픽이 기본적으로 연결(라우팅)이 됩니다. 서비스 간에 트래픽을 차단하기 위해서는 방화벽 구성을 통해 서비스넷 간 통신을 차단해야 합니다.

이런 특징들을 감안하여 의사 결정을 하면 됩니다. 만약 공유 VPC를 사용하지 않는다면 개별적으로 VPC를 구성하고 그들 사이를 VPC Peering이나 VPN을 통해서 연결해야 합니다. 이 글에서는 개별 VPC 구성에 대해서는 설명하지 않고 공유 VPC를 기준으로 설명합니다. 다만 공유 VPC를 사용하는 경우에도 단일 VPC가 아닌 복수의 VPC를 사용하는 경우에는 VPC 간 연결이 필요합니다. 이를 위해 다음 섹션에서는 VPC를 연결하는 옵션 간 의사결정 방법에 대해 설명합니다.

(5) VPC 간 연결하는 방법 Peering과 VPN의 차이

VPC를 호스팅하는 프로젝트가 분리되거나 VPC가 분리된 경우에는 두 네트워크를 연결하는 방법이 필요합니다. VPC 간 연결하는 방법인 VPC Peering과 VPN의 가장 큰 차이는 Transitive Peering이 되는가 여부입니다. VPC Peering은 Transitive Peering이 불가능한 반면, VPN은 가능합니다. Transitive Peering이란, 두 VPC 간의 연결을 통해 제 3의 VPC와 연결도 지원할 수 있는 기능입니다. 상세한 차이점에 대해서 살펴보겠습니다.

아래 그림과 같이 공유 VPC A(일반 VPC인 경우에도 동일)와 VPC B, C를 각각 연결한다고 가정해봅시다. VPC B는 Peering을 통해서 연결하고, VPC C는 VPN을 통해서 연결합니다. 이 때 VPC B, C 내에서 동작하는 Compute Engine B와 C는 각각 VPC A 내에서 동작하는 Compute Engine 1, 2와 통신이 가능합니다. VPC Peering이 양쪽 VPC의 라우팅 테이블을 교환하기 때문입니다.

여기서 VPC A에 배포된 Cloud SQL과 같은 Managed Service가 있다고 가정해 봅니다. Cloud SQL은 관리형 인스턴스를 숨겨진 Managed VPC에 배포하고 그것을 서비스를 운영하는 주 VPC에 Peering을 통해서 연결합니다. 이 경우 VPC B 입장에서 Cloud SQL은 VPC A를 통해서 바로 연결되는 것이 아니라, VPC B - VPC A - Managed VPC 간 이중 Peering을 통해서 연결되어야 합니다. 이 경우 Peering은 Transitive Peering이 되지 않으므로 VPC B에서 온 트래픽이 Managed VPC로 전달되지 않습니다.

반면, VPC C는 VPC A와 VPN으로 연결되어 있고 이 경우에는 VPC C에서 보낸 트래픽을 VPC C - VPC A 간의 VPN을 거쳐 VPC A - Managed VPC 간의 Peering을 통해서 전달됩니다..

따라서 VPC 간 연결을 위한 의사 결정 시, 이러한 Transitive Peering 기능이 필요한 경우에는 VPN을 사용해야 합니다. 특히, Cloud SQL, Memory Store 등과 같은 관리형 서비스들은 이러한 Managed VPC 형태를 하고 있고, 이러한 서비스들을 다른 VPC에서 연결해야 한다면 반드시 VPN을 사용해야 합니다..

만약, Peering을 통해서 Transitive Peering 요구사항을 해결하려면, 중간의 VPC A에 Proxy 역할을 할 수 있는 컴포넌트를 넣어 VPC B와 Managed VPC 사이 통신을 중계해야 합니다. Proxy 역할을 할 수 있는 컴포넌트로는 Compute Engine VM, Private Service Connect(PSC) 또는 NGFW 등이 있습니다. NGFW에 대해서는 3-(3)에 설명되어 있고 PSC에 대해서는 챕터 5에서 설명합니다.

(6) 외부 인터넷 SSL Termination을 LB에서 해야 하는가?

3-(1)과 3-(3)에서 각각 Untrusted VPC(외부 트래픽이 인입되는 네트워크)와 해당 트래픽에 대한 L7 레이어 검사를 위한 가상 어플라이언스 장비에 대한 언급을 하였습니다. 이 때, 두 가지 고려사항이 필요합니다.

첫 번째는, 외부에서 인입되는 트래픽이 HTTPS 혹은 SSL일 경우, 내부로 전달할 때 경로 상의 어느 지점에서는 SSL 트래픽을 일반 Plain Text 트래픽으로 변경하는 SSL Termination이 일어나야 합니다. SSL Termination을 위해서는 클라이언트가 보낸 SSL 트래픽을 디코딩할 수 있는 인증서가 필요합니다. SSL Termination을 트래픽이 인입되는 최초의 로드밸런서에서 하려면, 해당 로드밸런서에 인증서가 설치되어 있어야 합니다. 만약 최초 로드밸런서가 아닌 내부의 어느 지점에서 하려면, 해당 지점에 인증서가 설치되어야 합니다. 반면 해당 지점 앞 단계에서는 트래픽의 내용이 암호화 되어 있기 때문에 해당 내용을 볼 수 없고 단지 백엔드로 전달(pass-through)하는 역할만 하게 됩니다.

두 번째로 고려할 사항은 가상 어플라이언스를 VM에 배포하고 그것을 Instance Group으로 구성하여 로드밸런서의 백엔드(LB Backend)로 지정해야 합니다. 이 때, 가상 어플라이언스는 고가용성을 생각하여 복수로 구성을 하는 것이 권장됩니다. 구글 클라우드의 로드밸런서는 백엔드로 사용하는 Instance Group을 복수로 구성하여 그것들을 Active/Active 방식으로 사용할지 Active/Standby 방식으로 사용할지 결정해야 합니다. 사용하는 가상 어플라이언스가 두 가지 모두 지원한다면 선택이 자유롭지만, Active/Standby 방식만 지원한다면 로드밸런서의 종류가 NLB(Network Load Balancer)로 제한됩니다.

다음은 SSL Termination이 최초의 로드밸런서에서 일어나고, 가상 네트워크 어플라이언스에 대한 Instance Group은 Active/Active 형태로 구성된 경우입니다. 빨간색 선이 SSL 트래픽을 나타내고 검은색 선은 SSL Termination 이후 Plain Text 트래픽을 나타낸다. 여기서 사용된 구글 클라우드의 로드밸런서 ALB(Application Load Balancer, L7)입니다. Global HTTP/HTTPS 요청을 처리할 수 있는 GLB(Global LB)나 Regional ALB 등이 여기에 속합니다. 네트워크 어플라이언스가 Active/Active 구성을 지원한다면 아래와 같은 형태의 구성이 권장됩니다.

다음은 Instance Group을 Active/Standby 형태로 구성하는 경우입니다. 구글 클라우드에서 Instance Group을 Active/Standby 형태로 구성하여 로드밸런서의 백엔드로 사용하려면 NLB(Network Load Balancer)가 사용되어야 합니다. NLB의 백엔드에는 복수의 Instance Group을 연결하여 하나는 Primary로 지정하여 Active 모드로 동작하게 하고, 여기에 문제가 생기면 Failover로 지정한 Standby 모드의 Instance Group을 Active로 변경하여 그것을 통해 트래픽을 처리하게 할 수 있습니다. 다만, 이렇게 사용하기 위해서는 NLB가 Proxy 방식이 아닌 Pass-through 모드로 동작해야 하며, 이 경우 SSL Termination을 하는 것이 불가능합니다. Pass-through 모드는 말 그대로 들어온 TCP 트래픽을 그대로 백엔드로 전달하는 역할만 합니다.

4. 단일 프로젝트 아키텍처

(1) 단일 프로젝트 - Untrusted, Trusted VPC 간 동일 거버넌스 체계

다음과 같은 요구사항에 대해 관리 주체가 동일한 경우입니다.

Untrusted(DMZ) VPC와 Trusted(Internal) VPC의 관리 주체가 다릅니까?

이 경우에는 단일 Host Project에서 VPC를 구성하고 그것을 각 서비스 프로젝트에서 가져다 사용합니다. 가장 큰 특징은 인터넷에서 트래픽이 인입되는 DMZ VPC와 실제 워크로드를 처리하는 서비스 프로젝트가 단일한 VPC 및 단일한 프로젝트에 속한 경우입니다. 이 경우의 특징은 다음과 같습니다.

외부 트래픽을 처리하기 위한 로드밸런서와 서비스 프로젝트 네트워크가 하나의 VPC에 구성되며, 동일한 관리 주체가 관리합니다.
따라서 네트워크팀이 크지 않아 동일한 사람이나 팀이 담당해야 하는 경우 관리 오버헤드를 감소할 수 있습니다.
반대로 외부 트래픽과 서비스 프로젝트를 분리해서 관리해야 한다면 사용할 수 없는 방법입니다.
외부 트래픽 네트워크를 통해 들어오는 침입은 로드밸런서에 Cloud Armor를 구성하여 방어합니다.

주: GLB는 특정 VPC에 속하지 않으며, 동일 프로젝트 내 모든 VPC의 Instance Group, NEG 또는 다른 프로젝트의 서비스를 PSC 를 통해 backend로 연결해서 요청을 전달할 수 있음.

이 구성에서 추가적으로 고려해야 하는 요구사항은 다음과 같습니다.

온프레미스 또는 다른 클라우드 네트워크 연결이 필요합니까?
가상 네트워크 어플라이언스를 사용하는 VPC 간 레이어 7 트래픽 검사가 필요합니까?

(2) 단일 프로젝트 - 하이브리드(온프레미스 또는 다른 클라우드) 네트워크 구성

3-(2)에서 언급한 것처럼 Interconnect를 사용한 온프레미스 연결을 가정하고 설명합니다. Interconnect를 통해서 구글 클라우드 VPC와 온프레미스 네트워크 연결할 경우, 3-(4) 요구사항처럼 공유 VPC에서 일괄 연결할 수도 있고 별도의 VPC를 분리하여 연결하는 방법 중에서 선택이 가능합니다.

다음은 단일한 공유 VPC에 온프레미스 네트워크를 연결한 경우입니다. 온프레미스 자원은 Interconnect를 통해 구글 클라우드의 VPC에 연결되어 있고 거기에 연결 또는 포함되어 있는 모든 자원(여기서는 Compute Engine, Cloud SQL)에 접근할 수 있습니다. 반대의 연결도 마찬가지입니다. 이 경우의 특징은 다음과 같습니다.

온프레미스 연결 네트워크 연결까지 모든 네트워크에 대한 관리를 하나의 팀에서 합니다.
Cloud SQL과 같은 Managed Service에 대한 연결도 가능합니다.

만약 관리 주체의 차이¹로 온프레미스 연결을 별도의 VPC를 통해서 해야 한다면, 해당 VPC와 서비스 VPC 사이의 연결에 3-(5)에 언급된 Peering이나 VPN 중에서 하나의 방법을 사용해야 합니다. 특히 Transitive Peering 요구사항이 있다면 반드시 해당 섹션에 언급된 대로 VPN을 사용하거나 Proxy 기능이 같이 구현된 Peering을 사용해야 합니다. 다음은 온프레미스에 연결하는 VPC가 서비스용 공유 VPC A와 분리된 상태를 나타낸 다이어그램으로, Peering으로 연결한 VPC B와 VPN으로 연결한 VPC C를 동시에 표현한 것입니다.VPC Peering을 사용한 Location B의 경우 Transitive Peering이 되지 않기 때문에 온프레미스에서 보내는 요청이 VPC B를 거쳐 VPC A에는 도달하지만, Managed Service가 위치한 Managed VPC까지는 요청이 전달되지 않습니다. VPN을 사용한 Location C의 경우에는 온프레미스 요청이 VPC C와 VPC A를 거쳐 Managed VPC까지 전달됩니다.

^{1. 4-(4) 섹션에 언급하겠지만, 관리 주체를 다르게 가져가려면 엄밀히는 VPC 분리만으로는 안되며 관리자가 속한 IAM의 분리를 위해 프로젝트도 분리해야 합니다. 다만 여기서는 VPC 가 분리되어 서로 연결(Peering 또는 VPN을 이용하여)할 것이므로 프로젝트가 통합되어 있던 분리되어 있던 사실상 차이가 없으므로 편의상 동일한 프로젝트에서 VPC만 분리된 경우를 가정합니다.}

이러한 단일 프로젝트 아키텍처에서, GLB를 통해서 들어오는 인터넷 트래픽을 직접 온프레미스에 있는 서비스로 보내야 한다면 아래와 같이 Hybrid NEG를 GLB의 Backend로 하여(VPC 연결 방법에 상관 없이) 연결할 수 있습니다. 상세한 내용은 아래 문서를 참고하면 됩니다.

또 한 가지 고려해야 할 부분은 온프레미스와 연결하는 전용선(Interconnect)에 대한 이중화입니다. 일정 수준 SLA를 보장하기 위해서는 회선의 이중화와 함께 물리적인 연결 지역(region 또는 zone)에 대한 이중화도 해야 합니다. 이 글에서는 해당 부분을 구현하는 방법이나 아키텍처에 대한 자세한 언급은 하지 않을 것이며, 상세한 내용은 다음 문서들을 참고하기 바랍니다.

(3) 단일 프로젝트 - 가상 네트워크 어플라이언스를 사용하는 VPC 간 레이어 7 트래픽 검사

DMZ(Untrusted) VPC와 내부 서비스 VPC 및 온프레미스와의 연결 사이에 가상 네트워크 장비(Virtual Appliance)를 두어 L7 레이어의 트래픽을 검사, 방어 및 라우팅을 하도록 구성하는 것입니다. 이는 DMZ와 내부 네트워크를 분리하는 것이 주 목적으로, 각 VPC 네트워크 사이의 트래픽 전달은 가상 네트워크 장비(NGFW)가 수행합니다.

아래 그림은 단일 프로젝트에서 여러 개의 VPC를 분리하여 NGFW를 구성한 아키텍처입니다. VPC는 각각 외부 트래픽을 처리하기 위한 DMZ VPC, 내부 서비스 용 Shared VPC 그리고 온프레미스 연결을 위한 Hub VPC가 있습니다. 여기서 NGFW는 세 개의 VPC 중간에 위치하여 각 VPC 간의 L7 트래픽을 검사하고 제어하게 됩니다. 구글 클라우드의 Compute VM은 각각의 NIC을 VPC에 할당할 수 있습니다. 따라서 VM에 배포된 NGFW 가상 네트워크 장비는 각 VPC 별로 별도의 NIC를 할당해서 연결하였습니다. NGFW는 High Availability를 위해 복수의 인스턴스를 구성할 수 있으며, 이 경우에는 Instance Group를 사용해서 VM 들을 논리적으로 그룹핑해야 합니다.

위의 그림에서 각 트래픽의 흐름을 살펴보면,

(1)번은 인터넷에서 들어온 트래픽이 서비스 프로젝트의 애플리케이션에 전달되는 과정입니다. 인터넷 트래픽은 GLB의 Frontend를 통해 수신하며, GLB의 Backend인 NGFW를 통해서 Shared VPC로 전달됩니다. 여기서 애플리케이션은 Compute Engine에서 동작 중이며 그것들은 ILB를 통해 연결됩니다. SSL Termination은 GLB에서 발생하게 됩니다.

(2)번은 온프레미스에서 들어오는 트래픽이 서비스 프로젝트로 전달되는 과정입니다. Hub VPC에서는 ILB를 통해서 NGFW Instance Group에 요청이 전달되고, 여기서부터는 (1)과 마찬가지로 NGFW에 의해 Shared VPC를 거쳐 Service Project로 전달됩니다.

인터넷에서 들어온 트래픽이 클라우드 내의 서비스 대신 온프레미스로 전달되는 과정입니다. NGFW는 외부 트래픽을 Hub VPC로 보내고 여기서는 ILB의 Backend에 연결된 Hybrid NEG를 통해 온프레미스로 연결됩니다. 반대로 Service Project에서 온프레미스로 연결하는 과정은 Compute Engine ⇒ Shared VPC의 ILB ⇒ NGFW Instance Group ⇒ Hub VPC ⇒ 온프레미스 과정이 됩니다.

(3)번은 온프레미스에서 클라우드 내부 Shared VPC에 배포된 Managed Service에 트래픽이 전달되는 과정입니다. 앞서 단일 VPC나 VPN을 통해 VPC가 분리된 경우 트래픽을 전달하는 경우를 살펴 보았는데, 여기서는 NGFW가 온프레미스의 트래픽을 Managed VPC로 전달하는 역할을 합니다. 이 때, NGFW는 1번 NIC가 Shared VPC 내에서 동작하고 있기 때문에 Shared VPC에 VPC Peering으로 연결된 Managed Service에 문제 없이 트래픽을 전달할 수 있습니다.

만약 여기서 3-(6)에 언급된 의사 판단 과정 중에서 SSL 가상 어플라이언스를 Active/Standby 형태로 이중화를 하려면 아래와 같이 GLB를 NLB로 바꿔야 합니다. GLB를 NLB로 변경한 경우, 트래픽을 살펴보면,

(1)번에서 인터넷 트래픽은 NLB의 Frontend를 통해 수신하며, NLB의 Backend인 가상 네트워크 장비(NGFW)의 Instance Group을 통해 Shared VPC로 전달됩니다. SSL Termination은 NGFW에서 발생하게 됩니다.

(2), (3)번은 위에서 설명한 GLB인 경우와 동일합니다.

(4) 프로젝트 분리 - Untrusted, Trusted VPC 간 다른 거버넌스 체계

다음과 같은 요구사항에 대해 관리 주체가 다른 경우입니다.

Untrusted(DMZ) VPC와 Trusted(Internal) VPC의 관리 주체가 다릅니까?

이 경우에는 외부에서 트래픽이 유입되는 DMZ(Untrusted) VPC와 서비스를 위한 Host Shared VPC가 별도의 프로젝트에서 동작합니다. 3-(1)에 언급한 것처럼 하나의 프로젝트에 VPC를 다르게 구성해도 동일한 IAM의 계정과 권한을 공유하기 때문에, 관리자는 프로젝트에 속한 모든 VPC 네트워크를 접근하고 변경할 수 있는 권한을 가지게 됩니다. 하지만 프로젝트가 분리된 이 아키텍처에서는 각각에 VPC를 다음과 같이 배치하였습니다.

Hub 프로젝트에 DMZ VPC (다른 프로젝트의 VPC 연결을 위한 Transit VPC 포함)
Host Project에 Service 프로젝트를 위한 Shared VPC
Hybrid 프로젝트에 온프레미스 연결을 위한 Hybrid VPC

따라서 각 VPC는 서로 다른 IAM 계정과 권한을 사용할 수 있고, 서로 다른 관리자를 각각의 VPC에 배정할 수 있습니다.

이러한 아키텍처는 주로 금융업처럼 업계의 보안 규정이 특수한 요구사항(예: 망분리)을 충족해야 하는 경우에 사용합니다. 특히 해당 보안 규정에서는 3-(3)에 언급된 것처럼, 외부 트래픽이 들어오는 DMZ VPC와 서비스를 처리하는 내부 서비스 VPC 사이에 L7 트래픽을 검사하는 요구사항도 포함되어 있습니다. 따라서 이 글에서 기본적으로 프로젝트를 분리한 요건에서는 VPC 사이에 가상 네트워크 어플라이언스(NGFW)가 배포하는 아키텍처를 제시할 것입니다. 혹시 네트워크 어플라이언스가 불필요한 경우가 있다면 4-(1)에 제시된 내용들을 참고하여 구성하기 바랍니다.

본 아키텍처는 단일 아키텍처를 채택한 4-(3)과 유사하지만 다음과 같은 차이 및 특징들이 있습니다.

기본적으로 관리자를 분리해야 하는 네트워크(VPC)는 서로 다른 프로젝트에 배치합니다.
가상 네트워크 어플라이언스가 여러 VPC에 동시에 연결(실제로는 각 VPC를 NIC로 지정)이 되고 그들 사이에 트래픽을 전달할 수 있지만, 프로젝트가 분리되어 있는 VPC에 트래픽을 전달하기 위해서는 3-(5)에 언급된 VPC 간 연결을 위한 방안(VPC Peering 또는 VPN)이 필요합니다. (Transit VPC와 대상 VPC 사이)

(5) 프로젝트 분리 - VPC Peering을 이용한 VPC 간 연결

아래는 Hub, Hybrid, Service 프로젝트(VPC) 간 연결을 VPC Peering을 사용한 아키텍처입니다.

각 VPC 간 통신 과정에 대해 살펴봅니다.

DMZ VPC(인터넷 트래픽) to Host Shared VPC(Service Project)

인터넷 ⇒ External NLB(DMZ VPC) ⇒ Virtual Appliance(Instance Group) ⇒ Transit VPC ⇒ VPC Peering ⇒ Host Shared VPC ⇒ Service Project의 Compute Engine VM

인터넷으로 들어온 트래픽은 DMZ VPC의 External NLB를 통해 가상 네트워크 어플라이언스가 들어 있는 Instance Group을 호출합니다. 3-(6)에 언급한 것처럼 NLB를 사용하게 되면 SSL Termination은 네트워크 어플라이언스에서 해야 합니다. 어플라이언스는 트래픽을 nic1이 속한 Transit VPC에 VPC Peering으로 연결된 Host Shared VPC로 트래픽을 보낼 수 있습니다. 그러면 Service Project의 Compute Engine은 Shared VPC에 배포되어 있으므로 트래픽을 바로 받을 수 있습니다.

Hybrid VPC(온프레미스) to Host Shared VPC(Service Project)

온프레미스 ⇒ Interconnect ⇒ Hybrid VPC ⇒ Internal NLB ⇒ Virtual Appliance(Instance Group) ⇒ Transit VPC ⇒ VPC Peering ⇒ Host Shared VPC ⇒ Service Project의 Compute Engine VM

온프레미스에서 보낸 트래픽은 Interconnect를 통해 Hybrid VPC에 도착합니다. Hybrid VPC와 Hub 프로젝트의 Transit VPC와 VPC Peering으로 연결되어 있으므로 트래픽이 전달되어 가상 네트워크 어플라이언스로 전달됩니다. 그 이후 과정은 인터넷 트래픽과 마찬가지 과정을 거쳐 Compute Engine에 전달됩니다. 반대로 Service Project에서 보낸 요청도 온프레미스에 전달이 가능합니다.

다만, 온프레미스에서 Managed Service에 접속하기 위해서는 Transit VPC의 요청이 VPC Peering을 통해 전달된 Host Shared VPC에서 다시 Peering을 통해 전달되어야 하지만, 그것은 3-(5)에 언급한 것처럼 불가능합니다. 따라서 이러한 요구사항을 위해서는 VPN을 사용하거나 5장에서 설명할 PSC를 사용해야 합니다.

위에서 제시했던 아키텍처는 DMZ, Service와 함께 온프레미스 연결을 위한 Hybrid VPC도 별도의 프로젝트에서 관리했다. 하지만 만약 동일한 관리자가 DMZ와 Hybrid VPC를 관리한다면 아래와 같이 Hybrid VPC를 Hub Project 안에 넣을 수 있습니다. VPC 간 통신 기능에는 차이가 없습니다.

(6) 프로젝트 분리 - VPN을 이용한 VPC 간 연결

4-(5)에서 제시한 아키텍처에서 VPC 간 연결 방법을 3-(5)에 제시한 방법 중에서 VPN을 사용한 경우입니다. 4-(5)에서는 온프레미스 요청이 Managed Service에 전달될 수 없었으나, 여기서는 Transitive Peering이 가능한 VPN을 사용했기 때문에 전달이 가능합니다.

(7) 구글 클라우드 Public Web Page에 제시된 아키텍처에 대한 추가 설명

본 문서는 최대한 구글 클라우드의 웹페이지에 언급된 개념, 방법, 용어 등을 그대로 사용하였습니다. 다만, 업종별로 상이한 요건이나 국가별 규정에 따른 추가적인 요건을 만족할 수 있게 다음 부분을 추가하였습니다.

거버넌스 체계 분리를 위한 프로젝트의 분리
Virtual Network Appliance(NGFW)에 대한 구현 방법 상세화
Transitive VPC 구현을 위한 방안으로 VPC Peering, VPN, PSC에 대한 차이점 설명

구글 클라우드 웹페이지 문서 중 Centralized network appliances on Google Cloud | Cloud Architecture Center (한국어)에서 언급된 아키텍처는 Virtual Network Appliance와 인터넷, 온프레미스 그리고 클라우드 간에 어떻게 네트워크를 연결하고 구성하는지 잘 설명하고 있습니다. 다만, 모든 VPC가 동일한 프로젝트에 포함되어 있어 4-(4) 섹션에 나오는 거버넌스 체계의 분리 요건은 제외하고 설명하였습니다. VPC 간 연결은 모두 4-(5) 섹션에 나오는 VPC Peering을 사용하고 있지만, 4-(6) 섹션에 나오는 VPN을 사용하거나 5장에 설명할 PSC를 사용하는 방법도 있습니다. Untrusted VPC로부터 Virtual Network Appliance에 연결하는 과정에 어떤 로드밸런서를 사용해야 하는지 설명이 없지만, 4-(3) 섹션이나 3-(6) 섹션에 언급한 것처럼 로드밸런서를 ALB나 NLB를 사용할 때 Failover와 SSL Termination 등에서 차이가 있음을 감안해야 합니다.

5. Private Service Connect 사용

PSC(Private Service Connect)에 대한 상세한 설명은 다음 문서를 참고하기 바랍니다.

Private Service Connect | VPC | Google Cloud (한국어)

PSC는 기본적으로 VPC 내부에 있는 서비스를 외부에서 액세스할 수 있게 연결 지점(endpoint)을 제공하는 서비스입니다.통상은 Cloud SQL 등과 같은 관리형 서비스를 VPC 외부에서 액세스할 수 있게 할 때 사용할 수 있지만, 다음과 같은 다양한 서비스들을 지원하고 있습니다.

Google APIs
Google services (관리형 서비스. 예: Cloud SQL)
Third-party services (예: 마켓플레이스 솔루션)
Intra-org services (사용자 제작 애플리케이션. 예: VM에서 운영하는 HTTP 서버)

위의 그림에서 Producer VPC에 있는 다양한 서비스들을 Consumer VPC에서 액세스할 수 있게 하는데, Consumer 입장에서는 Endpoint를 보고 호출하고 이 요청은 PSC를 통해 대상 서비스에 전달됩니다. 이 때, VPC는 반드시 동일한 프로젝트나 조직(organization)이 아니어도 상관 없습니다..

이러한 특성으로 인해 VPC Peering이 제공하고 있는 다른 VPC 간 통신 기능을 구현할 수도 있습니다. 하지만, PSC는 VPC Peering과 달리 VPC의 모든 트래픽을 전달하는 것이 아니라 특정 서비스를 명시적으로 지정하여 해당 서비스와의 단방향 통신만 가능합니다. 4-(5)나 4-(6) 섹션에서 언급한 VPC 간 통신에 PSC를 적용한다면, 명시적으로 Producer VPC(Host VPC)의 특정 서비스(예: Instance Group, GKE 서비스)를 VPC Peering이나 VPN 구성 없이 Untrusted VPC나 온프레미스에서 호출할 수도 있습니다. 다음 그림은 VPC Peering과 PSC와의 차이를 설명한 것입니다.

다음은 VPC Peering 대신 PSC를 사용하여 Service Project에 위치한 Managed Service를 Endpoint로 연결한 아키텍처입니다. 이와 같이 구성하면 4-(5) 섹션에서 VPC 간 연결 방법에 제시된 Peering이나 VPN 대신 PSC를 사용할 수 있습니다. 다만, PSC는 앞에서도 말한 것처럼 단방향 연결이고 명시적으로 특정 서비스에 대한 연결을 만들고 관리해야하는 번거로움이 있음을 감안해야 합니다. 그럼에도 불구하고 VPC 간 Transitive Peering이 필요한 경우 하나의 대안이 될 수 있습니다.

6. 3rd Party NGFW(Virtual Network Appliance) 구성

구글 클라우드에서는 마켓플레이스를 통해 다양한 3rd Party NGFW(Virtual Network Appliance)를 선택할 수 있습니다. 이 중에 Palo Alto의 구글 클라우드 배포 아키텍처는 다음 문서에 잘 나와 있으니 참고하기 바랍니다.

https://github.com/PaloAltoNetworks/google-cloud-vmseries-ha-tutorial

SAP 비용 예측 도구 소개: Google Cloud 기반 SAP 환경의 총 비용을 계산하세요

Tue, 08 Aug 2023 07:00:00 +0000

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

Google Cloud 기반 SAP의 비용에 대해 생각해 보셨나요? 다양한 구성과 기능 선택이 비용에 어떤 영향을 미칠까요? 직접 비용을 추정해본 적이 있다면 SAP 환경에 대한 많은 세부정보를 입력하지 않은 채 초기 예상 비용을 개괄적으로 추정하는 것이 얼마나 어려운 일인지 아실 겁니다.

Google Cloud가 SAP 애플리케이션에 적합한 비용 효율적인 클라우드인 이유를 쉽게 알아볼 수 있는 간편한 기능을 제공하기 위해, Google Cloud 마이그레이션 센터의 Cloud 지출 예측 도구 모듈에 내장된 SAP 비용 예측 도구를 출시했습니다. 자세한 내용을 알아보려면 계속 읽어보세요.

SAP 비용 예측 도구 들여다보기

SAP 비용 예측 도구는 SAP 애플리케이션을 위한 일반적인 Infrastructure as a Service(Iaas) 재료명세서를 기반으로 사전 정의된 크기(XS, S, M, L, XL)로 SAP 배포 비용을 계산합니다. 고가용성/재해 복구(HA/DR) 여부에 따라 다음 SAP 애플리케이션을 위한 사전 정의된 크기를 선택할 수 있습니다.

S/4HANA
BW/4HANA
BusinessObjects 비즈니스 인텔리전스
Fiori
비즈니스 목표 데이터 서비스(BODS)
프로세스 조정(PO)
SAP NetWeaver ABAP

사전 정의된 크기에는 기본 스토리지 구성이 포함됩니다. 하지만 추가 스토리지가 필요한 경우 요건에 따라 Block과 Cloud Storage를 모두 간편하게 포함할 수 있습니다. 또한 기본 리전과 DR 리전을 계획한 후 다른 리전 비용을 비교하고 약정 사용 할인(CUD) 가격을 확인할 수 있습니다.

다음 다이어그램은 개발, 품질보증, Production 시스템 등 SAP 워크로드 환경 전반에 걸친 IaaS 비용 분석을 보여줍니다.

SAP 비용 예측 도구는 초기 예상 비용을 추정해 Google Cloud에서 SAP 인프라를 실행하는 데 드는 비용에 대한 유용한 정보를 제공합니다. 이는 IT 환경에 대해 보다 심층적인 무료 탐색과 평가를 실행하기 위한 초기 단계 역할을 하며, 사용자는 더 정확한 마이그레이션 계획을 수립하고 예상 추정치를 얻을 수 있습니다. 마이그레이션 센터에서 제공하는 이 평가로 환경의 각 시스템(vCPU, 메모리, 스토리지 등)에 대한 자세한 정보와 마이그레이션 기본 설정에 기반한 총소유비용 보고서를 확인할 수 있습니다.

또한 SAP 사용자에게 Google Cloud에서 SAP 앱을 실행하는 데 드는 비용에 관한 유용한 정보를 제공하게 된 것을 기쁘게 생각합니다. 한 고객은 이렇게 말했습니다. "SAP 비용 예측 도구는 SAP 고객이 Google Cloud 인프라에서 SAP 애플리케이션을 실행하는 데 드는 비용을 초기에 파악하여 Google Cloud로 마이그레이션하는 여정을 가속화할 수 있도록 도와줍니다. 이러한 기능을 제공해 주셔서 감사합니다.”

SAP 비용 예측 도구에 관한 자세한 정보를 알아보고, 마이그레이션 센터에서 직접 사용해 보거나, Google Cloud 기반 SAP를 지원하는 모든 방식에 대해 자세히 읽어보세요.

고가용성이 우선순위일 때 Google Cloud에서 SAP를 실행하는 방법

Mon, 29 Aug 2022 12:00:00 +0000

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

지난 2~3년간 업종을 불문하고 많은 기업이 엔터프라이즈 IT 시스템의 안전성, 보안, 사용자 가용성을 유지하는 데 있어 예상치 못한 어려움을 겪었습니다. 그중 다수가 제품과 서비스의 수요가 급증하거나 급감하는 경험을 했고 대다수가 지금도 하이브리드 업무 환경을 운영하는 중입니다. 이처럼 환경이 변화하는 가운데 비즈니스 요구사항과 기대가 지속적으로 달라지면서 IT 시스템의 서비스 수준 목표(SLO)와 서비스수준계약(SLA)을 주기적으로 재점검하고 비즈니스 니즈에 부합하는지 확인하는 과정이 권장되고 있습니다.

온프레미스 환경에서 SAP 엔터프라이즈 애플리케이션을 실행하는 기업이 이 같은 새로운 요구사항에 적응하기란 특히 복잡한 일일 수 있습니다. 조직이 비즈니스에 중요한 SAP 인스턴스를 실행하는 데 따르는 복잡성과 높은 유지보수 비용으로 인해 이미 어려움을 겪고 있을 가능성도 높습니다. 이러한 기업은 시스템에 대한 사용자의 의존성과 예기치 않은 서비스 중단이 초래할 수 있는 불편을 잘 알고 있기 때문에 온프레미스 환경을 사용하면서 고가용성(HA) 시스템과 인프라에 대한 많은 투자로 뒷받침하는 것을 필수 애플리케이션의 보안과 가용성을 보장하는 최선의 방법으로 보고 있습니다. 온프레미스 SAP 환경을 실행할 수밖에 없는 IT 조직은 계속 증가하는 기타 비즈니스 핵심 애플리케이션을 관리하는 동시에 더 적은 리소스로 더 많은 작업을 해내야 하는 압박을 받는 경우가 많습니다.

많은 조직이 이런 방식으로는 지속할 수 없다고 느끼고 있습니다. 실제로 HA 솔루션의 트렌드를 조사한 SIOS 연구에 따르면 조사 당시 이미 많은 기업에서 온프레미스 애플리케이션의 가용성을 유지하는 데 어려움을 겪고 있는 것으로 나타났습니다.

조사에 참여한 기업 중 95%는 애플리케이션을 지원하는 HA 서비스에서 비정기적인 오류 이상의 오류가 발생한다고 응답했습니다.
98%는 애플리케이션 성능 문제를 정기적 또는 비정기적으로 경험한 적이 있으며 71%는 그 횟수가 한 달에 1~2회에 달한다고 응답했습니다.
조사에 참여한 기업이 HA 애플리케이션 문제가 발생했을 때 문제를 파악하고 해결하는 데 걸린다고 응답한 시간은 평균 3~5시간이었습니다.

한 기업에 녹록지 않은 방향으로 흘러가고 있습니다. 오늘날의 IT 환경에는 위험, 불확실성, 긴축 상황에 대한 전망이 우세합니다. 동시에 기업의 핵심 소프트웨어인 SAP 애플리케이션의 보안, 생산성, 가용성을 유지하는 것이 비즈니스에 특히 중요한 상황입니다.

Google Cloud에서는 SAP 환경의 고가용성과 관련된 어려움을 해결하고자 많은 고민을 했습니다. Google은 이를 고객의 사활이 걸린 문제로 보고 해결책을 제시하는 것을 우선순위로 삼고 있습니다. 즉 고가용성과 성능을 제공하도록 설계된 클라우드 플랫폼에서 안정적이고 확장 가능하며 비용 효과적인 SAP 환경을 구축하기 위해 노력하고 있습니다.

Google Cloud 사용 시 제공되는 많은 서비스는 내결함성 또는 고가용성을 갖추도록 설계됩니다. 이러한 개념은 유사하지만 그 차이를 이해하면 아키텍처를 설계할 때 드는 시간과 노력을 절약할 수 있습니다.

Google은 내결함성 구성요소를 완전히 중복된 메커니즘으로, 즉, 구성요소에 장애가 발생하더라도 원활하게 시스템 가용성을 회복하도록 설계된 것으로 간주합니다. 스토리지(Google Cloud Storage, Persistent Disk)와 네트워크(Google 네트워크, Cloud DNS, Cloud 부하 분산기) 같은 구성요소가 여기에 해당됩니다.

이에 반해 가용성이 높은 서비스는 단일 장애점으로 알려진 모든 관련 아키텍처 구성요소의 자동 복구 메커니즘을 갖추어 복구 시간 목표(RTO)와 복구 지점 목표(RPO)를 최소화합니다. 일반적으로 구성요소를 복제하여 복제본 사이의 장애 조치 프로세스를 자동화하는 과정이 수반됩니다.

Google Cloud 환경에서 SAP 가용성을 높이는 4단계

SAP 고객에게 적합한 가용성 솔루션을 제공하는 방법을 이해하기 위해서는 먼저 각 고객이 목표로 하는 가용성 SLA가 서로 다르며 이러한 목표는 비즈니스 니즈, 예산, SAP 애플리케이션 용도, 기타 요인에 따라 달라진다는 사실을 인지해야 합니다. SAP 고가용성 환경의 인프라, 운영체제, 애플리케이션 가용성 구성요소를 살펴보고 SAP 시스템의 전반적인 가용성 전략에 고려해야 하는 사항을 알아보겠습니다.

1단계: 인프라

많은 고객이 온프레미스의 SAP 시스템을 Google Cloud로 이전하는 것만으로 시스템의 업타임이 늘어날 수 있다는 사실을 깨닫습니다. 기본적으로 가용성이 높은 보안, 네트워킹, 컴퓨팅, 스토리지 기능이 이 플랫폼에 내장되어 있어 활용 가능하기 때문입니다.

컴퓨팅 서비스

컴퓨팅 서비스의 경우 Google Cloud Compute Engine에서 기본 제공하는 3가지 기능이 특별히 중요한 역할을 하며 하드웨어 장애로 인한 애플리케이션 중단을 줄이거나 방지할 수 있습니다.

라이브 마이그레이션: 고객의 VM 인스턴스가 실행 중인 호스트 시스템에 정기적인 유지보수가 필요한 경우, 라이브 마이그레이션을 사용하면 VM 인스턴스를 다른 호스트로 이전하면서도 애플리케이션 재시작이나 중단이 발생하지 않습니다. 이것은 모든 Google Cloud 사용자가 추가 비용 없이 이용할 수 있는 기본 제공 기능이며 사용자 워크로드의 규모나 복잡성에 상관없이 원활하게 자동으로 작동합니다. Google Cloud에서 하드웨어 유지보수를 수행하고 하이퍼바이저 보안 패치와 업데이트를 전역에 매끄럽게 적용하는 동안 그 어떤 고객에게도 VM 재시작을 통보할 필요가 없습니다. 라이브 마이그레이션을 활용하는 유지보수는 실행 중인 애플리케이션에 아무런 영향을 미치지 않기 때문입니다.

메모리 포이즈닝 복구(MPR): 아무리 품질이 높은 하드웨어 인프라라 하더라도 어느 순간 고장이 날 수 있으며 메모리 오류는 가장 흔한 유형의 하드웨어 오작동입니다(메모리 안정성에 관한 Google Cloud 연구 참조). 최신 CPU 아키텍처에는 오류 정정 코드(ECC)와 같이 정정 가능한 오류가 발생한 호스트를 복구하는 기본 기능이 있습니다. 하지만 정정 불가능한 오류로 인해 호스트에 발생하는 장애와 전체 VM 재시작은 예기치 않은 다운타임으로 이어집니다.

HANA 데이터베이스가 있다면 데이터를 메모리에 로드하는 데 소요되는 시간도 고려해야 합니다. 이 경우 호스트 장애는 비즈니스에 필수적인 서비스에 몇 시간에 달하는 다운타임(데이터베이스 규모 따라 다름)을 초래할 수 있습니다.

Google Cloud는 메모리 오류로 인한 장애와 다운타임을 줄이기 위해 CPU 기반 오류 처리 기능, SAP HANA, Google Cloud 기능을 통합하는 솔루션을 개발했습니다. MPR은 정정 불가능한 메모리 오류를 감지하고 라이브 마이그레이션을 통해 문제가 발생한 호스트에서 VM을 이전할 수 있을 때까지 해당 오류를 격리합니다.

빠른 재시작 기능이 사용 설정된 상태에서 SAP HANA를 호스팅하는 VM에 정정 불가능한 오류가 발견된 경우 Google Cloud MPR은 SAP HANA에 신호를 보내 문제가 발생한 메모리만 디스크에서 다시 로드하므로 대부분의 경우 다운타임 없이 문제를 해결할 수 있습니다. 이후 문제가 발생한 호스트의 모든 VM이 라이브 마이그레이션을 통해 정상 작동 호스트로 마이그레이션되어 해당 VM에서 실행 중인 고객 애플리케이션에 다운타임이나 장애가 발생하는 것을 방지합니다.

자동 다시 시작: 드물지만 예기치 않은 종료를 방지할 수 없는 경우, 이 기능이 작동하면서 자동으로 다른 호스트의 VM 인스턴스를 재시작합니다. 필요하다면 사용자가 정의해 놓은 시작 스크립트를 호출하여 VM에서 실행 중인 애플리케이션이 동시에 재시작되도록 만듭니다. 이 기능의 목표는 예기치 않은 중단이 발생할 때 복구 시간을 최대한 앞당기고, 가능한 한 사용자가 이 프로세스를 간편하고 안정적으로 사용하도록 만드는 것입니다.

단일 노드의 업타임을 늘리는 것이 이러한 서비스의 목표이지만 중요성이 높은 워크로드는 완전한 영역 서비스 중단을 비롯한 컴퓨팅 관련 장애에 대비해 복원성을 확보해야 합니다. 이를 위해 Google Cloud Compute Engine은 여러 영역에 분산된 인스턴스에 대해 99.99%의 월별 업타임 비율 SLA를 제공합니다.

네트워크 파일 시스템 스토리지(NFS)

가용성이 높은 SAP 인프라의 또 다른 중요한 구성요소는 네트워크 파일 시스템 스토리지(NFS)입니다. NFS는 인터페이스 디렉터리 및 전송 관리 같은 SAP 공유 파일에 사용됩니다. Google Cloud는 여러 파일 공유 솔루션을 제공합니다. 자사 솔루션으로는 Filestore Enterprise가 있고 타사 솔루션으로는 NetApp CVS-Performance 같은 제품이 있으며 모두 99.99% 가용성 SLA를 제공합니다. Google Cloud 기반 NFS 솔루션 비교 정보를 자세히 살펴보려면 제공된 문서를 참고하세요.

2단계: 운영체제

운영체제 수준의 컴퓨팅 구성요소를 클러스터링하는 것은 장애 조치 메커니즘에서 중요한 부분입니다. 이로써 구성요소의 장애를 신속하게 감지하고 장애 조치 절차를 트리거하여 애플리케이션 다운타임을 최소화할 수 있습니다.

Google Cloud의 OS 수준 클러스터링은 온프렘의 클러스터링 방식과 매우 유사하지만 몇 가지 기능이 추가로 개선되었습니다.

SUSE Enterprise Linux(SLES)와 Red Hat Enterprise Linux(RHEL)는 둘 다 클러스터링 리소스 관리자로 Pacemaker를 구현하고 Google Cloud용으로 설계된 클러스터 에이전트를 제공하기 때문에 STONITH 펜싱, VIP 경로, 스토리지 작업 같은 함수와 기능을 원활하게 관리할 수 있습니다. Google Cloud에 OS 클러스터를 배포할 때 고객이 HA/DR 제공업체 후크를 활용하면 SAP HANA가 알림을 발송할 수 있어 데이터 손실 없이 성공적으로 장애 조치를 취할 수 있습니다. 자세한 내용은 SAP 고가용성 배포 가이드에서 RHEL 및 SLES에서 HA 클러스터를 구성하는 방법을 자세히 다룬 문서를 참조하세요.

Windows 기반 워크로드의 경우 Microsoft 장애 조치 클러스터링 기술을 사용하며 Google Cloud에서도 클러스터를 사용 설정하고 구성할 수 있는 특별한 기능이 있습니다. 여기에서 자세한 내용이 담긴 문서를 찾을 수 있습니다.

3단계: 데이터베이스

모든 SAP 환경은 중앙 데이터베이스 시스템을 활용해 비즈니스에 필수적인 데이터를 저장하고 관리합니다. SAP 고가용성 솔루션이라면 당연히 이 데이터베이스 레이어의 가용성과 무결성을 유지할 방법을 고려해야 합니다. 게다가 SAP 시스템에서 지원하는 다양한 데이터베이스 시스템 중 많은 수가 고가용성 성능을 달성하기 위해 여러 메커니즘을 사용합니다. Google Cloud는 SAP HANA, MaxDB, SAP ASE, IBM Db2, Microsoft SQL Server, Oracle 워크로드(이 경우 베어메탈 솔루션을 사용해 HA 인증 하드웨어를 사용하고 Oracle RAC 솔루션도 설치할 수 있음)에 HA 아키텍처를 사용하는 방법을 지원하고 문서화하는 방식으로 고객에게 SAP 데이터베이스의 HA 비용과 이점을 절충하는 방법을 결정할 수 있는 자유를 줍니다.

SAP HANA 시스템 복제(HSR)는 SAP HANA 시스템의 고가용성을 보장하는 데 가장 중요한 역할을 하는 애플리케이션 기반 기술 중 하나입니다. 이 기능은 기본 시스템의 데이터를 지속적으로 하나 이상의 보조 시스템에 복제하는 방식으로 작동하며 재해가 발생하는 경우 이 데이터를 메모리로 미리 로드하여 신속하게 장애 조치할 수 있습니다.

Google Cloud는 동일한 리전의 임의 영역에 상주하는 SAP 인스턴스에 동기식 복제를 사용할 수 있도록 지원하여 HSR을 지원하고 보완합니다. 즉 사용자는 기본 인스턴스와 보조 인스턴스를 각각 다른 영역에 배치하여 한 영역에 단일 장애점이 발생하는 것을 방지할 수 있습니다.

SAP ASE 또는 IBM Db2 같은 다른 데이터베이스 시스템 역시 Google Cloud 인프라에서 실행할 수 있는 유사한 기능을 제공합니다. 같은 리전 내 영역 간 네트워크 지연 시간이 짧은 데다 자동 배포용 도구까지 지원되므로 기업은 다양한 데이터베이스 HA 옵션을 현재 비즈니스 니즈에 맞게 선택할 수 있습니다. 지원되는 데이터베이스 시스템 및 참조 아키텍처의 최근 목록은 최신 문서에서 참고하세요.

4단계: 애플리케이션 서버

SAP의 NetWeaver 아키텍처는 사용자가 HA 업타임 요구사항에 위협이 될 수 있는 앱-서버 병목 현상을 피하는 데 도움이 됩니다. Google Cloud는 고객이 동기화를 통해 데이터 손실을 방지하고 SAP NetWeaver의 안정성과 성능을 최대한 활용하는 데 필요한 고가용성 컴퓨팅 및 네트워킹 기능을 제공함으로써 이 아키텍처의 장점을 활용합니다. 이 아키텍처는 하나의 OS 수준 클러스터(SLES 또는 RHEL)에 ABAP SAP Central Services(ASCS) 및 Enqueue Replication Server(ERS)를 위한 Pacemaker 클러스터 리소스 관리자와 STONITH 펜싱을 갖추고 있으며 각각 가상 IP용 자체 내부 부하 분산기(ILB)를 포함하고 있습니다. NetWeaver 고가용성 계획 가이드에서 RHEL 및 SLES에 HA 클러스터를 배포하고 구성하는 방법을 자세히 설명한 문서를 참조하세요.

애플리케이션 서버 인스턴스를 같은 리전의 여러 영역에 분산시키면 최종 사용자에게 계속 우수한 성능을 제공하면서도 영역 단위 장애를 가장 효과적으로 방지할 수 있습니다. IT팀은 자동 배포를 통해 수요 변동에 신속하게 대응하고 트래픽이 가장 많은 상황에도 SAP 시스템이 계속 실행되도록 수시로 추가 인스턴스를 구동할 수 있습니다.

Google Cloud가 고가용성 SAP 시스템을 지원하는 그 밖의 방법

매우 어려운 상황에서도 Google Cloud가 SAP 애플리케이션 업타임을 최대로 늘릴 수 있는 방법이 그 외에도 많습니다. 몇 가지 사례를 들어 규모를 막론하고 기업에서 유사한 기능을 저렴한 비용으로 구현하는 것이 얼마나 힘든 일인지 생각해 보세요.

지리적 분포 및 중복성. Google Cloud는 현재 전 세계적으로 91개 영역과 140개가 넘는 접속 지점을 아우르는 30개 리전에서 입지를 다졌습니다. 대부분의 SAP 사용자는 핵심 Google Cloud 서비스를 한 리전 내 여러 영역에 분산시키는 방법으로 성능이나 경제성 저하 없이 가용성 목표를 달성할 수 있습니다.

강력한 성능과 다목적성을 겸비한 부하 분산 기능. 부하 분산과 지리적 분포를 SAP 애플리케이션의 가용성을 유지하는 또 다른 핵심 요인으로 생각하는 기업이 많습니다. Google Cloud는 사용자에게 가장 근접한 정상 작동 리전으로 트래픽을 유도할 수 있는 글로벌 부하 분산을 포함한 다양한 부하 분산 옵션으로 기업의 이러한 니즈를 충족합니다. Google Cloud Load Balancing은 사용자, 트래픽, 네트워크, 백엔드 상태, 기타 관련 조건의 변화에 즉각적으로 반응합니다. 또한 소프트웨어 정의 서비스 역할을 하므로 많은 기업이 실제 부하 분산 인프라를 사용할 때 겪는 확장성 및 관리 문제를 방지합니다. 내부 부하 분산기는 가용성이 높은 SAP 시스템에 중요한 역할을 하는 또 하나의 부하 분산기 서비스로서, 기본 시스템과 보조 시스템 간의 가상 IP(VIP) 구현 자동화를 지원합니다.

개발자의 업무 집중과 생산성을 유지해 주는 도구. Google Cloud의서버리스 플랫폼에는 기본 제공되는 중복성 및 부하 분산을 제공하는 관리형 컴퓨팅 및 데이터베이스 제품이 포함됩니다. 따라서 회사의 SAP 개발팀은 기본 인프라에 대해 걱정할 필요 없이 SAP 시스템에 확장 프로그램을 병렬식으로 배포할 수 있습니다. Apigee API 관리를 사용하는 기업은 SAP 시스템에 이러한 확장 프로그램의 확장 가능한 인터페이스를 제공하여 트래픽이 급증하거나 악의적인 공격이 있을 때도 백엔드 시스템을 보호할 수 있습니다. Google Cloud는 기본 도구 및 인기 있는 오픈소스 기술의 통합을 통해 CI/CD를 지원하고 최신 DevOps 조직에 소프트웨어를 보다 빠르고 안전하게 개발하는 데 필요한 도구를 제공합니다. 그뿐만 아니라 Google Cloud의 Cortex Framework는 SAP를 사용한 혁신 여정에 위험, 복잡성, 비용을 줄여주는 가속화 도구와 권장사항을 제공하고 Google Cloud 최고의 애널리틱스 기능을 원활하게 이용할 수 있는 환경을 구축해 비즈니스에 가치를 더합니다.

유연한 풀 스택 모니터링. 기업은 Google Cloud Monitoring을 통해 성능, 업타임, SAP 환경의 전반적인 상태를 자세히 파악할 수 있습니다. Google Cloud Monitoring은 Google Cloud, Amazon Web Services, 호스팅된 업타임 프로브, 애플리케이션 계측은 물론 Cassandra, Nginx, Apache Web Server, Elasticsearch 등의 애플리케이션 구성요소에서 측정항목, 이벤트, 메타데이터를 수집합니다. 또한 Cloud Monitoring이 SAP HANA용 커스텀 모니터링 에이전트 및 Cloud 운영의 운영 에이전트와 더불어 이 데이터를 사용하여 유연한 대시보드와 풍부한 시각화 도구를 지원하므로 SAP팀은 새로운 문제가 비즈니스에 영향을 미치기 전에 식별하고 수정할 수 있습니다.

HA 옵션 살펴보기

위에 기술된 내용은 Google Cloud가 SAP 인스턴스를 위해 HA를 지원하고 확장하는 여러 방식을 개괄적으로 살펴본 것에 불과합니다. 보다 자세한 내용은 Google Cloud 서비스를 사용해 SAP 환경을 위한 고가용성 아키텍처를 설정하는 방법을 기술적 측면에서 상세히 설명한 문서를 참고하세요.

Google Cloud의 혁신 중심 인프라

Wed, 24 Aug 2022 00:38:00 +0000

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

오늘날 여러 조직들은 핵심 프로세스를 더 효율적으로 만드는 일부터 고객에게 도달해 더 나은 서비스를 제공하기 위한 방법을 개선하고, 혁신의 거름이 되는 데이터에서 유용한 정보를 도출하기까지 클라우드를 사용해 목표 달성을 위한 새로운 방법을 개발하여 비즈니스의 완전한 혁신을 추구하고 있습니다.

클라우드 인프라는 모든 조직의 혁신 전략에서 핵심적인 부분을 차지합니다. Google Cloud의 주요 기능을 활용해 혁신할 수 있는 기회는 무궁무진합니다. 이러한 기능은 Google Cloud에서 솔루션을 빠르고 간단하게 빌드하는 역량에 장기적인 영향을 미칠 것입니다. Google은 데이터 관리와 머신러닝부터 보안, 지속 가능성에 이르기까지 기초로부터 가치를 창출하는 인프라 혁신에 집중적인 투자를 이어가고 있습니다. Google은 고객이 혁신을 통해 비즈니스 속도를 높일 수 있도록 인프라의 3가지 무척 중요한 속성에 초점을 맞추고 있습니다.

최적화: 고객은 구체적인 니즈를 충족하는 솔루션을 원합니다. 일반적인 워크로드, 업계 솔루션은 물론 고성능, 비용 절감, 성능과 비용의 균형 등의 특정한 결과에 따라 맞춤설정된 앱을 필요한 곳에서 빌드하고 실행하기를 원하는 것입니다. 고객의 워크로드가 Google Cloud에서 더 잘 실행되어야 하는 이유입니다.
혁신: 혁신은 비용 절감 및 편의를 위해 인프라를 클라우드로 '리프트 앤 시프트'하는 것만을 의미하지 않습니다. 혁신적인 인프라는 Google 최고의 AI 및 ML 기능을 통합하여 혁신을 가속화하면서도 가장 엄격한 보안, 주권, 규정 준수 요구사항을 충족합니다.
사용 편의성: 클라우드 플랫폼의 용도가 다양해지면 채택과 운영이 매우 복잡해질 수 있습니다. 하지만 사용하기 쉬운 클라우드 플랫폼으로 운영 부담을 줄일 수 있습니다. 종종 고객들이 Google Cloud에서는 복잡한 업무가 단순하게 느껴진다고 이야기하는데, 이는 사용 편의성을 염두에 두고 제작했기 때문입니다.

Google이 20년 넘게 기술 분야를 주도할 수 있었던 것은 혁신 문화와 고객에 대한 집중이 토대가 되었기 때문입니다. Google이 이러한 부문에 일으킨 새로운 혁신의 예를 몇 가지 소개합니다.

고객에게 가장 중요한 가치에 맞춰 최적화된 솔루션

가격 대비 성능 최적화부터 살펴보겠습니다. 작년에 Google은 수평 확장 워크로드의 비용 효율적인 성능에 최적화된 Tau VM을 출시했습니다. Tau T2D는 다른 주요 클라우드의 동급 VM에 비해 최대 42% 높은 가격 대비 성능을 제공하면서 성능과 총 소유 비용 측면에서 다른 모든 주요 퍼블릭 클라우드 제공업체를 뛰어넘었습니다.

오늘 Google은 Tau VM 제품군에 Arm 기반 머신을 추가하여 고객에게 더 많은 선택권을 제공한다는 소식을 발표했습니다. Ampere® Altra® Arm 기반 프로세서로 구동되는 T2A VM은 합리적인 가격에 우수한 단일 스레드 성능을 제공하여 수평 확장 클라우드 기반 워크로드에 이상적입니다. 이제 개발자는 워크로드를 테스트, 개발, 실행하는 데 최적의 아키텍처를 선택할 수 있게 되었습니다.

비용 최적화는 많은 Google 고객의 주요 목표입니다. 스팟 VM을 사용하면 파격적인 할인이 적용되는 유휴 머신 주기를 활용하여 주문형 가격에서 60% 보장 할인 및 최대 91% 할인을 받을 수 있습니다. 스팟 VM은 고성능 컴퓨팅, 빅데이터, 분석 부문의 일괄 작업과 내결함성 워크로드에 이상적입니다. 스팟 VM 가격의 변동성을 줄이고 예측 가능성을 높여달라는 고객 의견이 많이 접수되었습니다. Google은 고객 의견을 경청하여 가격에 반영했습니다. 그 결과, Google의 스팟 VM은 다른 주요 클라우드에 비해 가장 낮은 가격 변동성(가격 변동 월 1회)과 보다 높은 예측 가능성을 제공하고 있습니다.

글로벌 규모에 맞춘 최적화는 동영상 스트리밍을 비롯하여 오늘날 소비자의 까다로운 요구사항을 충족시키는 데 매우 중요합니다. 2022년 5월에 출시된 Media CDN은 몰입형 동영상 스트리밍 경험을 글로벌 규모로 제공하도록 최적화되었습니다. 1,300개가 넘는 도시에서 지원되는 Media CDN은 YouTube가 전 세계 20억 명 이상의 사용자에게 콘텐츠를 제공하기 위해 사용하는 것과 동일한 인프라를 활용합니다. U-NEXT, Stan 등의 고객이 Media CDN을 빠르게 도입하여 시청자들에게 최신 고품질 경험을 제공하고 있습니다.

분산 시스템 및 분산 작업자가 증가하고 필요한 곳 어디에서나 앱을 빌드하고 실행할 수 있게 되면서 또 다른 새로운 기회가 생겼습니다. 이제 Google Distributed Cloud로 Google Cloud 인프라 및 서비스를 온프레미스, 코로케이션 데이터 센터, 다양한 에지 환경 등을 포함한 여러 물리적 위치(또는 분산 환경)로 확장할 수 있게 되었습니다. Anthos가 모든 Google Distributed Cloud 제품 및 서비스를 지원하여 사용자가 선택하는 어떤 위치에서든 컨테이너화된 최신 애플리케이션을 빌드, 배포, 실행할 수 있는 공통 제어 영역을 제공합니다.

선택의 폭을 넓히기 위해 Google은 Google Distributed Cloud를 워크로드 및 사용 사례의 특정 요구사항을 해결하기 위한 여러 제품이 포함된 하드웨어, 소프트웨어, 서비스로 구성된 포트폴리오로 설계했습니다. 에지, 가상, 호스팅 제품 중에서 비즈니스 요구사항에 맞는 제품을 선택할 수 있습니다.

AI/ML 및 보안을 통한 혁신 주도

머신러닝 분야의 혁신 속도가 계속해서 빨라지고 있으며 Google은 오랫동안 이 분야에서 선구자 역할을 했습니다. Google 검색부터 YouTube, Google Play, Google 지도에 이르기까지 Google 제품이 최상의 가치를 제공하는 데 ML이 도움을 주었습니다. Google은 최고의 Google 기능을 고객에게 제공하기 위해 노력을 기울여 왔으며 JAX와 Cloud TPU v4는 이를 방증하는 좋은 예시입니다.

JAX는 Google 연구팀이 개발한 첨단 오프소스 ML 프레임워크입니다. 이 프레임워크는 ML 실무자에게 더 많은 유연성을 제공하여 모델을 최대 규모로 보다 손쉽게 확장할 수 있도록 설계되었습니다.

최근에는 새로운 ML 허브를 통해 모든 고객에게 Cloud TPU v4 포드를 제공하고 있습니다. Cloud TPU v4 포드 클러스터는 9엑사플롭스급의 최고 집계 성능을 제공하며 90%의 무탄소 에너지로 운영됩니다. 전 세계에서 가장 빠르고 효율적이며 지속 가능한 ML 인프라 허브 중 하나입니다. 연구원들은 Cloud TPU v4를 사용해 자연어 처리 모델과 추천자 모델을 비롯한 여러 정교한 모델을 학습시킬 수 있습니다. Cohere는 학습 시간이 70% 개선되었고 LG Research에서는 Cloud TPU v4를 사용해 대규모 멀티모달 3,000억 매개변수 모델을 학습시키는 등 많은 고객이 이미 그 혜택을 누리고 있습니다.

보안 측면에서는, 사이버 보안 위협이 증가함에 따라 모든 기업이 보안 태세를 재고하고 있습니다. Google은 안전하고 성능이 우수하며 안정적인 세계적 규모의 네트워크에 투자하는 한편 고객이 소프트웨어 공급망을 보다 안전하게 보호할 수 있도록 업계 전반의 프레임워크 및 표준을 정의하는 데 앞장서고 있습니다. 작년 Google에서는 SLSA(Supply-chain Levels for Software Artifacts)를 도입했습니다. SLSA는 소프트웨어 공급망 전반에서 아티팩트의 무결성을 보장하는 엔드 투 엔드 프레임워크이자 Google 내부에서 구현 중인 여러 프로세스의 오픈소스 버전입니다.

Google은 복잡한 구성이나 성능 저하 없이 보안을 실현하는 데 도전하고 있습니다. 이러한 노력의 일례로 컨피덴셜 VM을 들 수 있습니다. 컨피덴셜 VM의 경우 외부에서는 디버거를 사용하더라도 VM에서 수행되는 데이터나 작업을 볼 수 없는 신뢰할 수 있는 실행 환경에 데이터가 저장됩니다. 또 다른 예로는 Cloud Intrusion Detection System(Cloud IDS)이 있습니다. 이 제품은 ML 기반 위협 분석을 토대로 한 네트워크 위협 감지를 제공하며 매일 430만 개의 고유한 보안 업데이트를 통해 새로운 위협을 식별하기 위하여 하루 15조 개가 넘는 트랜잭션을 처리합니다. CyberRatings.org에서 가장 높은 평점인 AAA를 받은 Cloud IDS는 거의 모든 방어 회피를 차단하는 효과를 입증했습니다.

개발자 중심의 사용 편의성

Google은 고객이 혁신을 가속화할 수 있도록 사용하기 쉬운 도구로 혁신 여정을 간소화하는 데 우선순위를 두고 있습니다. 오늘 Google에서는 Batch 미리보기 버전을 선보입니다. 이 완전 관리형 작업 스케줄러는 고객이 단일 명령어로 수천 개의 일괄 작업을 실행하도록 지원합니다. 간단하게 설정할 수 있으며 요구 사항이 까다로운 MPI 라이브러리를 비롯한 처리량 지향 워크로드를 지원합니다. 작업이 자동 확장 가능한 리소스에서 실행되므로 개발자에게 가장 중요한 작업을 처리할 수 있는 시간 여유가 생깁니다. 이에 따라 유전체 염기서열 분석, 미디어 렌더링, 금융 리스크 모델링, 전자 설계 자동화 등의 HPC, AI/ML, 데이터 처리 워크로드를 실행하는 개발자 환경이 개선됩니다.

계속해서 더욱 쉽게 혁신을 이룰 수 있도록 최근에는 새로운 HPC Toolkit의 출시를 발표했습니다. Google Cloud의 이 오픈소스 도구를 사용하면 입증된 권장사항에 따라 반복 가능하고 즉시 사용이 가능한 HPC 클러스터를 몇 분 만에 간편하게 만들 수 있습니다. 여러 청사진은 물론 Slurm 스케줄러, Intel DAOS, DDN Lustre 스토리지와 같은 서드 파티 구성요소에 대한 폭넓은 지원도 제공합니다.

시스템 성능 및 인프라가 수행하는 작업에 대한 이해는 보안과 밀접한 관련이 있지만, 이를 잘 수행하려면 사용하기 쉬워야 합니다. Google에서 최근에 선보인 네트워크 분석기는 고객이 사후 대응 워크플로를 사전 예방 프로세스로 변환하고 VPC 네트워크 구성을 자동으로 모니터링하여 네트워크 및 서비스 다운타임을 줄이도록 도와줍니다. Network Intelligence Center의 일부인 네트워크 분석기는 Google Cloud 네트워크 관측 가능성, 모니터링, 문제 해결을 위한 단일 콘솔을 제공합니다.

지금까지 소개한 내용은 고객이 손쉽고 혁신적이며 최적화된 플랫폼에서 안전하게 혁신하고 온프레미스에서 에지, 클라우드로 확장할 수 있는 인프라를 제공하기 위한 Google Cloud의 노력을 보여주는 일부 사례에 불과합니다. Broadcom 및 Snap과 같은 고객이 Google Cloud의 유연한 인프라를 사용하여 어떻게 가장 큰 난관을 해결하고 있는지 자세히 알아보려면 오늘 방송되는 Infrastructure Spotlight 이벤트를 시청하세요.

클라우드 위 구름(cloud): Google Cloud에서 기상 예측

Tue, 12 Jul 2022 00:00:00 +0000

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

기상 예측과 기후 모델링은 세상에서 가장 복잡한 컴퓨팅이 요구되는 까다로운 작업에 해당합니다. 특히 시간에 매우 민감하고 수요가 높습니다. 주말 나들이객부터 대규모 산업형 농장 운영자에 이르기까지 모두가 최신의 기상 예측 정보를 원합니다. 기상 예보관은 의미 있는 예측을 적시에 제공하기 위해 일반적으로 온프레미스 데이터 센터에 호스팅된 고성능 컴퓨팅(HPC) 클러스터를 이용합니다. 이 온프렘 HPC 시스템은 막대한 자본을 투자해야 하고 장기간 많은 운영비가 발생합니다. 전력 소모가 심하고 구성의 대부분이 고정적이며 기본 컴퓨터 하드웨어의 교체 주기 역시 경직되어 있습니다.

클라우드를 이용할 경우 유연성 향상, 지속적인 하드웨어 업그레이드, 높은 안정성, 지리적으로 분산된 컴퓨팅과 네트워킹, '사용한 만큼 비용을 지불하는' 가격 모델 등 다양한 이점을 누릴 수 있습니다. 그 결과 클라우드 컴퓨팅을 이용하는 기상 예보관과 기후 모델러는 최신 하드웨어 및 소프트웨어 시스템을 사용하는 유연한 플랫폼에서 비용 효율적인 방식으로 정확한 결과를 시의적절하게 제공할 수 있게 됩니다. 이러한 접근은 기존의 기상 예측 방식과 크게 다르기 때문에 어려워 보일 수 있습니다. 이제 기상 예보관은 Google Cloud에서 Fluid Numerics의 새로운 WRF VM 이미지를 사용하여 손쉽게 WRF(Weather Research and Forecasting)를 실행하고 저렴한 비용으로 온프레미스 슈퍼 컴퓨터의 성능을 구현하는 데 도움을 얻을 수 있습니다. 이 솔루션을 사용하면 기상 예보관이 Google Cloud에서 WRF 시뮬레이션을 준비하고 실행하는 데 1시간이 채 걸리지 않습니다.

WRF 자세히 살펴보기

WRF(Weather Research and Forecasting)는 연구원과 운영 조직 모두 활발히 사용하는 오픈소스 기반의 수치형 기상 예측 모델링 시스템입니다. WRF가 주로 기상 및 기후 시뮬레이션에 사용되지만 화학적 상호작용, 산불 모델링 등 다양한 사용 사례를 지원하도록 WRF의 기능을 확장했습니다. WRF 개발은 1990년대 후반 미국 국립 대기 연구 센터(NCAR), 미국 해양대기청(NOAA), 미국 공군 및 해군 연구소(U.S. Air Force, Naval Research Laboratory), 오클라호마 대학교, 연방항공국의 협업을 통해 시작되었습니다. WRF 커뮤니티는 대기 연구와 운영 예측을 지원한다는 공동의 목표 아래 160여 개국의 48,000명이 넘는 사용자로 구성되어 있습니다.

Google Cloud WRF 이미지는 Google의 HPC 관련 MPI 권장사항을 토대로 빌드되지만 예외적으로 하이퍼스레딩이 기본적으로 사용 중지되고, Google Cloud에서 SchedMD의 Slurm-GCP 등의 다른 HPC 솔루션과 손쉽게 통합됩니다. 일반적으로 WRF 및 관련 종속 항목을 설치하는 데는 많은 시간이 소요됩니다. 새로운 WRF VM 이미지를 이용하면 WRF v4.2가 사전 설치된 확장 가능한 HPC 클러스터를 Codelab을 통해 빠르고 쉽게 배포할 수 있습니다. 이전에는 이 작업 전반에서 OpenMPI 4.0.2를 사용했습니다. Google은 Intel MPI로 성공적인 결과를 얻었으며 이 사례에서 추가적인 성능 개선의 여지가 있는지 조사하고자 합니다.

WRF 최적화

WRF 이미지 개발 과정에서 핵심은 성능과 비용을 고려하여 최적의 아키텍처와 빌드 설정을 결정하는 것이었습니다. Google이 이상적인 컴파일러와 적절한 CPU 플랫폼, 파일 IO 처리에 가장 적합한 파일 시스템을 선택하는 방법을 평가했으므로 이제 고객은 그럴 필요가 없습니다. 성능 평가의 테스트 사례로는 CONUS 2.5km 벤치마크를 사용했습니다.

아래의 CONUS 2.5km 런타임 및 비용 그림은 Google Cloud에서 사용 가능한 다양한 머신 유형을 대상으로 (수치화 프로세스를 통해) 480개 MPI 랭크를 사용한 2시간 예측에서 WRF를 시뮬레이션하는 데 필요한 런타임을 보여줍니다. 머신 유형별로 컴파일러, 컴파일러 최적화, 작업 어피니티를 달리 하여 여러 테스트를 진행하고 여기서 측정된 최저 런타임을 보여줍니다.

컴퓨팅 최적화된 c2 인스턴스의 런타임이 가장 짧은 것으로 확인되었습니다. Slurm 작업 스케줄러를 사용하면 작업 어피니티 플래그를 사용하여 컴퓨팅 하드웨어에 MPI 작업을 매핑할 수 있습니다. 각 머신 유형의 런타임과 비용을 최적화할 때는 WRF 실행을 위해 각 MPI 프로세스를 실제 코어(MPI 랭크당 vCPU 2개)에 매핑하는 srun –map-by core –bind-to core와 각 MPI 프로세스를 vCPU 1개에 매핑하는 srun –map-by thread –bind-to thread를 사용하는 사례를 비교했습니다. 코어별로 매핑하고 MPI 랭크를 코어에 바인딩하는 것은 하이퍼스레딩을 사용 중지하는 것과 유사합니다.

각 플랫폼에서 CONUS 2.5km의 시뮬레이션 비용과 런타임이 가장 이상적인 경우는 각 MPI 랭크가 각 vCPU에 구독될 때입니다. vCPU에 바인딩하는 경우 필요한 컴퓨팅 리소스가 실제 코어에 바인딩할 때의 절반에 불과하므로 시뮬레이션의 초당 비용이 줄어듭니다. CONUS 2.5km의 경우, MPI 랭크를 코어에 매핑하면 동일한 수의 MPI 랭크에 대해 런타임이 감소하는 결과가 나타났지만 성능상의 이점이 비용 절감 효과를 능가할 만큼 크지는 않습니다. 이런 이유로 WRF-GCP 솔루션은 기본적으로 하이퍼스레딩을 사용 중지하지 않습니다.

이상적인 컴파일러를 선택하면 런타임과 시뮬레이션 비용을 더욱 절감할 수 있습니다. 아래 그림(CONUS 2.5km 컴파일러 비교)은 GCC 10.30, GCC 11.2.0, Intel® OneAPI® 컴파일러(v2021.2.0)를 사용하여 8개 c2-standard-60 인스턴스에 대해 실행한 WRF CONUS 2.5km 벤치마크에 대한 시뮬레이션 런타임을 보여줍니다. 어떤 방식을 사용하든 WRF는 수준 3 컴파일러 최적화와 Cascade Lake 대상 아키텍처 플래그를 사용하여 빌드됩니다. WRF를 Intel® OneAPI® 컴파일러로 컴파일하면 WRF 시뮬레이션 속도가 GCC 빌드보다 47% 더 빨라지므로 동일한 하드웨어에서 약 68%의 비용으로 실행할 수 있습니다. 이 작업에는 MPI 구현으로 각 컴파일러와 함께 OpenMPI 4.0.2가 사용되었습니다. 다른 애플리케이션의 경우 Intel MPI 2018에서 양호한 성능이 확인되었으므로 이 구현과 다른 MPI 구현에서 성능을 비교하는 조사를 실시하려고 합니다.

MPI 랭크 수가 증가하면 WRF의 파일 IO가 심각한 병목 현상을 유발할 수 있습니다. 최적의 파일 IO 성능을 얻으려면 WRF에서 병렬 파일 IO를 사용하고 Lustre와 같은 병렬 파일 시스템을 이용해야 합니다.

아래에서는 파일 IO 활동의 속도 향상을 NFS 파일 시스템의 직렬 IO와 비교하여 보여줍니다. 이 예에서는 MPI 랭크 수가 960개인 조건에서 c2-standard-60 인스턴스에 대해 CONUS 2.5km 벤치마크를 실행합니다. WRF의 파일 IO 전략을 병렬 IO로 변경할 경우 파일 IO 시간이 60배 빨라집니다.

또한 Fluid Numerics의 오픈소스 Lustre Terraform 코드형 인프라에서 배포된 Lustre 병렬 파일 시스템을 사용하여 IO 속도를 높이고 시뮬레이션 비용을 절감합니다. Lustre는 Google Cloud Marketplace의 DDN EXAScaler 솔루션 지원을 통해서도 이용할 수 있습니다. 이 경우 Lustre OSS(Object Storage Service) 인스턴스에 4개의 n2-standard-16 인스턴스를 사용하고 각 로컬 SSD는 3TB입니다. Lustre MDS(Metadata Server)는 n2-standard-16 인스턴스이고 1TB의 PD-SSD 디스크를 사용합니다. Lustre 파일 시스템을 클러스터에 마운트한 후 파일 IO가 4개 OSS 인스턴스에 분산될 수 있도록 Lustre 스트라이프 수를 4로 설정합니다. IO에 대해 Lustre 파일 시스템을 사용하도록 전환하여 파일 IO를 193배 가속화합니다. 이는 직렬 IO를 지원하는 1개 NFS 서버보다 몇 배 더 빠른 수치입니다.

컴퓨팅 리소스를 추가하고 MPI 랭크 수를 늘리면 시뮬레이션 실행 시간이 줄어듭니다. 이상적으로는 완벽한 선형 확장으로 MPI 랭크 수를 두 배로 늘리면 시뮬레이션 시간이 절반으로 단축되게 됩니다. 하지만 MPI 랭크를 추가하면 통신 오버헤드가 늘어나므로 시뮬레이션당 비용이 증가할 수 있습니다. 통신 오버헤드는 문제를 더 많은 머신에 골고루 분산하기 위해 필요한 통신의 양이 늘어나기 때문에 발생합니다.

MPI 랭크 수를 순차적으로 두 배씩 늘려 일련의 모델 예측을 실행하는 방법으로 CONUS 2.5km 벤치마크에 대해 WRF의 확장성을 평가할 수 있습니다. 아래에는 MPI 랭크 수를 480개에서 1,920개로 변경하면서 Lustre 파일 시스템을 사용하여 c2-standard-60 인스턴스에 대해 실행한 2시간 예측이 나와 있습니다. 이 모든 실행에서는 MPI 랭크 수가 증가함에 따라 각 시뮬레이션의 전용 vCPU 수도 증가하도록 MPI 랭크가 vCPU에 결속되어 있습니다. 많은 HPC 워크로드는 동시 멀티스레딩(SMT)이 사용 중지된 상태에서 실행하는 것이 가장 좋지만 CONUS 2.5km의 경우에는 SMT를 사용 설정한 상태에서 성능이 가장 우수한 것으로 확인됩니다. 따라서 본 실행에서는 MPI 랭크 수가 vCPU의 총 수와 동일합니다.

여기에 나와 있는 CONUS 2.5km 런타임 및 비용 확장 그림에서는 MPI 랭크 수와 컴퓨팅 리소스 양이 최소한 1,920개 랭크까지 증가하는 과정에서는 런타임(파란색 막대)이 감소한다는 것을 알 수 있습니다. MPI 랭크를 480개에서 960개로 전환하면 런타임이 줄고 속도가 약 1.8배 빨라집니다. 1,920개 MPI 랭크로 다시 두 배로 늘린 경우에는 속도가 추가적으로 1.5배 증가하는 데 그쳤습니다. 이렇게 MPI 랭크 증가 대비 속도 증가분이 줄어드는 추세를 통해 MPI 랭크가 증가할수록 MPI 오버헤드가 커지는 것을 알 수 있습니다.

최적의 사례 결정

WRF와 같이 긴밀하게 결합되는 대부분의 MPI 애플리케이션에서 이러한 확장 동작이 나타나며 MPI 랭크가 증가할수록 확장 효율성은 감소합니다. 따라서 총 소유 비용(TCO)을 고려할 때는 성능 대비 확장과 더불어 비용 대비 확장을 평가해야 합니다. 다행히 Google Cloud에서는 초 단위로 요금이 청구되므로 이러한 분석을 더 쉽게 수행할 수 있습니다. 위 그림과 같이 두 번째로 코어 수를 두 배를 늘린 경우인 960개에서 1,920개로 늘린 경우에는 속도가 1.5배 더 빨라지지만 비용도 32% 증가합니다. 상황에 따라 추가 비용을 감수할 만큼 이러한 빠른 처리가 필요한 경우가 있을 수 있습니다.

WRF를 빠르게 시작하고 CONUS 2.5km 벤치마크를 실험하고 싶은 고객을 위해 Google은 이 배포를 Terraform 스크립트로 캡슐화하고 관련 Codelab도 마련했습니다.

Google Cloud의 고성능 컴퓨팅 서비스에 대한 자세한 내용은 https://cloud.google.com/hpc에서 확인할 수 있으며 Google 파트너 Fluid Numerics에 대한 자세한 내용은 https://www.fluidnumerics.com을 참조하세요.

Cloud OnAir 디지털 컨퍼런스 - Infrastructure Modernization

Wed, 04 May 2022 00:00:00 +0000

다가오는 5월 11일, Google Cloud OnAir 디지털 컨퍼런스가 개최됩니다. 이번 디지털 컨퍼런스에서는 Google Cloud의 Infrastructure Modernization에 대해 함께 알아가는 시간을 가지려고 합니다.

Google Cloud와 파트너는 인프라를 유연하게 현대화하는 여러 방식을 제공하고 있습니다. 이 중, Google Cloud 기반으로 기업 애플리케이션과 환경을 위한 경제적인 백업&DR 방안, 인프라 현대화를 위해 비용을 최적화하는 방법, 그리고 컨테이너 운영환경을 통합 관리할 수 있는 Anthos에 대해 알아봅니다.

시각	표제	발표자
오후 1:00 - 오후 1:05	인사말	김세휘 Customer Engineer Google Cloud 진광훈 Customer Engineer, Infrastructure Modernization Google Cloud
오후 1:05 - 오후 1:25	Google Cloud 기반 백업/DR 방안 알아보기 기업 어플리케이션/환경을 위해 Google Cloud 기반으로 확장가능하면서도 경제적인 백업 방안과 운영 다운타임 최소화를 위한 원격 DR 사이트 구현 방안을 알아봅니다.	김세휘 Customer Engineer Google Cloud
오후 1:25 - 오후 2:05	인프라 비용을 효율적으로 최적화 하는 방법 인프라 환경 내에서 비용을 최적화 할 수 있는 여러 이론과 방법을 이야기해 봅니다. 사용자의 실제 환경에서 적용 가능한 방안을 모색합니다.	김세휘 Customer Engineer Google Cloud 진광훈 Customer Engineer, Infrastructure Modernization Google Cloud
오후 2:05 - 오후 2:10	휴식
오후 2:10 - 오후 2:35	하이브리드/멀티 클라우드 관리, Anthos 알아보기 Build once, Run anywhere. 온프레미스 부터 멀티 클라우드까지, 컨테이너 운영환경을 통합 관리할 수 있는 Anthos에 대해 알아봅니다.	이동민 Cloud Consultant Google Cloud
오후 2:35 - 오후 2:55	퀴즈 이벤트
오후 2:55 - 오후 3:00	맺음말

Google Cloud OnAir 디지털 컨퍼런스는 링크를 눌러 등록하실 수 있습니다. 많은 관심과 참여 바랍니다.

Google Cloud Marketing 팀 드림

소매업체가 Google Cloud로 민첩성과 복원력을 향상시킬 수 있는 방법

Mon, 28 Mar 2022 00:00:00 +0000

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

코로나19로 인해 소비자가 상품과 서비스를 구매하는 방식이 크게 달라졌지만 사실 이러한 변화는 성장 추세를 더욱 앞당겼을 뿐입니다. 갑작스런 전환에 당황한 소매업체도 많지만 대다수의 소매업체는 영구적으로 정착될 가능성이 높은 소비자 행동 및 기대의 변화에 대응하여 클라우드 혁신 이니셔티브에 더욱 매진하고 있습니다. 소매업체들은 제품을 효과적으로 홍보하고, 고객 지원을 확대하며, 수요 수준을 예측하고, 계속 높아지는 고객의 기대치를 충족시키는 데 필요한 속도와 대응력을 확보하기 위해 온프레미스 워크로드를 클라우드로 마이그레이션할 필요성을 깨닫고 있습니다. 관건은 최대한 빠르고 효과적이며 비용 효율적으로 마이그레이션하는 동시에 업무 중단을 최소화하는 것입니다. Google Cloud VMware Engine과 같은 솔루션을 활용하면 소매업체에서 온프레미스 애플리케이션을 클라우드로 이전하여 관련성과 경쟁력을 유지하는 데 필요한 확장성, 인텔리전스, 속도를 확보할 수 있습니다.

클라우드의 이점 확보

최근 MIT¹에서 진행한 설문조사*에서 소매업 IT 리더의 75%가 팬데믹으로 인해 비즈니스 프로세스 개선, 운영 효율성 증가, 고객 경험 향상을 위한 자사의 디지털 혁신 프로젝트를 가속화했다고 답했습니다. 클라우드 컴퓨팅은 디지털 혁신의 핵심입니다. 클라우드 컴퓨팅은 점점 더 빨라지는 변화 속도에 대응하는 데 필요한 확장성, 분석 능력, 민첩성을 소매업체에 제공합니다. 소매업체는 IT 리소스를 클라우드로 마이그레이션함으로써 혁신적인 모바일 앱을 개발 및 배포하고, 콜센터와 같이 비용이 많이 드는 서비스를 가상화하고, 비즈니스 프로세스를 자동화하고, 대량의 데이터를 분석하여 수요 예측의 속도와 정확성을 개선할 수 있습니다. 클라우드에서 애플리케이션을 실행하면 비즈니스 관리자와 IT 부서가 변경 없이 온프레미스 시스템의 기능을 복제할 수 있어 언제 어디서나 직원, 고객, 파트너가 시스템에 액세스할 수 있습니다. 또한 클라우드에서 운영하면 소매업체의 비즈니스를 방해하던 기존 시스템의 많은 제한사항도 피할 수 있습니다.

이는 소매업체가 애플리케이션과 데이터를 클라우드로 마이그레이션할 때 얻을 수 있는 이점 중 일부에 불과합니다.

새로운 수익원 구축: 클라우드 인프라의 속도와 안정성을 토대로 옴니채널 쇼핑을 실행할 수 있습니다.
인공지능 및 데이터 분석 활용: 클라우드에서 인공지능과 데이터 분석을 사용할 수 있습니다. Google Cloud의 BigQuery를 사용해 AI 기반 예측 모델을 실행하면 수요를 예측하고 판매, 주문, 기타 활동을 계획하는 데 정확도를 높일 수 있습니다. Recommendations AI를 배포하면 규모에 맞게 고도로 맞춤화된 제품 추천을 고객에게 제공할 수 있습니다.
운영 효율성 개선: 탄력적이고 확장성이 뛰어난 환경이 제공되므로 물리적 인프라에 대대적으로 선불 투자하는 대신 자사에 필요한 컴퓨팅 및 스토리지 비용만 지불하면 됩니다.
고객 경험 개선: 행동 및 기타 데이터를 분석하여 고객이 원하는 사항을 적절한 시기에 제공합니다. 또한 맞춤 모바일 및 웹 애플리케이션을 빌드하고 고객 서비스 및 현장 인력에게 실시간 정보를 제공하여 고객의 문제를 신속하고 효과적으로 해결할 수 있도록 합니다.
비용 절감: AI 기반 에이전트를 배포하면 간단한 문제는 고객이 직접 해결하도록 돕고 일상적인 백오피스 절차를 자동화하여 팀에서 더 가치 있는 작업에 집중할 수 있습니다.
고객 데이터 보호: Google Cloud의 멀티 레이어, 보안 내재화 설계 인프라, 내장 보호 기능, 글로벌 네트워크를 통해 고객 데이터를 보호합니다.
제어 개선: 통합 클라우드 관리 도구로 IT 인력이 온프레미스 시스템 및 클라우드의 전체 스택을 한 자리에서 감독할 수 있습니다.

Google Cloud VMware Engine을 사용한 쉬운 리프트 앤 시프트

소매업체에서 완전히 새로운 애플리케이션을 배포하지 않고도 Google Cloud를 활용할 수 있습니다. 코드를 다시 작성할 필요 없이 백오피스 애플리케이션 및 기타 비즈니스 시스템을 그대로 클라우드로 이전할 수 있습니다.

Google Cloud VMware Engine을 사용하면 비즈니스에서 온프레미스 워크로드 및 애플리케이션을 클라우드로 원활하게 마이그레이션하거나 확장할 수 있습니다. 즉, IT 관리자가 기존 애플리케이션을 다시 빌드할 필요 없이 단 몇 분 만에 클라우드로 이전할 수 있습니다. 클라우드에서 POS(point-of-sale) 시스템, 가상 데스크톱, 기타 기기 등의 기존 애플리케이션을 매장이나 사무실에 설치되어 있을 때처럼 실행할 수 있습니다.

Google Cloud VMware Engine에서는 현재 도구의 변경 없이 기본적으로 VMware 워크로드를 실행하는 소프트웨어 정의 인프라를 만듭니다. 이 인프라에는 개별 고객 전용의 컴퓨팅 성능, 스토리지, 네트워크 연결, 보안 서비스가 포함되어 있습니다.

새로운 소매업 현실에 맞는 클라우드 인프라

코로나19로 인해 많은 소매업체가 소비자 행동과 기대의 영구적인 변화에 대응하여 혁신 이니셔티브에 집중해야 했다는 사실을 깨닫게 되었습니다. 이러한 혁신을 위해서는 비용이 많이 드는 서비스 중단이나 다운타임 없이 최대한 빠르고 효과적이며 비용 효율적으로 클라우드로 전환하는 것이 필수입니다. Google Cloud VMware Engine을 사용하는 소매업체는 몇 분이면 끝나는 간단한 리프트 앤 시프트 프로세스를 통해 이를 달성할 수 있습니다. 클라우드로 전환한 소매업체는 정교한 데이터 분석, 고객 경험 개선, 엔터프라이즈 수준의 보안, 비용 절감 등 Google Cloud가 제공하는 수많은 이점을 활용할 수 있습니다.

소매업 백서를 읽고 Google Cloud VMware Engine을 사용하면 얼마나 쉽게 소매업 IT 시스템을 클라우드로 마이그레이션할 수 있는지 알아보세요.

_{1. MIT Technology Review Insights에서 전 세계 소매업계 기술 및 비즈니스 리더 100명을 대상으로 VMware와 관련해 코로나19 및 코로나19가 기술에 미치는 영향을 주제로 진행한 설문조사}

저렴한 메시지에 가용성까지 높아진 Pub/Sub 라이트

Thu, 24 Feb 2022 00:00:00 +0000

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

복원력이 우수한 데이터 분석 파이프라인을 구축할 때 절충점을 찾는 데 어려움을 겪는 경우가 많습니다. 안정성을 높이려면 비용이 상승하고 비용을 절감하려면 운영 관리에 더 많은 수작업이 들 수 있기 때문입니다. Cloud Pub/Sub팀에서는 귀사에서 워크로드를 고려해 비용, 안정성, 관리 수준을 최적화할 수 있는 유연성을 제공하고자 합니다. 이에 따라 비용과 고가용성 사이에서 조화를 이룰 수 있는 추가적인 메시지 옵션을 도입합니다. 이 새로운 Pub/Sub 라이트 기능을 리전별 주제라고 합니다.

두 영역을 사용하여 영역의 장애 발생 위험에서 보호

Pub/Sub 라이트는 매우 저렴한 고용량 메시지 서비스입니다. 이전에는 비용을 절감하려면 모든 라이트 주제를 영역별로 작성하고 하나의 영역에 저장해야 했습니다. 이제 Pub/Sub 라이트에서는 리전별 주제를 제공합니다. 리전별 주제는 영역별 주제와 달리 한 영역이 아니라 두 영역에 비동기식으로 복제됩니다. 이러한 복제 덕분에 리전별 주제의 월간 업타임 비율 SLO는 영역별 주제의 해당 비율(99.5% 이상)보다 높은 99.95% 이상에 달합니다.

비용과 가용성의 조화

비용을 낮춰야 하지만 영역별 서비스 중단을 막아야 한다면 리전별 라이트 주제가 적합합니다. 리전별 라이트 주제는 가용성과 가격 면에서 영역별 라이트 주제와 더욱 견고한 Pub/Sub(3개 영역에서 복제됨) 사이에 조화를 이룹니다.

리전별 주제는 서버 및 디스크 장애로부터 데이터를 보호하도록 설계됩니다. 리전별 주제에 메시지를 게시하면 서비스가 기본 영역의 디스크에 메시지를 작성합니다. 이 작업이 성공하면 즉시 확인을 받게 됩니다. 이와 동시에 같은 메시지가 보조 영역에 복사됩니다. 시스템에서 클라이언트에 응답하기 전에 복제가 성공된 것을 확인할 때까지 기다리지 않기 때문에 복제는 비동기식으로 이루어집니다. 한 복사가 실패하면 디스크의 데이터가 기본 복사와 보조 복사 사이에 정기적으로 조정됩니다.

리전별 주제의 장점은 내구성 향상에 그치지 않습니다. 머신, 프로그램, 연산자 오류, 소프트웨어 업그레이드 또는 자연 재해로 인해 영역 장애가 부분적으로나 전체적으로 발생할 수 있습니다. 이례적으로 영역 사용이 일시 중단되면 리전별 주제가 원활한 장애 조치를 통해 보조 영역으로 전달됩니다. 자세한 내용은 문서를 참조하세요.

리전별 라이트 주제의 비용은 Pub/Sub 주제와 영역별 라이트 주제 사이에서 책정됩니다. 리전별 라이트 주제의 비용은 영역별 라이트 주제보다 3~4배 비쌀 수 있지만 Pub/Sub 주제에 비해서는 3분의 1에 불과합니다. 구독자 한 명당 게시 처리량이 10MiB/s인 예시 워크로드의 경우 월간 비용이 영역별 라이트 주제는 $169, 리전별 라이트 주제는 $608, Pub/Sub는 $2,000입니다. Pub/Sub에서 리전별 라이트 주제로 전환하면 약 70%가 절감되는 것입니다. 리전별 Lite 주제도 예약을 사용해야 합니다. 자세한 내용은 가격 책정 페이지를 참조하세요.

지금 Pub/Sub 라이트에서 리전별 주제를 사용해 보세요

리전별 주제는 영역별 주제와 거의 동일한 방식으로 만들 수 있습니다. 주제 위치에 영역 대신 리전을 고르면 됩니다. Google Cloud Console에서 만들어 보세요.

Pub/Sub와 Pub/Sub 라이트를 선택할 때의 차이점을 자세히 알아보려면 여기를 클릭하세요.

BigQuery에서 SAP 데이터 모델링 시 설계 고려사항

Fri, 31 Dec 2021 00:00:00 +0000

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

지난 몇 년 동안 많은 조직이 SAP 솔루션을 Google Cloud로 마이그레이션하여 이점을 경험했습니다. 이러한 마이그레이션은 IT 유지보수 비용을 절감하고 데이터 보호를 강화하는 것 외에도 많은 이점을 제공합니다. SAP 고객은 BigQuery를 활용하여 기업 데이터를 통합하고 Google의 강력한 데이터 세트와 머신러닝을 통해 간편하게 확장하여, SAP 투자를 보완하고 최신 통계를 확보할 수 있습니다.

선도적인 클라우드 데이터 웨어하우스인 BigQuery는 완전 관리형 서버리스 서비스로, 페타바이트급 대형 쿼리를 고속으로 지원할 수 있습니다. SAP 데이터를 Google Analytics나 Salesforce 같은 추가 데이터 소스와 간편하게 결합할 수 있고 내장 머신러닝을 통해 비교적 저렴한 비용으로 표준 SQL을 사용하는 머신러닝 모델을 운영할 수 있습니다.

BigQuery의 장점을 활용하여 분석 역량을 향상하려는 SAP 기반 조직이라면 SAP 데이터 모델링 시 고려사항 및 권장사항에 대해 알아보세요. 본 가이드라인은 고객에게 실제 구현한 경험을 기반으로 작성되었으며 기업에 필요한 분석 역량을 구축하기 위한 로드맵 역할을 할 수 있습니다.

데이터 복제 시 고려사항

대부분의 기술 여정과 마찬가지로 데이터 복제도 비즈니스 목표부터 시작해야 합니다. 설계 프로세스 초기 단계에 적절한 결정을 내리기 위해서는 의도한 비즈니스 가치와 목표를 염두에 두어야 합니다.

SAP 시스템에서 BigQuery로 데이터를 복제하는 방법은 여러 가지가 있습니다. 다음 질문에 답하여 조직에 가장 적합한 방법을 결정하세요.

기업에 실시간 데이터가 필요한가요? 과거 데이터를 활용해야 하나요?
복제된 데이터에 어떤 외부 데이터 세트를 조인해야 하나요?
소스 구조나 비즈니스 로직이 변경될 가능성이 있나요? 조만간 SAP 소스 시스템을 마이그레이션할 예정인가요? 예를 들어 SAP ECC에서 SAP S/4HANA로 마이그레이션할 계획인가요?

아울러 테이블별로 복제할지 아니면 팀이 사전 빌드된 로직에서 데이터를 복제할 수 있는지도 판단해야 합니다. 이에 대한 결정과 더불어 라이선스 같은 기타 고려사항에 따라 어떤 복제 도구를 사용해야 하는지가 정해집니다.

테이블별 복제

특히 원시 형태 표준 테이블의 경우 테이블을 복제하면 소스를 재사용하고 소스 구조 및 기능 출력의 안정성을 개선할 수 있습니다. 예를 들어 판매 주문 헤더(VBAK)용 SAP 테이블은 SAP 버전에 따라 구조가 바뀔 가능성이 매우 낮으며, 테이블에 작성하는 로직이 복제된 테이블에 영향을 미치는 방식으로 변경될 가능성도 낮습니다.

추가 고려사항: 윈시 테이블을 비교할 때 소스 시스템과 BigQuery의 랜딩 테이블 사이의 조정이 선형이기 때문에 기말 마감과 같은 중요 비즈니스 프로세스 중 통합 문제를 방지하는 데 유용합니다. 복제된 테이블은 집계되거나 프로세스 전용 데이터 변환에 영향을 받지 않기 때문에 동일한 복제된 열이 다른 BigQuery 뷰에서 재사용될 수 있습니다. 예를 들어 MARA 테이블(자료 마스터)을 한 번 복제하면 필요한 만큼 많은 모델에서 사용할 수 있습니다.

사전 빌드된 로직 복제

SAP 추출기나 CDS 뷰와 같이 사전 빌드된 모델을 복제하는 경우 기존 로직을 사용하기 때문에 BigQuery에 로직을 빌드하지 않아도 됩니다. 일부 추출 객체에서 델타 메커니즘을 삽입하여 델타를 처리할 수 없는 복제 도구를 보완할 수 있습니다. 이에 따라 초기 개발 시간이 절약되지만 새 열을 만들거나 맞춤설정 또는 업그레이드로 추출용 로직이 변경되면 문제가 발생할 수 있습니다.

또한 다양한 추출 프로세스가 동일한 소스 열을 여러 번 변환하고 로드함에 따라 BigQuery에 중복이 발생하고 유지보수 필요성과 비용이 증가할 수 있습니다. 하지만 사전 빌드된 모델을 복제하면 계층 구조 평면화 같이 변경 불가능한 로직이나 매우 복잡한 로직에 특히 유용할 수 있으므로 여전히 좋은 선택이 될 수 있습니다.

복제 방식은 장기 계획과 더불어 개발자의 가용성(및 호기심)과 개발자가 새로운 데이터 웨어하우스에 SQL 지식을 적용하는 데 쏟을 수 있는 시간이나 노력 같은 다른 핵심 요소에도 좌우됩니다.

BigQuery는 상시 추가하는 데이터베이스로 고안되었기 때문에 복제 프로세스를 설계할 때 어느 복제 방식을 선택하더라도 데이터 후처리와 변경이 필요하다는 것을 명심해야 합니다.

데이터 변경사항 처리

어떤 복제 도구를 선택하는지에 따라 변경 데이터 캡처(CDC)로 알려진 데이터 변경사항 캡처 방식도 달라집니다. SAP SLT에서와 같이 복제 도구에서 허용되는 경우 BigQuery를 통한 CDC 문서에 설명된 동일한 패턴이 SAP 데이터에도 적용됩니다.

트랜잭션 같은 일부 데이터는 마스터 데이터 같은 다른 데이터보다 덜 정적으로 알려져 있기 때문에 실시간으로 스캔해야 할 대상, 즉시 일관성이 필요한 대상, 비용 관리를 위해 일괄 처리할 수 있는 대상을 결정해야 합니다. 이 결정은 기업의 보고 수요에 따라 달라집니다.

비즈니스 파트너용 마스터 데이터 샘플이 포함된 SAP 테이블 BUT000을 살펴보세요. 여기에 SAP ERP 시스템의 변경사항이 복제되어 있습니다.

BigQuery는 복제 데이터를 상시 추가하기 때문에 모든 업데이트가 새 레코드로 수신됩니다. 예를 들어 소스에서 레코드를 삭제하면 BigQuery에 삭제 플래그와 함께 새 레코드로 표시됩니다. 이는 BUT000 같은 원시 테이블의 레코드든 BW 추출기 또는 CDS 뷰 같이 사전 합산 데이터든 관계없이 적용됩니다.

파트너 'LUCIA'와 'RIZ'의 데이터를 자세히 살펴보겠습니다. 작업 플래그를 통해 BigQuery의 새 레코드 유형이 삽입(I), 업데이트(U) 또는 삭제(D)인지 알 수 있고 타임스탬프를 통해서는 비즈니스 파트너의 최신 버전을 확인할 수 있습니다.

파트너 LUCIA와 RIZ에 대한 최신 업데이트된 레코드를 찾으려면 다음과 같이 쿼리를 작성해야 합니다.

code_block: <ListValue: [StructValue([('code', "SELECT partner,\r\n ARRAY_AGG(i1 ORDER BY i1.recordstamp DESC LIMIT 1) AS row\r\nFROM SAP_ECC.but000 i1 \r\nWHERE partner in ('LUCIA','RIZ')\r\n GROUP BY partner"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa3a9d00a30>)])]>

결과는 다음과 같습니다.

'LUCIA'와 'RIZ' 비즈니스 파트너의 비활성 레코드를 확인한 후 기록을 유지하지 않으려는 경우 'LUCIA'의 모든 비활성 레코드를 삭제하면 됩니다. 이 예시에서는 비교를 위해 동일한 복제가 이루어진 다른 테이블을 사용하여 선택에 따라 비활성 레코드가 모두 삭제되고 최신 업데이트된 레코드만 유지되었는지 확인합니다. 예를 들면 다음과 같습니다.

code_block: <ListValue: [StructValue([('code', 'DELETE SAP_HANA.but000 i1\r\nWHERE\r\ni1.recordstamp < TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 3 HOUR) AND\r\ni1.recordstamp < (SELECT MAX(recordstamp) FROM SAP_HANA.but000 i2\r\nWHERE\r\ni1.partner = i2.partner\r\nand partner="LUCIA")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa3a9d00820>)])]>

또한 다음과 같은 쿼리를 사용하여 'LUCIA' 파트너에 대한 비활성 레코드를 검색한 후 삭제를 진행할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'SELECT partner, operation_flag, recordstamp FROM SAP_HANA.but000 i1\r\nWHERE\r\ni1.recordstamp < TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 3 HOUR) \r\nAND\r\ni1.recordstamp < (SELECT MAX(recordstamp) FROM SAP_HANA.but000 i2 \r\nWHERE \r\ni1.partner = i2.partner\r\nand partner="LUCIA")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa3a9d00ee0>)])]>

그러면 최신 업데이트를 제외한 모든 레코드가 생성됩니다.

파티션 나누기 및 클러스터링

쿼리에서 스캔되는 레코드 개수를 제한하고, 비용을 절감하고, 최고의 성능을 내려면 파티션을 결정하고 클러스터를 만드는 두 가지 중요한 단계를 진행해야 합니다.

파티션 나누기

파티션을 나눈 테이블은 파티션이라는 세그먼트로 구분되어 데이터 관리와 쿼리가 용이한 테이블입니다. 큰 테이블을 작은 파티션으로 나누면 쿼리에서 읽는 바이트 수가 줄어 쿼리 성능이 향상되고 비용을 관리할 수 있습니다.

다음을 기준으로 BigQuery 테이블을 여러 파티션으로 나눌 수 있습니다.

시간 단위 열: '타임스탬프,' '날짜' 또는 '일시' 열에 따라 테이블이 파티션으로 구분됩니다.
수집 시간: BigQuery가 데이터를 수집할 때 기록되는 타임스탬프를 기준으로 테이블이 파티션으로 구분됩니다.
정수 범위: 정수 열을 기준으로 테이블이 파티션으로 구분됩니다.

아래 예시와 같이 테이블이 생성될 때 파티션이 사용 설정됩니다. 쿼리 왼쪽에 표시된 것처럼 파티션 필터를 항상 포함시키는 것이 좋습니다.

클러스터링

클러스터링은 필터링에 사용될 수 있는 필드를 적용하여 파티션을 나눈 테이블에 추가로 만들 수 있습니다. BigQuery에서 클러스터링된 테이블을 만들 때, 테이블 데이터는 테이블 스키마에 있는 1개 이상의 열에 있는 콘텐츠를 기준으로 자동 정렬됩니다. 지정하는 열은 관련 데이터를 배치하는 데 사용됩니다.

클러스터링은 절을 필터링하는 데 사용하는 쿼리나 데이터를 집계하는 쿼리와 같은 특정 유형의 쿼리 성능을 개선할 수 있습니다. SAP S/4HANA의 회계 문서용 테이블인 ACDOCA 같은 대형 테이블에 적용하면 매우 편리합니다. 이 경우 타임스탬프를 이용하여 파티션을 나누고 원장, 기업 코드, 회계 연도 같은 일반 필터링 필드를 사용하여 클러스터를 정의할 수 있습니다.

BigQuery의 또 다른 유용한 기능으로는 정기적으로 데이터를 자동 재클러스터링하는 기능이 있습니다.

구체화된 뷰

BigQuery에서 구체화된 뷰는 성능 및 효율성 향상을 위해 쿼리 결과를 주기적으로 캐시하는 미리 계산된 뷰입니다. BigQuery는 구체화된 뷰로부터 미리 계산된 결과를 사용하고, 가능한 모든 경우에 기본 테이블에서 델타 변경사항만 읽어 최신 결과를 빠르게 계산합니다. 구체화된 뷰는 직접 쿼리될 수도 있고, 기본 테이블 쿼리 처리를 위해 BigQuery 옵티마이저에 사용될 수도 있습니다.

구체화된 뷰를 사용하는 쿼리는 일반적으로 기본 테이블에서 동일한 데이터만 검색하는 쿼리보다 속도가 빠르며 리소스 소비도 적습니다. 워크로드 성능이 문제인 경우 구체화된 뷰는 일반적인 반복 쿼리가 포함된 워크로드의 성능을 크게 개선할 수 있습니다. 현재 구체화된 뷰는 단일 테이블만 지원하지만 재고 수준이나 주문 처리와 같이 일반적으로 자주 사용되는 집계에 매우 유용합니다.

특정 구문을 작성하면서 성능을 최적화하는 방법에 대한 자세한 팁은 쿼리 계산 최적화 문서를 참조하세요.

배포 파이프라인 및 보안

BigQuery에서 실행하는 대부분의 작업의 경우 최소한 두 가지의 전송 파이프라인을 실행하게 됩니다. 하나는 BigQuery의 실제 객체용이고 또 다른 하나는 변경 데이터 캡처 흐름 내에서 의도된 바에 따라 데이터 스테이징, 변환, 업데이트를 유지하기 위한 것입니다. 지속적 통합/지속적 배포(CI/CD) 파이프라인에 기존 도구의 대부분을 사용할 수 있으며 이는 BigQuery 같은 오픈 시스템을 사용할 때 누릴 수 있는 이점 중 하나입니다. 하지만 조직이 CI/CD 파이프라인을 처음 사용하는 경우 점차 경험을 확장할 수 있는 좋은 기회입니다. 우선 데이터 처리 워크플로용 CI/CD 파이프라인 설정에 대한 가이드부터 읽어보시기 바랍니다.

액세스와 보안 면에서 대부분의 최종 사용자는 BigQuery 뷰의 최종 버전에만 액세스할 수 있습니다. SAP 소스 시스템에서처럼 행 및 열 수준 보안을 적용할 수 있지만 다양한 Google Cloud 프로젝트와 BigQuery 데이터 세트에서 데이터를 분할하여 분리 작업을 한 단계 업그레이드할 수 있습니다. 데이터 세트에서 데이터와 구조를 간편하게 복제할 수 있지만 설계 프로세스 초기에 요구사항과 이름 지정 규칙을 규정하여 처음부터 올바로 설정하는 것이 바람직합니다.

보다 빠르게 더 유용한 정보를 제공하는 분석을 시작

무엇보다도 직접 해보는 것이 좋습니다. SQL 지식이 있다면 누구나 BigQuery 무료 등급을 사용할 수 있습니다. 신규 고객에게는 처음 90일 동안 Google Cloud에 사용할 수 있는 $300의 무료 크레딧이 제공됩니다. 모든 고객에게 매월 10GB의 스토리지와 최대 1TB의 쿼리가 무료로 제공됩니다. 대규모 처리 기능, 내장 머신러닝, 다양한 통합 도구, 비용상의 이점과 더불어 BigQuery가 어떻게 분석 작업을 간소화하는지는 곧 알게 될 것입니다.

추가 지원이 필요한 경우 Google Cloud Professional Services Organization(PSO)과 고객 엔지니어가 귀사에 가장 적합한 방법을 탐색하는 데 기꺼이 도움을 드릴 것입니다. 다른 궁금한 점이 있다면 cloud.google.com/contact에서 문의하세요.

2021년 상반기 Cloud OnBoard 다시 보기

Wed, 23 Jun 2021 00:00:00 +0000

Google Cloud Korea 팀에서는 매 분기 Google Cloud에 입문하고자 하시는 분들을 위한 기초 교육인 “Cloud OnBoard”를 진행하고 있습니다. Cloud OnBoard는 타 클라우드는 활용해보았지만 Google Cloud 사용 경험이 없는 분들은 물론, 클라우드를 사용해본 적이 없는 분들도 참여할 수 있는 반나절짜리 온라인 교육입니다.

2021년 상반기에는 총 2회, 각각 Data Warehouse Modernization with BigQuery (BigQuery와 함께 하는 데이터 웨어하우스 현대화)와 Application Development(애플리케이션 개발)를 주제로 Cloud OnBoard가 진행됐습니다. 생방송은 종료되었습니다만 다시 보기 영상을 계속해서 시청하실 수 있습니다.

어떤 주제를 들어야 할지 고민 되신다고요? 저희가 도와드리겠습니다.

데이터 애널리스트, 데이터 사이언티스트, 비즈니스 애널리스트
데이터 프로세싱을 위한 파이프라인과 아키텍처를 디자인하거나, 머신러닝과 통계 모델을 만들거나, 데이터세트를 쿼리 하거나, 쿼리 결과를 시각화하고 리포트를 생성하는 업무를 맡고 있는 사람

위에 해당하는 분들에게는 Data Warehouse Modernization with BigQuery를 추천합니다.

실제 진행된 날짜: 2021년 3월 3일
연사: 박기택, Technical Trainer, Data & Machine Learning, Google Cloud
아젠다

교육 시간	모듈
40분	데이터 레이크 및 데이터베이스
40분	데이터 웨어하우스: BigQuery
50분	BigQuery 성능
50분	ETL, 데이터 파이프라인
10분	요약 및 마무리

만약 아래와 같은 업무를 맡고 계시다면

개발자. 특히 애플리케이션을 배포하고 애플리케이션 환경을 만들 계획인 개발자
시스템 운영자
솔루션 설계자

Application Development를 추천합니다.

실제 진행된 날짜: 2021년 6월 2일
연사

김정환, Technical Account Manager, Google Cloud
이준호, Solutions Architect, Google Cloud
양현주, Technical Account Manager, Google Cloud

아젠다

교육 시간	모듈
45분	애플리케이션 개발 소개
50분	스토리지와 모니터링
48분	Container, App Engine, Cloud Run

원하시는 곳에서, 원하시는 때에 Cloud OnBoard 다시 보기와 함께 기초를 쌓아보시길 바랍니다.

다음 Cloud OnBoard 생방송은 9월과 12월 진행됩니다. 본 블로그 및 Google Cloud 페이스북에서 소식을 알려드릴테니 기대해주세요.