Kubernetes and Cloud Native Associate (KCNA) #6 Cloud Native Observability (8%): テレメトリ、Prometheus、コスト管理
数十個の Pod が複数のノードに散らばって互いに呼び出し合う分散システムでは、ある 1 つのリクエストが遅くなったとき どこで何が起きたのか が一目では見えません。単一サーバーならログファイル 1 つを覗けば済みましたが、コンテナが死んでは立ち上がり、スケールが上下するクラウドネイティブ環境では、システムの状態を外部から観測可能なシグナルに変えておかないと障害の原因を追えません。この能力を扱うドメインが Cloud Native Observability です。
KCNA でこのドメインの比重は 8% と小さいですが、出題パターンが定型的で点数を確保しやすい区間です。この記事では、テレメトリの 3 本柱、Prometheus を中心としたメトリクス収集、OpenTelemetry と分散トレーシング、信頼性指標 (SLI・SLO・SLA)、そしてコスト管理 (FinOps) を整理します。
オブザーバビリティとモニタリングの違い #
試験では 2 つの用語を区別する問題が出るので、まず整理します。モニタリング (monitoring) はあらかじめ定めた指標としきい値を見張る活動です。「CPU 使用率が 80% を超えたら通知」のように、何を見るかをすでに分かっている 状況を扱います。一方 オブザーバビリティ (observability) は、システムが出すシグナルだけで あらかじめ予想していなかった問いにも答えられる性質 を指します。「なぜ特定のユーザーの決済だけ 3 秒かかるのか」のような、事前にダッシュボードとして作っていなかった問いを事後に掘り下げられて初めて、オブザーバビリティがあると言えます。
整理すると、モニタリングは既知の問題を監視する行為であり、オブザーバビリティは未知の問題までも探求できるようにするシステムの特性です。オブザーバビリティがよく備わったシステムの上でモニタリングが動く、と理解すればよいです。
テレメトリの 3 本柱 #
オブザーバビリティは、システムが出す テレメトリ (telemetry) データの上に成り立ちます。このデータは伝統的に 3 種類 に分かれ、それぞれ答える問いが異なります。試験で最もよく出る分類なので表で整理します。
| 柱 | 形態 | 答える問い | 代表ツール |
|---|---|---|---|
| Metrics (メトリクス) | 時間に沿った数値の時系列 | どれだけ多いか、どれだけ速いか | Prometheus |
| Logs (ログ) | 個別イベントの記録 | そのとき正確に何が起きたか | Fluentd、Loki |
| Traces (トレース) | 1 つのリクエストが経たサービス経路 | このリクエストはどこで遅くなったか | Jaeger、OpenTelemetry |
メトリクス は「秒間リクエスト数」「エラー率」「メモリ使用量」のように一定間隔で測定した数値を時系列に積んだものです。保存コストが軽く集計が速い一方で、個別の事象の詳細は持てません。ログ はアプリケーションが特定の時点に残したテキストイベントで、どのリクエストがどのメッセージで失敗したかといった具体的な文脈を持ちます。その代わり量が多く、保存と検索のコストが大きくなります。トレース は 1 つのリクエストが複数のサービスを経ていく全体の経路をつなぎ合わせたもので、マイクロサービスの間でどの区間がボトルネックかを示してくれます。
3 本柱は競合関係ではなく補完関係です。メトリクスで「エラー率が上がった」という事実を検知し、トレースで「どのサービス区間で詰まったか」を絞り込んだうえで、ログで「正確にどのメッセージで失敗したか」を確認する流れが典型です。
Prometheus: メトリクス収集の標準 #
Prometheus はメトリクス領域の事実上の標準であり、CNCF の 卒業 (Graduated) 段階 のプロジェクトです。Kubernetes の次に CNCF で 2 番目に卒業したプロジェクトだという点もよく出題されます。
pull 型収集 #
Prometheus の最大の特徴は pull 型 の収集モデルです。アプリケーションがメトリクスをどこかへ送り出す (push) のではなく、Prometheus サーバーが定められた周期ごとに対象の /metrics エンドポイントを直接収集しに行きます。この行為を scrape (スクレイプ) と呼びます。どの対象を scrape するかは設定とサービスディスカバリで決め、Kubernetes では Pod と Service を自動的に発見して対象リストを更新します。
push ではなく pull だという点は試験の定番の落とし穴です。(短命なジョブのように生存時間が短くて scrape しにくい場合のために Pushgateway という補助コンポーネントが別途ありますが、基本モデルはあくまで pull です。)
exporter と時系列 DB #
アプリケーションが Prometheus 形式のメトリクスを直接公開しないときは exporter (エクスポーター) を置きます。exporter は、データベース・メッセージキュー・ノードのハードウェア状態といった外部システムの状態を読み取り、Prometheus が scrape できる形式に変換するアダプターです。ノードの CPU・メモリ・ディスクを公開する Node Exporter が代表的です。
収集したメトリクスは Prometheus 内蔵の 時系列データベース (TSDB) に保存されます。各時系列はメトリクス名とラベル (label) の組み合わせで識別され、このラベルが後ろでクエリの次元を作ります。
PromQL とメトリクスタイプ #
保存されたデータは PromQL (Prometheus Query Language) でクエリします。たとえば下記の 1 行は直近 5 分間の秒間 HTTP リクエスト数を計算します。
rate(http_requests_total[5m])メトリクスは通常、次の 3 つのタイプ に分かれます。
| タイプ | 意味 | 例 |
|---|---|---|
| Counter (カウンター) | 増加のみする累積値 | 総リクエスト数、総エラー数 |
| Gauge (ゲージ) | 上下する瞬間値 | 現在のメモリ使用量、キュー長 |
| Histogram (ヒストグラム) | 値の分布をバケットで集計 | リクエスト遅延の分布 (p95 など) |
カウンターは累積なので再起動まで減りません。そのため上の例のように rate() で増加速度を求めて意味のある値に変えます。ゲージは現在の状態をそのまま読めばよいです。ヒストグラムは遅延時間のように分布が重要な値をバケットに分けて入れ、p95・p99 のようなパーセンタイル指標を取り出すときに使います。
Alertmanager と Grafana #
Prometheus は収集とクエリを担い、その周りに 2 つのツールが付きます。Alertmanager は Prometheus が評価したアラートルール (alerting rule) を受け取り、重複排除・グルーピング・ルーティングを経てメール・Slack・PagerDuty といったチャネルへ送ります。アラートルールを判断する主体は Prometheus で、送信とルーティングを担う主体は Alertmanager だという役割の区別が出題ポイントです。
Grafana はメトリクスをグラフとダッシュボードで見せる可視化ツールです。Prometheus をデータソースとして最も多く使いますが、Grafana 自体は Prometheus に従属せず、複数のデータソースを 1 つのダッシュボードにまとめます。つまり Prometheus が保存とクエリ、Grafana が可視化を担う分業だと理解すればよいです。
分散トレーシングと OpenTelemetry #
マイクロサービス環境では、1 つのリクエストがゲートウェイ・認証・注文・決済など複数のサービスを経ます。この全体の経路を追跡するのが 分散トレーシング (distributed tracing) です。
- Trace (トレース): 1 つのリクエストがシステムを通過した 全体の旅程 です。
- Span (スパン): その旅程の中で 1 つのサービスまたは作業単位が占めた 区間 です。開始・終了時刻を持ち、複数のスパンが親子としてつながって 1 つのトレースを成します。
各スパンの所要時間をつないで見ると、どのサービス区間が全体の遅延の原因かがすぐに浮かび上がります。
OpenTelemetry #
OpenTelemetry (OTel) はテレメトリデータを 生成し収集する方式の標準 であり、CNCF プロジェクトです。メトリクス・ログ・トレースの 3 シグナルを 1 つの SDK とプロトコル (OTLP) で扱えるよう統一し、アプリケーションの計測 (instrumentation) を特定のバックエンドに縛られないようにすることが目標です。つまり OpenTelemetry で計測しておけば、トレースデータを Jaeger に送ろうと別のバックエンドに送ろうとコードを変える必要がありません。
ここでは 計測は OpenTelemetry、保存と照会はバックエンド という分業が核心です。Jaeger はそのバックエンドのうち代表的な分散トレーシングシステムで、収集したトレースを保存しリクエスト経路を可視化して見せる CNCF プロジェクトです。
ロギング収集 #
コンテナ環境のロギングは 1 つの原則から出発します。コンテナの中のアプリケーションはログファイルを直接管理せず 標準出力 (stdout) と標準エラー (stderr) に出力し、その出力をプラットフォームが収集します。コンテナはいつでも死んでは立ち上がるので、ログをコンテナの中に置くと消えてしまうためです。
この出力を集めて中央ストレージへ送るツールが ログ収集器 (log collector) です。Fluentd とより軽量な Fluent Bit が CNCF プロジェクトとして広く使われ、各ノードでコンテナログを読み取って加工したうえで保存バックエンドへ転送します。保存と照会の側では、Grafana 陣営の Loki がメトリクスのようにラベルベースでログを扱い軽く運用できる点でよく言及されます。
信頼性指標: SLI、SLO、SLA #
サービスが「十分にうまく動いているか」を数字で扱う語彙が SLI・SLO・SLA です。3 つの略語を正確に区別する問題がほぼ毎回出るので、必ず分けておかなければなりません。
| 略語 | 正式名称 | 意味 | 例 |
|---|---|---|---|
| SLI | Service Level Indicator | 実際に 測定した値 | 過去 30 日の可用性 99.95% |
| SLO | Service Level Objective | 内部的に定めた 目標 | 可用性 99.9% 以上を維持 |
| SLA | Service Level Agreement | 顧客と結んだ 契約 (違反時に補償) | 99.5% 未満なら料金返金 |
順序で覚えると混乱しません。測定値 (SLI) が最も内側にあり、その測定値に対して組織が自ら立てた 目標 (SLO) がその上にあり、顧客と法的に約束した 契約 (SLA) が最も外側にあります。通常は SLA より SLO を厳しく設定し、契約を違反する前に内部目標で先にアラートが鳴るよう設計します。
Error budget #
SLO を 100% ではなく 99.9% に設定すると、残りの 0.1% 分だけ 失敗が許容される余裕 が生まれます。この余裕を error budget (エラーバジェット) と呼びます。エラーバジェットが残っていれば新機能を積極的にデプロイする余裕があるという意味で、使い切ったら安定化に集中すべきだという信号です。安定性とデプロイ速度の間のバランスを数値で扱う仕組みです。
Golden signals #
何を測定すべきか見当がつかないときに基準となる 4 つの核心指標が golden signals (ゴールデンシグナル) です。
| シグナル | 意味 |
|---|---|
| Latency (遅延) | リクエストを処理するのにかかる時間 |
| Traffic (トラフィック) | システムが受けるリクエスト量 |
| Errors (エラー) | 失敗したリクエストの割合 |
| Saturation (飽和) | リソースが限界にどれだけ近いか |
4 つを頭文字の順そのままに束ねて覚えておくと、golden signals を問う問題で 1 つ欠けていたり別の項目が混ざっていたりする選択肢を見抜けます。
コスト管理: FinOps #
クラウドネイティブ環境では、リソースを簡単に増やせる分だけコストも簡単に漏れ出します。そこでオブザーバビリティの一分野として コストの可視性 を扱い、これを運用文化としてまとめたものが FinOps (Financial Operations) です。エンジニア・財務・運用がともにクラウド支出を可視化し、測定したうえで最適化する反復活動を指します。
requests と limits がコストを分ける #
Kubernetes でコストに最も直接的に作用する設定が、コンテナの resource requests と limits です。requests はスケジューラが配置するときに予約する量なので、requests を実際の使用量より大きく設定すると、その分だけノード容量が空いたまま予約されて オーバープロビジョニング (over-provisioning) につながります。ノードは高くついて動いているのに実際の使用率は低い状態になります。逆に低く設定しすぎると、上限超過でコンテナが終了 (OOMKilled) したりスロットリングがかかったりします。実際の使用量に合わせて requests と limits を調整する rightsizing (適正化) がコスト管理の出発点です。
OpenCost と KubeCost #
Kubernetes 自体は「このネームスペースが今月いくら使ったか」を教えてくれません。この隙間を埋めるツールがコスト可視化ソリューションです。OpenCost は Kubernetes コスト測定の オープンソース標準 (CNCF サンドボックスプロジェクト) で、Pod・ネームスペース・ラベル単位でコストを配分して見せます。KubeCost は OpenCost を土台にした製品で、同じコストデータに最適化推奨とダッシュボードを足してくれます。2 つのツールはいずれも リソース使用量をコストに換算して誰がいくら使っているか を明らかにする役割だと理解すればよいです。
試験ポイント整理 #
このドメインでよく出る出題ポイントを集めると次のとおりです。
- 3 本柱の区別。メトリクス (数値の時系列)・ログ (イベントの記録)・トレース (リクエストの分散経路) がそれぞれ何に答えるか。3 つの役割が入り混じった選択肢を見抜く必要があります。
- Prometheus は pull モデル。対象の
/metricsを直接 scrape します。push と書かれた選択肢は罠です。 - SLI・SLO・SLA の区別。測定値 (SLI)・目標 (SLO)・契約 (SLA) の順序と定義を混同しないようにします。
- golden signals の 4 つ。latency・traffic・errors・saturation です。
- 役割マッチング。Prometheus (収集・クエリ)・Grafana (可視化)・Alertmanager (アラートルーティング)・OpenTelemetry (計測標準)・Jaeger (分散トレーシングバックエンド)・Fluentd / Fluent Bit (ログ収集) を 1 行ずつ区別しておく必要があります。
- FinOps と requests / limits。requests を過大に設定するとオーバープロビジョニングでコストが漏れます。
まとめ #
この記事で押さえたこと:
- オブザーバビリティはシステムの性質、モニタリングは既知の指標を見張る活動。2 つは補完関係
- テレメトリの 3 本柱。メトリクス (数値の時系列)・ログ (イベント)・トレース (分散経路)
- Prometheus。CNCF 卒業プロジェクト、pull 型 scrape、exporter、時系列 DB、PromQL、counter / gauge / histogram。周りに Alertmanager (アラート) と Grafana (可視化)
- OpenTelemetry。計測の標準、trace / span の概念。バックエンドとして Jaeger
- ロギング。コンテナは stdout / stderr に出力、Fluentd / Fluent Bit が収集、Loki が保存
- 信頼性指標。SLI (測定)・SLO (目標)・SLA (契約)、error budget、golden signals (latency / traffic / errors / saturation)
- FinOps。requests / limits がコストを分け、OpenCost / KubeCost がコストを可視化
オブザーバビリティの実務実装をより深く見たいなら、K8s 上級 #5 オブザーバビリティ で Prometheus・Grafana・Loki・OpenTelemetry を実際につないで運用する流れを扱います。
次へ: Cloud Native Application Delivery #
観測まで備えたら、最後のドメインはアプリケーションをクラスターへ届ける流れです。
#7 Cloud Native Application Delivery (8%): GitOps、CI/CD では、GitOps の原則 (Git を単一のソースとする宣言型デプロイ)、ArgoCD と Flux、CI/CD パイプラインの区別、そして試験によく出るデプロイ概念を整理します。