メニュー

デジタル庁GCASガイド

3. 監視機能のマネージドサービス化

2026/04/22 公開

クラウド環境では監視サービスがマネージドサービスとして標準で提供されており、監視サーバーを構築することなく監視基盤を整備できる。

なお、クラウド環境における監視の本来の目的は、CPUやメモリ等のシステムリソースの状態を監視することではなく、利用者が実際にサービスを利用する際のレスポンス時間やエラー率といったサービス品質を監視することである（詳細は、運用モダン化実践ガイドを参照）。

一方、R1（Replatform）の段階では、アプリケーションや運用方式の大幅な改修を伴わずにサービス品質の計測基盤を整備することは難しい場合も多い。そのため本章では、R1として最低限実施する内容として、オンプレミス環境で実施していたリソース監視等をクラウド環境に適した形で省力化し継続しつつ、将来的なサービス監視への移行を念頭に置いた監視設計を推奨する。

3.1 オンプレミス監視方式のクラウド移行

以下に、オンプレミス環境で一般的に実施されている監視方式ごとの移行分類を示す。

表3-1 監視方式別クラウド移行方針

監視方式検討ポイントクラウド移行時の対応説明
死活監視（Ping/ICMP）設計変更が必要クラウド環境ではIPアドレスは動的に変わる場合が多いため、IPアドレスの監視を前提としたPing/ICMP監視は廃止し、各コンポーネント（DBへのSQL投入、WebサーバーへのHTTPリクエスト等）単位のヘルスチェック監視や、外形監視サービスによるサービス正常確認に移行することを推奨する。
リソースメトリクスの収集（CPU/メモリ/ディスク等）追加作業ありCPU使用率等はクラウドサービスの標準メトリクスとして自動収集される。OS内部のメトリクス（メモリ使用率、ディスク使用率等）は監視エージェントの導入が必要(3.3参照)。

なお、収集したメトリクスに対する閾値アラートの設定については、「リソース閾値監視」の行を参照すること。
リソース閾値監視廃止検討リソースメトリクスの収集自体は継続しつつ、閾値超過時のアラートについては以下のとおり対応する。オートスケーリング等の自動拡張を導入している場合はアラートは不要のため廃止する。自動拡張を導入していない場合は、クラウド監視サービスの閾値アラーム機能で引き続き実施する。

なお、本来の目指すべき方向はリソース閾値ではなくサービス品質（レスポンス時間・エラー率等）に基づく監視への移行である。
プロセス監視追加作業あり監視エージェントのカスタムメトリクスまたはカスタムスクリプトで実現する。プロセス自動再起動等の機能は、別途運用系サービスやサーバーレス環境等を組み合わせた実装が必要となる場合がある。
ログ監視（特定文字列検出等）設定のみで対応可能クラウドのログ管理サービスのメトリクスフィルタ機能で、ログ内の特定文字列（ERROR等）を検出しアラームと連携し通知することが可能。

また、データベースやロードバランサー等のマネージドサービスは、状態異常等を直接イベントとして通知する機能を持つ場合も多い。ログ監視による通知だけでなく、イベントによる通知も組み合わせて検討すること。
サービス監視（URL監視/外形監視）設定のみで対応可能クラウドの外形監視サービスにより、定期的なHTTPリクエストベースの外形監視が標準機能として提供されている。

さらに、ロードバランサのメトリクスや、アプリケーション全体で問題が発生している場所を特定するための効果的なツールであるAPM（Application Performance Monitoring）を活用することで、レスポンス時間やエラー率の計測・監視も実現可能であり、単なる死活確認から利用者視点のサービス品質監視への発展を推奨する。
キャパシティのトレンド監視廃止検討クラウドではリソースの拡張・縮小が柔軟に可能なため、中長期的なキャパシティのトレンド監視の重要性は大幅に低下する。コスト最適化の観点での利用量モニタリングへの置き換えを推奨する。
ジョブ監視（バッチ実行結果の監視）設計変更が必要クラウドのワークフローサービスやイベント連携サービスを利用した方式への設計変更が必要。バッチ実行結果をクラウドの監視サービスに連携する仕組みの設計が必要となる。
ネットワーク機器監視（SNMP）廃止検討クラウド環境では物理的なネットワーク機器をユーザーが管理する必要がないため、クラウド側のSNMP監視は廃止する。

