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では１つ目のことをメインに話をさせていただきます。 o11yじゃなくて監視だよね感は否めませんが、o11y初心者ゆえ何卒ご容赦いただけますと幸いです。

o11yデビューすることになった経緯 5

2022年度まで 6 ● 受託案件にてインフラエンジニアを担当 ● アプリケーション周り=>顧客/インフラ周り=>弊社という明確な責任範囲 工数が限られており、顧客要件に引っ張られるためオブザーバビリティの実践が難しい。 また、もし実践したとしてもインフラ周りだけだとやれることが限定的になってしまう。 アプリ/インフラで分断 顧客要件ドリブン

2023年度から 7 ● 自社案件にて非機能領域全般を担当 ● アプリケーションもインフラも全て自社にて 自分たちで要件をコントロールできるため、オブザーバビリティの実践が現実的に！ またアプリ/インフラ全てのレイヤーを横断できることも追い風に！ 自分ドリブン アプリとインフラが一体

レッツ o11y !! 8

スタートダッシュ失敗 9 まずo11yという 概念自体がふわふわ していて、共通認識を 持ちにくい。。 トレースって何だ？ 具体的に何を やればいいの？ 何から手をつけていいかわからない

できるところからはじめる 10 まずはスモールスタート！できるところからやっていく！ 具体的には 1. 本質的な監視の実装 2. システム状態の可視化

1. 本質的な監視の実装 11 今までの監視にもやもやしていました。 もやもやポイント① : 無意味なリソース監視 EC2やRDSのCPU使用率/メモリ使用率/ディスク使用率に閾値を設けて、閾値を超過した らアラート/エスカレーションするといった監視をしていた もやもやポイント② : 不十分な外形監視 トップページのみに対して外形監視を行っており、アプリケーション全体に問題が生じない 限り、アプリケーションの異常に気づくことができなかった これらのもやもやを解決して、本質的な監視を実装することを決めました。

2. システム状態の可視化 12 監視対象のメトリクスやログのみを取得している状態だったため、以下の課題がありました。 ● 監視対象のメトリクス以外を取得していない ● システム状態(メトリクスやログなど)を一元的に確認できない これによって、実際にシステムに異常が生じた場合でも、すぐに調査や分析を開始することができず、異 常の原因を把握することが難しい状況でした。 そのため、取得できるメトリクス/ログを全て１箇所に集約して、それを可視化できる仕組みを作ることにし ました。

前提 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のダッシュボード機能を利用して、システムのメトリクスやログを１箇所で確認できるようにしま した。 １箇所でシステム状態を確認することが可能なため、 アラート発生 → ダッシュボード確認 → 原因の特定 がスピーディにできるようになりました。

最後に 28

ようやくスタートライン 29 o11yのはじめの一歩として ● 本質的な監視 ● システム状態の可視化 を行いました。これにより「異常の検知」と「原因の分析」が可能になりました。 あくまでここはスタートラインなので、今後さらに取り組みを広げて、より本格的なo11yを実現していくよう に取り組んでいきます！