株式会社リゾーム システム企画・開発部 第4グループの萩原です。
読書会の第7回目のレポートです。 第6回目のレポートは、こちらになります。
読書会の題材
前回に引き続き 入門 監視 ―モダンなモニタリングのためのデザインパターン を題材としています。
7回目レポート
今回は、「7章 アプリケーション監視」で、参加者は5名でした。
それぞれの感想・意見交換
メトリクスでアプリケーションを計測する
- クエリの実行時間や応答時間以外に、何を計測するべきか。
- アプリケーションパフォーマンス監視(APM)
- そのままでも小綺麗な滝グラフ、それっぽいグラフは出るけれど、言われてみれば確かに。
- APMを追加しだけでは何のコンテキストも把握していないというのは、そりゃそうだよなぁと思った。
- 自分たちが計測したいものと向き合う必要がある。
- 7章全体を通して StatsD の説明が多い。
- StatsD を利用すれば、Logger などのように必要な箇所に追加しておくだけで良い。
かなり細かい部分までデータ収集できそう。 - 確かにメトリクスの組み込みは、病みつきになりそうな予感がした。
- 自分たちのモチベーションに繋がるメトリクス取得ができると良い気がする。
反応が得られないとやりがいを見出しにくい。 - New Relic ではどう取り扱えばよいか確認しておきたいところ。
- StatsD を利用すれば、Logger などのように必要な箇所に追加しておくだけで良い。
- StatsD は聞いたことがない……。
- CloudWatch エージェント、カスタムメトリクスでCPU使用率を取得していた。
- 思い出すまでにいくらか時間がかかってしまったが、気付かないうちに恩恵を受けているのだな。
- StatsD よりも Prometheus の方が良いという意見も……。
- StatsDはドット区切りの記法になるので、書き方がバラける可能性がある。
- StatsD が古株だからではないか。後発の技術の方が融通が効く。
ビルドとリリースのパイプラインの監視
- パイプラインの監視・ログ出力は行っているが、得た情報を上手く利用できていない。
- 現状、エラー時のトラブルシューティング程度にしか活用できていない。
何かあった時に見る程度。 - Webistrano でデプロイ情報を確認できるが、これらの情報を元に更に何かアクションを起こすことはない。
- Heroku で誰がデプロイしたか記録されているし、Rundeck の方も時間の記録はされているが、やはり活用はできていない。
- これやったの誰？ が起きると困るから、誰が何をしたかも必要なんだろうなと。
AWS では AWS CloudTrail がこれに当たると思われる。
- 現状、エラー時のトラブルシューティング程度にしか活用できていない。
- デプロイ前後でアプリケーションがどう変わったかの監視は十分にできていないかも。
- 本当に役立つのはアプリケーションやインフラのメトリクスと共に利用するメタ情報。
- デプロイ履歴が監視サービス上で追跡できることは、パフォーマンスの向上・低下の確認や、障害調査時の原因特定に有用かもしれない。
- 環境全体が動作しているかの確認は、どこに問題が発生しているか一目で分かるので便利。
- メトリクスにデプロイタイミングをラベルとして付けておくと、その前後でどうなったかが一目瞭然で凄い。
- New Relic ではデプロイによるパフォーマンス変化を追跡できるらしい。
- SC BASE *1 では一部環境のデプロイに Rundeck を利用している。 現在進捗何パーセントか、成功・失敗したか、どのくらいの時間がかかったかが分かるようになっている。
healthエンドポイントパターン
- ヘルスチェック用APIを作っておくのは良さそう。
- 以前、バージョンとステータス一覧を表示させるページを用意し、異常を発見した場合は報告を上げるようにしようというやり取りをしたことがある。これを自動化するイメージかな。
- エンドポイントにアクセスが可能なアドレスは限定する。
- 外形監視としてこのエンドポイントを利用しているが、よくある考え方だったのか。
- ロードバランサーのヘルスチェックに使う一般的なURL名だと思っていた。
- 確かにデータベースやデータストアにアクセスできなければアプリは使用できない状態なので、これらの情報もあった方がいいと思う。
- データストアや外部APIを使用している場合これらも確認するとよいらしい。
- やり過ぎるとエラーが返ってきた時に調査範囲が広くなってしまい面倒なような。
- 複数のエンドポイントを用意するのがいいんだろうか？
- 改めてHTTPステータスコードは正しく使おうと思った。
そして構造化ログとして必要な情報をきちんと載せるようにする。 - BOND GATE *2 では本で紹介している内容と同じく、データベースに接続して1レコード SELECT し、成功すればHTTPステータスコード200を返す処理を行っている。
アプリケーションロギング
- syslog 正直あんまりよく分かってない。rsyslog もよく分かってない。
- Ruby on Rails の Lograge が紹介されていた。
デフォルトの production.log は見にくいので、導入しても良いかもしれない。 - Ruby on Rails の複数行にまたがったログを、まとまった情報として見られるようになればいいのに。
- ログ出力する場合は、ログをパースしていい感じに表示する環境・サービスがあれば、そっちの方がいいのかもしれない。
メトリクスにすべきか、ログにすべきか
- ログエントリとして情報をデータベースに保存しておけば、後からこれらを加工・統計処理して使用することも可能なように見える。
- メトリクスの方が良い場合とは？
- メトリクスの方がシンプルだが、いくつも送るようならログの方が良さげ。
何のログを取るべきか
- 何でもかんでも取りましょう！ でなくて良かった。
- 書いてあることにほぼ同意。
ツールの問題なら一次情報を多く保存しておいた方が良いと思う。 - 問題があった部分を探す時間を短くするためにも取捨選択は必要。
ログが肥大化してしまい、拾ってこれない・検索しづらい状況はある。 - 必要なログを選定するためにも、目的を見失わないようにすることが大事。
ログを取得することばかりに気を取られるのではなく、ログの中身を見ておかないといけない。 - 今までは障害発生時にアラートを出す意味で監視していたが、この本を通じて他の意味を持つログを出力する重要性も理解した。
一方でログ出力にも一定のコストがかかる訳で、単に量を増やすのではなく、必要なログを必要なだけ取らないといけない。
これは程度の問題になるので判断に迷うところではないだろうか。
- 書いてあることにほぼ同意。
- 俺たちは何を取ればいいんだ？
- ログインにかかる時間の計測から少しずつ追加していけば良いのではないか。
- BOND GATE であればバッチ処理の時間？ Rundeck で動かしているので取得はできている。
例えば日付単位のメトリクスを New Relic 上で確認できるようにすれば、日に日に遅くなっているかを確認することができるようになるのでは。 - 時間のかかる処理、失敗しやすい処理には、細かめのログがあった方がいいのかもしれない。
失敗した場合に画面やデータベースを調査しないと分からない状態だと、気付くにしても調査にしても時間がかかってしまう。
- BOND GATE では操作ログを取っているので、調査する時など便利ではある。
問題はデータ量が多すぎる点。迂闊にSQLを投げることができないし、ディスク容量を圧迫するので何とかしたい。
ディスクに書くべきか、ネットワーク越しに送るべきか
- ログをディスク上のファイルに書き込む方が良い。
定期的に外部にデータを送る機能があるサービスも組み合わせられる。 - データベースに保存しておくと、データ中継やバックアップはしやすそう。
- NoSQLデータベース？ Elasticsearch？
- データベースバックアップにかかる時間や、データベース自体の容量が増えそう。
- Django Admin が管理画面の操作ログを取得しているが、ログの量が膨大なため Heroku の無料枠を超えることも。一長一短はあると思う。
マイクロサービスアーキテクチャを監視する
- マイクロサービスは監視の問題も含めてだが、先進的過ぎるような気が。
- サーバレス・マイクロサービス・分散トレーシングは、そもそもよく分からない……。
- 分散トレーシングの仕組みは理解できるが、実際の実装・設定はリクエストIDの受け渡しが常に付いて回る訳で。
- Zipkin は勉強会で聞いたことがあるけれど、マイクロサービスから縁遠い生活を送っているので、どこの世界の話や……みたいな気分だったのを覚えている。
- マイクロサービスにすると1つ1つはシンプルだけど、異なるところで複雑さが生まれてくるよなぁ……と思う。
- これもまた慣れの問題かもしれない。Zipkin に慣れていたら、どうということはない的な。でもやっぱり複雑。
- マイクロサービスアーキテクチャの採用は、成熟した組織でないと厳しいのではないだろうか。
- 技術選定や設計の段階からモノリシックなアプリケーションとは異なる。
- 新しい技術に臆さず知識を吸収していけるようなスキルは必要に思う。
まとめ
healthエンドポイントの利用やStatsDによるメトリクスの取得など、あまり『監視』を意識せずその恩恵にあずかっていたようです。
既製のサービスをそのまま利用していると、自分たちが計測したいこと・アプリケーションのコンテキストを反映せずに使用してしまうことも……。今後は『自分たちのアプリケーションでは何を監視したいのか・監視すべきなのか』を更に意識して利用していきたいと思います。
エンドポイントによるヘルスチェックや、ログの収集・送信など基本的な部分はどのプロジェクトも問題なく実施できている様子。 今の方法が基本から逸れていないことを再確認できました。
一方で取得後のデータを活用し切れていないのではないか、という課題も浮き彫りになりました。 リリース後のパフォーマンス追跡、操作ログの管理方法など、当書を通じて改善すべき点を見出すことができました。
次回は「8章 サーバ監視」です。
