株式会社リゾーム システム企画・開発部 第4グループの萩原です。
読書会の第2回目のレポートです。
第1回目のレポートは、こちらになります。
tech.rhizome-e.com
読書会の題材
前回に引き続き 入門 監視 ―モダンなモニタリングのためのデザインパターン を題材としています。
2回目レポート
今回は、2章「監視のデザインパターン」で、参加者は6名でした。
それぞれの感想
組み合わせ可能な監視
- UNIX哲学「一つのことを、うまくやれ」
- ここでもUNIX哲学が出てくる。
- 改めて監視に当てはめて聞くと、なるほどと納得した。
- 聞いたことはある(が、内容を理解はしていない……)。
- 専門的なツールを組み合わせる方が、複合的なツールを扱うよりいいのかもしれない。
- 個別にも使えるし、組み合わせても使える。一つだけ乗り換えることもできる。
- 必要なものだけ使用することで、無駄を省くことができる。
ただ、どんな監視が必要かを明確にしておかないと持ち腐れになってしまう。
- Elastic Stack が正にこれ、やはり気になる。
データ収集
- 最近の主流はプッシュ型でしょう。
- プル型では監視対象の増減管理などが面倒そう。
プッシュ型であればデータをプッシュしなくなるだけなので楽そう。
- スケールしやすいメリットも、クラウドサービスを利用しているなら重要。
- 送りたいものが送りたいところに送る自発的・合理的なツール。便利そう。
- BOND GATE*1 では、以下を利用している。
- 外形監視としてプル型
- インフラ等のメトリクス取得にはプッシュ型
メトリクス
- 「カウンタ(Counter)」
- 「ゲージ(Gauge)」
- HDD使用量はゲージっぽさがあるけれど、カウンタの役割にも似ている。
Nヶ月後に80%超える的な予測ができる。
ログ
- 非構造化ログが普通と思っていたが、JSONで出力すればいいのかと気付かされた。
- JSON・キーと値のペアなど、ログが見やすい。
- 追加したキーの分ログサイズが大きくなるデメリットはあるが、ログが読みやすくなるメリットにおいて勝る。
- 考えれば考えるほど、JSON出力して Elasticsearch に食わせて Kibana で検索すればいいのでは……。
- Webアプリを作成する視点から見ると、構造化ログの取り回しが良さそう。
非構造化ログだとコンソールのように出力するか、構造化ログに直してから使用するか。
- BOND GATE では、Nginxログを Elasticsearch + Kibana で閲覧するためLTSV形式で構造化している。
New Relic でもログを見やすく改善したい。
データストレージ
- 「メトリクスの間引き」
- ログの量もバカにならないため、間引くというのはなるほどなと思った。
確かに過去のCPU使用率など細かく見る必要がない。
- 料金コストがもったいないので、運用ルールを作成し削除を行うようにしたい。
- 必要なものはどれくらいの周期で見るかをきちんと考える必要がある。
毎分見る必要ないものなど当然ある(CPU・HDD空き容量)。
- Webアプリが出すログにはデータベース保存・ログファイル出力・直接Amazon CloudWatchに送るなど種類があるが、
どれが監視の場面で使いやすいかをあまり考えずに、デフォルトで使っていることが多い気がする。
- BOND GATE では、ログを Fluentd で Amazon S3 へ転送・バックアップしている。
可視化
- 価値あるダッシュボードとは？
- あまりダッシュボードを使ったことがなかったので気になる。
- 何を見れるようにすればいいのか分からなかった。何を見るべきかを学びたい。
- Tableau などのデータ可視化ツールは、これにあたるのか。
- Service Level Agreement(SLA, サービス水準合意)
- 可用性をあげるのはAWSをもってしても難しいので、ほどほどにしておけという話。
- SLAが出せるのは、アプリケーションの稼働率が算出できるから。
これ以外の目的・場面でどのように監視で得たデータを利用していけば良いのだろうか。
- 自分でダッシュボードを作るのは難しい。
- 何をダッシュボードに表示させるべきなのかが、よく分からない……。
- 何のデータを欲しているか、正しく分析出来ていないからか。
- 機能ではなくデザインを追求して、余計なことをしてしまうことはよくある。
作る側は綺麗に色々なグラフを並べたくなりがち。監視という目的を忘れないようにしたい。
- New Relic のデフォルトのダッシュボードで十分な気もする。
アラート
- 「何か問題がおきた時にアラートを出すことが監視システムの目的だと信じている」
- 何か問題が起きた時にアラートを出すことが監視システムの目的、ではないのか？
- どうしてもWebアプリの範囲しか見えていないと、障害やエラーへの対処と紐付いてしまう。
もちろん開発中に明らかに時間のかかる処理などはパフォーマンスを確認するが。
- 「監視は、質問を投げかけるためにある。」
- 分かるような、分からないような……。
- CPU使用率が高いからといって問題とは限らないとか、高い原因を探るための判断材料とかいうことだろうか。
- アラートには、本当にまずいアラート・気付きのあるアラートの2種類が存在する。
- 運用的にはセーフだが気付きのあるアラートを作ることも大切なのではないか。
ユーザー視点での監視
- ユーザーから監視するとはどういうことか？
- とても大事な視点。監視のスタートはお客様からだったか。
- 真っ先に浮かんだのは外形監視。まずはアプリケーションが動いているかどうかが重要。
- どの機能がよく使われているか分かれば、サービス改善の順番を考えるのに使える。
- 時間帯別のアクセス数がわかれば、スケールアウト・スケールイン戦略を立てることができる。
常時同じスペックのサーバを動かすよりはコスト削減に繋がるだろう。
- サービスを継続させるための監視なのに、ユーザー視点を度外視していたら、それは監視と言えないのでは。
- 「HTTPレスポンスコード(特に HTTP 5xx 番台)」
- New Relic APM でデフォルトのダッシュボードに表示されるようになったので見ようと思う。
- 監視ツールの具体的な活用方法が見出だせないでいる。
- リクエスト時間、ページの表示速度などたまに見るが、そこから発展して何かするとかはあまりない。
- 結局障害発生時しか見ないので、常時監視ツールを開いておく必要があるかどうか。
作るのではなく買う
- 監視ツールの設計・作成による恩恵をどう捕らえるか。
- SaaS によるアウトソースを行うことで、溜まりにくい知見もあるのではないか。
確かに直接売上をもたらさないかもしれないが、運用スキルは上がるのではないか。
- これらの経験を踏まえた上でコスト面・監視対象を考慮に入れたSaaS選定ができるようになれば次に繋げていくことができる。
- クラウドサービスを利用した方が良いという結論も、
共有のレンタルサーバ・VPS・自宅サーバの運用経験しているからこそ出てくるものだと思う。
- 優先順位の問題ではないか。車輪の再発明や自作ツールの作成により技術を高めるか、
自社プロダクトの専門分野に特化した開発に注力するか。
- SaaS にしても詳しい人が必要になるので、コスト削減に繋がるかは疑問が残る。
- メンテナンスコストを考えれば理解できるが、他のコストについても考慮に入れるべきでは。
- メンバー全員に対して教育コストがかかると考えると、既製ツールを使っても結構なコストになりそう。
- 監視の仕組みが成熟していない時は買い、システムがツールを超えて成長してきたら何かに特化した自作ツールを作る感じ。
- 現状は、監視のサービスを使って基礎を整える段階っぽい。
- 監視ツールはSaaSやOSSをそのまま使う形にしがちだが、あるところまではこれでいい、ということが分かったのは大きい。
- 安いしどんどん便利になるし導入も簡単です使いなさい。
- 自分達で構築するよりはSaaSを使うか、出来の良いFOSSを使う方がいい気はする。
継続的改善
- 「継続は力なり」
- 常に監視を行う習慣を身に付けるとともに、設備や環境も整えていかねば。
- ふと「コードと向き合い過ぎてませんか？ サービスと向き合えてますか？」という問いが頭に浮かんだ。
- インフラやログは一度作ると、動いているうちは更新が滞りがち。
バージョンアップは大前提だが、より良い機能が増えたなら活用するなど、常に良い監視ができるように改善するようにしていきたい。
- 完成と思わない、変わるのが前提。
実用性重視で取り組むのが良いのだろうなと感じた。
- 段階を踏んで監視を変えないと、仕組みが整ってない状態で進んでしまい失敗する。
とりあえず、変えてみたになる。
意見交換
「価値あるダッシュボード」とは
Q.「価値あるダッシュボード」とは何か、具体的なイメージが掴めていません。
これまでの業務で行ったカスタマイズ事例などがあれば知りたいです。
A.New Relic APM のダッシュボードを眺めつつ、備わっている機能の確認やダッシュボードについての議論を行った。
- New Relic APM を見てみる。
- CPU利用率がスパイクしている部分を拡大。
- 遅いクエリのリストを確認。
- ダッシュボードのカスタマイズについて。
- 複数のダッシュボードを作ることはできる。
- プランや仕様によってはダッシュボードに表示できないものもある。
- 見たい情報をダッシュボードに集めるようにすれば、それが「価値あるダッシュボード」なのでは。
- 開発者・営業・サポート・ユーザー視点など、様々なダッシュボードがあるのでは。
- 開発者にとって遅いクエリの情報は重要だが、営業には不要。
- 同様に立場や仕事内容によって、必要な情報は異なる。
- こういった監視方法もユーザー目線の監視なのかもしれない。
- アクセス解析は広義の監視と捉えても良いのではないだろうか。
- システム利用率が低下したときにアラートを出してはどうか。
- 疑問をなげかけるアラート。見る価値がありそう。
- カスタムメトリクスでログイン回数を集計し、ログイン率が低い場合にアラートを出すなど。
- アクティブユーザー数を分析することで、事前に何らかの対策を打つことができるのでは。
営業視点で考えれば減少というのは大事な事象なので、共有した方がいいかもしれない。
まとめ
現在の監視体制はデザインパターンに即したベストプラクティスなのか、開きがある部分はどのように業務に取り入れていったらよいか、あるいは今はまだ取り入れない方がよいのか。
取り扱うプロダクトはメンバーそれぞれですが、監視という共通の括りで感想・意見交換を行う中で、具体的な改善点が見えてきたようです。
まだ合点がいかない部分も疑問が残る部分もある状態ですが、「第Ⅰ部 監視の原則」もやっと半分というところ。読書会を進めていく中で知識を得、より理解を深めていければと考えています。
次回は「3章 アラート、オンコール、インシデント管理」です。
