microservicesとKubernetesのモニタリング:単純な稼働チェックを超えて

microservicesモニタリングの危機#

従来のアップタイムモニタリングはこう問いかけます。「あなたのウェブサイトは応答していますか?」

現代のmicroservicesアーキテクチャはこう問いかけます。「47個すべてのmicroservicesが応答しており、しかも互いに正しく応答していますか?」

microservicesプラットフォームは、相互接続された数十のサービスで構成されています。

API Gateway → Auth Service → User Service → Database
             → Payment Service → Stripe
             → Notification Service → SendGrid
             → Reporting Service → Data Warehouse
             → Search Service → Elasticsearch
             → Cache → Redis

これらのサービスのいずれかが失敗した場合:

• Auth Serviceがダウン = 誰もログインできない
• Payment Serviceがダウン = 顧客が支払いできない
• Search Serviceがダウン = 顧客が商品を見つけられない
• Redisキャッシュがダウン = システムが遅くなる(連鎖的障害)

従来のアップタイムモニタリングでは、この複雑さを完全に見逃します。

---

なぜmicroservicesモニタリングは異なるのか#

1. 分散障害

モノリシックなシステムでは、障害は二者択一です。稼働中かダウンか。

microservicesでは、障害は部分的かつ連鎖的に発生します。

シナリオ1: Search Serviceの低速化
  - 検索リクエストに10秒かかる(通常は200ms)
  - フロントエンドのリクエストが検索結果を待ってタイムアウト
  - APIリクエストのレイテンシが10倍に急増
  - ユーザーには「ページの読み込みが遅い」と表示される
  - 単純なアップタイムチェックでは検出されない(APIは技術的には応答している)

シナリオ2: Cache Serviceの劣化
  - Redisキャッシュのヒット率が90%から20%に低下
  - データベースへのクエリが4倍に増加
  - データベースのCPU使用率が100%に急上昇
  - すべてのリクエストが遅くなる(無関係なものまで)
  - システム全体に連鎖的障害が発生

シナリオ3: サービス間通信の障害
  - Auth Serviceは稼働中
  - User Serviceは稼働中
  - しかしネットワークの問題でAuth → User通信が阻害される
  - ユーザーがログインできない
  - 両サービスとも監視上は「稼働中」と表示される

2. Kubernetes固有の障害

Kubernetesは複雑さを増します。

Pod再起動サイクル:
  - メモリリークによりPodがクラッシュ
  - KubernetesがPodを自動的に再起動
  - Podは再起動中で、トラフィックに応答しない
  - 「稼働中」に見える(Podは存在する)が、リクエストを処理していない

ノード障害:
  - Kubernetesノードがダウン
  - Schedulerが他のノードへPodを移動
  - Podは正常だが、移行中は一時的に利用不可
  - 移行中に短時間のリクエスト失敗が発生

デプロイの問題:
  - 新しいデプロイの起動時にバグがある
  - Podが起動に失敗する
  - 既存のPodは引き続きリクエストを処理
  - システムは劣化しているが、完全にダウンしているわけではない

3. Service Meshの複雑さ

Service Mesh(Istio、Linkerd)を使用すると:

Service Meshはさらにレイヤーを追加します:
  - Service → Sidecar → Network → Sidecar → Service
  - Sidecarが障害を注入できる(レート制限、タイムアウト)
  - サーキットブレーカーがトリップする可能性がある(リクエストを阻止)
  - 負荷分散が不均衡になる可能性がある(一部のインスタンスがより多くのトラフィックを受信)

モニタリングには以下を含める必要があります:
  - Sidecarの健全性
  - サーキットブレーカーのステータス
  - 負荷分散の分布
  - Service Meshのコントロールプレーンの健全性

---

microservicesモニタリングのアーキテクチャ#

レベル1: サービスの可用性#

各サービスを個別に監視します。

Auth Service:
  - サービスが実行中か?(pod数 > 0)
  - ヘルスチェックに応答しているか?(GET /health が200を返す)
  - レスポンスタイムは?(P95 < 100ms)
  - エラー率は?(< 0.1%)

Payment Service:
  - サービスが実行中か?
  - 応答しているか?(GET /health)
  - Stripeと通信できるか?(Stripeが応答している)
  - レイテンシは?(P95 < 500ms)

