서버리스

Cloud Run의 새로운 소식: Next '26 업데이트

Tue, 28 Apr 2026 01:00:00 +0000

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

바이브 코딩(Vibe-coded) 애플리케이션과 대규모 앱부터 AI 모델 및 에이전트에 이르기까지, Cloud Run은 모든 워크로드에 대해 오버헤드 없는 온디맨드 컴퓨팅과 사용량 기반 과금(Pay-per-use) 방식을 제공합니다. 지난해 Cloud Run을 사용하는 외부 활성 개발자와 애플리케이션의 수는 두 배로 증가했으며, 2025년 한 해 동안 유입된 신규 고객과 앱의 수는 서비스 출시 후 첫 6년 동안의 기록을 합친 것보다 더 많았습니다!

오늘 우리는 여러분의 워크로드 운영을 돕기 위해 Cloud Run의 새로운 기능과 개선 사항을 발표합니다.

Cloud Run, Firestore, 사용자 인증을 사용하여 Google AI Studio에서 풀스택 앱을 구축하고 배포할 수 있습니다.
완전히 새로운 Gemini Enterprise Agent Platform과 Cloud Run을 통해 안정적인 AI 에이전트를 구축, 확장, 거버넌스 관리 및 최적화할 수 있습니다.
Cloud Run의 완전 관리형 원격 MCP 서버를 통해 개발자와 에이전트가 손쉽게 배포를 진행할 수 있습니다.
Cloud Run에서 NVIDIA RTX PRO 6000 Blackwell Server Edition GPU를 사용하여 고성능 인퍼런스와 서버리스 컴퓨팅을 결합할 수 있습니다.

개발자의 새로운 시대를 위한 역량 강화

수십 년 동안 소프트웨어 개발은 진입 장벽이 높은 학습 곡선을 가져왔으나, AI 덕분에 이제 누구나 디지털 빌더가 될 수 있습니다. Cloud Run과 함께라면 프로토타입에서 배포된 앱까지 단 몇 초 만에 도달할 수 있습니다.

Google AI Studio에서 풀스택 앱 구축
AI Studio가 이제 서버 측 코드, Firestore 데이터베이스 및 사용자 인증을 실행할 수 있는 풀스택 애플리케이션을 지원합니다. 바이브 코딩으로 만든 앱을 클릭 한 번으로 Cloud Run에 배포해 보세요. 현재 정식 출시(GA)되었습니다.

Cloud Run 완전 관리형 원격 MCP 서버
개발자나 에이전트가 코드를 더욱 쉽게 배포할 수 있도록 공식 원격 Cloud Run MCP(Model Context Protocol) 서버를 출시합니다. 이를 통해 앱을 관리하고 배포할 수 있는 도구를 제공합니다. 현재 정식 출시(GA)되었습니다.

청구 상한선(Billing caps)
곧 월별 최대 지출 금액을 설정할 수 있게 됩니다. 청구액이 이 금액에 도달하면 Cloud Run 리소스가 비활성화됩니다.

"Cloud Run은 우리 배포 플랫폼에서 내린 최고의 기술적 선택 중 하나였습니다. 현재 Replit에서 호스팅되는 100만 개 이상의 라이브 프로젝트를 지원하는 우리의 주요 타겟입니다." - Replit 엔지니어링 부사장, Scott Kennedy

에이전틱(Agentic) 시대의 수용

AI 에이전트도 사람과 마찬가지로 작업을 수행하기 위해 컴퓨팅 환경에 대한 접근이 필요합니다. 클라우드 기반 AI 에이전트가 복잡한 작업을 수행할 때 Cloud Run의 온디맨드 컴퓨팅 서비스를 활용할 수 있습니다.

Gemini Enterprise Agent Platform과 Cloud Run 통합
에이전트 플랫폼은 Cloud Run과의 통합을 통해 에이전트를 다시 구축할 필요 없이 실험 환경에서 완전 관리형 프로덕션 급 시스템으로 전환할 수 있도록 돕습니다. 현재 일부 고객을 대상으로 프리뷰가 진행 중입니다.

Cloud Run 인스턴스
기존에는 Cloud Run 서비스, 잡(Job), 워커 풀(Worker pool)이 인프라를 관리하는 고정된 방식이었습니다. 이제 우리는 그 아래의 기본 단위인 개별 'Cloud Run 인스턴스'를 직접 생성할 수 있는 권한을 제공합니다. Cloud Storage 볼륨 마운트와 결합된 이 인스턴스들은 OpenClaw와 같이 장시간 실행되는 백그라운드 에이전트를 간단한 명령 하나로 호스팅하는 데 이상적입니다.

code_block: <ListValue: [StructValue([('code', 'gcloud run instances create \\\r\n --image alpine/openclaw:latest \\\r\n --port 18789 \\\r\n --memory 4Gi \\\r\n --default-url \\\r\n --add-volume mount-path=/home/node/.openclaw,type=cloud-storage,bucket=$BUCKET_NAME'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205bb5a670>)])]>

이 기능은 현재 일부 고객을 대상으로 프리뷰(Preview) 형태로 제공됩니다.

Cloud Run 샌드박스
에이전트는 코드나 명령을 가능한 한 빠르게 실행할 수 있는 안전한 공간이 필요한 경우가 많습니다. 곧 출시될 내장형 sandbox 도구를 사용하면, 단일 요청을 처리하는 동안 에이전트 코드로부터 엄격하게 격리된 휘발성(Ephemeral) 샌드박스를 매우 신속하게 구동할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'app.post(\'/execute\', (req, res) => {\r\n const escapedCode = req.body.code.replace(/"/g, \'\\\\"\');\r\n\r\n exec(`sandbox do -- /usr/bin/python3 -c "${escapedCode}"`, (e, stdout, stderr) => {\r\n res.send({ stdout, stderr });\r\n });\r\n\r\n});'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205bb5a310>)])]>

"Cloud Run의 동시성 모델은 우리의 고객 서비스용 AI 도구인 Lumi의 AI 워크로드를 단순화하는 데 큰 역할을 했습니다. Gemini 및 AlloyDB와 함께 Cloud Run을 사용함으로써, 실시간 통화 요약과 흐름 안내가 가능한 통합 액션 레이어를 구축할 수 있었습니다. 이를 통해 컨택 센터 팀의 첫 통화 해결률을 높이고 신규 팀원의 온보딩 속도를 앞당기는 성과를 거두었습니다." - 에드워드 라이트(Edward Wright), VirginMedia O2 UK 엔지니어링 헤드

수요가 높은 애플리케이션을 위한 자동 확장

Cloud Run은 수요에 맞춰 자동으로 리소스를 확장하므로, 트래픽 폭증에 즉각적으로 대응하고 서비스를 제공해야 하는 대규모 고객사에게 매우 적합합니다.

Cloud Run SSH 지원
개발자는 이제 실행 중인 Cloud Run 컨테이너에 보안 셸(SSH)로 직접 액세스하여 고급 트러블슈팅을 수행하거나 컨테이너의 파일 시스템을 즉석에서 점검할 수 있습니다. 현재 일부 고객을 대상으로 프리뷰(Preview)가 진행 중이며, 간단한 명령어로 보안 대화형 셸 세션을 열 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'gcloud run services ssh SERVICE'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205bb5ac40>)])]>

Cloud Run 서비스 바인딩
곧 출시될 Cloud Run 서비스 바인딩을 통해 확장 가능한 마이크로서비스 아키텍처에서 서비스 간 통신을 원활하게 구현할 수 있습니다.

"Cloud Run의 서버리스 아키텍처는 거의 즉각적인 확장을 통해 기하급수적으로 증가하는 수요를 충족할 수 있게 해주며, 효율적인 개발자 경험은 애플리케이션 구축 및 실행 과정을 단순화해 줍니다." - Anthropic 기술 스태프, Mimi Chen

AI 모델 실행

GPU를 활용한 커스텀 모델 서빙부터 잡(Jobs)을 통한 모델 학습 및 미세 조정까지, Cloud Run은 AI 집약적인 워크로드에 최적화되어 있습니다.

Cloud Run의 NVIDIA RTX PRO 6000 Blackwell GPU 지원
이제 Cloud Run에서 NVIDIA RTX PRO™ 6000 Blackwell GPU를 지원하며 정식 출시(GA)되었습니다. 이를 통해 하부 인프라를 직접 관리할 필요 없이 70B 이상의 대규모 파라미터 모델을 서빙할 수 있으며, 리소스를 사용하지 않을 때는 0으로 자동 확장(Scale-to-zero)하여 비용을 최적화할 수 있습니다.

임시 디스크(Ephemeral disk)
인스턴스당 제공되는 임시 디스크 스토리지를 통해 컨테이너 메모리를 소모하지 않고도 대용량 파일을 처리하거나 스크래치 공간을 사용할 수 있습니다. 현재 프리뷰로 제공되는 이 임시 디스크는 인스턴스가 시작될 때 생성되고 중지될 때 삭제됩니다.

"Cloud Run은 우리의 모델 배포 관리 방식을 근본적으로 바꿨습니다. 사용량 기반의 '0으로 확장(Scale-to-zero)' 모델로 전환하면서 트래픽이 적은 모델에 대한 유휴 GPU 비용을 완전히 제거했습니다. 현재 용량 계획이나 플릿 관리의 부담 없이 여러 리전에 걸쳐 17개 이상의 모델 변체를 프로덕션 환경에서 독립적으로 실행하고 있습니다." - Elastic 글로벌 부사장, Ajay Nair

모든 워크로드를 위한 온디맨드 컴퓨팅

숙련된 소프트웨어 개발자이든, 다음 화제의 앱을 배포하려는 바이브 코더(vibe coder)이든 관계없이 Cloud Run은 모든 사람과 모든 워크로드에 최적화된 온디맨드 컴퓨팅을 제공합니다. 지금 바로 시작해 보세요.

CVE-2025-55182 보안 취약점, 당신의 React와 Next.js 프로젝트를 직접 겨냥합니다.

Wed, 03 Dec 2025 23:00:00 +0000

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

편집자 주

2025년 12월 7일 오후 9시 10분 (PDT) 업데이트: CVE-2025-55182 악용 시도를 완화하는 데 도움이 되도록 추가 ruleID를 포함하여 권장되는 Cloud Armor WAF 구문을 업데이트했습니다.
2025년 12월 5일 오후 12시 40분 (PDT) 업데이트: CVE-2025-55182의 악용 시도를 탐지하고 완화하는 데 도움이 되도록 Cloud Armor WAF 규칙의 권장 구문을 업데이트했습니다.
2025년 12월 4일 오후 9시 20분 (PDT) 업데이트: React Server Components 및 Next.js의 취약한 버전 목록을 수정하고 Cloud Armor에 대한 구성 가이드를 업데이트했습니다.

오늘 Meta와 Vercel은 널리 사용되는 오픈소스 프레임워크인 React Server Components(CVE-2025-55182) 및 Next.js를 사용하여 구축된 서비스가 일부 서버 측 사용 사례에서 원격 코드 실행 위험에 노출되는 두 가지 취약점을 공개했습니다. Google Cloud는 이러한 취약점의 심각성을 인지하고 있으며, Google의 보안팀은 고객이 애플리케이션 보안을 위해 즉각적이고 결정적인 조치를 취하는 데 도움이 될 권장 사항을 공유했습니다.

취약점 배경

React Server Components 프레임워크는 일반적으로 사용자 인터페이스를 구축하는 데 사용됩니다. 2025년 12월 3일, CVE.org는 이 취약점에 CVE-2025-55182를 할당했습니다. 공식 공통 취약점 등급 시스템(CVSS) 기본 심각도 점수는 10.0점 만점인 '심각(Critical)'으로 결정되었습니다.

취약한 버전: React 19.0, 19.1.0, 19.1.1, 19.2.0
패치된 버전: React 19.2.1
수정 사항(Fix): https://github.com/facebook/react/commit/7dc903cd29dac55efb4424853fd0442fef3a8700
공지: https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

Next.js는 React에 의존하는 웹 개발 프레임워크이며, 역시 사용자 인터페이스 구축에 널리 사용됩니다. (Next.js 취약점은 중복으로 표시되기 전 CVE-2025-66478로 참조되었습니다.)

취약한 버전: Next.js 15.x, Next.js 16.x, Next.js 14.3.0-canary.77 및 이후 canary 릴리스
패치된 버전은 여기에 나열되어 있습니다.
수정 사항(Fix): https://github.com/vercel/next.js/commit/6ef90ef49fd32171150b6f81d14708aa54cd07b2
공지: https://nextjs.org/blog/CVE-2025-66478

React 및 Next.js 프레임워크를 사용하는 환경을 관리하는 조직은 최신 버전으로 업데이트하고 아래에 설명된 완화 조치를 취할 것을 강력히 권장합니다.

CVE-2025-55182 완화 조치

Google은 CVE-2025-55182와 관련된 악용 시도를 탐지하고 차단하도록 설계된 새로운 Cloud Armor 웹 애플리케이션 방화벽(WAF) 규칙을 만들어 배포했습니다. 이 새로운 규칙은 지금 바로 사용 가능하며, 전역 또는 리전별 애플리케이션 부하 분산기를 사용하는 인터넷 연결 애플리케이션 및 서비스를 보호하기 위한 것입니다. 조직의 취약점 관리 프로그램이 환경 내의 모든 취약한 인스턴스를 패치하고 검증하는 동안, 이 규칙을 임시 완화 조치로 배포하는 것을 권장합니다.

Firebase Hosting 또는 Firebase App Hosting을 사용하는 고객의 경우, 커스텀 및 기본 도메인으로의 요청을 통한 CVE-2025-55182 악용을 제한하는 규칙이 이미 적용되어 있습니다. 그 외 모든 워크로드는 영향을 받는 패키지에 대해 고객의 조치와 패치가 필요합니다.

Project Shield 사용자의 경우, 모든 사이트에 WAF 보호 기능을 배포하기 위해 노력하고 있으며 이러한 WAF 규칙을 활성화하기 위한 별도의 조치는 필요하지 않습니다. 장기적인 완화를 위해서는 취약점을 근본적으로 제거하기 위한 필수 단계로 오리진 서버를 패치해야 합니다(아래 추가 지침 참조).

Cloud Armor와 애플리케이션 부하 분산기는 애플리케이션과 서비스가 Google Cloud, 온프레미스 또는 다른 인프라 제공업체 중 어디에 배포되었는지에 관계없이 이를 제공하고 보호하는 데 사용될 수 있습니다. 아직 Cloud Armor와 애플리케이션 부하 분산기를 사용하고 있지 않다면, 아래의 시작하기 가이드를 참조하세요.

Cloud Armor용 cve-canary WAF 규칙 배포하기

CVE-2025-55182로부터 탐지하고 보호하도록 Cloud Armor를 구성하려면, 이 취약점을 위해 추가된 새로운 ruleID를 활용하는 cve-canary 사전 구성된 WAF 규칙을 사용할 수 있습니다.

Cloud Armor 백엔드 보안 정책에서 새 규칙을 만들고 다음 일치 조건을 구성합니다.

code_block: <ListValue: [StructValue([('code', "(has(request.headers['next-action']) || has(request.headers['rsc-action-id']) || request.headers['content-type'].contains('multipart/form-data') || request.headers['content-type'].contains('application/x-www-form-urlencoded')) && evaluatePreconfiguredWaf('cve-canary',{'sensitivity': 0, 'opt_in_rule_ids': ['google-mrs-v202512-id000001-rce','google-mrs-v202512-id000002-rce']})"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f2060cd5790>)])]>

이 작업은 Google Cloud 콘솔에서 Cloud Armor로 이동한 후, 기존 정책을 수정하거나 새 정책을 생성하여 수행할 수 있습니다.

Google Cloud 콘솔에서 Cloud Armor 규칙 생성

또는, gcloud CLI를 사용하여 필요한 규칙이 포함된 정책을 생성하거나 수정할 수도 있습니다.

code_block: <ListValue: [StructValue([('code', 'gcloud compute security-policies rules create PRIORITY_NUMBER \\\r\n --security-policy SECURITY_POLICY_NAME \\\r\n --expression "(has(request.headers[\'next-action\']) || has(request.headers[\'rsc-action-id\']) || request.headers[\'content-type\'].contains(\'multipart/form-data\') || request.headers[\'content-type\'].contains(\'application/x-www-form-urlencoded\')) && evaluatePreconfiguredWaf(\'cve-canary\',{\'sensitivity\': 0, \'opt_in_rule_ids\': [\'google-mrs-v202512-id000001-rce\',\'google-mrs-v202512-id000002-rce\']})" \\\r\n --action=deny-403'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f2060cd5880>)])]>

Terraform으로 규칙을 관리하고 있다면, 아래 구문을 사용하여 규칙을 적용할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'rule {\r\n action = "deny(403)"\r\n priority = "PRIORITY_NUMBER"\r\n match {\r\n expr {\r\n expression = "(has(request.headers[\'next-action\']) || has(request.headers[\'rsc-action-id\']) || request.headers[\'content-type\'].contains(\'multipart/form-data\') || request.headers[\'content-type\'].contains(\'application/x-www-form-urlencoded\')) && evaluatePreconfiguredWaf(\'cve-canary\',{\'sensitivity\': 0, \'opt_in_rule_ids\': [\'google-mrs-v202512-id000001-rce\',\'google-mrs-v202512-id000002-rce\']})"\r\n }\r\n }\r\n description = "Applies protection for CVE-2025-55182 (React/Next.JS)"\r\n }'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f2060cd5100>)])]>

애플리케이션을 위한 WAF 규칙 안전성 검증 및 원격 분석 활용

Cloud Armor 규칙은 Cloud Armor가 구성된 작업을 강제로 실행하지 않고, 규칙의 예상 영향을 테스트하거나 모니터링할 수 있는 로깅 전용 모드인 미리보기 모드(preview mode)로 구성할 수 있습니다. 위에서 설명한 새 규칙을 프로덕션 환경에 먼저 미리보기 모드로 배포하여 어떤 트래픽이 차단될지 확인하는 것을 권장합니다.

환경에서 새 규칙이 예상대로 작동하는지 확인한 후에는 미리보기 모드를 비활성화하여 Cloud Armor가 규칙을 능동적으로 적용하도록 할 수 있습니다.

Cloud Armor의 요청별 WAF 로그는 애플리케이션 부하 분산기 로그의 일부로 Cloud Logging에 기록됩니다. 모든 요청에 대한 Cloud Armor의 결정을 확인하려면, 먼저 백엔드 서비스별로 부하 분산기 로깅을 활성화해야 합니다. 활성화되면 이후의 모든 Cloud Armor 결정이 기록되며, 다음 안내에 따라 Cloud Logging에서 해당 내용을 찾을 수 있습니다.

Cloud Armor 규칙과 취약점 스캐닝 도구의 상호 작용

사용자 환경에서 React 및 Next.js의 취약한 인스턴스를 식별하는 데 도움이 되도록 설계된 스캐닝 도구가 급증했습니다. 이러한 스캐너 중 다수는 서버에서 실행 중인 React 및 Next.js의 버전을 탐지하기 위해 합법적인 쿼리를 작성하고 서버의 응답을 검사하여 관련 프레임워크의 버전 번호를 식별하도록 설계되었습니다.

Google의 WAF 규칙은 CVE-2025-55182의 악용 시도를 탐지하고 방지하도록 설계되었습니다. 위에서 설명한 스캐너는 악용을 시도하는 것이 아니라, 소프트웨어 버전 정보를 나타내는 응답을 유도하기 위해 안전한 쿼리를 보내므로, 위의 Cloud Armor 규칙은 이러한 스캐너를 탐지하거나 차단하지 않습니다.

만약 이러한 스캐너의 결과가 Cloud Armor로 보호되는 소프트웨어의 취약한 인스턴스를 나타낸다고 해서, 해당 취약점에 대한 실제 악용 시도가 Cloud Armor 보안 정책을 성공적으로 통과한다는 의미는 아닙니다. 대신, 이러한 결과는 탐지된 React 또는 Next.js 버전이 취약한 것으로 알려져 있으므로 패치해야 함을 의미합니다.

신규 사용자를 위한 Cloud Armor 시작 가이드

워크로드가 이미 애플리케이션 부하 분산기를 사용하여 인터넷에서 트래픽을 받고 있다면, 다음 안내에 따라 Cloud Armor를 구성하여 이 취약점 및 기타 애플리케이션 수준의 취약점(DDoS 공격 포함)으로부터 워크로드를 보호할 수 있습니다.

아직 애플리케이션 부하 분산기와 Cloud Armor를 사용하고 있지 않다면, 외부 애플리케이션 부하 분산기 개요, Cloud Armor 개요, Cloud Armor 권장사항을 참조하여 시작할 수 있습니다.

워크로드가 Cloud Run, Cloud Run functions 또는 App Engine을 사용하고 인터넷에서 트래픽을 받는 경우, 먼저 엔드포인트 앞에 애플리케이션 부하 분산기를 설정해야 Cloud Armor 보안 정책을 활용하여 워크로드를 보호할 수 있습니다. 그런 다음 Cloud Armor와 애플리케이션 부하 분산기가 우회되지 않도록 적절한 제어를 구성해야 합니다.

권장사항 및 추가 위험 완화 조치

Cloud Armor를 구성한 후에는 Google의 권장사항 가이드를 참조하는 것이 좋습니다. 문서에 설명된 제한사항을 반드시 고려하여 워크로드의 안전과 가용성을 보장하면서 위험을 최소화하고 성능을 최적화하세요.

