kakudooo docs

構成案

課題・背景、目標の整理(5分)
- 課題・背景
  - ログについての前提知識の整理
    - 構造化ログ・非構造化ログ
    - ログを用途で分類(監視、調査、分析、監査)
  - この発表で対象とするログの用途(監視、調査)について
    - 課題・背景(不具合の検知、障害からの復旧時間短縮をはじめとした信頼性の担保)を例にログの用途との関連付けでイメージを掴んでもらう
  - 今回の発表で想定するWebアプリケーションの構成について説明
- 目標
  - 監視ツールを使った監視、調査業務でログの活用がされること
    - 各サーバープロセスで構造化ログが出力されている状態
Railsアプリケーションのログを構造化する(5分)
- ロギング手法の調査とライブラリの選定
  - 標準ログ機能の拡張やライブラリの導入など、複数ある方法の比較検討
  - 構造化ロギング用途にSemantic Loggerを選択。その理由
- 構造化ロギングのために試行錯誤したポイントを紹介
  - 共通
    - エラーログのフォーマットを監視ツールに合わせる
      - 監視ツールで合わせるか？アプリケーションで合わせるか？の検討
  - Rakeタスク
    - Rakeタスクで発生した例外を構造化ロギングに対応させる
      - 複数ある手法の比較検討
      - Rakeにパッチを当てる方法を選択。その理由
監視ツール(Datadog)でのログ活用(3分)
- ログの構造化により、監視・調査観点でログ活用がどう改善されたのかを説明
  - エラー追跡、アラート、APMとの関連づけなど、監視ツールとの連携が強固になったこと、検索性やプログラムからの活用がスムーズになったことを説明
