Google Cloud 아키텍처 프레임워크

Last reviewed 2023-11-09 UTC

이 페이지를 인쇄하거나 브라우저의 인쇄 기능을 사용하고 PDF로 저장 옵션을 선택하여 페이지를 PDF 형식으로 저장할 수 있습니다. 이 페이지의 표준 버전은 아키텍처 프레임워크로 돌아갑니다.

Google Cloud 아키텍처 프레임워크는 설계자, 개발자, 관리자, 기타 클라우드 실무자가 안전하고 효율적이며 복원력이 우수하고 성능이 탁월하며 비용 효율적인 클라우드 토폴로지를 설계하고 운영하는 데 도움이 되는 권장사항을 제공하고 설명합니다. Google Cloud 아키텍처 프레임워크는 제대로 설계된 프레임워크 버전입니다.

여러 부서의 Google 전문가 팀이 아키텍처 프레임워크를 구성하는 설계 권장사항을 검증합니다. 이 팀은 Google Cloud의 확장 기능, 업계 권장사항, 커뮤니티 지식, 개발자의 의견을 반영하기 위해 아키텍처 프레임워크를 선별합니다. 주요 변경사항에 대한 요약은 새로운 기능을 참조하세요.

아키텍처 프레임워크의 설계 안내는 클라우드용으로 빌드된 애플리케이션과 온프레미스에서 Google Cloud로 마이그레이션된 워크로드, 하이브리드 클라우드 배포, 멀티 클라우드 환경에 적용됩니다.

Google Cloud 아키텍처 프레임워크는 다음 다이어그램에 표시된 것처럼 6개 카테고리(원칙이라고도 함)로 구성됩니다.

시스템 설계

이 카테고리는 Google Cloud 아키텍처 프레임워크의 기초입니다. 클라우드 시스템 요구사항을 충족하는 데 필요한 아키텍처, 구성요소, 모듈, 인터페이스, 데이터를 정의하고 시스템 설계를 지원하는 Google Cloud 제품 및 기능에 대해 알아봅니다.

운영 우수성

클라우드 워크로드를 효율적으로 배포, 운영, 모니터링, 관리합니다.

보안, 개인 정보 보호, 규정 준수

클라우드에서 데이터 및 워크로드의 보안을 극대화하고, 개인 정보를 보호하며, 규제 요구사항 및 표준에 부합하도록 만듭니다.

안정성

클라우드에서 복원력이 우수하고 가용성이 높은 워크로드를 설계하고 운영합니다.

비용 최적화

Google Cloud에 대한 투자 가치를 극대화합니다.

성능 최적화

최적의 성능을 위해 클라우드 리소스를 설계하고 조정합니다.

Google Cloud 제품 요약과 제품 간의 상호 관계를 보려면 네 단어 이하로 요약된 Google Cloud 제품, 기능, 서비스를 참조하세요.

Google Cloud 아키텍처 프레임워크: 시스템 설계

시스템 설계는 Google Cloud 아키텍처 프레임워크의 기능 카테고리입니다. 이 카테고리에서는 설계 권장사항을 제공하고 시스템 요구사항 충족을 위해 클라우드 플랫폼에서 아키텍처, 구성요소, 모듈, 인터페이스, 데이터를 정의하는 데 도움이 되는 권장사항 및 원칙에 대해 설명합니다. 또한 시스템 설계를 지원하는 Google Cloud 제품과 기능을 알아봅니다.

시스템 설계 카테고리의 문서에서는 기본 시스템 설계 원칙에 익숙하다고 가정합니다. 이 문서에서는 사용자가 클라우드 개념과 Google Cloud 제품에 익숙하다고 가정하지 않습니다.

복잡한 클라우드 마이그레이션 및 배포 시나리오의 경우에는 Google Cloud 컨설팅 서비스를 이용하는 것이 좋습니다. 저희 컨설턴트는 클라우드 전환의 성공적인 수행을 돕기 위해 권장사항 및 가이드 원칙에 대한 전문 지식을 제공합니다. 또한 Google Cloud에는 대규모 글로벌 시스템 통합업체부터 머신러닝과 같은 특정 분야에 대한 심층적인 전문성을 갖춘 파트너에 이르기까지 강력한 파트너 생태계가 있습니다. Google Cloud 파트너와 협력하여 디지털 전환을 가속화하고 비즈니스 성과를 개선하는 것이 좋습니다.

참고: 프로덕션 환경을 변경하기 전에 샌드박스 환경에서 새로운 기능이나 디자인을 실험하는 것이 좋습니다.

아키텍처 프레임워크의 시스템 설계 카테고리에서 다음을 수행하는 방법을 알아봅니다.

• 시스템 설계의 핵심 원칙 적용
• 비즈니스 애플리케이션을 지원하는 지역적 리전 선택
• 클라우드 리소스 관리
• 컴퓨팅 선택 및 관리
• 네트워크 인프라 설계
• 스토리지 전략 선택 및 구현
• 데이터베이스 최적화
• 데이터 분석
• 머신러닝 구현
• 지속 가능성을 위해 클라우드 워크로드 설계

시스템 설계의 핵심 원칙

Google Cloud 아키텍처 프레임워크의 이 문서에서는 시스템 설계의 핵심 원칙을 설명합니다. 강력한 시스템 설계는 안전하고 안정적이며 확장 가능하고 독립적입니다. 시스템을 중단하지 않고도 반복적이고 가역적인 변경을 수행하고 잠재적인 위험을 최소화하며 운영 효율성을 개선할 수 있습니다. 강력한 시스템 설계를 달성하기 위해서는 다음 4개의 핵심 원칙을 따르는 것이 좋습니다.

모든 것 문서화

워크로드를 클라우드로 이동하거나 애플리케이션을 빌드하기 시작할 때 성공의 가장 큰 장애물은 시스템에 대한 문서화 부족입니다. 문서는 현재 배포의 아키텍처를 올바르게 시각화하는 데 특히 중요합니다.

클라우드 아키텍처를 적절하게 문서화함으로써 공통된 언어 및 표준을 수립하고 여러 부서팀이 효과적으로 소통하고 협업할 수 있습니다. 또한 이후 설계 결정 요소를 식별하고 안내하는 데 필요한 정보를 제공합니다. 설계 결정을 위한 컨텍스트를 제공하기 위해 사용 사례를 염두에 두고 문서를 기록해야 합니다.

시간이 지남에 따라 설계 결정도 진화 및 변화할 것입니다. 변경 내역은 팀이 이니셔티브를 조정하고 중복을 방지하고 시간 경과에 따른 성능 변화를 효과적으로 측정하는 데 필요한 컨텍스트를 제공합니다. 변경 로그는 현재 시스템 설계, 전략, 기록에 익숙하지 않은 새로운 클라우드 설계자를 온보딩할 때 특히 유용합니다.

설계 간소화 및 완전 관리형 서비스 사용

단순성은 시스템 설계에 매우 중요합니다. 아키텍처가 너무 복잡해서 이해하기 어려우면 시간이 지남에 따라 설계를 구현하고 관리하는 것이 어려워집니다. 가능한 경우 완전 관리형 서비스를 사용해서 기준 시스템 관리 및 유지보수와 관련된 위험, 시간, 노력을 최소화합니다.

프로덕션에서 이미 워크로드를 실행 중이면 관리형 서비스로 테스트하여 운영 복잡성을 줄이는 데 도움이 될지 확인합니다. 새 워크로드를 개발하려면 단순하게 시작해서 실행 가능한 최소 제품(MVP)을 구축하고 오버엔지니어링을 방지합니다. 시간이 지남에 따라 예외적인 사용 사례를 식별하고, 작업을 반복하며, 시스템을 점진적으로 개선할 수 있습니다.

아키텍처 분리

분리는 애플리케이션 및 서비스 구성요소를 독립적으로 작동할 수 있는 더 작은 구성요소로 분리하는 데 사용되는 기술입니다. 예를 들어 모놀로식 애플리케이션 스택을 개별 서비스 구성요소로 분할할 수 있습니다. 분리된 아키텍처에서 애플리케이션은 여러 종속 항목에 관계없이 해당 기능을 독립적으로 실행할 수 있습니다.

분리된 아키텍처는 다음을 수행할 수 있는 유연성을 제공합니다.

• 독립적인 업그레이드를 적용합니다.
• 특정 보안 제어를 적용합니다.
• 각 하위 시스템의 안정성 목표를 설정합니다.
• 상태를 모니터링합니다.
• 성능 및 비용 매개변수를 세부적으로 제어합니다.

설계 단계 초기에 분리를 시작하거나 확장에 따라 시스템 업그레이드의 일부에 통합할 수 있습니다.

스테이트리스(Stateless) 아키텍처 사용

스테이트리스(Stateless) 아키텍처는 애플리케이션의 안정성과 확장성을 모두 향상시킬 수 있습니다.

스테이트풀(Stateful) 애플리케이션은 로컬로 캐시된 데이터와 같은 태스크 수행을 위해 여러 종속 항목을 사용합니다. 스테이트풀(Stateful) 애플리케이션은 진행 상황을 캡처하고 정상적으로 재시작하기 위한 추가 메커니즘이 필요한 경우가 많습니다. 스테이트리스(Stateless) 애플리케이션은 공유 스토리지 또는 캐시된 서비스를 사용하여 상당한 로컬 종속 항목 없이 태스크를 수행할 수 있습니다. 스테이트리스(Stateless) 아키텍처를 통해 최소한의 부팅 종속 항목으로 애플리케이션을 빠르게 확장할 수 있습니다. 애플리케이션은 하드 재시작을 견디고, 다운타임을 줄이고, 최종 사용자에게 더 나은 성능을 제공할 수 있습니다.

시스템 설계 카테고리에서는 애플리케이션을 스테이트리스(Stateless)로 만들거나 클라우드 기반 기능을 활용하여 스테이트풀(Stateful) 애플리케이션에 대한 머신 상태 캡처 기능을 개선하기 위한 권장사항을 설명합니다.

다음 단계

• 비즈니스 애플리케이션을 지원하는 지역적 리전 선택
• 클라우드 리소스 관리
• 컴퓨팅 선택 및 관리
• 네트워크 인프라 설계
• 스토리지 전략 선택 및 구현
• 데이터베이스 최적화
• 데이터 분석
• 머신러닝 구현
• 지속 가능성을 위해 클라우드 워크로드 설계

Google Cloud 배포 원형 선택

Google Cloud 아키텍처 프레임워크의 이 문서에서는 6개의 배포 원형¹(영역, 리전, 멀티 리전, 전역, 하이브리드, 멀티 클라우드)에 대해 설명하며, 이러한 배포 원형은 가용성, 비용, 성능, 운영 효율성에 대한 요구사항에 따라 클라우드 워크로드의 아키텍처를 빌드하는 데 사용할 수 있습니다.

배포 원형이란 무엇인가요?

배포 원형은 비즈니스 및 기술 요구사항을 충족시켜 주는 애플리케이션에 한정된 배포 아키텍처를 빌드하기 위한 기초로 사용할 수 있으며, 공급자마다 독립적인 추상적인 모델입니다. 각 배포 원형은 애플리케이션이 실행할 수 있는 장애 도메인의 조합을 지정합니다. 이러한 장애 도메인은 하나 이상의 Google Cloud 영역 또는 리전일 수 있으며, 다른 클라우드 제공업체의 온프레미스 데이터 센터 또는 장애 도메인을 포함하도록 확장될 수 있습니다.

다음 다이어그램은 Google Cloud에 배포된 6개의 애플리케이션을 보여줍니다. 각 애플리케이션은 특정 요구사항을 충족시켜 주는 배포 원형을 사용합니다.

위 다이어그램에 표시된 것처럼 하이브리드 또는 멀티 클라우드 배포 원형을 사용하는 아키텍처에서 클라우드 토폴로지는 기본 원형인 영역, 리전, 멀티 리전, 전역 중 하나를 기반으로 합니다. 이러한 의미에서 하이브리드와 멀티 클라우드 배포 원형은 기본 원형 중 하나를 포함하는 복합 배포 원형으로 고려될 수 있습니다.

참고: 배포 원형은 위치 범위와 다릅니다. Google Cloud 리소스의 위치 범위는 해당 리소스의 가용성 경계를 정의합니다. 예를 들어 Compute Engine VM의 위치 범위는 영역별로 지정됩니다. 즉, VM이 프로비저닝되는 Google Cloud 영역에 중단이 발생하면 해당 VM의 가용성이 영향을 받습니다. 그러나 여러 영역에 걸쳐서 VM을 분산할 때는 리전별 배포 원형을 기반으로 하는 고가용성 아키텍처를 빌드할 수 있습니다.

배포 원형을 선택하면 사용할 Google Cloud 제품과 기능과 관련해서 이후의 의사결정을 단순화하는 데 도움이 됩니다. 예를 들어 가용성이 높은 컨테이너화된 애플리케이션의 경우에는 리전별 배포 원형을 선택할 때 리전별 Google Kubernetes Engine(GKE) 클러스터가 영역별 GKE 클러스터보다 적합합니다.

애플리케이션의 배포 원형을 선택할 때는 가용성, 비용, 운영 복잡성 등의 요소들 간의 장단점을 고려해야 합니다. 예를 들어 애플리케이션이 여러 국가의 사용자를 지원하고 고가용성이 필요한 경우에는 멀티 리전 배포 원형을 선택할 수 있습니다. 하지만 단일 지리적 리전 내의 직원들이 사용하는 내부 애플리케이션의 경우에는 가용성보다 비용을 우선시하여 리전 배포 원형을 선택할 수 있습니다.

배포 원형 개요

다음 탭에서는 배포 원형에 대한 정의와 각 배포 원형의 사용 사례 및 설계 고려 사항을 요약해서 보여줍니다.

영역

다음 다이어그램에 표시된 것처럼 애플리케이션이 단일 Google Cloud 영역 내에서 실행됩니다.

사용 사례	개발 및 테스트 환경 고가용성이 필요하지 않은 애플리케이션 애플리케이션 구성요소 간에 지연 시간이 짧은 네트워킹 상용 워크로드 마이그레이션 라이선스가 제한적인 소프트웨어를 사용하는 애플리케이션
설계 고려사항	영역 중단 중 다운타임 비즈니스 연속성을 위해서는 동일 리전의 또 다른 영역에 애플리케이션의 수동 복제본을 프로비저닝할 수 있습니다. 영역 중단이 발생하면 수동 복제본을 사용해서 애플리케이션을 프로덕션에 복원할 수 있습니다.
추가 정보	다음 섹션을 참조하세요. 영역 배포 원형 모든 배포 원형에 대한 비교 분석

리전

다음 다이어그램에 표시된 것처럼 단일 Google Cloud 리전 내에 있는 둘 이상의 영역에서 애플리케이션이 독립적으로 실행됩니다.

사용 사례	하나의 지리적 영역 내에서 사용자를 지원하는 고가용성 애플리케이션 데이터 상주 및 데이터 주권 요구사항 준수
설계 고려사항	리전 중단 중 다운타임 비즈니스 연속성을 위해서는 애플리케이션 및 데이터를 다른 리전에 백업할 수 있습니다. 리전 중단이 발생하면 다른 리전의 백업을 사용해서 애플리케이션을 프로덕션에 복원할 수 있습니다. 중복 리소스 프로비저닝 및 관리에 필요한 비용과 노력
추가 정보	다음 섹션을 참조하세요. 리전 배포 원형 모든 배포 원형에 대한 비교 분석

멀티 리전

둘 이상의 Google Cloud 리전에 걸쳐 있는 여러 영역에서 애플리케이션이 독립적으로 실행됩니다. DNS 라우팅 정책을 사용해서 들어오는 트래픽을 리전 부하 분산기로 라우팅할 수 있습니다. 그런 후에는 다음 다이어그램에 표시된 것처럼 리전 부하 분산기가 애플리케이션의 영역 복제본으로 트래픽을 분산합니다.

사용 사례	사용자가 지리적으로 분산된 고가용성 애플리케이션 최종 사용자의 지연 시간이 낮은 환경이 요구되는 애플리케이션 지오펜싱 DNS 라우팅 정책을 사용하여 데이터 상주 및 주권 요구사항 준수
설계 고려사항	리전 간 데이터 전송 및 데이터 복제 비용 운영 복잡성
추가 정보	다음 섹션을 참조하세요. 멀티 리전 배포 원형 모든 배포 원형에 대한 비교 분석

전역

위치를 구분하지 않는 전역 분산 스택 또는 리전별로 격리된 스택의 전 세계 Google Cloud 리전에 걸쳐서 애플리케이션이 실행됩니다. 전역 애니캐스트 부하 분산기는 사용자에게 가장 가까운 리전으로 트래픽을 분산합니다. 데이터베이스, 캐시, 객체 저장소와 같은 애플리케이션 스택의 다른 구성요소도 전역적일 수 있습니다.

다음 다이어그램은 전역 배포 원형의 전역적으로 분산된 변형을 보여줍니다. 전역 애니캐스트 부하 분산기는 여러 리전에 걸쳐서 분산되었고 전역적으로 복제된 데이터베이스를 사용하는 애플리케이션 스택으로 요청을 전달합니다.

다음 다이어그램은 리젼별로 격리된 애플리케이션 스택이 포함된 전역 배포 원형의 변형을 보여줍니다. 전역 애니캐스트 부하 분산기는 리전 중 하나에 있는 애플리케이션 스택으로 요청을 전달합니다. 모든 애플리케이션 스택은 전역적으로 복제된 단일 데이터베이스를 사용합니다.

사용 사례	전역적으로 분산된 사용자를 지원하는 고가용성 애플리케이션 리전별 리소스의 여러 인스턴스 대신 전역적 리소스를 사용하여 얻을 수 있는 비용 최적화 및 운영 간소화 기회
설계 고려사항	리전 간 데이터 전송 및 데이터 복제 비용
추가 정보	다음 섹션을 참조하세요. 전역 배포 원형 모든 배포 원형에 대한 비교 분석

하이브리드

다음 다이어그램에 표시된 것처럼 애플리케이션의 특정 부분은 Google Cloud에 배포되고 다른 부분은 온프레미스로 실행됩니다. Google Cloud의 토폴로지는 영역, 리전, 멀티 리전, 전역 배포 원형을 사용할 수 있습니다.

사용 사례	온프레미스 워크로드에 대한 재해 복구(DR) 사이트 클라우드 애플리케이션을 위한 온프레미스 개발 기존 애플리케이션의 점진적인 클라우드 마이그레이션 클라우드 기능으로 온프레미스 애플리케이션 향상
설계 고려사항	설정 노력과 운영 복잡성 중복 리소스 비용
추가 정보	다음 섹션을 참조하세요. 하이브리드 배포 원형 모든 배포 원형에 대한 비교 분석

멀티 클라우드

다음 다이어그램에 표시된 것처럼 애플리케이션의 일부는 Google Cloud에 배포되고 다른 부분은 다른 클라우드 플랫폼에 배포됩니다. 각 클라우드 플랫폼의 토폴로지는 영역, 리전, 멀티 리전, 전역 배포 원형을 사용할 수 있습니다.

사용 사례	Google Cloud를 기본 사이트로 사용하고 다른 클라우드를 DR 사이트로 사용 고급 Google Cloud 기능으로 애플리케이션 향상
설계 고려사항	설정 노력과 운영 복잡성 중복 리소스 비용과 클라우드 전체 네트워크 트래픽
추가 정보	다음 섹션을 참조하세요. 멀티 클라우드 배포 원형 모든 배포 원형에 대한 비교 분석

지리적 영역 및 리전 선택

Google Cloud 아키텍처 프레임워크의 이 문서에서는 지리적 요구사항에 따라 시스템을 배포하기 위한 권장사항을 제공합니다. 규정 준수 지원, 비용 최적화, 부하 분산 구현을 위해 가용성 및 근접성에 따라 최적의 지리적 영역 및 리전을 선택하는 방법을 알아봅니다.

비즈니스 애플리케이션의 한 리전 또는 여러 리전을 선택할 때 사용자는 서비스 가용성, 최종 사용자 지연 시간, 애플리케이션 지연 시간, 비용, 규제 또는 지속 가능성 요구사항을 포함한 기준을 고려합니다. 비즈니스 우선순위와 정책을 지원하려면 이러한 요구사항의 균형을 맞추고 최상의 장단점을 확인해야 합니다. 예를 들어 가장 준수한 리전이 가장 비용 효율적인 리전이 아니거나 가장 낮은 탄소 발자국을 갖지 않을 수 있습니다.

여러 리전에 배포

리전은 여러 영역으로 구성되는 독립적인 지리적 위치입니다. 영역은 리전 내 Google Cloud 리소스의 배포 위치입니다. 각 영역은 리전 내의 단일 장애 도메인을 나타냅니다.

예상되는 다운타임(유지보수 포함)으로부터 보호하고 이슈와 같은 예상치 못한 다운타임으로부터 보호하기 위해서는 가용성이 높은 내결함성 애플리케이션을 배포하고 하나 이상의 리전에 있는 여러 영역에 애플리케이션을 한 번에 배포하는 것이 좋습니다. 자세한 내용은 위치 및 리전, 애플리케이션 배포 고려사항, Compute Engine 리전 선택 권장사항을 참조하세요.

멀티 영역 배포는 비용 또는 기타 고려 사항으로 인해 멀티 리전 배포가 제한된 경우 탄력성을 제공할 수 있습니다. 이 접근 방식은 영역 또는 리전 서비스 중단을 방지하고 재해 복구 및 비즈니스 연속성 문제를 해결하는 데 특히 유용합니다. 자세한 내용은 확장 및 고가용성 설계를 참조하세요.

지리적 근접성에 따른 리전 선택

지연 시간은 사용자 경험과 외부 사용자 대상 서비스 제공 관련 비용에 영향을 줍니다. 외부 사용자에게 트래픽을 제공할 때 지연 시간을 최소화하려면 사용자와 지리적으로 가깝고 서비스가 규정을 준수하는 방식으로 실행되는 리전 또는 리전 집합을 선택합니다. 자세한 내용은 Cloud 위치 및 규정 준수 리소스 센터를 참조하세요.

사용 가능한 서비스에 따른 리전 선택

비즈니스에 필요한 서비스의 사용 가능 여부에 따라 리전을 선택합니다. 대부분의 서비스는 모든 리전에서 사용할 수 있습니다. 일부 엔터프라이즈별 서비스는 초기 출시 버전이 있는 리전의 하위 집합에서 사용할 수 있습니다. 리전 선택을 확인하려면 Cloud 위치를 참조하세요.

규정 준수 지원을 위한 리전 선택

개인 정보 보호법(GDPR) 또는 데이터 상주와 같이 특정 지역을 사용해야 하는 지리적 규정 또는 규정 준수 규제를 준수하려면 특정 리전 또는 리전 집합을 선택하세요. 보안 시스템 설계에 대해 자세히 알아보려면 규정 준수 제품 및 Google Cloud 유럽 고객을 위한 데이터 상주, 운영 투명성, 개인정보 보호를 참조하세요.

주요 리소스의 가격 비교

리전마다 동일한 서비스에 대한 비용이 다릅니다. 비용 효율적인 리전을 식별하려면 사용하려는 주요 리소스의 가격을 비교하세요. 비용 고려 사항은 백업 요구사항과 컴퓨팅, 네트워킹, 데이터 스토리지 등의 리소스에 따라 다릅니다. 자세한 내용은 비용 최적화 카테고리를 참조하세요.

Cloud Load Balancing을 사용하여 전 세계 사용자에게 서비스 제공

전 세계 사용자에게 서비스를 제공할 때 사용자 경험을 개선하려면 Cloud Load Balancing을 사용하여 애플리케이션으로 라우팅되는 단일 IP 주소를 제공하세요. 안정적인 시스템 설계에 대해 자세히 알아보려면 Google Cloud 아키텍처 프레임워크: 안정성을 참고하세요.

Google Cloud 리전 선택 도구를 사용하여 지속 가능성 지원

Google은 2007년부터 탄소 중립을 유지해 왔으며 2030년까지 무탄소 에너지로 운영하기 위해 노력하고 있습니다. 탄소 발자국을 기준으로 리전을 선택하려면 Google Cloud 리전 선택 도구를 사용하세요. 지속 가능성을 위한 설계에 대해 자세히 알아보려면 클라우드 지속가능성을 참조하세요.

다음 단계

Resource Manager, Google Cloud 리소스 계층, 조직 정책 서비스를 사용하여 클라우드 리소스를 관리하는 방법에 대해 알아보기

아키텍처 프레임워크에서 안정성, 운영 우수성, 보안, 개인 정보 보호, 규정 준수 등의 다른 카테고리 살펴보기

클라우드 리소스 관리

Google Cloud 아키텍처 프레임워크의 이 문서에서는 Google Cloud에서 리소스를 구성 및 관리하기 위한 권장사항을 제공합니다.

리소스 계층 구조

Google Cloud 리소스는 조직, 폴더, 프로젝트에 계층적으로 배열됩니다. 이 계층 구조를 통해 액세스 제어, 구성 설정 및 정책과 같이 리소스의 공통된 요소를 관리할 수 있습니다. Cloud 리소스의 계층 구조를 설계하기 위한 권장사항은 Google Cloud 시작 영역의 리소스 계층 구조 결정을 참조하세요.

리소스 라벨 및 태그

이 섹션에서는 라벨과 태그를 사용하여 Google Cloud 리소스를 구성하기 위한 권장사항을 제공합니다.

단순한 폴더 구조 사용

폴더를 사용하여 프로젝트와 하위 폴더를 조합해서 그룹화할 수 있습니다. 단순한 폴더 구조를 만들어 Google Cloud 리소스를 구성하세요. 비즈니스 요구사항을 지원하도록 리소스 계층 구조를 정의하는 데 필요한 만큼 수준을 더 추가할 수 있습니다. 폴더 구조는 유연하고 확장 가능합니다. 자세한 내용은 폴더 만들기 및 관리를 참조하세요.

폴더와 프로젝트를 사용하여 데이터 거버넌스 정책 반영

조직 내 데이터 거버넌스 정책을 반영하도록 폴더, 하위 폴더, 프로젝트를 사용하여 리소스를 서로 분리하세요. 예를 들어 폴더와 프로젝트를 조합해서 사용하여 재무, 인적 자원, 엔지니어링을 분리할 수 있습니다.

프로젝트를 사용하여 동일한 신뢰 경계를 공유하는 리소스를 그룹화합니다. 예를 들어 같은 제품 또는 마이크로서비스의 리소스는 동일한 프로젝트에 속할 수 있습니다. 자세한 내용은 Google Cloud 시작 영역의 리소스 계층 구조 결정을 참조하세요.

프로젝트 초기에 태그 및 라벨 사용

Google Cloud 제품을 사용하기 시작할 때 나중을 위해 라벨과 태그를 사용하세요. 나중에 라벨과 태그를 추가하려면 오류가 발생하기 쉬우며 완료하기 어려운 수동 작업이 필요할 수 있습니다.

태그를 사용하면 리소스에 특정 태그가 있는지 여부에 따라 조건부로 정책을 허용하거나 거부할 수 있습니다. 라벨은 Google Cloud 인스턴스를 체계화하는 데 도움이 되는 키-값 쌍입니다. 라벨에 대한 자세한 내용은 라벨 요구사항, 라벨을 지원하는 서비스 목록, 라벨 형식을 참조하세요.

Resource Manager는 리소스를 관리하고, 비용을 할당 및 보고하고, 세분화된 액세스 제어를 위해 다양한 리소스에 정책을 할당하는 데 도움이 되는 라벨과 태그를 제공합니다. 예를 들어 라벨과 태그를 사용하여 세분화된 액세스 및 관리 원칙을 다양한 테넌트 리소스와 서비스에 적용할 수 있습니다. VM 라벨과 네트워크 태그에 대한 자세한 내용은 VM 라벨과 네트워크 태그 사이의 관계를 참조하세요.

다음을 포함하여 여러 목적으로 라벨을 사용할 수 있습니다.

• 리소스 결제 관리: 결제 시스템에서 라벨을 사용할 수 있으므로 비용을 라벨별로 구분할 수 있습니다. 예를 들어 다른 비용 센터 또는 예산에 라벨을 지정할 수 있습니다.
• 유사한 특성 또는 관계별로 리소스 그룹화: 라벨을 사용하여 여러 애플리케이션 수명 주기 단계 또는 환경을 구분할 수 있습니다. 예를 들어 프로덕션, 개발, 테스트 환경에 라벨을 지정할 수 있습니다.

비용 및 결제 보고를 지원하는 라벨 할당

통합 보고 구조 외부의 속성(예: 프로젝트별 또는 제품별 유형)을 기반으로 세분화된 비용 및 결제 보고를 지원하려면 리소스에 라벨을 할당합니다. 라벨은 비용 센터, 부서, 특정 프로젝트, 내부 재청구 메커니즘에 소비를 할당할 수 있습니다. 자세한 내용은 비용 최적화 카테고리를 참조하세요.

라벨을 대량으로 만들지 않기

라벨을 대량으로 만들지 않습니다. 주로 프로젝트 수준에서 라벨을 만들고 하위 팀 수준에서는 라벨을 만들지 않는 것이 좋습니다. 지나치게 세분화된 라벨을 만들면 분석에 노이즈가 추가될 수 있습니다. 라벨의 일반적인 사용 사례는 라벨의 일반적인 사용 사례를 참조하세요.

라벨에 민감한 정보 추가하지 않기

라벨은 민감한 정보를 처리하도록 고안된 것은 아닙니다. 개인의 이름이나 직책과 같이 개인을 식별할 수 있는 정보를 포함하여 민감한 정보를 라벨에 포함하지 마세요.

프로젝트 이름의 정보를 익명처리

COMPANY_INITIAL_IDENTIFIER-ENVIRONMENT-APP_NAME과 같은 프로젝트 이름 지정 패턴을 따르세요. 자리표시자는 고유하며 회사 또는 애플리케이션 이름을 공개하지 않습니다. 이후에 변경될 수 있는 속성(예: 팀 이름 또는 기술)은 포함하지 마세요.

비즈니스 측정기준 모델링에 태그 적용

태그를 적용하여 조직 구조, 리전, 워크로드 유형, 비용 센터 등의 추가적인 비즈니스 측정기준을 모델링할 수 있습니다. 태그에 대한 자세한 내용은 태그 개요, 태그 상속, 태그 생성 및 관리를 참조하세요. 정책에 태그를 사용하는 방법은 정책 및 태그를 참조하세요. 태그를 사용하여 액세스 제어를 관리하는 방법은 태그 및 액세스 제어를 참조하세요.

조직 정책

이 섹션에서는 클라우드 리소스 계층 구조에서 Google Cloud 리소스에 대한 거버넌스 규칙을 구성하기 위한 권장사항을 제공합니다.

프로젝트 명명 규칙 설정

SYSTEM_NAME-ENVIRONMENT(dev, test, uat, stage, prod)와 같은 표준화된 프로젝트 이름 지정 규칙을 설정합니다.

프로젝트 이름은 30자로 제한됩니다.

COMPANY_TAG-SUB_GROUP/SUBSIDIARY_TAG와 같은 프리픽스를 적용할 수 있지만 회사가 재구성을 수행하면 프로젝트 이름이 오래될 수 있습니다. 식별 가능한 이름을 프로젝트 이름에서 프로젝트 라벨로 이동하는 것을 고려하세요.

프로젝트 생성 자동화

프로덕션 및 대규모 비즈니스를 위한 프로젝트를 만들려면 Deployment Manager 또는 Google Cloud 프로젝트 팩토리 Terraform 모듈과 같은 자동화된 프로세스를 사용하세요. 이러한 도구는 다음을 수행합니다.

• 적절한 권한이 있는 개발, 테스트, 프로덕션 환경 또는 프로젝트를 자동으로 만듭니다.
• 로깅 및 모니터링 구성

Google Cloud 프로젝트 팩토리 Terraform 모듈을 사용하면 Google Cloud 프로젝트 생성을 자동화할 수 있습니다. 대기업에서는 Google Cloud에서 프로젝트를 만들기 전에 프로젝트를 검토하고 승인하는 것이 좋습니다. 이 프로세스를 통해 다음을 확인할 수 있습니다.

• 비용은 기속될 수 있습니다. 자세한 내용은 비용 최적화 카테고리를 참조하세요.
• 데이터 업로드 시 승인이 적용됩니다.
• 규제 또는 규정 준수 요구사항이 충족됩니다.

Google Cloud 프로젝트 및 리소스 생성과 관리를 자동화하면 일관성, 재현성, 테스트 가능성의 이점을 얻게 됩니다. 구성을 코드로 취급하면 소프트웨어 아티팩트와 함께 구성의 수명 주기를 관리하고 버전을 관리할 수 있습니다. 자동화는 일관된 명명 규칙 및 리소스 라벨 지정과 같은 권장사항을 지원할 수 있습니다. 자동화는 요구사항이 진화하는 과정에서 프로젝트 리팩터링을 간소화합니다.

시스템 정기 감사

새 프로젝트에 대한 요청을 감사 및 승인할 수 있도록 하려면 기업의 티켓 시스템 또는 감사를 제공하는 독립형 시스템과 통합하세요.

일관성 있는 프로젝트 구성

조직의 요구사항을 일관되게 충족하도록 프로젝트를 구성합니다. 프로젝트를 설정할 때 다음 항목을 포함하세요.

• 프로젝트 ID 및 명명 규칙
• 결제 계정 연결
• 네트워킹 구성
• 사용 설정된 API 및 서비스
• Compute Engine 액세스 구성
• 로그 내보내기 및 사용 보고서
• 프로젝트 삭제 선취권

워크로드 또는 환경 분리 및 격리

할당량 및 한도는 프로젝트 수준에서 적용됩니다. 할당량과 한도를 관리하려면 워크로드 또는 환경을 프로젝트 수준에서 분리하고 격리합니다. 자세한 내용은 할당량 작업을 참조하세요.

환경 분리는 데이터 분류 요구사항과 다릅니다. 인프라에서 데이터를 분리하는 것은 비용이 많이 들고 구현하기 복잡할 수 있으므로 데이터 민감도 및 규정 준수 요구사항에 따라 데이터 분류를 구현하는 것이 좋습니다.

결제 격리 적용

결제 격리를 적용하여 워크로드 및 환경별로 다양한 결제 계정 및 비용 가시성을 지원합니다. 자세한 내용은 셀프 서비스 Cloud Billing 계정 생성, 수정, 해지 및 프로젝트 결제 사용 설정, 사용 중지, 변경을 참조하세요.

관리 복잡성을 최소화하려면 프로젝트 수준의 중요 환경 또는 여러 프로젝트에 분산된 워크로드에 세분화된 액세스 관리 제어를 사용하세요. 중요한 프로덕션 애플리케이션의 액세스 제어를 선별하면 워크로드의 보안과 효과적인 관리가 보장됩니다.

조직 정책 서비스를 사용하여 리소스 제어

조직 정책 서비스를 사용하면 정책 관리자에게 조직의 클라우드 리소스에 대한 중앙 집중식 프로그래매틱 제어를 제공하여 리소스 계층 구조 전반에 걸친 제약 조건을 구성할 수 있습니다. 자세한 내용은 조직 정책 관리자 추가를 참조하세요.

조직 정책 서비스를 사용하여 규제 정책 준수

규정 준수 요건을 충족하려면 조직 정책 서비스를 사용하여 리소스 공유 및 액세스에 대한 규정 준수 요건을 적용하세요. 예를 들어 외부 사용자와의 공유를 제한하거나 클라우드 리소스를 지리적으로 배포할 위치를 결정할 수 있습니다. 기타 규정 준수 시나리오에는 다음이 포함됩니다.

• 조직의 리소스 사용 방법을 정의하는 제한사항 구성을 중앙에서 제어합니다.
• 개발팀이 규정을 준수할 수 있도록 정책을 정의하고 설정합니다.
• 프로젝트 소유자와 해당 팀에서 시스템을 변경하도록 하면서 규정 준수를 유지하고 규정 준수 규칙 위반에 대한 우려를 최소화합니다.

도메인을 기반으로 리소스 공유 제한

제한된 공유 조직 정책을 사용하면 Google Cloud 리소스가 조직 외부의 ID와 공유되지 않도록 할 수 있습니다. 자세한 내용은 도메인별 ID 제한 및 조직 정책 제약조건을 참조하세요.

서비스 계정 및 키 생성 사용 중지

보안을 강화하려면 Identity and Access Management(IAM) 서비스 계정 및 해당 키의 사용을 제한하세요. 자세한 내용은 서비스 계정 사용 제한을 참조하세요.

새 리소스의 물리적 위치 제한

리소스 위치를 제한하여 새로 만든 리소스의 물리적 위치를 제한합니다. 조직의 리소스를 제어할 수 있는 제약조건 목록을 보려면 조직 정책 서비스 제약조건을 참조하세요.

다음 단계

다음을 포함한 컴퓨팅 선택 및 관리 방법 알아보기

• 컴퓨팅 마이그레이션 접근방식

• 워크로드 설계 및 워크로드 확장

• 작업 관리

• VM 마이그레이션 관리

아키텍처 프레임워크에서 안정성, 운영 우수성, 보안, 개인 정보 보호, 규정 준수 등의 다른 카테고리 살펴보기

컴퓨팅 선택 및 관리

Google Cloud 아키텍처 프레임워크의 이 문서에서는 컴퓨팅 요구사항에 따라 시스템을 배포하기 위한 권장사항을 제공합니다. 컴퓨팅 플랫폼 및 마이그레이션 방법을 선택하고, 워크로드를 설계 및 확장하고, 작업 및 VM 마이그레이션을 관리하는 방법을 알아봅니다.

컴퓨팅은 커스텀 비즈니스 로직 실행 또는 데이터 세트에 대한 복잡한 컴퓨팅 알고리즘 적용 등을 가리키는, 여러 워크로드의 핵심입니다. 대부분의 솔루션은 특정 형태의 컴퓨팅 리소스를 사용하므로 애플리케이션 요구에 맞는 컴퓨팅 리소스를 선택하는 것이 중요합니다.

Google Cloud는 CPU에서 시간을 사용하는 여러 옵션을 제공합니다. 옵션은 CPU 유형, 성능, 사용 요금 청구를 포함한 코드 예약 방법을 기반으로 합니다.

Google Cloud 컴퓨팅 옵션에는 다음이 포함됩니다.

• 라이브 마이그레이션과 같은 클라우드 관련 이점을 제공하는 가상 머신(VM)
• CPU를 공유할 수 있는 클러스터 머신의 컨테이너 적재
• 단일 HTTP 요청 중에 이루어진 작업에 대해 CPU 시간의 사용량이 측정될 수 있는 함수 및 서버리스 접근 방식

컴퓨팅 선택

이 섹션에서는 컴퓨팅 플랫폼을 선택하고 마이그레이션하기 위한 권장사항을 제공합니다.

컴퓨팅 플랫폼 선택

워크로드에 맞는 컴퓨팅 플랫폼을 선택할 때는 워크로드, 수명 주기 자동화 프로세스, 지역화, 보안의 기술 요구사항을 고려하세요.

코드 패키징 및 배포, 분산 및 호출 방법 등 앱과 전체 지원 시스템의 CPU 사용량 특성을 평가합니다. 일부 시나리오는 여러 플랫폼 옵션과 호환될 수 있지만, 포팅 가능한 워크로드는 다양한 컴퓨팅 옵션으로 실행 가능해야 하며 성능이 뛰어나야 합니다.

다음 표에서는 다양한 사용 사례에 권장되는 Google Cloud 컴퓨팅 서비스를 간략하게 설명합니다.

컴퓨팅 플랫폼	사용 사례	권장 제품
서버리스	첫 번째 앱을 배포합니다. 인프라 작업 유지보수보다 데이터 및 처리 로직과 앱 개발에 중점을 둡니다.	Cloud Run: 완전 관리형 서버리스 옵션을 사용하여 비즈니스 로직을 컨테이너에 적용합니다. Cloud Run은 컴퓨팅 집약적이지만 항상 실행되는 것은 아닌 워크로드를 위해 설계되었습니다. 0(트래픽 없음)부터 비용 효율적으로 확장하고 작업 및 서비스의 CPU와 RAM을 정의합니다. 명령어 하나로 배포하면 적절한 양의 리소스가 자동으로 프로비저닝됩니다. Cloud Functions: 부하 분산, 업데이트, 인증 또는 확장과 같은 인프라 문제 없이 코드를 유연한 비즈니스 로직으로 분리합니다.
Kubernetes	서비스 메시 제어를 관리하려면 Istio와 같은 추가 서비스가 필요한 복잡한 마이크로서비스 아키텍처를 빌드합니다.	Google Kubernetes Engine: 컨테이너화된 앱의 배포, 확장, 관리를 자동화하는 오픈소스 컨테이너 조정 엔진입니다.
가상 머신(VM)	애플리케이션 및 워크로드 요구사항과 서드 파티 소프트웨어 및 서비스를 지원하는 사전 정의되고 맞춤설정 가능한 VM 제품군에서 VM을 만들고 실행합니다.	Compute Engine: VM 인스턴스에 그래픽 처리 장치(GPU)를 추가합니다. 이 GPU를 사용하여 인스턴스에서 머신러닝 및 데이터 처리와 같은 특정 워크로드를 가속화할 수 있습니다. 요구사항에 따라 적절한 머신 유형을 선택하려면 머신 계열 권장사항을 참조하세요.

자세한 내용은 컴퓨팅 옵션 선택을 참조하세요.

컴퓨팅 마이그레이션 방식 선택

다른 클라우드 또는 온프레미스에서 기존 애플리케이션을 마이그레이션하는 경우 다음 Google Cloud 제품 중 하나를 사용하여 성능, 확장성, 비용, 보안을 최적화하세요.

마이그레이션 목표	사용 사례	권장 제품
리프트 앤 시프트	VMware 워크로드를 Google Cloud로 몇 분 안에 마이그레이션하거나 확장할 수 있습니다.	Google Cloud VMware Engine
리프트 앤 시프트	VM 기반 애플리케이션을 Compute Engine으로 이전합니다.	Migrate to Virtual Machines
컨테이너로 업그레이드	기존 애플리케이션을 Google Kubernetes Engine의 기본 제공 컨테이너로 현대화합니다.	Migrate to Containers

내부 팀을 조정하는 동안 워크로드를 마이그레이션하는 방법은 VM Migration 수명 주기 및 Google Cloud를 사용하여 대규모 마이그레이션 프로그램 빌드를 참조하세요.

워크로드 설계

이 섹션에서는 시스템을 지원하도록 워크로드를 설계하기 위한 권장사항을 제공합니다.

단순한 로직을 위한 서버리스 옵션 평가

단순한 로직은 특수 하드웨어나 CPU 최적화 머신 같은 머신 유형이 필요 없는 컴퓨팅 유형입니다. 운영 오버헤드를 추상화하고 비용 및 성능을 최적화하기 위해 Google Kubernetes Engine(GKE) 또는 Compute Engine 구현에 투자하기 전에 경량형 로직의 서버리스 옵션을 평가합니다.

애플리케이션을 스테이트리스(Stateless)로 분리

가능하면 서버리스 컴퓨팅 옵션 사용을 극대화하기 위해 애플리케이션을 스테이트리스(Stateless)로 분리합니다. 이 접근 방식을 사용하면 관리형 컴퓨팅 제품을 사용하고, 필요에 따라 애플리케이션을 확장하고, 비용과 성능을 최적화할 수 있습니다. 확장성 및 고가용성을 위해 애플리케이션을 분리하는 방법에 대한 자세한 내용은 확장 및 고가용성을 위한 설계를 참조하세요.

아키텍처를 분리할 때 캐싱 로직 사용

애플리케이션이 스테이트풀(Stateful)로 설계된 경우 캐싱 로직을 사용하여 워크로드를 분리하고 확장할 수 있습니다. 자세한 내용은 데이터베이스 권장사항을 참조하세요.

라이브 마이그레이션을 사용하여 업그레이드 촉진

Google 유지보수 업그레이드를 촉진하려면 인스턴스 가용성 정책을 설정하여 라이브 마이그레이션을 사용하세요. 자세한 내용은 VM 호스트 유지보수 정책 설정을 참조하세요.

워크로드 확장

이 섹션에서는 시스템을 지원하도록 워크로드를 확장하기 위한 권장사항을 제공합니다.

시작 및 종료 스크립트 사용

스테이트풀(Stateful) 애플리케이션의 경우 가능하면 애플리케이션 시작 및 중지를 위해 시작 및 종료 스크립트를 사용합니다. 단계적 시작은 소프트웨어 기능에 의해 컴퓨터가 켜지고 운영체제가 프로세스를 안전하게 시작하고 연결을 여는 작업을 수행할 수 있는 경우입니다.

단계적 시작 및 종료는 스테이트풀(Stateful) 애플리케이션이 컴퓨팅과 가까운 위치(일반적으로 로컬 또는 영구 디스크 또는 RAM에 있음)에 있는 데이터의 즉각적인 가용성에 의존하므로 중요합니다. 시작 시마다 애플리케이션 데이터를 실행하지 않으려면 시작 스크립트를 사용하여 마지막으로 저장된 데이터를 다시 로드하고 이전에 종료 시 중단된 프로세스를 실행합니다. 종료 시 진행 상태를 잃지 않도록 애플리케이션 메모리 상태를 저장하려면 종료 스크립트를 사용합니다. 예를 들어 축소 또는 Google 유지보수 이벤트로 인해 VM이 종료되도록 예약된 경우 종료 스크립트를 사용합니다.

MIG를 사용하여 VM 관리 지원

Compute Engine VM을 사용할 때 관리형 인스턴스 그룹(MIG)은 자동 복구, 부하 분산, 자동 확장, 자동 업데이트, 스테이트풀(Stateful) 워크로드와 같은 기능을 지원합니다. 가용성 목표를 기준으로 영역 또는 리전 MIG를 만들 수 있습니다. 스테이트리스(Stateless) 제공 또는 일괄 워크로드, 그리고 각 VM의 고유 상태를 보존해야 하는 스테이트풀(Stateful) 애플리케이션에 MIG를 사용할 수 있습니다.

포드 자동 확장 처리를 사용하여 GKE 워크로드 확장

수평형 및 수직형 포드 자동 확장 처리를 사용하여 워크로드를 확장하고 노드 자동 프로비저닝을 사용하여 기본 컴퓨팅 리소스를 확장합니다.

애플리케이션 트래픽 분산

애플리케이션을 전역으로 확장하려면 Cloud Load Balancing을 사용하여 애플리케이션 인스턴스를 하나 이상의 리전 또는 영역으로 분산합니다. 부하 분산기는 Google Cloud 에지 네트워크에서 가장 가까운 영역으로의 패킷 라우팅을 최적화하여 제공 트래픽 효율성을 높이고 제공 비용을 최소화합니다. 최종 사용자 지연 시간을 최적화하려면 Cloud CDN을 사용하여 정적 콘텐츠를 캐시합니다.

컴퓨팅 생성 및 관리 자동화

컴퓨팅 생성 및 관리를 자동화하여 프로덕션 환경에서 사람에 의한 오류를 최소화합니다.

작업 관리

이 섹션에서는 시스템을 지원하는 작업을 관리하기 위한 권장사항을 제공합니다.

Google에서 제공하는 공개 이미지 사용

Google Cloud에서 제공하는 공개 이미지를 사용합니다. Google Cloud 공개 이미지는 정기적으로 업데이트됩니다. 자세한 내용은 Compute Engine에서 사용 가능한 공개 이미지 목록을 참조하세요.

특정 구성 및 설정으로 고유 이미지를 만들 수도 있습니다. 가능하면 조직 내에서 승인된 사용자와 공유할 수 있는 별도의 프로젝트에서 이미지 생성을 자동화하고 중앙화합니다. 별도의 프로젝트에서 커스텀 이미지를 만들고 선별하면 자신의 구성을 사용하여 VM을 업데이트하고, 패치하고, 만들 수 있습니다. 그러면 선별된 VM 이미지를 관련 프로젝트와 공유할 수 있습니다.

인스턴스 백업을 위해 스냅샷 사용

스냅샷을 사용하여 인스턴스의 백업을 만들 수 있습니다. 스냅샷은 스테이트풀(Stateful) 애플리케이션에 특히 유용하지만 갑작스러운 종료가 발생할 경우 상태를 유지하거나 진행 상황을 저장하기에는 유연하지 않습니다. 스냅샷을 사용하여 새 인스턴스를 자주 만들 경우 해당 스냅샷에서 기본 이미지를 만들어 백업 프로세스를 최적화할 수 있습니다.

머신 이미지를 사용하여 VM 인스턴스 만들기 사용 설정

스냅샷은 머신 내부의 데이터 이미지만 캡처하지만 머신 이미지는 데이터 외에 머신 구성 및 설정도 캡처합니다. 머신 이미지를 사용하여 VM 인스턴스를 만드는 데 필요한 하나 이상의 디스크에서 모든 구성, 메타데이터, 권한, 데이터를 저장할 수 있습니다.

스냅샷에서 머신을 만들 때는 많은 작업이 필요한 새 VM 인스턴스에 인스턴스 설정을 구성해야 합니다. 머신 이미지를 사용하면 알려진 설정을 새 머신에 복사하여 오버헤드를 줄일 수 있습니다. 자세한 내용은 머신 이미지를 사용하는 경우를 참조하세요.

용량, 예약, 격리

이 섹션에서는 시스템 지원을 위해 용량, 예약, 격리를 관리하기 위한 권장사항을 제공합니다.

약정 사용 할인을 사용하여 비용 절감

약정 사용 할인을 사용하여 항상 사용 중인 워크로드의 운영 지출(OPEX) 비용을 줄일 수 있습니다. 자세한 내용은 비용 최적화 카테고리를 참조하세요.

비용 및 성능을 지원하는 머신 유형 선택

Google Cloud는 비용 및 성능 매개변수에 따라 컴퓨팅을 선택할 수 있는 머신 유형을 제공합니다. 비용에 맞게 저성능 제품을 선택하거나 더 높은 비용으로 고성능 컴퓨팅 옵션을 선택할 수 있습니다. 자세한 내용은 비용 최적화 카테고리를 참조하세요.

단독 테넌트 노드를 사용하여 규정 준수 지원

단독 테넌트 노드는 프로젝트의 VM만 전담하여 호스팅하는 물리적 Compute Engine 서버입니다. 단독 테넌트 노드는 다음을 포함한 물리적 격리 규정 준수 요구사항을 충족하는 데 도움이 됩니다.

• VM을 다른 프로젝트의 VM과 물리적으로 분리합니다.
• 동일한 호스트 하드웨어에서 VM을 그룹화합니다.
• 결제 처리 워크로드를 격리합니다.

자세한 내용은 단독 테넌트 노드를 참조하세요.

예약을 사용하여 리소스 가용성 보장

Google Cloud를 사용하면 워크로드에 예약을 정의하여 해당 리소스를 항상 사용할 수 있습니다. 예약 생성에는 추가 요금이 없지만 사용하지 않더라도 예약된 리소스에 대한 비용을 지불해야 합니다. 자세한 내용은 예약 사용 및 관리를 참조하세요.

VM 마이그레이션

이 섹션에서는 시스템을 지원하기 위해 VM을 마이그레이션하기 위한 권장사항을 제공합니다.

기본 제공되는 마이그레이션 도구 평가

다른 클라우드 또는 온프레미스에서 워크로드를 이전하기 위해 기본 제공되는 마이그레이션 도구를 평가합니다. 자세한 내용은 Google Cloud로 마이그레이션을 참조하세요. Google Cloud는 워크로드를 마이그레이션하고 비용 및 성능을 최적화하는 데 도움이 되는 도구와 서비스를 제공합니다. 현재 IT 환경을 기준으로 무료 마이그레이션 비용 평가를 받으려면 Google Cloud 신속 평가 및 마이그레이션 프로그램을 참조하세요.

맞춤설정된 운영체제에 가상 디스크 가져오기 사용

맞춤설정된 지원되는 운영체제를 가져오려면 가상 디스크 가져오기를 참조하세요. 단독 테넌트 노드는 코어별 또는 프로세서별 라이선스의 Bring Your Own License(사용자 라이선스 사용) 요구사항을 충족하는 데 유용합니다. 자세한 내용은 사용자 라이선스 사용을 참조하세요.

권장사항

아키텍처 프레임워크의 안내 사항을 자신의 환경에 적용하려면 다음을 수행하는 것이 좋습니다.

• Google Cloud Marketplace 제품을 검토하여 애플리케이션이 지원되는 공급업체에 포함되어 있는지 평가합니다. Google Cloud는 다양한 오픈소스 시스템과 다양한 타사 소프트웨어의 실행을 지원합니다.

• VM 기반 애플리케이션을 GKE에서 실행되는 컨테이너화된 애플리케이션으로 추출하고 패키징하려면 Migrate to Containers 및 GKE를 사용하는 것이 좋습니다.

• Compute Engine을 사용하여 Google Cloud에서 애플리케이션을 실행합니다. VM 기반 애플리케이션에서 실행되는 기존 종속 항목이 있는 경우 공급업체 요구사항을 충족하는지 확인합니다.

• Google Cloud 내부 패스 스루 네트워크 부하 분산기를 사용하여 분리된 아키텍처를 확장할 수 있는지 평가합니다. 자세한 내용은 내부 패스 스루 네트워크 부하 분산기 개요를 참조하세요.

• HA 프록시 사용 등의 기존 온프레미스 사용 사례에서 전환하는 옵션을 평가합니다. 자세한 내용은 유동 IP 주소를 위한 권장사항을 참조하세요.

• VM Manager를 사용하여 Compute Engine에서 Windows 또는 Linux를 실행하는 대규모 VM Fleet의 운영체제를 관리하고 일관된 구성 정책을 적용할 수 있습니다.

• GKE Autopilot을 사용하여 Google SRE에서 클러스터를 완전히 관리할 수 있습니다.

• GKE 클러스터 전반에서 정책 및 구성 관리에 정책 컨트롤러와 구성 동기화를 사용합니다.

• 특정 리전 및 영역에서 머신의 가용성과 확장성을 보장합니다. Google Cloud는 컴퓨팅 요구사항을 지원하도록 확장할 수 있습니다. 하지만 특정 리전 또는 영역에서 특정 머신 유형이 많이 필요한 경우 계정팀과 협력하여 가용성을 보장합니다. 자세한 내용은 Compute Engine 예약을 참조하세요.

다음 단계

다음을 비롯한 네트워킹 설계 원칙에 대해 알아보세요.

• 워크로드 VPC 아키텍처 설계

• VPC 간 연결 설계

아키텍처 프레임워크에서 안정성, 운영 우수성, 보안, 개인 정보 보호, 규정 준수 등의 다른 카테고리 살펴보기

네트워크 인프라 설계

Google Cloud 아키텍처 프레임워크의 이 문서에서는 네트워킹 설계를 기반으로 시스템을 배포하기 위한 권장사항을 제공합니다. Virtual Private Cloud(VPC)를 선택하고 구현하는 방법과 네트워크 보안을 테스트하고 관리하는 방법을 알아봅니다.

핵심 원칙

네트워킹 설계는 성공적인 시스템 설계에 매우 중요한데, 그 이유는 성능 최적화와 내부 및 외부 서비스의 안전한 애플리케이션 통신에 도움이 되기 때문입니다. 네트워킹 서비스를 선택할 때는 애플리케이션 요구사항을 평가하고 애플리케이션이 서로 통신하는 방법을 평가하는 것이 중요합니다. 예를 들어 일부 구성요소에는 글로벌 서비스가 필요하지만 다른 구성요소는 특정 리전에 지리적으로 위치해야 할 수 있습니다.

Google의 비공개 네트워크가 리전 위치를 100개가 넘는 글로벌 네트워크 접속 지점으로 연결합니다. Google Cloud는 소프트웨어 정의 네트워킹 및 분산 시스템 기술을 사용하여 전 세계에서 서비스를 호스팅하고 제공합니다. Google Cloud 내에서 네트워킹을 위한 Google의 핵심 요소는 전역 VPC입니다. VPC는 Google의 글로벌 고속 네트워크를 사용하여 리전 간에 애플리케이션을 연결하는 동시에 개인 정보 보호와 안정성을 지원합니다. Google은 병목 현상 대역폭 및 왕복 전파 시간(BBR) 정체 제어 인텔리전스와 같은 기술을 사용하여 높은 처리량으로 콘텐츠를 전송합니다.

클라우드 네트워킹 설계 개발에는 다음 단계가 포함됩니다.

1. 워크로드 VPC 아키텍처를 설계합니다. 먼저 필요한 Google Cloud 프로젝트와 VPC 네트워크 수를 파악합니다.
2. VPC 간 연결을 추가합니다. 워크로드가 다른 VPC 네트워크의 다른 워크로드에 연결되는 방식을 설계합니다.
3. 하이브리드 네트워크 연결을 설계합니다. 워크로드 VPC가 온프레미스 및 기타 클라우드 환경에 연결되는 방식을 설계합니다.

Google Cloud 네트워크를 설계할 때 다음 사항을 고려하세요.

• VPC는 Compute Engine, Google Kubernetes Engine (GKE), 서버리스 컴퓨팅 솔루션에서 빌드된 서비스를 상호 연결하기 위해 클라우드에서 비공개 네트워킹 환경을 제공합니다. VPC를 사용하여 Cloud Storage, BigQuery, Cloud SQL과 같은 Google 관리 서비스에 비공개로 액세스할 수도 있습니다.
• VPC 네트워크는 연결된 라우터와 방화벽 규칙을 포함하여 전역 리소스입니다. 어떠한 특정 리전이나 영역과도 연결되어 있지 않습니다.
• 서브넷은 리전 리소스입니다. 동일한 클라우드 리전의 여러 영역에 배포된 Compute Engine VM 인스턴스는 동일한 서브넷의 IP 주소를 사용할 수 있습니다.
• VPC 방화벽 규칙을 사용하여 인스턴스에서 송수신되는 트래픽을 제어할 수 있습니다.
• Identity and Access Management(IAM) 역할을 사용하여 네트워크 관리를 보호할 수 있습니다.
• Cloud VPN이나 Cloud Interconnect를 사용하여 하이브리드 환경에서 VPC 네트워크를 안전하게 연결할 수 있습니다.

VPC 사양의 전체 목록을 보려면 사양을 참조하세요.

워크로드 VPC 아키텍처

이 섹션에서는 시스템을 지원하기 위해 워크로드 VPC 아키텍처를 설계하기 위한 권장사항을 제공합니다.

초기에 VPC 설계 고려

Google Cloud에서 조직 설정 설계 시 초기 단계에 VPC 네트워크 설계를 고려하세요. 조직 수준에서 선택한 설계는 프로세스의 후반부에서 쉽게 되돌릴 수 없습니다. 자세한 내용은 VPC 설계에 관한 권장사항 및 참조 아키텍처와 Google Cloud 시작 영역의 네트워크 설계 결정을 참조하세요.

단일 VPC 네트워크로 시작

공통 요구사항이 있는 리소스를 포함하는 많은 사용 사례의 경우 단일 VPC 네트워크가 필요한 기능을 제공합니다. 단일 VPC 네트워크는 생성, 유지 관리, 파악이 간단합니다. 자세한 내용은 VPC 네트워크 사양을 참조하세요.

VPC 네트워크 토폴로지 단순화

관리 가능하고 안정적이며 이해하기 쉬운 아키텍처를 보장하려면 VPC 네트워크 토폴로지 설계를 가능한 한 단순화합니다.

커스텀 모드에서 VPC 네트워크 사용

Google Cloud 네트워킹이 기존 네트워킹 시스템과 원활하게 통합되도록 VPC 네트워크를 만들 때 커스텀 모드를 사용하는 것이 좋습니다. 커스텀 모드를 사용하면 Google Cloud 네트워킹을 기존 IP 주소 관리 체계에 통합하는 데 도움이 되며 VPC에 포함할 클라우드 리전을 제어할 수 있습니다. 자세한 내용은 VPC를 참조하세요.

VPC 간 연결

이 섹션에서는 시스템을 지원하기 위해 VPC 간 연결을 설계하기 위한 권장사항을 제공합니다.

VPC 연결 방법 선택

여러 VPC 네트워크를 구현하기로 결정한 경우 해당 네트워크를 연결해야 합니다. VPC 네트워크는 Google의 Andromeda 소프트웨어 정의 네트워크(SDN) 내의 격리된 테넌트 공간입니다. VPC 네트워크가 서로 통신할 수 있는 방법에는 여러 가지가 있습니다 대역폭, 지연 시간, 서비스수준계약(SLA) 요구사항에 따라 네트워크 연결 방법을 선택합니다. 연결 옵션에 대한 자세한 내용은 비용, 성능 및 보안 요구사항을 충족하는 VPC 연결 방법 선택을 참조하세요.

공유 VPC를 사용하여 여러 작업 그룹 관리

여러 팀으로 구성된 조직의 경우 공유 VPC를 사용하면 아키텍처 측면에서 단순한 단일 VPC 네트워크를 여러 작업 그룹에 걸쳐 확장할 수 있습니다.

간단한 명명 규칙 사용

간단하고 직관적이며 일관된 명명 규칙을 선택하세요. 이렇게 하면 관리자와 사용자가 각 리소스의 목적, 위치, 다른 리소스와의 차이점을 이해하는 데 도움이 됩니다.

연결 테스트를 사용하여 네트워크 보안 확인

네트워크 보안의 맥락에서 연결 테스트를 사용하여 두 엔드포인트 사이에서 막으려는 트래픽이 차단되었는지 확인할 수 있습니다. 트래픽이 차단되었는지 여부와 차단된 이유를 확인하려면 두 엔드포인트 간의 테스트를 정의하고 결과를 평가합니다. 예를 들어 트래픽 차단을 지원하는 규칙을 정의할 수 있는 VPC 기능을 테스트할 수 있습니다. 자세한 내용은 연결 테스트 개요를 참조하세요.

Private Service Connect를 사용하여 비공개 엔드포인트 만들기

자체 IP 주소 스킴으로 Google 서비스에 액세스할 수 있는 비공개 엔드포인트를 만들려면 Private Service Connect를 사용하세요. VPC에서 종료되는 하이브리드 연결을 통해 또는 VPC 내에서 비공개 엔드포인트에 액세스할 수 있습니다.

외부 연결 보안 및 제한

인터넷 액세스는 인터넷 액세스가 필요한 리소스로만 제한합니다. 비공개 내부 IP 주소만 있는 리소스도 비공개 Google 액세스를 통해 많은 Google API 및 서비스에 액세스할 수 있습니다.

Network Intelligence Center를 사용하여 클라우드 네트워크 모니터링

Network Intelligence Center에서는 모든 리전 간에 Google Cloud 네트워크를 포괄적으로 파악할 수 있습니다. 운영 및 보안 위험을 초래할 수 있는 트래픽 및 액세스 패턴을 식별할 수 있게 도와줍니다.

다음 단계

다음을 포함하여 스토리지 관리 권장사항에 대해 알아보세요.

• 스토리지 유형 선택
• 스토리지 액세스 패턴 및 워크로드 유형 선택

아키텍처 프레임워크에서 안정성, 운영 우수성, 보안, 개인 정보 보호, 규정 준수 등의 다른 카테고리 살펴보기

스토리지 전략 선택 및 구현

Google Cloud 아키텍처 프레임워크의 이 문서는 스토리지를 기반으로 시스템을 배포하기 위한 권장사항을 제공합니다. 스토리지 전략을 선택하는 방법과 스토리지, 액세스 패턴, 워크로드를 관리하는 방법을 알아봅니다.

조직에서는 데이터 교환을 용이하게 하고 데이터를 안전하게 백업 및 저장하기 위해 워크로드, 초당 입출력 작업 수(IOPS), 지연 시간, 검색 빈도, 위치, 용량, 형식(블록, 파일, 객체)을 기준으로 스토리지 요금제를 선택해야 합니다.

Cloud Storage는 안정적이고 안전한 객체 스토리지 서비스를 제공하여 여기에는 다음 서비스가 포함됩니다.

• 장비 고장 시 데이터를 보호하고 데이터 센터 유지보수 중에도 데이터 가용성을 보장하는 중복성 옵션 내장
• 데이터 전송 옵션은 다음과 같습니다.
  • Storage Transfer Service
  • Transfer Appliance
  • BigQuery Data Transfer Service
  • Google Cloud로 마이그레이션: 대규모 데이터 세트 전송
• 워크로드를 지원하는 스토리지 클래스
• Google이 읽기 및 쓰기를 확인할 수 있게 해주는 모든 Cloud Storage 작업에 대해 계산된 체크섬

Google Cloud에서 IOPS는 프로비저닝된 스토리지 공간에 맞춰 확장됩니다. Persistent Disk와 같은 스토리지 유형은 영역별 또는 리전별로 제공되므로 수동 복제 및 백업이 필요합니다. 이와 달리 객체 스토리지는 가용성이 높고 단일 리전 또는 여러 리전에서 자동으로 데이터를 복제합니다.

스토리지 유형

이 섹션에서는 시스템을 지원하는 스토리지 유형을 선택하기 위한 권장사항을 제공합니다.

고성능 스토리지 요구에 대한 옵션 평가

고성능 스토리지가 필요한 컴퓨팅 애플리케이션을 위한 영구 디스크 또는 로컬 솔리드 스테이트 드라이브(SSD)를 평가해 보세요. Cloud Storage는 버전 관리가 지원되는 변경 불가능한 객체 스토리지입니다. Cloud Storage를 Cloud CDN과 함께 사용하면 비용을 최적화하는 데 도움이 되며, 자주 액세스하는 정적 객체의 경우 더 그렇습니다.

Filestore는 고성능 공유 공간이 필요한 멀티 쓰기 애플리케이션을 지원합니다. 또한 Filestore는 네트워크 파일 시스템(NFS) 마운트를 통해 POSIX와 비슷한 파일 작업이 필요한 기존 및 최신 애플리케이션을 지원합니다.

Cloud Storage는 데이터 레이크를 만들고 보관처리 요구사항을 처리하는 등의 사용 사례를 지원합니다. 특히 보관 정책을 구성하는 경우 액세스 및 가져오기 비용을 감안해 Cloud Storage 클래스를 선택할 때 균형 잡힌 결정을 내려야 합니다. 자세한 내용은 클라우드 워크로드를 위한 최적의 스토리지 전략 설계를 참조하세요.

모든 스토리지 옵션은 기본적으로 Google 관리 키를 사용하여 미사용 상태와 전송 중에 암호화됩니다. Persistent Disk와 Cloud Storage 같은 스토리지 유형의 경우 자체 키를 제공하거나 Cloud Key Management Service(Cloud KMS)를 통해 관리할 수 있습니다. 프로덕션 데이터에 사용하기 전에 이러한 키를 처리하기 위한 전략을 수립합니다.

스토리지 설계를 지원하는 Google Cloud 서비스 선택

스토리지 설계를 지원하는 Google Cloud 서비스에 대해 알아보려면 다음 표를 사용하세요.

Google Cloud 서비스	설명
Cloud Storage	데이터 양에 상관없이 언제든지 데이터를 저장하고 가져올 수 있습니다. Cloud Storage를 웹사이트 콘텐츠 제공, 보관 및 재해 복구를 위한 데이터 저장, 직접 다운로드를 통해 사용자에게 대량의 데이터 객체 배포 등 다양한 시나리오에서 사용할 수 있습니다. 자세한 내용은 다음을 참조하세요. Cloud Storage 권장사항 버킷 위치 스토리지 클래스 Cloud Storage FUSE
Persistent Disk	Google Cloud의 고성능 블록 스토리지입니다. Persistent Disk는 Compute Engine 또는 Google Kubernetes Engine(GKE)에서 실행되는 인스턴스에 연결할 수 있는 SSD 및 하드 디스크 드라이브(HDD)를 제공합니다. 리전 디스크는 동일한 리전 내의 두 영역 간 데이터 복제를 지원하며 내구성 있는 스토리지를 제공합니다. IOPS를 높이고 지연 시간이 짧아야 하는 경우 Google Cloud는 Filestore를 제공합니다. 로컬 SSD는 가상 머신 인스턴스를 호스팅하는 서버에 물리적으로 연결됩니다. 로컬 SSD를 임시 디스크 공간으로 사용할 수 있습니다.
Filestore	파일 시스템 인터페이스와 데이터용 공유 파일 시스템이 필요한 애플리케이션을 위해 만들어진 관리형 파일 스토리지 서비스입니다. Filestore는 관리형 네트워크 연결 스토리지(NAS)를 Compute Engine 및 GKE 인스턴스와 같이 구축할 수 있는 원활한 환경을 제공합니다.
Firebase용 Cloud Storage	사진이나 동영상과 같은 사용자 제작 콘텐츠를 저장하고 제공해야 하는 앱 개발자를 위해 빌드되었습니다. 모든 파일이 Cloud Storage 버킷에 저장되므로 Firebase 및 Google Cloud 둘 다에서 파일에 액세스할 수 있습니다.

스토리지 전략 선택

애플리케이션 요구사항을 충족하는 스토리지 전략을 선택하려면 다음 표를 활용하세요.

사용 사례	권장사항
가장 저렴한 비용으로 규모에 맞게 데이터를 저장하려 하며 액세스 성능은 문제가 되지 않는 경우	Cloud Storage
즉각적인 스토리지가 필요한 컴퓨팅 애플리케이션을 실행 중입니다. 자세한 내용은 Persistent Disk 및 로컬 SSD 성능 최적화를 참조하세요.	Persistent Disk 또는 로컬 SSD
공유 공간에 대한 읽기 및 쓰기 액세스가 필요한 고성능 워크로드를 실행 중인 경우	Filestore
고성능 컴퓨팅(HPC) 또는 대용량 컴퓨팅(HTC) 사용 사례가 있는 경우	클러스터에서 대규모 기술 컴퓨팅을 위한 클러스터 사용

스토리지 액세스 요구사항에 따라 활성 또는 아카이브 스토리지 선택

스토리지 클래스는 모든 객체에서 사용되는 메타데이터의 조각입니다. 높은 요청 비율과 고가용성으로 처리되는 데이터의 경우 Standard Storage 클래스를 사용해야 합니다. 자주 액세스하지 않으며 가용성이 다소 낮아도 되는 데이터에는 Nearline Storage, Coldline Storage 또는 Archive Storage 클래스를 사용하세요. 스토리지 클래스 선택 관련 비용 고려사항에 대한 자세한 내용은 Cloud Storage 가격 책정을 참조하세요.

Cloud Storage의 스토리지 위치 및 데이터 보호 요구사항 평가

리전에 위치한 Cloud Storage 버킷의 경우 해당 리전에 포함된 데이터가 자동으로 리전 내의 영역 간에 복제됩니다. 여러 영역으로 데이터를 복제하면 리전 내 한 영역에서 장애가 발생하더라도 데이터를 보호할 수 있습니다.

또한 Cloud Storage는 리전 간에 중복되는 위치를 제공하므로 데이터를 지리적으로 별도의 여러 데이터 센터에 복제합니다. 자세한 내용은 버킷 위치를 참조하세요.

Cloud CDN을 사용하여 정적 객체 전송 기능 개선

객체 검색 비용을 최적화하고 액세스 지연 시간을 최소화하려면 Cloud CDN을 사용합니다. Cloud CDN은 Cloud Load Balancing 외부 애플리케이션 부하 분산기를 사용하여 라우팅, 상태 점검, 애니캐스트 IP 주소 지원을 제공합니다. 자세한 내용은 클라우드 버킷을 사용한 Cloud CDN 설정을 참조하세요.

스토리지 액세스 패턴 및 워크로드 유형

이 섹션에서는 시스템을 지원하기 위해 스토리지 액세스 패턴과 워크로드 유형을 선택하기 위한 권장사항을 제공합니다.

Persistent Disk를 사용하여 고성능 스토리지 액세스 지원

데이터 액세스 패턴은 시스템 성능 설계 방식에 따라 다릅니다. Cloud Storage는 확장 가능한 스토리지를 제공하지만 대량의 데이터에 높은 처리량으로 액세스해야 하는 컴퓨팅 워크로드를 많이 실행하는 경우에는 이상적인 옵션이 아닙니다. 고성능 스토리지 액세스가 필요하다면 Persistent Disk를 사용하세요.

재시도 로직 구현 시 지수 백오프 사용

재시도 로직을 구현할 때 지수 백오프를 사용해 5XX, 408, 429 오류를 해결하세요. 각 Cloud Storage 버킷에는 초기 I/O 용량이 프로비저닝됩니다. 자세한 내용은 요청 비율 및 액세스 분배 가이드라인을 참조하세요. 재시도 요청이 점진적으로 증가하도록 계획을 수립하세요.

스토리지 관리

이 섹션에서는 시스템을 지원하는 스토리지 관리를 위한 권장사항을 제공합니다.

모든 버킷에 고유한 이름 할당

모든 버킷 이름은 Cloud Storage 네임스페이스에서 고유해야 합니다. 버킷 이름에 민감한 정보를 포함하지 마세요. 추측하기 어려운 버킷 이름과 객체 이름을 선택합니다. 자세한 내용은 버킷 이름 지정 가이드라인 및 객체 이름 지정 가이드라인을 참조하세요.

Cloud Storage 버킷을 비공개로 유지

비즈니스 관련 사유가 없는 한 Cloud Storage 버킷에 익명이나 공개적으로 액세스할 수 없어야 합니다. 자세한 내용은 액세스 제어 개요를 참조하세요.

임의의 객체 이름을 할당하여 로드를 균등하게 분산

임의의 객체 이름을 할당하여 성능을 개선하고 핫스팟을 피하세요. 가능하다면 객체에 무작위화된 프리픽스를 사용합니다. 자세한 내용은 전체 키 범위에 걸쳐 부하를 균일하게 분배하는 이름 지정 규칙 사용을 참조하세요.

공개 액세스 방지 사용

조직, 폴더, 프로젝트 또는 버킷 수준에서 액세스하지 못하도록 공개 액세스 방지를 사용하세요. 자세한 내용은 공개 액세스 방지 사용을 참조하세요.

다음 단계

다음을 포함한 Google Cloud 데이터베이스 서비스 및 권장사항 알아보기

• 데이터베이스 선택 및 마이그레이션
• 데이터베이스 암호화 관리
• 데이터베이스 네트워킹 및 액세스 관리

아키텍처 프레임워크에서 안정성, 운영 우수성, 보안, 개인 정보 보호, 규정 준수 등의 다른 카테고리 살펴보기

데이터베이스 최적화

Google Cloud 아키텍처 프레임워크의 이 문서에서는 데이터베이스 설계를 기반으로 시스템을 배포하기 위한 권장사항을 제공합니다. 데이터베이스 설계, 마이그레이션, 확장, 데이터베이스 정보 암호화, 라이선스 관리, 데이터베이스에서 이벤트 모니터링 방법을 알아봅니다.

주요 서비스

아키텍처 프레임워크 시스템 설계 카테고리의 이 문서에는 다양한 Google Cloud 데이터베이스 서비스가 포함된 권장사항이 나와 있습니다. 다음 표에서는 이러한 서비스에 대해 개략적으로 설명합니다.

Google Cloud 서비스	설명
Cloud SQL	PostgreSQL용 Cloud SQL, MySQL용 Cloud SQL, SQL Server용 Cloud SQL을 사용하는 관계형 데이터베이스를 설정, 유지, 관리할 수 있는 완전 관리형 데이터베이스 서비스입니다. Cloud SQL은 고성능과 확장성을 제공합니다. Google Cloud에서 호스팅되는 Cloud SQL은 어디에서나 실행되는 애플리케이션을 위한 데이터베이스 인프라를 제공합니다.
Bigtable	수십억 개의 행과 수천 개의 열까지 확장하여 수 페타바이트의 데이터까지 저장할 수 있는 테이블입니다. 각 행의 단일 값에 대한 색인이 생성되는데, 이러한 값을 row key라고 부릅니다. Bigtable을 사용하면 매우 짧은 지연 시간으로 엄청난 양의 단일 키 입력 데이터를 저장할 수 있습니다. Cloud Bigtable은 낮은 지연 시간으로 높은 읽기 및 쓰기 처리량을 지원하며, 맵리듀스 작업을 위한 데이터 소스입니다.
Spanner	관계형 데이터베이스 구조 및 비관계형 수평적 확장을 포함하여 클라우드에 맞게 설계된 확장 가능한 글로벌 분산형 엔터프라이즈 데이터베이스 서비스입니다. 이 조합을 통해 행, 리전, 대륙 간에 고성능 트랜잭션과 일관성을 유지할 수 있습니다. Spanner는 99.999% 가용성 SLA를 제공하고 예정된 다운타임이 없으며 엔터프라이즈급 보안을 제공합니다.
Memorystore	Google Cloud용 완전 관리형 Redis 서비스입니다. Google Cloud에서 실행되는 애플리케이션은 복잡한 Redis 배포를 관리하지 않고도 가용성이 높고 확장 가능하며 안전한 Redis 서비스를 통해 성능을 향상시킬 수 있습니다.
Firestore	자동 확장, 고성능, 애플리케이션 개발을 위해 설계된 NoSQL 문서 데이터베이스입니다. Firestore 인터페이스의 대다수 기능이 기존 데이터베이스와 동일하지만 이 인터페이스는 NoSQL 데이터베이스로서 데이터 객체 간의 관계를 다르게 설명합니다.
Firebase 실시간 데이터베이스	클라우드 호스팅 데이터베이스입니다. Firebase는 데이터를 JSON으로 저장하고 연결된 모든 클라이언트와 실시간으로 동기화됩니다. Google, iOS, Android, 자바스크립트 SDK로 크로스 플랫폼 앱을 빌드하면 모든 클라이언트가 하나의 실시간 데이터베이스 인스턴스를 공유하고 자동 업데이트로 최신 데이터를 수신합니다.
오픈소스 데이터베이스	Google 파트너는 MongoDB, MariaDB, Redis를 포함한 다양한 오픈소스 데이터베이스를 제공합니다.
PostgreSQL용 AlloyDB	까다로운 엔터프라이즈 워크로드를 위한 완전 관리형 PostgreSQL 호환 데이터베이스 서비스입니다. 표준 PostgreSQL과 비교할 때 트랜잭션 워크로드 성능을 최대 4배, 분석 쿼리를 최대 100배 더 빠르게 제공합니다. PostgreSQL용 AlloyDB는 머신러닝 지원 Autopilot 시스템으로 관리를 간소화합니다.

데이터베이스 선택

이 섹션에서는 시스템을 지원할 데이터베이스를 선택하기 위한 권장사항을 제공합니다.

관리형 데이터베이스 서비스 사용을 고려합니다.

자체 데이터베이스 또는 데이터베이스 클러스터를 설치하기 전에 Google Cloud 관리형 데이터베이스 서비스를 평가합니다. 자체 데이터베이스를 설치하려면 패치 및 업데이트 설치, 백업 모니터링 및 수행과 같은 일상적인 운영 활동 관리를 비롯한 유지관리 오버헤드가 필요합니다.

기능적 및 비기능적 애플리케이션 요구사항을 사용하여 데이터베이스 선택을 유도합니다. 지연 시간이 짧은 액세스, 시계열 데이터 처리, 재해 복구, 모바일 클라이언트 동기화를 고려합니다.

데이터베이스를 마이그레이션하려면 다음 표에 설명된 제품 중 하나를 사용하세요.

데이터베이스 마이그레이션 제품	설명
Cloud SQL	원격 리전, 지연 시간이 짧은 읽기, 재해 복구에서 읽기 복제본을 지원하는 리전 서비스입니다.
Spanner	외적 일관성, 전역 복제, 99.999%의 서비스수준계약(SLA)을 제공하는 멀티 리전 제품입니다.
Bigtable	대규모 분석 및 운영 워크로드를 위한 확장 가능한 완전 관리형 NoSQL 데이터베이스 서비스로 최대 99.999%의 가용성을 제공합니다.
Memorystore	널리 사용되는 두 가지 오픈소스 캐싱 솔루션인 Redis 및 Memcached의 관리형 버전을 제공하는 완전 관리형 데이터베이스 서비스입니다.
Firebase 실시간 데이터베이스	Firebase 실시간 데이터베이스는 실시간으로 데이터를 저장하고 사용자 간에 동기화할 수 있는 클라우드 호스팅 NoSQL 데이터베이스입니다.
Firestore	자동 확장, 고성능, 간편한 애플리케이션 개발을 위해 설계된 NoSQL 문서 데이터베이스입니다.
오픈소스	MongoDB 및 MariaDB를 사용하는 대체 데이터베이스 옵션입니다.

데이터베이스 마이그레이션

기존 워크로드를 Google Cloud로 마이그레이션할 때 사용자에게 애플리케이션 다운타임이 발생하지 않도록 하려면 요구사항을 지원하는 데이터베이스 기술을 선택해야 합니다. 데이터베이스 마이그레이션 옵션 및 권장사항에 대한 자세한 내용은 데이터베이스 마이그레이션 솔루션 및 동종 데이터베이스 마이그레이션 권장사항을 참조하세요.

데이터베이스 마이그레이션 계획에는 다음이 포함됩니다.

• 현재 데이터베이스의 평가 및 검색
• 마이그레이션 성공 기준의 정의
• 마이그레이션 및 대상 데이터베이스의 환경 설정
• 대상 데이터베이스에서 스키마 생성
• 대상 데이터베이스로 데이터 마이그레이션
• 마이그레이션이 검증되어 모든 데이터가 올바르게 마이그레이션되고 데이터베이스에 있는지 확인합니다.
• 롤백 전략 수립

마이그레이션 전략 선택

마이그레이션에 성공하기 위해서는 적절한 대상 데이터베이스를 선택하는 것이 중요합니다. 다음 표에서는 일부 사용 사례에 대한 마이그레이션 옵션을 제공합니다.

사용 사례	권장사항
Google Cloud에서 새로 개발	사용 사례 요구사항에 맞게 클라우드용으로 설계된 관리형 데이터베이스(Cloud SQL, Spanner, Bigtable, Firestore) 중 하나를 선택합니다.
리프트 앤 시프트 마이그레이션	Cloud SQL, MYSQL, PostgreSQL, SQLServer와 같은 호환 가능한 관리형 데이터베이스 서비스를 선택합니다.
애플리케이션에 CloudSQL에서 지원하지 않는 데이터베이스에 대한 세부적인 액세스 권한이 필요합니다.	Compute Engine VM에서 데이터베이스를 실행합니다.

Memorystore를 사용하여 캐싱 데이터베이스 레이어 지원

Memorystore는 밀리초 이하의 지연 시간을 지원하는 완전 관리형 Redis 및 Memcached 데이터베이스입니다. Memorystore는 오픈소스 Redis 및 Memcached와 완벽하게 호환됩니다. 애플리케이션에서 이러한 캐싱 데이터베이스를 사용하는 경우 코드에서 애플리케이션 수준을 변경하지 않고도 Memorystore를 사용할 수 있습니다.

베어메탈 서버를 사용하여 Oracle 데이터베이스 실행

워크로드에 Oracle 데이터베이스가 필요한 경우 Google Cloud에서 제공하는 베어메탈 서버를 사용합니다. 이 접근 방식은 리프트 앤 시프트 마이그레이션 전략에 적합합니다.

워크로드를 Google Cloud로 이동하고 기본 워크로드가 작동된 후 현대화하려면 Spanner, Bigtable, Firestore와 같은 관리형 데이터베이스 옵션 사용을 고려합니다.

클라우드용으로 구축된 데이터베이스는 클라우드 인프라의 하향식으로 구축된 최신 관리형 데이터베이스입니다. 이러한 데이터베이스는 자체 데이터베이스 실행 시 확보하기 어려운 확장성 및 고가용성과 같은 고유한 기본 기능을 제공합니다.

데이터베이스 현대화

클라우드에서 새로운 애플리케이션을 설계하든 기존 데이터베이스를 클라우드로 마이그레이션하든 시스템 설계 프로세스 초기에 데이터베이스 전략을 계획합니다. Google Cloud는 MySQL용 Cloud SQL 및 PostgreSQL용 Cloud SQL과 같은 오픈소스 데이터베이스의 관리형 데이터베이스 옵션을 제공합니다. 데이터베이스를 현대화하고 향후 비즈니스 요구사항을 지원할 수 있는 기회로 마이그레이션을 사용하는 것이 좋습니다.

기존 애플리케이션과 함께 고정 데이터베이스 사용

상용 기성품(COTS) 애플리케이션에는 고정된 유형의 데이터베이스와 고정된 구성이 필요합니다. 리프트 앤 시프트는 일반적으로 COTS 애플리케이션에 가장 적합한 마이그레이션 방법입니다.

팀의 데이터베이스 마이그레이션 기술 세트 확인

팀의 데이터베이스 마이그레이션 기능과 역량을 기반으로 클라우드 데이터베이스 마이그레이션 방식을 선택합니다. Google Cloud 파트너 어드밴티지를 사용하여 마이그레이션 여정을 도와줄 파트너를 찾아보세요.

HA 및 DR 요구사항을 충족하도록 데이터베이스 설계

고가용성(HA) 및 재해 복구(DR) 요구사항을 충족하도록 데이터베이스를 설계할 때 안정성과 비용 간의 절충안을 평가합니다. 클라우드용으로 빌드된 데이터베이스 서비스는 데이터베이스 및 구성에 따라 특정 리전 또는 여러 리전에 몇 개의 데이터 복사본을 만듭니다.

BigQuery 및 Spanner 같은 일부 Google Cloud 서비스에는 멀티 리전 변형이 포함됩니다. 리전 장애로부터 복원력을 늘리기 위해서는 가능한 경우 디자인에 멀티 리전 서비스를 사용합니다.

Google Cloud에서 관리형 데이터베이스를 사용하는 대신 Compute Engine VM에서 데이터베이스를 설계할 경우 데이터베이스의 여러 사본을 실행해야 합니다. 자세한 내용은 안정성 카테고리에서 확장 및 고가용성을 위한 설계를 참조하세요.

데이터 보존을 지원하는 클라우드 리전 지정

데이터 보존은 데이터가 실제로 저장되는 위치를 설명합니다. 데이터 보존 요구사항에 따라 데이터베이스를 배포할 특정 클라우드 리전을 선택하는 것이 좋습니다.

데이터베이스를 여러 리전에 배포하면 데이터베이스 구성 방식에 따라 데이터베이스 간에 데이터 복제가 발생할 수 있습니다. 원하는 저장 리전 내에 데이터를 보관하는 구성을 선택합니다. Spanner와 같은 일부 데이터베이스는 기본 멀티 리전 복제를 제공합니다. 리소스 위치 제약조건을 포함하는 조직 정책을 설정하여 데이터 보존을 적용할 수도 있습니다. 자세한 내용은 리소스 위치 제한을 참조하세요.

데이터 보존 설계에 재해 복구 포함

데이터 보존 계획에 복구 시간 목표(RTO)와 복구 지점 목표(RPO)를 포함하고 RTO/RPO와 재해 복구 비용 간의 균형을 고려합니다. RTO/RPO 수가 작을수록 비용이 높아집니다. 시스템이 중단 없이 더 빠르게 복구되도록 하려면 시스템 실행 비용이 증가합니다. 또한 재해 복구 방식에는 고객 만족을 고려하여 적절한 안정성 투자가 필요합니다. 자세한 내용은 100% 안정성이 잘못된 대상 및 재해 복구 계획 가이드를 참조하세요.

Google Cloud 호환 데이터베이스 만들기

워크로드용 데이터베이스를 선택할 때는 선택한 서비스에서 작업 중인 지리적 리전 및 데이터가 물리적으로 저장되는 위치의 규정 준수 요구사항을 충족하는지 확인해야 합니다. Google의 인증 및 규정 준수 표준에 대한 자세한 내용은 규정 준수 제품을 참조하세요.

암호화

이 섹션에서는 암호화 요구사항을 식별하고 시스템을 지원하는 암호화 키 전략을 선택하기 위한 권장사항을 제공합니다.

암호화 요구사항 파악

암호화 요구사항은 회사 보안 정책 및 규정 준수 요구사항을 비롯한 여러 요소에 따라 달라집니다. Google Cloud에 저장된 모든 데이터는 기본적으로 AES256을 사용하여 별도의 조치 없이 암호화됩니다. 자세한 내용은 Google Cloud 저장 데이터 암호화를 참조하세요.

암호화 키 전략 선택

암호화 키를 직접 관리할지 아니면 관리형 서비스를 사용할지 여부를 결정합니다. Google Cloud는 두 시나리오를 모두 지원합니다. 완전 관리형 서비스가 Google Cloud에서 암호화 키를 관리하도록 하려면 Cloud Key Management Service(Cloud KMS)를 선택합니다. 키의 수명 주기를 더 세밀하게 제어하기 위해 암호화 키를 관리하려면 고객 관리 암호화 키(CMEK)를 사용합니다.

Google Cloud 외부에서 암호화 키를 만들고 관리하려면 다음 옵션 중 하나를 선택합니다.

• 파트너 솔루션을 사용하여 키를 관리하는 경우 Cloud 외부 키 관리자를 사용합니다.
• 키를 온프레미스에서 관리하고 해당 키를 사용하여 Google Cloud의 데이터를 암호화하려면 키를 KMS 키 또는 하드웨어 키 모듈(HSM) 키로 Cloud KMS에 가져옵니다. 이러한 키를 사용하여 Google Cloud의 데이터를 암호화합니다.

데이터베이스 설계 및 확장

이 섹션에서는 시스템을 지원하기 위해 데이터베이스를 설계하고 확장하기 위한 권장사항을 제공합니다.

모니터링 측정항목을 사용하여 확장 요구사항 평가

기존 모니터링 도구 및 환경의 측정항목을 사용하여 데이터베이스 크기와 확장 요구사항(예: 데이터베이스 인스턴스의 크기 최적화 및 확장 전략 설계)에 대한 기본 지식을 설정합니다.

새 데이터베이스 설계의 경우 제공 애플리케이션의 예상 부하 및 트래픽 패턴을 기준으로 확장 수를 결정합니다. 자세한 내용은 Cloud SQL 인스턴스 모니터링, Cloud Monitoring으로 모니터링, 인스턴스 모니터링을 참조하세요.

네트워킹 및 액세스

이 섹션에서는 시스템을 지원하는 네트워킹 및 액세스 관리를 위한 권장사항을 제공합니다.

비공개 네트워크 내에서 데이터베이스 실행

비공개 네트워크 내에서 데이터베이스를 실행하고 데이터베이스와 상호작용해야 하는 클라이언트에서만 제한된 액세스 권한을 부여합니다. VPC 내에 Cloud SQL 인스턴스를 만들 수 있습니다. 또한 Google Cloud는 Cloud SQL용 VPC 서비스 제어, Spanner, Bigtable 데이터베이스를 제공하여 이러한 리소스에 대한 액세스가 승인된 VPC 네트워크 내에서 클라이언트로만 제한되도록 합니다.

사용자에게 최소 권한 부여

Identity and Access Management(IAM)는 데이터베이스 서비스를 포함한 Google Cloud 서비스에 대한 액세스를 제어합니다. 무단 액세스의 위험을 최소화하려면 사용자에게 최소한의 권한만 부여하세요. 데이터베이스에 대한 애플리케이션 수준 액세스의 경우 최소 권한 수가 지정된 서비스 계정을 사용합니다.

자동화 및 크기 조정

이 섹션에서는 시스템을 지원하기 위해 자동화 및 적절한 크기 조정을 정의하는 권장사항을 제공합니다.

데이터베이스 인스턴스를 코드로 정의

Google Cloud로 마이그레이션할 때의 이점 중 하나는 컴퓨팅 및 데이터베이스 레이어와 같은 인프라 및 워크로드의 다른 측면을 자동화하는 기능을 사용할 수 있다는 것입니다. Google 배포 관리자 및 Terraform Cloud와 같은 타사 도구를 사용하여 데이터베이스 인스턴스를 코드로 정의하면 데이터베이스를 만들고 업데이트할 때 일관되고 반복 가능한 방식을 적용할 수 있습니다.

Liquibase를 사용하여 데이터베이스 버전 제어

Cloud SQL 및 Spanner와 같은 Google 데이터베이스 서비스는 데이터베이스용 오픈소스 버전 제어 도구인 Liquibase를 지원합니다. Liquibase는 데이터베이스 스키마 변경사항을 추적하고 스키마 변경사항을 롤백하며 반복 가능한 마이그레이션을 수행할 수 있도록 지원합니다.

확장을 지원하기 위한 데이터베이스 테스트 및 조정

데이터베이스 인스턴스에서 로드 테스트를 수행하고 테스트 결과에 따라 애플리케이션 요구사항에 맞게 조정합니다. 핵심성과지표(KPI)에 대한 로드 테스트를 수행하거나 현재 데이터베이스에서 파생된 모니터링 KPI를 사용하여 데이터베이스의 초기 규모를 결정합니다.

데이터베이스 인스턴스를 만들 때 테스트 결과 또는 이전 모니터링 측정항목을 기반으로 하는 크기로 시작합니다. 클라우드에서 예상되는 로드를 사용하여 데이터베이스 인스턴스를 테스트합니다. 그런 다음 데이터베이스 인스턴스의 예상 로드에 대해 원하는 결과를 얻을 때까지 인스턴스를 미세 조정합니다.

확장 요구사항에 적합한 데이터베이스 선택

데이터베이스 확장과 컴퓨팅 레이어 구성요소 확장은 서로 다릅니다. 데이터베이스에는 상태가 존재합니다. 데이터베이스의 한 인스턴스가 로드를 처리할 수 없는 경우 데이터베이스 인스턴스를 확장하기 위한 적절한 전략을 고려합니다. 확장 전략은 데이터베이스 유형에 따라 다릅니다.

다음 표에서는 확장 사용 사례를 해결하는 Google 제품에 대해 자세히 알아볼 수 있습니다.

사용 사례	권장 제품	설명
제공 용량 및 스토리지를 확장해야 하는 경우 데이터베이스에 노드를 추가하여 수평으로 데이터베이스 인스턴스를 확장합니다.	Spanner	클라우드용으로 설계된 관계형 데이터베이스입니다.
노드를 추가하여 데이터베이스를 확장합니다.	Bigtable	완전 관리형 NoSQL 빅데이터 데이터베이스 서비스입니다.
데이터베이스 확장을 자동으로 처리합니다.	Firestore	모바일, 웹, 서버 개발을 위한 유연하고 확장 가능한 데이터베이스입니다.
더 많은 쿼리를 제공하려면 Cloud SQL 데이터베이스 인스턴스를 수직 확장하여 더 많은 컴퓨팅 및 메모리 용량을 확보합니다. Cloud SQL에서 스토리지 레이어는 데이터베이스 인스턴스와 분리됩니다. 스토리지 레이어가 용량에 도달할 때마다 자동으로 확장하도록 선택할 수 있습니다.	Cloud SQL	Google Cloud에서 관계형 데이터베이스를 설정, 유지, 관리할 수 있는 완전 관리형 데이터베이스 서비스입니다.

운영

이 섹션에서는 시스템을 지원하는 작업에 대한 권장사항을 제공합니다.

Cloud Monitoring을 사용하여 데이터베이스 알림 모니터링 및 설정

Cloud Monitoring을 사용하여 데이터베이스 인스턴스를 모니터링하고 적절한 이벤트 팀에 알림을 보내도록 설정합니다. 효율적인 알림 권장사항에 대한 자세한 내용은 효율적인 알림 설계를 참조하세요.

클라우드용으로 설계된 모든 데이터베이스는 로깅 및 모니터링 측정항목을 제공합니다. 각 서비스는 로깅 및 모니터링 측정항목을 시각화하는 대시보드를 제공합니다. 모든 서비스의 모니터링 측정항목은 Google Cloud 관측 가능성과 통합됩니다. Spanner는 디버깅 및 근본 원인 분석을 위해 Key Visualizer와 같은 쿼리 점검 도구를 제공합니다. Key Visualizer는 다음과 같은 기능을 제공합니다.

• 데이터베이스에 대한 시각적 보고서를 생성하여 Spanner 사용 패턴을 분석하는 데 도움을 줍니다. 보고서에는 시간 경과에 따른 행 범위별로 사용량 패턴이 표시됩니다.
• 대규모 사용 패턴에 대한 유용한 정보를 제공합니다.

Bigtable은 Bigtable 인스턴스 사용 패턴을 분석하는 데 도움이 되는 Key Visualizer 진단 도구도 제공합니다.

라이선스

이 섹션에서는 시스템을 지원하기 위한 라이선스 권장사항을 제공합니다.

주문형 라이선스와 기존 라이선스 중에서 선택

SQL Server용 Cloud SQL을 사용하는 경우 Bring Your Own License(사용자 라이선스 사용)는 지원되지 않습니다. 라이선스 비용은 코어별 시간당 사용량을 기준으로 합니다.

기존 SQL Server용 Cloud SQL 라이선스를 사용하려면 Compute VM에서 SQL Server용 Cloud SQL 실행을 고려합니다. 자세한 내용은 Microsoft 라이선스 및 주문형 라이선스와 기존 라이선스 가져오기 중에서 선택을 참조하세요.

Oracle을 사용하고 Oracle용 베어메탈 솔루션으로 마이그레이션하는 경우 Bring Your Own License(사용자 라이선스 사용) 적용이 가능합니다. 자세한 내용은 베어메탈 솔루션 계획을 참조하세요.

마이그레이션 타임라인, 방법론, 도구 세트

이 섹션에서는 시스템을 지원하기 위해 데이터베이스 마이그레이션을 계획하고 지원하는 권장사항을 제공합니다.

데이터베이스 현대화 준비 확인

조직에서 데이터베이스를 현대화하고 클라우드용으로 빌드된 데이터베이스를 사용할 준비가 되었는지 평가합니다.

현대화가 애플리케이션 측에 영향을 미칠 수 있으므로 워크로드 마이그레이션 타임라인을 계획할 때 데이터베이스 현대화를 고려합니다.

마이그레이션 계획의 관련 이해관계자 참여

데이터베이스를 마이그레이션하려면 다음 작업을 완료합니다.

• 대상 데이터베이스를 설정합니다.
• 스키마를 변환합니다.
• 소스 데이터베이스와 대상 데이터베이스 간의 데이터 복제를 설정합니다.
• 마이그레이션 중에 발생하는 문제를 디버깅합니다.
• 애플리케이션 레이어와 데이터베이스 간에 네트워크 연결을 설정합니다.
• 대상 데이터베이스 보안을 구현합니다.
• 애플리케이션이 대상 데이터베이스에 연결되어 있는지 확인합니다.

이러한 작업에는 종종 다른 기술 세트가 필요하고 여러 팀이 조직 내에서 공동작업을 진행하여 마이그레이션을 완료합니다. 마이그레이션을 계획할 때는 앱 개발자, 데이터베이스 관리자, 인프라 및 보안팀과 같은 모든 팀의 이해관계자를 포함합니다.

팀이 이러한 유형의 마이그레이션을 지원할 기술이 없는 경우 Google의 파트너가 마이그레이션을 수행할 수 있도록 지원합니다. 자세한 내용은 Google Cloud 파트너 어드밴티지를 참조하세요.

동종 및 이기종 마이그레이션을 위한 도구 세트 파악

동종 마이그레이션은 동일한 데이터베이스 기술의 소스 데이터베이스와 대상 데이터베이스 간의 데이터베이스 마이그레이션입니다. 이기종 마이그레이션은 대상 데이터베이스가 소스 데이터베이스와 다른 마이그레이션입니다.

이기종 마이그레이션에서는 일반적으로 소스 데이터베이스에서 대상 데이터베이스 엔진 유형으로 스키마 변환을 위한 추가 단계를 수행합니다. 데이터베이스팀은 소스 데이터베이스 스키마의 복잡성에 따라 스키마 변환과 관련된 문제를 평가해야 합니다.

데이터 마이그레이션의 각 단계 테스트 및 검증

데이터 마이그레이션에는 여러 단계가 포함됩니다. 마이그레이션 오류를 최소화하려면 다음 단계로 이동하기 전에 마이그레이션의 각 단계를 테스트하고 검증합니다. 마이그레이션 프로세스를 주도하는 요인은 다음과 같습니다.

• 마이그레이션이 동종 또는 이기종인지 여부
• 마이그레이션을 수행하는 데 필요한 도구 및 기술 유형
• 이기종 마이그레이션의 경우 대상 데이터베이스 엔진 사용 경험

지속적인 데이터 복제 요구사항 확인

데이터를 처음에 마이그레이션한 후 소스에서 대상 데이터베이스로 데이터를 지속적으로 복제하는 계획을 수립합니다. 대상이 안정화되고 애플리케이션이 새 데이터베이스로 완전히 마이그레이션될 때까지 복제를 계속합니다. 이 계획을 사용하면 데이터베이스 전환 중에 잠재적인 다운타임을 식별하고 이에 따라 계획할 수 있습니다.

Cloud SQL, MySQL용 Cloud SQL, PostgreSQL용 Cloud SQL에서 데이터베이스 엔진을 마이그레이션할 계획인 경우 Database Migration Service를 사용하여 완전 관리형 방식으로 이 프로세스를 자동화합니다. 다른 유형의 마이그레이션을 지원하는 타사 도구에 대한 자세한 내용은 Cloud Marketplace를 참조하세요.

권장사항

아키텍처 프레임워크의 안내 사항을 자신의 환경에 적용하려면 다음을 수행하는 것이 좋습니다.

• 데이터베이스의 멀티테넌시에는 공유 인프라(이 경우 데이터베이스)에 여러 고객의 데이터를 저장하는 작업이 포함됩니다. 고객에게 Software as a service(SaaS) 기반 서비스를 제공하는 경우 다양한 고객에게 속한 데이터 세트를 논리적으로 격리하고 액세스 요구사항을 지원하는 방법을 이해해야 합니다. 또한 분리 수준에 따라 요구사항을 평가합니다.

  Spanner 및 Cloud SQL과 같은 관계형 데이터베이스에는 데이터베이스 인스턴스 수준, 데이터베이스 수준, 스키마 수준, 데이터베이스 테이블 수준에서 테넌트의 데이터를 격리하는 것과 같은 여러 가지 접근 방법이 있습니다. 다른 설계 결정과 마찬가지로 격리 수준과 비용 및 성능과 같은 다른 요소 사이에 절충사항이 있습니다. IAM 정책은 데이터베이스 인스턴스에 대한 액세스를 제어합니다.

• 데이터 모델 요구사항에 맞는 데이터베이스를 선택합니다.

• 키 핫스팟을 방지하려면 키 값을 선택합니다. 핫스팟은 다른 위치보다 더 많은 액세스 요청을 받는 테이블 내 위치입니다. 핫스팟에 대한 자세한 내용은 스키마 설계 권장사항을 참조하세요.

• 가능하면 데이터베이스 인스턴스를 샤딩합니다.

• 연결 풀링 및 지수 백오프와 같은 연결 관리 권장사항을 사용합니다.

• 매우 큰 트랜잭션을 방지하세요.

• 데이터베이스의 유지보수 업데이트에 대한 애플리케이션의 응답을 설계하고 테스트합니다.

• 데이터베이스에 대한 연결을 보호하고 격리합니다.

• 데이터베이스가 요구사항을 지원하는지 확인하기 위해 데이터베이스 및 성장 기대치를 조정합니다.

• HA 및 DR 장애 조치 전략을 테스트합니다.

• 프로세스에 익숙해지도록 백업 및 복원뿐만 아니라 내보내기와 가져오기도 수행합니다.

Cloud SQL 권장사항

• 비공개 IP 주소 네트워킹(VPC)을 사용합니다. 추가 보안을 위해 다음 사항을 고려합니다.
  • Cloud SQL 인증 프록시를 사용하여 비공개 네트워킹을 지원합니다.
  • 공개 IP 주소 액세스(constraints/sql.restrictPublicIp)를 제한합니다.
• 공개 IP 주소 네트워킹이 필요한 경우 다음을 고려합니다.
  • 제한된 범위 또는 좁은 범위의 IP 주소 목록으로 기본 제공되는 방화벽을 사용합니다. Cloud SQL 인스턴스에는 수신 연결에 SSL을 사용해야 합니다. 자세한 내용은 SSL/TLS 인증서 구성을 참조하세요.
• 추가 보안을 위해 다음 사항을 고려합니다.
  • 일반 액세스 권한을 부여해서는 안 됩니다. 대신 Cloud SQL 인증 프록시를 사용해야 합니다.
  • 승인된 네트워크(constraints/sql.restrictAuthorizedNetworks)를 제한합니다.
• 데이터베이스 사용자에게 제한된 권한을 사용합니다.

다음 단계

다음을 포함한 데이터 분석 권장사항 알아보기

• 핵심 데이터 분석 원칙 및 주요 Google Cloud 서비스 알아보기
• 데이터 수명 주기 알아보기
• 데이터 수집 방법 알아보기
• 데이터 스토리지 선택 및 관리
• 데이터 처리 및 변환

아키텍처 프레임워크에서 안정성, 운영 우수성, 보안, 개인 정보 보호, 규정 준수 등의 다른 카테고리 살펴보기

데이터 분석

Google Cloud 아키텍처 프레임워크의 이 문서에서는 Google Cloud 데이터 분석과 관련된 핵심 원칙과 권장사항을 설명합니다. 주요 데이터 분석 서비스 몇 가지와 이 서비스가 데이터 수명 주기의 여러 단계에서 어떻게 도움이 되는지 알아보세요. 이러한 권장사항은 데이터 분석 요구사항을 충족하고 시스템 설계를 만드는 데 도움이 됩니다.

핵심 원칙

기업은 데이터를 분석하고 데이터에서 활용 가능한 분석 정보를 생성하려고 합니다. Google Cloud는 데이터 수집부터 보고서 및 시각화에 이르기까지 전체 데이터 수명 주기를 지원하는 다양한 서비스를 제공합니다. 이러한 서비스는 대부분 완전 관리형이며, 일부는 서버리스입니다. 또한 Compute Engine VM에서 자체 Apache Hadoop 또는 Beam 호스팅과 같은 데이터 분석 환경을 빌드하고 관리할 수 있습니다.

특정 관심 분야, 팀 전문성, 전략적 관점을 통해 데이터 분석 요구사항을 지원하는 데 채택할 Google Cloud 서비스를 결정할 수 있습니다. 예를 들어 Dataflow를 사용하면 서버리스 방식으로 복잡한 변환을 작성할 수 있지만 컴퓨팅 및 처리 요구사항을 위해서는 독단적인 구성 버전을 사용해야 합니다. 또는 Dataproc을 사용하여 동일한 변환을 실행할 수 있지만 클러스터를 관리하고 작업을 직접 세부 조정해야 합니다.

시스템 설계에서 추출, 변환, 로드(ETL) 또는 추출, 로드, 변환(ELT)과 같이 팀에서 사용하는 처리 전략을 고려하세요. 또한 시스템 설계 시 일괄 분석 또는 스트리밍 분석이 필요한지 여부를 고려해야 합니다. Google Cloud는 통합 데이터 플랫폼을 제공하며 이를 통해 비즈니스 요구를 충족하는 데이터 레이크 또는 데이터 웨어하우스를 구축할 수 있습니다.

주요 서비스

다음 표에서는 Google Cloud 분석 서비스의 대략적인 개요를 보여줍니다.

Google Cloud 서비스	설명
Pub/Sub	스트림 분석 및 이벤트 기반 컴퓨팅 시스템에 사용되는 간단하고도 안정적인 확장형 기반 서비스입니다.
Dataflow	스트림(실시간) 및 일괄(기록) 모드에서 데이터를 변환하고 강화하는 완전 관리형 서비스입니다.
Trifacta 제공 Dataprep	분석을 위해 구조화된 데이터와 구조화되지 않은 데이터를 시각적으로 탐색, 정리, 준비하는 지능형 데이터 서비스입니다.
Dataproc	Apache Spark 및 Apache Hadoop 클러스터를 실행하는 빠르고 사용하기 쉬운 완전 관리형 클라우드 서비스입니다.
Cloud Data Fusion	클라우드용으로 빌드된 완전 관리형 데이터 통합 서비스로, ETL/ELT 데이터 파이프라인을 구축하고 관리할 수 있습니다. Cloud DataFusion은 사전 구성된 커넥터 및 변환 기능이 담긴 광범위한 오픈소스 라이브러리와 그래픽 인터페이스를 제공합니다.
BigQuery	스토리지 및 컴퓨팅 요구 수준에 맞춰 확장 가능한 완전 관리형 저비용 서버리스 데이터 웨어하우스입니다. BigQuery는 테라바이트에서 페타바이트 단위에 이르는 데이터를 분석할 수 있는 열 형식의 ANSI SQL 데이터베이스입니다.
Cloud Composer	클라우드 및 온프레미스 데이터 센터 전체의 파이프라인을 작성, 예약, 모니터링할 수 있는 완전 관리형 워크플로 조정 서비스입니다.
Data Catalog	모든 데이터를 검색, 관리, 이해하는 데 도움이 되는 확장 가능한 완전 관리형 메타데이터 관리 서비스입니다.
Looker Studio	대화형 대시보드를 통해 데이터에서 유용한 정보를 얻는 데 도움이 되는 완전 관리형 시각적 분석 서비스입니다.
Looker	멀티 클라우드 환경에서 데이터를 연결, 분석, 시각화하는 엔터프라이즈 플랫폼입니다.
Dataform	데이터 파이프라인을 공동작업, 생성, 배포하고 데이터 품질을 보장하는 데 도움이 되는 완전 관리형 제품입니다.
Dataplex	일관된 제어를 통해 여러 데이터 레이크, 데이터 웨어하우스, 데이터 마트의 데이터를 중앙에서 관리, 모니터링, 통제하는 관리형 데이터 레이크 서비스입니다.
AnalyticsHub	조직 전체에서 데이터 분석 애셋을 효율적이고 안전하게 교환하여 데이터 안정성 및 비용 문제를 해결하는 플랫폼입니다.

데이터 수명 주기

시스템을 설계할 때 모든 시스템의 일반적인 데이터 이동 또는 데이터 수명 주기를 중심으로 Google Cloud 데이터 분석 서비스를 그룹화할 수 있습니다.

데이터 수명 주기에는 다음과 같은 단계 및 서비스(예시)가 포함됩니다.

• 수집에는 Pub/Sub, Storage Transfer Service, Transfer Appliance, BigQuery 등의 서비스가 포함됩니다.
• 저장에는 Cloud Storage, Bigtable, Memorystore, BigQuery 등의 서비스가 포함됩니다.
• 처리 및 변환에는 Dataflow, Dataproc, Dataprep, 민감한 정보 보호, BigQuery와 같은 서비스가 포함됩니다.
• 분석 및 웨어하우징에는 BigQuery와 같은 서비스가 포함됩니다.
• 보고 및 시각화에는 Looker Studio 및 Looker와 같은 서비스가 포함됩니다.

다음 단계 및 서비스는 전체 데이터 수명 주기에서 실행됩니다.

• 데이터 통합에는 Data Fusion과 같은 서비스가 포함됩니다.
• 메타데이터 관리 및 거버넌스에는 Data Catalog와 같은 서비스가 포함됩니다.
• 워크플로 관리에는 Cloud Composer와 같은 서비스가 포함됩니다.

데이터 수집

고유 환경에 다음 데이터 수집 권장사항을 적용합니다.

수집용 데이터 소스 결정

일반적으로 데이터는 다른 클라우드 제공업체나 서비스 또는 온프레미스 위치에서 가져옵니다.

• 다른 클라우드 제공업체의 데이터를 수집하려면 일반적으로 Cloud Data Fusion, Storage Transfer Service, BigQuery Transfer Service를 사용합니다.

• 온프레미스 데이터 수집의 경우 수집할 데이터 양과 팀의 역량을 고려하세요. 팀이 로우 코드 그래픽 사용자 인터페이스(GUI) 방식을 선호하는 경우 적절한 커넥터(예: 자바 데이터베이스 연결(JDBC))와 함께 Cloud Data Fusion을 사용합니다. 대용량 데이터의 경우 Transfer Appliance 또는 Storage Transfer Service를 사용할 수 있습니다.

데이터를 수집한 후 처리하는 방법을 고려합니다. 예를 들어 Storage Transfer Service는 Cloud Storage 버킷에만 데이터를 쓰고 BigQuery Data Transfer Service는 BigQuery 데이터 세트에만 데이터를 씁니다. Cloud Data Fusion은 여러 대상을 지원합니다.

스트리밍 또는 일괄 데이터 소스 식별

데이터를 사용해야 하는 방법을 고려하고 스트리밍 또는 일괄 사용 사례가 있는 위치를 파악합니다. 예를 들어 지연 시간이 짧은 글로벌 스트리밍 서비스를 실행하는 경우 Pub/Sub를 사용할 수 있습니다. 분석 및 보고용으로 데이터가 필요한 경우 BigQuery로 데이터를 스트리밍하면 됩니다.

온프레미스 또는 기타 클라우드 환경에서는 Apache Kafka와 같은 시스템에서 데이터를 스트리밍해야 하는 경우 Kafka to BigQuery Dataflow 템플릿을 사용합니다. 일괄 워크로드의 첫 번째 단계는 일반적으로 데이터를 Cloud Storage로 수집하는 것입니다. 데이터를 수집하려면 gsutil 도구 또는 Storage Transfer Service를 사용합니다.

자동화된 도구로 데이터 수집

다른 시스템에서 클라우드로 데이터를 수동으로 이동하는 것은 어려울 수 있습니다. 가능하면 데이터 수집 프로세스를 자동화하는 도구를 사용하세요. 예를 들어 Cloud Data Fusion은 드래그 앤 드롭 GUI를 사용하여 외부 소스의 데이터를 가져오는 커넥터와 플러그인을 제공합니다. 팀이 코드를 작성하려는 경우 Data Flow 또는 BigQuery가 데이터 수집을 자동화하는 데 도움이 될 수 있습니다. Pub/Sub는 로우 코드 또는 코드 우선 접근 방식 모두에 도움이 될 수 있습니다. 데이터를 스토리지 버킷으로 수집하려면 최대 1TB의 데이터 크기에 gsutil을 사용합니다. 1TB보다 큰 양의 데이터를 수집하려면 Storage Transfer Service를 사용합니다.

마이그레이션 도구를 사용하여 다른 데이터 웨어하우스에서 수집

Teradata, Netezza, Redshift와 같은 다른 데이터 웨어하우스 시스템에서 마이그레이션해야 하는 경우 BigQuery Data Transfer Service 마이그레이션 지원 기능을 사용할 수 있습니다. BigQuery Data Transfer Service는 외부 소스에서 일정에 따라 데이터를 수집하는 데 도움이 되는 타사 전송 기능도 제공합니다. 자세한 내용은 각 데이터 웨어하우스의 상세한 마이그레이션 접근 방식을 참조하세요.

데이터 수집 요구 예측

수집해야 하는 데이터의 볼륨은 시스템 설계에서 사용할 서비스를 결정하는 데 도움이 됩니다. 데이터의 스트리밍 수집을 위해 Pub/Sub는 초당 수십 기가바이트로 확장됩니다. 데이터의 용량, 스토리지, 리전 요구사항을 통해 Pub/Sub 라이트가 시스템 설계에 더 나은 옵션인지 결정할 수 있습니다. 자세한 내용은 Pub/Sub 또는 Pub/Sub 라이트 중 선택을 참조하세요.

데이터의 일괄 수집의 경우 총 전송 데이터 양과 전송 속도를 추정합니다. 예상 시간 및 온라인 전송과 오프라인 전송 비교를 포함한 사용 가능한 마이그레이션 옵션을 검토합니다.

적절한 도구를 사용하여 일정에 따라 데이터를 정기적으로 수집

Storage Transfer Service 및 BigQuery Data Transfer Service 모두 수집 작업을 예약할 수 있습니다. 수집 시점 또는 소스 및 대상 시스템을 세밀하게 제어하려면 Cloud Composer와 같은 워크플로 관리 시스템을 사용하세요. 보다 수동적인 방법을 원하는 경우 Cloud Scheduler 및 Pub/Sub를 사용하여 Cloud 함수를 트리거할 수 있습니다.
Compute 인프라를 관리하려면 크론과 함께 gsutil 명령어를 사용하여 최대 1TB의 데이터를 전송할 수 있습니다. Cloud Composer 대신 이 수동 방식을 사용하는 경우 프로덕션 전송 스크립팅 권장사항을 따르세요.

FTP/SFTP 서버 데이터 수집 요구사항 검토

FTP/SFTP 서버에서 데이터를 수집하는 코드 작성이 필요 없는 환경이 필요한 경우 FTP 복사 플러그인을 사용할 수 있습니다. 장기 워크플로 솔루션을 현대화하고 만들려고 할 때 사용하는 Cloud Composer는 다양한 소스 및 싱크에서 데이터를 읽고 쓸 수 있는 완전 관리형 서비스입니다.

Apache Kafka 커넥터를 사용하여 데이터 수집

Pub/Sub, Dataflow 또는 BigQuery를 사용하는 경우 Apache Kafka 커넥터 중 하나를 사용하여 데이터를 수집할 수 있습니다. 예를 들어 오픈소스 Pub/Sub Kafka 커넥터를 사용하면 Pub/Sub 또는 Pub/Sub 라이트에서 데이터를 수집할 수 있습니다.

추가 리소스

• Cloud Storage Transfer Service 에이전트 권장사항
• 분석할 수 있도록 BigQuery로 데이터를 수집하는 방법
• Cloud Data Fusion으로 임상 및 운영 데이터 수집
• 분석 이벤트 및 로그의 대규모 수집 최적화

데이터 스토리지

다음 데이터 스토리지 권장사항을 자체 환경에 적용합니다.

필요에 맞는 데이터 저장소 선택

사용할 스토리지 솔루션 유형을 선택하는 데 도움이 되도록 데이터의 다운스트림 사용량을 검토하고 이해합니다. 다음과 같은 일반적인 사용 사례는 사용할 Google Cloud 제품을 권장합니다.

데이터 사용 사례	제품 추천
파일 기반	Filestore
객체 기반	Cloud Storage
짧은 지연 시간	Bigtable
시계열	Bigtable
온라인 캐시	Memorystore
트랜잭션 처리	Cloud SQL
비즈니스 인텔리전스(BI) 및 분석	BigQuery
일괄 처리	Cloud Storage 수신 데이터가 시계열이고 데이터에 대한 지연 시간이 짧은 액세스가 필요한 경우 Bigtable SQL을 사용하는 경우 BigQuery

데이터 구조 요구 검토

문서 및 텍스트 파일, 오디오 및 동영상 파일, 로그 등 대부분의 구조화되지 않은 데이터에서는 객체 기반 저장소가 가장 적합합니다. 그런 후 필요한 경우 객체 스토리지에서 데이터를 로드하고 처리할 수 있습니다.

XML 또는 JSON과 같은 반구조화된 데이터의 경우 사용 사례 및 데이터 액세스 패턴을 통해 선택할 수 있습니다. 자동 스키마 감지를 위해 이러한 데이터세트를 BigQuery에 로드할 수 있습니다. 지연 시간 요구사항이 낮다면 Bigtable에 JSON 데이터를 로드할 수 있습니다. 기존 요구사항이 있거나 애플리케이션이 관계형 데이터베이스로 작동하는 경우 데이터 세트를 관계 저장소에 로드할 수도 있습니다.

CSV, Parquet, Avro 또는 ORC와 같은 구조화된 데이터의 경우 SQL을 사용하는 BI 및 분석 요구사항이 있으면 BigQuery를 사용할 수 있습니다. 자세한 내용은 데이터 일괄 로드 방법을 참조하세요. 개방형 표준 및 기술에 대한 데이터 레이크를 만들기 위해 Cloud Storage를 사용할 수 있습니다.

HDFS의 데이터 마이그레이션 및 비용 절감

Hadoop 분산 파일 시스템(HDFS) 데이터를 온프레미스 또는 다른 클라우드 제공업체에서 더 저렴한 객체 스토리지 시스템으로 이동하는 방법을 찾습니다. 기업이 선택하는 가장 일반적인 대체 데이터 저장소는 Cloud Storage입니다. 이 선택의 장점과 단점에 대한 자세한 내용은 HDFS와 Cloud Storage 비교를 참조하세요.

push 또는 pull 메서드를 사용하여 데이터를 이동할 수 있습니다. 두 메서드 모두 hadoop distcp 명령어를 사용합니다. 자세한 내용은 온프레미스에서 Google Cloud로 HDFS 데이터 마이그레이션을 참조하세요.

오픈소스 Cloud Storage 커넥터를 사용하여 Hadoop 및 Spark 작업이 Cloud Storage의 데이터에 액세스하도록 할 수도 있습니다. 커넥터는 기본적으로 Dataproc 클러스터에 설치되며 다른 클러스터에 수동으로 설치할 수 있습니다.

객체 스토리지를 사용하여 통합 데이터 레이크 구축

데이터 레이크는 구조화되거나 반구조화되거나 구조화되지 않은 대량의 데이터를 저장, 처리, 보호하기 위한 중앙 집중식 저장소입니다. Cloud Composer 및 Cloud Data Fusion을 사용하여 데이터 레이크를 구축할 수 있습니다.

최신 데이터 플랫폼을 빌드하기 위해 Cloud Storage 대신 BigQuery를 중앙 데이터 소스로 사용할 수 있습니다. BigQuery는 스토리지와 컴퓨팅의 분리가 있는 최신 데이터 웨어하우스입니다. BigQuery를 기반으로 구축된 데이터 레이크를 사용하면 Cloud Console의 BigQuery에서 기존의 분석을 수행할 수 있습니다. 또한 Apache Spark와 같은 다른 프레임워크에서 저장된 데이터에 액세스할 수 있습니다.

추가 리소스

• Cloud Storage 권장사항
• Cloud Storage 비용 최적화 권장사항
• Cloud Storage에서 데이터의 개인정보 보호 및 보안을 위한 권장사항
• Memorystore 권장사항
• BigQuery에서 스토리지 최적화
• Bigtable 스키마 디자인

데이터 처리 및 변환

데이터를 처리하고 변환할 때 자체 환경에 다음 데이터 분석 권장사항을 적용합니다.

Google Cloud에서 사용할 수 있는 오픈소스 소프트웨어 살펴보기

많은 Google Cloud 서비스가 오픈소스 소프트웨어를 사용하여 원활한 전환을 지원합니다. Google Cloud는 Open API가 있고 오픈소스 프레임워크와 호환되어 공급업체 종속을 줄이는 관리형 서버리스 솔루션을 제공합니다.

Dataproc은 운영 부담이 거의 없는 오픈소스 소프트웨어를 호스팅할 수 있는 Hadoop 호환 관리형 서비스입니다. Dataproc은 Spark, Hive, Pig, Presto, Zookeeper를 지원합니다. 또한 관리형 서비스로 Hive 메타스토어를 사용하여 Hadoop 생태계에서 단일 장애점으로 자신을 삭제합니다.

현재 Apache Beam을 일괄 및 스트리밍 처리 엔진으로 사용하는 경우 Dataflow로 마이그레이션할 수 있습니다. Dataflow는 Apache Beam을 사용하는 완전 관리형 서버리스 서비스입니다. Dataflow를 사용하여 Beam에 작업을 기록하되 Google Cloud는 실행 환경을 관리하도록 할 수 있습니다.

CDAP를 데이터 통합 플랫폼으로 사용하는 경우 완전 관리형 환경을 위해 Cloud Data Fusion으로 마이그레이션할 수 있습니다.

ETL 또는 ELT 데이터 처리 요구사항 확인

팀의 경험과 선호도는 데이터 처리 방법에 대한 시스템 설계를 결정하는 데 도움이 됩니다. Google Cloud에서는 기존 ETL 또는 최신 ELT 데이터 처리 시스템을 사용할 수 있습니다.

• ETL 파이프라인의 경우 Data Fusion, Dataproc, Dataflow를 사용할 수 있습니다.

  • 새 환경의 경우 일괄 및 스트리밍 애플리케이션을 통합하기 위한 방법으로 Dataflow를 사용하는 것이 좋습니다.
  • 완전 관리형 방법의 경우 Data Fusion은 파이프라인을 만드는 데 도움이 되는 드래그 앤 드롭 GUI를 제공합니다.

• ELT 파이프라인의 경우 일괄 및 스트리밍 데이터 로드를 모두 지원하는 BigQuery를 사용합니다. 데이터가 BigQuery에 있으면 모든 변환을 수행하는 SQL을 사용하여 비즈니스 사용 사례에 대한 새 데이터세트를 파생합니다.

• ETL에서 ELT로 이전하려는 경우 Dataform을 사용할 수 있습니다.

데이터 사용 사례에 적합한 프레임워크 사용

데이터 사용 사례에 따라 사용할 도구 및 프레임워크가 결정됩니다. 일부 Google Cloud 제품은 다음과 같은 데이터 사용 사례를 모두 처리하도록 빌드되었지만 나머지는 하나의 특정 사용 사례만 지원하는 것이 좋습니다.

• 일괄 데이터 처리 시스템의 경우 익숙한 SQL 인터페이스를 통해 BigQuery에서 데이터를 처리하고 변환할 수 있습니다. Apache Hadoop이나 Spark 온프레미스 또는 다른 퍼블릭 클라우드에서 실행되는 기존 파이프라인이 있는 경우 Dataproc을 사용할 수 있습니다.
  • 일괄 및 스트리밍 사용 사례 모두에 통합 프로그래밍 인터페이스가 필요한 경우에는 Dataflow를 사용할 수도 있습니다. ETL에는 Dataflow를, ELT에는 BigQuery를 현대화하고 사용하는 것이 좋습니다.

• 스트리밍 데이터 파이프라인의 경우 기간 설정, 자동 확장, 템플릿을 제공하는 Dataflow와 같은 관리형 및 서버리스 서비스를 사용합니다. 자세한 내용은 Dataflow를 사용하여 프로덕션에 즉시 사용 가능한 데이터 파이프라인 빌드를 참조하세요.

  • 분석과 SQL 중심의 팀 및 역량이 있다면 BigQuery로 데이터를 스트리밍할 수도 있습니다.

• 시계열 분석 또는 스트리밍 동영상 분석과 같은 실시간 사용 사례에서는 Dataflow를 사용합니다.

실행 엔진에 대한 향후 제어 유지

공급업체 종속을 최소화하고 향후 다른 플랫폼을 사용할 수 있도록 하려면 관리형 서버리스 솔루션으로 Apache Beam 프로그래밍 모델 및 Dataflow를 사용합니다. Beam 프로그래밍 모델을 사용하면 Dataflow에서 Apache Flink 또는 Apache Spark로 변경하는 등 기본 실행 엔진을 변경할 수 있습니다.

Dataflow를 사용하여 여러 소스의 데이터 수집

Pub/Sub, Cloud Storage, HDFS, S3, Kafka와 같은 여러 소스의 데이터를 수집하려면 Dataflow를 사용하세요. Dataflow는 Dataflow 템플릿을 지원하는 관리형 서버리스 서비스로 팀이 다양한 도구에서 템플릿을 실행할 수 있도록 합니다.

Dataflow Prime은 파이프라인 실행 프로세스에 사용되는 머신의 수평 및 수직 자동 확장을 제공합니다. 또한 문제를 식별하고 해결 방법을 제안하는 스마트 진단 및 권장사항을 제공합니다.

민감한 정보 검색, 식별, 보호

민감한 정보 보호를 사용하여 구조화된 데이터와 구조화되지 않은 데이터를 검사하고 변환합니다. 민감한 정보 보호는 Cloud Storage 또는 데이터베이스 등 Google Cloud 내에 위치한 데이터에 사용할 수 있습니다. 민감한 정보를 분류, 마스킹, 토큰화하여 다운스트림 처리에 안전하게 사용할 수 있습니다. 민감한 정보 보호를 사용하여 BigQuery 데이터 스캔 또는 대규모 데이터 세트에서 PII 익명화와 같은 작업을 수행합니다.

데이터 변환 프로세스 현대화

Dataform을 사용하여 데이터 변환을 코드로 작성하고 기본적으로 버전 제어 사용을 시작합니다. 또한 CI/CD, 단위 테스트, 버전 제어와 같은 소프트웨어 개발 권장사항을 SQL 코드에 채택할 수 있습니다. Dataform은 PostgreSQL과 같은 모든 주요 클라우드 데이터 웨어하우스 제품과 데이터베이스를 지원합니다.

추가 리소스

• Dataproc
  • 권장사항 가이드
  • 장기 실행 클러스터를 위한 팁
  • Dataproc에서 Apache Hive 사용
  • 프로덕션 실행 권장사항
  • Apache Ranger 사용 권장사항
  • 자동 확장 구성 권장사항
  • 느린 Hadoop/Spark 작업 지원
• Dataflow
  • 파이프라인을 프로덕션으로 이전
  • 일반 사용 사례
• Data Fusion
  • 파이프라인 성능
• BigQuery
  • 쿼리 성능 최적화
• Dataform
  • 프로젝트 관리 권장사항
• 민감한 정보 보호
  • 비용을 적절하게 유지
  • 스토리지 및 데이터베이스에서 민감한 정보 검사
  • 텍스트에서 민감한 정보 검사

데이터 분석 및 웨어하우스

다음 데이터 분석 및 웨어하우스 권장사항을 자체 환경에 적용합니다.

데이터 스토리지 요구 검토

데이터 레이크와 데이터 웨어하우스는 상호 배타적이지 않습니다. 데이터 레이크는 구조화되지 않은 또는 반구조화된 데이터 스토리지 및 처리에 유용합니다. 데이터 웨어하우스는 분석 및 BI에 가장 적합합니다.

데이터 요구를 검토하여 데이터를 저장할 위치와 데이터를 처리 및 분석하는 가장 적합한 Google Cloud 제품을 결정합니다. BigQuery와 같은 제품은 PB 데이터를 처리하고 수요에 따라 확장할 수 있습니다.

기존 데이터 웨어하우스에서 BigQuery로 마이그레이션할 기회 포착

현재 환경에서 현재 사용 중인 기존 데이터 웨어하우스를 검토합니다. 복잡성을 줄이고 비용을 절감하려면 기존 데이터 웨어하우스를 BigQuery와 같은 Google Cloud 서비스로 마이그레이션할 기회를 찾으세요. 자세한 내용과 시나리오 예시는 BigQuery로 데이터 웨어하우스 마이그레이션을 참조하세요.

데이터에 대한 제휴 액세스 계획

데이터 요구사항 및 다른 제품 및 서비스와 상호작용하는 방법을 검토합니다. 데이터 제휴 요구를 확인하고 적절한 시스템 설계를 만듭니다.

예를 들어 BigQuery를 사용하면 Bigtable, Cloud SQL, Cloud Storage, Google Drive와 같은 다른 소스에서 데이터를 읽을 수 있는 외부 테이블을 정의할 수 있습니다. 이러한 외부 소스를 BigQuery에 저장하는 테이블과 조인할 수 있습니다.

BigQuery 가변 슬롯을 사용하여 주문형 버스트 용량 제공

많은 컴퓨팅 리소스가 필요한 실험용 또는 탐색 분석을 수행하기 위해 추가 용량이 필요한 경우가 있습니다. BigQuery를 사용하면 추가 컴퓨팅 용량을 가변 슬롯 형태로 가져올 수 있습니다. 이러한 가변 슬롯은 수요가 많은 기간이나 중요한 분석을 완료하고 싶을 때 유용합니다.

BigQuery로 마이그레이션하는 경우의 스키마 차이점 이해

BigQuery는 별표 및 눈송이 스키마를 모두 지원하지만 기본적으로 중첩 및 반복 필드를 사용합니다. 중첩 및 반복 필드는 다른 스키마와 비교할 때 읽기 및 상관관계 지정이 더 쉽습니다. 데이터가 별표 또는 눈송이 스키마로 표시되고 BigQuery로 마이그레이션하려면 시스템 설계에서 프로세스 또는 분석에 필요한 변경사항이 있는지 검토합니다.

추가 리소스

• BigQuery의 멀티 테넌트 워크로드 권장사항
• BigQuery의 행 수준 보안 권장사항
• BigQuery의 구체화된 뷰 권장사항

보고서 및 시각화

고유 환경에 다음 보고 및 시각화 권장사항을 적용합니다.

BigQuery BI Engine을 사용한 데이터 시각화

BigQuery BI Engine은 신속한 인메모리 분석 서비스입니다. BI Engine을 사용하여 1초 미만의 쿼리 응답 시간과 높은 동시 실행으로 BigQuery에 저장된 데이터를 분석할 수 있습니다. BI Engine은 BigQuery API에 통합되어 있습니다. 예약된 BI Engine 용량을 사용하여 필요에 맞게 주문형 또는 정액제를 관리합니다. BI Engine은 1초 미만의 응답 시간이 필요한 다른 BI 또는 커스텀 대시보드 애플리케이션과 작동할 수 있습니다.

Looker를 사용하여 BI 프로세스 현대화

Looker는 BI, 데이터 애플리케이션, 임베디드 분석을 위한 최신 엔터프라이즈 플랫폼입니다. 데이터의 속도와 정확성으로 일관된 데이터 모델을 만들 수 있으며, 트랜잭션 및 분석 데이터 저장소 내의 데이터에 액세스할 수 있습니다. Looker는 여러 데이터베이스 및 클라우드에서 데이터를 분석할 수도 있습니다. 기존 BI 프로세스 및 도구가 있는 경우 Looker와 같은 중앙 플랫폼을 현대화하고 사용하는 것이 좋습니다.

추가 리소스

• 데이터 웨어하우스를 BigQuery로 마이그레이션: 보고 및 분석
• Google Cloud에서 실행되는 Hadoop에 시각화 소프트웨어를 연결하기 위한 아키텍처
• BI Engine을 사용하여 BigQuery에서 작은 쿼리 속도 향상

워크플로 관리 도구 사용

데이터 분석에는 다양한 프로세스와 서비스가 포함됩니다. 데이터는 데이터 분석 수명 주기 동안 여러 도구와 처리 파이프라인에서 이동합니다. 엔드 투 엔드 데이터 파이프라인을 관리하고 유지보수하려면 적절한 워크플로 관리 도구를 사용합니다. Cloud Composer는 오픈소스 Apache Airflow 프로젝트를 기반으로 하는 완전 관리형 워크플로 관리 도구입니다.

Cloud Composer를 사용하여 Dataflow 파이프라인을 실행하고 Dataproc 워크플로 템플릿을 사용할 수 있습니다. Cloud Composer는 DAG를 테스트, 동기화, 배포하는 CI/CD 파이프라인을 만들거나 또는 데이터 처리 워크플로를 위한 CI/CD 파이프라인 사용할 때도 도움이 될 수 있습니다. 자세한 내용은 Cloud Composer: 개발 권장사항을 참조하세요.

마이그레이션 리소스

데이터 분석 플랫폼을 이미 실행하고 있고 워크로드의 일부 또는 전부를 Google Cloud로 마이그레이션하려면 다음 마이그레이션 리소스를 살펴보고 권장사항과 안내를 확인하세요.

• 일반 마이그레이션 안내
  • Google Cloud로의 마이그레이션: 마이그레이션 경로 선택
  • Twitter의 광고 참여 분석 플랫폼 현대화 예시
• Cloud Storage 마이그레이션
  • 온프레미스에서 Google Cloud로 HDFS 데이터 마이그레이션
  • VPC 서비스 제어 및 Storage Transfer Service를 사용하여 Amazon S3에서 Cloud Storage로 데이터 전송
• Pub/Sub 마이그레이션
  • Kafka에서 Pub/Sub로 마이그레이션
• Bigtable 마이그레이션
  • HBase에서 Bigtable로 데이터 마이그레이션
  • Aerospike에서 Bigtable로 마이그레이션
• Dataproc 마이그레이션
  • Google Cloud로 온프레미스 Hadoop 인프라 마이그레이션
  • Hadoop 마이그레이션 비용 및 팁
  • Dataproc에 대한 Hadoop
  • Dataproc에 대한 온프레미스 Hadoop 작업
  • Dataproc에 대한 Apache Spark
  • Dataproc Metastore에 대한 외부 Hive Metastore
• BigQuery 마이그레이션
  • 기존 데이터 웨어하우스 마이그레이션의 과제
  • BigQuery로 데이터 웨어하우스 마이그레이션
  • 데이터 웨어하우스 전문가를 위한 BigQuery
• Composer 마이그레이션
  • Airflow 2로 환경 마이그레이션

다음 단계

다음을 포함하여 Google Cloud AI 및 머신러닝의 시스템 설계 권장사항에 대해 알아보세요.

• 시스템 설계를 지원하는 Google Cloud AI 및 머신러닝 서비스에 대해 알아보기
• ML 데이터 처리 권장사항 알아보기
• 모델 개발 및 학습 권장사항 알아보기

아키텍처 프레임워크에서 안정성, 운영 우수성, 보안, 개인 정보 보호, 규정 준수 등의 다른 카테고리 살펴보기

머신러닝 구현

Google Cloud 아키텍처 프레임워크의 이 문서에서는 Google Cloud 데이터 분석과 관련된 핵심 원칙과 권장사항을 설명합니다. 주요 AI 및 머신러닝(ML) 서비스가 무엇이고 AI 및 ML 수명 주기의 각 단계에서 어떤 도움을 얻을 수 있는지 알아보세요. 이러한 권장사항은 AI 및 ML 요구사항을 충족하고 시스템 설계를 만드는 데 도움이 됩니다. 이 문서에서는 사용자가 기본 AI 및 ML 개념에 익숙하다고 가정합니다.

Google Cloud에서 ML 모델을 빌드할 때 개발 프로세스를 단순화하고 오버헤드를 최소화하려면 사용 사례에 맞는 가장 높은 추상화 수준을 고려하세요. 추상화 수준은 시스템을 확인 또는 프로그래밍하는 복잡성 정도에 따라 정의됩니다. 추상화 수준이 높을수록 사용자에게 제공되는 세부정보 수준이 낮아집니다.

비즈니스 요구에 맞게 Google AI 및 ML 서비스를 선택하려면 다음 테이블을 사용합니다.

개성	Google 서비스
비즈니스 사용자	Contact Center AI Insights, Document AI ,Discovery AI, Cloud Healthcare API와 같은 표준 솔루션입니다.
최소한의 ML 경험이 있는 개발자	사전 학습된 API가 비전, 비디오, 자연어와 같은 일반적인 개념적 태스크를 처리합니다. 이러한 API는 사전 학습된 모델에서 지원되며 기본 감지기를 제공합니다. ML 전문 기술 또는 모델 개발 작업 없이 즉시 사용할 수 있습니다. 사전 학습된 API에는 Vision API, Video API, Natural Language API, Speech-to-Text API, Text-to-Speech API, Cloud Translation API가 포함됩니다.
개발자용 생성형 AI	Vertex AI Search and Conversation를 통해 개발자는 즉시 사용 가능한 기능으로 몇 분 만에 챗봇을 몇 시간 만에 검색엔진을 빌드하고 배포할 수 있습니다. 여러 기능을 엔터프라이즈 워크플로에 결합하려는 개발자는 직접 통합에 Gen App Builder API를 사용할 수 있습니다.
개발자 및 데이터 과학자	AutoML은 고유 이미지, 비디오, 텍스트, 표형식 데이터로 커스텀 모델 개발을 지원합니다. AutoML은 가장 성능이 뛰어난 모델 아키텍처의 Google 모델군을 통한 자동 검색으로 모델 개발을 가속화하므로, 모델을 빌드할 필요가 없습니다. AutoML은 모델 아키텍처 선택, 초매개변수 조정, 학습 및 제공을 위한 머신 프로비저닝 등의 일반적인 태스크를 처리합니다.
데이터 과학자 및 ML 엔지니어	Vertex AI 커스텀 모델 도구는 커스텀 모델 학습 및 제공을 도와주고 ML 워크플로를 운영화합니다. 또한 Compute Engine VM과 같은 자체 관리형 컴퓨팅으로 ML 워크로드를 실행할 수 있습니다.
데이터 과학자 및 머신러닝 엔지니어	Vertex AI의 생성형 AI 지원(genai이라고도 함)은 Google의 대규모 생성형 AI 모델에 액세스할 수 있으므로 AI 기반 애플리케이션에서 모델을 테스트, 조정, 배포할 수 있습니다.
SQL 인터페이스에 익숙한 데이터 엔지니어, 데이터 과학자, 데이터 분석가	BigQuery ML을 통해 BigQuery에 저장된 데이터 위에서 SQL 기반 모델을 개발할 수 있습니다.

주요 서비스

다음 표에서는 AI 및 ML 서비스에 대한 상위 수준의 개요를 제공합니다.

Google 서비스	설명
Cloud Storage 및 BigQuery	머신러닝 데이터 및 아티팩트에 대해 유연한 스토리지 옵션을 제공합니다.
BigQuery ML	BigQuery 내에서 제공되는 데이터에서 직접 머신러닝 모델을 빌드할 수 있습니다.
Pub/Sub, Dataflow, Cloud Data Fusion, Dataproc	일괄 및 실시간 데이터 수집 및 처리를 지원합니다. 자세한 내용은 데이터 분석을 참조하세요.
Vertex AI	데이터 과학자와 머신러닝 엔지니어가 생성형 AI부터 MLOps에 이르는 모든 ML 모델을 생성, 학습, 테스트, 모니터링, 조정, 배포할 수 있는 단일 플랫폼을 제공합니다. 도구에는 다음이 포함됩니다. 정확한 데이터 라벨을 가져오기 위한 Vertex Data Labelling 이동 가능하고 일관적인 환경에서 모델을 빌드 및 배포하기 위한 Deep Learning Containers 관리형 또는 사용자 관리형 JupyterLab 환경을 위한 Vertex AI Workbench 완전 관리형 학습 서비스를 위한 Vertex Training 실험 추적을 위한 Vertex AI TensorBoard 초매개변수 조정을 위한 Vertex AI Vizier 커스텀 학습된 BigQuery ML, AutoML 모델을 지원하는 통합 배포 프레임워크를 위한 Vertex Prediction 모델 예측을 위한 설명을 제공하는 Vertex Explainable AI 프로덕션으로의 모델 배포 가속화를 위한 Vertex Experiments 이제 모델을 더 빠르게 선택할 수 있습니다. 조정을 위한 Vertex AI Pipelines와 완전 관리형 특성 저장소를 위한 Vertex AI Feature Store와 같은 MLOps 도구
Vertex AI Search and Conversation	웹사이트 및 기업 데이터 전반에 사용할 수 있는 챗봇 및 검색엔진을 빌드할 수 있습니다. Vertex AI Search and Conversation의 대화형 AI는 생성 가능한 AI 기반 챗봇 및 디지털 어시스턴트와의 고객 및 직원 상호작용을 재창조하는 데 도움이 될 수 있습니다. 예를 들어 이러한 도구를 사용하면 채팅 환경 내에서 트랜잭션을 사용 설정하여 단순한 정보 그 이상의 다양한 정보를 제공할 수 있습니다. Vertex AI Search and Conversation에서 엔터프라이즈 검색을 사용하면 기업이 공개 또는 비공개 웹사이트에서 고객과 직원을 위한 검색 환경을 구축할 수 있습니다. 고품질 멀티모달 검색 결과를 제공할 뿐만 아니라 엔터프라이즈 검색은 결과를 요약하고 생성형 AI를 사용하여 해당 인용을 제공할 수 있습니다.
Vertex AI의 생성형 AI	Google의 대규모 생성 AI 모델에 대한 액세스 권한을 제공하므로 AI 기반 애플리케이션에서 사용할 수 있도록 테스트, 조정, 배포할 수 있습니다. Vertex AI의 생성형 AI는 genai라고도 합니다. 기반 모델이라고도 하는 생성형 AI 모델은 생성하도록 설계된 콘텐츠 유형에 따라 분류됩니다. 이러한 콘텐츠에는 텍스트 및 채팅, 이미지, 코드, 텍스트 임베딩이 포함됩니다. Vertex AI Studio를 사용하면 Google Cloud 콘솔에서 생성형 AI 모델을 신속하게 프로토타입으로 제작하고 테스트할 수 있습니다. 샘플 프롬프트를 테스트하고 고유 프롬프트를 설계하고 기반 모델을 맞춤설정하여 애플리케이션의 요구사항을 충족하는 태스크를 처리할 수 있습니다. Model Tuning - 입력 출력 예시의 데이터 세트로 모델을 조정하여 특정 사용 사례에 맞게 기반 모델을 맞춤설정할 수 있습니다. Model Garden은 엔터프라이즈 지원 기반 모델, 작업별 모델, API를 제공합니다.
사전 학습된 API	사전 학습된 API에는 Vision API, Video API, Natural Language API, Speech-to-Text API, Text-to-Speech API, Cloud Translation API가 포함됩니다.
AutoML	ML 모델을 빌드, 배포, 확장하기 위한 커스텀 모델 도구를 제공합니다. 개발자는 자신의 고유 데이터를 업로드하고 적용 가능한 AutoML 서비스를 사용하여 커스텀 모델을 빌드할 수 있습니다. AutoML Image: 이미지 데이터에 대해 이미지 분류 및 객체 감지를 수행합니다. AutoML Video: 비디오 데이터에 대해 객체 감지, 분류, 작업 인식을 수행합니다. AutoML Text: 텍스트 데이터에 대해 언어 분류, 항목 추출, 감정 분석을 수행합니다. AutoML Translation: 언어 쌍 간의 감지 및 번역을 수행합니다. AutoML Tabular: 회귀, 분류, 예측 모델을 빌드할 수 있습니다. 구조화된 데이터에 사용됩니다.
AI 인프라	AI 가속기를 사용하여 대규모 ML 워크로드를 처리할 수 있습니다. 이러한 가속기를 통해 비용 효율적인 방식으로 딥 러닝 모델 및 머신러닝 모델에 대한 학습 및 추론을 수행할 수 있습니다. GPU는 딥 러닝 모델에 대한 비용 효율적인 추론 및 수직 확장 또는 수평 확장 학습을 지원할 수 있습니다. Tensor Processing Unit(TPU)은 심층신경망을 학습시키고 실행할 수 있도록 커스텀 빌드된 ASIC입니다.
Dialogflow	대화형 경험을 제공하는 가상 에이전트를 제공합니다.
Contact Center AI	상담사를 위해 Agent Assist 기능이 포함된 자동화되고 인사이트가 지원되는 연락 센터 경험을 제공합니다.
Document AI	대출 및 조달 관련 문서와 같은 특정 문서 유형과 일반적인 문서에 대한 대규모 문서 인식 기능을 제공합니다.
Lending DocAI	주택담보대출 관련 문서 처리를 자동화합니다. 규제 및 규정 준수 요구사항을 지원하면서 처리 시간을 줄이고 데이터 캡처를 효율화합니다.
Procurement DocAI	인보이스 및 영수증 등의 구조화되지 않은 문서를 구조화된 데이터로 변환하여 대규모 조달 데이터 캡처를 자동화하면 운영 효율성을 높이고 고객 경험을 개선하며 정보에 입각한 의사 결정을 지원할 수 있습니다.
권장사항	맞춤설정된 제품 권장사항을 제공합니다.
Healthcare Natural Language AI	의료 문서를 검토 및 분석할 수 있습니다.
Media Translation API	오디오 데이터로부터 실시간 음성 번역을 지원합니다.

데이터 처리

자체 환경에 데이터 처리 권장사항을 적용합니다.

데이터가 ML 요구사항을 충족하는지 확인합니다.

ML에 사용되는 데이터는 데이터 유형에 관계없이 특정 기본 요구사항을 충족해야 합니다. 이러한 요구사항에는 대상을 예측하는 데이터 기능, 학습에 사용되는 데이터와 예측에 사용되는 데이터 사이의 세분성에 대한 일관성, 학습을 위해 정확하게 레이블 지정된 데이터가 포함됩니다. 데이터는 볼륨도 충분해야 합니다. 자세한 내용은 데이터 처리를 참조하세요.

BigQuery에 표 형식 데이터 저장

표 형식 데이터를 사용하는 경우 모든 데이터를 BigQuery에 저장하고, BigQuery Storage API를 사용하여 여기에서 데이터를 읽을 수 있습니다. API와의 상호작용을 단순화하기 위해서는 데이터를 읽으려는 위치에 따라 다음 추가적인 도구 옵션 중 하나를 사용합니다.

• Dataflow를 사용하는 경우 BigQuery I/O 커넥터를 사용합니다.
• TensorFlow 또는 Keras를 사용하는 경우 BigQuery용 tf.data.dataset 리더를 사용합니다.
• 이미지 또는 비디오와 같은 구조화되지 않은 데이터를 사용하는 경우에는 모든 데이터를 Cloud Storage에 저장하는 것이 좋습니다.

또한 입력 데이터 유형에 따라 사용 가능한 모델 개발 도구가 결정됩니다. 사전 학습된 API, AutoML, BigQuery ML은 특정 이미지, 비디오, 텍스트, 구조화된 데이터 사용 사례에 대해 보다 비용 효율적이고 시간 효율적인 개발 환경을 제공할 수 있습니다.

ML 모델 개발을 위해 데이터가 충분한지 확인

유용한 ML 모델을 개발하기 위해서는 충분한 데이터가 필요합니다. 카테고리를 예측하기 위해 각 카테고리에 권장되는 예시 수는 특성 수의 10배에 해당합니다. 예측할 카테고리가 많을수록 필요한 데이터도 많습니다. 게다가 균형적이지 않은 데이터 세트는 더 많은 데이터를 필요로 합니다. 레이블 지정된 데이터를 충분히 사용할 수 없으면 준지도 학습을 고려하세요.

데이터 세트 크기는 학습 및 제공에도 영향을 줍니다. 데이터 세트가 작으면 Notebooks 인스턴스 내에서 직접 이를 학습시킬 수 있습니다. 분산 학습이 필요한 큰 데이터 세트가 있으면 Vertex AI 커스텀 학습 서비스를 사용합니다. Google이 사용자 데이터로 모델을 학습시키길 원하는 경우에는 AutoML을 사용합니다.

사용할 데이터 준비

잘 준비된 데이터는 모델 개발을 가속화하는 데 도움이 됩니다. 데이터 파이프라인을 구성할 때 일괄 및 스트림 데이터 모두에서 일관적인 결과를 얻을 수 있도록 두 유형의 데이터 모두를 처리할 수 있는지 확인합니다.

모델 개발 및 학습

다음 모델 개발 및 학습 권장사항을 자체 환경에 적용합니다.

관리형 또는 커스텀 학습 모델 개발 선택

모델을 빌드할 때 가능한 한 가장 높은 추상화 수준을 고려하세요. 가능하면 개발 및 학습 태스크가 자동으로 처리되는 AutoML을 사용하세요. 커스텀 학습 모델의 경우에는 자체 관리형 옵션 대신 확장성 및 유연성을 위해 관리형 옵션을 선택합니다. 모델 개발 옵션에 대해 자세히 알아보려면 권장 도구 및 제품 사용을 참조하세요.

Compute Engine VM 또는 Deep Learning VM 컨테이너에 대한 자체 관리형 학습 대신 Vertex AI 학습 서비스를 고려합니다. JupyterLab 환경의 경우 관리형 및 사용자 관리형 JupyterLab 환경을 모두 제공하는 Vertex AI Workbench를 고려하세요. 자세한 내용은 머신 러닝 개발 및 운영화된 학습을 참조하세요.

커스텀 학습 모델을 위해 사전 빌드된 컨테이너 또는 커스텀 컨테이너를 사용합니다.

Vertex AI의 커스텀 학습된 모델의 경우 머신 러닝 프레임워크 및 프레임워크 버전에 따라 사전 빌드된 컨테이너 또는 커스텀 컨테이너를 사용할 수 있습니다. 사전 빌드된 컨테이너는 특정 TensorFlow, scikit-learn, PyTorch, XGBoost 버전을 위해 생성된 Python 학습 애플리케이션에서 사용할 수 있습니다.

그렇지 않으면 학습 작업을 위해 커스텀 컨테이너를 빌드하도록 선택할 수 있습니다. 예를 들어 사전 빌드된 컨테이너에서 제공되지 않는 Python ML 프레임워크를 사용하여 모델을 학습시키려는 경우 또는 Python 이외의 프로그래밍 언어를 사용해서 학습시키려는 경우 커스텀 컨테이너를 사용합니다. 커스텀 컨테이너에서 학습 애플리케이션 및 모든 종속 항목을 학습 작업을 실행하는 이미지에 사전 설치합니다.

분산 학습 요구사항 고려

분산 학습 요구사항을 고려합니다. TensorFlow 및 PyTorch와 같은 일부 ML 프레임워크를 사용하면 여러 머신에서 동일한 학습 코드를 실행할 수 있습니다. 이러한 프레임워크는 각 머신에 설정된 환경 변수를 기준으로 작업 구분을 자동으로 조정합니다. 다른 프레임워크에는 추가적인 맞춤설정이 필요할 수 있습니다.

다음 단계

AI 및 머신 러닝에 대한 자세한 내용은 다음을 참조하세요.

• Google Cloud에서 머신러닝 구현을 위한 권장사항
• MLOps 실무자 가이드: 머신 러닝의 지속적 배포 및 자동화를 위한 프레임워크

아키텍처 프레임워크에서 안정성, 운영 우수성, 보안, 개인 정보 보호, 규정 준수 등의 다른 카테고리 살펴보기

환경 지속 가능성을 위한 설계

Google Cloud 아키텍처 프레임워크의 이 문서는 Google Cloud에서 워크로드의 환경 지속성에 대한 접근 방식을 요약합니다. 여기에는 Google Cloud에서 탄소 발자국을 최소화하는 방법에 대한 정보가 포함되어 있습니다.

탄소 발자국 이해

Google Cloud 사용량의 탄소 발자국을 이해하려면 탄소 발자국 대시보드를 사용하세요. 탄소 발자국 대시보드는 개발자가 소유한 Google Cloud 프로젝트와 사용하는 클라우드 서비스에 대한 배출량을 설명합니다.

자세한 내용은 'Google Cloud 탄소 발자국 줄이기'의 탄소 발자국 이해를 참조하세요.

가장 적합한 클라우드 리전 선택

탄소 배출을 줄이는 간단하고 효과적인 방법 중 하나는 탄소 배출량이 적은 클라우드 리전을 선택하는 것입니다. 이러한 선택을 위해 Google에서는 모든 Google Cloud 리전에 대해 탄소 데이터를 게시합니다.

리전을 선택할 때 탄소 배출량 감소를 다른 요구사항(예: 가격 책정 및 네트워크 지연 시간)과 균형시켜야 할 수 있습니다. 리전을 선택하려면 Google Cloud 리전 선택 도구를 사용하세요.

자세한 내용은 'Google Cloud 탄소 발자국 줄이기'의 가장 적합한 클라우드 리전 선택을 참조하세요.

가장 적합한 클라우드 서비스 선택

기존 탄소 발자국을 줄이려면 온프레미스 VM 워크로드를 Compute Engine으로 마이그레이션하는 것이 좋습니다.

또한 많은 워크로드에 VM이 필요하지 않습니다. 대신 서버리스 제품을 활용할 수 있습니다. 이러한 관리형 서비스는 클라우드 리소스 사용량을 최적화하여(종종 자동으로 수행) 클라우드 비용과 탄소 배출 공간을 줄일 수 있습니다.

자세한 내용은 'Google Cloud 탄소 발자국 줄이기'의 가장 적합한 클라우드 서비스 선택을 참조하세요.

유휴 클라우드 리소스 최소화

유휴 리소스는 불필요한 비용과 배출량을 발생시킵니다. 유휴 리소스의 일반적인 원인은 다음과 같습니다.

• 유휴 VM 인스턴스와 같은 사용되지 않는 활성 클라우드 리소스
• 초과 프로비저닝 리소스(예: 워크로드에 필요한 것보다 더 큰 VM 인스턴스 머신 유형)
• 효율성에 최적화되지 않은 리프트 앤 시프트 마이그레이션 등 최적화되지 않은 아키텍처. 이러한 아키텍처를 점진적으로 개선하는 것을 고려하세요.

다음은 낭비되는 클라우드 리소스를 최소화하기 위한 몇 가지 일반적인 전략입니다.

• 유휴 리소스 또는 초과 프로비저닝된 리소스를 식별하고 삭제하거나 크기를 조정합니다.
• 아키텍처를 리팩터링하여 더 최적인 설계를 통합합니다.
• 워크로드를 관리형 서비스로 마이그레이션합니다.

자세한 내용은 'Google Cloud 탄소 발자국 줄이기'의 유휴 클라우드 리소스 최소화를 참조하세요.

일괄 워크로드의 탄소 배출량 감소

탄소 배출량이 적은 리전에서 일괄 워크로드를 실행합니다. 배출량을 더 줄이기 위해 가능한 경우 그리드 탄소 강도가 낮은 시간에 워크로드를 실행하세요.

자세한 내용은 'Google Cloud 탄소 발자국 줄이기'의 일괄 워크로드의 탄소 배출량 감소을 참조하세요.

다음 단계

• 탄소 발자국 데이터를 사용하여 클라우드 탄소 배출량을 측정, 보고, 줄이는 방법을 알아보세요.
• Google Cloud 탄소 발자국을 줄이는 방법 알아보기

Google Cloud 아키텍처 프레임워크: 운영 우수성

Google Cloud 아키텍처 프레임워크의 이 카테고리는 Google Cloud에서 서비스를 효율적으로 운영하는 방법을 보여줍니다. 비즈니스 가치를 제공하는 시스템의 실행, 관리, 모니터링 방법을 설명합니다. 또한 운영 우수성을 지원하는 Google Cloud 제품 및 기능에 대해 설명합니다. 운영 우수성의 원칙을 따르면 안정성 기초를 구축하는 데 도움이 됩니다. 이를 위해 관측 가능성, 자동화, 확장성과 같은 기본적인 요소를 설정합니다.

이 아키텍처 프레임워크는 권장사항을 설명하고, 구현 권장사항을 제공하며 운영 우수성을 달성하는 데 도움이 되는 사용 가능한 몇몇 제품 및 서비스를 설명합니다. 이 프레임워크의 목표는 비즈니스 요구사항에 가장 잘 맞는 Google Cloud 배포를 설계하도록 지원하는 것입니다.

아키텍처 프레임워크의 운영 우수성 카테고리에서는 다음을 수행하는 방법을 알아봅니다.

• 배포 자동화
• 모니터링, 알림, 로깅 설정
• 클라우드 지원 및 에스컬레이션 프로세스 설정
• 용량 및 할당량 관리
• 최대 트래픽 및 출시 이벤트 대비 계획
• 자동화 문화 만들기

배포 자동화

Google Cloud 아키텍처 프레임워크의 이 문서에서는 빌드, 테스트, 배포를 자동화하기 위한 권장사항을 제공합니다.

자동화는 코드 업데이트와 같은 반복 프로세스에서 사람이 야기하는 오류를 제거하여 빌드, 테스트, 배포를 표준화하는 데 도움이 됩니다. 이 섹션에서는 자동화 시 다양한 검사와 보호 조치를 사용하는 방법을 설명합니다. 표준화된 머신 제어 프로세스는 배포를 안전하게 적용하는 데 도움이 됩니다. 또한 사용자 환경에 큰 영향을 미치지 않으면서 필요에 따라 이전 배포를 복원하는 메커니즘도 제공합니다.

중앙 코드 저장소에 코드 저장

태그를 지정하고 코드 변경사항 롤백이 가능한 버전 제어 시스템을 포함하는 중앙 코드 저장소에 코드를 저장합니다. 버전 제어를 사용하면 파일을 구성하고 팀과 조직 전체의 액세스, 업데이트, 삭제를 제어할 수 있습니다.

개발의 여러 단계에서 필요한 경우 저장소에 버전을 지정하고 라벨을 지정합니다. 예를 들어 라벨은 test, dev, prod일 수 있습니다.

Google Cloud에서 Cloud Source Repositories에 코드를 저장하고 여기에 버전을 지정하여 다른 Google Cloud 제품과 통합할 수 있습니다. 컨테이너화된 애플리케이션을 빌드하는 경우 컨테이너의 관리형 레지스트리인 Artifact Registry를 사용합니다.

버전 제어에 대한 자세한 내용은 버전 제어를 참조하세요. 저장소를 사용한 트렁크 기반 개발 구현에 대한 자세한 내용은 트렁크 기반 개발을 참조하세요.

지속적 통합 및 지속적 배포(CI/CD) 사용

지속적 통합 및 지속적 배포(CI/CD) 방식을 사용하여 배포를 자동화합니다. CI/CD 방식은 개발자가 구성한 파이프라인과 개발팀이 따르는 프로세스를 조합한 것입니다.

CI/CD 방식은 소프트웨어 개발팀의 생산성을 높여 배포 속도를 높입니다. 이 방식을 통해 개발자는 철저하게 테스트한 변경사항을 더 자주 만들고 해당 변경사항을 배포하는 데 필요한 시간을 줄일 수 있습니다.

CI/CD 방식의 일환으로 코드 빌드, 테스트, 배포의 모든 단계를 자동화합니다. 예를 들면 다음과 같습니다.

• 새 코드가 저장소에 커밋될 때마다 커밋이 빌드 및 테스트 파이프라인을 자동으로 호출하도록 합니다.
• 통합 테스트를 자동화합니다.
• 빌드가 특정 테스트 기준을 충족하면 변경사항이 배포되도록 배포를 자동화합니다.

Google Cloud에서는 CI/CD 파이프라인에 Cloud Build 및 Cloud Deploy를 사용할 수 있습니다.

Cloud Build를 사용하여 애플리케이션 패키지를 패키징하고 빌드하는 데 사용할 수 있는 종속 항목과 버전을 정의할 수 있습니다. 빌드 전체에 걸쳐 일관성을 유지하고 필요한 경우 이전 구성으로 롤백할 수 있도록 빌드 구성의 버전을 지정합니다.

Cloud Deploy를 사용하여 애플리케이션을 Google Cloud의 특정 환경에 배포하고 배포 파이프라인을 관리합니다.

CI/CD 구현에 대한 자세한 내용은 지속적 통합 및 배포 자동화를 참조하세요.

코드형 인프라를 사용하여 인프라 프로비저닝 및 관리

코드형 인프라는 설명적 모델을 사용하여 VM과 같은 인프라와 방화벽 규칙과 같은 구성을 관리합니다. 코드형 인프라를 사용하면 다음을 수행할 수 있습니다.

• CI/CD 파이프라인의 배포 또는 테스트 환경을 포함하여 클라우드 리소스를 자동으로 만듭니다.
• 인프라 변경사항을 애플리케이션 변경사항처럼 취급합니다. 예를 들어 구성 변경사항이 검토, 테스트, 감사를 받을 수 있도록 합니다.
• 클라우드 인프라에 대한 단일 버전의 정보를 제공합니다.
• 필요에 따라 클라우드 환경을 복제합니다.
• 필요한 경우 이전 구성으로 롤백합니다.

코드형 인프라 개념은 Google Cloud의 프로젝트에도 적용됩니다. 이 방식을 사용하면 프로젝트에서 공유 VPC 연결 또는 Identity and Access Management(IAM) 액세스와 같은 리소스를 정의할 수 있습니다. 이 방식의 예시는 Google Cloud 프로젝트 팩토리 Terraform 모듈을 참조하세요.

Terraform과 같은 타사 도구를 사용하면 Google Cloud에서 인프라를 자동으로 만들 수 있습니다. 자세한 내용은 Terraform, Cloud Build, GitOps를 사용하여 코드형 인프라 관리를 참조하세요.

실수로 또는 악의적으로 중요한 리소스를 삭제하지 못하도록 프로젝트 선취권, Cloud Storage 보관 정책, Cloud Storage 버킷 잠금과 같은 Google Cloud 기능을 사용하는 것이 좋습니다.

소프트웨어 배포 수명 주기 전반에서 테스트 통합

테스트는 소프트웨어를 성공적으로 출시하는 데 필수적입니다. 지속적 테스트는 팀이 고품질 소프트웨어를 더 빠르게 만들고 소프트웨어 안정성을 향상시키는 데 도움이 됩니다.

테스트 유형:

• 단위 테스트: 단위 테스트는 속도가 빠르며 신속한 배포를 수행하는 데 도움이 됩니다. 단위 테스트를 코드베이스의 일부로 취급하고 빌드 프로세스의 일부로 포함합니다.
• 통합 테스트: 통합 테스트는 특히 확장되고 두 개 이상의 서비스에 종속되도록 설계된 워크로드에서 중요합니다. 이 테스트는 상호 연결된 서비스와의 통합을 테스트할 때 복잡해질 수 있습니다.
• 시스템 테스트: 시스템 테스트는 시간이 많이 소요되고 복잡하지만 배포 전에 특이 사례를 식별하고 문제를 해결하는 데 도움이 됩니다.
• 기타 테스트: 정적 테스트, 부하 테스트, 보안 테스트, 정책 유효성 검사 등을 포함하여 실행할 기타 테스트가 있습니다. 프로덕션에 애플리케이션을 배포하기 전에 이러한 테스트를 실행합니다.

테스트를 통합하려면 다음 안내를 따르세요.

• 소프트웨어 배포 수명주기 전반에서 모든 유형의 테스트를 지속적으로 수행합니다.
• 이러한 테스트를 자동화하고 CI/CD 파이프라인에 포함합니다. 테스트가 실패하면 파이프라인이 실패하도록 만듭니다.
• 새로운 테스트를 지속적으로 업데이트하고 추가하여 배포의 운영 상태를 개선하고 유지합니다.

테스트 환경:

• 테스트 환경마다 별도의 Google Cloud 프로젝트를 사용합니다. 애플리케이션마다 별도의 프로젝트 환경을 사용합니다. 이렇게 분리하면 프로덕션 환경 리소스와 하위 환경의 리소스가 명확하게 구분됩니다. 이렇게 분리하면 실수로 한 환경의 변경사항이 다른 환경에 영향을 주지 않도록 할 수 있습니다.
• 테스트 환경 생성을 자동화합니다. 이 자동화를 수행하는 한 가지 방법은 코드형 인프라를 사용하는 것입니다.
• 합성 프로덕션 환경을 사용하여 변경사항을 테스트합니다. 이 환경은 애플리케이션을 테스트하고 엔드 투 엔드 테스트 및 성능 테스트를 포함한 다양한 유형의 워크로드 테스트를 수행할 수 있는, 프로덕션과 유사한 환경을 제공합니다.

지속적 테스트 구현에 대한 자세한 내용은 자동화 테스트를 참조하세요.

점진적 배포 실행

최종 사용자의 최소 중단, 순차적 업데이트, 롤백 전략, A/B 테스트 전략과 같은 중요한 매개변수를 기반으로 배포 전략을 선택합니다. 각 워크로드에서 이러한 요구사항을 평가하고 지속적 업데이트, 블루/그린 배포, 카나리아 배포와 같은 검증된 기술에서 배포 전략을 선택합니다.

CI/CD 프로세스만 프로덕션 환경에서 변경하고 푸시할 수 있도록 합니다.

변경 불가능한 인프라를 사용하는 것이 좋습니다. 변경 불가능한 인프라는 변경 또는 업데이트되지 않는 인프라입니다. 환경에서 새 코드를 배포하거나 다른 구성을 변경해야 할 경우 전체 환경(예: VM 또는 포드 모음)을 새 환경으로 바꿉니다. 블루/그린 배포는 변경할 수 없는 인프라의 예시입니다.

카나리아 테스트를 수행하고 변경사항을 배포할 때에는 시스템에 오류가 있는지 관찰하는 것이 좋습니다. 강력한 모니터링 및 알림 시스템이 있으면 이 유형의 관찰이 더 쉬워집니다. A/B 테스트 또는 카나리아 테스트를 수행하기 위해 Google Cloud의 관리형 인스턴스 그룹을 사용할 수 있습니다. 그런 다음 느린 출시 또는 필요한 경우 복원을 수행할 수 있습니다.

Cloud Deploy를 사용하여 배포를 자동화하고 배포 파이프라인을 관리하는 것을 고려해 보세요. 또한 Google Cloud에서 Spinnaker 및 Tekton과 같은 다양한 서드 파티 도구를 사용하여 배포를 자동화하고 배포 파이프라인을 만들 수 있습니다.

이전 출시 버전을 원활하게 복원

배포 전략의 일환으로 복원 전략을 정의합니다. 배포 또는 인프라 구성을 이전 버전의 소스 코드로 롤백할 수 있어야 합니다. 이전의 안정적인 배포를 복원하는 작업은 안정성 및 보안 이슈 모두를 위한 이슈 관리에서 중요한 단계입니다.

또한 배포 프로세스가 시작되기 전의 상태로 환경을 복원할 수 있어야 합니다. 여기에는 다음이 포함될 수 있습니다.

• 애플리케이션의 코드 변경사항을 되돌릴 수 있습니다.
• 환경에 대한 구성 변경사항을 되돌릴 수 있습니다.
• 변경 불가능한 인프라를 사용하고 배포로 환경이 변경되지 않도록 합니다. 이렇게 하면 구성 변경사항을 쉽게 되돌릴 수 있습니다.

CI/CD 파이프라인 모니터링

자동화된 빌드, 테스트, 배포 프로세스를 원활하게 실행하려면 CI/CD 파이프라인을 모니터링합니다. 파이프라인에서 문제가 발생한 시기를 나타내는 알림을 설정합니다. 파이프라인의 각 단계에서 파이프라인이 실패하는 경우 팀에서 근본 원인 분석을 수행할 수 있도록 적절한 로그 구문을 작성해야 합니다.

Google Cloud에서 모든 CI/CD 서비스는 Google Cloud 관측 가능성과 통합됩니다. 예를 들면 다음과 같습니다.

• Cloud Source Repositories는 Pub/Sub 서비스와 통합됩니다.
• Cloud Build는 Pub/Sub와 통합되며 감사 로그와 빌드 로그도 저장합니다. Cloud Monitoring 서비스를 사용하여 빌드 로그의 특정 키워드 및 기타 여러 측정항목에 대한 알림을 설정할 수 있습니다.
• Cloud Deploy는 감사 로그를 저장합니다.

모니터링 및 로깅에 대한 자세한 내용은 모니터링, 알림, 로깅 설정을 참조하세요.

애플리케이션을 안전하게 배포

아키텍처 프레임워크의 보안, 규정 준수, 개인 정보 보호 카테고리에서 애플리케이션을 안전하게 배포 섹션을 검토합니다.

버전 출시에 대한 관리 가이드라인 설정

엔지니어가 실수를 방지하고 빠른 소프트웨어 배포를 가능하게 하려면 새로운 소프트웨어 버전 출시에 대한 관리 가이드라인을 명확하게 설명해야 합니다.

출시 엔지니어는 소프트웨어의 빌드 및 제공 방식을 감독합니다. 출시 엔지니어링 시스템은 다음과 같은 4가지 권장사항을 따라야 합니다.

• 셀프서비스 모드. 소프트웨어 엔지니어의 일반적인 실수를 방지하는 데 도움이 되는 가이드라인을 수립합니다. 이 가이드라인은 일반적으로 자동화된 프로세스에 코드화되어 있습니다.

• 빈번한 출시. 빠른 속도로 출시하면 문제를 더 쉽게 해결하는 데 도움이 됩니다. 출시 빈도를 높이려면 자동화된 단위 테스트가 수반되어야 합니다.

• 기본 제공 빌드. 빌드 도구의 일관성을 확보합니다. 현재 버전을 빌드하는 데 사용하는 빌드 컴파일러 버전과 한 달 전 버전을 비교합니다.

• 정책 시행. 모든 변경사항에는 코드 검토가 필요하며 원칙적으로 보안을 강화하기 위한 가이드라인과 정책 세트가 포함되어야 합니다. 정책을 시행하면 코드 검토, 문제 해결, 새 출시 버전의 테스트가 향상됩니다.

다음 단계

• 모니터링, 알림, 로깅 설정(이 시리즈의 다음 문서)
• 아키텍처 프레임워크의 보안, 규정 준수, 개인 정보 보호 카테고리에서 애플리케이션을 안전하게 배포
• 컨테이너 빌드를 위한 권장사항 검토
• 기술 역량 알아보기
• 시스템 설계, 보안, 개인 정보 보호, 규정 준수, 안정성, 비용 최적화, 성능 최적화 등 아키텍처 프레임워크의 다른 카테고리 살펴보기

모니터링, 알림, 로깅 설정

Google Cloud 아키텍처 프레임워크의 이 문서에서는 시스템 동작을 기반으로 조치를 취할 수 있도록 모니터링, 알림, 로깅을 설정하는 방법을 보여줍니다. 여기에는 시스템에 대한 정보를 쉽게 볼 수 있도록 대시보드를 추적하는 데 유용한 측정항목을 식별하고 빌드하는 방법이 포함됩니다.

DevOps 리소스 및 평가(DORA) 연구 프로그램은 다음과 같이 모니터링을 정의합니다.

"비즈니스 결정을 내릴 수 있도록 안내하기 위해 정보를 수집, 분석, 사용하여 애플리케이션 및 인프라를 추적하는 프로세스입니다. 모니터링은 시스템과 작업에 대한 유용한 정보를 제공하는 핵심 기능입니다."

모니터링을 통해 서비스 소유자는 다음을 수행할 수 있습니다.

• 서비스 변경사항이 성능에 영향을 미칠 때 정보에 입각한 결정
• 이슈 대응에 과학적 접근 방식 적용
• 서비스가 비즈니스 목표에 부합하는지 측정

모니터링, 로깅, 알림을 사용하면 다음을 수행할 수 있습니다.

• 장기 트렌드 분석
• 시간 경과에 따른 실험 비교
• 중요한 측정항목에 대한 알림 정의
• 관련 실시간 대시보드 빌드
• 소급적 분석 수행
• 비즈니스 기반 측정항목과 시스템 상태 측정항목을 모두 모니터링
  • 비즈니스 기반 측정항목은 시스템이 비즈니스를 얼마나 잘 지원하는지 이해하는 데 도움이 됩니다. 예를 들어 측정항목을 사용하여 다음을 모니터링합니다.
    • 사용자에게 애플리케이션을 제공하는 데 드는 비용
    • 재설계 후 사이트 트래픽의 규모 변화
    • 고객이 사이트에서 제품을 구매하는 데 걸리는 시간
  • 시스템 상태 측정항목은 시스템이 허용 가능한 성능 수준에서 올바르게 작동하는지 이해하는 데 도움이 됩니다.

시스템을 모니터링하려면 다음 4가지의 골든 신호를 사용하세요.

• 지연 시간. 요청을 처리하는 데 걸리는 시간입니다.
• 트래픽. 시스템에 배치되는 요구의 양입니다.
• 오류. 요청의 실패율입니다. 실패는 명시적(예: HTTP 500), 암시적(예: 잘못된 콘텐츠와 결합된 HTTP 200 성공 응답), 정책(예: 1초의 응답 시간에 커밋한 경우 1초를 초과하는 모든 요청은 오류)에 의한 것일 수 있습니다.
• 포화도. 서비스가 얼마나 가득 찼는지입니다. 포화도는 시스템 비율을 나타내는 것으로, 가장 제한적인 리소스(즉, 메모리가 제한된 시스템에서는 메모리를 표시하고 I/O가 제한된 시스템에서는 I/O를 표시)를 강조합니다.

모니터링 계획 만들기

조직의 사명과 운영 전략에 맞는 모니터링 계획을 세웁니다. 애플리케이션 개발 중 모니터링 및 관측 가능성 계획을 포함합니다. 애플리케이션 개발 초기에 모니터링 계획을 포함하면 조직이 운영 우수성을 달성할 수 있습니다.

모니터링 계획에 다음 세부정보를 포함합니다.

• 온프레미스 리소스 및 클라우드 리소스를 포함한 모든 시스템을 포함합니다.
• 클라우드 비용 모니터링을 포함하여 확장 이벤트로 인해 예산 기준액을 초과하지 않도록 하세요.
• 인프라 성능, 사용자 환경, 비즈니스 핵심성과지표(KPI)를 측정하는 다양한 모니터링 전략을 빌드합니다. 예를 들어 정적 임계값은 인프라 성능을 측정하는 데 잘 작동하지만 사용자 환경을 실제로 반영하지는 않습니다.

모니터링 전략이 발전함에 따라 계획을 업데이트합니다. 계획을 반복하여 시스템 상태를 개선합니다.

조직의 모든 측면을 측정하는 측정항목 정의

배포의 동작 방식을 측정하는 데 필요한 측정항목을 정의합니다. 방법은 다음과 같습니다.

• 비즈니스 목표를 정의합니다.
• 성능을 측정하기 위한 정량적 정보를 제공할 수 있는 측정항목과 KPI를 파악합니다. 측정항목 정의가 클라우드 비용 등 비즈니스 요구사항부터 기술 구성요소에 이르기까지 조직의 모든 측면에 걸쳐 변환되는지 확인합니다.
• 이러한 측정항목을 사용하여 애플리케이션의 서비스 수준 지표(SLI)를 만듭니다. 자세한 내용은 적절한 SLI 선택을 참조하세요.

다양한 구성요소의 일반적인 측정항목

측정항목은 인프라 및 네트워킹에서 비즈니스 로직에 이르기까지 서비스의 모든 수준에서 생성됩니다. 예를 들면 다음과 같습니다.

• 인프라 측정항목:
  • 인스턴스, CPU, 메모리, 사용률, 계수 등 가상 머신 통계
  • 클러스터 사용률, 클러스터 용량, 포드 수준 사용률, 계수 등 컨테이너 기반 통계
  • 인그레스/이그레스, 구성요소 간 대역폭, 지연 시간, 처리량 등 네트워킹 통계
  • 부하 분산기로 측정한 초당 요청
  • 디스크당 읽은 총 디스크 블록
  • 지정된 네트워크 인터페이스를 통해 전송된 패킷
  • 지정된 프로세스의 메모리 힙 크기
  • 응답 지연 시간의 분포
  • 데이터베이스 인스턴스에서 거부한 잘못된 쿼리 수
• 애플리케이션 측정항목:
  • 초당 쿼리 수, 초당 쓰기 수, 초당 메시지 전송 수 등 애플리케이션별 동작
• 관리형 서비스 통계 측정항목:
  • Google 관리형 서비스(BigQuery, App Engine, Bigtable 등의 API 또는 제품)의 QPS, 처리량, 지연 시간, 사용률
• 네트워크 연결 통계 측정항목:
  • 온프레미스 시스템 또는 Google Cloud 외부에 있는 시스템에 대한 연결의 VPN/상호 연결 관련 통계입니다.
• SLI
  • 전반적인 시스템 상태와 관련된 측정항목입니다.

모니터링 설정

온프레미스 리소스와 클라우드 리소스를 모두 모니터링하도록 모니터링을 설정합니다.

다음과 같은 모니터링 솔루션을 선택합니다.

• 플랫폼과 독립적임
• 온프레미스, 하이브리드, 멀티 클라우드 환경을 모니터링할 수 있는 일관된 기능 제공

단일 플랫폼을 사용하여 다양한 소스에서 제공되는 모니터링 데이터를 통합하면 동일한 측정항목과 시각화 대시보드를 빌드할 수 있습니다.

모니터링을 설정할 때 가능하면 모니터링 작업을 자동화하세요.

Google Cloud로 모니터링

모니터링 서비스를 직접 빌드하는 것보다 Cloud Monitoring과 같은 모니터링 서비스를 사용하는 것이 더 간편합니다. 복잡한 애플리케이션을 모니터링하는 것은 그 자체로 상당한 엔지니어링 작업입니다. 계측, 데이터 수집 및 표시, 알림을 위한 기존 인프라가 있더라도 누군가가 빌드하고 유지관리하려면 담당자가 필요합니다.

Cloud Monitoring을 사용하면 온프레미스 및 클라우드 리소스 모두에 대해 애플리케이션 및 인프라의 성능, 가용성, 상태를 파악할 수 있습니다.

Cloud Monitoring은 Google Cloud 관측 가능성의 일부인 관리형 서비스입니다. Cloud Monitoring을 사용하여 Google Cloud 서비스 및 커스텀 측정항목을 모니터링할 수 있습니다. Cloud Monitoring은 타사 모니터링 도구와의 통합을 위한 API를 제공합니다.

Cloud Monitoring은 시스템의 클라우드 기반 인프라에서 측정항목, 로그 및 이벤트를 집계합니다. 이 데이터는 개발자와 운영자에게 관측 가능한 신호를 다양하게 제공하여 근본 원인 분석의 속도를 높이고 평균 해결 시간을 단축시킬 수 있습니다. Cloud Monitoring을 사용하면 비즈니스 목표를 충족하는 알림 및 커스텀 측정항목을 정의하고 시스템 상태를 집계, 시각화, 모니터링할 수 있습니다.

Cloud Monitoring은 클라우드 및 오픈소스 애플리케이션 서비스용 기본 대시보드를 제공합니다. 측정항목 모델을 사용하면 강력한 시각화 도구를 갖춘 커스텀 대시보드를 정의하고 측정항목 탐색기에서 차트를 구성할 수 있습니다.

알림 설정

좋은 알림 시스템은 기능 출시 능력을 향상시킵니다. 시간 경과에 따른 성능을 비교하여 기능 출시 속도 또는 기능 출시 롤백을 결정할 수 있습니다. 롤백에 대한 자세한 내용은 이전 출시 버전을 원활하게 복원을 참조하세요.

알림을 설정할 때 알림을 중요한 측정항목에 직접 매핑하세요. 이러한 중요 측정항목은 다음과 같습니다.

• 4가지 골든 신호:
  • 지연 시간
  • 트래픽
  • 오류
  • 포화도
• 시스템 상태
• 서비스 사용량
• 보안 이벤트
• 사용자 환경

알림을 통해 해결 시간을 최소화합니다. 이렇게 하려면 각 알림에 다음을 수행합니다.

• 모니터링 대상과 모니터링의 비즈니스에 미치는 영향을 설명하는 명확한 설명을 포함합니다.
• 즉시 조치를 취하는 데 필요한 모든 정보를 제공합니다. 알림을 이해하는 데 클릭을 여러 번 해서 이동해야 하는 경우 긴급 대기 엔지니어가 조치를 취하기가 어렵습니다.
• 다양한 알림의 우선순위 수준을 정의합니다.
• 알림에 대응할 담당자 또는 팀을 명확하게 파악합니다.

중요한 애플리케이션 및 서비스의 경우 서비스 상태 실패, 구성 변경, 처리량 급증 등의 일반적인 오류 조건으로 인해 트리거된 알림에 자가 복구 작업을 구축합니다.

알림을 설정할 때는 수작업 부담을 해소해야 합니다. 예를 들어 빈번한 오류를 제거하거나 알림이 트리거되지 않도록 하는 이러한 오류를 자동으로 수정하여 수작업을 최소화합니다. 따라서 수작업 부담을 없애고 애플리케이션의 운영 구성요소를 안정적으로 만드는 데 집중할 수 있습니다. 자세한 내용은 자동화 문화 만들기를 참조하세요.

모니터링 및 알림 대시보드 빌드

모니터링이 완료되면 모니터링 및 알림 시스템의 정보를 포함하는 복잡하지 않은 관련 대시보드를 빌드합니다.

대시보드를 시각화하는 적절한 방법을 선택하는 것은 안정성 목표와의 연관성을 유지하기 어려울 수 있습니다. 대시보드를 만들어 다음을 모두 시각화합니다.

• 단기 및 실시간 분석
• 장기 분석

시각적 관리 구현에 대한 자세한 내용은 시각적 관리 기능 문서를 참조하세요.

중요 애플리케이션에 로깅 사용 설정

로깅 서비스는 시스템 모니터링에 매우 중요합니다. 측정항목은 모니터링할 특정 항목의 기반을 형성하지만 로그에는 디버깅, 보안 관련 분석, 규정 준수 요구사항에 필요한 중요한 정보가 포함됩니다.

시스템에서 생성되는 데이터를 로깅하면 효과적인 보안 상태를 보장하는 데 도움이 됩니다. 로깅 및 보안에 대한 자세한 내용은 아키텍처 프레임워크의 보안 카테고리에서 로깅 및 감지 제어 구현을 참조하세요.

Cloud Logging은 로그 데이터 및 이벤트를 저장, 검색, 분석, 모니터링하고 알림을 받는 데 사용할 수 있는 통합 로깅 서비스입니다. Logging은 Google Cloud 및 기타 클라우드 제공업체의 서비스에서 자동으로 로그를 수집합니다. 이러한 로그를 사용하여 모니터링을 위한 측정항목을 빌드하고 Cloud Storage, BigQuery, Pub/Sub와 같은 외부 서비스로의 로깅 내보내기를 만들 수 있습니다.

감사 추적 설정

Google Cloud 프로젝트에서 '누가, 언제, 어디서, 무엇을 했는가'와 같은 질문에 답하려면 Cloud 감사 로그를 사용하세요.

Cloud 감사 로그는 다음과 같은 여러 유형의 활동을 캡처합니다.

• 관리자 활동 로그에는 API 호출이나 리소스의 구성 또는 메타데이터를 수정하는 기타 관리 작업과 관련된 로그 항목이 포함됩니다. 관리자 활동 로그는 항상 사용 설정되어 있습니다.
• 데이터 액세스 감사 로그는 사용자가 제공한 데이터를 생성하거나 수정하거나 읽는 API 호출을 기록합니다. 데이터 액세스 감사 로그는 크기가 클 수 있으므로 기본적으로 사용 중지되어 있습니다. 데이터 액세스 로그를 생성하는 Google Cloud 서비스를 구성할 수 있습니다.

감사 로그를 작성하는 Google Cloud 서비스 목록은 감사 로그를 생성하는 Google 서비스를 참조하세요. Identity and Access Management(IAM) 컨트롤을 사용하여 감사 로그를 볼 수 있는 액세스 권한을 가진 사용자를 제한합니다.

다음 단계

• 클라우드 지원 및 에스컬레이션 프로세스 설정(이 시리즈의 다음 문서)
• Google Cloud 관측 가능성 살펴보기
• Cloud Monitoring을 배포하여 애플리케이션 및 인프라의 성능, 가용성, 상태 파악
• 모니터링 및 관측 가능성 자세히 알아보기
• 시스템 설계, 보안, 개인 정보 보호, 규정 준수, 안정성, 비용 최적화, 성능 최적화 등 아키텍처 프레임워크의 다른 카테고리 살펴보기

클라우드 지원 및 에스컬레이션 프로세스 설정

Google Cloud 아키텍처 프레임워크의 이 문서에서는 효과적인 에스컬레이션 프로세스를 정의하는 방법을 설명합니다. 클라우드 제공업체나 다른 타사 서비스 제공업체의 지원 설정은 효과적인 에스컬레이션 관리의 핵심입니다.

Google Cloud는 라이브 지원 또는 개발자 커뮤니티나 제품 문서와 같은 게시된 안내를 통해 다양한 지원 채널을 제공합니다. 클라우드 고객 관리 제품을 통해 Google Cloud와 함께 워크로드를 효율적으로 실행할 수 있습니다.

제공업체의 지원 설정

클라우드 제공업체나 다른 타사 서비스 제공업체의 지원 계약을 구매합니다. 지원은 다양한 운영 문제에 대한 즉각적인 대응과 해결을 보장하는 데 중요합니다.

Google Cloud 고객 관리로 작업하려면 스탠더드, 고급 또는 프리미엄 지원이 포함된 고객 관리 서비스를 구매하는 것이 좋습니다. 주요 프로덕션 환경에는 고급 또는 프리미엄 지원을 사용하는 것이 좋습니다.

에스컬레이션 프로세스 정의

잘 정의된 에스컬레이션 프로세스는 시스템의 문제를 식별하고 처리하는 데 드는 수고와 시간을 줄이는 데 중요합니다. 여기에는 Google Cloud 제품, 기타 클라우드 제작자 또는 타사 서비스에 대한 지원이 필요한 문제가 포함됩니다.

에스컬레이션 경로를 만들려면 다음 안내를 따르세요.

• 문제를 내부적으로 에스컬레이션하는 시기와 방법을 정의합니다.
• 클라우드 제공업체나 다른 타사 서비스 제공업체에서 지원 케이스를 만드는 시기와 방법을 정의합니다.
• 지원을 제공하는 팀과 협력하는 방법을 알아봅니다. Google Cloud의 경우 운영팀은 고객 관리 작업을 위한 권장사항을 검토해야 합니다. 이러한 권장사항을 에스컬레이션 경로에 통합합니다.
• 아키텍처를 설명하는 문서를 찾거나 만듭니다. 이러한 문서에 지원 엔지니어에게 도움이 되는 정보가 포함되어 있는지 확인합니다.
• 서비스 중단 시 팀 커뮤니케이션 방법을 정의합니다.
• 지원이 필요한 사용자에게 Google Cloud Support Center에 액세스하거나 다른 지원 제공업체와 통신할 수 있는 적절한 수준의 지원 권한이 있는지 확인합니다. Google Cloud Support Center 사용 방법은 지원 절차를 참조하세요.
• 문제가 발생한 경우 조치하는 데 필요한 정보가 있도록 모니터링, 알림, 로깅을 설정합니다.
• 이슈 보고에 사용될 템플릿을 만듭니다. 이슈 보고서에 포함할 정보는 고객 관리 작업을 위한 권장사항을 참조하세요.
• 조직의 에스컬레이션 프로세스를 문서화합니다. 에스컬레이션을 처리할 수 있는 명확하고 잘 정의된 작업이 있는지 확인합니다.
• 신규 팀원에게 지원팀과 상호작용하는 방법을 교육하는 계획을 포함합니다.

에스컬레이션 프로세스를 내부에서 정기적으로 테스트합니다. 마이그레이션, 새 제품 출시, 최대 트래픽 이벤트와 같은 주요 이벤트 전에 에스컬레이션 절차를 테스트합니다. Google Cloud 고객 관리 프리미엄 지원이 있는 경우 기술계정 관리자가 에스컬레이션 프로세스를 검토하고 Google Cloud 고객 관리에서 테스트를 조정할 수 있습니다.

지원팀의 커뮤니케이션이 수신되는지 확인

관리자가 클라우드 제공업체 및 타사 서비스로부터 통신을 수신하는지 확인합니다. 관리자가 이 정보를 사용하면 정보에 입각한 결정을 내리고 더 큰 문제가 발생하기 전에 문제를 해결할 수 있습니다. 다음 사항에 해당되는지 확인합니다.

• 보안, 네트워크, 시스템 관리자는 Google Cloud 및 기타 제공업체나 서비스에서 중요한 이메일을 수신하도록 설정됩니다.
• 보안, 네트워크, 시스템 관리자는 Cloud Monitoring과 같은 모니터링 도구에서 생성된 시스템 알림을 수신하도록 설정됩니다.
• 프로젝트 소유자는 이메일을 라우팅할 수 있는 사용자 이름을 가지고 있으므로 중요한 이메일을 받을 수 있습니다.

Google Cloud의 알림 관리에 대한 자세한 내용은 알림 연락처 관리를 참조하세요.

검토 프로세스 구축

검토 프로세스나 사후 분석 프로세스를 설정합니다. 새 지원 티켓을 제출하거나 기존 지원 티켓을 에스컬레이션한 후에 다음 프로세스를 따릅니다. 사후 분석의 일환으로 얻은 교훈을 문서화하고 완화를 추적합니다. 이 검토에서 비난 없는 사후 분석 문화를 조성합니다.

사후 분석에 대한 자세한 내용은 사후 분석 문화: 실패로부터 학습을 참조하세요.

우수성 센터 구축

조직의 정보와 경험, 패턴을 위키, Google 사이트, 인트라넷 사이트와 같은 내부 지식 기반에 보관하면 유용하게 활용할 수 있습니다. Google Cloud에 새로운 제품과 기능이 지속적으로 출시되고 있으므로 이러한 지식은 애플리케이션 및 서비스에 특정 설계를 선택하는 이유를 파악하는 데 도움이 될 수 있습니다. 자세한 내용은 아키텍처 결정 레코드를 참조하세요.

또한 조직에서 Google Cloud 전문가와 챔피언을 지명하는 것도 좋은 방법입니다. 지명된 챔피언이 전문 기술을 쌓을 수 있는 폭넓은 학습 및 인증 옵션을 제공합니다. Google Cloud 블로그를 구독하는 팀은 최신 뉴스, 발표, 고객 사례 관련 정보를 얻을 수 있습니다.

다음 단계

• 용량 및 할당량 관리(이 시리즈의 다음 문서)
• 시스템 설계, 보안, 개인 정보 보호, 규정 준수, 안정성, 비용 최적화, 성능 최적화 등 아키텍처 프레임워크의 다른 카테고리 살펴보기

용량 및 할당량 관리

Google Cloud 아키텍처 프레임워크의 이 문서에서는 클라우드에서 용량 및 할당량을 평가하고 계획하는 방법을 보여줍니다.

기존 데이터 센터에서는 일반적으로 매 분기에 현재 리소스 요구 사항을 검토하고 미래 요구 사항을 예측하느라 많은 시간을 소비합니다. 물리적, 물류 관련, 인적 자원 관련 우려사항을 고려해야 합니다. 즉, 랙 공간, 냉방, 전기, 대역폭, 케이블 배선, 조달 시간, 배송 시간, 새 장비를 랙에 설치하고 쌓아 올릴 엔지니어 수와 같은 문제를 고려해야 합니다. 또한 용량과 워크로드 분산을 적극적으로 관리하여 Hadoop 파이프라인과 같은 리소스 소비량이 많은 작업이 웹 서버와 같이 고가용성을 유지해야 하는 서비스를 간섭하지 않도록 해야 합니다.

반면에 Google Cloud를 사용할 때는 용량 계획을 대부분 Google에 양도하게 됩니다. 클라우드를 사용하면 필요하지 않은 경우에 유휴 리소스를 프로비저닝 및 유지할 필요가 없습니다. 예를 들어 필요에 따라 VM 인스턴스를 만들고, 확장, 축소할 수 있습니다. 사용한 만큼만 비용을 지불하기 때문에 최대 트래픽 시간에만 필요한 초과 용량을 포함하여 지출을 최적화할 수 있습니다. 비용 절약을 위해 Compute Engine은 크기 조정 또는 삭제가 가능한 미사용 VM 인스턴스가 감지될 때 머신 유형 권장사항을 제공합니다.

클라우드 용량 요구사항 평가

용량을 효과적으로 관리하기 위해서는 조직의 용량 요구사항을 알아야 합니다.

용량 요구사항을 평가하려면 먼저 주요 클라우드 워크로드를 식별해야 합니다. 이러한 워크로드의 평균 및 최대 사용률과 현재 및 미래의 용량 요구사항을 평가하세요.

이러한 주요 워크로드를 사용하는 팀도 파악해야 합니다. 해당 팀과 협력하여 내부 수요 계획 프로세스를 마련합니다. 이 프로세스를 사용하여 현재 및 예상 클라우드 리소스 요구사항을 파악합니다.

부하 패턴 및 호출 분산을 분석하세요. 지난 30일 최고 사용량, 시간별 최고 사용량, 분당 최고 사용량 등의 요인을 분석에 사용합니다.

Cloud Monitoring을 사용하여 애플리케이션과 인프라의 성능, 업타임, 전반적인 상태를 파악해 보세요.

인프라 사용률 측정항목 보기

쉽게 용량 계획을 세울 수 있도록 조직의 클라우드 리소스 사용에 대한 이전 데이터를 수집하고 저장합니다.

인프라 사용률 측정항목에 대한 가시성을 확보해야 합니다. 예를 들어 주요 워크로드의 다음 항목을 평가합니다.

• 평균 및 최대 사용률
• 사용 패턴 급증
• 소매업체 연말연시 기간 등 비즈니스 요구사항에 따른 시즌별 급증
• 급증 이벤트를 대비하고 잠재적 트래픽 급증을 빠르게 처리하는 데 필요한 초과 프로비저닝

할당량 및 용량 제한에 임박하면 자동으로 알리도록 조직에서 알림을 설정했는지 확인합니다.

Google 모니터링 도구를 사용하여 애플리케이션 사용 및 용량에 대한 통계를 확인합니다. 예를 들어 Monitoring으로 커스텀 측정항목을 정의할 수 있습니다. 이러한 커스텀 측정항목을 사용하여 알림 추세를 정의합니다. 또한 모니터링은 시급한 문제를 식별하는 데 도움이 되는 유연한 대시보드와 풍부한 시각화 도구도 제공합니다.

용량 계획 프로세스 만들기

용량 계획 프로세스를 수립하고 이 계획을 문서화하세요.

이 계획을 만들 때는 다음 단계를 따르세요.

1. 부하 테스트를 실행하여 고정된 리소스 수량에 따라 지연 시간 목표를 충족하면서도 시스템이 처리할 수 있는 부하를 확인합니다. 부하 테스트에서는 실시간 사용자의 프로덕션 트래픽 프로필과 일치하는 요청 유형을 혼합하여 사용해야 합니다. 균일하거나 무작위로 혼합된 방식으로 작업을 사용하지 마세요. 트래픽 프로필 사용량에 사용량 급증을 포함합니다.
2. 용량 모델을 만듭니다. 용량 모델은 부하 테스트로부터 확인된 대로 서비스 부하에서 단위별 증가에 필요한 증분 리소스를 계산하기 위한 일련의 수식입니다.
3. 향후 트래픽을 예측하고 성장에 대비합니다. Google에서 트래픽 예측을 빌드하는 방법에 대한 요약은 향후 qngk 측정 문서를 참조하세요.
4. 예측에 용량 모델을 적용해서 이후 리소스 수요를 결정합니다.
5. 조직에 필요한 리소스 비용을 예상합니다. 그런 후 재무 조직에서 예산 승인을 받습니다. 비즈니스가 다양한 제품 범위 중에서 비용과 위험 사이의 절충안을 선택할 수 있기 때문에 이 단계가 필수적입니다. 이러한 절충안은 비즈니스 우선순위에 따라 지정된 제품의 예상 수요보다 낮거나 높은 용량을 확보하는 것을 의미할 수 있습니다.
6. 클라우드 제공업체와 협력하여 할당량과 예약을 통해 필요한 시기에 정확한 양의 리소스를 확보하세요. 용량을 계획할 때 인프라팀을 참여시키고 운영팀에서 신뢰 구간을 사용해 용량 계획을 세우도록 합니다.
7. 1~2분기에 한 번씩 이전 단계를 반복합니다.

리소스 사용량을 최적화하고 용량을 계획하는 프로세스에 대한 자세한 가이드는 용량 계획을 참조하세요.

할당량이 용량 요구사항과 일치하는지 확인

Google Cloud는 할당량을 사용해서 사용 가능한 특정 공유 Google Cloud 리소스의 양을 제한합니다. 각 할당량은 특정 서비스에 대한 API 호출, 프로젝트에서 동시에 사용하는 부하 분산기 수, 사용자가 만들 수 있는 프로젝트 수와 같이 계수할 수 있는 특정 리소스를 나타냅니다. 예를 들어 할당량을 사용하면 일부 고객 또는 프로젝트가 특정 리전 또는 영역에서 CPU 코어를 독점할 수 없도록 보장할 수 있습니다.

할당량을 검토할 때는 다음 세부정보를 고려하세요.

• 예상치 못한 리소스 소비 제한을 방지하려면 프로젝트의 용량 요구사항을 사전에 계획하세요.
• 전체 리전 장애를 처리할 수 있도록 할당량 및 용량을 설정합니다.
• 할당량을 사용해서 특정 리소스 소비에 상한을 설정합니다. 예를 들어 BigQuery API를 대상으로 최대 일일 쿼리 사용량 할당량을 설정하여 프로젝트가 BigQuery에 과도한 비용을 소비하지 않도록 할 수 있습니다.
• 사용량 급증을 계획하고 할당량 계획의 일부에 이러한 급증을 포함합니다. 사용량 급증은 하루 중에도 계속 변동될 것으로 예상될 수 있고, 예기치 않은 최대 트래픽 이벤트 또는 알려진 최대 트래픽 및 출시 이벤트가 발생할 수 있습니다. 최대 트래픽 및 출시 이벤트를 계획하는 방법에 대한 자세한 내용은 운영 우수성: 최대 트래픽 및 출시 이벤트 계획의 다음 섹션을 참조하세요.

현재 할당량이 충분하지 않으면 Google Cloud 콘솔을 사용해서 할당량을 관리할 수 있습니다. 더 큰 용량이 필요한 경우 Google Cloud 영업팀에 문의하세요. 하지만 많은 서비스에 할당량 시스템과 관련되지 않은 제한도 있다는 것을 알아야 합니다. 자세한 내용은 할당량 작업을 참조하세요.

할당량을 정기적으로 검토하세요. 할당량이 더 필요해지기 전에 할당량 요청을 제출하세요. 할당량 요청을 어떻게 평가하고 요청을 어떻게 승인하거나 거부하는지에 대한 자세한 내용은 할당량 작업을 참조하세요.

Google Cloud 할당량을 보고 관리하는 방법에는 여러 가지가 있습니다.

• Google Cloud 콘솔 사용
• Google Cloud CLI 사용
• Service Usage API 사용
• Monitoring을 사용하여 견적 측정항목 보기
• 한 조직 또는 폴더에 포함된 여러 Google Cloud 프로젝트의 할당량을 관리하려면 할당량 모니터링 대시보드 솔루션을 구현하는 것이 좋습니다.

다음 단계

• 최대 트래픽 및 출시 이벤트 계획(이 시리즈의 다음 문서)
• 시스템 설계, 보안, 개인 정보 보호, 규정 준수, 안정성, 비용 최적화, 성능 최적화 등 아키텍처 프레임워크의 다른 카테고리 살펴보기

최대 트래픽 및 출시 이벤트 대비 계획

Google Cloud 아키텍처 프레임워크의 이 문서에서에서는 비즈니스 중단을 방지하기 위해 최대 트래픽을 계획하고 이벤트를 시작하는 방법을 보여줍니다.

피크 이벤트는 애플리케이션의 표준 기준을 초과하는 급격한 트래픽 증가를 유발하는 주요 비즈니스 관련 이벤트입니다. 이러한 피크 이벤트를 위해 계획된 확장이 필요합니다.

예를 들어 온라인 상점을 보유한 소매업 비즈니스는 연말연시 중에 피크 이벤트가 발생할 수 있습니다. 미국에서 추수감사절 다음 날부터 시작되는 블랙 프라이데이는 일 년 중 가장 많은 쇼핑이 이루어지는 성수기 중 하나입니다. 미국 내 의료 업계의 경우 10월과 11월의 의료 보험 등록 관련 온라인 트래픽이 급증하면서 최대 트래픽이 발생할 수 있습니다.

출시 이벤트는 대대적 출시 또는 프로덕션의 신기능 마이그레이션을 의미합니다. 예를 들어 온프레미스에서 클라우드로 마이그레이션하거나 새로운 제품 서비스 또는 기능을 출시합니다.

신제품을 출시하는 경우 발표 도중과 그 이후에 시스템 부하가 증가할 것으로 예상해야 합니다. 이러한 이벤트로 인해 프런트엔드 시스템의 부하가 5~20배 이상 증가할 수 있습니다. 이 같은 부하로 인해 백엔드 시스템의 부하도 늘어납니다. 이러한 프런트엔드 및 백엔드 부하의 경우 이벤트가 열리면 웹 트래픽이 단시간 내에 빠르게 확장되는 특성이 있습니다. 출시 이벤트에서는 트래픽이 점차 정상 수준으로 감소합니다. 하락 속도는 일반적으로 상승 속도보다 느립니다.

피크 이벤트 및 출시 이벤트에는 3가지 단계가 포함됩니다.

• 출시 또는 최대 트래픽 이벤트의 계획 및 준비
• 이벤트 출시
• 이벤트 성과 및 이벤트 후 분석 검토

이 문서에 설명된 방법이 각 단계를 원활하게 실행하는 데 도움이 될 수 있습니다.

출시 및 피크 이벤트를 위한 일반 플레이북 만들기

현재 및 미래의 피크 이벤트에 대한 장기적인 관점으로 일반 플레이북을 작성합니다. 이후 피크 이벤트에 대한 참조가 될 수 있도록 문서에 학습한 내용을 계속 추가합니다.

출시 및 피크 이벤트 계획

미리 계획하세요. 예정된 출시 및 예상된(또는 예기치 않은) 피크 이벤트에 대한 비즈니스 예측을 만듭니다. 확장 급증에 대비한 시스템 준비는 비즈니스 예측을 이해하는 데 따라 달라집니다. 이전 예측으로부터 더 많은 정보를 알아낼수록 새로운 비즈니스 예측을 더 정확하게 수행할 수 있습니다. 이와 같은 새로운 예측 정보는 시스템에 예상되는 수요가 어느 정도인지를 판단하는 데에도 중요한 데이터입니다.

조직 전체 및 타사 공급업체와 함께 프로그램 관리 및 조율된 계획을 수립하는 것 역시 성공의 비결입니다. 프로그램 관리팀이 타임라인을 설정하고, 예산을 확보하고, 추가 인프라, 테스트 지원, 교육을 위한 리소스를 모을 수 있도록 이러한 팀을 초기에 구성하세요.

명확한 커뮤니케이션 채널을 설정하는 것이 중요합니다. 커뮤니케이션은 출시 또는 피크 이벤트의 모든 단계에서 중요합니다. 위험과 우려되는 부분을 미리 논의하고 문제가 심각한 장애물이 되기 전에 뜻을 모아 해결합니다. 이벤트 계획 문서를 만듭니다. 피크 이벤트에 대한 가장 중요한 정보를 간추려 배포합니다. 이렇게 하면 사람들이 계획 정보를 이해하고 기본적인 질문을 해결하는 데 도움이 됩니다. 이 문서는 새로 참여한 사람이 피크 이벤트 계획을 숙지할 수 있게 하는 데 도움이 됩니다.

각 이벤트의 계획을 문서화합니다. 계획을 문서화할 때 다음을 수행해야 합니다.

• 가정, 위험, 알 수 없는 요소를 파악합니다.
• 과거 이벤트를 검토하여 예정된 출시 또는 피크 이벤트에 관련된 정보를 확인합니다. 사용 가능한 데이터와 해당 데이터가 과거에 어떠한 가치를 제공했는지 파악합니다.
• 출시 및 마이그레이션 이벤트의 롤백 계획을 자세히 세웁니다.
• 아키텍처 검토를 수행합니다.
  • 핵심 리소스 및 아키텍처 구성요소를 문서화합니다.
  • 아키텍처 프레임워크를 사용하여 환경의 모든 측면에서 위험과 확장 문제를 검토합니다.
  • 아키텍처의 주요 구성요소가 연결되는 방식을 보여주는 다이어그램을 만듭니다. 다이어그램을 검토하면 문제를 격리하고 해결 속도를 높이는 데 도움이 될 수 있습니다.
• 해당되는 경우 실패 시 자동 다시 시작을 수행하도록 알림 작업을 사용하도록 서비스를 구성합니다. Compute Engine을 사용할 때는 처리량 급증 처리를 위해 자동 확장을 사용하는 것이 좋습니다.
• 필요할 때 Compute Engine 리소스를 사용할 수 있게 하려면 예약을 사용합니다. 예약을 사용하면 매우 높은 수준의 확신으로 Compute Engine 영역별 리소스의 용량을 확보할 수 있습니다. 예약을 사용하면 프로젝트에 사용 가능한 리소스가 있는지 확인할 수 있습니다.
• 추적할 측정항목과 알림을 파악합니다.
  • 이벤트에서 모니터링할 비즈니스 및 시스템 측정항목을 파악합니다. 측정항목 또는 서비스 수준 지표(SLI)를 수집하지 않는 경우 이 데이터를 수집하도록 시스템을 수정합니다.
  • 모니터링 및 알림 기능이 충분한지, 정상 및 이전 최대 트래픽 패턴을 검토했는지 확인합니다. 알림이 적절하게 설정되어 있는지 확인합니다. Google Cloud Monitoring 도구를 사용하여 애플리케이션 사용량, 용량, 애플리케이션과 인프라의 전체 상태를 봅니다.
  • 관심 모니터링 및 알림 수준으로 시스템 측정항목이 캡처되고 있는지 확인합니다.
• Google Cloud 계정팀과 함께 증가한 용량 요구사항을 검토하고 필요한 할당량 관리를 계획합니다. 자세한 내용은 할당량이 용량 요구사항과 일치하는지 확인을 확인하세요.
• 적절한 클라우드 지원 수준이 마련되어 있는지, 팀이 지원 케이스를 여는 방법을 이해하고 있는지, 에스컬레이션 경로가 설정되어 있는지 확인합니다. 자세한 내용은 클라우드 지원 및 에스컬레이션 프로세스 설정을 참조하세요.
• 커뮤니케이션과 관련한 계획, 일정, 책임을 정의하세요.
  • 여러 부서의 이해 관계자와 협력하여 커뮤니케이션 및 프로그램 계획을 조정합니다. 이러한 이해관계자에는 기술, 운영, 리더십 팀과 타사 공급업체의 적절한 인력이 포함될 수 있습니다.
  • 중요한 작업과 해당 작업의 담당팀이 포함된 명확한 타임라인을 설정합니다.
  • 팀, 팀 리더, 관계자, 책임자의 소유권을 알리는 책임 할당 매트릭스(RACI)를 설정합니다.
  • 계획된 피크 이벤트에 프리미엄 지원의 이벤트 관리 서비스를 사용할 수 있습니다. 이 서비스를 사용하면 고객 관리 파트너가 팀과 협력하여 계획을 세우고 이벤트 기간 동안 안내를 제공합니다.

검토 프로세스 구축

최대 트래픽 이벤트 또는 출시 이벤트가 끝나면 이벤트를 검토하여 학습한 내용을 문서화합니다. 그런 다음 해당 내용으로 플레이북을 업데이트합니다. 마지막으로 알게 된 내용을 다음 주요 이벤트에 적용합니다. 특히 부하가 걸렸을 때 시스템에 어떤 제약이 있었는지가 확연히 드러나는 경우 이전 이벤트로부터 배우는 것이 중요합니다.

최대 트래픽 이벤트 또는 출시 이벤트에 대한 소급 검토(사후 분석이라고도 함)은 데이터를 캡처하고 발생한 이슈를 이해하는 데 유용한 기법입니다. 예상대로 진행된 최대 트래픽 및 출시 이벤트와 문제가 발생한 이슈에 소급 검토를 수행합니다. 이 같은 검토를 진행할 때 비난 없는 문화를 조성합니다.

사후 분석에 대한 자세한 내용은 사후 분석 문화: 실패로부터 학습을 참조하세요.

다음 단계

• 자동화 문화 만들기(이 시리즈의 다음 문서)
• 시스템 설계, 보안, 개인 정보 보호, 규정 준수, 안정성, 비용 최적화, 성능 최적화 등 아키텍처 프레임워크의 다른 카테고리 살펴보기

자동화 문화 만들기

Google Cloud 아키텍처 프레임워크의 이 문서에서는 수작업을 평가하고 시스템 및 팀에 미치는 영향을 완화하는 방법을 보여줍니다.

반복 업무는 지속적인 가치가 없는 반복적인 수작업이며 서비스가 성장함에 따라 증가합니다. 따라서 이 수작업을 지속적으로 줄이거나 최소화하기 위해 노력해야 합니다. 그렇지 않으면 운영 작업은 결국 작업자를 완전히 지치게 만들고 제품 사용이나 복잡성이 증가하면 인력을 추가해야 할 수 있습니다.

자동화는 반복 업무를 최소화하는 핵심 방법입니다. 또한 자동화를 통해 출시 속도를 향상시키고 사람에 의한 오류를 최소화할 수 있습니다.

자세한 내용은 반복 업무 제거를 참조하세요.

수작업 목록 작성 및 비용 평가

인벤토리를 만들고 시스템을 관리하는 팀의 반복 업무를 평가하는 것부터 시작합니다. 이 지속적인 프로세스를 수행한 후에 맞춤설정된 자동화에 투자하여 Google Cloud 서비스와 파트너에서 이미 제공한 서비스를 확장합니다. 경우에 따라 Compute Engine의 자동 확장 처리와 같은 Google Cloud의 자체 자동화 기능을 수정할 수 있습니다.

수작업 제거 우선순위 지정

자동화는 유용하지만 모든 운영 문제에 대한 해결책은 아닙니다. 알려진 반복 업무를 처리하는 첫 번째 단계로 기존 반복 업무의 인벤토리를 검토하고 우선적으로 최대한 많은 반복 업무를 제거하는 것이 좋습니다. 그러면 자동화에 집중할 수 있습니다.

필요한 반복 업무 자동화

시스템의 일부 반복 업무를 제거할 수 없습니다. 알려진 반복 업무를 처리하는 두 번째 단계는 Google Cloud에서 구성 가능한 자동화를 통해 제공하는 솔루션을 사용하여 이러한 반복 업무를 자동화하는 것입니다.

구성 가능한 자동화나 맞춤설정된 자동화가 반복 업무를 제거하려는 조직을 지원할 수 있는 몇 가지 영역은 다음과 같습니다.

• ID 관리(예: Cloud ID 및 Identity and Access Management)
• 자체 설계된 솔루션과 달리 Google Cloud에서 호스팅하는 솔루션(예: 클러스터 관리(Google Kubernetes Engine(GKE)), 관계형 데이터베이스 관리(Cloud SQL), 데이터 웨어하우스 관리(BigQuery), API 관리(Apigee))
• Google Cloud 서비스 및 테넌트 프로비저닝(예: Terraform, Cloud Foundation Toolkit)
• 다단계 작업(예: Cloud Composer)을 위한 자동화된 워크플로 조정
• 추가 용량 프로비저닝(예: Compute Engine 및 GKE와 같은 여러 Google Cloud 제품)에서는 구성 가능한 자동 확장을 제공합니다. 사용 중인 Google Cloud 서비스를 평가하여 구성 가능한 자동 확장이 포함되어 있는지 확인합니다.
• 자동 배포 기능이 포함된 CI/CD 파이프라인(예: Cloud Build)
• 배포 검증을 위한 카나리아 분석
• 머신러닝을 위한 자동화된 모델 학습(예: AutoML)

수동 워크플로를 자동화하거나 삭제할 때 Google Cloud 제품이나 서비스가 기술 요구사항 일부분만 충족하는 경우 Google Cloud 계정 담당자를 통해 기능 요청을 제출하는 것이 좋습니다. 문제는 다른 고객의 우선순위가 되거나 이미 로드맵의 일부일 수도 있습니다. 이러한 경우 기능 우선순위와 타임라인을 알고 있으면 고유한 솔루션 빌드와 Google Cloud 기능을 사용하기 위한 대기 간의 관계를 더욱 효율적으로 평가할 수 있습니다.

고비용 수작업을 위해 솔루션 빌드 또는 구매

첫 번째 단계 및 두 번째 단계와 동시에 완료할 수 있는 세 번째 단계에서는 수작업 비용이 높게 유지(예: 프로덕션 시스템을 관리하는 모든 팀이 수작업에 많은 시간을 할애함)되는 경우에 대비해 다른 솔루션의 빌드 또는 구매를 평가합니다.

솔루션을 빌드하거나 구매할 때는 통합, 보안, 개인 정보 보호, 규정 준수 비용을 고려합니다. 고유한 자동화를 설계하고 구현하면 초기 개발 및 설정 비용 외에도 유지보수 비용과 안정성에 대한 위험이 발생하므로 이 옵션을 최후의 수단으로 사용하는 것이 좋습니다.

다음 단계

시스템 설계, 보안, 개인 정보 보호, 규정 준수, 안정성, 비용 최적화, 성능 최적화 등 아키텍처 프레임워크의 다른 카테고리 살펴보기

Google Cloud 아키텍처 프레임워크: 보안, 개인 정보 보호, 규정 준수

Google Cloud 아키텍처 프레임워크의 이 카테고리에서는 Google Cloud에서 보안 서비스를 설계하고 운영하는 방법을 보여줍니다. 보안 및 규정 준수를 지원하는 Google Cloud 제품 및 기능에 대해서도 알아봅니다.

아키텍처 프레임워크는 권장사항을 설명하고 구현 권장사항을 제공하며 사용 가능한 여러 제품 및 서비스를 설명합니다. 이 프레임워크는 비즈니스 요구사항에 맞게 Google Cloud 배포를 설계하도록 도와줍니다.

워크로드를 Google Cloud로 이전하려면 비즈니스 요구사항, 위험, 규정 준수 의무, 보안 제어 기능을 평가해야 합니다. 이 문서는 Google Cloud에서 안전한 솔루션을 설계하는 것과 관련된 주요 권장사항을 고려하는 데 도움이 됩니다.

Google 핵심 원칙에는 심층 방어, 대규모, 기본 지원이 포함됩니다. Google Cloud에서 데이터와 시스템은 IAM, 암호화, 네트워킹, 감지, 로깅 및 모니터링에 구성된 정책과 제어 기능을 사용하여 여러 레이어로 구성된 방어를 통해 보호됩니다.

Google Cloud에서는 다음과 같은 다양한 보안 제어 기능을 활용할 수 있습니다.

• 전송 중 데이터를 위한 보안 옵션 및 저장 데이터의 기본 암호화
• Google Cloud 제품 및 서비스를 위해 기본 제공되는 보안 기능
• 정보 처리 수명 주기를 아우르는 보안 제어 기능을 비롯하여 지리적 중복성을 위해 설계된 글로벌 인프라
• 코드형 인프라(IaC) 및 구성 가드레일을 사용하는 자동화 기능

Google Cloud의 보안 상황에 대한 자세한 내용은 Google 보안 자료 및 Google 인프라 보안 설계 개요를 참조하세요. 기본 보안 환경의 예시는 Google Cloud 엔터프라이즈 기반 청사진을 참조하세요.

아키텍처 프레임워크의 보안 카테고리에서는 다음을 수행하는 방법을 알아봅니다.

• Google Cloud에서 공유 책임과 공통된 운명 검토
• 보안 원칙 이해
• 제어 기능을 통한 위험 관리
• 애셋 관리
• ID 및 액세스 관리
• 컴퓨팅 및 컨테이너 보안 구현
• 네트워크 보호
• 데이터 보안 구현
• 애플리케이션 보안 기능 배포
• 규정 준수 의무 관리
• 데이터 상주 및 데이터 주권 요구사항 구현
• 개인 정보 보호 요건 구현
• 로깅 및 감지 제어 구현

Google Cloud의 책임 공유 및 공통된 운명

이 문서에서는 Google Cloud의 책임 공유 모델과 공통된 운명의 차이점을 설명합니다. 책임 공유 모델의 과제와 미묘한 차이에 대해서도 다룹니다. 공통된 운명이란 무엇이며 클라우드 보안 과제를 해결하기 위해 고객과 어떻게 협력하는지 설명합니다.

Google Cloud에서 데이터와 워크로드를 가장 안전하게 보호하는 방법을 결정하려면 책임 공유 모델을 이해해야 합니다. 책임 공유 모델에서는 사용자 작업을 클라우드 보안과 관련해 설명하고 사용자 작업이 클라우드 제공업체의 작업과 어떻게 다른지 소개합니다.

그러나 책임 공유 모델을 이해하기란 어려울 수 있습니다. 이 모델에 대해 알려면 사용자가 활용하는 각각의 서비스, 각 서비스가 제공하는 구성 옵션, 서비스 보호를 위한 Google Cloud 조치를 심층적으로 이해해야 합니다. 서비스마다 구성 프로필이 다르므로 최적의 보안 구성을 결정하기 어려울 수 있습니다. Google은 책임 공유 모델만으로는 클라우드 고객이 더 나은 보안 결과를 얻도록 지원하지 못한다고 생각합니다. Google은 책임 공유 대신 공통된 운명의 힘을 믿습니다.

공통된 운명에는 워크로드를 위한 신뢰할 수 있는 클라우드 플랫폼을 구축하고 운영하기 위한 Google의 노력이 포함됩니다. Google은 안전한 방식으로 워크로드를 배포하기 위해 사용할 수 있는 권장사항 안내와 안전한 입증된 인프라 코드를 제공합니다. Google에서는 복잡한 보안 문제를 해결하는 여러 Google Cloud 서비스를 결합한 솔루션을 출시하고 사용자가 감수해야 할 위험을 측정하고 완화하는 데 도움이 될 혁신적인 보험 옵션을 제공합니다. 공통된 운명은 사용자가 Google Cloud에서 리소스를 보호할 때 Google이 사용자와 더욱 긴밀하게 상호작용한다는 의미입니다.

공유 책임

비즈니스의 보안 및 규제 요구사항을 파악하고 기밀 데이터 및 리소스를 보호하기 위한 요구사항을 잘 알고 있는 전문가입니다. Google Cloud에서 워크로드를 실행할 때 기밀 데이터와 각 워크로드를 보호하기 위해 Google Cloud에서 구성해야 하는 보안 제어를 식별해야 합니다. 구현할 보안 제어를 결정하려면 다음 요소를 고려해야 합니다.

• 규정 준수 의무
• 조직의 보안 표준 및 위험 관리 계획
• 고객 및 공급업체의 보안 요구사항

워크로드에 따른 정의

일반적으로 책임은 실행 중인 워크로드 유형과 필요한 클라우드 서비스에 따라 정의됩니다. 클라우드 서비스에는 다음 카테고리가 포함됩니다.

클라우드 서비스	설명
Infrastructure as a Service(IaaS)	IaaS 서비스에는 Compute Engine, Cloud Storage와 Cloud VPN, Cloud Load Balancing, Cloud DNS 등의 네트워킹 서비스가 포함됩니다. IaaS는 사용한 만큼만 지불하는 컴퓨팅, 스토리지, 네트워크 서비스를 주문형으로 제공합니다. 리프트 앤 시프트를 사용하여 기존 온프레미스 워크로드를 클라우드로 마이그레이션할 계획이거나 특정 데이터베이스 또는 네트워크 구성을 사용해 특정 VM에서 애플리케이션을 실행하려는 경우 IaaS를 사용하면 됩니다. IaaS에서는 대부분의 보안 책임이 사용자에게 있는 반면 Google의 책임은 주로 기본 인프라 및 물리적 보안에 있습니다.
Platform as a Service(PaaS)	PaaS 서비스에는 App Engine, Google Kubernetes Engine(GKE), BigQuery가 포함됩니다. PaaS는 애플리케이션을 개발하고 실행할 수 있는 런타임 환경을 제공합니다. 애플리케이션(예: 웹사이트)을 빌드하고 기본 인프라가 아닌 개발에 집중하려는 경우 PaaS를 사용할 수 있습니다. PaaS에서는 Google이 IaaS에 비해 네트워크 제어를 비롯한 더 많은 제어를 책임집니다. 애플리케이션 수준 제어 및 IAM 관리에 대한 책임을 사용자와 Google이 공유합니다. 사용자에게는 데이터 보안 및 클라이언트 보호에 대한 책임이 있습니다.
Software as a service(SaaS)	SaaS 애플리케이션에는 Google Workspace, Chronicle, Google Cloud Marketplace에서 제공되는 타사 SaaS 애플리케이션이 포함됩니다. SaaS는 어떤 방식으로든 구독하거나 비용을 지불할 수 있는 온라인 애플리케이션을 제공합니다. 기업에서 애플리케이션을 직접 빌드하는 데 필요한 내부 전문성 또는 비즈니스 요구사항이 없지만 워크로드를 처리할 수 있는 능력이 필요한 경우 SaaS 애플리케이션을 사용하면 됩니다. SaaS에서는 Google에서 보안 책임을 대부분 맡고 있습니다. 애플리케이션에 저장하도록 선택한 데이터와 액세스 제어에 대한 책임은 사용자에게 있습니다.
서비스로서의 기능(FaaS) 또는 서버리스	FaaS는 특정 이벤트에 대한 응답으로 실행되는 작은 단일 목적 코드(함수)를 실행할 수 있는 플랫폼을 개발자에게 제공합니다. 특정 이벤트를 기반으로 특정 작업이 수행되도록 하려면 FaaS를 사용합니다. 예를 들어 데이터를 Cloud Storage에 업로드할 때마다 실행되는 함수를 만들어 분류할 수 있습니다. FaaS에는 SaaS와 유사한 공유 책임 목록이 있습니다. Cloud Functions는 FaaS 애플리케이션입니다.

다음 다이어그램에서는 클라우드 서비스를 보여주며 클라우드 제공업체와 고객이 책임을 공유하는 방법을 정의합니다.

다이어그램에서 볼 수 있듯이 클라우드 제공업체는 항상 기본 네트워크 및 인프라를 책임지고 고객에게는 항상 액세스 정책 및 데이터에 대한 책임이 있습니다.

업계 및 규제 프레임워크에 따른 정의

업종마다 마련해야 할 보안 제어를 정의하는 규제 프레임워크가 있습니다. 워크로드를 클라우드로 이전할 때는 다음 사항을 이해해야 합니다.

• 사용자가 책임지는 보안 제어
• 클라우드 제품의 일부로 제공되는 보안 제어
• 상속되는 기본 보안 제어

상속된 보안 제어(예: 기본 암호화 및 인프라 제어)는 감사 기관 및 규제 당국에 보안 상태에 대한 증거로 제공할 수 있는 제어입니다. 예를 들어 결제 카드 산업 데이터 보안 표준(PCI DSS)에서는 결제 대행업체에 적용되는 규정을 정의합니다. 비즈니스를 클라우드로 이전하면 이러한 규정이 사용자와 CSP 간에 공유됩니다. 사용자와 Google Cloud 간에 PCI DSS 책임을 공유하는 방법은 Google Cloud: PCI DSS 공유 책임 규정을 참조하세요.

또 다른 예시로 미국에서는 건강 보험 이동성 및 책임법(HIPAA)에 따라 전자 개인 건강 정보(PHI) 처리 표준이 설정되어 있습니다. 이러한 책임은 CSP와 사용자 사이에 공유됩니다. Google Cloud가 HIPAA에 따른 책임을 충족하는 방법에 대한 자세한 내용은 HIPAA - 규정 준수를 참조하세요.

금융 또는 제조업과 같은 다른 업계에도 데이터 수집, 처리, 저장 방법을 정의하는 규정이 있습니다. 이와 관련된 공유 책임 및 Google Cloud이 책임을 이행하는 방법에 대한 자세한 내용은 규정 준수 리소스 센터를 참조하세요.

위치에 따른 정의

비즈니스 시나리오에 따라 비즈니스 사무실, 고객, 데이터의 위치에 따라 책임을 고려해야 할 수 있습니다. 국가 및 지역마다 고객의 데이터를 처리하고 저장하는 방법을 알려주는 규정을 만들었습니다. 예를 들어 비즈니스에 유럽 연합에 거주하는 고객이 있는 경우 비즈니스는 개인 정보 보호법(GDPR)에 설명된 대로 요구사항을 준수해야 할 수 있으며 고객 데이터를 EU에 보관할 의무가 있을 수 있습니다. 이 경우 사용자는 수집한 데이터가 EU의 Google Cloud 리전에 유지되도록 해야 합니다. Google의 GDPR 의무 준수 방법에 대한 자세한 내용은 GDPR 및 Google Cloud를 참조하세요.

리전과 관련된 요구사항에 대한 자세한 내용은 규정 준수 제품을 참조하세요. 시나리오가 특히 복잡한 경우 보안 책임을 평가하는 데 도움이 되도록 영업팀 또는 파트너에게 문의하는 것이 좋습니다.

책임 공유 과제

책임 공유는 사용자나 클라우드 제공업체의 보안 역할을 정의하는 데 도움이 되지만 책임 공유 모델을 활용해도 여전히 문제가 발생할 수 있습니다. 다음과 같은 시나리오를 가정합니다.

• 대부분의 클라우드 보안 침해는 (Cloud Security Alliance의 Pandemic 11 보고서 3번에 설명된 대로) 잘못된 구성으로 인한 직접적인 결과이며, 이러한 추세가 늘어날 것으로 예상됩니다. 클라우드 제품은 끊임없이 변화하고 있으며 새로운 제품이 계속 출시되고 있습니다. 거듭되는 변화를 따라잡기가 어려울 수 있습니다. 클라우드 제공업체는 변화에 대응하여 기본적인 권장사항과 안전한 기준 구성을 갖출 수 있는 독자적인 권장사항을 고객에게 제공해야 합니다.
• 클라우드 서비스별로 항목을 나누면 유용하지만 여러 클라우드 서비스 유형이 필요한 워크로드를 사용하는 기업이 많습니다. 이 경우 서비스 간 중복 여부를 포함해 이러한 서비스의 다양한 보안 제어가 상호작용하는 방식을 고려해야 합니다. 예를 들어 Compute Engine으로 마이그레이션하려는 온프레미스 애플리케이션이 있고 회사 이메일로 Google Workspace를 사용하며 BigQuery를 실행해 데이터를 분석하여 제품을 개선할 수 있습니다.
• 규정이 바뀌거나 신규 시장에 진출하거나 다른 기업을 인수함에 따라 비즈니스 및 시장이 계속 달라집니다. 신규 시장에 다른 요구사항이 있거나 새로운 인수로 인해 다른 클라우드에 워크로드를 호스팅할 수 있습니다. 끊임없는 변화를 관리하려면 위험 프로필을 지속적으로 다시 평가하고 새 제어를 빠르게 구현할 수 있어야 합니다.
• 데이터 암호화 키를 관리하는 방법과 위치는 데이터 보호에 대한 사용자 책임과 관련된 중요한 결정입니다. 규제 요구사항, 하이브리드 클라우드 환경 실행 여부, 온프레미스 환경 유지 여부, 처리 및 저장 중인 데이터의 민감도에 따라 선택해야 할 옵션이 달라집니다.
• 이슈 관리는 사용자의 책임과 클라우드 제공업체의 책임이 쉽게 정의되지 않는 영역으로서 중요하지만 종종 간과되는 부분입니다. 이슈를 조사하고 완화하려면 클라우드 제공업체의 긴밀한 협업과 지원이 필요합니다. 클라우드 리소스가 잘못 구성되었거나 사용자 인증 정보가 도용되어 발생하는 이슈도 있습니다. 리소스와 계정을 보호하기 위한 권장사항을 충족하기가 어려울 수 있습니다.
• APT(Advanced Persistent Threats) 및 새로운 취약점이 클라우드 혁신을 시작할 때 고려하지 못한 방식으로 워크로드에 영향을 미칠 수 있습니다. 특히 비즈니스에 대규모 보안팀이 없는 경우 변화하는 환경에서 최신 상태를 유지하고 위협 완화 담당자를 확보하기가 어렵습니다.

공유 운명

Google은 책임 공유 모델로는 해결할 수 없는 과제를 해결하기 위해 Google Cloud의 공통된 운명을 개발했습니다. 공통된 운명은 모든 당사자가 더 나은 상호작용을 통해 보안을 지속적으로 개선하는 방법에 초점을 맞춥니다. 클라우드 제공업체와 고객 간의 관계를 보안 개선을 위한 지속적인 파트너십으로 간주하므로 공통된 운명은 책임 공유 모델을 기반으로 합니다.

공통된 운명에서는 Google이 Google Cloud의 보안 강화를 책임지게 됩니다. 공통된 운명에는 안전한 시작 영역을 시작하도록 지원하고 권장되는 보안 제어, 설정, 관련 권장사항을 명확하고 독자적으로 투명하게 공개하는 관행이 포함됩니다. Google의 위험 보호 프로그램을 사용하여 사이버 보험으로 위험을 효과적으로 수치화하고 관리하도록 돕는 관행도 포함됩니다. Google은 공통된 운명을 활용하여 표준 책임 공유 프레임워크에서 한층 더 발전된 모델로 나아가 비즈니스를 보호하고 Google Cloud에서 신뢰를 구축하는 데 도움이 되고자 합니다.

다음 섹션에서는 공통된 운명의 다양한 구성요소를 설명합니다.

시작 지원

공통된 운명의 핵심 구성요소는 Google Cloud에서 안전한 구성으로 시작할 수 있도록 제공되는 리소스입니다. 안전한 구성으로 시작하면 대다수 보안 침해의 근본 원인인 잘못된 구성 문제를 줄일 수 있습니다.

다음과 같은 리소스가 포함됩니다.

• 엔터프라이즈 기반 청사진: 주요 보안 문제 및 주요 권장사항을 다룹니다.

• 보안 청사진: 코드형 인프라(IaC)를 사용하여 안전한 솔루션을 배포하고 유지보수할 수 있습니다. 청사진에는 기본적으로 보안 권장사항이 사용 설정되어 있습니다. 많은 청사진이 Google 보안팀에서 생성되어 제품으로 관리됩니다. 이러한 지원은 정기적으로 업데이트되고 엄격한 테스트 절차를 거치며 타사 테스트 그룹의 증명을 받습니다. 청사진에는 엔터프라이즈 기반 청사진, 보안 데이터 웨어하우스 청사진, Vertex AI Workbench 노트북 청사진이 포함됩니다.

• 아키텍처 프레임워크 권장사항: 설계에서 보안을 구현하기 위한 주요 권장사항을 다룹니다. 아키텍처 프레임워크에는 전문가 및 동료와 소통할 수 있는 보안 섹션과 커뮤니티 영역이 포함됩니다.

• 시작 영역 탐색 가이드: 리소스 계층 구조, ID 온보딩, 보안 및 키 관리, 네트워크 구조 등 워크로드의 안전한 기반을 구축하는 데 필요한 주요 결정을 안내합니다.

위험 보호 프로그램

또한 공통된 운명에는 위험 보호 프로그램(현재 미리보기 버전)도 포함되어 있습니다. 이 프로그램은 클라우드 워크로드를 관리해야 할 또 다른 위험 소스로 취급하기보다는 Google Cloud를 위험을 관리하는 플랫폼으로 활용할 수 있도록 도와줍니다. 위험 보호 프로그램은 Google Cloud와 선도적인 사이버 보험 회사인 Munich Re 및 Allianz Global & Corporate Speciality가 협업한 결과물입니다.

위험 보호 프로그램에는 클라우드 보안 상태를 더 잘 이해할 수 있는 데이터 기반 통계를 제공하는 Risk Manager가 포함되어 있습니다. 사이버 보험 보장 범위를 알아보고 싶다면 Risk Manager의 통계를 Google 보험 파트너와 바로 공유하여 견적을 받으면 됩니다. 자세한 내용은 미리보기 버전의 Google Cloud 위험 보호 프로그램을 참조하세요.

배포 및 거버넌스 지원

공통된 운명은 지속적인 환경 통제에도 도움이 됩니다. 예를 들어 Google에서는 다음과 같은 제품에 주력하고 있습니다.

• Assured Workloads는 규정 준수 의무를 준수하는 데 도움이 됩니다.
• Security Command Center 프리미엄은 위협 인텔리전스, 위협 감지, 웹 스캔, 기타 고급 방법을 사용하여 위협을 모니터링하고 감지합니다. 또한 이러한 위협을 신속하게 자동으로 해결하는 방법을 제공합니다.
• 조직 정책 및 리소스 설정: 폴더 및 프로젝트의 계층 구조 전반에 정책을 구성할 수 있습니다.
• Policy Intelligence 도구: 계정 및 리소스 액세스에 대한 통계를 제공합니다.
• 컨피덴셜 컴퓨팅: 사용 중 데이터를 암호화할 수 있습니다.
• Sovereign Cloud: 독일에서 제공되며 데이터 상주 요구사항을 구현합니다.

책임 공유 및 공통된 운명의 실천

계획 절차의 일환으로 적절한 보안 제어를 이해하고 구현하는 데 도움이 될 다음 작업을 고려해 보세요.

• Google Cloud에서 호스팅할 워크로드 유형과 IaaS, PaaS, SaaS 서비스가 필요한지 여부를 목록으로 작성합니다. 책임 공유 다이어그램을 체크리스트로 사용하면 고려해야 할 보안 제어를 파악할 수 있습니다.
• 준수해야 할 규제 요구사항 목록을 만들고 규정 준수 리소스 센터에서 이러한 요구사항과 관련된 리소스를 이용합니다.
• 특정 워크로드에 필요한 보안 제어와 관련해 아키텍처 센터에서 사용 가능한 청사진 및 아키텍처 목록을 검토합니다. 청사진에서는 권장 제어 목록과 해당 아키텍처를 배포하는 데 필요한 IaC 코드를 제공합니다.
• 시작 영역 문서 및 엔터프라이즈 기반 가이드의 권장사항을 따라 요구사항에 맞는 리소스 계층 구조와 네트워크 아키텍처를 설계합니다. 보안 데이터 웨어하우스 등 독자적인 워크로드 청사진을 사용하면 개발 프로세스를 가속화할 수 있습니다.
• 워크로드를 배포한 후 Risk Manager, Assured Workloads, Policy Intelligence 도구, Security Command Center 프리미엄과 같은 서비스를 사용하여 보안 책임을 충족하는지 확인합니다.

자세한 내용은 CISO의 클라우드 혁신 가이드 자료를 참조하세요.

다음 단계

• 보안 원칙(이 시리즈의 다음 문서) 검토하기
• 공통된 운명 리소스의 최신 정보 확인하기
• 보안 기반 청사진 및 보안 데이터 웨어하우스와 같은 워크로드 예시를 포함해 사용 가능한 청사진 숙지하기
• 공통된 운명 자세히 알아보기
• Google 인프라 보안 설계 개요에서 Google의 기본 보안 인프라에 대해 알아보기
• Google Cloud의 NIST 사이버 보안 프레임워크 권장사항(PDF) 구현 방법 읽기

보안 원칙

Google Cloud 아키텍처 프레임워크의 이 문서에서는 Google Cloud에서 안전하고 규정을 준수하는 서비스를 실행하는 핵심 원칙을 설명합니다. 온프레미스 환경에서 익숙한 많은 보안 원칙이 클라우드 환경에 적용됩니다.

레이어로 구성된 보안 접근 방식 빌드

심층 방어 방식을 적용하여 애플리케이션 및 인프라의 각 수준에서 보안을 구현합니다. 각 제품의 기능을 사용하여 필요에 따라 액세스를 제한하고 암호화를 구성합니다.

보안 분리 시스템을 위한 설계

가능한 경우 유연성을 수용하도록 시스템 설계를 간소화하고 각 구성요소의 보안 요구사항을 문서화합니다. 복원력과 복구를 고려하여 견고한 보안 메커니즘을 통합하세요.

민감한 작업의 배포 자동화

배포 및 기타 관리 작업을 자동화하여 작업 스트림에서 수동 작업을 최소화합니다.

보안 모니터링 자동화

자동화된 도구를 사용하여 애플리케이션과 인프라를 모니터링합니다. 인프라의 취약점을 검사하고 보안 이슈를 감지하려면 지속적 통합 및 지속적 배포(CI/CD) 파이프라인에서 자동화된 스캔을 사용하세요.

리전의 규정 준수 요구사항 충족

규제 요건을 충족하기 위해 개인 식별 정 (PII)를 난독화하거나 수정해야 할 수도 있습니다. 가능하면 규정 준수 작업을 자동화합니다. 예를 들어 새 데이터가 시스템에 저장되기 전에 Sensitive Data Protection 및 Dataflow를 사용하여 PII 수정 작업을 자동화합니다.

데이터 상주 및 데이터 주권 요구사항 준수

데이터 스토리지 및 처리 위치를 제어해야 하는 내부(또는 외부) 요구사항이 있을 수 있습니다. 이러한 요구사항은 시스템 설계 목표, 업계 규제 문제, 국가 법률, 세금 관련 사항, 문화에 따라 달라집니다. 데이터 상주는 데이터 저장 위치를 설명합니다. 데이터 상주 요구사항을 준수하기 위해 Google Cloud는 데이터 저장 위치, 액세스 방법, 처리 방법을 제어할 수 있습니다.

개발 초기부터 보안 문제 반영

DevOps 및 배포 자동화를 통해 조직은 제품 제공 속도를 높일 수 있습니다. 제품의 보안을 유지하려면 개발 프로세스 시작 시점부터 보안 프로세스를 통합하세요. 예를 들어 다음을 수행할 수 있습니다.

• 배포 파이프라인 초기에 코드의 보안 문제를 테스트합니다.
• 지속적으로 컨테이너 이미지와 클라우드 인프라를 스캔합니다.
• 잘못된 구성 및 보안 방지 패턴 감지를 자동화합니다. 예를 들어 자동화를 사용하여 애플리케이션 또는 구성에 하드 코딩된 보안 비밀을 찾습니다.

다음 단계

다음 리소스를 통해 핵심 보안 원칙에 대해 자세히 알아봅니다.

• 컨트롤을 통한 위험 관리(이 시리즈의 다음 문서)
• Google Cloud 엔터프라이즈 기반 청사진
• Google 보안 자료
• Google 인프라 보안 설계 개요
• 이슈 관리를 위한 공동작업 프로세스 빌드
• 업종별 배포 가능한 청사진

여러 제어 기능을 통한 위험 관리

Google Cloud 아키텍처 프레임워크의 이 문서에서는 클라우드 배포의 위험 관리를 위한 권장사항을 설명합니다. 조직에 적용되는 위험을 신중하게 분석하면 필요한 보안 제어를 결정할 수 있습니다. Google Cloud에 워크로드를 배포하기 전에 위험 분석을 완료해야 하며 이후 비즈니스 요구사항, 규제 요건, 조직과 관련된 위협에 따라 정기적으로 분석을 수행해야 합니다.

조직의 위험 파악

Google Cloud에 리소스를 만들고 배포하기 전에 위험 평가를 완료하여 내부 보안 요구사항과 외부 규제 요건을 충족하는 데 필요한 보안 기능을 결정합니다. 위험 평가는 사용자와 관련된 위험 카탈로그를 제공하며 보안 위협을 감지하고 완화할 수 있는 조직의 역량이 얼마나 되는지 알려줍니다.

클라우드 환경의 위험은 이용하는 클라우드 제공업체와의 공유 책임이 있으므로 온프레미스 환경의 위험과는 다릅니다. 예를 들어 온프레미스 환경에서는 사용자가 하드웨어 스택의 취약점을 완화해야 합니다. 반면에 클라우드 환경에서는 이러한 위험이 클라우드 제공업체에 의해 발생합니다.

또한 위험은 Google Cloud 사용 계획에 따라 달라집니다. Google Cloud로 일부 워크로드를 전송하나요? 아니면 모든 워크로드를 전송하나요? 재해 복구 목적으로만 Google Cloud를 사용 중인가요? 하이브리드 클라우드 환경을 설정하고 있나요?

클라우드 환경과 규제 요건에 적용되는 업계 표준 위험 평가 프레임워크를 사용하는 것이 좋습니다. 예를 들어 Cloud Security Alliance(CSA)는 Cloud Controls Matrix(CCM)를 제공합니다. 또한 잠재적인 차이점의 목록을 제공하고 발견된 모든 차이를 해결하기 위한 조치를 제안하는 OWASP 애플리케이션 위협 모델링과 같은 위협 모델이 있습니다. 파트너 디렉터리에서 Google Cloud 위험 평가 수행에 대한 전문가 목록을 확인할 수 있습니다.

위험을 분류하는 데 도움이 되도록 위험 보호 프로그램에 포함된 Risk Manager를 사용하는 것이 좋습니다. (이 프로그램은 현재 미리보기입니다.) Risk Manager는 워크로드를 검사하여 비즈니스 위험을 파악합니다. 해당 세부 보고서는 보안 기준을 제공합니다. 또한 Risk Manager 보고서를 사용하여 위험을 인터넷 보안 센터(CIS) 벤치마크에 설명된 위험과 비교할 수 있습니다.

위험을 카탈로그화한 후에는 위험을 해결하는 방법, 즉 위험을 허용, 방지, 이전 또는 완화할지 결정해야 합니다. 다음 섹션에서는 완화 제어 방법을 설명합니다.

위험 완화

기술 제어, 계약 보호, 제3자 확인 또는 증명을 사용하여 위험을 완화할 수 있습니다. 다음 표에는 새로운 퍼블릭 클라우드 서비스를 도입할 때 이러한 완화 조치를 사용하는 방법이 나와 있습니다.

위험 완화	설명
기술 제어	기술 제어는 환경을 보호하기 위해 사용하는 기능 및 기술을 의미합니다. 여기에는 방화벽 및 로깅과 같이 기본 제공되는 클라우드 보안 제어가 포함됩니다. 기술 제어에는 보안 도구를 강화하거나 지원하기 위해 타사 도구를 사용하는 것도 포함될 수 있습니다. 기술 관리에는 두 가지 카테고리가 있습니다. Google Cloud에는 사용자에게 적용되는 위험을 완화할 수 있는 다양한 보안 제어 기능이 포함되어 있습니다. 예를 들어 온프레미스 환경이 있으면 Cloud VPN과 Cloud Interconnect를 사용하여 온프레미스와 클라우드 리소스 간의 연결을 보호할 수 있습니다. Google은 고객 데이터에 내부자가 액세스하는 것을 방지하기 위해 강력한 내부 제어 및 감사 시스템을 갖추고 있습니다. Google의 감사 로그는 고객에게 Google Cloud에서 Google 관리자 액세스 로그를 거의 실시간으로 제공합니다.
계약 보호	계약 보호는 Google Cloud 서비스에 대한 Google의 법적 약속을 의미합니다. Google은 규정 준수 포트폴리오를 유지보수하고 확장하기 위해 최선을 다하고 있습니다. Cloud 데이터 처리 추가 조항(CDPA) 문서에는 ISO 27001, 27017, 27018 인증을 유지하고 SOC 2 및 SOC 3 보고서를 12개월마다 업데이트한다는 Google의 노력이 명시되어 있습니다. DPST 문서에서는 Google 지원 엔지니어의 고객 환경에 대한 액세스를 제한하기 위해 마련된 액세스 제어에 대해 간략하게 설명하고 엄격한 로깅과 승인 절차에 대해 설명합니다. 법률 및 규제 전문가와의 Google Cloud 계약 제어 시스템을 검토하고 요구사항을 충족하는지 확인하는 것이 좋습니다. 자세한 내용은 기술 계정 담당자에게 문의하세요.
제3자 인증 또는 증명	제3자 검증 또는 증명은 클라우드 제공업체가 규정 준수 요구사항을 충족하는지 제3자 공급업체가 감사하는 것을 의미합니다. 예를 들어 Google은 ISO 27017 규정 준수에 대해 제3자의 감사를 받습니다. 현재 Google Cloud 인증 및 증명서는 규정 준수 리소스 센터에서 확인할 수 있습니다.

다음 단계

다음 리소스를 통해 위험 관리에 대해 자세히 알아보세요.

• 애셋 관리(이 시리즈의 다음 문서)

• 위험 보호 프로그램

• 규정 준수 리소스 센터

• 클라우드 디지털 혁신의 위험 관리(PDF)

애셋 관리

Google Cloud 아키텍처 프레임워크의 이 문서에서는 애셋 관리를 위한 권장사항을 제공합니다.

애셋 관리는 비즈니스 요구사항 분석의 중요한 부분입니다. 보유한 애셋을 알고 있어야 하며 모든 애셋, 애셋의 가치, 모든 중요한 관련 경로나 프로세스를 잘 이해하고 있어야 합니다. 애셋을 보호하기 위해 보안 제어를 구축하려면 먼저 정확한 애셋 인벤토리가 있어야 합니다.

보안 이슈를 관리하고 조직의 규제 요건을 충족하려면 이전 데이터를 분석하는 방법이 포함된 정확한 최신 애셋 인벤토리가 필요합니다. 시간 경과에 따른 위험 노출 변화를 포함하여 애셋을 추적할 수 있어야 합니다.

Google Cloud로 이전한다는 것은 클라우드 환경에 맞게 애셋 관리 프로세스를 수정해야 함을 의미합니다. 예를 들어 클라우드로 이전할 경우의 이점 중 하나는 조직이 빠르게 확장할 수 있는 능력을 높이는 것입니다. 하지만 빠르게 확장할 수 있는 기능으로 인해 직원이 적절히 관리되거나 보호되지 않는 클라우드 리소스를 만드는 비공식 IT 문제가 발생할 수 있습니다. 따라서 애셋 관리 프로세스는 충분한 유연성을 제공하여 직원이 업무를 수행하며 적절한 보안 제어를 제공할 수 있도록 해야 합니다.

클라우드 애셋 관리 도구 사용

Google Cloud 애셋 관리 도구는 Google 환경과 주요 고객 사용 사례에 맞게 특별히 설계되었습니다.

이러한 도구 중 하나인 Cloud 애셋 인벤토리는 리소스의 현재 상태에 대한 실시간 정보와 5주 간의 기록을 제공합니다. 이 서비스를 사용하면 다양한 Google Cloud 리소스 및 정책에 대한 조직 전체의 인벤토리 스냅샷을 얻을 수 있습니다. 그런 다음 자동화 도구는 스냅샷을 모니터링 또는 정책 시행에 사용하거나 규정 준수 감사를 위해 스냅샷을 보관처리할 수 있습니다. 애셋 인벤토리에서는 애셋의 변경사항을 분석하는 데 사용하도록 메타데이터 기록 내보내기도 지원합니다.

Cloud 애셋 인벤토리에 대한 자세한 내용은 애셋 변경사항에 대응하기 위한 커스텀 솔루션 및 감지 제어를 참조하세요.

애셋 관리 자동화

자동화를 사용하면 지정한 보안 요구사항에 따라 애셋을 빠르게 만들고 관리할 수 있습니다. 다음과 같은 방법으로 애셋 수명 주기의 요소를 자동화할 수 있습니다.

• Terraform과 같은 자동화 도구를 사용하여 클라우드 인프라를 배포합니다. Google Cloud는 보안 권장사항을 충족하는 인프라 리소스를 설정하는 데 도움이 되는 엔터프라이즈 기반 청사진을 제공합니다. 또한 Cloud 애셋 인벤토리에서 애셋 변경사항 및 정책 규정 준수 알림을 구성합니다.
• Cloud Run 및 Artifact Registry와 같은 자동화 도구를 사용하여 애플리케이션을 배포합니다.

규정 준수 정책 위반 모니터링

애셋 수명 주기의 모든 단계에서 정책 위반이 발생할 수 있습니다. 예를 들어 적절한 보안 제어 없이 애셋이 생성되거나 권한이 에스컬레이션될 수 있습니다. 마찬가지로 애셋이 적절한 지원 종료 절차를 따르지 않고 폐기될 수도 있습니다.

이러한 시나리오를 방지하려면 애셋을 규정 준수를 위반하지 않도록 모니터링하는 것이 좋습니다. 모니터링할 애셋 세트는 위험 평가 결과와 비즈니스 요구사항에 따라 달라집니다. 애셋 모니터링에 대한 자세한 내용은 애셋 변경사항 모니터링을 참조하세요.

기존 애셋 관리 모니터링 시스템과 통합

이미 SIEM 시스템이나 다른 모니터링 시스템을 사용하고 있다면 Google Cloud 애셋을 해당 시스템과 통합합니다. 통합을 통해 조직이 환경에 관계없이 모든 리소스를 한 곳에서 종합적으로 볼 수 있습니다. 자세한 내용은 SIEM 시스템으로 Google Cloud 보안 데이터 내보내기 및 Cloud Logging 데이터 내보내기 시나리오: Splunk를 참조하세요.

데이터 분석을 사용하여 모니터링 강화

추가 분석을 위해 인벤토리를 BigQuery 테이블 또는 Cloud Storage 버킷으로 내보낼 수 있습니다.

다음 단계

다음 리소스를 사용하여 애셋 관리에 대해 자세히 알아보세요.

• ID 및 액세스 관리(이 시리즈의 다음 문서)
• 리소스 관리
• 시스템 설계

ID 및 액세스 관리

Google Cloud 아키텍처 프레임워크의 이 문서에서는 ID 및 액세스 관리를 위한 권장사항을 제공합니다.

ID 및 액세스 관리(일반적으로 IAM이라고도 함)를 사용하면 적절한 사람이 올바른 리소스에 액세스할 수 있습니다. IAM은 인증 및 승인의 다음과 같은 측면을 다룹니다.

• 프로비저닝을 포함한 계정 관리
• ID 거버넌스
• 인증
• 액세스 제어(승인)
• ID 제휴

서로 다른 환경이 있거나 여러 ID 공급업체를 사용하는 경우 IAM을 관리하기가 어려울 수 있습니다. 그러나 비즈니스 요구사항을 충족하면서 위험을 완화할 수 있는 시스템을 설정하는 것이 중요합니다.

이 문서의 권장사항은 현재 IAM 정책 및 절차를 검토하고 Google Cloud에서 워크로드에 수정해야 하는 항목을 결정하는 데 도움이 됩니다. 예를 들어 다음을 검토해야 합니다.

• 기존 그룹을 사용하여 액세스를 관리할 수 있는지 아니면 새 그룹을 만들어야 하는지 여부
• 인증 요구사항(예: 토큰을 사용하는 다단계 인증(MFA))
• 서비스 계정이 현재 정책에 미치는 영향
• 재해 복구를 위해 Google Cloud를 사용하는 경우 적절한 업무 분장 유지

Google Cloud에서 리소스 액세스를 지정하기 위해 Cloud ID를 사용하여 사용자 및 리소스와 Google의 Identity and Access Management(IAM) 제품을 인증합니다. 관리자는 조직, 폴더, 프로젝트, 리소스 수준에서 액세스를 제한할 수 있습니다. Google IAM 정책은 누가 어떤 리소스에서 어떤 작업을 수행할 수 있는지 지정합니다. IAM 정책을 올바르게 구성하면 리소스에 대한 무단 액세스를 방지하여 환경을 보호하는 데 도움이 됩니다.

자세한 내용은 ID 및 액세스 관리 개요를 참조하세요.

단일 ID 공급업체 사용

대부분의 고객에게는 Google Cloud 외부의 ID 공급업체에서 관리 및 프로비저닝되는 사용자 계정이 있습니다. Google Cloud는 대부분의 ID 공급업체 및 Active Directory와 같은 온프레미스 디렉터리가 있는 제휴를 지원합니다.

대부분의 ID 공급업체를 통해 사용자 및 그룹에 싱글 사인온(SSO)을 사용 설정할 수 있습니다. Google Cloud에 배포하고 외부 ID 공급업체를 사용하는 애플리케이션의 경우 ID 공급업체를 Google Cloud로 확장할 수 있습니다. 자세한 내용은 참조 아키텍처 및 하이브리드 환경에서 기업 사용자를 인증하는 패턴을 참조하세요.

기존 ID 공급업체가 없으면 Cloud ID Premium 또는 Google Workspace를 사용하여 직원 ID를 관리할 수 있습니다.

최고 관리자 계정 보호

최고 관리자 계정(Google Workspace 또는 Cloud ID에서 관리)을 사용하면 Google Cloud 조직을 만들 수 있습니다. 따라서 이 관리자 계정은 권한이 높습니다. 이 계정의 권장사항은 다음과 같습니다.

• 기존 사용자 계정을 사용하지 않고 이 용도를 위해 새 계정을 만듭니다.
• 백업 계정을 만들고 보호합니다.
• MFA를 사용 설정합니다.

자세한 내용은 최고 관리자 계정 권장사항을 참조하세요.

서비스 계정 사용 계획

서비스 계정은 애플리케이션이 서비스의 Google API를 호출하는 데 사용할 수 있는 Google 계정입니다.

사용자 계정과 달리 서비스 계정은 Google Cloud 내에서 생성 및 관리됩니다. 또한 서비스 계정은 사용자 계정과 다르게 인증합니다.

• Google Cloud에서 실행되는 애플리케이션이 서비스 계정을 사용하여 인증하도록 하려면 애플리케이션이 실행되는 컴퓨팅 리소스에 서비스 계정을 연결하면 됩니다.
• GKE에서 실행되는 애플리케이션이 서비스 계정을 사용하여 인증하도록 하려면 워크로드 아이덴티티를 사용하면 됩니다.
• Google Cloud 외부에서 실행되는 애플리케이션이 서비스 계정을 사용하여 인증하도록 하려면 워크로드 아이덴티티 제휴를 사용하면 됩니다.

서비스 계정을 사용하는 경우 설계 프로세스 중에 적절한 업무 분장을 고려해야 합니다. 수행해야 하는 API 호출을 확인하고 API 호출에 필요한 서비스 계정 및 관련 역할을 결정합니다. 예를 들어 BigQuery 데이터 웨어하우스를 설정하는 경우 최소한 다음 프로세스 및 서비스에 사용할 ID가 필요합니다.

• 일괄 파일을 제공하는지 또는 스트리밍 서비스를 만드는지에 따라 Cloud Storage 또는 Pub/Sub
• 민감한 정보를 익명화하기 위한 Dataflow와 Sensitive Data Protection

자세한 내용은 서비스 계정 작업 권장사항을 참조하세요.

클라우드의 ID 프로세스 업데이트

ID 거버넌스를 통해 액세스, 위험, 정책 위반을 추적하여 규제 요건을 지원할 수 있습니다. 이 거버넌스에 따라 사용자에게 액세스 제어 역할 및 권한을 부여하고 감사할 수 있도록 프로세스와 정책을 마련해야 합니다. 프로세스 및 정책은 테스트, 개발, 프로덕션과 같은 환경의 요구사항을 반영해야 합니다.

Google Cloud에 워크로드를 배포하기 전에 현재 ID 프로세스를 검토하고 필요한 경우 업데이트합니다. 조직에 필요한 계정 유형에 따라 적절하게 계획하고 역할 및 액세스 요구사항을 잘 이해해야 합니다.

Google Cloud는 Google IAM 활동을 감사하는 데 도움이 되도록 다음을 포함하는 감사 로그를 만듭니다.

• 관리자 활동. 이 로깅은 사용 중지할 수 없습니다.
• 데이터 액세스 활동. 이 로깅을 사용 설정해야 합니다.

규정 준수를 위해 필요한 경우 또는 SIEM 시스템과 같은 로그 분석을 설정하려면 로그를 내보낼 수 있습니다. 로그는 스토리지 요구사항을 늘릴 수 있으므로 비용에 영향을 미칠 수 있습니다. 필요한 작업만 로깅하고 적절한 보관 일정을 설정해야 합니다.

SSO 및 MFA 설정

ID 공급업체가 사용자 계정 인증을 관리합니다. 제휴 ID는 SSO를 사용하여 Google Cloud에 인증할 수 있습니다. 최고 관리자와 같은 권한이 부여된 계정의 경우 MFA를 구성해야 합니다. Titan 보안 키는 피싱 공격을 방지하기 위해 2단계 인증(2FA)에 사용할 수 있는 물리적 토큰입니다.

Cloud ID는 다양한 방법을 통해 MFA를 지원합니다. 자세한 내용은 회사 소유의 리소스에 균일한 MFA 적용을 참조하세요.

Google Cloud는 OAuth 2.0 프로토콜 또는 서명된 JSON 웹 토큰(JWT)을 사용하는 워크로드 아이덴티티 인증을 지원합니다. 워크로드 인증에 대한 자세한 내용은 인증 개요를 참조하세요.

최소 권한 및 업무 분장 구현

적절한 권한이 있는 개인이 작업을 수행하는 데 필요한 리소스와 서비스에만 액세스할 수 있도록 해야 합니다. 즉, 최소 권한의 원칙을 따라야 합니다. 또한 적절한 업무 분장이 있는지 확인해야 합니다.

사용자 액세스를 과도하게 프로비저닝하면 내부자 위협, 잘못된 리소스 구성, 감사 미준수 위험이 증가할 수 있습니다. 권한에 대한 프로비저닝이 부족하면 사용자가 작업을 완료하는 데 필요한 리소스에 액세스하지 못할 수 있습니다.

초과 프로비저닝을 방지하기 위한 한 가지 방법은 적시 권한 있는 액세스를 구현하는 것입니다. 즉, 필요한 만큼만 권한 있는 액세스를 제공하고 이러한 권한을 일시적으로만 부여합니다.

Google Cloud 조직을 만들 때 도메인의 모든 사용자에게는 기본적으로 결제 계정 생성자 역할과 프로젝트 생성자 역할이 부여됩니다. 이러한 작업을 수행할 사용자를 식별하고 다른 사용자에게서 해당 역할을 취소합니다. 자세한 내용은 조직 만들기 및 관리를 참조하세요.

Google Cloud에서 역할 및 권한이 작동하는 방법에 대한 자세한 내용은 IAM 문서의 개요 및 역할 이해를 참조하세요. 최소 권한 적용에 대한 자세한 내용은 역할 권장사항으로 최소 권한 적용을 참조하세요.

감사 액세스

권한이 부여된 계정의 활동을 모니터링하여 승인된 조건과의 차이를 확인하려면 Cloud 감사 로그를 사용합니다. Cloud 감사 로그는 Google Cloud 조직의 구성원이 Google Cloud 리소스에서 수행한 작업을 기록합니다. Google 서비스에서 다양한 감사 로그 유형으로 작업할 수 있습니다. 자세한 내용은 Cloud 감사 로그를 사용하여 내부자 위험 관리(동영상)를 참조하세요.

IAM 추천자를 사용하여 사용량을 추적하고 필요한 경우 권한을 조정합니다. IAM 추천자가 권장하는 역할을 통해 사용자의 이전 행동 및 기타 기준에 따라 사용자에게 부여할 역할을 결정할 수 있습니다. 자세한 내용은 역할 권장사항을 참조하세요.

Google 지원 및 엔지니어링 담당자가 리소스에 대한 액세스를 감사하고 제어하려면 액세스 투명성을 사용하면 됩니다. 액세스 투명성은 Google 직원이 수행한 작업을 기록합니다. 액세스 투명성에 포함된 액세스 승인을 사용하여 고객 콘텐츠에 액세스할 때마다 명시적인 승인을 부여합니다. 자세한 내용은 데이터에 대한 클라우드 관리자의 액세스 권한 제어를 참조하세요.

정책 제어 자동화

가능하면 프로그래매틱 방식으로 액세스 권한을 설정합니다. 권장사항은 조직 정책 제약조건을 참조하세요. 엔터프라이즈 기반 청사진의 Terraform 스크립트는 예시 기반 저장소에 있습니다.

Google Cloud에는 액세스 권한을 자동으로 검토하고 업데이트할 수 있는 Policy Intelligence가 포함되어 있습니다. Policy Intelligence에는 추천자, 정책 문제 해결 도구, 정책 분석 도구가 포함되어 있으며 이러한 도구는 다음을 수행합니다.

• IAM 역할 할당에 대한 권장사항을 제공합니다.
• 과도한 권한이 부여된 IAM 정책을 모니터링하고 방지합니다.
• 액세스 제어 관련 문제 해결을 지원합니다.

리소스 제한 설정

Google IAM은 누구에 중점을 두며 이를 통해 권한을 기반으로 특정 리소스에 조치를 취할 수 있는 사용자를 승인할 수 있습니다. 조직 정책 서비스는 무엇에 중점을 두며 이를 통해 구성 방법을 지정하는 리소스에 제한을 설정할 수 있습니다. 예를 들어 조직 정책을 사용하여 다음을 수행할 수 있습니다.

• 도메인을 기반으로 리소스 공유를 제한합니다.
• 서비스 계정 사용을 제한합니다.
• 새로 만든 리소스의 물리적 위치를 제한합니다.

이러한 작업에 조직 정책을 사용하는 것 외에도 다음 방법 중 하나를 사용하여 리소스에 대한 액세스를 제한할 수 있습니다.

• 태그를 사용하여 각 리소스에 대한 액세스 권한을 정의하지 않고 리소스에 대한 액세스를 관리합니다. 대신 태그를 추가한 다음 태그 자체에 대한 액세스 정의를 설정합니다.
• IAM 조건을 사용하여 리소스에 대한 조건부 속성 기반 액세스를 제어합니다.
• VPC 서비스 제어를 사용해 심층 방어를 구현하여 리소스에 대한 액세스를 추가로 제한합니다.

리소스 관리에 대한 자세한 내용은 리소스 관리를 참조하세요.

다음 단계

다음 리소스를 통해 IAM에 대해 자세히 알아보세요.

• 컴퓨팅 및 컨테이너 보안 구현(이 시리즈의 다음 문서)

• 안전하게 IAM 사용

• 참조 아키텍처

• IAM 추천자: 적은 노력으로 최소 권한 달성

• 클라우드 데이터 개인 정보 보호

• ID 및 액세스 관리 개요

컴퓨팅 및 컨테이너 보안 구현

Google Cloud에는 컴퓨팅 리소스와 Google Kubernetes Engine(GKE) 컨테이너 리소스를 보호하기 위한 제어 기능이 포함되어 있습니다. Google Cloud 아키텍처 프레임워크의 이 문서에서는 이를 사용하기 위한 주요 제어 기능과 권장사항을 설명합니다.

강화 및 선별된 VM 이미지 사용

Google Cloud에는 VM 인스턴스를 강화하는 보안 VM이 포함되어 있습니다. 보안 VM은 부팅 주기가 진행되는 동안 악성 코드가 로드되지 않도록 설계되었습니다. 부팅 보안을 제공하고 무결성을 모니터링하고 Virtual Trusted Platform Module(vTPM)을 사용합니다. 민감한 워크로드에 보안 VM을 사용합니다.

보안 VM 외에도 Google Cloud 파트너 솔루션을 사용하여 VM을 추가로 보호할 수 있습니다. Google Cloud에서 제공하는 많은 파트너 솔루션은 이벤트 위협 감지 및 상태 모니터링을 제공하는 Security Command Center와 통합됩니다. 고급 위협 분석 또는 런타임 추가 보안을 위해 파트너를 이용할 수 있습니다.

민감한 정보 처리에 컨피덴셜 컴퓨팅 사용

기본적으로 Google Cloud는 네트워크 전체에서 저장 데이터와 전송 중인 데이터를 암호화하지만 메모리에서 사용되는 데이터는 암호화되지 않습니다. 조직에서 기밀 데이터를 처리하는 경우 애플리케이션 또는 시스템 메모리에 있는 데이터의 기밀성 및 무결성을 약화시키는 위협을 완화해야 합니다. 기밀 데이터에는 개인 식별 정보(PII), 금융 데이터, 건강 정보가 포함됩니다.

컨피덴셜 컴퓨팅은 보안 VM을 기반으로 합니다. 하드웨어 기반의 신뢰할 수 있는 실행 환경에서 계산을 수행하여 사용 중 데이터를 보호합니다. 이러한 유형의 안전하고 격리된 환경은 데이터가 사용되는 동안 애플리케이션과 데이터의 무단 액세스 또는 수정을 방지하는 데 도움이 됩니다. 또한 신뢰할 수 있는 실행 환경은 규제 대상인 민감한 정보를 관리하는 조직의 보안을 보장합니다.

Google Cloud에서는 컨피덴셜 VM 또는 Confidential GKE Node를 실행하여 컨피덴셜 컴퓨팅을 사용 설정할 수 있습니다. 컨피덴셜 워크로드를 처리하거나 처리하는 동안 노출해야 하는 기밀 데이터(예: 보안 비밀)가 있는 경우 컨피덴셜 컴퓨팅을 사용 설정합니다. 자세한 내용은 컨피덴셜 컴퓨팅 컨소시엄을 참조하세요.

VM 및 컨테이너 보호

OS 로그인을 사용하면 직원이 정보의 출처로 SSH를 활용하는 대신 Identity and Access Management(IAM) 권한을 사용하여 VM에 연결할 수 있습니다. 따라서 조직에서 SSH 키를 관리할 필요가 없습니다. OS 로그인은 관리자의 액세스 권한을 직원 수명 주기에 연결합니다. 즉, 직원이 다른 역할로 이동하거나 조직을 떠나면 해당 사용자의 액세스 권한이 취소됩니다. OS 로그인은 2단계 인증도 지원하므로 계정 탈취 공격에 대한 보안이 한층 강화됩니다.

GKE에서 App Engine은 Docker 컨테이너 내에서 애플리케이션 인스턴스를 실행합니다. 정의된 위험 프로필을 사용 설정하고 직원이 컨테이너를 변경하지 못하도록 하려면 컨테이너가 스테이트리스(Stateless)이자 변경 불가능이어야 합니다. 불변성의 원칙은 직원이 컨테이너를 수정하거나 대화식으로 액세스하지 않는다는 것을 의미합니다. 이미지를 변경해야 하는 경우 새 이미지를 빌드하고 다시 배포합니다. 특정 디버깅 시나리오에서만 기본 컨테이너에 대한 SSH 액세스를 사용 설정합니다.

필요한 경우가 아니면 외부 IP 주소 사용 중지

프로덕션 VM의 외부 IP 주소 할당을 사용 중지(동영상)하고 외부 부하 분산기의 사용을 방지하려면 조직 정책을 사용하면 됩니다. VM을 인터넷이나 온프레미스 데이터 센터에 연결해야 하는 경우 Cloud NAT 게이트웨이를 사용 설정하면 됩니다.

GKE에 비공개 클러스터를 배포할 수 있습니다. 비공개 클러스터의 노드에는 내부 IP 주소만 있습니다. 즉, 노드와 포드는 기본적으로 인터넷에서 격리되어 있습니다. 또한 네트워크 정책을 정의하여 클러스터에서 포드 간 통신을 관리할 수도 있습니다. 자세한 내용은 서비스 비공개 액세스 옵션을 참조하세요.

컴퓨팅 인스턴스 및 GKE 사용량 모니터링

Cloud 감사 로그는 Compute Engine 및 GKE에서 자동으로 사용 설정됩니다. 감사 로그를 사용하면 클러스터와 관련된 모든 활동을 자동으로 캡처하고 의심스러운 활동을 모니터링할 수 있습니다.

런타임 보안을 위해 GKE를 파트너 제품과 통합할 수 있습니다. 이러한 솔루션을 Security Command Center와 통합하여 애플리케이션 모니터링을 위한 단일 인터페이스를 제공할 수 있습니다.

이미지 및 클러스터를 최신 상태로 유지

Google Cloud는 정기적으로 패치되는 선별된 OS 이미지를 제공합니다. 커스텀 이미지를 가져와 Compute Engine에서 실행할 수 있지만 이 경우에는 직접 패치해야 합니다. Google Cloud는 보안 게시판에 설명된 대로 새로운 취약점을 완화하기 위해 OS 이미지를 정기적으로 업데이트하고, 기존 배포의 취약점을 해결하기 위한 조치를 제공합니다.

GKE를 사용하는 경우 Google에서 최신 패치로 클러스터 노드를 업데이트하도록 노드 자동 업그레이드를 사용 설정하는 것이 좋습니다. Google은 자동으로 업데이트되고 패치되는 GKE 제어 영역을 관리합니다. 또한 배포에 Google에서 선별한 컨테이너 최적화 이미지를 사용합니다. Google은 이러한 이미지를 정기적으로 패치하고 업데이트합니다.

이미지 및 클러스터에 대한 액세스 제어

인스턴스를 만들고 실행할 수 있는 사용자를 이해하는 것이 중요합니다. IAM을 사용하여 이 액세스를 제어할 수 있습니다. 필요한 액세스 워크로드 결정 방법에 대한 자세한 내용은 워크로드 아이덴티티 계획을 참조하세요.

또한 VPC 서비스 제어를 사용하여 프로젝트에서 커스텀 할당량을 정의하면 이미지를 실행할 수 있는 사용자를 제한할 수 있습니다. 자세한 내용은 네트워크 보호 섹션을 참조하세요.

클러스터에 인프라 보안을 제공하기 위해 GKE를 사용하면 IAM을 역할 기반 액세스 제어 (RBAC)와 함께 사용하여 클러스터 및 네임스페이스에 대한 액세스를 관리할 수 있습니다.

샌드박스에서 컨테이너 격리

GKE Sandbox를 사용하여 호스트 커널로부터 격리와 추가 보안 레이어가 필요한 멀티 테넌트 애플리케이션을 배포합니다. 예를 들어 알 수 없거나 신뢰할 수 없는 코드를 실행하는 경우 GKE Sandbox를 사용합니다. GKE Sandbox는 GKE에서 컨테이너화된 워크로드 간의 2차 방어 레이어를 제공하는 컨테이너 격리 솔루션입니다.

GKE Sandbox는 I/O 요구사항이 적지만 확장성은 우수한 애플리케이션용으로 빌드되었습니다. 컨테이너화된 워크로드의 경우 속도와 성능을 유지해야 하지만 신뢰할 수 없는 코드가 포함될 수도 있어 추가적인 보안이 필요합니다. 컨테이너 런타임 샌드박스인 gVisor는 애플리케이션과 호스트 커널 간의 추가 보안 격리를 제공합니다. gVisor는 추가 무결성 검사를 제공하고 서비스에 대한 액세스 범위를 제한합니다. 외부 위협으로부터 보호하기 위한 컨테이너 강화 서비스는 아닙니다. gVisor에 대한 자세한 내용은 gVisor: 실제 환경에서 GKE 및 서버리스 사용자 보호를 참조하세요.

다음 단계

다음 리소스를 통해 컴퓨팅 및 컨테이너 보안에 대해 자세히 알아보세요.

• 네트워크 보호(이 시리즈의 다음 문서)
• 컨테이너 보안이 중요한 이유(PDF)
• Google Cloud 출시 체크리스트
• 인스턴스 ID 확인
• 워크로드 아이덴티티
• 보안 VM
• 영구 디스크 스냅샷 권장사항
• 이미지 관리 권장사항

네트워크 보호

Google Cloud 아키텍처 프레임워크의 이 문서에서는 네트워크 보안을 위한 권장사항을 제공합니다.

클라우드 환경을 포함하도록 기존 네트워크를 확장하면 보안에 많은 영향을 미칩니다. 멀티 레이어 방어에 대한 온프레미스 접근 방식은 인터넷과 내부 네트워크 간에 별개의 경계를 포함할 수 있습니다. 물리적 방화벽, 라우터, 침입 감지 시스템 등을 사용하여 경계를 보호할 수 있습니다. 경계가 명확하게 정의되었으므로 침입을 쉽게 모니터링하고 적절히 대응할 수 있습니다.

(완전히 또는 하이브리드 방식으로) 클라우드로 이전하면 온프레미스 경계 외부로 이동합니다. 이 문서에서는 Google Cloud에서 조직의 데이터와 워크로드를 계속 보호하는 방법을 설명합니다. 제어를 통한 위험 관리에서 언급했듯이 Google Cloud 네트워크를 설정하고 보호하는 방법은 비즈니스 요구사항 및 위험 요구사항에 따라 달라집니다.

이 섹션에서는 시스템 설계 카테고리의 네트워킹 섹션을 읽었고 Google Cloud 네트워크 구성요소의 기본 아키텍처 다이어그램을 이미 생성한 것으로 가정합니다. 예시 다이어그램은 허브 및 스포크를 참조하세요.

제로 트러스트 네트워크 배포

클라우드로 이전하면 네트워크 신뢰 모델을 변경해야 합니다. 사용자와 워크로드가 더 이상 온프레미스 경계 뒤에 있지 않으므로 신뢰할 수 있는 내부 네트워크를 만드는 것과 동일한 방식으로 경계 보호를 사용할 수 없습니다. 제로 트러스트 보안 모델은 기본적으로 조직 네트워크 내부 또는 외부에 관계없이 어떤 것도 신뢰되지 않음을 의미합니다. 액세스 요청을 확인할 때 제로 트러스트 보안 모델을 사용하는 경우 사용자 ID와 컨텍스트를 모두 확인해야 합니다. VPN과 달리 액세스 제어는 네트워크 경계에서 사용자 및 기기로 이전합니다.

Google Cloud에서는 BeyondCorp Enterprise를 제로 트러스트 솔루션으로 사용할 수 있습니다. BeyondCorp Enterprise는 위협 및 데이터 보호와 추가 액세스 제어 수단을 제공합니다. 설정 방법에 대한 자세한 내용은 BeyondCorp Enterprise 시작하기를 참조하세요.

Google Cloud는 BeyondCorp Enterprise 외에도 IAP(Identity-Aware Proxy)를 포함합니다. IAP를 사용하면 제로 트러스트 보안을 Google Cloud 및 온프레미스 내의 애플리케이션으로 확장할 수 있습니다. IAP는 액세스 제어 정책을 사용하여 애플리케이션 및 리소스에 액세스하는 사용자에게 인증 및 승인을 제공합니다.

온프레미스 또는 멀티 클라우드 환경에 대해 보안 연결을 구성합니다.

많은 조직이 클라우드 환경과 온프레미스 모두에서 워크로드를 사용합니다. 또한 복원력을 위해 일부 조직은 멀티 클라우드 솔루션을 사용합니다. 이러한 시나리오에서는 모든 환경 간의 연결을 보호하는 것이 중요합니다.

Google Cloud에는 다음을 비롯해 Cloud VPN 또는 Cloud Interconnect에서 지원되는 VM용 비공개 액세스 방법이 포함됩니다.

• 고속의 직접 연결을 사용하여 VPC 네트워크를 지원되는 다른 클라우드 제공업체에 연결하려면 Cross-Cloud Interconnect를 사용합니다. Cross-Cloud Interconnect를 사용하면 자체 라우터를 제공하거나 타사 공급업체와 협력하지 않아도 됩니다.
• Dedicated Interconnect 및 Partner Interconnect를 사용하면 VPC 네트워크를 고속 직접 연결을 통해 온프레미스 데이터 센터 또는 다른 클라우드 제공업체에 연결할 수 있습니다.
• IPSec VPN을 사용하여 Virtual Private Cloud(VPC) 네트워크를 온프레미스 데이터 센터 또는 다른 클라우드 제공업체에 연결합니다.
• Private Service Connect 엔드포인트를 사용하여 조직 또는 다른 제공업체에서 제공하는 게시된 서비스에 액세스합니다.
• 내부 IP 주소를 사용하여 VM이 Google API에 액세스할 수 있도록 Private Service Connect 엔드포인트를 사용합니다. Private Service Connect를 사용하면 VM에 외부 IP 주소가 없어도 Google 서비스에 액세스할 수 있습니다.
• GKE Enterprise를 사용하는 경우 Anthos Service Mesh 이그레스 게이트웨이를 사용하는 것이 좋습니다. GKE Enterprise를 사용하지 않는 경우 서드 파티 옵션을 사용합니다.

제품 간 비교는 네트워크 연결 제품 선택을 참조하세요.

기본 네트워크 사용 중지

새 Google Cloud 프로젝트를 만들 때 자동 모드 IP 주소와 기본 Google Cloud VPC 네트워크 및 자동 입력된 방화벽 규칙이 자동으로 프로비저닝됩니다. 프로덕션 배포의 경우 기존 프로젝트에서 기본 네트워크를 삭제하고 새 프로젝트에서 기본 네트워크 생성을 중지하는 것이 좋습니다.

Virtual Private Cloud 네트워크를 사용하면 모든 내부 IP 주소를 사용할 수 있습니다. IP 주소 충돌을 방지하려면 먼저 연결된 배포 및 프로젝트 간에 네트워크 및 IP 주소 할당을 계획하는 것이 좋습니다. 프로젝트는 여러 VPC 네트워크를 허용하지만 일반적으로 액세스 제어를 효과적으로 적용하려면 프로젝트당 네트워크를 하나로 제한하는 것이 가장 좋습니다.

경계 보호

Google Cloud에서는 방화벽 및 VPC 서비스 제어를 비롯한 다양한 방법을 사용하여 클라우드 경계를 분할하고 보호할 수 있습니다.

공유 VPC를 사용하면 단일 공유 네트워크를 제공하고 여러 팀에서 관리할 수 있는 개별 프로젝트로 워크로드를 격리하는 프로덕션 배포를 구축할 수 있습니다. 공유 VPC는 여러 프로젝트의 네트워크 및 네트워크 보안 리소스를 중앙 집중식으로 배포, 관리, 제어합니다. 공유 VPC는 다음 기능을 수행하는 호스트 및 서비스 프로젝트로 구성됩니다.

• 호스트 프로젝트에는 VPC 네트워크, 서브넷, 방화벽 규칙, 하이브리드 연결과 같은 네트워킹 및 네트워크 보안 관련 리소스가 포함되어 있습니다.
• 서비스 프로젝트는 호스트 프로젝트에 연결됩니다. 이를 통해 Identity and Access Management(IAM)를 사용하여 프로젝트 수준에서 워크로드와 사용자를 격리하고 중앙에서 관리되는 호스트 프로젝트에서 네트워킹 리소스를 공유할 수 있습니다.

조직, 폴더, VPC 네트워크 수준에서 방화벽 정책 및 규칙을 정의합니다. VM 인스턴스를 오가는 트래픽을 허용하거나 거부하도록 방화벽 규칙을 구성할 수 있습니다. 예를 들어 전역 및 리전 네트워크 방화벽 정책 예시 및 계층적 방화벽 정책 예시를 참조하세요. IP 주소, 프로토콜, 포트를 기반으로 규칙을 정의하는 것 외에도 VM 인스턴스에서 사용되거나 보안 태그를 사용할 때 사용되는 서비스 계정에 따라 트래픽을 관리하고 방화벽 규칙을 적용할 수 있습니다.

Google 서비스에서 데이터 이동을 제어하고 컨텍스트 기반 경계 보안을 설정하려면 VPC 서비스 제어를 고려하세요. VPC 서비스 제어는 IAM 및 방화벽 규칙과 정책과 별개로 Google Cloud 서비스의 보안을 강화합니다. 예를 들어 VPC 서비스 제어를 사용하면 기밀 데이터와 비기밀 데이터 간의 경계를 설정하여 데이터 무단 반출을 방지하는 제어를 적용할 수 있습니다.

Google Cloud Armor 보안 정책을 사용하면 들어오는 트래픽의 소스와 최대한 가까운 Google Cloud 에지에서 외부 애플리케이션 부하 분산기에 대한 요청을 허용, 거부 또는 리디렉션할 수 있습니다. 이러한 정책은 원치 않는 트래픽이 리소스를 소비하거나 네트워크에 유입되는 것을 방지할 수 있습니다.

보안 웹 프록시를 사용하여 이그레스 웹 트래픽에 세분화된 액세스 정책을 적용하고 신뢰할 수 없는 웹 서비스에 대한 액세스를 모니터링합니다.

네트워크 트래픽 검사

Cloud IDS 및 패킷 미러링을 사용하여 Compute Engine 및 Google Kubernetes Engine(GKE)에서 실행되는 워크로드의 보안 및 규정 준수를 보장할 수 있습니다.

Cloud Intrusion Detection System(현재 미리보기 버전)을 사용하여 VPC 네트워크로 들어오고 나가는 트래픽을 파악할 수 있습니다. Cloud IDS는 미러링된 VM이 있는 Google 관리 피어링된 네트워크를 만듭니다. Palo Alto Networks 위협 보호 기술은 트래픽을 미러링하고 검사합니다. 자세한 내용은 Cloud IDS 개요를 참조하세요.

패킷 미러링은 VPC 네트워크에서 지정된 VM 인스턴스의 트래픽을 클론하여 수집, 보관, 검사를 위해 전달합니다. 패킷 미러링을 구성한 후에는 Cloud IDS 또는 타사 도구를 사용하여 규모에 맞게 네트워크 트래픽을 수집하고 검사할 수 있습니다. 이러한 방식으로 네트워크 트래픽을 검사하면 침입 감지 및 애플리케이션 성능 모니터링을 제공하는 데 도움이 됩니다.

웹 애플리케이션 방화벽 사용

외부 웹 애플리케이션 및 서비스의 경우 Google Cloud Armor를 사용 설정하여 DDoS 보호 및 웹 애플리케이션 방화벽(WAF) 기능을 제공할 수 있습니다. Google Cloud Armor는 외부 HTTP(S) 부하 분산, TCP 프록시 부하 분산 또는 SSL 프록시 부하 분산을 사용하여 노출되는 Google Cloud 워크로드를 지원합니다.

Google Cloud Armor는 표준과 Managed Protection 플러스라는 두 가지 서비스 등급으로 제공됩니다. 고급 Google Cloud Armor 기능을 최대한 활용하려면 주요 워크로드에 Managed Protection 플러스에 투자해야 합니다.

인프라 프로비저닝 자동화

자동화를 사용하면 변경 불가능한 인프라를 만들 수 있으며, 이러한 인프라는 프로비저닝 후에 변경할 수 없습니다. 이러한 특성은 운영팀에 알려진 정상 상태, 빠른 롤백, 문제 해결 기능을 제공합니다. 자동화를 위해 Terraform, Jenkins, Cloud Build와 같은 도구를 사용할 수 있습니다.

자동화를 사용하는 환경을 구축할 수 있도록 Google Cloud는 엔터프라이즈 기반 청사진을 기반으로 하는 보안 청사진 시리즈를 제공합니다. 보안 기반 청사진은 안전한 애플리케이션 환경을 위한 Google의 독자적인 설계를 제공하고, Google Cloud 자산 구성 및 배포 방법을 단계별로 설명합니다. 보안 기반 청사진에 포함된 안내 및 스크립트를 사용하면 보안 권장사항 및 가이드라인을 충족하는 환경을 구성할 수 있습니다. 추가 청사진을 사용하여 청사진을 구축하거나 자체 자동화를 설계할 수 있습니다.

자동화에 대한 자세한 내용은 데이터 처리 워크플로에 CI/CD 파이프라인 사용을 참조하세요.

네트워크 모니터링

원격 분석을 사용하여 네트워크와 트래픽을 모니터링합니다.

VPC 흐름 로그 및 방화벽 규칙 로깅은 Google Cloud 환경의 트래픽 및 방화벽 사용량을 실시간에 가깝게 파악할 수 있도록 합니다. 예를 들어 방화벽 규칙 로깅은 Compute Engine VM 인스턴스와 주고받는 트래픽을 로깅합니다. 이러한 도구를 Cloud Logging 및 Cloud Monitoring과 함께 사용하면 트래픽을 추적, 알림, 시각화하고 패턴에 액세스하여 배포 운영 보안을 개선할 수 있습니다.

방화벽 통계를 사용하면 수신 및 발신 연결과 일치하는 방화벽 규칙을 검토하고 연결이 허용 또는 거부되었는지 여부를 확인할 수 있습니다. 섀도 처리된 규칙 기능은 다른 규칙이 항상 먼저 트리거되어 트리거되지 않는 규칙을 표시하여 방화벽 구성을 조정하는 데 도움을 줍니다.

Network Intelligence Center를 사용하여 네트워크 토폴로지와 아키텍처의 성능을 확인하세요. 또한 네트워크 성능에 대한 자세한 정보를 확인하고 배포를 최적화하여 서비스에서 병목 현상을 제거할 수 있습니다. 연결 테스트는 네트워크 경로에 적용되는 방화벽 규칙 및 정책에 대한 유용한 정보를 제공합니다.

모니터링에 대한 자세한 내용은 로깅 및 감지 제어 구현을 참조하세요.

다음 단계

다음 리소스를 통해 네트워크 보안에 대해 자세히 알아보세요.

• 데이터 보안 구현(이 시리즈의 다음 문서)
• VPC 설계에 관한 권장사항 및 참조 아키텍처
• VPC 서비스 제어를 관리하는 IAM 역할
• Security Command Center 파트너로 온보딩
• Security Command Center에서 취약점 및 위협 보기
• 패킷 미러링: 클라우드 네트워크의 시각화 및 보호
• 침입 감지에 패킷 미러링 사용
• 파트너 IDS 솔루션으로 패킷 미러링 사용

데이터 보안 구현

Google Cloud 아키텍처 프레임워크의 이 문서에서는 데이터 보안을 구현하기 위한 권장사항을 제공합니다.

배포 아키텍처의 일부로 Google Cloud에서 처리하고 저장할 데이터 및 데이터의 민감도를 고려해야 합니다. 수명 주기 동안 데이터를 보호하고, 데이터 소유권 및 분류를 식별하고, 승인되지 않은 사용으로부터 데이터를 보호할 수 있도록 제어를 설계합니다.

이 문서에 설명된 보안 권장사항에 따라 BigQuery 데이터 웨어하우스를 배포하는 보안 청사진은 기밀 데이터를 저장하는 BigQuery 데이터 웨어하우스 보안을 참조하세요.

자동으로 데이터 분류

데이터 관리 수명 주기 초기(이상적으로 데이터 생성 시)에 데이터 분류를 수행하는 것이 좋습니다. 일반적으로 데이터 분류 작업에는 다음과 같은 몇 가지 카테고리만 필요합니다.

• 공개: 공개 액세스가 승인된 데이터
• 내부: 일반에 공개되지 않은 민감하지 않은 데이터
• 기밀: 일반적인 내부 배포에 사용할 수 있는 민감한 데이터
• 제한: 제한된 배포가 필요한 매우 민감하거나 규제되는 데이터

민감한 정보 보호를 사용하여 Google Cloud 환경에서 데이터를 검색하고 분류할 수 있습니다. 민감한 정보 보호는 Cloud Storage, BigQuery, Datastore에서 민감한 정보를 스캔하고 분류하는 기능을 기본적으로 제공합니다. 추가 데이터 소스와 커스텀 워크로드를 지원하는 스트리밍 API도 있습니다.

민감한 정보 보호는 기본 제공 infoType을 사용하여 민감한 정보를 식별할 수 있으며, 민감한 요소(예: PII 데이터)를 자동으로 분류, 마스킹, 토큰화, 변환하여 데이터 수집, 저장, 사용의 위험을 관리할 수 있습니다. 즉, 데이터 수명 주기 프로세스와 통합하여 모든 단계의 데이터를 보호할 수 있습니다.

자세한 내용은 민감한 정보 보호를 사용하여 대규모 데이터 세트에서 PII 익명화 및 재식별을 참조하세요.

메타데이터를 사용하여 데이터 거버넌스 관리

데이터 거버넌스는 데이터의 보안, 개인정보 보호, 정확성, 가용성, 사용성을 보장하는 프로세스의 조합입니다. 조직의 데이터 거버넌스 전략을 정의할 책임은 개발자에게 있지만 Google Cloud는 이러한 전략을 구현하는 데 도움이 되는 도구와 기술을 제공합니다. 또한 Google Cloud는 클라우드에서 데이터 거버넌스용 프레임워크(PDF)를 제공합니다.

Data Catalog를 통해 메타데이터를 찾고 선별하고 사용하여 클라우드의 데이터 애셋을 설명합니다. Data Catalog를 사용하여 데이터 애셋을 검색한 후 메타데이터로 애셋에 태그를 지정할 수 있습니다. 데이터 분류 작업을 가속화하기 위해 Data Catalog를 민감한 정보 보호와 통합하여 기밀 데이터를 자동으로 식별할 수 있습니다. 데이터에 태그를 지정한 후에는 Google Identity and Access Management(IAM)를 사용하여 Data Catalog 뷰를 통해 쿼리하거나 사용할 수 있는 데이터를 제한할 수 있습니다.

Dataproc Metastore 또는 Hive Metastore를 사용하여 워크로드의 메타데이터를 관리합니다. Data Catalog에는 서비스가 Hive Metastore에 있는 메타데이터를 검색할 수 있도록 하는 Hive 커넥터가 있습니다.

Dataprep by Trifacta를 사용하여 콘솔을 통해 데이터 품질 규칙을 정의하고 적용합니다. Cloud Data Fusion 내에서 Dataprep을 사용하거나 Dataprep을 독립형 서비스로 사용할 수 있습니다.

수명 주기 단계 및 분류에 따라 데이터 보호

수명 주기의 맥락에서 데이터를 정의하고 민감도와 위험에 따라 데이터를 분류한 후에는 적절한 보안 제어를 할당하여 보호할 수 있습니다. 제어가 적절한 보호를 제공하고, 규정 준수 요구사항을 충족하며, 위험을 줄일 수 있는지 확인해야 합니다. 클라우드로 이전할 때 현재 전략과 현재 프로세스를 변경해야 하는 위치를 검토하세요.

다음 표에서는 클라우드 데이터 보안 전략의 세 가지 특성을 설명합니다.

특성	설명
식별	데이터를 생성, 수정, 저장, 사용, 공유, 삭제할 때 사용자, 리소스, 애플리케이션의 ID를 이해합니다. Cloud ID 및 IAM을 사용하여 데이터에 대한 액세스를 제어합니다. ID에 인증서가 필요한 경우 Certificate Authority Service를 사용하는 것이 좋습니다. 자세한 내용은 ID 및 액세스 관리를 참조하세요.
경계 및 액세스	데이터 액세스 방법, 액세스하는 사용자, 상황에 따라 제어를 설정합니다. 데이터에 대한 액세스 경계를 다음 수준에서 관리할 수 있습니다. Cloud 방화벽과 같은 제어를 사용하는 네트워크 레이어 액세스. 네트워크 레이어에 대한 자세한 내용은 Network Intelligence Center를 참조하세요. VPC 서비스 제어를 사용하여 지정한 서비스의 리소스와 데이터를 보호하는 경계를 만듭니다. IAM을 사용하는 IAM 액세스 제어. IAM 역할 관리에 대한 자세한 내용은 액세스 제어에 리소스 계층 구조 사용을 참조하세요.
공개 상태	사용량을 감사하고 데이터를 제어하고 액세스하는 방법을 보여주는 보고서를 만들 수 있습니다. Google Cloud Logging 및 액세스 투명성은 자체 클라우드 관리자 및 Google 직원의 활동에 대한 유용한 정보를 제공합니다. 자세한 내용은 데이터 모니터링을 참조하세요.

데이터 암호화

기본적으로 Google Cloud는 사용자가 아무런 조치를 취하지 않아도 저장된 고객 데이터를 암호화합니다. Google Cloud는 기본 암호화 외에도 봉투 암호화 및 암호화 키 관리를 위한 옵션을 제공합니다. 예를 들어 Compute Engine 영구 디스크는 자동으로 암호화되지만 자체 키를 제공하거나 관리할 수 있습니다.

스토리지, 컴퓨팅 또는 빅데이터 워크로드 등 어떤 용도의 키를 선택하든 키 생성, 보관, 순환을 위한 요구사항에 가장 적합한 솔루션을 찾아야 합니다.

Google Cloud에는 다음과 같은 암호화 및 키 관리 옵션이 포함되어 있습니다.

• 고객 관리 암호화 키(CMEK). Cloud Key Management Service(Cloud KMS)를 사용하여 암호화 키를 생성하고 관리할 수 있습니다. 암호화 키를 정기적으로 순환해야 하는 경우와 같은 특정 키 관리 요구사항이 있는 경우 이 옵션을 사용합니다.
• 고객 제공 암호화 키(CSEK) 자체 암호화 키를 만들고 관리한 다음 필요한 경우 Google Cloud에 제공할 수 있습니다. 온프레미스 키 관리 시스템에서 자체 키를 생성하여 자체 키를 조달하는 경우(BYOK) 이 옵션을 사용합니다. CSEK를 사용하여 자체 키를 제공하는 경우 Google에서 키를 복제하여 워크로드에 제공합니다. 그러나 고객 제공 키는 인스턴스 템플릿 또는 Google 인프라에 저장되지 않으므로 CSEK의 보안 및 가용성에 대한 책임은 사용자에게 있습니다. 키에 대한 액세스가 손실되면 Google에서는 암호화된 데이터를 복구할 수 없습니다. 직접 만들고 관리할 키를 신중하게 고려하세요. 가장 민감한 정보에만 CSEK를 사용하는 것이 좋습니다. 또 다른 옵션은 데이터에 클라이언트 측 암호화를 수행한 후 암호화된 데이터를 Google Cloud에 저장하는 것이며, 여기서 데이터는 Google이 다시 암호화합니다.
• Cloud 외부 키 관리자(Cloud EKM)를 사용하는 타사 키 관리 시스템. Cloud EKM은 Google 인프라 외부에서 제어하는 서드 파티 키 관리 시스템에서 저장 및 관리되는 암호화 키를 사용하여 저장 데이터를 보호합니다. 이 방법을 사용하면 조직 외부의 사람이 데이터에 액세스할 수 없다는 확신을 가질 수 있습니다. Cloud EKM을 사용하면 키 관리를 위한 HYOK(Hold-Your-Own-Key) 모델을 얻을 수 있습니다. 호환성 정보는 Cloud EKM이 사용 설정된 서비스 목록을 참조하세요.

또한 Cloud KMS를 사용하면 소프트웨어 지원 암호화 키 또는 FIPS 140-2 Level 3 검증 하드웨어 보안 모듈(HSM)로 데이터를 암호화할 수 있습니다. Cloud KMS를 사용하는 경우 암호화 키는 리소스를 배포하는 리전에 저장됩니다. Cloud HSM은 키 관리 요구사항을 여러 리전에 분산하여 키의 중복성과 전역 가용성을 제공합니다.

봉투 암호화 작동 원리에 대한 자세한 내용은 Google Cloud의 저장 데이터 암호화를 참조하세요.

데이터에 대한 클라우드 관리자의 액세스 권한 제어

Google Cloud의 환경에 대한 Google 지원 및 엔지니어링 담당자의 액세스를 제어할 수 있습니다. 액세스 승인을 사용하면 Google 직원이 Google Cloud의 데이터나 리소스에 액세스하기 전에 명시적으로 승인할 수 있습니다. 이 제품은 Google 직원이 데이터와 상호작용할 때 로그를 생성하는 액세스 투명성에서 제공하는 가시성을 보완합니다. 이러한 로그에는 사무실 위치와 액세스 이유가 포함됩니다.

이러한 제품을 함께 사용하면 어떤 이유로든 Google에서 데이터를 복호화하지 못하도록 거부할 수 있습니다.

데이터가 저장되는 위치와 사용자가 액세스할 수 있는 위치 구성

VPC 서비스 제어를 사용하여 사용자가 데이터에 액세스할 수 있는 네트워크 위치를 제어할 수 있습니다. 이 제품을 사용하면 특정 리전의 사용자로 액세스를 제한할 수 있습니다. Google IAM 정책에 따라 사용자가 승인된 경우에도 이 제약조건을 적용할 수 있습니다. VPC 서비스 제어를 사용하면 서비스에서 액세스할 수 있는 가상 경계를 정의하는 서비스 경계를 만들어 해당 경계 외부로 데이터가 이동되지 않도록 막을 수 있습니다.

자세한 내용은 다음을 참조하세요.

• Cloud Storage에 업로드되는 데이터 분류 자동화
• 클라우드에서의 데이터 거버넌스
• 데이터 웨어하우스에서 BigQuery로의 데이터 거버넌스
• Cloud Hive Metastore 사용 가능

Secret Manager를 사용하여 보안 비밀 관리

Secret Manager를 사용하면 모든 보안 비밀을 중앙 위치에 저장할 수 있습니다. 보안 비밀은 데이터베이스 비밀번호, API 키 또는 TLS 인증서와 같은 구성 정보입니다. 보안 비밀을 자동으로 순환할 수 있으며, 최신 버전의 보안 비밀을 자동으로 사용하도록 애플리케이션을 구성할 수 있습니다. Secret Manager와의 모든 상호작용은 감사 로그를 생성하므로 모든 보안 비밀에 대한 모든 액세스를 볼 수 있습니다.

민감한 정보 보호에는 Secret Manager와 함께 보호할 수 있는 데이터의 사용자 인증 정보와 보안 비밀을 식별하는 데 도움이 되는 감지기 카테고리도 있습니다.

데이터 모니터링

관리 활동 및 키 사용 로그를 보려면 Cloud 감사 로그를 사용하세요. 데이터를 보호하려면 Cloud Monitoring을 통해 로그를 모니터링하여 키가 적절하게 사용되는지 확인합니다.

Cloud Logging은 Google Cloud 이벤트를 캡처하고 필요한 경우 소스를 추가할 수 있게 해줍니다. 리전별로 로그를 세분화하고, 로그를 버킷에 저장하고, 로그 처리를 위한 커스텀 코드를 통합할 수 있습니다. 예시를 보려면 자동화된 로그 분석을 위한 커스텀 솔루션을 참조하세요.

또한 BigQuery로 로그를 내보내어 보안 및 액세스 분석을 수행하여 승인되지 않은 변경사항과 조직 데이터에 대한 부적절한 액세스를 식별할 수 있습니다.

Security Command Center는 클라우드에 저장된 민감한 조직 데이터에 대한 안전하지 않은 액세스 문제를 식별하고 해결하는 데 도움이 됩니다. 단일 관리 인터페이스를 통해 클라우드 인프라에 대한 다양한 보안 취약점과 위험을 스캔할 수 있습니다. 예를 들어 데이터 무단 반출을 모니터링하고, 스토리지 시스템에서 기밀 데이터를 스캔하고, 인터넷에 열려 있는 Cloud Storage 버킷을 감지할 수 있습니다.

다음 단계

다음 리소스를 통해 데이터 보안에 대해 자세히 알아보세요.

• 애플리케이션을 안전하게 배포(이 시리즈의 다음 문서)

• 기밀 데이터가 저장된 BigQuery 데이터 웨어하우스 보안

• 데이터 보안 전략 설계 및 배포(PDF)

• Google Cloud Platform을 사용한 데이터 보안(PDF)

• 버킷 잠금을 사용하는 보관 정책

• Cloud Storage 권장사항

• SQL Server 인스턴스 관련 권장사항

• Datastore 권장사항

• Data Catalog

애플리케이션을 안전하게 배포

Google Cloud 아키텍처 프레임워크의 이 문서에서는 애플리케이션의 안전한 배포를 위한 권장사항을 제공합니다.

보안 애플리케이션을 배포하려면 설계, 개발, 테스트, 배포 단계 중에 적절한 보안 검사를 통해 잘 정의된 소프트웨어 개발 수명 주기가 있어야 합니다. 애플리케이션을 설계할 때 ID, 승인, 액세스 제어에 표준화된 프레임워크를 사용하는 레이어 시스템 아키텍처를 사용하는 것이 좋습니다.

보안 출시 자동화

자동화된 도구가 없으면 일관된 보안 요구사항을 충족하기 위해 복잡한 애플리케이션 환경을 배포, 업데이트, 패치하기가 어려울 수 있습니다. 따라서 이러한 문제를 해결할 수 있도록 이러한 태스크를 위해 CI/CD 파이프라인을 빌드하는 것이 좋습니다. 자동화된 파이프라인은 수동 오류를 삭제하고 표준화된 개발 피드백 루프를 제공하며 빠른 제품 반복을 지원합니다. 예를 들어 Cloud Build 비공개 풀을 사용하면 금융 및 의료를 포함하여 엄격한 규제가 있는 산업에 적합한 안정성이 뛰어난 관리형 CI/CD 파이프라인을 배포할 수 있습니다.

아티팩트가 생성될 때 자동화를 사용하여 보안 취약점을 스캔할 수 있습니다. 확인된 아티팩트만 배포되도록 다양한 환경(개발, 테스트, 프로덕션 등)에 대한 정책을 정의할 수도 있습니다.

승인된 프로세스에 따라 애플리케이션을 배포합니다.

공격자가 CI/CD 파이프라인을 손상시킬 경우 전체 스택이 영향을 받을 수 있습니다. 파이프라인을 보호하려면 코드를 프로덕션에 배포하기 전에 설정된 승인 프로세스를 적용해야 합니다.

Google Kubernetes Engine(GKE) 또는 GKE Enterprise를 사용하려는 경우 Binary Authorization을 사용하여 이러한 확인 및 균형을 설정할 수 있습니다. Binary Authorization은 구성 가능한 서명을 컨테이너 이미지에 연결합니다. 이러한 서명(증명이라고도 함)은 이미지를 검증하는 데 도움이 됩니다. 배포 시 Binary Authorization은 이러한 증명을 사용하여 프로세스가 이전에 완료되었는지 확인합니다. 예를 들어 Binary Authorization을 사용하여 다음을 수행할 수 있습니다.

• 특정 빌드 시스템 또는 지속적 통합(CI) 파이프라인이 컨테이너 이미지를 만들었는지 확인합니다.
• 컨테이너 이미지가 취약점 서명 정책을 준수하는지 확인합니다.
• 컨테이너 이미지가 QA로의 개발과 같은 다음 배포 환경으로 승격하기 위한 기준을 통과하는지 확인합니다.

배포 전 알려진 취약점 스캔

컨테이너가 프로덕션에 배포되기 전에 컨테이너 이미지에 대한 취약점 스캔을 지속적으로 수행할 수 있는 자동화된 도구를 사용하는 것이 좋습니다.

Artifact Analysis를 사용하여 Artifact Registry 및 Container Registry에 저장된 컨테이너의 취약점을 자동으로 스캔합니다. 이 프로세스에는 스캔 및 지속적 분석이라는 두 가지 태스크가 있습니다.

먼저 Artifact Registry 또는 Container Registry에 새 이미지가 업로드되면 Artifact Analysis가 해당 이미지를 스캔합니다. 스캔은 컨테이너의 시스템 패키지에 대한 정보를 추출합니다.

그러면 Artifact Analysis가 이미지를 업로드할 때 취약점을 찾습니다. 초기 스캔 후 Artifact Analysis는 Artifact Registry 및 Container Registry에서 스캔한 이미지의 메타데이터를 지속적으로 모니터링하여 새로운 취약점이 있는지 확인합니다. Artifact Analysis는 취약점 소스에서 새로운 업데이트된 취약점 정보를 수신하면 다음을 수행합니다.

• 스캔한 이미지의 메타데이터를 업데이트하여 최신 상태로 유지합니다.
• 새 메모에 대한 새 취약점 어커런스를 만듭니다.
• 더 이상 유효하지 않은 취약점 어커런스를 삭제합니다.

애플리케이션 코드에 알려진 취약점이 있는지 모니터링합니다.

애플리케이션 코드를 지속적으로 모니터링하여 OWASP 상위 10개와 같은 알려진 취약점이 있는지 확인할 수 있는 자동화된 도구를 사용하는 것이 좋습니다. OWASP 상위 10개 완화 기술을 지원하는 Google Cloud 제품 및 기능에 대한 설명은 Google Cloud의 OWASP 상위 10개 완화 옵션을 참조하세요.

Web Security Scanner를 사용하여 App Engine, Compute Engine, Google Kubernetes Engine 웹 애플리케이션의 보안 취약점을 파악할 수 있습니다. 스캐너는 애플리케이션을 크롤링하여 시작 URL 범위 내에 있는 모든 링크를 확인하고 최대한 많은 사용자 입력과 이벤트 핸들러 실행을 시도합니다. 교차 사이트 스크립팅(XSS), 플래시 삽입, 혼합 콘텐츠(HTTPS 내 HTTP), 구버전 및 취약 라이브러리 등의 일반적인 취약점을 자동으로 스캔하고 감지할 수 있습니다. Web Security Scanner는 이러한 유형의 취약점을 조기에 식별할 수 있으므로 거짓양성률이 낮습니다.

경계 간에 데이터 이동 제어

경계 간에 데이터 이동을 제어하려면 Google 관리형 서비스의 리소스 주위에 보안 경계를 구성할 수 있습니다. VPC 서비스 제어를 사용하여 CI/CD 파이프라인의 모든 구성요소와 서비스(예: Container Registry, Artifact Registry, Artifact Analysis, Binary Authorization)를 보안 경계 내에 배치합니다.

VPC 서비스 제어는 Google 관리형 서비스에서 데이터를 무단으로 복사하거나 전송하는 위험(데이터 무단 반출)을 완화하는 기능을 개선합니다. VPC 서비스 제어를 사용하여 Google 관리형 서비스의 리소스 주위에 보안 경계를 구성하고 경계 범위 간의 데이터 이동을 제어합니다. 서비스 경계가 시행되면 경계 외부에서 보호되는 서비스에 대한 요청과 같이 경계 정책을 위반하는 요청은 거부됩니다. 시행 경계로 서비스가 보호되는 경우 VPC 서비스 제어는 다음을 확인합니다.

• 서비스는 경계 외부로 데이터를 전송할 수 없습니다. 보호된 서비스는 경계 내에서 정상적으로 작동하지만 경계 외부로 리소스와 데이터를 전송할 수 없습니다. 이러한 제한은 경계의 프로젝트에 액세스할 수 있는 악의적인 내부자가 데이터를 유출하는 것을 방지하는 데 도움이 됩니다.
• 경계 외부에서 보호된 서비스로 보내는 요청은 경계에 할당된 액세스 수준의 기준을 충족하는 경우에만 적용됩니다.
• 경계 브리지를 사용하여 다른 경계의 프로젝트에서 이 서비스에 액세스할 수 있습니다.

컨테이너 이미지 암호화

Google Cloud에서는 고객 관리 암호화 키(CMEK)를 사용하여 컨테이너 이미지를 암호화할 수 있습니다. CMEK 키는 Cloud Key Management Service(Cloud KMS)에서 관리됩니다. CMEK를 사용할 때 키를 사용 중지하거나 폐기하여 암호화된 컨테이너 이미지에 대한 액세스를 일시적으로 또는 영구적으로 사용 중지할 수 있습니다.

다음 단계

다음 리소스를 통해 공급망 및 애플리케이션 보안을 보호하는 방법을 자세히 알아보세요.

• 규정 준수 의무 관리(이 시리즈의 다음 문서)
• 운영 우수성
• Binary Authorization
• Artifact Analysis
• Artifact Registry

규정 준수 의무 관리

Google Cloud 아키텍처 프레임워크의 이 문서에서는 규정 준수 의무를 관리하기 위한 권장사항을 제공합니다.

클라우드 규제 요구사항은 다음 요소들의 조합에 따라 달라집니다.

• 조직의 물리적 위치에 적용되는 법률 및 규정
• 고객의 물리적 위치에 적용되는 법률 및 규정
• 업계의 규제 요구사항

이러한 요구사항은 Google Cloud에서 워크로드에 사용 설정할 보안 제어에 대해 결정해야 하는 여러 가지 사항을 좌우합니다.

일반적인 규정 준수는 평가, 간격 해결, 지속적인 모니터링의 세 가지 단계로 진행됩니다. 이 섹션에서는 각 단계에서 사용할 수 있는 권장사항을 설명합니다.

규정 준수 요구사항 평가

규정 준수 평가는 모든 규제 의무와 비즈니스가 이를 구현하는 방식을 철저하게 검토합니다. Google Cloud 서비스 평가에 도움이 되도록 규정 준수 리소스 센터를 사용하세요. 이 사이트에서 제공되는 세부정보는 다음과 같습니다.

• 다양한 규정 서비스 지원
• Google Cloud 인증 및 증명

Google 규정 준수 전문가와의 상담을 요청하면 Google의 규정 준수 수명 주기와 요구사항을 충족하는 방법을 더 잘 이해할 수 있습니다.

자세한 내용은 클라우드에서 규정 준수 보장(PDF)을 참조하세요.

Assured Workloads 배포

Assured Workloads는 Google Cloud 내의 제어를 기반으로 하는 Google Cloud 도구이며, 규정 준수 의무를 이행하는 데 도움이 됩니다. Assured Workloads를 사용하면 다음을 수행할 수 있습니다.

• 규정 준수 체계를 선택합니다. 그런 다음 이 도구는 기준 직원 액세스 제어를 자동으로 설정합니다.
• 조직 정책을 통해 데이터 위치를 설정하여 저장 데이터와 리소스가 해당 리전에만 유지되도록 합니다.
• 보안 및 규정 준수 요구사항에 가장 적합한 키 관리 옵션(예: 키 순환 기간)을 선택합니다.
• FedRAMP Moderate과 같은 특정 규제 요건에 따라 Google 지원 담당자의 액세스 기준(예: 적절한 백그라운드 확인 완료 여부)을 선택하세요.
• Google 관리 암호화 키가 FIPS-140-2를 준수하고 FedRAMP 중간 수준 규정 준수를 지원하는지 확인합니다. 추가적인 제어 레이어와 업무 분리를 위해 고객 관리 암호화 키(CMEK)를 사용할 수 있습니다. 키에 대한 자세한 내용은 데이터 암호화를 참조하세요.

규정 준수 체계에 적용되는 템플릿 및 권장사항의 청사진 검토

Google은 권장사항을 설명하고 규정 준수를 달성하는 데 도움이 되는 환경을 배포할 수 있는 Terraform 모듈을 제공하는 청사진 및 솔루션 가이드를 게시했습니다. 다음 표에는 보안 문제를 해결하고 규정 준수 요구사항에 부합하는 청사진이 나열되어 있습니다.

표준	설명
PCI	보안 청사진: PCI on GKE PCI 데이터 보안 표준 규정 준수 Google Cloud의 PCI 환경 규정 준수 범위 제한 GKE의 PCI DSS 규정 준수
FedRAMP	Google Cloud FedRAMP 구현 가이드(PDF) Google Cloud에서 FedRAMP 정렬 3계층 워크로드 설정
HIPAA	Google Cloud의 의료 데이터 보호(PDF) Data Protection Toolkit을 사용한 HIPAA 지원 워크로드 설정(PDF)

규정 준수 모니터링

대부분의 규정에서는 액세스 제어를 비롯한 특정 활동을 모니터링해야 합니다. 모니터링에 도움이 되려면 다음을 사용합니다.

• 액세스 투명성: Google Cloud 관리자가 콘텐츠에 액세스할 때 거의 실시간 수준의 로그를 제공합니다.
• 방화벽 규칙 로깅: 직접 만든 규칙에 대한 VPC 네트워크 내부의 TCP 및 UDP 연결을 기록합니다. 이러한 로그는 네트워크 액세스를 감사하거나 네트워크가 승인되지 않은 방식으로 사용되고 있음을 미리 경고하는 데 유용할 수 있습니다.
• VPC 흐름 로그: VM 인스턴스에서 전송 또는 수신되는 네트워크 트래픽 흐름을 기록합니다.
• Security Command Center 프리미엄: 다양한 표준을 준수하는지 여부를 모니터링합니다.
• OSSEC(또는 다른 오픈소스 도구): 환경에 대한 관리자 액세스 권한이 있는 개별 사용자의 활동을 로깅합니다.
• 키 액세스 근거: 키 액세스 요청의 이유를 봅니다.

규정 준수 자동화

변화하는 규정을 계속 준수할 수 있도록 보안 정책을 코드 배포로 인프라에 통합하여 보안 정책을 자동화할 수 있는 방법이 있는지 확인합니다. 예를 들어, 다음 사항을 고려해 보세요.

• 보안 청사진을 사용하여 인프라 배포에 보안 정책을 구축합니다.

• Security Command Center를 구성하여 규정 준수 문제가 발생하면 알리도록 합니다. 예를 들어 사용자가 2단계 인증 또는 권한이 높은 서비스 계정을 사용 중지하는 것과 같은 문제를 모니터링합니다. 자세한 내용은 발견 항목 알림 설정을 참조하세요.

• 특정 알림에 대한 자동 구제 조치를 설정합니다. 자세한 내용은 Cloud Functions 코드를 참조하세요.

규정 준수 자동화에 대한 자세한 내용은 코드형 위험 및 규정 준수(RCaC) 솔루션을 참조하세요.

다음 단계

다음 리소스의 규정 준수에 대해 자세히 알아보세요.

• 데이터 보존 및 주권 요구사항 구현(이 시리즈의 다음 문서)
• 규정 준수 리소스 센터
• Google 보안 백서(PDF)
• Assured Workloads

데이터 상주 및 데이터 주권 요구사항 구현

Google Cloud 아키텍처 프레임워크의 이 문서에서는 데이터 보존 및 데이터 주권 요구사항을 구현하기 위한 권장사항을 제공합니다.

데이터 상주 및 주권 요구사항은 각 리전 규정과 업종별 규정을 기반으로 하며 조직마다 데이터 주권 요구사항이 다를 수 있습니다. 예를 들어 다음 요구사항이 있을 수 있습니다.

• 데이터에 액세스할 수 있는 직원과 액세스할 수 있는 리전을 포함하여 Google Cloud의 데이터에 대한 액세스 제어
• 데이터 액세스나 데이터 보안에 영향을 미칠 수 있는 클라우드 인프라와 서비스의 변경사항 검사. 이러한 유형의 변경사항에 대한 유용한 정보는 Google Cloud가 제어 수단을 우회하거나 데이터를 리전 외부로 이동할 수 없게 하는데 도움이 됩니다.
• Google Cloud에서 소프트웨어 업데이트를 수신할 수 없는 경우 장시간 워크로드를 유지합니다.

데이터 주권 관리

데이터 주권에서는 Google이 사용자 데이터에 액세스하지 못하게 하는 메커니즘을 제공합니다. 동의가 필요한 제공업체 동작에 대한 액세스만 승인합니다.

예를 들어 다음과 같은 방법으로 데이터 주권을 관리할 수 있습니다.

• 클라우드 외부에서 암호화 키를 저장하고 관리합니다.
• 자세한 액세스 근거에 따라 이러한 키에 대한 액세스 권한만 부여합니다.
• 사용 중인 데이터를 보호합니다.

운영 주권 관리

운영 주권에서는 Google 직원이 워크로드를 손상시킬 수 없다는 확신을 제공합니다.

예를 들어 다음과 같은 방법으로 운영 주권을 관리할 수 있습니다.

• 새 리소스 특정 공급업체 리전으로의 배포를 제한합니다.
• 시민권 또는 지리적 위치와 같은 사전 정의된 속성을 기반으로 Google 직원의 액세스를 제한합니다.

소프트웨어 주권 관리

소프트웨어 주권은 단일 클라우드 제공업체에 종속(잠금)되지 않고 워크로드 가용성을 제어하고 원하는 곳에서 실행할 수 있음을 보증합니다. 소프트웨어 주권에는 워크로드가 배포되는 위치와 허용되는 외부 연결 수준을 빠르게 변경해야 하는 이벤트에서 생존할 수 있는 기능이 포함됩니다.

예를 들어 Google Cloud에서는 하이브리드 및 멀티 클라우드 배포를 지원합니다. 또한 GKE Enterprise를 사용하면 클라우드 환경과 온프레미스 환경 모두에서 애플리케이션을 관리하고 배포할 수 있습니다

데이터 상주 제어

데이터 상주에서는 데이터가 저장되는 위치를 설명합니다. 데이터 상주 요구사항은 시스템 설계 목표, 업계 규제 문제, 국가 법률, 세금 관련 사항, 심지어 문화에 따라 달라집니다.

데이터 상주 제어는 다음으로 시작합니다.

• 데이터 유형 및 위치 이해
• 데이터에 어떤 위험이 있는지, 적용되는 법률과 규정이 무엇인지 확인
• 데이터 저장 위치 또는 이동 위치 제어

데이터 상주 요구사항을 준수하기 위해 Google Cloud를 사용하여 데이터 저장 위치, 액세스 방법, 처리 방법을 제어할 수 있습니다. 리소스 위치 정책을 사용하여 리소스가 생성되는 위치를 제한하고 리전 간에 데이터가 복제되는 위치를 제한할 수 있습니다. 리소스 위치 속성을 사용하여 서비스가 배포되는 위치와 유지보수하는 사용자를 식별할 수 있습니다.

지원 가능성 정보는 리소스 위치 지원 서비스를 참조하세요.

다음 단계

다음 리소스를 통해 데이터 상주와 주권에 대해 자세히 알아보세요.

• 개인 정보 보호 요건 구현(이 시리즈의 다음 문서)
• Google Cloud 유럽 고객을 위한 데이터 상주, 운영 투명성, 개인정보 보호(PDF)
• 데이터 보안 전략 설계 및 배포(PDF)
• Cloud Key Management Service
• Google Cloud Platform을 사용한 데이터 보안(PDF)
• Google의 액세스 권한 관리
• Google Cloud 액세스 투명성

개인 정보 보호 요건 구현

Google Cloud 아키텍처 프레임워크의 이 문서에서는 개인 정보 보호 요건을 구현하기 위한 권장사항을 제공합니다.

개인 정보 보호 규정은 사용자 데이터를 획득, 처리, 저장, 관리하는 방법을 정의하는 데 도움이 됩니다. 개발자가 데이터(사용자로부터 받은 데이터 포함)를 소유하므로 많은 개인 정보 보호 설정(예: 쿠키 제어, 세션 관리, 사용자 권한 획득)은 사용자 책임입니다.

Google Cloud에는 개인 정보 보호를 승격하는 다음과 같은 제어가 포함되어 있습니다.

• 저장 데이터, 전송 중인 데이터, 처리 중인 데이터 등 모든 데이터의 기본 암호화
• 내부자 액세스 방지
• 다양한 개인 정보 보호 규정 지원

자세한 내용은 Google Cloud 개인 정보 보호 약정을 참조하세요.

기밀 데이터 분류

기밀 데이터를 정의하고 기밀 데이터가 올바르게 보호되고 있는지 확인해야 합니다. 기밀 데이터에는 신용카드 번호, 주소, 전화번호, 기타 개인 식별 정보(PII)가 포함될 수 있습니다.

민감한 정보 보호를 사용하면 적절한 분류를 설정할 수 있습니다. 그런 다음 Google Cloud에 데이터를 저장하기 전에 데이터에 태그를 지정하고 토큰화할 수 있습니다. 자세한 내용은 데이터 자동 분류를 참조하세요.

민감한 정보에 대한 액세스 잠금

VPC 서비스 제어를 사용하여 자체 서비스 경계에 민감한 정보를 배치하고 해당 데이터에 대한 Google Identity and Access Management(IAM) 액세스 제어를 설정합니다. 민감한 정보에 액세스해야 하는 모든 사용자에 다단계 인증(MFA)을 구성합니다.

자세한 내용은 경계 간 데이터 이동 제어 및 SSO 및 MFA 설정을 참조하세요.

피싱 공격 모니터링

사기 및 멀웨어 공격에 자주 사용되는 피싱 공격으로부터 보호하도록 이메일 시스템을 구성했는지 확인합니다.

조직에서 Gmail을 사용하면 고급 피싱 및 멀웨어 차단을 사용할 수 있습니다. 이 설정 모음은 이메일 격리 제어를 제공하고 비정상적인 첨부파일 형식으로부터 보호하며 인바운드 스푸핑 이메일로부터 보호하는 데 도움이 됩니다. 보안 샌드박스는 첨부파일에서 멀웨어를 감지합니다. Gmail은 조직의 이메일을 안전하게 보호하는 데 도움이 되도록 최신 보안 개선사항과 보호 조치로 지속적으로 자동 업데이트됩니다.

하이브리드 작업자로 제로 트러스트 보안 확장

제로 트러스트 보안 모델은 조직 네트워크 내부 또는 외부에 관계없이 어떤 것도 암시적으로 신뢰되지 않음을 의미합니다. IAM 시스템이 액세스 요청을 확인할 때 제로 트러스트 보안 상태는 사용자의 ID 및 컨텍스트(예: IP 주소 또는 위치)가 고려된다는 의미입니다. VPN과 달리 제로 트러스트 보안은 액세스 제어를 네트워크 경계에서 사용자와 사용자 기기로 이전합니다. 제로 트러스트 보안을 통해 사용자는 어디서나 더욱 안전하게 업무를 처리할 수 있습니다. 예를 들어 사용자는 가정에서 노트북이나 모바일 기기에서 조직의 리소스에 액세스할 수 있습니다.

Google Cloud에서 BeyondCorp Enterprise 및 IAP(Identity-Aware Proxy)를 구성하여 Google Cloud 리소스에 제로 트러스트를 사용 설정할 수 있습니다. 사용자가 Google Chrome을 사용하고 BeyondCorp Enterprise를 사용 설정한 경우 사용자 브라우저에 제로 트러스트 보안을 통합할 수 있습니다.

다음 단계

다음 리소스를 통해 보안과 개인 정보 보호에 대해 자세히 알아보세요.

• 로깅 및 감지 제어 구현(이 시리즈의 다음 문서)
• 개인정보 보호센터

• Google Cloud 개인정보처리방침

• Google Cloud 지원팀과 작업 시 개인 정보 보호 권장사항

• Google에서 조직의 보안을 유지하고 개인정보를 보호하는 방법

• 개인정보 보호 FAQ

로깅 및 감지 제어 구현

Google Cloud 아키텍처 프레임워크의 이 문서에서는 로깅 및 감지 제어를 구현할 수 있는 권장사항을 제공합니다.

감지 제어는 원격 분석을 사용해서 잘못된 구성, 취약점, 클라우드 환경의 잠재적으로 악의적인 활동을 감지합니다. Google Cloud를 사용하면 환경에 맞게 조정된 모니터링 및 감지 제어를 만들 수 있습니다. 이 섹션에서는 이러한 추가 기능 및 사용 권장사항을 설명합니다.

네트워크 성능 모니터링

Network Intelligence Center에서는 네트워크 토폴로지와 아키텍처의 성능을 파악할 수 있습니다. 네트워크 성능에 대한 자세한 정보를 가져온 후 이 정보를 사용하여 서비스에서 병목 현상을 제거해 배포를 최적화할 수 있습니다. 연결 테스트는 네트워크 경로에 적용되는 방화벽 규칙과 정책에 대한 유용한 정보를 제공합니다.

데이터 무단 반출 모니터링 및 방지

데이터 무단 반출은 조직의 주요 관심사입니다. 데이터 무단 반출은 일반적으로 승인된 사람이 보안 시스템에서 데이터를 추출한 후 해당 데이터를 승인되지 않은 당사자와 공유하거나 안전하지 않은 시스템으로 이동하는 경우에 발생합니다.

Google Cloud에서는 데이터 무단 반출을 감지하고 방지하는 데 도움이 되는 몇 가지 기능과 도구를 제공합니다. 자세한 내용은 데이터 무단 반출 방지를 참조하세요.

모니터링 중앙 집중화

Security Command Center는 Google Cloud의 리소스와 보안 상태에 대한 가시성을 제공합니다. Security Command Center는 위협을 예방 및 감지하고 이에 대응하도록 도와줍니다. 가상 머신, 네트워크, 애플리케이션, 스토리지 버킷에서 잘못된 보안 구성을 식별하는 데 사용할 수 있는 중앙 대시보드를 제공합니다. 비즈니스 손상 또는 손실을 입기 전에 이러한 문제를 해결할 수 있습니다. Security Command Center의 기본 제공 기능으로 Cloud Logging 보안 로그에서 의심스러운 활동을 표시하거나 손상된 가상 머신을 표시할 수 있습니다.

실행 가능한 권장사항을 따르거나 로그를 SIEM 시스템으로 내보내 추가 조사를 진행하여 위협에 대응할 수 있습니다. Google Cloud에서 SIEM 시스템을 사용하는 방법에 대한 자세한 내용은 Google Cloud의 보안 로그 분석을 참조하세요.

Security Command Center에서도 인프라 보안을 분석하는 데 도움이 되는 여러 감지기를 제공합니다. 이러한 감지기에는 다음이 포함됩니다.

• Event Threat Detection
• Security Health Analytics(SHA)
• 민감한 작업 서비스

Google Cloud Armor 로그 등의 다른 Google Cloud 서비스도 Security Command Center에 표시할 발견 항목을 제공합니다.

워크로드에 필요한 서비스를 사용 설정한 후 중요 데이터만 모니터링하고 분석합니다. 서비스 로깅 사용 설정에 대한 자세한 내용은 Google Cloud의 보안 로그 분석에서 로그 사용 설정 섹션을 참조하세요.

위협 모니터링

Event Threat Detection은 로그 스트림의 위협을 감지하는 Security Command Center 프리미엄의 선택적 관리형 서비스입니다. Event Threat Detection을 사용하면 멀웨어, 암호화폐 채굴, 승인되지 않은 Google Cloud 리소스 액세스, DDoS 공격, SSH 무작위 공격 등 위험도가 높고 많은 비용이 드는 위협을 감지할 수 있습니다. 이 도구의 기능을 사용하여 대량의 로그 데이터를 추출함으로써 보안팀에서 고위험 이슈를 빠르게 식별하고 구제 조치를 마련하는 데 집중할 수 있습니다.

사용자 계정의 유출 가능성을 조직에서 감지할 수 있도록 민감한 작업 Cloud Platform 로그를 사용하여 민감한 작업이 수행되는 시점을 파악하고 유효한 사용자가 적합한 목적으로 작업을 수행했는지를 확인하세요. 민감한 작업이란 높은 권한의 역할 추가와 같이 악의적인 행위자가 수행했을 때 비즈니스에 피해를 줄 수 있는 작업입니다. Cloud Logging을 사용하여 민감한 작업 Cloud Platform 로그를 조회, 모니터링, 쿼리하세요. 또한 Security Command Center 프리미엄의 기본 제공 서비스인 민감한 작업 서비스로 민감한 작업 로그 항목을 볼 수 있습니다.

Chronicle은 모든 보안 데이터를 중앙에서 저장하고 분석할 수 있습니다. 공격의 전체 스팬을 볼 수 있도록 Chronicle은 로그를 공통 모델로 매핑하고 보강한 후 타임라인에 연결할 수 있습니다. 또한 Chronicle을 사용하여 감지 규칙을 만들고, 침해 지표(IoC) 일치 기준을 설정하고, 위협 탐지 활동을 수행할 수 있습니다. 감지 규칙은 YARA-L 언어로 작성합니다. YARA-L의 샘플 위협 감지 규칙은 커뮤니티 보안 분석(CSA) 저장소를 참조하세요. 자체 규칙을 작성하는 것 외에도 Chronicle의 선별된 감지를 활용할 수 있습니다. 이러한 선별된 감지는 위협을 식별하는 데 도움이 되는 사전 정의된 관리형 YARA-L 규칙 집합입니다.

보안 분석, 감사, 조사를 위해 로그를 중앙화하는 또 다른 옵션은 BigQuery를 사용하는 것입니다. BigQuery에서는 SQL 쿼리(예: CSA 저장소 쿼리)를 사용하여 권한 변경, 프로비저닝 활동, 워크로드 사용량, 데이터 액세스, 네트워크 활동을 분석하여 일반적인 위협 또는 잘못된 구성을 모니터링합니다. 설정부터 분석까지 BigQuery의 보안 로그 분석에 대한 자세한 내용은 Google Cloud의 보안 로그 분석을 참조하세요.

다음 다이어그램은 Security Command Center의 기본 제공되는 위협 감지 기능과 BigQuery, Chronicle 또는 서드 파티 SIEM에서 수행하는 위협 감지를 모두 사용하여 모니터링을 중앙 집중화하는 방법을 보여줍니다.

다이어그램에 표시된 것처럼 다양한 보안 데이터 소스를 모니터링해야 합니다. 이러한 데이터 소스에는 Cloud Logging의 로그, Cloud 애셋 인벤토리의 애셋 변경사항, Google Workspace 로그, 하이퍼바이저 또는 게스트 커널의 이벤트가 포함됩니다. 다이어그램은 Security Command Center를 사용하여 이러한 데이터 소스를 모니터링할 수 있음을 보여줍니다. 이 모니터링은 Security Command Center에서 적절한 기능과 위협 감지기를 사용 설정한 경우에 자동으로 수행됩니다. 이 다이어그램은 보안 데이터 및 Security Command Center 발견 항목을 BigQuery, Chronicle 또는 서드 파티 SIEM과 같은 분석 도구로 내보내 위협을 모니터링할 수도 있음을 보여줍니다. 분석 도구에서 이 다이어그램은 CSA에서 사용 가능한 것과 같은 쿼리 및 규칙을 사용 및 확장하여 추가 분석 및 조사를 수행할 수 있음을 보여줍니다.

다음 단계

다음 리소스를 통해 로깅 및 감지에 대해 자세히 알아보세요.

• Cloud Logging

• Google Cloud의 Chronicle Detect 소개

• 이슈 관리를 위한 공동작업 프로세스 빌드

Google Cloud 아키텍처 프레임워크: 안정성

Google Cloud 아키텍처 프레임워크의 이 카테고리에서는 안정적인 서비스를 설계하여 클라우드 플랫폼에서 운영하는 방법을 보여줍니다. 또한 안정성을 지원하는 몇 가지 Google Cloud 제품 및 기능에 대해 알아봅니다.

아키텍처 프레임워크는 권장사항을 설명하고 구현 권장사항을 제공하며 사용 가능한 여러 제품 및 서비스를 설명합니다. 이 프레임워크의 목표는 비즈니스 요구사항에 가장 잘 맞는 Google Cloud 배포를 설계하도록 지원하는 것입니다.

안정적인 서비스를 실행하려면 아키텍처에 다음이 포함되어야 합니다.

• 편차를 즉시 수정할 수 있는 측정 가능한 안정성 목표
• 확장성, 고가용성, 재해 복구, 자동 변경 관리를 위한 설계 패턴
• 가능한 경우 자가 복구되는 구성요소와 관측 가능성을 위한 계측을 포함하는 코드
• 작업자의 수작업과 인지 부하를 최소화하여 서비스를 실행하고 장애를 빠르게 감지하고 완화할 수 있는 운영 절차

안정성은 개발팀, 제품 관리, 운영, 사이트 안정성 엔지니어링(SRE)팀 등에 속한 모든 엔지니어링 담당자의 책임입니다. 모두가 책임 의식을 갖고 애플리케이션의 안정성 목표, 위험 및 오류 예산을 이해하고 있어야 합니다. 팀은 업무 우선순위를 적절하게 지정하고 안정성과 제품 기능 개발 간의 우선순위 충돌을 에스컬레이션할 수 있어야 합니다.

아키텍처 프레임워크의 안정성 카테고리에서는 다음을 수행하는 방법을 알아봅니다.

• 안정성의 핵심 원칙 이해
• 안정성 목표 정의
• SLO 정의
• SLO 채택
• 인프라 및 애플리케이션에 관측 가능성 빌드
• 확장성 및 고가용성 설계
• 안정적인 운영 프로세스 및 도구 만들기
• 효율적인 알림 빌드
• 이슈 관리를 위한 공동작업 프로세스 빌드

신뢰성 원칙

아키텍처 프레임워크의 이 문서에서는 클라우드 플랫폼에서 안정적인 서비스를 실행하기 위한 몇 가지 핵심 원칙을 설명합니다. 이러한 원칙은 일부 Google Cloud 제품 및 기능이 안정적인 서비스를 지원하는 방법을 보여주는 아키텍처 프레임워크의 추가 섹션을 읽는 동안 공통의 이해를 만드는 데 도움이 됩니다.

주요 용어

신뢰성 관행과 관련된 몇 가지 일반적인 용어가 있습니다. 많은 독자에게 익숙할 수도 있습니다. 하지만 다시 확인하려면 용어 페이지에서 자세한 설명을 참조하세요.

핵심 원칙

안정성에 대한 Google의 접근 방식은 다음 핵심 원칙을 기반으로 합니다.

안정성이 최우선 과제

단기적으로는 새 제품 기능이 최우선 과제가 되는 경우가 있습니다. 그러나 안정성이 장기적으로는 최고 제품 기능입니다. 제품이 너무 느리거나 장기간 사용할 수 없게 되면 사용자가 떠나 관련 없는 다른 제품 기능이 됩니다.

안정성은 사용자가 정의

사용자 대상 워크로드의 경우 사용자 환경을 측정합니다. 사용자가 서비스 수행 방식에 만족해야 합니다. 예를 들어 CPU 사용량 같은 서버 측정항목뿐만 아니라 사용자 요청의 성공률을 측정합니다.

일괄 워크로드와 스트리밍 워크로드의 경우 디스크 사용량과 같은 서버 측정항목 대신 기간별로 스캔된 행과 같은 데이터 처리량의 핵심성과지표(KPI)를 측정해야 할 수 있습니다. 처리량 KPI를 사용하면 사용자에게 필요한 일일 보고서나 분기별 보고서를 제시간에 완성할 수 있습니다.

100% 안정성은 잘못된 목표임

시스템의 안정성은 사용자가 만족할 만한 수준이어야 하고 투자가 정당화되지 않을 만큼 과도한 수준은 아니어야 합니다. 원하는 안정성 기준을 설정하는 SLO를 정의한 다음에는 오류 예산을 사용하여 적절한 변경 속도를 관리하세요.

해당 제품 또는 애플리케이션의 SLO가 비용의 근거를 제공하는 경우에만 이 프레임워크의 설계 및 운영 원칙을 제품에 적용합니다.

안정성과 빠른 혁신은 상호 보완 관계

오류 예산을 사용하여 시스템 안정성과 개발자 민첩성 사이의 균형을 유지하세요. 다음 지침은 빨리. 또는 느리게 행동할 시기를 결정하는 데 도움이 됩니다.

• 적절한 오류 예산을 사용할 수 있으면 신속하게 혁신하고 제품을 개선하거나 제품 기능을 추가할 수 있습니다.
• 오류 예산이 줄어들면 속도를 늦추고 안정성 기능에 집중하세요.

설계 및 운영 원칙

시스템 안정성을 극대화하기 위해 다음 설계 및 운영 원칙이 적용됩니다. 각 원칙은 아키텍처 프레임워크 안정성 카테고리의 나머지 부분에 자세히 설명되어 있습니다.

안정성 목표 정의

이 아키텍처 프레임워크 섹션에서 다루는 권장사항은 다음과 같습니다.

• 적절한 SLI 선택
• 사용자 경험에 따라 SLO를 설정
• SLO를 반복적으로 개선
• 엄격한 내부 SLO 사용
• 오류 예산을 사용하여 개발 속도를 관리할 수 있습니다.

자세한 내용은 아키텍처 프레임워크 안정성 카테고리에서 안정성 목표 정의를 참조하세요.

인프라 및 애플리케이션에 관측 가능성을 빌드합니다.

이 아키텍처 프레임워크 섹션에서는 다음과 같은 설계 원칙을 다룹니다.

• 코드를 사용하면 관측 가능성을 극대화할 수 있습니다.

자세한 내용은 아키텍처 프레임워크 안정성 카테고리의 인프라 및 애플리케이션에 관측 가능성 빌드를 참조하세요.

확장성 및 고가용성 설계

이 아키텍처 프레임워크 섹션에서는 다음 설계 원칙을 다룹니다.

• 중복성을 생성하여 가용성을 높이기
• 재해 복구를 위해 리전 간 데이터 복제
• 리전 서비스 중단에 대한 복원력이 우수한 멀티 리전 아키텍처 설계
• 확장성 병목 현상 제거
• 과부하 시 단계적으로 서비스 수준 저하
• 트래픽 급증을 방지하고 완화하기
• 입력 삭제 및 유효성 검사
• 시스템 작동이 지속되는 안전 장치
• 재시도할 수 있도록 API 호출 및 작업 명령어 설계
• 시스템 종속 항목 식별 및 관리
• 중요한 종속 항목 최소화
• 모든 변경 사항을 롤백 가능한지 확인

자세한 내용은 아키텍처 프레임워크 안정성 카테고리의 확장 및 고가용성 설계를 참조하세요.

안정적인 운영 프로세스 및 도구 만들기

이 아키텍처 프레임워크 섹션에서는 다음 운영 원칙을 다룹니다.

• 애플리케이션 및 서비스에 대해 적합한 이름 선택
• 카나리아 테스트 절차로 점진적 출시 구현
• 예약 프로모션 및 출시를 위한 트래픽 분산
• 빌드, 테스트, 배포 프로세스 자동화
• 작업자 오류 방지
• 오류 복구 절차 테스트
• 재해 복구 테스트 수행
• 카오스 엔지니어링 연습

자세한 내용은 아키텍처 프레임워크 안정성 카테고리의 안정적인 운영 프로세스 및 도구 만들기를 참조하세요.

효율적인 알림 빌드

이 아키텍처 프레임워크 섹션에서는 다음 운영 원칙을 다룹니다.

• 알림 지연 최적화
• 원인이 아닌 증상에 대한 알림
• 평균이 아닌 이상점에 대한 알림

자세한 내용은 아키텍처 프레임워크 안정성 카테고리의 효율적인 알림 빌드를 참조하세요.

이슈 관리를 위한 공동작업 프로세스 빌드

이 아키텍처 프레임워크 섹션에서는 다음 운영 원칙을 다룹니다.

• 명확한 서비스 소유권 할당
• 미세 조정 알림으로 감지 시간(TTD)을 단축
• 사고 관리 계획 및 교육을 통해 완화 시간(TTM) 단축
• TTM을 최소화하도록 대시보드 레이아웃과 콘텐츠 설계
• 알려진 중단 시나리오에 대한 진단 절차 및 완화 기술
• 비난 없는 사후 분석을 통해 서비스 중단으로부터 배우고 재발 방지

자세한 내용은 아키텍처 프레임워크 안정성 카테고리의 공동작업 이슈 관리 프로세스 빌드를 참조하세요.

다음 단계

• 안정성 목표 정의(이 시리즈의 다음 문서)

시스템 설계, 운영 우수성, 보안, 개인 정보 보호, 규정 준수 등 아키텍처 프레임워크의 다른 카테고리를 살펴봅니다.

안정성 목표 정의

Google Cloud 아키텍처 프레임워크의 이 문서에서는 안정적인 서비스를 실행할 수 있도록 서비스의 고객 경험을 측정하는 적절한 방법을 정의하는 권장사항을 제공합니다. 정의한 서비스 수준 목표(SLO)를 반복하는 방법을 알아보고 오류 예산을 사용하여 추가 업데이트를 출시할 경우 안정성이 저하되는 시점을 파악합니다.

적절한 SLI 선택

적절한 서비스 수준 지표(SLI)를 선택하여 서비스 성능을 완전히 이해하는 것이 중요합니다. 예를 들어 애플리케이션에 여러 독립적인 고객이 사용하는 전형적인 SaaS 애플리케이션인 멀티 테넌트 아키텍처가 있으면 테넌트 수준에서 SLI를 캡처합니다. SLI가 전역 집계 수준에서만 측정되면 애플리케이션에서 중요한 고객 한 명 또는 소수의 고객에게 영향을 미치는 중요한 문제를 놓칠 수 있습니다. 대신 각 사용자 요청에 테넌트 식별자를 포함하도록 애플리케이션을 설계한 다음 스택의 각 레이어를 통해 해당 식별자를 전파합니다. 이렇게 하면 모니터링 시스템에서 요청 경로를 따라 모든 레이어 또는 마이크로서비스의 테넌트 수준에서 통계를 집계할 수 있습니다.

다음 예시와 같이 실행하는 서비스 유형에 따라 모니터링할 SLI가 결정됩니다.

제공 시스템

데이터를 제공하는 시스템의 일반적인 SLI는 다음과 같습니다.

• 가용성은 서비스를 사용할 수 있는 시간의 비율을 나타냅니다. 가용성은 보통 제대로 구성된 요청 중 성공한 요청의 비율(예: 99%)로 정의됩니다.
• 지연 시간은 특정 비율의 요청이 처리되는 속도를 나타냅니다. 지연 시간은 보통 50번째 백분위수가 아닌 '300밀리초에서 99번째 백분위수'와 같이 정의됩니다.
• 품질은 특정 응답이 얼마나 양호한지 나타냅니다. 품질은 보통 서비스별로 정의되며, 요청에 대한 응답 콘텐츠와 이상적인 응답 콘텐츠 간의 차이 정도를 나타냅니다. 응답 품질은 양호 또는 불량이거나 0~100% 범위의 비율로 표현할 수 있습니다.

데이터 처리 시스템

데이터를 처리하는 시스템의 일반적인 SLI는 다음과 같습니다.

• 노출 범위는 처리된 데이터의 비율을 나타냅니다(예: 99.9%).
• 정확성은 정답으로 간주되는 출력 데이터의 비율을 나타냅니다(예: 99.99%).
• 최신성은 소스 데이터 또는 집계된 출력 데이터가 얼마나 최신인지를 나타냅니다. 일반적으로 최신 업데이트일수록 좋습니다(예: 20분).
• 처리량은 처리 중인 데이터의 양을 나타냅니다(예: 500MiB/초 또는 초당 요청(RPS) 1,000개).

스토리지 시스템

데이터를 저장하는 시스템의 일반적인 SLI는 다음과 같습니다.

• 내구성은 시스템에 기록된 데이터가 나중에 검색되는 가능성을 나타냅니다(예: 99.9999%). 영구적인 데이터 손실 이슈는 내구성 측정항목을 줄입니다.
• 처리량과 지연 시간도 스토리지 시스템의 일반적인 SLI입니다.

사용자 환경에 따른 SLI 선택 및 SLO 설정

이 아키텍처 프레임워크 섹션의 핵심 원칙 중 하나는 사용자가 안정성을 정의한다는 것입니다. 다음 옵션과 같이 안정성 측정항목을 사용자와 최대한 가깝게 계측합니다.

• 가능하다면 모바일 또는 웹 클라이언트를 계측합니다.
  • 예를 들어 Firebase 성능 모니터링을 사용하면 iOS, Android, 웹 앱의 성능 특성을 파악할 수 있습니다.
• 그럴 수 없다면 부하 분산기를 계측합니다.
  • 예를 들어 외부 애플리케이션 부하 분산기 로깅 및 모니터링에 Cloud Monitoring을 사용합니다.
• 마지막 옵션으로 서버의 안정성을 계측합니다.
  • 예를 들어 Cloud Monitoring으로 Compute Engine 인스턴스를 모니터링합니다.

SLO는 거의 모든 사용자가 서비스에 만족하고 더 높은 항목이 없도록 충분히 높게 설정합니다. 네트워크 연결 또는 기타 일시적인 클라이언트 측 문제로 인해 고객이 애플리케이션의 안정성 문제를 짧은 기간 동안 인식하지 못할 수 있으며, 그 결과 SLO를 낮출 수 있습니다.

업타임 및 기타 중요한 측정항목의 경우 목표를 100% 미만이되 100%에 가깝게 설정합니다. 서비스 소유자는 외부 계약 수준에 따라 대상을 설정하는 것뿐만 아니라 대부분의 사용자가 만족할 만한 최소 수준의 서비스 성능 및 가용성을 객관적으로 평가해야 합니다.

속도가 변경되면 시스템의 안정성에 영향을 줍니다. 하지만 빈번하게 조금씩 변경할 수 있으면 더 빠르고 더 나은 품질을 제공하는 데 도움이 됩니다. 고객 환경에 맞게 조정된, 달성 가능한 안정성 목표는 고객이 감당할 수 있는 최대 속도 및 변경 범위(기능 개발 속도)를 정의하는 데 도움이 됩니다.

고객 경험을 측정하고 측정 결과에 따라 목표를 정의할 수 없는 경우 경쟁력 있는 벤치마크 분석을 실행할 수 있습니다. 비교 가능한 경쟁사가 없다면 목표를 아직 정의할 수 없더라도 고객 경험을 측정합니다. 예를 들어 시스템 가용성 또는 고객에게 유의미한 트랜잭션 성공률을 측정합니다. 이 데이터로 소매 주문량 또는 고객지원 통화 및 티켓, 심각도와 같은 비즈니스 측정항목 또는 KPI의 상관관계를 파악할 수 있습니다. 일정 기간 동안 이러한 상관관계 연습을 사용하여 고객 행복의 합리적인 기준에 도달할 수 있습니다. 그 기준은 SLO입니다.

SLO를 반복적으로 개선

SLO를 설정한 대로 계속 두어서는 안 됩니다. 분기별 또는 연 1회 이상 SLO를 다시 검토하여 SLO가 사용자 만족도를 정확하게 반영하고 서비스 중단과 상관관계가 있는지 확인합니다. 리소스가 현재 비즈니스 요구사항과 새로운 중요한 사용자 여정을 충족하는지 확인합니다. 정기 검토 후 필요에 따라 SLO를 수정하고 보강합니다.

엄격한 내부 SLO 사용

외부 SLA보다 엄격한 내부 SLO를 사용하는 것이 좋습니다. SLA 위반 시 재무 크레딧 또는 고객 환불을 요구하는 경우가 많으므로 재무에 영향을 미치기 전에 문제를 해결해야 합니다.

비난 없는 사후 분석 프로세스 및 이슈 검토와 함께 더 엄격한 내부 SLO를 사용하는 것이 좋습니다. 자세한 내용은 아키텍처 센터 안정성 카테고리의 공동작업 이슈 관리 프로세스 빌드를 참조하세요.

오류 예산을 사용하여 개발 속도를 관리할 수 있습니다.

오류 예산은 특정 기간 동안 시스템의 안정성이 필요 이상인지 이하인지 여부를 알려줍니다. 오류 예산은 30일 등의 일정 기간 동안 100% – SLO로 계산됩니다.

오류 예산에 남은 용량이 있으면 계속해서 개선 또는 새로운 기능을 빠르게 실행할 수 있습니다. 오류 예산이 거의 소진된 경우에는 서비스 변경을 중단하거나 속도를 늦추고 안정성 기능 향상을 위해 엔지니어링 리소스를 투입합니다.

Google Cloud 관측 가능성에는 SLO 및 오류 예산을 설정하는 데 필요한 노력을 최소화하기 위한 SLO 모니터링이 포함됩니다. 이 서비스에는 SLO를 수동으로 구성하는 데 도움이 되는 그래픽 사용자 인터페이스, SLO의 프로그래매틱 방식 설정을 위한 API, 오류 예산의 소진율을 추적하기 위한 기본 제공 대시보드가 포함됩니다. 자세한 내용은 SLO 만들기를 참조하세요.

권장사항

아키텍처 프레임워크의 안내 사항을 사용자의 고유 환경에 적용하려면 다음 권장사항을 따르세요.

• 고객 중심의 SLI(예: 서비스 가용성 또는 지연 시간)를 정의하고 측정합니다.
• 외부 SLA보다 엄격한 고객 중심 오류 예산을 정의합니다. 프로덕션 중단과 같은 위반의 결과를 포함합니다.
• 지연 시간 SLI를 설정하여 가장 느린 응답을 감지하기 위한 이상점 값(예: 90번째 또는 99번째 백분위수)을 캡처합니다.
• 1년에 1회 이상 SLO를 검토하고 사용자 만족도 및 서비스 중단과 상관관계가 높은지 확인합니다.

다음 단계

다음 리소스로 안정성 목표를 정의하는 방법 자세히 알아보기:

• 인프라 및 애플리케이션에 관측 가능성 빌드(이 시리즈의 다음 문서)
• Coursera - SRE: 안정성 측정 및 관리
• SRE 도서 SLO 챕터 및 SLO 구현을 위한 SRE 통합문서
• SLI 측정항목 조정

시스템 설계, 운영 우수성, 보안, 개인 정보 보호, 규정 준수 등 아키텍처 프레임워크의 다른 카테고리를 살펴봅니다.

SLO 정의

이 문서는 온라인 서비스를 운영하는 팀이 서비스 수준 목표(SLO)를 이용하여 사이트 안정성 엔지니어링(SRE) 문화를 구축하고 채택하는 방법을 보여주는 2부로 구성된 시리즈 중 1부입니다. SLO는 서비스를 위한 안정성 목표 수준입니다.

Software as a service(SaaS)에서는 제품 개발 속도와 운영 안정성 사이에서 자연스럽게 갈등하게 됩니다. 시스템을 많이 변경할수록 시스템이 중단될 가능성이 커집니다. 모니터링 및 관측 도구를 사용하면 개발 속도를 높일 때 운영 안정성에 대한 확신을 유지할 수 있습니다. 하지만 애플리케이션 성능 관리(APM) 도구와 같은 도구도 중요하지만 이러한 도구의 가장 중요한 애플리케이션 중 하나는 바로 SLO를 설정하는 것입니다.

SLO를 올바르게 정의하면 팀은 안정성 저하 없이도 개발 속도를 높이는 데이터 기반의 운영 결정을 내릴 수 있습니다. 또한 SLO는 개발팀과 운영팀이 제품을 생성 및 반복(개발)과 시스템 무결성 유지(작업)라는 두 목표 사이에서 자연스럽게 갈등하는 것을 완화할 수 있는 서로 합의한 단일 목표에 부응하도록 개발과 운영을 조정할 수 있습니다.

SLO는 다른 SRE 방침과 함께 SRE 도서 및 SRE 통합문서에 자세히 설명되어 있습니다. 이 시리즈에서는 사용자가 손쉽게 SLO를 채택할 수 있도록 SLO를 이해하고 개발하는 과정을 단순화합니다. 이러한 문서를 읽고 이해한 후에는 도서에서 더 많은 내용을 찾아볼 수 있습니다.

이 시리즈는 조직에 SLO를 구현하는 명확한 방법을 보여줍니다.

• 이 문서에서는 SLO가 무엇인지와 서비스를 위한 SLO를 정의하는 방법을 검토합니다.
• SLO 채택에서는 워크로드 유형에 따른 다양한 SLO 유형, 이러한 SLO를 측정하는 방법, 이를 기반으로 알림을 개발하는 방법에 대해 설명합니다.

이 시리즈는 SRE, 운영팀, DevOps, 시스템 관리자, 온라인 서비스의 안정성과 신뢰성을 담당하는 기타 사용자를 대상으로 합니다. 이 시리즈는 사용자가 인터넷 서비스에서 웹브라우저 및 휴대기기와 통신하는 방법을 이해하고 웹 서비스를 모니터링, 배포, 문제 해결하는 방법에 대한 기본적인 지식이 있다고 가정합니다.

State of DevOps 보고서에는 소프트웨어 제공 성능을 향상시키는 기능이 나와 있습니다. 이 시리즈에서는 다음 기능을 설명합니다.

• 모니터링 및 관측 가능성
• 비즈니스 의사 결정용 모니터링 시스템
• 오류 사전 알림

SLO를 사용해야 하는 이유

SRE 문화를 구축할 때 SLO로 시작하는 이유는 무엇인가요? 간단히 말해 서비스 수준을 정의하지 않으면 고객이 서비스에 만족하는지 여부를 측정하기가 어렵습니다. 서비스를 개선할 수 있다고 해도 서비스 수준이 정의되지 않으면 어느 부분을 얼마나 개선해야 하는지 파악하기가 어렵습니다.

사용자에게 표시되는 여부에 관계없이 모든 서비스에 대해 별도의 SLO를 개발하고 싶을 수 있습니다. 예를 들어 흔히 범하는 실수는 사용자가 두 서비스(예: 프런트엔드 서비스 및 백엔드 Datastore)를 구분하지 않고 활용할 때 두 개 이상의 서비스를 별도로 측정하는 것입니다. 더 나은 접근 방식은 제품(서비스 모음)을 기반으로 하는 SLO를 개발하고 사용자의 가장 중요한 상호작용에 집중하는 것입니다.

따라서 효과적인 SLO를 개발하려면 중요한 사용자 여정(CUJ)이라고 하는 사용자의 서비스 상호작용을 이해하는 것이 좋습니다. CUJ는 사용자의 목표가 무엇인지, 사용자가 서비스를 사용하여 이러한 목표를 달성하는 방법을 고려합니다. CUJ는 서비스 경계를 고려하지 않고 고객의 관점에서 정의됩니다. CUJ가 충족되면 고객이 만족하게 되고 우수한 고객 만족도는 서비스 성공에 대한 주요 척도입니다.

서비스에 대한 고객 만족도의 주요 측면은 서비스의 안정성입니다. 서비스가 불안정하다면 서비스가 어떻게 작동하는지는 중요하지 않게 됩니다. 따라서 안정성이 모든 서비스의 가장 중요한 특징입니다. 안정성의 일반적인 측정항목은 기본적으로 시스템이 실행된 시간을 의미하는 업타임입니다. 하지만 더 유용하고 정확한 측정항목인 가용성을 사용하는 것이 좋습니다. 가용성은 시스템이 중단된 후 경과한 시간을 측정하는 것보다 정확한 방법으로 시스템이 가동 중인지에 대한 질문에 여전히 답합니다. 오늘날의 분산 시스템에서 서비스는 부분적으로 중단될 수 있으며 업타임이 잘 캡처하지 못하는 요소가 될 수 있습니다.

가용성은 종종 99.9% 가용성 또는 99.99% 가용성과 같이 9의 개수로 설명됩니다. 가용성 SLO를 측정하는 것은 시스템 신뢰성을 측정하는 가장 좋은 방법 중 하나입니다.

SLO는 운영 성공을 정의하는 것 외에도 어디에 리소스를 투자할지 선택하는 데 도움이 됩니다. 예를 들어 SRE 도서에서는 사용자가 엔지니어링하는 각 9로 인해 한계 유틸리티와 함께 비용 증가가 초래될 수 있다는 점을 말해줍니다. 일반적으로 가용성의 다음 자리 9를 달성하는 데 드는 비용이 이전 자리의 비용보다 10배나 더 많이 듭니다.

SLI 선택

SLO가 충족되었는지, 즉 성공적인지 확인하려면 측정이 필요합니다. 이러한 측정을 서비스 수준 지표(SLI)라고 합니다. SLI는 사용자가 고객에게 제공하는 특정 서비스의 수준을 측정합니다. 이상적으로 SLI는 허용되는 CUJ와 연결되어 있습니다.

최적의 측정항목 선택

SLI 개발의 첫 번째 단계는 초당 요청, 초당 오류, 큐 길이, 지정된 기간의 응답 코드 분포, 전송된 바이트 수와 같이 측정할 측정항목을 선택하는 것입니다.

이러한 측정항목은 일반적으로 다음과 같은 유형입니다.

• 카운터. 예를 들어 지정된 측정 지점에서 발생한 오류 수입니다. 이러한 유형의 측정항목은 늘릴 수 있지만 줄일 수는 없습니다.
• 분포. 예를 들어 지정된 기간에 특정한 측정 세그먼트를 채우는 이벤트 수입니다. 완료하는 데 0~10ms가 걸리는 요청 수, 11~30ms가 걸리는 요청 수, 31~100ms가 걸리는 요청 수를 측정할 수 있습니다. 결과는 각 버킷의 개수입니다(예: [0~10: 50], [11~30: 220], [31~100: 1,103]).
• 게이지. 예를 들어 시스템 측정 가능 부분의 실제 값(예: 큐 길이)입니다. 이 유형의 측정항목은 늘리거나 줄일 수 있습니다.

이러한 유형에 대한 자세한 내용은 Prometheus 프로젝트 문서와 Cloud Monitoring 측정항목 유형 ValueType 및 MetricKind를 참조하세요.

SLI에 대한 중요한 차이점은 모든 측정항목이 SLI인 것은 아니라는 점입니다. 실제로 SRE 워크북에는 다음 사항이 명시되어 있습니다(강조표시됨).

'... 일반적으로 SLI를 두 숫자의 비율로 처리하는 것이 좋습니다. 이 비율은 우수한 이벤트 수를 총 이벤트 수로 나눈 것입니다.'

'SLI의 범위는 0~100%입니다. 여기서 0%는 아무것도 작동하지 않음을, 100%는 아무런 문제가 없음을 의미합니다. 이 규모는 직관적이며 이 스타일은 오류 예산의 개념에 쉽게 부합한다는 사실을 발견했습니다.'

많은 소프트웨어 회사가 수백 또는 수천 개의 측정항목을 추적하며 일부 측정항목만 SLI로 인정됩니다. 그렇다면 우수한 이벤트 수와 전체 이벤트 수의 비율 이외에 어떤 것이 측정항목을 적합한 SLI의 자격이 있나요? 적합한 SLI 측정항목에는 다음과 같은 특성이 있습니다.

• 이 측정항목은 사용자 만족도와 직접적으로 관련이 있습니다. 일반적으로 서비스가 예상하는 방식으로 작동하지 않거나, 실패하거나, 느려지는 경우 사용자는 만족하지 못합니다. 이러한 측정항목을 기반으로 하는 모든 SLO는 고객 불만 신고 수, 문의 전화량, 소셜 미디어 감정, 에스컬레이션과 같은 사용자 만족도의 다른 신호를 SLI와 비교하여 검증될 수 있습니다. 측정항목이 사용자 만족도의 다른 측정항목에 해당되지 않으면 SLI로 사용하기에 적합한 측정항목이 아닐 수 있습니다.
• 측정항목 저하는 서비스 중단과 상관관계가 있습니다. 서비스 중단 중에 적합해 보이는 측정항목은 SLI에 대해 잘못된 측정항목입니다. 정상 작동 중에 부적합해 보이는 측정항목도 SLI에 대해 잘못된 측정항목입니다.
• 측정항목은 적합한 신호대 잡음비를 제공합니다. 많은 수의 거짓음성 또는 거짓양성을 유발하는 측정항목은 적합한 SLI가 아닙니다.
• 측정항목은 고객의 만족도를 통해 단조로우며 약 선형적으로 확장됩니다. 측정항목이 개선되면 고객 만족도도 향상됩니다.

다음 다이어그램에서 그래프를 살펴보세요. 서비스의 SLI로 사용할 수 있는 두 가지 측정항목은 시간 경과에 따라 그래프로 표시됩니다. 서비스가 저하되는 기간은 빨간색으로 강조표시되고 서비스가 양호한 기간은 파란색으로 강조표시됩니다.

부적합한 SLI의 경우 사용자의 불만족은 부정적인 이벤트(예: 서비스 성능 저하, 속도 저하, 중단)와 직접 대응하지는 않습니다. 또한 SLI는 사용자 만족도와는 독립적으로 변동합니다. 적합한 SLI의 경우 SLI 및 사용자 만족도는 상관관계가 있고, 다양한 만족도 수준이 명확하고, 관련 없는 변동이 훨씬 적습니다.

올바른 측정항목 수 선택

일반적으로 단일 서비스에는 여러 SLI가 있으며 특히 서비스가 여러 가지 유형의 작업을 수행하거나 여러 유형의 사용자에게 서비스를 제공하는 경우 더 그렇습니다. 예를 들어 쓰기 요청을 읽기 요청과 분리하는 것이 좋습니다. 이러한 요청은 서로 다른 방식으로 작동하기 때문입니다. 이 경우에는 각 서비스에 적합한 측정항목을 선택하는 것이 가장 좋습니다.

반대로 많은 서비스가 서비스 전반에서 유사한 유형의 작업을 수행하며, 이 경우 직접 비교할 수 있습니다. 예를 들어 온라인 마켓플레이스가 있는 경우 사용자가 홈페이지를 보거나 하위 카테고리 또는 상위 10개 목록을 보거나, 세부정보 페이지를 보거나, 항목을 검색할 수 있습니다. 이러한 각 작업에 대해 별도의 SLI를 개발하고 측정하는 대신 단일 SLI 카테고리(예: 서비스 탐색)로 결합할 수 있습니다.

실제로 고객의 기대는 유사한 카테고리의 작업 간에 크게 달라지지 않습니다. 고객의 만족도는 데이터가 프로모션 항목의 정적 목록에서 파생되는지 또는 대규모 데이터 세트에서 머신러닝 지원 검색의 동적 생성 결과인지의 여부와 관계없이 탐색 중인 데이터의 구조에 의존하지 않습니다. 고객 만족도는 '항목의 전체 페이지를 빠르게 보았나요?'라는 질문에 대한 답을 통해 수치화할 수 있습니다.

특정 서비스의 허용 범위를 정확하게 나타내기 위해 가능한 한 적은 수의 SLI를 사용하는 것이 좋습니다. 일반적으로 서비스에는 2~6개의 SLI가 있어야 합니다. SLI가 너무 적으면 중요한 신호를 놓칠 수 있습니다. SLI가 너무 많으면 대기하는 팀에서 한계 추가 유틸리티만으로 추적할 양이 너무 많아집니다. SLI는 프로덕션 상태에 대한 이해를 간소화하고 범위를 제공해야 합니다.

SLO 선택

SLO는 다음 값으로 구성됩니다.

• SLI. 예를 들어 HTTP 코드 200이 있는 응답 수와 총 응답 수의 비율입니다.
• 기간. 측정항목이 측정된 기간입니다. 이 기간은 캘린더 기반(예: 한 달의 첫째 날과 다음 달의 첫째 날) 또는 순환 기간(예: 지난 30일)입니다.
• 목표. 예를 들어 특정 기간에 충족될 것으로 예상되는 총 이벤트 대비 적합한 이벤트의 목표 비율(예: 99.9%)입니다.

SLO를 개발할 때는 기간과 목표를 정의하기 어려울 수 있습니다. 프로세스를 시작하는 한 가지 방법은 SLI를 식별하고 시간에 따라 차트를 작성하는 것입니다. 사용할 기간 및 목표를 결정할 수 없다면 SLO가 처음부터 완벽하지 않아도 된다는 점을 기억하세요. 고객의 만족도와 일치시키고 비즈니스 니즈를 충족하도록 SLO를 반복할 가능성이 있습니다. 먼저 한 달에 2개의 9(99.0%)로 시작해보세요.

배포, 중단, 일일 트래픽 패턴 같은 이벤트 중에 SLO 규정 준수를 추적하면 어떤 목표가 적절한지, 부적절한지, 무난한지에 대한 정보를 얻을 수 있습니다. 예를 들어 백그라운드 프로세스에서는 75% 성공을 적절하다고 정의할 수 있습니다. 하지만 사용자에게 표시되는 중요 작업의 경우 99.95%와 같이 더 엄격한 목표를 정할 수 있습니다.

물론 모든 사용 사례에 적용할 수 있는 단일 SLO는 없습니다. SLO는 다음과 같은 몇 가지 요인에 따라 달라집니다.

• 고객 기대치
• 워크로드 유형
• 제공, 실행, 모니터링을 위한 인프라
• 문제 도메인

이 시리즈의 2부인 SLO 채택에서는 도메인 독립적 SLO을 주로 다룹니다. 도메인 독립적 SLO(예: 서비스 가용성)는 높은 수준의 지표(예: 분당 판매되는 위젯)를 대체하지는 않습니다. 그러나 비즈니스 사용 사례와 관계없이 서비스가 작동하는지 여부를 확인하는 데 도움이 될 수 있습니다.

도메인 독립적 표시기는 질문과 답변을 주기도 합니다(예: '서비스를 사용할 수 있나요?' 또는 '서비스 속도가 충분히 빠른가요?'). 그 답은 가용성 및 지연 시간이라는 두 가지 요소를 고려하는 SLO에서 가장 많이 발견됩니다. 다음 용어로 SLO를 기술할 수 있습니다. 여기서 X = 99.9%이고 Y = 800ms입니다.

유효한 요청의 X%가 성공적이며 Yms보다 빠르게 성공합니다.

다음 단계

• 이러한 정의를 더 상세하게 살펴보고 다양한 워크로드 유형에 더 적합한 다른 SLI를 소개하는 SLO 채택을 읽어보세요.
• 다른 SRE 리소스를 참조하세요.
  • SRE 도서
  • SRE 워크북
• Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항을 살펴봅니다. Cloud 아키텍처 센터를 확인하세요.
• DevOps에 대한 리소스를 읽어보세요.
• 이 시리즈와 관련된 DevOps 기능을 자세히 알아보세요.
  • 모니터링 및 관측 가능성
  • 비즈니스 의사 결정용 모니터링 시스템
  • 오류 사전 알림
• DevOps 빠른 점검을 사용하여 업계와 비교되는 자신의 현재 상태를 파악하세요.

SLO 채택

이 문서에서는 다양한 유형의 일반적인 서비스 워크로드에 유용한 여러 서비스 수준 목표(SLO)를 정의합니다. 이 문서는 2부로 구성된 시리즈 중 2부입니다. 1부 SLO 정의에서는 SLO를 소개하고, SLO가 서비스 수준 지표(SLI)에서 파생되는 방식을 보여주고, 좋은 SLO의 조건을 설명합니다.

State of DevOps 보고서에는 소프트웨어 제공 성능을 향상시키는 기능이 나와 있습니다. 이러한 두 문서에서는 다음 기능을 설명합니다.

• 모니터링 및 관측 가능성
• 비즈니스 의사 결정용 모니터링 시스템
• 오류 사전 알림

측정 항목

도메인에 관계없이 많은 서비스가 공통 기능을 공유하고 일반 SLO를 사용할 수 있습니다. 일반 SLO에 대한 아래의 설명은 서비스 유형별로 구성되어 있으며 각 SLO에 적용되는 SLI에 대해 자세히 설명합니다.

요청 기반 서비스

요청 기반 서비스는 클라이언트(다른 서비스 또는 사용자)로부터 요청을 수신하고, 계산을 수행하고, 네트워크 요청을 백엔드로 보낸 후 클라이언트에게 응답을 반환합니다. 요청 기반 서비스에서 가장 자주 측정되는 지표는 가용성 및 지연 시간 SLI입니다.

SLI로서의 가용성

가용성 SLI는 서비스의 작동 여부를 나타냅니다. 가용성 SLI는 다음과 같이 정의됩니다.

성공적으로 처리된 유효한 요청 비율

먼저 유효한 용어를 정의해야 합니다. 기본 정의는 '길이가 0이 아님' 또는 '클라이언트-서버 프로토콜을 준수'일 수 있지만 유효한 용어의 의미를 정의하는 것은 서비스 소유자의 책임입니다. 유효성을 검사하는 일반적인 방법은 HTTP(또는 RPC) 응답 코드를 사용하는 것입니다. 예를 들어 HTTP 500 오류는 SLO로 포함되는 서버 오류로 간주되기도 하는 반면 400 오류는 그렇지 않은 클라이언트 오류입니다.

측정할 대상을 결정한 후에는 애플리케이션이 해당 코드를 원활하고 일관되게 사용하도록 시스템이 반환하는 모든 응답 코드를 검사해야 합니다. SLO에 오류 코드를 사용할 때는 코드가 사용자의 서비스 환경을 정확하게 나타내는지 물어보는 것이 중요합니다. 예를 들어 사용자가 재고가 없는 상품을 주문하려고 하면 사이트에서 오류가 발생하고 오류 메시지가 반환되는지 또는 유사한 제품을 제안하는지 물어볼 수 있습니다. SLO와 함께 사용하려면 오류 코드가 사용자의 기대치에 연결되어야 합니다.

개발자는 오류를 오용할 수 있습니다. 사용자가 일시적으로 재고가 없는 제품을 요청하는 경우 개발자가 실수로 오류를 반환할 수 있습니다. 하지만 실제로 시스템은 올바르게 작동하고 있으며 오류 상태가 아닙니다. 사용자가 원하는 상품을 구매할 수 없더라도 코드는 성공으로 반환되어야 합니다. 물론 이 서비스의 소유자는 제품의 재고가 없다는 것을 알아야 하지만 판매 불가능은 고객의 입장에서 오류가 아니므로 SLO로 포함되지 않습니다. 하지만 서비스가 데이터베이스에 연결하여 상품의 재고 상태를 파악할 수 없는 경우에는 오류 예산에 포함되는 오류입니다.

서비스가 더 복잡할 수 있습니다. 예를 들어 서비스가 비동기식 요청을 처리하거나 고객을 위한 장기 실행 프로세스를 제공할 수도 있습니다. 이러한 경우에는 다른 방식으로 가용성을 노출할 수 있습니다. 하지만 가용성은 성공적인 유효한 요청의 비율로 나타내는 것이 좋습니다. 고객의 워크로드가 요청대로 실행되는 시간(분)으로 가용성을 정의할 수 있습니다. 이 접근 방식을 가용성을 측정하는 '양호 시간(분)' 방식이라고도 합니다. 가상 머신의 경우 SSH를 통해 VM에 액세스할 수 있는 VM을 처음 요청한 후에 분 단위로 가용성을 측정할 수 있습니다.

SLI로서의 지연 시간

지연 시간 SLI(속도라고도 함)는 서비스가 충분히 빠른지 여부를 나타냅니다. 지연 시간 SLI는 가용성과 유사하게 정의됩니다.

임곗값보다 빨리 처리한 유효한 요청 비율

지정된 요청 유형에 대해 타이머가 시작되는 시점과 중지되는 시점의 차이를 계산하여 지연 시간을 측정할 수 있습니다. 핵심은 지연 시간에 대한 사용자의 인식입니다. 일반적인 함정은 지연 시간을 측정할 때 너무 정확하려고 하는 것입니다. 실제로 사용자는 100밀리초(ms)와 300밀리초(ms) 새로고침의 차이를 구분할 수 없으며 300밀리초(ms)와 1,000밀리초(ms) 사이의 어느 지점이나 수용할 수 있을 것입니다.

대신 다음 프로세스처럼 사용자가 계속 집중할 수 있는 활동 중심 측정항목을 개발하는 것이 좋습니다.

• 대화형: 사용자가 요소를 클릭한 후 결과를 기다리는 시간으로 1,000ms입니다.
• 쓰기: 기본 분산 시스템 변경 시 1,500ms입니다. 시스템에서는 이 시간을 느리다고 간주하지만 대부분 사용자는 수용합니다. 측정항목에서는 쓰기와 읽기를 명시적으로 구분하는 것이 좋습니다.
• 백그라운드: 데이터의 정기적인 새로고침 또는 다른 비동기식 요청과 같이 사용자에게 표시되지 않는 작업의 경우 5,000ms입니다.

지연 시간은 일반적으로 분포로 측정됩니다(이 시리즈의 1부에 있는 SLI 선택 참조). 분포를 사용하여 다양한 백분위수를 측정할 수 있습니다. 예를 들어 이전 99번째 백분위수보다 느린 요청 수를 측정할 수 있습니다. 이 경우 이전의 분포를 검사하여 설정된 이 임곗값보다 더 빠른 이벤트를 적합한 이벤트로 간주합니다. 제품 요구사항에 따라 이 임곗값을 설정할 수도 있습니다. 여러 지연 시간 SLO도 설정할 수도 있습니다(예: 일반적인 지연 시간과 꼬리 지연 시간 비교).

평균(또는 중앙값) 지연 시간만 SLI로 사용하지 않는 것이 좋습니다. 중앙값 지연 시간이 너무 느리면 사용자의 절반이 이미 불만족스러워한 것입니다. 즉, 장기적인 오류 예산에 대한 실제 위협을 발견하기 전에 며칠 동안 잘못된 지연 시간이 발생할 수 있습니다. 따라서 꼬리 지연 시간(95번째 백분위수) 및 중앙값 지연 시간(50번째 백분위수)에 대한 SLO를 정의하는 것이 좋습니다.

ACM 문서 Metrics That Matter에서 벤자민 트레이너 슬로스는 다음과 같이 말합니다.

"제 경험칙에 따르면... 일반적으로 99번째 백분위수 지연 시간은 중앙값 지연 시간의 3~5배를 초과해서는 안 된다."

트레이너 슬로스는 이렇게 덧붙였습니다.

"서비스의 50번째, 95번째, 99번째 백분위수 지연 시간 측정값은 각각 개별적으로 가치가 있으며 각 값을 중심으로 SLO를 이상적으로 설정할 것이다."

이전 백분위수를 기준으로 지연 시간 임곗값을 결정한 다음 각 버킷에 속하는 요청 수를 측정하는 것이 좋습니다. 자세한 내용은 이 문서 뒷부분의 지연 시간 알림 섹션을 참조하세요.

SLI로서의 품질

품질은 종속 항목이 느리거나 사용할 수 없는 경우 이를 저하시켜 정상적으로 실패하도록 설계된 복잡한 서비스에 유용한 SLI입니다. 품질 SLI는 다음과 같이 정의됩니다.

서비스를 저하시키지 않고 제공된 유효한 요청 비율

예를 들어 웹페이지는 하나의 Datastore에서 기본 콘텐츠를 로드하고 100개의 다른 서비스와 Datastore에서 선택적인 보조 애셋을 로드할 수 있습니다. 하나의 선택적 서비스가 중단되거나 너무 느린 경우 웹페이지는 여전히 보조 요소 없이 페이지를 렌더링할 수 있습니다. 성능이 저하된 응답(즉, 하나 이상의 백엔드 서비스 응답이 누락된 응답)을 측정하여 잘못된 요청의 비율을 보고할 수 있습니다. 사용자에게 단일 백엔드에서 응답이 없거나 여러 백엔드에서 응답이 누락된 경우를 추적할 수도 있습니다.

데이터 처리 서비스

일부 서비스는 사용자 요청에 응답하도록 빌드되지 않고, 대신에 입력에서 데이터를 사용하고 해당 데이터를 처리하여 출력을 생성하도록 빌드됩니다. 이러한 서비스의 중간 단계 성능은 최종 결과만큼 중요하지 않습니다. 이러한 서비스에서 가장 강력한 SLI는 지연 시간과 가용성이 아니라 최신 상태, 적용 범위, 정확성, 처리량입니다.

SLI로서의 최신 상태

최신 상태 SLI는 다음과 같이 정의됩니다.

임곗값보다 최근에 업데이트된 유효한 데이터 비율

예를 들어 일괄 처리 시스템에서는 처리 실행이 주어진 출력에서 성공적으로 완료된 이후 경과된 시간으로 최신 상태를 측정할 수 있습니다. 더 복잡한 시스템이나 실시간 처리 시스템에서는 파이프라인에서 처리된 가장 최근 레코드의 기간을 추적할 수 있습니다.

예를 들어 실시간으로 지도 타일을 생성하는 온라인 게임을 생각해 보세요. 사용자는 지도 타일이 얼마나 빨리 생성되는지는 알아차리지 못할 수 있지만 맵 데이터가 누락되거나 최신 상태가 아닌 경우에는 알아차릴 수 있습니다.

또는 전자상거래 웹사이트에서 '상품 재고 X개 있음' 메시지를 생성하기 위해 재고 추적 시스템에서 레코드를 읽는 시스템을 고려해 보겠습니다. 최신 상태 SLI를 다음과 같이 정의할 수 있습니다.

지난 1분 이내에 새로고침한 재고 정보를 사용한 조회 비율

또한 최신이 아닌 데이터를 제공하는 측정항목을 사용하여 품질 SLI 정보를 제공할 수도 있습니다.

SLI로서의 적용 범위

적용 범위 SLI는 다음과 같이 정의됩니다.

성공적으로 처리된 유효한 데이터 비율

적용 범위를 정의하려면 먼저 입력을 유효한 것으로 수락할지 아니면 건너뛸지 결정합니다. 예를 들어 입력 레코드가 손상되었거나 길이가 0이며 처리될 수 없는 경우 이 레코드를 시스템을 측정하기에 유효하지 않다고 간주할 수 있습니다.

다음으로 유효한 레코드 수를 계산합니다. 이 단계는 간단한 count() 메서드 또는 다른 메서드를 사용하여 수행할 수 있습니다. 이 숫자는 총 레코드 수입니다.

마지막으로 적용 범위에 대한 SLI를 생성하기 위해 성공적으로 처리한 레코드 수를 계산하고 총 유효한 레코드 수와 비교합니다.

SLI로서의 정확성

정확성 SLI는 다음과 같이 정의됩니다.

올바른 출력을 생성한 유효한 데이터 비율

경우에 따라 출력 처리의 유효성을 검사하는 데 사용할 수 있는 출력의 정확성을 확인하는 여러 방법이 있습니다. 예를 들어 이미지를 회전하거나 색상을 지정하는 시스템은 0바이트 이미지나 길이 또는 너비가 0인 이미지를 생성해서는 안 됩니다. 이 검증 로직을 처리 로직 자체에서 분리하는 것이 중요합니다.

정확성 SLI를 측정하는 한 가지 방법은 알려진 올바른 출력을 가지는 데이터 즉, 알려진 정상 테스트 입력 데이터를 사용하는 것입니다. 입력 데이터는 사용자 데이터를 나타내야 합니다. 다른 경우에는 이전의 이미지 회전 예시와 같이 출력에 대해 수학적 또는 논리적 검사를 수행할 수 있습니다. 또 다른 예시는 트랜잭션 이전의 잔액과 트랜잭션 이후 잔액의 차이가 트랜잭션 자체의 값과 일치하는지를 확인하여 트랜잭션이 유효한지 확인하는 결제 시스템입니다.

SLI로서의 처리량

처리량 SLI는 다음과 같이 정의됩니다.

데이터 처리 속도가 임곗값보다 빠른 데이터의 비율

예를 들어 데이터 처리 시스템에서는 특정 작업에 대한 단일 지연 시간 측정보다 처리량이 사용자 만족도에 더 크게 반영되는 경우가 많습니다. 예를 들어 각 입력의 크기가 크게 다른 경우 작업이 허용 속도로 진행되면 각 요소가 완료되는 데 걸리는 시간을 비교하는 것은 별 의미가 없을 수 있습니다.

초당 바이트 수는 데이터 세트의 크기에 관계없이 데이터를 처리하는 데 걸리는 작업량을 측정하는 일반적인 방법입니다. 하지만 처리 비용과 관련하여 대략 선형적으로 확장되는 측정항목은 모두 작동할 수 있습니다.

예상 처리 속도를 기준으로 데이터 처리 시스템의 파티션을 나누거나, 우선순위가 높은 입력을 먼저 처리하고 낮은 우선순위 입력이 큐에 추가되도록 서비스 품질 시스템을 구현하는 것도 좋은 방법입니다. 어느 쪽이든 이 섹션에 정의된 처리량을 측정하면 시스템이 예상대로 작동하는지 확인할 수 있습니다.

예약된 실행 서비스

Kubernetes 크론 작업 같이 일정한 간격으로 작업을 수행해야 하는 서비스의 경우 편향 및 실행 기간을 측정할 수 있습니다. 다음은 예약된 Kubernetes 크론 작업의 예시입니다.

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "0 * * * *"

SLI로서의 편향

편향 SLI는 다음과 같이 정의됩니다.

예상 시작 시간의 허용 가능한 기간 안에 시작되는 실행 비율

편향은 작업이 시작되도록 예약된 시점과 실제 시작되는 시점 사이의 시간 차이를 측정합니다. 예를 들어 매시간 0분에 시작하도록 설정된 Kubernetes 크론 작업이 정시에서 3분 후에 시작된다면 편향은 3분입니다. 작업이 일찍 실행되면 음의 편향이 있는 것입니다.

양호한 편향을 정의하는 해당 허용 범위를 사용하여 편향을 시간 경과에 따른 분포로 측정할 수 있습니다. SLI를 결정하려면 양호한 범위 내에 있는 실행 수를 비교합니다.

SLI로서의 실행 기간

실행 기간 SLI는 다음과 같이 정의됩니다.

허용 가능한 기간 내에 완료되는 실행 비율

실행 기간은 작업이 완료되는 데 걸리는 시간입니다. 특정한 실행에서 일반적인 장애 모드는 실제 기간이 예약된 기간을 초과하는 것입니다.

한 가지 흥미로운 경우는 이 SLI를 적용하여 끝이 없는 작업을 포착하는 것입니다. 이러한 작업이 완료되지 않았으므로 작업이 완료될 때까지 기다리는 대신 특정 작업에 소요된 시간을 기록해야 합니다. 이 방식은 최악의 시나리오에서도 작업 완료에 걸리는 시간에 대한 정확한 분포를 제공합니다.

편향과 마찬가지로 실행 기간을 분포로 추적하고 적합한 이벤트에 대한 허용 상한 및 하한을 정의할 수 있습니다.

다른 시스템의 측정항목 유형

다른 많은 워크로드에는 SLI 및 SLO를 생성하는 데 사용할 수 있는 자체 측정항목이 있습니다. 다음 예시를 고려하세요.

• 스토리지 시스템: 내구성, 처리량, 첫 번째 바이트까지의 시간, blob 가용성
• 미디어/동영상: 클라이언트 재생 지속성, 재생 시작 시간, 트랜스코딩 지연 실행 완료
• 게임: 활성 플레이어 매칭 시간, 지도 생성 시간

측정 방법

무엇을 측정할 것인지 파악한 후 측정을 수행할 방법을 결정할 수 있습니다. SLI를 수집하는 방법은 여러 가지입니다.

서버 측 로깅

SLI를 생성하는 방법

요청의 서버 측 로그 또는 처리된 데이터를 처리합니다.

고려사항

장점:

• 기존 로그를 다시 처리하여 이전 SLI 레코드를 백필할 수 있습니다.
• 교차 서비스 세션 식별자는 여러 서비스에서 복잡한 사용자 여정을 재구성할 수 있습니다.

단점:

• 서버에 도달하지 않은 요청은 기록되지 않습니다.
• 서버 충돌을 일으키는 요청은 기록되지 않습니다.
• 로그를 처리하는 데 시간이 걸리면 SLI의 비활성 상태를 초래하여 운영 응답의 데이터가 불충분할 수 있습니다.
• 로그 처리를 위한 코드를 작성하면 오류가 발생하기 쉽고 시간이 오래 걸릴 수 있습니다.

구현 방법 및 도구:

• BigQuery
• Dataflow, Apache Spark
• Splunk

애플리케이션 서버 측정항목

SLI를 생성하는 방법

사용자의 요청을 처리하거나 데이터를 처리하는 코드에서 SLI 측정항목 내보냅니다.

고려사항

장점:

• 코드에 새 측정항목을 추가하는 것은 일반적으로 빠르고 저렴합니다.

단점:

• 애플리케이션 서버에 도달하지 않는 요청은 기록되지 않습니다.
• 다중 서비스 요청은 추적하기 어려울 수 있습니다.

구현 방법 및 도구:

• Cloud Monitoring
• Prometheus
• 타사 APM 제품

프런트엔드 인프라 측정항목

SLI를 생성하는 방법

부하 분산 인프라에서 측정항목을 활용합니다(예: Google Cloud의 글로벌 레이어 7 부하 분산기).

고려사항

장점:

• 측정항목과 이전 데이터가 이미 존재하기 때문에 엔지니어링 작업을 줄일 수 있습니다.
• 측정은 고객과 가장 가까우면서도 아직 서비스 인프라 내에 있는 지점에서 이루어집니다.

단점:

• 데이터 처리 SLI에는 사용할 수 없습니다.
• 대략적인 다중 요청 사용자 여정만 가능합니다.

구현 방법 및 도구:

• Cloud Monitoring
• CDN/LB 측정항목 또는 Reporting API(Cloudflare, Akamai, Fastly)

합성 클라이언트 또는 데이터

SLI를 생성하는 방법

일정한 간격으로 조작된 요청을 보내고 응답을 검사하는 클라이언트를 빌드합니다. 데이터 처리 파이프라인의 경우 알려진 유효한 합성 입력 데이터를 만들고 출력을 검증합니다.

고려사항

장점:

• 다중 요청 사용자 여정의 모든 단계를 측정합니다.
• 인프라 외부에서 요청을 보내면 SLI에서 더 많은 전체 요청 경로가 캡처됩니다.

단점:

• 합성 요청으로 사용자 환경을 추정하므로 거짓양성 또는 거짓음성이 나올 수 있습니다.
• 모든 특수한 사례를 처리하는 것이 어렵고 통합 테스트로 이어질 수 있습니다.
• 높은 안정성 목표로 인해 정확한 측정을 위한 빈번한 프로브가 필요합니다.
• 프로브 트래픽이 실제 트래픽을 분산시킬 수 있습니다.

구현 방법 및 도구:

• Cloud Monitoring 업타임 체크
• 오픈소스 솔루션:
  • Cloudprober
  • blackbox_exporter
• 공급업체 솔루션:
  • Catchpoint Synthetic Monitoring
  • New Relic Synthetics
  • Datadog Synthetic Monitoring

클라이언트 계측

SLI를 생성하는 방법

사용자가 상호작용하는 클라이언트에 관측 기능을 추가하고 SLI를 추적하는 서비스 인프라에 이벤트를 다시 로깅합니다.

고려사항

장점:

• 사용자 환경을 가장 정확하게 측정할 수 있습니다.
• CDN 또는 결제 서비스 제공 업체와 같은 타사의 안정성을 수치화할 수 있습니다.

단점:

• 클라이언트 로그 수집 및 처리 지연 시간은 SLI가 운영 응답을 트리거하는 데 적합하지 않도록 합니다.
• SLI 측정에는 잠재적으로 직접적인 제어를 할 수 없는 다양한 변수가 포함됩니다.
• 클라이언트에 계측을 빌드하려면 많은 엔지니어링 작업이 필요합니다.

구현 방법 및 도구:

• Google 애널리틱스, Firebase
• 사용자 분석: Amplitude 및 기타 도구
• 모바일/프런트엔드 모니터링: New Relic Browser, Raygun Real User Monitoring, Sentry
• 기록하고 추적할 커스텀 클라이언트 및 커스텀 서버

측정 방법 선택

이상적으로는 고객 서비스 환경과 가장 근접하며 최소한의 노력이 요구되는 측정 방법을 선택해야 합니다. 이를 위해 위 표에 나온 방법을 조합하여 사용해야 할 수도 있습니다. 다음은 시간이 지남에 따라 구현할 수 있는 권장되는 접근 방식을 큰 노력을 들여야 하는 순으로 나열한 것입니다.

1. 애플리케이션 서버 내보내기 및 인프라 측정항목 사용. 일반적으로 이러한 측정항목은 즉시 액세스할 수 있으며 값을 빠르게 제공합니다. 일부 APM 도구에는 기본 SLO 도구가 포함되어 있습니다.
2. 클라이언트 계측 사용. 기존 시스템에는 일반적으로 내장된 최종 사용자 클라이언트 계측이 없으므로 계측을 설정하려면 상당한 투자가 필요할 수 있습니다. 그러나 클라이언트 계측을 제공하는 APM 제품군 또는 프런트엔드 프레임워크를 사용하면 고객의 만족도에 대한 유용한 정보를 빠르게 얻을 수 있습니다.
3. 로그 처리 사용. 서버 내보내기 또는 클라이언트 계측은 구현할 수 없지만 로그가 있는 경우에는 로그 처리가 가장 좋은 값이 될 수 있습니다. 또 다른 접근 방식은 내보내기를 일부 SLI(예: 즉시 가용성)의 즉각적인 소스로 사용하고 로그 처리를 장기 신호(예: 후반부의 SLO 및 알림 섹션에서 다루게 될 느린 소진 알림)로 사용하여 내보내기와 로그 처리를 조합하는 것입니다.
4. 합성 테스트 구현. 고객이 서비스를 사용하는 방법에 대한 기본 사항을 이해했으면 서비스 수준을 테스트합니다. 예를 들어 정상 데이터와 함께 계정을 테스트하고 질의할 수 있습니다. 이 테스트는 트래픽이 적은 서비스의 경우와 같이 쉽게 관찰할 수 없는 장애 모드를 강조표시하는 데 도움이 될 수 있습니다.

목표 설정

목표를 설정하는 가장 좋은 방법 중 하나는 SLO가 무엇이고 SLO를 어떻게 개발했는지 설명하는 공유 문서를 만드는 것입니다. 사용자의 팀은 시간 경과에 따라 SLO를 구현하고 반복하면서 문서를 반복할 수 있습니다.

비즈니스 소유자, 제품 소유자, 경영진이 이 문서를 검토하는 것이 좋습니다. 이러한 이해관계자는 서비스 기대치와 제품의 안정성 절충에 대한 정보를 제공할 수 있습니다.

회사에서 가장 중요한 중요 사용자 여정(CUJ)의 경우 SLO를 개발하기 위한 템플릿은 다음과 같습니다.

1. SLI 사양을 선택합니다(예: 가용성 또는 최신 상태).
2. SLI 사양을 구현하는 방법을 정의합니다.
3. 계획을 검토하여 CUJ가 포함되었는지 확인합니다.
4. 과거 성능 또는 비즈니스 요구사항에 따라 SLO를 설정합니다.

CUJ는 단일 서비스나 단일 개발팀 또는 조직으로 제한되지 않아야 합니다. 사용자가 99.5%에서 작동하는 수백 가지 마이크로서비스를 활용하지만 아무도 엔드 투 엔드 가용성을 추적하지 않으면 고객은 만족스럽지 않을 것입니다.

부하 분산기, 프런트엔드, 혼합기, 백엔드, 데이터베이스의 순서대로 작동하는 5개의 서비스를 활용하는 쿼리가 있다고 가정해 봅니다.

각 구성 요소의 가용성이 99.5%인 경우 사용자에게 표시되는 가장 낮은 가용성은 다음과 같습니다.

99.5% * 99.5% * 99.5% * 99.5% * 99.5% = 97.52%

이는 5가지 서비스 중 하나가 실패하면 전체 시스템이 실패하므로 사용자에게 표시되는 가장 낮은 가용성입니다. 이는 중간 재시도, 캐시 또는 큐와 같은 복원력 요소 없이 사용자 요청을 처리하기 위해 스택의 모든 레이어를 항상 즉시 사용할 수 있어야 하는 경우에만 해당됩니다. 이와 같이 서비스 간에 밀접한 결합이 있는 시스템은 부적절한 설계이며 마이크로서비스 모델을 무용지물로 만듭니다.

단편적으로(서비스별) 분산 시스템의 SLO에 대한 성능을 측정하는 것은 고객의 경험을 정확하게 반영하지 않으며 과도하게 해석될 수 있습니다.

그 대신에 프런트엔드의 SLO를 기준으로 성능을 측정하여 사용자 환경을 파악해야 합니다. 구성요소 서비스가 실패하여 자동으로 쿼리를 성공적으로 재시도하든 사용자의 쿼리가 여전히 성공하든 사용자는 신경 쓰지 않습니다. 내부 서비스를 공유한 경우 이러한 서비스는 SLO를 기준으로 성능을 별도로 측정할 수 있으며 사용자에게 표시되는 서비스는 고객 역할을 합니다. 이러한 SLO는 서로 개별적으로 처리해야 합니다.

스마트 재시도, 캐싱, 큐에 추가 등의 복원력 요소를 활용하여 가용성이 낮은 서비스(예: 99.9%) 위에 가용성이 높은 서비스(예: 99.99%)를 구축할 수 있습니다.

일반적으로 통계에 대한 실무 지식이 있는 사용자라면 누구든지 기본 서비스 또는 조직 레이아웃을 이해하지 않고도 SLO를 읽고 이해할 수 있어야 합니다.

SLO 워크시트 예시

SLO를 개발할 때 반드시 다음을 수행해야 합니다.

• SLI가 이벤트, 성공 기준, 성공 또는 실패를 기록하는 위치와 방법을 지정하는지 확인합니다.
• 양호한 이벤트의 비율에 따라 SLI 사양을 정의합니다.
• SLO가 목표 수준과 측정 기간을 모두 지정했는지 확인합니다.
• 관심을 보이는 당사자가 절충사항 및 문제점을 이해할 수 있도록 접근 방식의 장단점을 설명합니다.

예를 들어 다음 SLO 워크시트를 살펴보겠습니다.

CUJ: 홈페이지 로드
SLI 유형: 지연 시간 SLI 사양: 100ms 미만으로 처리되는 홈페이지 요청 비율 SLI 구현: 100ms 이내에 처리되는 홈페이지 요청의 비율이며 서버 로그의 지연 시간 열에서 측정합니다. (단점: 이 측정은 백엔드에 도달하지 못한 요청을 무시합니다.) 가상 머신에서 실행되는 브라우저에서 자바스크립트를 실행하는 프로브에서 측정한 100ms 이내에 처리되는 홈페이지 요청의 비율입니다. (장점 및 단점: 이 측정은 요청이 네트워크에 도달하지 못할 때 오류를 포착하지만 일부 사용자에게만 영향을 미치는 문제는 놓칠 수 있습니다.) SLO: 지난 28일 동안 99%의 홈페이지 요청이 100ms 이내에 처리됨

참고: 목표 수준에 대해 팀에서 합의할 수 없는 경우에는 일부 수준을 선택하고 6개월 후에 재검토하세요. 수를 잘못 선택하는 것이 아예 선택하지 않는 것보다 낫습니다.

다음 단계

• Google 고객 신뢰도 엔지니어링팀에서 개발한 워크숍인 SLO의 기술을 읽어보세요.
• SLO 빌드에 대한 온라인 과정인 사이트 안정성 엔지니어링: 안정성 측정 및 관리를 시도해 보세요.
• 사이트 안정성 엔지니어링: SLO 구현을 읽어보세요.
• 서비스 모니터링 개념을 읽어보세요.
• Cloud Monitoring으로 SLO 개발을 읽어보세요.
• Google의 Professional Services Organization(PSO)에서 개발한 탄력적인 SLO Generator를 사용해 보세요.
• Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항을 살펴봅니다. Cloud 아키텍처 센터를 확인하세요.
• DevOps에 대한 리소스를 읽어보세요.
• 이 시리즈와 관련된 DevOps 기능을 자세히 알아보세요.
  • 모니터링 및 관측 가능성
  • 비즈니스 의사 결정용 모니터링 시스템
  • 오류 사전 알림
• DevOps 빠른 점검을 사용하여 업계와 비교되는 자신의 현재 상태를 파악하세요.

용어

이 문서에서는 Google Cloud 아키텍처 프레임워크: 신뢰성 섹션에 사용된 SLO 관련 용어에 대한 일반적인 정의를 제공합니다.

• 서비스 수준: 특정 서비스가 사용자의 예상 작업을 얼마나 잘 수행했는지에 대한 척도입니다. 이 척도를 사용자 만족도와 관련하여 설명할 수 있으며, 서비스에서 수행하는 작업과 사용자가 예상하는 서비스의 작업이나 알려진 수행 가능한 작업에 따라 다양한 방법으로 이를 측정할 수 있습니다.

  예: '사용자는 서비스가 사용 가능하며 속도가 빠를 것으로 예상합니다.'

• 중요한 사용자 여정(CUJ): 단일 목표(예: 단일 클릭 또는 다단계 파이프라인)를 달성하기 위한 사용자와 서비스의 일련의 상호작용입니다.

  예: '사용자가 결제 버튼을 클릭한 다음 장바구니가 처리되고 영수증이 반환될 때까지 기다립니다.'

• 서비스 수준 지표(SLI): 서비스 수준을 정량적으로 측정할 수 있는 사용자 만족도 기준입니다. 즉, 서비스 수준을 측정하려면 해당 서비스 수준(예: 서비스 가용성)으로 사용자 만족도를 나타내는 표시기를 측정해야 합니다. SLI는 서비스가 개선되거나 저하되는 과정에서 시간이 지남에 따라 변하는 그래프의 선으로 간주할 수 있습니다. 이는 일반적으로 특정 단위가 없는 백분율로 표시되는 "양호"/"총합" 사이의 비율을 나타냅니다. 이러한 백분율을 일관적으로 사용함으로써 구현 방법에 대한 전문적인 지식 없이도 팀이 SLI를 파악할 수 있습니다.

  예: '최근 10분 동안의 성공한 요청 수를 최근 10분 동안의 모든 유효한 요청 수로 나눈 값을 측정합니다.'

• 서비스 수준 목표 (SLO): 서비스가 측정된 SLI에 비해 대부분의 시간을 달성할 것으로 예상하는 수준입니다.

  예: "서비스 응답이 14일 동안 측정된 모든 유효한 요청의 95%에 대해 400밀리초(ms)보다 빠릅니다."

  

• 서비스수준계약(SLA): SLO를 충족하지 못한 경우 발생하는 상황을 설명합니다. 일반적으로 SLA는 제공업체와 고객 간의 법적 계약이며 보상 조건을 포함할 수도 있습니다. SRE에 대한 기술적 토론에서는 이 조건이 기피되기도 합니다.

  예: '서비스가 한 달 동안 99.95%의 가용성을 제공하지 않는 경우 서비스 제공업체는 규정이 위반되는 1분마다 고객에게 보상을 제공합니다.'

• 오류 예산: SLO를 위반하기 전에 견딜 수 있는 시간 또는 부정적인 이벤트의 수입니다. 이 측정값은 비즈니스에서 예상하거나 허용할 수 있는 오류의 수를 나타냅니다. 오류 예산은 위험한 결정을 내리는 데 도움이 됩니다.

  예: 'SLO를 99.9% 사용할 수 있는 경우 요청의 0.1%를 허용하여 이슈, 사고 또는 실험을 통해 오류를 처리합니다.'

SLO 및 알림

Google Cloud 아키텍처 프레임워크: 신뢰성 섹션의 이 문서에서는 SLO 관련 알림에 대해 자세히 설명합니다.

SLO 등의 새로운 관측 시스템을 도입할 때 이 시스템으로 이전 시스템을 완전히 교체하는 것은 잘못된 접근 방법입니다. 오히려 SLO를 보완적인 시스템으로 여겨야 합니다. 예를 들어 기존 알림을 삭제하는 대신 여기에 설명된 SLO 알림과 함께 알림을 실행하는 것이 좋습니다. 이 접근 방식을 사용하면 SLO 알림을 예측할 수 있는 기존 알림, SLO 알림과 함께 실행되는 알림, 실행되지 않는 알림을 확인할 수 있습니다.

SRE의 원칙은 원인이 아닌 증상을 기반으로 알리는 것입니다. 본질적으로 SLO는 증상을 측정한 것입니다. SLO 알림을 채택하면 증상 알림이 다른 알림과 함께 실행되는 것을 확인할 수 있습니다. 기존 오류 기반 알림이 SLO 또는 증상 없이 실행되는 경우 이러한 알림을 완전히 끄거나, 티켓팅 알림으로 바꾸거나, 나중에 참조용으로 로깅하는 것이 좋습니다.

자세한 내용은 SRE 워크북 5장을 참조하세요.

SLO 소진율

SLO의 소진율은 서비스 중단으로 얼마나 빨리 사용자가 오류에 노출되고 오류 예산을 소진하는지에 대한 측정값입니다. 소진율을 측정하면 서비스가 SLO를 위반할 때까지의 시간을 결정할 수 있습니다. SLO 소진율에 기반한 알림은 유용한 접근 방법입니다. SLO는 기간을 기준으로 하며 이 기간은 몇 주나 몇 개월까지 길어질 수도 있습니다. 하지만 실제로 위반이 발생하기 전에 SLO 위반으로 이어질 조건을 빠르게 감지하는 것이 목표입니다.

다음 표에서는 초당 쿼리 수(QPS)가 일정하다는 가정하에 지정된 기간 동안 요청이 100% 실패하는 경우 목표를 초과하는 데 걸리는 시간을 보여줍니다. 예를 들어 30일 동안 99.9%의 SLO를 측정한 경우 30일 동안 43.2분의 전체 다운타임을 견딜 수 있습니다. 예를 들어 다운타임은 모두 한 번에 발생하거나 여러 이슈에 걸쳐 간격을 두고 발생할 수 있습니다.

목표	90일	30일	7일	1일
90%	9일	3일	16.8시간	2.4시간
99%	21.6시간	7.2시간	1.7시간	14.4분
99.9%	2.2시간	43.2분	10.1분	1.4분
99.99%	13분	4.3분	1분	8.6초
99.999%	1.3분	25.9초	6초	0.9초

실제로는 높은 성공율을 달성하고 싶다면 100% 중단 이슈를 감당할 수 없습니다. 그러나 많은 분산 시스템은 부분적으로 실패하거나 단계적으로 저하시킬 수 있습니다. 그런 경우에도 이러한 실패에 사람이 개입해야 하는지 여전히 알고 싶을 수 있으며 SLO 알림은 이를 판단할 방법을 제공합니다.

알림 시기

중요한 질문은 SLO 소진율을 기반으로 언제 조치를 취할 것인지입니다. 일반적으로 24시간 이내에 오류 예산이 소진된다면 즉시 이 문제를 해결하기 위해 다른 사람을 호출해야 합니다.

실패율을 판단하는 것이 항상 간단한 것은 아닙니다. 잠시 동안은 일련의 작은 오류가 두려울 수 있으나 사실은 단기적이고 SLO에 미치는 영향도 미미할 수 있습니다. 마찬가지로 시스템이 오랫동안 미세하게 손상되었다면 이런 오류가 SLO 위반으로 이어질 수도 있습니다.

일반적으로 팀은 이러한 신호에 반응하여 주어진 기간 동안 오류 예산을 거의 대부분 소비합니다(그러나 초과하지는 않음). 너무 많은 금액을 소비하면 SLO를 위반하게 됩니다. 너무 적은 금액을 소비하면 위험을 충분히 감수하지 않거나 긴급 대응팀을 혹사시키고 있는지도 모릅니다.

언제 인간이 개입해야 할 정도로 시스템이 망가졌는지 판단할 방법이 필요합니다. 다음 섹션에서는 이 질문에 대한 몇 가지 접근 방식을 설명합니다.

빠른 소진

SLO 소진의 한 가지 유형은 빠른 SLO 소진입니다. 이는 오류 예산을 빠르게 소진하고 SLO 위반을 방지하기 위해 사용자의 개입을 요구하기 때문입니다.

서비스가 일반적으로 초당 쿼리 수(QPS) 1,000개로 작동하며 7일 동안 측정했을 때 99% 가용성을 유지하기를 바란다고 가정해 봅시다. 오류 예산은 약 6억 개 요청 중에서 약 600만 개의 허용 가능 오류입니다. 예를 들어 오류 예산 소진까지 24시간이 있다면 초당 약 70개의 오류 또는 시간당 252,000개의 오류 한계가 있는 셈입니다. 이러한 매개변수는 호출 가능 이슈가 분기별 오류 예산의 최소 1% 이상을 소비해야 한다는 일반 규칙을 기반으로 합니다.

1시간이 지나기 전에 이 오류율을 감지하도록 선택할 수 있습니다. 예를 들어 초당 오류 70개의 속도를 15분 동안 관찰한 후에 다음 다이어그램과 같이 긴급 대기 엔지니어를 호출할지 결정할 수 있습니다.

이상적으로는 24시간 예산 중에서 1시간을 사용하기 전에 문제가 해결되는 것이 가장 좋습니다. 더 짧은 기간(예: 1분)에 이 속도를 감지하도록 선택하면 오류가 발생하기가 지나치게 쉽습니다. 감지 목표 시간이 15분보다 짧으면 이 숫자를 조정할 수 있습니다.

느린 소진

다른 유형의 소진율은 느린 소진입니다. 주별 오류 예산을 5~6일째에 또는 월 오류 예산을 2주째에 소진하는 버그가 발생했다고 가정해 봅시다. 어떤 대응이 가장 좋을까요?

이 경우 알림 기간이 끝나기 전에 전체 오류 예산을 모두 소진할 가능성이 있음을 알려주는 느린 SLO 소진 알림을 도입할 수 있습니다. 물론 이 알림은 많은 거짓 양성을 반환할 수도 있습니다. 예를 들어 오류의 발생 시간은 짧지만 오류 예산을 재빨리 소비할 정도의 속도로 발생하는 경우도 있습니다. 이러한 경우 오류가 짧은 시간만 지속되고 장기적으로 오류 예산을 위협하지 않으므로 거짓양성 조건에 해당합니다. 목표는 모든 오류 소스를 제거하는 것이 아니라 오류 예산을 초과하지 않도록 허용 가능한 범위 안에 머무르는 것임을 기억하세요. 오류 예산을 합법적으로 위협하지 않는 이벤트에 대해서는 사람의 개입을 요청하는 알림을 보내지 않는 것이 좋습니다.

페이징이나 이메일이 아닌 티켓 큐에 느린 소진 이벤트를 알리는 것이 좋습니다. 느린 소진 이벤트는 긴급 상황이 아니지만 예산이 만료되기 전에 사람의 개입이 필요합니다. 이러한 알림은 금방 무시해도 되는 알림이 되며 팀 목록으로 발송되는 이메일이 아니어야 합니다. 티켓은 추적 가능하고 할당 가능하며 전송할 수 있어야 합니다. 팀은 티켓 로드, 폐쇄율, 작업 가능성, 중복에 대한 보고서를 개발해야 합니다. 작업을 수행할 수 없는 과도한 티켓은 과중한 업무의 좋은 예시입니다.

SLO 알림을 적절하게 사용하려면 시간이 걸릴 수 있고 팀의 문화와 기대치에 따라 달라집니다. 시간이 지남에 따라 SLO 알림을 미세 조정할 수 있습니다. 또한 필요에 따라 다양한 알림 기간을 가지는 여러 알림 방법이 있을 수 있습니다.

지연 시간 알림

가용성 알림 외에 지연 시간 알림도 사용할 수 있습니다. 지연 시간 SLO를 사용하면 지연 시간 목표를 충족하지 않는 요청 비율을 측정할 수 있습니다. 이 모델을 사용하면 오류 예산의 빠른 소진 또는 느린 소진을 감지하는 데 사용하는 것과 동일한 알림 모델을 활용할 수 있습니다.

앞에서 설명한 중간 지연 시간 SLO과 같이 요청의 절반만 SLO가 될 수 있습니다. 즉, 사용자가 장기적인 오류 예산에 미치는 영향을 감지하기 전에 잘못된 지연 시간을 겪을 수 있습니다. 대신 서비스는 꼬리 지연 시간 목표와 일반적인 지연 시간 목표를 정의해야 합니다. 이전 90번째 백분위수를 사용하여 일반적인 지연 시간 목표를 정의하고 이전 99번째 백분위수를 사용하여 꼬리 지연 시간 목표를 정의하는 것이 좋습니다. 이러한 목표를 설정한 후 각 지연 시간 카테고리에서 예상되는 요청 수와 지나치게 느린 요청 수를 기반으로 SLO를 정의할 수 있습니다. 이 접근 방식은 오류 예산과 동일한 개념이며 동일하게 취급해야 합니다. 따라서 '일반적인 지연 시간 내에서 요청의 90%가 처리되고 꼬리 지연 시간 내에서 요청의 99.9%가 처리'됩니다. 이러한 목표를 통해 대부분의 사용자는 일반적인 지연 시간을 경험하고 꼬리 지연 시간 목표보다 느린 요청 수를 추적할 수 있습니다.

일부 서비스에는 변동이 심한 예상된 런타임이 있을 수 있습니다. 예를 들어 Datastore 시스템에서 데이터를 읽을 때와 쓸 때의 성능 예상이 크게 다를 수 있습니다. 가능한 모든 예상을 열거하는 대신 다음 표와 같이 런타임 성능 버킷을 사용할 수 있습니다. 이 방식은 이러한 유형의 요청이 식별 가능하다고 여기며 각 버킷으로 사전에 분류됩니다. 요청을 즉시 분류해서는 안 됩니다.

사용자에게 표시되는 웹사이트
버킷	예상 최대 런타임
읽기	1초
쓰기 / 업데이트	3초

데이터 처리 시스템
버킷	예상 최대 런타임
작게	10초
중간	1분
크게	5분
대형	1시간
초대형	8시간

현재 사용 중인 시스템을 측정하면 일반적으로 이러한 요청이 실행되는 데 걸리는 시간을 파악할 수 있습니다. 예를 들어 동영상 업로드를 처리하는 시스템을 가정해 보겠습니다. 동영상이 매우 긴 경우 처리 시간이 더 오래 걸릴 수 있습니다. 다음 표와 같이 동영상 길이(초)를 사용하여 이 작업을 버킷으로 분류할 수 있습니다. 표에는 버킷당 요청 수와 한 주 동안의 런타임 분포에 대한 다양한 백분위가 기록됩니다.

동영상 길이	1주 동안 측정된 요청 수	10%	90%	99.95%
작게	0	-	-	-
중간	190만	864밀리초	17초	86초
크게	2,500만	1.8초	52초	9.6분
대형	430만	2초	43초	23.8분
초대형	81,000	36초	1.2분	41분

이러한 분석에서 다음과 같은 몇 가지 매개변수를 추출할 수 있습니다.

• fast_typical: 최대 10%의 요청이 이 시간보다 빠릅니다. 너무 많은 요청이 이 시간보다 빠르면 목표가 잘못되었거나 시스템에서 무언가가 변경되었을 수 있습니다.
• slow_normal: 최소 90%의 요청이 이 시간보다 빠릅니다. 이 한도는 기본 지연 시간 SLO를 유도합니다. 이 매개변수는 대부분의 요청이 충분히 빠른지 여부를 나타냅니다.
• slow_tail: 최소 99.95%의 요청이 이 시간보다 빠릅니다. 이 제한은 느린 요청이 너무 많지 않게 합니다.
• deadline: 사용자 RPC 또는 백그라운드 처리가 시간 초과되어 실패하는 지점입니다(일반적으로 이미 시스템에 하드 코딩된 제한). 이 요청들은 실제로 느리지는 않지만 오류와 함께 실제로 실패하게 되며 대신 가용성 SLO으로 포함됩니다.

버킷을 정의할 때 가이드라인은 버킷의 fast_typical, slow_typical, slow_tail이 서로의 자릿수 내에 유지되도록 하는 것입니다. 이 가이드는 버킷을 너무 광범위하게 잡지 않습니다. 버킷 간에는 겹침이나 공백이 없도록 하는 것이 좋습니다.

버킷	fast_typical	slow_typical	slow_tail	deadline
작게	100밀리초	1초	10초	30초
중간	600밀리초	6초	60초(1분)	300초
크게	3초	30초	300초(5분)	10분
대형	30초	6분	60분(1시간)	3시간
초대형	5분	50분	500분(8시간)	12시간

이렇게 하면 api.method: SMALL => [1s, 10s]와 같은 규칙이 적용됩니다. 이 경우 SLO 추적 시스템은 요청을 확인하고, 버킷을 결정하고(메서드 이름 또는 URI를 분석하고 조회 테이블과 이름을 비교하는 방식) 해당 요청의 런타임을 기반으로 통계를 업데이트합니다. 여기서 700밀리초가 소요되었으면 slow_typical 목표 내에 포함됩니다. 3초이면 slow_tail 이내입니다. 22초라면 slow_tail을 넘어서지만 오류는 아닙니다.

사용자 만족이라는 측면에서는 사라진 꼬리 지연 시간은 서비스를 사용할 수 없다는 의미로 생각해도 무방합니다. 즉, 응답이 너무 느려서 실패로 간주됩니다. 따라서 다음과 같이 가용성에 사용하는 것과 동일한 비율을 사용하는 것이 좋습니다.

전체 요청의 99.95%가 10초 이내에 충족됩니다.

일반 지연 시간은 개발자가 결정합니다. Google 내 일부 팀은 90%를 적합한 목표로 간주합니다. 이는 분석 및 slow_typical 기간을 선택한 방법과 관련이 있습니다. 예를 들면 다음과 같습니다.

전체 요청의 90%가 1초 이내에 처리됩니다.

추천 알림

이 가이드라인을 고려해 볼 때 다음 표에는 SLO 알림의 제안된 기준 집합이 포함되어 있습니다.

SLO	측정 기간	소진율	작업
가용성, 빠른 소진 일반 지연 시간 꼬리 지연 시간	1시간 기간	SLO 위반까지 24시간 미만 남음	도움 요청
가용성, 느린 소진 일반 지연 시간, 느린 소진 꼬리 지연 시간, 느린 소진	7일 기간	SLO 위반까지 24시간 넘게 남음	티켓 만들기

SLO 알림은 개발하는 데 시간이 걸리는 기술입니다. 이 섹션의 기간은 제안사항입니다. 이는 필요한 요구사항과 정밀도에 따라 조정할 수 있습니다. 측정 기간 또는 오류 예산 지출에 대하여 알림을 보내는 것은 도움이 될 수 있습니다. 또는 빠른 소진과 느린 소진 사이에 또 다른 알림 레이어를 추가할 수도 있습니다.

인프라 및 애플리케이션에 관측 가능성을 빌드합니다.

Google Cloud 아키텍처 프레임워크의 이 문서에서는 서비스에 관측 가능성을 추가할 수 있도록 권장사항을 제공하여 서비스 성능을 더 잘 이해하고 문제를 빠르게 식별할 수 있도록 합니다. 관측 가능성에는 모니터링, 로깅, 추적, 프로파일링, 디버깅, 기타 유사한 시스템이 포함됩니다.

모니터링은 Google SRE 핸드북의 서비스 안정성 계층 구조를 기반으로 합니다. 적절한 모니터링 없이는 애플리케이션이 제대로 작동하는지 알 수 없습니다.

코드를 사용하면 관측 가능성을 극대화할 수 있습니다.

잘 설계된 시스템은 개발 단계에서 시작되는 적절한 관측 가능성을 제공하는 것을 목표로 합니다. 관찰을 시작하기 전에 애플리케이션이 프로덕션 단계에 올 때까지 기다리지 마세요. 코드를 계측하고 다음 안내를 고려하세요.

• 효율적으로 디버깅하고 문제를 해결하려면 기록할 로그 및 trace 항목과 모니터링하고 내보낼 측정항목을 고려하세요. 가능성이 가장 높거나 빈번하게 발생하는 시스템의 장애 모드에 따라 우선순위를 지정합니다.
• 주기적으로 모니터링을 감사하고 프루닝합니다. 사용되지 않거나 불필요한 대시보드, 그래프, 알림, 추적, 로깅을 삭제하여 깔끔하게 정리합니다.

Google Cloud 관측 가능성은 실시간 모니터링, 하이브리드 멀티 클라우드 모니터링 및 로깅(예: AWS 및 Azure)은 물론 추적을 제공합니다. 프로파일링, 디버깅. Google Cloud 관측 가능성은 App Engine 또는 Istio와 같은 서비스 메시에서 실행 중인 마이크로서비스를 자동으로 검색 및 모니터링할 수 있습니다.

애플리케이션 데이터를 많이 생성하는 경우 BigQuery를 사용하여 분석 이벤트 로그의 대규모 수집을 최적화할 수 있습니다. BigQuery는 모니터링 프레임워크에서 카디널리티가 높은 시계열 데이터를 유지하고 분석하는 데도 적합합니다. 이 방식은 모니터링을 완전히 처음부터 설계하고 모니터링에서 보고를 분리하는 것보다 저렴한 비용으로 임의 쿼리를 실행할 수 있으므로 유용합니다. Looker Studio 또는 Looker를 사용하여 데이터로부터 보고서를 만들 수 있습니다.

권장사항

아키텍처 프레임워크의 안내 사항을 사용자의 고유 환경에 적용하려면 다음 권장사항을 따르세요.

• 마이그레이션 시작 전 또는 새 애플리케이션을 프로덕션 환경에 배포하기 전 등 사전에 모니터링을 구현합니다.
• 애플리케이션 문제와 근본적인 클라우드 문제를 구별합니다. Monitoring API 또는 다른 Cloud Monitoring 제품 및 Google Cloud 상태 대시보드를 사용합니다.
• 모니터링 외에도 추적, 프로파일링, 디버깅을 포함한 관측 가능성 전략을 정의합니다.
• 실행되지 않는 알림과 같이 사용하지 않거나 값을 제공하지 않는 관측 가능성 아티팩트를 정기적으로 삭제합니다.
• 대량의 관측 가능성 데이터를 생성하는 경우 애플리케이션 이벤트를 BigQuery와 같은 데이터 웨어하우스 시스템으로 전송합니다.

다음 단계

• 확장성 및 고가용성 설계(이 시리즈의 다음 문서)

시스템 설계, 운영 우수성, 보안, 개인 정보 보호, 규정 준수 등 아키텍처 프레임워크의 다른 카테고리를 살펴봅니다.

확장성 및 고가용성 설계

이 Google Cloud 아키텍처 프레임워크 문서에서는 고객 요구에 따라 오류를 허용하고 확장할 수 있도록 서비스를 설계하는 설계 원칙을 제공합니다. 안정적인 서비스에서는 서비스 수요가 많거나 유지보수 이벤트가 있을 때에도 고객 요청에 응답합니다. 다음과 같은 안정성 설계 원칙과 권장사항을 시스템 아키텍처 및 배포 계획에 포함해야 합니다.

가용성 증대를 위한 중복성 만들기

안정성이 높은 시스템에는 단일 장애점이 없어야 하며 리소스는 여러 장애 도메인에 걸쳐 복제되어야 합니다. 장애 도메인은 VM 인스턴스, 영역 또는 리전과 같이 독립적으로 실패할 수 있는 리소스 풀입니다. 장애 도메인 간 복제 시 개별 인스턴스보다 높은 집계 수준의 가용성을 얻을 수 있습니다. 자세한 내용은 리전 및 영역을 참조하세요.

시스템 아키텍처의 일부일 수 있는 중복성의 구체적인 예시로 DNS 등록 실패를 개별 영역으로 격리하려면 동일한 네트워크의 인스턴스들이 상호 액세스할 수 있도록 영역 DNS 이름을 사용합니다.

고가용성을 위한 장애 조치가 포함된 다중 영역 아키텍처 설계

데이터 복제, 부하 분산, 영역 간 자동 장애 조치 기능을 통해 애플리케이션이 여러 영역에 분산된 리소스 풀을 사용하도록 설계하여 영역 장애에 대한 복원력이 우수하도록 합니다. 애플리케이션 스택의 모든 레이어에 대한 영역 복제본을 실행하고 아키텍처의 모든 영역 간 종속 항목을 삭제합니다.

재해 복구를 위해 리전 간 데이터 복제

리전 서비스 중단 또는 데이터 손실 시 재해 복구가 가능하도록 원격 리전에 데이터를 복제하거나 보관처리합니다. 복제 지연으로 인해 소량의 데이터가 손실될 수 있는 경우를 제외한다면 복제 사용 시 원격 리전의 스토리지 시스템에 이미 최신 데이터가 있으므로 복구 속도가 더 빠릅니다. 지속적 복제 대신 주기적인 보관처리를 사용하는 경우 재해 복구에 새 리전의 백업 또는 보관 파일에서 데이터를 복원하는 작업이 포함됩니다. 이 절차는 일반적으로 계속 업데이트되는 데이터베이스 복제본을 활성화할 때보다 서비스 다운타임이 길고, 연속된 백업 작업 사이의 시간 간격으로 인해 더 많은 데이터 손실이 발생할 수 있습니다. 어떤 접근 방식을 사용하든 전체 애플리케이션 스택을 다시 배포하여 새 리전에서 시작해야 하며 그동안에는 서비스를 사용할 수 없습니다.

재해 복구 개념 및 기법에 대한 자세한 내용은 클라우드 인프라 서비스 중단의 재해 복구 설계를 참조하세요.

리전 서비스 중단에 대한 복원력이 우수한 멀티 리전 아키텍처 설계

드물지만 전체 리전에 장애가 발생하더라도 서비스를 계속 실행해야 하는 경우 서비스가 여러 리전에 분산된 컴퓨팅 리소스 풀을 사용하도록 설계하세요. 애플리케이션 스택의 모든 레이어에 대한 리전 복제본을 실행합니다.

리전이 작동 중지될 때 리전 간 데이터 복제 및 자동 장애 조치를 사용합니다. 일부 Google Cloud 서비스에는 Spanner와 같은 멀티 리전 변형이 있습니다. 리전 장애로부터 복원력을 늘리기 위해서는 가능한 경우 디자인에 멀티 리전 서비스를 사용합니다. 리전 및 서비스 가용성에 대한 자세한 내용은 Google Cloud 위치를 참조하세요.

리전 수준 장애가 미치는 영향의 범위가 해당 리전으로 제한되도록 리전 간 종속 항목이 없는지 확인합니다.

연결할 수 없을 때 전역 서비스 중단을 초래할 수 있는 단일 리전 기본 데이터베이스와 같은 리전 단일 장애점을 제거합니다. 멀티 리전 아키텍처는 비용이 많이 드는 경우가 많으므로 이 접근 방식을 채택하기 전에 비용과 비즈니스 요구를 비교하여 고려하세요.

장애 도메인 간 중복성 구현에 대한 자세한 지침은 클라우드 애플리케이션을 위한 배포 Archetype(PDF) 문서를 참조하세요.

확장성 병목 현상 제거

단일 VM 또는 단일 영역의 리소스 한도를 초과해서는 안 되는 시스템 구성요소를 식별합니다. 부하 증가를 처리하기 위해 단일 VM 인스턴스에 CPU 코어, 메모리 또는 네트워크 대역폭을 추가하여 수직 확장되는 애플리케이션도 있습니다. 이러한 애플리케이션은 확장성이 엄격하게 제한되어 증가를 처리하도록 수동으로 구성해야 하는 경우가 많습니다.

가능한 경우 VM 또는 영역에서 샤딩 또는 파티션 나누기 등을 사용해 수평 확장이 가능하도록 구성요소를 재설계합니다. 샤드를 추가하여 트래픽 또는 사용량 증가를 처리할 수 있습니다. 자동으로 추가되는 표준 VM 유형을 사용하면 샤드당 부하의 증가를 처리할 수 있습니다. 자세한 내용은 확장 가능하고 복원력이 우수한 앱 패턴을 참조하세요.

애플리케이션을 다시 설계할 수 없는 경우 사용자가 관리하는 구성요소를 사용자 작업 없이 수평 확장되도록 설계된 완전 관리형 클라우드 서비스로 바꿀 수 있습니다.

과부하 발생 시 단계적으로 서비스 수준 저하

과부하를 허용하도록 서비스를 설계합니다. 서비스에서 과부하를 감지하고 사용자에게 낮은 품질의 응답을 반환하거나 과부하로 인해 완전히 실패하지 않게 트래픽을 부분적으로 삭제해야 합니다.

예를 들어 서비스에서 정적 웹 페이지를 통해 사용자 요청에 응답하고 처리하는 데 비용이 많이 드는 동적 동작을 일시적으로 사용 중지할 수 있습니다. 이 동작은 Compute Engine에서 Cloud Storage로의 웜 장애 조치 패턴에서 자세히 설명합니다. 또는 읽기 전용 작업을 허용하고 데이터 업데이트를 일시적으로 사용 중지할 수 있습니다

서비스가 저하되면 오류 조건을 수정하라는 알림이 운영자에게 전달되어야 합니다.

트래픽 급증을 방지하고 완화하기

클라이언트 간 요청을 동기화하지 마세요. 동일한 인스턴스에서 트래픽을 보내는 클라이언트가 너무 많으면 트래픽이 급증하여 연쇄적 장애가 발생할 수 있습니다.

서버 측에 제한, 큐에 추가, 부하 차단, 회로 차단, 단계적 성능 저하, 중요 요청 우선순위 지정과 같은 급증 완화 전략을 구현합니다.

클라이언트의 완화 전략에는 클라이언트 측 제한과 지터를 사용한 지수 백오프가 포함됩니다.

입력 내용 삭제 및 유효성 검사

서비스 중단 또는 보안 침해를 야기하는 오류, 무작위 또는 악의적 입력을 방지하려면 API 및 운영 도구에 대한 입력 매개변수를 삭제하고 검사합니다. 예를 들어 Apigee와 Google Cloud Armor가 삽입 공격으로부터 보호하는 데 도움이 될 수 있습니다.

테스트 하네스가 의도적으로 무작위 입력, 비어 있는 입력, 너무 큰 입력으로 API를 호출하는 퍼즈 테스트를 정기적으로 사용합니다. 이러한 테스트는 격리된 테스트 환경에서 수행합니다.

변경사항을 적용하기 전에 운영 도구에서 자동으로 구성 변경사항을 검증하고 검증에 실패하면 변경사항을 거부해야 합니다.

작동이 지속되는 안전 장치

문제로 인해 오류가 발생한 경우 전체 시스템이 계속 작동할 수 있는 방식으로 시스템 구성요소에 장애가 발생해야 합니다. 이러한 문제는 소프트웨어 버그, 잘못된 입력 또는 구성, 계획되지 않은 인스턴스 중단 또는 작업자 오류일 수 있습니다. 서비스가 처리하는 작업은 지나치게 제한적이지 않고 오히려 지나치게 권한이 많거나, 지나치게 단순해야 하는지 여부를 확인하는 데 도움이 됩니다.

다음 예시 시나리오와 실패에 대응하는 방법을 고려하세요.

• 일반적으로 구성이 잘못되거나 비어 있는 방화벽 구성요소의 경우 오류 시 허용을 적용하고 운영자가 오류를 해결하는 동안 승인되지 않은 네트워크 트래픽이 단시간 통과할 수 있도록 하는 것이 좋습니다. 이 동작은 오류 시 종료하고 트래픽을 100% 차단하는 대신 서비스를 계속 사용할 수 있도록 합니다. 서비스에서 모든 트래픽이 통과하는 동안 민감한 영역을 보호하기 위해 애플리케이션 스택의 더 깊은 수준까지 인증 및 승인 확인을 사용해야 합니다.
• 하지만 사용자 데이터에 대한 액세스를 제어하는 권한 서버 구성요소는 오류 시 종료하여 모든 액세스를 차단하는 것이 좋습니다. 이 동작으로 인해 구성이 손상되면 서비스 중단이 발생하지만 오류 시 허용일 때의 기밀 사용자 데이터 유출 위험을 피할 수 있습니다.

두 경우 모두 운영자가 오류 조건을 해결할 수 있도록 장애 시 높은 우선순위의 알림이 발생해야 합니다. 비즈니스에 심각한 위험을 초래하지 않는 한, 서비스 구성요소에 오류 시 허용을 적용해야 합니다.

재시도할 수 있도록 API 호출 및 작업 명령어 설계

API 및 운영 도구에서 최대한 안전하게 호출을 재시도할 수 있어야 합니다. 여러 오류 조건에 대한 자연스러운 접근 방식은 이전 작업을 다시 시도하는 것이지만 첫 시도가 성공했는지 모를 수 있습니다.

시스템 아키텍처는 작업이 멱등성을 갖도록 해야 합니다. 즉, 객체에 대해 동일한 작업을 두 번 이상 연속적으로 실행하면 단일 호출과 동일한 결과가 생성됩니다. 비멱등성 작업에는 시스템 상태의 손상을 방지하기 위해 더 복잡한 코드가 필요합니다.

서비스 종속 항목 식별 및 관리

서비스 설계자와 소유자가 다른 시스템 구성요소의 종속 항목에 관한 전체 목록을 유지해야 합니다. 또한 서비스 설계에는 종속 항목 오류 복구 또는 전체 복구가 불가능한 경우 단계적 성능 저하가 포함되어야 합니다. 모든 시스템 종속 항목의 실패율이 0이 아님을 인식하고, 시스템에서 사용하는 클라우드 서비스 및 타사 서비스 API와 같은 외부 종속 항목을 고려합니다.

안정성 목표를 설정할 때 서비스의 SLO가 모든 중요한 종속 항목의 SLO에 따라 수학적으로 제한된다는 것을 인식합니다. 종속 항목 중 하나의 최저 SLO보다 안정적일 수는 없습니다. 자세한 내용은 서비스 가용성의 미적분을 참조하세요.

시작 종속 항목

서비스는 안정 상태 동작과 달리 시작 시 다르게 작동합니다. 시작 종속 항목은 안정 상태의 런타임 종속 항목과 상당히 다를 수 있습니다.

예를 들어 서비스가 시작할 때 다시 호출할 일이 거의 없는 사용자 메타데이터 서비스에서 사용자 또는 계정 정보를 로드해야 할 수 있습니다. 비정상 종료나 정기 유지보수 후에 다시 시작되는 서비스 복제본이 많으면 특히 캐시가 비어 있어 다시 채워야 하는 경우 복제본으로 인해 시작 종속 항목의 부하가 급증할 수 있습니다.

로드 시 서비스 시작을 테스트하고 그에 맞게 시작 종속 항목을 프로비저닝합니다. 중요 시작 종속 항목에서 검색하는 데이터 복사본을 저장하여 단계적으로 성능 저하가 발생하도록 디자인을 고려합니다. 이 동작은 중요 종속 항목에 중단이 발생할 때 서비스가 시작되지 않는 것이 아니라 잠재적으로 오래된 데이터를 사용해서 서비스가 다시 시작될 수 있도록 합니다. 서비스는 나중에 가능하면 새 데이터를 로드하여 정상 작동 상태로 돌아갈 수 있습니다.

시작 종속 항목은 또한 새 환경에서 서비스를 부트스트랩할 때 중요합니다. 레이어 간 순환 종속 항목 없이 계층형 아키텍처로 애플리케이션 스택을 디자인합니다. 순환 종속 항목은 단일 애플리케이션에 대해 증분적인 변경을 차단하지 않기 때문에 용인되는 것으로 보일 수 있습니다. 하지만 순환 종속 항목은 재해로 인해 전체 서비스 스택이 중단된 이후 다시 시작하는 것을 어렵거나 불가능하게 만들 수 있습니다.

중요한 종속 항목 최소화

서비스에 중요한 종속 항목, 즉 장애가 발생하여 서비스가 중단되는 원인이 되는 다른 구성요소를 최소화합니다. 사용하는 다른 구성요소의 장애 또는 속도 저하에 대한 복원력이 우수한 서비스를 만들려면 다음과 같은 설계 기법 및 원칙을 사용하여 중요한 종속 항목을 중요하지 않은 종속 항목으로 변환합니다.

• 중요한 종속 항목의 중복 수준을 높입니다. 복제본을 더 추가하면 전체 구성요소를 사용할 수 없게 될 가능성이 낮습니다.
• 응답을 차단하는 대신 다른 서비스에 대한 비동기식 요청을 사용하거나 게시/구독 메시지를 사용하여 응답에서 요청을 분리합니다.
• 단기적으로 사용할 수 없게 된 종속 항목을 복구하기 위해 다른 서비스의 응답을 캐시합니다.

서비스 장애 또는 속도 저하를 종속된 다른 구성요소에 피해가 덜 가는 방식으로 렌더링하려면 다음 설계 기법 및 원칙을 고려하세요.

• 우선순위가 지정된 요청 큐를 사용하고 사용자가 응답을 기다리는 요청에 더 높은 우선순위를 부여합니다.
• 캐시에서 응답을 제공하여 지연 시간과 부하를 줄입니다.
• 작동이 지속되는 안전 장치를 마련합니다.
• 트래픽 과부하가 발생하면 성능이 단계적으로 저하되도록 합니다.

모든 변경 사항을 롤백 가능한지 확인

서비스에 대해 특정 유형의 변경사항을 실행 취소할 수 있는 잘 정의된 방법이 없으면 롤백을 지원하도록 서비스 디자인을 변경합니다. 주기적으로 롤백 프로세스를 테스트합니다. 각 구성요소 또는 마이크로서비스의 API 버전을 관리하고, API가 발전하더라도 이전 세대의 클라이언트가 계속 올바르게 작동하도록 하위 호환성을 지원해야 합니다. 이러한 디자인 원칙은 필요에 따라 빠른 롤백을 지원하고 API 변경사항의 점진적 롤아웃을 허용하기 위해 중요합니다.

롤백은 모바일 애플리케이션에 구현하는 데 비용이 많이 들 수 있습니다. Firebase 원격 구성은 기능을 손쉽게 롤백할 수 있는 Google Cloud 서비스입니다.

데이터베이스 스키마 변경사항을 즉시 롤백할 수는 없으므로, 이를 여러 단계에 걸쳐 실행해야 합니다. 애플리케이션의 최신 버전 및 이전 버전에서 안전한 스키마 읽기 및 업데이트 요청을 허용하도록 각 단계를 디자인합니다. 이러한 디자인 방식을 사용하면 최신 버전에 문제가 있을 때 안전하게 롤백할 수 있습니다.

권장사항

아키텍처 프레임워크의 안내 사항을 사용자의 고유 환경에 적용하려면 다음 권장사항을 따르세요.

• 클라이언트 애플리케이션의 오류 재시도 로직에서 무작위 순서 지정으로 지수 백오프를 구현합니다.
• 높은 가용성을 위해 자동 장애 조치가 포함된 멀티 리전 아키텍처를 구현합니다.
• 부하 분산을 사용하여 샤드와 리전 전체에 사용자 요청을 분산합니다.
• 과부하 시 성능이 단계적으로 저하되도록 애플리케이션을 설계합니다. 완전히 실패하는 대신 부분 응답을 제공하거나 제한된 기능을 제공합니다.
• 용량 계획을 위해 데이터 중심의 프로세스를 설정하고 로드 테스트 및 트래픽 예측을 사용해서 리소스 프로비저닝 시기를 결정합니다.
• 재해 복구 절차를 수립하고 주기적으로 테스트합니다.

다음 단계

• 안정적인 운영 프로세스 및 도구 만들기(이 시리즈의 다음 문서)

시스템 설계, 운영 우수성, 보안, 개인 정보 보호, 규정 준수 등 아키텍처 프레임워크의 다른 카테고리를 살펴봅니다.

안정적인 운영 프로세스 및 도구 만들기

Google Cloud 아키텍처 프레임워크의 이 문서에서는 업데이트를 배포하고 프로덕션 환경에서 서비스를 실행하고 오류를 테스트하는 방법 등 서비스를 안정적으로 실행하기 위한 운영 원칙을 제공합니다. 안정성을 고려한 설계에는 소프트웨어 설계뿐만 아니라 서비스의 전체 수명주기가 포함되어야 합니다.

애플리케이션 및 서비스에 대해 적합한 이름 선택

프로덕션 구성 파일에 내부 코드 이름을 사용하지 마세요. 특히 신규 직원의 경우 이름이 혼동될 수 있고, 서비스 중단 시 해결 시간(TTM)이 길어질 수 있습니다. 가능한 경우 언제라도 VM, 클러스터, 데이터베이스 인스턴스 등 모든 애플리케이션, 서비스, 중요 시스템 리소스에 대해 해당 이름 길이 한도에 맞게 적합한 이름을 선택하세요. 좋은 이름은 해당 항목의 목적을 나타내야 하고, 정확하고, 구체적이고, 구분이 가능해야 하며, 누구라도 이해할 수 있는 이름입니다. 좋은 이름은 두문자어, 코드 이름, 축약어, 잠재적으로 불쾌감을 주는 용어 등을 피해야 하며, 외부에 공개되더라도 부정적인 대중 반응을 일으키지 않는 것이어야 합니다.

카나리아 테스트로 점진적 출시 구현

서비스 바이너리 또는 구성을 즉각적이고 전체적으로 변경하는 것은 본질적으로 위험합니다. 새 버전의 실행 파일 및 구성 변경사항을 단계적으로 출시합니다. 영역 하나에서 몇 개의 VM 인스턴스와 같이 작은 범위로 시작한 다음 범위를 점진적으로 확장합니다. 변경사항이 예상한 대로 수행되지 않거나 출시 단계에서 사용자에게 부정적인 영향을 미치는 경우 빠르게 롤백합니다. 목표는 변경사항을 전역적으로 출시하기 전에 소수의 사용자 트래픽에만 영향을 미칠 때 버그를 식별하고 해결하는 것입니다.

서비스 변경사항을 인식하고 변경된 서버의 측정항목과 나머지 서버를 A/B 비교하는 카나리아 테스트 시스템을 설정합니다. 이 시스템은 예기치 않거나 비정상적인 동작을 신고해야 합니다. 변경사항이 예상한 대로 작동하지 않으면 카나리아 테스트 시스템이 출시를 자동으로 중단해야 합니다. 사용자 오류처럼 명확한 문제이거나 CPU 사용량 증가나 메모리 블로트와 같이 미묘한 문제가 발생할 수 있습니다.

문제가 처음 감지되었을 때 중단하고 롤백하면 서비스 중단으로 인한 시간적 압박 없이 문제를 진단할 수 있습니다. 변경사항이 카나리아 테스트를 통과하면 해당 변경사항을 더 큰 범위(예: 전체 영역, 두 번째 영역)에 단계적으로 전파합니다. 변경된 시스템이 더 많은 양의 사용자 트래픽을 단계적으로 처리하여 잠재적인 버그를 노출할 때까지 기다립니다.

자세한 내용은 애플리케이션 배포 및 테스트 전략을 참조하세요.

예약 프로모션 및 출시를 위한 트래픽 분산

정해진 시간에 시작하고 많은 사용자가 동시에 서비스에 연결하도록 유도하는 등의 프로모션 이벤트가 있을 수 있습니다. 그렇다면 몇 초 동안 트래픽을 분산하도록 클라이언트 코드를 설계합니다. 요청을 시작하기 전에 무작위 지연을 사용합니다.

시스템을 예열할 수도 있습니다. 시스템을 예열할 경우 예상하는 사용자 트래픽을 미리 전송하여 예상한 대로 작동하는지 확인할 수 있습니다. 이러한 방법으로 예약된 시작 시간에 서버의 장애를 초래할 수 있는 갑작스러운 트래픽 급증을 방지할 수 있습니다.

빌드, 테스트, 배포 자동화

지속적 통합 및 지속적 배포(CI/CD) 파이프라인을 사용하여 출시 프로세스에서 수동적인 작업을 제거하세요. 자동화된 통합 테스트 및 배포를 수행합니다. 예를 들어 GKE로 현대적인 CI/CD 프로세스를 만듭니다.

자세한 내용은 지속적 통합, 지속적 배포, 테스트 자동화 및 배포 자동화를 참조하세요.

작업자 오류 방지

잘못되었을 수 있는 구성은 거부하도록 운영 도구를 설계합니다. 구성 버전이 비어 있거나 일부만 있거나 잘렸거나 손상되었거나 논리적으로 맞지 않거나 예기치 않았거나 예상된 시간 내에 수신되지 않은 경우 감지하여 알립니다. 도구에서 이전 버전과 크게 다른 구성 버전도 거부해야 합니다.

문제를 일으킬 수 있는, 너무 범위가 포괄적인 변경이나 명령어를 허용하지 마세요. 이러한 광범위한 명령어는 '모든 사용자의 권한 취소', '이 리전의 모든 VM 다시 시작', '이 영역의 모든 디스크 다시 포맷'과 같은 명령어일 수 있습니다. 이러한 변경사항은 운영자가 구성을 배포할 때 긴급 재정의 명령줄 플래그 또는 옵션 설정을 추가하는 경우에만 적용해야 합니다.

도구에서 변경사항의 영향을 받는 VM 수 등 위험한 명령어가 미치는 영향의 범위를 표시하고 도구를 진행하기 전에 명시적인 연산자 확인을 요구합니다. 또한 Cloud Storage 보관 정책 잠금과 같은 기능을 사용해 중요한 리소스를 잠그고 실수로 또는 승인 없이 삭제하지 못하도록 방지할 수 있습니다.

장애 복구 테스트

서비스 장애를 복구하는 운영 절차를 정기적으로 테스트합니다. 테스트를 정기적으로 실시하지 않으면 실제 장애가 발생하여 필요할 때 절차가 작동하지 않을 수 있습니다. 주기적으로 테스트할 항목에는 리전별 장애 조치, 출시 롤백 방법, 백업에서 데이터를 복원하는 방법이 포함됩니다.

재해 복구 테스트 수행

장애 복구 테스트와 마찬가지로 재해가 발생할 때까지 기다리지 말고 재해 복구 절차와 프로세스를 주기적으로 테스트하고 확인하세요.

고가용성(HA)을 제공하는 시스템 아키텍처를 만들 수 있습니다. 이 아키텍처는 재해 복구(DR)와 완전히 겹치지는 않지만 복구 시간 목표(RTO) 및 복구 지점 목표(RPO) 값이 중요하다면 HA를 고려해야 하는 경우가 많습니다.

HA를 사용하면 업타임과 같은 합의된 운영 성능을 충족하거나 초과할 수 있습니다. Google Cloud에서 프로덕션 워크로드를 실행할 때 수동 또는 활성 대기 인스턴스를 두 번째 리전에 배포할 수 있습니다. 이 아키텍처를 사용하면 기본 리전에 재해가 발생해도 애플리케이션은 영향을 받지 않는 리전의 서비스를 계속 제공합니다. 자세한 내용은 클라우드 서비스 중단에 대비한 재해 복구 설계를 참조하세요.

카오스 엔지니어링 연습

테스트 시 카오스 엔지니어링의 사용을 고려해 보세요. 안전한 환경에서 부하가 걸린 프로덕션 시스템의 다양한 구성요소에 실제 장애를 주입할 수 있습니다. 이 접근 방식에서는 서비스가 각 수준에서 올바르게 장애를 처리하므로 시스템이 받는 전반적인 영향을 막는 데 도움이 됩니다.

시스템에 주입하는 실패에는 비정상 종료 태스크, RPC의 오류 및 시간 제한, 리소스 가용성 감소가 포함될 수 있습니다. 임의의 결함 주입을 사용하여 서비스 종속 항목에서 간헐적인 장애를 테스트합니다(중단했다가 재개). 이러한 동작은 프로덕션 환경에서 감지하고 완화하기가 어렵습니다.

카오스 엔지니어링은 이러한 실험의 부정적 결과를 최소화하고 억제합니다. 이 테스트로 실제 서비스 중단을 대비해 연습하고 수집된 모든 정보를 사용하여 서비스 중단 대응을 개선하세요.

다음 단계

• 효율적인 알림 빌드(이 시리즈의 다음 문서)

시스템 설계, 운영 우수성, 보안, 개인 정보 보호, 규정 준수 등 아키텍처 프레임워크의 다른 카테고리를 살펴봅니다.

효율적인 알림 빌드

Google Cloud 아키텍처 프레임워크의 이 문서에서는 안정적인 서비스를 실행하는 데 도움이 되는 알림을 만들기 위한 운영 원칙을 제공합니다. 서비스 작동 방식에 대한 정보가 많을수록 문제가 있을 때 정보에 입각한 결정을 내릴 수 있습니다. 사용자에게 영향을 미치는 모든 시스템 문제를 조기에 정확하게 감지할 수 있도록 알림을 설계하고 거짓양성을 최소화합니다.

알림 지연 최적화

운영팀이 업무 부담을 느낄 정도로 너무 빨리 전송되는 알림과 서비스 중단 기간이 길어질 만큼 너무 늦은 알림 사이의 균형을 찾아야 합니다. 모니터링 시스템에서 사용자에게 문제를 알리기 전에 알림 지연을 조정하여 신호 대 잡음 비율을 최대화하는 동시에 감지 시간을 최소화합니다. 오류 예산 소비율을 기준으로 최적의 알림 구성을 생성합니다.

원인이 아닌 증상에 대한 알림

사용자 환경에 미치는 직접적인 영향을 기준으로 알림을 트리거합니다. 전역 또는 고객별 SLO를 준수하지 않으면 직접적인 영향이 있음을 나타냅니다. 특히 영향이 단일 복제본으로 제한되는 경우 가능한 모든 근본 원인에 대해 알림을 보내지 마세요. 잘 설계된 분산 시스템은 단일 복제본 장애로부터 원활하게 복구됩니다.

평균이 아닌 이상점 값에 대한 알림

지연 시간을 모니터링할 때 SLO를 정의하고 평균 또는 50번째 백분위수 지연 시간이 아닌 90번째, 95번째 또는 99번째 백분위수 지연 시간(3개 중 2개 선택)에 대한 알림을 설정합니다. 양호한 평균 또는 중앙값 지연 시간 값은 매우 부정적인 사용자 경험을 초래할 수 있는 90번째 백분위수 또는 그 이상의 허용할 수 없는 높은 값을 숨길 수 있습니다. 따라서 웹 서버와의 요청-응답 상호작용, 데이터 처리 파이프라인의 일괄 완료, 스토리지 서비스의 읽기 또는 쓰기 작업과 같은 중요한 작업의 지연 시간을 모니터링할 때 이상점 값에 알림 원칙을 적용해야 합니다.

이슈 관리를 위한 공동작업 프로세스 빌드

Google Cloud 아키텍처 프레임워크의 이 문서에서는 서비스를 관리하고 이슈 대응 프로세스를 정의하기 위한 권장사항을 제공합니다. 이슈는 모든 서비스에서 발생하므로, 이러한 이슈에 효율적으로 대응하고 완화하기 위해 잘 기술된 프로세스가 필요합니다.

이슈 관리 개요

잘 설계된 시스템도 결국에는 SLO를 충족하는 데 실패하게 됩니다. SLO가 없는 경우에도 고객은 자체적으로 과거 경험을 토대로 허용 가능한 서비스 수준을 대략적으로 정의합니다. 그런 후 SLA 내용과 관계없이 기술 지원 또는 유사한 그룹으로 에스컬레이션합니다.

고객에게 적절한 서비스를 제공하려면 이슈 관리 계획을 수립하고 정기적으로 테스트해야 합니다. 이러한 계획은 10개 정도의 항목이 포함된 한 페이지짜리 체크리스트일 수 있습니다. 팀은 이러한 프로세스를 통해 감지 시간(TTD)과 완화 시간(TTM)을 줄일 수 있습니다.

TTR과 달리 TTM이 선호됩니다. 여기서 R은 복구를 나타내며 종종 전체 수정과 완화의 의미를 비교하는 데 사용됩니다. TTM은 서비스 중단에 따른 고객 영향을 빠르게 끝낸 후 문제를 완벽하게 해결하도록 종종 훨씬 더 긴 프로세스를 시작하기 위해 빠른 완화를 강조합니다.

운영 우수성이 검증된 잘 설계된 시스템의 경우 장애 간 시간(TBF)이 길어집니다. 즉, 우수한 사고 관리 등 안정성을 위한 운영 원칙은 장애 발생 빈도를 줄이는 것을 목표로 합니다.

안정적인 서비스를 실행하기 위해서는 이슈 관리 프로세스에 다음과 같은 권장사항을 적용하세요.

명확한 서비스 소유권 할당

모든 서비스 및 핵심 종속 항목에는 SLO 준수 책임을 위해 소유자가 명확하게 지정되어 있어야 합니다. 조직 또는 팀 규모가 축소될 경우 엔지니어링 리드는 필요한 문서 기록 및 학습 절차와 함께 소유권이 새 팀으로 명확하게 이관되는지 확인해야 합니다. 다른 팀에서 서비스 소유자를 쉽게 확인할 수 있어야 합니다.

미세 조정 알림으로 감지 시간(TTD) 단축

TTD를 줄이려면 먼저 아키텍처 프레임워크 안정성 카테고리의 인프라 및 애플리케이션에 대한 관측 가능성 빌드 및 안정성 목표 정의 섹션에 설명된 권장사항을 검토하고 구현해야 합니다. 예를 들어 애플리케이션 이슈와 기본적인 클라우드 이슈 사이의 모호함을 없애야 합니다.

여러 SLI를 적절히 조정하면 과도한 알림 없이 적시에 팀에 알림이 전송됩니다. 자세한 내용은 아키텍처 프레임워크 안정성 카테고리의 효율적인 알림 빌드 섹션이나 SLI 측정항목 개선: CRE 주기 강의를 참조하세요.

사고 관리 계획 및 학습을 통해 완화 시간(TTM) 단축

TTM을 줄이려면 문서화되고 충분한 연습을 거친 사고 관리 계획을 정의해야 합니다. 해당 환경의 변경사항에 대한 데이터를 바로 사용할 수 있도록 준비해야 합니다. 팀은 TTM을 최소화하기 위해 신속하게 적용할 수 있는 일반적인 완화를 알고 있어야 합니다. 이러한 완화 기술에는 드레이닝, 변경사항 롤백, 리소스 늘리기, 서비스 품질 낮추기가 포함됩니다.

다른 아키텍처 프레임워크 안정성 카테고리 문서에 설명된 것처럼 변경사항에 대한 안전 및 빠른 롤백을 지원하도록 안정적인 운영 프로세스 및 도구를 만듭니다.

TTM이 최소화되도록 대시보드 레이아웃 및 콘텐츠 설계

운영자가 서비스와 중요한 모든 종속 항목이 실행되는지 여부를 1~2분 내에 확인할 수 있도록 서비스 대시보드 레이아웃 및 탐색을 구성합니다. 잠재적인 문제 원인을 빠르고 정확하게 확인하기 위해서는 운영자가 대시보드에서 모든 차트를 스캔하여 알림 시점에 크게 변경된 그래프를 빠르게 찾을 수 있어야 합니다.

이슈 문제 해결을 돕기 위해 대시보드에 다음과 같은 예시 그래프 목록이 표시될 수 있습니다. 이슈 대응 전문가가 단일 뷰에서 한 눈에 빨리 확인할 수 있어야 합니다.

• 서비스 수준 지표(예: 성공한 요청을 총 유효 요청으로 나눈 값)
• 구성 및 바이너리 출시
• 시스템에 대한 초당 요청 수
• 시스템의 초당 오류 응답 수
• 시스템에서 종속 항목으로 전송되는 초당 요청 수
• 종속 항목에서 시스템으로 전송되는 초당 오류 응답 수

문제 해결을 도와주는 다른 일반적인 그래프에는 지연 시간, 포화도, 요청 크기, 응답 크기, 쿼리 비용, 스레드 풀 사용률, 자바 가상 머신(JVM) 측정항목(해당하는 경우)이 포함됩니다. 포화도는 할당량 또는 시스템 메모리 크기와 같은 일부 제한에 따라 가득찬 정도를 나타냅니다. 스레드 풀 사용률은 풀 소진으로 인한 회귀를 찾습니다.

가장 중요한 그래프가 위쪽에 표시되고 그래프 순서가 표준 진단 워크플로와 일치하도록 몇 가지 중단 시나리오에 따라 이러한 그래프의 배치를 테스트합니다. 또한 머신러닝 및 통계적 이상 감지를 적용하여 이러한 그래프의 적합한 하위 집합을 드러낼 수 있습니다.

알려진 중단 시나리오에 대한 진단 절차 및 완화 기술

플레이북을 작성하고 알림 고지 항목에 연결합니다. 알림 고지로부터 이러한 문서에 액세스할 수 있으면 운영자가 문제 해결 및 완화에 필요한 정보를 빠르게 얻을 수 있습니다.

비난 없는 사후 분석을 통해 서비스 중단으로부터 배우고 재발 방지

비난 없는 사후 분석 환경과 이슈 검토 프로세스를 수립합니다. 비난 없는이란 해당 팀에서 누군가를 비난할 필요 없이 객관적인 방식으로 잘못된 것을 평가하고 문서로 기록하는 것을 의미합니다.

실수는 비난의 대상이 아닌 발전할 수 있는 기회입니다. 항상 시스템의 복원력을 향상시켜 사람의 실수로부터 신속하게 복구하거나 훨씬 더 효과적으로 사람의 실수를 감지하고 예방하는 것을 목표로 해야 합니다. 서비스 중단 발행 빈도가 줄어들도록 각 사후 조사에서 최대한 많은 학습을 추출하고 각 사후 작업 항목에 대해 지속적으로 후속 조치를 취합니다. 그러면 TBF가 증가합니다.

이슈 관리 계획 예시

알림이나 호출 또는 에스컬레이션 과정을 통해 프로덕션 이슈가 있음이 내게 확인되었습니다.

• 다른 사람에게 위임해야 할까요?
  • 예. 본인과 팀이 문제를 해결할 수 없다면 위임해야 합니다.
• 개인 정보 보호 또는 보안 침해 문제인가요?
  • 그렇다면 개인 정보 보호 또는 보안팀에 위임하세요.
• 응급상황 이슈이거나 SLO가 위반될 수 있는 이슈인가요?
  • 확실하지 않으면 응급상황으로 처리해야 합니다.
• 더 많은 사람이 참여해야 하나요?
  • 영향을 받는 고객 비중이 X% 이상이거나 문제 해결을 위해 Y분 이상 걸린다면 참여 인원을 늘려야 합니다. 확실하지 않다면, 특히 영업 시간 중이라면 항상 더 많은 인원을 투입하세요.
• 기본 커뮤니케이션 채널(예: IRC, 행아웃 채팅, Slack)을 정의합니다.
• 다음과 같이 이전에 정의된 역할을 위임합니다.
  • 전체 조정을 담당하는 이슈 책임자
  • 내부 및 외부 커뮤니케이션을 담당하는 커뮤니케이션 책임자
  • 이슈 완화 업무를 책임지는 운영 책임자
• 이슈가 종료되는 시점을 정의합니다. 이 결정을 위해서는 지원 담당자 또는 기타 유사한 팀의 확인이 필요할 수 있습니다.
• 비난 없는 사후 분석을 위해 공동 작업을 수행합니다.
• 사후 분석 이슈 검토 회의에 참여하여 담당자가 수행할 작업에 대해 논의합니다.

권장사항

아키텍처 프레임워크의 안내 사항을 사용자의 고유 환경에 적용하려면 다음 권장사항을 따르세요.

• 이슈 관리 계획을 설정하고 이를 사용하도록 팀을 훈련합니다.
• TTD를 줄이기 위해 인프라 및 애플리케이션에 대한 관측 가능성 빌드 권장사항을 구현합니다.
• 이슈 발생 시 상태를 한 눈에 확인할 수 있는 '변경사항' 대시보드를 빌드합니다.
• 쿼리 스니펫을 문서화하거나 자주 사용되는 로그 쿼리가 포함된 Looker Studio 대시보드를 빌드합니다.
• Firebase 원격 구성을 평가하여 모바일 애플리케이션 관련 출시 문제를 완화합니다.
• 백업에서 데이터 복원을 포함하여 장애 복구를 테스트하여 이슈의 하위 집합에 대한 TTM을 줄입니다.
• 구성 및 바이너리 롤백을 설계하고 테스트합니다.
• 재해 복구를 위해 리전 간 데이터를 복제하고 재해 복구 테스트를 사용하여 리전 서비스 중단 후 TTM을 줄입니다.
• 고가용성에 대한 비즈니스 요구사항으로 인해 비용이 높은 경우 TBF를 늘리기 위해 리전 중단에 대한 복원력이 우수한 멀티 리전 아키텍처를 설계합니다.

다음 단계

다음 리소스를 사용하여 이슈 관리를 위한 공동작업 프로세스를 빌드하는 방법을 자세히 알아보세요.

• Google Cloud 상태 대시보드
• Google에서의 이슈 관리
• 데이터 이슈 대응 절차
• 이슈 관리에 관한 SRE 워크북 항목

시스템 설계, 운영 우수성, 보안, 개인 정보 보호, 규정 준수 등 아키텍처 프레임워크의 다른 카테고리를 살펴봅니다.

Google Cloud 아키텍처 프레임워크: 제품 안정성 가이드

아키텍처 프레임워크의 이 섹션에는 일부 Google Cloud 제품의 안정성, 가용성, 일관성에 관한 제품별 권장사항 안내가 포함되어 있습니다. 또한 이 가이드에서는 장애를 최소화 및 복구하고 부하가 걸렸을 때 애플리케이션을 확장하기 위한 권장사항도 제공합니다.

참고: Google Cloud의 플랫폼 수준의 안정성 구성 요소(영역, 리전, 위치 범위 리소스)와 제공되는 가용성 수준은 Google Cloud 인프라 안정성 가이드를 참조하세요. 또한 이 가이드에서는 워크로드의 안정성 요구사항을 평가하기 위한 가이드라인과 Google Cloud에서 안정적인 인프라를 빌드하고 관리하기 위한 아키텍처 권장사항도 제공합니다.

제품 안정성 가이드는 다음 영역에 따라 구성됩니다.

• 컴퓨팅
  • Compute Engine
  • Cloud Run
  • Cloud Functions
  • Google Kubernetes Engine
• 스토리지 및 데이터베이스
  • Cloud Storage
  • Firestore
  • Bigtable
  • Cloud SQL
  • Spanner
  • Filestore
  • Memorystore
• 네트워킹
  • Cloud DNS
  • Cloud Load Balancing
  • Cloud CDN
• 데이터 분석
  • BigQuery
  • Dataflow
  • Dataproc

Compute Engine 안정성 가이드

Compute Engine은 사용자가 Google 인프라에서 필요에 따라 가상 머신을 만들고 실행할 수 있게 해주는 맞춤설정 가능한 컴퓨팅 서비스입니다.

권장사항

• Compute Engine API 권장사항 - Compute Engine API를 사용하고 API 비율 제한의 영향을 완화하기 위한 권장사항입니다.
• 복원력이 우수한 시스템 설계 - 단일 VM 장애나 재부팅, 영역 또는 리전 장애로부터 복구하도록 Compute Engine 애플리케이션을 설계하는 방법에 대한 자세한 안내입니다.
• 오버프로비저닝으로 가용성을 높이는 방법 - 영역 또는 리전 장애로 인해 용량 손실이 발생해도 애플리케이션을 계속 실행할 수 있도록 중복 리소스를 추가합니다.
• 가용성이 높은 애플리케이션을 위한 부하 분산 사용 - Compute Engine과 함께 Cloud Load Balancing을 사용하여 영역 서비스 중단 중에도 고가용성을 제공하는 방법입니다.
• Compute Engine 리전 선택 권장사항 - 가격/성능의 절충점을 고려하면서 애플리케이션의 지연 시간을 최적화하기 위해 Compute Engine 리소스에 사용할 Google Cloud 리전을 선택하는 방법입니다.
• Migrate to Virtual Machines를 사용하여 VM을 마이그레이션하기 위한 권장사항 - 평가, 계획 및 마이그레이션 수행을 포함하여 Migrate to Virtual Machines를 통해 지원되는 원본 환경에서 Compute Engine으로 VM을 마이그레이션하는 방법입니다. 마이그레이션으로 인해 발생할 수 있는 일반적인 문제를 해결하는 방법도 나와 있습니다.
• Compute Engine에서 유동 IP 주소 사용 패턴 - 아키텍처를 사용 사례의 패턴으로 변경하여 Compute Engine 환경에서 공유 또는 가상 IP 주소를 구현하는 방법입니다. 패턴에는 부하 분산, Google Cloud 경로, 자동 복구를 사용하는 패턴이 포함됩니다.
• 영구 디스크 스냅샷 권장사항 - 스냅샷을 더 빠르고 안정적으로 만듭니다.
• 영구 디스크 및 복제 - 영구 디스크가 스토리지 백엔드에 Colossus를 사용하고 VM에서 영구 디스크에 액세스합니다. 또한 영구 디스크 지연 시간을 모니터링하고, 리전 또는 영역 간에 영구 디스크를 복제하고, 복제본에 대한 읽기 및 쓰기 요청을 처리합니다.
• 성능 요구사항을 충족하도록 디스크 구성 - VM 인스턴스에 연결된 블록 스토리지 볼륨의 성능에 영향을 미치는 요소입니다.
• 이미지 관리 권장사항 - 부팅 이미지 선택, 이미지 및 이미지 수명 주기 맞춤설정, 프로젝트 간 이미지 공유 등 Compute Engine 이미지 관리에 대한 자세한 안내입니다.
• 이미지 계열 권장사항 - 이미지 계열의 최신 이미지를 프로덕션 환경에 사용하기 전에 테스트하는 것의 중요성과 테스트 절차를 설정하는 방법이 나와 있습니다.
• SQL Server 인스턴스 관련 권장사항 - Microsoft SQL Server를 실행하는 Compute Engine 인스턴스 및 SQL Server Enterprise 버전을 최적화하기 위한 권장사항입니다. 또한 운영체제의 기본 네트워크 설정과 운영 활동을 사용하여 성능과 안정성을 높이는 방법도 나와 있습니다.

Cloud Run 안정성 가이드

Cloud Run은 컨테이너화된 애플리케이션을 배포하는 데 적합한 관리형 서버리스 컴퓨팅 플랫폼입니다. Cloud Run은 사용자가 애플리케이션 빌드에 집중할 수 있도록 모든 인프라를 추상화합니다.

권장사항

• Cloud Run 일반 팁 - Cloud Run 서비스를 구현하고, 컨테이너를 빠르게 시작하고, 전역 변수를 사용하고, 컨테이너 보안을 개선하는 방법
• 부하 테스트 권장사항 - 부하 테스트 전 동시 실행 문제 해결, 최대 인스턴스 수 관리, 부하 테스트에 가장 적합한 리전 선택, 부하에 따른 서비스 확장 보장 등 Cloud Run 서비스의 부하 테스트 방법
• 인스턴스 확장 - 일부 인스턴스를 중지하는 대신 유휴 상태로 유지하여 컨테이너 인스턴스를 확장 및 제한하고 응답 시간을 최소화하는 방법
• 최소 인스턴스 사용 - 제공할 준비가 된 최소 컨테이너 인스턴스 수를 지정. 적절하게 설정하면 콜드 스타트 횟수를 줄여 평균 응답 시간을 최소화합니다.
• Cloud Run을 위한 자바 애플리케이션 최적화 - 자바로 작성된 Cloud Run 서비스에 대한 일부 최적화의 장단점을 이해하고 시작 시간과 메모리 사용량을 줄임
• Cloud Run을 위한 Python 애플리케이션 최적화 - WSGI 서버의 효율성을 개선하여 컨테이너 이미지를 최적화하고 스레드 수를 줄이거나 시작 작업을 동시에 실행하여 애플리케이션을 최적화함

Cloud Functions 안정성 가이드

Cloud Functions는 서비스 빌드 및 연결을 지원하는 확장 가능한 이벤트 기반 서버리스 플랫폼입니다. Cloud Functions는 HTTP 요청을 통해 호출되거나 백그라운드 이벤트를 기반으로 트리거될 수 있습니다.

권장사항

• Cloud Functions 권장사항 - Cloud Functions 사용 및 상호작용 방법, 멱등성 구현, 함수 배포, 성능 최적화 방법에 대한 가이드라인

Google Kubernetes Engine 안정성 가이드

Google Kubernetes Engine(GKE)은 클라우드에서 대규모로 컨테이너화된 애플리케이션을 실행하기 위한 시스템입니다. GKE는 컨테이너화된 애플리케이션의 리소스를 배포, 관리, 프로비저닝합니다. GKE 환경은 모두 함께 클러스터를 형성하도록 그룹화된 Compute Engine 인스턴스들로 구성됩니다.

권장사항

• 컨테이너 작동을 위한 권장사항 - 로깅 메커니즘을 사용하고, 컨테이너의 스테이트리스(Stateless) 및 변경 불가능성을 보장하고, 애플리케이션을 모니터링하고, 활성 및 준비 프로브를 수행하는 방법
• 컨테이너 빌드를 위한 권장사항 - 컨테이너별 단일 애플리케이션 패키지 구성, 프로세스 식별자(PID) 처리, Docker 빌드 캐시 최적화, 빠른 업로드 및 다운로드 시간을 위한 더 작은 이미지 빌드를 수행하는 방법
• Google Kubernetes Engine 네트워킹 권장사항 - 쉬운 확장을 위해 VPC 기반 클러스터를 사용하고, IP 주소를 계획하고, 클러스터 연결을 확장하고, Google Cloud Armor를 사용하여 분산 서비스 거부(DDoS) 공격을 차단하고, 낮은 지연 시간을 위해 컨테이너 기반 부하 분산을 구현하고, 단계적 장애 조치를 위해 외부 애플리케이션 부하 분산기의 상태 점검 기능을 사용하고, 클러스터에서 애플리케이션 가용성 향상을 위해 리전별 클러스터를 사용합니다.
• 클라우드 기반 Kubernetes 애플리케이션 준비 - 애플리케이션 용량 계획을 위한 권장사항을 학습하고, 수평 또는 수직적으로 애플리케이션을 확장하고, 메모리 대비 CPU에 대한 리소스 요청에 상대적인 리소스 한도를 설정하고, 빠른 애플리케이션 시작을 위해 컨테이너를 최소화하고, Pod Disruption Budget(PDB)을 설정하여 Pod 중단을 제한합니다. 또한 단계적 애플리케이션 시작을 위해 활성 프로브 및 준비 프로브를 설정하는 방법을 확인하고, 무중단 종료를 확인하고, 애플리케이션 과부하를 일으키는 트래픽 급증을 방지하기 위해 재시도 요청에 대해 지수 백오프를 구현합니다.
• GKE 멀티테넌시 권장사항 - 고가용성 및 안정성을 위해 멀티 테넌트 클러스터 아키텍처를 설계하고, 테넌트별 사용 측정항목을 위해 Google Kubernetes Engine(GKE) 사용 측정을 사용하고, 테넌트별 로그를 제공하고, 테넌트별 모니터링을 제공하는 방법을 알아봅니다.

Cloud Storage 안정성 가이드

Cloud Storage는 고급 보안 및 공유 기능을 갖춘 내구성과 가용성이 높은 객체 저장소입니다. 이 서비스는 Google Cloud 인프라에서 데이터를 저장하고 액세스하는 데 사용됩니다.

권장사항

• Cloud Storage 권장사항 - 가용성을 극대화하고 애플리케이션 지연 시간을 최소화하고 업로드 작업의 안정성을 개선하며 대규모 데이터 삭제 성능을 개선할 수 있는 Cloud Storage 일반 권장사항입니다.
• 요청 비율 및 액세스 분배 가이드라인 - Cloud Storage 자동 확장의 작동 방식을 이해하여 많은 요청 비율의 읽기, 쓰기, 삭제 작업에 대한 지연 시간 및 오류 응답을 최소화하는 방법을 알아봅니다.

Firestore 안정성 가이드

Firestore는 글로벌 규모의 모바일 및 웹 애플리케이션을 위해 데이터를 저장, 동기화, 쿼리할 수 있게 해주는 NoSQL 문서 데이터베이스입니다.

권장사항

• Firestore 권장사항 - 안정성 향상을 위한 데이터베이스 위치 선택, 인덱싱 시 성능 문제 최소화, 읽기 및 쓰기 작업 성능 향상, 변경 알림 지연 시간 감소, 확장성 설계 방법에 대한 권장사항입니다.

Bigtable 안정성 가이드

Bigtable은 대규모 분석 및 운영 워크로드에 사용되는 확장 가능한 완전 관리형 NoSQL 데이터베이스입니다. 수십억 개의 행과 수천 개의 열까지 확장할 수 있는 데이터 밀도가 낮은 테이블로 설계되었으며 짧은 지연 시간으로 많은 읽기 및 쓰기 처리량을 지원합니다.

권장사항

• Bigtable 성능 이해 - Bigtable의 처리량 예측, 처리량과 스토리지 사용량을 확인하여 Bigtable 용량을 계획하는 방법, 복제를 사용 설정할 때 읽기 및 쓰기 처리량에 각각 미치는 영향, Bigtable이 장기적으로 데이터를 최적화하는 방식을 설명합니다.
• Bigtable 스키마 설계 - 키/값 저장소의 개념, 계획된 읽기 요청에 따른 row key 설계, 열 및 행 처리, 특수한 사용 사례를 포함한 Bigtable 스키마 설계에 대한 안내입니다.
• Bigtable 복제 개요 - 여러 영역 또는 리전에서 Bigtable을 복제하는 방법, 복제가 성능에 미치는 영향, Bigtable이 충돌을 해결하고 장애 조치를 처리하는 방법을 알아봅니다.
• Bigtable 백업 정보 - Bigtable 백업으로 테이블 스키마와 데이터의 복사본을 저장하는 방법으로, 애플리케이션 수준 데이터 손상이나 운영자 실수(예: 테이블을 실수로 삭제)로부터 복구하는 데 도움이 될 수 있습니다.

Cloud SQL 안정성 가이드

Cloud SQL은 MySQL, PostgreSQL, SQL Server를 위한 완전 관리형 관계형 데이터베이스 서비스입니다. Cloud SQL은 기존 애플리케이션과 Google Cloud 서비스(예: Google Kubernetes Engine 및 BigQuery)와 간편하게 통합됩니다.

권장사항

• Cloud SQL 고가용성 - 읽기 복제본 처리 및 장애 조치 프로세스를 포함한 Cloud SQL의 고가용성 구성을 간략하게 설명합니다. 또한 여기에는 데이터베이스 유지보수 이벤트의 시점을 제어하는 방법과 HA 구성의 리전 영구 디스크 사용이 데이터베이스 성능에 미치는 영향이 포함합니다. 이 콘텐츠는 섹션 3개로 구성됩니다.

  • MySQL 고가용성
  • PostgreSQL 고가용성
  • SQL Server 고가용성

• Cloud SQL 데이터베이스 재해 복구 - 리전 간 읽기 복제본을 사용하는 Cloud SQL의 재해 복구 구성 개요입니다.

  • MySQL 재해 복구
  • PostgreSQL 재해 복구
  • SQL Server 재해 복구

• Cloud SQL의 일반 권장사항 - 인스턴스 구성, 데이터 아키텍처, 데이터 가져오기 및 내보내기, 백업 및 복구에 대한 지침입니다. 이 콘텐츠는 섹션 3개로 구성됩니다.

  • MySQL 권장사항
  • PostgreSQL 권장사항
  • SQL Server 권장사항

• 데이터 가져오기 및 내보내기 권장사항 - Cloud Storage 버킷을 사용할 수 없는 상황, 비용 절감을 위해 데이터 압축, 데이터 가져오기 및 내보내기에 대한 알려진 제한사항, 내보내기 작업 자동화 방법, 가져오기 및 내보내기 작업 문제 해결.

  • MySQL 권장사항
  • PostgreSQL 권장사항
  • SQL Server 권장사항

Spanner 안정성 가이드

Spanner는 전역 트랜잭션, 가용성이 높은 수평 확장, 트랜잭션 일관성과 같은 기능이 포함된 분산형 SQL 데이터베이스 관리 및 스토리지 서비스입니다.

권장사항

• Spanner 백업 및 복원 - Spanner 백업 및 복원의 주요 기능, 가져오기 및 내보내기와 백업 및 복원 비교, 구현 세부정보, Spanner 리소스에 대한 액세스 제어 방법
• 리전 및 멀티 리전 구성 - Spanner에서 제공하는 두 가지 유형의 인스턴스 구성(리전 구성 및 멀티 리전 구성)에 대한 설명입니다. 설명에는 각 구성의 차이점과 장단점이 포함됩니다.
• Spanner 자동 확장 - Cloud Spanner를 보조하는 도구로 사용할 수 있는 오픈소스 도구인 Spanner용 자동 확장 처리 도구를 소개합니다. 이 도구를 사용하면 각 Spanner 인스턴스의 사용률 측정항목을 기준으로 Spanner 인스턴스 하나 이상에서 노드 수나 처리 단위를 자동으로 늘리거나 줄일 수 있습니다.
• PITR(point-in-time recovery) 정보 - 우발적인 Spanner 데이터 삭제 또는 쓰기로부터 보호하는 기능인 Spanner PITR(point-in-time recovery)에 대한 설명입니다. 예를 들어 운영자가 실수로 데이터를 쓰거나 애플리케이션 출시가 데이터베이스를 손상시킵니다. PITR을 사용하면 과거의 특정 시점(최대 7일)에서 데이터를 원활하게 복구할 수 있습니다.
• Spanner 권장사항 - 일괄 로드, DML 사용, 핫스팟을 방지하기 위한 스키마 설계, SQL 권장사항에 대한 지침

Filestore 안정성 가이드

Filestore는 파일 시스템 인터페이스와 데이터용 공유 파일 시스템이 포함된 Google Cloud 애플리케이션을 위한 관리형 파일 스토리지 서비스입니다. Filestore는 Compute Engine 및 Google Kubernetes Engine 인스턴스를 위한 페타바이트급 온라인 네트워크 연결 스토리지(NAS)를 제공합니다.

권장사항

• Filestore 성능 - 성능 설정 및 Compute Engine 머신 유형 권장사항, Linux 클라이언트 VM 인스턴스의 최적 성능을 위한 NFS 마운트 옵션, 성능 테스트를 위한 fio 도구 사용. 여러 Google Cloud 리소스에서 성능을 개선하기 위한 권장사항이 포함되어 있습니다.

• Filestore 백업 - Filestore 백업, 일반적인 사용 사례, 백업 만들기 및 사용 권장사항에 대한 설명입니다.

• Filestore 스냅샷 - Filestore 스냅샷, 일반적인 사용 사례, 스냅샷 생성 및 사용에 대한 권장사항 설명

• Filestore 네트워킹 - Filestore를 사용하는 데 필요한 네트워킹 및 IP 리소스 요구사항

Memorystore 안정성 가이드

Memorystore는 2개의 오픈소스 캐싱 솔루션인 Redis 및 Memcached의 관리형 버전을 제공하는 완전 관리형 인메모리 저장소입니다. Memorystore는 확장 가능하며 프로비저닝, 복제, 장애 조치, 패치 적용과 같은 복잡한 작업을 자동화합니다.

권장사항

• Redis 일반 권장사항 - Redis 데이터베이스(RDB) 백업, 리소스 집약적인 작업, 연결 재시도가 필요한 작업에 대한 안내입니다. 또한 유지보수, 메모리 관리, 서버리스 VPC 액세스 커넥터 설정, 비공개 서비스 액세스 연결 모드, 모니터링 및 알림에 대한 정보도 있습니다.
• Redis 메모리 관리 권장사항 - 인스턴스 용량 및 Maxmemory 구성, 내보내기, 확장, 버전 업그레이드 작업, 메모리 관리 측정항목, 메모리 부족 해결 방법과 같은 메모리 관리 개념 조건에 대한 정보를 제공합니다.
• Redis 지수 백오프 - 지수 백오프 작동 방식, 예시 알고리즘, 최대 백오프 및 최대 재시도 횟수에 대한 정보를 제공합니다.
• Memcached 권장사항 - 캐시 부적중, 애플리케이션 IP 주소 직접 연결, Memcached 자동 검색 서비스에 맞게 애플리케이션을 설계하는 방법에 대한 정보가 있습니다. 또한 필수 매개변수 모니터링을 위해 max-item-size 매개변수 구성, 클러스터 분산, Cloud Monitoring 사용에 대한 안내도 제공합니다.
• Memcached 메모리 관리 권장사항 - Memcached 인스턴스의 메모리 구성, 예약 메모리 구성, 예약 메모리 증가 시기, 메모리 사용량 측정항목에 대한 정보를 제공합니다.

Cloud DNS 안정성 가이드

Cloud DNS는 도메인 등록, 관리 및 제공을 도와주는 지연 시간이 짧은 도메인 이름 시스템입니다. Cloud DNS는 많은 수의 DNS 영역 및 레코드로 확장되며, 수백만 개의 DNS 레코드를 사용자 인터페이스를 통해 만들고 업데이트할 수 있습니다.

권장사항

• Cloud DNS 권장사항 - 비공개 영역을 관리하고, DNS 전달을 구성하고, DNS 서버 정책을 만드는 방법을 알아봅니다. 하이브리드 환경에서 Cloud DNS를 사용하는 방법에 대한 안내가 포함되어 있습니다.

Cloud Load Balancing 안정성 가이드

Cloud Load Balancing은 사용자의 트래픽 전체에 적용되는 완전 분산형의 소프트웨어 정의 관리형 서비스입니다. Cloud Load Balancing은 또한 원활한 자동 확장, 레이어 4 및 레이어 7 부하 분산과 IPv6 전역 부하 분산과 같은 기능 지원을 제공합니다.

권장사항

• 성능 권장사항 - 최적의 성능이 제공되도록 애플리케이션 인스턴스에서 부하를 분산하는 방법. 전략에는 트래픽, 캐싱, 전달 규칙 프로토콜 선택, 세션 어피니티 구성에 가장 가까운 리전의 백엔드 배치가 포함됩니다.
• 가용성이 높은 애플리케이션을 위한 부하 분산 사용 - Compute Engine과 함께 Cloud Load Balancing을 사용하여 영역 서비스 중단 중에도 고가용성을 제공하는 방법입니다.

Cloud CDN 신뢰성 가이드

Cloud CDN(Content Delivery Network)은 Google의 에지 네트워크를 사용하여 사용자에게 최대한 가까운 콘텐츠를 제공하여 인터넷 콘텐츠 전송을 가속화하는 서비스입니다. Cloud CDN은 사용자에게 서비스를 쉽게 제공하도록 지연 시간, 비용, 부하를 줄여 줍니다.

권장사항

• 콘텐츠 전송 권장사항 - 캐시 키를 사용하여 캐시 적중률을 최적화하고, 최고 성능의 HTTP/3를 사용 설정하고, Cloud CDN 커스텀 모니터링 대시보드를 사용하여 모니터링 측정항목을 검토하는 방법입니다. 타사 성능 테스트의 가용성, 지연 시간, 처리량에 대한 보고서도 검토하는 방법입니다.

BigQuery 안정성 가이드

BigQuery는 데이터를 대규모로 저장 및 분석하기 위한 Google Cloud'의 데이터 웨어하우스 플랫폼입니다.

권장사항

• 안정성 소개 - 안정성 모범 사례와 가용성, 내구성, 데이터 일관성과 같은 개념 소개가 포함됩니다.
• 가용성 및 내구성 - Google Cloud 데이터 센터에서 발생할 수 있는 기능 도메인 유형, BigQuery가 데이터 스토리지 위치를 기반으로 스토리지 중복성을 제공하는 방법, 교차 리전 데이터 세트가 재해 복구를 향상시켜 주는 이유가 포함됩니다.
• BigQuery의 멀티 테넌트 워크로드 권장사항 - 멀티 테넌트 데이터 플랫폼에 사용되는 일반 패턴이 포함됩니다. 이러한 패턴에는 Software as a Service(SaaS) 공급업체의 안정성과 격리 보장, 중요 BigQuery 할당량 및 용량 계획 한도, BigQuery Data Transfer Service를 사용하여 관련 데이터 세트를 다른 리전에 복사하는 작업 등이 포함됩니다.
• 구체화된 뷰 사용 - 구체화된 뷰 쿼리, 파티션 정렬, 스마트 조정(쿼리 자동 재작성) 이해를 포함하여 더 저렴한 비용으로 BigQuery 구체화된 뷰를 사용하는 방법입니다.

Dataflow 신뢰성 가이드

Dataflow는 오픈소스 Apache Beam 라이브러리를 사용해서 빠르고 간소화된 스트리밍 데이터 파이프라인 개발을 가능하게 해주는 완전 관리형 데이터 처리 서비스입니다. Dataflow는 자동 확장 및 일괄 처리를 통해 지연 시간, 처리 시간, 비용을 최소화합니다.

권장사항

Dataflow를 사용하여 프로덕션에 즉시 사용할 수 있는 데이터 파이프라인 빌드 - Dataflow 파이프라인을 계획, 개발, 배포, 모니터링을 포함한 Dataflow 사용에 대한 문서 시리즈입니다.

• 개요 - Dataflow 파이프라인을 소개합니다.
• 계획 - Dataflow 작업을 실행할 리전을 지정할 때 SLO를 측정하고, 데이터 소스와 싱크가 파이프라인 확장성 및 성능에 미치는 영향을 이해하고, 고가용성, 재해 복구 및 네트워크 성능을 고려합니다.
• 개발 및 테스트 - 개발 환경을 설정하고, 오류 처리를 위한 데드 레터 큐를 사용해서 데이터 손실을 방지하고, 비용이 높은 요소별 작업을 최소화해서 지연 시간 및 비용을 줄여줍니다. 또한 일괄 처리를 사용하여 외부 서비스에 과부하가 발생하지 않으면서 성능 오버헤드를 줄이고, 부적절한 융합 단계를 융합 해제하여 성능 향상을 위해 단계를 분리하고 사전 프로덕션 시 엔드 투 엔드 테스트를 실행하여 파이프라인이 SLO 및 기타 프로덕션 요구사항을 계속 충족하도록 합니다.
• 배포 - 새로운 버전의 스트리밍 파이프라인을 배포할 때 특히 고려해야 하는 지속적 통합(CI)과 지속적 배포(CD)입니다. 또한 예시 CI/CD 파이프라인, 그리고 리소스 사용량 최적화를 위한 일부 기능입니다. 마지막으로 고가용성, 지리적 중복성, 그리고 리전 격리, 스냅샷 사용, 작업 제출 오류 처리, 파이프라인 실행에 영향을 미치는 오류 및 서비스 중단 복구와 같은 파이프라인 안정성에 대한 권장사항을 설명합니다.
• 모니터링 - 파이프라인 성능에 대한 주요 지표인 서비스 수준 지표(SLI)를 관찰하고 서비스 수준 목표(SLO)를 정의하고 측정합니다.

Dataproc 안정성 가이드

Dataproc는 Apache Hadoop 및 Spark 작업을 실행하기 위한 확장 가능한 완전 관리형 서비스입니다. Dataproc를 사용하면 필요에 따라 가상 머신을 맞춤설정하고 확장 및 축소할 수 있습니다. Dataproc는 Cloud Storage, BigQuery, Bigtable, 기타 Google Cloud 서비스와 밀접하게 통합됩니다.

권장사항

• Dataproc 고가용성 모드 - 인스턴스 이름, Apache ZooKeeper, Hadoop 분산 파일 시스템(HDFS), Yet Another Resource Negotiator(YARN) 등의 측면에서 Hadoop 고가용성(HA) 모드를 기본 비HA 모드와 비교합니다. 또한 고가용성 클러스터를 만드는 방법.
• 클러스터 자동 확장 - Dataproc 자동 확장 사용 시기, 자동 확장 정책 생성 방법, 멀티 클러스터 정책 사용, 자동 확장 구성을 위한 안정성 모범 사례, 측정항목 및 로그
• Dataproc 향상된 유연성 모드(EFM) - 작업 진행 지연을 최소화하기 위한 향상된 유연성 모드, 파티션 나누기 및 동시 로드와 같은 고급 구성, EFM 클러스터의 YARN 단계적 해제 사용 예시
• 단계적 해제 - 클러스터에서 작업자를 삭제할 때의 영향을 최소화하기 위한 단계적 해제 사용, 보조 작업자와의 이 기능 사용 방법, 단계적 해제에 대한 명령어 예시
• 다시 시작 가능한 작업 - 선택적 설정을 사용하면 실패 시 작업이 다시 시작하도록 설정하여 메모리 부족 문제 및 예상치 못한 Compute Engine 가상 머신 재부팅을 비롯한 일반적인 유형의 작업 실패 문제를 완화할 수 있습니다.

Google Cloud 아키텍처 프레임워크: 비용 최적화

Google Cloud 아키텍처 프레임워크의 이 카테고리에서는 설계 권장사항을 제공하고 설계자, 개발자, 관리자, 기타 클라우드 실무자가 Google Cloud의 워크로드 비용을 최적화하는 데 도움이 되는 권장사항을 설명합니다.

IT 워크로드를 클라우드로 이전하면 규모에 맞게 혁신하고, 기능을 더 빠르게 제공하며, 변화하는 고객의 요구사항에 대응할 수 있습니다. 기존 워크로드를 마이그레이션하거나 클라우드용으로 빌드된 애플리케이션을 배포하려면 보안, 복원력, 운영 우수성, 비용, 성능에 최적화된 토폴로지가 필요합니다.

아키텍처 프레임워크의 비용 최적화 카테고리에서는 다음을 수행하는 방법을 알아봅니다.

• FinOps 도입 및 구현: Google Cloud에서 리소스를 프로비저닝하고 관리할 때 직원이 비용 영향을 고려하도록 유도하는 전략입니다.
• 비용 모니터링 및 관리: Google Cloud의 리소스 비용을 추적하고 제어하는 권장사항, 도구, 기법입니다.
• 비용 최적화: 컴퓨팅, 컨테이너, 서버리스: Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Functions, App Engine에 대한 서비스별 비용 최적화 제어 방법입니다.
• 비용 최적화: 스토리지: Cloud Storage, Persistent Disk, Filestore의 비용 최적화 제어 방법입니다.
• 비용 최적화: 데이터베이스 및 스마트 분석: BigQuery, Bigtable, Spanner, Cloud SQL, Dataflow, Dataproc의 비용 최적화 제어 방법입니다.
• 비용 최적화: 네트워킹: Google Cloud의 네트워킹 리소스에 대한 비용 최적화 관리 방법입니다.
• 비용 최적화: Cloud 운영: Google Cloud에서 리소스 모니터링 및 관리 비용을 최적화하는 데 도움이 되는 권장사항입니다.

FinOps 채택 및 구현

Google Cloud 아키텍처 프레임워크의 이 문서에서는 Google Cloud에서 리소스를 프로비저닝하고 관리할 때 작업의 비용 및 영향력을 고려하고 결정하는 데 도움이 되는 전략을 설명합니다. 인력, 프로세스, 기술을 결합하여 규모나 클라우드 성숙도에 상관없이 조직의 재무 책임성 및 비용 최적화 규율을 촉진하는 FinOps에 대해 논의합니다.

이 섹션의 안내는 클라우드에서 조직의 지출을 관리하는 CTO, CIO, 경영진을 대상으로 합니다. 또한 개별 클라우드 운영자들이 FinOps를 이해하고 도입하는 데 도움이 될 수 있습니다.

조직의 모든 직원이 역할(분석가, 설계자, 개발자, 관리자)에 관계없이 Google Cloud의 리소스 비용을 줄이는 데 일조할 수 있습니다. 과거에 인프라 비용을 추적할 필요가 없었던 팀이라면 집단 책임의 필요성을 직원에게 교육해야 할 수 있습니다.

일반적인 모델은 중앙 FinOps팀 또는 Cloud Center of Excellence(CCoE)가 모든 클라우드 워크로드에서 비용을 최적화하는 프로세스를 표준화하는 것입니다. 이 모델은 중앙팀이 효율성을 개선하기 위한 높은 가치의 기회를 파악하는 데 필요한 지식과 전문성을 가지고 있다고 가정합니다.

중앙 집중식 비용 관리는 사용량이 적은 클라우드 채택 초기 단계에는 효과적일 수 있지만 클라우드 도입 및 사용량이 증가하면 제대로 확장되지 않습니다. 중앙팀이 확장에 어려움을 겪을 수 있으며 프로젝트팀에서 팀 외부인의 결정을 받아들이지 않을 수 있습니다.

중앙팀에서 리소스 최적화에 대한 결정을 프로젝트팀에 위임하는 것이 좋습니다. 중앙팀은 조직 전체에 FinOps 도입을 촉진하기 위한 광범위한 활동을 할 수 있습니다. 개별 프로젝트팀이 FinOps를 익히도록 하려면 중앙팀에서 프로세스, 보고, 비용 최적화 도구를 표준화해야 합니다. 중앙팀은 FinOps 관행에 익숙하지 않은 팀과 긴밀하게 협력하고 이러한 팀이 의사 결정 프로세스에서 비용을 고려하도록 지원해야 합니다. 또한 중앙팀은 재무팀과 개별 프로젝트팀 간의 중개자 역할을 해야 합니다.

다음 섹션에서는 중앙팀에서 장려하는 것이 좋은 설계 원칙을 설명합니다.

개인의 책임 장려

클라우드 리소스를 만들고 사용하는 모든 직원은 해당 리소스의 사용량과 비용에 영향을 미칩니다. 조직이 FinOps를 성공적으로 구현하기 위해 중앙관리팀은 직원이 비용을 다른 사람의 책임으로 보는 것에서 비용을 자신의 책임으로 소유하는 방식으로 전환할 수 있도록 지원해야 합니다. 이러한 전환을 통해 직원은 워크로드, 팀, 조직에 적합한 비용 결정을 소유하고 수행합니다. 이 소유권은 데이터 기반 비용 최적화 작업 구현으로 확장됩니다.

비용에 대한 책임감을 높이기 위해 중앙팀이 다음 작업을 수행할 수 있습니다.

• 사용자에게 비용 최적화 기회 및 기법을 교육합니다.
• 비용을 최적화한 직원에게 보상을 제공하고 성과를 기립니다.
• 조직 전체에서 비용을 확인할 수 있도록 합니다.

비용 확인

직원들이 클라우드에서 리소스를 프로비저닝하고 관리할 때 비용을 고려하려면 관련 데이터를 거의 실시간으로 완전히 확인해야 합니다. 보고서 및 대시보드의 데이터는 관련 영향이 발생할 때 팀 구성원의 결정에 따르는 비용과 비즈니스 영향을 표시해야 합니다. 다른 팀의 사용량 및 비용 데이터는 효율적인 배포 패턴을 식별하기 위한 기준으로 사용될 수 있습니다. 이 데이터를 사용하면 클라우드 서비스를 사용하는 최선의 방법에 대한 공유된 이해를 장려하는 데 도움이 됩니다.

조직에서 비용 데이터 공유를 장려하거나 권장하지 않는 경우 직원들은 데이터 공유를 꺼릴 수 있습니다. 때로는 비즈니스상의 이유로 조직에서 원시 비용 데이터 공유를 허용하지 않을 수 있습니다. 이 경우에도 비용 정보에 대한 액세스를 제한하는 기본 정책은 피하는 것이 좋습니다.

조직 전체에서 비용을 확인하기 위해 중앙팀이 다음 작업을 수행할 수 있습니다.

• 잘 정의된 한 가지 방법으로 클라우드 리소스의 부과된 비용 전부를 계산합니다. 예를 들어 이 방법은 공유 데이터베이스 비용과 같이 구매한 할인 및 공유 비용에 맞게 조정된 총 클라우드 지출을 고려할 수 있습니다.
• 직원이 거의 실시간으로 클라우드 지출을 확인할 수 있는 대시보드를 설정합니다.
• 팀 구성원이 비용을 소유하도록 독려하려면 팀 전체에서 클라우드 지출을 광범위하게 파악할 수 있어야 합니다.

공동작업 동작 지원

클라우드 리소스 비용을 효과적으로 관리하려면 팀 공동작업으로 기술 및 운영 절차를 개선해야 합니다. 공동작업 문화는 팀이 일관적인 비즈니스 목표와 요인을 기반으로 비용 효율적인 배포 패턴을 설계하는 데 도움이 됩니다.

공동작업 동작을 사용 설정하기 위해 중앙팀이 다음 작업을 수행할 수 있습니다.

• 다른 엔지니어가 제안한 아키텍처에 대한 동료 검토를 통해 설계 단계의 비용 효율성을 높이는 데 도움이 되는 워크로드 온보딩 프로세스를 만듭니다.
• 비용 효율적인 아키텍처 패턴으로 교차 팀 기술 자료를 만듭니다.

비난 없는 문화 조성

위험을 감수하고 필요한 경우 수정하며 혁신해도 안전한 환경을 조성하여 학습 및 성장 문화를 장려합니다. 다른 비즈니스 부문과 마찬가지로 IT 설계 및 배포 수명 주기 중 어느 단계에서나 실수(경우에 따라 많은 비용을 수반한 실수)가 발생할 수 있음을 인정합니다.

과도한 비용을 지출했거나 낭비를 유발한 개인을 탓하고 망신을 주기보다는 비용 초과 및 잘못된 계산의 원인을 파악하는 데 도움이 되는 비난 없는 문화를 장려합니다. 이러한 환경에서는 팀원이 자신의 견해와 경험을 공유할 가능성이 높습니다. 실수가 반복되지 않도록 기업 전체에 실수 사례를 익명 처리하여 공유합니다.

비난 없는 문화를 책임감 없는 문화로 혼동하지 마세요. 비난 없는 문화에서는 직원들이 자신의 결정과 자신이 지출한 금액을 계속 책임집니다. 하지만 실수를 저질렀을 때 실수가 다시 발생하지 않도록 학습 기회를 강조해야 합니다.

비난 없는 문화를 조성하기 위해 중앙팀이 다음 작업을 수행할 수 있습니다.

• 관련 담당자가 아닌 체계적인 근본 원인에 초점을 맞춰 주요 비용 문제에 대한 비난 없는 사후 분석을 실행합니다.
• 비용 초과에 대처하고 자신이 얻은 교훈을 공유한 팀 구성원을 치하합니다. 팀의 다른 구성원에게 실수, 자신이 취한 조치, 학습한 교훈을 공유하도록 장려합니다.

비즈니스 가치에 집중

비용 절감에 중점을 둔 FinOps 관행이 많지만 중앙팀은 프로젝트팀이 클라우드 리소스의 비즈니스 가치를 극대화하는 결정을 내릴 수 있도록 지원하는 데 중점을 두어야 합니다. 최소한의 서비스 수준이 충족되는 지점까지 비용을 줄이도록 결정하고 싶을 것입니다. 하지만 이러한 결정을 내리면 비용이 다른 리소스로 전환되어 유지보수 비용이 늘어날 수 있으며 결과적으로 총 소유 비용이 증가할 수 있습니다. 예를 들어 비용 절감을 위해 관리형 서비스 대신 가상 머신(VM)을 사용하도록 결정할 수 있습니다. 그러나 VM 기반 솔루션은 관리형 서비스와 비교했을 때 유지보수 작업이 더 많이 필요하므로 관리형 서비스가 더 높은 순 비즈니스 가치를 제공할 수 있습니다.

FinOps 관행은 프로젝트팀에서 클라우드 리소스의 비즈니스 가치를 극대화하는 아키텍처 및 운영 결정을 내리는 데 필요한 가시성과 유용한 정보를 제공할 수 있습니다.

직원이 비즈니스 가치에 집중하도록 돕기 위해 중앙팀이 다음 작업을 수행할 수 있습니다.

• 관리형 서비스 및 서버리스 아키텍처를 사용하여 컴퓨팅 리소스의 총 소유 비용을 절감하세요. 자세한 내용은 컴퓨팅 플랫폼 선택을 참조하세요.

• 클라우드 사용량과 비즈니스 가치 측정항목(비용 효율성, 복원력, 특성 속도, 비용 최적화 결정을 촉진하는 혁신)의 상관관계를 파악합니다. 비즈니스 가치 측정항목에 대한 자세한 내용은 Cloud FinOps 백서를 참조하세요.

• 클라우드에서 실행되는 모든 애플리케이션 및 서비스에 대한 단위 비용 예측을 구현합니다.

다음 단계

• FinOps에 대해 자세히 알아보기:
  • Cloud FinOps로 비즈니스 가치 극대화
  • Google Cloud에서 FinOps 시작하기
  • FinOps 기반
  • 클라우드의 단위 비용 예측
• 비용 모니터링 및 제어
• Google Cloud 서비스 비용 최적화:
  • 비용 최적화: 컴퓨팅, 컨테이너, 서버리스
  • 비용 최적화: 스토리지
  • 비용 최적화: 데이터베이스 및 스마트 분석
  • 비용 최적화: 네트워킹
  • 비용 최적화: Cloud 운영
• Google Cloud 아키텍처 프레임워크의 다른 카테고리 살펴보기

비용 모니터링 및 제어

Google Cloud 아키텍처 프레임워크의 이 문서에서는 Google Cloud에서 리소스 비용을 추적하고 제어하는 데 도움이 되는 권장사항, 도구, 기법을 설명합니다.

이 섹션의 안내는 클라우드에서 리소스를 프로비저닝하거나 관리하는 사용자를 대상으로 합니다.

비용 관리 중심 영역

Google Cloud의 리소스 비용은 사용하는 리소스의 양과 리소스에 대한 청구 요율에 따라 달라집니다.

클라우드 리소스 비용을 관리하려면 다음 영역에 중점을 두는 것이 좋습니다.

• 비용 가시성
• 리소스 최적화
• 요율 최적화

비용 가시성

지출 비용과 리소스 및 서비스 청구 방식을 추적하여 비즈니스 결과에 미치는 비용 영향을 분석할 수 있습니다. 조직 전체에서 비용 정보를 볼 수 있도록 다음 작업을 제안하는 FinOps 운영 모델을 따르는 것이 좋습니다.

• 할당: 모든 비용 항목에 소유자를 할당합니다.
• 보고서: 비용 데이터를 제공, 소비, 활용 가능하게 만듭니다.
• 예측: 미래 지출을 예측하고 추적합니다.

리소스 최적화

클라우드 리소스의 수와 크기를 워크로드의 요구사항에 맞춥니다. 가능하다면 관리형 서비스를 사용하거나 애플리케이션을 재설계하는 것을 고려하세요. 일반적으로 개별 엔지니어링팀은 리소스 배포를 최적화할 수 있는 기회와 기법에 대해 중앙 FinOps(재무 운영)팀보다 더 많은 컨텍스트를 갖고 있습니다. FinOps팀은 개별 엔지니어링 팀과 협력하여 조직 전체에 적용할 수 있는 리소스 최적화 기회를 파악하는 것이 좋습니다.

요율 최적화

FinOps팀은 종종 요율 최적화 결정을 중앙에서 수행합니다. 개별 엔지니어링팀은 중앙 FinOps 팀과 협력하여 예약, 약정 사용, Spot VM, 정액제, 볼륨, 계약 할인에 대한 큰 폭의 할인 혜택을 누릴 수 있습니다.

설계 권장사항

이 섹션에서는 비용을 모니터링하고 제어하는 데 사용할 수 있는 접근 방법을 제안합니다.

결제 및 리소스 관리 통합

Google Cloud에서 결제 및 리소스를 효율적으로 관리하려면 조직에 단일 결제 계정을 사용하고 내부 지불 거절 메커니즘을 사용하여 비용을 할당하는 것이 좋습니다. 서로 영향을 주지 않는 항목이 있는 느슨한 구조의 대기업과 조직에는 여러 결제 계정을 사용합니다. 예를 들어 리셀러는 고객마다 별도의 계정이 필요할 수 있습니다. 별도의 결제 계정을 사용하면 국가별 세금 규정을 충족하는 데에도 도움이 됩니다.

또 다른 권장사항은 관리하는 모든 프로젝트를 조직으로 옮기는 것입니다. Resource Manager를 사용하면 다음 목표를 달성하는 데 도움이 되는 리소스 계층 구조를 빌드할 수 있습니다.

• 각 리소스와 직속 상위 요소의 관계를 기반으로 리소스 소유권의 계층 구조를 설정합니다.
• 액세스 정책과 비용 할당 태그 또는 라벨이 조직의 리소스에 연결되고 상속되는 방식을 제어합니다.

또한 공유 서비스 비용을 소비량에 비례하여 할당하는 것이 좋습니다. 비즈니스 목표 및 우선순위의 변화에 따라 주기적으로 비용 할당 매개변수를 검토하고 조정합니다.

태그 또는 라벨을 사용하여 비용 추적 및 할당

태그와 라벨은 Google Cloud 리소스에 주석을 추가하는 데 사용할 수 있는 두 가지 방법입니다. 태그는 라벨보다 더 많은 기능을 제공합니다. 예를 들어 지원되는 리소스에 태그가 연결되었는지 여부를 조건부로 하는 Identity and Access Management(IAM) 정책을 만들어 리소스에 대한 세분화된 제어를 구현할 수 있습니다. 또한 리소스와 연결된 태그는 계층 구조의 모든 하위 리소스에 상속됩니다. 태그와 라벨의 차이점에 대한 자세한 내용은 태그 개요를 참조하세요.

비용 할당 및 추적을 위한 새 프레임워크를 빌드하는 경우 태그를 사용하는 것이 좋습니다.

필요한 세부 수준으로 비용 데이터를 분류하려면 조직의 지불 거절 메커니즘에 적합하고 비용을 적절하게 할당할 수 있는 태그 또는 라벨 지정 스키마를 설정합니다. 조직 또는 프로젝트 수준에서 태그를 정의할 수 있습니다. 프로젝트 수준에서 라벨을 할당하고 모든 프로젝트에 기본적으로 적용할 수 있는 라벨 집합을 정의할 수 있습니다.

태그 및 라벨 이상치와 라벨이 지정되지 않은 프로젝트를 감지하고 수정하는 프로세스를 정의합니다. 예를 들어 Cloud 애셋 인벤토리에서 프로젝트에 있는 모든 리소스의 인벤토리(.csv 파일)를 다운로드하고 인벤토리를 분석하여 태그 또는 라벨이 할당되지 않은 리소스를 식별할 수 있습니다.

공유 리소스 및 서비스(예: 일반적인 데이터 스토어, 멀티 테넌트 클러스터, 지원 구독) 비용을 추적하려면 특수 태그 또는 라벨을 사용하여 공유 리소스가 포함된 프로젝트를 식별하는 것이 좋습니다.

결제 액세스 제어 구성

Cloud Billing에 대한 액세스를 제어하려면 결제 연락처 정보를 관리하는 사용자에게만 결제 계정 관리자 역할을 할당하는 것이 좋습니다. 예를 들어 재무, 회계, 운영 직원은 이 역할이 필요할 수 있습니다.

결제 지원의 단일 장애점을 방지하려면 결제 계정 관리자 역할을 여러 사용자 또는 그룹에 할당합니다. 결제 계정 관리자 역할이 있는 사용자만 지원팀에 문의할 수 있습니다. 자세한 안내는 Cloud Billing 액세스 제어 예시 및 중요 역할을 참조하세요.

결제 액세스를 관리하려면 다음 구성을 수행합니다.

• 결제 계정을 프로젝트와 연결하려면 구성원에게 결제 계정에 대한 결제 계정 사용자 역할과 프로젝트에 대한 프로젝트 결제 관리자 역할이 있어야 합니다.
• 팀이 결제 계정을 프로젝트와 수동으로 연결할 수 있도록 하려면 조직 수준에서 프로젝트 결제 관리자 역할과 결제 계정에 대한 결제 계정 사용자 역할을 할당합니다. 프로젝트 생성 중에 서비스 계정에 프로젝트 결제 관리자 및 결제 계정 사용자 역할을 할당하여 결제 계정 연결을 자동화할 수 있습니다. 결제 계정 생성자 역할을 제한하거나 이 역할의 모든 할당을 삭제하는 것이 좋습니다.
• 프로젝트의 결제 상태를 실수로 변경하여 발생한 서비스 중단을 방지하기 위해 프로젝트와 해당 결제 계정 간의 링크를 잠글 수 있습니다. 자세한 내용은 프로젝트와 결제 계정 간의 링크 보안을 참조하세요.

결제 보고서 구성

결제 보고서를 설정하여 추적해야 하는 주요 측정항목의 데이터를 제공하세요. 다음 측정항목을 추적하는 것이 좋습니다.

• 비용 추세
• 최대 지출자(프로젝트 및 제품별)
• 불규칙한 지출 영역
• 조직 차원의 주요 통계는 다음과 같습니다.
  • 이상 감지
  • 시간 변동에 따른 추이
  • 설정된 패턴(예: 월별)에서 발생하는 추세
  • 내부 워크로드와 외부 워크로드 간의 비용 비교 및 벤치마크 분석
  • 비즈니스 사례 추적 및 가치 실현(예: 유사한 온프레미스 리소스 비용과 클라우드 비용 비교)
  • Google Cloud 청구서가 예상한 대로 정확한지 검증

추세 분석 및 비용 예측

BigQuery 결제 내보내기를 사용하여 비용 보고서를 맞춤설정하고 분석하고 Looker Studio를 사용하여 비용 데이터를 시각화할 수 있습니다. 예측 도구를 사용하여 실제 비용 추세와 지출 비용을 평가합니다.

리소스 사용량 및 비용 최적화

이 섹션에서는 Google Cloud 서비스 전반에서 리소스 사용 및 비용을 최적화하는 데 도움이 되는 권장사항을 설명합니다.

과다 지출을 방지하려면 모든 프로젝트에 대해 높은 임곗값을 사용하여 기본 예산 및 알림을 구성하는 것이 좋습니다. 예산을 초과하지 않도록 다음 작업을 수행하는 것이 좋습니다.

• 절대적 사용량이 필요한 프로젝트(예: 학습 또는 샌드박스 프로젝트)의 예산 및 알림 구성

• 추적해야 하는 재무 예산을 기반으로 예산을 정의합니다. 예를 들어 부서에 전체 클라우드 예산이 있는 경우 추적해야 하는 특정 프로젝트를 포함하도록 Google Cloud 예산의 범위를 설정합니다.

• 예산을 유지관리하려면 워크로드를 소유한 팀에 예산 및 알림 구성 책임을 위임합니다.

비용을 최적화하려면 다음을 수행하는 것이 좋습니다.

• 비즈니스에 미치는 영향이 거의 또는 전혀 없는 경우 API 사용량 상한을 설정합니다. 상한은 샌드박스 또는 학습 프로젝트와 고정 예산이 있는 프로젝트(예: BigQuery의 임시 분석)에 유용할 수 있습니다. 상한을 설정해도 연결된 프로젝트의 모든 리소스와 데이터가 삭제되지는 않습니다.
• 할당량을 사용하여 리소스 배포를 제한하는 엄격한 제한을 설정합니다. 할당량을 사용하면 비용을 관리하고 리소스를 악의적으로 사용하거나 오용하지 않도록 방지하는 데 도움이 됩니다. 할당량은 리소스 유형 및 위치에 따라 프로젝트 수준에서 적용됩니다.
• 권장사항 허브에서 비용 최적화 권장사항을 보고 구현합니다.
• 약정 사용 할인(CUD)을 구매하여 리소스 요구 사항을 예측 가능한 워크로드의 리소스 비용을 절감합니다.

도구 및 기술

클라우드의 주문형 프로비저닝 및 종량제 특성은 IT 비용을 최적화하는 데 도움이 됩니다. 이 섹션에서는 Google Cloud에서 제공하는 도구와 클라우드의 리소스 비용을 추적하고 제어하는 데 사용할 수 있는 기술을 설명합니다. 이러한 도구와 기술을 사용하기 전에 기본 Cloud Billing 개념을 검토하세요.

결제 보고서

Google Cloud는 Google Cloud Console 내에서 현재 및 예상 지출을 볼 수 있는 결제 보고서를 제공합니다. 결제 보고서를 사용하면 단일 페이지에서 비용 데이터를 확인하고, 추세를 검색 및 분석하고, 기간 종료 비용을 예측하고, 필요한 경우 시정 조치를 취할 수 있습니다.

결제 보고서는 다음 데이터를 제공합니다.

• 특정 기간의 비용 및 비용 추세는 다음과 같이 구성됩니다.
  • 결제 계정별
  • 프로젝트별
  • 제품별(예: Compute Engine)
  • SKU(예: 고정 IP 주소)
• 할인 또는 프로모션 크레딧이 제외된 경우의 예상 비용
• 예상 지출

BigQuery로 데이터 내보내기

BigQuery로 결제 보고서를 내보내고 라벨 또는 태그를 사용해 분류된 데이터를 포함한 세분화된 과거 데이터 뷰를 사용하여 비용을 분석할 수 있습니다. BigQuery ML을 사용하여 고급 분석을 수행할 수 있습니다. Cloud Billing 계정을 만들 때 BigQuery로 결제 보고서 내보내기를 사용 설정하는 것이 좋습니다. BigQuery 데이터 세트에는 Cloud Billing 내보내기를 설정한 날짜의 결제 데이터가 포함됩니다. 데이터 세트에는 내보내기를 사용 설정하기 전의 기간 데이터는 없습니다.

참고: 내보낸 결제 데이터는 지연 보고된 데이터, 타임스탬프 변형, 오류 및 조정, 세금으로 인해 결제 인보이스의 데이터와 다를 수 있습니다. 자세한 내용은 내보낸 데이터와 인보이스의 차이점을 참조하세요.

비용 데이터를 시각화하려면 BigQuery와 통합되는 커스텀 대시보드를 만들면 됩니다(예시 템플릿: Looker, Looker Studio).

내보낸 결제 데이터를 필터링하는 기준으로 태그와 라벨을 사용할 수 있습니다. 결제 내보내기에 포함된 라벨 수는 제한되어 있습니다. 한 시간 동안 최대 1,000개의 라벨 맵이 유지됩니다. 인보이스 PDF 또는 CSV에는 라벨이 표시되지 않습니다. 사업부, 내부 지불 거절 부서, 기타 관련 메타데이터를 나타내는 태그 또는 라벨을 사용하여 리소스에 주석을 추가하는 것이 좋습니다.

결제 액세스 제어

리소스에 대한 Identity and Access Management(IAM) 정책을 정의하여 특정 리소스와 관련된 Cloud Billing 액세스를 제어할 수 있습니다. Cloud Billing에 대해 액세스 권한을 부여하거나 제한하려면 조직 수준, 결제 계정 수준, 프로젝트 수준에서 IAM 정책을 설정할 수 있습니다.

참고: 결제 계정이 프로젝트에 연결되어 있어도 IAM에서 결제 계정은 프로젝트의 상위 요소가 아닙니다. 프로젝트는 연결된 결제 계정에서 권한을 상속받지 않습니다.

청구 및 리소스 관리를 위한 액세스 제어는 업무 분장 원칙을 따릅니다. 각 사용자는 비즈니스 역할에 필요한 권한만 있습니다. 조직 관리자 역할과 결제 관리자 역할의 권한이 다릅니다.

결제 계정 수준 및 조직 수준에서 결제 관련 권한을 설정할 수 있습니다. 일반적인 역할은 결제 계정 관리자, 결제 계정 사용자, 결제 계정 뷰어입니다.

인보이스 결제를 사용하거나 백업 결제 수단을 구성하는 것이 좋습니다. 청구 및 결제에 대한 연락처 및 알림 설정을 유지합니다.

예산, 알림, 할당량

예산을 사용하면 계획된 지출 대비 실제 Google Cloud 비용을 추적할 수 있습니다. 예산을 만들 때 실제 비용이나 예상 비용이 정의된 임곗값을 초과할 때 이메일 알림을 트리거하도록 알림 규칙을 구성할 수 있습니다. 예산을 사용하여 비용 관리 응답을 자동화할 수도 있습니다.

예산은 알림을 트리거하여 리소스 사용량 및 비용 추세를 알리고 비용 최적화 작업을 수행하라는 메시지를 표시할 수 있습니다. 하지만 실제 비용이 예산 또는 기준에 도달하거나 이를 초과할 때 예산에 따른 서비스 사용 또는 청구가 방지되지는 않습니다. 비용 알림을 자동으로 제어하려면 예산 알림을 사용하여 프로젝트의 Cloud Billing을 프로그래매틱 방식으로 사용 중지할 수 있습니다. 또한 API 사용량을 제한하여 정의된 사용량 임곗값을 넘은 후에는 비용이 발생하지 않도록 할 수도 있습니다.

결제 계정 및 프로젝트에 대한 알림을 구성할 수 있습니다. 계정에 예산을 1개 이상 구성합니다.

미리 정의된 수준 이상으로 리소스를 프로비저닝하거나 특정 작업의 볼륨을 제한하려면 리소스 또는 API 수준에서 할당량을 설정할 수 있습니다. 다음은 할당량을 사용하는 방법의 예시입니다.

• 초당 API 호출 수를 제어합니다.
• 생성되는 VM 수를 제한합니다.
• BigQuery에서 하루에 쿼리되는 데이터 양을 제한합니다.

프로젝트 소유자는 Service Usage API를 사용하여 소비자 재정의를 특정 할당량 제한에 적용함으로써 할당량 제한에 대해 청구될 수 있는 할당량을 줄일 수 있습니다. 자세한 내용은 소비자 할당량 재정의 만들기를 참조하세요.

워크로드 효율성 개선

Google Cloud의 워크로드를 비용 효율적으로 만들려면 다음 전략을 사용하는 것이 좋습니다.

• 제품 효율성을 개선하여 리소스 사용량을 최적화합니다.
• 리소스 청구 요율을 낮춥니다.
• 리소스 사용량과 지출액을 제어하고 제한합니다.

비용 절감 기술 및 Google Cloud 기능을 선택할 때는 다음 그래프와 같이 필요한 작업과 예상 절감액을 고려하세요.

다음은 이전 그래프에 표시된 기술을 요약한 것입니다.

• 다음 기술은 적은 노력으로 높은 절감 효과를 얻을 수 있습니다.
  • 약정 사용 할인
  • 자동 확장
  • BigQuery 슬롯
• 다음 기술을 사용하면 적당한 노력으로 높은 비용을 절감할 수 있습니다.
  • Spot VM
  • 서버리스 또는 컨테이너화된 애플리케이션으로 재설계
  • 관리형 서비스 사용을 위한 플랫폼 변경
• 다음 기술을 사용하면 보통 정도의 노력으로도 어느 정도 비용을 절감할 수 있습니다.
  • 커스텀 머신 유형
  • Cloud Storage 수명 주기 관리
  • 알맞은 크기 조정
  • 유휴 리소스 회수

다음 섹션에서 설명하는 기술을 사용하면 워크로드의 효율성을 개선할 수 있습니다.

리팩터링 또는 재설계

Google Cloud 제품을 사용하도록 워크로드를 리팩터링하거나 다시 설계하여 상당한 비용 절감을 달성할 수 있습니다. 예를 들어 Scale-to-zero를 지원하는 서버리스 서비스(Cloud Storage, Cloud Run, BigQuery, Cloud Functions 등)로 전환하면 효율성이 향상될 수 있습니다. 이러한 제품의 비용을 평가하고 비교하려면 가격 계산기를 사용하세요.

알맞은 크기 조정

이 기술을 사용하면 인프라의 확장이 원하는 사용량과 일치하는지 확인할 수 있습니다. 이 전략은 주로 기본 인프라 비용을 지불하는 Infrastructure as a Service(IaaS) 솔루션과 관련이 있습니다. 예를 들어 VM 50개를 배포했지만 VM이 완전히 활용되지 않았고 워크로드가 더 적거나 작은 VM에서 효과적으로 실행될 수 있다고 가정해 보겠습니다. 이 경우 일부 VM을 삭제하거나 크기를 조절할 수 있습니다. Google Cloud는 적정 크기 권장사항을 제공하므로 더 작은 VM을 프로비저닝하여 성능에 영향을 주지 않고 비용을 절감할 수 있습니다. 크기 조정을 프로덕션 단계에서 리소스를 배포한 후보다 설계 단계에서 수행하는 경우 크기 최적화의 부담이 줄어듭니다.

자동 확장

사용하는 제품이 동적 자동 확장을 지원할 경우 자동 확장을 활용할 수 있는 워크로드를 설계하여 비용과 성능 이점을 얻을 수 있습니다. 예를 들어 컴퓨팅 집약적인 워크로드의 경우 Compute Engine에서 관리형 인스턴스 그룹을 사용하거나 애플리케이션을 컨테이너화하여 Google Kubernetes Engine 클러스터에 배포할 수 있습니다.

Active Assist 권장사항

Active Assist는 데이터, 인텔리전스, 머신러닝을 사용하여 클라우드의 복잡성과 관리 작업을 줄여줍니다. Active Assist를 사용하면 클라우드 토폴로지의 보안, 성능, 비용을 쉽게 최적화할 수 있고 비용 및 사용량을 최적화하기 위한 지능형 권장사항을 사용할 수 있습니다. 이러한 권장사항을 적용하면 비용을 즉시 절감하고 효율성을 높일 수 있습니다.

다음은 Active Assist에서 제공하는 권장사항의 예시입니다.

• Compute Engine 리소스 크기 최적화: VM 인스턴스의 크기를 조절하여 사용량에 따라 비용 및 성능을 최적화합니다. 비활성 VM과 영구 디스크를 식별하고 삭제하거나 백업하여 인프라 비용을 최적화합니다.
• 약정 사용 할인 (CUD): Google Cloud가 이전 사용량을 분석하고, 워크로드의 최적 약정 수량을 찾아내고, 비용 절감을 위한 이해하기 쉽고 실용적인 추천 사항을 제공합니다. 자세한 내용은 약정 사용 할인 추천자를 참조하세요.
• 미사용 프로젝트: 조직의 미사용 프로젝트를 찾고 이를 삭제하거나 회수합니다. 자세한 내용은 미사용 프로젝트 추천자를 참조하세요.

전체 목록은 추천자를 참조하세요.

다음 단계

• Cloud Billing 개념에 대해 알아보기
• 예산 및 예산 알림 설정
• 컴퓨팅 서비스, 스토리지, 데이터베이스, 네트워킹, 운영 비용 최적화:
  • 비용 최적화: 컴퓨팅, 컨테이너, 서버리스
  • 비용 최적화: 스토리지
  • 비용 최적화: 데이터베이스 및 스마트 분석
  • 비용 최적화: 네트워킹
  • 비용 최적화: Cloud 운영
• Google Cloud 아키텍처 프레임워크의 다른 카테고리 살펴보기

비용 최적화: 컴퓨팅, 컨테이너, 서버리스

Google Cloud 아키텍처 프레임워크의 이 문서에서는 Google Cloud에서 가상 머신(VM), 컨테이너, 서버리스 리소스 비용을 최적화하는 데 도움이 되는 권장사항을 제공합니다.

이 섹션의 안내는 클라우드에서 워크로드의 컴퓨팅 리소스를 프로비저닝하고 관리하는 설계자, 개발자, 관리자를 대상으로 합니다.

컴퓨팅 리소스는 클라우드 인프라에서 가장 중요한 부분입니다. 워크로드를 Google Cloud에 마이그레이션할 때는 일반적으로 클라우드에서 VM을 효율적으로 프로비저닝하고 관리할 수 있게 해주는 Compute Engine이 먼저 선택됩니다. Compute Engine은 다양한 머신 유형을 제공하며 전 세계적으로 모든 Google Cloud 리전에서 제공됩니다. Compute Engine의 사전 정의된 커스텀 머신 유형을 사용하면 온프레미스 인프라와 비슷한 컴퓨팅 용량을 제공하는 VM을 프로비저닝하여 마이그레이션 프로세스를 가속화할 수 있습니다. Compute Engine은 사용되는 인프라에 대해서만 비용을 지불하는 가격 책정 이점이 있으며 지속 사용 할인에 따라 컴퓨팅 리소스를 더 많이 사용할 수록 비용을 크게 절약할 수 있습니다.

Compute Engine 외에도 Google Cloud는 컨테이너 및 서버리스 컴퓨팅 서비스를 제공합니다. 서버리스 접근 방식은 API, 데이터 처리, 이벤트 처리와 같이 상시적으로 실행되지 않는 새 서비스의 경우 더 비용 효율적일 수 있습니다.

이 문서에서는 일반적인 권장사항과 함께 다음 제품들을 사용할 때 컴퓨팅 리소스 비용을 최적화하는 데 도움이 되는 안내를 제공합니다.

• Compute Engine
• Google Kubernetes Engine(GKE)
• Cloud Run
• Cloud Functions
• App Engine

일반 권장사항

다음 권장 사항은 이 문서에서 설명하는 Google Cloud의 모든 컴퓨팅, 컨테이너, 서버리스 서비스에 적용됩니다.

사용량 및 비용 추적

다음 도구와 기법을 사용해서 리소스 사용량과 비용을 모니터링합니다.

• 권장사항 허브에서 비용 최적화 권장사항을 확인하고 대응합니다.
• 예산 알림을 구성하여 리소스 사용량 및 비용의 잠재적 증가에 대한 이메일 알림을 받습니다.
• Pub/Sub 및 Cloud Functions 서비스를 사용해서 알림을 프로그래매틱 방식으로 관리 및 대응합니다.

리소스 프로비저닝 제어

다음 권장사항에 따라 클라우드에 프로비저닝되는 리소스 양과 리소스가 생성되는 위치를 제어합니다.

• 리소스 소비 및 비용이 예측을 초과하지 않도록 리소스 할당량을 사용합니다.
• 워크로드의 지연 시간 요구사항을 충족하고 비용이 가장 낮은 리전에 리소스를 프로비저닝합니다. 리소스 프로비저닝 위치를 제어하려면 조직 정책 제약조건 gcp.resourceLocations를 사용할 수 있습니다.

약정 사용 할인 받기

약정 사용 할인(CUDs)은 필요한 리소스를 예측할 수 있는 워크로드에 이상적입니다. 워크로드를 Google Cloud로 마이그레이션한 후에는 필요한 리소스 기준을 찾고 약정 사용량 요금을 대폭 할인받을 수 있습니다. 예를 들어 1년 또는 3년 약정을 구매하고 Compute Engine VM 가격을 대폭 할인받을 수 있습니다.

라벨 사용으로 비용 추적 자동화

라벨을 일관적으로 정의하고 할당합니다. 다음 예시는 라벨을 사용하여 비용 추적을 자동화하는 방법을 보여줍니다.

• 영업시간 중에 개발자만 사용하는 VM의 경우 env: development 라벨을 할당합니다. Cloud Scheduler를 사용하면 서버리스 Cloud Function을 설정하여 영업시간 후 이러한 VM을 종료하고 필요한 경우 다시 시작할 수 있습니다.

• 여러 Cloud Run 서비스 및 Cloud Functions 인스턴스가 있는 애플리케이션의 경우 모든 Cloud Run 및 Cloud Functions 리소스에 일관된 라벨을 할당합니다. 고비용 영역을 파악하고 조치를 취하여 비용을 절감합니다.

결제 보고서 맞춤설정

필요한 필터를 설정하고 필요에 따라 데이터를 그룹화하여(예: 프로젝트, 서비스 또는 라벨별로) Cloud Billing 보고서를 구성합니다.

비용 절약 문화 장려

개발자 및 운영자에게 클라우드 인프라 교육을 제공합니다. 기존 또는 온라인 교육 과정, 토론 그룹, 동료 검토, 페어 프로그래밍, 비용 절약 게임을 사용해서 학습 프로그램을 만들고 장려합니다. Google DORA 연구조사에 나타난 것처럼 성능을 높이고 재작업 및 번아웃을 줄이고 비용을 최적화하기 위해서는 조직 문화가 핵심 원동력입니다. 직원이 자신의 리소스 비용을 직접 확인할 수 있게 함으로써 비즈니스 목표 및 제약조건에 맞게 우선순위 및 활동을 조정할 수 있게 도와줍니다.

Compute Engine

이 섹션에서는 Compute Engine 리소스의 비용을 최적화하는 데 도움이 되는 안내를 제공합니다. 이 안내 외에도 앞서 설명한 일반 권장사항을 따르는 것이 좋습니다.

결제 모델 이해

Compute Engine의 결제 옵션에 대해 자세히 알아보려면 가격 책정을 참조하세요.

리소스 소비 분석

Compute Engine에서 리소스 소비를 이해하기 위해서는 사용 데이터를 BigQuery로 내보냅니다. BigQuery Datastore를 쿼리해서 프로젝트의 가상 CPU(vCPU) 사용 추세를 분석하고 회수 가능한 vCPU 수를 확인합니다. 프로젝트별 코어 수에 대해 임곗값을 정의한 경우 사용 추세를 분석해서 이상점을 발견하고 수정 조치를 취합니다.

유휴 리소스 회수

다음 권장사항을 사용하여 우선순위가 낮은 개념 증명 프로젝트의 VM과 같이 사용되지 않은 VM 및 디스크를 식별하고 회수합니다.

• 유휴 VM 추천자를 사용해서 사용량 측정항목에 따라 비활성 상태의 VM 및 영구 디스크를 식별합니다.
• 리소스 삭제 전 잠재적인 작업 영향을 평가하고 필요할 때를 대비해서 리소스 재생성을 계획합니다.
• VM을 삭제하기 전에 스냅샷을 만드는 것이 좋습니다. VM을 삭제하면 디스크 유지 옵션을 선택하지 않는 경우 연결된 디스크가 삭제됩니다.
• 가능하다면 VM 삭제 대신 중지를 고려하세요. VM을 중지하면 인스턴스가 종료되지만 분리 또는 삭제하기 전까지 디스크 및 IP 주소가 보존됩니다.

수요에 맞게 용량 조정

VM이 자동으로 시작 및 중지되도록 예약 예를 들어 일주일 중 5일 동안 매일 8시간만 VM이 사용될 경우(주당 40시간) 일주일 중 VM이 사용되지 않는 128시간 동안 VM을 중지해서 비용을 75%까지 줄일 수 있습니다.

관리형 인스턴스 그룹을 사용하여 요청에 따라 컴퓨팅 용량을 자동 확장합니다. CPU 사용량 또는 부하 분산 용량 등 비즈니스에 중요한 매개변수를 기준으로 용량을 자동 확장할 수 있습니다.

적절한 머신 유형 선택

VM 머신 유형 추천자를 사용하여 워크로드 컴퓨팅 요구사항에 맞게 VM 크기를 조정합니다.

예측 가능한 리소스 요구사항이 있는 워크로드의 경우 커스텀 VM을 사용하여 머신 유형을 필요에 맞게 조정하고 비용을 절약할 수 있습니다.

내결함성이 있는 일괄 처리 워크로드의 경우 Spot VM 사용을 고려하세요. Spot VM에 배포할 수 있는 워크로드 예시에는 고성능 컴퓨팅(HPC), 빅데이터, 미디어 트랜스코딩, 지속적 통합 및 지속적 배포(CI/CD) 파이프라인, 스테이트리스(Stateless) 웹 애플리케이션이 있습니다. Descartes Lab에서 위성 이미지 처리를 위해 선점형 VM(Spot VM의 이전 버전)을 사용하여 분석 비용을 낮춘 방법 예시를 보려면 Descartes Labs 우수사례를 참조하세요.

라이선싱 옵션 평가

타사 워크로드를 Google Cloud로 마이그레이션할 때 사용자 라이선스 사용(BYOL)을 통해 비용을 절감할 수 있습니다. 예를 들어 Microsoft Windows Server VM을 배포하기 위해 타사 라이선스에 대한 추가 비용이 발생하는 프리미엄 이미지를 사용하는 대신 커스텀 Windows BYOL 이미지를 만들고 사용할 수 있습니다. 그런 다음 Google Cloud에서 사용하는 VM 인프라에 대해서만 비용을 지불합니다. 이 전략은 타사 라이선스에 대한 기존 투자의 가치를 지속적으로 실현하는 데 도움이 됩니다.

BYOL 접근 방법을 사용하도록 결정한 경우에는 다음을 수행하는 것이 좋습니다.

• 커스텀 머신 유형을 사용하여 메모리와 독립적으로 필요한 수의 컴퓨팅 CPU 코어를 프로비저닝하고 타사 라이선스 비용을 필요한 CPU 코어 수로 제한합니다.
• 동시 멀티스레딩(SMT)을 사용 중지해서 코어당 vCPU 수를 2개에서 1개로 줄이고 라이선싱 비용을 50% 줄입니다.

타사 워크로드에 보안 또는 규정 준수 요구사항을 충족하기 위한 전용 하드웨어가 필요한 경우 단독 테넌트 노드로 사용자 라이선스를 사용할 수 있습니다.

Google Kubernetes Engine

이 섹션에서는 GKE 리소스 비용 최적화 안내를 제공합니다.

다음 권장사항 외에도 앞서 설명한 일반 권장사항을 참조하세요.

• GKE Autopilot을 사용해서 GKE가 클러스터 인프라 효율을 극대화할 수 있게 해줍니다. 노드 상태를 모니터링하거나, 적재를 처리하거나, 워크로드에 필요한 용량을 계산할 필요가 없습니다.
• 워크로드의 요구사항에 따라 수평형 포드 자동 확장 처리(HPA), 수직형 포드 자동 확장 처리(VPA), 클러스터 자동 확장 처리(CA) 또는 노드 자동 프로비저닝를 사용하여 GKE 자동 확장을 미세 조정합니다.
• 시작 지연 시간에 민감하지 않은 일괄 워크로드의 경우 최적화 사용률 자동 확장 프로필을 사용하여 클러스터 사용률을 개선합니다.
• 노드 자동 프로비저닝을 사용하여 GKE 클러스터 자동 확장 처리를 확장하고, 오버프로비저닝 없이 보류 중인 포드의 사양에 따라 노드 풀을 효율적으로 만들고 삭제합니다.
• 별도의 노드 풀, 즉 고정 로드를 위한 고정 노드 풀과 동적 로드를 위한 클러스터 자동 확장 그룹이 있는 동적 노드 풀을 사용합니다.
• 포드가 내결함성이 있고 25초 이내에 정상적으로 종료될 수 있는 경우 Kubernetes 노드 풀에 Spot VM을 사용합니다. 이 전략을 GKE 클러스터 자동 확장 처리와 함께 사용하면 저비용 VM(이 경우 Spot VM이 있는 노드 풀)의 노드 풀이 먼저 확장되도록 할 수 있습니다.
• 비용 효율적인 머신 유형(예: E2, N2D, T2D)을 선택합니다. 20~40% 더 높은 가격 대비 성능을 제공합니다.
• GKE 사용량 측정을 사용해서 네임스페이스 및 라벨별로 클러스터 사용 프로필을 분석합니다. 소비량이 가장 많은 팀 또는 애플리케이션, 갑작스러운 사용량 또는 비용 증가를 일으킨 환경 또는 구성요소, 리소스를 낭비하는 팀을 식별합니다.
• 멀티 테넌트 클러스터에서 리소스 할당량을 사용하면 임의의 테넌트가 자신에게 할당된 클러스터 리소스까지만 사용하도록 제한할 수 있습니다.
• 영업시간 이후에 개발 및 테스트 환경의 자동 축소를 예약합니다.
• 권장사항에 따라 GKE에서 비용 최적화된 Kubernetes 애플리케이션을 실행합니다.

Cloud Run

이 섹션에서는 Cloud Run 리소스 비용을 최적화하는 데 도움이 되는 안내를 제공합니다.

다음 권장사항 외에도 앞서 설명한 일반 권장사항을 참조하세요.

• 동시 설정(기본값: 80)을 조정해서 비용을 낮춥니다. Cloud Run은 CPU 및 메모리 사용량에 따라 인스턴스로 전송할 요청 수를 결정합니다. 요청 동시 실행을 늘리면 필요한 인스턴스 수를 줄일 수 있습니다.
• 배포할 수 있는 인스턴스 수에 한도를 설정합니다.
• 청구 가능한 인스턴스 시간 측정항목을 사용하여 필요한 인스턴스 수를 예상합니다. 예를 들어 측정항목에 100s/s가 표시되면 약 100개 인스턴스가 예약된 것입니다. 성능 보존을 위해 30% 버퍼를 추가합니다. 즉, 100s/s 트래픽에 대해 인스턴스를 130개로 조정합니다.
• 콜드 스타트로 인한 영향을 줄이기 위해 최소 인스턴스 수를 구성합니다. 이러한 인스턴스가 유휴 상태이면 1/10의 비용이 청구됩니다.
• CPU 사용량을 추적하고 그에 따라 CPU 한도를 조정합니다.
• 트래픽 관리를 사용하여 비용 최적화 구성을 결정합니다.
• 정적 애셋 제공을 위해 Cloud CDN 또는 Firebase 호스팅을 사용합니다.
• 요청을 전역으로 처리하는 Cloud Run 앱의 경우, 대륙 간 데이터 전송에 많은 비용이 들 수 있으므로 여러 리전에 앱을 배포하는 것이 좋습니다. 이 설계는 부하 분산기 및 CDN을 사용하는 경우에 권장됩니다.
• 시작 시간도 청구 가능하므로 인스턴스의 시작 시간을 줄입니다.
• 약정 사용 할인을 구매하면 1년 약정으로 주문형 가격에서 최대 17% 절약할 수 있습니다.

Cloud Functions

이 섹션에서는 Cloud Functions 리소스 비용을 최적화하는 데 도움이 되는 안내를 제공합니다.

다음 권장사항 외에도 앞서 설명한 일반 권장사항을 참조하세요.

• 함수의 실행 시간을 관찰합니다. 실험 및 벤치마크를 진행해서 필요한 성능 기준점을 충족하는 가장 작은 함수를 설계합니다.
• Cloud Functions 워크로드가 계속 실행되는 경우 GKE 또는 Compute Engine을 사용하여 워크로드를 처리하는 것이 좋습니다. 컨테이너 또는 VM은 항상 실행되는 워크로드를 위한 저비용 옵션입니다.
• 공존 가능한 함수 인스턴스 수를 제한합니다.
• 함수 워크로드에 따라 Cloud Functions 프로그래밍 언어의 런타임 성능을 벤치마크합니다. 컴파일된 언어의 프로그램에 더 이상 콜드 스타트가 지원되지 않지만 더 빠르게 실행됩니다. 통합 언어로 된 프로그램은 실행 속도가 느리지만 콜드 스타트 오버헤드가 작습니다. 자주 실행되는 짧고 간단한 함수는 인터프리트 언어에서 비용을 줄여줄 수 있습니다.
• 인메모리 파일 시스템인 로컬 디스크에 기록된 임시 파일을 삭제합니다. 임시 파일은 함수에 할당된 메모리를 사용하며 경우에 따라 호출 간에 그대로 유지됩니다. 이 파일을 삭제하지 않으면 메모리 부족 오류가 발생하여 콜드 스타트가 트리거되면서 실행 시간과 비용이 늘어날 수 있습니다.

App Engine

이 섹션에서는 App Engine 리소스의 비용을 최적화하는 데 도움이 되는 안내를 제공합니다.

다음 권장사항 외에도 앞서 설명한 일반 권장사항을 참조하세요.

• 트래픽 및 요청 지연 시간을 기준으로 최대 인스턴스를 설정합니다. App Engine은 일반적으로 애플리케이션에 수신되는 트래픽에 따라 용량을 확장합니다. App Engine이 만들 수 있는 인스턴스 수를 제한하여 비용을 제어할 수 있습니다.
• 애플리케이션에 사용 가능한 메모리 또는 CPU를 제한하려면 인스턴스 클래스를 설정합니다. CPU 집약적인 애플리케이션의 경우 더 많은 CPU를 할당합니다. 몇 가지 구성을 테스트해서 최적 크기를 결정합니다.
• 여러 프로그래밍 언어로 App Engine 워크로드를 벤치마크합니다. 예를 들어 한 언어로 구현된 워크로드가 다른 언어로 동일하게 프로그래밍된 워크로드보다 태스크를 시간 내에 완료하는 데 필요한 인스턴스와 비용이 더 낮을 수 있습니다.
• 콜드 스타트를 줄일 수 있도록 최적화합니다. 가능한 경우 전역 범위에서 발생하는 CPU 집약적인 태스크 또는 장기 실행 태스크를 줄입니다. 태스크를 요청 컨텍스트에서 '지연 로드'될 수 있는 더 작은 작업들로 세분화합니다.
• 트래픽 급증이 예상될 경우 사전 워밍되는 유휴 인스턴스 수를 최소한으로 구성합니다. 트래픽이 예상되지 않을 때는 최소 유휴 인스턴스를 0으로 구성할 수 있습니다.
• 성능과 비용을 균형적으로 조정하기 위해 구성이 각기 다른 두 버전 간에 트래픽을 분할하여 A/B 테스트를 실행합니다. 각 버전의 성능 및 비용을 모니터링하고 필요에 따라 조정하고, 트래픽을 전송할 구성을 결정합니다.
• 요청 동시 실행을 구성하고 최대 동시 요청 수를 기본값보다 높게 설정합니다. 각 인스턴스가 동시에 처리할 수 있는 요청 수가 늘어날수록 트래픽 제공을 위한 기존 인스턴스 사용 효율이 늘어납니다.

다음 단계

• GKE 리소스 비용 최적화에 대해 알아보세요.
  • GKE에서 비용 최적화된 Kubernetes 애플리케이션 실행: 권장사항
  • 프로비저닝 중 GKE 감소 권장사항
  • 노드 자동 프로비저닝을 사용하여 멀티 테넌트 GKE 클러스터에서 리소스 사용 최적화
  • 사용량이 많지 않은 시간대에 GKE 클러스터 축소를 통한 비용 절감
  • 비용 최적화된 Spot VM을 사용하여 GKE에서 웹 애플리케이션 실행
  • GitLab을 사용하여 개발 주기 초반에 GKE 비용 예측
  • 동영상 시리즈: GKE 비용 최적화
  • 학습: GKE 비용 최적화
• Cloud Run 및 Cloud Functions 리소스 비용을 최적화하는 방법을 알아보세요.
  • 완전 관리형 애플리케이션으로 비용 및 안정성 관리
  • 완전 관리형 애플리케이션의 장기 비용 관리 최적화
  • 새로운 약정 사용 할인으로 Cloud Run 투자 극대화
• 스토리지, 데이터베이스, 네트워킹, 운영 비용 최적화
  • 비용 최적화: 스토리지
  • 비용 최적화: 데이터베이스 및 스마트 분석
  • 비용 최적화: 네트워킹
  • 비용 최적화: Cloud 운영
• Google Cloud 아키텍처 프레임워크의 다른 카테고리 살펴보기

비용 최적화: 스토리지

Google Cloud 아키텍처 프레임워크의 이 문서에서는 Cloud Storage, Persistent Disk, Filestore 리소스의 사용량 및 비용을 최적화하기 위한 권장사항을 제공합니다.

이 섹션의 안내는 클라우드에서 워크로드의 스토리지 프로비저닝 및 관리를 담당하는 설계자와 관리자를 대상으로 합니다.

참고 워크로드에 적합한 스토리지 서비스를 선택하는 방법은 클라우드 워크로드에 최적화된 스토리지 전략 설계를 참조하세요.

Cloud Storage

워크로드를 위해 Cloud Storage를 계획할 경우 성능, 데이터 보관, 액세스 패턴의 요구사항을 고려하세요.

스토리지 클래스

다음 표와 같이 워크로드의 데이터 보관 및 액세스 빈도 요구사항에 적합한 스토리지 클래스를 선택합니다.

스토리지 요구사항	권장사항
자주 액세스하는 데이터(처리량 분석 또는 데이터 레이크, 웹사이트, 스트리밍 동영상, 모바일 앱)	표준 스토리지
자주 액세스하지 않는 데이터를 최소 30일 동안 저장할 수 있는 저비용 스토리지(예: 백업 및 롱테일 멀티미디어 콘텐츠)	Nearline Storage
최소 90일 동안 저장할 수 있는 자주 액세스하지 않는 데이터(예: 재해 복구를 위한 데이터 복제본)	Coldline Storage
최소 365일 동안 저장할 수 있는 자주 액세스하지 않는 데이터에 대한 가장 저렴한 스토리지(예: 법적 및 규제용 보관 파일)	Archive Storage

참고 Nearline, Coldline, Archive 스토리지 클래스는 Standard Storage보다 저렴하지만 더 높은 검색 비용과 조기 삭제 페널티가 발생합니다.

위치

성능, 가용성, 데이터 중복성에 대한 요구사항에 따라 버킷의 위치를 선택합니다.

• 리전은 리전이 최종 사용자와 가까울 때 권장됩니다. 특정 리전을 선택하면 해당 리전 내에서 중복성이 보장됩니다. 리전은 특정 지리적 영역 내에 있는 사용자가 자주 액세스하는 데이터 세트에 대해 빠르고, 중복성이 잇고, 저렴한 비용의 스토리지를 제공합니다.
• 멀티 리전은 분산 사용자에게 고가용성을 제공합니다. 하지만 스토리지 비용은 리전보다 높습니다. 멀티 리전 버킷은 콘텐츠 제공 사용 사례와 하위 분석 워크로드에 권장됩니다.
• 이중 리전은 고가용성 및 데이터 중복성을 제공합니다. 고성능 분석 워크로드와 컴퓨팅 및 스토리지를 여러 위치에 배치한 실제 활성-활성 버킷이 필요한 사용 사례에는 이중 리전 버킷을 사용하는 것이 좋습니다. 이중 리전을 사용하면 데이터가 저장되는 위치를 선택할 수 있으므로 규정 준수 요구사항을 충족할 수 있습니다. 예를 들어 이중 리전 버킷을 사용하여 클라우드의 데이터 복사본 간의 물리적 거리와 관련된 업종별 요구사항을 충족할 수 있습니다.

수명 주기 정책

수명 주기 정책을 정의하여 Cloud Storage에서 객체의 스토리지 비용을 최적화합니다. 이러한 정책은 특정 객체의 스토리지 클래스를 자동으로 다운로드하거나 설정한 조건에 따라 객체를 삭제하여 비용을 절약할 수 있게 해줍니다.

객체가 액세스되는 빈도 및 보관해야 할 기간에 따라 수명 주기 정책을 구성합니다. 다음은 수명 주기 정책의 예시입니다.

• 다운그레이드 정책: 데이터 세트가 자주 액세스되지만 약 3개월 정도만 액세스될 것으로 예상됩니다. 이 데이터 세트의 스토리지 비용을 최적화하려면 Standard Storage를 사용하고 90일이 지난 객체를 Coldline Storage로 다운그레이드하도록 수명 주기 정책을 구성합니다.

• 삭제 정책: 특정 현지 법규를 충족시키기 위해 데이터 세트를 365일 동안 보관해야 하고, 이후에는 삭제할 수 있습니다. 365일 넘게 경과된 객체를 삭제하도록 정책을 구성합니다.

  (법률 또는 규정 준수를 위해) 특정 기간 동안 보관해야 하는 데이터가 해당 날짜 또는 시간 전에 삭제되지 않도록 하려면 보관 정책 잠금을 구성합니다.

참고: 장기 스토리지 클래스(Nearline, Coldline, Archive)는 Standard Storage와 비교하여 더 높은 검색 비용과 조기 삭제 페널티가 발생합니다. 장기 스토리지 클래스에 저장된 데이터에 자주 액세스해야 할 경우에는 액세스 비용이 늘어나지 않도록 데이터를 Standard Storage 버킷에 복사할 수 있습니다.

책무성

운영 요금, 네트워크 비용, 데이터 검색 비용의 책임을 지우려면 적절한 방식으로 요청자 지불 구성을 사용합니다. 이 구성을 사용하면 소유자가 아닌 데이터를 사용하는 부서 또는 팀에 비용이 부과됩니다.

모든 버킷 및 객체에 대해 비용 추적 라벨을 일관적으로 정의하고 할당합니다. 가능한 경우 라벨 지정을 자동화합니다.

중복

데이터 중복 없이 필요한 스토리지 중복성을 유지하려면 다음 기법을 사용하세요.

• 단일 정보 소스를 통해 데이터 복원력을 유지하려면 여러 버킷에 데이터의 중복 사본이 아닌 이중 리전 또는 멀티 리전 버킷을 사용합니다. 이중 리전 및 멀티 리전 버킷은 리전 간 중복성을 제공합니다. 데이터가 2개 이상 위치에 비동기식으로 복제되고 리전별 장애로부터 보호됩니다.
• 객체 버전 관리를 사용 설정하는 경우 새 버전이 이전 버전이 될 때 가장 오래된 객체 버전을 삭제하기 위해 수명 주기 정책을 정의하는 것이 좋습니다. 객체의 각 이전 버전은 서비스 중인 객체 버전과 동일한 요금이 청구됩니다.
• 더 이상 필요하지 않으면 객체 버전 관리 정책을 사용 중지합니다.
• 백업 및 스냅샷 보관 정책을 주기적으로 검토하고 불필요한 백업 및 데이터 보관을 방지하도록 조정합니다.

Persistent Disk

Compute Engine에서 배포하는 모든 VM 인스턴스에는 부트 디스크와 하나 이상의 데이터 디스크(선택사항)가 포함됩니다. 각 디스크는 프로비저닝된 크기, 리전, 디스크 유형에 따라 비용을 발생시킵니다. 스냅샷 크기에 따라 디스크에 사용하는 모든 스냅샷에 비용이 발생합니다.

다음 설계 및 운영 권장사항에 따라 영구 디스크 비용을 최적화합니다.

• 디스크 공간을 과도하게 할당하지 않습니다. 프로비저닝 후에는 디스크 용량을 줄일 수 없습니다. 작은 디스크로 시작해서 필요할 때 크기를 늘리세요. 디스크에 저장된 데이터가 아닌 프로비저닝된 용량에 따라 영구 디스크 비용이 청구됩니다.

• 워크로드의 성능 특성과 일치하는 디스크 유형을 선택합니다. SSD는 높은 IOPS와 처리량을 제공하지만 표준 영구 디스크보다 비용이 높습니다.

• 영역별 중단에 대한 데이터 보호가 필수적일 때만 리전별 영구 디스크를 사용하세요. 리전별 영구 디스크는 리전 내 다른 영역에 복제되므로, 동일한 영역별 디스크 비용이 두 배가 발생합니다.

• Cloud Monitoring을 사용해서 영구 디스크 사용을 추적하고 사용량이 낮은 디스크에 대해 알림을 설정합니다.

• 더 이상 필요 없는 웹사이트를 삭제합니다.

• 이후에 필요할 수 있는 데이터가 포함된 디스크의 경우에는 데이터를 저비용 Cloud Storage에 보관한 후 디스크를 삭제하는 것이 좋습니다.

• 권장사항 허브에서 권장사항을 확인하고 대응하세요.

또한 고성능 스토리지에는 하이퍼디스크를 사용하고 임시 스토리지에는 이페머럴 디스크(로컬 SSD)를 사용하는 것이 좋습니다.

디스크 스냅샷은 기본적으로 증분되며, 자동으로 압축됩니다. 디스크 스냅샷 비용을 최적화하려면 다음 권장사항을 고려하세요.

• 가능한 경우 데이터를 개별 영구 디스크에 정리합니다. 그런 후 선택적으로 디스크를 백업하고 디스크 스냅샷 비용을 줄일 수 있습니다.
• 스냅샷을 만들 때는 가용성 요구사항 및 연관된 네트워크 비용에 따라 위치를 선택합니다.
• 부팅 디스크 스냅샷을 사용해서 여러 VM을 만들려는 경우 스냅샷에서 이미지를 만든 후 이 이미지를 사용해서 VM을 만듭니다. 이 방법은 스냅샷 위치와 스냅샷을 복원할 위치 간의 데이터 이동으로 인한 네트워크 비용을 방지하는 데 도움이 됩니다.
• 디스크 스냅샷의 장기 스토리지 비용을 최소화하도록 보관 정책을 설정합니다.
• 더 이상 필요하지 않으면 디스크 스냅샷을 삭제합니다. 체인의 각 스냅샷에는 이전 스냅샷에 저장된 데이터가 필요할 수 있습니다. 따라서 스냅샷을 삭제해도 스냅샷의 모든 데이터가 반드시 삭제되지는 않습니다. 스냅샷에서 데이터를 명확하게 삭제하려면 체인에서 모든 스냅샷을 삭제해야 합니다.

Filestore

Filestore 인스턴스 비용은 서비스 등급, 프로비저닝된 용량, 인스턴스가 프로비저닝된 리전에 따라 달라집니다. 다음은 Filestore 인스턴스 비용을 최적화하기 위한 설계 및 운영 상의 권장사항입니다.

• 스토리지 요구사항에 적합한 서비스 등급 및 스토리지 유형(HDD 또는 SSD)을 선택합니다.
• 용량을 과도하게 할당하지 마세요. 작은 크기로 시작해서 나중에 필요할 때 크기를 늘리세요. Filestore 청구는 저장된 데이터가 아닌 프로비저닝된 용량을 기준으로 합니다.
• 가능한 경우 데이터를 개별 Filestore 인스턴스에 구성합니다. 그런 다음 선택적으로 인스턴스를 백업하고 Filestore 백업 비용을 줄일 수 있습니다.
• 리전 및 영역을 선택할 때는 클라이언트와 동일한 영역에서 인스턴스를 만드는 것이 좋습니다. Filestore 인스턴스의 영역에서 데이터 전송 트래픽에 대한 요금이 청구됩니다.
• Filestore 백업을 저장할 리전을 결정할 때는 소스 인스턴스와 다른 리전에 백업을 저장할 때 발생하는 데이터 전송 비용을 고려하세요.
• Cloud Monitoring을 사용하여 Filestore 인스턴스 사용을 추적하고 사용량이 낮은 인스턴스에 대해 알림을 설정합니다.
• 사용량이 낮은 Filestore 인스턴스에 할당된 용량을 줄입니다. 기본 등급을 제외한 인스턴스의 용량을 줄일 수 있습니다.

다음 단계

• Cloud Storage 비용 최적화를 위한 권장사항 검토(블로그)
• 컴퓨팅 서비스, 스토리지, 데이터베이스, 네트워킹, 운영 비용 최적화:
  • 비용 최적화: 컴퓨팅, 컨테이너, 서버리스
  • 비용 최적화: 데이터베이스 및 스마트 분석
  • 비용 최적화: 네트워킹
  • 비용 최적화: Cloud 운영
• Google Cloud 아키텍처 프레임워크의 다른 카테고리 살펴보기

비용 최적화: 데이터베이스 및 스마트 분석

Google Cloud 아키텍처 프레임워크의 이 문서에서는 Google Cloud에서 데이터베이스 및 분석 워크로드의 비용을 최적화하는 데 도움이 되는 권장사항을 제공합니다.

이 섹션의 안내는 클라우드에서 데이터베이스 및 분석 워크로드를 프로비저닝하고 관리하는 설계자, 개발자, 관리자를 대상으로 합니다.

이 섹션에는 다음 제품에 대한 비용 최적화 권장사항이 포함되어 있습니다.

• Cloud SQL
• Spanner
• Bigtable
• BigQuery
• Dataflow
• Dataproc

Cloud SQL

Cloud SQL은 MySQL, PostgreSQL, SQL Server를 위한 완전 관리형 관계형 데이터베이스입니다.

사용량 모니터링

모니터링 대시보드에서 측정항목을 검토하고 배포가 워크로드 요구사항을 충족하는지 확인합니다.

리소스 최적화

다음은 Cloud SQL 리소스를 최적화하는 데 도움이 되는 권장사항입니다.

• 복구 시간 목표(RTO)와 복구 지점 목표(RPO)에 맞는 고가용성 및 재해 복구 전략을 설계합니다. 워크로드에 따라 다음을 권장합니다.
  • 짧은 RTO 및 RPO가 필요한 워크로드의 경우 고가용성 구성과 리전 장애 조치용 복제본을 사용합니다.
  • 더 긴 RTO 및 RPO를 감당할 수 있는 워크로드의 경우 자동 및 주문형 백업을 사용합니다. 그러면 장애 후 복원에 시간이 조금 더 걸릴 수 있습니다.
• 필요한 최소 스토리지 용량으로 데이터베이스를 프로비저닝합니다.
• 데이터 증가에 따라 스토리지 용량을 자동으로 확장하려면 저장용량 자동 증가 기능을 사용 설정합니다.
• 사용 사례에 적합한 스토리지 유형인 솔리드 스테이트 드라이브(SSD) 또는 하드 디스크 드라이브(HDD)를 선택합니다. 대부분의 사용 사례에서는 SSD가 가장 효율적이고 경제적인 선택입니다. 지연 시간에 민감하지 않거나 자주 액세스하지 않는 10TB 이상의 큰 데이터 세트에는 HDD가 적합할 수 있습니다.

요율 최적화

필요한 리소스를 예측할 수 있는 워크로드에는 약정 사용 할인을 구매하는 것이 좋습니다. 1년 약정의 경우 주문형 가격의 25%, 3년 약정의 경우 52%를 절약할 수 있습니다.

Spanner

Spanner는 최대 99.999%의 가용성을 제공하는 무제한 규모의 클라우드 기반 strong consistency 데이터베이스입니다.

사용량 모니터링

다음은 Spanner 리소스 사용량을 추적하는 데 도움이 되는 권장사항입니다.

• 배포를 모니터링하고 CPU 권장사항에 따라 노드 수를 구성합니다.
• 배포 알림을 설정하여 스토리지 리소스를 최적화합니다. 적절한 구성을 확인하려면 권장 노드당 한도를 참조하세요.

리소스 최적화

다음은 Spanner 리소스를 최적화하는 데 도움이 되는 권장사항입니다.

• 노드 대신 처리 단위(PU)로 리소스를 프로비저닝하여 Spanner에서 훨씬 저렴한 비용으로 보다 작은 워크로드를 실행합니다. Spanner 노드 하나는 PU 1,000개와 같습니다.
• 쿼리 최적화 도구를 사용하여 쿼리 실행 성능을 개선합니다.
• 효율적인 실행 계획을 수립하기 위한 권장사항을 따라 SQL 문을 구성합니다.
• 자동 확장 처리 도구를 사용하여 Spanner 배포의 사용 및 성능을 관리합니다. 이 도구는 인스턴스를 모니터링하고 노드를 자동으로 추가하거나 삭제하며 인스턴스가 권장 CPU 및 스토리지 한도를 초과하지 않도록 하는 데 도움이 됩니다.
• PITR(point-in-time recovery)를 사용하여 실수로 인한 삭제 또는 쓰기로부터 보호합니다. 버전 보관 기간이 긴 데이터베이스(특히 데이터를 자주 덮어쓰는 데이터베이스)는 더 많은 시스템 리소스를 사용하므로 노드가 더 필요합니다.
• 백업 전략을 검토하고 다음 옵션 중 하나를 선택합니다.
  • 백업 및 복원
  • 내보내기 및 가져오기

요율 최적화

Spanner 노드 위치를 결정할 때 Google Cloud 리전 간의 비용 차이를 고려하세요. 예를 들어 us-central1 리전에 배포된 노드의 비용은 southamerica-east1 리전의 노드보다 시간당 훨씬 저렴합니다.

Bigtable

Bigtable은 지연 시간이 짧은 대규모 워크로드를 위한 클라우드 기반 와이드 칼럼 NoSQL 저장소입니다.

사용량 모니터링

다음은 Bigtable 리소스 사용량을 추적하는 데 도움이 되는 권장사항입니다.

• 사용량 측정항목을 분석하여 리소스 최적화 기회를 파악합니다.
• Key Visualizer 진단 도구를 사용하여 Bigtable 클러스터의 핫스팟 및 핫키를 식별합니다.

리소스 최적화

다음은 Bigtable 리소스를 최적화하는 데 도움이 되는 권장사항입니다.

• 지연 시간과 스토리지 용량 간의 균형을 제공하는 CPU 및 디스크 사용량을 보장하도록 Bigtable 클러스터의 노드 수와 크기를 평가하고 조정합니다.
• Bigtable 클러스터를 프로그래매틱 방식으로 확장하여 노드 수를 자동으로 조정함으로써 가능한 한 저렴한 비용으로 성능을 유지합니다.

• 다음 고려사항에 따라 사용 사례에 가장 경제적인 스토리지 유형(HDD 또는 SSD)을 평가하세요.

  • HDD 스토리지는 SSD보다 저렴하지만 성능이 낮습니다.
  • SSD 스토리지는 HDD보다 비용이 높지만 더 빠르고 예측 가능한 성능을 제공합니다.

  많은 양의 데이터를 저장하지 않는 한 Bigtable 클러스터의 노드 비용과 관련한 HDD의 비용 절감 효과는 미미합니다. 지연 시간에 민감하지 않거나 자주 액세스하지 않는 10TB 이상의 큰 데이터 세트에는 HDD 스토리지가 적합한 경우도 있습니다.

• 가비지 컬렉션을 사용하여 만료되어 사용되지 않는 데이터를 삭제합니다.

• 핫스팟을 방지하려면 row key 설계 권장사항을 적용합니다.

• RPO에 맞는 비용 효율적인 백업 계획을 설계합니다.

• 클러스터 사용량을 줄이고 노드 수를 줄이려면 Memorystore를 사용하여 캐시 가능한 쿼리의 용량 캐시를 추가하는 것이 좋습니다.

추가 자료

• 블로그: Bigtable 비용 최적화 입문서
• 블로그: Bigtable 성능 및 비용 최적화 권장사항

BigQuery

BigQuery는 확장성과 비용 효율성이 뛰어난 멀티 클라우드 서버리스 데이터 웨어하우스로, 비즈니스 민첩성을 제공하도록 설계되었습니다.

사용량 모니터링

다음은 BigQuery 리소스 사용량을 추적하는 데 도움이 되는 권장사항입니다.

• 프로젝트 및 사용자별로 BigQuery 비용을 시각화합니다. 가장 비용이 많이 드는 쿼리를 찾아서 최적화합니다.
• INFORMATION_SCHEMA 메타데이터 테이블을 사용하여 프로젝트, 작업, 예약에서의 슬롯 사용률을 분석합니다.

리소스 최적화

다음은 BigQuery 리소스를 최적화하는 데 도움이 되는 권장사항입니다.

• 규정 준수 전략에 따라 데이터 세트 수준, 테이블 수준 또는 파티션 수준의 데이터 만료 시간을 설정합니다.
• 쿼리당 청구되는 바이트 수를 제한하여 쿼리 비용을 제한합니다. 실수를 방지하려면 사용자 수준 및 프로젝트 수준에서 비용 관리를 사용 설정합니다.
• 필요한 데이터만 쿼리합니다. 전체 쿼리 스캔을 하지 않습니다. 데이터 시맨틱스를 살펴보고 이해하려면 무료 데이터 미리보기 옵션을 사용합니다.
• 처리 비용을 줄이고 성능을 개선하려면 가능한 경우 테이블의 파티션 나누기 및 클러스터링을 수행합니다.
• 쿼리를 최대한 자주, 이른 시점에 필터링합니다.
• 여러 소스(예: Bigtable, Cloud Storage, Google Drive, Cloud SQL)의 데이터를 처리할 때 제휴 액세스 데이터 모델을 사용하고 소스에서 직접 데이터를 쿼리하여 데이터 복제를 방지합니다.
• 데이터를 복제하는 대신 BigQuery의 백업을 활용합니다. 데이터 재해 복구 시나리오를 참조하세요.

요율 최적화

다음은 BigQuery 리소스의 청구 요율을 낮추는 데 도움이 되는 권장사항입니다.

• 데이터를 수정하는 방법을 평가하고 장기 스토리지 가격을 활용합니다.
• 정액제와 주문형 가격 책정의 차이점을 검토하고 요구사항에 맞는 옵션을 선택합니다.
• 데이터 워크플로에 스트리밍 삽입 대신 일괄 로드를 사용할 수 있는지 여부를 평가합니다. BigQuery에 로드된 데이터가 즉시 소비되는 경우 스트리밍 삽입을 사용합니다.
• 성능을 높이고 데이터 검색 비용을 줄이려면 캐시 처리된 쿼리 결과를 사용하세요.

추가 자료

• BigQuery 비용 관리
• BigQuery의 비용 최적화 권장사항
• 비용 최적화 원칙의 이해(PDF)

Dataflow

Dataflow는 통합 스트림 및 일괄 데이터 처리를 위한 빠르고 경제적인 서버리스 서비스입니다.

사용량 모니터링

다음은 Dataflow 리소스 사용량을 추적하는 데 도움이 되는 권장사항입니다.

• 소규모 부하 실험을 실행하고, 작업의 최적 성능을 찾고, 처리량 요소를 추정하여 Dataflow 작업 비용을 예측합니다.
• 관측 가능성 대시보드를 사용하여 처리량 및 CPU 사용량에 대한 가시성을 높입니다.
• Dataflow 모니터링 인터페이스를 사용하여 성능, 실행, 상태 관련 파이프라인 측정항목을 관찰합니다.

리소스 최적화

다음은 Dataflow 리소스를 최적화하는 데 도움이 되는 권장사항입니다.

• 빅데이터를 효율적으로 처리하려면 Dataflow Prime을 고려하세요.
• 자동 확장 처리된 일괄 파이프라인에 가변형 리소스 예약(FlexRS)을 사용하여 일괄 처리 비용을 줄입니다. FlexRS는 고급 예약, Dataflow Shuffle, 선점형 및 일반 VM의 조합을 사용하여 일괄 파이프라인의 비용을 줄입니다.
• Persistent Disk 및 워커 노드 대신 인메모리 셔플 서비스를 사용하여 성능을 개선합니다.
• 응답성이 높은 자동 확장을 제공하고 리소스 소비를 줄이려면 파이프라인 실행을 작업자 VM에서 Dataflow 서비스 백엔드로 이동시키는 Streaming Engine을 사용합니다.
• 파이프라인에 인터넷 및 기타 Google Cloud 네트워크에 대한 액세스 권한이 필요하지 않으면 공개 IP 주소를 사용 중지합니다. 인터넷 액세스를 사용 중지하면 네트워크 비용을 줄이고 파이프라인 보안을 개선할 수 있습니다.
• Dataflow를 통한 효율적인 파이프라인 권장사항을 따릅니다.

Dataproc

Dataproc은 일괄 처리, 쿼리, 스트리밍, 머신러닝을 위한 관리형 Apache Spark 및 Apache Hadoop 서비스입니다.

다음은 Dataproc 리소스의 비용을 최적화하는 데 도움이 되는 권장사항입니다.

• 워크로드에 적합한 머신 유형을 선택합니다.
• 자동 확장 클러스터를 사용하여 수요에 맞게 자동으로 확장하고 필요한 리소스에 대해서만 비용을 지불합니다.
• 작업 완료 시 클러스터를 삭제할 수 있는 경우 관리형 클러스터 워크플로 템플릿을 사용하여 임시 클러스터를 프로비저닝하는 것이 좋습니다.
• 비활성 클러스터에 대한 요금 청구를 방지하려면 지정된 유휴 기간 후에, 지정된 시간에 또는 지정한 기간 후에 클러스터를 삭제할 수 있는 예약 삭제를 사용합니다.
• Dataproc에서 장기 실행 클러스터 빌드 권장사항을 따릅니다.
• 상시 사용하는 워크로드에 대해 약정 사용 할인을 구매합니다.

다음 단계

• 컴퓨팅 서비스, 스토리지, 네트워킹, 운영 비용 최적화:
  • 비용 최적화: 컴퓨팅, 컨테이너, 서버리스
  • 비용 최적화: 스토리지
  • 비용 최적화: 네트워킹
  • 비용 최적화: Cloud 운영
• Google Cloud 아키텍처 프레임워크의 다른 카테고리 살펴보기

비용 최적화: 네트워킹

Google Cloud 아키텍처 프레임워크의 이 문서에서는 Google Cloud에서 네트워킹 리소스의 비용을 최적화하는 데 도움이 되는 권장사항을 제공합니다.

이 섹션의 안내는 클라우드에서 워크로드의 네트워킹 프로비저닝 및 관리를 담당하는 설계자와 관리자를 대상으로 합니다.

설계 고려사항

온프레미스 네트워크와 클라우드 네트워크의 근본적인 차이점은 기존 데이터 센터의 네트워크 고정 비용과 비교할 때 클라우드의 동적 사용량 기반 비용 모델입니다.

클라우드 네트워크를 계획할 때는 다음과 같이 트래픽 방향을 기준으로 하는 가격 책정 모델을 이해하는 것이 중요합니다.

• Google Cloud의 인바운드 트래픽에는 요금이 부과되지 않습니다. Cloud Load Balancing과 같이 인바운드 트래픽을 처리하는 리소스에는 비용이 발생합니다.
• Google Cloud의 가상 머신(VM) 간 트래픽, Google Cloud에서 인터넷 및 온프레미스 호스트로의 트래픽, 온프레미스 호스트로의 트래픽을 모두 포함하는 데이터 전송 트래픽의 경우 다음 요소를 기준으로 가격이 책정됩니다.
  • 트래픽이 내부 또는 외부 IP 주소를 사용하는지 여부
  • 트래픽이 영역 또는 리전 경계를 넘는지 여부
  • 트래픽이 Google Cloud에서 나가는지 여부
  • 트래픽이 Google Cloud에서 나가기 전에 이동하는 거리

Google Cloud 내의 두 VM 또는 클라우드 리소스가 통신할 때 각 방향의 트래픽은 소스에서는 아웃바운드 데이터 전송으로 지정되고, 대상에서는 인바운드 데이터 전송으로 지정되며 그에 따라 가격이 책정됩니다.

비용에 최적화된 클라우드 네트워크를 설계할 때는 다음 요소를 고려하세요.

• 위치정보
• 네트워크 레이아웃
• 연결 옵션
• 네트워크 서비스 등급
• 로깅

이러한 요소는 다음 섹션에서 더 자세히 설명합니다.

위치정보

네트워킹 비용은 리소스가 프로비저닝된 Google Cloud 리전에 따라 달라질 수 있습니다. 리전 간 네트워크 대역폭을 분석하려면 VPC 흐름 로그와 Network Intelligence Center를 사용하면 됩니다. Google Cloud 리전 간 트래픽 흐름의 경우 트래픽이 인터넷을 통과하지 않더라도 리전의 위치에 따라 비용이 달라질 수 있습니다.

Google Cloud 리전 외에도 리소스가 배포된 영역을 고려합니다. 가용성 요구사항에 따라 내부 IP 주소를 통해 영역 내에서 비용 없이 통신하도록 애플리케이션을 설계할 수 있습니다. 단일 영역 아키텍처를 고려할 때는 가용성에 미치는 영향과 함께 네트워킹 비용 절감을 고려해야 합니다.

네트워크 레이아웃

네트워크 레이아웃, 애플리케이션과 사용자 간 트래픽이 흐르는 방식, 각 애플리케이션 또는 사용자가 소비하는 대역폭을 분석합니다. 네트워크 토폴로지 도구는 토폴로지와 관련된 네트워크 성능 측정항목에 대한 조직 차원의 뷰를 포함하여 전역 Google Cloud 배포와 공개 인터넷과의 상호작용을 포괄적으로 보여줍니다. 비효율적인 배포를 식별하고 리전 및 대륙 간 데이터 전송 비용을 최적화하는 데 필요한 조치를 취할 수 있습니다.

연결 옵션

온프레미스 환경에서 Google Cloud로 대량의 데이터(TB 또는 PB)를 자주 푸시해야 하는 경우 Dedicated Interconnect 또는 Partner Interconnect 사용을 고려하세요. 전용 연결은 공개 인터넷을 통과하거나 VPN을 사용하는 데 드는 비용과 비교할 때 더 저렴할 수 있습니다.

가능하면 비공개 Google 액세스를 사용하여 비용을 줄이고 보안 상태를 개선하세요.

네트워크 서비스 등급

Google의 프리미엄 네트워크 인프라(프리미엄 등급)는 모든 서비스에 기본적으로 사용됩니다. 높은 성능과 짧은 지연 시간이 필요하지 않은 프리미엄 리소스의 경우 표준 등급을 선택하여 비용을 줄일 수 있습니다.

서비스 등급을 선택할 때는 등급 간의 차이점과 표준 등급의 제한사항을 고려하세요. 네트워크를 애플리케이션의 요구에 맞게 미세 조정하고 지연 시간을 허용할 수 있으며 SLA가 필요하지 않은 서비스의 네트워킹 비용을 절감할 수 있습니다.

로깅

VPC 흐름 로그, 방화벽 규칙 로깅, Cloud NAT 로깅을 사용하면 네트워크 로그를 분석하고 비용 절감 기회를 파악할 수 있습니다.

VPC 흐름 로그와 Cloud Load Balancing의 경우 데이터베이스에 기록되는 로그의 양을 줄일 수 있는 샘플링을 사용 설정할 수도 있습니다. 샘플링 레이트를 1.0(모든 로그 항목 유지)에서 0.0(로그가 유지되지 않음)까지 변경할 수 있습니다. 문제 해결 또는 커스텀 사용 사례의 경우 항상 특정 VPC 네트워크 또는 서브넷에 대한 원격 분석을 수집하거나 특정 VM 인스턴스 또는 가상 인터페이스를 모니터링하도록 선택할 수 있습니다.

설계 권장사항

네트워크 트래픽을 최적화하려면 다음 작업을 수행하는 것이 좋습니다.

• 사용자층과 더 가까운 애플리케이션을 만들기 위한 솔루션을 설계합니다. Cloud CDN을 사용하여 트래픽 볼륨 및 지연 시간을 줄이고 CDN의 저렴한 가격을 활용하여 많은 사용자가 자주 액세스할 것으로 예상되는 콘텐츠를 제공할 수 있습니다.
• 최종 사용자와 멀리 있거나 높은 네트워킹 비용이 발생할 수 있는 리전 간에 데이터를 전역으로 동기화하지 마세요. 애플리케이션이 리전 내에서만 사용되는 경우 리전 간 데이터 처리를 지양합니다.
• 영역 내의 VM 간 통신이 외부에서 라우팅되지 않고 내부 IP 주소를 통해 라우팅되도록 합니다.
• 데이터 출력을 압축하여 데이터 전송 비용과 클라이언트 지연 시간을 줄입니다.
• VPC 흐름 로그를 사용하여 중요한 프로젝트의 아웃바운드 및 인바운드 트래픽 흐름을 관찰해 지출 패턴을 분석하고 비용을 관리할 수 있는 기회를 파악합니다.
• 클라우드에서 네트워크를 설계할 때는 분산 네트워크가 제공하는 고가용성과 단일 영역 또는 리전 내의 트래픽 중앙 집중화로 인한 비용 절감을 고려하세요.

네트워킹 서비스 비용을 최적화하기 위해 다음을 수행하는 것이 좋습니다.

• 서버 위치가 제약조건이 아닌 경우 다른 리전에서 비용을 평가하고 가장 비용 효율적인 리전을 선택하세요. 웹 서버 그룹에서 제공하는 콘텐츠와 같은 일반적인 아웃바운드 트래픽의 경우 서버가 프로비저닝된 리전에 따라 가격이 달라질 수 있습니다.
• 대량의 데이터를 클라우드로 자주 이동하는 비용을 줄이려면 온프레미스 네트워크와 Google Cloud 네트워크 간에 직접 연결을 사용하세요. Dedicated Interconnect 또는 Partner Interconnect를 사용하는 것이 좋습니다.
• 각 환경에 적합한 서비스 등급, 즉 개발 및 테스트 환경에는 표준 등급, 프로덕션에는 프리미엄 등급을 선택하세요.

다음 단계

• 네트워크 가격 책정 정보 검토
• 네트워킹 비용 최적화 권장사항 검토
• 컴퓨팅 서비스, 스토리지, 데이터베이스, 운영 비용 최적화:
  • 비용 최적화: 컴퓨팅, 컨테이너, 서버리스
  • 비용 최적화: 스토리지
  • 비용 최적화: 데이터베이스 및 스마트 분석
  • 비용 최적화: Cloud 운영
• Google Cloud 아키텍처 프레임워크의 다른 카테고리 살펴보기

비용 최적화: Cloud 운영

Google Cloud 아키텍처 프레임워크의 이 문서에서는 Google Cloud에서 리소스 모니터링 및 관리 비용을 최적화하는 데 도움이 되는 권장사항을 제공합니다.

이 섹션의 안내는 클라우드에서 조직 리소스의 사용량과 비용을 모니터링하고 제어하는 클라우드 사용자를 대상으로 합니다.

Google Cloud 관측 가능성은 Google Cloud에서 워크로드의 성능을 모니터링, 문제 해결, 개선하는 데 사용할 수 있는 관리형 서비스 모음입니다. 서비스로는 Cloud Monitoring, Cloud Logging, Error Reporting, Cloud Trace, Cloud Profiler가 포함됩니다. Google Cloud의 관리형 서비스가 지닌 이점 중 하나는 서비스를 사용량 기준으로 집계한다는 것입니다. 데이터 볼륨을 기준으로 사용한 만큼만 지불하면 되며 월별 무료 데이터 사용 할당량과 Google Cloud 측정항목 및 감사 로그에 대한 무제한 액세스가 제공됩니다.

Cloud Logging

다음은 Logging 작업 비용을 최적화하는 데 도움이 되는 권장사항입니다.

• 결제 보고서를 필터링하여 Logging 비용을 표시합니다.
• 불필요한 로그 항목을 제외 또는 필터링하여 수집 및 저장되는 로그의 볼륨을 줄입니다.
• Google Cloud Console에서 billing/bytes_ingested 및 billing/monthly_bytes_ingested 측정항목을 모니터링하여 제외 필터가 적절한지 확인합니다.
• 로그를 오프로드하여 저비용 스토리지로 내보냅니다.
• 타사 애플리케이션에서 로그를 스트리밍할 때 프로덕션 인스턴스에서만 Logging 에이전트를 사용하거나 더 적은 데이터를 전송하도록 구성하여 로그 볼륨을 줄입니다.

Cloud Monitoring

다음은 Monitoring 작업 비용을 최적화하는 데 도움이 되는 권장사항입니다.

• 라벨 수를 제한하여 측정항목 및 라벨 사용량을 최적화합니다. 카디널리티가 높은 라벨을 사용하지 않습니다. 예를 들어 하나의 IP 주소를 라벨로 사용하는 경우 각 IP 주소는 항목이 하나인 라벨 시리즈를 가지므로 VM이 여러 개일 때 수많은 라벨이 생성됩니다.
• 특히 비필수 환경에서는 이러한 측정항목이 필요하지 않은 애플리케이션에 대해 자세한 측정항목의 볼륨을 줄이거나 모니터링 에이전트를 삭제하세요.
• 애플리케이션이 전송하는 커스텀 측정항목 수를 줄여 수집 볼륨을 최소화합니다.

Cloud Trace

다음은 Trace 작업 비용을 최적화하는 데 도움이 되는 권장사항입니다.

• Trace를 OpenCensus trace의 내보내기 대상으로 사용하는 경우 OpenCensus의 샘플링 기능을 사용하여 수집되는 trace 볼륨을 줄입니다.
• Trace 사용량을 제한하고 할당량을 사용하여 비용을 제어합니다. Google Cloud 콘솔의 API별 할당량 페이지를 통해 스팬 할당량을 적용할 수 있습니다.

다음 단계

• Google Cloud 관측 가능성 비용 최적화
• 동영상: Google Cloud 관측 가능성 비용 관리
• 컴퓨팅 서비스, 스토리지, 데이터베이스, 네트워킹 비용 최적화:
  • 비용 최적화: 컴퓨팅, 컨테이너, 서버리스
  • 비용 최적화: 스토리지
  • 비용 최적화: 데이터베이스 및 스마트 분석
  • 비용 최적화: 네트워킹
• Google Cloud 아키텍처 프레임워크의 다른 카테고리 살펴보기

Google Cloud 아키텍처 프레임워크: 성능 최적화

Google Cloud 아키텍처 프레임워크의 이 카테고리는 Google Cloud에서 워크로드 성능을 최적화하기 위한 성능 최적화 프로세스 및 권장사항에 대해 설명합니다.

이 문서의 정보는 Google Cloud에서 워크로드를 계획, 설계, 배포, 관리하는 설계자, 개발자, 관리자를 대상으로 합니다.

클라우드에서 워크로드의 성능을 최적화하면 조직을 효율적으로 운영하고 고객 만족도를 높이고 수익을 높이며 비용을 절감할 수 있습니다. 예를 들어 애플리케이션의 백엔드 처리 시간이 단축되면 사용자의 응답 시간이 빨라져 사용자 유지율과 수익이 증가할 수 있습니다.

성능과 비용 간에 절충점이 있을 수 있습니다. 그러나 때로는 성능을 최적화하면 비용을 절감할 수 있습니다. 예를 들어 자동 확장은 리소스가 과부하되지 않도록 하여 부하가 증가할 때 예측 가능한 성능을 제공하는 데 도움이 됩니다. 자동 확장을 사용하면 미사용 리소스를 삭제하여 부하가 낮은 기간에도 비용을 절감할 수 있습니다.

아키텍처 프레임워크의 이 카테고리에서는 다음 작업을 수행하는 방법을 알아봅니다.

• 성능 최적화 프로세스 구현
• 성능 모니터링 및 분석
• 컴퓨팅 성능 최적화
• 스토리지 성능 최적화
• 네트워킹 성능 최적화
• 데이터베이스 성능 최적화
• 분석 성능 최적화

성능 최적화 프로세스

Google Cloud 아키텍처 프레임워크의 이 문서에서는 성능 최적화 프로세스를 간략히 설명합니다.

성능 최적화는 일회성 활동이 아닌 연속적인 프로세스입니다. 다음 다이어그램은 성능 최적화 프로세스의 단계를 보여줍니다.

다음은 성능 최적화 프로세스의 단계를 간략하게 보여줍니다.

성능 요구사항 정의

클라우드로 배포하거나 마이그레이션하려는 애플리케이션을 설계하고 개발하기 전에 성능 요구사항을 결정합니다. 프런트엔드 부하 분산, 웹 또는 애플리케이션 서버, 데이터베이스, 스토리지 등 애플리케이션 스택의 각 레이어에 대한 요구사항을 최대한 세부적으로 정의합니다. 예를 들어 스택의 스토리지 레이어인 경우 애플리케이션에 필요한 처리량 및 초당 I/O 작업 수(IOPS)를 변경할 수 있습니다.

애플리케이션 설계 및 배포

성능 요구사항을 충족하는 데 도움이 될 수 있는 탄력적이고 확장 가능한 설계 패턴을 사용하여 애플리케이션을 설계합니다. 탄력적이고 확장 가능한 애플리케이션을 설계하기 위한 다음 가이드라인을 고려하세요.

• 최적의 콘텐츠 배치를 위해 워크로드를 설계합니다.
• 읽기 및 쓰기 트래픽을 격리합니다.
• 정적 및 동적 트래픽을 격리합니다.
• 콘텐츠 캐싱을 구현합니다. 내부 레이어에 데이터 캐시를 사용합니다.
• 관리형 서비스 및 서버리스 아키텍처를 사용합니다.

Google Cloud는 다른 클라우드 플랫폼과 비교하여 Google Cloud 서비스의 성능을 벤치마킹하는 데 사용할 수 있는 오픈소스 도구를 제공합니다.

성능 모니터링 및 분석

애플리케이션을 배포한 후 로그 및 알림을 사용하여 성능을 지속적으로 모니터링하고, 데이터를 분석하고, 성능 문제를 파악합니다. 애플리케이션 성장 및 발전에 따라 성능 요구사항을 다시 평가합니다. 성능을 유지하거나 개선하려면 애플리케이션의 일부를 다시 설계해야 할 수 있습니다.

성능 최적화

애플리케이션 성능 및 요구사항 변화에 따라 현재 성능 요구사항을 충족하도록 Cloud 리소스를 구성합니다. 예를 들어 리소스 크기를 조정하거나 자동 확장을 설정합니다. 리소스를 구성할 때 성능 최적화에 도움이 될 수 있는 최근에 출시된 Google Cloud 기능 및 서비스를 사용할 수 있는 기회를 평가합니다.

성능 최적화 프로세스는 여기에서 끝나지 않습니다. 성능 모니터링 주기를 계속하고 필요에 따라 요구사항을 다시 평가하고, 성능 유지 및 개선을 위해 Cloud 리소스를 조정합니다.

다음 단계

• 성능 모니터링 및 분석
• 컴퓨팅 성능 최적화
• 스토리지 성능 최적화
• 네트워킹 성능 최적화
• 데이터베이스 성능 최적화
• 분석 성능 최적화

성능 모니터링 및 분석

Google Cloud 아키텍처 프레임워크의 이 문서에서는 워크로드의 성능을 기록, 모니터링, 분석하는 데 사용할 수 있는 Google Cloud 운영 제품군의 서비스를 설명합니다.

성능 측정항목 모니터링

Cloud Monitoring을 사용하여 성능 측정항목의 추세를 분석하고, 실험의 효과를 분석하고, 중요한 측정항목에 대한 알림을 정의하고, 소급 분석을 수행할 수 있습니다.

중요 데이터 및 이벤트 로깅

Cloud Logging은 로그 데이터 및 이벤트를 저장, 분석, 모니터링하고 알림을 설정하는 데 사용할 수 있는 통합 로깅 서비스입니다. Cloud Logging은 Google Cloud 및 기타 클라우드 제공업체 서비스에서 로그를 수집할 수 있습니다.

코드 성능 분석

코드의 성능이 낮으면 애플리케이션의 지연 시간과 실행 비용이 증가할 수 있습니다. Cloud Profiler를 사용하면 애플리케이션에서 CPU나 메모리를 집중적으로 사용하는 함수의 성능을 지속적으로 분석하여 성능 문제를 파악하고 해결할 수 있습니다.

지연 시간 데이터 수집

복잡한 애플리케이션 스택과 마이크로서비스 기반 아키텍처에서는 서비스 간 통신의 지연 시간을 평가하고 성능 병목 현상을 식별하기가 어려울 수 있습니다. Cloud Trace 및 OpenTelemetry 도구를 사용하면 대규모 배포에서 지연 시간 데이터를 수집할 수 있습니다. 이러한 도구는 효율적인 지연 시간 데이터 분석에도 도움이 됩니다.

네트워크 성능 모니터링

Network Intelligence Center의 성능 대시보드는 Google 네트워크와 프로젝트 리소스의 성능 측정항목을 포괄적으로 보여줍니다. 이러한 측정항목은 네트워크 관련 성능 문제의 원인을 파악하는 데 도움이 될 수 있습니다. 예를 들어 성능 문제의 원인이 프로젝트의 문제인지 아니면 Google 네트워크의 문제인지를 확인할 수 있습니다.

다음 단계

• Cloud 리소스 모니터링 권장사항 알아보기
• Google Cloud 리소스의 성능 최적화를 위한 권장사항 검토:
  • 컴퓨팅 성능 최적화
  • 스토리지 성능 최적화
  • 네트워킹 성능 최적화
  • 데이터베이스 성능 최적화
  • 분석 성능 최적화

컴퓨팅 성능 최적화

Google Cloud 아키텍처 프레임워크의 이 문서에서는 Compute Engine, Google Kubernetes Engine(GKE), 서버리스 리소스의 성능을 최적화하는 데 도움이 되는 권장사항을 제공합니다.

Compute Engine

이 섹션에서는 Compute Engine 리소스의 성능을 최적화하는 데 도움이 되는 안내를 제공합니다.

리소스 자동 확장

관리형 리소스 그룹(MIG)을 사용하면 Compute Engine VM에 배포된 스테이트리스(Stateless) 앱을 효율적으로 확장할 수 있습니다. 자동 확장을 사용하면 부하가 증가해도 앱에서 계속 예측 가능한 성능을 제공할 수 있습니다. MIG에서 Compute Engine VM 그룹은 사용자가 정의한 템플릿을 기반으로 시작됩니다. 템플릿에서 자동 확장 처리가 그룹 확장에 사용하는 하나 이상의 신호를 지정하는 자동 확장 정책을 구성합니다. 자동 확장 신호는 시작 시간 또는 기간과 같이 일정을 기준으로 하거나 평균 CPU 사용률과 같은 목표 측정항목을 기반으로 합니다. 자세한 내용은 인스턴스 그룹 자동 확장을 참조하세요.

SMT 중지

Compute Engine VM에 할당하는 각 가상 CPU(vCPU)는 단일 하드웨어 멀티 스레드로 구현됩니다. 기본적으로 2개의 vCPU가 물리적 CPU 코어를 공유합니다. 이 아키텍처를 동시 멀티 스레딩 (SMT)이라고 합니다.

병렬이거나 부동 소수점 계산을 수행하는 워크로드(예: 트랜스코딩, Monte Carlo 시뮬레이션, 유전 서열 분석, 금융 리스크 모델링)의 경우 SMT를 중지하면 성능을 개선할 수 있습니다. 자세한 내용은 코어당 스레드 수 설정을 참조하세요.

GPU 사용

머신러닝 및 시각화와 같은 워크로드의 경우 VM에 그래픽 처리 단위(GPU)를 추가할 수 있습니다. Compute Engine은 패스 스루 모드의 NVIDIA GPU를 제공하여 VM이 GPU 및 관련 메모리를 직접 제어할 수 있도록 합니다. 3D 시각화와 같은 그래픽 집약적인 워크로드의 경우 NVIDIA RTX 가상 워크스테이션을 사용할 수 있습니다. 워크로드를 배포한 후 GPU 사용량을 모니터링하고 GPU 성능 최적화 옵션을 검토합니다.

컴퓨팅 최적화 머신 유형 사용

게임, 미디어 트랜스코딩, 고성능 컴퓨팅(HPC)과 같은 워크로드는 높은 CPU 코어당 성능을 지속적으로 요구합니다. 이러한 워크로드를 실행하는 VM의 경우 컴퓨팅 최적화 머신 유형을 사용하는 것이 좋습니다. 컴퓨팅 최적화 VM은 최적의 신뢰할 수 있는 성능을 위해 비균일 메모리 액세스(NUMA)와 같은 기능을 사용하는 아키텍처를 기반으로 합니다.

긴밀하게 결합된 HPC 워크로드에는 최고의 성능 효율성을 달성하는 데 필요한 고유한 요구사항이 있습니다. 자세한 내용은 다음 문서를 참조하세요.

• HPC 워크로드용 병렬 파일 시스템
• 아키텍처: DDN EXAScaler를 사용하는 Google Cloud의 Lustre 파일 시스템

적합한 스토리지 선택

Google Cloud는 영구 디스크, 로컬 솔리드 스테이트 드라이브(SSD) 디스크, Filestore, Cloud Storage 등 다양한 Compute Engine VM용 스토리지 옵션을 제공합니다. 이러한 각 스토리지 옵션의 성능을 최적화하기 위한 설계 권장사항은 스토리지 성능 최적화를 참조하세요.

Google Kubernetes Engine

이 섹션에서는 Google Kubernetes Engine(GKE) 리소스의 성능을 최적화하는 데 도움이 되는 안내를 제공합니다.

리소스 자동 확장

클러스터 자동 확장 처리 기능을 사용하여 현재 로드와 일치하도록 GKE 클러스터에서 노드 풀 크기를 자동으로 조정할 수 있습니다. 자동 확장을 사용하면 부하가 증가해도 앱에서 계속 예측 가능한 성능을 제공할 수 있습니다. 클러스터 자동 확장 처리는 실제 리소스 사용률 대신 노드에서 실행되는 포드의 리소스 요청에 따라 자동으로 노드 풀의 크기를 조절합니다. 자동 확장을 사용하는 경우 성능과 비용 간에 절충될 수 있습니다. 클러스터 자동 확장을 효율적으로 구성하기 위한 권장사항을 검토합니다.

참고: Autopilot 클러스터를 사용하면 노드 프로비저닝 또는 노드 풀 관리에 신경을 쓰지 않아도 됩니다. 노드 풀이 워크로드 요구사항에 따라 자동으로 프로비저닝되고 확장됩니다.

C2D VM 사용

C2D 머신 유형을 사용하여 컴퓨팅 집약적인 컨테이너화된 워크로드 성능을 향상시킬 수 있습니다. 노드 풀에서 C2D 머신 유형을 선택하여 GKE 클러스터에 C2D 노드를 추가할 수 있습니다.

SMT 중지

동시 멀티 스레딩(SMT)을 사용하면 일반 컴퓨팅 태스크와 높은 I/O가 필요한 워크로드의 애플리케이션 처리량을 크게 늘릴 수 있습니다. 하지만 두 가상 코어 모두의 컴퓨팅이 제약되는 워크로드의 경우 SMT로 인해 성능의 일관성이 저하될 수 있습니다. 보다 우수하고 예측 가능한 성능을 얻으려면 코어당 vCPU 수를 1로 설정하여 GKE 노드의 SMT를 중지하면 됩니다.

GPU 사용

영상 인식 및 동영상 트랜스코딩과 같은 컴퓨팅 집약적인 워크로드의 경우 GPU를 사용하는 노드 풀을 만들어 성능을 가속화할 수 있습니다. 자세한 내용은 GPU 실행을 참조하세요.

컨테이너 기반 부하 분산 사용

컨테이너 기반 부하 분산은 부하 분산기가 트래픽을 포드에 직접 균일하게 분산시킬 수 있도록 해줍니다. 이 접근 방식은 향상된 네트워크 성능과 부하 분산기 및 포드 간 네트워크 지연 시간에 대한 개선된 가시성을 제공합니다. 이러한 이점에 따라 컨테이너 기반 부하 분산이 인그레스를 통한 부하 분산에 권장되는 솔루션입니다.

압축 배치 정책 정의

밀접하게 결합된 일괄 워크로드에는 GKE 노드 풀의 노드 간 네트워크 지연 시간이 짧아야 합니다. 이러한 워크로드를 단일 영역 노드 풀에 배포하고 압축 배치 정책을 정의하여 노드가 물리적으로 서로 가까이 있도록 할 수 있습니다. 자세한 내용은 GKE 노드를 위한 압축 배치 정의를 참조하세요.

서버리스 컴퓨팅 서비스

이 섹션에서는 Google Cloud에서 서버리스 컴퓨팅 서비스(Cloud Run 및 Cloud Functions)의 성능을 최적화하는 데 도움이 되는 안내를 제공합니다. 이러한 서비스는 자동 확장 기능을 제공하며 기본 인프라에서 자동으로 확장을 처리합니다. 이러한 서버리스 서비스를 사용하면 마이크로서비스 및 함수를 확장하기 위한 작업을 줄이고 애플리케이션 수준에서 성능을 최적화하는 데 집중할 수 있습니다.

자세한 내용은 다음 문서를 참조하세요.

• Cloud Run 서비스 성능 최적화
• Cloud Run용 자바 애플리케이션 최적화
• Cloud Functions의 성능 최적화

다음 단계

스토리지, 네트워킹, 데이터베이스, 분석 리소스의 성능을 최적화하기 위한 권장사항을 검토합니다.

• 스토리지 성능 최적화
• 네트워킹 성능 최적화
• 데이터베이스 성능 최적화
• 분석 성능 최적화

스토리지 성능 최적화

Google Cloud 아키텍처 프레임워크의 이 문서에서는 Google Cloud에서 스토리지 리소스 성능을 최적화하는 데 도움이 되는 권장사항을 제공합니다.

Cloud Storage

이 섹션에서는 Cloud Storage 작업의 성능을 최적화하는 데 도움이 되는 권장사항을 제공합니다.

버킷 성능 평가

gsutil perfdiag 명령어를 사용하여 Cloud Storage 버킷 성능을 평가합니다. 이 명령어는 서로 다른 크기의 파일로 일련의 읽기 및 쓰기 요청을 전송하여 지정된 버킷의 성능을 테스트합니다. 애플리케이션의 사용 패턴과 일치하도록 테스트를 조정할 수 있습니다. 명령어로 생성되는 진단 보고서를 사용해서 성능 기대 수준을 설정하고 잠재적인 병목 현상을 식별합니다.

자주 액세스하는 객체 캐시

공개적으로 액세스할 수 있는 자주 액세스되는 객체의 읽기 지연 시간을 개선하기 위해서는 이러한 객체를 캐시하도록 구성할 수 있습니다. 캐싱으로 성능을 향상시킬 수 있지만 캐시에 오래된 객체 버전이 포함된 경우 오래된 콘텐츠가 제공될 수 있습니다.

효율적으로 요청 확장

버킷의 요청 비율이 증가함에 따라 Cloud Storage는 여러 서버에 요청 부하를 분산하여 해당 버킷에 대한 I/O 용량을 자동으로 늘립니다. 요청을 확장할 때 최적의 성능을 얻기 위해서는 요청 비율을 늘리고 부하를 고르게 분산하기 위한 권장사항을 따릅니다.

멀티스레딩 및 다중 처리 사용 설정

gsutil을 사용하여 많은 작은 파일을 업로드할 때는 -m 옵션을 사용하여 작업 성능을 향상시킬 수 있습니다. 이 옵션을 사용하면 업로드 요청이 일괄 처리된 병렬(즉, 멀티스레딩 및 다중 처리) 작업으로 구현됩니다. 고속 네트워크 연결로 작업을 수행할 때만 이 옵션을 사용합니다. 자세한 내용은 Global 명령줄 옵션의 -m 옵션 문서를 참조하세요.

대용량 파일 복합 업로드

대용량 파일을 업로드하려면 병렬 복합 업로드라는 전략을 사용할 수 있습니다. 이 전략을 사용하면 병렬로 업로드되고 클라우드에서 다시 구성되는 청크로 대용량 파일이 분할됩니다. 병렬 복합 업로드는 네트워크 대역폭 및 디스크 속도가 제한적이지 않을 때 일반적인 업로드 작업보다 속도가 빠를 수 있습니다. 그러나 이 전략은 일부 제한사항과 비용 영향이 있습니다. 자세한 내용은 병렬 복합 업로드를 참조하세요.

영구 디스크 및 로컬 SSD

이 섹션에서는 Compute Engine VM에 연결된 영구 디스크 및 로컬 SSD의 성능을 최적화하는 데 도움이 되는 권장사항을 제공합니다.

영구 디스크 및 로컬 SSD의 성능은 디스크 유형과 크기, VM 머신 유형, vCPU 수에 따라 달라집니다. 영구 디스크 및 로컬 SSD의 성능을 관리하려면 다음 안내를 따르세요.

• VM의 블록 스토리지를 프로비저닝할 때는 워크로드에 적합한 디스크 유형 및 디스크 크기를 선택합니다. 자세한 내용은 성능 요구사항을 충족하도록 디스크 구성을 참조하세요.
• 블록 스토리지 성능을 벤치마킹합니다. 자세한 내용은 다음 문서를 참조하세요.
  • 영구 디스크 성능 벤치마킹
  • 로컬 SSD 성능 벤치마킹
• 영구 디스크 및 로컬 SSD 성능을 최적화합니다. 자세한 내용은 다음 문서를 참조하세요.
  • 영구 디스크 성능 최적화
  • 로컬 SSD 성능 최적화

Filestore

이 섹션에서는 Filestore 인스턴스의 성능을 최적화하는 데 도움이 되는 권장사항을 제공합니다. Filestore를 사용하여 Compute Engine VM 및 GKE 클러스터에 대해 완전 관리형 네트워크 파일 시스템(NFS) 파일 서버를 프로비저닝할 수 있습니다.

• Filestore 인스턴스를 프로비저닝할 때는 워크로드의 성능 및 용량 요구사항을 충족하는 서비스 등급을 선택합니다.
• 캐시 종속 워크로드를 실행하는 클라이언트 VM에 대해 Filestore 인스턴스의 네트워크 성능을 최적화하는 데 도움이 되는 머신 유형을 사용합니다. 자세한 내용은 권장되는 클라이언트 머신 유형을 참조하세요.
• Linux를 실행하는 클라이언트 VM에 대해 Filestore 인스턴스 성능을 최적화하기 위해서는 특정 NFS 마운트 옵션이 권장됩니다. 자세한 내용은 Linux 클라이언트 마운트 옵션을 참조하세요.
• 네트워크 지연 시간을 최소화하려면 인스턴스를 사용하려는 위치와 가까운 리전 및 영역에 Filestore 인스턴스를 프로비저닝합니다.
• Filestore 인스턴스 성능을 모니터링하고 Cloud Monitoring을 사용하여 알림을 설정합니다.

다음 단계

컴퓨팅, 네트워킹, 데이터베이스, 분석 리소스의 성능을 최적화하기 위한 권장사항을 검토합니다.

• 컴퓨팅 성능 최적화
• 네트워킹 성능 최적화
• 데이터베이스 성능 최적화
• 분석 성능 최적화

네트워킹 및 API 성능 최적화

Google Cloud 아키텍처 프레임워크의 이 문서에서는 Google Cloud에서 네트워킹 리소스 및 API의 성능을 최적화하는 데 도움이 되는 권장사항을 제공합니다.

네트워크 서비스 등급

네트워크 서비스 등급을 사용하면 워크로드의 네트워크 비용과 성능을 최적화할 수 있습니다. 다음 등급 중에서 선택할 수 있습니다.

• 프리미엄 등급은 Google의 안정성이 높은 글로벌 백본을 사용하여 최소한의 패킷 손실과 지연 시간을 최소화하는 데 도움이 줍니다. 트래픽은 최종 사용자와 가까운 전역 에지 접속 지점(PoP)에서 Google 네트워크를 출입합니다. 최적 성능을 위해서는 프리미엄 등급을 기본 등급으로 사용하는 것이 좋습니다. 프리미엄 등급은 VM 및 부하 분산기에 대해 리전 및 전역 외부 IP 주소를 모두 지원합니다.
• 표준 등급은 리전 외부 IP 주소를 사용하는 리소스에서만 사용할 수 있습니다. 워크로드가 실행되는 Google Cloud 위치와 가장 가까운 에지 PoP에서 Google 네트워크를 출입합니다. 표준 등급 가격 책정은 프리미엄 등급보다 낮습니다. 표준 등급은 패킷 손실에 민감하지 않고 짧은 지연 시간에 대한 요구사항이 없는 트래픽에 적합합니다.

Network Intelligence Center 성능 대시보드에서 각 클라우드 리전에 대한 표준 등급 및 프리미엄 등급의 네트워크 지연 시간을 볼 수 있습니다.

점보 프레임

Virtual Private Cloud(VPC) 네트워크의 기본 최대 전송 단위(MTU)는 1,460바이트입니다. 하지만 최대 8896(점보 프레임)의 MTU를 지원하도록 VPC 네트워크를 구성할 수 있습니다.

MTU가 더 높으면 네트워크에서 동일한 데이터 양을 전송하는 데 드는 패킷이 줄어들어 TCP/IP 헤더에서 사용되는 대역폭이 줄어듭니다. 이렇게 하면 네트워크의 유효 대역폭이 높아집니다.

VPC 내 MTU와 다른 연결의 최대 MTU에 대한 자세한 내용은 VPC 문서의 최대 전송 단위 페이지를 참조하세요.

VM 성능

Compute Engine VM에는 머신 유형에 따라 달라지는 최대 이그레스 대역폭이 있습니다. 적절한 머신 유형을 선택하는 한 가지 방법은 VM에서 생성되는 트래픽 양을 고려하는 것입니다.

네트워크 대역폭 페이지에는 Compute Engine 머신 유형의 네트워크 대역폭에 대한 설명과 표가 포함되어 있습니다.

VM 간 대역폭 요구사항이 매우 높으면 Tier_1 네트워킹을 지원하는 VM을 사용하는 것이 좋습니다.

Cloud Load Balancing

이 섹션에서는 Cloud Load Balancing 인스턴스의 성능을 최적화하는 데 도움이 되는 권장사항을 제공합니다.

사용자에게 가깝게 애플리케이션 배포

사용자 트래픽이 부하 분산기에 도달할 것으로 예상되는 위치에 가까운 애플리케이션 백엔드를 프로비저닝합니다. 사용자 또는 클라이언트 애플리케이션이 워크로드 서버와 가까울수록 사용자와 워크로드 사이의 네트워크 지연 시간이 낮아집니다. 전 세계 여러 위치에서 클라이언트에 대한 지연 시간을 최소화하기 위해서는 백엔드를 여러 리전에 배포해야 할 수 있습니다. 자세한 내용은 Compute Engine 리전 선택 권장사항을 참조하세요.

적절한 부하 분산기 유형 선택

애플리케이션에 대해 선택한 부하 분산기 유형에 따라 사용자가 경험하는 지연 시간이 결정됩니다. 다양한 부하 분산기 유형의 애플리케이션 지연 시간 측정 및 최적화에 대한 자세한 내용은 부하 분산으로 애플리케이션 지연 시간 최적화를 참조하세요.

캐싱 사용 설정

콘텐츠를 더 빠르게 제공하려면 기본 외부 HTTP 부하 분산기 구성의 일부로 캐싱 및 Cloud CDN을 사용 설정합니다. 정적 응답을 캐시하는 데 필요한 응답 헤더를 전송하도록 백엔드 서버가 구성되었는지 확인합니다.

HTTPS가 필요하지 않으면 HTTP 사용

Google은 자동으로 패킷 수준에서 프록시 부하 분산기 및 백엔드 사이의 트래픽을 암호화합니다. 패킷 수준 암호화는 대부분의 용도에 대해 부하 분산기와 백엔드 중복 간에 HTTPS를 사용하여 레이어 7 암호화를 수행합니다. 부하 분산기와 백엔드 간 트래픽에는 HTTPS 또는 HTTP/2 대신 HTTP를 사용하는 것이 좋습니다. 또한 HTTP를 사용하여 백엔드 VM의 CPU 사용량을 줄일 수 있습니다. 하지만 백엔드가 인터넷 네트워크 엔드포인트 그룹(NEG)인 경우, 부하 분산기와 백엔드 간 트래픽에 HTTPS 또는 HTTP/2를 사용합니다. 이렇게 하면 공개 인터넷에서 트래픽을 안전하게 보호할 수 있습니다. 최적 성능을 위해서는 애플리케이션의 트래픽 패턴을 벤치마킹하는 것이 좋습니다.

Network Intelligence Center

Google Cloud Network Intelligence Center에서는 모든 리전 간에 Google Cloud 네트워크 성능을 포괄적으로 파악할 수 있습니다. Network Intelligence Center를 통해 지연 시간 문제가 프로젝트 또는 네트워크 문제로 인해 발생하는지 여부를 확인할 수 있습니다. 또한 이 정보를 사용하여 워크로드를 배포해야 하는 리전 및 영역을 선택하여 네트워크 성능을 최적화할 수 있습니다.

Network Intelligence Center에서 제공하는 다음 도구를 사용하여 Google Cloud 워크로드의 네트워크 성능을 모니터링하고 분석합니다.

• 성능 대시보드는 Google Cloud 리전 간, 개별 리전 간, 인터넷의 위치 간 지연 시간을 보여줍니다. 성능 대시보드는 지연 시간을 최적화하도록 워크로드를 배치할 위치를 결정하고 기본 네트워크 문제로 인해 애플리케이션 문제가 발생할 수 있는 시점을 확인하는 데 도움이 됩니다.

• 네트워크 토폴로지는 Virtual Private Cloud(VPC) 네트워크, 온프레미스 네트워크와의 하이브리드 연결, Google 관리형 서비스에 대한 연결을 시각적으로 보여줍니다. 네트워크 토폴로지는 네트워크 성능을 분석 및 이해하고 비정상적인 트래픽 패턴을 식별하는 데 사용할 수 있는 실시간 운영 측정항목을 제공합니다.

• 네트워크 분석기는 자동 구성 모니터링 및 진단 도구로, 방화벽 규칙, 경로, 구성 종속 항목, 서비스 및 애플리케이션 연결에 대한 VPC 네트워크 구성을 확인합니다. 또한 네트워크 장애를 식별하고, 근본 원인 분석 및 권장사항을 제공합니다. 네트워크 분석기는 우선순위가 지정된 통계를 제공하여 서브넷의 높은 IP 주소 사용률과 같은 네트워크 구성 문제를 분석할 수 있도록 도와줍니다.

API 게이트웨이 및 Apigee

이 섹션에서는 API 게이트웨이 및 Apigee를 통해 Google Cloud에 배포하는 API의 성능을 최적화하는 데 도움이 되는 권장사항을 제공합니다.

API 게이트웨이를 사용하면 Cloud Functions, Cloud Run, App Engine을 포함한 Google Cloud 서버리스 백엔드용 API를 만들고 관리할 수 있습니다. 이러한 서비스는 관리형 서비스이며 자동으로 확장됩니다. 그러나 이러한 서비스에 배포된 애플리케이션이 확장됨에 따라 API 게이트웨이에 대해 할당량 및 비율 제한을 늘려야 할 수 있습니다.

참고: 애플리케이션 또는 인프라를 추가 트래픽에 노출하면 애플리케이션 스택의 다음 레이어에 성능 병목 현상이 발생할 수 있습니다.

Apigee는 관리형 API 성능을 모니터링하는 데 도움이 되는 다음 분석 대시보드를 제공합니다.

• API 프록시 성능 대시보드: API 프록시 트래픽 패턴 및 처리 시간을 모니터링합니다.
• 목표 성능 대시보드: API 프록시 백엔드 대상에 대한 트래픽 패턴 및 성능 측정항목을 시각화합니다.
• 캐시 성능 대시보드: 평균 캐시 적중률 및 평균 캐시 시간 등 Apigee 캐시의 성능 측정항목을 모니터링합니다.

Apigee Integration을 사용하는 경우 통합을 빌드 및 관리할 때 시스템 구성 한도를 고려합니다.

다음 단계

컴퓨팅, 스토리지, 데이터베이스, 분석 리소스의 성능 최적화를 위한 권장사항 검토:

• 컴퓨팅 성능 최적화
• 스토리지 성능 최적화
• 데이터베이스 성능 최적화
• 분석 성능 최적화

데이터베이스 성능 최적화

Google Cloud 아키텍처 프레임워크의 이 문서에서는 Google Cloud에서 데이터베이스의 성능을 최적화하는 데 도움이 되는 권장사항을 제공합니다.

Cloud SQL

다음 권장사항은 SQL Server, MySQL, PostgreSQL 데이터베이스를 실행하는 Cloud SQL 인스턴스의 성능을 최적화하는 데 도움이 됩니다.

• SQL Server 데이터베이스의 경우 특정 매개변수를 수정하고 일부 매개변수에 대해 기본값을 보존하는 것이 좋습니다.
• MySQL 또는 PostgreSQL 데이터베이스에 대해 스토리지 유형을 선택할 때는 SSD와 HDD 스토리지 사이의 가격과 성능 절충점을 고려하세요.
• PostgreSQL 데이터베이스의 성능 문제를 식별하고 분석하려면 Cloud SQL Insights 대시보드를 사용합니다.
• SQL 쿼리를 실행할 때 성능 저하를 진단하려면 EXPLAIN 문을 사용합니다.

자세한 내용은 다음 문서를 참조하세요.

• 성능 최적화: SQL Server
• 성능 최적화: MySQL
• 성능 최적화: PostgreSQL

Bigtable

이 섹션에서는 Bigtable 인스턴스 성능을 최적화하는 데 도움이 되는 권장사항을 제공합니다.

성능 요구사항을 기반으로 용량 계획

각각 서로 다른 최적화 목표가 있는 광범위한 애플리케이션에서 Bigtable을 사용할 수 있습니다. 예를 들어 일괄 데이터 처리 작업의 경우 처리량이 지연 시간보다 더 중요할 수 있습니다. 사용자 요청을 지원하는 온라인 서비스의 경우 처리량보다 낮은 지연시간을 우선시해야 할 수 있습니다. Bigtable 클러스터의 용량을 계획할 때는 처리량과 지연 시간 간의 균형점을 고려해야 합니다. 자세한 내용은 Bigtable 용량 계획을 참조하세요.

스키마 설계 권장사항 수행

테이블을 수십억 개의 행과 수천 개의 열로 확장하여 페타바이트 단위로 데이터를 저장할 수 있습니다. Bigtable 테이블의 스키마를 디자인할 때는 스키마 설계 권장사항을 고려합니다.

성능 모니터링 및 조정

인스턴스의 CPU 및 디스크 사용량을 모니터링하고, 각 클러스터의 성능을 분석하고, 모니터링 차트에 표시되는 크기 권장사항을 검토합니다.

Spanner

이 섹션에서는 Spanner 인스턴스 성능을 최적화하는 데 도움이 되는 권장사항을 제공합니다.

핫스팟을 방지하는 기본 키 선택

핫스팟은 여러 요청을 강제로 처리하는 단일 서버입니다. 데이터베이스의 기본 키를 선택할 때는 핫스팟 방지를 위해 스키마 설계 권장사항을 따릅니다.

SQL 코딩 권장사항 수행

Spanner의 SQL 컴파일러는 사용자가 작성하는 각 선언적 SQL 문을 필수 쿼리 실행 계획으로 변환합니다. Spanner는 실행 계획을 사용하여 SQL 문을 실행합니다. SQL 문을 생성할 때는 SQL 권장사항에 따라 Spanner에 최적 성능을 제공하는 실행 계획이 사용되도록 합니다.

쿼리 옵션을 사용하여 SQL 쿼리 옵티마이저 관리

Spanner는 SQL 쿼리 옵티마이저를 사용하여 SQL 문을 효율적인 쿼리 실행 계획으로 변환합니다. 옵티마이저가 생성하는 쿼리 실행 계획은 쿼리 옵티마이저가 자체적으로 진화할 때 또는 데이터베이스 통계가 업데이트될 때 약간 변경될 수 있습니다. 쿼리 옵션을 사용하여 쿼리 옵티마이저 또는 데이터베이스 통계가 변경될 때 성능 회귀 가능성을 최소화할 수 있습니다.

쿼리 실행 계획 구조 시각화 및 조정

쿼리 성능 문제를 분석하려면 쿼리 계획 시각화 도구를 사용하여 쿼리 실행 계획의 구조를 시각화하고 조정할 수 있습니다.

작업 API를 사용하여 장기 실행 작업 관리

특정 메서드 호출의 경우 Spanner가 완료하는 데 상당 시간이 걸릴 수 있는 장기 실행 작업을 만듭니다. 예를 들어 데이터베이스를 복원할 때 Spanner는 복원 진행률을 추적하는 장기 실행 작업을 만듭니다. 장기 실행 작업의 모니터링 및 관리를 돕기 위해 Spanner에서는 작업 API가 제공됩니다. 자세한 내용은 장기 실행 작업 관리를 참조하세요.

일괄 로드 권장사항 수행

Spanner는 대용량 데이터를 일괄 로드하는 몇 가지 옵션을 제공합니다. 일괄 로드 작업의 성능은 파티션 나누기, 쓰기 요청 수, 각 요청의 크기와 같은 요인에 따라 달라집니다. 대량의 데이터를 효율적으로 로드하려면 일괄 로드 권장사항을 따르세요.

CPU 사용률 모니터링 및 제어

Spanner 인스턴스의 CPU 사용률은 요청 지연 시간에 영향을 줄 수 있습니다. 과부하된 백엔드 서버는 높은 요청 지연 시간을 일으킬 수 있습니다. Spanner는 높은 CPU 사용률 조사를 돕기 위해 CPU 사용률 측정항목을 제공합니다. 성능에 민감한 애플리케이션의 경우 educe컴퓨팅 용량을 늘려서 CPU 사용률을 줄여야할 수 있습니다.

지연 시간 문제 분석 및 해결

클라이언트가 Spanner에 리모트 프로시져 콜을 수행하면 클라이언트 라이브러리에서 먼저 API 요청이 준비됩니다. 그런 후 요청이 Google 프런트엔드 및 Cloud Spanner API 프런트엔드를 통과하여 Spanner 데이터베이스에 도달합니다. 지연 시간 문제를 분석하고 해결하려면 API 요청이 통과하는 경로의 각 세그먼트에 대해 지연 시간을 측정 및 분석해야 합니다. 자세한 내용은 Spanner 엔드 투 엔드 가이드를 참조하세요.

데이터베이스가 웜 상태에 도달한 후 애플리케이션 실행

Spanner 데이터베이스 확장에 따라 데이터의 키 공간을 분할로 나눕니다. 각 분할은 테이블의 하위 집합이 포함된 행 범위입니다. 데이터베이스에서 전체 부하를 균형 조정하기 위해 Spanner는 개별 분할을 동적으로 개별적으로 이동하고 이를 서로 다른 서버에 할당합니다. 분할이 여러 서버에 분산되면 데이터베이스가 웜 상태로 고려됩니다. 웜이 동시 로드를 극대화하고 향상된 성능을 제공할 수 있는 데이터베이스입니다. 애플리케이션을 실행하기 전 테스트 데이터 부하를 사용해서 데이터베이스를 준비하는 것이 좋습니다.

다음 단계

컴퓨팅, 스토리지, 네트워킹, 분석 리소스의 성능 최적화를 위한 권장사항 검토:

• 컴퓨팅 성능 최적화
• 스토리지 성능 최적화
• 네트워킹 성능 최적화
• 분석 성능 최적화

분석 성능 최적화

Google Cloud 아키텍처 프레임워크의 이 문서에서는 Google Cloud에서 분석 워크로드의 성능을 최적화하는 데 도움이 되는 권장사항을 제공합니다.

BigQuery

이 섹션에서는 BigQuery에서 쿼리 성능을 최적화하는 데 도움이 되는 권장사항을 제공합니다.

쿼리 설계 최적화

쿼리 성능은 쿼리가 읽고 쓰는 바이트 수, 슬롯 간에 전달되는 데이터 볼륨과 같은 요소에 따라 달라집니다. BigQuery에서 쿼리 성능을 최적화하려면 다음 문서에 설명된 권장사항을 적용합니다.

• 쿼리 성능 최적화 소개
• 입력 데이터 및 데이터 소스 관리
• 슬롯 간 통신 최적화
• 쿼리 계산 최적화
• 쿼리 출력 관리
• SQL 안티패턴 방지

효율적인 구체화된 뷰 정의 및 사용

공통 및 반복 쿼리를 사용하는 워크로드 성능을 향상시키려면 구체화된 뷰를 사용하면 됩니다. 만들 수 있는 구체화된 뷰의 개수에는 한도가 있습니다. 쿼리의 모든 치환에 대해 개별적으로 구체화된 뷰를 만들지 마세요. 대신 여러 쿼리 패턴에 사용할 수 있는 구체화된 뷰를 정의합니다.

JOIN 성능 개선

구체화된 뷰를 사용하여 JOIN 위에서 집계를 수행하는 쿼리의 비용 및 지연 시간을 줄일 수 있습니다. 큰 팩트 테이블을 몇 개의 작은 차원 테이블과 조인하고 이 조인 위에서 집계를 수행하는 경우를 가정해보세요. 먼저 외래 키를 그룹화 키로 사용해서 팩트 테이블 위에서 집계를 수행하는 쿼리를 다시 작성하는 것이 실용적일 수 있습니다. 그런 다음 결과를 차원 테이블과 조인합니다. 마지막으로 집계 후 작업을 수행합니다.

Dataflow

이 섹션에서는 Dataflow 파이프라인의 쿼리 성능을 최적화하는 데 도움이 되는 권장사항을 제공합니다.

파이프라인을 만들고 배포할 때는 Dataflow 작업자 VM에 사용해야 하는 Compute Engine 머신 유형과 같이 실행 매개변수를 구성할 수 있습니다. 자세한 내용은 파이프라인 옵션을 참조하세요.

파이프라인을 배포한 후 Dataflow는 작업 실행에 필요한 Compute Engine 및 Cloud Storage 리소스를 관리합니다. 또한 Dataflow의 다음 기능은 파이프라인 성능을 최적화하는 데 도움이 됩니다.

• 동시 로드: Dataflow는 자동으로 데이터를 분할하고 작업자 코드를 Compute Engine 인스턴스에 배포하여 동시 처리합니다. 자세한 내용은 동시 처리 및 분산을 참조하세요.
• 최적화: Dataflow는 파이프라인 코드를 사용하여 PCollection 객체 및 파이프라인의 변환을 나타내는 실행 그래프를 만듭니다. 그런 다음 가장 효율적인 성능 및 리소스 사용을 위해 그래프를 최적화합니다. Cloud Dataflow는 또한 데이터 집계와 같이 많은 비용이 들 수 있는 작업을 자동으로 최적화합니다. 자세한 내용은 융합 최적화 및 결합 최적화를 참조하세요.
• 자동 조정: Dataflow는 수평 자동 확장, 수직 자동 확장, 동적 작업 재균등화를 사용하여 작업이 실행되는 동안 작업을 동적으로 최적화합니다.

웹 기반 모니터링 인터페이스 또는 Dataflow gcloud CLI를 사용하여 Dataflow 파이프라인 성능을 모니터링할 수 있습니다.

참고: 또한 Cloud Profiler를 사용하여 대부분의 리소스를 소비하는 파이프라인 코드 부분을 식별할 수 있습니다. 자세한 내용은 파이프라인 성능 모니터링.

을 참조하세요.

Dataproc

이 섹션에서는 Dataproc 클러스터 성능을 최적화하기 위한 권장사항에 대해 설명합니다.

클러스터 자동 확장

Dataproc 클러스터가 예측 가능한 성능을 제공하는지 확인하려면 자동 확장을 사용 설정하면 됩니다. Dataproc는 Hadoop YARN 메모리 측정항목 및 사용자가 정의한 자동 확장 정책을 사용하여 클러스터에서 작업자 VM 수를 자동으로 조정합니다. 자동 확장을 사용하고 구성하는 방법은 클러스터 자동 확장을 참조하세요.

적절한 스토리지 프로비저닝

성능 및 비용 요구사항에 따라 Dataproc 클러스터에 적합한 스토리지 옵션을 선택합니다.

• 최소한의 변경으로 Hadoop 및 Spark 작업이 읽고 쓰기를 수행할 수 있는 저비용 Hadoop 호환 파일 시스템(HCFS)이 필요한 경우 Cloud Storage를 사용합니다. Cloud Storage에 저장된 데이터는 영구적이며 다른 Dataproc 클러스터 및 BigQuery와 같은 다른 제품에서 액세스할 수 있습니다.
• Dataproc 클러스터에 지연 시간이 짧은 Hadoop 분산 파일 시스템(HDFS)이 필요한 경우 워커 노드에 연결된 Compute Engine 영구 디스크를 사용합니다. HDFS 스토리지에 저장된 데이터는 일시적이며 스토리지 비용이 Cloud Storage 옵션보다 높습니다.
• Compute Engine 영구 디스크의 성능 이점과 Cloud Storage의 비용 및 내구성 이점을 얻기 위해 두 스토리지 옵션을 조합할 수 있습니다. 예를 들어 소스 및 최종 데이터 세트를 Cloud Storage에 저장하고 중간 데이터 세트에 대해 제한된 HDFS 용량을 프로비저닝할 수 있습니다. HDFS 스토리지의 디스크 크기 및 유형을 결정할 때는 영구 디스크 및 로컬 SSD 섹션의 권장사항을 고려하세요.

Cloud Storage를 사용할 때 지연 시간 감소

Cloud Storage에 저장된 데이터에 액세스할 때 지연 시간을 줄이려면 다음이 권장됩니다.

• Dataproc 클러스터와 동일한 리전에 Cloud Storage 버킷을 만듭니다.
• Cloud Storage에 저장된 Apache Hive 관리형 테이블에 대해 auto.purge를 사용 중지합니다.
• Spark SQL을 사용할 때는 사용 가능한 최신 버전의 이미지를 사용하여 Dataproc 클러스터를 만드는 것이 좋습니다. 최신 버전을 사용하면 Spark 2.x의 느린 INSERT OVERWRITE 성능과 같이 이전 버전에 있을 수 있는 성능 문제를 방지할 수 있습니다.
• Cloud Storage에 대해 서로 다른 크기 또는 작은 크기로 여러 파일을 기록할 가능성을 최소화하기 위해서는 Spark SQL 매개변수 spark.sql.shuffle.partitions 및 spark.default.parallelism 또는 Hadoop 매개변수 mapreduce.job.reduces를 구성할 수 있습니다.

스토리지 부하 및 용량 모니터링 및 조정

Dataproc 클러스터의 워커 노드에 연결된 영구 디스크에는 셔플 데이터가 포함됩니다. 최적 성능을 위해 워커 노드에는 충분한 디스크 공간이 필요합니다. 노드에 디스크 공간이 부족하면 노드가 YARN NodeManager 로그에 UNHEALTHY로 표시됩니다. 이 문제가 발생하면 영향을 받는 노드의 디스크 크기를 늘리거나 동시에 실행하는 작업 수를 줄입니다.

EFM 사용 설정

축소 또는 선점 등으로 인해 실행 중인 Dataproc 클러스터에서 워커 노드를 삭제하면 셔플 데이터가 손실될 수 있습니다. 이러한 시나리오에서 작업 지연을 최소화하기 위해서는 선점형 VM을 사용하는 클러스터 또는 보조 작업자 그룹만 자동 확장하는 클러스터에 대해 향상된 유연성 모드(EFM)를 사용 설정하는 것이 좋습니다.

다음 단계

컴퓨팅, 스토리지, 네트워킹, 데이터베이스 리소스의 성능 최적화를 위한 권장사항 검토:

• 컴퓨팅 성능 최적화
• 스토리지 성능 최적화
• 네트워킹 성능 최적화
• 데이터베이스 성능 최적화

아키텍처 프레임워크의 새로운 소식

이 문서에서는 Google Cloud 아키텍처 프레임워크의 중요 변경사항을 설명합니다.

2023년 11월 28일

• 신뢰성 카테고리:
  • 가독성 및 일관성 향상을 위해 콘텐츠 구성이 조정되었습니다.
  • SLO 정의: '용어' 섹션을 새 페이지로 이동: 용어
  • SLO 채택: 'SLO 및 알림' 섹션을 새 페이지로 이동: SLO 및 알림

2023년 11월 9일

• 시스템 설계 카테고리:
  • 클라우드 설계자가 Google Cloud의 워크로드의 배포 원형을 선택하는 데 도움이 되는 지침이 추가되었습니다.

2023년 9월 8일

• 비용 최적화 카테고리:

  • 비용 할당 및 거버넌스에 태그를 사용하는 방법에 대한 정보가 추가되었습니다.
  • 라벨 이상치 식별에 대한 지침이 업데이트되었습니다.

  자세한 내용은 태그 또는 라벨을 사용하여 비용 추적 및 할당을 참조하세요.

2023년 8월 28일

• 시스템 설계 카테고리:
  • Google Cloud의 AI 및 ML 서비스 목록이 업데이트되었습니다.

2023년 8월 23일

• 비용 최적화 카테고리:
  • 노드 대신 처리 단위를 사용하여 소규모 워크로드에 대한 Spanner 리소스 사용량을 최적화하는 방법에 대한 지침이 추가되었습니다.

2023년 8월 18일

• 보안, 개인 정보 보호, 규정 준수 카테고리:
  • HIPAA 관련 안내가 추가되었습니다.
• 운영 우수성 카테고리:
  • 최대 트래픽 이벤트 계획 권장사항이 업데이트되었습니다.

2023년 8월 9일

• 안정성 카테고리:
  • 다음 제품에 대한 안정성 관련 문서 링크가 추가되었습니다.
    • Dataproc
    • Bigtable
    • Cloud SQL
    • Spanner

2023년 7월 13일

• 시스템 설계:
  • PostgreSQL용 AlloyDB가 Google Cloud의 데이터베이스 서비스 목록에 추가되었습니다.
• 비용 최적화:
  • Persistent Disk 섹션에 Google Cloud Hyperdisk 및 로컬 SSD에 대한 안내가 추가되었습니다.

2023년 6월 23일

• 성능 최적화:
  • 점보 프레임 및 VM에 적합한 머신 유형을 사용하여 대역폭 사용량을 최적화하는 방법에 대한 지침이 추가되었습니다.

2023년 6월 15일

• 보안, 개인 정보 보호, 규정 준수:
  • Cross-Cloud Interconnect를 사용하여 온프레미스 및 멀티 클라우드 환경에 대한 연결을 보호하는 방법에 대한 지침이 추가되었습니다.
  • 방화벽 정책 및 규칙, 보안 웹 프록시를 사용하여 클라우드 워크로드 경계를 보호하는 방법에 대한 지침이 추가되었습니다.

2023년 3월 30일

• 프레임워크에 다음 두 개의 추가 SLO 문서를 추가했습니다.
  • SLO 정의
  • SLO 채택

2022년 9월 16일

• 성능 최적화 카테고리가 크게 확장되었습니다.

2022년 8월 10일

• 시스템 설계 카테고리 변경사항:
  • 시스템 설계의 핵심 원칙이 추가되었습니다.
  • Google Cloud 컨설팅 서비스를 사용하고 파트너와 협력하기 위한 권장사항이 추가되었습니다.

2022년 8월 4일

• 비용 최적화 카테고리에 다음 기능에 대한 정보가 추가되었습니다.

  • 프로젝트와 결제 계정 간의 연결을 잠가 결제 문제로 인한 서비스 중단을 방지합니다. 자세한 내용은 결제 액세스 제어 구성을 참조하세요.

  • Service Usage API를 사용하여 할당량을 줄입니다. 자세한 내용은 예산, 알림, 할당량을 참조하세요.

  • 미사용 프로젝트를 식별하고 삭제합니다. 자세한 내용은 Active Assist 권장사항을 참조하세요.

2022년 7월 13일

• 운영 우수성 카테고리 변경사항:

  • 우수성 센터를 빌드하는 방법에 대한 권장사항이 추가되었습니다.
  • 감사 추적 설정 방법에 대한 권장사항이 추가되었습니다.

2022년 6월 27일

• 보안 카테고리에 Google Cloud의 공유 책임과 공통된 운명에 대한 정보가 추가되었습니다.

2022년 6월 13일

• 시스템 설계 카테고리에 환경 지속 가능성을 위한 클라우드 워크로드를 설계하는 데 도움이 되는 권장사항이 추가되었습니다.

2022년 6월 1일

• 비용 최적화: 컴퓨팅, 컨테이너, 서버리스 섹션에 스팟 VM에 대한 정보가 추가되었습니다.

2022년 5월 7일

• Cloud Storage의 비용 최적화 권장사항에 이중 리전 위치에 대한 정보가 추가되었습니다.

2022년 5월 4일

• 제품 안정성 가이드가 추가되었습니다. 이 가이드에는 다음 제품의 안정성 권장사항이 포함되어 있습니다.

  • 컴퓨팅: Compute Engine, Cloud Run, Cloud Functions, Google Kubernetes Engine

  • 스토리지 및 데이터베이스: Cloud Storage, Firestore

  • 네트워킹: Cloud DNS, Cloud Load Balancing

  • 데이터 분석: BigQuery

2022년 2월 25일

• 보안 카테고리 변경사항:

  • 자동화를 논의하도록 규정 준수 권장사항이 업데이트되었습니다.

2021년 12월 15일

• Google Cloud 커뮤니티의 아키텍처 프레임워크 공간 출시

2021년 10월 25일

• 안정성 카테고리 변경사항:

  • 재해 복구를 위한 리전 간 데이터 복제 및 리전 중단 복원력을 위한 멀티 리전 아키텍처 설계에 대한 권장사항이 추가되었습니다.
  • 오류 예산 계산 방법 예시가 추가되었습니다.
  • 애플리케이션 및 서비스에 적합한 이름 선택을 위한 권장사항이 추가되었습니다.

2021년 10월 7일

• 모든 카테고리의 주요 새로고침

---

1. 안나 베렌베르크 및 브래드 칼더, 클라우드 애플리케이션의 배포 원형, ACM Computing Surveys, Volume 55, Issue 3, Article No.: 61, pp 1-48 ↩