기업 조직을 위한 권장사항

이 가이드에서는 귀사와 같은 기업 고객을 대상으로 Google Cloud Platform(GCP)을 이용하는 데 도움이 되는 권장사항을 소개합니다. 이 가이드는 종합적인 권장 목록이 아닙니다. 이 가이드의 목적은 기업 설계자와 기술 이해관계자가 작업의 범위를 파악하고 그에 따라 적절히 계획하는 데 도움을 제공하는 데 있습니다. 각 섹션은 주요 활동 및 자세한 내용을 볼 수 있는 링크를 제공합니다.

이 가이드를 읽기 전에 GCP에 대한 전반적인 이해를 돕기 위해 플랫폼 개요를 살펴보는 것이 좋습니다.

조직 설정

리소스 계층 구조 정의

GCP 리소스는 계층적으로 구성됩니다. 이러한 계층 구조를 통해 기업의 운영 구조를 GCP에 매핑하고 관련 리소스 그룹에 대한 액세스 제어 및 권한을 관리할 수 있습니다. 다음 다이어그램은 계층 구조의 예를 보여줍니다.

리소스가 계층적으로 구성된 역트리 구조

계층 구조의 최상위 노드는 조직(예: 회사)을 나타내는 조직 리소스입니다. 조직 리소스는 계층 구조 하위에 있는 모든 리소스를 중앙에서 보고 제어할 수 있게 해줍니다.

다음 계층 구조에는 폴더가 있습니다. 폴더를 사용하면 상위 조직의 여러 부서 및 팀에 대한 요구사항을 격리할 수 있습니다. 마찬가지로 폴더를 사용하여 프로덕션 리소스를 개발 리소스로부터 분리할 수 있습니다.

계층 구조 맨 아래에는 프로젝트가 있습니다. 프로젝트에는 앱을 구성하는 컴퓨팅, 저장소, 네트워킹 리소스가 포함됩니다. 프로젝트에 대한 자세한 내용은 이 문서의 뒷부분에서 설명합니다.

정의하는 구조는 유연하며 진화하는 요구사항에 적응할 수 있습니다. GCP를 막 시작한 경우, 초기 요구사항을 충족시키는 가장 간단한 구조를 채택하는 것이 좋습니다. 자세한 내용은 리소스 관리자 개요를 참조하세요.

조직 노드 만들기

GCP에서 지원되는 기능의 상당수에는 조직 노드가 필요합니다. Cloud ID를 통해 example.com과 같이 기업 인터넷 도메인에 매핑되는 조직 노드를 만들 수 있습니다. 기존 GCP 프로젝트와 결제 계정을 조직 노드로 이전할 수 있습니다. 자세한 내용은 조직 만들기 및 관리를 참조하세요.

설정에 도움이 필요한 경우 조직 설정 마법사를 참조하세요.

프로젝트 구조 지정

GCP를 사용하기 위해서는 프로젝트가 필요합니다. Compute Engine 가상 머신, Cloud Storage 버킷과 같은 모든 GCP 리소스는 단일 프로젝트에 속합니다. 프로젝트에 대한 자세한 내용은 플랫폼 개요를 참조하세요.

프로젝트의 범위를 직접 제어할 수 있습니다. 단일 프로젝트에 여러 개별 앱이 필요하거나, 역으로 단일 앱에 여러 개의 프로젝트가 포함될 수 있습니다. 프로젝트는 여러 지역 및 지리적 위치에 걸쳐 분산된 리소스를 포함할 수 있습니다.

이상적인 프로젝트 구조는 개별 요구사항에 따라 달라지며 시간이 지나면서 발전할 수 있습니다. 프로젝트 구조를 설계할 때는 리소스를 개별적으로 결제해야 하는지 여부, 필요한 격리 수준, 리소스와 앱을 관리하는 팀의 구성 방법을 결정하세요.

프로젝트 생성 자동화

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

GCP 프로젝트의 경우 GCP 기본 관리 도구인 Cloud Deployment Manager를 사용하세요. Cloud Deployment Manager를 사용하면 함께 배포하고자 하는 GCP 리소스 집합을 기술하는 구성 파일을 만들 수 있습니다. 재사용 가능한 리소스 구성 요소 역할을 하는 매개변수화된 템플릿을 정의할 수 있습니다. 또한 Cloud Deployment Manager는 Cloud IAM을 통해 액세스 제어 권한을 설정하여 프로젝트 생성 프로세스 중에 개발자에게 적절한 액세스 권한이 부여되도록 할 수 있습니다.

이미 Terraform, Ansible, Puppet과 같은 도구를 사용하는 경우 이러한 도구를 대신 사용할 수 있습니다. 이렇게 하면 팀이 이미 보유한 기술을 활용할 수 있습니다.

ID 및 액세스 관리

Google ID 관리

GCP는 인증 및 액세스 관리에 Google 계정을 사용합니다. 개발자 및 기타 기술 담당자에게는 GCP에 액세스하기 위한 Google 계정이 필요합니다. Cloud ID를 통해 회사 도메인 이름에 연결된 완전 관리형 Google 계정을 사용하는 것이 좋습니다. 이렇게 하면 개발자는 회사 이메일 ID를 사용하여 GCP에 액세스할 수 있으며 관리자는 관리 콘솔을 통해 계정을 보고 제어할 수 있습니다. 이 문서의 이어지는 섹션에서는 기존 ID 플랫폼을 Cloud ID와 통합하는 방법을 설명합니다.

