DevOps 및 SRE

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 0x7f3c4e2b9be0>)])]>

이 작업은 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 0x7f3c4e2b9ee0>)])]>

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 0x7f3c4e2b9460>)])]>

애플리케이션을 위한 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 보안 권고 사항을를 참조해 주십시오.

퍼블릭 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 0x7f3c4c771c40>)])]>

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

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

Personalized Service Health 소개: 이슈 대응 커뮤니케이션 향상

Fri, 25 Aug 2023 07:00:00 +0000

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

사용 중인 클라우드 서비스가 이슈로 인해 중단되는 경우 효과적인 대응은 중단의 원인을 파악하고 영향의 범위를 평가하는 것에서 시작됩니다. 이 단계는 이해관계자와의 커뮤니케이션이나 재해 복구 절차의 진행과 같은 조치를 취하는 데 있어 매우 중요합니다. 그러나 클라우드 서비스 제공업체를 사용하는 경우 효과적인 이슈 대응 역량은 제공되는 이슈 커뮤니케이션의 투명성, 시의성, 실행 가능성에 따라 달라집니다.

오늘, Google Cloud 서비스 중단에 대한 빠르고 투명하고 관련성 있고 실행 가능한 커뮤니케이션을 제공하는 Personalized Service Health를 소개하게 된 것을 기쁘게 생각합니다. 현재 미리보기 버전으로 제공되는 Personalized Service Health를 사용하면 이슈 대응의 한 지점, 또는 이슈 대응이나 모니터링 도구와 통합하여 Google Cloud 서비스 중단에 대한 상세 알림을 받을 수 있습니다.

Personalized Service Health를 사용해야 하는 이유

현재 Google은 사용자에게 영향을 미칠 가능성이 있는 이슈가 감지되면 Google Cloud Service Health를 통해 공개적으로 해당 정보를 게시합니다. 높은 신뢰도를 갖추고 있는 이 공개 대시보드는 널리 알려야 하는 활성 이슈(일반적으로 규모가 크거나 심각도가 높음)에 대한 정보를 전달합니다. Google Cloud 제품 및 해당 제품이 운영되는 리전별로 구성되는 Google Cloud Service Health는 Google Cloud 제품에 영향을 미치는 이슈에 대한 실시간 정보를 표시하며 서비스 중단 내역을 다운로드할 수 있는 메커니즘을 제공합니다.

Personalized Service Health는 이러한 장점을 한 단계 더 발전시킨 서비스로, 많은 고객에게 이슈 대응 여정을 나서기에 이상적인 목적지 역할을 합니다. Personalized Service Health는 다음과 같은 기능을 제공합니다.

고객과 관련된 서비스 중단을 결정하는 제어 기능: Google Cloud Service Health는 광범위한 고객에 영향을 미치는 이슈를 게시하며, 전체 이슈 목록을 제공하는 것은 아닙니다. 더 많은 이슈에 대해 조기에 또는 더 빈번하게(규모가 작은 이슈 포함) 알림을 받고자 하는 경우 Personalized Service Health를 사용하여 이슈 발생 시 알림을 받는 방법과 시기를 설정하면 됩니다.
기존 이슈 관리 워크플로와 통합하는 기능: Personalized Service Health는 고객이 선호하는 이슈 관리 도구 및 워크플로와의 다양한 통합 옵션을 제공합니다. 예를 들어 알림을 PagerDuty와 통합하여 서비스 중단이 시작될 때 적절한 이슈 대응 전문가에게 알릴 수 있습니다.
사전 예방적 이슈 발견 가능성: Personalized Service Health는 로그를 내보내며 맞춤설정 가능한 알림을 푸시하여 워크플로에서 이슈의 발견 가능성을 높일 수 있습니다.

이러한 이점에 대해 자세히 살펴보겠습니다.

이벤트를 발견하는 방식을 선택하는 알림 구성

Personalized Service Health는 Google Cloud 서비스 중단이 게시 또는 업데이트될 때 광범위한 대상에 알림을 전송할 수 있습니다. 이때 알림을 받을 대상과 위치를 선택하고 영향을 받는 Google 서비스 및 위치, 현재 프로젝트와의 관련성, 관찰 가능한 증상, 알려진 완화 방법을 포함하여 이슈에 대한 중요 정보를 포함하도록 알림 내용을 맞춤설정할 수 있습니다.

알림은 Personalized Service Health에서 직접 구성하거나, Cloud Monitoring에서, 또는 Terraform을 통해 구성할 수 있습니다. 각 알림은 이메일, SMS, Pub/Sub, 웹훅 또는PagerDuty를 포함한 하나 이상의 대상으로 전송 가능합니다. 또한 보다 상세한 알림을 받을 수 있도록 하나의 프로젝트에 대해 여러 개의 알림을 생성할 수 있습니다.

Personalized Service Health는 고객의 프로젝트에 영향을 미칠 수 있는 서비스 중단 관련 정보를 다양한 관련성 수준에 따라 게시하도록 설계되었습니다. 이 접근 방식은 고객이 반드시 필요하다고 생각하는 것 이상의 정보를 제공할 수 있습니다. 균형을 맞추려면 다양한 통합 지점에 걸쳐 관련성이 있다고 판단되는 이슈만 확인하도록 이슈를 필터링할 수 있습니다.

대시보드: 표시되는 필드와 이슈의 최신성을 기준으로 이슈 테이블을 필터링합니다.
알림: Google Cloud 제품, 위치 또는 프로젝트와의 관련성을 포함한 모든 이슈 필드를 사용하여 조건부 알림 정책을 만들 수 있습니다.
API: API 요청에 요청 필터를 사용하여 애플리케이션에서 프로그래매틱 방식으로 이벤트를 추가 필터링할 수 있습니다.
로그: Cloud Logging은 로그가 로그 싱크를 통해 다른 대상으로 라우팅될 때 로그를 필터링하는 강력한 쿼리 언어를 지원합니다.

기존 이슈 관리 워크플로와 통합

이슈 대응에는 조직의 여러 구성원, 팀, 도구가 관여할 수 있습니다. Personalized Service Health는 프로그래매틱 액세스, 사전 예방적 또는 사후 대응적 상호작용, 기존 도구에 대한 설정에 따라 다양한 통합 옵션을 제공함으로써 기존 이슈 대응 프로세스에 맞추는 것을 목표로 합니다.

Personalized Service Health를 Google Cloud 콘솔에서 직접 대시보드로 사용하거나, 원하는 워크플로의 기존 이슈 대응 또는 모니터링 도구에 맞춰 조정할 수 있습니다. Service Health 대시보드는 프로젝트와 관련된 활성 이슈 목록을 제공하며, 각 이슈에 대해 해당 이슈의 세부적인 영향을 보거나 Google Cloud 지원팀의 업데이트를 추적할 수 있습니다. 빠르게 설정하고 간편하게 유지관리할 수 있습니다.

Personalized Service Health를 외부 알림, 모니터링 또는 이슈 대응 도구와 통합하는 경우 Service Health API는 특정 프로젝트와 관련된 모든 이슈 또는 조직의 모든 프로젝트에 대한 프로그래매틱 액세스를 제공합니다. API는 관련성 있는 모든 이슈, Google Cloud의 업데이트, 영향 설명의 전체 목록에 대한 프로그래매틱 액세스를 제공합니다.

내역과 보고서 만들기 및 과거 중단에서 배우기

서비스 중단이 시작되면 Cloud Logging은 이벤트에 대한 모든 업데이트의 Personalized Service Health 로그를 수집합니다. 이벤트의 내역 기록을 작성하기 위해 스토리지 버킷에 로그를 보존할 수 있습니다. 또한 로그 애널리틱스와 BigQuery를 함께 사용하여 과거 서비스 중단을 분석할 수 있습니다.

통합하여 시간이 갈수록 더욱 커지는 이점 누리기

오늘부터 Personalized Service Health가 Compute Engine, Cloud Storage, 모든 Cloud Networking 제품, BigQuery, Google Kubernetes Engine 등 50여 개의 Google Cloud 제품 및 서비스와 통합됩니다. 통합된 Google Cloud 제품에서 고객에게 영향을 미칠 수 있는 서비스 중단이 감지되면 Personalized Service Health가 영향 평가를 제공하고 증상, 알려진 해결 방법 또는 해결 ETA를 포함한 업데이트를 공유합니다.

일부 제품은 Personalized Service Health를 통해 더 빠른 초기 게시와 결정적인 영향 신호를 포함한 고급 기능을 제공하며, 공개 Google Cloud Service Health 대시보드에는 게시되지 않는 영향력이 작은 이슈를 게시할 수 있습니다. 다음은 통합되는 제품 및 지원되는 기능의 전체 목록입니다. 지원되는 Google Cloud 제품 및 기능은 시간이 지나면서 증가할 전망입니다.

고객 및 파트너의 사례

"클라우드 공급업체는 서비스 중단을 너무 빨리 알리는 것이 아닌지 염려하며 지나치게 신중한 접근을 보입니다. 모르고 있는 상태에서 워크로드가 다운되는 것보다 선제적으로 워크로드를 이동한 뒤에 문제가 없음을 발견하는 편이 낫다고 생각합니다. Google Cloud가 이 단계를 고객에게 보다 투명하게 공개하는 것에 만족감을 느끼며 앞으로 PSH 활용이 기대됩니다."

- 저스틴 왓츠, Telus 정보 서비스 및 기술 전략 부문 책임자

“Personalized Service Health가 이슈 대응 전문가에게 보내는 사전 예방적 알림은 모든 기업 고객의 이슈 대응 프로세스에서 중요한 역할을 합니다. PagerDuty와 Google Cloud의 파트너십은 클라우드 서비스 중단에 신속하게 대응하고 원활한 디지털 경험을 제공하는 데 도움이 되는 현대적 운영을 위한 필수적인 플랫폼을 고객에게 제공할 수 있도록 지원합니다."

-조나단 렌드, PagerDuty 제품 부문 SVP

지금 시작하기

안정적인 인프라는 클라우드 워크로드를 위해 필수적이며 Google은 기술, 제품, 프로세스 혁신을 통해 안정성의 기준을 지속적으로 높이고 있습니다. 안정석의 핵심 구성요소는 이슈 대응의 속도와 효율성입니다. 발생 가능성이 낮기는 하지만 만약 클라우드 서비스 이슈가 발생한다면 원활한 커뮤니케이션이 중요합니다. Personalized Service Health는 이슈 대응 커뮤니케이션을 한 단계 더 발전시키는 데 필요한 정보를 제공하므로 현재 일어나고 있는 상황을 신속하게 평가하고 애플리케이션에 대한 영향을 최소화하기 위한 조치를 취하고 이해관계자에게 계속 정보를 제공할 수 있습니다. 시작하려면 프로젝트 또는 조직 전반에서 Personalized Service Health를 사용 설정하세요.

속도와 안정성 사이 균형을 이룬 DevOps Awards 수상자 Kakao Mobility

Wed, 02 Aug 2023 06:00:00 +0000

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

