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
360
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
25
5.5k
Other Decks in Technology
See All in Technology
TypeScript、上達の瞬間
sadnessojisan
46
13k
初心者向けAWS Securityの勉強会mini Security-JAWSを9ヶ月ぐらい実施してきての近況
cmusudakeisuke
0
130
複雑なState管理からの脱却
sansantech
PRO
1
150
IBC 2024 動画技術関連レポート / IBC 2024 Report
cyberagentdevelopers
PRO
1
110
The Rise of LLMOps
asei
7
1.7k
CDCL による厳密解法を採用した MILP ソルバー
imai448
3
140
第1回 国土交通省 データコンペ参加者向け勉強会③- Snowflake x estie編 -
estie
0
130
障害対応指揮の意思決定と情報共有における価値観 / Waroom Meetup #2
arthur1
5
480
OCI Network Firewall 概要
oracle4engineer
PRO
0
4.2k
プロダクト活用度で見えた真実 ホリゾンタルSaaSでの顧客解像度の高め方
tadaken3
0
180
開発生産性を上げながらビジネスも30倍成長させてきたチームの姿
kamina_zzz
2
1.7k
iOSチームとAndroidチームでブランチ運用が違ったので整理してます
sansantech
PRO
0
150
Featured
See All Featured
Designing on Purpose - Digital PM Summit 2013
jponch
115
7k
What's in a price? How to price your products and services
michaelherold
243
12k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Practical Orchestrator
shlominoach
186
10k
GitHub's CSS Performance
jonrohan
1030
460k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
How to train your dragon (web standard)
notwaldorf
88
5.7k
How GitHub (no longer) Works
holman
310
140k
For a Future-Friendly Web
brad_frost
175
9.4k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Art, The Web, and Tiny UX
lynnandtonic
297
20k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
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を実現していくよう に取り組んでいきます!