이 문서에서는 마이크로서비스를 소개하고 Cloud Monitoring에서 지원하는 마이크로서비스 유형을 설명합니다.
마이크로서비스라는 용어는 사용자별로 의미하는 것이 다릅니다. 경우에 따라 마이크로서비스는 시스템 아키텍처에 대해 이야기할 때 화이트보드에 그려진 '상자'에 해당합니다. 그 외는 시스템의 다른 마이크로서비스에서 독립적으로 개발, 배포, 작동할 수 있는 외부 공개 API로 결정되는 기능이 있는 네트워크 주소 지정 가능 엔드포인트를 설명하는 공식적인 정의에 해당합니다. 하지만 여전히 다른 사용자들은 App Engine 서비스 또는 Cloud Service Mesh 서비스와 같이 개발 플랫폼에서 제공하는 마이크로서비스 개념을 이해의 배경으로 합니다.
Google의 목표는 마이크로서비스 정의를 강요하지 않는 것입니다. Google에서는 사용자 아키텍처를 지원하기 위해 서비스 지향 모니터링 도구를 제공하여 디지털 혁신이 진행되는 동안 규모에 맞춰 시스템을 모니터링할 수 있도록 도움을 제공하고자 합니다. 코드를 단 한 줄도 변경하지 않고 모니터링 시스템에 대한 권장사항을 적용할 수 있도록 사용자와 작업할 것입니다.
Cloud Monitoring에서는 마이크로서비스를 모니터링하는 데 도움이 되도록 다음을 수행합니다.
가능한 경우 마이크로서비스 자동 감지
Google Kubernetes Engine 및 Cloud Run 기반 마이크로서비스를 정의하는 안내 환경을 제공합니다.
유연성을 극대화할 수 있도록 완전 커스텀 솔루션 제공
자동 검색된 마이크로서비스
일부 최신 개발 프레임워크에서는 전문가의 의견이 담긴 마이크로서비스 개념을 제공합니다. 이러한 프레임워크를 사용하는 아키텍처에서 Cloud Monitoring은 서비스가 배포, 업데이트 또는 삭제될 때 이를 자동으로 감지합니다. Monitoring은 프로젝트에서 생성한 메타데이터 스트림을 지속적으로 분석하여 이러한 감지를 수행합니다.
Cloud Monitoring은 다음 개발 프레임워크를 사용하여 빌드된 마이크로서비스를 자동으로 감지할 수 있습니다.
App Engine: App Engine에는 App Engine 서비스(이전에는 모듈)라고 하는 강력한 마이크로서비스 개념이 있습니다. 각 서비스는 자체 app.yaml 구성 파일로 구분됩니다.
Cloud Service Mesh: Cloud Monitoring은 단일 GKE 클러스터 위에 구축된 서비스 메시를 지원합니다. 이 구성에서 Cloud Service Mesh 서비스는 GKE 서비스에 직접 대응합니다. 모든 Cloud Service Mesh 서비스는 사용자 관리 서비스와 시스템 관리 서비스 모두를 자동으로 감지합니다.
자동 검색된 마이크로서비스의 대시보드
자동으로 검색된 모든 마이크로서비스의 서비스 대시보드가 자동으로 생성됩니다. 대시보드에는 서비스의 메타데이터 세부정보, 알림 타임라인, 서비스 수준 목표(SLO) 상태, 서비스와 관련된 로그가 포함됩니다. 각 구성요소에 대한 자세한 내용은 마이크로서비스 대시보드 사용에 설명되어 있습니다.
GKE, Cloud Run, 커스텀 서비스
Cloud Monitoring은 다음 유형의 잠재적 또는 후보 서비스를 식별할 수 있습니다.
GKE 네임스페이스
GKE 서비스
GKE 워크로드
Cloud Run 서비스
하지만 이러한 후보가 많이 있을 수 있으며 모든 후보에 SLO를 만들 필요는 없습니다. Monitoring은 후보 서비스 목록을 만들며 목록에서 선택하여 모니터링 서비스로 취급할 서비스를 식별합니다. 그러면 Monitoring에서 자동으로 서비스 인프라를 만듭니다.
기존 서비스 유형에 SLO를 만들려는 애플리케이션을 수용할 수 없는 경우 커스텀 서비스를 정의할 수 있습니다.
후보 서비스 식별 및 커스텀 서비스 만들기에 대한 자세한 내용은 마이크로서비스 정의를 참조하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-12(UTC)"],[],[],null,["# Microservices\n\nThis document introduces microservices and describes the types of microservices\nsupported by Cloud Monitoring.\n\nThe term *microservice* means different things to different people. For some,\nthe microservice corresponds with the \"boxes\" drawn on the whiteboard when\ntalking about system architecture. Others refer to a more formal\n[definition](https://en.wikipedia.org/wiki/Microservices)\nthat describes a network-addressable endpoint with functionality determined\nby its external-facing API that can be developed, deployed, and operated\nindependently from other microservices in the system. Still others base their\nunderstanding on the microservice concept provided by their development\nplatform, like the\n[App Engine services](/appengine/docs/standard/python/an-overview-of-app-engine#services) or the [Cloud Service Mesh service](/anthos/service-mesh).\n\nOur goal is not to force a definition of *microservice* upon you. Instead, we\nwant to help you monitor your systems at scale during your digital\ntransformation by providing service-oriented monitoring tools to support you\nand your architecture. We want to work with you to adopt best practices for\nmonitoring systems without changing a single line of code.\n\nTo help you monitor your microservices, Cloud Monitoring\ndoes the following:\n\n- Auto-detects microservices when possible\n- Provides a guided experience for defining Google Kubernetes Engine- and Cloud Run-based microservices\n- Offers a fully custom solution for maximum flexibility\n\nAuto-discovered microservices\n-----------------------------\n\nSome modern development frameworks offer opinionated concepts of\na microservice. In architectures that use such frameworks,\nCloud Monitoring automatically detects when services are deployed,\nupdated, or deleted. Monitoring accomplishes this detection\nthrough constant analysis of the metadata stream produced by a project.\n\nCloud Monitoring can automatically detect microservices built using\nthe following development frameworks:\n\n- [App Engine](/appengine): App Engine has a strong notion of microservice,\n called an App Engine service (and formerly a *module* ). Each service\n is distinguished by its own [`app.yaml`](/appengine/docs/standard/nodejs/config/appref) configuration file.\n\n- [Cloud Service Mesh](/anthos/service-mesh): Cloud Monitoring supports service meshes\n built atop a single GKE cluster. In this configuration,\n a Cloud Service Mesh service corresponds directly to a\n [GKE service](/kubernetes-engine/docs/concepts/service). All Cloud Service Mesh services,\n both user-managed and system-managed, are automatically detected.\n\n### Dashboards for auto-discovered microservices\n\nA service dashboard is automatically created for all auto-discovered\nmicroservices. The dashboard contains the metadata details of the service,\nthe alert timeline, the status of your service-level objectives (SLOs), and\nlogs related to the service. Each of these components is described in\nmore detail in [Using microservice dashboards](/stackdriver/docs/solutions/slo-monitoring/ui/svc-dashboard).\n\n| **Note:** The alert timeline and SLO list will be empty since no SLOs or SLO alerts have been defined. To get the most out of your service dashboard, create SLOs and set alerts on them as described in [Creating an SLO](/stackdriver/docs/solutions/slo-monitoring/ui/create-slo).\n\nGKE, Cloud Run and custom services\n----------------------------------\n\n| **Note:** In Cloud Monitoring, a *service* is a construct that you can associate with SLOs and alerting policies. Several of the resources for which you might create Monitoring services are also referred to as *services* , but with different meanings, like [*GKE\n| services*](/kubernetes-engine/docs/concepts/service) or [*Cloud Run\n| services*](/run/docs/resource-model#services).\n\nCloud Monitoring can identify *potential* or *candidate* services\nfor the following types:\n\n- GKE namespaces\n- GKE services\n- GKE workloads\n- Cloud Run services\n\nHowever, there may be many such candidates, and you don't necessarily\nwant to create SLOs on all of them. Monitoring creates a\nlist of candidate services, and you identify the services you want\nto treat as Monitoring services by selecting them from the\nlist. Monitoring then creates the\nservice infrastructure for you.\n\nWhen no existing service type accommodates an application for which you\nwant to create SLOs, you can define a custom service.\n\nFor more information about identifying candidate services and creating custom\nservices, see [Defining a microservice](/stackdriver/docs/solutions/slo-monitoring/ui/define-svc)."]]