レベル2: サービス間通信#

サービス間の通信を監視します。

Auth Service → User Service:
  - Auth ServiceはUser Serviceに到達できるか?(ネットワーク接続)
  - レイテンシは?(P95 < 50ms)
  - エラー率は?(< 0.01%)

User Service → Database:
  - User Serviceはデータベースに到達できるか?(コネクションプールの健全性)
  - コネクションプールが枯渇していないか?(接続待ち)
  - クエリのレイテンシは?(P95 < 100ms)

レベル3: 分散トランザクショントレース#

完全なリクエストフローを監視します。

ユーザーログインフロー:
  1. API Gatewayがログインリクエストを受信
  2. Auth Serviceにルーティング(レイテンシ: 10ms)
  3. Auth ServiceがUser Serviceに問い合わせ(レイテンシ: 15ms)
  4. User Serviceがデータベースに問い合わせ(レイテンシ: 20ms)
  5. Auth ServiceがJWTトークンに署名(レイテンシ: 5ms)
  6. API Gatewayがレスポンスを返す(レイテンシ: 2ms)

合計レイテンシ: 52ms(許容範囲)

User Serviceのクエリが20msではなく500msかかる場合:
  - 合計レイテンシが532msに跳ね上がる
  - ユーザーはログインが遅いと感じる
  - アプリケーションのパフォーマンスが低下
  - モニタリングが根本原因を捕捉(User Serviceのクエリが遅い)

レベル4: Kubernetes固有のモニタリング#

Kubernetesインフラを監視します。

Podの健全性:
  - Pod再起動回数(24時間で5回を超えたらアラート)
  - Podのメモリ使用量(制限に近づいたらアラート)
  - PodのCPU使用率(80%以上が継続したらアラート)

ノードの健全性:
  - ノードのステータス(Ready、NotReady、Unknown)
  - ノードのディスク逼迫(85%以上満杯ならアラート)
  - ノードのメモリ逼迫(空きが10%未満ならアラート)

デプロイの健全性:
  - 望ましいレプリカ数 vs 準備完了レプリカ数(不一致ならアラート)
  - Pod作成のレイテンシ(30秒を超えたらアラート)
  - イメージpullエラー(Podが起動できないならアラート)

---

実際のmicroservicesモニタリング失敗例#

組織: 30以上のmicroservicesと50のKubernetes Podを持つFinTechプラットフォーム

アーキテクチャ:

• API Gateway(5レプリカ)
• Auth Service(3レプリカ)
• Payment Service(5レプリカ)
• Notification Service(3レプリカ)
• Data Pipeline(2レプリカ)
• Cache(Redisクラスター)
• Database(PostgreSQL)

インシデント: 決済処理の低速化

タイムライン:

• 14:00: Notification ServiceのPodが再起動(メモリリーク)
• 14:05: Notification ServiceのPod作成が遅い(Kubernetes Schedulerが過負荷)
• 14:10: Payment ServiceからNotification Serviceへのリクエストがタイムアウト(サービスが応答していない)
• 14:10: Payment Serviceがクライアント側のリトライ(指数バックオフ)を実行
• 14:15: リトライ嵐がAPI Gatewayに連鎖
• 14:15: API Gatewayが過負荷になり、リクエストキューが溜まる
• 14:20: すべてのユーザーリクエストがタイムアウト
• 14:20: インシデント宣言、オンコールエンジニアにページング

モニタリングが捕捉できたもの:

• 14:01: アラート「Notification ServiceのPod再起動回数が閾値を超過」
• 14:06: アラート「Notification ServiceのPod作成レイテンシ > 30秒」
• 14:07: アラート「Notification Serviceのヘルスチェック失敗」
• 14:08: アラート「Payment Service → Notification Serviceのレイテンシ急増」
• 14:09: アラート「Payment Serviceのエラー率急増」

早期のアラートがあれば連鎖を防げた可能性があります。Notification Serviceを手動で再起動するか、Payment Serviceのリトライ戦略を調整するなどです。

---

microservicesモニタリングの実装#

オプション1: Prometheus + Grafanaで自前構築#

Prometheus:
  - 各サービスの/metricsエンドポイントをスクレイプ
  - メトリクスを時系列データベースに保存
  - アラートルールを実行(メトリクスが閾値を超えたらアラート)