Cloud ID는 독립형 서비스로서의 ID(IDaaS) 솔루션입니다. 이 솔루션을 통해 Cloud Platform 고객은 Google Cloud의 다양한 직장 생산성 앱 모음인 G Suite가 제공하는 다양한 ID 관리 기능에 액세스할 수 있습니다 Cloud ID에는 G Suite 라이선스가 필요 없습니다. Cloud ID에 가입하면 회사 도메인 이름과 연결된 Google 계정을 통해 관리 계층이 제공됩니다. 이 관리 계층을 통해 GCP를 포함한 Google 서비스에 대한 액세스를 사용 설정하거나 사용 중지할 수 있습니다. 또한 Cloud ID에 가입하면 도메인에 대한 조직 노드가 생성되며, 이는 회사 구조와 통제를 리소스 계층 구조를 통해 GCP 리소스에 매핑하는 데 도움이 됩니다.

자세한 내용은 Cloud ID 솔루션을 참조하세요.

기존 ID 플랫폼 동기화

조직에서 온프레미스 또는 타사 ID 플랫폼을 사용하는 경우 기존 사용자 디렉토리를 Cloud ID와 동기화하면 사용자가 회사 사용자 인증 정보로 GCP에 액세스할 수 있습니다. 이 경우 기존 ID 플랫폼은 진실의 근원 역할을 유지하며 Cloud ID는 직원이 Google 서비스에 액세스하는 방법에 대한 통제 수단을 제공합니다.

Google 클라우드 디렉토리 동기화(GCDS)를 사용하여 Active Directory, LDAP 서버의 사용자 및 그룹을 Cloud ID가 제공하는 사용자 디렉토리에 동기화합니다. GCDS는 회사 사용자 및 그룹에 해당하는 Google 계정을 프로비저닝합니다. 동기화는 단방향입니다. 즉, 디렉토리 서버의 데이터는 수정되지 않습니다. 명시적으로 구성하지 않는 한 비밀번호는 Google 디렉토리에 복사되지 않습니다.

많은 ID 관리 공급업체는 G Suite에 대한 커넥터를 제공합니다. GCP와 G Suite는 Cloud ID를 통해 공통된 ID 인프라를 공유하므로 이러한 커넥터는 GCP에도 적용됩니다.

자세한 내용은 Google Identity & Security 블로그의 Google Cloud Platform과 함께 기존 ID 관리 시스템 사용하기를 참조하세요.

싱글 사인온(SSO) 구현

기존 ID 관리 플랫폼을 Cloud ID와 통합한 후 싱글 사인온(SSO)을 설정할 수 있습니다. SSO는 사용자가 모든 서비스에 대해 한 번의 로그인으로 기업 클라우드 앱에 액세스할 수 있게 해줍니다. GCP는 기존 온프레미스 또는 타사 ID 공급업체를 대상으로 SAML 2.0 기반 SSO를 지원합니다. 사용자를 구성한 후 사용자는 Cloud Platform에 액세스하려면 먼저 ID 공급업체에 인증해야 합니다.

GCP Console과 gcloud 및 gsutil 명령줄 도구는 모두 SAML 2.0 기반 SSO를 지원합니다. 사용자가 이전에 SSO 공급업체에 인증하지 않고 직접 또는 다른 앱 액세스를 경유하여 이러한 도구에 액세스하는 경우 로그인하라는 메시지가 표시됩니다.

SSO 설정에 대한 자세한 내용은 싱글 사인온 설정을 참조하세요.

관리되지 않는 계정 이전

도메인의 구성원이 회사 이메일 주소를 사용하여 예를 들어 YouTube 또는 Blogger와 같은 Google 서비스에 가입한 경우 Cloud ID를 사용하여 해당 구성원을 관리할 수 있도록 이러한 계정을 이전하는 것이 좋습니다. 또는 다른 이메일 주소를 사용하도록 이러한 계정의 변경을 강제할 수 있습니다.

계정을 이전하는 방법 또는 계정의 이름 변경을 강제하는 방법에 대한 추가 안내는 Cloud ID 문서에서 볼 수 있습니다.

리소스 액세스 제어

개발자와 IT 담당자를 승인하여 GCP 리소스를 소비할 수 있도록 해야 합니다. Cloud Identity and Access Management(IAM)를 사용하여 특정 GCP 리소스에 대한 세분화된 액세스 권한을 부여하고 다른 리소스에 대한 원치 않는 액세스를 차단할 수 있습니다. 구체적으로, Cloud IAM은 누구(ID)에게 무슨 리소스에 대한 어떤 액세스 권한(역할)이 있는지를 정의함으로써 액세스를 제어할 수 있게 해줍니다.

직접 권한을 할당하지 않고 역할을 할당합니다. Cloud IAM 역할은 권한 모음입니다. 예를 들어 BigQuery 데이터 뷰어 역할에는 BigQuery 테이블을 나열, 읽기, 쿼리하는 권한이 포함되지만 새 테이블을 만들거나 기존 데이터를 수정하는 권한은 포함되지 않습니다. Cloud IAM은 일반적인 다양한 사용 사례를 처리하기 위한 여러 가지 사전 정의된 역할을 제공합니다. 또한 커스텀 역할을 만들 수 있게 해줍니다.

