より意味のある監視を目指して、外形監視の有効活用

株式会社スリーシェイク
青木亮磨
2022/05/14 SRE NEXT 2022
より意味のある監視を
目指して、外形監視の
有効活用

View Slide

Copyrights©3-shake Inc. All Rights Reserved. 2
自己紹介
Web 系企業にて、バックエンドエンジニアとして
EC モールのシステムリプレイスや運用、
大規模セールに向けた負荷対策などに従事した後、
2021 年に株式会社スリーシェイクに入社。
現在は、 AWS / Google Cloud / Kubernetes などを用いた技術支援と、
自社の新規プロダクト開発に携わっています。
休日は愛犬と散歩したり、
愛犬を撫でくりまわしたりして過ごしています。
青木亮磨

View Slide

スリーシェイクについて

View Slide

提供しているサービス
SRE 支援 / 技術支援
サービス
Sreake
セキュリティ脆弱性診断
サービス
Sreake Security
クラウド型 ETL / データ
パイプラインサービス
Reckoner
ハイスキルフリーランス
紹介サービス
Relance
Reckoner はクラウド型 ETL /
データパイプラインサービス
です。
データベース・ストレージ・
アプリケーションなど、あら
ゆるデータを統合・連携する
ことで、データを活用したビ
ジネス変革に貢献します。
Sreake Security は経験豊富な
セキュリティ専門家が貴社の
課題に合わせたセキュリティ
対策を支援するサービスで
す。
Sreake は金融・医療・動画
配信・ AI ・ゲームなど技術力
が求められる領域で豊富な
経験を持つ SRE チームによる
技術支援サービスです。
戦略策定から設計・構築・
運用、 SaaS 提供まで、幅広
い領域をサポートします。
Relance はフリーランスエン
ジニア紹介サービスです。
技術支援や、 1on1 での定期
フォローなど、参画後も高い
パフォーマンスを維持し続け
られる体制を提供していま
す。

View Slide

Securify β 版無償提供中！
◯ Securify ( セキュリファイ ) とは
診断したいサイトを登録するとクラウド上で自動で脆弱性診断を実施し、
診断結果一覧と改善方法を分かりやすく提示するサービスです。
手軽に何度でも脆弱性診断の実施を可能にし、
セキュリティレベルの可視化・ DevSecOps への取り組みをサポートします。
β 版無償提供中！！

View Slide

本日お話しする内容
1. 監視について
a. よくあるアラート設計
b. よくあるアラート設計で生じる問題
c. 問題に対するアプローチ
2. CUJ の外形監視実装例
a. Datadog での実装例
b. 各 SaaS 、クラウドでの外形監視機能比較

View Slide

監視について

View Slide

監視とは
「監視とは、あるシステムやそのシステムのコンポーネントの
振る舞いや出力を観察しチェックし続ける行為である」
( 原文 ) “Monitoring is the actions of observing and checking the
behavior and outputs of a system and its components over time.”
by Greg Poirier at Monitorama 2016
システムを安定して継続的に提供するために、監視は重要な要素

View Slide

監視の要素
システムの行動や状態に
関するデータの収集・保持
収集したデータの
可視化・分析
問題の検知・通知
( アラート )

View Slide

監視の要素
可視化・分析
( アラート )
アプリケーションやサーバ、ネットワークなどの
ログやメトリクスを収集し、後から参照できるように保持する。

View Slide

監視の要素
可視化・分析
( アラート )
収集したデータを可視化して、
システムの状態を把握できるようにする。
必要に応じて分析を行い、システムに何か問題が起きていないか
何か問題が起きそうではないかを確認する。

View Slide

監視の要素
可視化・分析
( アラート )
システムに何か問題が発生している場合や、
問題が発生しそうな場合に検知し、通知する。
緊急で対応しなければいけない場合の通知と、
緊急ではないが後ほど確認しておいた方が良い場合の通知がある。

View Slide

よくあるアラート設計
思いつく怪しい状態をどんどん緊急的なアラートとして通知
Error ログが x 件出
たら
レイテンシが x sec 以
上になったら
ディスクの空き容量が
xx GB 以下になったら
メモリの空き容量が x
GB 以下になったら
ロードアベレージが x
以上になったら
CPU 使用率が xx %

