Google Cloud 시작 영역의 리소스 계층 구조 결정

리소스 계층 구조는 Google Cloud에서 리소스를 정리하는 데 도움이 됩니다. 이 문서에서는 시작 영역 설계의 일부로 리소스 계층 구조를 선택하는 방법을 설명합니다. 이 문서는 소스 계층 구조 설계와 관련된 클라우드 시스템 관리자, 설계자, 기술 실무자를 대상으로 합니다. 이 문서는 시작 영역 관련 시리즈의 일부입니다. 여기에는 비즈니스가Google Cloud에서 리소스를 구성하는 일반적인 방법을 설명하는 샘플 아키텍처가 포함되어 있습니다.

리소스 계층 구조의 디자인 요소

Google Cloud에서 리소스 계층 구조를 정의할 때는 현재 조직의 작동 방식과 클라우드 변환의 이상적인 최종 상태를 고려해야 합니다. 리소스 관리를 위한 최선의 방법은 조직에서 의도한 클라우드 작동 방식을 기반으로 합니다. 조직마다 다르기 때문에 리소스 계층 구조에 대한 최상의 단일 접근 방식은 존재하지 않습니다.

하지만 회사 조직 구조를 리소스 계층 구조에 매핑하는 것은 피하는 것이 좋습니다. 대신 Google Cloud에서 비즈니스 요구사항과 운영에 집중하세요.

Google Cloud 리소스 계층 구조

Google Cloud 의 리소스 계층 구조는 조직이라고 부르는 루트 노드에서 시작합니다. 기업에는 특정 상황을 제외하고 루트 노드가 하나만 있는 것이 좋습니다. 폴더 및 프로젝트를 사용하여 계층의 하위 수준을 정의하고 폴더 내에 폴더를 만들어 계층 구조를 빌드합니다. 계층의 모든 수준에서 워크로드를 호스팅하는 프로젝트를 만들 수 있습니다.

다음 다이어그램은 조직이라는 루트 노드와 수준 1, 2, 3의 폴더를 보여줍니다. 프로젝트 및 하위 폴더는 수준 2의 폴더 아래에 생성됩니다.

리소스 계층 구조 요소

리소스 계층 구조를 결정할 때는 다음 요소를 고려하세요.

• 클라우드 리소스는 누가 담당하나요? 귀하의 부서, 자회사, 기술팀, 법인 중에 무엇인가요?
• 규정 준수 요구는 무엇인가요?
• 합병, 인수, 스핀오프와 같은 예정된 비즈니스 이벤트가 있나요?

계층 구조 전체의 리소스 상호작용 이해

조직 정책은 리소스 계층 구조의 하위 요소에 의해 상속되지만 하위 수준에 정의된 정책으로 대체될 수 있습니다. 자세한 내용은 계층 구조 평가 이해를 참조하세요. 조직 정책 제약조건을 사용하여 전체 조직 또는 조직의 주요 부분에 대한 가이드라인을 설정하고 예외를 허용할 수 있습니다.

IAM 정책이라고 하는 허용 정책은 하위 요소에 의해 상속되며 하위 수준의 허용 정책은 추가됩니다. 하지만 허용 정책을 거부 정책으로 대체하여 프로젝트, 폴더, 조직 수준에서 권한을 제한할 수 있습니다. 거부 정책은 허용 정책 전에 적용됩니다.

또한 다음 사항을 고려해야 합니다.

• Cloud Logging에는 폴더 또는 조직 수준에서 로그를 집계하는 데 사용할 수 있는 집계 싱크가 포함되어 있습니다. 자세한 내용은 시작 영역의 보안 결정 Google Cloud 을 참고하세요.
• 청구는 리소스 계층 구조에 직접 연결되지 않고 프로젝트 수준에서 할당됩니다. 하지만 폴더 수준에서 합산 데이터를 가져오려면 청구 보고서를 사용하여 프로젝트 계층 구조에 따라 비용을 분석할 수 있습니다.
• 계층식 방화벽 정책을 사용하면 조직 전체 또는 특정 폴더에서 일관된 방화벽 정책을 구현할 수 있습니다. 상속은 암묵적입니다. 즉, 모든 수주에서 트래픽을 허용 또는 거부하거나 더 낮은 수준으로 결정을 위임할 수 있습니다.

리소스 계층 구조 설계에 대한 결정 사항

다음 플로우 차트는 조직에 가장 적합한 리소스 계층 구조를 선택하기 위해 고려해야 할 사항을 보여줍니다.

위 다이어그램은 다음과 같은 결정 지점을 간략하게 보여줍니다.