Grafana:
  - Prometheusからのメトリクスを可視化
  - サービスごとのダッシュボード
  - サービス単位および横断的なダッシュボード

実装: オープンソース、無料、インフラ知識が必要
コスト: 低(インフラのみ)、高(エンジニアリング工数)
適している対象: DevOpsの専門知識を持つチーム

オプション2: マネージドサービス(Datadog、New Relic)#

Datadog/New Relicエージェント:
  - 各PodのSidecarとして動作
  - メトリクス、ログ、トレースを収集
  - マネージドサービスへ送信

ダッシュボード:
  - Kubernetes向けの構築済みダッシュボード
  - サービス間通信のためのAPM
  - 分散トレースが組み込み

実装: ベンダーツール、設定が複雑、強力
コスト: 高(ホスト/GB単位の課金)、低(エンジニアリング工数)
適している対象: 予算があり、運用の専門知識が少ないチーム

オプション3: モニタリング機能内蔵のService Mesh#

Istio/Linkerd:
  - Sidecarプロキシがすべてのサービス間通信を傍受
  - レイテンシ、エラー、トラフィックを自動的に追跡
  - コード変更なしで可観測性を提供

モニタリング:
  - Service Meshダッシュボードでサービス依存関係を表示
  - サーキットブレーカーのステータス
  - トラフィックの分散
  - ルートごとのリクエストレイテンシ

実装: インフラレベルの変更、強力だが複雑
コスト: インフラのオーバーヘッド(Sidecarが消費するCPU/メモリ)
適している対象: 多数のサービスを持つ大規模組織

---

microservicesモニタリングのチェックリスト#

サービスごと

☐ ヘルスチェックエンドポイントが実装されている(健全時に/healthが200を返す)
☐ メトリクスエンドポイントが公開されている(Prometheusスクレイプ用の/metrics)
☐ サービスの可用性が監視されている(pod実行中、ヘルスチェック合格)
☐ サービスのレスポンスタイムが監視されている(P95レイテンシを追跡)
☐ サービスのエラー率が監視されている(4xx、5xxエラーを追跡)
☐ サービスのログが集中管理されている(ELK、Splunkなど)

サービス間通信ごと

☐ サービス間のレイテンシが監視されている(サービスA → サービスB)
☐ サービス間通信ごとのエラー率が追跡されている
☐ サーキットブレーカーのステータスが監視されている(該当する場合)
☐ タイムアウト処理が検証されている(適切なリトライロジック)

Kubernetesクラスターごと#

☐ Podの健全性が監視されている(再起動回数、メモリ、CPU)
☐ ノードの健全性が監視されている(ステータス、ディスク、メモリ)
☐ デプロイの健全性が監視されている(望ましいレプリカ vs 準備完了レプリカ)
☐ 永続ボリュームの健全性が監視されている(空き容量、I/Oエラー)
☐ ネームスペースのリソース使用量が監視されている(CPU、メモリの上限)

分散トレース

☐ リクエストトレースが収集されている(リクエストIDがサービス全体に伝播)
☐ トレースの可視化が利用可能(リクエストフローを確認できる)
☐ トレースのレイテンシ内訳が確認可能(どのサービスが遅いか?)
☐ トレースのエラー検出(どのサービスが失敗したか?)

---

microservicesモニタリングのベストプラクティス#

1. 分散トレース用の相関ID

すべてのリクエストには、すべてのサービスに伝播される一意のIDが必要です。

ユーザーリクエスト:
  Header: X-Request-ID: 12345

Service A:
  ログ: 「Request 12345: Started」
  Service Bを呼び出す際にヘッダーを付与: X-Request-ID: 12345

Service B:
  ログ: 「Request 12345: Received from Service A」
  Service Cを呼び出す際にヘッダーを付与: X-Request-ID: 12345

Service C:
  ログ: 「Request 12345: Processing complete」

後でリクエスト12345のすべてのログを取得して、フロー全体を確認

2. 構造化ロギング

「Error occurred」とは記録しない コンテキスト付きのJSONで記録する

{
  "timestamp": "2026-02-20T14:32:15Z",
  "request_id": "12345",
  "service": "payment-service",
  "level": "error",
  "message": "Payment authorization failed",
  "error_code": "STRIPE_AUTH_FAILED",
  "attempt": 1,
  "latency_ms": 2500,
  "status_code": 503
}