Cloud IAM을 통해 최소 권한 보안 원칙을 적용하여 리소스에 대해 필요한 액세스 권한만 부여할 수 있습니다. Cloud IAM은 기업 조직을 위한 기초적인 주제입니다. ID 및 액세스 관리에 대한 자세한 내용은 다음 리소스를 참조하세요.

그룹 및 서비스 계정을 사용하여 책임 위임

같은 책임을 가진 사용자를 그룹으로 묶고 개별 사용자가 아닌 그룹에 Cloud IAM 역할을 할당하는 것이 좋습니다. 예를 들어 '데이터 과학자' 그룹을 만들고 BigQuery 및 Cloud Storage를 다루기 위한 적절한 권한을 할당할 수 있습니다. 새 데이터 과학자가 팀에 합류할 경우 그룹에 추가만 하면 해당 과학자는 정의된 권한을 상속합니다. 관리 콘솔을 통해 그룹을 만들고 관리할 수 있습니다.

서비스 계정은 특수한 유형의 Google 계정으로, 개별 사용자가 아닌 Google Cloud 서비스 ID 또는 앱을 나타냅니다. 사용자 및 그룹과 마찬가지로 서비스 계정에 IAM 역할을 할당하여 특정 리소스에 대한 액세스 권한을 부여할 수 있습니다. 서비스 계정은은 비밀번호가 아닌 키로 인증됩니다. Google은 GCP에서 실행되는 코드에 대한 서비스 계정 키를 관리 및 순환합니다. 서버 간 상호작용에는 서비스 계정을 사용하는 것이 좋습니다.

조직 정책 정의

조직 정책 서비스를 사용하여 조직의 클라우드 리소스를 중앙에서 프로그래매틱 방식으로 제어할 수 있습니다. Cloud IAM누구에 초점을 두며, 권한을 기반으로 특정 리소스에 조치를 취하도록 사용자 및 그룹을 승인하는 기능을 제공합니다. 조직 정책은 무엇에 초점을 두며, 특정 리소스에 제한을 설정하여 구성 및 사용되는 방법을 결정하는 기능을 제공합니다. 예를 들어 제약조건을 정의하여 가상 머신 인스턴스가 외부 IP 주소를 갖지 않도록 제한할 수 있습니다.

리소스에 대한 정책은 리소스 계층 구조에서 설정합니다. 리소스의 모든 하위 요소는 기본적으로 리소스의 정책을 상속합니다. 취상위 조직 노드에 정책을 연결하여 계층 구조의 모든 요소에 적용되는 기본 제약조건 집합을 정의할 수 있습니다. 그런 다음 하위 노드에 커스텀 조직 정책을 설정할 수 있으며, 이러한 정책은 상속된 정책을 덮어쓰거나 병합됩니다.

정책 설정에 대한 자세한 내용은 기업 고객을 위한 정책 설계를 참조하세요.

네트워킹 및 보안

VPC를 사용하여 네트워크 정의

VPC와 서브넷을 사용하여 네트워크를 계획하고 관련 리소스를 그룹화 및 격리합니다. 가상 사설 클라우드(VPC)는 물리적 네트워크의 가상 버전입니다. VPC 네트워크는 Compute Engine 가상 머신(VM) 인스턴스, 그리고 Google Kubernetes Engine(GKE), Cloud Dataproc, Cloud Dataflow를 포함한.VM 인스턴스를 활용하는 서비스를 위한 확장 가능하고 유연한 네트워킹을 제공합니다.

VPC 네트워크는 전역 리소스입니다. 단일 VPC는 공개 인터넷을 통해 통신하지 않고도 여러 지역에 걸쳐 구현될 수 있습니다. 즉, 하나의 GCP 프로젝트에서 전 세계에 분산된 리소스를 연결 및 관리할 수 있으며, 단일 프로젝트에 여러 개의 격리된 VPC 네트워크를 만들 수 있습니다.

VPC 네트워크 자체는 IP 주소 범위를 정의하지 않습니다. 대신 각 VPC 네트워크는 하나 이상의 하위 네트워크라는 파티션으로 구성됩니다. 각 서브넷은 하나 이상의 IP 주소 범위를 정의합니다. 서브넷은 지역 리소스입니다. 즉, 각 서브넷은 하나의 지역과 명시적으로 연결됩니다.

자세한 내용은 VPC 개요를 참조하세요.

방화벽 규칙을 사용하여 트래픽 관리

각 VPC 네트워크는 분산 가상 방화벽을 구현합니다. Compute Engine VM 인스턴스 및 GKE 클러스터를 포함하여 VPC에 연결된 리소스를 오가는 트래픽을 허용하거나 거부하는 방화벽 규칙을 구성합니다. 방화벽 규칙은 가상 네트워크 수준에서 적용되므로 인스턴스가 사용하는 운영 체제에 관계없이 효과적인 보호 및 트래픽 제어를 제공하는 데 유용합니다. 방화벽은 상태를 저장합니다. 즉, 허용된 흐름의 경우 반환 트래픽은 자동으로 허용됩니다.