한국에서 선도적인 모빌리티 서비스 제공업체인 Kakao Mobility는 모바일 내비게이션 서비스, 대중교통 정보 제공, 택시 호출 서비스, 대리 호출 서비스 등 다양한 서비스를 사용자 들에게 제공하고 있습니다. 이 블로그 게시물에서는 KakaoMobility가 2022 DevOps 어워즈에서 '안정성 저하 없는 속도 최적화' 상을 수상할 수 있었던 DevOps 성과를 집중 조명합니다. 수상 기업과 해당 기업에서 DORA 측정항목 및 권장사항을 사용하여 비즈니스를 성장시킨 방법을 자세히 알아보려면 여기에서 시작하세요.

Kakao Mobility는 고객들이 출퇴근 시간 등에 서비스를 집중적으로 사용한다는 것을 잘 알고 있기에 100% 업타임 SLA를 보장하기 위해 노력하고 있습니다. 실시간 교통 정보 모니터링과 결제 시스템부터 운전자 예약에 이르기까지 광범위한 서비스를 통합하고 지속적으로 확대하려면 필요에 따라 확장할 수 있는 클라우드 인프라가 필요합니다. 유연한 확장이 어려운 인프라 환경에서는 새로운 서비스와 기능 배포가 어려울 수 있으므로, 사용자에게 제공하는 서비스의 성능이 크게 저하될 수 있습니다.

시내 교통은 출퇴근 시간의 변동부터 예기치 못한 사고에 이르기까지 예측하기 어려운 특성이 있어, 사용자 트래픽이 급증하는 경우가 종종 발생하고 이로 인해 고객 경험이 저하될 수 있습니다. 가용성과 응답성의 감소가 소비자층의 불신과 이익 손실로 이어질 수 있음을 잘 알고 있기에 필요에 따라 확장할 수 있는 내결함성과 복원력이 우수한 시스템을 제공해야 합니다. Kakao Mobility에서는 네이티브 앱 환경에 다양한 교통 및 모빌리티 서비스를 통합하기 위해 API를 통해 서드 파티 플랫폼에 서비스를 제공합니다. 또한 서비스의 보안 상태를 유지하기 위해 API 복원력을 강화하는 한편 고객을 위해 100% SLA 목표를 달성하려는 노력을 기울이고 있습니다.

목표

시장점유율과 서비스 운영 국가를 늘리고 고객에게 새로운 기능과 서비스를 제공하면서도 사용자에게 가용성 높은 앱 경험을 제공하려면 복원력에 초점을 맞춰야 합니다. 통근하는 고객들이 제시간에 직장에 도착하려면 서비스 안정성이 중요합니다. 이에 따라 최악의 시나리오에서도 가용성을 유지할 수 있도록 멀티 클라우드 전략을 추구하고 있습니다.

Kakao Mobility의 하이브리드 클라우드 전략에는 크게 세 가지 목표가 있습니다.

애플리케이션을 분리 및 현대화하여 Kubernetes 컨테이너와 마이크로서비스 통합
개발자 부담을 완화하면서 배포 수행 속도 개선
서비스의 가용성, 안정성, 성능 향상

속도와 안정성 개선

다단계 마이그레이션 프로세스는 멀티 클라우드 하이브리드 클라우드 아키텍처를 구축할 수 있도록 환경을 현대화하는 것에서 시작됩니다. 2021~2022년에 Kakao Mobility의 팀은 애플리케이션을 마이크로서비스로 재구조화하여 워크로드를 Google Cloud에서 성공적으로 구동하였으며, Anthos Service Mesh(ASM)를 API 조정 플랫폼으로 사용하기 시작했습니다. 클라우드 리소스의 탄력성과 확장성 덕분에 팀에서는 비용 효율적이고 안정적인 솔루션을 경험하고 있습니다.

2022년에는 플래그십 애플리케이션을 Google Cloud로 성공적으로 마이그레이션했습니다. Google Kubernetes Engine(GKE) 클러스터를 사용하여 구현한 덕분에 확장성과 안정성을 유지하고 있습니다. DevOps팀은 Google Cloud와 긴밀하게 협력하면서 기존 서비스를 현대화하여 온프레미스와 Google Cloud 간의 새로운 멀티 클라우드 전략을 지원하고 있습니다.

Kakao Mobility는 Anthos Service Mesh를 통해 게이트웨이를 배포하여 애플리케이션 전반에 걸쳐 트래픽의 인그레스와 이그레스를 제어하고 여러 GKE 클러스터에서 리소스를 분리합니다. API는 서드 파티 오프라인 애플리케이션을 비롯해 안정적이고 확장 가능한 사용자 서비스를 제공하는 데 중요한 역할을 합니다.
Google Cloud 이벤트 관리 서비스(EMS)는 한국 명절이나 크리스마스 연휴, 새해 전야와 같이 트래픽이 급증할 것으로 예상되는 주요 시즌 이벤트 때 안정성과 가용성을 확보할 수 있도록 도와줍니다. Google Cloud팀과의 긴밀한 협력은 인프라를 강화하여 이벤트 전반에서 안정성을 유지하는 것뿐만 아니라 만일의 사태에 대비할 수 있도록 시뮬레이션과 모의 훈련을 실행하는 데도 도움이 됩니다.

고객 중심의 설계

Anthos Service Mesh 덕분에 Kakao Mobility는 IT 환경을 현대화하고 클라우드 보안을 강화했으며, 앞으로 더 많은 Google Cloud 서비스를 도입할 계획입니다.

포드(Pod) 확장 시간은 더 이상 배포 시간에 포함되지 않습니다. 포드(Pod) 가 모두 시작한뒤에 배포 관리자는 그때부터 트래픽 제어로만 배포를 수행합니다. 배포 관리자는 원하는 만큼의 트래픽을 새 버전으로 전달하고 충분한 시간을 두고 검증할 수 있으며, 핫픽스 배포가 필요한 경우 10초 이내에 트래픽 전환으로 배포를 완료합니다. 실제 사례에서도 긴급한 배포가 필요한 경우 새로운 버전의 포드(노드 포함)를 프로비저닝하는 데 걸리는 시간은 약 10분에 불과했고, 그 10분 동안 트래픽을 안정적으로 처리했습니다.

이제 개발자팀은 API 액세스에 대한 보안을 강화하고 Anthos Service Mesh를 통해 트래픽을 허용 목록에 추가하여 통근 시간에 업무 부담이 몰리지 않도록 합니다. 전체 서비스를 담당하는 개발팀이 운영하는 마이크로서비스는 ASM을 구현하면서 2개에서 9개로 무려 450% 증가했습니다.

어떻게 조직 내부의 지속적인 개선에 집중해야 하는지 알려준 DORA 연구가 없었다면 이 가운데 무엇도 해낼 수 없었을 것입니다. 이 프로젝트가 항상 성공적인 과정을 거친 것은 아니지만, 실패를 겪을 때도 고객에게 보다 효과적이고 효율적으로 서비스를 제공하기 위해 향후 어떤 부분에 집중해야 하는지 세밀하게 파악할 수 있었습니다.

DevOps Award 수상 기업을 하이라이트하는 나머지 시리즈와 함께 2022 State of DevOps 보고서를 읽고 DORA 연구에 대해 자세히 알아보세요.

DevOps팀, IT 운영팀, 플랫폼 엔지니어, SRE팀이 Google Cloud Next에 참석해야 하는 5가지 이유

Tue, 01 Aug 2023 16:00:00 +0000

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

급변하는 기술 세계에서 DevOps, IT 운영, 플랫폼 엔지니어링, SRE 분야의 전문가들은 반드시 최신 혁신 기술과 권장사항에 대한 정보를 발빠르게 파악해야 합니다. Google Cloud Next는 최신 정보를 접할 수 있는 최적의 장소입니다. 유용한 정보를 얻고, 지식을 넓히고, 관심사가 비슷한 동료들과 교류할 수 있는 절호의 기회입니다. 올해 운영 전문가들이 Next '23에 꼭 참석해야 하는 설득력 있는 이유 5가지에 대해 읽어 보세요.

1. 운영을 위한 생성형 AI의 잠재력 발견하기

최근에 진행된 IDC 설문조사¹에 따르면 IT 운영이 생성형 AI의 지원으로 가장 많은 이점을 누릴 수 있는 분야로 나타났습니다. 생성형 AI는 일상 업무의 자동화부터 잠재적인 문제 예측과 예방에 이르기까지 IT팀의 업무 방식을 혁신할 수 있습니다. Next '23은 최신 AI 혁신 기술에 대해 자세히 알아보고 이러한 기술이 IT 운영을 강화하는 데 어떻게 도움이 될 수 있는지 살펴볼 기회입니다. Google 전문가들이 연사로 나서 Google Cloud에서 AIOps 플랫폼을 구축한 실제 성공 사례를 공유할 예정입니다. 워크플로 최적화, 시스템 안정성 향상, IT 환경의 효율성 증대를 위해 AI가 발휘할 수 있는 막대한 잠재력을 확인하는 시간이 될 것입니다.

2. 플랫폼 엔지니어링 채택

플랫폼 엔지니어링은 강력하고 확장 가능하며 효율적인 소프트웨어 배포 플랫폼을 빌드하려는 조직에 중요한 분야로 부상했습니다. Next '23은 전문가들이 플랫폼 엔지니어링의 원칙과 관행을 자세히 알아볼 수 있는 좋은 기회입니다. 업계를 선도하는 혁신적인 리더들이 패널로 참여하고 플랫폼 엔지니어링 고객 성공사례를 공유하는 등 다양한 세션을 통해 개발자를 위한 자체 소프트웨어 배포 플랫폼을 설계하고 빌드하는 데 필요한 전문성을 얻을 수 있습니다.

3. 최신 GKE 혁신에 대해 알아보기

Google Kubernetes Engine을 즐겨 사용하는 사용자라면 최신 GKE 기능, 권장사항, 동료들의 실제 사용 사례에 대한 유용한 정보를 얻을 수 있는 이 기회를 놓치지 마세요. 최초의 관리형 Kubernetes 제품인 GKE는 수많은 고객의 마음을 사로잡았으며, 올해 Next '23에서 그 이유를 확인할 수 있습니다. ANZ Bank, Equifax, Ordaōs Bio, Etsy, Moloco와 같은 GKE 고객들이 성공사례를 공유할 예정입니다. 더 나아가 최신 워크로드를 실행하는 데 도움이 될 수 있도록 GKE에 추가되는 최신 혁신 기능도 공개됩니다.

4. 동료들에게 영감을 얻기

동료들에게 배우는 것은 기술 전문가에게 매우 소중한 경험입니다. Next '23에서는 선도적인 조직이 Google Cloud의 솔루션을 활용하여 비즈니스 성장과 혁신을 추진한 고객 성공사례를 살펴볼 수 있습니다. Charles Schwab의 Google Cloud 서비스 운영 권장사항을 듣고, SAP가 자동화로 비용을 관리하고 재정적 복원력을 구축한 노하우를 배우고, 오픈소스에서 Google Cloud 운영 도구로 전환하여 비용을 64% 절감한 Wayfair의 사례에 귀를 기울여 보세요. Snap은 관측 가능성에 대한 접근 방식을 공유하고, Priceline은 안정성과 비용 효율성을 위해 Kubernetes를 최적화하는 방법을 다루며, Uber는 Google Cloud 서비스를 사용하여 AIOps 플랫폼을 구축하는 방법을 소개합니다.

