運用ダッシュボードの設計を誰も教えてくれないのだけど みなさんどうしてるんですか？ - チームに監視するという文化を根付かせるための第一歩を踏みたい -

Transcript

1. 運用ダッシュボードの設計を誰も教 えてくれないのだけど みなさんどうしてるんですか？  チームに監視するという文化を根付かせるための第一歩を踏みたい 2026.07.26 SATOSHI KANEYASU
2. Speaker Introduction 氏名：兼安 聡 所属：株式会社サーバーワークス アプリケーションサービス本部 在住：広島 担当： PM、SM、DevOps、仕様駆動開発 SNS(X)：@satoshi256kbyte • • • • • • 2026 Japan AWS Ambassadors 2024-26 Japan AWS Top Engineers 2024-26 Japan AWS All Certifications Engineers 2025-26 AWS Community Builders Certified ScrumMaster PMP
3. このLTの背景 • 今回は私はアプリエンジニアだと思ってください • SREというか監視の文化がまだない現場に、 最初の一歩として運用ダッシュボードを作ろうとしてます • チームに監視するという文化を根付かせるための第一歩を踏みたいのです
4. 別のチームの運用担当者さんに相談してみました • Q：前のページの内容を踏まえて、 運用ダッシュボードには何を載せればいいですか？ • A：要件次第
5. 教えてもらった手順 • • • • • 何を見たいのかを明らかにする 誰が見るものなのかを明らかにする 必要なデータの収集と整理 KPIの設定 etc
6. どうも考えていることが違うような気がする • そんなつもりは全くなかったのだが、 DevとOpsの立場が出ているように思える状況になった • Dev • 新しい機能を作るのが ミッション • まずは最小限 できる範囲を広げる • Ops • 安定稼働させるのがミッション • 対象・シチュエーションの網羅 • 役割・スコープの明確化 • じゃあまあ、一歩踏み出すならこっち（Dev）だ • 変わってくれというのは筋違いだ
7. 参考書籍・参考ページ • SLO サービスレベル目標 ―SLI、SLO、エラーバジェット導入の実践ガイド • レベル違いだった。書籍の選択ミス • 入門 監視 ―モダンなモニタリングのためのデザインパターン • • [引用]2.2 デザインパターン２：ユーザー視点での監視 ここまでですでに何か作りたくてウズウズしているかもしれませんが、どこから始めたらよいで しょうか？あなたのアプリケーションとインフラは複雑で、たくさんの稼働部分から構成されており、 どこが壊れてもおかしくありません。計測する必要がありそうな箇所はたくさんありますが、手を つけるのに最適な場所があります。それはユーザーです。 • Google SRE Book - Chapter 6: Monitoring Distributed Systems • [引用]The four golden signals of monitoring are latency, traffic, errors, and saturation. If you can only measure four metrics of your user-facing system, focus on these four.
8. Google SRE Book - The Four Golden Signals シグナル 説明 Latency（レイテンシー） リクエストを処理するのにかかる時間。成功時と失敗時を区別し て計測する Traffic（トラフィック） システムに対するリクエスト量。HTTP リクエスト数/秒など Errors（エラー） 失敗したリクエストの割合。明示的な 5xx だけでなく不正な応答 内容も含む Saturation（飽和度） リソースがどれだけ逼迫しているか。CPU・メモリ・ディスク I/O などの使用率
9. AWSの構成図と照らし合わせてみる
10. ALBとAmazon ECS Clusterに着目してみる シグナル AWS サービス Latency ALB TargetResponseTime ターゲットがリクエストを処理して応答するまで の時間 Traffic ALB RequestCount ALB が受け付けたリクエストの総数 Errors ALB HTTPCode_ELB_5XX_Count ALB 起因の 5xx エラー数 Errors ALB HTTPCode_Target_5XX_Count バックエンド（ECS）起因の 5xx エラー数 Saturation ECS CPUUtilization クラスター/サービスの CPU 使用率 Saturation ECS MemoryUtilization クラスター/サービスのメモリ使用率 メトリクス 説明
11. 静的閾値と異常検知 • リクエスト数はパッと見てもOK/NGがわかると思えないので、 最初から過去のパターンからの異常検知の方がいいと思う • AWSなら機械学習による異常検知のAmazon CloudWatch Anomaly Detection 引用：CloudWatch 異常検出の使用 - Amazon CloudWatch • レイテンシーの許容度は現実的には機能ごとに事情が違う気もするが、 最初から例外を設けるのもおかしいので決め打ちの静的閾値で良いかと
12. 5XXエラーを一まとめにしたメトリクスでいいのか？ • 5XXエラーのメトリクスは最初の一歩としてもちょっと大雑把だとは思う。 ステータスコード メトリクス 意味 500 HTTPCode_ELB_500_Count ALB 内部エラー 502 HTTPCode_ELB_502_Count ターゲットからの不正な応答 （接続拒否・途中切断など） 503 HTTPCode_ELB_503_Count ターゲットが不足・ヘルスチェック失敗で 振り先がない 504 HTTPCode_ELB_504_Count ターゲットの応答がタイムアウト • だが、5XXを綺麗に出し分けられるほどアプリが成熟してるか？と言われる と、アプリと相談の気がする。 5XX系で一旦運用ダッシュボードをリリースし て、ここでアプリチームと改めて相談な気がする。
13. まとめ • 最初の一歩はThe Four Golden Signals、user-facing • Traffic は異常検知 • 次のステップは5XX系のエラーの細分化？