WebアプリでもインフラでもAIエージェントでも大事なのはログ！

JAWS-UG初心者支部 #93 Short Session大会

Transcript

1. Webアプリでもインフラでも AIエージェントでも大事なのはログ！ JAWS-UG初心者支部 #93 Short Session大会 くらっち
2. 自己紹介 普段の業務 趣味 Railsアプリのエンジニア スポーツ QAエンジニア 野球, ソフトボール AIエンジニア マラソン インフラはちょっと！ ビーチラグビー スキー, スノボ 好きなAWSサービス くらっち @kuracchi_enj 23卒の25歳 JAWS-UG 東京支部 運営メンバー 好きなRubyライブラリ Bedrock AgentCore ActiveRecord Lambda ruby-sdk CDK（OSSだけど！）
3. logって聞いて、何を思い浮かべますか？
4. y = logx
5. 一定の数、対数関数が浮かぶ方が いらっしゃるでしょう
6. 今日は「履歴」の方のログ！
7. ログってなんで重要？ Agenda ログ設計のコツ ログレベルを意識しよう ログ出力における注意点 まとめ
8. ログの話なんですけど、 最近GAした「CloudWatch Omni」の 話はしません！
10. 01 ログってなんで重要？
11. そもそも「ログ」ってなんだ？ システムで起きた出来事を、後から確認できるように記録したもの でもね？ 記録するだけじゃダメなんです。 なんで？ 問題・障害が発生した時に、 早急に原因を突き止めることができない
12. 僕はこう思います。
13. 役に立たないログは「落書き」だ。
14. 例えば、こんなシステムで障害があったとします 注文ボタンを クリック ユーザから 「昨日の21時頃、注文ができなかったんですけど！」 と問い合わせが来たとします まず何を確認しますか？ 在庫確認 決済 注文の保存 ログ！
15. ケースごとに考えてみる！ ログがない リクエストが届いていたのかわからない どこまで処理されていたのかわからない ログメッセージが不十分（ ERROR 注文に失敗しました ） 失敗したことはわかる どの注文でどこで失敗したのかわからない 調査に使えるログがある（注文, リクエストID, 処理名, 結果） 対象のリクエストを追い、どこでどのように失敗したのかがわかる
16. 調査に使えるログ例！ 21:03:10 INFO request_id=abc step=stock_check result=success 21:03:10 INFO request_id=abc step=payment result=started 21:03:15 ERROR request_id=abc step=payment error=timeout ERRORレベルのログにtimeoutって書いてある！ stepがpaymentだから決済処理で落ちたんだな！ ってことは 「決済処理でタイムアウトになったんだな！」
17. ログがないと何が起きたかわからない！ ログがあっても必要な情報がなければ調査できん！
18. 02 ログ設計のコツ
19. ざっくりで失礼！ 先ほどのシステムが以下の構成だったとします 注文ボタンを クリック ① リクエストが API Gatewayへ ② Lambdaを発火 ③ 在庫確認 ⑥ レスポンス ⑤ 注文を保存 ④ 決済実行
20. ざっくりで失礼！ 先ほどのシステムが以下の構成だったとします API Gatewayには 「アクセスログ」が溜まっているはず！ 注文ボタンを クリック ① リクエストが API Gatewayへ ② Lambdaを発火 ③ 在庫確認 ⑥ レスポンス ⑤ 注文を保存 ④ 決済実行 Lambdaには 「実行環境」「在庫確認処理」「決済処理」「注文保存処理」のログが溜まっているはず！ オレンジ・・・インフラ側のログ ブルー・・・・アプリ側のログ
21. これらのログは、CloudWatch Logsへ！ ざっくりで失礼！ CloudWatch Logs アクセスログ 注文ボタンを クリック ① リクエストが API Gatewayへ ② Lambdaを発火 ③ 在庫確認 ⑥ レスポンス ⑤ 注文を保存 ④ 決済実行 「実行環境」「在庫確認処理」 「決済処理」「注文保存処理」 のログ CloudWatch Logs
22. AWSの場合、ログの出力先といえば CloudWatch Logs ってくらいよく使われます！
23. ここからログ設計のコツを... ※ 個人の感覚的なところも含みます！
24. では、何か障害が発生した場合
25. 真っ先に見るログは インフラ側のログ？ アプリ側のログ？
26. インフラ基盤があって インフラ基盤 アプリケーション その上でアプリケーションが動作すると考える！
27. まずは場所を特定する必要があるので...
28. インフラ側のログを先に見ることになるはず！
29. インフラ側のログを見て、 どこでバグが起きているか確認して 「インフラ起因」or「アプリ起因」 を見極める！
30. インフラ側のログ設計のコツ アクセスログ 注文ボタンを クリック ① リクエストが API Gatewayへ ② Lambdaを発火 ③ 在庫確認 ⑥ レスポンス ⑤ 注文を保存 ④ 決済実行 例えば、 API Gatewayのアクセスログ Lambda Event Functionsの 実行環境ログ 実行環境ログ 以下を押さえておきましょう！ インフラのどこで何が発生しているのか、わかるようにする！ インフラのログからアプリのログ調査に繋げられるようにする！ デフォルトでAWSが用意したログが出力されるようになってたりしますが、 有効化や記録項目の設定を考える必要があります！
31. アプリ側のログ設計のコツ アクセスログ 注文ボタンを クリック ① リクエストが API Gatewayへ ② Lambdaを発火 ③ 在庫確認 ⑥ レスポンス ⑤ 注文を保存 ④ 決済実行 ここでは Lambda関数内で動いている アプリのログを指します 実行環境ログ 以下を押さえておきましょう！ タイミング, 結果, 理由, 一連の処理を把握できるようにする！ 「エラーが起きた」だけでなく、 「どの処理で、何が起きたか」を残すようにしましょう！
32. 03 ログレベルを意識しよう
33. ログの設計で忘れてはいけないのが
34. ログレベル
35. ログレベル 記録した出来事の重要度や深刻度を表すカテゴリ ログレベルの名前や種類は使う仕組みやロガーライブラリによって異なる！ Python DEBUG INFO WARNING ERROR CRITICAL Ruby DEBUG INFO WARN ERROR FATAL Lambda アプリログ TRACE DEBUG Lambda システムログ DEBUG INFO INFO WARN WARN ERROR UNKNOWN FATAL
36. ログに対して、数種類のログレベルで 意味付けをしていくのが大事です
37. 例えば 参考までに、以下のようにログレベルを定義します。 FATAL, CRITICAL アプリ全体の継続に関わる重大な障害が発生している状態 例）アプリにアクセスできない ERROR ある処理が失敗した状態 例）注文を完了できない WARN, WARNING 処理は続けられるが、注意が必要な状態 例）再試行したら注文できた INFO 通常の運用だが、動作を把握したいイベント 例）DBへの保存リクエスト DEBUG, TRACE 詳しく調査するときに必要な情報 例）開発環境デバッグ用
38. ログをカテゴリ分けすることで 調査をスムーズに行うことができます
39. FATALやERRORには、エラーコードも定義！ INFO 「200系」「300系」の HTTPステータスが一般的 FATAL/ERROR 「400 系」「500系」のHTTPステータスが一般的 よく使われるエラーコードは、 「E」+「HTTPステータス」+「エラーを表す番号」 例えば、 ログを見た時にわかるように 自分で決める E400001・・・必須のカラムが未指定です E404001・・・指定したIDのデータがない E500002・・・INSERT手前で想定外のエラー
40. 異常発生を「知る」仕組みも必要 一方で、FATALやERRORログは、「400系」「500系」の異常系が多い。 中には、すぐに対処しなきゃいけないバグもある... こんな時のために、以下のような仕組みが必要です。 エラーを検知して、通知する仕組み 通知を受け取る仕組みを用意しておくことで、緊急度の高いバグが 見つかった時に即時で知ることができます。
41. 異常系が発生した時にすぐ確認できる仕組み その仕組みによく使われるのが、この2つです。 CloudWatch メトリクスフィルター CloudWatch アラーム CloudWatchに吐き出されるログに 特定の形式のログが出力されたことを キャッチする メトリクスフィルターが 特定のログをキャッチした時に 何かしらの方法で通知する CloudWatch FATALログ
42. これで深夜に バグに起こされる仕組みが完成します！
43. 04 ログ出力における注意点
44. こんな情報はログに入れないようにしましょう！ ユーザの認証情報 企業の機密情報 特に最近は、AIにそのままログを投げてしまうことも多いです。 なので、大事な情報は最初からログに出さない！ （少なくともマスキングするなどの対応はしましょう） ※ モデルの二次学習に利用されないとしても、 サービスのサーバーへデータは送信されますし、 AIが暴走することもあります。 できる限りのリスクヘッジはしておきましょう。
45. 何でもかんでもログに出さない！ FATALやERRORなどの緊急性の高いログは、もちろん出すべき。 しかし、INFOやDEBUGのような緊急性の低いログは選ぶべき！ 本当に見るべきバグが埋もれてしまう ログの量によってコストが増える
46. 05 まとめ
47. まとめ ログを出すのは非常に大事！ ログの内容と出し方を意識しよう！ 必要な情報を簡潔に！ ログレベルによって出力する内容を変える！選定する！ FATAL, ERRORなどの緊急度の高いログに気づける仕組みを！ 大事な認証情報, 機密情報はログに出さない！
48. 東京支部として宣伝！
49. 10/30（金）8:00~9:00 @オンライン
50. 11/5（木）19:00~21:00 @麻布台ヒルズ
51. 11/19（木）12:00~13:00 @オンライン
52. 以上！