5. 네트워킹과 커뮤니티 구축

네트워킹과 커뮤니티 구축은 Google Cloud Next 경험에서 필수적인 부분인데 올해는 특히 더 흥미로운 기회가 마련됩니다. 팬데믹 이후 처음으로 진행되는 이번 프리미어 이벤트는 대면 모임이라는 본연의 방식으로 돌아갑니다. DevOps와 IT 운영 전문가들을 위한 Innovator Hive 전문 구역에서 다른 전문가들과 교류하세요. 대화형 데모를 직접 체험하고, 소소한 챌린지를 시도하고, 몰입형 학습에 도전하고, 게임을 플레이하고, Google 전문가와 동료들을 만나 아키텍처에 대해 자세히 알아보세요. 상호작용을 통해 새로운 관점과 아이디어를 얻고 미래의 파트너십으로 이어질 기회가 펼쳐치리라 자신합니다.

Google Cloud Next는 평범한 기술 이벤트가 아닙니다. 커리어를 전환하고 클라우드와 기술에 대한 열정을 불태울 수 있는 몰입형 경험을 선사할 것입니다. 최신 GKE 혁신 기술을 탐색하는 것부터 IT 운영에 도움이 되는 AI의 마법 같은 기능을 살펴보는 것까지, 또한 플랫폼 엔지니어링을 채택하는 것부터 동료들에게 배우는 경험에 이르기까지 Next '23은 지평을 넓히고 기술을 향상시킬 수 있는 기회로 가득합니다.

이 특별한 이벤트에 참여할 기회를 놓치지 마세요. 캘린더에 일정을 기록하고, 기대감을 키우며, Google Cloud Next에 참여해 보세요. 모두 함께라면 클라우드 기술의 잠재력을 최대한 발휘하며 더 밝고 혁신적인 미래로 향하는 길을 닦을 수 있습니다.

^{1: 미국 – 생성형 AI, IDC, 2023 4월, N= 200명, Base= 전체 응답자. 참고: IDC의 Global Primary Research Group에서 관리, 가중치가 적용되지 않은 데이터. 표본 크기가 작은 경우 해석에 주의하세요.}

AI 기반 공동작업 도구 소개: Duet AI for Google Cloud

Mon, 19 Jun 2023 06:00:00 +0000

클라우드 개발자 여러분, 바야흐로 무엇이든 할 수 있는 시대입니다. 원하는 언어로 코딩하고, 컨테이너로 이식성을 활용하고, 서버리스로 복잡성을 최소화하고, DevOps 원칙에 따라 전체 소프트웨어 수명 주기를 관리할 수 있습니다. 그렇지만 현실을 직시해보죠. 새로운 클라우드 애플리케이션을 빌드하고 온보딩하려면 여전히 수작업 계획 통합, 그리고 그야말로 고된 작업을 해야 합니다. 배포에 대해 조사하고 계획을 수립하고, 실행 가능하며 안전한 아키텍처를 만들어야 하며, 실제 코드 또한 작성해야 합니다.

지난 수십 년 간 클라우드는 기본적으로 다양한 옵션을 제공하는 'DIY' 모델로서 개발을 더욱 복잡하게 만드는 방향으로 발전해 왔습니다. 처음에는 기쁨의 비명을 질렀지만, 이제는 비명만 지르게 된 상황입니다.

그 기쁨을 온전히 되찾을 수 있다면 어떨까요? 필요하기만 하면 언제 어디서든 도움을 얻을 수 있다면 어떨까요?

Duet AI for Google Cloud 소개

Google의 최신 생성형 AI 기반 모델로 구동되는 Duet AI for Google Cloud는 상시 사용 가능한 AI 공동작업 도구로, 기술 수준에 관계없이 모든 사용자에게 필요한 도움을 제공합니다. Google은 Duet AI를 통해 사용자 의도에 기반하며 맞춤화된 새로운 클라우드 경험을 선사하고 사용자 환경을 심층적으로 파악하여 확장 가능하면서 안전한 애플리케이션 구축을 지원하는 동시에 전문적인 가이드를 제공하고자 합니다.

Google은 Duet AI에 맞춰 Google Cloud를 진화시키면서 책임감 있는 AI를 경험의 중심에 두며 더욱 인간 중심적이고 종합적이며 유용한 클라우드 플랫폼을 구축하고자 합니다.

인간 중심: Google은 Duet AI를 통해 필요할 때마다 개발자를 위한 코드 추천부터 데이터 엔지니어를 위한 프롬프트 기반 데이터 통계, 비즈니스 사용자를 위한 채팅 기반 앱 제작에 이르기까지 다양한 지원을 제공함으로써 기술 수준에 관계없이 모든 유형의 사용자가 Google Cloud에 더욱 쉽게 액세스하고 맞춤화하여 사용할 수 있도록 지원합니다.
종합적: 생성형 AI 중심의 클라우드 환경을 사용하면 기능, 서비스, 기술 스택 전반에 걸쳐 사일로가 감소하고 유기적으로 클라우드를 개발할 수 있으며, Google Cloud의 어떤 위치에서든 원하는 형식으로 전체 그림을 파악할 수 있습니다.
유용성: Google Cloud로 앱을 빌드하고 운영하기 위한 더욱 스마트하고 문맥에 맞는 권장사항을 제공하기 위해 Duet AI를 지원하는 기본 모델 중 하나인 Codey를 문서 및 샘플 코드와 같은 Google Cloud 관련 콘텐츠로 선행 학습시키고 Google Cloud 사용자 행동 및 패턴을 토대로 미세 조정했습니다.
책임감: Google은 AI 원칙에 따라 책임감 있게 기술을 개발하려는 노력을 기울입니다. 사용자의 코드와 권장사항은 모델 학습과 개발에 재사용되지 않습니다. 따라서 데이터 및 코드를 보호하고 AI 모델을 학습시키는 지식 공간의 무결성을 보장할 수 있습니다.

Duet AI for Google Cloud에서 새롭게 제공되는 기능

사용자 의도에 기반한 그리고 개인에게 맞춤화된 새로운 클라우드 경험을 선사한다는 Google의 미션을 가능케 하는 새로운 기능 몇 가지를 소개합니다.

코드 어시스턴스는 애플리케이션 개발자와 데이터 엔지니어 같은 클라우드 사용자를 위한 AI 기반 코드 어시스턴스를 제공합니다. 코드를 입력할 때 실시간으로 추천 코드를 제공하고, 전체 함수와 코드 블록을 생성하며, 코드의 취약성과 오류를 파악하여 수정 사항을 제안합니다.

Google Cloud Storage 버킷 생성 코드를 자동 생성하는 코드 어시스턴스

코드 어시스턴스는 Google의 완전 관리형 보안 개발 환경인 Cloud Workstations와 Google Cloud 콘솔에서 제공하는 기타 코드 편집기 환경 등 Google Cloud 전반의 여러 제품 및 서비스에서 활용가능해집니다. 또한 Cloud Shell 편집기 또는 VSCode 및 JetBrains IDE를 위한 Cloud Code IDE 확장 프로그램에서도 개발자에게 코드 어시스턴스를 제공합니다. 코드 어시스턴스는 Go, Java, JavaScript, Python, SQL을 비롯해 다양한 언어를 지원합니다.

채팅 어시스턴스를 사용하면 간단한 자연어를 사용하여 개발 또는 클라우드에 관련된 구체적 질문에 답변을 얻을 수 있습니다. 사용자는 채팅 어시스턴스를 통해 특정 클라우드 서비스 또는 기능을 사용하는 방법이나 클라우드 프로젝트 구현을 위한 세부 계획 등 다양한 주제에 대해 실시간 안내를 받을 수 있습니다. 또한 아키텍처 또는 코딩 관련 권장사항을 제공하므로 관련 문서를 검색할 필요성이 줄어듭니다.

채팅 어시스턴스를 사용하여 Cloud Run에 앱을 배포하기 위한 세부 단계 알아보기

또한 IDE, Cloud 콘솔과 같은 여러 Google Cloud 표시 영역과 제품 및 서비스에서도 채팅 어시스턴스가 제공됩니다. 채팅 어시스턴스를 활용하면 개발자, 운영자, 데이터 엔지니어, 보안 전문가 등이 더 많은 작업을 보다 빠르게 완료할 수 있습니다.

한 가지 특정 영역에 전문화된 개발자를 위해 이러한 기능을 더욱 최적화하려면 기업에서 Vertex AI의 생성형 AI 지원을 사용해 자체 코드베이스로 Codey를 미세 조정하면 됩니다. 현재 Vertex AI에서 이러한 맞춤형 Codey 모델을 직접 사용할 수 있으며 올 하반기에는 기본 제공 Duet AI 환경과 연결할 수 있게 될 예정입니다. 코드로 Codey를 학습시키는 경우에도 비공개 데이터는 비공개로 유지되며 광범위한 기반 모델 학습 코퍼스에서 사용되지 않으니 걱정하지 마세요. 데이터가 저장되는 위치와 데이터가 사용되는 방식 또는 사용 여부를 직접 관리하고 투명하게 확인할 수 있습니다.

Duet AI for AppSheet를 사용하면 지능형 비즈니스 애플리케이션을 만들어 데이터를 연결하고 자연어를 통해 Google Workspace에 워크플로를 구축할 수 있습니다. AI 기반 프롬프트가 안내하는 채팅에서 사용자가 요구사항을 설명하는 방식으로 앱을 빌드할 수 있어 코딩이 필요하지 않습니다. 덕분에 더욱 많은 사용자의 앱 제작이 가능해져 개발자팀에서 더 중요한 다른 업무에 집중할 수 있습니다.

Duet AI for AppSheet를 사용하여 자연어로 비즈니스 애플리케이션 제작하기

지속적으로 진화하는 공동작업 도구의 도움을 얻어 개발자의 과도한 업무 부담을 완화하면서도 클라우드 개발의 즐거움을 되찾게 되기를 바랍니다. Duet AI를 사용하여 보다 자신 있고 쉽고 재미있게 클라우드를 탐색하세요.

게다가 이것은 시작에 불과합니다. Duet AI가 선사하는 클라우드 경험의 미래에는 가능성이 가득합니다. Google은 정교하게 맞춤화된 지원에 개발자 생산성 향상의 미래가 달려 있다고 생각합니다. Duet AI는 Google만의 고유한 엔드 투 엔드 AI 지원 기술을 사용하여 작업 환경의 생산성을 새롭게 정의합니다. Duet AI for Google Cloud에 대한 Google의 비전을 보려면 여기를 확인하세요.

현재 Duet AI for Google Cloud의 초기 기능은 제한된 사용자에게만 제공되며, 곧 제공 범위가 확대될 예정입니다. Google Cloud의 신뢰할 수 있는 AI 테스터 프로그램에 참가하려면 여기에서 가입하세요.

