애플리케이션 중심 Google Cloud를 사용하면 Google Cloud에서 일관된 방식으로 애플리케이션을 만들고 관리할 수 있습니다. App Hub 및 App Design Center에서 애플리케이션 설계 및 관리에 대한 권장사항을 따르면 비즈니스 목표에 부합하는 운영 가능하고 관리 가능하며 효율적인 애플리케이션을 빌드하는 데 도움이 됩니다.
애플리케이션 관리의 핵심 원칙
다음 핵심 원칙을 준수하면 애플리케이션 중심 방식으로 Google Cloud 인프라를 관리하여 얻는 가치를 극대화할 수 있습니다.
명확한 경계 정의: 운영, 모니터링, 거버넌스, 문제 해결에 논리적인 방식으로 애플리케이션 관리 경계를 설정합니다. 또한 애플리케이션 구성요소로 사용하는 이 경계 내의 리소스는 관리를 간소화하고 위험을 줄이기 위해 공동 운영 수명 주기 또는 비즈니스 가치를 공유하는 것이 이상적입니다.
운영 목적을 위해서는 애플리케이션 관리 경계와 모니터링 가능성 범위의 차이를 이해하는 것이 중요합니다.
- 애플리케이션 관리 경계는 주요 개념에 설명된 대로 애플리케이션을 설계, 생성, 관리하는 데 사용할 수 있는 Google Cloud 리소스가 포함된 프로젝트 모음을 정의합니다.
- Google Cloud Observability의 모니터링 가능성 범위를 사용하면 여러 프로젝트의 원격 분석을 함께 볼 수 있습니다.
로그, 측정항목, trace 범위에는 애플리케이션 관리 경계에 포함된 동일한 프로젝트의 데이터가 포함되어야 합니다. 모니터링 가능성 범위에 대한 자세한 내용은 모니터링 가능성 범위 구성을 참조하세요.
비즈니스 기능 반영: 기술 레이어뿐만 아니라 비즈니스 기능 또는 엔드 투 엔드 워크플로를 중심으로 애플리케이션을 정의합니다. 애플리케이션은 비즈니스의 고유한 가치 흐름을 나타내야 합니다.
명확한 소유권 및 메타데이터 설정: 각 애플리케이션에 명확한 속성을 할당하여 팀이 App Hub에서 애플리케이션을 효과적으로 찾고, 이해하고, 관리할 수 있도록 합니다. 이러한 속성은 검색 가능성과 거버넌스를 지원합니다. 검색 가능성은 개발자 및 운영자와 같은 관련 팀이 애플리케이션을 찾을 수 있음을 의미합니다. 거버넌스는 각 애플리케이션의 소유자와 책임자를 명확하게 정의합니다.
App Hub에서는 다음과 같은 주요 속성을 정의할 수 있습니다.
- 환경: 애플리케이션 수명 주기의 단계(예: 프로덕션, 스테이징, 테스트 또는 개발)입니다. 이 속성은 팀이 배포 단계에 따라 구성요소를 필터링하고 관리하는 데 도움이 됩니다.
- 중요도: 애플리케이션 및 구성요소의 비즈니스 중요도(예: 미션 크리티컬 여부)입니다. 이 속성은 모니터링 및 사고 대응 우선순위를 알릴 수 있습니다.
- 소유자: 애플리케이션을 담당하는 여러 팀의 연락처 정보로, 책임감을 높이고 커뮤니케이션을 간소화하며 책임을 명확히 합니다.
애플리케이션 설계 센터는 이러한 속성을 지원하며 애플리케이션 구성요소의 위치 및 구성 세부정보도 포함합니다. 이러한 속성과 세부정보를 일관되게 적용하는 것은 탐색, 거버넌스, 보고에 매우 중요합니다.
발전을 위한 설계: App Design Center를 사용하면 애플리케이션에 재사용 가능한 템플릿을 만들어 발전을 위한 설계를 할 수 있습니다. 기본 템플릿을 업데이트하는 경우 애플리케이션을 재배포하여 변경사항을 적용할 수 있습니다. 이를 통해 수요를 충족하고, 새로운 기능을 도입하고, 아키텍처를 변경하여 향후 성장과 진화하는 인프라 요구사항을 수용할 수 있습니다.
애플리케이션 모델 반복 및 미세 조정: 조직 구조, 비즈니스 우선순위, 기술 아키텍처의 변화를 반영하도록 애플리케이션 정의를 정기적으로 검토하고 조정합니다. Cloud Hub는 Application Design Center 템플릿에서 배포된 애플리케이션에 사용할 수 있는 업데이트를 중앙 집중식 뷰로 제공하므로, 변화하는 요구사항을 반영하도록 애플리케이션 정의를 검토하고 조정할 수 있습니다.
데이터 모델 권장사항
App Hub 프레임워크 내에서 실제 시스템을 애플리케이션, 서비스, 워크로드로 모델링하는 방법을 이해하면 Google Cloud환경에서 애플리케이션 관리 기능을 효과적으로 사용할 수 있습니다.
애플리케이션을 정의할 때는 속성을 사용하여 명확한 소유권과 메타데이터를 설정하는 등 애플리케이션 관리의 핵심 원칙을 적용하는 것이 중요합니다.
이 프레임워크를 염두에 두고 애플리케이션 구성요소를 모델링하려면 다음 권장 사용 사례 예를 참고하세요.
예시: 마이크로서비스 기반 애플리케이션
온라인 상점의 OpenTelemetry 데모에 설명된 것과 같은 전자상거래 시스템은 마이크로서비스 기반 애플리케이션의 예시입니다. 이러한 종류의 시스템은 단일 애플리케이션으로 모델링하는 것이 좋습니다. 이 접근 방식은 제품 검색부터 결제까지 전체 비즈니스 기능에 대한 통합 뷰를 제공합니다. 예를 들어 Google Cloud에서 실행되는 기존 리소스에 대한 다음 모델을 고려하세요.
애플리케이션: App Hub에서 단일 애플리케이션을 만들거나 정의합니다(예:
my-ecommerce-site). 이 애플리케이션은 전체 온라인 상점을 관리 가능한 단일 단위로 나타냅니다. 다음 리소스를 애플리케이션에 등록하여 온라인 상점의 비즈니스 기능을 공동으로 제공하는 구성요소의 논리적 그룹을 만듭니다.- 마이크로서비스를 워크로드로 사용: 광고, 장바구니, 결제와 같이 전자상거래 시스템을 구성하는 개별 마이크로서비스를 애플리케이션 내의 워크로드로 등록합니다. 이러한 리소스는 비즈니스 로직의 개별 부분을 수행하는 바이너리 코드가 있는 컴퓨팅 리소스로, Google Kubernetes Engine (GKE) 배포로 실행됩니다.
- 서비스로서의 네트워크 엔드포인트: 부하 분산기와 같은 이러한 마이크로서비스의 네트워크 엔드포인트를 애플리케이션의 서비스로 등록합니다. 이러한 API는 온라인 상점 기능을 클라이언트에 노출합니다.
각 마이크로서비스를 자체 애플리케이션으로 등록하지 마세요. 이러한 접근 방식은 비즈니스 컨텍스트를 단편화하고 온라인 상점의 상태와 성능을 종합적으로 파악하기 어렵게 만듭니다.
모든 마이크로서비스를 단일 애플리케이션으로 그룹화하면 다음과 같은 이점이 있습니다.
- 포괄적인 가시성: 광고 기능부터 결제 기능까지 전체 이커머스 사용자 여정의 상태와 성능을 하나의 통합 뷰에서 모니터링할 수 있습니다.
- 명확한 비즈니스 컨텍스트: 애플리케이션은 인프라를 제공하는 비즈니스 기능(온라인 상점)에 맞게 조정합니다. 이 접근 방식을 사용하면 애플리케이션의 상태와 비용을 더 쉽게 이해할 수 있습니다.
- 간소화된 문제 해결: 문제가 발생하면 애플리케이션 내의 다양한 마이크로서비스 간의 종속 항목을 확인하여 근본 원인 분석을 가속화할 수 있습니다.
예시: 3계층 웹 애플리케이션
3계층 웹 애플리케이션은 애플리케이션을 프런트엔드 계층, 백엔드 계층, 데이터베이스 계층으로 분리하는 아키텍처 패턴입니다. 이 사용 사례에서는 각 계층을 격리된 구성요소로 취급하는 대신 전체 비즈니스 함수를 단일 애플리케이션으로 모델링하는 방법을 보여줍니다.
다음 모델은 기술 레이어를 3계층 웹 애플리케이션에 매핑합니다.
애플리케이션: 웹 애플리케이션을 구성하는 모든 구성요소의 논리적 컨테이너 역할을 하는 단일 애플리케이션(예:
my-web-app)을 만듭니다.서비스: 다른 계층 또는 사용자에게 기능을 노출하는 네트워크 인터페이스를 서비스로 등록합니다. 예를 들면 다음과 같습니다.
- 사용자 트래픽을 수신하는 프런트엔드 부하 분산기입니다.
- 프런트엔드와 백엔드 간의 트래픽을 관리하는 내부 부하 분산기입니다.
- 백엔드 로직 계층에 데이터 서비스를 노출하는 Cloud SQL 또는 Spanner 데이터베이스 인스턴스
워크로드: 애플리케이션 코드를 실행하는 컴퓨팅 리소스를 워크로드로 등록합니다. 예를 들면 다음과 같습니다.
- 프런트엔드 사용자 인터페이스를 제공하는 관리형 인스턴스 그룹 (MIG) 또는 Google Kubernetes Engine 배포
- 백엔드 비즈니스 로직을 실행하는 MIG 또는 Google Kubernetes Engine 배포
세 계층을 모두 단일 애플리케이션으로 그룹화하면 다음과 같은 이점이 있습니다.
- 통합 모니터링 가능성: 세 개의 개별 애플리케이션에서 데이터를 조합할 필요 없이 애플리케이션 모니터링의 단일 대시보드에서 전체 애플리케이션의 상태와 성능을 모니터링할 수 있습니다.
- 명확한 소유권: 비즈니스, 개발자, 운영자 소유자를
my-web-app애플리케이션에 할당하여 전체 비즈니스 기능에 대한 책임을 명확히 할 수 있습니다. - 간소화된 거버넌스:
my-web-app수준에서 정책 및 액세스 제어를 적용하여 모든 등급에서 일관된 거버넌스를 지원할 수 있습니다.
애플리케이션 설계 및 거버넌스 전략
다음 전략을 채택하여 App Hub 및 App Design Center 설정이 확장 가능하고, 관리 가능하며, 운영 관행에 부합하는지 확인하세요.
전역 애플리케이션과 리전 애플리케이션 중에서 선택
애플리케이션에 대해 선택하는 위치(전역 또는 리전)는 데이터 처리, 지연 시간, 규정 준수에 영향을 미치는 기본적인 결정입니다.
- 리전 애플리케이션 우선순위 지정: 가능하면 애플리케이션을 리전으로 정의합니다. 이 방식은 지연 시간 감소, 잠재적 비용 절감, 데이터 레지던시 요구사항 준수와 같은 이점을 제공합니다. 리전 애플리케이션은 모든 애플리케이션 구성요소가 단일 Google Cloud 리전 내에 상주하여 리전별 Google Cloud 기능 및 장애 도메인과 고유한 호환성을 제공하는 경우에 권장됩니다. 가용성이 높은 시스템을 빌드하는 방법에 대한 안내는 리소스 중복을 통해 가용성이 높은 시스템 빌드를 참조하세요.
- 전역 애플리케이션을 전략적으로 사용: 시스템 구성요소가 여러 리전에 분산되어 있거나 전역 외부 애플리케이션 부하 분산기와 같은 전역 Google Cloud 리소스가 포함된 경우에만 전역 애플리케이션을 선택합니다.
- 멀티 리전 시스템 분해: 단일의 응집력 있는 전역 함수를 형성하지 않는 여러 리전에 리소스가 있는 경우 각 리전 내의 구성요소에 대해 별도의 리전 애플리케이션을 정의하는 것이 좋습니다. 이렇게 하면 각 배포에 대해 리전화의 이점을 극대화할 수 있습니다.
App Hub의 다양한 배포 지역 간의 자세한 비교는 전역 및 리전 애플리케이션을 참조하세요.
환경을 별도의 애플리케이션으로 분리
보안, 권한, 운영 위험에 대한 격리를 지원하려면 개발, 스테이징, 프로덕션과 같은 다양한 배포 환경을 별개의 애플리케이션으로 나타냅니다. 예를 들어 애플리케이션을 my-app-dev, my-app-staging, my-app-prod로 구성할 수 있습니다.
환경을 별도의 애플리케이션으로 분리하면 액세스 제어, 정책 시행, 모니터링에 대한 정확한 제한이 제공됩니다. 또한 애플리케이션 구성요소에서 속성, 구성 세부정보, 위치를 일관되게 사용하면 검색 가능성이 향상되고 거버넌스가 적용됩니다. 이러한 속성은 필터링, 보고, 정책 적용을 위한 풍부한 메타데이터를 제공합니다. 예를 들어 Environment 속성은 고유한 배포 환경 정책에 대한 세부적인 세부정보와 리소스별 제어를 제공합니다. 이 속성 및 기타 속성에 관한 자세한 내용은 속성을 참고하세요.
애플리케이션 관리 경계를 팀 구조에 맞게 조정
애플리케이션 관리 경계 내에서 조직 구조, 특히 애플리케이션 개발 및 운영을 담당하는 팀을 나타냅니다.
이 방식은 애플리케이션 모델이 비즈니스에서 기능을 달성하기 위해 작업을 분할, 그룹화, 조정하는 방법을 정의하는 데 사용하는 프레임워크를 반영하므로 소유권과 커뮤니케이션을 간소화합니다.
애플리케이션 수명 주기 따르기
App Hub를 App Design Center와 통합하여 원활한 애플리케이션 수명 주기 환경을 제공합니다.
- 애플리케이션에 등록할 기존 리소스가 있음: App Hub를 사용하여 기존 Google Cloud 리소스를 애플리케이션의 서비스 또는 워크로드로 등록합니다. 이 관행은 현재 인프라에 대한 통합 가시성과 운영 제어를 빠르게 제공합니다. 원하는 경우 나중에 App Design Center에서 실행 중인 애플리케이션을 기반으로 템플릿을 만들어 향후 배포를 위한 아키텍처를 표준화할 수 있습니다.
- 애플리케이션에 등록할 기존 리소스가 없음: App Design Center를 사용하여 관리되는 재사용 가능한 템플릿에서 새 애플리케이션을 설계하고 배포합니다. App Design Center 템플릿에서 애플리케이션을 배포하면 구성요소가 App Hub에 자동으로 등록되므로 애플리케이션 모델이 의도한 설계를 정확하게 반영합니다. 또한 Application Design Center를 사용하면 템플릿 버전을 기반으로 일관된 애플리케이션 업데이트를 관리할 수 있습니다. 템플릿을 업데이트하면 애플리케이션을 재배포하여 변경사항을 전파하고 일관성과 거버넌스를 지원할 수 있습니다.
리소스 계층 구조 고려사항
Google Cloud의 리소스 계층 구조는 실용적인 애플리케이션 관리의 기반입니다. 관리 프로젝트를 구성하여 애플리케이션 관리 경계를 정의함으로써 해당 계층 구조 위에 애플리케이션 관리 레이어를 도입합니다. 애플리케이션 중심 Google Cloud 솔루션의 일부로 다양한 제품이 함께 작동하는 방식에 대한 개요는 애플리케이션 중심 Google Cloud를 참조하세요.
애플리케이션 관리를 위한 Google Cloud 리소스 계층 구조를 신중하게 계획하는 것은 논리적 그룹을 설정하는 데 필수적입니다. 애플리케이션 관리 경계를 정의하기 위해 단일 프로젝트, 폴더 또는 프로젝트 집합을 선택하면 거버넌스, 정책 시행, 리소스 검색이 근본적으로 형성됩니다. 또한 애플리케이션 중심 Google Cloud 제품 지원은 이 애플리케이션 관리 경계를 정의하는 방법에 따라 달라집니다.
리소스 계층 구조 및 비즈니스 요구사항에 가장 적합한 애플리케이션 관리 경계를 정의하고 다양한 리소스 구조 패턴에 대한 제품 지원을 알아보려면 애플리케이션 설정 모델 선택을 참조하세요.
지속적인 미세 조정
애플리케이션 설계는 정적이지 않으며 일반적으로 시간이 지남에 따라 발전합니다. 애플리케이션을 정기적으로 검토하고 미세 조정하여 비즈니스 기능, 팀 구조, 변화하는 아키텍처에 계속 부합하는지 확인합니다.
Cloud Hub 및 Gemini Cloud Assist의 인사이트를 사용하여 최적화 기회를 파악하고 이에 따라 애플리케이션을 조정하는 것이 좋습니다. Application Design Center를 사용하여 아키텍처 변경사항을 모델링 및 배포하고 템플릿을 통해 애플리케이션의 수명 주기를 관리합니다.