まとめ(2分)
- Railsアプリケーションの各サーバープロセスにおいて、監視ツールで求められるフォーマットで構造化ログを書き出すことが出来ることの重要性
- Railsでの構造化ログ標準化への期待
  - (https://github.com/rails/rails/issues/50452)[https://github.com/rails/rails/issues/50452]

一部の内容はブログとして公開もしております。

アウトラインv1

課題・背景・目標の整理

Plex Job(HRプラットフォーム)では、Plex Job(ダイレクトリクルーティングサービス)を構成する各プロダクト(求人サイト/ATS)、社内の人材マッチングの効率化ツールの開発と運用を行っている
各システムは一般的なWebアプリケーションであり、いずれもRailsが使われている
- 構成を簡単に説明(オードソックスなWebアプリケーションであり特別な非機能要件や要素などはない)
- 社内システムもHerokuをインフラのプラットフォームとして使用している以外は同じ構成である
HRプラットフォームの成長により求人サイト/ATSを中心として、小規模から中規模開発への移行期を迎えた
- サービス利用者数の増加
- 社内ユーザー、関連チームの増加
- 社内外の複数システムとの連携
- など
安定性や信頼性がより求められるように
- 不具合時の損失
- 運用コストの増加
不具合の検知、障害からの復旧時間短縮をはじめとした信頼性の担保をする
- 監視の強化
- 監視のためのログ収集(活用できるログの収集)
- ログとログの分類について整理しておく
- システム規模の拡大や外部システムとの連携の増加により、「監視」や「調査」業務における情報源を増やし活用していきたいというニーズがあることの確認と前提整理
現状
- 監視ツール(Datadog)を導入していた
  - 当時は、APM機能は有効化されており、トレース情報に基づくエラートラッキングなどの機能については活用できている状態でした。ログについては、監視ツール(Datadog)に送信・収集されているものの、不具合時に関連しそうなログを検索してみる、程度の活用しかされていなかった
- SREチームなどの専門性のあるチームなどはない。(顧問としてSREを見ていただいている方はいる)状態。
目標
- SWEのみのチームでなるべく監視を強化していく
- 監視のための情報源としてのアプリケーションログの収集を整備し、ツールや運用業務に活用していけるようにする
- そのためアプリケーションを構成する各サーバープロセスで構造化ログが出力されている状態
補足
- 他にも取り組んだことはあるが、今回は時間が限られるので構造化ログの出力にあたっての課題に絞る

Railsアプリケーションのログを構造化する

課題に対してのアプローチはテーマ2個くらいが適切(15分と時間が限られているため)

ブログ2本分のテーマはあるので、コンパクトにまとめる

ロギング手法の調査とライブラリの選定
- 標準ログ機能の拡張やライブラリの導入など、複数ある方法の比較検討
  - 構造化ロギング用途のモジュールのスタンダードがない、監視ツールのドキュメントはLogrageを推奨しているがメンテナンスされていないなど、情報としては古い
- 構造化ロギング用途にSemantic Loggerを選択。その理由
構造化ロギングのために試行錯誤したポイントを紹介
- 共通
  - エラーログのフォーマットを監視ツールに合わせる
    - 監視ツールで合わせるか？アプリケーションで合わせるか？の検討
- Rakeタスク
  - Rakeタスクで発生した例外を構造化ロギングに対応させる
    - 複数ある手法の比較検討
    - Rakeにパッチを当てる方法を選択。その理由

ログ活用

監視ツール(Datadog)でのログ活用(3分)
- ログの構造化により、監視・調査観点でログ活用がどう改善されたのかを説明
  - エラー追跡、アラート、APMとの関連づけなど、監視ツールとの連携が強固になったこと、検索性やプログラムからの活用がスムーズになったことを説明

Railsでの構造化ログ標準化やエコシステム進化の期待

課題に対して取り組んできた内容と、Railsへの期待が対応している形にしたい

構造化ログ
- Railsでの構造化ログ標準化への期待
  - (https://github.com/rails/rails/issues/50452)[https://github.com/rails/rails/issues/50452]
RakeとRails統合

まとめ

信頼性向上の一歩目として監視、調査用途のログを出力することのススメ
- Railsアプリケーションの各サーバープロセスにおいて、監視ツールで求められるフォーマットとしての構造化ログの重要性
- アプリケーションエンジニアを中心としたチームでも取り組むことが可能。専門性のあるチームに良い形でバトンを渡すことができる
Railsアプリケーションのログ出力を構造化する際にはいくつか課題があり、チームの状況に合わせて採用する技術を検討する必要があること
上記に課題については、構造化ログをはじめとして一部Railsがフレームワークとしてサポートする動きがあること(Rails標準機能に乗り換えられるように意識しておく必要がある)

アウトラインv2

Railsアプリケーションのログ、活用できるようになっていますか？課題提起
まずログについて整理
- 構造化ログと非構造化ログ
- ログの用途について分類
今日話すこと
- 信頼性担保の観点で、構造化ログが有用であること
- Railsアプリケーションを構造化ログに対応させる上での課題とアプローチ方法
- Railsと構造化ロギングのこれから
対象者
- なんとなくRails.loggerでログを書き出している方
- 立ち上げフェーズもしくはそれをを経て、そろそろ監視をはじめとした信頼性について考え始めた方
- アプリケーションの監視をはじめようとしているが、どこから手をつけてよいか迷っている方
私達の話し課題
- Plex JobというHRプラットフォームを作っています
  - 求人サイト/ATSはじめ、社内の人材マッチングの効率化ツールなど複数を開発・運用
  - 各システムは一般的なWebアプリケーションであり、いずれもRails(APIモード)を使って開発している
  - 社内システムもHerokuをインフラとして使用している以外は同じ構成になっている
- 立ち上げから4年ほど経過し、サービスも順調に成長してきた
  - サービス利用者数の増加
  - 社内ユーザー、関連チームの増加
  - システムの複雑性
    - 社内外の複数システムとの連携
    - 取り扱う職種領域の(ドメイン)の広がり
- システムの利用者の数と複雑性から
  - 不具合時の損失
  - 運用コストの増加
  - → 小規模 → 中規模と勝手に定義しています
- 信頼性を担保する必要性が出てきた
  - 監視
  - 調査&復旧業務の効率化
  - → いずれもシステムの状態を知るために、ログの収集が重要
  - → ログの収集を見直し
  - SWEのみのチームでなるべく監視を強化していく
    - 監視のための情報源としてのアプリケーションログの収集を整備し、ツールや運用業務に活用していけるようにする
- 当時のログ活用度
  - 監視ツール(Datadog)を導入していた
    - APM機能は有効化されており、トレース情報に基づくエラートラッキングなどの機能については活用できている状態でした。ログについては、監視ツール(Datadog)に送信・収集されているものの、不具合時に関連しそうなログを検索してみる、程度の活用しかされていなかった
    - SREチームなどの専門性のあるチームなどはない
解決方法と目標
- そのためアプリケーションを構成する各サーバープロセスで構造化ログが出力されている状態にする。また、監視ツールで提供されている機能に合わせてログの構造化を行う。
- 各サーバープロセスを構造化ログに対応させる上で行う上でいくつか課題があった
- その中でもログを出力する上で事前に知っておくとよさそうなものを中心に紹介します
Railsアプリケーションのログを構造化する
- ログの構造化と監視ツールとの連携
  - 構造化ロギングの手法を選定・導入
  - → これでwebプロセス、workerプロセスは網羅
  - → 監視ツール向けのスキーマにも対応
- Rakeタスクの例外を構造化ロギングする
  - 構造化しきれていない箇所
  - → これで定期バッチプロセスも網羅
ログ活用の現在
- 監視ツールとの連携が強固に Datadog
  - エラートラッキング
  - アラート
  - APMとの関連付け
    - ログを構造化したことにより自動認識
  - など
- ログエクスプローラーからの検索性の向上
- パッチ用のスクリプトからの活用(サルベージ)の効率化
まとめ
おまけ Rails8.1と構造化ログ

スライド作成tips

https://blog.lacolaco.net/posts/deck-markdown-to-google-slides/
https://gist.githubusercontent.com/lacolaco/f11270f4fb663841976e873b55020978/raw/2298348132e16f02a3af8183db1b815d9c7a130b/tskaigi-2025.md
https://kaigionrails.org/2024/talks/ohbarye/
https://speakerdeck.com/ohbarye/learn-architecture-through-admin?slide=7

サービスが成長すると…

ログまわりの困りごと

ユーザー数が増えて、障害の影響範囲が拡大
復旧や調査にかかる時間・コストが増加
ログはあるけど「ノイズが多い」「フォーマットがバラバラ」で活用しづらい

👉 ログはあるのに、信頼性を高める武器になっていない

RakeタスクはRailsコマンドで実行することが可能ですが、タスクの実行についてはRailsのエコシステムで実行されるわけではありません。例外についても独自の機能traceメソッドでエラー出力されます。