3. サーキットブレーカーパターン

連鎖的障害を防ぐためにサーキットブレーカーを実装します。

通常時:
  Payment Service → Stripe APIを呼び出し
  Stripeが200(成功)を返す
  リクエストが続行

障害モード(サーキットOpen):
  Stripe APIが503(サービスダウン)を返す
  5回失敗後、サーキットブレーカーがオープン
  以降のリクエストは即座に失敗(Stripe呼び出しを試みない)
  Stripe API呼び出しのレイテンシが2秒から50msに低下
  連鎖的障害ではなく、優雅にシステムが劣化

復旧:
  サーキットブレーカーがHalf-Open(1リクエストでテスト)
  成功すれば、Stripeへのリクエストを徐々に増やす
  失敗すれば、サーキットはOpenに戻る

---

Kubernetes固有のモニタリングの落とし穴#

落とし穴1: Pod再起動時にPodのIPが変わる#

Podが再起動すると、そのIPは変わります。DNSレコードを更新する必要があります。

モニタリングではこれを考慮する必要があります。

• Pod IPではなく、サービス名で監視する
• Kubernetes DNS(service-name.namespace.svc.cluster.local)を使用する
• Kubernetesサービスのエンドポイントを監視する(Podが登録されているか?)

落とし穴2: initコンテナの遅延#

Kubernetesのinitコンテナはメインコンテナの前に実行されます。initコンテナが遅い場合:

Podステータス: 「Running」(技術的には正しい)
しかし実際には: initコンテナが実行中で、サービスはまだ準備できていない
ヘルスチェックが失敗する可能性がある(サービスがまだ応答していない)

解決策:

• 最初の60秒間はヘルスチェック失敗でアラートを出さない
• startup probeを使用する(liveness probeとは異なる)
• initコンテナの完了レイテンシを監視する

落とし穴3: リソース上限がパフォーマンスに影響する#

PodのCPU上限が低すぎる場合:

Podステータス: Running
しかし実際には: CPUがスロットリングされ、レイテンシが急増
モニタリングはレイテンシの急増を示すが、CPU使用率は100%スロットリングを示す

解決策: CPU使用率とCPUスロットリングの両方を監視する
CPUスロットリングが時間の20%を超える場合にアラート

---

microservicesモニタリングのためのNova Uptime#

Nova Uptimeの無料プランでmicroservicesを監視できます。

1. サービスのヘルスチェック: 各サービスのヘルスエンドポイントを監視
2. APIモニタリング: レスポンスタイムとエラー率を追跡
3. Webhookモニタリング: サービス間通信を検証
4. メールモニタリング: 通知サービスがメールを配信していることを検証
5. Public APIモニタリング: サービスがPublic APIを公開している場合

包括的なmicroservicesモニタリングには、専門ツール(Prometheus、Datadog、New Relic)を使用してください。ただし、Nova Uptimeは外部サービスの健全性や顧客向けAPIを監視することで、それらを補完できます。

---

まとめ: 単純なアップタイムを超えたmicroservicesモニタリング#

microservicesは、従来のシステムよりも高度なモニタリングを必要とします。

アクションプラン:

1. 各microserviceにヘルスチェックエンドポイントを実装する
2. メトリクスを公開する(Prometheus用の/metricsエンドポイント)
3. すべてのリクエストフローに相関IDを追加する
4. 連鎖的障害を防ぐためにサーキットブレーカーを実装する
5. リクエストコンテキスト付きの構造化ロギングを使用する
6. サービス間通信を監視する(レイテンシ、エラー)
7. Kubernetesインフラを監視する(Pod、ノード、デプロイ)
8. 分散トレースを設定する(リクエストフロー全体を確認)
9. サービスごとのダッシュボードを作成する(各サービスの可視性)
10. 劣化に対してアラートを出す(完全な障害だけではなく)

まずはNova Uptimeで顧客向けAPIを監視することから始めましょう。ヘルスチェックモニタリングを追加してください。より深いインフラモニタリングのために、Prometheus/Grafanaやマネージドサービスで補完してください。

あなたのmicroservicesは複雑です。あなたのモニタリングもその複雑さに見合うべきです。