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
20241120_JAWS_東京_ランチタイムLT#17_AWS認定全冠の先へ
tsumita
2
250
フルカイテン株式会社 採用資料
fullkaiten
0
40k
マルチプロダクトな開発組織で 「開発生産性」に向き合うために試みたこと / Improving Multi-Product Dev Productivity
sugamasao
1
300
[FOSS4G 2024 Japan LT] LLMを使ってGISデータ解析を自動化したい!
nssv
1
210
DMARC 対応の話 - MIXI CTO オフィスアワー #04
bbqallstars
1
160
ドメイン名の終活について - JPAAWG 7th -
mikit
33
20k
TypeScript、上達の瞬間
sadnessojisan
46
13k
データプロダクトの定義からはじめる、データコントラクト駆動なデータ基盤
chanyou0311
2
310
Shopifyアプリ開発における Shopifyの機能活用
sonatard
4
250
Python(PYNQ)がテーマのAMD主催のFPGAコンテストに参加してきた
iotengineer22
0
470
社内で最大の技術的負債のリファクタリングに取り組んだお話し
kidooonn
1
550
Lexical Analysis
shigashiyama
1
150
Featured
See All Featured
For a Future-Friendly Web
brad_frost
175
9.4k
[RailsConf 2023] Rails as a piece of cake
palkan
52
4.9k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
860
Building a Scalable Design System with Sketch
lauravandoore
459
33k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
Docker and Python
trallard
40
3.1k
Designing on Purpose - Digital PM Summit 2013
jponch
115
7k
Speed Design
sergeychernyshev
25
620
Testing 201, or: Great Expectations
jmmastey
38
7.1k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
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を実現していくよう に取り組んでいきます!