맞춤설정 가능한 모니터링 대시보드로 시스템 관측 가능성을 향상시키는 Cloud Storage

Mon, 02 Jan 2023 00:00:00 +0000

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

Google Cloud Storage는 비정형 데이터를 저장하고 사용자가 원하는 만큼 데이터를 가져올 수 있는 관리형 서비스입니다. Cloud Storage는 활용도가 높은 기본 서비스이기 때문에 스토리지 관측 가능성이 스토리지 엔지니어와 관리자의 일상적인 운영 업무에 매우 중요하며 비즈니스의 확장성과 지속 가능성을 위해서도 중요합니다.

스토리지 관측 가능성과 관련해 Cloud Storage 사용자들은 다음과 같은 질문을 합니다.

스토리지 프로젝트 및 버킷 관측을 시작하기 위한 권장사항은 무엇인가요?
문제를 사전에 식별하고 해결하기 위해 모니터링해야 할 가장 중요한 운영 측정항목/로그는 무엇인가요?
내가 관심을 두고 있는 스토리지 측정항목에 대한 알림을 만들려면 어떻게 하면 되나요? 스토리지 프로젝트 안에서 알림을 확인하거나 버킷에 대한 알림을 볼 수 있나요?

또한 사용자들은 여러 관측 가능성 도구를 오가야 하기 때문에 다양한 모니터링 플랫폼 간에 이동하는 동안 컨텍스트를 놓치는 경우가 많다고 말합니다.

오늘 Google에서는 프로젝트 수준과 버킷 수준 모두에서 사용할 수 있는 새로운 Cloud Storage용 모니터링 대시보드를 공개 미리보기 버전으로 출시한다는 기쁜 소식을 전해드립니다.

이제 모든 Cloud Storage 사용자가 왼쪽 탐색 메뉴에서 모니터링 탭을 통해 새 대시보드를 이용할 수 있습니다.

니즈에 따른 고도의 맞춤설정

Google은 모든 사용자의 니즈를 충족할 수 있는 단일 관측 가능성 도구란 없다는 사실을 잘 알고 있습니다. 사용자가 자신만의 대시보드 버전을 만들고 기본 뷰로 설정할 수 있도록 대시보드를 컨텍스트에 따라 맞춤설정할 수 있게 만든 이유가 바로 여기에 있습니다. 모니터링 편집자 또는 소유자 액세스 권한이나 프로젝트 편집자 또는 소유자 액세스 권한이 있다면 전에 만든 알림 정책에서 알림 차트를 추가하거나 즉시 사용 가능한 대시보드를 맞춤설정하여 알림을 만들 수 있습니다. 맞춤설정된 대시보드에 알림 차트를 추가하면 Cloud Storage 모니터링 페이지에서 컨텍스트별로 알림을 직접 확인할 수 있습니다. 또한 Google Cloud 콘솔의 스토리지 페이지를 벗어나지 않고도 대시보드에 여러 서비스의 측정항목을 추가하여 상관관계를 관측할 수 있습니다.

로그 패널에서는 관심을 두고 있는 가장 중요한 로그를 반영하도록 로그 뷰어 쿼리를 수정하고 해당 쿼리를 스토리지 프로젝트 맞춤설정 대시보드에서 유지할 수 있습니다. 동일한 대시보드에서 측정항목과 로그를 살펴볼 수 있어 컨텍스트 전환이 줄어들고 보다 효과적으로 문제를 해결할 수 있습니다.

맞춤설정 가능한 대시보드를 사용하면 플랫폼의 스토리지 페이지 내에서 문제 해결 과정을 수행할 수 있으므로 여러 모니터링 도구나 모니터링 플랫폼 간에 이동할 필요성이 줄어듭니다.

즉시 사용 가능한 운영 측정항목

스토리지 관측 가능성에는 여러 가지 측면이 있는데 새 모니터링 대시보드는 문제 해결에 초점을 맞추고 있습니다. 여기에는 모든 스토리지 사용자가 Google Cloud에서 스토리지 서비스를 시작할 때 자동으로 받게 되는 즉시 사용 가능한 스토리지 시스템 측정항목과 스토리지 시스템 로그가 포함됩니다.

Cloud Monitoring UI에서 차트 위로 마우스를 가져가 값을 읽거나 범례를 펼치고, 기간을 확대 또는 축소하여 데이터를 보다 상세하게 또는 간략하게 살펴보고, MQL 또는 PromQL 같은 고급 쿼리를 사용할 수 있습니다. 실제로 Google Cloud 콘솔의 스토리지 페이지 내에서 Cloud Monitoring 대시보드의 모든 기능을 사용할 수 있습니다.

대시보드에서 사용할 수 있는 차트와 로그 패널에 대해 자세히 살펴보도록 하겠습니다.

차트

Storage API 요청 수의 서버 오류율: 모든 서버 측 5xx 오류를 표시하도록 필터링합니다.

Storage API 요청 수의 클라이언트 오류율: 응답 코드를 포함해 모든 클라이언트 측 4xx 오류를 표시하도록 필터링합니다.

읽기 오류가 가장 많이 발생한 상위 5개 버킷: 응답 코드가 INTERNAL 및 UNAVAILABLE 오류인 List 및 Read 메서드로 필터링되며 상위 5개 버킷에서 측정됩니다. 이러한 오류가 발생한 버킷을 더 많이 표시하도록 차트를 손쉽게 맞춤설정할 수 있습니다.

쓰기 오류가 가장 많이 발생한 상위 5개 버킷: 읽기 오류가 가장 많이 발생하는 경우와 마찬가지로 이 차트는 응답 코드가 INTERNAL 및 UNAVAILABLE 오류인 WriteObject 메서드로 필터링됩니다.

총 Read/List/Get 요청 수: Read, List, Get 메서드의 API 요청 수로 필터링됩니다. 특정 시간 동안 이 3가지 메서드에 대해 발생한 총 요청 수와 API 메서드의 위치별로 분류한 총개수가 표시됩니다.

총 쓰기 요청 수: 모든 API 요청의 Write 메서드로 필터링되며 쓰기 요청의 총개수가 위치별로 분류되어 표시됩니다.

네트워크의 데이터 인그레스 속도: 수신 바이트 속도를 표시하여 프로젝트당 또는 버킷당 인그레스 속도를 쉽게 파악할 수 있습니다.

프로젝트의 총 수신 바이트 볼륨을 표시하도록 이 차트를 맞춤설정할 수 있습니다.
버킷 수준 대시보드에서는 프로젝트의 버킷당 인그레스 속도를 표시하도록 차트가 필터링됩니다.

네트워크의 데이터 이그레스 속도: 전송 바이트 속도를 표시하여 프로젝트당 또는 버킷당 이그레스 속도를 쉽게 파악할 수 있습니다.

로그 패널

GCS 로그 및 감사 로그 위젯

이 2가지 로그 위젯은 심각도가 오류와 같거나 큰 GCS 로그 및 GCS 감사 로그로 필터링됩니다. 심각도가 오류, 심각, 알림, 긴급에 해당하는 로그가 로그 패널에 표시됩니다.
위젯에서 로그 항목을 펼쳐 '로그 탐색기에서 보기' 버튼을 클릭하면 로그 탐색기 뷰로 쉽게 이동할 수 있습니다.

프로젝트 수준에서 사용할 수 있는 모든 차트가 버킷 수준에서도 제공되며 특정 버킷으로 대시보드가 필터링됩니다. 버킷 수준 대시보드의 맞춤설정이 생성되면 프로젝트 내의 모든 버킷 수준 대시보드에 맞춤설정된 버킷 수준 대시보드가 자동으로 표시됩니다. 간편하게 다른 버킷으로 이동하고 드롭다운 메뉴에서 맞춤설정된 대시보드를 선택해 확인할 수 있습니다.

지금 미리보기로 시작하기

Cloud Storage UI의 왼쪽 탐색 메뉴에서 모니터링 탭을 클릭하면 지금 바로 미리보기를 시작할 수 있습니다. 모든 Cloud Storage 사용자에게 미리보기가 제공됩니다.

이 대시보드를 모든 사용자에게 공개적으로 제공하게 된 것을 기쁘게 생각하며 여러분의 소중한 제안과 의견을 기다리겠습니다.

각 대시보드에서 '의견 보내기' 버튼을 사용하면 의견을 제출할 수 있습니다. 보내주신 모든 제안을 신중하게 검토하고 모든 사용자가 Cloud Storage 내에서 일상적인 운영을 분석하는 데 도움이 되도록 대시보드를 지속적으로 개선해 나가겠습니다.

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

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

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

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

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

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

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

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

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

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

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

개발자를 위해 만들어진 클라우드 — 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배 더 빠르게 혁신을 이루세요.

Lowe’s가 Google SRE 관행으로 고객 수요를 충족하는 방법

Tue, 14 Sep 2021 00:00:00 +0000

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

편집자 주: 오늘은 Lowe’s SRE팀의 사례를 살펴보겠습니다. Google 사이트 안정성 엔지니어링(SRE) 프레임워크를 채택하고 Google Cloud와의 파트너십을 활용해서 지원 가능한 출시 수를 늘릴 수 있었던 비결을 공유합니다.

Lowe’s는 다년간에 걸쳐 기술 혁신을 단행하면서 괄목할 만한 발전을 이뤄냈습니다. 시스템을 현대화하고 고객 및 관계자를 위한 새로운 기능을 빌드하기 위해 Lowe’s는 니즈를 보다 빠르고 효율적으로 충족시킬 수 있도록 지원하는 Google SRE 프레임워크 및 Google Cloud를 활용하고 있습니다. 이러한 노력에 힘입어 2주에 한 번이었던 출시가 하루 20개 이상으로 증가하면서 월별 출시 횟수가 약 20배 뛰었습니다.

하지만 SRE 혁신이 하루 밤 사이에 이뤄진 것은 아닙니다. 혁신을 이루는 단계마다 난관에 부닥쳤습니다. 하지만 돌아보면 결과적으로 고객을 위해 많은 성과를 이뤘다는 점에서 보람을 느낍니다.

SRE 관행을 채택하기 전인 2018년에는 주도적이기보다 수동적으로 대응하면서 '모니터링에 급급한' 자세를 취했습니다. 반복 작업과 수동 작업이 지나치게 많아 상시 대기 구조 및 사고 관리 효율성이 낮았기 때문에 운영 부담이 컸습니다. 프로덕션 환경의 문제가 제품 로드맵에 반영되지 않아 수정 시 지연이 발생했습니다.

Lowe’s의 SRE 부트스트랩 수행

온프레미스에서 Google Cloud로 이전함에 따라 모놀리식 기반에서 마이크로서비스 기반의 아키텍처로 이동하기로 결정했습니다. 또한 새로운 아키텍처를 보다 효과적으로 관리하기 위해 SRE 여정을 시작했습니다.

그러다 코로나19 사태 발생과 더불어 고객들이 전면적인 주택 개조 니즈를 충족하기 위해 부쩍 온라인 주문 및 배달을 선택하면서 SRE 여정에 더욱 박차를 가해야 했습니다. 이를 위해 Lowe's는 변화하는 고객 니즈를 빠르게 충족시키고 신속하고 안정적으로 제품을 출시할 수 있도록 도와주는 네 가지 원칙을 따랐습니다.

