マイクロサービスという用語は、人によってとらえる意味が変わります。システム アーキテクチャについて語った場合に、マイクロサービスをホワイトボード上に描かれる「箱」と捉える人もいます。一方で、より公式的な定義、つまり、システム内の他のマイクロサービスとは無関係に開発、デプロイ、運用できる外向きの API により確定される機能を持つ、ネットワーク アドレスが割り振り可能なエンドポイントと解釈する人もいます。App Engine サービスまたは Cloud Service Mesh サービスなどの開発プラットフォームによりもたらされるマイクロサービスのコンセプトに沿った理解をする人もまだいます。
Google では、マイクロサービスに関する定義を強制することはありません。Google は、お客様とお客様のアーキテクチャをサポートするサービス指向のモニタリング ツールを提供することにより、お客様がデジタル トランスフォーメーションでシステムのモニタリングを大規模に行えるよう支援したいと考えています。コードを 1 行も変更せずに、お客様がシステムをモニタリングするためのベスト プラクティスを採用できるよう Google がサポートします。
マイクロサービスをモニタリングするために、Cloud Monitoring は次の処理を行います。
可能であればマイクロサービスを自動検出する
Google Kubernetes Engine と Cloud Run ベースのマイクロサービスを定義するガイドを提供する
[[["わかりやすい","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-09-05 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)."]]