하이브리드 및 멀티 클라우드의 모니터링 패턴과 로깅 패턴

Last reviewed 2024-06-11 UTC

이 문서에서는 하이브리드 및 멀티 클라우드 배포를 위한 모니터링 및 로깅 아키텍처와 Google Cloud를 사용하여 이를 구현하기 위한 권장사항에 대해 논의합니다. 이 문서를 통해 환경에 가장 적합한 패턴과 제품을 확인할 수 있습니다.

모든 기업은 고유한 애플리케이션 워크로드 포트폴리오를 통해 하이브리드 또는 멀티 클라우드 설정의 아키텍처에 대한 요구사항과 제약 조건을 관리합니다. 이러한 제약 조건 및 요구 사항을 충족하도록 아키텍처를 설계하고 맞춤화해야 하지만 몇 가지 일반적인 패턴에 의존할 수 있습니다.

이 문서에서 다루는 패턴은 다음 두 가지 카테고리로 분류됩니다.

  • 단일 창구 아키텍처에서는 모든 모니터링 및 로깅이 중앙 집중화되며 단일 액세스 및 제어 포인트를 제공합니다.
  • 별도의 애플리케이션 및 작업 아키텍처에서는 민감한 정보에 대한 규정 준수 요건을 충족하기 위해 민감한 애플리케이션 데이터가 덜 민감한 운영 데이터와 분리됩니다.

아키텍처 패턴 선택

다음 다이어그램의 결정 트리를 사용하여 사용 사례에 가장 적합한 아키텍처를 파악할 수 있습니다.

모니터링 및 로깅 아키텍처 선택을 위한 결정 트리

각 아키텍처에 대한 자세한 내용은 이 문서에서 자세히 논의하지만 대략적으로 다음과 같이 선택할 수 있습니다.

  • Monitoring에서 레거시 솔루션으로 내보내기
  • 레거시 솔루션으로 직접 내보내기
  • Prometheus 및 Fluentd 또는 Fluent Bit와 Monitoring 사용하기
  • observIQ BindPlane과 Monitoring 사용하기

단일 창구 아키텍처

하이브리드 시스템의 일반적인 목표는 여러 애플리케이션 및 환경의 다양한 소스에서 발생하는 모니터링 및 로깅 정보를 단일 디스플레이로 통합하는 것입니다. 이 유형의 디스플레이는 단일 창구라고 합니다.

아래 다이어그램은 온프레미스와 클라우드의 모든 애플리케이션의 모니터링 및 로깅 데이터가 클라우드에서 호스팅되는 단일 저장소로 중앙 집중화되는 이 패턴을 보여줍니다.

모니터링 및 로깅의 개략적인 아키텍처

이 아키텍처에는 다음과 같은 장점이 있습니다.

  • 모든 모니터링 및 로깅 정보를 일관적인 하나의 뷰로 확인할 수 있습니다.
  • 한 곳에서 데이터 스토리지와 보관을 관리할 수 있습니다.
  • 중앙 집중식 액세스 제어 및 감사가 가능합니다. 하지만 중앙 저장소로 전송되는 데이터의 보안은 유지해야 합니다.

단일 창구로서 Monitoring

Cloud Monitoring은 서비스, 컨테이너, 애플리케이션, 인프라를 위한 Google 관리 모니터링 및 관리 솔루션입니다. 측정항목, 로그, trace, 이벤트를 위한 단일 제어 창과 강력한 스토리지 솔루션의 경우 Google Cloud Observability를 사용합니다. 또한 대시보드, 보고, 알림 등의 관찰 기능 도구 모음을 제공합니다.

모든 Google Cloud 제품 및 서비스는 Monitoring과의 통합을 지원합니다. 또한 Monitoring을 하이브리드 및 온프레미스 리소스로 확장하는 데 사용할 수 있는 여러 통합된 도구가 있습니다.

Monitoring을 단일 창구로 사용하는 모든 아키텍처에 적용되는 권장사항은 다음과 같습니다.

Monitoring 및 observIQ의 BindPlane을 사용한 하이브리드 모니터링 및 로깅