장기적 완화 조치: 필수 프레임워크 업데이트 및 재배포

WAF 규칙이 중요한 최전선 방어를 제공하지만, 가장 포괄적인 장기 해결책은 기본 프레임워크를 패치하는 것입니다.

Google Cloud에서 React 및 Next.js 애플리케이션을 실행하는 모든 고객은 즉시 종속성을 최신 안정 버전(React 19.2.1 또는 여기에 나열된 관련 Next.js 버전)으로 업데이트하고 서비스를 재배포할 것을 강력히 촉구합니다.

이는 특히 다음에 배포된 애플리케이션에 적용됩니다.

Cloud Run, Cloud Run functions 또는 App Engine: 애플리케이션 종속성을 업데이트된 프레임워크 버전으로 업데이트하고 재배포하세요.
Google Kubernetes Engine (GKE): 컨테이너 이미지를 최신 프레임워크 버전으로 업데이트하고 파드를 재배포하세요.
Compute Engine: Google Cloud에서 제공하는 공개 OS 이미지에는 기본적으로 React 또는 Next.js 패키지가 설치되어 있지 않습니다. 영향을 받는 패키지가 포함된 커스텀 OS를 설치한 경우, 최신 프레임워크 버전을 포함하도록 워크로드를 업데이트하고 모든 워크로드 앞에 WAF 규칙을 활성화하세요.
Firebase: Cloud Functions for Firebase, Firebase Hosting 또는 Firebase App Hosting을 사용하는 경우, 애플리케이션 종속성을 업데이트된 프레임워크 버전으로 업데이트하고 재배포하세요. Firebase Hosting 및 App Hosting은 또한 커스텀 및 기본 도메인으로의 요청을 통한 CVE-2025-55182 악용을 제한하는 규칙을 자동으로 적용하고 있습니다.

애플리케이션을 패치하는 것은 근본 원인에서 취약점을 제거하고 서비스의 지속적인 무결성과 보안을 보장하기 위한 필수적인 단계입니다.

Google은 상황을 계속 면밀히 모니터링하고 필요에 따라 추가 업데이트와 지침을 제공할 것입니다. 가장 최신 정보와 자세한 단계는 공식 Google Cloud 보안 권고 사항을를 참조해 주십시오.

NVIDIA GPU가 지원되는 Cloud Run에서 AI 추론 애플리케이션 실행

Mon, 17 Mar 2025 08:01:00 +0000

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

Cloud Run이 개발자 사이에서 주목받는 이유는 단순성, 빠른 자동 확장, Scale-to-zero 기능, 종량제 가격 책정 때문입니다. 이와 똑같은 이점이 개방형 생성형 AI 모델을 서빙하는 실시간 추론 앱에 적용됩니다. 오늘 NVIDIA L4 GPU에 대한 지원을 프리뷰로 Cloud Run에 추가한 이유가 바로 여기에 있습니다.

덕분에 Cloud Run 개발자는 다음과 같은 여러 새로운 사용 사례를 실현할 수 있습니다.

Google의 개방형 Gemma(2B/7B) 모델이나 Meta의 Llama 3(8B) 등의 경량 개방형 모델로 실시간 추론을 수행하여 커스텀 채팅 봇이나 즉석 문서 요약을 빌드하고 급증하는 사용자 트래픽을 처리하도록 확장합니다.
회사 브랜드에 맞는 이미지 생성과 같이 파인 튜닝된 커스텀 생성형 AI 모델을 서빙하고 사용하지 않을 때는 축소하여 비용을 최적화합니다.
주문형 이미지 인식, 동영상 트랜스코딩 및 스트리밍, 3D 렌더링 등 컴퓨팅 집약적인 Cloud Run 서비스의 속도를 높입니다.

완전 관리형 플랫폼인 Cloud Run을 사용하면 Google의 확장 가능한 인프라에서 직접 코드를 실행하여 컨테이너의 유연성과 서버리스의 단순성을 결합해 생산성을 높일 수 있습니다. Cloud Run을 사용하면 기본 인프라를 관리할 필요 없이 프런트엔드 및 백엔드 서비스를 실행하고, 작업을 일괄 처리하고, 웹사이트 및 애플리케이션을 배포하고, 큐 처리 워크로드를 처리할 수 있습니다.

한편 AI 추론을 수행하는 많은 워크로드, 특히 실시간 처리가 필요한 애플리케이션에서 반응형 사용자 경험을 제공하기 위해서는 GPU 가속이 필요합니다. NVIDIA GPU가 지원되면서 이제 원하는 LLM을 사용하여 몇 초 만에 주문형 온라인 AI 추론을 수행할 수 있습니다. 24GB의 vRAM을 사용하면 Llama 3.1(80억 개), Mistral(70억 개), Gemma 2(90억 개) 등 최대 90억 개의 파라미터가 포함된 모델에서 빠른 토큰 속도를 기대할 수 있습니다. 앱을 사용하지 않을 때는 서비스가 0으로 자동 축소되어 요금이 청구되지 않습니다.

“NVIDIA L4 Tensor GPU와 NVIDIA NIM 지원이 추가된 Cloud Run은 사용자에게 빠르게 확장되는 실시간 AI 추론 플랫폼을 제공하여 고객이 인프라 관리 오버헤드를 최소화하면서 AI 프로젝트를 앞당기고 솔루션을 더 빨리 출시할 수 있도록 지원합니다.” - Anne Hecht, NVIDIA 제품 마케팅 부문 선임 이사

Cloud Run 및 NVIDIA GPU 조합에 대한 발 빠른 고객들의 기대

“Cloud Run의 GPU 지원은 실시간 추론 애플리케이션에 획기적인 변화를 일으켰습니다. 특히 짧은 콜드 스타트 지연 시간이 인상적입니다. 덕분에 모델에서 거의 즉시 예측을 제공할 수 있는데 이는 시간에 민감한 고객 경험에 매우 중요합니다. 또한 Cloud Run GPU는 다양한 부하에서도 일관되게 서빙 지연 시간을 최소한으로 유지하여 생성형 AI 애플리케이션이 항상 반응성과 신뢰성을 유지하고 비활성화 기간 동안에는 쉽게 0으로 축소할 수 있습니다. 전반적으로 Cloud Run GPU 덕분에 빠르고 정확하고 효율적인 결과를 최종 사용자에게 제공하는 능력이 크게 향상되었습니다.” - Thomas MENARD, L’Oreal 글로벌 뷰티 기술 부문 AI 책임자

“Cloud Run GPU는 Google Cloud에서 GPU 컴퓨팅을 사용하는 데 가장 좋은 확실한 방법입니다. 오픈소스 표준(Knative)을 사용하여 높은 수준의 제어 및 맞춤 설정을 제공할 뿐만 아니라 바로 사용할 수 있는 뛰어난 모니터링 가능성 도구와 Scale-to-zero 기능이 있는 완전 관리형 인프라를 지원한다는 점이 마음에 듭니다. Knative 기본 요소를 사용해 GKE로 쉽게 마이그레이션할 수 있기 때문에 높은 복잡성과 유지보수를 감내하는 대신 더 많은 제어를 누릴 수 있는 옵션이 항상 존재합니다. 자사 사용 사례의 GPU 할당과 시작 시간도 경쟁업체 서비스에 비해 더 빨랐습니다.” - Alex Bielski, Chaptr 혁신 부문 이사

Cloud Run에서 사용하는 NVIDIA GPU

오늘부터 Cloud Run 인스턴스당 1개의 NVIDIA L4 GPU 연결이 지원됩니다. GPU를 사전에 예약할 필요는 없습니다. 이제 us-central1(아이오와)에서 Cloud Run GPU를 사용할 수 있으며 연말 전에 europe-west4(네덜란드) 및 asia-southeast1(싱가포르)에도 지원할 예정입니다.

NVIDIA GPU가 지원되는 Cloud Run 서비스를 배포하려면 명령줄에 --gpu=1 플래그를 추가하여 GPU 수를 지정하고 --gpu-type=nvidia-l4 플래그를 추가하여 GPU 유형을 지정하세요. Google Cloud 콘솔에서 배포할 수도 있습니다.

최근에 발표한 Cloud Run Functions를 사용하면 GPU를 함수에 연결하여 이벤트 기반 AI 추론을 간단하게 수행할 수 있습니다.

"GPU 지원을 추가해 새롭게 출시된 Cloud Run Functions에서는 Python 개발자가 인프라, GPU 드라이버, 컨테이너에 대한 걱정 없이 Hugging Face 모델을 사용할 수 있습니다. Cloud Run의 Scale-to-zero 및 빠른 시작 기능은 특히 단 몇 줄의 서버리스 코드만으로 HuggingFace 모델을 사용해 AI를 시작하기를 원하는 개발자에게 적합합니다.” - Julien Chaumond, Hugging Face CTO

성능

NVIDIA GPU가 지원하는 Cloud Run에서는 간단한 조작으로 강력한 성능을 누릴 수 있습니다. 인프라 지연 시간을 최소한으로 유지하여 모델 서빙 시 최고의 성능을 보장합니다.

드라이버가 사전 설치된 L4 GPU가 연결된 Cloud Run 인스턴스는 약 5초 만에 시작되며 이때 컨테이너에서 실행되는 프로세스가 GPU를 사용하기 시작합니다. 이후 프레임워크와 모델이 로드되고 초기화되는 데 몇 초가 더 소요됩니다. 아래 표에는 Ollama 프레임워크를 사용하는 Gemma 2b, Gemma2 9b, Llama2 7b/13b, Llama3.1 8b 모델의 콜드 스타트 시간(11초~35초)이 나와 있습니다. 이는 인스턴스를 0에서 시작하여 GPU에 모델을 로드하고 LLM이 첫 단어를 반환하는 데 걸리는 시간을 측정한 값입니다.

모델	모델 크기	콜드 스타트 시간
gemma:2b	1.7GB	11~17초
gemma2:9b	5.1GB	25~30초
llama2:7b	3.8GB	14~21초
llama2:13b	7.4GB	23~35초
llama3.1:8b	4.7GB	15~21초

_{콜드 스타트 시간: Cloud Run 인스턴스의 서비스 URL을 처음 호출하여 0에서 1이 되고 응답의 첫 단어를 제공하는 데 걸리는 시간입니다.}

_{모델: 위에 나온 각 모델의 4비트 양자화된 버전을 사용했습니다. 이러한 모델은 Ollama 프레임워크를 사용해 배포했습니다.}

_{참고로 통제된 실험 환경에서 관찰한 수치이며 실제 성능 수치는 다양한 요인에 따라 달라질 수 있습니다.}

Ollama를 사용한 샘플 앱 배포

아래에서 NVIDIA GPU가 지원되는 Cloud Run을 통해 Ollama 기반의 Google Gemma2 9b 모델을 배포하는 방법을 확인할 수 있습니다. Gemma는 Gemini 모델을 만드는 데 사용되는 것과 동일한 연구와 기술로 빌드된 최첨단 경량 개방형 모델군입니다. Ollama는 대규모 언어 모델을 관리할 수 있는 간단한 API를 제공하는 프레임워크입니다.

먼저 Ollama를 사용하는 컨테이너 이미지와 이 Dockerfile을 사용하는 모델을 만듭니다.