1. 자회사, 리전 그룹 또는 사업부별로 정책 요구사항이 서로 다릅니까?
   1. 그렇다면 리전 또는 자회사별 설계를 따르세요.
   2. 그렇지 않으면 다음 결정 지점으로 이동합니다.

2. 워크로드 또는 제품팀에서 정책에 대한 강력한 자율성을 요구하나요? 예를 들어 모든 워크로드 또는 제품팀의 정책을 결정하는 중앙 보안팀이 없는 경우,

   1. 그렇다면 책임성 프레임워크 기반의 설계를 따르세요.

   2. 그렇지 않은 경우 애플리케이션 환경 기반의 설계를 참조하세요.

특정 사용 사례에 따라 결정 차트가 제안하는 것과 다른 리소스 계층 구조 설계로 이어질 수 있습니다. 대부분의 조직은 하이브리드 접근 방식을 선택하고 정책 및 액세스에 가장 큰 영향을 미치는 설계부터 시작하여 리소스 계층 구조의 다양한 수준에서 다양한 설계를 선택합니다.

옵션 1: 애플리케이션 환경 기반의 계층 구조

많은 조직에서 개발, 프로덕션, 테스트와 같은 여러 애플리케이션 환경에 대해 다양한 정책 및 액세스 제어를 정의합니다. 각 환경에 걸쳐 표준화된 별도의 정책을 사용하면 관리 및 구성을 쉽게 수행할 수 있습니다. 예를 들어 테스트 환경보다는 프로덕션 환경의 보안 정책이 더 엄격할 수 있습니다.

다음 사항에 해당하는 경우 애플리케이션 환경 기반의 계층 구조를 사용하세요.

• 정책 및 관리 요구사항이 서로 다른 별도의 애플리케이션 환경이 있는 경우
• 중앙 보안팀이 모든 프로덕션 워크로드 및 데이터에 일관되게 적용할 수 있어야 하는 중앙 집중식 보안 또는 감사 요구사항이 있는 경우
• 다양한 환경에서Google Cloud 리소스에 액세스하는 데 서로 다른 Identity and Access Management (IAM) 역할이 필요한 경우

다음과 같은 경우 이 계층 구조를 사용하지 마세요.

• 여러 애플리케이션 환경을 실행하지 않는 경우
• 환경마다 애플리케이션 종속 항목과 비즈니스 프로세스가 달라지지 않는 경우
• 리전, 팀 또는 애플리케이션에 따라 강력한 정책 차이가 있는 경우

다음 다이어그램은 가상의 금융 기술 회사인 example.com의 계층 구조를 보여줍니다.

이전 다이어그램에 표시된 것처럼 example.com에는 서로 다른 정책, 액세스 제어, 규제 요구사항, 프로세스가 포함된 3개의 애플리케이션 환경이 있습니다. 환경은 다음과 같습니다.

• 개발 및 QA 환경: 이 환경은 내부 직원 및 컨설턴트인 개발자가 관리합니다. 개발자는 지속적으로 코드를 푸시하고 품질 보증을 책임집니다. 이 환경은 비즈니스 소비자에게 제공되지 않습니다. 이 환경은 프로덕션 환경에 비해 통합 및 인증 요구사항이 덜 엄격하며 적절한 권한을 가진 승인된 역할이 개발자에게 할당됩니다. 개발 및 QA 환경은 example.com의 표준 애플리케이션 오퍼링만을 위해 설계됩니다.

• 테스트 환경: 이 환경은 회귀 및 애플리케이션 테스트에 사용되며 example.com API를 사용하는 example.com 클라이언트의 기업 간 거래(B2B) 오퍼링을 지원합니다. 이를 위해 example.com은 두 가지 프로젝트 유형을 만듭니다.

  • B2B 오퍼링의 내부 회귀, 성능, 구성을 완료하기 위한 내부 테스트 프로젝트
  • 멀티 테넌트 지원을 받는 클라이언트 UAT 프로젝트로, B2B 클라이언트가 구성을 검증하고 사용자 환경, 브랜딩, 워크플로, 보고서 등에 대한 example.com 요구사항에 맞게 조정할 수 있습니다.

• 프로덕션 환경: 이 환경은 검증, 수락, 시작되는 모든 제품 오퍼링을 호스팅합니다. 이 환경은 결제 카드 산업 데이터 보안 표준(PCI DSS, Payment Card Industry Data Security Standard) 규제를 따르고 하드웨어 보안 모듈(HSM)을 사용하며 인증 및 결제 조정과 같은 항목에 대해 타사 프로세서와 통합됩니다. 감사 및 규정 준수팀은 이 환경의 중요한 이해관계자입니다. 이 환경에 대한 액세스는 엄격하게 제어되며 대부분 자동화된 배포 프로세스로 제한됩니다.