Google의 파트너 observIQ의 BindPlane을 사용하면 Amazon Web Services(AWS), Microsoft Azure, Alibaba Cloud, IBM Cloud 등의 다른 클라우드 제공업체 및 온프레미스 VM의 모니터링 및 로깅 데이터를 Google Cloud로 가져올 수 있습니다. 다음 다이어그램은 Monitoring과 BindPlane이 하이브리드 클라우드에 대한 단일 창구를 제공하는 방식을 보여줍니다.

BindPlane과 Monitoring을 사용한 모니터링 및 로깅의 개략적인 아키텍처

이 아키텍처에는 다음과 같은 장점이 있습니다.

이 패턴을 구현하는 방법에 대한 자세한 내용은 BindPlane으로 온프레미스 리소스 로깅 및 모니터링을 참조하세요.

Prometheus와 Monitoring을 사용한 하이브리드 Google Kubernetes Engine 모니터링

Google Cloud에서 완전 관리형의 인기 있는 오픈소스 모니터링 솔루션인 Google Cloud Managed Service for Prometheus를 사용하면 Monitoring으로 여러 Kubernetes 클러스터에서 실행 중인 애플리케이션을 모니터링할 수 있습니다. 이 아키텍처는 통합 인터페이스를 제공하므로 Google Cloud 기반 Google Kubernetes Engine(GKE) 및 온프레미스 데이터 센터의 Google Distributed Cloud에 분산된 Kubernetes 워크로드를 실행할 때 유용합니다. 다음 다이어그램은 Prometheus와 Monitoring 수집기를 사용하여 데이터를 수집하는 방법을 보여줍니다.

Prometheus와 Monitoring을 사용한 GKE 모니터링의 개략적인 아키텍처

이 아키텍처에는 다음과 같은 장점이 있습니다.

  • 클라우드 및 온프레미스 환경 전반에서 일관적인 Kubernetes 측정항목을 사용합니다.
  • Prometheus를 사용하고, 대규모 Prometheus 관리 및 운영을 수동으로 수행할 필요 없이 워크로드를 모니터링하고 알림을 설정할 수 있습니다.
  • Prometheus 사용에 대한 추가 라이선스 비용은 없습니다. Prometheus 측정항목은 Monitoring으로 가져옵니다. 가져오기는 청구 가능하며 수집된 샘플 수에 따라 가격이 책정됩니다.

이 아키텍처에는 다음과 같은 단점이 있습니다.

  • Prometheus는 모니터링만 지원하므로 로깅을 별도로 구성해야 합니다. 다음 섹션에서는 Fluentd 또는 Fluent Bit를 사용하는 로깅의 일반적인 옵션에 대해 설명합니다.

다음 권장사항을 따르는 것이 좋습니다.

  • 기본적으로 Prometheus는 노출된 모든 측정항목을 수집하며 각 측정항목은 청구 가능한 측정항목이 됩니다. 예상치 못한 비용을 방지하려면 Monitoring 비용 관리를 구현하세요.

Fluentd 또는 Fluent Bit와 Cloud Logging을 사용한 하이브리드 GKE 로깅

인기 있는 오픈소스 로깅 에이전트인 Fluentd 또는 Fluent Bit와 Cloud Logging을 사용하면 여러 GKE 클러스터에서 실행되는 애플리케이션의 로그를 Cloud Logging으로 수집할 수 있습니다. 이 아키텍처는 통합 인터페이스를 제공하므로 Google Cloud 기반 GKE 및 온프레미스 데이터 센터의 Google Distributed Cloud에 분산된 Kubernetes 워크로드를 실행할 때 유용합니다. 다음 다이어그램은 로그의 흐름을 보여줍니다.

Fluentd 또는 Fluent Bit, Monitoring, Logging을 사용하는 GKE 모니터링의 개략적인 아키텍처.

이 아키텍처에는 다음과 같은 장점이 있습니다.

  • 클라우드 환경과 온프레미스 환경 전체에서 일관적인 Kubernetes 로깅이 가능합니다.
  • Logging을 맞춤설정하여 민감한 정보를 필터링할 수 있습니다.
  • Fluentd 또는 Fluent Bit 사용에는 추가 라이선스 비용이 없습니다. Fluentd 또는 Fluent Bit를 사용하여 Logging으로 가져온 로그는 청구 가능합니다.

