이 가이드에서는 App Hub 및 Application Design Center를 사용하여 애플리케이션 중심 Google Cloud에서 App Hub 애플리케이션을 설계, 정의, 관리하는 권장사항을 제공합니다. 이러한 관행을 따르는 것은 비즈니스 목표에 부합하는 작동 가능하고 관리 가능하며 효율적인 애플리케이션을 만드는 데 중요합니다.
애플리케이션 관리의 핵심 원칙
다음 핵심 원칙을 준수하면 애플리케이션 중심 방식으로 Google Cloud 인프라를 관리할 때 얻을 수 있는 가치를 극대화할 수 있습니다.
명확한 경계 정의: 운영, 모니터링, 거버넌스, 문제 해결에 논리적인 방식으로 애플리케이션 관리 경계를 설정합니다. 또한 이 경계 내에서 애플리케이션 구성요소로 사용하는 리소스는 관리 작업을 간소화하고 위험을 줄이기 위해 공동 운영 라이프사이클 또는 비즈니스 가치를 공유하는 것이 좋습니다.
운영 목적으로 애플리케이션 관리 경계와 관측 가능성 범위의 차이를 이해하는 것이 중요합니다.
- 애플리케이션 관리 경계는 주요 개념에 설명된 대로 애플리케이션을 설계, 생성, 관리하는 데 사용할 수 있는 Google Cloud 리소스가 포함된 프로젝트 모음을 정의합니다.
- Google Cloud Observability의 관측 가능성 범위를 사용하면 여러 프로젝트의 원격 분석을 함께 볼 수 있습니다.
로그, 측정항목, 트레이스 범위에는 애플리케이션 관리 경계에 포함된 것과 동일한 프로젝트의 데이터가 포함되어야 합니다. 관측 가능성 범위에 관한 자세한 내용은 관측 가능성 범위 구성을 참고하세요.
비즈니스 기능 반영: 기술 레이어가 아닌 비즈니스 기능 또는 엔드 투 엔드 워크플로를 중심으로 애플리케이션을 정의합니다. 애플리케이션은 비즈니스의 고유한 가치 스트림을 나타내야 합니다.
명확한 소유권 및 메타데이터 설정: 각 애플리케이션에 명확한 속성을 할당하여 팀이 App Hub에서 애플리케이션을 효과적으로 찾고, 이해하고, 관리할 수 있도록 합니다. 이러한 속성은 검색 가능성과 거버넌스를 지원합니다. 검색 가능성은 개발자 및 운영자와 같은 관련 팀이 애플리케이션을 찾을 수 있음을 의미합니다. 거버넌스는 각 애플리케이션의 소유자 및 책임자를 명확하게 정의합니다.
App Hub에서 다음과 같은 주요 속성을 정의할 수 있습니다.
- 환경: 애플리케이션 수명 주기의 단계(예: 프로덕션, 스테이징, 테스트, 개발)입니다. 이 속성은 팀이 배포 단계에 따라 구성요소를 필터링하고 관리하는 데 도움이 됩니다.
- 중요도: 애플리케이션 및 구성요소의 비즈니스 중요도입니다(예: 미션 크리티컬 여부). 이 속성은 모니터링 및 사고 대응 우선순위를 알릴 수 있습니다.
- 소유자: 애플리케이션을 담당하는 여러 팀의 연락처 정보로, 책임감을 높이고, 커뮤니케이션을 간소화하며, 책임을 명확히 합니다.
애플리케이션 설계 센터는 이러한 속성을 지원하며 애플리케이션 구성요소의 위치 및 구성 세부정보도 포함합니다. 이러한 속성과 세부정보를 일관되게 적용하는 것은 검색, 거버넌스, 보고에 매우 중요합니다.
진화를 위한 설계: Application 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 및 Application Design Center 설정이 확장 가능하고 관리 가능하며 운영 관행과 일치하는지 확인하세요.
전역 및 리전 애플리케이션 중에서 선택
애플리케이션에 대해 선택하는 위치(전역 또는 리전)는 데이터 처리, 지연 시간, 규정 준수에 영향을 미치는 기본적인 결정입니다.
- 지역 애플리케이션 우선순위 지정: 가능한 경우 애플리케이션을 지역으로 정의합니다. 이 방식을 사용하면 지연 시간 감소, 잠재적 비용 절감, 데이터 상주 요구사항 준수와 같은 이점이 있습니다. 모든 애플리케이션 구성요소가 단일 Google Cloud 리전 내에 있는 경우 리전별 Google Cloud 기능 및 장애 도메인과의 호환성이 내재된 리전 애플리케이션을 사용하는 것이 좋습니다. 가용성이 높은 시스템을 빌드하는 방법에 관한 안내는 리소스 중복을 통해 가용성이 높은 시스템 빌드를 참고하세요.
- 전역 애플리케이션 전략적으로 사용: 시스템의 구성요소가 여러 리전에 분산되어야 하거나 전역 외부 애플리케이션 부하 분산기와 같은 전역 Google Cloud 리소스를 포함하는 경우에만 전역 애플리케이션을 선택합니다.
- 멀티 리전 시스템 분해: 단일의 응집력 있는 전역 함수를 형성하지 않는 리소스가 여러 리전에 있는 경우 각 리전 내 구성요소에 대해 별도의 리전 애플리케이션을 정의하는 것이 좋습니다. 이렇게 하면 각 배포의 지역화 이점이 극대화됩니다.
App Hub의 다양한 배포 지역을 자세히 비교하려면 전역 및 리전 애플리케이션을 참고하세요.
환경을 별도의 애플리케이션으로 분리
보안, 권한, 운영 위험을 위한 격리를 지원하려면 개발, 스테이징, 프로덕션과 같은 다양한 배포 환경을 별도의 애플리케이션으로 나타내세요. 예를 들어 애플리케이션을 my-app-dev, my-app-staging, my-app-prod로 구성할 수 있습니다.
환경을 별도의 애플리케이션으로 분리하면 액세스 제어, 정책 시행, 모니터링에 대한 정확한 제한이 제공됩니다. 또한 애플리케이션 구성요소에서 속성, 구성 세부정보, 위치를 일관되게 사용하면 검색 가능성이 향상되고 거버넌스가 적용됩니다. 이러한 속성은 필터링, 보고, 정책 적용을 위한 풍부한 메타데이터를 제공합니다. 예를 들어 Environment 속성은 고유한 배포 환경 정책에 대한 세부적인 정보와 리소스별 제어를 제공합니다. 이 속성 및 기타 속성에 관한 자세한 내용은 속성 및 속성을 참고하세요.
애플리케이션 관리 경계를 팀 구조와 일치시킴
애플리케이션 관리 경계 내에서 조직 구조, 특히 애플리케이션 개발 및 운영을 담당하는 팀을 나타냅니다.
이 방법을 사용하면 비즈니스에서 기능을 달성하기 위해 작업을 나누고, 그룹화하고, 조정하는 방법을 정의하는 프레임워크가 애플리케이션 모델에 반영되므로 소유권과 커뮤니케이션이 간소화됩니다.
애플리케이션 수명 주기 따르기
원활한 애플리케이션 수명 주기 환경을 위해 App Hub를 Application Design Center와 통합합니다.
- 애플리케이션에 등록할 기존 리소스가 있는 경우: App Hub를 사용하여 기존 Google Cloud 리소스를 애플리케이션의 서비스 또는 워크로드로 등록합니다. 이 방법을 사용하면 현재 인프라에 대한 통합 가시성과 운영 제어 기능을 빠르게 확보할 수 있습니다. 원하는 경우 나중에 실행 중인 애플리케이션에서 App Design Center에 템플릿을 만들어 향후 배포를 위한 아키텍처를 표준화할 수 있습니다.
- 애플리케이션에 등록할 기존 리소스가 없는 경우: Application Design Center를 사용하여 관리되고 재사용 가능한 템플릿에서 새 애플리케이션을 설계하고 배포합니다. Application Design Center 템플릿에서 애플리케이션을 배포하면 구성요소가 App Hub에 자동으로 등록되므로 애플리케이션 모델에 의도한 설계가 정확하게 반영됩니다. 또한 애플리케이션 설계 센터를 사용하면 템플릿 버전을 기반으로 일관된 애플리케이션 업데이트를 관리할 수 있습니다. 템플릿을 업데이트하면 변경사항을 전파하기 위해 애플리케이션을 재배포하여 일관성과 거버넌스를 지원할 수 있습니다.
리소스 계층 구조 고려사항
Google Cloud의 리소스 계층 구조는 실제 애플리케이션 관리의 기반입니다. 관리 프로젝트를 구성하여 계층 구조 위에 애플리케이션 관리 레이어를 도입하여 애플리케이션 관리 경계를 정의합니다. 다양한 제품이 애플리케이션 중심 Google Cloud 솔루션의 일부로 어떻게 함께 작동하는지 개요를 보려면 애플리케이션 중심 Google Cloud를 참고하세요.
애플리케이션 관리를 위한 Google Cloud 리소스 계층 구조를 신중하게 계획하는 것은 논리적 그룹을 설정하는 데 필수적입니다. 애플리케이션 관리 경계를 정의하기 위해 단일 프로젝트, 폴더 또는 프로젝트 집합을 선택하면 거버넌스, 정책 시행, 리소스 검색이 근본적으로 달라집니다. 또한 애플리케이션 중심 Google Cloud 제품 지원은 이 애플리케이션 관리 경계를 정의하는 방식에 따라 달라집니다.
리소스 계층 구조 및 비즈니스 요구사항에 가장 적합한 애플리케이션 관리 경계를 정의하고 다양한 리소스 구조 패턴에 대한 제품 지원에 대해 알아보려면 애플리케이션 설정 모델 선택을 참고하세요.
지속적인 개선
애플리케이션 설계는 정적이지 않으며 일반적으로 시간이 지남에 따라 발전합니다. 애플리케이션이 비즈니스 기능, 팀 구조, 변화하는 아키텍처와 계속 일치하도록 정기적으로 검토하고 개선하세요.
Cloud 허브 및 Gemini Cloud Assist의 인사이트를 사용하여 최적화 기회를 파악하고 이에 따라 애플리케이션을 조정하는 것이 좋습니다. Application Design Center를 사용하여 아키텍처 변경사항을 모델링하고 배포하며 템플릿을 통해 애플리케이션의 수명 주기를 관리합니다.