자동화로 업무 부담 제거
기존 운영 방식에서 SRE 생태계로 이동하면서 발생한 가장 큰 기회는 업무 부담이 줄어든 것입니다. 덕분에 엔지니어가 경영 성과 및 고객이 원하는 결과물을 도출할 수 있는 활동에 시간을 투자할 수 있습니다. 여기서 업무 부담이란 반복적이며, 전략적이고, 지속적인 가치가 결여되어 있으나 자동화가 가능한 수작업을 의미합니다. 업무 부담을 덜기 위해 Lowe's는 직접 개입해야 하는 작업을 자동화하는 일에 집중했습니다. 예를 들어 알림이 발생했을 때 엔지니어가 최초의 연락 지점이 되지 않도록 했습니다. 엔지니어가 수행할 수 있는 분류 작업이나 해결 방법이 있다면 머신이 동일한 작업을 수행할 수 있도록 학습시킬 수 있습니다. Lowe's는 지도 및 비지도 학습 기술을 사용하여 업무 부담을 자동화했습니다. '업무 부담을 없애자'라는 장기적인 목표에 따라 SRE는 조직 전반에서 업무 부담을 식별하고 관리 가능한 수준으로 줄였습니다.
로드맵을 통한 엔지니어 조율
Lowe's의 목표는 개발팀의 엔지니어링 속도를 극대화하면서도 제품 안정성을 유지하는 것입니다. 이를 위해 제품팀, SRE팀, 개발팀이 긴밀하게 협업하는 참여 모델을 정립하고자 했습니다. 이러한 협업을 가능케 한 비결은 SRE를 도메인 및 제품팀에 포함시킨 것입니다. 각 도메인에 제품 개발의 초기 단계에 관여하는 SRE가 배치되어 해당 도메인의 관계자들이 SRE 이니셔티브에 부합하게 업무를 수행할 수 있습니다. 이와 같이 SRE는 서비스 수명 주기의 모든 단계에 걸쳐 서비스의 안정성, 성능, 확장성, 출시 속도를 향상시킬 수 있습니다.
원터치 출시 방식 채택
이전에는 프로덕션 경로에 여러 수동 단계 및 검증이 포함되어 기능 출시 속도를 둔화시켰습니다. 또한 한 번에 배포할 수 있도록 모든 출시를 하나로 묶었기 때문에 실패 위험이 커졌고 프로덕션에서 피드백 루프가 더 길어졌습니다. SRE 방식으로 이러한 문제를 해결하기 위해 SRE가 제품팀의 pull 요청을 검토하는 원터치 출시 프로세스를 만들었습니다. 승인을 받으면 승인된 변경사항을 프로덕션에 안전하게 배포하는 DevSecOps 파이프라인이 트리거됩니다. 이러한 프로세스는 빠른 피드백 루프가 가능한 안전하고, 안정적이고, 지속가능한 지속적 배포 파이프라인을 만들었습니다. 속도, 혁신, 안정성이 균형을 이루면서 연간 출시 횟수가 기하급수적으로 증가했습니다. 자동화된 여러 품질 확인 및 프로세스를 포함하여 양질의 코드를 제공하는 데 걸리는 시간이 30분 미만으로 단축되었고 이 모든 작업이 단 한 번의 클릭으로 가능해졌습니다.
용량 계획 수용
서비스에 급격한 트래픽 증가를 처리할 수 있는 충분한 예비 용량을 갖추기 위해, SRE는 지속적 배포(CD) 파이프라인에서 용량 변경 권장사항을 수행하는 용량 계획의 중요성을 강조했습니다. SRE는 지속적인 성능 모니터링을 통해 서비스가 강력하고, 안정적이며, 사용 가능한지 확인합니다. 또한 예측된 볼륨을 넘어서 트래픽이 급증하는 경우 SRE가 필요에 따라 용량을 변경하고 성능 및 도메인팀을 위해 해당 변경사항을 기록합니다.

용량 계획은 블랙 프라이데이 및 사이버 먼데이(BFCM) 같은 성수기에 특히 중요합니다. Lowe's는 3개월 전에 미리 SRE 안정성 계획을 마련하고 도메인팀의 제품 로드맵에 반영합니다. 이렇게 하면 개발팀이 안정성을 위해 충분한 엔지니어링 시간을 할당할 수 있습니다. 성능 테스트를 통해 해당 환경이 부하 증가를 장기간 견딜 수 있으며 트래픽 급증을 처리할 수 있는지 확인합니다. 또한 전 세계적인 규모로 리전 장애 조치 테스트를 수행하여 서비스수준계약(SLA)의 자동 장애 조치 기간, SRE, 도메인 준비 상황을 확인합니다. 아울러 블랙 프라이데이 및 사이버 먼데이와 관련된 집중 테스트를 수행하여 고객 경험, 안정성 등을 검증합니다.

Google Cloud의 블랙 프라이데이 및 사이버 먼데이고객 맞춤형 서비스는 Lowe’s가 2019년 BFCM 및 2020년 BFCM에 성공적인 결과를 얻는 데 핵심적인 역할을 했습니다. 이 서비스에는 Google 고객 신뢰성 공학(CRE)팀의 현장 방문을 통한 Lowe’s 웹 아키텍처, 용량 계획, 이벤트 위험에 대한 운영 관행 검토 및 사고 대응 권장사항과 같은 주제에 대한 워크샵 등이 포함됐습니다.

향후 계획

언제나 개선의 여지는 있으며 Lowe’s는 SRE 관행을 지속적으로 개선해나갈 것입니다. 지금까지 효과가 좋았고 앞으로도 이어갈 SRE 관행으로는 로드쇼를 꼽을 수 있습니다. 로드쇼에서는 선임 SRE 책임자가 다른 SRE 및 애플리케이션 도메인팀에 최신 SRE 원칙 및 권장사항을 소개하고 상대방의 의견을 실시간으로 청취하는 자리입니다.

Google 도구 및 방법론은 SRE 관행을 재구성하고 고객 서비스를 개선하는 데 있어서 중요한 역할을 했습니다. Lowe's는 SRE 여정을 지속하면서 Google Cloud와 모멘텀 및 파트너십을 계속 발전시켜 나가기를 기대합니다.

Google Cloud에서 SRE 권장사항을 채택하는 방법에 대한 자세한 내용은 관련 문서를 확인해 보세요. Google SRE에 대해 자세히 알아보려면 Google Cloud 웹사이트를 참조하세요. Lowe's에서 SRE 관행 및 도구를 채택하기 위해 엔지니어링 인력을 교육시키고 SRE 원칙에 따라 MTTR을 향상시킨 방법이 궁금하다면 다음 블로그를 기다려 주세요.

목표에 도달했나요? SRE팀의 성숙도 평가에 대한 고찰

Wed, 11 Aug 2021 02:12:00 +0000

고객 신뢰성 엔지니어(Customer Reliability Engineers, CRE), 즉 Google Cloud 고객이 조직에서 직접 관행을 개발하는 데 도움을 주는 Google 사이트 안정성 엔지니어(Google Site Reliability Engineer ,SRE)가 담당하는 업무에는 운영팀 또는 SRE팀이 운영 성숙도를 높이도록 자문을 제공하는 일이 포함됩니다. 이러한 논의에서 반복적으로 제기되는 질문이 있는데 일반적으로 "지금 우리가 하는 일이 'SRE 업무'인가요?" 또는 "우리를 SRE라고 부를 수 있나요?"라는 보다 존재론적인 요소가 가미된 같은 표현이 사용됩니다.

이전에는 그러한 질문에 SRE 통합문서의 관행 목록으로 답변했습니다. 하지만 목록에는 업무에 대한 내용은 많지만 팀의 존재 이유에 대한 설명은 적어 정체성 위기를 겪고 있는 팀에서 받아들이기는 어렵습니다. 그래서 Google에서는 SRE팀 운영에 있어 필수적이라고 생각하는 원칙에 대해 논의하여 그러한 질문에 답하는 데 도움을 드리고자 합니다. 운영 원칙이 중요한 이유를 살펴보고 원칙을 구현하는 과정에서 팀의 위치를 파악할 수 있는 질문을 제시하겠습니다.

목표에 도달했나요?

이 질문은 갖은 이유로 인해 다양한 방식으로 던질 수 있으며 고객이 운영하는 환경이 다양하기 때문에 이 질문에 답하기가 매우 어려울 수 있습니다. 더불어 CRE와 Google은 조직의 'SRE'가 무엇인가에 대해 최종 정의를 내릴 수 없기 때문에 권위 있는 답이 존재한다 하더라도 그 답을 제공할 수 없습니다. Google에서는 대면 상담 또는 책자와 블로그 게시물을 통해 의견과 경험을 제시하여 사용자와 커뮤니티에 영향을 줄 수 있을 뿐입니다.

게다가 이 주제에 대한 논의는 'SRE'라는 용어가 다음과 같은 세 가지 의미로 혼용되기 때문에 복잡해지는 경향이 있습니다.

서비스나 제품의 안정성을 유지하는 데 주력하는 직종
조직 내에서 일반적으로 위의 직종을 담당하는 집단
위 담당자가 서비스 안정성을 개선하는 데 사용할 수 있는 원칙 및 관행 집합

"우리를 SRE라고 부를 수 있나요?"라는 질문을 Google에서는 위의 세 가지 정의를 연결지으려는 시도라고 해석합니다. 이 해석을 보다 명확하게 표현하면 "우리 집단의 직종을 SRE라고 정의해도 합당할 정도로 원칙과 관행을 충분히 적용하고 있나요?"라는 질문이 될 수 있습니다.

SRE로 인정받을 만한 일을 하기 위한 원칙과 관행을 활용하기 위해서는 먼저 직종이나 팀이 명확히 정의되어야 한다는 의미가 아님을 분명히 밝힙니다. 조직이 성장함에 따라 직종과 팀은 보다 유연한 책임 집합을 통해 구체화됩니다. 하지만 구체화 과정 속에서 담당자들은 어디까지 책임을 져야 하는지에 대해 다소 확신을 잃게 되고 '목표에 도달했는가?'라는 질문을 하게 됩니다. 여기서 존재론적인 의문이 비롯된다고 생각합니다.

주요 SRE 지표

Google Cloud의 CRE팀에서는 "목표에 도달했나요?"라는 질문을 통해 SRE팀에 방향을 제시하는 핵심 원칙에 대한 다양한 의견을 도출했습니다. 하나의 단서를 달고 대략적인 합의에 도달했습니다. 바로, 이 질문에 대한 답은 팀이 지원하는 서비스에 관여하는 방식에 부분적으로 좌우된다는 것입니다.

프로덕션 단계의 서비스를 직접 지원하는 SRE로 활동하는 집단에서 지켜야 할 원칙을 중심으로 게시물을 작성했습니다. 리트머스 테스트처럼 본 게시물은 정확한 답을 제공하지는 않습니다. 다만 Google의 집단적인 의견은, 적어도 아래 소개된 대부분의 원칙에 부합한다면 사이트 안정성 엔지니어링팀이라고 부를 수 있는 관행을 실천하고 있다는 좋은 신호라고 할 수 있다는 것입니다.

