Ameba Platform のインターンで、Istio / Karpenter/AWS LBC の監視整備に取り組んだ話
はじめまして。
慶應義塾大学商学部3年の利根川颯汰と申します。
私は、3月4日~3月30日の1ヶ月間、サイバーエージェントの「CA Tech JOB」というインターン制度でメディア統括本部 サービスリライアビリティグループ（SRG）にお世話になりました。
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
今回のインターンでは、Ameba のプラットフォームチームにて、Istio・Karpenter・AWS Load Balancer Controller などの主要コンポーネントに対するDatadog上での監視整備に取り組みました。
この記事では、監視整備の背景、設計方針、実装の進め方、そして実際に進める中で得られた知見を紹介します。
なぜ監視整備が必要だったのか現状の課題監視整備によって何が変わるか監視整備のロードマップSTEP 0: まずはコンポーネントの優先度を決める共通ポリシー優先度付けの結果STEP 1: ワークロード死活監視を整備する監視の考え方DaemonSet は別の見方が必要だったモニター数を増やしすぎない工夫Datadog クエリの例STEP 1 で得られたことSTEP 2: コンポーネント個別監視を整備するKarpenter の監視主要メトリクス選定理由運用上の補足Istio の監視主要メトリクス選定理由実環境での調査結果最終的に採用した監視観点運用上の補足AWS Load Balancer Controller の監視主要メトリクス選定理由今回は見送ったメトリクス今回の取り組みで意識したこと1. 最初に共通監視を整える2. ノイズを拾わない3. 監視は単体では完結しない今後の取り組みまとめ終わりに
なぜ監視整備が必要だったのか
Kubernetes 上で動作するプラットフォームは、多数のコンポーネントが連携して成り立っています。
しかし、それらのコンポーネントが正常に動いているかを継続的に把握する仕組みがなければ、障害が起きてもユーザーからの報告や偶然の気付きに頼ることになります。
現状の課題
当時、プラットフォーム側には ArgoCD や FluxCD などのDatadogインテグレーションが自動生成するダッシュボードは存在していました。
ただし、実運用で使うには情報の整理が不十分で、障害検知や一次切り分けに活用されているとは言いづらい状態でした。
また、以下のような障害が起きた場合にも、すぐに気付けないリスクがありました。
- istiod が停止した場合: Pod 再起動時に sidecar が設定を取得できなくなり、結果としてサービス間通信が徐々に不安定になる
- Karpenter が停止した場合: 新規ノードが追加されなくなり、 Pending Pod が増え続け、サービスがスケールできなくなる
- AWS Load Balancer Controller が停止した場合: Load Balancer のターゲット更新や反映処理が止まり、Kubernetes 側の変更が外部疎通に反映されなくなる
監視整備によって何が変わるか
| 観点 | 整備前 | 整備後 |
|---|---|---|
| 障害検知 | ユーザー報告または偶然気付くまで分からない | アラートで障害を検知できる |
| 障害の予兆検知 | なし | 劣化や異常傾向を事前に検知できる |
| 障害対応速度 | エラー調査から始まる | Runbook を前提に、すぐ対処に入れる |
| 可視性 | 低い | 各コンポーネントの状態を継続的に把握できる |
監視整備の目的は、単にアラートを増やすことではありません。
「気付けること」「切り分けを始められること」「運用で改善できること」 を揃えることが重要だと考えました。
監視整備のロードマップ
今回の取り組みは、段階的に進められるように、以下のステップに分けて設計しました。
今回のインターン期間では、Step 0〜Step 2を対象に、特に Istio / Karpenter / AWS Load Balancer Controller の監視整備に取り組みました。
STEP 0: まずはコンポーネントの優先度を決める
インターン期間には限りがあるため、最初に「どこから手を付けるべきか」を決める必要がありました。
また、後続のアラート設計でも優先度の定義はそのまま通知レベルに影響するため、最初に全体方針を固めることにしました。
共通ポリシー
優先度は次の 2 軸で判断しました。
- 重要度: 影響の大きさ × 影響が出るまでの早さ
- 系統: 障害の種類（停止 / 劣化）
その上で、P1〜P4 に対して以下のような共通ルールを定義しました。
※ ここでの閾値や評価ウィンドウは、運用やクラスタ特性によって変わるため、あくまで参考値です。
| 重要度 | 系統 | 基準 | 条件 | レベル |
|---|---|---|---|---|
| P1 | Hard down | 即時に広範囲へ影響 | が 1 分継続 | critical |
| P1 | Degraded | 即時停止ではないが継続すると危険 | が 10 分継続 | warn |
| P2 | Hard down | 比較的近いうちに影響あり | が 1 分継続 | warn |
| P2 | Degraded | 継続で重大影響へ進展 | が 10 分継続 | warn |
| P3 | Hard down | 限定的だが停止影響あり | が 1 分継続 | warn |
| P3 | Degraded | 劣化が続く | が 10 分継続 | warn |
| P4 | Hard down | 即時影響は薄い | が 1 分継続 | warn |
| P4 | Degraded | 長期放置で問題化 | が 10 分継続 | warn |
優先度付けの結果
P1 に分類したのは、停止時の影響が大きく、かつ影響が比較的短時間で顕在化するコンポーネントです。
| コンポーネント | サブコンポーネント | 実 workload 名 | ワークロード | Hard down | Degraded | 停止時の主な影響 |
|---|---|---|---|---|---|---|
| Istio | istiod（stable） | Deployment | 1分 → critical | 10分 → warn | 新規 Pod の sidecar 設定が届かなくなる | |
| Karpenter | controller | Deployment | 1分 → critical | 10分 → warn | 新しいノードが追加されなくなる | |
| AWS LBC | controller | Deployment | 1分 → critical | 10分 → warn | LB ターゲットが更新されなくなる |
この 3 つは、今回のインターンで最優先の監視対象として扱いました。
STEP 1: ワークロード死活監視を整備する
まず整備したのは、各コンポーネントに共通して適用できる ワークロード単位の死活監視 です。
個別メトリクスを見る前に、そもそも「コンポーネントが生きているか」を確実に検知できるようにすることが必要でした。
監視の考え方
ワークロードの種類ごとに、以下の 2 系統のアラートを定義しました。
- Hard down: ほぼ停止とみなせる状態
- Degraded: 一部レプリカ不足やカバレッジ低下など、継続すると危険な状態
Deployment / StatefulSet では、基本的に以下の方針です。
- Hard down: が 1 分継続
- Degraded: が 10 分継続
Degraded に 10 分のバッファを入れたのは、ローリングアップデート中に一時的に となるケースがあり、そこを過敏に拾うとノイズになるためです。
DaemonSet は別の見方が必要だった
DaemonSet では Deployment のように単純な「レプリカ数不足」だけでは実態を表しきれません。
各ノードで動くことに意味があるため、見るべきは ready / desired のカバレッジ です。
例えば Fluent Bit や Datadog Agent は、全ノードに広く展開されている前提のコンポーネントです。
そのため「1 台落ちた」と「2 割落ちた」では意味がまったく違います。
そこで、DaemonSet では比率を使った二段階監視を採用しました。
- Hard down: が一定時間継続
- Degraded: が一定時間継続
※ ここでの閾値や評価ウィンドウは、運用やクラスタ特性によって変わるため、あくまで参考値です。
たとえば、 が大きく低下した状態を Hard down、軽度の欠損が継続する状態を Degraded とみなし、それぞれに異なる閾値と評価ウィンドウを設定しました。
モニター数を増やしすぎない工夫
優先度 × 系統 × ワークロードごとに細かくモニターを分けると、管理対象が急激に増えてしまいます。
そこで今回は、系統 × ワークロード種別 を基本単位とし、P1 の Hard down だけを別途 critical として切り出す設計にしました。
結果として、作成したモニターは以下の 7 種類です。
- Deployment / Hard down / P1 critical
- Deployment / Hard down / non-P1 warn
- Deployment / Degraded / warn
- StatefulSet / Hard down / warn
- StatefulSet / Degraded / warn
- DaemonSet / Hard down / warn
- DaemonSet / Degraded / warn
この分け方により、通知ポリシーを保ちながら、運用上のモニター数を抑えることができました。
Datadog クエリの例
P1 の Deployment Hard down では、以下のようなクエリを使いました。
評価設定は次の通りです。
- Evaluate the minimum
- 直近 1 分の rolling window で評価
- 評価値が 1 未満になった場合に発火
また、StatefulSet の Degraded は desired と ready の差分で見ています。
STEP 1 で得られたこと
この段階で、最低限「主要コンポーネントが止まっていることに気付ける」状態が作れました。
一方で、これだけでは なぜ止まりそうなのか、どの方向に劣化しているのか までは見えません。
そこで次に、コンポーネントごとの特性に合わせた個別監視に進みました。
STEP 2: コンポーネント個別監視を整備する
個別監視では、各コンポーネントにとって「止まる前の兆候」や「止まっていなくても危険な状態」を捉えることを目指しました。
今回重点的に取り組んだのは、以下の 3 つです。
- Karpenter
- Istio
- AWS Load Balancer Controller
Karpenter の監視
Karpenter は Kubernetes クラスタにおけるノードライフサイクル管理を担うコンポーネントです。
正常に動いていないと、Pending Pod が増え続けてもノードが追加されず、サービスがスケールアウトできなくなります。
そのため、ワークロード死活監視だけでなく、ノード追加が遅れていないか / 失敗していないか を捉える個別監視が必要でした。
調査にあたりこちらを参考にさせていただきました。
主要メトリクス
今回は、以下の 4 つを主要な監視対象として選びました。
| メトリクス | 監視対象 |
|---|---|
| Pod 作成から Running までの時間 | |
| スケジューリング待ち Pod の滞留 | |
| クラウドプロバイダー API 呼び出しエラー | |
| コントローラ内部の Reconcile エラー |
選定理由
Karpenter における異常は、大きく次の 3 つの観点で捉えられます。
- 結果としてスケールが遅くなっているか
- ノード追加待ちが滞留しているか
- 外部要因または内部要因で処理に失敗しているか
そのため、以下のようにメトリクスを対応付けました。
- 実際に Pod の起動完了まで時間がかかっていないかを見る指標です。利用者影響に近い側のシグナルとして扱えます。
- スケジューリング待ちの Pod が滞留していないかを見るための指標です。ノード追加が追いついていない兆候を検知できます。
- AWS などクラウドプロバイダー API 側の失敗を検知するための指標です。外部要因によるノード追加失敗を把握できます。
- Karpenter 自体の内部処理失敗を捉えるための指標です。controller 側の異常を直接的に検知できます。
運用上の補足
は、そのまま監視すると が disruption の影響で頻繁に発生し、ノイズになっていました。
そのため、実際には以下のように除外条件を入れて監視しました。
このように、単にエラー数を見るのではなく、実運用で意味のある異常だけを拾えるようにすること を意識しました。
Istio の監視
Istio はサービスメッシュを提供するコンポーネントです。
istiod（Control Plane）が停止したり、xDS 設定の配布に問題が発生したりすると、サービス間通信に影響が出る可能性があります。
ただし、現行の運用では、Ameba のプラットフォームで Istio を主に トポロジー把握と分散トレーシング のために利用しており、mTLS を前提とした通信制御までは中心ではありません。
そのため今回は、監視対象を広げすぎず、Control Plane（istiod）の健全性監視 に絞って進めました。
調査にあたりこちらを参考にさせていただきました。
主要メトリクス
当初は、以下のメトリクスを監視候補として選定しました。
| メトリクス | 監視対象 |
|---|---|
| istiod 内部の XDS 処理エラー | |
| proxy が XDS 設定を拒否した回数 | |
| XDS レスポンス送信タイムアウト数 | |
| 設定変更から各 proxy への反映完了までの遅延 | |
| push キューの滞留 | |
| sidecar 注入失敗回数 |
選定理由
Istio の Control Plane における異常は、主に次の観点で捉えられると考えました。
- xDS 配布そのものに失敗していないか
- 設定反映が遅延していないか
- sidecar 注入に問題が起きていないか
それぞれに対して、以下のように候補メトリクスを整理しました。
- istiod 内部での XDS 処理失敗を検知するための指標です。
- 配布した設定が proxy 側で拒否されていないかを見るための指標です。
- XDS レスポンス送信の遅延・停滞を把握するための指標です。
- 設定変更が各 proxy に行き渡るまでの遅延を示す指標で、劣化の予兆検知に向いています。
- push キュー内部の滞留を見られるため、 の補助指標として利用できます。
- sidecar 注入失敗により、新規 Pod が mesh に正しく参加できていない状況を検知するための指標です。
実環境での調査結果
一方で、調査を進めると、ドキュメントやコード上では定義されているメトリクスの中に、実際の環境では取得できていないものがありました。
たとえば以下です。
コード上には定義が存在するため「本来は取得できるはず」と考えられますが、実際に stg 環境の istiod が公開している を確認すると、これらは出力されていませんでした。
この調査から、エラー系メトリクスは、イベントが一度も発生していない場合、Prometheus エンドポイントに公開されないことがある と分かりました。
つまり、
- コードには定義がある
- ドキュメントにも載っている
- しかし現環境でまだ発火していないため、実際の には現れない
という状況が起きていました。
最終的に採用した監視観点
この結果を受けて、取得できていないメトリクスは一次監視の対象から外し、実際に取得できているメトリクスから最低限有効な監視を構成する 方針に切り替えました。
最終的に、現時点で主監視対象としたのは以下です。
| メトリクス | 監視対象 | 備考 |
|---|---|---|
| 設定変更から各 proxy への反映完了までの遅延 | 主要監視対象 | |
| push キューの滞留 | 必要に応じて補助的に利用 |
証明書関連メトリクスについては、今回は mTLS を利用していないため優先度を下げました。
運用上の補足
は、Control Plane 障害そのものを直接示すメトリクスではありません。
一方で、設定反映の遅延を通じて、障害の手前にある不穏な状態 を捉えやすいという利点があります。
ただし、環境によっては値が一時的に跳ねることもあり、いきなり強いアラートを設定するとノイズになる可能性があります。
そのため、今回は
- まず可視化する
- 平常時の分布を見る
- ノイズと異常の境界を把握する
- その上でアラート化する
という順で進める方針にしました。
AWS Load Balancer Controller の監視
AWS Load Balancer Controller（以下 LBC）は、Kubernetes 上の Service / Ingress と AWS の Load Balancer リソースをつなぐ重要なコンポーネントです。
ここが正常に動いていないと、Kubernetes 側で変更を加えても、ALB / NLB の作成・更新が進まなくなります。
そのため、ワークロード死活監視に加えて、AWS 側との連携失敗や admission 経路の異常を捉える個別監視 が必要でした。
調査にあたりこちらを参考にさせていただきました。
※ AWS Load Balancer Controller の独自メトリクスは v2.13 以降で公開されているため、本記事の監視設計は v2.13 以降を前提としています。それ以前のバージョンでは、LBC 固有のメトリクスは利用できません。
主要メトリクス
| メトリクス | 監視対象 |
|---|---|
| LBC 内部の Reconcile エラー | |
| AWS API スロットリング | |
| AWS API 権限エラー | |
| AWS API service limit 超過 | |
| AWS API validation エラー | |
| webhook validation 失敗 | |
| webhook mutation 失敗 |
選定理由
LBC の異常は、大きく次の 3 系統に分けられます。
- LBC 自身の内部エラー
- AWS API 側の制約や異常
- Admission webhook 経路の失敗
そのため、単一のエラーカウンタだけを見るのではなく、どの層で失敗しているのか を分けて見られるようにしました。
たとえば、
- が増えているなら controller 自体の処理失敗
- が増えているなら IAM やポリシーの問題
- が増えているなら AWS クォータの問題
- が増えているなら admission 経路の異常
というように、異常カテゴリごとの切り分けがしやすくなります。
今回は見送ったメトリクス
性能分析や詳細調査に有用なメトリクスとして、以下も候補にはありました。
ただし、これらは一次監視というより、
- 発火後の詳細分析
- どこで遅いのかの切り分け
- ノイジーなリソースの特定
に向いています。
そのため、今回は 異常検知に直結するメトリクスを優先 し、これらは今後の可視化・運用改善のための候補として整理しました。
今回の取り組みで意識したこと
今回の監視整備では、単に「メトリクスを集めてアラートを設定する」のではなく、次の点を強く意識しました。
1. 最初に共通監視を整える
個別監視に進む前に、Deployment / StatefulSet / DaemonSet の死活監視を先に整えることで、最低限の検知網を先に作りました。
これにより、個別監視がまだ未整備のコンポーネントでも「完全停止には気付ける」状態を確保できました。
2. ノイズを拾わない
監視を育てるうえでは、検知漏れを減らすことと同じくらい、誤アラートや過剰な発報を防ぐことが重要です。発報が多すぎるとアラート疲れにつながり、本当に対処すべき異常を見逃しかねません。そのため今回の設計では、異常を拾うことだけでなく、閾値や評価ウィンドウを調整し、運用上持続可能な発報にすることを意識しました
3. 監視は単体では完結しない
最終的には、アラートが鳴ったときにどう動くかまで含めて設計する必要があります。
そのため、今後は Runbook とダッシュボードを整備し、監視を運用に接続していく予定です。
今後の取り組み
STEP 1 と STEP 2（Istio・Karpenter・AWS Load Balancer Controller）の整備後は、以下を進める予定です。
- STEP 2.5: そのほかのコンポーネント個別監視 cert-manager、ESO、HNC などAmeba Platformで使用されているコンポーネントへの展開
- STEP 3: Runbook 作成 アラート発火時の確認手順・対処手順の整備
- STEP 4: ダッシュボード作成 平常時の傾向把握や異常兆候の可視化
- STEP 5: 運用を通じた改善 PDCA 閾値調整、ノイズ削減、対象拡大
まとめ
今回のインターンでは、プラットフォームコンポーネントの監視が十分に整っていない状態から、まずワークロード死活監視を設計・整備し、そのうえで Istio・Karpenter・AWS Load Balancer Controller の個別監視に取り組みました。
特に印象的だったのは、監視設計が単なるメトリクス選定ではなく、
- 何を優先するか
- どこまでを一次監視にするか
- 実際に取れるメトリクスは何か
- ノイズやアラート疲れをどう減らすか
といった、運用全体を見据えた設計作業だったことです。
監視は、一度作って終わりではなく、実際の運用を通じて、閾値の妥当性を見直し、Runbook を整備し、ダッシュボードで傾向を把握しながら、継続的に改善していく必要があると感じました。
今回の取り組みが、Ameba Platformにおける障害の早期検知と対応速度の向上につながっていけば嬉しいです。
終わりに
インターン期間中、レビューや相談に乗ってくださった皆さま、ありがとうございました。
監視は地味に見えるかもしれませんが、安定運用を支える土台そのものだと感じました。
今回整備した内容を起点に、今後も「気付ける」「切り分けられる」「改善できる」監視に育てていければと思います。
SRGにご興味ありましたらぜひこちらからご連絡ください。