アプリケーションログ、 どう出⼒する？どう調査する？ 森井康平 2023/10/07 課題からはじめるオブザーバビリティの第⼀歩

⾃⼰紹介 ● 森井康平 ● 2020年からフェンリル株式会社でエンジニア ● 主な業務内容 ○ AWSの設計/構築/運⽤ ○ サーバーサイド設計/開発/運⽤（PHP / Go） ● マイブームはパン作り 2

この発表の前提 ● 資料は後⽇公開します ● 正確な情報の記載を⼼掛けていま すが、ご⾃⾝のシステムに導⼊す る際には必ず公式の情報を参照し てください ● AWS上で動かすモノリシックアプ リケーションのシステムを前提と します。マイクロサービスの話はあ りません ● 開発寄りの話が多くなりますが、 インフラ担当者に知ってほしい内 容です 3

突然ですが、 こんな経験ありませんか？ 4

ある⽇のやりとり 昨⽇の9時ごろにデータが表⽰さ れなくなったと問い合わせがあり ました。 ユーザーIDは123です。調査お願 いします！ 5 お問い合わせ窓⼝ ※ 架空のお話です

ある⽇のやりとり まずはログファイルをダウンロード して解凍してと。ユーザーIDでgrep してみよう。うーんヒットしない な。9時ごろに何かログ出てないか しらみ潰しに⾒てみよう。怪しい箇 所はなさそうだ。アラートは発⽣し てないしシステム全体は正常だな。 もう調べようがない.. 6 インフラ担当

問題は何か？ 7

問題は何か？ ● 調査に時間がかかったり、不具合が解消できずにユーザー満⾜度が落ちる ○ 問い合わせが来たのは1⼈でも、問い合わせしない同じ症状のユーザーがもっとたくさんいる かもしれない ○ 多くのユーザーは問い合わせをせず、サービスを使うのをやめてしまう ○ 否定的なレビューが増えると、潜在的なユーザーまで失ってしまう ● チームに⻑くいるシニアエンジニアの勘と経験頼り ○ チームに⻑くいればいるほど価値を発揮できる。しかし、次のプロジェクトに移りたくても 抜けられない ○ ジュニアエンジニアはいつまで経ってもシニアエンジニアを超えられない 8

問題は何か？ ● 調査に時間がかかったり、不具合が解消できずにユーザー満⾜度が落ちる ○ 問い合わせが来たのは1⼈でも、問い合わせしない同じ症状のユーザーがもっとたくさんいる かもしれない ○ 多くのユーザーは問い合わせをせず、サービスを使うのをやめてしまう ○ 否定的なレビューが増えると、潜在的なユーザーまで失ってしまう ● チームに⻑くいるシニアエンジニアの勘と経験頼り ○ チームに⻑くいればいるほど価値を発揮できる。しかし、次のプロジェクトに移りたくても 抜けられない ○ ジュニアエンジニアはいつまで経ってもシニアエンジニアを超えられない → オブザーバビリティが低い状態 9

オブザーバビリティとは？ 可観測性は、外部出⼒の知識からシステムの内部状態をどの程度推測できるかを ⽰す尺度です。 （引⽤：https://en.wikipedia.org/wiki/Observability） 10

アプリケーションログ、どう出⼒する？ 11

ログレベル 12

ログレベル ● ログの重⼤度を⽰す ● RFC5424での定義を引き継いでいるロギ ングライブラリが多い ● ログレベルに対してどのような⾏動を取 るかを決める（例：Error発⽣時はメー ルでアラートを⾶ばし、業務時間内で解 消を⽬指す） ● 環境ごとに、どのレベル以上を出⼒する かを決めておく（例：開発環境は Debug、検証/本番環境はInfoなど） 13 引用：https://datatracker.ietf.org/doc/html/rfc5424

⾮構造化ログから構造化イベントログへ 14

構造化イベント イベントとは、本番環境のサービスへの影響を理解 するために、ある特定のリクエストがそのサービス とやりとりしている間に発⽣したすべての記録です。 （中略） 簡単に検索できるようにするため、そのマップに書 き込まれたデータはキーバリューのペアとして整理さ れ、フォーマットされます。つまりデータは構造化さ れていなければならないのです。 15 引用：オブザーバビリティ・エンジニアリング Charity Majors、Liz Fong-Jones、George Miranda　著、大谷 和紀、山口 能迪　訳