직접적으로 개입하는 SRE팀은 일반적으로 서비스 안정성에 대한 책무(RACI 용어 측면)가 있으며 SRE팀과 개발팀이 책임을 공유한다고 간주됩니다. 팀이 직접 지원을 제공하는 정도가 덜하다면 이러한 지표를 적용하기 어려울 수 있습니다. 그렇더라도 팀이 처한 환경에 맞게 원칙을 조정할 수 있기를 바랍니다.

이를 실행하는 방법을 설명하기 위해 원칙별로 모범적으로 활동 중인 SRE팀에 반대되는 예를 제시했습니다. 이들은 주제 전문가로서 서비스 안정성에 대해 책임과 책무가 있는 개발팀으로부터 자문을 받습니다.

참여 모델이 스펙트럼 상에 있다면, 조직의 나머지 부서로부터 서비스 안정성에 대해 공동 책임을 지고 있는 팀 또는 안정성 주제 전문가로 간주되는 것은 SRE임을 판단할 수 있는 주요 지표입니다.

제1원칙: SRE는 현재와 미래의 이슈를 완화합니다

이 원칙은 일반적으로 서비스 안정성에 대한 책임 및 책무의 기저를 이룹니다. 이 세상에서 아무리 꼼꼼한 엔지니어링과 규제라도 특히 복합 분산 시스템에서의 안정성을 보장할 수 없으며 예상치 못한 오류가 발생하는 경우에는 대응하고, 완화하고, 바로잡는 수밖에 없습니다. SRE는 이러한 상황에서 신속하게 서비스를 복구하는 권한과 기술적 역량을 모두 갖추고 있습니다.

하지만 당면한 문제를 완화하는 것만으로는 부족합니다. 내일 문제가 다시 발생할 수 있고 심지어 오늘보다 상황이 더 나쁠 수 있기 때문에 SRE는 이슈 촉발 요소를 이해하고 담당하는 인프라 내 모든 등급의 문제를 방지하는 변경사항을 제안해야 합니다. 다음 달에 똑같은 식의 서비스 중단이 다시 발생해서는 안 됩니다.

서비스 중단이 얼마나 특별한 경우에 해당하나요? 다음을 자문해 보세요.

개발팀의 전문 지식이 없어도 이슈 대부분을 완화할 수 있나요?
교육 자료를 보존하고 이슈 대응 시나리오를 훈련하나요?
중대한 서비스 중단이 발생한 후 문제의 진정한 원인을 분명하게 밝히고 서비스 중단을 방지할 방법을 파악하는 주요 담당자에 해당하나요?

이제 반대 예를 알아보겠습니다. 많은 조직에서 SRE는 희소 자원에 해당하며 이슈 대응에 주력하기보다 기업 전반의 경쟁력을 강화하기 위한 플랫폼 및 권장사항을 개발함으로써 가치를 더할 수도 있습니다. 따라서 대대적인 서비스 중단 발생 시 컨설팅 SRE팀이 이슈 대응에 협력하도록 호출을 받더라도 대부분의 이슈 완화에 직접 관여하지 않을 가능성이 있습니다. 교육 자료를 작성하고 사후 분석을 진행하는 대신 자문을 받은 팀이 작성한 자료를 검토하는 업무를 담당합니다.

제2원칙: SRE는 적극적으로 서비스 안정성을 관리합니다

안정성 목표와 피드백 신호는 SRE 업무에 동기를 부여하고 개발 작업 우선순위에 영향을 주는 기본적인 요소입니다. Google에서는 안정성 목표를 서비스 수준 목표, 피드백 신호를 오류 예산이라 하며 자세한 활용 방식은 사이트 안정성 통합문서를 참조하시기 바랍니다.

안정성 신호가 조직의 우선순위에 영향을 미치나요? 다음을 자문해 보세요.

자신이 지원하는 조직의 서비스 안정성 목표에 동의하며 목표 대비 성과를 실시간으로 추적하나요?
최근 서비스 안정성을 바탕으로 조직 활동을 조율하는 피드백 루프를 수립했나요?
안정성 목표를 추구하는 과정에서 조직 내 변화에 영향을 줄 권한이 있나요?
서비스가 현재의 안정성 목표를 달성하지 못할 가능성이 있는 변경사항을 요청받았을 때 거절하거나 목표를 완화하는 협상을 진행할 대행사가 있나요?

각 질문은 이전 질문에 기반합니다. 잘 정의되고 측정된 안정성 목표가 없다면 데이터 기반 피드백 루프를 수립하기란 거의 불가능한 일입니다. 유의미한 목표를 수립하려면 SRE는 목표를 뒷받침할 역량을 갖춰야 합니다. 서비스 안정성이 떨어지는 기간에는 미래 프로덕션 변경의 총 위험을 일시적으로 완화하고 안정성을 회복하는 것으로 엔지니어링 우선순위를 변경해야 합니다.

서비스 안정성 유지와 새롭지만 안정성이 떨어지는 기능의 출시 사이에서 선택을 내려야 할 때 SRE는 '반대'할 수 있어야 합니다. 이러한 반대는 데이터에 기반한 결정이어야 합니다. 오류 예산에 여유가 없을 경우 사용자 불만족을 야기하는 것에 대한 타당한 비즈니스 이유가 있어야 합니다. 물론 타당한 이유가 있는 경우도 있을 것입니다. 이때에는 안정성 요건을 완화한 느슨한 새 SLO 목표를 통해 수용할 수 있습니다.

반대로 컨설팅 SRE는 팀이 안정성 목표를 작성하는 데 도움을 주고 조직 전반에서 목표를 측정하기 위한 공통 모니터링 인프라를 개발할 수도 있습니다. 사실상 안정성 피드백 루프를 관리하고 이를 뒷받침하는 정책 문서를 유지하는 역할을 합니다. 컨설팅 SRE는 여러 팀 및 서비스와 연결되어 있어 폭넓고 유용한 정보를 얻기 때문에 부서 간 안정성 향상을 촉발할 수 있습니다.

제3원칙: SRE는 조기에 포괄적으로 참여합니다

앞서 설명한 바와 같이 SRE는 오늘보다 더 나은 미래를 구축할 수 있어야 합니다. 지원하는 코드와 서비스의 구성을 변경할 수 없다면 문제 발생 시 해결할 수 없습니다. 설계 단계에서 SRE를 조기에 참여시키면 값비싼 사후 수정이 필요한 일반적인 안정성 안티패턴을 방지할 수 있습니다. 또한 SRE가 아키텍처 의사 결정에 영향을 줄 수 있는 역량을 갖추면 하나의 서비스 안정성 향상이 회사 전체에 혜택이 되도록 조직 전반을 통합할 수 있습니다.

팀이 오늘보다 더 나은 미래를 위해 적극적으로 활동하고 있나요? 세부적인 부분부터 폭넓고 개략적인 부분까지 아우르는 질문을 자문해 보세요.

소스 코드나 구성을 보고 수정하는 것처럼 안정성을 개선하기 위해 현재 서비스를 설계하고 있나요?
향후 서비스 반복을 분석하고 설계하는 데 참여하여 안정성/운영성/유지보수성에 대한 관점을 제시하나요?
조직의 전반적인 아키텍처 의사 결정에 영향을 줄 수 있나요?

다른 팀에 자문을 제공하다보면 개별 서비스의 구성이나 코드를 직접 수정하는 일이 우선순위에서 밀리게 마련입니다. 하지만 컨설팅 SRE도 일반적인 측정항목 내보내기나 점진적인 서비스 품질 저하 같은 핵심 안정성 기능을 제공하는 공유 라이브러리나 프레임워크를 유지할 수 있습니다. 여러 팀에 폭넓게 관여하기 때문에 개략적인 아키텍처 자문을 제공하여 조직 전반의 안정성을 개선하는 데 적합합니다.

제4원칙: SRE는 반복되는 모든 작업을 자동화합니다

마지막으로 SRE는 기본적으로 컴퓨터가 인간보다 반복 작업에 더 적합하다고 생각합니다. 사람들은 일상 작업의 자동화를 고려할 때 투자수익을 과소평가하는 경우가 많은데 이는 성공적인 서비스를 대규모로 실행하는 데 따르는 기하급수적인 성장 곡선을 고려하지 않은 결과입니다. 게다가 컴퓨터는 같은 작업을 100번 하더라도 주의력이 떨어지거나 실수를 하지 않으며 사기가 저하되어 그만두는 일이 없습니다. SRE를 교육하거나 채용하는 데 많은 비용과 시간이 들기 때문에 SRE 조직의 성공은 지루한 작업을 컴퓨터가 처리하는지에 크게 좌우됩니다.

업무를 충분히 자동화하고 있나요? 다음을 자문해 보세요.

유기적 성장이나 지원하는 서비스 수의 증가에 비례하여 운영 부하가 증가하지 않도록 자동화 및 기타 도구를 사용하거나 제작하나요?
팀의 반복 작업을 측정하고 시간이 갈수록 반복 작업이 줄어들도록 노력하나요?

생각할 시간

대부분의 블로그 게시물은 행동을 요청하며 마무리됩니다. 이 게시물을 읽은 후 곧바로 변화를 모색하는 대신 시간을 들여 생각해보기를 바랍니다. 이 게시물과 같이 자기 주장이 강한 글에는 위험이 있습니다. 기준선은 성장과 개선이 아닌 구분을 위한 것입니다. 이 게시물은 SRE에 대한 접근을 제어하고 조건에 해당하지 않는 사람을 배제하기 위함이 아닙니다. 이는 무가치한 행동입니다. 하지만 어떤 측면에서 직종이 고안된 이유는 접근을 제어하기 위해서이기도 합니다. 어떤 조직이든 성공에 있어 업무 전문화와 분화는 매우 중요하며 이 때문에 선을 긋는 일을 피하기는 어렵습니다.

스스로 SRE라고 칭하고자 하는 사람이나 SRE라고 규정하는 것에 다른 사람들이 동의하지 않을지도 모른다고 우려하는 사람들에게 이 게시물은 존재론적 부담을 완화하는 역할을 할 수 있을 것입니다.

코끼리를 먹는 방법. Google SRE가 말하는 디지털 혁신

Thu, 29 Apr 2021 00:00:00 +0000

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

이제 급여 소프트웨어부터 특수 머신러닝 시스템에 이르는 모든 것이 클라우드에 '서비스로' 제공되므로 기업 전반의 광범위한 요구사항이 해결되고, 신속한 성장과 확장이 가능해지는 한편 기업은 핵심 역량에 집중할 수 있습니다.

하지만 클라우드로 이전하는 경우 긴장감이 조성되며, 이와 관련된 모든 사람은 필연적으로 부담을 느낍니다. 이러한 혁신으로 인해 '승자'와 '패자'가 생기거나 개인에게 '구식' 또는 '신식'이라는 프레임이 씌워지는 경우에는 특히 더 그렇습니다. 다행스럽게도 클라우드 혁신에서는 이러한 문제가 없습니다.