code_block: <ListValue: [StructValue([('code', 'FROM ollama/ollama\r\nENV HOME /root\r\nWORKDIR /\r\nRUN ollama serve & sleep 10 && ollama pull gemma2\r\nENTRYPOINT ["ollama","serve"]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205b8a93d0>)])]>

이제 모든 작업이 완료되었습니다.

code_block: <ListValue: [StructValue([('code', 'gcloud beta run deploy --source . --port 11434 --region us-central1 --no-cpu-throttling --cpu 8 --memory 32Gi --gpu 1 --gpu-type=nvidia-l4'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205b8a9550>)])]>

배포 후 Ollama API를 사용해 Gemma 2와의 채팅을 시작하면 됩니다!

“최신 GPU 지원 덕분에 Cloud Run에서 Ollama를 사용해 대규모 언어 모델을 간단하게 배포할 수 있게 되었습니다. 명령어 몇 개만으로 Ollama와 앱의 원활한 통합 및 Cloud Run의 서버리스 인프라를 활용하여 손쉽게 LLM을 배포하고 관리할 수 있습니다. Cloud Run의 빠른 콜드 스타트와 신속한 확장으로 애플리케이션의 안정적인 확장이 가능합니다. 인프라나 머신러닝에 관해 전문 지식이 없어도 됩니다. 편하게 애플리케이션에 집중하세요. 나머지는 이 도구에 맡기면 됩니다.” - Jeffrey Morgan, Ollama 설립자

또한 Google Cloud Marketplace에서 제공되는 NVIDIA AI Enterprise 소프트웨어 제품군의 일부인 NVIDIA NIM 추론 마이크로서비스를 활용할 수 있습니다. 이에 따라 가속화된 고성능 AI 모델 추론이 안전하고 안정적으로 배포되므로 AI 추론 배포가 간소화되고 Cloud Run에서 NVIDIA L4 GPU의 성능이 극대화됩니다. 이 NVIDIA 블로그에서 시작하는 방법을 확인하세요.

지금 시작하기

Cloud Run을 사용하면 웹 애플리케이션을 매우 쉽게 호스팅할 수 있습니다. 이제 GPU 지원이 추가되어 AI 추론 애플리케이션에서도 최고의 서버리스, 단순성, 확장성을 누릴 수 있습니다. NVIDIA GPU가 지원되는 Cloud Run을 사용하려면 g.co/cloudrun/gpu에서 프리뷰 프로그램을 신청하고 환영 이메일을 기다리세요.

GPU가 지원되는 Cloud Run에 대해 자세히 알아보려면 NVIDIA 및 Ollama와 함께한 2024년 8월 21일 자 라이브 스트림을 확인하세요. Cloud Run의 새로운 기능을 다루고 다양한 시나리오에서 Cloud Run을 사용하는 방법을 시연합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

예약 백업 예시 살펴보기

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

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

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

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

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

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

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

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

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

다음 단계

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

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

스타트업 환경에서 Google Cloud 서버리스 기술을 사용하여 빠르게 변경하고 개선하기

Mon, 06 Feb 2023 00:00:00 +0000

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

스타트업은 MVP(최소 기능 제품)에 빠르게 도달하고 얼리 어답터의 의견을 수집하며 짧은 주기로 제품을 변경하고 개선해야 합니다. 기능을 개발하고 변경 및 개선하는 것과 관계없는 모든 활동이 출시를 지연시키는 요인이 되며, TTM(time to market)이 중요한 상황에서 이는 심각한 문제를 불러 일으킵니다.

Google Cloud는 완전 관리형 서버리스 플랫폼에서 백엔드 서비스를 빌드하고 실행하도록 지원하는 제품을 제공하여 시간을 절약하고 서비스 실행에 필요한 인프라의 프로비저닝 및 관리 부담을 덜도록 도와줍니다. 덕분에 인프라에 쓰는 시간이 줄어 서비스 구현과 변경 및 개선에 더 많은 시간을 투자할 수 있습니다. 또한 대부분의 서버리스 제품은 처음에 초기 비용이 거의 들지 않는 '사용한 만큼만 지불' 가격 책정 모델을 지원합니다. 서비스와 스타트업의 규모에 따라 가격이 증가하므로 원할 때 필요한 만큼만 지불하면 됩니다.

이러한 제품 중 몇 가지를 살펴보고 빠르게 변경 및 개선하는 데 어떤 도움을 주는지 알아보겠습니다.

코드를 실행하는 위치

먼저 코드를 배포하고 실행할 위치를 결정해야 합니다. Cloud Functions는 Google Cloud에서 코드를 실행하는 가장 쉬운 방법입니다. Cloud Functions를 사용할 경우 지원되는 언어로 간단한 함수를 작성하고 이 함수를 트리거하는 방법(HTTP 또는 이벤트를 통해)을 결정하면 Cloud Functions가 해당 함수를 실행, 트리거, 자동 확장하는 방식과 관련된 모든 세부적인 작업을 처리해 줍니다.

Cloud Functions는 기본적으로 전체 앱이 아닌 단일 용도의 사용 사례를 위해 설계되었기 때문에 제한사항을 숙지하고 있어야 합니다. 예를 들어 사용할 수 있는 언어의 종류에 제한이 있으며 정해진 시간 내에 함수가 응답해야 합니다.

Cloud Functions의 제한사항으로 인해 한계에 부딪힌 경우 더 유연한 Cloud Run을 사용할 수 있습니다. Cloud Run 서비스에서는 함수 대신 서버리스 HTTP 컨테이너를 실행합니다. 자체 런타임의 정의가 가능해 원하는 언어를 사용할 수 있고 컨테이너에서 모두 실행할 수 있는 한 간단한 함수가 아닌 더 정교한 로직을 구현할 수 있습니다.

요청을 지속적으로 처리하는 서비스가 아니라 완료될 때까지 실행되는 코드만 필요한 경우 Cloud Run 작업을 사용하면 됩니다. 완전 관리형 서버리스 환경에서 장기 실행되는 여러 컨테이너를 동시에 실행할 수 있습니다.

Cloud Functions와 Cloud Run을 사용하는 경우 모두 사용자는 함수나 컨테이너를 작성하는 데 집중하면 됩니다. 이를 실행하고 확장하는 데 필요한 인프라는 Google Cloud가 관리해 줍니다. 덕분에 서비스의 기능을 빠르게 변경하고 개선할 수 있습니다.

서버리스 개발을 위한 Cloud Code

서비스 실행을 위해 Cloud Functions 또는 Cloud Run 중 무엇을 사용하든 Cloud Code를 사용해 원하는 IDE에서 빠르게 서비스를 만들어 Google Cloud에 배포할 수 있습니다.

Cloud Code에는 Cloud Functions 또는 Cloud Run 애플리케이션을 신속하게 만들 수 있는 템플릿이 있습니다.

이후 IDE에서 이러한 서비스를 배포하고 배포된 Cloud Functions 및 Cloud Run 서비스 목록을 볼 수 있습니다.

서비스 조정 방법

서비스를 실행한 후에는 단순한 HTTP 이상의 트리거 방법을 결정해야 합니다. Cloud Scheduler를 사용하면 시간에 따라 실행할 수 있습니다. 보다 세밀한 제어를 원하는 경우 Cloud Tasks 큐로 HTTP 서비스를 앞에 배치하면 재시도, 비율 제한, 중복 제거 등 정교한 기능을 즉시 사용할 수 있습니다.

여러 개의 서비스를 사용할 때는 각 서비스의 통신 및 조정 방법도 결정해야 합니다. 다음과 같은 옵션이 있습니다.

직접적인 서비스 간 통신
간접적인 이벤트 기반 통신(코레오그래피라고도 함)
통신을 지시하는 중앙 조정자

직접적인 서비스 간 통신은 구현하기 쉽습니다. 하지만 서비스 간에 긴밀한 결합이 형성되므로 피하는 것이 좋습니다.

이벤트 기반 통신을 위해 Google Cloud에서는 Pub/Sub 및 Eventarc를 지원합니다. Pub/Sub는 이벤트 전송 관련 고도의 맞춤설정을 지원하는 낮은 수준의 서비스인 반면, Eventarc는 서비스를 연결하는 더 쉬운 시맨틱스를 갖춘 높은 수준의 서비스입니다. 중요한 점은 두 서비스 모두 완전 관리형 글로벌 서비스로서 기본 인프라에 대한 걱정 없이 이벤트 소스를 이벤트 소비자와 연결하도록 도와준다는 것입니다.

서비스 조정을 원한다면 Workflows를 사용하면 됩니다. 서비스 조정 정의에서 서비스를 호출할 순서와 방법을 정의하면 Workflows에서 사용자가 정의한 방식대로 호출을 수행하고 이와 더불어 출력을 캡처하고 오류를 처리해 줍니다.

이러한 모든 조정 서비스가 서버리스 방식으로 실행되어 기본 인프라에 대해 걱정할 필요 없이 실질적인 서비스에 더 많은 시간을 쓸 수 있습니다.

서버가 필요한 경우

서버리스 플랫폼의 제한사항으로 인해 서버가 필요할 때도 있습니다. 예를 들어 모든 서버리스 플랫폼에는 워크로드를 실행할 수 있는 시간과 워크로드에 포함할 수 있는 CPU 및 메모리 리소스에 대한 제한이 있습니다. Cloud Functions 또는 Cloud Run과 같은 서버리스 서비스에서 코드를 실행할 수 없더라도 Batch를 사용하면 Compute Engine의 가상 머신(VM)에서 일괄 작업을 실행하고 관리할 수 있습니다. 마찬가지로 Workflows와 해당 Compute Engine 커넥터를 사용하면 Workflows를 통해 VM에서 코드를 실행하고 VM 수명 주기를 관리할 수 있습니다. 두 경우 모두 실제 워크로드가 서버에서 실행되어 그에 따른 전체적인 유연성을 누릴 수 있지만 서버 관리는 Batch 및 Workflows와 같은 서비스에서 서버리스 방식으로 처리됩니다.

결론

코드를 실행해야 할 때마다 이 코드를 서버리스 플랫폼에서 실행할 수 있는지 자문해 보세요. 실행할 수 없더라도 서버리스 플랫폼에서 수명 주기를 관리할 수 있습니다. 클라우드에 인프라 관리를 많이 위임할수록 실질적인 서비스를 개발하고 변경 및 개선하는 데 소중한 시간을 더 많이 할애할 수 있습니다.

Workflows로 빌드할 수 있는 3가지 범용 서버리스 패턴

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

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

2021년 1월부터 Google Cloud의 Workflows 조정 및 자동화 서비스가 정식 버전으로 제공되고 있습니다. 또한 다른 Google Cloud 제품과의 원활한 통합 기능을 제공하는 커넥터의 미리보기 버전을 사용할 수 있도록 Workflows를 업데이트했습니다. Workflows와 커넥터를 함께 사용하면 고급 서버리스 애플리케이션을 빌드하는 데 도움이 되는 범용 아키텍처 패턴을 효과적으로 설계할 수 있습니다.

Workflows는 모든 Google Cloud API와 인터넷에서 사용할 수 있는 HTTP 기반 API에서 작업을 조정할 수 있도록 설계된 서버리스 제품입니다. 인프라 관리가 필요하지 않으며 워크플로가 작업 완료를 기다리는 시간에 대해서 비용이 발생하지 않습니다. Workflows의 핵심 기능을 자세히 알아보려면 Google Cloud의 이전 블로그 게시물을 참고하세요.

이 블로그 게시물에서는 반복 워크플로 실행 예약, 결과 폴링을 통한 장기 실행 API 요청의 처리, 데이터베이스 항목 배열을 통한 반복 등 몇 가지 유용한 아키텍처 패턴을 살펴보겠습니다.

예약 워크플로

사용자 트래픽이 예상된 정상 범위를 벗어날 때마다 지원팀의 개입이 필요한 전자상거래 웹사이트나 게임 애플리케이션에 대해 생각해 보겠습니다. 예를 들어 사용자 수가 예외적으로 적으면 서비스 중단이 발생한 것으로 보일 수 있고, 동시 실행 사용자 수가 예상보다 많으면 확장성 문제가 발생할 수도 있습니다.

동시 실행 온라인 사용자 수는 Firestore 데이터베이스에 분산 카운터로 저장되며 로그인/로그아웃 트랜잭션에 따라 업데이트됩니다. 워크플로는 이 카운터 값을 주기적으로 확인하고 값에 따라 다른 조치를 취해야 합니다.

다음 워크플로를 살펴보세요.

이 워크플로는 5분마다 트리거되며 Firestore Connector를 사용해 현재 사용자 카운터 값을 Firestore 데이터베이스에서 가져옵니다. 또한 카운터 값 외에도 이전 워크플로 실행 시 저장된 마지막 트래픽 상태(예: '낮음', '정상', '높음')를 가져옵니다.

Workflows에 기본 제공되는 스위치 단계는 커스텀 수식을 결합해 현재 카운터 값이 워크플로의 이전 실행에 저장된 상태와 다른 상태에 해당하는지를 판단하는 데 사용됩니다. 상태가 달라진 경우 Firestore 데이터베이스에 새로운 상태가 저장되고 Pub/Sub 커넥터가 지원팀에 푸시 메시지를 전송해 상태 변화를 알려줍니다. 워크플로는 현재 카운터 값뿐 아니라 마지막으로 저장된 상태도 확인하기 때문에 상태가 변경된 경우에만 알림이 전송됩니다.

몇 단계만 거치면 위의 워크플로는 완전한 실행 내역 추적이 가능한 안정적인 서버리스 애플리케이션이 될 수 있습니다. 기본 제공되는 Identity and Access Management(IAM) 통합 기능은 Firestore, Pub/Sub 등 다른 Google Cloud 제품과의 상호작용에 따른 복잡성을 줄여줍니다.

Cloud Scheduler를 사용해 위 예시와 같이 워크플로 실행을 예약하는 방법을 알아보려면 이 가이드를 참고하세요.

API 폴링이 포함된 워크플로

이번에는 외부 API를 사용하는 장기 실행 작업의 실행을 요청하는 워크플로를 살펴보겠습니다. 외부 API는 작업 실행 요청을 수락하고 이 작업의 실행 상태를 폴링하는 데 사용되는 고유의 JobID를 반환합니다. 이러한 작업에는 몇 시간이 걸릴 수 있으며 워크플로는 작업이 완료된 후에만 다음 단계를 진행할 수 있습니다. 이 API에는 워크플로에 작업 완료를 알려주는 기능이 없기 때문에 워크플로가 작업 상태를 주기적으로 폴링해야 합니다.

아래 제시된 워크플로는 이 패턴을 수행하면서 2분마다 작업 상태를 확인합니다. Workflows의 가격 책정 모델은 실행된 단계의 수를 기준으로 하며 대기 작업 시간에 대한 비용은 청구되지 않습니다. 워크플로는 최대 1년 동안 실행 가능하기 때문에 가장 긴 장기 실행 작업도 계속 처리할 수 있습니다.

실제 상황에서는 이 워크플로를 시작하기에 앞서 안전한 저장 시스템에서 외부 API에 대한 인증 키를 가져오는 단계를 추가해야 할 수 있습니다. Secret Manager를 키 또는 비밀번호 저장 시스템으로 사용하고 Secret Manager Connector 기능을 사용해 키 값을 가져오는 것이 좋습니다.

데이터베이스 레코드 배열을 통한 반복

이번 예시는 애플리케이션이 고객 레코드를 매일 한 번씩 확인하고 기한이 지난 인보이스에 대한 이메일 알림을 고객에게 전송해야 하는 경우입니다.

아래 워크플로는 Firestore Connector를 사용해 연체 대금이 있는 모든 고객의 항목을 가져오는 쿼리를 수행합니다. 워크플로는 이 세트를 반복하면서 SendGrid와 같은 외부 Email API를 사용해 각 고객에게 연체 대금에 대한 이메일 알림을 전송합니다.

위 예시는 이 샘플 워크플로에서 볼 수 있듯이 배열을 처리하고 각 배열의 모든 요소에 대한 작업을 수행할 수 있는 Workflows의 기능을 활용합니다. 워크플로에서 오류 처리와 재시도를 지정하면 간헐적인 장애나 특정 항목의 오류 때문에 나머지 고객에게도 메시지를 성공적으로 전송하지 못하는 경우를 예방할 수 있습니다.

이전 예시와 유사하게 이 워크플로는 이메일 서비스에 대한 액세스 키를 가져오기 위해 Secret Manager에 대한 커넥터 호출로 확장해야 할 수 있습니다.

Workflow 준비하기

실제 상황에서 비즈니스 계열 애플리케이션은 여러 아키텍처 패턴을 조합하여 사용해야 하는 경우가 많습니다. 고객의 실제 사용 사례는 위 예시와 다를 수 있지만 주기적 예약, 폴링, 배열 반복은 범용적으로 사용되며 수많은 구현을 구성하는 요소입니다. 서버리스 및 API 기반 아키텍처에 대한 Workflows의 지원 덕분에 지속적인 운영 오버헤드를 최소화하면서도 비즈니스 로직을 완전히 제어할 수 있습니다. 또한 커넥터를 통해 Pub/Sub, Firestore, Compute Engine, Secret Manager, Cloud Tasks 등 Google Cloud 제품을 사용 환경에 간편하게 통합할 수 있습니다.

이제 Workflows가 정식 버전으로 제공되므로 비즈니스 계열 애플리케이션 제작을 위해 Workflows를 안심하고 사용할 수 있으며 기본 제공되는 API 호출 오류 처리 기능을 통해 애플리케이션의 안정성을 더욱 향상할 수 있습니다. 자세히 알아보려면 지금 Workflows 방문 페이지로 이동하거나 바로 Cloud Console로 이동해 사용해 보세요.

L’Oréal Beauty Tech Data Platform - 테라바이트 및 서버리스 데이터 혁신 사례

Wed, 06 Apr 2022 00:00:00 +0000

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

편집자 주: 오늘의 게스트 게시물에서는 뷰티 업계 선두업체인 L'Oréal이 완전 관리형 서비스를 기반으로 최신 데이터 플랫폼을 구축한 방법에 대해 소개합니다. L'Oréal은 Cloud Run을 통해 BigQuery로 다양한 데이터 세트를 수집하고 이를 관련 비즈니스 도메인 표현으로 변환하여 조직 전체의 이해관계자가 이해할 수 있게끔 조정하고 있습니다. Forrester의 Total Economic Impact 보고서에서 Cloud Run이 기업에 어떤 이점을 제공하는지 자세히 알아보세요.

L’Oréal은 과학적 연구로 탄생한 회사입니다. 100년이 넘는 세월 동안 꾸준히 뷰티 업계의 미래를 개척했으며 끝없는 탐구를 통해 새로운 지평을 열었습니다. 그 결과 세계 최고의 뷰티 선두업체(2021년 연간 매출 약 €320억)로 자리매김했으며 현재 150개국에서 85,000명이 넘는 직원들이 일하고 있습니다.

L’Oréal은 지금도 획기적인 과학과 최첨단 기술의 힘으로 뷰티 업계의 미래를 만드는 끝없는 여정을 이어가고 있습니다. 또한 뷰티 테크 기업으로서 수십 년 동안 축적된 풍부한 데이터 자산을 활용하여 즉각적이고 정교한 분석에 기반한 효과적인 의사 결정을 내리고 있습니다.

글로벌 브랜드를 감독하기 위해서는 현지 요구사항에 맞춰 조정해야 하므로 브랜드 데이터가 나타내는 의미를 심층적으로 이해하고 국가별로 상이한 법률 및 규제 요건을 관리해야 합니다. 최종 목표는 안전하고 규정을 준수하며 지속가능한 데이터 웨어하우스를 최대한 효율적이고 효과적으로 운영하는 것입니다.

L’Oréal은 조직에서 소매점 매장까지 다양한 소스에서 내부 및 외부 데이터를 동기화 및 집계하고 있습니다. 이 때문에 Google Cloud를 사용하기 전에는 데이터 웨어하우스 인프라 관리가 매우 복잡하고 어려웠습니다. 그러던 중 사용 공간이 너무 커서 표준화된 방법으로 데이터를 처리하는 것은 불가능하다는 사실을 깨달았습니다. 모든 프로세스가 공급업체별로 다르고 인프라가 불안정했습니다. 그에 따라 복잡한 데이터 인프라 요구에 맞는 솔루션을 찾아 나서면서 다음과 같은 타협 불가능한 원칙을 정의했습니다.

노옵스(no-ops): L’Oréal 개발자의 직무는 서버 관리가 아닙니다. 개발자가 서버 관리에 집중하기보다는 모든 소비자에게 맞춤설정된 포용적인 뷰티 경험을 제공하는 데 전념할 수 있도록 수요에 따라 확장되는 탄력적인 인프라가 필요합니다.
보안: 국가별로 다른 엄격한 보안 및 규정 준수 요건을 마련하고 제로 트러스트 보안 전략을 채택하고 있습니다. L’Oréal에서는 내부 데이터와 고객 데이터를 모두 안전하게 보호하고 암호화해야 합니다.
지속가능성: 온프렘 데이터 센터 및 퍼블릭 클라우드 서비스를 포함한 다양한 환경에 데이터가 위치합니다. 데이터 이동 및 복제의 복잡성과 환경에 미치는 영향을 최소화하면서 이 데이터에 안전하게 액세스하고 분석할 수 있어야 합니다.
엔드 투 엔드 감독: 개발자가 서버 관리에만 매달릴 수는 없기 때문에, 문제가 발생할 경우 시스템을 모니터링하고 분류할 수 있는 '단일 제어 창' 대시보드가 필요합니다.
쉬운 배포: 안전한 코드 배포를 위해 속도를 저하시켜서는 안 됩니다. 과학의 지평을 넓히고 아름다움을 재창조하는 혁신 기술을 끊임없이 개발하고 있습니다. 코드 배포 프로세스를 원활하고 안전하게 만들어 주는 통합된 도구가 필요합니다.
이벤트 기반 아키텍처: 데이터 품질과 적시성에 대한 기대치가 높은 연구, 제품, 비즈니스, 엔지니어링팀에서 전역적으로 데이터를 사용하고 있습니다. 거의 실시간에 가까운 데이터를 토대로 많은 내부 절차 및 분석이 이루어지고 있습니다.
'서비스형'으로 제공되는 데이터 제품: L’Oréal은 직원들의 역량을 강화하여 빠른 속도로 비즈니스 가치를 창출하고자 했습니다. 이를 위해서는 중요한 솔루션 제공 과정에서 가능한 한 개발자를 배제할 수 있는 솔루션이 필요합니다.
ELT(추출-로드-변환): 목표는 데이터 웨어하우스에 데이터를 최대한 빨리 로드하는 패턴을 구현하여 SQL 변환을 활용하는 것입니다.

이러한 원칙을 염두에 두고 시장의 여러 공급업체를 고려한 끝에 엔드 투 엔드 Google Cloud 서버리스 및 데이터 도구를 도입했습니다. 이미 몇 가지 절차에 BigQuery를 포함한 Google Cloud를 사용 중이었으며 제품에 대한 만족도가 높았습니다.

그리고 이제 L’Oréal Beauty Tech Data Platform을 완벽하게 지원하기 위해 Google Cloud 사용을 확장했습니다.

L’Oréal의 Beauty Tech Data Platform은 두 가지 유형의 소스에서 얻은 데이터를 통합합니다. API를 통해 직접 얻는 데이터는 스키마에 맞춰 조정하기가 쉽고 BigQuery에 직접 삽입되며, 통합을 통해 얻는 일괄 데이터는 Eventarc 메커니즘을 사용한 이벤트 기반 변환이 필요합니다. 이러한 변환은 Cloud Run 및 Cloud Functions(2세대)에서 수행되거나 SQL에서 직접 처리되며, Google Cloud를 사용하면서 빠른 적응이 가능해졌습니다.

현재 Google Cloud에서 제공하는 기본 제로 트러스트 기능을 사용해 약 5,000명의 사용자를 지원하는 8,500개의 흐름이 존재합니다. 실제로 이러한 흐름은 Google Cloud 및 기타 타사 서비스에서 시작됩니다.

BigQuery는 데이터 웨어하우스에서 표준 SQL을 범용 언어로 채택하여 쿼리 및 보고에 대한 모든 기대를 충족할 수 있었습니다. 또한 통합 쿼리 등의 기능을 사용하여 원본 데이터를 로드할 수 있었고 SQL을 사용해 반구조화된 데이터를 처리하여 ETL에서 ELT 데이터 수집으로 효율적으로 전환했습니다. 비파괴적인 변환을 통해 원본 데이터를 소스에서 BigQuery로 로드하는 이러한 접근 방식 덕분에 BigQuery 내에서 바로 새로운 사용 사례에 맞게 데이터를 재처리하기가 쉬워졌습니다.

자사 애플리케이션은 온프레미스, Google Cloud, 기타 퍼블릭 클라우드와 같은 여러 환경에서 호스팅됩니다. 이 때문에 BigQuery Omni를 사용하기 전에는 데이터 엔지니어 및 분석가가 클라우드 전반의 데이터를 기본적으로 분석하기가 어려웠습니다. 이 BigQuery 기능 덕분에 기본 BigQuery 사용자 인터페이스를 사용하여 단일 제어 창을 통해 클라우드 전반의 데이터에 액세스하고 이를 분석할 수 있게 되었습니다. BigQuery Omni가 없었다면 팀에서 기본적으로 교차 클라우드 분석이 불가능했을 것입니다. 또한 민감한 정보의 이동은 현지 세금이나 해저 케이블 전송 때문에 많은 비용이 드는 것은 물론, 현지 규정으로 인해 위험도가 매우 높으며, 심지어 금지되는 경우도 있는데 이제는 이런 민감한 정보를 이동할 필요가 없어졌습니다.

현재 Google Cloud는 BigQuery에 100TB의 프로덕션 데이터를 저장하고 매달 20TB의 데이터를 처리하는 Beauty Tech Data Platform을 지원하고 있습니다. Salesforce, SAP, Microsoft, Google Ads 등 여러 데이터 소스에서 8,000개가 넘는 제어된 데이터 세트와 2백만 개 이상의 BigQuery 테이블을 얻고 있습니다.

특정한 커스텀 라이브러리가 필요한 보다 복잡한 전환의 경우, Cloud Workflows의 도움을 받아 컨테이너의 단계를 Cloud Run, Cloud Functions, BigQuery 작업을 통해 조정함으로써 복잡성을 매우 효율적으로 관리하고 있습니다. L'Oréal의 데이터를 변환하고 가치를 높이기 위해 이 방법을 주로 사용하고 있습니다.

또한 API 수집, 일괄 데이터 로드, 사후 로드 변환에 BigQuery와 Google Cloud의 서버리스 컴퓨팅을 사용하여 적은 비용으로 전체 시스템을 하나의 신뢰 경계 안에 유지할 수 있습니다. 수집, 쿼리, 변환이 모두 완전히 탄력적인 주문형 방식으로 이루어지기 때문에 더 이상 시스템의 컴퓨팅 또는 분석 구성요소에 대한 용량 계획을 세울 필요가 없습니다. 이러한 서비스의 사용한 만큼만 지불하는 모델은 사용 시에만 요금을 지불한다는 L’Oréal의 전략과 완벽하게 일치합니다.

Google Cloud는 Beauty Tech Data Platform의 요구사항을 충족했습니다. 또한 Google Cloud는 엔드 투 엔드 감독을 지원하는 노옵스(no-ops) 방식의 안전하고 배포가 쉽고 커스텀 개발이 자유로운 이벤트 기반 플랫폼을 제공하는 데 그치지 않고 지속가능성 노력에도 도움을 주었습니다.

퍼블릭 클라우드 사용에 따른 환경 오염도를 측정하고 이해할 수 있는 능력 또한 지속가능한 기술 로드맵의 핵심 요소입니다. Google Cloud 탄소 발자국을 통해 지속가능한 인프라 접근 방식과 아키텍처 원칙이 환경에 미치는 영향을 쉽게 확인할 수 있습니다. Beauty Tech 플랫폼에는 미래형 기업으로서 미래의 뷰티 제품을 개발한다는 L’Oréal의 전략적 포부가 담겨 있습니다.

지속가능한 기술은 소비자를 위한 책임감 있는 뷰티 제품과 지속가능하게 설계된 직원용 기술 서비스를 만든다는 포부를 실현하는 데 필수적인 중요한 단계입니다. 모두가 각자의 역할이 있으며, 모두가 힘을 합치면 긍정적인 영향력을 행사할 수 있습니다.

Google Cloud의 데이터 생태계와 서버리스 도구는 매우 상호 보완적이며, 모든 요구를 충족하는 차세대 데이터 분석 플랫폼을 구축할 수 있도록 지원해 줬습니다.

Google Cloud에서 서버리스 및 BigQuery를 함께 사용해 보세요.

Functions, 이벤트, 트리거를 사용해 이벤트 기반 앱을 빌드하는 방법

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

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

오늘날 많은 개발자들이 이벤트 기반 아키텍처(EDA)를 사용하여 앱을 설계하고자 합니다. 이 소프트웨어 아키텍처 패러다임은 이벤트 생성, 인식, 사용, 반응을 촉진합니다. 느슨하게 결합된 소프트웨어 구성요소와 서비스 사이에 이벤트를 전송하는 애플리케이션과 시스템을 설계하고 구현하는 데 최적인 아키텍처 패러다임입니다.

Google Cloud의 서비스로서의 기능(FaaS) 제품인 Cloud Functions를 사용하면 이벤트와 트리거를 활용하여 이벤트 기반 애플리케이션을 빌드할 수 있습니다. 이벤트는 데이터베이스 내 데이터 변경사항, 스토리지 시스템에 추가된 파일 또는 생성된 새로운 가상 머신 인스턴스 등 개발자가 작업할 클라우드 환경 내에서 발생하는 모든 종류의 활동이나 요소를 의미합니다. 이벤트가 발생하면 트리거를 통해 함수를 호출할 수 있습니다. Cloud Functions는 서버 관리 없이 코드를 실행할 수 있고 이벤트와 트리거에서 작동할 수 있는 확장 가능하고 사용한 만큼만 지불하는 서비스로서의 기능(FaaS)을 제공합니다.

이 블로그에서는 Cloud Functions, 이벤트, 트리거를 사용하여 확장 가능한 이벤트 기반 애플리케이션을 빌드하는 방법을 설명합니다. 최근 뉴스 이벤트의 예시를 통해 아키텍처를 설명하고 Cloud Functions, 이벤트, 트리거, Natural Language API를 사용하여 사람, 위치, 조직, 이벤트, 소비재 등 알려진 모든 항목에 대한 항목 감정 메타데이터 저장소를 빌드하는 단계별 절차를 살펴겠습니다.

그러면 이 저장소를 사용하여 뉴스 내 다양한 항목에 대해 표현된 감정이 긍정적인지 부정적인지 판단할 수 있습니다. 예를 들어 2021년 10월 12~14일까지 진행된 Google Cloud Next ‘21에서는 다양한 Google Cloud 제품이 논의됐습니다. 논의된 제품에 대한 여러 언론이나 개발자 블로그의 반응을 파악하는 것은 이벤트의 전체적인 효과를 이해하는 데 중요한 정보가 될 수 있습니다.

Cloud Functions, 이벤트, 트리거 이해하기

예시를 살펴보기 전에 아키텍처의 다양한 구성요소를 알아보겠습니다.

이벤트는 데이터베이스 내 데이터 변경사항, 스토리지 시스템에 추가된 파일 또는 생성된 새로운 가상 머신 인스턴스 등 개발자가 작업해야 할 수 있는 클라우드 환경 내에서 발생하는 모든 종류의 활동이나 요소를 의미합니다. Cloud Functions는 다음과 같은 환경에서 발생하는 이벤트를 지원합니다.

HTTP
Cloud Storage
Cloud Pub/Sub
Cloud Firestore
Firebase(실시간 데이터베이스, Cloud Storage, 애널리틱스, 인증)
Cloud Logging

예를 들어 Cloud Pub/Sub 주제에 새 메시지가 게시되거나 Cloud Storage 버킷컷에 변경사항이 발생하면 작업을 트리거할 수 있는 이벤트가 생성될 수 있습니다. 이벤트가 발생하면 애플리케이션 상태가 변경될 수 있습니다. 예를 들어 고객이 제품을 구매하면 제품 상태가 '재고 있음'에서 '판매됨'으로 변경됩니다.

이러한 기본 이벤트 소스 외에도 기타 많은 소스에서 Cloud Build 알림이나 Cloud Scheduler 작업 같은 메시지를 Pub/Sub를 통해 제공할 수 있습니다.

Cloud Functions에는 HTTP 함수와 이벤트 기반 함수 등 두 가지 유형이 있습니다. 또한 이벤트 기반 함수는 작성된 Cloud Functions 런타임에 따라 백그라운드 함수 또는 CloudEvent 함수일 수 있습니다.

HTTP 함수

HTTP 함수는 표준 HTTP 요청에서 호출될 수 있습니다. 이 HTTP 요청을 보낸 클라이언트는 동기식으로 응답을 기다리고 HTTP 함수는 GET, PUT, POST, DELETE, OPTIONS 같은 일반 HTTP 요청 메서드의 처리를 지원할 수 있습니다.

이벤트 기반 함수

Cloud Functions는 이벤트 기반 함수를 사용하여 Pub/Sub 주제의 메시지 또는 Cloud Storage 버킷의 변경사항과 같은 클라우드 인프라의 이벤트를 처리할 수 있습니다. Cloud Functions는 두 가지 하위 유형의 이벤트 기반 함수를 지원합니다.

백그라운드 함수: Node.js, Python, Go, 자바 Cloud Functions 런타임용으로 작성된 이벤트 기반 함수를 백그라운드 함수라고 합니다. 자세한 내용은 백그라운드 함수 작성을 참조하세요.
CloudEvent 함수: .NET, Ruby, PHP 런타임용으로 작성된 이벤트 기반 함수를 CloudEvent 함수라고 합니다. 자세한 내용은 CloudEvent 함수 작성을 참조하세요.

백그라운드 함수와 CloudEvent 함수 같은 이벤트 기반 함수는 Pub/Sub 주제의 메시지, Cloud Storage 버킷의 변경사항 또는 Firebase 이벤트 같은 이벤트에 반응하여 Cloud Functions가 간접적으로 호출될 때 사용될 수 있습니다.

CloudEvent 함수는 백그라운드 함수와 개념적으로 유사합니다. 두 유형의 함수에서 주된 차이점은 CloudEvent 함수가 CloudEvents라는 업계 표준 이벤트 형식을 사용한다는 것입니다. 또 다른 차이점은 Cloud Functions가 다른 컴퓨터 플랫폼에서 재생산될 수 있는 HTTP 요청을 사용하여 CloudEvent 함수를 직접 호출할 수 있다는 점입니다. 이러한 차이점 덕분에 CloudEvent 함수를 컴퓨팅 플랫폼 간에 원활하게 이전할 수 있습니다.

이 블로그에서는 CloudEvent 함수를 통해 Cloud Functions을 사용하여 이벤트 기반 아키텍처를 만드는 방법을 설명하는 데모를 만들어 보겠습니다.

이벤트 기반 아키텍처(EDA)의 이해

이벤트 기반 아키텍처(EDA)는 이벤트 생성, 인식, 사용, 반응을 촉진하는 소프트웨어 아키텍처 패러다임입니다. 이 아키텍처 패러다임은 느슨하게 결합된 소프트웨어 구성요소와 서비스 사이에 이벤트를 전송하는 애플리케이션과 시스템을 설계하고 구현하는 데 최적입니다.

예시를 통해 종합적으로 살펴하기

이 예시는 Cloud Functions(이벤트 기반), Cloud Scheduler, Google Cloud 머신러닝 API 같은 관리형 서비스를 사용하여 RSS 피드 콘텐츠를 분석하는 서비스를 빌드하는 이벤트 기반 아키텍처의 구축에 초점을 둡니다.

목표

이 예시를 통해 머신러닝 API를 사용하여 매일 일정한 간격으로 RSS 피드와 항목 감정 분석을 수집하고, 분석하고, 저장해 보겠습니다. 항목 분석과 감정 분석이 결합된 항목 감정 분석은 텍스트 내에서 항목에 대해 표현되는 감정(긍정적 또는 부정적)을 판단하려고 시도합니다. 이 분석은 다음과 같은 경우에 유용합니다.

블로그나 뉴스 기사에 언급된 제품, 회사 또는 인물 등 모든 항목을 확인하려는 경우
항목에 대해 어떤 감정이 표현됐는지 파악하려는 경우

데이터 엔지니어링팀은 이러한 사용 사례를 바탕으로 뉴스에서 가장 많이 언급된 항목과 그에 대한 감정 같은 최근 트렌드를 살펴서 해당 항목이 시장에서 어떻게 인식되는지 파악할 수 있습니다.

아키텍처:

위 아키텍처는 RSS 피드를 수집하자마자 분석할 수 방법에 대한 워크플로를 보여줍니다. 로직은 다음과 같습니다.

STEP 1: 하나의 RSS 피드 링크에는 하나 이상의 URL이 있습니다. 함수를 작성하여 RSS 피드 링크의 URL을 파싱하고 큐에 저장합니다.
STEP 2: 1단계의 큐에서 URL을 하나씩 읽고 웹페이지 콘텐츠를 다운로드하는 함수를 작성합니다. 모든 웹페이지 콘텐츠를 영구 스토리지에 저장합니다.
STEP 3: 마지막으로, 2단계의 영구 스토리지에 저장된 웹페이지 콘텐츠를 읽고, 분석하고, 결과를 또 다른 영구 스토리지 대상에 쓰는 또 따른 함수를 작성합니다.

다음은 Google Cloud 관리형 서비스를 사용하여 위에 설명한 단계를 빌드하는 단계별 프로세스입니다.

STEP 1: Cloud Scheduler가 샘플 메시지를 Pub/Sub에 작성합니다. 이 이벤트가 발생하면 바로 시작하도록 구성된 클라우드 함수를 호출합니다.

위와 같은 구성에 따라 매일 오전 5시(PDT)에 메시지를 Pub/Sub 주제에 작성합니다.

STEP 2: RSS 피드에는 하나 이상의 웹페이지 URL이 있습니다. 1단계에서 Pub/Sub에 작성된 메시지가 RSS 피드의 콘텐츠를 다운로드하고 콘텐츠에서 웹페이지 URL 목록을 파싱하는 클라우드 함수를 트리거합니다. 그러면 해당 URL이 추가 처리를 위해 또 다른 Pub/Sub 주제에 작성됩니다.

위와 같은 구성에 따라 Pub/Sub 트리거를 통해 스케줄러 이벤트가 도착하는 오전 5시에 Cloud Functions가 실행되기 시작합니다.

다음은 C#, .NET core 3.1로 작성되어 RSS 피드를 파싱하고 거기에서 웹페이지 URL을 수집하는 새플 코드입니다.

code_block: <ListValue: [StructValue([('code', 'var url = "https://news.google.com/news/rss";\r\n HttpWebRequest req = WebRequest.Create(url) as HttpWebRequest;\r\n req.UserAgent = "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)";\r\n using (Stream responseStream = req.GetResponse().GetResponseStream())\r\n {\r\n using (XmlReader xr = XmlReader.Create(responseStream))\r\n {\r\n SyndicationFeed feed = SyndicationFeed.Load(xr);\r\n foreach (var item in feed.Items)\r\n {\r\n try{\r\n var t = item.Links[0].Uri.ToString();\r\n PublishMessageWithRetrySettingsAsync("<<project>>","rssfeeds", t).GetAwaiter().GetResult();\r\n \r\n }catch(Exception e)\r\n {\r\n Console.WriteLine(e.Message);\r\n }\r\n }\r\n }\r\n }'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f2060721f10>)])]>

함수 publishMessageWithRetrySettingsAsync는 여기에서 찾을 수 있습니다.

STEP 3: 2단계에서 Pub/Sub에 작성된 URL이 웹페이지 텍스트를 다운로드하고 텍스트를 Cloud Storage 버킷에 작성하는 새 클라우드 함수를 트리거합니다.

위와 같은 구성에 따라, 2단계에서 RSS 피드로부터 수집되어 Pub/Sub에 작성된 웹페이지 URL별로 클라우드 함수가 실행됩니다.

다음은 Python 3.9로 작성되어 웹페이지 텍스트를 다운로드하고 Cloud Storage에 저장하는 샘플 코드입니다. 웹페이지를 파싱하고 텍스트를 추출하는 데 BeautifulSoup 라이브러리가 사용됩니다.

code_block: <ListValue: [StructValue([('code', 'headr = {\'User-Agent\': \'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.64 Safari/537.11\',\r\n \'Accept\': \'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\',\r\n \'Accept-Charset\': \'ISO-8859-1,utf-8;q=0.7,*;q=0.3\',\r\n \'Accept-Encoding\': \'none\',\r\n \'Accept-Language\': \'en-US,en;q=0.8\',\r\n \'Connection\': \'keep-alive\'}\r\n \r\n req = Request(pubsub_message, headers=headr)\r\n page = urlopen(req)\r\n webpage = page.read()\r\n soup = bs4.BeautifulSoup(webpage, "html.parser")\r\n webpagetext = soup.get_text()\r\n client = storage.Client()\r\n bucket = client.get_bucket(\'rsscontent\')\r\n blob2 = bucket.blob(pubsub_message.replace(\'https://\',\'\').replace(\'http://\', \'\') + "contents.txt")\r\n blob2.upload_from_string(webpagetext)\r\n print("uploaded " + pubsub_message)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f206009c460>)])]>

3단계에서 아래와 같이 웹페이지 텍스트가 Cloud Storage에 저장됩니다.

STEP 4: 3단계에서 새 파일이 생성되면 웹 페이지 텍스트에 대해 항목 감정 분석을 실시하고 결과를 또 다른 Cloud Storage 버킷에 작성하는 새로운 클라우드 함수가 트리거됩니다.

이와 같은 구성에 따라, 다운로드되어 Cloud Storage 버킷에 저장된 웹 페이지 텍스트별로 클라우드 함수가 실행됩니다.

다음은 Nodejs 14로 작성되어 Cloud Storage 버킷에서 데이터를 읽고, 다운로드 웹페이지 텍스트를 파싱하여 Cloud Storage에 저장하는 샘플 코드입니다.

code_block: <ListValue: [StructValue([('code', "const document = {\r\n gcsContentUri: <<Input File Uri>>,\r\n type: 'PLAIN_TEXT',\r\n };\r\n \r\n // Detects entities in the document\r\n const [result] = await client.analyzeEntitySentiment({document});\r\n const entities = result.entities;\r\n const outputFile = outputBucket.file(outFilename);\r\n outputFile.save(JSON.stringify(entities));\r\n console.log(result);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f206009c790>)])]>

analyzeEntitySentiment함수가 항목 감정 분석을 실시합니다. Natural Language API에는 텍스트 데이터를 분석하고 주석을 달기 위한 여러 가지 메서드가 있습니다. Natural Language API를 사용하여 텍스트 데이터를 분석하는 방법은 여기를 참고하세요.

수집된 분석 데이터는 데이터 엔지니어링팀에서 ‘최근에 가장 많이 논의된 항목(사람, 제품 등)'과 ‘해당 항목에 관련된 감정’ 등에 대한 질문에 답을 찾는 데 사용될 수 있습니다. 이 같은 질문은 기존 마케팅 캠페인의 전반적인 효과나 최신 트렌드를 이해하여 마케팅 또는 홍보 캠페인을 향상하는 데 도움이 될 수 있습니다.

리소스:

위 서비스의 모든 로그는 Cloud Logging에서 사용할 수 있습니다.
Cloud Functions는 로컬에서 테스트하고 디버깅할 수 있습니다.
모든 서비스는 느슨하게 결합되어 있습니다.
Vertex AI를 사용하여 마지막에 수집된 메타데이터를 분석할 수 있습니다.

요약:

Cloud Functions는 최소한의 수고로 이벤트 기반 애플리케이션을 만드는 데 사용할 수 있는 강력한 서비스입니다. 위 둘러보기는 다양한 Google Cloud 서비스와 다국어 지원과 함께 제공되는 Cloud Functions 이벤트, 트리거, 통합을 소개합니다. 시작하려면 아래 참조를 확인하세요.

참조:

Google App Engine 앱의 보안을 강화하는 새로운 기능

Mon, 14 Feb 2022 00:10:00 +0000

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

2008년 출시된 이후 Google App Engine은 앱 개발자가 기본 인프라를 관리할 필요 없이 코드 작성에 집중할 수 있도록 사용 편의성에 중점을 두었습니다. 지난 몇 년간 인그레스 제어, App Engine 방화벽, IAP(Identity-Aware Proxy) 지원 등 앱 보안을 강화하는 데 도움이 되는 다양한 기능을 추가했습니다. 이번에는 이미 플랫폼에서 제공하던 보안 기능을 한층 더 확장하는 여러 새로운 기능을 도입합니다.

서버리스 VPC 액세스의 이그레스 제어
사용자 관리 서비스 계정

이그레스 제어

완전 관리형 플랫폼인 App Engine은 앱의 아웃바운드 트래픽을 위한 IP 주소 풀을 제공합니다. 네트워킹 세부정보를 관리할 필요가 없다는 점에서 대부분의 고객에게 이상적이지만, 발신 요청을 보다 세부적으로 제어해야 하는 고객도 있습니다.

App Engine의 새로운 이그레스 제어 기능은 Google Cloud VPC 서비스, 특히 서버리스 VPC 액세스 기능을 활용합니다. 사용자는 서버리스 VPC 액세스를 통해 커넥터를 구성하여 App Engine 앱에서 VPC 네트워크로 요청을 라우팅할 수 있습니다. 이그레스 제어를 사용하면 고객이 VPC 커넥터를 사용할 트래픽을 더욱 세부적으로 제어할 수 있습니다.

사용자는 두 가지 옵션 중에서 선택할 수 있습니다. 기본 옵션인 '비공개 범위만'의 경우 VPC 네트워크의 비공개 IP에 대한 모든 HTTP 요청이 VPC 커넥터에 전송되고, 나아가 VPC 네트워크로 전송되며 공개 IP에 대한 모든 HTTP 요청은 인터넷으로 직접 전송됩니다. 다른 옵션인 '모든 트래픽'에서는 모든 발신 HTTP 요청을 VPC 커넥터를 통해 VPC 네트워크로 라우팅합니다. 이후 해당 요청에 VPC 방화벽 규칙 및 기타 VPC 설정이 적용됩니다.

이그레스 제어로 지원되는 주요 사용 사례는 App Engine http 요청을 위한 고정 발신 IP 주소를 만드는 경우입니다. 여러 App Engine 고객들이 최종 고객 네트워크에 연결해야 하는 SaaS 서비스를 제공합니다. 대다수의 최종 고객은 특정 출처 IP의 트래픽에만 방화벽을 여는 것을 선호합니다. 이그레스 제어('모든 트래픽'으로 설정)를 사용하면 고객이 서버리스 VPC 액세스와 Cloud NAT를 사용하여 안정적인 고정 IP 주소를 구성할 수 있습니다.

사용자 관리 서비스 계정

현재 App Engine(표준 및 가변형 모두)에는 App Engine 앱 대신 다른 GCP 서비스와 상호작용하는 데 사용되는 기본 서비스 계정이 있습니다. App Engine 기본 서비스 계정은 초기 App Engine 앱 생성 프로세스 중에 설정되며 고객은 서비스 계정에 부여된 권한을 관리할 수 있습니다. 하지만 지금까지는 기본 서비스 계정이 앱의 모든 서비스에서 사용되었습니다. 즉, 특정 서비스에 실제로 필요한 권한과 상관없이 일반적인 권한 집합을 모든 서비스가 공유합니다.

새로 도입된 사용자 관리 서비스 계정을 사용하면 고객이 (배포 시점에 또는 App Engine Admin API를 통해) 앱의 버전별로 서로 다른 서비스 계정을 지정할 수 있습니다. 주요 이점 중 하나는 앱의 모든 서비스에 필요한 권한이 부여된 단일 공유 서비스 계정을 사용하는 대신 '최소 권한' 권장사항을 따라 각 서비스를 관련 태스크 수행에 필요한 권한으로만 제한할 수 있다는 것입니다. 버전별 서비스 계정의 사용 여부는 전적으로 선택의 문제입니다. 서비스 계정을 지정하지 않으면 App Engine 기본 서비스 계정이 사용됩니다.

code_block: <ListValue: [StructValue([('code', 'Services to deploy:\r\ndescriptor: [/helloworld_default/app.yaml]\r\nsource: [/helloworld_default]\r\ntarget project: [PROJECT_ID]\r\ntarget service: [default]\r\ntarget version: [VERSION_NAME]\r\ntarget url: [https://PROJECT_ID.uc.r.appspot.com]\r\ntarget service account: [version-service-account@PROJECT_ID.iam.gserviceaccount.com]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f2060c02b20>)])]>

다음 단계

새로운 이그레스 제어를 자세히 알아보려면 문서를 참고하세요. 이 기능을 처음 사용하는 경우 서버리스 VPC 액세스를 구성하는 방법을 다룬 이 페이지도 확인하세요. 자체 서비스 계정 맞춤설정에 대한 정보도 문서에서 확인할 수 있습니다.

개발자를 위해 만들어진 클라우드 — 2021년 총정리

Tue, 25 Jan 2022 00:00:00 +0000

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

2021년은 소프트웨어 개발자에게 중요한 해였습니다. 모든 기업이 디지털과 온라인 행보에 박차를 가하는 동시에 원격 개발 체제로 전환하는 모습을 보였습니다. 개발자 생산성 향상을 통한 혁신은 조사에 응답한 거의 모든 IT 담당 임원이 꼽은 최우선 과제였습니다. 그중 많은 수가 Alphabet이 오랜 기간 혁신을 거듭한 비결을 물었습니다. Google 검색 기술부터 Waymo의 무인 자동차에 이르기까지, 차세대 핵심 기술을 개발할 수 있는 비결은 무엇일까요?

답은 간단합니다. 생각을 10배 더 많이 하는 거죠. 장기간 쌓여 더 큰 결실이 되는 일련의 소소한 변화를 통해 고객이 10배 더 빠르게 개선할 수 있도록 만드는 솔루션을 찾으면 됩니다. Google Cloud에서는 고객이 혁신적인 기술 기업이 되도록 돕기 위해 이와 같은 철학을 따르고 있습니다. 최근에는 파트너, 고객, 개발자와 긴밀하게 협업하여 개발자 생산성을 10배 더 높여주는 서비스를 개발하고 있습니다.

6년 전에 Google은 관리형 Kubernetes 서비스인 Google Kubernetes Engine(GKE)을 소개했습니다. 올해에는 일체의 노드 관리 작업을 없애 Kubernetes 관리에 혁신을 불러온 GKE Autopilot을 추가했습니다. Cloud Run 서버리스 플랫폼 역시 개발자가 작은 코드 조각을 실행하던 기존의 방식에서 벗어나 서버리스 환경에서 전체 애플리케이션을 실행할 수 있도록 만든 업계 최초의 서비스였습니다. 2020년 9월부터 2021년 9월까지 Cloud Run 배포는 4배 넘게 늘었습니다. 최근에는 오픈소스 보안 재단(Open Source Security Foundation)을 공동 설립해 안전한 지속적 통합 및 지속적 배포(CI/CD) 서비스를 함께 개발하기 시작했으며, 이는 헤드라인을 장식한 사이버 보안 위협보다도 1여 년 이상 앞선 것이었습니다.

2021년에 가장 많은 고객이 Google에 솔루션을 요청한 개발 관련 과제는 다음과 같습니다.

분산된 개발자 생산성 향상
소프트웨어 공급망 보호
클라우드 기반 애플리케이션 실행 간소화

자세한 내용을 확인하려면 계속 읽어보세요.

분산된 개발자 생산성 향상

시간은 혁신을 이루는 데 있어 중요한 필수 요건입니다. 개발자 생산성에 투자하면 개발자에게 중요한 업무에 집중할 수 있는 시간적 여유가 생깁니다. 과거에 개발자는 로컬 환경에 도구를 다운로드 및 설치하고, 최신 버전 또는 종속 항목으로 업데이트하는 데 많은 시간을 보냈습니다. Cloud Shell 편집기는 완전 원격 개발 환경으로, 보안 기능이 기본 제공되며 계속 추가되고 있습니다. 이 편집기는 MySQL, Kubernetes, Docker, minikube, Skaffold 같은 개발자 도구가 사전 설치된 상태로 제공되므로 개발자는 웹브라우저와 인터넷 연결만 갖추면 생산성을 발휘할 수 있습니다. 개발자는 이제 Cloud Shell 편집기에서 바로 튜토리얼에 액세스할 수 있으며 Google 문서에서 바로 코드 샘플을 사용해 볼 수 있습니다. 또한 개발자는 빌드팩 지원 덕분에 Docker 또는 컨테이너에 대한 지식이 없어도 소스 코드에서 바로 컨테이너 이미지를 만들 수 있습니다.

소프트웨어 공급망 보호

소프트웨어 공급망 취약점은 2021년에 SolarWinds, Mimecast/Microsoft Exchange, Log4j 등의 사건을 일으키며 비즈니스, 일상, 정부 기관 전체에까지 영향을 미쳤습니다. 이에 바이든 대통령은 소프트웨어 공급망 보안 표준을 강화하는 행정 명령을 내리기에 이르렀습니다.

소프트웨어 공급망 문제를 해결하기 위해서는 전 산업분야의 기업이 힘을 모아야 합니다. Google이 오픈소스 보안 협회(Open SSF)를 공동 설립한 이유도 여기에 있습니다. Google은 소프트웨어 공급망 전반의 소프트웨어 아티팩트 무결성을 유지할 수 있도록 산업 전반에 적용되는 프레임워크인 SLSA를 제안하기도 했습니다.

종속 항목 트리가 복잡하게 얽혀 있는 오픈소스는 여전히 주요 공격 대상입니다. 실제로 대략 84%의 상업적 코드베이스에 하나 이상의 오픈소스 취약점이 존재합니다. 오늘날 개발자는 Allstar GitHub App, 오픈소스 보안 점수 카드, Open Source Insights와 같은 Google 도구를 사용해 보안 권장사항을 구현하고 오픈소스 프로젝트의 위험 점수를 판단하며 프로젝트 내부의 종속 항목을 시각화할 수 있습니다. 또한 이와 같은 종류의 오픈소스 혁신 기술 중 다수가 Google Cloud 고객이 바로 사용할 수 있도록 제공됩니다. 예를 들면 다음과 같습니다.

Apache Log4j 취약점을 완화하기 위한 상세 권장사항
Google Cloud On-Demand Scanning의 자바 스캔 기능은 개발자가 취약한 Log4j 버전을 사용하는 Linux 기반 컨테이너 이미지를 식별하는 데 매우 유용하게 사용됩니다. On-Demand Scanning은 2021년 12월 31일까지 무료로 사용할 수 있습니다.
자사의 서버리스 CI/CD 서비스인 Cloud Build는 SLSA 레벨 1 수준의 규정 준수를 기본적으로 제공합니다. 이처럼 빌드 출처를 검증함으로써 소스 코드의 바이너리를 추적해 조작을 방지하고 실행 중인 코드가 의도한 코드가 맞는지 증명할 수 있습니다.
Cloud Build의 새로운 빌드 무결성 기능은 디지털 서명을 자동으로 생성하여 무결성을 개선합니다. Binary Authorization으로 배포하기 전에 이 디지털 서명을 검사하는 방식입니다.

클라우드 기반 애플리케이션 실행 간소화

혁신이 순탄하게 이루어지는 경우는 거의 없으며 수많은 시행착오를 거치기 마련입니다. 개발자는 실험을 실행하고 오류를 신속하게 수정할 수 있는 비용 효과적인 런타임이 필요합니다. 이를 위해 GKE Autopilot은 시장에서 가장 성숙한 Kubernetes 서비스인 GKE를 채택하고, 관리형 제어 영역과 데이터 영역, 즉시 사용 가능한 최적화된 구성, 자동화된 확장성, 상태 점검 및 복원, 사용한 만큼 지불하는 요금제를 제공하여 Kubernetes 작업을 더욱 간소화합니다.

"GKE Autopilot 덕분에 비즈니스의 잠재력이 더욱 향상됐습니다. 인프라의 세부 조정에 신경 쓸 필요 없이 지속적으로 제품을 개발하고 업그레이드할 수 있게 되었습니다."—준 사카타, Ubie의 사이트 안정성 담당 소프트웨어 엔지니어

클러스터가 없으면 더욱 단순해집니다. 개발자는 Cloud Run을 통해 클러스터나 VM을 관리할 필요 없이 노드나 컨테이너 이미지에서 서비스를 실행할 수 있는 자유를 얻게 됩니다. 그와 동시에 하이퍼바이저급의 안전한 샌드박스 환경과 여러 가지 기본 제공 DevOps 기능(예: 여러 버전의 배포 환경, 점진적 출시 및 롤백, GitHub, Cloud Build 통합)을 제공합니다. 이 환경은 웹과 모바일 애플리케이션을 개발하기에 이상적입니다. 2021년에 인스턴스당 동시 실행 수 증가, 새로운 CPU 할당 제어, 표준 Docker 이미지 지원 같은 기능이 추가되면서 서버리스의 이점은 이제 기존 워크로드를 포함한 더 광범위한 워크로드로 확대될 수 있습니다. 추가적으로, 약정 사용 계약 같은 결제 유연성과 CPU 상시 사용 같은 기능과 더불어 새로운 비용 관리 수단을 사용함으로써 서버리스 환경에서 보다 안정적인 패턴의 워크로드를 비용 효과적으로 실행할 수 있게 되었습니다. 무엇보다도 이러한 개선에 힘입어 Cloud Run을 사용하는 조직에서 개발자 인건비를 40%나 절감한 것으로 조사되었습니다.

Cloud Run은 개발자에게 탄소 발자국을 최적화할 수 있는 옵션을 제공하는 최초의 플랫폼이기도 합니다. 새로운 셀프서비스 방식의 리전 선택 도구를 사용하면 Cloud Run 워크로드 실행 시 총 탄소 비용이 가장 낮은 데이터 센터 리전을 선택할 수 있습니다. 게다가 Google Cloud 탄소 발자국을 사용하면 단 한 번의 클릭으로 에너지 관련 배출 데이터에 액세스하여 외부 탄소 공개 정보를 확인할 수 있습니다.

"Cloud Run을 사용하면서 전과 비교해 절반 수준의 인력만으로 시스템을 관리할 수 있게 되었습니다."Cosmetics의 Google Cloud Platform 아키텍트설계자

"Cloud Run은 Google Cloud Platform에서 배포할 수 있는 가장 쉬운 서비스입니다. 놀랍도록 간단하죠." Healthcare SaaS의 CTO

Cloud Run과 관련 Cloud Functions를 사용해 보려면 2만 달러가 넘는 상금이 걸려 있는 Easy as Pie Serverless Hackathon을 확인해 보세요.

2022년에 다가올 새로운 변화

2021년은 간소화를 실현하고 개발자 생산성에 대한 관심을 높인 한 해였습니다. 중요한 것은 개발자가 인프라, 보안, 규정 준수, 통합에 대해 걱정할 필요 없이 더 높은 수준의 스택에서 계속 작업을 수행하는 것입니다. 이것이 2022년의 목표입니다. 2022년에는 Google Cloud의 ISV 파트너, 개발자, SecOps팀과 함께 혁신을 일구어 개발자를 위해 만들어진 클라우드에서 10배 더 빠르게 혁신을 이루세요.

Google App Engine 앱의 보안을 강화하는 새로운 기능

Mon, 24 Jan 2022 00:00:00 +0000

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

서버리스 VPC 액세스의 이그레스 제어
사용자 관리 서비스 계정

이그레스 제어

사용자 관리 서비스 계정

code_block: <ListValue: [StructValue([('code', 'Services to deploy:\r\ndescriptor: [/helloworld_default/app.yaml]\r\nsource: [/helloworld_default]\r\ntarget project: [PROJECT_ID]\r\ntarget service: [default]\r\ntarget version: [VERSION_NAME]\r\ntarget url: [https://PROJECT_ID.uc.r.appspot.com]\r\ntarget service account: [version-service-account@PROJECT_ID.iam.gserviceaccount.com]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205bf54490>)])]>

다음 단계

차세대 서버리스: 기업에 도움을 주는 3가지 방법

Tue, 24 Aug 2021 00:00:00 +0000

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

지난해만큼 '삶에서 유일하게 변하지 않는 것은 변화이다'라는 헤라클레이토스의 명언이 와닿은 적은 없었습니다. 팬데믹으로 인해 기업들은 때로는 불과 몇 주 만에 운영 방식을 전환하고 새로운 제품을 출시하고 극단적인 수요 패턴에 적응해야만 했습니다.

고객 니즈에 보다 빠르고 효율적으로 대응하기 위해 많은 기업이 서버리스 기술로 전환하여 실시간 신호와 인텔리전스가 기본 제공되는 애플리케이션을 설계했습니다. 진료 예약 및 백신 접종, 공공 부문 실업 급여, 접촉자 추적, 소매업 물류, 매장 밖 수령 및 배달, 호텔 및 여행 예약 등 많은 앱과 사이트가 서버리스 방식으로 구축되었습니다.

서버리스의 재정의

세상이 바뀌고 시장이 변했으며 우리의 삶이 달라졌습니다. 그에 발맞춰 Google Cloud도 변화하여 고객 니즈를 충족시키고 고객과 함께 성장하기 위한 새로운 제품을 도입했습니다.

특히 서버리스 기술이 처음 도입된 이후 대대적인 변화를 겪었습니다. Google은 2008년에 처음으로 서버리스 컴퓨팅 제품인 App Engine을 출시하여 고객이 애플리케이션을 보다 빠르고 원활하게 확장할 수 있도록 지원했습니다. 이후 Cloud Functions에서 서비스로서의 기능을 실행할 수 있는 기능을 추가하여 고객에게 통합 원격 분석과 관측 가능성 기능을 갖춘 간편한 개발자 환경을 제공했습니다. 이와 동시에 Google Cloud는 Kubernetes로 컨테이너 시장에 혁신을 가져왔습니다. 그러자 얼마 지나지 않아 고객들이 서버리스의 자동 확장 및 개발자 경험이라는 특성과 컨테이너의 유연성을 결합할 수 있는지 문의하기 시작했습니다.

이에 부응하여 차세대 서버리스 제품인 Cloud Run을 출시했습니다. 이제 서버리스는 더 이상 이벤트 기반 프로그래밍이나 마이크로서비스에 국한되지 않습니다. 서버리스는 복잡한 워크로드를 규모에 맞게 실행하는 한편 만족도 높은 개발자 환경을 그대로 유지하는 데에도 유용합니다. 실제로 Cloud Run의 서버리스는 언어, 라이브러리, 바이너리에 상관없이 실행할 수 있는 유연성을 갖춘 진정한 개발자 플랫폼을 의미합니다.

Cloud Run을 다른 '서버리스' 제품과 차별화된 차세대 서버리스 제품으로 만들어 주는 3가지 기능을 소개합니다.

우수한 개발자 중심 환경
다기능성: 컨테이너화된 광범위한 앱 집합으로 확장
DevOps 및 보안 기본 제공

각 특성을 자세히 살펴보겠습니다.

우수한 개발자 환경

개발자가 중심이 되기 위해서는 완전 관리형 자체 운영 인프라와 우수한 개발자 환경이 마련되어야 합니다. Google Cloud는 모두가 스마트한 애플리케이션을 개발할 수 있기를 바라기에 손쉽게 사용할 수 있도록 만들었습니다. 또한 기술 인재가 비즈니스 가치가 창출되는 영역에 더 집중할 수 있도록 지원하고자 합니다.

지난해에는 사용 편의성을 높이기 위해 소스 코드에서 바로 컨테이너 이미지를 만들 수 있는 Buildpack을 도입했습니다. Docker나 컨테이너를 학습할 필요가 없습니다. 컨테이너를 기반으로 하지만 개발자에게 투명하게 노출됩니다.

더욱 간단하게 사용할 수 있도록 코드를 빌드하여 Cloud Run에 배포하는 단일 'gcloud run deploy' 명령어도 도입했습니다. 이러한 기능들 덕분에 Cloud Run 사용자의 98%가 애플리케이션 배포를 처음 시도할 때 5분 내에 성공합니다.

실제로 지난해에만 25개가 넘는 새 기능과 서비스를 서버리스 스택에 추가하여 복잡한 앱 개발을 더욱 쉽게 만들었습니다. 출시된 주요 제품 중에는 Cloud Run을 원하는 Google Cloud 제품 또는 HTTP 기반 API 서비스와 결합할 수 있는 Workflows도 있습니다. 이 제품은 개발자가 복잡한 프로세스를 자동화하거나 다양한 시스템에 GCP 분석 서비스를 통합할 때 매우 유용합니다.

User Research International의 최근 보고서에 따르면 이러한 모든 새로운 기능 덕분에 Cloud Run 개발자 환경은 경쟁업체 제품보다 사용이 훨씬 쉽습니다.

다기능성

차세대 서버리스라면 다기능성도 갖추어야 합니다. Google Cloud 서버리스는 다양한 애플리케이션을 지원하고 기업 요구사항을 충족합니다. 함수와 웹 앱은 물론 고강도 애플리케이션, 시의적절성, 브라운필드, 컨테이너화된 타사 앱까지도 지원됩니다. 이 같은 다기능성은 언어, 런타임, 하드웨어의 제약을 없애주는 컨테이너가 기반이 되기에 가능한 것입니다.

서버리스 스택에서 다양한 애플리케이션을 실행할 수 있다는 사실은 예측 가능한 사용량에 맞춰 최적화할 수 있음을 의미합니다. 오늘 Google Cloud는 새로운 지출 기반의 Cloud Run 약정 사용 할인을 발표했습니다. 사용량이 안정적이고 꾸준하며 예측 가능한 기업은 이제 결제 UI에서 직접 약정 사용 계약을 구매할 수 있습니다. 선불 결제가 없기 때문에 할인으로 지출을 최대 17% 절감할 수 있습니다.

다기능성을 제공하는 또 다른 방법은 Cloud Run의 WebSocket 및 gRPC 지원입니다. 새롭게 추가된 지원을 통해 서버리스 인프라를 활용하여 반응성이 향상된 고성능 애플리케이션을 빌드할 수 있습니다. Cloud Run에 최소 인스턴스 수 사용도 추가했습니다. 이 기능으로 Cloud Run에서 콜드 스타트 시간을 단축하고 지연 시간에 민감한 애플리케이션을 실행할 수 있습니다. 또한 브라운필드 자바 애플리케이션 등을 실행하는 경우에 사용 가능한 컴퓨팅 용량을 0으로 축소하거나 최소한으로 유지할 수 있습니다.

DevOps 기본 제공

서버리스에서는 개발자가 앱을 보다 빠르게 설정할 수 있음은 물론 애플리케이션을 준비하여 실행한 후에는 운영팀의 과도한 관리 부담을 덜어줄 수도 있습니다. 특히 서버리스 시스템에서 애플리케이션의 '확장' 또는 '축소'를 관리합니다. 즉, 애플리케이션에서 트래픽 처리량이 급증하기 시작하면 서버리스 플랫폼이 부하를 처리하기 위해 자동으로 더 많은 리소스를 가동합니다. 덕분에 과도한 시간 초과, 지연, 로딩 또는 운영팀 업무가 발생하지 않습니다. 마찬가지로 수요가 감소하는 즉시 플랫폼에서 리소스를 해제, 즉 축소하여 더 이상 필요 없는 리소스에 대한 요금이 청구되지 않습니다. 운영팀 및 좌초 비용 없이 짧은 지연 시간으로 전 세계에서 서비스를 실행하고 싶으신가요? Cloud Run이 모든 Google Cloud 리전에서 글로벌 부하 분산과 0까지 축소되는 자동 확장을 처리해 드립니다.

또한 점진적 출시 및 롤백 지원 등의 기능으로 Cloud Run에서 개발자가 아이디어를 빠르게 실험하고 테스트할 수 있을 뿐만 아니라 정교한 트래픽 관리도 가능합니다. Cloud Run에서는 설정 또는 구성 없이도 분산 추적을 이용할 수 있어 개발자가 프로덕션의 성능 병목 현상을 발견할 수 있습니다.

다음 단계: 서버리스 보안

DevOps 권장사항의 일부로 배포 시간, 런타임, 네트워킹 등 모든 레이어에 서버리스 애플리케이션 보안을 구축했습니다. 예를 들어 기본 제공되는 취약점 스캔을 사용하면 신뢰하는 아티팩트만 배포할 수 있습니다.

오늘 Google Cloud는 쉽게 저장 데이터를 보호하고 민감한 정보를 저장할 수 있도록 지원하는 Google Secret Manager 및 고객 관리 암호화 키(CMEK)를 선보입니다. 또한 Cloud Run과 Binary Authorization을 통합하여 사용자가 특정한 정책을 시행할 수 있게 되면서 확인된 이미지만 프로덕션에 적용할 수 있습니다. 마지막으로, 새로운 IAP(Identity-Aware Proxy) 통합, VPC-SC 지원, 보안 경계를 적용하는 데 사용할 수 있는 이그레스 제어, 서비스가 프로덕션에서 실행될 때 특정 서비스에 액세스할 수 있는 사용자와 액세스할 수 있는 리소스를 제한할 수 있는 기능도 추가했습니다. 향상된 보안 기능에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

요약하면, 차세대 서버리스는 최고의 서버리스와 컨테이너를 결합하여 언어, 네트워킹 또는 리전별 제한사항에 구애받지 않고 광범위한 앱에서 실행됩니다. 차세대 서버리스는 개발자가 미래형 최신 애플리케이션을 빌드할 수 있도록 도와줍니다. 변화에 맞춰 쉽게 조정되고, 필요에 따라 확장되며, 고객 요구에 보다 빠르고 효율적으로 반응하는 애플리케이션을 빌드하면서도 최고의 개발자 환경을 누릴 수 있습니다. 자세한 내용은 서버리스의 강점에 참여하여 알아 보세요. 2시간 동안 진행되는 이 가상 이벤트에서는 서버리스 컴퓨팅에 대한 Google Cloud의 비전을 제시하고 서버리스 분야 전문가들이 서버리스 개발을 주제로 심도 있는 발표를 진행합니다. 이벤트에서 뵙겠습니다.

서버리스 및 클라우드 기반 애플리케이션 개발에 대한 자세한 내용이 궁금하신가요? 예정된 최신 앱 개발 및 배포 워크숍과 전문가 문의 라운드테이블을 확인하세요.

Workflows로 빌드할 수 있는 3가지 범용 서버리스 패턴

Tue, 06 Apr 2021 00:00:00 +0000

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

2021년 1월부터 Google Cloud의 Workflows 조정 및 자동화 서비스가 정식 버전으로 제공되고 있습니다. 또한 다른 Google Cloud 제품과의 원활한 통합 기능을 제공하는 Connectors의 프리뷰 버전을 사용할 수 있도록 Workflows를 업데이트했습니다. Workflows와 Connectors를 함께 사용하면 고급 서버리스 애플리케이션을 빌드하는 데 도움이 되는 범용 아키텍처 패턴을 효과적으로 설계할 수 있습니다.

Workflows는 모든 Google Cloud API와 인터넷에서 사용할 수 있는 HTTP 기반 API에서 작업을 조정할 수 있도록 설계된 서버리스 제품입니다. 인프라 관리가 필요하지 않으며 워크플로가 작업 완료를 기다리는 시간에 대해서는 비용이 발생하지 않습니다. Workflows의 핵심 기능을 자세히 알아보려면 Google Cloud의 이전 블로그 게시물을 참고하세요.

예약 워크플로

다음 워크플로를 살펴보세요.

Workflows에 기본 제공되는 스위치 단계는 커스텀 수식을 결합해 현재 카운터 값이 워크플로의 이전 실행에 저장된 상태와 다른 상태에 해당하는지를 판단하는 데 사용됩니다. 상태가 달라진 경우 Firestore 데이터베이스에 새로운 상태가 저장되고 Pub/Sub Connector가 지원팀에 푸시 메시지를 전송해 상태 변화를 알려줍니다. 워크플로는 현재 카운터 값뿐 아니라 마지막으로 저장된 상태도 확인하기 때문에 상태가 변경된 경우에만 알림이 전송됩니다.

Cloud Scheduler를 사용해 위 예시와 같이 워크플로 실행을 예약하는 방법을 알아보려면 이 가이드를 참고하세요.

API 폴링이 포함된 워크플로

데이터베이스 레코드 배열을 통한 반복

이번 예시는 애플리케이션이 고객 레코드를 매일 한 번씩 확인하고 기한이 지난 인보이스에 대한 이메일 리마인더를 고객에게 전송해야 하는 경우입니다.

아래 워크플로는 Firestore Connector를 사용해 연체 대금이 있는 모든 고객의 항목을 가져오는 쿼리를 수행합니다. 워크플로는 이 세트를 반복하면서 SendGrid와 같은 외부 Email API를 사용해 각 고객에게 연체 대금에 대한 이메일 리마인더를 전송합니다.

이전 예시와 유사하게 이 워크플로는 이메일 서비스에 대한 액세스 키를 가져오기 위해 Secret Manager에 대한 커넥터 호출로 확장해야 할 수 있습니다.

Workflow 준비하기

실제 상황에서 비즈니스 계열 애플리케이션은 여러 아키텍처 패턴을 조합하여 사용해야 하는 경우가 많습니다. 고객의 실제 사용 사례는 위 예시와 다를 수 있지만 주기적 예약, 폴링, 배열 반복은 범용적으로 사용되며 수많은 구현을 구성하는 요소입니다. 서버리스 및 API 기반 아키텍처에 대한 Workflows의 지원 덕분에 지속적인 운영 오버헤드를 최소화하면서도 비즈니스 로직을 완전히 제어할 수 있습니다. 또한 Connectors를 통해 Pub/Sub, Firestore, Compute Engine, Secret Manager, Cloud Tasks 등 Google Cloud 제품을 사용 환경에 간편하게 통합할 수 있습니다.

이제 Workflows가 정식 버전으로 제공되므로 비즈니스 계열 애플리케이션 제작을 위해 Workflows를 안심하고 사용할 수 있으며 기본 제공되는 API 호출 오류 처리 기능을 통해 애플리케이션의 안정성을 더욱 향상할 수 있습니다. 자세히 알아보려면 지금 Workflows 페이지로 이동하거나 바로 Cloud Console로 이동해 사용해 보세요.

Cloud Run에 이벤트를 라우팅하는 Eventarc 정식 버전 출시

Mon, 01 Mar 2021 00:00:00 +0000

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

지난 10월, Google Cloud는 개발자가 Cloud Run 서비스로 이벤트를 라우팅할 수 있도록 새로운 이벤트 기능을 탑재한 Eventarc를 발표했습니다. 이전 게시물에는 통합적인 Google Cloud 이벤트 환경, 중앙 집중식 이벤트 라우팅, 일관된 이벤트 형식과 라이브러리, 야심찬 장기 비전 등 Eventarc의 주된 장점이 간략하게 소개되어 있습니다.

오늘은 Eventarc 정식 버전이 출시되었다는 반가운 소식을 전해드립니다. Eventarc는 이벤트 수집, 전송, 보안, 관측 가능성, 오류 처리와 같은 세부사항을 도맡아 처리하므로 개발자는 이벤트 처리를 위한 코드 작성에 보다 집중할 수 있습니다.

Eventarc의 기능을 간추려 정리하면 다음과 같습니다.

Cloud 감사 로그를 통해 60개가 넘는 Google Cloud 소스에서 이벤트를 수신할 수 있습니다.
Pub/Sub 게시를 통해 커스텀 소스에서 이벤트를 수신할 수 있습니다.
소스에 상관없이 모든 이벤트에 대해 CloudEvents 표준을 준수하여 일관된 개발자 환경을 보장할 수 있습니다.
요청 시 확장이 가능하며 최소 수수료가 없습니다.

이 게시물에서는 공개 미리보기 버전에 비하여 Eventarc 일반 안정화 버전에서 무엇이 개선되었는지 살펴보겠습니다.

gcloud 업데이트

Eventarc 정식 버전은 gcloud 명령어가 일부 업데이트되었습니다.

첫째, 더 이상 Eventarc 명령어에서 beta를 지정할 필요가 없습니다. gcloud beta eventarc 대신 gcloud eventarc를 사용하면 됩니다.

둘째, 공개 미리보기 버전에서 --matching-criteria였던 플래그가 정식 버전에서는 --event-filters로 변경되었습니다.

셋째, 이제 리전 트리거를 생성할 때 --destination-run-region을 선택할 수 있습니다. 사용자가 지정하지 않을 경우 트리거 위치와 함께 자동으로 생성됩니다(--location 플래그 또는 eventarc/location 속성에서 지정).

예를 들어 동일한 리전 내에서 Pub/Sub 주제가 전송한 메시지를 리슨하는 트리거를 생성하는 방법은 다음과 같습니다.

code_block: <ListValue: [StructValue([('code', 'gcloud eventarc triggers create trigger-pubsub \\\r\n --destination-run-service=${SERVICE_NAME} \\\r\n --event-filters="type=google.cloud.pubsub.topic.v1.messagePublished"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f2060e0a9d0>)])]>

이 트리거에서 Pub/Sub 주제를 비공개로 생성합니다.

이제 Eventarc에서 --transport-topic gcloud 플래그 옵션을 허용하므로, 원한다면 기존 Pub/Sub 주제를 사용할 수도 있습니다. 또한 트리거에 사용 가능한 리전을 나열할 수 있는 명령어도 새로 추가되었습니다. 이에 관한 자세한 내용은 아래에서 확인하세요.

자체 Pub/Sub 주제 사용

퍼블릭 프리뷰 버전에서는 Pub/Sub 트리거를 생성하면 Eventarc에서 Pub/Sub 주제를 비공개로 생성해 애플리케이션 및 Cloud Run 서비스 간 전송 주제로 사용할 수 있었습니다. 이 방식은 Pub/Sub 지원 트리거를 쉽고 빠르게 생성해야 하는 경우에는 유용하지만, 기존 Pub/Sub 주제에서 트리거를 생성하거나 단일 Pub/Sub 주제에서 확장할 방법이 없다는 한계가 있었습니다.

이번에 출시된 Eventarc 정식 버전에서는 --transport-topic gcloud 플래그를 사용하면 동일한 프로젝트 내에서 기존 Pub/Sub 주제를 지정할 수 있습니다. 방법은 다음과 같습니다.

code_block: <ListValue: [StructValue([('code', 'gcloud eventarc triggers create trigger-pubsub \\\r\n --destination-run-service=${SERVICE_NAME} \\\r\n --event-filters="type=google.cloud.pubsub.topic.v1.messagePublished"\r\n --transport-topic=projects/${PROJECT_ID}/topics/${TOPIC_NAME}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f2060e0a8b0>)])]>

리전 확장

Eventarc 정식 버전은 공개 미리보기 버전에서 지원하던 리전(asia-east1, europe-west1, us-central1, us-east1, global)과 더불어 Google Cloud 리전 4개(asia-southeast1, europe-north1, europe-west4, us-west1)를 추가로 지원합니다. 즉 8개 리전에서 리전 트리거를 생성하거나, 글로벌 트리거를 생성하여 8개 리전에서 이벤트를 수신할 수 있습니다.

새로 추가된 다음 명령어를 사용하면 사용 가능한 트리거 위치가 나열됩니다.

code_block: <ListValue: [StructValue([('code', 'gcloud eventarc locations list'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f2060e0ab50>)])]>

트리거 위치를 지정하려면 각 명령어에 --location 플래그를 추가합니다.

code_block: <ListValue: [StructValue([('code', 'gcloud eventarc triggers create trigger-pubsub \\\r\n --destination-run-service=${SERVICE_NAME} \\\r\n --event-filters="type=google.cloud.pubsub.topic.v1.messagePublished"\r\n --location=europe-west1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f2060e0a730>)])]>

또는 eventarc/location 구성을 사용하여 모든 명령어에 전역으로 설정할 수도 있습니다.

code_block: <ListValue: [StructValue([('code', 'gcloud config set eventarc/location europe-west1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f2060e0a370>)])]>

다음 단계

Google Cloud에서는 Eventarc 정식 버전을 출시하게 된 것을 기쁘게 생각합니다. 별도의 준비 없이도 빠른 트리거 설정으로 다양한 Google Cloud 소스에서 이벤트를 수집하고 Cloud Run 서비스로 라우팅할 수 있으므로 어느 때보다도 Eventarc를 간편하게 시작할 수 있습니다. Google Cloud의 문서를 참조하여 빠른 시작을 해보거나 Codelab을 이용해 보세요.

Cloud Run용 WebSocket, HTTP/2, gRPC 양방향 스트림 소개

Mon, 22 Feb 2021 00:00:00 +0000

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

Cloud Run을 위한 다양하고 새로운 트래픽 전달 기능인 엔드 투 엔드 HTTP/2 연결, WebSocket 지원, gRPC 양방향 스트리밍을 출시한다는 소식을 전해드립니다. 이로써 gRPC에서 제공하는 RPC 유형이 완성되었습니다. 이러한 기능을 사용하면 서버리스 인프라의 장점을 활용하면서 기존에 지원되지 않았던 새로운 종류의 애플리케이션을 Cloud Run에 배포할 수 있습니다. 이 기능은 현재 모든 Cloud Run 위치에서 퍼블릭 프리뷰로 제공됩니다.

스트리밍 지원은 반응성과 성능이 우수한 애플리케이션을 빌드하는 데 있어 중요한 부분입니다. 초기에 출시된 Cloud Run에서는 클라이언트의 요청과 서비스의 응답 모두가 버퍼링을 야기했기 때문에 스트리밍을 지원하지 않았습니다. 지난 10월 Google Cloud에서는 서버리스 컨테이너에서 클라이언트로 데이터를 스트리밍할 수 있는 서버 측 스트리밍 지원을 발표했으며 이로써 이전의 응답 한도인 32MB가 상향되고 gRPC를 위한 서버 측 스트리밍을 지원할 수 있게 되었습니다. 하지만 여전히 클라이언트 스트리밍과 양방향 스트리밍에서 WebSocket과 gRPC를 실행하는 것이 허용되지 않았습니다.

WebSocket 및 gRPC 양방향 스트리밍

이제 Cloud Run에는 새로운 양방향 스트리밍 기능이 지원되어 WebSocket(예: 소셜 피드, 공동작업 편집, 멀티플레이 게임)은 물론 모든 범위의 gRPC 양방향 스트리밍 API를 사용하는 애플리케이션을 실행할 수 있습니다. 이러한 양방향 스트리밍 기능을 사용하면 같은 요청에 대해 서버와 클라이언트 양쪽에서 데이터를 지속적으로 교환할 수 있습니다. WebSocket과 양방향 RPC를 사용하면 반응성이 우수한 애플리케이션과 API를 빌드할 수 있습니다. 즉 WebSocket과 같은 프로토콜을 사용해 Cloud Run 기반의 채팅 앱을 빌드하거나 gRPC를 사용해 스트리밍 API를 설계할 수 있습니다.

아래 예시에서는 Cloud Run에서 컨테이너로 실행되는 공동작업 실시간 '화이트보드' 애플리케이션을 보여 줍니다. 두 WebSocket 세션이 각각 서로 다른 브라우저 창에서 제공되며 두 창에서 캔버스가 실시간으로 업데이트되는 것을 확인할 수 있습니다.

Cloud Run에서 WebSocket을 사용하면 별도의 구성이 필요 없으며 즉시 사용할 수 있습니다. gRPC로 클라이언트 측 스트리밍이나 양방향 스트리밍을 사용하려면 HTTP/2 지원이 필요한데 이 내용에 대해서는 다음 섹션에서 살펴보겠습니다.

Cloud Run에서 WebSocket 샘플 애플리케이션을 사용해 보려면 이 링크를 클릭하여 Socket.io에서 화이트보드 예시를 배포하세요.

WebSocket 스트림에는 아직 Cloud Run 서비스에서 구성한 요청 제한 시간이 적용된다는 점을 유의하세요. 따라서 WebSocket을 사용하려는 경우 그에 맞게 요청 제한 시간을 설정해야 합니다.

엔드 투 엔드 HTTP/2 지원

다른 많은 앱과 달리 Cloud Run은 첫 번째 출시부터 gRPC용 엔드 투 엔드 HTTP/2를 포함한 HTTP/2를 지원했습니다. 클라이언트가 프로토콜을 사용하도록 자동으로 업그레이드하는 방법으로 지원이 가능했으며 그 덕분에 서비스의 속도와 효율성을 향상할 수 있었습니다. 하지만 지금까지는 HTTP/2 요청이 컨테이너로 전송되면 HTTP/1로 다운그레이드되는 문제가 있었습니다.

이제부터는 Cloud Run에서 엔드 투 엔드 HTTP/2 전송 기능을 사용할 수 있습니다. 이 기능은 기존에 HTTP/2를 지원하는 애플리케이션에 특히 유용하며 HTTP/2를 지원하지 않는 앱의 경우 HTTP/2 트래픽이 컨테이너에 도착할 때까지 Cloud Run에서 트래픽을 처리합니다.

서비스에서 엔드 투 엔드 HTTP/2를 사용해 트래픽을 전달하도록 하려면 애플리케이션에서 HTTP/2 일반 텍스트('h2c'라고도 함) 형식으로 요청을 처리할 수 있어야 합니다. Google Cloud에서는 개발자가 'h2c' 프로토콜을 사용해 볼 수 있는 샘플 h2c 서버 애플리케이션(Go로 작성)을 개발했습니다. 링크된 저장소를 클론하여 실행하면 이 앱을 빌드하고 Cloud Run에 배포할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'git clone https://github.com/GoogleCloudPlatform/golang-samples.git\r\ncd ./run/h2c\r\ngcloud beta run deploy http2-test --use-http2 --source=.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f20625a7490>)])]>

위 예시 명령어에서 '--use-http2' 옵션은 애플리케이션이 'h2c' 프로토콜을 지원하며 서비스가 HTTP/2 요청을 다운그레이드 없이 처리할 수 있음을 의미합니다.

서비스를 배포한 후에는 다음 명령어를 실행하여 요청이 HTTP/1로 다운그레이드되지 않고 HTTP/2를 사용하여 처리되었는지 확인합니다.

curl -v --http2-prior-knowledge https://<SERVICE_URL>

Google Cloud Console에서도 HTTP/2를 사용하도록 서비스를 구성할 수 있습니다.

시작하기

이제 이 새로운 네트워킹 기능을 사용하여 더욱 다양한 웹 서비스와 API를 Cloud Run에서 배포 및 실행할 수 있습니다. 새로운 기능과 현재 미리보기로 제공되는 기능에 대해 자세히 알아보려면 WebSockets 데모 앱 또는 샘플 h2c 서버 앱을 확인하세요.

문제가 발생하거나 제안사항이 있다면 알려주세요. Google에서 진행하는 연구에 참여하면 Cloud Run의 미래를 함께 만들 수 있습니다.

2020년 리뷰: 불확실성 속에서 고객의 성공을 돕는 서버리스 솔루션

Thu, 04 Feb 2021 00:00:00 +0000

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

다사다난한 해였습니다. 2020년은 적응력이 뛰어난 기업조차도 잘 수립된 계획을 전면 수정해야 했던 힘든 한 해였습니다. 하지만 수많은 Google Cloud 고객이 이러한 불확실성을 기회로 바꿨습니다. 고객은 Google Cloud의 서버리스 솔루션을 사용해 빠르게 혁신했으며, 대부분의 경우 새로운 제품을 출시하고 새로운 기능을 제공하여 시장 요구에 대응했습니다. Google Cloud 역시 이러한 고객들과 마찬가지로 그 어느 때보다도 빠르게 100개가 넘는 새로운 기능을 선보였습니다. 제공해 주신 고객의 아이디어와 서버리스 솔루션 및 클라우드 기반 애플리케이션 개발에 보여 주신 큰 관심에 감사드립니다.

불확실성 시대에 필요성이 입증된 Cloud Run

디지털 채택이 가속화되면서 개발자들은 코드를 프로덕션 단계로 안전하고 안정적으로 가져올 수 있는 가장 쉽고 빠른 방법인 Cloud Run을 선택했습니다. 서버리스 컨테이너를 포함한 Cloud Run은 웹 앱, 모바일 백엔드, 데이터 처리에 최적화되어 있을 뿐만 아니라 컨테이너에 포함할 수 있는 대부분의 애플리케이션 유형을 실행할 수 있습니다. 연구에 따르면 초보자가 Cloud Run에서 처음으로 앱을 빌드하고 배포하는 데 5분이 채 걸리지 않았습니다. 누구나 하루에도 여러 번 배포할 수 있을 정도로 매우 빠르고 간편합니다.

지난 한 해, Cloud Run은 엄청난 성과를 거두었습니다. 소스 및 IDE부터 배포에 이르는 엔드 투 엔드 개발자 환경을 추가했고 총 21개 리전으로 Cloud Run을 확장했으며 스트리밍, 보다 긴 제한 시간, 더 큰 인스턴스, 점진적 출시, 롤백 등에 대한 지원을 추가했습니다.

이번에 추가된 지원은 바로 고객들에게 그 유용성을 입증했습니다. 예를 들어 유럽의 대형 가전 소매업체인 MediaMarktSaturn은 Cloud Run을 선택하여 디지털 채널 전반에서 발생한 145%의 트래픽 증가량을 처리했습니다. 마찬가지로 Cloud Run과 기타 관리형 서비스를 사용한 IKEA는 솔루션을 가동하여 코로나19 대유행이 가져온 문제를 며칠 만에 해결하고 운영 비용을 10배나 절감했습니다. Google 내부에서도 개발자를 위한 최고의 서비스로 Cloud Run이 사용된 것은 당연한 결과였습니다. 개발자들은 Cloud Run으로 일 년 내내 다양한 새 프로젝트를 추진했습니다.

Google Cloud는 자체 관리형 인프라 및 우수한 개발자 환경을 단일 워크로드 유형으로 제한해서는 안 된다는 신념에 따라 Cloud Run에서 서버리스가 함수 이상의 의미를 갖도록 재정의하고 있습니다. 때로는 함수가 꼭 필요한 상황이 있는 만큼 올해에는 관리형 서비스로서의 기능 제품인 Cloud Functions에 새로운 기능을 추가하는 데 더욱 노력했습니다. 다음은 새롭게 추가된 기능입니다.

기능 및 리전 확장: Cloud Functions에 17가지의 새 기능을 추가했으며, 여러 곳의 새로운 리전으로 확대하여 총 19개의 리전을 지원합니다.
완전한 서버리스 솔루션: 또한 API 게이트웨이, Workflows, Eventarc을 도입했습니다. 이 제품군으로 개발자가 서버리스 워크로드의 API를 만들고 보호하며 모니터링할 수 있으며 Google Cloud 및 HTTP 기반 API 서비스를 조정 및 자동화하고 이벤트 기반 애플리케이션을 쉽게 빌드할 수 있습니다.
비공개 액세스: VPC 서비스 제어 및 Cloud Functions 통합으로 기업에서 서버리스 서비스를 보호하여 데이터 무단 반출을 포함한 위협을 완화할 수 있습니다. 또한 Cloud Functions용 VPC 커넥터를 활용하면 클라우드 리소스 및 온프레미스 하이브리드 배포 간 비공개 통신도 가능합니다.
엔터프라이즈 규모: 대규모 데이터 세트를 사용하는 기업은 이제 gRPC를 활용해 Cloud Run 서비스를 다른 서비스와 연결할 수 있습니다. 마지막으로 외부 HTTP(S) 부하 분산과 Cloud Run 및 Cloud Functions를 통합하여 기업이 외부 IP 주소 하나로 전 세계에서 서비스를 실행하고 확장할 수 있게 되었습니다.

Cloud Run 및 Cloud Functions 모두 2020년 많은 사용자의 선택을 받았지만 가장 오래된 서버리스 제품인 App Engine의 성장세가 여전하며 그 비결은 통합 개발자 환경 및 자동 확장이라는 이점 덕분입니다. 2020년에는 새로운 리전, 런타임, 부하 분산에 대한 지원을 App Engine에 추가하여 개발자 생산성과 확장성을 높였습니다.

확대하려면 클릭

기본으로 제공되는 보안 기능을 바탕으로 지속적 혁신

코로나19 대유행 기간 동안 기업들은 뉴노멀에 맞춰 비즈니스를 재구성하고 사고를 전환해야 했습니다. 서버리스 지속적 통합/지속적 배포(CI/CD) 플랫폼인 Cloud Build를 사용하면 빌드, 테스트, 출시 주기를 단축할 수 있어 도움이 됩니다. 개발자가 CI/CD 파이프라인 내에서 정밀 보안 스캔을 수행하고 신뢰할 수 있는 컨테이너 이미지만 프로덕션에 배포되도록 할 수 있습니다.

학생들의 수업이 가정 학습으로 전환됨에 따라 예상치 못한 수요에 부응하기 위해 노력한 Khan Academy의 사례를 살펴보겠습니다. Khan Academy는 Cloud Build를 사용해 맞춤 일정 등의 새로운 기능을 빠르게 실험하고 이와 동시에 App Engine에서 원활하게 확장할 수 있었습니다. 한편 뉴욕주에서는 대유행 기간 동안 실업 지원 시스템에 접수된 신규 실업 수당 신청이 1,600% 증가했습니다. 뉴욕주는 급증한 신청량을 처리하기 위해 Cloud Build, Pub/Sub, Datastore, Cloud Logging을 포함한 완전 관리형 서버리스 서비스 기반의 새 웹사이트를 출시했습니다.

2020년, Google Cloud는 고객의 성공을 돕기 위해 다음과 같은 영역에서 새로운 기능을 Cloud Build에 추가했습니다.

엔터프라이즈 레디 (Enterprise readiness): Artifact Registry로 세분화된 IAM, 리전 저장소, CMEK , VPC-SC에 대한 지원은 물론 Maven, npm 패키지, 컨테이너 관리 기능 등을 포함해 기업 고객들이 요청한 여러 기능을 한곳에 모았습니다.
사용 편의성: 클릭 몇 번이면 Cloud Run 및 GKE 권장사항이 즉시 구현되는 CI/CD 파이프라인을 만들 수 있습니다. 또한 Cloud Build에 Buildpack 지원을 추가하여 프로덕션에 바로 적용 가능한 안전한 컨테이너 이미지를 쉽게 만들고 Cloud Run 또는 GKE에 배포할 수 있도록 합니다.
정보에 입각한 결정: 새로운 Four Keys 프로젝트를 이용하면 주요 DevOps Research & Assessment(DORA) 측정항목을 캡처하여 소프트웨어 개발 및 제공 프로세스를 포괄적으로 파악할 수 있습니다. 또한 새로운 Cloud Build 대시보드에서 CI/CD 프로세스 최적화 방법에 대한 자세한 통계를 제공합니다.
CI/CD 공급업체 간 상호 운용성: 2018년 Google에서 개발하여 2019년 Continuous Delivery Foundation(CDF)에 기탁한 Tekton은 90여 기업의 참여에 힘입어 현재 공급업체, 언어, 배포 환경 관련 CI/CD의 사실상 표준으로 자리 잡았습니다. 2020년에는 트리거와 같은 새로운 기능 지원을 Tekton에 추가했습니다.
GitHub 통합: 매일 수백만 명의 사용자가 공동작업하는 GitHub에 고급 서버리스 CI/CD 기능을 도입했습니다. 새로운 Cloud Build GitHub 앱을 사용하면 특정 pull 요청, 분기, 태그 이벤트를 기반으로 빌드를 구성하고 트리거할 수 있습니다.

확대하려면 클릭

도구 모음에서 보안 기능을 기본적으로 제공한다면(즉, 프로세스에 보안 기능이 내장된 경우) 지속해서 혁신을 이룰 수 있습니다. 뉴욕주, Khan Academy와 같은 여러 조직에서 고객에게 소프트웨어를 안전하게 제공하려면 안전한 소프트웨어 공급망이 필수적입니다.

혁신적이고 강력한 동급 최고의 보안 제어 기능을 기본적으로 제공한 덕분에 Google Cloud가 최근의 2020년 4분기 Forrester Wave™ IaaS 플랫폼 기본 보안 보고서에서 선두 제품으로 선정되고 현재 제품 카테고리의 평가 대상 제공업체 중 최고 점수를 받았다고 생각합니다.

개발자의 원활한 클라우드 온보딩

무수히 많은 서비스와 문서, 계속되는 신기술 도입 등으로 인해 클라우드 개발은 결코 쉽지 않은 작업입니다. 따라서 Google Cloud는 개발자를 클라우드에 쉽게 온보딩하여 개발자의 생산성을 극대화하는 데 투자하고 있습니다.

컨텍스트 내 가이드가 지원되는 Cloud Shell 편집기: 개인적으로 마음에 들어 자주 사용하는 Google Cloud 학습 및 사용 도구가 바로 Cloud Shell 편집기입니다. ide.cloud.google.com을 통해 제공되는 Cloud Shell 편집기는 모든 기능을 갖춘 개발 도구로서 로컬 설정이 필요 없으며 브라우저에서 바로 사용할 수 있습니다. 최근에는 컨텍스트 내 가이드, 기본 제공되는 Google Cloud API 인증 지원, 광범위한 개발자 도구를 추가하여 Cloud Shell 편집기를 개선했으니 사용해 보세요. 이 편집기가 여러분에게도 유용한 도구가 되었으면 합니다.

Cloud Shell 편집기에서 제공되는 컨텍스트 내 가이드

클라우드 기반 개발 가속화: 서버리스 애플리케이션 빌드 프로세스를 개선하기 위해 Cloud Run과 Cloud Code를 통합했습니다. 그리고 Cloud Code를 통해 Kubernetes 개발 속도를 높이고자 Buildpack 지원을 추가했습니다. 개발자가 YAML을 쉽게 작성할 수 있도록 인라인 문서, 코드 완성, 스키마 검증 등의 새 기능과 함께 즉시 사용 가능한 400개의 인기 Kubernetes CRD에 대한 기본 지원도 추가했습니다.
Google Cloud의 장점 활용: Cloud Code를 사용하면 앱을 빌드할 때 AI/ML, 컴퓨팅, 데이터베이스, ID 및 액세스 관리를 포함한 여러 API를 쉽게 통합할 수 있습니다. 또한 새로운 Secret Manager 통합 덕분에 API 키, 비밀번호, 인증서와 같은 민감한 정보를 IDE에서 바로 관리할 수 있습니다.
기존 애플리케이션 현대화: Spring Cloud GCP를 통해 코드를 거의 변경하지 않고도 쉽게 기존 Java 애플리케이션을 현대화할 수 있도록 만들었습니다. 또한 Anthos Developer Sandbox 무료 이용 혜택을 발표하여 Google 계정 사용자는 누구나 Anthos에서 무료로 애플리케이션을 개발할 수 있습니다.

확대하려면 클릭

2021년을 맞이하며

한마디로 2020년은 정말 바쁜 해였습니다. 다들 그렇지만 Google Cloud도 올해 기업들이 앞당긴 디지털 혁신의 혜택을 2021년에는 모두가 누릴 수 있기를 바랍니다. Google Cloud는 2021년에도 기업이 시장 변화에 적응하고 고객 경험을 개선할 수 있는 애플리케이션을 빠르고 안전하게 빌드할 수 있도록 개발자를 지원하며 여러분과 여정을 함께하겠습니다. 안전하고 행복한 연말이 되시길 바라며 여러분과 함께 차세대 뛰어난 애플리케이션을 빌드할 수 있기를 기대합니다.

Cloud Run 최소 인스턴스: 서버리스 콜드 스타트 최소화

Thu, 28 Jan 2021 00:00:00 +0000

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

서버리스의 장점 중 하나는 사용한 만큼만 비용을 지불하는 운영 모델로, 서비스를 0으로 조정할 수 있다는 것입니다. 그러나 서버리스의 이러한 특징이 일부 애플리케이션에는 단점으로 작용합니다. 애플리케이션이 0으로 축소되었다가 절전 모드가 해제되어 첫 번째 요청을 처리할 때 지연 시간이 발생하기 때문입니다. 이른바 '스타트업 세금'이라고 불리는 이 현상은 서버리스에서만 발생합니다. 명칭에서 알 수 있듯 애플리케이션에 수신되는 트래픽이 없으면 서버가 실행되지 않기 때문입니다.

오늘 Google Cloud의 관리형 서버리스 컴퓨팅 플랫폼인 Cloud Run용 최소 인스턴스가 출시된다는 소식을 알려드리게 되어 기쁩니다. 새로 출시되는 이 중요한 기능은 애플리케이션의 성능을 비약적으로 향상시킬 수 있습니다. 그 결과 지연 시간에 민감한 애플리케이션을 Cloud Run에서 실행할 수 있으며 서버리스 컴퓨팅 플랫폼의 이점을 활용할 수 있습니다. 그럼 더 자세히 살펴보겠습니다.

콜드 스타트 단축

이 기능을 사용하면 대기 중이며 트래픽을 제공할 준비가 된 Cloud Run 최소 인스턴스 집합을 구성하여 서비스가 최소 콜드 스타트로 요청을 수행할 수 있습니다.

Cloud Run의 새로운 최소 인스턴스 기능을 사용하려면 간단한 gcloud 명령어 또는 UI로 Cloud Run 서비스에 사용할 최소 인스턴스 수를 구성하기만 하면 됩니다.

code_block: <ListValue: [StructValue([('code', '$ gcloud beta run deploy --image gcr.io/cloudrun/hello --min-instances=3 helloservice'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205bb75730>)])]>

구성이 완료되면 최소 인스턴스가 애플리케이션에 트래픽을 제공할 준비를 마치고 대기합니다. 따라서 애플리케이션의 콜드 스타트를 최소화하고 Cloud Run에서 지연 시간에 민감한 애플리케이션을 실행할 수 있게 됩니다.

부트스트랩 로직 재사용

Cloud Run 최소 인스턴스는 콜드 스타트를 최소화할 뿐만 아니라 데이터베이스 연결 생성, Cloud Storage에서 메모리로 파일 로드 등 주요 작업에 대한 부트스트랩 시간을 단축시켜 줍니다. 부트스트랩 시간을 단축함으로써 최소 인스턴스는 요청 지연 시간을 더욱 줄일 수 있습니다. 부트스트랩 로직을 한 번만 실행하면 되며 그 이후에는 구성한 수 만큼의 최소 인스턴스에 대한 여러 요청 전반에 걸쳐 로직을 활용할 수 있기 때문입니다.

다음 golang 서버리스 함수는 부트스트랩 로직을 한 번 실행한 다음 최소 인스턴스 전반에서 재사용하는 방법을 보여줍니다.

부트스트랩 로직을 한 번 실행한 다음 최소 인스턴스 전반에서 재사용하기

code_block: <ListValue: [StructValue([('code', 'package main\r\n \r\nimport (\r\n "fmt"\r\n "log"\r\n "net/http"\r\n)\r\n \r\nfunc init() {\r\n setupDBConnection(dbName)\r\n}\r\n \r\nfunc handler(w http.ResponseWriter, r *http.Request) {\r\n \r\n fmt.Fprintf(w, "Hi there, I love %s!", r.URL.Path[1:])\r\n}\r\n \r\nfunc main() {\r\n fmt.Println("Processing your serverless request")\r\n http.HandleFunc("/", handler)\r\n log.Fatal(http.ListenAndServe(":8080", nil))\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205bb75490>)])]>

저렴한 비용으로 서버리스 이점 누리기

Cloud Run 최소 인스턴스를 사용하면 최소 인스턴스 수를 설정할 수 있을 뿐만 아니라 제한된 CPU로 인스턴스를 구성하여 훨씬 저렴한 비용으로 이 기능을 활용할 수 있습니다. 따라서 지연 시간에 민감한 워크로드를 서버리스로 이전하는 동시에 서버리스의 효율성과 비용 측면의 이점을 누리는 일석이조의 효과를 볼 수 있습니다.

Cloud Run 최소 인스턴스의 실제 작동 방식

지금까지 Cloud Run 최소 인스턴스의 이점과 기능 활용법에 대해 살펴봤습니다. 그런데 Cloud Run 최소 인스턴스는 실제로 어떻게 작동하며, 사용하는 것이 좋은 이유는 무엇일까요?

기존 서버리스 플랫폼은 Scale-to-zero를 활용할 수 있는 애플리케이션에 적합했지만 부트스트랩 기간 중의 콜드 스타트 지연 시간으로 인해 초기 응답 시간이 늦어진다는 단점이 있었습니다. 이러한 단점은 처음부터 빌드하고 소스 및 런타임 중 작동 방식을 완전하게 제어할 수 있는 애플리케이션에서는 문제가 되지 않습니다. 하지만 상용 애플리케이션 중에 기존 서버리스 접근법이 적합하지 않은 종류가 있습니다. 측정항목을 수집하는 Prometheus와 정책 결정을 내리는 개방형 정책 에이전트(OPA) 같은 커스텀 제어 영역을 생각해 보세요. 이러한 제어 영역에는 일반적으로 최초 시작 시에 고급 구성과 약간의 부트스트랩이 필요하며 추가적인 지연 시간이 허용되지 않습니다.

예를 들어 OPA를 시작하면 일반적으로 원격 소스에서 정책을 가져오고 향후 정책 결정 속도를 높이기 위해 정책을 캐싱합니다. 일반적인 서버리스 환경에서 OPA 같은 제어 영역은 0으로 축소된 상태에서 정책 요청을 처리하기 위해 원래 상태로 돌아오면 성능이 저하됩니다. 중요 사용자 트랜잭션을 위해 요청 경로 내에 위치하기 때문입니다.

Cloud Run 최소 인스턴스를 사용하면 이 문제를 해결할 수 있습니다. 각 요청 간에 0으로 축소되었다가 정책 엔진을 부트스트래핑하는 대신 OPA의 '자주 사용하는' 인스턴스에서 각 요청을 처리해 주기 때문입니다.

실제 작동 과정을 살펴보겠습니다. 다음 섹션에서는 OPA를 배포해 중앙 제어 영역으로 실행하고 최소 인스턴스가 성능 요구사항을 충족시키도록 만듭니다.

OPA 서버를 구성하여 런타임에 Cloud Storage 버킷에서 정책 번들을 가져오면 쿼리할 때 '/health' HTTP 경로에 대한 http GET 요청을 허용합니다. OPA 정책은 다음과 같습니다.

code_block: <ListValue: [StructValue([('code', 'package http.example.authz\r\n \r\ndefault allow = false\r\n \r\nallow {\r\n input.method == "GET"\r\n input.path == "/health"\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205bb75a00>)])]>

정책은 정책 번들에 패키징되고 Cloud Storage 버킷에 업로드됩니다. 하지만 먼저 일부 종속 항목을 부트스트랩해야 합니다. 자세한 내용은 부트스트랩 프로세스 가이드를 참조하세요. 과정을 단순화하기 위해 도우미 스크립트를 활용하겠습니다.

code_block: <ListValue: [StructValue([('code', '$ git clone https://github.com/kelseyhightower/min-instances-tutorial.git'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205bb757f0>)])]>

min-instances-tutorial 디렉터리로 변경합니다.

code_block: <ListValue: [StructValue([('code', '$ cd min-instances-tutorial'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205bb75970>)])]>

OPA Cloud Run 인스턴스를 배포하기 전에 다음 작업을 수행해야 합니다.

OPA 서비스 계정 생성
OPA 정책 번들을 보관할 Cloud Storage 버킷 생성
Cloud Storage에 OPA 정책 번들(bundle.tar.gz) 업로드
OPA 서비스 계정에 OPA 번들 액세스 권한 부여

code_block: <ListValue: [StructValue([('code', '$ ./bin/bootstrap \r\n \r\nCreating the open-policy-agent service account ...\r\nCreating the GCS bucket to hold the OPA policy bundle...\r\nCreating gs://opa-policies-hightowerlabs/...\r\nCreated GCS bucket opa-policies-hightowerlabs\r\nCopying the OPA policy bundle (bundle.tar.gz) to gs://opa-policies-hightowerlabs...\r\nCopying file://bundle.tar.gz [Content-Type=application/x-tar]...\r\n/ [1 files][ 280.0 B/ 280.0 B] \r\nOperation completed over 1 objects/280.0 B. \r\nGranting read permission on to the open-policy-agent service account\r\nTutorial bootstrapping complete.\r\nService account email and bucket name written to .env\r\nService Account: open-policy-agent@hightowerlabs.iam.gserviceaccount.com\r\nBucket Name: opa-policies-hightowerlabs'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205bb750a0>)])]>

이제 OPA를 호스팅할 모든 종속 항목이 전부 갖춰졌습니다. ‘gcloud’ 명령어를 사용해 OPA를 배포할 준비가 되었습니다. 버킷 이름과 서비스 계정 이메일 주소는 이전 단계에서 실행한 부트스트랩 스크립트에서 생성된 '.env' 파일에 저장되어 있습니다.

$ source .env

code_block: <ListValue: [StructValue([('code', '$ source .env'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205bb75eb0>)])]>

open-policy-agent Cloud Run 인스턴스 생성:

code_block: <ListValue: [StructValue([('code', '$ gcloud beta run deploy open-policy-agent \\\r\n --concurrency 80 \\\r\n --cpu 2 \\\r\n --image gcr.io/hightowerlabs/opa:0.24.0-min-instances \\\r\n --memory \'2G\' \\\r\n --min-instances 1 \\\r\n --no-allow-unauthenticated \\\r\n --platform managed \\\r\n --port 8181 \\\r\n --region us-west1 \\\r\n --service-account ${SERVICE_ACCOUNT} \\\r\n --set-env-vars="BUCKET_NAME=${BUCKET_NAME}" \\\r\n --timeout 300'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205bb75af0>)])]>

명령어의 출력이 다음과 같이 나타나며 환경 부트스트래핑을 성공적으로 완료했음을 의미합니다.

code_block: <ListValue: [StructValue([('code', 'Deploying container to Cloud Run service [open-policy-agent] in project [hightowerlabs] region [us-west1]\r\n✓ Deploying... Done. \r\n ✓ Creating Revision... \r\n ✓ Routing traffic... \r\n ✓ Setting IAM Policy... \r\nDone. \r\nService [open-policy-agent] revision [open-policy-agent-00018-bim] has been deployed and is serving 100 percent of traffic.\r\nService URL: https://open-policy-agent-6bn2iswfgq-uw.a.run.app'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205bb755e0>)])]>

OPA 서버가 최초로 시작되면 Cloud Storage에서 정책 번들을 다운로드하고 캐싱합니다. 단, 최소 인스턴스를 사용하므로 이 작업을 한 번만 수행합니다.

이제 정책 결정 내리기를 테스트할 준비가 되었습니다. curl로 테스트할 수 있습니다. open-policy-agent Cloud Run URL을 가져옵니다.

code_block: <ListValue: [StructValue([('code', "$ OPA_URL=$(gcloud run services describe open-policy-agent \\\r\n --platform managed \\\r\n --region us-west1 \\\r\n --format json | \\\r\n jq -r '.status.url')"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205bb75ee0>)])]>

입력 집합을 제공하여 OPA 서버를 쿼리하고 Cloud Storage에 저장된 정책 번들에 기반한 정책 결정을 검색합니다.

code_block: <ListValue: [StructValue([('code', '$ curl -i "${OPA_URL}/v1/data/http/example/authz" \\\r\n -H "Authorization: Bearer $(gcloud auth print-identity-token)" \\\r\n -d \'{"input": {"path": "/health","method": "GET"}}\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205bb75340>)])]>

응답은 다음과 같습니다.

code_block: <ListValue: [StructValue([('code', 'HTTP/2 200 \r\ncontent-type: application/json\r\ndate: Thu, 29 Oct 2020 15:20:06 GMT\r\ncontent-length: 25\r\nserver: Google Frontend\r\n \r\n{"result":{"allow":true}}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205bb75b80>)])]>

몇 분 기다려보면 OPA가 0으로 축소되지 않으며 프로세스가 백그라운드에 정지되어 있음을 확인할 수 있습니다. 다음 요청이 인스턴스에 도달해야 프로세스 정지 상태가 풀립니다. 가격에 어떤 영향을 미치는지 자세히 알아보려면 가격 책정 페이지를 확인하세요.

최대 애플리케이션을 위한 최소 인스턴스

언뜻 보기에는 Cloud Run 최소 인스턴스가 사소하게 느껴질 수 있지만 이 기능을 통해 더 많은 상용 애플리케이션을 서버리스 모델에서 비용 효율적인 방식으로 실행하고 서버리스 컴퓨팅에 내재된 단점을 제어할 수 있게 될 것입니다. Cloud Run을 시작하려면 빠른 시작을 참조하세요.

Cloud Run 1주년: 돌아보기

Tue, 19 Jan 2021 09:00:00 +0000

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

Cloud Run은 컨테이너의 유연성에 서버리스의 단순성, 확장성, 생산성을 결합한다는 간단한 전제를 바탕으로 빌드되었습니다. Cloud Run을 사용하면 클릭 몇 번만으로 Git 저장소를 완전 관리형 환경에 지속적으로 배포하여 컨테이너를 안전한 HTTPS 엔드포인트로 자동 확장할 수 있습니다. Cloud Run은 인프라 관리가 필요 없는 완전 관리형이기 때문에 개발자는 애플리케이션을 신속하게 제공하는 데 집중할 수 있습니다.

Cloud Run이 정식 출시된 지 이제 1년이 되었습니다! 1년 동안 Cloud Run이 어떻게 발전해 왔는지 여기에서 간략히 살펴보겠습니다.

엔터프라이즈 지원

Google은 Cloud Run을 21개 리전으로 확대하고자 노력해왔으며 2020년 연말까지 나머지 모든 Google Cloud 리전에서도 사용할 수 있도록 하기 위해 작업 중입니다.

이제 Cloud Run 서비스에 비공개 IP를 사용하는 리소스를 연결할 수 있으며 공유 VPC를 지원하는 서버리스 VPC 커넥터를 사용하여 Cloud Memorystore Redis와 Memcached를 사용할 수도 있으므로 온프레미스나 서로 다른 프로젝트에 있는 리소스를 연결할 수 있습니다. VPC를 통해 모든 이그레스를 라우팅하면 Cloud Run에서 출발한 트래픽에 대해 고정 아웃바운드 IP 주소를 활용하여 특정 IP 범위만 허용하는 외부 서비스를 호출할 때 유용할 수 있습니다.

또한 Cloud Load Balancing의 기능을 Cloud Run과 함께 활용할 수도 있습니다. 자체 TLS 인증서를 준비하거나, 허용할 SSL 버전을 지정하거나, 부하 분산기에 커스텀 URL 기반 라우팅을 구성하여 여러 백엔드의 콘텐츠를 제공할 수 있습니다.

또한 글로벌 부하 분산을 통해 여러 리전에서 들어오는 트래픽을 전달하여 전 세계에 분산된 애플리케이션을 실행하거나, Cloud CDN을 통해 에지에 캐시된 정적 콘텐츠를 제공하거나, Cloud Armor 웹 애플리케이션 방화벽으로 엔드포인트를 보호할 수 있습니다.

API 게이트웨이 지원을 통해 호스팅 API에 대한 기타 일반적인 문제를 걱정하거나 인증을 구현할 필요 없이 고객을 위한 API를 빌드하여 Cloud Run에서 실행할 수 있습니다.

이제 점진적 출시와 롤백을 통해 각 버전으로 전송된 트래픽의 비율을 관리하고 전용 URL로 특정 버전을 테스트하여 Cloud Run 서비스의 새로운 버전을 안전하게 출시할 수 있습니다.

개발자 친화적

개발자의 입장에서, 개발자 커뮤니티에서 활발하게 사용되는 제품을 개발한다는 것은 아주 뿌듯한 일입니다.

제품을 처음 사용하는 초보자도 5분 안에 앱을 빌드하고 배포할 수 있습니다. 누구나 하루에도 여러 번 배포할 수 있을 정도로 빠르고 간편합니다. Cloud Run으로 생산성이 향상되어 더 빠르게 코드를 제공할 수 있다는 개발자의 스토리를 들으면 큰 보람을 느낍니다.

빌드 기록과 Git 저장소 링크가 표시된 Cloud Run 사용자 인터페이스

지난 1년 동안 개발자의 생산성을 높일 수 있는 여러 가지 기능을 추가했습니다.

간편한 사용자 인터페이스를 추가하여 Git 저장소에서 지속적 배포를 설정할 수 있도록 했습니다. 특정 분기에 대한 커밋을 푸시하거나 새 버전에 태그를 지정할 때마다 Cloud Build를 통해 Cloud Run에 자동으로 빌드되고 배포됩니다.

애플리케이션 개발도 한층 더 간편해졌습니다. 이제 Cloud Code를 사용하여 로컬에서 Cloud Run 애플리케이션을 배포하고 실행할 수 있습니다. 처음 시작하는 사용자라면 Cloud Code에서 새 애플리케이션 템플릿이 생성되며 에뮬레이터를 통해 로컬에서 코드를 실행하거나 디버깅할 수 있습니다.

Dockerfile 작성이 번거로우신가요? Google Cloud Buildpacks를 사용하면 애플리케이션 코드를 지원되는 언어의 컨테이너 이미지로 바로 전환할 수 있습니다. 이 기능은 기존 애플리케이션을 Cloud Run으로 가져오는 경우 특히 유용합니다. 또한 Buildpacks에서는 함수 프레임워크를 지원하므로 Cloud Functions도 컨테이너 이미지로 변환할 수 있습니다.

이뿐만 아니라 이제 Cloud Run 서비스로 전송된 요청이 Cloud Trace에서 즉시 캡처되어 서비스의 성능을 모니터링하고 지연 시간 문제를 손쉽게 파악할 수 있습니다. 여러 서비스 간 분산 추적을 수행하려는 경우 수신한 trace 헤더를 발신 요청에 전달하기만 하면 trace 스팬이 자동으로 연결됩니다.

요청에 응답하고 Pub/Sub에서 푸시한 메시지를 비공개로 안전하게 처리할 수 있는 Cloud Run에 60개 이상의 Google Cloud 소스에서 Cloud Run 서비스를 트리거할 수 있는 기능을 추가했습니다. 더 효과적인 조정이 필요할 경우에는 Workflows를 활용해 Cloud Run을 사용하는 프로세스를 자동화하고 조정할 수 있습니다.

유연성

Google에서는 완전 관리형 환경에서 더 많은 워크로드를 실행할 수 있도록 계속해서 Cloud Run의 한계에 도전하고 있습니다. 이제 컨테이너에 최대 4GB의 메모리와 CPU 4개를 할당할 수 있습니다.

특히 0에서부터 확장할 때 '콜드 스타트'를 최소화하고 싶다는 의견도 있었습니다. 이에 도움이 될 수 있도록 웜 컨테이너 인스턴스의 최소 개수를 유지하는 기능을 추가하여 콜드 스타트를 피해 요청을 처리할 수 있도록 했습니다. 이러한 유휴 인스턴스는 요청을 처리하고 있지 않은 경우 활성 인스턴스보다 비용이 저렴합니다. 콜드 스타트가 거슬린다면 이 기능을 이용해 보세요.

gRPC및 서버 측 스트리밍을 사용하면 부분 응답을 계산하는 동시에 전송하고 서버 측으로부터 데이터를 스트리밍하는 애플리케이션을 작성할 수 있으므로 서비스에서 첫 번째 바이트까지 소요되는 시간을 줄일 수 있습니다. 이 기능을 활용하면 응답이 더 이상 32MB로 제한되지 않으며 서버 전송 이벤트(SSE)를 구현할 수 있습니다.

1시간 요청 제한 시간을 사용하여 하나의 요청을 최대 1시간까지 실행할 수 있습니다. 서버 측 스트리밍과 함께 이제 Cloud Run에서 대규모 응답(예: 문서 또는 동영상)을 스트리밍하거나 장기 실행 작업을 처리할 수 있습니다.

마지막으로, 단계적 인스턴스 종료를 통해 Cloud Run이 컨테이너 인스턴스를 축소하기 전에 프로세스에 종료 신호(SIGTERM)를 보냅니다. 그러면 로컬에 저장된 원격 분석 데이터를 삭제하고, 열려 있는 연결을 정리하고, 잠금을 해제하는 등의 작업을 수행할 수 있습니다.

Cloud Run의 다음 단계

지난 한 해 동안 Cloud Run은 멋진 성과를 거두었지만 이는 단지 시작일 뿐입니다. Google에서는 더욱 다양한 워크로드에 Cloud Run을 사용할 수 있도록 개선에 힘쓰고 있습니다. 이와 동시에, 훌륭한 개발자 환경을 제공하고 주요 기업 요구사항을 해결하는 데 여전히 집중하고 있습니다. 앞으로도 Cloud Secret Manager에서 보안 비밀 마운팅, IAP(Identity-Aware Proxy) 통합, 양방향 스트리밍, WebSocket 등 새롭고 흥미로운 출시 소식을 기다려 주시기 바랍니다.

Cloud Run 기능의 과거와 미래에 대해 알아보려면 출시 노트를 참조하세요. 이러한 새로운 기능에 대해 자세히 알아보려면 이 동영상을 확인하시기 바랍니다. Google에서 진행하는 연구에 참여하여 Cloud Run의 미래를 함께 만들어 주세요.

Google Cloud의 서버리스 조정 엔진, Workflows 알아보기

Thu, 07 Jan 2021 09:00:00 +0000

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

기업에서 전자상거래 처리, 제품 생산, IT 서비스 제공 등 어떤 작업을 수행하든 다양한 시스템에 걸쳐 업무 흐름을 관리해야 합니다. 워크플로를 직접 관리하거나 범용 도구로 관리할 수도 있지만 전용 제품을 사용하면 훨씬 쉽게 관리할 수 있습니다.

Google Cloud 포트폴리오에는 Cloud Composer와 새로 도입된 Workflows라는 두 가지 워크플로 도구가 있습니다. 8월에 도입된 Workflows는 Google Cloud의 일부로 실행되는 완전 관리형 워크플로 조정 제품입니다. 완전한 서버리스 제품이므로 인프라 관리가 필요 없습니다.

이 도움말에서는 Workflows가 지원하는 사용 사례, 기능, 효과적으로 사용하기 위한 팁을 다룹니다.

샘플 워크플로

먼저, 인보이스를 생성하는 다음과 같은 워크플로가 있다고 가정하겠습니다.

이 단계를 조정하는 일반적인 방법은 Cloud Functions, Cloud Run 또는 PDF 파일이 첨부된 이메일을 전송하는 공개 SaaS API(예: SendGrid)를 기준으로 API 서비스를 호출하는 것입니다. 하지만 일반적으로 실제 상황은 위에서 든 예시보다 훨씬 더 복잡하며 모든 워크플로 실행, 오류 처리, 결정 지점, 조건부 건너뛰기를 추적하고 항목 배열, 데이터 변환, 기타 고급 기능을 반복하는 작업을 계속해야 합니다.

즉, 기술적으로는 범용 도구를 사용해 이 프로세스를 관리하는 것이 가능하지만 이상적인 선택은 아닙니다. 예를 들어 Cloud Functions와 같은 이벤트 기반 컴퓨팅 플랫폼으로 이 흐름을 처리할 경우 발생하는 몇 가지 문제를 알아보겠습니다. 우선, Cloud 함수의 최대 실행 기간은 9분이지만 워크플로는 특히 인적 상호작용이 포함된 경우 수일간 실행될 수 있습니다. 워크플로를 완료하는 데 시간이 더 필요하거나 응답 상태를 폴링할 때 단계 사이에 일시중지해야 할 수도 있습니다. 예를 들어 여러 Cloud Functions를 서로 연결하려는 경우 Pub/Sub를 사용할 수도 있지만 이러한 워크플로를 간단하게 개발하거나 운영할 방법은 없습니다. 우선, 이 모델에서는 단계 실패를 워크플로 실행과 연결하기가 까다롭기 때문에 문제 해결이 매우 어렵습니다. 또한 모든 워크플로 실행 상태를 파악하려면 커스텀 설계된 추적 모델이 필요하므로 아키텍처의 복잡성이 증가합니다.

이와 달리 워크플로 제품은 예외 처리를 지원하며 성공 및 실패를 포함한 개별 단계의 실행 및 상태에 대한 가시성을 제공합니다. 각 단계의 상태가 개별적으로 관리되기 때문에 워크플로 엔진이 오류에서 원활하게 복구할 수 있어 이 워크플로를 사용하는 애플리케이션의 안정성이 크게 개선됩니다. 마지막으로 워크플로 제품에는 인기 API 및 클라우드 제품의 기본 제공 커넥터가 포함된 경우가 많아 시간을 절약하고 기존 API 인터페이스를 활용할 수 있습니다.

Google Cloud의 Workflow 제품

Google Cloud 최초의 범용 워크플로 조정 도구는 Cloud Composer입니다.

Apache Airflow를 기반으로 한 Cloud Composer는 ETL 조정, 빅데이터 처리 또는 머신러닝 워크플로 등의 데이터 엔지니어링 파이프라인에 적합하며 BigQuery 또는 Dataflow 와 같은 데이터 제품과 원활하게 통합됩니다. 예를 들어 데이터 웨어하우스 또는 빅데이터 클러스터에서 일련의 작업을 실행하고 결과를 스토리지 버킷에 저장해야 하는 워크플로라면 Cloud Composer를 선택하는 것이 당연합니다.

하지만 서버리스 방식으로 이벤트를 처리하거나 API를 연결하려는 경우 또는 워크로드가 급격하게 증가하거나 지연 시간에 민감한 경우에는 Workflows를 권장합니다.

Workflows는 사용하지 않을 때는 0으로 조정되어 유휴 상태에서 비용이 발생하지 않습니다. 워크플로의 단계 수를 기준으로 가격이 책정되므로 워크플로를 실행하는 경우에만 비용을 지불하면 됩니다. 또한 Workflows에서는 실행 시간을 기준으로 요금을 청구하지 않으므로 태스크 사이에 워크플로를 몇 시간 일시중지할 때도 요금이 부과되지 않습니다.

Workflows는 자동으로 수직 확장되어 시작 시간이 매우 짧으며 '콜드 스타트'의 영향이 없습니다. 아울러 단계 간 전환이 빨라 지연 시간에 민감한 애플리케이션을 지원합니다.

Workflows 사용 사례

Workflows가 조정할 수 있는 프로세스와 흐름의 수에는 제한이 없습니다. 보다 인기 있는 사용 사례를 살펴보겠습니다.

고객 트랜잭션 처리

고객 주문을 처리해야 하는 경우를 가정해보면 한 상품의 재고가 없는 경우 외부 공급업체의 인벤토리 보충을 트리거해야 합니다. 또한 주문을 처리하는 중에 대량 고객 주문이 들어오면 영업 담당자에게 알리는 것이 좋습니다. 영업 담당자가 Slack을 사용해 이러한 알림을 받으면 빠르게 대처할 가능성이 높아집니다.

다음은 예시의 워크플로 다이어그램입니다.

위의 워크플로는 Slack, SendGrid 또는 인벤토리 공급업체의 커스텀 API를 포함한 외부 API는 물론 Google Cloud Firestore에 대한 호출을 조정합니다. 단계 간에 데이터를 전달하고 다른 API 출력에 따라 조건부로 단계를 실행하는 결정 지점을 구현합니다.

한 번에 하나의 트랜잭션을 처리하는 각 워크플로 실행이 로깅되어 필요한 경우 역추적하거나 문제를 해결할 수 있습니다. 워크플로는 필요한 재시도 또는 API에서 발생한 예외를 처리하여 전체 애플리케이션의 안정성을 개선합니다.

업로드된 파일 처리

고려할 만한 또 다른 사례로는 사용자가 업로드한 파일에 파일 콘텐츠에 따라 태그를 지정하는 워크플로가 있습니다. 사용자가 텍스트 파일, 이미지 또는 동영상을 업로드할 수 있기 때문에 워크플로에서는 파일의 콘텐츠를 분석하기 위해 다양한 API를 사용해야 합니다.

이 시나리오에서는 Cloud Storage 트리거에 의해 Cloud 함수가 트리거됩니다. 그러면 함수가 Workflows 클라이언트 라이브러리를 사용해 워크플로를 시작하고 워크플로에 파일 경로를 인수로 전달합니다.

이 예시에서 워크플로는 파일 확장자에 따라 사용할 API를 결정하고 해당하는 태그를 Firestore 데이터베이스에 저장합니다.

Workflows 심층 탐구

이 모든 사용 사례를 Workflows에서 즉시 구현할 수 있습니다. Workflows에서 확인할 수 있는 주요 기능을 자세히 살펴보겠습니다.

단계

Workflows는 ‘단계’로 전달되는 활동의 시퀀싱을 처리합니다. 필요한 경우 단계 사이에 시간 관련 요금이 발생하지 않고 일시중지되도록 워크플로를 구성할 수도 있습니다.

특히 네트워크 연결이 가능하며 워크플로 단계로 HTTP를 따르는 거의 모든 API를 조정할 수 있습니다. Cloud Functions 또는 Cloud Run에서 호출을 래핑하지 않고도 SaaS API 또는 비공개 엔드포인트를 포함한 모든 인터넷 기반 API에 대한 호출을 실행할 수 있습니다.

인증

Cloud 함수를 호출하거나 Firestore에서 데이터를 읽는 등 Google Cloud API에 대한 호출을 실행할 때 Workflows는 기본 제공 IAM 인증을 사용합니다. 워크플로에 특정 Google Cloud API를 사용할 수 있는 IAM 권한이 부여되어 있는 한 인증 프로토콜에 대해 걱정할 필요가 없습니다.

워크플로 단계 간 통신

대부분의 실제 워크플로에서는 단계 간 상호 통신이 필요합니다. Workflows는 단계에서 작업 결과를 후속 단계에 전달할 때 사용할 수 있는 기본 제공 변수를 지원합니다.

자동 JSON 변환

JSON이 API 통합에서 매우 일반적으로 사용되면서 Workflows가 API JSON 응답을 사전으로 자동 변환하여 이후 단계에서 이 정보에 손쉽게 액세스할 수 있습니다.

다양한 표현식 언어

또한 Workflows에는 산술 및 논리 연산자, 배열, 사전 및 기타 여러 기능을 지원하는 다양한 표현식 언어가 포함되어 있습니다. 워크플로에서 기본적인 데이터 조작을 직접 수행할 수 있어 API 통합이 더욱 간소화됩니다. Workflows는 런타임 인수를 허용하기 때문에 단일 워크플로를 사용해 다양한 이벤트 또는 입력 데이터에 대응할 수 있습니다.

결정 지점

변수와 표현식으로 대다수 워크플로의 중요한 또 다른 구성요소인 결정 지점을 구현할 수 있습니다. Workflows에서는 커스텀 표현식을 사용해 워크플로의 다른 부분으로 건너뛸지 아니면 단계를 조건부로 실행할지를 결정합니다.

조건부 단계 실행

로직에서 자주 사용되는 부분을 하위 워크플로로 코딩한 후 일반 단계로 호출하면 여러 프로그래밍 언어의 루틴과 비슷하게 작동합니다.

네트워크 문제나 특정 API의 작동 중지 등으로 인해 워크플로의 단계가 실패하는 경우가 있습니다. 그러나 이로 인해 전체 워크플로 실행이 즉시 실패하지는 않습니다.

Workflows는 워크플로가 API 호출에서 반환된 오류에 적절하게 대응하도록 해주는 구성 가능한 재시도 및 예외 처리의 조합으로 이 문제를 방지합니다.

위의 모든 기능을 Workflows 소스 코드의 일부로 구성할 수 있습니다. 구성의 실제 예시는 여기에서 확인할 수 있습니다.

지금 Workflows 시작하기

Workflows는 Google Cloud의 애플리케이션 개발 및 관리 도구 집합에 새로 추가된 강력한 도구이며 모든 프로젝트에 즉시 사용해 볼 수 있습니다.

Workflows 사이트를 살펴보거나 Cloud Console로 바로 이동하여 첫 워크플로를 빌드해 보세요. Workflows에는 무료로 사용해 볼 수 있는 무료 등급이 포함되어 있습니다. 앞으로 발표될 Workflows 관련 공지도 기대해 주세요.

Workflows가 조정에 도움이 되기를 바랍니다.

Google Cloud Functions에 .NET 도입

Tue, 05 Jan 2021 09:00:00 +0000

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

Cloud Functions는 사용자가 서버 또는 런타임 환경을 관리할 필요 없이 이벤트에 응답하는 것을 유일한 목적으로 하는 독립 실행형 함수를 만들 수 있는 Google Cloud의 서비스로서의 기능 플랫폼입니다. Cloud Functions는 서버리스 애플리케이션, 모바일 또는 IoT 백엔드, 실시간 데이터 처리 시스템, 동영상/이미지/감정 분석뿐만 아니라 챗봇 또는 가상 어시스턴트 등에도 적합합니다.

이제 Windows, Mac, Linux용 오픈소스 플랫폼이자 무료로 사용할 수 있는 교차 플랫폼인 .NET Core 3.1이 Cloud Functions에 도입됩니다. 이번 통합으로 .NET용 함수 프레임워크에서 자주 이용하는 .NET Core 3.1 런타임을 사용해 클라우드 함수를 작성할 수 있는 관용적인 개발자 환경이 구축됩니다.

현재 미리보기로 제공되는 .NET용 Cloud Functions에서는 .NET Core 3.1을 사용해 비즈니스에 중요한 애플리케이션과 통합 레이어를 빌드하고 비공개 VPC 네트워크의 리소스에 액세스 가능한 완전 관리형 환경에 함수를 배포할 수 있습니다. .NET 함수는 부하에 따라 자동으로 확장됩니다. HTTP 이벤트에 응답하는 HTTP 함수는 물론 다양한 클라우드와 Pub/Sub, Cloud Storage, Firestore 등의 Google Cloud 서비스에서 발생하는 이벤트를 처리하는 CloudEvent 함수를 작성할 수 있습니다.

포팅 가능한 .NET 함수를 작성할 수 있는 서비스로서의 기능 오픈소스 프레임워크인 .NET용 함수 프레임워크를 사용해 함수를 개발할 수 있습니다. 함수 프레임워크를 사용해 함수를 개발하여 로컬에서 실행한 후 Cloud Functions 또는 다른 .NET 환경에 배포하세요.

.NET용 함수 프레임워크는 HTTP 함수와 CloudEvent 함수를 지원합니다. HTTP Cloud 함수는 작성하기가 매우 쉽습니다. 아래에서 웹훅/HTTP 사용 사례의 간단한 HTTP 함수를 확인할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'using Google.Cloud.Functions.Framework;\r\nusing Microsoft.AspNetCore.Http;\r\nusing System.Threading.Tasks;\r\n \r\nnamespace HelloWorld\r\n{\r\n public class Function : IHttpFunction\r\n {\r\n public async Task HandleAsync(HttpContext context)\r\n {\r\n await context.Response.WriteAsync("Hello World!");\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205b9c69a0>)])]>

.NET 런타임의 CloudEvent 함수는 업계 표준 CNCF CloudEvents에 응답합니다. 이 이벤트는 Pub/Sub, Cloud Storage, Firestore 등의 여러 Google Cloud 서비스에서 발생할 수 있습니다.

다음은 Pub/Sub에서 작동하는 간단한 CloudEvent 함수입니다.

code_block: <ListValue: [StructValue([('code', 'using CloudNative.CloudEvents;\r\nusing Google.Cloud.Functions.Framework;\r\nusing Google.Events.Protobuf.Cloud.PubSub.V1;\r\nusing Microsoft.Extensions.Logging;\r\nusing System.Threading;\r\nusing System.Threading.Tasks;\r\n \r\nnamespace HelloPubSub\r\n{\r\n public class Function : ICloudEventFunction<MessagePublishedData>\r\n {\r\n private readonly ILogger _logger;\r\n \r\n public Function(ILogger<Function> logger) =>\r\n _logger = logger;\r\n \r\n public Task HandleAsync(CloudEvent cloudEvent, MessagePublishedData data, CancellationToken cancellationToken)\r\n {\r\n string nameFromMessage = data.Message?.TextData;\r\n string name = string.IsNullOrEmpty(nameFromMessage) ? "world" : nameFromMessage;\r\n _logger.LogInformation("Hello {name}", name);\r\n return Task.CompletedTask;\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f205b9c63a0>)])]>

VB 및 F# 지원

Cloud Functions .NET 런타임은 VB 및 F#도 지원합니다. 프로그래밍 모델이 완전히 동일하며 GitHub 저장소에서 예시를 확인할 수 있습니다. .NET 함수 프레임워크에는 명령줄 또는 Visual Studio에서 사용할 수 있는 템플릿 패키지가 포함되어 있습니다. 이 템플릿 역시 VB 및 F#를 지원합니다.

.NET용 Cloud Functions 사용해 보기

.NET용 Cloud Functions를 바로 사용해 볼 수 있습니다. 빠른 시작 가이드에서 첫 번째 함수를 작성하는 방법에 대해 알아보고 Google Cloud Platform 무료 체험판에서 사용해 보세요. 기술적 측면을 자세히 알아보려면 .NET 함수 프레임워크 둘러보기에 대해 다룬 존 스키트의 블로그도 참조하세요. .NET용 오픈소스 함수 프레임워크에 관심이 있다면 프로젝트를 살펴보고 참여해 보세요. 또한 런타임에 익숙해질 수 있도록 실습 가능한 Codelab도 준비되어 있습니다. 사용자 여러분이 작성할 .NET 함수를 기대하고 있겠습니다.