構造化ログの実現⽅法 PHPでは、MonologのJsonFormatterを導⼊するだけで対応可能。 JsonFormatter適⽤後 { "message": "Hello!", "context": {}, "level": 200, "level_name": "INFO", "channel": "local", "datetime": "2023-10-07T09:00:00.000000+09:00", "extra": {} } デフォルトのログフォーマット [2023-10-07 09:00:00] local.INFO: Hello! 16

構造化イベントに追加する情報を決める 17

構造化イベントに追加する情報を決める オブザーバビリティにおいて、⾼ディメンションかつ ⾼カーディナリティのデータを⽐較することが、複雑 なシステムアーキテクチャに埋もれ、隠れた問題を発 ⾒するための重要な要素となります。 （中略） カーディナリティがデータ内の値のユニークさを意味 するのに対し、ディメンションはデータ内のキーの数 を意味します。 18 引用：オブザーバビリティ・エンジニアリング Charity Majors、Liz Fong-Jones、George Miranda　著、大谷 和紀、山口 能迪　訳

構造化イベントに追加する情報を決める ● リクエストコンテキスト ○ パス ○ メソッド ○ ボディ ○ クライアントIP ● レスポンスコンテキスト ○ ステータスコード ○ ボディ ○ 経過時間 ● 時刻 ● ユーザーID ● 実⾏サーバーID ● 取引ID ● ログレベル ● 発⾏したクエリ、パラメーター ● 外部連携システムへのリクエス ト/レスポンス 19 出せる限りの全ての情報を記録したい。しかし、パフォーマンス、コスト、 セキュリティの観点から、全てを記録することはできません。システムの状態 を理解するのに必要と思われるデータに絞り込みましょう。

クラウドで動かすシステムは、複数のサービス で連携してリクエストを処理します。各サービ スのログを紐づけるためにトレースIDを記録す るのがよいでしょう。トレースIDがない場合 は、時刻情報で⾒当をつけるしかなくなってし まいます。 トレース情報を追加する 20

トレース情報を追加する 21 引用：https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-request-tracing.html

トレース情報を追加する ● ALBがトレースIDを発⾏してく れるので、アプリケーションま で引き回してイベントログに追 記すれば良いだけ ● X-Rayに送信して可視化すること も可能（らしい） 22 X-Amzn-Trace-Id Root=1-63441c4a-a bcdef012345678912 345678 requestId 1-63441c4a-abcdef0 12345678912345678 x_amzn_trace_id 1-63441c4a-abcdef0 12345678912345678

構造化イベントログの流れ Request Request Response 処理開始ログ コンテキスト追加 ‧クライアントIP ‧トレースID 処理開始ログ コンテキスト ‧クライアントIP ‧トレースID 処理終了ログ ‧レスポンスボディ ‧ステータスコード ‧エラーメッセージ …など 処理開始ログ ‧ユーザーID ‧クライアントIP ‧トレースID …など 何らかの処理ログ ‧取引ID ‧問い合わせID …など 23 PHPではMonologのwithContextメソッドを呼ぶだけで、後続のすべてのログエ ントリに含めるコンテキスト情報を指定できる

構造化イベント出⼒のイメージ（正常系） {"message":"REQUEST START","context":{"server_host":"local","path":"api/info","method":"GET","x_forwarded_for":"192.0.2.0","x_a mzn_trace_id":"Root=1-63441c4a-abcdef012345678912345678"},"level":200,"level_name":"INFO","channel":"local" ,"datetime":"2023-09-29T19:49:08.897865+09:00","extra":{}} {"message":"取得件 数:[2]","context":{"server_host":"local","path":"api/info","method":"GET","x_forwarded_for":"192.0.2.0","x_a mzn_trace_id":"Root=1-63441c4a-abcdef012345678912345678","user_id":"111"},"level":200,"level_name":"INFO"," channel":"local","datetime":"2023-2023-10-07T09:00:00.000000+09:00","extra":{}} {"message":"REQUEST END","context":{"server_host":"local","path":"api/info","method":"GET","x_forwarded_for":"192.0.2.0","x_amz n_trace_id":"Root=1-63441c4a-abcdef012345678912345678","user_id":"111","status_code":200,"duration_ms":200. 00000000000000},"level":200,"level_name":"INFO","channel":"local","datetime":"2023-2023-10-07T09:00:00.0000 00+09:00","extra":{}} 24

