Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
o11y入門_外形監視を利用したWebアプリケーションへの最適なモニタリング_TechBrew
Search
Keisuke Matsuda
April 11, 2024
Technology
4
470
o11y入門_外形監視を利用したWebアプリケーションへの最適なモニタリング_TechBrew
イベントURL
https://findy.connpass.com/event/312930/
Keisuke Matsuda
April 11, 2024
Tweet
Share
More Decks by Keisuke Matsuda
See All by Keisuke Matsuda
AWS構成図についてのLT
k5k
24
5.9k
Other Decks in Technology
See All in Technology
Perlの生きのこり - エンジニアがこの先生きのこるためのカンファレンス2025
kfly8
1
230
Cloud Spanner 導入で実現した快適な開発と運用について
colopl
1
940
The Future of SEO: The Impact of AI on Search
badams
0
250
Culture Deck
optfit
0
510
コンピュータビジョンの社会実装について考えていたらゲームを作っていた話
takmin
1
530
白金鉱業Meetup Vol.17_あるデータサイエンティストのデータマネジメントとの向き合い方
brainpadpr
7
950
AIエージェント元年
shukob
0
130
全文検索+セマンティックランカー+LLMの自然文検索サ−ビスで得られた知見
segavvy
2
140
LINEギフトにおけるバックエンド開発
lycorptech_jp
PRO
0
140
ディスプレイ広告(Yahoo!広告・LINE広告)におけるバックエンド開発
lycorptech_jp
PRO
0
140
人はなぜISUCONに夢中になるのか
kakehashi
PRO
6
1.7k
SA Night #2 FinatextのSA思想/SA Night #2 Finatext session
satoshiimai
1
150
Featured
See All Featured
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Java REST API Framework Comparison - PWX 2021
mraible
28
8.4k
The World Runs on Bad Software
bkeepers
PRO
67
11k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
420
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
40
2k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Transcript
TechBrew in 東京〜オブザーバビリティのベストプラクティス〜 o11y入門 外形監視を利用したWebアプリケーションへの最適なモニタリング 2024/04/11 アイレット株式会社 松田 啓佑
自己紹介 2 松田 啓佑 • X(Twitter) ◦ @ksk_mats_ • 所属
◦ アイレット株式会社 • 業務 ◦ Webアプリケーション開発における非機能領域全般を担当 ◦ インフラ、オブザーバビリティ、バックエンド開発 • 好きなAWSサービス ◦ Amazon ECS • 認定 ◦ 2023 Japan AWS Top Engineers • 趣味 ◦ テニス ◦ 飲酒
本日話すこと 3
本日話すこと 4 オブザーバビリティ(以後o11y)デビューすることになったエンジニアが、まず初めの一歩として以下のこと に取り組みました。 • 最適なモニタリングの設計/実装 • 取得可能なメトリクスを集約/可視化 本LTでは1つ目のことをメインに話をさせていただきます。 o11yじゃなくて監視だよね感は否めませんが、o11y初心者ゆえ何卒ご容赦いただけますと幸いです。
o11yデビューすることになった経緯 5
2022年度まで 6 • 受託案件にてインフラエンジニアを担当 • アプリケーション周り=>顧客/インフラ周り=>弊社という明確な責任範囲 工数が限られており、顧客要件に引っ張られるためオブザーバビリティの実践が難しい。 また、もし実践したとしてもインフラ周りだけだとやれることが限定的になってしまう。 アプリ/インフラで分断 顧客要件ドリブン
2023年度から 7 • 自社案件にて非機能領域全般を担当 • アプリケーションもインフラも全て自社にて 自分たちで要件をコントロールできるため、オブザーバビリティの実践が現実的に! またアプリ/インフラ全てのレイヤーを横断できることも追い風に! 自分ドリブン アプリとインフラが一体
レッツ o11y !! 8
スタートダッシュ失敗 9 まずo11yという 概念自体がふわふわ していて、共通認識を 持ちにくい。。 トレースって何だ? 具体的に何を やればいいの? 何から手をつけていいかわからない
できるところからはじめる 10 まずはスモールスタート!できるところからやっていく! 具体的には 1. 本質的な監視の実装 2. システム状態の可視化
1. 本質的な監視の実装 11 今までの監視にもやもやしていました。 もやもやポイント① : 無意味なリソース監視 EC2やRDSのCPU使用率/メモリ使用率/ディスク使用率に閾値を設けて、閾値を超過した らアラート/エスカレーションするといった監視をしていた もやもやポイント②
: 不十分な外形監視 トップページのみに対して外形監視を行っており、アプリケーション全体に問題が生じない 限り、アプリケーションの異常に気づくことができなかった これらのもやもやを解決して、本質的な監視を実装することを決めました。
2. システム状態の可視化 12 監視対象のメトリクスやログのみを取得している状態だったため、以下の課題がありました。 • 監視対象のメトリクス以外を取得していない • システム状態(メトリクスやログなど)を一元的に確認できない これによって、実際にシステムに異常が生じた場合でも、すぐに調査や分析を開始することができず、異 常の原因を把握することが難しい状況でした。
そのため、取得できるメトリクス/ログを全て1箇所に集約して、それを可視化できる仕組みを作ることにし ました。
前提 13
監視対象システム 14 • AWS上に実装した小規模なWebアプリケーション • コンピューティングはECS Fargate • フレームワークはLaravel •
バックエンドDBはRDS • 静的ファイル保存はS3 • 認証基盤はCognito • メール送信はSES • 外部API連携(slackなど)
利用したツール 15 New Relicを利用しました。 元々、社内における標準的な監視ツールとして利用していた背景があります。
バイブル 16
実際に取り組んだこと ~本質的な監視の実装~ 17
本質的な監視の実装 18 ❖ 問題 無意味なリソース監視をやめて、システムのあらゆる異常を検知できる本質的な監視を実現するた めにはどうすれば良いか? ❖ 答え システム内の正常性確認ができるヘルスチェックエンドポイントを設けて、そのエンドポイントに対し て外形監視を行う
アプリ自身が正常性確認する仕組みを作り、外部から実行する = バックエンド監視
バックエンド監視 19 確認したい観点分、ヘルスチェックエンドポイントを設けました。 処理や連携に異常がない場合はステータスコード200、異常がある場合は500を返すようにエンドポイン トを実装。 エンドポイント エンドポイントの確認観点 healthcheck/func1 機能 :
func1が正常に処理されるか? healthcheck/func2 機能 : func2が正常に処理されるか? healthcheck/db DBとの連携(読み取り/書き込み)が正常に行えるか? healthcheck/mail メール送信が正常に行えるか? healthcheck/s3 S3との連携(ListObject / PutObject)が正常に行えるか? healthcheck/slack slackとの連携(post)が正常に行えるか?
バックエンド監視 20 New RelicのSynthetic Monitorという外形監視機能を利用して、定期的にヘルスチェックエンドポイント にHTTPリクエストを送信、以下の場合にアラートになるような監視を実装しました。 • レスポンスのステータスコードが200以外 • レスポンスの応答時間が3秒以上
フロントエンド監視 21 途中、Cognitoとの連携をエンドポイントにて確認することが難しいことが発覚しました。 そこで、New RelicのScripted Browser Monitorという機能を利用して、ログイン操作をシミュレートした 外形監視を行うことでカバーしました。 具体的には以下を行います。 1.
ユーザ/パスワードの入力 2. ログインボタンのクリック 3. ログインした後のHTML要素の存在有無の確認 外部からユーザ操作をシミュレートした確認を行う = フロントエンド監視
Webアプリケーションにおける本質的な監視とは 22 バックエンド監視とフロントエンド監視を組み合わせてシステム全体をカバーする。 これでもカバーできない範囲はログ監視で補う。 バックエンド監視 + フロントエンド監視 + (ログ監視) =
本質的な監視
ツッコミどころ 23 ❖ 質問 バックエンド監視とフロントエンド監視って言ってるけど、結局どちらも外形監視により成り立っているじゃ ないか!!外形監視を利用しているということは、どちらもフロントエンド監視ということじゃない!?
ツッコミどころ 24 ❖ 回答 外形監視を利用しているので、監視の起点はフロントエンドです。しかし正常性確認の実態が異なりま す。バックエンド監視はフロントエンドを経由して、バックエンドにて正常性確認の処理が行われます。フ ロントエンド監視は、フロントエンドだけで正常性確認の処理が完結します。 どこで確認の処理が行われるかという観点で分けると、バックエンド監視とフロントエンド監視の棲み分け は明確になるのかなと。
New Relicの外形監視機能について 25 バックエンド監視で利用したのはPing Monitorという機能です。URLを指定するだけで、定期的にその URLに対してHTTPリクエストを送信して、ステータスコードや応答時間などを取得することができます。 フロントエンド監視で利用したのはScripted Browser Monitorです。これはSeleniumベースの機能で、 JSスクリプトで処理を記述して、ユーザ操作をシミュレーションしたフロントエンドの確認が可能です。
全部で7つの機能があります。ブログでまとめているのでぜひご参照ください。 アイレット newrelic synthetics
実際に取り組んだこと ~システム状態の可視化~ 26
システム状態の可視化 27 New Relicのダッシュボード機能を利用して、システムのメトリクスやログを1箇所で確認できるようにしま した。 1箇所でシステム状態を確認することが可能なため、 アラート発生 → ダッシュボード確認 →
原因の特定 がスピーディにできるようになりました。
最後に 28
ようやくスタートライン 29 o11yのはじめの一歩として • 本質的な監視 • システム状態の可視化 を行いました。これにより「異常の検知」と「原因の分析」が可能になりました。 あくまでここはスタートラインなので、今後さらに取り組みを広げて、より本格的なo11yを実現していくよう に取り組んでいきます!