View Slide

よくあるアラート設計の行く末
思いつく怪しい状態をどんどん緊急的なアラートとして通知
Error ログが x 件出
たら
レイテンシが x sec 以
上になったら
ディスクの空き容量が
xx GB 以下になったら
メモリの空き容量が x
GB 以下になったら
ロードアベレージが x
CPU 使用率が xx %
大量のアラート
電話やメンションの嵐

View Slide

よくあるアラート設計で生じる問題
本当に緊急で対応しないといけない内容なのであれば、
アラート設計的には問題なし。
システムを修正して、アラートの根本要因を取り除けば良い。
緊急で対応しなくても良い内容なのであれば危険。

View Slide

緊急ではないもしくはそもそも対応する必要がないのに
業務の中断 or 業務時間外の呼び出しが発生し、貴重な時間を奪われる。
また、そういったアラートが上がる状態が続くと単純に疲れてしまう。
しまいにはアラートを軽視するようになり、本当に対応が必要な場合に
● 初動が遅れる
● 適当に対応して、判断や対処を誤る
● 無視してしまう

View Slide

緊急ではないもしくはそもそも対応する必要がないのに
業務の中断 or 業務時間外の呼び出しが発生し、貴重な時間を奪われる。
また、そういったアラートが上がる状態が続くと単純に疲れてしまう。
しまいにはアラートを軽視するようになり、本当に対応が必要な場合に
● 初動が遅れる
● 適当に対応して、判断や対処を誤る
● 無視してしまう
俗に言う「オオカミ少年アラート」問題

View Slide

じゃどうすれば良いか
ユーザー目線でサービスが正常に動いているかを監視し、
サービス影響が生じている ( 緊急対応が必要な ) 場合に
通知したい ...

View Slide

じゃどうすれば良いか
ユーザー目線でサービスが正常に動いているかを監視し、
サービス影響が生じている ( 緊急対応が必要な ) 場合に
通知したい ...
SRE の世界では、ユーザー目線でサービスの
信頼度 (SLI / SLO) を定義・計測する際に
クリティカルユーザージャーニー (CUJ) を
活用しているよ。
SRE

View Slide

クリティカルユーザージャーニー (CUJ) とは
ユーザージャーニー = ユーザーが目的を果たすために行う一連のアクション
ビジネスへのインパクトとして最も重要なものが
クリティカルユーザージャーニー (CUJ) と呼ばれる。
例えば、 EC サイトであれば商品を購入されることが
ビジネスとして重要なので、 CUJ としては次のようなものが考えられる。
→ →
商品の検索商品をカートに追加購入

View Slide

CUJ の監視には外形監視が導入しやすい
パターン内容メリットデメリット
API ベース
CUJ を実行する際にアプリ
ケーションから利用される
API を順々に確認し、正常に
レスポンスが返ってくるかを
確認
導入がシンプル
ブラウザや端末からサービス
を利用できるかという観点で
の確認はできない
ブラウザベース
(Web アプリの場合 )
ヘッドレスブラウザなどを用
いて実際にブラウザ上でアプ
リケーションを操作し
て、 CUJ を実行できるか確認
よりユーザー目線でサービス
の状態を確認できる
UI の変更が多い場合、保守が
大変
CUJ の監視としては外形監視がシンプルで導入しやすい。
外形監視としては大きく 2 パターンのやり方が存在する。

View Slide

API ベース
確認
大変
多くの場合、ブラウザベースでの監視は運用コストが無視できない大きさに ...

View Slide

API ベース
確認
大変
なので、今回は API ベースを採用して、 CUJ の監視を行ってみる

View Slide

Datadog での
CUJ 外形監視実装例

View Slide

今回のお題 : Sock Shop
Microservices なデモアプリ
maintained by Weaveworks & Container Solutions
靴下の EC サイトで以下の機能がある
● 会員登録 / ログイン
● 商品検索
● カート
● 注文

View Slide