アプリケーションログ、どう調査する？ 25

選択肢1 Amazon Athena ● S3上のファイルに標準SQLを実⾏ ● サーバーレスのためインフラストラクチャ の管理が不要 ● CSV、JSON、ORC、Avro、Parquet に対 応 ● ペタバイト規模まで対応可能 ● 分析ようにデータ整形したい場合はAWS Glueを使⽤してETL処理が可能 26

選択肢2 Amazon CloudWatch Logs ● CloudWatch Logs Insightsを使⽤してクエ リが可能（≠標準SQL） ● クエリを使⽤しなくてもGUIからログの確 認や全⽂検索が可能 ● メトリクスフィルターによるアラーム実⾏ ● Live Tailによるリアルタイム表⽰ ● 機密データのマスキング 27

選択肢3 Amazon OpenSearch Service ● OpenSearch クラスターの管理を容易にす るマネージドサービス ● OpenSearchおよびElasticsearch OSSをサ ポート ● サーバーレス版（オンデマンド⾃動ス ケーリング）も提供 ● SQLやGUIで検索可能 ● トレース分析 28

機能も違いますが、料⾦体系に⼤きな違いがあります。 ● Athena ○ S3保存費⽤+Athenaデータスキャン量（ざっくりいうと、格安） ■ Athena ● 5.00USD per TB of data scanned ■ S3 Standard ● 最初の 50 TB/⽉ 0.025USD/GB ● 次の 450 TB/⽉ 0.024USD/GB ● 500 TB/⽉以上 0.023USD/GB ● CloudWatch Logs ○ データ収集、保存、分析それぞれ従量課⾦（ざっくりいうと、データ⼊れれば⼊れるほどコスト上昇） ■ 収集 (データの取り込み) 0.76USD/GB ■ 保存 (アーカイブ) 0.033USD/GB ■ 分析 (Logs Insights のクエリ) スキャンしたデータ 1 GB あたり 0.0076USD ■ 検出およびマスク (データ保護) スキャンされたデータ 1 GB あたり 0.12USD ■ 分析 (Live Tail) 0.01 USD/分 ● OpenSearch Service ○ インスタンス費⽤とEBS費⽤（ざっくりいうと、ほぼ固定費） ■ インスタンス費⽤（EC2よりも割⾼） ● t3.medium.search vCPU2 メモリ4GiB 0.112USD ■ EBS費⽤（EC2よりも割⾼） ● 汎⽤ SSD (gp3) - ストレージ 1 GB あたり 0.1464USD/⽉ 料⾦⽐較 29 ※2023年10⽉時点の東京リージョンの料⾦

どのサービスを選ぶ？ ● アプリケーションログの⽂脈では、GUIで表⽰できて⼿軽に使える CloudWatch Logsがおすすめ ● よりランニングコストを抑えたい場合はAthena ● CloudWatch Logsのパフォーマンスが物⾜りない場合や、ログの流量が多く データ取り込み費⽤を抑えたい場合、OpenSearch特有の機能を使⽤したい 場合はOpenSearch Serviceを検討 30

まとめ ● ログレベルを適切に設計しましょう ● 構造化イベントログを出⼒しましょう ● 構造化イベントログにはトレース情報も追加しましょう ● ログ収集/検索サービスは、まずCloudWatch Logsを検討しましょう。ランニ ングコストが⾼い場合はAthenaを検討しましょう。パフォーマンスが物⾜り ない場合はOpenSearch Serviceを検討しましょう 31

よきオブザーバビリティライフを 32

ご清聴ありがとうございました 33

Q&A：構造化は常にするべき？ ⾮構造化ログのほうが⽂字数が少なくなるため、⽐較的に⼈間が⾒やすい利点が あります。ただし、検索するには構造化ログのほうが適しています。 開発時は⼈間が⾒やすいようにカスタマイズすることも可能です。 ● 環境変数でログチャンネルを切り替える ● jq などを使⽤してフィルタリングする よって、ほとんどの場合には構造化するべきでしょう。 34