一方、オンプレミス側に残存するネットワーク機器については引き続きSNMP監視が必要となるため、既存監視ツールの縮小運用による継続、またはクラウド側のネットワーク管理サービスとの併用を検討する。
仮想化基盤監視（VMware等）廃止検討仮想化基盤はCSPの責任範囲であり、利用システムによる監視は不要。
ハードウェア監視（温度/電源/ファン等）廃止検討ハードウェアはCSPの責任範囲であり、利用システムによる監視は不要。CSP側の障害はCSPの障害通知サービスで把握する。

3.2 クラウド環境で新たに必要な監視

クラウド環境への移行にあたっては、オンプレミス環境にはなかった以下の監視を新たに検討する必要がある。

表3-2 クラウド環境で新たに必要な監視

監視方式説明
CSP障害の把握CSPの障害通知サービスとイベント連携サービスを組み合わせ、CSP障害を自動通知する仕組みを導入する。
クラウドサービス固有メトリクスの監視データベースサービスのコネクション数・キャッシュヒット率、ロードバランサのリクエスト数・レイテンシ等、クラウドサービス固有のメトリクスを活用した監視を設計する。
コスト監視従量課金特性を踏まえ、予算超過や異常なコスト増加を検知するコスト監視を導入する。

詳細は、「継続的運用経費最適化（FinOps）ガイド」および「コスト最適化アプローチガイド」を参照。
セキュリティ関連の監視クラウド環境特有の設定不備やセキュリティリスクに対する継続的な監視を導入する。詳細は6章を参照。
サービス品質の監視（レスポンス時間・エラー率）ロードバランサのメトリクスやAPMツールを活用することで、レスポンス時間やエラー率の計測・監視を実現できる。まずロードバランサのメトリクスから着手し、段階的にAPMツールの活用へと発展させることを推奨する。

3.3 監視対象データの収集方法

CSPサービスの利用状況データ（CPU使用率、データベースのコネクション数等）は自動的に収集されるため、追加の設計・構築は不要である。一方、OS上のディスク使用率やアプリケーション正常性等、利用システムの責任範囲における監視データは、監視エージェントまたはSDKの導入やスクリプト開発が必要となる。この場合も、スクリプト実行専用のサーバーを構築する必要はなく、クラウドが提供するサーバーレス実行環境を活用できる。

自動収集されるデータを最大限活用し、個別対応が必要なデータ収集の範囲を可能な限り限定することで、設計・構築コストを抑えることができる。

クラウド環境における監視対象の構成図。システム利用者からネットワーク・セキュリティサービスを経由してWebアプリケーションサーバーおよびデータベースサーバーへ接続し、利用システムによる監視とCSP責任範囲の障害確認・通知機能を含む監視サービスがシステム運用者へ確認/通知を行う構成。白枠が監視必要/収集必要、水色が監視必要/自動収集、紺色がCSP責任範囲（監視不要）を示す。

図3-1 クラウド環境における監視対象データ収集

3.4 参考資料

3.4.1 リファレンスアーキテクチャ

具体的なサービス選定や構成検討の際は、各CSPのリファレンスアーキテクチャを参照されたい。
どのように構成するかの実現例を具体的に示しており、アーキテクチャ検討の参考として活用できる。

（※1）Google CloudおよびOCIのコスト管理については、リファレンスアーキテクチャの掲載がないため、各CSPの公式ドキュメントを参照すること。

3.4.2 コスト最適化

コスト最適化の観点で、関連文書も参考として提示する。

← マネージドサービス活用実践ガイド に戻る