Sock Shop の CUJ
商品検索 → → →
商品情報取得カートに追加注文

View Slide

Sock Shop の CUJ
商品検索 → 商品情報取得 → →
カートに追加注文

View Slide

Sock Shop の CUJ
商品検索 → 商品情報取得 → カートに追加 → 注文

View Slide

Sock Shop のシステム構成図 ( 簡略版 )
front-end は SSR と BFF の役割を担う。
front-end の後ろにユーザーアカウントや
商品、カート、支払い方法、注文情報を
管理する API が存在する。
先ほど設定した CUJ を実行する際に
Web アプリケーションから利用される
BFF のエンドポイントを順々に確認する
外形監視を作成してみる。

View Slide

Datadog の外形監視機能 (Synthetic Monitoring)
Synthetic Monitoring で
実行できるテスト
内容
API Test API に対して、単一のリクエストを送り、レスポンスを検証できる。
Multistep API Test
複数の API Test をチェーンして、シナリオを検証できる。
前のリクエストで得たレスポンスは後続のリクエストで
用いることが可能。
Browser Test 実際にブラウザ上でアプリケーションを操作して、
アプリケーションの動作を検証できる。

View Slide

Datadog の外形監視機能 (Synthetic Monitoring)
Synthetic Monitoring で
実行できるテスト
内容
API Test API に対して、単一のリクエストを送り、レスポンスを検証できる。
Multistep API Test
複数の API Test をチェーンして、シナリオを検証できる。
前のリクエストで得たレスポンスは後続のリクエストで
用いることが可能。
Browser Test 実際にブラウザ上でアプリケーションを操作して、
アプリケーションの動作を検証できる。
今回は API ベースで CUJ を監視するので、 Multistep API Test を利用する

View Slide

定義したステップ

View Slide

ステップ① ログイン
⇦ リクエスト内容の設定
Sock Shop はベーシック認証でログインする仕組みなので、
Authorization header にユーザー名とパスワードをセットし、
ログイン用のエンドポイントにリクエスト。
※ パスワードなどの機密情報は Global Variables という機能を
“ hide and obfuscate variable value” というオプションとともに
利用すると、値は利用できるが値の中身は見ることができないと
いう状態で保持できる。
⇦ レスポンスの検証内容の設定
● レスポンスタイムが 2000ms 以下
● ステータスコードが 200
● Set-Cookie header に値が含まれている
⇦ レスポンスから値を抽出
後続のリクエストの header に cookie をセットできるように、
cookie の中身を COOKIE という変数に入れておく。

View Slide

ステップ② 商品検索
header にステップ①で取得した cookie を付与。
以降のステップのリクエストでも同様に cookie を付与する。

View Slide

ステップ② 商品検索
商品を検索するために、商品検索用エンドポイントにリクエスト。
今回は brown タグが設定されている商品のみを検索するため、
tags=brown のクエリパラメータを設定。
⇦ レスポンスから値を抽出
ステップ③以降では、ヒットした 1 件目の商品を購入する
フローを検証していくので、 1 件目の商品 ID を変数に入れておく。

View Slide

ステップ③ 商品情報取得
先ほどの検索でヒットした 1 件目の商品の情報を取得するため、
商品情報を取得するためのエンドポイントにリクエスト。
● body の id が検索した商品の ID と一致

View Slide

ステップ④ カートに追加
body にカートに追加したい商品の ID を記載し、
カート追加用のエンドポイントにリクエスト。
⇦ レスポンスの検証方法の指定

View Slide

ステップ⑤ カートの中身を確認
カートに先ほど追加した商品が入っているか確認するために、
カートの状態を参照する用のエンドポイントにリクエスト。
● カートの商品の ID が追加した商品の ID と一致

View Slide

ステップ⑥ 注文
カートに入れた商品を注文するために、
注文用のエンドポイントにリクエスト。

View Slide

ステップ⑥ 注文
カートに入れた商品を注文するために、
注文用のエンドポイントにリクエスト。
※ 今回はデモアプリなので特に気にせず注文処理をテストしているが、
実運用しているアプリケーションでは監視のリクエストにより不都合が生じないように、
監視のリクエストの場合は決済のようなクリティカルな処理はスキップし、
正常時と同じようなレスポンスを返すといった振る舞いに事前にしておく必要あり