이 아키텍처에는 다음과 같은 단점이 있습니다.

  • Fluentd 및 Fluent Bit는 로깅만 지원하므로 모니터링을 별개로 구성해야 합니다. 이전 섹션에서는 Prometheus로 모니터링하기 위한 일반적인 옵션을 설명합니다.

이 패턴 구현에 관한 자세한 내용은 Google Kubernetes Engine 로그의 Fluent Bit 맞춤설정을 참조하세요.

단일 제어 창으로서의 파트너 서비스

Datadog 또는 Splunk와 같은 타사 모니터링 또는 로깅 서비스를 이미 사용하고 있다면 Logging으로 이동하지 않아도 됩니다. 이동하지 않는다면 Google Cloud에서 여러 일반적인 모니터링 및 로깅 서비스로 데이터를 내보내면 됩니다. 통합 모니터링 및 로깅 서비스를 사용하거나 필요에 가장 적합한 별도의 모니터링 및 로깅 서비스를 선택할 수 있습니다.

Logging에서 파트너 서비스로 내보내기

이 패턴에서는 Datadog와 같은 파트너의 모니터링 서비스를 Cloud Monitoring API에 연결하도록 승인합니다. 이 승인을 통해 서비스는 Logging에서 사용 가능한 모든 측정항목을 수집할 수 있으므로 Datadog를 모니터링을 위한 단일 창구로 사용할 수 있습니다.

Logging의 로깅 데이터는 Pub/Sub으로 내보낼 수 있습니다(로그 싱크). 이러한 내보내기는 Elastic이나 Splunk와 같은 파트너 로깅 서비스에서 실시간으로 많은 양의 Logging 로그를 수집할 수 있는 성능과 복원력이 우수한 방식이므로 이들 파트너 서비스를 로그의 단일 제어 창으로 사용할 수 있습니다.

다음 다이어그램은 로깅 및 모니터링을 위해 결합된 아키텍처를 보여줍니다.

모니터링 및 로깅 데이터를 파트너 서비스로 내보내는 작업의 개략적인 아키텍처

이 아키텍처에는 다음과 같은 장점이 있습니다.

  • 익숙한 기존 도구를 계속 사용할 수 있습니다.
  • Google Cloud 지원팀은 문제해결을 위해 Logging 로그에 계속 액세스할 수 있습니다.

이 아키텍처에는 다음과 같은 단점이 있습니다.

  • 파트너 솔루션은 일반적으로 외부에서 호스팅되므로 네트워크 연결이 끊기면 솔루션이 작동하지 않거나 데이터를 수집할 수 없습니다. 자체 호스팅을 통해 이러한 위험을 완화할 수 있지만 솔루션의 인프라를 직접 유지보수해야 합니다.
  • 외부 호스팅 대시 보드는 Google Cloud 지원팀에서 직접 이용할 수 없습니다. 이렇게 가용성이 떨어지면 문제해결 및 완화 속도가 느려질 수 있습니다.
  • 상업용 파트너 솔루션에는 라이선스 요금이 추가로 발생할 수 있습니다.

통합의 구체적인 예시는 다음과 같습니다.

Grafana로 Prometheus 및 Logging의 측정항목 분석

인기 있는 오픈소스 모니터링 도구인 Grafana는 보통 측정항목 수집을 위해 Prometheus와 함께 사용됩니다. 이 아키텍처에서는 온프레미스 수집 계층으로 Prometheus를 사용하고 Google Cloud 리소스와 온프레미스 리소스의 단일 창구로 Grafana를 사용합니다. 다음 다이어그램은 Google Cloud 및 온프레미스에서 측정항목을 분석하는 샘플 아키텍처를 보여줍니다.

Grapana를 단일 창구로 사용하는 모니터링의 개략적인 아키텍처

이 아키텍처에는 다음과 같은 장점이 있습니다.

  • VM과 컨테이너가 모두 있는 하이브리드 환경에 적합합니다.
  • 조직에서 이미 Prometheus와 Grapana를 사용 중인 경우 사용자가 계속 사용할 수 있습니다.

이 아키텍처에는 다음과 같은 단점이 있습니다.

자세한 내용은 Grafana용 Cloud Logging 플러그인으로 문제 해결 개선을 참조하세요

Fluentd를 사용하여 로그 내보내기