방화벽 규칙은 특정 VPC 네트워크에 적용됩니다. 규칙를 통해 포트 및 프로토콜과 같은 트래픽 유형, IP 주소, 서브넷, 태그, 서비스 계정을 포함한 트래픽의 출처 또는 목적지를 지정할 수 있습니다. 예를 들어 수신 규칙을 만들어 특정 서비스 계정에 연결된 VM 인스턴스가 특정 소스 서브넷에서 오는 TCP 트래픽을 포트 80에서 수락하도록 할 수 있습니다. 각 VPC는 자동으로 기본 및 암시적 방화벽 규칙을 포함합니다.

앱이 GKE에서 호스팅되는 경우 네트워크 트래픽을 관리하고 방화벽 규칙을 구성하기 위한 다른 고려 사항이 있습니다. 자세한 내용은 GKE 네트워킹 개념을 참조하세요.

외부 액세스 제한

VPC를 활용하는 GCP 리소스를 만드는 경우 리소스를 배치할 네트워크와 서브넷을 선택합니다. 리소스에는 서브넷과 연결된 IP 범위 중 하나에서 내부 IP 주소가 할당됩니다. VPC 네트워크의 리소스는 방화벽 규칙이 허용하는 한 내부 IP 주소를 통해 상호 통신할 수 있습니다.

리소스가 인터넷과 통신하려면 외부 공개 IP 주소가 있거나 Cloud NAT를 사용해야 합니다. 마찬가지로, 네트워크가 예를 들어 VPN을 통해 연결되는 등 어떤 방식으로든 연결된 경우를 제외하고 리소스가 VPC 네트워크 밖에 있는 다른 리소스에 연결하려면 외부 IP 주소가 있어야 합니다.자세한 내용은 IP 주소 문서를 참조하세요.

인터넷 액세스는 인터넷 액세스가 필요한 리소스로만 제한합니다. 비공개 내부 IP 주소만 있는 리소스도 비공개 Google 액세스를 통해 많은 Google API 및 서비스에 액세스할 수 있습니다. 이 비공개 액세스는 리소스가 인터넷으로부터 격리된 상태를 유지하면서 주요 Google 및 GCP 서비스와 상호작용할 수 있게 해줍니다.

네트워크 제어 중앙화

공유 VPC를 사용하여 공통 VPC 네트워크에 연결합니다. 이러한 프로젝트의 리소스는 내부 IP를 사용하여 프로젝트 경계를 넘어 상호 안전하고 효율적으로 통신할 수 있습니다. 중앙 호스트 프로젝트에서 서브넷, 경로, 방화벽과 같은 공유 네트워크 리소스를 관리하여 여러 프로젝트에 걸쳐 일관적인 네트워크 정책을 적용 및 강제할 수 있습니다.

공유 VPC와 IAM 제어를 통해 네트워크 관리를 프로젝트 관리로부터 분리할 수 있습니다. 이 분리는 최소 권한 원칙을 구현하는 데 도움이 됩니다. 예를 들어 중앙 네트워크팀에서 참여 프로젝트에 대한 권한 없이 네트워크를 관리할 수 있습니다. 마찬가지로, 프로젝트 관리자는 공유 네트워크를 조작하기 위한 권한 없이 프로젝트 리소스를 관리할 수 있습니다.

기업 네트워크 연결

많은 기업은 기존 온프레미스 인프라를 GCP 리소스와 연결해야 합니다. 대역폭, 지연, SLA 요구사항을 평가하여 최선의 연결 옵션을 선택하세요.

  • GCP까지 인터넷 연결을 거칠 필요 없이 온프레미스와 VPC 네트워크 간에 안정적으로 데이터를 전송할 수 있는 저지연, 고가용성 엔터프라이즈급 연결이 필요한 경우 Cloud Interconnect를 사용하세요.

    • 전용 상호 연결은 온프레미스 네트워크와 Google 네트워크 간에 물리적인 직접 연결을 제공합니다.
    • 파트너 상호 연결은 지원되는 서비스 제공업체를 통해 온프레미스와 GCP VPC 간 연결을 제공합니다.
  • Cloud Interconnect의 저지연과 고가용성이 필요 없거나 클라우드를 처음 시작하는 경우 Cloud VPN을 사용하여 온프레미스 네트워크와 VPC 간에 암호화된 IPsec VPN 터널을 설정하세요. IPsec VPN 터널은 직접 비공개 연결에 비해 오버헤드와 비용이 낮습니다.

앱과 데이터 보호

GCP는 인프라와 서비스 전반에서 데이터 센터의 물리적 보안과 커스텀 보안 하드웨어부터 전담 연구팀에 이르기까지 강력한 보안 기능을 제공합니다. 그러나 GCP 리소스 보호는 Google과 여러분 공동의 책임입니다. 여러분은 앱과 데이터를 보호하기 위한 적절한 조치를 취해야 합니다.

방화벽 규칙과 VPC 격리 외에 다음과 같은 추가 도구를 사용하여 앱을 안전하게 보호하세요.

  • VPC 서비스 제어를 사용하여 GCP 리소스를 둘러싸는 보안 경계를 정의해서 데이터를 VPC 내부로만 제한하고 데이터 유출 위험을 낮춥니다.
  • GCP 전역 HTTP(S) 부하 분산기를 사용하여 인터넷 연결 서비스를 위한 고가용성과 확장을 지원합니다.
  • Cloud Armor를 HTTP(S) 부하 분산기와 통합하여 DDoS 보호와 함께 네트워크 에지에서 IP 주소를 차단 목록 또는 허용 목록에 추가하는 기능을 제공합니다.
  • Cloud Identity-Aware Proxy(Cloud IAP)를 통해 사용자 ID와 요청의 컨텍스트를 확인함으로써 사용자에게 액세스 권한을 부여해야 하는지 여부를 판단하여 앱에 대한 액세스를 제어합니다.