View Slide

監視の頻度
監視の頻度は 30sec ~ 1week の間で設定可能。
高頻度で行うことが望ましいが、その分費用が発生するので、
そこは予算との相談で。
Datadog の Synthetic Monitoring の API Test だと費用は
10,000 テスト / 月あたり $5 (2022/04/11 時点）

View Slide

ダッシュボード : 全ステップ成功時

View Slide

ダッシュボード : 失敗時

View Slide

ダッシュボード : 失敗時
失敗時のアラート設定をしておけば、
Slack などのチャットツールに通知したり、
PagerDuty などと連携して電話をかけたりが可能

View Slide

各 SaaS 、クラウドでの外形監視機能比較
[Datadog]
Synthetic Monitoring
API Test, Multistep API Test
[New Relic]
Synthetics
Endpoint availability
[AWS]
Cloud Watch
Synthetics Canaries
[Google Cloud]
Cloud Monitoring
public uptime check
シナリオ実装の可否 ◯ ◯ ◯ ×
設定可能な実行間隔 30 sec ~ 1 week 1 min ~ 1 day 1 min ~ 1 year 1 min ~ 15 min
送信元
国内からの送信 : ◯
IP 固定 : (Location
△ 毎に
IP range が決まっている )
△ 毎に
IP 固定 : ◯
国内からの送信 : ×️
△ 毎に
gRPC 対応
△
( ヘルスチェックなら可 )
◯
( 自環境に Containerized
Private Minion を入れる必要あり )
△
( ヘルスチェックなら可 )
×
コスト 10,000/ 月あたり $5
無料プラン : 毎月 100 回まで
Pro プラン : 毎月 100 万回まで
Enterprise プラン : 毎月 1000 万回
毎月 100 回まで無料
それ以降は 1 回あたり $0.0019 無料
要点 UI 上で設定できるので簡単。
スクリプトを記述する
形式なので柔軟に設定可能。
スクリプトを記述する
形式なので柔軟に設定可能。
他と比べるとコスト高め。
シナリオでのテストはできないが、
無料なので気軽に利用できる。

View Slide

まとめ

View Slide

まとめ
● 何でもかんでも緊急的なアラートとして発報するのは危険
○ アラート疲れが起きてしまう
○ アラートを軽視するようになり、アラートとしての効果を失ってしまう
● まずはサービス影響が生じている場合にアラートを発報する
○ サービス影響が生じているかの判断はクリティカルユーザージャーニー (CUJ) の監視を
○ CUJ の監視には外形監視がシンプルで導入しやすい
○ 各 SaaS やクラウドには外形監視機能が備わっているのですぐ導入可能
● 余談
○ CUJ の外形監視だけをしておけば良いというわけではない
■ CUJ の外形監視で捕捉できない障害は他の監視でカバー
■ 近いうちに起こりうる障害を検知するにはサービス影響が生じているかではなく、
システム目線での健康診断も必要
もし検知した場合は緊急的なアラートとは別の方法で通知したり、
チケットを生成するなどして、アラートがごちゃごちゃにならないように

View Slide

参考資料・動画
● 入門監視、 Mike Julian 著、松浦隼人訳
○ https://www.oreilly.co.jp/books/9784873118642/
● Monitorama PDX 2016 - Greg Poirier - Monitoring is Dead. Long Live Monitoring
○ https://vimeo.com/173610062
● Datadog : Synthetic Monitoring
○ https://docs.datadoghq.com/synthetics/
● New Relic : Write synthetic API tests
○ https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/scripting-monitors/write-synthetic-a
pi-tests
● AWS : Using synthetic monitoring
○ https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics`_Ca
naries.html
● Google Cloud : Create public uptime checks
○ https://cloud.google.com/monitoring/uptime-checks

View Slide

Thank you

View Slide

より意味のある監視を目指して、外形監視の有効活用

より意味のある監視を目指して、外形監視の有効活用

Ryoma Aoki

Featured

Transcript