Google Cloud가 성장함에 따라 이 플랫폼을 빌드하고 지원하는 Google 직원들 역시 성장했으며, 대다수는 고객과 똑같은 상황을 겪었습니다. 이 플랫폼이 조직의 미래를 형성하고, 서로 성장하도록 돕고, 혁신으로 얻을 수 있는 비즈니스 기회를 발굴할 때 얼마나 힘이 되는지 직접 경험했습니다. 우리는 개인적인 경험과 동료들의 경험을 바탕으로 모든 회사에서 디지털 혁신이란 기술적 혁신만큼이나 많은 문화적 혁신을 수반하는 휴먼 스토리라는 결론에 도달했습니다. 이러한 깨달음을 통해 성공적인 혁신 이면에 있는 심층 요소를 알아냈으며, 최근에는 이러한 변화의 특성과 조직에서 클라우드로의 마이그레이션을 추진하기 위해 조치를 취하는 방법이 수록된 가이드를 발표했습니다.

의미 있는 변화를 위해 따라야 할 조직의 여정과 고유한 경로를 구상할 때는 어려운 질문을 던지면 도움이 됩니다. 조직에서 도입해야 하는 이러한 변화의 철학을 뒷받침하는 주요 원칙을 공유하기 위해 이 가이드를 작성했습니다. 클라우드 이전에 대한 실무 가이드에서는 다음과 같은 행동을 촉구합니다.

조직에서 클라우드로 이전하기 위해 협력해야 하는 사람을 파악합니다.
함께 성장할 수 있는, 심리적으로 안전한 문화를 조성합니다.
조직의 명확한 목표를 정의합니다. 이러한 목표를 이루기 위한 측정 가능한 단계를 문서화하고 각 단계 자체가 가치를 제공해야 함을 이해합니다.
기존의 조직 행동을 검토하고 향후 혁신과 관련하여 내리게 될 모든 결정에 적용되고 길잡이가 될 원칙 및 정책을 수립합니다.
새로운 문화에 따라 의사결정 방식을 개선하고 조직 전체에 의미 있는 자율성을 부여합니다.
실무자가 권장사항을 공유하고 일반적인 문제를 해결할 수 있게 해주는 체계를 구축합니다. 이러한 체계를 이용해 동료를 지원합니다.
다른 사람에게 부정적인 영향을 주지 않으면서 빠른 속도로 혁신을 지원하는 가드레일을 클라우드 플랫폼에 구축합니다. 안전한 실험을 지원합니다.
비즈니스 니즈에 가장 적합한 클라우드 플랫폼 유형을 파악하고 진화하는 비즈니스 니즈(예: 인수, 새로운 수익원, 경쟁적 반응)를 예견하여 멀티 클라우드 전략을 결정합니다.
이제 모든 것이 소프트웨어임을 인식하고 기존 IT 인프라 기능에 어떤 의미인지 이해합니다.
기존의 소중한 보안 정책을 재검토하는 것을 두려워하지 않습니다. 목적에 부합하게 만드는 것이 중요합니다.
소프트웨어를 통해 새 정책을 지속적으로 평가하고 적용합니다.
과감하게, 고객 중심의 관점에서 비즈니스 제품의 새로운 운영 방식을 구축합니다.
개발자를 존중합니다.

Google Cloud는 항상 사용자와 사용자의 비즈니스에 적합한 마이그레이션 경로를 구축하도록 지원해 드립니다. 클라우드 이전에 대한 실무 가이드는 무료로 다운로드할 수 있으며 데이터 센터 마이그레이션 솔루션에 대해 자세히 알아보거나 무료 마이그레이션 비용 평가를 신청할 수 있습니다. 모두 마이그레이션에 동참하시기를 바랍니다.

sre.google을 방문하여 SRE 및 업계를 선도하는 서비스 안정성 관련 방침에 대해 자세히 알아보세요.

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

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

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

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

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

설정

앱 배포

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

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

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

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

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

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

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

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

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

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

경고 구성

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

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

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

알림 테스트

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

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

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

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

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

요약

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

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

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

Cloud Operations Sandbox로 SRE를 향한 첫걸음 내딛기

Tue, 23 Feb 2021 00:00:00 +0000

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

Google Cloud는 조직 권장사항에 대한 교육뿐 아니라 클라우드 서비스를 성공적으로 실행하는 데 필요한 도구를 통해 고객사에 사이트 안정성 엔지니어링(SRE) 문화가 정착되도록 노력하고 있습니다. 그 일환으로 프로덕션 문제의 보다 신속한 해결, 출시 속도 향상, 서비스 안정성 개선에 도움이 되는 로깅, 모니터링, 추적, 프로파일링, 디버깅 같은 종합적인 관측 가능성 도구가 지원됩니다.

특히 여러 프로그래밍 언어로 구현되고, 다양한 환경에 배포되며, 운영 비용 및 기타 여러 요인이 다른 복잡한 분산 애플리케이션에서 관측 가능성을 실현하기가 어렵다는 의견이 자주 들려옵니다. 그 결과 워크로드를 Google Cloud로 마이그레이션하고 현대화할 때 관측 가능성이 부차적인 요소에 그치는 경우가 많습니다.

그렇지만 안정적인 프로덕션 시스템을 실행하려면 시스템을 디버깅하고 시스템의 동작에 관한 통계를 확보하는 것이 중요합니다. 고객은 프로덕션 환경을 손상하지 않으면서 Google Cloud가 제공하는 도구를 사용해 관측 가능성을 위한 서비스를 도입하고 SRE 권장사항을 실행할 수 있는 방법을 알고 싶어 합니다. Cloud Operations Sandbox를 사용하면 관측 가능성 여정을 시작하는 실질적인 방법을 배우고 '내 사용 사례에 효과가 있을까?'라는 물음에 답을 얻을 수 있습니다.

Cloud Operations Sandbox는 오픈소스 도구로, Google Cloud 운영 제품군(이전 명칭: Stackdriver)을 사용해 Google의 SRE 관행을 배우고 클라우드 서비스에 적용하는 데 도움이 됩니다. Cloud Operations Sandbox에는 클릭 한 번으로 시작하는 데 필요한 모든 도구가 있습니다.

데모 서비스 - 최신 클라우드 기반 스택의 마이크로서비스 아키텍처를 사용해 제작된 애플리케이션(Online Boutique 마이크로서비스 데모 앱의 수정된 포크)

원클릭 배포 - 다음과 같이 서비스를 Google Cloud에 배포하고 구성하는 자동 스크립트

Service Monitoring 구성
OpenTelemetry를 사용한 추적
Cloud Profiling, Logging, Error Reporting, 디버깅 등

부하 생성기 - 데모 서비스에서 합성 트래픽을 생성하는 구성요소
SRE 레시피 - 프로덕션에서와 마찬가지로 Cloud Operations 도구를 사용해 문제의 근본 원인을 찾을 수 있도록 데모 앱에서 의도적인 오류를 생성하는 사전 빌드된 태스크
Cloud Operations 시작을 도와주는 대화형 둘러보기

시작하기

Cloud Operations Sandbox를 시작하는 방법은 무척 간단합니다.

cloud-ops-sandbox.dev로 이동합니다.
'Google Cloud Shell에서 열기' 버튼을 클릭합니다.

이렇게 하면 새로운 Google Cloud 프로젝트가 생성됩니다. 생성된 프로젝트 내에서 Terraform 스크립트가 Google Kubernetes Engine(GKE) 클러스터를 만들고 여기에 샘플 애플리케이션을 배포합니다. 데모 앱을 구성하는 마이크로서비스에는 로깅, 모니터링, 추적, 디버깅, 프로파일링이 각 마이크로서비스 언어 런타임에 적합하게 사전 설치되어 있습니다. 따라서 데모 앱에 트래픽을 전송하면 클라우드 서비스의 작업을 진단하는 데 유용한 원격 분석이 생성됩니다. 데모 앱에 프로덕션과 유사한 트래픽을 생성하기 위해 자동 스크립트는 데모 앱과 다른 지리적 위치에 합성 부하 생성기를 배포합니다.

11개 커스텀 대시보드(각 마이크로 서비스당 1개)가 생성되어 Google의 SRE 책에 설명된 대로 모니터링의 네 가지 골든 신호가 나타납니다.

또한 업타임 체크, 서비스 모니터링(SLO 및 SLI), 로그 기반 측정항목, 알림 정책 등이 추가되고 자동으로 구성됩니다.

다음과 같이 프로비저닝 스크립트의 끝에서 새로 생성된 프로젝트의 몇 가지 URL을 확인할 수 있습니다.

데모 앱의 OpenTelemetry 계측 덕분에 가능한 Cloud Trace를 통한 마이크로서비스 상호작용 추적 등 전체 Cloud Operations 도구 제품군에 대해 알아보고 학습한 내용을 내 시나리오에 적용하는 방법을 확인하려면 사용자 가이드를 따르세요.

마지막으로 사용을 종료한 후에 샌드박스를 삭제하려면 다음을 실행하세요.

code_block: <ListValue: [StructValue([('code', 'sandboxctl destroy'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f3c4e3f6a00>)])]>

다음 단계

SRE 원칙을 준수하면 클라우드에서 안정성이 높은 애플리케이션을 실행할 수 있는 것으로 입증되었습니다. Cloud Operations Sandbox가 고객 여러분께 SRE 관행을 시작하는 데 필요한 이해와 신뢰를 제공하기를 바랍니다.

시작하려면 cloud-ops-sandbox.dev를 방문하여, 프로젝트 저장소를 살펴보고, 사용자 가이드의 안내를 따르세요.

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가 조정에 도움이 되기를 바랍니다.

애플리케이션 개발 및 제공 가속화

Tue, 20 Oct 2020 10:00:00 +0000

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

소프트웨어의 빠르고 안정적이고 안전한 제공은 모든 디지털 혁신과 애플리케이션 현대화 여정의 핵심입니다. 속도 향상은 뛰어난 비즈니스 성과로 이어집니다. DevOps Research and Assessment(DORA)의 연구 결과에 따르면 소프트웨어 속도, 안정성, 가용성은 수익성, 생산성, 고객 만족도를 포함한 조직의 성과에 직접적으로 기여합니다.

오늘은 개발자, 운영자, 보안 전문가가 더 나은 품질의 소프트웨어를 프로덕션에 보다 빠르게 제공할 수 있도록 애플리케이션 개발 및 제공 플랫폼에 새로 추가된 기능을 소개하겠습니다. 새로 추가된 기능에는 Google에서 수년간 애플리케이션을 규모에 맞춰 빌드하면서 습득한 권장사항이 적용되어 있습니다. 또한 DORA에서 지난 6년 동안 31,000명이 넘는 IT 전문가와 함께 수행한 연구 결과에도 일치합니다.

현재 애플리케이션 개발 및 제공을 가속화하는 데 도움이 되는 새로운 기능과 서비스를 자세히 살펴보겠습니다.

개발자 생산성 향상