GCP는 전송 중보관 중에 모두 암호화를 적용하여 데이터를 안전하게 보호합니다. 보관 중인 데이터는 기본적으로 Google이 관리하는 암호화 키를 사용하여 암호화됩니다. 민감한 정보의 경우 대신 GCP에서 키를 관리할 수 있습니다. 더 강력한 제어가 필요한 경우 GCP 외부에서 유지관리되는 자체 암호화 키를 제공할 수 있습니다. 자체 키를 관리 또는 유지하는 데는 오버헤드가 수반되므로 이 방법은 극히 민감한 정보에만 사용하는 것이 좋습니다. 자세한 내용은 보관 중 암호화를 참조하세요.

로깅, 모니터링, 운영

로깅 및 모니터링 중앙화

일반적으로 기업은 여러 앱, 데이터 파이프라인, 기타 프로세스를 보통 여러 플랫폼에 걸쳐 실행합니다. 이러한 앱과 프로세스의 정상적인 상태를 확보하는 것은 개발자와 운영팀 모두의 중요한 책임입니다. 정상 상태 유지를 위해 Stackdriver를 사용하여 로깅, 모니터링, 디버깅, 추적, 프로파일링 등을 관리하는 것이 좋습니다.

로그는 앱과 프로세스의 상태에 대한 진단 정보를 얻는 주 소스입니다. Stackdriver Logging은 Stackdriver 제품군에 속하며 로그 데이터 및 이벤트를 저장, 열람, 검색, 분석하고 알림을 전송하는 기능을 제공합니다. 로깅은 많은 GCP 서비스와 기본적으로 통합됩니다. 서비스에는 Amazon EC2 인스턴스 및 온프레미스에서 실행 중인 앱을 지원하기 위한 로깅 에이전트와 API가 포함됩니다. 로깅을 사용하여 모든 앱의 로그를 Stackdriver로 중앙화하세요.

로그를 살펴보는 것 외에 안정적인 운영을 보장하기 위해서는 일반적으로 앱과 시스템의 다른 측면도 모니터링해야 합니다. Stackdriver Monitoring을 사용하여 앱과 인프라의 성능, 가동시간, 전체적인 상태를 살펴볼 수 있습니다. 모니터링은 이벤트, 측정항목, 메타데이터를 내부 데이터화하여 대시보드, 차트, 알림을 통해 유용한 정보를 생성합니다. 모니터링은 많은 GCP 및 타사 소스의 측정항목을 기본적으로 지원합니다. 모니터링으로 커스텀 측정항목을 정의할 수도 있습니다. 예를 들어 비정상적인 행동이나 트렌드가 발생하는 경우 운영팀이 알림을 받도록 측정항목을 사용하여 알림 정책을 정의할 수 있습니다. 또한 모니터링은 시급한 문제를 식별하는 데 도움이 되는 유연한 대시보드와 풍부한 시각화 도구도 제공합니다.

감사 추적 설정

앱 및 프로세스 수준 로그를 캡처하는 것 외에, 개발자와 IT팀이 GCP 리소스와 어떻게 상호작용하고 있는지에 대한 세부정보를 추적하고 유지관리해야 할 수 있습니다. Cloud 감사 로깅을 사용하면 GCP 프로젝트에서 '누가 언제, 어디서 무엇을 했는지'와 같은 질문에 대한 답을 찾는 데 도움이 됩니다. 감사 로그를 작성하는 GCP 서비스의 목록은 감사 로그 생성 서비스를 참조하세요. IAM 제어를 사용하여 감사 로그를 보기 위한 액세스 권한을 가진 사람을 제한합니다.

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

감사에 대한 더 자세한 내용은 Cloud 감사 로깅 작업을 위한 권장사항을 참조하세요.

로그 내보내기

로깅은 제한된 기간 동안 앱 및 감사 로그를 보관합니다. 규정 준수 의무를 충족하기 위해 더 오랜 기간 로그를 보관해야 할 수 있습니다. 또는 기록 분석을 위해 로그를 보관하려는 경우도 있습니다.

Cloud Storage, BigQuery, Cloud Pub/Sub로 로그를 내보낼 수 있습니다. 필터를 사용하여 내보내기에서 리소스를 포함하거나 제외할 수 있습니다. 예를 들어 모든 Compute Engine 로그를 내보내면서 Cloud Load Balancing의 대량 로그는 제외할 수 있습니다.

로그를 내보내는 위치는 사용 사례에 따라 다릅니다. 많은 기업은 여러 대상으로 내보냅니다. 대체로 규정 준수 의무를 준수하기 위한 장기 저장소로는 Cloud Storage를 사용하세요. 로그를 분석해야 하는 경우 SQL 쿼리와 방대한 타사 도구 생태계를 지원하는 BigQuery를 사용하세요.

로깅 내보내기에 대한 자세한 내용은 로깅에서 내보내기 위한 설계 패턴을 참조하세요.