애플리케이션 환경을 기반으로 하는 계층 구조 설계에 대한 자세한 내용은 엔터프라이즈 기반 청사진에서 조직 구조를 참조하세요.

옵션 2: 리전 또는 자회사 기반의 계층 구조

일부 조직은 여러 리전에 걸쳐 운영되며 자회사가 서로 다른 지역에서 비즈니스를 수행하거나 인수 합병의 결과물입니다. 이러한 조직에는 Google Cloud의 확장성 및 관리 옵션을 사용하고 리전 또는 자회사 간에 존재하는 다양한 프로세스 및 정책에 대한 독립성을 유지하는 리소스 계층 구조가 필요합니다. 이 계층 구조는 자회사 또는 리전을 리소스 계층 구조에서 가장 높은 폴더 수준으로 사용합니다. 배포 절차는 일반적으로 리전을 중심으로 이뤄집니다.

다음 조건에 해당하면 이 계층 구조를 사용합니다.

• 여러 지역 또는 자회사가 독립적으로 작동하는 경우
• 지역 또는 자회사가 운영 백본, 디지털 플랫폼 제품, 프로세스가 다른 경우
• 비즈니스가 리전 또는 자회사에 대한 다양한 규정 및 규정 준수 표준을 사용하는 경우

다음 다이어그램은 두 개의 자회사와 리전화된 구조를 가진 지주 그룹이 있는 전역 조직의 계층 구조 예시를 보여줍니다.

이전 다이어그램에는 다음과 같은 계층 구조가 포함됩니다.

• 다음 폴더는 첫 번째 수준에 있습니다.
  • Subsidiary 1 및 Subsidiary 2 폴더는 조직의 나머지 부분과 액세스 권한 및 정책이 다른 회사의 두 자회사를 나타냅니다. 각 자회사는 IAM을 사용하여 프로젝트 및 리소스에 대한 액세스를 제한합니다. Google Cloud
  • Holding group 폴더는 리전에 걸쳐 개략적인 공통 정책이 있는 그룹을 나타냅니다.
  • Bootstrap 폴더는 엔터프라이즈 기반 청사진에 설명된 대로 Google Cloud 인프라를 배포하는 데 필요한 공통 리소스를 나타냅니다.
• 두 번째 수준에서 지주 그룹 폴더에는 다음 폴더가 포함됩니다.
  • APAC, EMEA, Americas 폴더는 그룹 내에서 거버넌스, 액세스 권한, 정책이 서로 다른 다양한 리전을 나타냅니다.
  • Shared infrastructure 폴더는 모든 리전에서 전역적으로 사용되는 리소스를 나타냅니다.
• 각 폴더에는 이러한 자회사 또는 리전이 담당하는 리소스를 포함하는 다양한 프로젝트가 있습니다.

더 많은 폴더를 추가하여 회사 내에서 서로 다른 법인, 부서, 팀을 구분할 수 있습니다.

옵션 3: 책임성 프레임워크 기반의 계층 구조

책임성 프레임워크에 기반한 계층 구조는 제품이 독립적으로 실행되거나 조직 단위에서 제품의 수명 주기를 소유하는 팀이 명확하게 정의된 경우에 가장 잘 작동합니다. 이러한 조직에서 제품 소유자는 프로세스, 지원, 정책, 보안, 액세스 권한을 포함하여 전체 제품 수명 주기에 대해 책임을 집니다. 제품은 서로 독립적이며 조직 전체의 가이드라인 및 제어는 일반적이지 않습니다.

다음 조건에 해당하면 이 계층 구조를 사용합니다.

• 각 제품에 대한 명확한 소유권과 책임이 있는 조직을 운영하는 경우
• 워크로드가 독립적이며 많은 공통 정책을 공유하지 않는 경우
• 프로세스 및 외부 개발자 플랫폼이 서비스 또는 제품 서비스로 제공되는 경우

다음 다이어그램은 전자상거래 플랫폼 제공업체의 계층 구조 예시를 보여줍니다.

이전 다이어그램에는 다음과 같은 계층 구조가 포함됩니다.

• 다음 폴더는 첫 번째 수준에 있습니다.
  • Ecommerce Modules 및 Logistics and Warehousing Modules 폴더는 제품 수명 주기 동안 동일한 액세스 권한 및 정책이 필요한 플랫폼 제품 내의 모듈을 나타냅니다.
  • Reconciliation and Billing 폴더는 플랫폼 오퍼링 내의 특정 비즈니스 구성요소에 대해 엔드 투 엔드 모듈을 담당하는 제품팀을 나타냅니다.
  • Bootstrap 폴더는 엔터프라이즈 기반 청사진에 설명된 대로 Google Cloud 인프라를 배포하는 데 필요한 공통 리소스를 나타냅니다.