먼저 Google의 완전 관리형 컨테이너 플랫폼인 Cloud Run에 대한 지원을 Cloud Code IDE 플러그인에 추가했습니다. 이제 VS Code, IntelliJ와 같은 IDE에서 완전 관리형 서버리스 런타임으로 컨테이너화된 애플리케이션을 직접 작성, 배포, 디버깅할 수 있습니다. 자바, Node.js, Python, Go를 비롯한 다양한 언어로 된 시작 템플릿이 함께 제공되어 손쉽게 시작하고 권장사항을 준수할 수 있습니다. 이를 통해 자동화된 2일 차 작업, 비용 효율적이고 자동으로 확장되는 컨테이너화된 애플리케이션과 같은 Cloud Run의 핵심 이점을 빠르게 살펴볼 수 있습니다.

둘째, 로컬 개발 루프의 일부로 빠른 피드백을 위한 광범위한 지원을 기본 제공합니다. 이를 위해 로컬 머신에서 실행되는 VS Code와 IntellIJ를 위한 새로운 Cloud Run 에뮬레이터가 Cloud Code에 포함되어 변경사항을 신속하게 검증할 수 있으므로 번거롭게 변경사항을 반복하고 재배포할 필요가 없습니다. 로컬에서 변경사항을 확인한 후 IDE 내에서 바로 Cloud Run에 대한 업데이트/수정으로 변경사항을 직접 푸시할 수 있습니다. 클라우드뿐만 아니라 로컬에서 코드를 빠르게 반복하는 기능으로 문제를 조기에 발견하고 실시간 애플리케이션에서 발견된 모든 문제를 해결할 수 있습니다.

셋째, 애플리케이션 빌드를 더욱 빠르게 시작할 수 있도록 Cloud Code에 Google Cloud 빌드팩을 위한 기본 지원 기능을 추가했습니다. 개발자는 해당 코드를 컨테이너화하는 방법을 작업할 것이 아니라 비즈니스 요구사항을 코드로 구현하는 일에 집중해야 합니다. 오늘날 개발자는 Dockerfile을 작성하고 컨테이너 빌드 방법을 정의하는 데 많은 시간을 투입합니다. 이 과정에서 오류가 발생하기 쉬우며 새로운 기능 개발이 아닌 오류 해결에 시간과 기술이 허비됩니다. Google Cloud 빌드팩은 Dockerfile 없이 애플리케이션을 실행하는 데 필요한 모든 종속 항목과 프레임워크를 통합합니다. 이러한 빌드팩은 보안팀이 플랫폼에서 실행되는 항목을 검사할 수 있는 훌륭한 방법을 제공하여 규정 준수와 강화된 보안 상태가 보장됩니다. Cloud 빌드팩은 Google Kubernetes Engine(GKE), Cloud Run, Anthos에서 완벽하게 지원됩니다.

Cloud Code와 Cloud Run의 이러한 개선사항 덕분에 애플리케이션 개발 및 제공이 간소화됩니다. 더 큰 애플리케이션을 빌드하고 점점 복잡해지는 비즈니스 프로세스를 자동화하면서 Google Cloud API, 외부 API, 서버리스 런타임을 통합해야 할 수 있습니다. 이 프로세스를 지원하기 위해 Google은 두 개의 신제품을 선보입니다.

이제 Events for Cloud Run이 베타 버전으로 제공됩니다. Events for Cloud Run을 사용하면 Cloud Run 서비스를 GCP 서비스, 자체 소프트웨어, GitHub를 비롯한 다양한 소스의 이벤트와 연결할 수 있습니다. 또한 커스텀 작업, Google API, 타사 API를 통합하는 데 도움이 되는 워크플로가 베타 버전으로 제공됩니다. 여기에는 단계 간 값 전달, 객체에 대한 JSON 응답 파싱, 배열 반복, 오류 처리, 재시도 등의 고급 기능 지원이 포함됩니다. 워크플로는 서버리스이므로 관리할 인프라가 없으며 제품이 비즈니스 요구에 따라 신속한 확장을 처리합니다. 이벤트와 워크플로를 사용하면 가장 복잡한 비즈니스 요구사항도 자동화할 수 있습니다.

소프트웨어 공급망 보호

소프트웨어 제공이 가속화됨에 따라 '개발 초기부터' 보안 문제가 발생합니다. 위협이 도처에 존재하는 이 시대에 소프트웨어 공급망을 보호하는 것은 매우 중요합니다. 하지만 보안 검토로 인해 속도가 느려지는 것도 바람직하지 않습니다. DORA의 연구는 성과가 가장 뛰어난 '엘리트' 팀이 소프트웨어 개발 프로세스 전반에 걸쳐 보안을 구축하여 어떻게 보안 검토를 며칠 만에 수행할 수 있는지 잘 보여줍니다. 성과가 낮은 팀에서는 동일한 프로세스를 수행하는 데 몇 주가 걸리기도 합니다.

보안 상태를 개선하고 엘리트 팀에서 구현한 관행을 활용하는 데 도움이 되도록 이제 Artifact Registry가 베타 버전으로 제공됩니다. Artifact Registry를 사용하면 Docker 이미지와 함께 maven 및 npm 언어 패키지와 같은 아티팩트를 관리하고 보호할 수 있습니다. 또한 Artifact Registry는 소프트웨어 공급망을 거치는 다양한 유형의 아티팩트에 대해 뛰어난 가시성과 제어 기능을 제공하며 이제 리전별 저장소와 프로젝트당 여러 저장소 생성을 지원합니다. 기업은 VPC-SC를 사용하여 저장소에 대한 액세스를 보안 경계 내의 호출자로 제한하고 고객 관리 암호화 키를 활용하여 저장소의 콘텐츠를 암호화할 수도 있습니다.

기본 제공되는 배포 권장사항

코드를 프로덕션으로 푸시해야 하는 단계에서는 배포 자동화가 성패를 가릅니다. 이는 DORA의 연구에서도 확인됩니다. 엘리트 팀의 69%가 배포를 자동화한 반면 성과가 낮은 팀에서 배포를 자동화한 비율은 17%에 불과합니다. 또한 배포를 자동화하면 변경사항을 푸시하는 부담이 줄고 팀이 중요한 리팩터링, 설계, 문서 작업에 집중할 수 있습니다.

이제 Cloud Run은 배포를 보다 쉽게 자동화할 수 있도록 트래픽 분할 및 점진적 출시를 지원합니다. 이전에는 프로덕션의 모든 사용자에게 변경사항이 푸시되었지만 이제는 소수의 사용자로부터 피드백을 수집합니다. 그러면 문제가 있는 코드 변경의 '영향 범위'를 제한하고 필요한 경우 롤백을 수행할 수 있습니다. Google 내부에서도 이와 유사한 프로세스에 따라 변경사항을 google.com, Gmail, 기타 여러 서비스에 적용합니다.

배포 자동화를 더욱 촉진하기 위해 Google은 직접 Cloud Run 사용자 인터페이스에서 지속적 배포를 손쉽게 설정할 수 있도록 했습니다. git 저장소를 연결하고 변경사항을 감시할 분기를 지정하기만 하면 새 변경사항이 푸시될 때 코드가 Cloud Run에 자동으로 배포됩니다.

서버리스 서비스에 대한 엔터프라이즈 추가 사항

최근 Google은 서버리스 서비스가 VPC 네트워크의 리소스에 액세스할 수 있도록 해주는 서버리스 VPC 액세스를 발표했습니다. 이제 기업이 공유 VPC 네트워크와 VPN 또는 Cloud Interconnect로 연결된 모든 온프렘 리소스에 서버리스 서비스를 연결할 수 있도록 공유 VPC가 지원됩니다.

향상된 소프트웨어를 더 빠르게 제공

이번 출시의 목표는 애플리케이션 개발을 구현하는 데 필요한 속도, 보안, 안정성을 제공하고 엘리트 DevOps팀에서 이용하는 권장사항을 전달하는 것입니다. 여기에서 이러한 새 기능 동작을 모두 확인할 수 있습니다.

권장사항도 Google Cloud App Modernization Program(CAMP)의 일부로 포함했습니다. 이러한 새 기능과 함께 CAMP에 대해 자세히 알아보려면 다음과 같은 Next OnAir 세션에 참여하세요.

DevOps 및 SRE

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

취약점 배경

CVE-2025-55182 완화 조치

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

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

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

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

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

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

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

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

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

Preparing Google Cloud deployments for Docker Hub pull request limits

Personalized Service Health 소개: 이슈 대응 커뮤니케이션 향상

Personalized Service Health를 사용해야 하는 이유

이벤트를 발견하는 방식을 선택하는 알림 구성

기존 이슈 관리 워크플로와 통합

내역과 보고서 만들기 및 과거 중단에서 배우기

통합하여 시간이 갈수록 더욱 커지는 이점 누리기

고객 및 파트너의 사례

지금 시작하기

속도와 안정성 사이 균형을 이룬 DevOps Awards 수상자 Kakao Mobility

목표

속도와 안정성 개선

고객 중심의 설계

DevOps팀, IT 운영팀, 플랫폼 엔지니어, SRE팀이 Google Cloud Next에 참석해야 하는 5가지 이유

1. 운영을 위한 생성형 AI의 잠재력 발견하기

2. 플랫폼 엔지니어링 채택

3. 최신 GKE 혁신에 대해 알아보기

4. 동료들에게 영감을 얻기

5. 네트워킹과 커뮤니티 구축

AI 기반 공동작업 도구 소개: Duet AI for Google Cloud

Duet AI for Google Cloud 소개

Duet AI for Google Cloud에서 새롭게 제공되는 기능

맞춤설정 가능한 모니터링 대시보드로 시스템 관측 가능성을 향상시키는 Cloud Storage

니즈에 따른 고도의 맞춤설정

즉시 사용 가능한 운영 측정항목

차트

로그 패널

지금 미리보기로 시작하기

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

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

분산된 개발자 생산성 향상

소프트웨어 공급망 보호

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

2022년에 다가올 새로운 변화

Lowe’s가 Google SRE 관행으로 고객 수요를 충족하는 방법

Lowe’s의 SRE 부트스트랩 수행

향후 계획

목표에 도달했나요? SRE팀의 성숙도 평가에 대한 고찰

목표에 도달했나요?

주요 SRE 지표

제1원칙: SRE는 현재와 미래의 이슈를 완화합니다

제2원칙: SRE는 적극적으로 서비스 안정성을 관리합니다

제3원칙: SRE는 조기에 포괄적으로 참여합니다

제4원칙: SRE는 반복되는 모든 작업을 자동화합니다

생각할 시간

코끼리를 먹는 방법. Google SRE가 말하는 디지털 혁신

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

설정

알림 테스트

요약

Cloud Operations Sandbox로 SRE를 향한 첫걸음 내딛기

시작하기

다음 단계

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

샘플 워크플로

Google Cloud의 Workflow 제품

Workflows 사용 사례

Workflows 심층 탐구

지금 Workflows 시작하기

애플리케이션 개발 및 제공 가속화

개발자 생산성 향상

소프트웨어 공급망 보호

기본 제공되는 배포 권장사항

서버리스 서비스에 대한 엔터프라이즈 추가 사항

향상된 소프트웨어를 더 빠르게 제공