DevOps를 수용하고 사이트 신뢰성 엔지니어링을 검토

앱과 기능의 민첩성을 높이고 TTM(time-to-market)을 단축하려면 개발, 운영, 네트워킹, 보안팀 사이의 사일로를 허물어야 합니다. 이를 위해 필요한 프로세스, 문화, 도구를 통틀어 DevOps라고 합니다.

GCP는 DevOps 방식을 도입하는 데 도움이 되는 다양한 서비스를 제공합니다. 제공되는 기능에는 통합 소스 코드 저장소, 지속적 배포 도구, Stackdriver를 통한 풍부한 모니터링 기능, 충실한 오픈소스 도구 지원이 포함됩니다. 자세한 내용은 GCP의 DevOps 솔루션을 참조하세요.

사이트 안정성 엔지니어링(SRE)은 DevOps와 긴밀하게 연관된 일련의 실천 방안입니다. 이러한 실천 방안은 Google의 프로덕션 인프라를 관리하는 SRE팀에서 비롯되었습니다. 많은 기업에서 여건상 전담 SRE 부서를 만들기는 어렵겠지만 SRE 도서를 통해 운영 전략을 가다듬는 데 도움이 되는 실천 방안을 익히는 것이 좋습니다.

클라우드 아키텍처

이전 계획 세우기

온프레미스 앱과 인프라를 클라우드로 이전하려면 신중한 실사와 계획이 필요합니다. 앱별로 리프트 앤 시프트부터 변환 및 이동에 이르기까지 다양한 이전 전략을 평가해야 합니다. GCP는 가상 머신을 이전하고 데이터를 전송하고 작업 부하를 현대화하는 데 도움이 되는 도구를 제공합니다. 자세한 내용은 이전 센터를 참조하세요.

특정 앱의 경우 규제, 기술, 재무적 제약으로 인해 공용 클라우드로 옮기기가 불가능하거나 바람직하지 않을 수 있습니다. 따라서 온프레미스와 GCP 인프라에 걸쳐 작업 부하를 분산 및 통합해야 할 수 있습니다. 이러한 구성을 하이브리드 클라우드라고 합니다. 하이브리드 작업 부하에 대한 자세한 내용은 하이브리드 클라우드 페이지와 하이브리드 및 다중 클라우드 솔루션을 위한 패턴 및 권장사항을 참조하세요.

관리형 서비스 우선 고려

클라우드 도입을 이끄는 핵심 동력은 IT 오버헤드 감소와 효율성 증대를 통해 핵심 비즈니스에 집중하고자 함입니다. DevOps 방식을 도입하고 자동화를 늘리는 것 외에 GCP 관리형 서비스를 사용하여 운영 부담과 총소유비용(TCO)을 낮춰야 합니다.

애플리케이션 스택의 모든 부분을 개별적으로 설치, 지원, 운영하는 대신 관리형 서비스를 사용하여 애플리케이션 스택의 각 부분을 서비스로 소비할 수 있습니다. 예를 들어 VM 인스턴스에 MySQL 데이터베이스를 설치하고 직접 관리하는 대신 Cloud SQL이 제공하는 MySQL 데이터베이스를 사용할 수 있습니다. 그러면 GCP를 통해 기반 인프라를 관리하고 백업, 업데이트, 복제를 자동화할 수 있습니다.

각 관리형 서비스가 제공하는 SLA를 평가하는 것이 좋습니다.

GCP는 관리형 데이터베이스부터 빅데이터 처리 도구에 이르기까지, 많은 일반적인 앱 구성요소 및 사용 사례를 위한 관리형 서비스와 서버리스 옵션을 제공합니다. 이와 같은 관리형 서비스의 상당수는 인기 있는 오픈소스 프레임워크와 플랫폼을 지원하므로 이러한 오픈소스 플랫폼을 활용하는 기존 앱을 클라우드로 리프트 앤 시프트 방식으로 이전함으로써 TCO 혜택을 실현할 수 있습니다.

고가용성을 위한 설계

중요 앱을 위한 가동시간을 유지하려면 오류 또는 예상치 못한 부하 변경에 매끄럽게 대처하는 탄력적인 앱을 설계합니다. 고가용성은 시스템 구성요소에서 오류가 발생하더라도 앱이 응답성을 유지하고 계속해서 작동하는 역량입니다. 고가용성 아키텍처에는 일반적으로 컴퓨팅 리소스의 분산, 부하 분산, 데이터 복제가 사용됩니다. 고가용성 프로비저닝의 범위는 앱마다 다를 수 있습니다. 가용성 개념에 대한 자세한 내용은 지리적 위치 및 지역 문서를 참조하세요.

최소한 Compute Engine VM 인스턴스 및 GKE 클러스터와 같은 컴퓨팅 리소스를 지역의 여러 가용 영역에 걸쳐 분산하여 특정 영역에서 장애가 발생하더라도 보호되도록 해야 합니다. 컴퓨팅 리소스의 가용성을 더욱 개선하려면 지리적으로 흩어진 여러 지역에 걸쳐 리소스를 분산하여 전체 지역의 손실 위험을 완화할 수 있습니다. 컴퓨팅 리소스를 만드는 지점에 대한 안내는 Compute Engine 지역 선택 권장사항을 참조하세요.