• 각 폴더에는 서로 다른 제품팀이 담당하는 독립 모듈을 포함하는 다양한 프로젝트가 있습니다.

자세한 내용은 Fabric FAST Terraform 프레임워크 리소스 계층 구조를 참조하세요.

리소스 계층 구조 권장사항

다음 섹션에서는 선택한 리소스 계층 구조에 관계없이 권장되는 리소스 계층 구조 설계에 대한 권장사항을 설명합니다.

Cloud Identity 및 Google Workspace 계정 및 조직을 구성하는 방법에 대한 자세한 권장사항은 계정 및 조직 계획 권장사항을 참조하세요.

단일 조직 노드 사용

관리 오버헤드를 방지하려면 가능한 모든 경우에 단일 조직 노드를 사용합니다. 하지만 다음과 같은 사용 사례를 해결하기 위해서는 여러 조직 노드를 사용하는 것이 좋습니다.

• IAM 수준 또는 리소스 계층 구조의 주요 변경사항을 테스트하려는 경우
• 동일한 조직 정책이 없는 샌드박스 환경에서 실험하려는 경우
• 향후 매각되거나 완전히 별개의 법인으로 운영될 가능성이 있는 하위 회사가 조직에 포함된 경우

표준화된 명명 규칙 사용

조직 전체에서 표준화된 명명 규칙을 사용합니다. 보안 기반 청사진에는 요구사항에 맞게 조정할 수 있는 샘플 명명 규칙이 포함되어 있습니다.

부트스트랩 리소스 및 공통 서비스 분리 유지

코드형 인프라 (IaC)를 사용하여 Google Cloud 환경을 부트스트랩하고 환경 또는 애플리케이션 사이에 공유되는 공통 서비스를 위해 폴더를 개별적으로 유지합니다. 리소스 계층의 조직 노드 바로 아래에 부트스트랩 폴더를 배치합니다.

선택한 서비스에 따라 공통 서비스 폴더를 계층 구조의 여러 수준에 배치하세요.

다음 사항에 해당하면 공통 서비스 폴더를 조직 노드 바로 아래에 배치하도록 합니다.

• 계층 구조가 최상위 수준에서 애플리케이션 환경을 사용하고 두 번째 레이어에서 팀 또는 애플리케이션을 사용하는 경우
• 환경 간에 공통적인 모니터링과 같은 공유 서비스가 있는 경우

다음 사항에 해당하면 공통 서비스 폴더를 애플리케이션 폴더 아래의 하위 수준에 배치합니다.

• 애플리케이션 간에 공유되는 서비스가 있으며 각 배포 환경에 대해 개별 인스턴스를 배포합니다.

• 애플리케이션은 각 배포 환경에 대해 개발 및 테스트가 필요한 마이크로서비스를 공유합니다.

다음 다이어그램은 계층 구조의 하위 수준에 있는 각 애플리케이션 환경의 모든 환경 및 공유 서비스 폴더에서 사용하는 공유 인프라 폴더가 있는 계층 구조의 예시를 보여줍니다.

이전 다이어그램에는 다음과 같은 계층 구조가 포함됩니다.

• 첫 번째 수준의 폴더는 다음과 같습니다.
  • Development environment 폴더와 Production environment 폴더에는 애플리케이션 환경이 포함됩니다.
  • Shared infrastructure 폴더에는 모니터링과 같이 환경 간에 공유되는 공통 리소스가 포함됩니다.
  • Bootstrap 폴더에는 엔터프라이즈 기반 청사진에 설명된 대로 Google Cloud 인프라를 배포하는 데 필요한 공통 리소스가 포함됩니다.
• 두 번째 수준에는 다음 폴더가 있습니다.
  • 각 애플리케이션의 각 환경에 있는 폴더(App 1 및 App 2). 이러한 애플리케이션의 리소스가 포함됩니다.
  • 애플리케이션 간에 공유되지만 각 환경에 독립적인 서비스를 포함하는 두 애플리케이션 환경의 Shared 폴더입니다. 예를 들어 프로덕션 보안 비밀과 비프로덕션 보안 비밀에 서로 다른 허용 정책을 적용할 수 있도록 폴더 수준 보안 비밀 프로젝트가 있을 수 있습니다.
• 각 애플리케이션 폴더에는 각 애플리케이션의 일부인 독립 모듈을 포함하는 다양한 프로젝트가 있습니다.

다음 단계

• 시작 영역에 사용할 네트워크 설계(이 시리즈의 다음 문서).
• 엔터프라이즈 기반 청사진 검토
• Google Cloud 보안 권장사항 센터에서 제공되는 청사진 및 백서 읽기