이전 패턴에는 Fluentd 또는 Fluent Bit를 Logging용 로그 수집기로 사용하는 방법이 포함되었습니다. BigQuery, Elastic, Splunk 등 Fluentd 또는 Fluent Bit를 지원하는 다른 로깅 또는 데이터 분석 시스템에도 동일한 기본 아키텍처를 사용할 수 있습니다. 다음 다이어그램은 이 패턴을 보여줍니다.

Fluentd 또는 Fluent Bit에서 직접 로그를 내보내는 개략적인 아키텍처

이 아키텍처에는 다음과 같은 장점이 있습니다.

  • VM과 컨테이너가 모두 있는 하이브리드 환경에 적합합니다.
  • Fluentd는 시스템 로그를 비롯한 여러 데이터 소스에서 읽을 수 있습니다.
  • Fluentd는 여러 인기 있는 서드 파티 로깅 및 데이터 분석 시스템에 대해 출력 플러그인을 제공합니다.
  • Fluent Bit도 시스템 로그를 포함하여 많은 입력을 읽을 수 있습니다.
  • Fluent Bit는 여러 인기 있는 서드 파티 로깅 및 데이터 분석 시스템에 대해 출력을 제공합니다.

이 아키텍처에는 다음과 같은 단점이 있습니다.

  • Fluentd 및 Fluent Bit는 로그만 지원하므로 모니터링을 별도로 구성해야 합니다. 이전 섹션에서 Prometheus 및 Grafana로 모니터링하기 위한 일반적인 옵션을 설명합니다.
  • Fluentd 및 Fluent Bit는 타사 도구이며 공식 Google 제품이 아닙니다. Google은 이들을 지원하지 않습니다.
  • 내보낸 로그는 문제 해결을 위해 Google Cloud 지원팀에서 사용할 수 없습니다. 특히 Google은 Logging이 사용 설정되지 않은 Google Distributed Cloud 클러스터에 대한 지원을 제공하지 않습니다.

별도의 애플리케이션 및 운영 데이터

단일 창구 아키텍처를 사용하려면 클라우드로 전송되는 데이터를 모니터링 및 로깅하는 스트리밍 애플리케이션이 필요합니다. 그러나 고객 데이터를 온프레미스에 보관하거나 퍼블릭 클라우드에 저장할 수 있는 데이터를 엄격하게 제한하는 장소에 보관해야 하는 규제 또는 규정 준수 요건이 있을 수 있습니다.

이러한 하이브리드 환경에 유용한 패턴은 아래 다이어그램에 설명된 바와 같이 민감한 애플리케이션 데이터를 저위험 운영 데이터와 분리하는 것입니다.

애플리케이션 데이터와 운영 데이터를 분리하는 개략적인 아키텍처

GKE Enterprise를 사용하여 애플리케이션과 시스템 데이터 분리

GKE Enterprise 제품군에 속하는 GKE Enterprise on VMware에는 온프레미스 클러스터를 모니터링할 수 있는 Grafana가 포함되어 있습니다. 로깅을 위해 Elastic Stack 또는 Splunk와 같은 파트너 솔루션을 설치할 수도 있습니다. 이러한 솔루션을 사용하면 시스템 데이터를 Google Cloud의 Logging으로 내보내면서 온프레미스에서 민감한 애플리케이션 데이터 전부를 수집하고 볼 수 있습니다. 이 아키텍처를 다이어그램으로 나타내면 다음과 같습니다.

GKE Enterprise로 애플리케이션과 시스템 데이터 분리

이 아키텍처에는 다음과 같은 장점이 있습니다.

  • 민감한 애플리케이션 데이터는 전부 온프레미스에 보관됩니다.
  • 온프레미스 모니터링 및 로깅은 클라우드에 종속되지 않으며 네트워크 연결이 끊어져도 계속 사용할 수 있습니다.
  • 온프레미스 및 Google Cloud의 모든 GKE 시스템 데이터는 Logging에 중앙 집중화되며 필요에 따라 Google Cloud 지원팀도 액세스할 수 있습니다.

Elastic Stack을 파트너 솔루션으로 사용하는 예시 구현은 Elastic Stack으로 GKE Enterprise 모니터링을 참조하세요.

다음 단계