GCP는 여러 가지 변형의 부하 분산을 제공합니다. HTTP(S) 부하 분산기는 인터넷 연결 앱을 노출하는 데 자주 사용됩니다. 이 부하 분산기는 글로벌 분산을 제공하여 여러 지리적 위치의 지역에 걸쳐 부하를 분산할 수 있도록 합니다. 영역 또는 지역이 사용 불능 상태가 되면 부하 분산기가 가용 용량이 있는 영역으로 트래픽을 보냅니다. 자세한 내용은 글로벌 부하 분산을 사용한 애플리케이션 용량 최적화를 참조하세요.

데이터 저장소를 선택할 때도 가용성을 고려해야 합니다. 일부 GCP 데이터 저장소 서비스는 한 지역의 여러 영역에 걸쳐 데이터를 복제하는 기능을 제공합니다. 또 다른 서비스는 하나의 지리적 위치에 있는 여러 지역에 걸쳐 자동으로 데이터를 복제하지만 지연 또는 일관성 모델 측면에서 타협이 필요할 수 있습니다. 가장 적절한 데이터 저장소 서비스는 앱과 가용성 요구사항에 따라 달라집니다.

재해 복구 전략 수립

고가용성을 위한 설계 외에, 대규모 중단 또는 자연 재해에 대비하여 비즈니스 연속성 유지를 위한 계획을 마련해야 합니다. 재해 복구(DR)는 드물지만 큰 사고로부터 복구하는 역량입니다. 고가용성 프로비저닝이 비효율적이거나 사용 불가능한 경우 재해 복구를 시작해야 할 수 있습니다.

효과적인 DR 계획을 수립하기 위해서는 계획과 테스트가 필요합니다. DR 계획은 조기에 마련하는 것이 좋습니다. 자세한 내용은 재해 복구 계획 가이드 및 관련 자료를 참조하세요.

리소스

결제 및 관리

리소스에 비용이 청구되는 방식 이해

GCP는 소비 모델에 따라 운영됩니다. 즉, 지정된 결제 기간 동안 특정 리소스 또는 제품을 사용한 양에 따라 비용이 청구됩니다. 제품은 다양한 방식으로 소비를 측정합니다. 예를 들면 다음과 같습니다.

  • 시간(머신이 실행된 초 단위 시간)
  • 양(저장된 데이터의 양)
  • 실행된 작업의 수
  • 이러한 개념의 변형

비용을 정확히 판단할 수 있도록 시스템의 구성요소에 비용이 청구되는 방식을 파악해야 합니다. 각 제품은 해당 문서에서 세부적인 가격 책정 정보를 제공합니다. 많은 제품이 특정 기준 미만의 소비에 대해서는 비용이 청구되지 않는 무료 등급을 제공합니다. 무료 등급이 제공하는 기준 이상으로 리소스를 소비하려면 결제를 사용 설정해야 합니다.

GCP 가격 책정 방식, 혁신, 할인에 대한 자세한 내용은 가격 책정 페이지를 참조하세요.

결제 제어 설정

Compute Engine VM, Cloud Storage 버킷, BigQuery 데이터세트를 포함한 모든 GCP 리소스는 GCP 프로젝트와 연결되어야 합니다. 무료 등급으로 제공되는 기준 이상으로 리소스를 소비하려면 제품을 결졔 계정과 연결해야 합니다. 결제 계정과 프로젝트는 일대다 관계입니다. 즉, 하나의 프로젝트는 하나의 결제 계정에만 연결될 수 있지만 결제 계정은 다수의 프로젝트와 연결이 가능합니다.

결제 계정을 사용하여 프로젝트 집합에서 누가 리소스 비용을 지불하는지를 정의합니다. 계정에는 신용카드와 같은 비용이 청구되는 결제 수단이 포함됩니다. 조직 수준에서 조직 노드 아래의 프로젝트를 결제 계정에 연결하여 결제 계정을 정의할 수 있습니다. 조직에서 다양한 비용 센터 또는 부서를 반영하는 여러 결제 계정을 둘 수 있습니다.

Cloud IAM은 사용자가 결제를 관리 및 상호작용하는 방법을 제한하기 위한 강력한 제어 기능을 제공합니다. 이러한 제어 기능은 최소 권한 원칙을 적용하고 명확한 역할 구분을 제공하는 데 도움이 됩니다. 예를 들어 프로젝트를 특정 결제 계정에 연결하는 권한으로부터 결제 계정을 만드는 권한을 분리할 수 있습니다.

결제 개념 및 설정에 대한 자세한 내용은 결제 온보딩 체크리스트를 참조하세요.

청구서 분석 및 내보내기

적절한 권한을 가진 사용자는 GCP Console에서 비용, 거래 내역 및 그 외의 다양한 내용을 세부적으로 볼 수 있습니다. 정보는 결제 계정별로 제공됩니다. 또한 콘솔에는 프로젝트, 제품, 시간 범위별로 비용을 필터링하고 세분화할 수 있는 양방향 결제 보고서도 포함되어 있습니다. 복잡성이 높지 않은 GCP 설정을 사용하는 고객에게는 GCP Console 기능으로 충분한 경우가 많습니다.

그러나 클라우드 지출에 대해서는 일반적으로 커스텀 분석과 보고가 필요합니다. 이 요구사항을 충족하려면 청구액의 일일 내보내기를 사용 설정합니다. 파일 내보내기를 구성하여 CSV 또는 JSON 파일을 Cloud Storage 버킷으로 내보낼 수 있습니다. 마찬가지로, BigQuery 데이터세트로 내보내기도 구성할 수 있습니다. 내보내기에는 리소스에 적용된 모든 라벨이 포함됩니다.

BigQuery 내보내기를 사용 설정하는 것이 좋습니다. 이러한 내보내기는 파일 내보내기에 비해 비용을 더 세분화해서 제공합니다. BigQuery에 결제 데이터가 저장된 다음에는 재무팀이 표준 SQL을 사용하여 데이터를 분석하고 BigQuery와 통합되는 도구를 사용할 수 있습니다.

용량 요구사항 계획

GCP 프로젝트에는 특정 리소스 또는 API의 소비를 제한하는 할당량이 있습니다. 할당량은 예상치 못한 사용량 증가를 방지함으로써 광범위한 GCP 커뮤니티를 보호하는 역할을 합니다. 예를 들어 할당량은 소수의 고객 또는 프로젝트가 특정 지역 또는 영역의 CPU 코어를 독점하는 경우를 방지합니다.

예상치 못한 리소스 소비 제한을 방지하려면 프로젝트의 용량 요구사항을 사전에 계획하세요. 할당량이 충분하지 않은 경우 GCP Console의 할당량 섹션에서 변경을 요청할 수 있습니다. 더 큰 용량이 필요한 경우 GCP 영업팀에 문의하세요.

비용 관리 구현

클라우드 서비스가 확장되면 비용도 상승합니다. GCP는 리소스 소비를 제한하고 관련 결제 이벤트를 관련된 사람에게 알리기 위한 여러 방법을 제공합니다.

예산을 정의하여 지출이 특정 기준에 도달하면 알림을 생성하도록 할 수 있습니다. 알림은 이메일 형식으로 생성되며, 선택에 따라 프로그래매틱 알림을 위해 Cloud Pub/Sub 메시지도 생성할 수 있습니다. 예산을 전체 결제 계정에 적용하거나 해당 결제 계정과 연결된 개별 프로젝트에 적용할 수 있습니다. 예를 들어 결제 계정의 총 월 지출액이 지정된 예산 금액의 50, 80, 100%에 도달할 때 알림을 생성하도록 예산을 만들 수 있습니다. 참고로 예산 자체는 지출을 제한하지 않으며, 알림을 생성하기 위한 기능입니다. 자세한 내용은 예산 알림 문서를 참조하세요. 비용 관리를 간소화하는 데 도움이 되는 권장사항, 설계 관련 의사 결정, 구성 옵션을 더 많이 보려면 클라우드 결제 온보딩 체크리스트를 참조하세요.

또한 할당량을 사용하여 특정 리소스의 소비에 상한을 설정할 수 있습니다. 예를 들어 BigQuery API를 대상으로 최대 '일일 쿼리 사용량' 할당량을 설정하여 프로젝트가 BigQuery에 과도한 비용을 소비하지 않도록 할 수 있습니다.

지원 패키지 구매

GCP는 커뮤니티의 포럼부터 유료 지원 패키지에 이르기까지 문제가 발생할 때 지원을 받을 수 있는 다양한 방법을 제공합니다. 업무상 중요한 작업 부하를 보호하려면 엔터프라이즈 지원 패키지를 구매하는 것이 좋습니다. 자세한 내용은 GCP 지원 포털을 참조하세요.

구매하는 지원의 수준에 따라 지원 티켓을 받을 수 있는 기능이 특정 개인으로 제한될 수 있습니다. 따라서 지원 정보 센터 또는 응급 처치소를 두는 것이 좋습니다. 이렇게 하면 티켓 중복과 의사소통 문제를 방지하고 Google Cloud 지원과의 의사소통을 최대한 명확하게 할 수 있습니다.

전문가의 도움 받기

Google Cloud 전문 서비스 지원팀(PSO)은 GCP 여정에 도움이 되는 컨설팅 서비스를 제공합니다. 귀사의 팀에 성공적인 구현을 위한 권장사항과 기본 원칙을 전수하는 데 필요한 심층적인 전문 기술을 제공하는 PSO 컨설턴트에 문의하세요. 서비스는 작업 부하를 계획, 배포, 실행, 최적화하는 데 도움이 되도록 패키지 형태로 제공됩니다.

또한 GCP에는 대규모 글로벌 시스템 통합업체부터 머신러닝과 같은 특정 분야에 대한 심층적인 전문성을 갖춘 파트너에 이르기까지 강력한 Google 클라우드 파트너 생태계가 있습니다. Google 클라우드 파트너는 GCP를 사용한 고객 성공 사례를 보유하고 있으며 귀사의 프로젝트를 가속화하고 비즈니스 성과를 개선할 수 있습니다. 기업 고객은 GCP 구현을 계획하고 실행하는 과정에서 파트너에게 연락하여 도움을 받는 것이 좋습니다.

우수성 센터 구축

Google은 이러한 제품에 대한 투자를 지속하고 있으며, 새로운 기능이 계속해서 구현되고 있습니다. 조직의 정보와 경험, 패턴을 위키, Google 사이트, 인트라넷 사이트와 같은 내부 지식 기반에 보관하면 유용하게 활용할 수 있습니다.

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

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...